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

[Arnold Schwaighofer]

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.


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