[llvm-dev] RFC: Killing undef and spreading poison
MARCELLO MAGGIONI via llvm-dev
llvm-dev at lists.llvm.org
Mon Oct 24 16:31:02 PDT 2016
> 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?
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
More information about the llvm-dev
mailing list