similar to: A tagged architecture, the elephant in the undef / poison room

> On Jun 16, 2017, at 8:23 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Peter, > > On Tue, Jun 13, 2017 at 10:27 AM, Peter Lawrence via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Here’s what seems to really be going on >> >> “undef” === models an uninitialized register, but > > No, it specifically does

Sanjoy, The point is this, you have to take a stand one way or the other on the function-inlining issue: [1. this function *always* executes statement S, F(a) { If (a == a) S; } but in llvm if you inline it and “a” happens to be “undef” then nothing can be said about whether statement S is executed. This is indefensible.] My belief is this: that llvm exists for a

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

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 Krzysztof, freeze(poison) is different from undef today, in the sense that it is an instruction that produces some random, but fixed bit pattern. E.g. today in %x = undef %y = xor %x, %x we can fold %y to undef since each use of %x can independently see some arbitrary (up to the compiler / environment) bit pattern. But in the new proposal, in: %x = freeze(poison) %y = xor

Hi Peter, On Thu, Jun 8, 2017 at 9:41 AM, Peter Lawrence <peterl95124 at sbcglobal.net> wrote: > >> On Jun 7, 2017, at 2:23 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: >> >> Since most add/sub operations compiled from C have the nsw attribute, we cannot simply restrict movement of these instructions. > > Nuno, > I’m not saying the operations

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

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

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,

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

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

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

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

> On 10/18/2016 5:06 AM, Nuno Lopes via llvm-dev wrote: >> Another use is, for example, to implement bit-fields: >> a.x = 2 >> becomes: >> %v = load %a >> %v2 = freeze %v ; %v could be uninitialized data (poison) >> %v3 = ... bitmasking... >> store %a, %v3 > > It seems like you're saying that an integer load which touches any >

Sanjoy, in your blog post https://www.playingwithpointers.com/problem-with-undef.html <https://www.playingwithpointers.com/problem-with-undef.html> you describe a problem with LLVM “undef”, yet in your paper http://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf <http://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf> you do not suggest fixing this problem, even though in

On Wed, Oct 19, 2016 at 4:52 AM Nuno Lopes <nuno.lopes at ist.utl.pt> wrote: > > 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 wrote: > >> Instcombine currently transforms "memcpy(dst, src, 4)" to "load i32 src; > >>

> On Oct 19, 2016, at 7:06 AM, Alexandre Isoard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Tue, Oct 18, 2016 at 9:12 PM, Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi Krzysztof, > > freeze(poison) is different from undef today, in the sense that it is an instruction that produces

Since most add/sub operations compiled from C have the nsw attribute, we cannot simply restrict movement of these instructions. Sure, we could drop nsw when moving these instructions, but there are still many other problems left. Please read more about the topic here: https://blog.regehr.org/archives/1496 For example, doing loop unswitching, followed by inline (just to illustrate that the

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