similar to: Function Inlining and undef / poison question

On 15 June 2017 at 23:12, John Regehr via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Peter, I don't see what you're driving at here. You can perhaps move > the discussion forward with a complete, compilable example. > > John I don't KNOW for sure, but I think I understand, see below: > > > > On 6/15/17 11:27 AM, Peter Lawrence via llvm-dev

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

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

Hi, Lately we have come to realize how undef makes our life complicated.. Therefore in this email we propose to change the behavior of a few instruction to yield poison instead of undef in error cases. This follows the suggestion of Eli in https://reviews.llvm.org/D33654. Why is undef so bad? - I believe it's not possible to make newgvn correct with undef. See for example the discussion

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

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

> On Oct 18, 2016, at 12:44 PM, Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > Nuno Lopes wrote: > >>> Okay; so the problem is that an instruction that is value-equivalent >>> to a poison value is not itself necessarily poison? >> >> Right. >> I think there were other examples, but I don't have them here

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

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

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

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

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

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

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

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

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

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

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

Daniel, Thanks for taking the time to respond. Regarding GVN and newGVN, I recently finished a search through the llvm-dev archives for “nsw” in the subject line, and GVN was discussed in some of those threads [1]. In particular it was claimed that there was a right choice for GVN to make given two ADD instructions, one with the “nsw” attribute and one without, the one without ‘nsw’

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