[llvm-dev] analysis based on nonnull attribute

[Michael Kuperstein via llvm-dev]

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>