search for: poisoned

...ermitted to overflow. Perhaps chief among them is that evaluating an expression in C++ or C which results performs an overflow is undefined behavior. In LLVM, executing an instruction which is marked `nsw` but which violates signed overflow results in poison. Values which have no relationship with poisoned values are not effected by them. Let us take the following C program into consideration: ``` int calculateImportantResult(int a, int b) { int result = 0; if (a) { result = a + b; } return result; } ``` A straightforward lowering to LLVM IR could be: ``` define i32 @calculateImportantR...

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

...among them is that evaluating an expression in C++ > or C which results performs an overflow is undefined behavior. In > LLVM, executing an instruction which is marked `nsw` but which > violates signed overflow results in poison. Values which have no > relationship with poisoned values are not effected by them. > > Let us take the following C program into consideration: > ``` > int calculateImportantResult(int a, int b) { > int result = 0; > if (a) { > result = a + b; > } > return result; > } &gt...

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

...t; > Perhaps chief among them is that evaluating an expression in C++ or C > which results performs an overflow is undefined behavior. In LLVM, > executing an instruction which is marked `nsw` but which violates signed > overflow results in poison. Values which have no relationship with poisoned > values are not effected by them. > > > > Let us take the following C program into consideration: > > ``` > > int calculateImportantResult(int a, int b) { > > int result = 0; > > if (a) { > > result = a + b; > > } > > return resu...

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.

...ng them is that evaluating an expression in C++ or C > which > > results performs an overflow is undefined behavior. In LLVM, executing an > > instruction which is marked `nsw` but which violates signed overflow > results > > in poison. Values which have no relationship with poisoned values are not > > effected by them. > > > > Let us take the following C program into consideration: > > ``` > > int calculateImportantResult(int a, int b) { > > int result = 0; > > if (a) { > > result = a + b; > > } > > return...

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