llvm dev - Aug 2011 - [LLVMdev] [PATCH] Go on dragonegg

Attached patches change how dragonegg lowers trampolines (for
compatibility with Go).

--
Sanjoy Das
http://playingwithpointers.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-the-trampolines-for-Go.patch
Type: text/x-diff
Size: 5108 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110818/93e0501d/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Turn-on-segmented-stacks-for-Go.patch
Type: text/x-diff
Size: 1192 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110818/93e0501d/attachment-0001.patch>

Hi Sanjoy,
> Attached patches change how dragonegg lowers trampolines (for
> compatibility with Go).
I think the right approach is to add an llvm.adjust.trampoline intrinsic
to LLVM (and change llvm.init.trampoline to not return a result).  Then the
dragonegg trampoline code will become trivial, and the Go problem will just
Go away :)  In fact this was how I first did it: two intrinsics, just like in
GCC (probably the commits are still in the repository history).  Chris asked me
to combine them into one if possible, and I did but I now think that that was a
mistake because they don't go naturally together: the call to
adjust_trampoline
can occur far away from the call to init.trampoline (eg: in a different
function).  As you can see in the dragonegg code, by doing evil tricks you can
overcome this difference between the intrinsics, but as you also discovered it
is fragile and broke the moment Go generalized the use of trampolines.

Ciao, Duncan.

Hi!
> I think the right approach is to add an llvm.adjust.trampoline intrinsic
> to LLVM (and change llvm.init.trampoline to not return a result).  Then the
Won't that break previous code that relies on the current
llvm.init.trampoline? I can start work on this if that is not a problem.

-- 
Sanjoy Das
http://playingwithpointers.com