PATCH: don't tail call functions with 3 'inreg' arguments on x86-32 PIC

[Eli Bendersky]

On Wed, Feb 13, 2013 at 10:54 AM, Nick Lewycky <nlewycky at google.com> wrote:
> On 13 February 2013 09:00, Eli Bendersky <eliben at google.com> wrote:
>>
>> [forwarding review to llvm-commits. I hit "Reply" by mistake]
>>
>> On Tue, Feb 12, 2013 at 6:21 PM, Nick Lewycky <nlewycky at google.com> wrote:
>> > This patch is one way of fixing PR15250, by only forming a TCRETURN call
>> > to
>> > a function with up to two 'inreg' arguments. This extends a fix
>> > implemented
>> > by Evan in r105092.
>> >
>> > Patch attached, please review!
>> >
>>
>> LGTM, with a small question about the test:
>>
>> +; RUN: llc < %s -relocation-model=pic | FileCheck %s
>> +; PR15250
>> +
>> +target datalayout =
>>
>> "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S128"
>> +target triple = "i386-unknown-linux-gnu"
>> +
>> +declare void @callee1(i32 inreg, i32 inreg, i32 inreg)
>> +define void @test1(i32 %a, i32 %b) nounwind {
>> +; CHECK: test1:
>> +; CHECK: calll callee1 at PLT
>> +  tail call void @callee1(i32 inreg 0, i32 inreg 0, i32 inreg 0) nounwind
>> +  ret void
>> +}
>>
>> Should the test also verify that a tail call did not happen here?
>
>
> It does, if it were a tail call we'd see a jmp to callee1 instead of a call
> instruction.

What I was meaning to say is this: in some cases the tail is not
converted to a jump because the result is not directly returned. The
callee stack frame is still popped before the call, however. But
looking at the source again, I realize that this shouldn't have
happened in your case since you don't do anything with the result of
callee1, so indeed if TCO was applied it should've went all the way to
a jump.

Eli