similar to: killing undef and spreading poison

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’

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

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

> So just to be clear (mainly so i can go back to letting y'all hash this out), in value numbering: > 1. I can value number all freeze operations on the same operand to the same value > *as long as* > 2. I replace all freeze values of the same operand with a single one. > > Or am i misunderstanding? > If i've got it right, the issue i see with #2 is whether i can

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

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

On Mon, Oct 24, 2016 at 1:26 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Sun, Oct 23, 2016 at 9:30 AM, Nuno Lopes <nuno.lopes at ist.utl.pt> wrote: > >> > So just to be clear (mainly so i can go back to letting y'all hash this >> out), in value numbering: >> > 1. I can value number all freeze operations on the same operand to 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; > >>

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

> 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

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 Tue, Oct 25, 2016 at 10:19 AM, Nuno Lopes <nuno.lopes at ist.utl.pt> wrote: > >>>> So just to be clear (mainly so i can go back to letting y'all hash > this out), in value numbering: > >>>> 1. I can value number all freeze operations on the same operand to > the same value > >>>> *as long as* > >>>> 2. I replace all

Sanjoy, My answer is that step 3, commuting the multiply with the sign-extends, is invalid, As this is what causes the `udiv` to fault. I think it is invalid with or without the “freeze”, why do you think step 3, the commute, without the “freeze" is valid ? Also, do you think you can come up with an example that does not depend on signed overflow being “undefined” ? Peter

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

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

> Except for one bit, which was that it requires correct typing of load/store >> operations. That is, if you load an i32, it means you are loading a single >> 32-bit integer, not two 16-bit integers or something else. >> > > This is a valid concern because currently nor LLVM nor clang respect this >> property. Clang may pass several parameters as a single

> On 10/18/2016 3:12 PM, Sanjoy Das wrote: >> But in the new proposal, in: >> >> %x = freeze(poison) >> %y = xor %x, %x >> >> that is no longer allowed (%y _has_ to be 0) -- all uses of %x will see >> some garbage, but fixed bit pattern. > > What about this: > %x = phi poison, poison (I'm simplifying the syntax here) > Can this

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

Hi Nuno, Except for one bit, which was that it requires correct typing of load/store > operations. That is, if you load an i32, it means you are loading a single > 32-bit integer, not two 16-bit integers or something else. > This is a valid concern because currently nor LLVM nor clang respect this > property. Clang may pass several parameters as a single variable, LLVM has >