similar to: What is the status of the "Killing Undef and Spreading Poison" RFC?

Hi, Let me give you my view of the status: The proposal you mentioned was, I believe, well understood and accepted. 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

> On 20 March 2018 at 09:39, Nuno Lopes via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi, >> >> Let me give you my view of the status: >> The proposal you mentioned was, I believe, well understood and accepted. >> Except for one bit, which was that it requires correct typing of load/store >> operations. That is, if you load an i32, it means

On 20 March 2018 at 09:39, Nuno Lopes via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > > Let me give you my view of the status: > The proposal you mentioned was, I believe, well understood and accepted. > 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 >

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

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

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

> 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

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

1. ————— Dan, The reasoning given below for how GVN operates seems odd to me, Poison is an attribute of a value, just like nsw is an attribute of an operation, So when GVN sees a pair of equal values, one of which has an extra attribute, The proper choice for representative value is the one without the attribute, Just like when GVN sees a pair of add operations, one of which has an

> 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

> 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 Krzysztof, Krzysztof Parzyszek wrote: > On 10/18/2016 4:29 PM, Nuno Lopes wrote: >> Even %a and %b might not be the same in "%a = freeze(%x), %b = >> freeze(%x)" (each freeze returns an arbitrary, but fixed, value). > > Assume that %x is known to be a poison value and have: > %a = freeze(%x) > %b = freeze(%x) > > Is %a == %a true? Yes, %a is always

Hi Alexandre, On Wed, Oct 19, 2016 at 11:19 AM, Alexandre Isoard <alexandre.isoard at gmail.com> wrote: > I am probably missing something important, but what I mean is that you can > always convert: > > %y = xor %x, %x > to > %y = 0 > > Regardless of if %x is/might be an undef. That is, consider that reading %x > any number of times always give the value of its

Hi Mehdi, On Wed, Oct 19, 2016 at 8:29 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> sext(x): >> t = zext x >> result = 0 >> for i = 0 to bitwidth: >> result |= t << i; >> return result > > I don’t understand this definition of sext? > Are you trying to express that we will copy the sign one bit at a time, and so every `new`

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’

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

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