search for: poisonous

Hello, What follows is my attempt to describe how poison works. Let me know what you think. -- David # LLVM Poison Semantics Poison is an LLVM concept which exists solely to enable further optimization of LLVM IR. The exact behavior of poison has been, to say the least, confusing for users, researchers and engineers working with LLVM. This document hopes to clear up some of the confusion

...htly painful but it is the only way forward. John On 5/22/17 2:32 PM, Sanjay Patel wrote: > Some InstCombine transforms for select-of-select were added here: > <https://reviews.llvm.org/rL228409> https://reviews.llvm.org/rL228409 > > But Alive says this is more poisonous: > > Name: selsel > %s1 = select i1 %cond1, i8 C1, i8 C2 > %s2 = select i1 %cond2, i8 %s1, i8 C2 > => > %andcond = and i1 %cond1, %cond2 > %s2 = select i1 %andcond, i8 C1, i8 C2 > > <http://rise4fun.com/Alive/JT6> http://rise4fun.com/Alive/JT6 >...

On 01/28/2015 07:02 AM, Sean Silva wrote: > Could you maybe provide an example where replacing `%always_poison` > with `undef` will change the meaning? At least for me, the thing that > I'm most unclear about is how poison differs from undef. I will second this request for much the same reason. > > -- Sean Silva > > On Wed, Jan 28, 2015 at 2:50 AM, David Majnemer >

...se and %b is poison This disallows 3) and some transformations of 1). Since 3) is only performed in CodeGenPrepare, we can safely ignore it (no aggressive optimizations are run afterwards). For 1), we will have to restrict InstCombine patterns for the cases when we are sure a given variable is non-poisonous (which is only when it came from a 'freeze' instruction or it's the result of a non-poison-producing instruction). This semantics also allows arithmetic -> select, but not select -> arithmetic (without use of freeze). Acknowledgements ================ I would personally like to...

...C // fshl(0, X, C) -> lshr X, (BW-C) // fshl(undef, X, C) -> lshr X, (BW-C) These were part of: https://reviews.llvm.org/D54778 In all cases, one operand must be 0 or undef and the shift amount is a constant, so I think these are safe. If X is poison, we'll transform from a poisonous funnel shift to a poisonous shift (no need to introduce any special poison blocking behavior). On Mon, Feb 25, 2019 at 4:01 PM Nuno Lopes <nunoplopes at sapo.pt> wrote: > You are very right! Transformation to rotate is correct. > > So I guess the remaining case is if you want to be...

It is UB when a poison is passed to certain operations that raise UB on poison, such as division by poison/dereferencing poison pointer/branching on poison condition/etc. Otherwise, poison is simply propagated, but it does not raise UB Copying poison bytes is okay: // Members are initialized to poison at object creation. p = alloca {i8, i32} // p[0], p[4~7] are poison q = alloca {i8, i32} // we

...= select i1 %c, i8 %x, i8 %f ; shift amount is 0 returns x (same as > fshl) > ret i8 %s > } > => > define i8 @fshl_zero_shift_guard(i8 %x, i8 %y, i8 %sh) { > %f = fshl i8 %x, i8 %y, i8 %sh > ret i8 %f > } > Transformation doesn't verify! > ERROR: Target is more poisonous than source > > > ---------------------------------------------------------------------------- > > The problem is that if %y is poison and we assume that funnel shift uses > all > of its operands unconditionally, the reduced code sees poison while the > original code is prot...

...se and %b is poison This disallows 3) and some transformations of 1). Since 3) is only performed in CodeGenPrepare, we can safely ignore it (no aggressive optimizations are run afterwards). For 1), we will have to restrict InstCombine patterns for the cases when we are sure a given variable is non-poisonous (which is only when it came from a 'freeze' instruction or it's the result of a non-poison-producing instruction). This semantics also allows arithmetic -> select, but not select -> arithmetic (without use of freeze). Acknowledgements ================ I would personally like to...

> > // Members are initialized to poison at object creation. >> p = alloca {i8, i32} // p[0], p[4~7] are poison >> p[0] is an i8, so it shouldn't be poison? > > My interpretation of standard is that reading uninitialized char can also yield trap representation. If uninitialized, char variable has indeterminate value, and C/C++ does not seem to forbid reading trap

On Tue, Feb 3, 2015 at 3:15 AM, Nuno Lopes <nuno.lopes at ist.utl.pt> wrote: > Hi, > > > > Thanks David for putting up this proposal together! > > I like the idea of having poison values behave more like undef (i.e., per > bit, with run-time behavior). > > One of the problems this proposal solves is speculation of 'a && b' into > 'a &

...cmp eq i8 %sh, 0 %f = fshl i8 %x, i8 %y, i8 %sh %s = select i1 %c, i8 %x, i8 %f ; shift amount is 0 returns x (same as fshl) ret i8 %s } => define i8 @fshl_zero_shift_guard(i8 %x, i8 %y, i8 %sh) { %f = fshl i8 %x, i8 %y, i8 %sh ret i8 %f } Transformation doesn't verify! ERROR: Target is more poisonous than source ---------------------------------------------------------------------------- The problem is that if %y is poison and we assume that funnel shift uses all of its operands unconditionally, the reduced code sees poison while the original code is protected by the "conditional poison&...

On Thu, Jan 29, 2015 at 10:01 PM, Matthias Braun <matze at braunis.de> wrote: > But > (Poison > INT_MAX) <=> poison > contradicts > (X > INT_MAX) <=> false > > and I don't think you want to abandon the second rule just because x might be poison. Maybe we could define poison in such a way that it is safe to pretend it "is" false, as per our

Here's an idea for a slightly unusual framework for poison semantics: we do it in two steps -- 1. for every bit in the program, we define a second "shadow bit", is-poison. We define the semantics of LLVM IR using this is-poison relation. So, for instance, we could say if there is a bit 'b'in address 'a' such that if is-poison['b'], then "store X to

...hl(undef, X, C) -> lshr X, (BW-C) > > > > These were part of: https://reviews.llvm.org/D54778 > > > > In all cases, one operand must be 0 or undef and the shift amount is a > > constant, so I think these are safe. If X is poison, we'll transform > > from a poisonous funnel shift to a poisonous shift (no need to introduce > > any special poison blocking behavior). > > > > On Mon, Feb 25, 2019 at 4:01 PM Nuno Lopes <nunoplopes at sapo.pt > > <mailto:nunoplopes at sapo.pt>> wrote: > > > > You are very right! Tra...

...'t object to deferring the optimization, but let me check my poison > understanding... > select i1 %cond, i1 true, i1 %x --> or i1 %cond, %x > > 1. 'select' is a poison-blocking operation, but 'or' is > non-poison-blocking, so we are propagating a potentially poisonous %x with > this transform. > 2. We will fix the problem in IR by removing this transform in IR > 3. The backend (SDAG) has that same transform. > 4. SDAG has poison because we propagate the wrapping/exact flags to DAG > nodes. > 5. Are we just sweeping the bug under the rug? Nobody...

> It is important to note that this applies to trap representations and not to unspecified values. A structure or union never has a trap representation. Yes, nondeterministic bits would work for padding of struct/union, as described in (3) The third case is the value of struct/union padding. For the members of struct/union, it is allowed to have trap representation, so poison can be used.

On Tue, Jan 27, 2015 at 7:23 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi David, > > I spent some time thinking about poison semantics this way, but here > is where I always get stuck: > > Consider the IR fragment > > %x = zext i32 %maybe_poison to i64 > %y = lshr i64 %x 32 > %ptr = gep %global, %y > store 42 to %ptr > > If

> > Okay, it's just not immediately undefined behaviour. The C model has more > issues because of the problem with how "trap representation" is defined > (which precludes trap representations for unsigned char, two's complement > signed char, etc.). This interpretation is further stressed because C only explicitly ascribes > undefined behaviour to trap

One way around this is to say that there are some special instructions, icmp, sext and zext which produce a value solely composed of poison bits if any of their input bits is poison. So `<poison> icmp X` is poison for any value of X, including INT_MAX. This is one way poison could be fundamentally different from undef. -- Sanjoy On Thu, Jan 29, 2015 at 8:05 PM, Matthias Braun <matze at

> On 11/8/2016 3:32 PM, Sanjoy Das wrote: >> 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) {