[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 Aug 22, 2007, at 4:57 PM, Duncan Sands wrote:

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

As we discussed, I think following GCC's model is fine.

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

Ahhh, ok!

-Chris