[llvm-commits] Trampoline support (pointers nested funtions)

Duncan Sands baldrick at free.fr
Sun Aug 12 08:46:56 PDT 2007


On Thursday 2 August 2007 02:55:57 Chris Lattner wrote:
> 
> On Jul 31, 2007, at 3:08 PM, Evan Cheng wrote:
> 
> >>> Also, isn't the static chain register described in  
> >>> X86CallingConv.td?
> >>
> >> It is, but it's hard to use here.  The problem is that when  
> >> lowering the
> >> init.trampoline intrinsic you only have a pointer to the target  
> >> function.
> >> From this pointer you would like to find out which register a certain
> >> parameter will be passed in for that function.  Not so easy!  It's  
> >> like
> >> having a call instruction without having the arguments.  In order to
> >> exploit X86CallingConv.td, you have to use all the lowering  
> >> machinery,
> >> which isn't adapted to this case.  For example, you could try to  
> >> synthesize
> >> a fake call.  Or you could pretend to be lowering the target  
> >> function.  I
> >> tried it, and it can be done with a lot of horrible hacking.  But  
> >> it's not
> >> worth it.  It's much simpler to simply grab the calling convention  
> >> and use
> >> that, which unfortunately means keeping LowerTRAMPOLINE and
> >> X86CallingConv.td in sync.  Personally I can live with that,  
> >> especially since
> >> I've seen the alternative and it still wakes me up screaming at  
> >> night :)
> >> But maybe you can see a reasonable way of doing it?
> >
> > Seems like a deficiency in CCState class. Chris, your thoughts?
> 
> Isn't the argument always a pointer, and thus always the same thing  
> for a particular calling conv?

It is, but that's not the problem: the problem is that you need to
know how the *other* arguments are lowered in order to know whether
there was a register left for the static chain argument, or whether
an argument that would have been passed in a register if the static
chain wasn't there is not passed in a register if the static chain
is there (these are all error conditions).  Only a problem on X86.

Ciao,

Duncan.



More information about the llvm-commits mailing list