[llvm-dev] killing undef and spreading poison

[Peter Lawrence via llvm-dev]

1. ————— 
Dan,
       The reasoning given below for how GVN operates seems odd to me,

Poison is an attribute of a value,  just like nsw is an attribute of an operation,

So when GVN sees a pair of equal values, one of which has an extra attribute,
The proper choice for representative value is the one without the attribute,

Just like when GVN sees a pair of add operations, one of which has an extra attribute,
The proper choice for representative is the one without the attribute


2. —————
Nuno,
         If Dan agrees with the above then can we come up with a better example
for why branch-on-poison should be “undefined behavior”.



Thoughts ?
Comments ?
Questions ?

Peter Lawrence.

-------------------------------------------------------------------------------------------
>Nuno Lopes via llvm-dev at lists.llvm.org
>Tue Oct 18 08:10:41 PDT 2016
>
>>> Note that having branch on poison not trigger UB has its own problems.
>> Can you please elaborate on these problems?
>
>Sure! For example, the following transformation would be wrong if branch on poison was a non-deterministic branch instead of >UB:
>
>    %a = add i32 %x, 1
>    %c = icmp eq i32 %a, %p
>    br i1 %c, label %bb1, label %bb2
>bb1:
>    %b = add i32 %x, 1
>    %d = call i32 @bar(i32 %b)
> ------>
> bb1:
>    %d = call i32 @bar(i32 %p)

>GVN will perform this kind of transformation: it concludes that %a, %b, and %p are all equal and picks one representative value. However, these values are equal only when they are not poison.  If %p is indeed poison, then the transformation is wrong because before it was passing an ok value to bar() and after the transformation it is passing poison.
On the other hand, if branching on poison is UB, the original program was executing UB already because %p (and therefore %c) were poison. So the transformation is ok.
-------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170614/e97f7880/attachment.html>