[LLVMdev] Quick trampoline intrinsics question

[Philip Reames]

I strongly suspect that this use case wasn't considered.  :)  The honest 
answer is that an interested party could probably spec whatever they 
wanted as long as a) it was reasonable and b) it didn't break existing 
uses.

I could see possible reasons why we might want a non-relocatable 
trampoline (i.e. smaller code on a fast path), but I don't know if we 
exploit that today.

Without giving it too much thought, is there any reason that trampoline 
generation shouldn't follow the global "-fPIC" setting? This would seem 
like a reasonable way to support both relocatable and non-relocatable 
trampolines.

Taking a step back, let me ask a more fundamental question.  Why does 
the *code* need to move?  I can understand that the data needing to move 
- which clearly isn't supported today for trampolines - but why the 
code?  I would expect the code to be shared between many instances of an 
"add int parameter at position 2 with value X" object (for example).

On a tangent, I'm not sure that the trampoline mechanism is the right 
one for procedure objects as you call them.  I would expect a lowering 
closer to a standard struct with a member function.  The member function 
does the parameter manipulation, with the data being stored in the 
struct.  This has the advantage of being 'normal data' and thus handled 
by the existing statepoint support.

Philip


On 12/25/2014 11:42 AM, Jonathan S. Shapiro wrote:
> The specification of llvm.init.trampoline does not say whether the 
> trampoline can safely be moved after code has been generated. Is there 
> any contract about this?
>
> My question is motivated by copying collectors, which may want to 
> relocate procedure objects (in llvm-speak: trampolines). If the 
> generated trampoline code uses a PC-relative call instruction, then 
> either:
>
>  1. The trampoline needs to be updated during relocation (in which
>     case I need a way to recover the target procedure's address), or
>  2. Trampolines cannot be relocated
>
> I know that I can look at the LLVM implementation to see what it 
> actually does, but if this question is not resolved by the 
> specification of llvm.init.trampoline then the implementation is free 
> to change in future.
>
> Thank you.
>
>
> Jonathan
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141229/d25c204f/attachment.html>