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

Rafael EspĂ­ndola rafael.espindola at gmail.com
Thu Jan 3 11:21:34 PST 2013


> on the other hand, the optimizers will turn recursive tail calls into a
> loop.  I didn't check whether this optimization tests for byval, but it
> would be a wrong to generate a loop when there are byval parameters in
> general.
>
> There may be other cases like this.  I think it would be wise to audit the
> code base to see what deductions transforms make based on the tailcall flag
> being set.  That should give a better idea of whether it is better to simply
> disallow byval or not (or allow some kind of compromise).  Whatever the
> conclusion is, it would be good to document it explicitly.

That is not illegal in general, is it? The simple function from the
example above:

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

Can be turned into an infinite loop by an IL pass (but no pass in
-std-compile-opts does it right now). The real constraint is that the
pointer value can be different in the caller and callee, but
optimizations have to handle that even if the call is not tail.

> Ciao, Duncan.

Cheers,
Rafael



More information about the llvm-commits mailing list