similar to: 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

>> A use of freeze is to enable speculative execution. For example, loop >> switching does the following transformation: >> while (C) { >> if (C2) { >> A >> } else { >> B >> } >> } >> => >> if (C2) { >> while (C) >> A >> } else { >> while (C) >> B >> } >>

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

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

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

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

>> 1) a bit in the output is poison if flipping any set of poison bits >> in the >> input may yield different values for the output bit. > > This is the definition I'd expect. > >> For example (bitwise notation): >> ppp * 000 == 000 (since flipping any of the poison bits cannot yield >> a >> result other than zero) >> 00p + 00p == 0pp

Regarding the patches, there are two concerns AFAICT: 1. It’s a new instruction and as usual when introducing a new instruction it will require work for some time until most optimizations know about it, and to get rid of any potential perf regression. No big deal; we just need to do the work (and we have already done some of it). 2. The patch was written by a student, which may not have time to

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

Hello all, Thank everyone who participated in the (impromptu) round table discussion on Tuesday. For those who are interested, I share the summary of the discussion. Also, I share a short-term plan regarding this issue and relevant patches. *Fixing Miscompilations using Freeze* ----------------------------------- To reduce the cost of fixing miscompilations using freeze instruction, we need to

Thank you for the infos; it seems making it raise UB is problematic. Would clarifying it in LangRef be good? I can update the patch to contain the information instead. Another concern is then, how can we efficiently encode an assumption that a pointer variable in IR does not have undef bits? Certainly, in the front-end language, (most of) pointers won't have undef bits, and it would be great

Hi John, John McCall wrote: >>> Well, we could say non-nsw add and mul are actually "bitwise" operations, so "mul i32 poison, 2" is guaranteed to have its bottom bit zero (but "mul nsw i32 poison, 2" is poison). Of course, there's a limit to how far we can go in that direction, or we just end up with the old notion of undef. Off the top of my head,

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

I think calling the attribute "used" is confusing. I'd suggest the following: "not_poison": If an argument is marked not_poison, and the argument is poison at runtime, the call is instant UB. Whether an argument is poison is checked after the rules for other attributes like "nonnull" and "align" are applied. This makes it clear that the IR semantics

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

Hello all, LangRef says it is undefined behavior to pass null to a nonnull argument (`call f(nonnull null);`), but the semantics is too strong for a few existing optimizations. To support these, we can relax the semantics so `f(nonnull null)` is equivalent to `f(poison)`, but (A) it again blocks another set of optimizations, and (B) this makes the semantics of nonnull deviate from other

Hi Johannes, >> Not sure the semantics of "used" you propose is sufficient. AFAIU the >> proposal, "used" could only be used in cases where the function will >> always trigger UB if poison is passed as argument. The semantics of >> attributes is usually the other way around, since function calls need >> to have UB as strong as the worst

>> >> Here we are evaluating C2 before C. If the original loop never >> >> executed then we had never evaluated C2, while now we do. So we >> >> need >> >> to make sure there's no UB for branching on C2. Freeze ensures >> >> that >> >> so we would actually have 'if (freeze(C2))' instead. >> >> Note

Not sure the semantics of "used" you propose is sufficient. AFAIU the proposal, "used" could only be used in cases where the function will always trigger UB if poison is passed as argument. The semantics of attributes is usually the other way around, since function calls need to have UB as strong as the worst behavior of the function. If a function may for some reason trigger

Hi Dan, Thanks a lot for the feedback and apologies for the delay! >> br poison -> UB > What impact does this have on API contracts? Some library functions might currently tolerate being passed an uninitialized value (at the LLVM level; C's semantics are different). However, with the new poison, if the implementation of a function happens to do a branch on the input, the code has