Sanjoy Das via llvm-dev
2016-Oct-18 20:12 UTC
[llvm-dev] RFC: Killing undef and spreading poison
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 %x, %x that is no longer allowed (%y _has_ to be 0) -- all uses of %x will see some garbage, but fixed bit pattern. -- Sanjoy Krzysztof Parzyszek via llvm-dev wrote:> On 10/18/2016 2:25 PM, Nuno Lopes via llvm-dev wrote: >> Right, a load touching a single uninitialized bit results in poison. >> The trick is that on the first bitfield write, all the remaining >> untouched fields become initialized (with an arbitrary value, though). >> Essentially we are making the adjacent bitfields undef. > > So "undef" still exists, except now it's obtainable via "freeze(poison)"? > > -Krzysztof >
Krzysztof Parzyszek via llvm-dev
2016-Oct-18 20:22 UTC
[llvm-dev] 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 be simplified to "%x = poison", i.e. can we rauw(%x, poison)? Or %x = load %uninitialized_var %y = load %uninitialized_var // are %x and %y equal (i.e. is "cmp eq %x, %y" == true)? // is freeze(%x) equal to freeze(%y)? I'm wary about such rules. I have a feeling that this is going to create its own set of problems. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Krzysztof Parzyszek via llvm-dev
2016-Oct-18 21:09 UTC
[llvm-dev] RFC: Killing undef and spreading poison
I guess, it may help if we don't have a literal for poison (as we do for undef). Then freeze(%x) would always be equal to freeze(%x) and there would be no question about freeze(poison). -Krzysztof On 10/18/2016 3:22 PM, Krzysztof Parzyszek via llvm-dev wrote:> 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 be simplified to "%x = poison", i.e. can we rauw(%x, poison)? > > Or > %x = load %uninitialized_var > %y = load %uninitialized_var > // are %x and %y equal (i.e. is "cmp eq %x, %y" == true)? > // is freeze(%x) equal to freeze(%y)? > > I'm wary about such rules. I have a feeling that this is going to create > its own set of problems. > > -Krzysztof > >-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Nuno Lopes via llvm-dev
2016-Oct-18 21:29 UTC
[llvm-dev] 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 be simplified to "%x = poison", i.e. can we rauw(%x, poison)?Yes, that's ok.> %x = load %uninitialized_var > %y = load %uninitialized_var > // are %x and %y equal (i.e. is "cmp eq %x, %y" == true)? > // is freeze(%x) equal to freeze(%y)?"icmp %x, %y" would be poison (so you can chose true or false if you wish). There's no change here with respect to current poison semantics. freeze(%x) is not necessarily the same as freeze(%y). Even %a and %b might not be the same in "%a = freeze(%x), %b = freeze(%x)" (each freeze returns an arbitrary, but fixed, value). Nuno
Alexandre Isoard via llvm-dev
2016-Oct-19 14:06 UTC
[llvm-dev] RFC: Killing undef and spreading poison
On Tue, Oct 18, 2016 at 9:12 PM, Sanjoy Das via llvm-dev < 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 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. >We can also fold it to %y = 0 if we want, isn't it?> > 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 is the real motivation behind introducing a new kind of undef? I remember having read that undef does not obey all the rules of SSA. That is, a variable %x set to undef is in fact not initialized at it's definition but at each of it's use instead. Which is an argument I never quite understood, because the nature of undef is that we can safely restrict ourself to a classic aproach where %x has the same value at each use (as the compiler is free to assign any value to any undef it encounter). This does not exploit all of the freedom offered by undef, but is always valid, isn't it?> > -- Sanjoy > > > Krzysztof Parzyszek via llvm-dev wrote: > >> On 10/18/2016 2:25 PM, Nuno Lopes via llvm-dev wrote: >> >>> Right, a load touching a single uninitialized bit results in poison. >>> The trick is that on the first bitfield write, all the remaining >>> untouched fields become initialized (with an arbitrary value, though). >>> Essentially we are making the adjacent bitfields undef. >>> >> >> So "undef" still exists, except now it's obtainable via "freeze(poison)"? >> >> -Krzysztof >> >> _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- *Alexandre Isoard* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161019/0f7dc61a/attachment.html>
Mehdi Amini via llvm-dev
2016-Oct-19 16:01 UTC
[llvm-dev] RFC: Killing undef and spreading poison
> 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 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. > We can also fold it to %y = 0 if we want, isn't it? > > 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 is the real motivation behind introducing a new kind of undef? > > I remember having read that undef does not obey all the rules of SSA. That is, a variable %x set to undef is in fact not initialized at it's definition but at each of it's use instead. Which is an argument I never quite understood, because the nature of undef is that we can safely restrict ourself to a classic aproach where %x has the same value at each use (as the compiler is free to assign any value to any undef it encounter). This does not exploit all of the freedom offered by undef, but is always valid, isn't it?Even if you wanted to do this (use the same “undef” for every use of %x), how can you do since undef is a constant? For example: %y = xor %x, %x and: %y = xor %x, %z If %x and %z are undef you can’t differentiate these anymore: %y = xor undef, undef — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161019/81b90053/attachment-0001.html>
MARCELLO MAGGIONI via llvm-dev
2016-Oct-24 23:31 UTC
[llvm-dev] RFC: Killing undef and spreading poison
> On Oct 18, 2016, at 1:12 PM, Sanjoy Das via llvm-dev <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 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 %x, %xWhat is %x = freeze(poison) %y = freeze(poison) %z = xor %x, %y going to result into? Marcello> > that is no longer allowed (%y _has_ to be 0) -- all uses of %x will see some garbage, but fixed bit pattern. > > -- Sanjoy > > > Krzysztof Parzyszek via llvm-dev wrote: >> On 10/18/2016 2:25 PM, Nuno Lopes via llvm-dev wrote: >>> Right, a load touching a single uninitialized bit results in poison. >>> The trick is that on the first bitfield write, all the remaining >>> untouched fields become initialized (with an arbitrary value, though). >>> Essentially we are making the adjacent bitfields undef. >> >> So "undef" still exists, except now it's obtainable via "freeze(poison)"? >> >> -Krzysztof >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Nuno Lopes via llvm-dev
2016-Oct-25 17:10 UTC
[llvm-dev] RFC: Killing undef and spreading poison
>> On Oct 18, 2016, at 1:12 PM, Sanjoy Das via llvm-dev <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 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 %x, %x > > > What is > > %x = freeze(poison) > %y = freeze(poison) > %z = xor %x, %y > > going to result into?%x and %y will be arbitrary, and possibly distinct values. Therefore you can replace %z with a new "freeze poison" instruction (assuming %x and %y have no other uses). If %x and %y have other uses, no similar rewrite can be done without taking all other uses into account. Nuno