[LLVMdev] RFC: Proposal for Poison Semantics

Sanjoy Das sanjoy at playingwithpointers.com
Tue Jan 27 20:32:11 PST 2015


>
> Correct me if I am wrong but we are talking about transforming:
>    %maybe_poison = add nuw i32 %a, %b
>    %x = zext i32 %maybe_poison to i64
>    %y = lshr i64 %x 32
>
> To:
>    %za = zext i32 %a to i64
>    %zb = zext i32 %b to i64
>    %x = add nuw i64 %za, %zb
>    %y = lshr i64 %x 32
>
> ?
>
> If so, this seems fine in the model given by the RFC.
>
> In the before case:
> %maybe_poison doesn't infect the upper bits of %x with its poison which
> allows %y to have the well defined result 0.
>
> In the after case:
> %za and %zb will have their top 32-bits filled with zeros making it
> impossible for nuw to be violated for %x, %y would have the well defined
> result 0.
>

If both %a and %b are 2^32-1, won't %y be 0 in the first case and 1 in
the second?  The reason why we can get away with this _now_ is because
the first program has UB and hence anything can happen, including
storing to &a[1] instead &a[0].  But with the semantics in the RFC,
the first program is well-defined and is storing to &a[0] so we cannot
change it to store to &a[1] instead.

-- Sanjoy



More information about the llvm-dev mailing list