<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 8, 2014 at 6:56 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Now that I think of it, I think function arguments cannot be poison.<br>
<span class="">The LangRef says:<br>
<br>
"Values other than phi nodes depend on their operands."<br>
<br>
</span>and<br>
<span class=""><br>
"any instruction that has a dependence on a poison value has undefined<br>
behavior."<br>
<br>
</span>This means a call or invoke that passes a poison value as an argument<br>
has undefined behavior.</blockquote><div><br></div><div>I'm pretty sure the LangRef has a bug here.  It cannot literally mean undefined behavior or the program hits UB once an add nsw that produces poison is used as the operand to another add.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">So we can conclude that a function argument<br>
can never be poison -- the call (or invoke) would be UB otherwise.<br>
Inlining a function can change undefined behavior to not undefined<br>
behavior, but that's allowed.<br>
<span class=""><font color="#888888"><br>
-- Sanjoy<br>
</font></span><div class=""><div class="h5"><br>
<br>
On Sat, Nov 8, 2014 at 4:59 PM, Sanjoy Das<br>
<<a href="mailto:sanjoy@playingwithpointers.com">sanjoy@playingwithpointers.com</a>> wrote:<br>
> Hi,<br>
><br>
> Just to be sure I understand the situation correctly: llvm concludes a<br>
> value to be non-zero or a poison value.  The value cannot be poison<br>
> because if it is, any instruction that observes the poison will cause<br>
> undefined behavior (that may include propagating the poison value down<br>
> the use-def chain) and this "cannot happen".  Thus it must be non-zero<br>
> or have no uses.  So it is safe to conclude that it is non-zero.<br>
><br>
>> I doubt a correct implementation of isKnownNeverToBeUndef will ever fire<br>
>> because it must be incredibly conservative: function arguments might<br>
>> silently cary poison in them making them unsafe.<br>
><br>
> It feels like that "isKnownNotPoison" will have to be a path-sensitive<br>
> property.  For example, the following case<br>
><br>
> void f(int x) {<br>
>   if (x < 10) {<br>
>     if (unknown) {<br>
>       int t = 30 / x;<br>
>     }<br>
>   }<br>
> }<br>
><br>
> can be transformed to<br>
><br>
> void f(int x) {<br>
>   if (x < 10) {<br>
>     int t = 30 / x;<br>
>     if (unknown) {<br>
>     }<br>
>   }<br>
> }<br>
><br>
> since x can't be poison after the `icmp` has been executed. LangRef<br>
> says:<br>
><br>
>  1. "Values other than phi nodes depend on their operands."<br>
><br>
>  2. "any instruction that has a dependence on a poison value has<br>
>      undefined behavior."<br>
><br>
> "isKnownNeverToBeUndef" is distinct from "isKnownNotPoison", since not<br>
> every instruction consuming an undef has UB.  For example the above<br>
> transform is not sound if `x` was `undef` (without "coercing" the<br>
> `undef` to some constant value) -- since it could then be `0`.<br>
><br>
> -- Sanjoy<br>
</div></div></blockquote></div><br></div></div>