similar to: Change undef to poison in a few operations

Hi, This is a follow up on a discussion around shufflevector with undef mask in https://reviews.llvm.org/D70641 and https://bugs.llvm.org/show_bug.cgi?id=43958. The current semantics of shufflevector in http://llvm.org/docs/LangRef.html#shufflevector-instruction states: "If the shuffle mask is undef, the result vector is undef. If any element of the mask operand is undef, that element

Ok, makes sense. My suggestion is that we patch the IR Verifier to ensure that the mask is indeed a vector of constants and/or undefs. Right now it only runs the standard checks for instructions. We will also run Alive2 on the test suite to make sure undef is never replaced in practice. Thanks, Nuno -----Original Message----- From: Eli Friedman <efriedma at quicinc.com> Sent: 27 de

On 11/27/19 2:10 AM, Eli Friedman via llvm-dev wrote: The shuffle mask of a shufflevector is special: it's required to be a constant in a specific form. From LangRef: "The shuffle mask operand is required to be a constant vector with either constant integer or undef values." So really, we can resolve this any way we want; "undef" in this context doesn't have to mean

Oh, no. I should have been more clear. The patch was not rejected, just lost in the daily shuffle. I already have my employer's approval to send this upstream, so I will prepare a patch against trunk this morning. > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > > Parts of my patch did make it into trunk about a year after, but others > > did not.

Sanjay, I'm looking at some missed optimizations caused by D70246. Here's a test case: define <4 x float> @f(i32 %t32, <4 x float>* %t24) { .entry: %t43 = insertelement <3 x i32> undef, i32 %t32, i32 2 %t44 = bitcast <3 x i32> %t43 to <3 x float> %t45 = shufflevector <3 x float> %t44, <3 x float> undef, <4 x i32> <i32 0, i32 undef,

On Monday, July 30, 2012 12:16 AM, Cameron McInally wrote: > Hey Andy, > > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > Parts of my patch did make it into trunk about a year after, but others > did not. > > At that time, my solution was to add a binary operator to the IRBuilder, > since LCS fits in nicely with the other shift operators. But,

On 05/26/2017 03:02 PM, Matthias Braun wrote: > >> Regarding SDAG, and given that poison is already there, we would need >> to adopt a similar solution to the IR. Maybe right now we can get >> away with it because nsw is not exploited significantly (as you say). >> Just because there’s no explicit poison in SDAG, just having nsw is >> sufficient to cause

Sanjoy, My belief is that this is a register allocation problem that should not be addressed in the IR. However you have changed the subject, and we still need an example showing why the proposed definition for branch is the right one. Peter Lawrence. > On Jun 16, 2017, at 7:39 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Peter, > > On

Hi everyone! The fptoui/fptosi instructions are currently specified to return a poison value if the rounded-towards-zero floating point number cannot be represented by the target integer type. The motivation for this behavior is that overflowing float to int casts in C are undefined behavior. However, many newer languages prefer to have a float to integer cast that is well-defined for all input

I would be interested in learning what the set of used semantics for float-to-int conversion is. If the only two used are 1) undefined behavior if unrepresentable and 2) saturate to int_{min,max} with NaN going to zero, then I think it makes sense to expose both of those natively in the IR. If the set is much larger, I think separate intrinsics for each behavior would make sense. It would be nice

John, Here’s what I’m getting at “Poison” is an attribute of a “value”, not a “value” itself. “Poison” is an analysis result, and we should think about implementing it as such, just like we do constant and range analysis. Turning “poison” into a “value” means all “values” now have in addition to a bit pattern an extra attribute (IE a tag). Peter Lawrence.

> Only freezing it will > replace it with something concrete such that if x is poison then > freeze(x) == freeze(x), etc. Nit: it's not true that freeze(x) == freeze(x) in the current proposal. Each freeze can choose its own value. John

Having though about this some more I think optimizing (x+1 > x) <=> true and at the same time modeling undefined behavior as a posion value is impossible. This is because we also want the following rule: (x > INT_MAX) <=> false Now if poison is a value, then the second replacement tells us (poison > INT_MAX) == false which contradicts the first rule. The only way out of

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

> I've been discussing a model with David that might steer poison back towards > something that simply supports algebraic simplification. If we have a math > operation that cannot wrap, then it notionally produces as many bits of > undef as the operation could possibly produce. For example, "add nsw i8" can > produce an i9 undef, and "mul nsw i8" can produce

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. - Matthias > On Jan 29, 2015, at 9:43 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > One way around this is to say that there are some special > instructions, icmp, sext and zext which

Nuno, we still need some examples showing that the definition “Branching on poison is immediate-UB” is the best choice, so far we only have arguments against it (the one for loop-switching). Excerpts from the Paper [1] Here’s the example you give for GVN t = x + 1; if (t == y) { w = x + 1; foo(w); } Therefore, GVN can pick y as the

I'm still digesting the proposal in its entirety, but one point I want to call out here: On Tue, Oct 18, 2016 at 1:39 PM Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Instcombine currently transforms "memcpy(dst, src, 4)" to "load i32 src; > store i32 dst". I guess that's illegal under this model? How about the > related transform

On Wed, Oct 19, 2016 at 2:52 PM, Nuno Lopes via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Memcpy does a byte-by-byte copy. So if one of the bits is poison then only > the byte containing that bit becomes poison. > Therefore, memcpy(x, y, 1) is equivalent to load i8. But memcpy(x,y,4) is > not equivalent to "load i32" since load makes the whole value poison if

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