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

Eli Friedman eli.friedman at gmail.com
Fri Mar 5 15:16:11 PST 2010


On Fri, Mar 5, 2010 at 2:18 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Evan,
>
>> Fix an oops in x86 sibcall optimization. If the ByVal callee argument is itself passed as a pointer, then it's obviously not safe to do a tail call.
>
>  > +      // define @foo(%struct.X* %A) {
>  > +      //   tail call @bar(%struct.X* byval %A)
>  > +      // }
>
> in this case maybe the call should not have been marked "tailcall" in the
> first place?  i.e. I'm suggesting that this is really a bug in
> TailRecursionElimination.

Take the following testcase:
void b(float), c(double);
struct x { float a; double b; int c : 10; };
__attribute((noinline)) static void a(struct x x) { b(x.a); c(x.b); }
__attribute((noinline)) static void e(struct x* x) { a(*x); }
struct x *xs;
void d() { e(xs); }

The call to a from e generates precisely the given construct on
x86-32, and piping it from llvm-gcc to llc -tailcallopt generates a
perfectly valid tail call.  The issue in question is specific to the C
calling convention x86.

-Eli




More information about the llvm-commits mailing list