llvm dev - Oct 2016 - 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>

On Wed, Oct 19, 2016 at 5:01 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
> 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> 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
>
I am probably missing something important, but what I mean is that you can
always convert:

%y = xor %x, %x
to
%y = 0

Regardless of if %x is/might be an undef. That is, consider that reading %x
any number of times always give the value of its definition (as SSA
suggest). Therefore, disregarding the special semantic of undef (which is
always safe in this direction).

Is there an example of transformation which is forbidden by the fact that a
variable might be undef?
>
> —
> Mehdi
>
>
In other words, can I do transformations in llvm assuming undef follow the
expected SSA semantic? That is, if I do a transformation that is valid for
any value of %x, will it be valid for when %x is undef?

-- 
*Alexandre Isoard*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161019/d996aff1/attachment.html>

Hi Alexandre,

On Wed, Oct 19, 2016 at 11:19 AM, Alexandre Isoard
<alexandre.isoard at gmail.com> wrote:
> I am probably missing something important, but what I mean is that you can
> always convert:
>
> %y = xor %x, %x
> to
> %y = 0
>
> Regardless of if %x is/might be an undef. That is, consider that reading %x
> any number of times always give the value of its definition (as SSA
> suggest). Therefore, disregarding the special semantic of undef (which is
> always safe in this direction).
>
> Is there an example of transformation which is forbidden by the fact that a
> variable might be undef?
There are some examples earlier in this thread, but this is one:
http://www.playingwithpointers.com/problem-with-undef.html

(Writing the blog post is already paying off :) )

-- Sanjoy