[llvm-dev] RFC: Killing undef and spreading poison

[Alexandre Isoard via llvm-dev]

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>