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

[Michael Kuperstein via llvm-dev]

The fact two IR values are defined the same way doesn't necessarily imply
they are actually the same value.
e.g.

%a = load volatile i32, i32* %p
%b = load volatile i32, i32* %p

As Sanjoy said, though, it should always be legal to optimize all uses of
different "freeze(%x)" values to use the same def - this is equivalent to
choosing the same value for all freezes. It's just not necessary to do so.

On Thu, Oct 20, 2016 at 1:58 PM, Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> In both of these cases, the expression tree in the IR is going to look like
>   == (freeze(%x), freeze(%x))
>
> The %a and %b are just labels on values, which are defined in the exact
> same way. How do you differentiate these two?
>
> If %a = freeze(%x), is %a+1 == %a+1?
>
> -Krzysztof
>
>
>
> On 10/20/2016 3:36 PM, Sanjoy Das wrote:
>
>> Hi Krzysztof,
>>
>> Krzysztof Parzyszek wrote:
>>
>>> On 10/18/2016 4:29 PM, Nuno Lopes wrote:
>>>
>>>> Even %a and %b might not be the same in "%a = freeze(%x), %b =
>>>> freeze(%x)" (each freeze returns an arbitrary, but fixed, value).
>>>>
>>>
>>> Assume that %x is known to be a poison value and have:
>>> %a = freeze(%x)
>>> %b = freeze(%x)
>>>
>>> Is %a == %a true?
>>>
>>
>> Yes, %a is always == %a.  It is a normal SSA value with some unspecific
>> content.
>>
>> Is %a == %b true?
>>>
>>
>> Not necessarily; but the compiler can make it true by (consistently)
>> choosing equal values for %a and %b.
>>
>> By consistently I mean it can't fold one instance of %a == %b to true
>> and fold another instance of %a == %b to false.
>>
>> -- Sanjoy
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161020/0c2fb0bb/attachment.html>