similar to: killing undef and spreading poison

Displaying 20 results from an estimated 10000 matches similar to: "killing undef and spreading poison"

2017 Jun 19
3
killing undef and spreading poison
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
2017 Jun 08
2
RFC: Killing undef and spreading poison
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
2017 Jun 08
7
RFC: Killing undef and spreading poison
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
2018 Mar 19
2
What is the status of the "Killing Undef and Spreading Poison" RFC?
Hi, Back in 2016 an RFC titled "Killing Undef and Spreading Poison" [1] was posted on this mailing list, which generated a lot of discussion between different people. Later in 2017, a paper titled "Taming Undefined Behavior in LLVM" [2] was published, detailing the various concerns introduced in the RFC. There is also a patch proposal with an initial implementation
2017 Jun 14
2
killing undef and spreading poison
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
2016 Oct 18
2
RFC: Killing undef and spreading poison
>> 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 >> } >>
2016 Oct 18
2
Killing undef and spreading poison
>> >> 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
2017 Jun 15
3
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’
2017 Jun 07
2
RFC: Killing undef and spreading poison
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
2016 Oct 18
2
Killing undef and spreading poison
> 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
2016 Oct 25
3
RFC: Killing undef and spreading poison
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
2018 Mar 20
0
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
2018 Mar 21
0
What is the status of the "Killing Undef and Spreading Poison" RFC?
> 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
2016 Oct 23
2
RFC: Killing undef and spreading poison
> 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
2016 Nov 04
3
RFC: Killing undef and spreading poison
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; > >>
2016 Oct 24
2
RFC: Killing undef and spreading poison
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
2018 Mar 20
3
What is the status of the "Killing Undef and Spreading Poison" RFC?
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 >
2017 Jun 02
5
RFC: Killing undef and spreading poison
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
2016 Oct 18
2
RFC: Killing undef and spreading poison
> 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
2016 Oct 19
3
RFC: Killing undef and spreading poison
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