search for: poisoned

Displaying 20 results from an estimated 856 matches for "poisoned".

2015 Jan 28
15
[LLVMdev] RFC: Proposal for Poison Semantics
...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...
2017 May 23
4
[poison] is select-of-select to logic+select allowed?
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 ->
2015 Jan 29
5
[LLVMdev] RFC: Proposal for Poison Semantics
...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...
2016 Oct 18
8
RFC: Killing undef and spreading poison
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
2019 Feb 25
3
funnel shift, select, and poison
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.
2020 Oct 09
2
Undef and Poison round table follow-up & a plan
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
2019 Feb 25
2
funnel shift, select, and poison
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
2016 Dec 06
2
RFC: Killing undef and spreading poison
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
2020 Oct 09
2
Undef and Poison round table follow-up & a plan
> > // 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
2015 Feb 03
6
[LLVMdev] Proposal for Poison Semantics
...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...
2019 Feb 25
4
funnel shift, select, and poison
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
2015 Jan 30
2
[LLVMdev] RFC: Proposal for Poison Semantics
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
2015 Jan 30
0
[LLVMdev] RFC: Proposal for Poison Semantics
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
2019 Feb 26
2
funnel shift, select, and poison
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
2019 Feb 27
3
funnel shift, select, and poison
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
2020 Oct 08
2
Undef and Poison round table follow-up & a plan
> 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.
2015 Jan 28
2
[LLVMdev] RFC: Proposal for Poison Semantics
...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...
2020 Oct 10
2
Undef and Poison round table follow-up & a plan
> > 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
2015 Jan 30
3
[LLVMdev] RFC: Proposal for Poison Semantics
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
2016 Nov 09
4
RFC: Killing undef and spreading poison
> 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) {