[llvm-commits] [llvm] r95351 - in /llvm/trunk: lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/tailcall2.ll

[Evan Cheng]

On Feb 5, 2010, at 12:23 AM, Duncan Sands <baldrick at free.fr> wrote:

> Hi Evan,
>
>> Handle tail call with byval arguments.
>
> if you have a tail call with byval arguments, does this mean that an  
> extra copy
> of the byval argument won't be made?  This came up with the C++

Correct. The whole point is the byval argument is already available in  
the caller's incoming argument stack. This kind of tail call is  
especially beneficial.

> thunk
> implementation in dragonegg, where you can get this kind of thing:
>
> define void @f_thunk(xyz *%this, %struct *%x byval) {
> ... adjust %this ...
>  tail call void @f(xyz *%new_this, %struct *%x byval)
> }
>
> It would be nice if this didn't result in a second copy of %x being  
> made
> on the stack when calling @f.  Is this the case?

If %this and %new_this are passed in registers, then yes.

Evan

>
> Thanks,
>
> Duncan.
>
> PS: To be honest, I don't mark the call to @f "tailcall" because I  
> was worried
> that it is invalid to do, since after all the byval argument creates  
> a stack
> object which is used by the callee, which is exactly what tail calls  
> are not
> supposed to do...  On the other hand, the optimizers happily mark @f  
> "tailcall",
> but I suspect that's because the tailcall optimization pass doesn't  
> know about
> byval, and not because it is being clever...