[llvm-dev] analysis based on nonnull attribute

[Hal Finkel via llvm-dev]

----- Original Message -----

> From: "Michael Kuperstein" <michael.kuperstein at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Sanjay Patel" <spatel at rotateright.com>, "llvm-dev"
> <llvm-dev at lists.llvm.org>, "Michael Kuperstein" <mkuper at google.com>
> Sent: Thursday, December 15, 2016 1:13:07 AM
> Subject: Re: [llvm-dev] analysis based on nonnull attribute

> I think what Sanjay is getting at is that it's not an integer, it's
> still a pointer - but it's not clear where information about
> non-nullness of the pointer should be propagated to.

> In this particular case, since the def of %x in the caller is also an
> argument, we could propagate it to the def directly, e.g.

> define i1 @foo(i32* nonnull %x) {
> %y.i = load i32, i32* %x ; inlined, still known to be nonnull

> And if the def of %x was a load, we could use !nonnull. But I'm not
> sure what we can do in the general case (say, %x = select...).
> The best I can think of is generating an llvm.assume for the
> condition.
True. In this case, the preferred thing would be to add the nonnull attribute to the caller's parameter. Adding llvm.assume is indeed a general solution. 

-Hal 

> Michael

> On 14 December 2016 at 14:05, Hal Finkel via llvm-dev <
> llvm-dev at lists.llvm.org > wrote:

> > > From: "Sanjay Patel" < spatel at rotateright.com >
> > 
> 
> > > To: "Hal Finkel" < hfinkel at anl.gov >
> > 
> 
> > > Cc: "llvm-dev" < llvm-dev at lists.llvm.org >
> > 
> 
> > > Sent: Wednesday, December 14, 2016 4:03:40 PM
> > 
> 
> > > Subject: Re: [llvm-dev] analysis based on nonnull attribute
> > 
> 

> > > On Wed, Dec 14, 2016 at 2:51 PM, Hal Finkel < hfinkel at anl.gov >
> > > wrote:
> > 
> 

> > > > > From: "Sanjay Patel via llvm-dev" < llvm-dev at lists.llvm.org >
> > > > 
> > > 
> > 
> 
> > > > > To: "llvm-dev" < llvm-dev at lists.llvm.org >
> > > > 
> > > 
> > 
> 
> > > > > Sent: Wednesday, December 14, 2016 3:47:03 PM
> > > > 
> > > 
> > 
> 
> > > > > Subject: [llvm-dev] analysis based on nonnull attribute
> > > > 
> > > 
> > 
> 

> > > > > Does the nonnull parameter attribute give us information
> > > > > about
> > > > > subsequent uses of that value outside of the function that
> > > > > has
> > > > > the
> > > > > attribute?
> > > > 
> > > 
> > 
> 

> > > > Yes. We're guaranteeing that we never pass a null value for the
> > > > argument, so that information can be used to optimize the
> > > > caller
> > > > as
> > > > well.
> > > 
> > 
> 
> > > Thanks! I don't know if that will actually solve our sub-optimal
> > > output for dyn_cast (!), but it might help...
> > 
> 
> > > https://llvm.org/bugs/show_bug.cgi?id=28430
> > 
> 

> > > > > Example:
> > > > 
> > > 
> > 
> 

> > > > > define i1 @bar(i32* nonnull %x) { ; %x must be non-null in
> > > > > this
> > > > > function
> > > > 
> > > 
> > 
> 
> > > > > %y = load i32, i32* %x
> > > > 
> > > 
> > 
> 
> > > > > %z = icmp ugt i32 %y, 23
> > > > 
> > > 
> > 
> 
> > > > > ret i1 %z
> > > > 
> > > 
> > 
> 
> > > > > }
> > > > 
> > > 
> > 
> 

> > > > > define i1 @foo(i32* %x) {
> > > > 
> > > 
> > 
> 
> > > > > %d = call i1 @bar(i32* %x)
> > > > 
> > > 
> > 
> 
> > > > > %null_check = icmp eq i32* %x, null ; check if null after
> > > > > call
> > > > > that
> > > > > guarantees non-null?
> > > > 
> > > 
> > 
> 
> > > > > br i1 %null_check, label %t, label %f
> > > > 
> > > 
> > 
> 
> > > > > t:
> > > > 
> > > 
> > 
> 
> > > > > ret i1 1
> > > > 
> > > 
> > 
> 
> > > > > f:
> > > > 
> > > 
> > 
> 
> > > > > ret i1 %d
> > > > 
> > > 
> > 
> 
> > > > > }
> > > > 
> > > 
> > 
> 

> > > > > $ opt -inline nonnull.ll -S
> > > > 
> > > 
> > 
> 
> > > > > ...
> > > > 
> > > 
> > 
> 
> > > > > define i1 @foo(i32* %x) {
> > > > 
> > > 
> > 
> 
> > > > > %y.i = load i32, i32* %x ; inlined and non-null knowledge is
> > > > > lost?
> > > > 
> > > 
> > 
> 

> > > > It should be replaced by !nonnull metadata on the load. We
> > > > might
> > > > not
> > > > be doing that today, however.
> > > 
> > 
> 

> > > We can't tag this load with !nonnull though because this isn't a
> > > load
> > > of the pointer?
> > 
> 
> > > "The existence of the !nonnull metadata on the instruction tells
> > > the
> > > optimizer that the value loaded is known to never be null. This
> > > is
> > > analogous to the nonnull attribute on parameters and return
> > > values.
> > > This metadata can only be applied to loads of a pointer type."
> > 
> 

> > True, but we have range metadata for integers.
> 

> > -Hal
> 

> > --
> 

> > Hal Finkel
> 
> > Lead, Compiler Technology and Programming Languages
> 
> > Leadership Computing Facility
> 
> > Argonne National Laboratory
> 

> > _______________________________________________
> 
> > LLVM Developers mailing list
> 
> > llvm-dev at lists.llvm.org
> 
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 

Hal Finkel 
Lead, Compiler Technology and Programming Languages 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161215/918ab3d9/attachment.html>