[llvm-commits] [llvm] r40549 - in /llvm/trunk: docs/ include/llvm/ include/llvm/CodeGen/ include/llvm/Target/ lib/AsmParser/ lib/CodeGen/SelectionDAG/ lib/Target/ lib/Target/ARM/ lib/Target/Alpha/ lib/Target/IA64/ lib/Target/Mips/ lib/Target/PowerPC/ lib/Target/Sparc/ lib/VMCore/

[Chris Lattner]

On Jul 27, 2007, at 5:58 AM, Duncan Sands wrote:

> Author: baldrick
> Date: Fri Jul 27 07:58:54 2007
> New Revision: 40549
>
> URL: http://llvm.org/viewvc/llvm-project?rev=40549&view=rev
> Log:
> Support for trampolines, except for X86 codegen which is
> still under discussion.

Nice.  You just had to make a lier out of me...  on wednesday I said  
we probably wouldn't have trampolines for quite a while ;-)

Comments below:

>
>  <!--  
> ====================================================================== 
> = -->
>  <div class="doc_subsection">
> +  <a name="int_trampoline">Trampoline Intrinsics</a>
> +</div>
..
> +  These intrinsics make it possible to excise one parameter,  
> marked with
> +  the <tt>nest</tt> attribute, from a function.  The result is a  
> callable
> +  function pointer lacking the nest parameter - the caller does  
> not need
> +  to provide a value for it.  Instead, the value to use is stored in
> +  advance in a "trampoline", a block of memory usually allocated
> +  on the stack, which also contains code to splice the nest value  
> into the
> +  argument list.  This is used to implement the GCC nested  
> function address
> +  extension.


Nice summary.  Dummy question: it isn't possible to merge the init  
and adjust intrinsics, is it?  If the result of init can only be used  
by adjust, it seems reasonable to merge them.

> +<p>
> +  Trampolines are currently only supported on the X86 architecture.
> +</p>

LangRef.html should not describe implementation state, please remove  
this comment.


> +declare void @llvm.init.trampoline(i8* <tramp>, i8*  
> <func>, i8* <nval>)

> +  The <tt>llvm.init.trampoline</tt> intrinsic takes three  
> arguments, all
> +  pointers.  The <tt>tramp</tt> argument must point to a  
> sufficiently large
> +  and sufficiently aligned block of memory; this memory is written  
> to by the
> +  intrinsic.  Currently LLVM provides no help in determining just  
> how big and
> +  aligned the memory needs to be.

I would suggest changing this last sentence to:

"Note that this size is target-specific - LLVM currently provides no  
portable way to determine the size or alignment to use for the  
memory, so a front-end that generates this intrinsic must have some  
target-specific knowledge."

> +SDOperand ARMTargetLowering::LowerADJUST_TRAMP(SDOperand Op,
> +                                                    SelectionDAG  
> &DAG) {
> +  // Thumb trampolines should be entered in thumb mode, so set the  
> bottom bit
> +  // of the address.
> +  return DAG.getNode(ISD::OR, MVT::i32, Op.getOperand(0),
> +                     DAG.getConstant(1, MVT::i32));

This may or may not be right in the future.  For now, both GCC and  
LLVM compile an entire file in thumb or in arm mode.  In the future,  
we may mix and match functions as appropriate.  Can you please add a  
fixme to this saying that we should reevaluate it if the caller and  
callee can ever be different ISAs.

-Chris