[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/

[Duncan Sands]

Hi Chris,

> 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.

yes they can be merged, but that would require some gcc hacking (not
trivial, but not hard either).  The reason is that gcc currently stores
the memory for the trampoline in the frame object that gets passed
around to nested functions.  When a nested functions wants to call
the trampoline, it takes the address of this memory from the object it was
passed and calls adjust_trampoline on it - this can happen far away from the
trampoline initialization.  What would need to be done is to move the memory
out of the frame object and into an alloca, and store a function pointer
inside the frame object instead.  init_trampoline would then initialize the
trampoline memory and generate the function pointer, which would then be
stored in the frame object.  Shall I do it?

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

Done.

> 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."

Done.

> > +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.

I don't know anything about ARM or thumb, but I think the reason is that
the trampoline itself (i.e. the code on the stack) is written in thumb
mode (remember that this is a canned sequence of instructions that are
not generated by LLVM itself), and thus should be called via a pointer
with the bottom bit set.  The nested function itself, the code for which
is generated by LLVM, can presumably be in thumb mode or not, and will
have the mode encoded in the lower bit of its address in the usual way;
when the trampoline jumps to it, the correct new mode should be set
appropriately.  So I don't see any problem here, assuming we copy the
trampoline initializer from gcc (where it is a bunch of thumb mode
opcodes).

Ciao,

Duncan.