Michael Kuperstein via llvm-dev
2016-Dec-15 07:13 UTC
[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.
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161214/b23eef09/attachment.html>
Hal Finkel via llvm-dev
2016-Dec-15 07:20 UTC
[llvm-dev] analysis based on nonnull attribute
----- 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>
Michael Kuperstein via llvm-dev
2016-Dec-16 19:03 UTC
[llvm-dev] analysis based on nonnull attribute
By the way, I've been wondering - why can we only attach !nonnull and !range to loads (for both) and call/invoke (for !range)? I mean, those are all instructions you can't do dataflow through - intraprocedurally, w/o memoryssa - but why only these instructions? Why not allow annotating any pointer def with !nonnull and any integer def with !range? Sure, that's redundant w.r.t llvm.assume, but so are the existing annotations. On Wed, Dec 14, 2016 at 11:20 PM, Hal Finkel <hfinkel at anl.gov> wrote:> > > ------------------------------ > > *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/20161216/a7408c01/attachment.html>