[llvm-commits] Trampoline changes

[Chris Lattner]

On Sep 9, 2007, at 1:46 AM, Duncan Sands wrote:

> Hi Nick,
>
>>> It is easy to construct testcases for which this works, but sadly  
>>> I was unable to get
>>> the optimization to occur even once in a trampoline heavy real- 
>>> world program without
>>> jacking-up the inlining limit hugely (to 100000; 10000 wasn't  
>>> enough).  Still, I'm
>>> hoping that it may sometimes be useful.
>>
>> Why does changing the inliner threshold help? Are you talking about
>> inlining the trampoline itself or the llvm.init.trampoline intrinsic?
>> Could we adjust the weights in the inliner so that it does it more
>> often, seeing as a trampoline call is much more expensive than a  
>> regular
>> call?
>>
>> Would you mind sending a small before and after example for the
>> transformation implemented by your instcombine patch?
>
> My hope was that some of these trampoline calls could be eliminated  
> using this optimization.  But for
> that to happen, the routines in the container library have to be  
> small enough to be inlined.  They are
> not.  In fact they're rather small in terms of lines of code, but  
> exception handling etc really bulks
> up the LLVM bitcode making the inliner pass them over.

It would be pretty straight-forward to implement an IPO pass that  
turns trampoline pointers into fat pointers in cases like this.  It  
sounds like it could be a big win for the container library, because  
the container (if the routines get marked internal) would  
automatically be converted to take fat pointers, even if there are  
multiple different trampolines being passed in.

-Chris