[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