[llvm-commits] PATCH: Tailcallopt x86 byval argument handling

[Evan Cheng]

On Apr 8, 2008, at 3:19 PM, Arnold Schwaighofer wrote:

> Sorry i don't seem to be able to handle gmail that well this time of  
> day :)
>
>>> I am not very comfortable with this. Is the registers that can be
>>> impacted somehow specified in X86CallingConv.td? I don't want to get
>>> into a situation where someone updates the .td file but forgot to
>>> update this code.
> I am not sure i understand. The impacted Registers RSI,RDI,RCX (or
> their 32bit respectives) always stays the same. They have nothing to  
> do
> with the calling convention. A change in callling convention - which
> registers are used for passing does not influence above set (in the
> sence that above set is conservative, knowing the calling convention
> some of the above registers could be removed). It is caused by the
> fact that there has to be a byval lowering between moving actual
> parameters to registers and the tail call. the byval lowering creates
> new values in the RSI,RDI,RCX (ESI,EDI,ECX) registers invalidating the
> ones from the argument lowering - so arguments targeting those
> registers have to be temporarily stored to virtual registers before
> the byval lowering to be restored to the actual target registers
> aftwards.

Ok, I misread it. These are the registers that are used in the lowered  
memcpy code sequence for byval? The trouble is this is assuming  
memcpy's are always lowered a certain way which doesn't seem safe to  
me. There seems to be a phase ordering problem here. We need for the  
byval memcpy to be lowered first before we issue the copies to save  
these registers in virtual registers. Do you think that's possible?


>
>
>
>> Will this work for all the CC that might want tail
>> call support?
> probably i can not see why not.
> but there are other issues to support them there. (like the callee vs.
> caller pops issue and the PIC/GOT problem, which of course can be
> resolved by restricting tail call optimization to certain cases
> there).

Ok.

>
>> Is it necessary for all the copyfromreg and copytoreg to be chained
>> and flagged together? Perhaps each pair need to be flagged together
>> and chains from all pairs ended up feeding into a TokenFactor?
> I will look at that. Probably not. ;)

Thanks.

Evan

>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits