[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