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

Nick Lewycky nlewycky at google.com
Wed Feb 13 10:54:21 PST 2013


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.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130213/2e4ad379/attachment.html>


More information about the llvm-commits mailing list