search for: poisonable

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

Hi, Let me try to give a bit more context on why select is so tricky. First thing to consider is which transformations we would like to support: 1) Control-flow -> select (SimplifyCFG) if (c) a = x else a = y => %a = select %c, %x, %y 2) select -> control-flow; reverse of 1) Not sure if this is done at IR level, or only later at SDAG. 3) select ->

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 >

Hi, Over the past few years we've been trying to kill poison somehow. There have been a few proposals, but they've all failed to pass the bar and/or to gather significant support (my own proposals included). We (David, Gil, John, Juneyoung, Sanjoy, Youngju, Yoonseung, and myself) have a new proposal to kill undef instead and replace it with poison + a new 'freeze' instruction. We

We have these transforms from funnel shift to a simpler shift op: // fshl(X, 0, C) -> shl X, C // fshl(X, undef, C) -> shl X, 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.

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

Don't we need to distinguish funnel shift from the more specific rotate? I'm not seeing how rotate (a single input op shifted by some amount) gets into trouble like funnel shift (two variables concatenated and shifted by some amount). Eg, if in pseudo IR we have: %funnel_shift = fshl %x, %y, %sh ; this is problematic because either x or y can be poison, but we may not touch the poison when

Hi, Thanks everybody that showed up in our talk at the LLVM dev meeting and to those that provided feedback so far. The slides are already online: http://llvm.org/devmtg/2016-11/Slides/Lopes-LongLivePoison.pdf The main question that some people raised was whether we could have bitwise poison instead of value-wise poison, since that semantics seems to be more natural as values continue to be just

> > // 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 &

There's a question about the behavior of funnel shift [1] + select and poison here that reminds me of previous discussions about select and poison [2]: https://github.com/AliveToolkit/alive2/pull/32#discussion_r257528880 Example: define i8 @fshl_zero_shift_guard(i8 %x, i8 %y, i8 %sh) { %c = icmp eq i8 %sh, 0 %f = fshl i8 %x, i8 %y, i8 %sh %s = select i1 %c, i8 %x, i8 %f ; shift amount is 0

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

If I got poison propagation right, it's probably only by luck! Hopefully, the funnel shift bug is fixed here: https://reviews.llvm.org/rL354905 Nuno, IIUC this means that you do *not* need to change the funnel shift semantics in Alive. So I think that means we're still on track to go with John's suggestion that only select and phi can block poison? (I don't know of any

You are right: select in SDAG has to be poison-blocking as well, otherwise the current lowering from IR's select to SDAG's select would be wrong. Which makes the select->or transformation incorrect at SDAG level as well. I guess until recently people believed that poison in SDAG wasn't much of a problem (myself included). I was convinced otherwise with the test cases that

> 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) {