[llvm] r219899 - TRE: make TRE a bit more aggressive

[Hal Finkel]

----- Original Message -----
> From: "Rafael Espíndola" <rafael.espindola at gmail.com>
> To: "Nick Lewycky" <nlewycky at google.com>
> Cc: "llvm-commits" <llvm-commits at cs.uiuc.edu>
> Sent: Friday, October 17, 2014 4:08:41 PM
> Subject: Re: [llvm] r219899 - TRE: make TRE a bit more aggressive
> 
> On 17 October 2014 16:50, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
> >> It is not so much the backend, it is also the language spec:
> >>
> >> It says "Both markers imply that the callee does not access
> >> allocas or
> >> varargs from the caller." and I think that is what -dse was using
> >> in
> >> pr7272 to break the code even before codegen.
> >
> > Running
> >
> > ./bin/opt ~/llvm/llvm/test/Transforms/Inline/byval-tail-call.ll -S
> > -basicaa -inline -tailcallelim -dse
> >
> > I now get
> >
> > define void @frob(i32* %x) {
> >   %x1 = alloca i32, align 4
> >   %1 = bitcast i32* %x1 to i8*
> >   call void @llvm.lifetime.start(i64 4, i8* %1)
> >   tail call void @ext(i32* %x1)
> >   tail call void @ext(i32* null)
> >   %2 = bitcast i32* %x1 to i8*
> >   call void @llvm.lifetime.end(i64 4, i8* %2)
> >   ret void
> > }
> >
> > Note how %x1 is passed uninitialized to ext.
> 
> The attached patch reverts the commit but updates this test to use
> FileCheck variables to make it more obvious what the problem caused
> by
> the patch was.
> 
> OK?

Can we also update the LangRef to spell this out? The "Both markers imply that the callee does not access allocas or varargs from the caller." does not clearly cover byval arguments (in practice they're often implemented similarly to non-entry-block allocas in the caller, but they could be on the callee's stack frame in some ABIs, and regardless, at the IR level they're not allocas). The byval documentation says only, "The attribute implies that a hidden copy of the pointee is made between the caller and the callee, so the callee is unable to modify the value in the caller." so it does not specify in which stack frame the pointer is considered to reside.

Thanks again,
Hal

> 
> Cheers,
> Rafael
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory