search for: not_poison

Two thoughts: 1. I think that we should aim for regularity, to the extent possible, and so we should treat nonnull, align, etc. similarly w.r.t. to whether they produce poison or UB. 2. I was thinking about the following last night, and it clarified for me why having an not_poison attribute makes sense and seems useful, and how poison/UB might affect things on a function-call boundary itself. Imagine that we had a fastcc lowering strategy that took a pointer argument with an alignment attribute, followed by a suitably-small integer argument, and implemented a calling convent...

On 02/19, Juneyoung Lee via llvm-dev wrote: > Hello, > > > Would it be correct to resolve this by saying that dereferenceable(N) > > *implies* not_poison? This would be helpful as a clarification of how > > it all fits together. > > Yes, I think it makes sense. I don't we should do that. Take the `gep inbounds` example: char* foo(char *arg) { return `gep inbounds %arg, -100` } Here it depends if we want to deduce the output is...

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

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

...e to understand what are the deficiencies of value-wise poison. Is there any major issue? I'm asking because value-wise poison seems to be a much simpler concept, so if it works ok it seems to be preferable. During the meeting last week, Richard Smith proposed that instead we add a "load not_poison %ptr" (like load atomic) instruction that would be equivalent to load+freeze+bitcast, because he is concerned that some C++ stuff needs to be lowered to such a load. This load then becomes tricky to move around (e.g., cannot be sank to inside loops), but there are options to attenuate that pro...

...hat are the deficiencies of value-wise poison. Is there any major issue? I'm asking because value-wise poison seems to be a much simpler concept, so if it works ok it seems to be preferable. >> >> During the meeting last week, Richard Smith proposed that instead we add a "load not_poison %ptr" (like load atomic) instruction that would be equivalent to load+freeze+bitcast, because he is concerned that some C++ stuff needs to be lowered to such a load. This load then becomes tricky to move around (e.g., cannot be sank to inside loops), but there are options to attenuate that pro...

Hi Nuno, Chandler, Nuno Lopes via llvm-dev wrote: > This program stores 8 bits, and leaves the remaining 24 bits > uninitialized. It then loads 16 bits, half initialized to %v, half > uninitialized. SROA transforms the above function to: > > define i16 @g(i8 %in) { > %v = add nsw i8 127, %in > %1 = zext i8 %v to i16 > %2 = shl i16 %1, 8 > %3 = and

Hi Johannes, >> Not sure the semantics of "used" you propose is sufficient. AFAIU the >> proposal, "used" could only be used in cases where the function will >> always trigger UB if poison is passed as argument. The semantics of >> attributes is usually the other way around, since function calls need >> to have UB as strong as the worst

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 deviate from other