[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