[llvm-commits] [PATCH] Remove tail marker when changing an argument to an alloca.

Rafael EspĂ­ndola rafael.espindola at gmail.com
Tue Jan 1 16:49:17 PST 2013


On 1 January 2013 12:26, Duncan Sands <baldrick at free.fr> wrote:
> Hi Rafael, if a call uses a 'byval' parameter, should it be marked as a tail
> call in the first place?  After all, byval implicitly places a copy of the
> passed argument on the stack, so the call is implicitly using the stack.
> There is the question of who puts the copy on the stack: the caller or the
> callee?  If the former, maybe there isn't a problem after all...

That is an interesting point. On one hand, we cannot produce an tail
call (as in, an actual jump) for

%X = type { i32 }
define void @g(%X* byval %b, %X* byval %a) {
entry:
  tail call void @f(%X* %a, %X* %b)
  ret void
}
declare void @f(%X* byval, %X* byval)


but it would be nice to remain the ability of producing one for

%X = type { i32 }
define void @g(%X* byval %a) {
entry:
  tail call void @f(%X* %a)
  ret void
}
declare void @f(%X* byval)

Since the language spec says the code generator "may optimize", I
think we can interpret the "does not access any allocas or varargs in
the caller" at the IL level. If, for a given function, the code
generator has to produce stack space for a call, than it is free to
not doing the optimization. It looks like that is what the x86 backend
does for the above examples.

> Ciao, Duncan.

Cheers,
Rafael



More information about the llvm-commits mailing list