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

Arnold Schwaighofer arnold.schwaighofer at gmail.com
Wed Apr 9 04:32:33 PDT 2008


On Wed, Apr 9, 2008 at 9:05 AM, Evan Cheng <evan.cheng at apple.com> wrote:

>  Ok, I misread it. These are the registers that are used in the lowered
>  memcpy code sequence for byval?
yes
> 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?

No i believe not. The problem with reordering is that when performing
tail call optimization we always have to keep in mind that we might
end up copying arguments (caller function's) onto arguments (tailcall
function's) overwriting each other. So a special ordering has to be
obeyed.

copy byval arguments to the top of the stack
[1]
move arguments to registers

emit a series of copytovirtreg copyfromvirtreg
for the tailcallclobbered arguments

store the copyfromreg values to the tailcall stack slots

copy byval arguments form the top of the stack to their
tailcall stack slot [<- this line would have to be moved to 1]

We can't move the last line after the first line because we might
overwrite arguments that are source for the registers. confusing.
definitately ;)

consider this example:
int (struct{int,int} a byval, int b) {
     tailcall callee(int b,struct{int,int} a byval))
}

say we generate the following code sequence

copy byval args to top of stack
copy byval args to tail call position
[ups we are overwriting b]
mov b to a argument register
[wrong b]

BUT: I think it is possible to eliminate the check for esi, edi, ecx.
Instead of only copying the 'byval clobbered' registers to virtual
registers and back this will be done for all argument registers (if
byval args occur). The register allocator will than hopefully do the
rest (eliminating the unneccessary ones).

D'oh - there is always a simpler solution waiting to be beaten out of
me by evan. ;-)

ill try this and correct the other stuff and hopefully return with a
new shiny patch

i'll be back

regards arnold



More information about the llvm-commits mailing list