search for: nonnull

Hello all, LangRef says it is undefined behavior to pass null to a nonnull argument (`call f(nonnull null);`), but the semantics is too strong for a few existing optimizations. To support these, we can relax the semantics so `f(nonnull null)` is equivalent to `f(poison)`, but (A) it again blocks another set of optimizations, and (B) this makes the semantics of nonnull dev...

...ibutes is usually the other way around, since function calls need to have UB as strong as the worst behavior of the function. If a function may for some reason trigger UB with a given set of arguments, then the function call has to trigger UB as well. Imagine something like: Call f(null, 1) int f(nonnull %ptr, int c) { if (c) deref %ptr } You can't use the "used" attribute, since UB is only conditional. So we would say the return value of f(null, 1) is poison. But if you inline the function you get UB. Inlining has to continue to be correct without exceptions. Maybe I misunders...

...t it seems that removing "used" wouldn't be possible. This is because a function with "used" gives poison, and without gives UB. It should the other way around, such that optimizers can freely remove "used". To make it clear, what I understood was: - %v = call @fn(nonnull null) -- %v == poison - %v = call @fn(nonnull used null) -- UB Even if the function is just a load of the pointer argument. Nuno > Imagine something like: > Call f(null, 1) > > int f(nonnull %ptr, int c) { > if (c) > deref %ptr > } > > You can't use th...

...calling the attribute "used" is confusing. I'd suggest the following: "not_poison": If an argument is marked not_poison, and the argument is poison at runtime, the call is instant UB. Whether an argument is poison is checked after the rules for other attributes like "nonnull" and "align" are applied. This makes it clear that the IR semantics don't depend on the implementation of the called function. And it's the logical extension of the way we define the relationship between UB and poison for instructions. -Eli > -----Original Message-----...

...ing code section, they seem redundant. However, when I remove them, the behavior of the code becomes non-deterministic. The live ranges of the variables defined by them are never used in the code. Thanks, --------------- %37 = bitcast i32* %7 to i8* call void @llvm.lifetime.start.p0i8(i64 4, i8* nonnull %37) #5 store i32 0, i32* %7, align 4, !tbaa !4 %38 = bitcast i32* %8 to i8* call void @llvm.lifetime.start.p0i8(i64 4, i8* nonnull %38) #5 store i32 99, i32* %8, align 4, !tbaa !4 %39 = bitcast i32* %9 to i8* call void @llvm.lifetime.start.p0i8(i64 4, i8* nonnull %39) #5 store i32 1,...

...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 &gt...

...'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 Dec...

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...

...----- > 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 > > &g...

...t; > > ------------------------------ > > *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 optim...

...ut didn't. e.g. call metadata/attributes allow us to model external calls, load metadata allow us to model frontend knowledge of external memory locations, etc.. On 12/16/2016 11:03 AM, Michael Kuperstein via llvm-dev wrote: > 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...

...re putting !range on an add instruction as part of a transform pass, that would clearly be several steps too far. > > Admittedly, the only example I have in mind right now is the one under > discussion above - if we have: > > %p = select i1 %a, i8* %x, i8 *y > call void foo(i8* nonnull %p) > > Then after inlining foo, we lose the non-null information for %p > unless we annotate it - and we can't propagate it through the select. > The same would happen for a phi, Are there cases where we loose information by inlining this example? Yes. Are they common? I don&...

...t's a semantic property, so I don't really see why that means we should prohibit annotating certain instructions on the syntactic level. Admittedly, the only example I have in mind right now is the one under discussion above - if we have: %p = select i1 %a, i8* %x, i8 *y call void foo(i8* nonnull %p) Then after inlining foo, we lose the non-null information for %p unless we annotate it - and we can't propagate it through the select. The same would happen for a phi, On Fri, Dec 16, 2016 at 11:25 AM, Philip Reames <listmail at philipreames.com> wrote: > The general idea to dat...

...dd > instruction as part of a transform pass, that would clearly be several > steps too far. > Yes. > > > Admittedly, the only example I have in mind right now is the one under > discussion above - if we have: > > %p = select i1 %a, i8* %x, i8 *y > call void foo(i8* nonnull %p) > > Then after inlining foo, we lose the non-null information for %p unless we > annotate it - and we can't propagate it through the select. The same would > happen for a phi, > > Are there cases where we loose information by inlining this example? > Yes. Are they comm...

----- Original Message ----- > 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 calle...

>>> 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 >>> For propagation of non-nullity to the argument, don't you need value propagation or backward all dataflow analysis? IE. define i1 @foo(i32* %x) if (%x != NULL) { %y.i = load i32, i32* %x ; inlined } // d...

Based on the earlier comments in this thread and the existence of a transform that adds 'nonnull' to callsite params, I have proposed a patch to extend nonnull to a parent function: https://reviews.llvm.org/D27855 ...but given today's comments about inferring the analysis rather than making it part of the IR, this might be the wrong approach? On Fri, Dec 16, 2016 at 12:49 PM, Philip R...

Does the nonnull parameter attribute give us information about subsequent uses of that value outside of the function that has the attribute? 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)...

On Wed, Feb 19, 2020 at 3:51 AM Juneyoung Lee via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I think not_poison (Johannes's used keyword) makes sense. We can simulate the original UB semantics by simply attaching it, as explained. > For the attributes other than nonnull, we may need more discussion; align attribute seems to be okay with defining it as poison, dereferenceable may need UB even without nonnull (because it needs to be non-poison as shown Nuno's hoisting example). For reference, the hoisting example was: f(dereferenceable(4) %p) { loop() {...

This weekend, I got an email from Nuno Lopes informing me that UBSAN now paid attention to attribute(nonnull), and he was having some problems with it going off when using libc++. I did some investigation, and found that he was exactly right - there were places (deep inside the vector code, for example) which called std::memcpy(null, null, 0) - which is definitely UB. In an ideal world, our C library wo...