[LLVMdev] RFC: Proposal for Poison Semantics

[Reid Kleckner]

On Wed, Jan 28, 2015 at 8:53 PM, Philip Reames <listmail at philipreames.com>
wrote:

>  On 01/28/2015 07:02 AM, Sean Silva wrote:
>
> Could you maybe provide an example where replacing `%always_poison` with
> `undef` will change the meaning? At least for me, the thing that I'm most
> unclear about is how poison differs from undef.
>
> I will second this request for much the same reason.
>

undef isn't strong enough to perform the simplification "a + 1 > a  -->
 true" for an nsw add.

If we use undef instead of poison, "a + 1" will produce undef iff a is
MAX_INT, but we cannot choose a bit-pattern for the undef result that is
greater than MAX_INT. In other words, as David said, the comparison  "icmp
gt i32 undef, MAX_INT" is always true, just as "and i32 undef, 0" always
produces 0.

I've been discussing a model with David that might steer poison back
towards something that simply supports algebraic simplification. If we have
a math operation that cannot wrap, then it notionally produces as many bits
of undef as the operation could possibly produce. For example, "add nsw i8"
can produce an i9 undef, and "mul nsw i8" can produce an undefined 16 bit
bitpattern. This is strong enough to do things like "a + 1 > a  -->  true",
because on overflow of "a + 1" we can choose an poison value of "MAX_INT +
1", even though that is not a valid i8 bit pattern.

So, a short version would be that poison is like undef, except you get to
include the overflow bits of the computation in your undef value.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150129/7d650184/attachment.html>