[llvm-commits] [llvm] r131887 - in /llvm/trunk: lib/Transforms/InstCombine/InstCombineMulDivRem.cpp test/Transforms/InstCombine/shift.ll

[Eli Friedman]

On Mon, May 23, 2011 at 10:27 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Chris,
>
>> Transform any logical shift of a power of two into an exact/NUW shift when
>> in a known-non-zero context.
>
> in "x div (1 << y)" this will mark the shift as "nuw" always, due to the
> following logic: (A) isPowerOfTwo will say that "1 << y" is a power of
> two, because either the 1 is shifted off the end so yielding an undef which
> can be assumed to be a power of two, or the 1 isn't shifted off the end in
> which case it sure is a power of two; (B) then your logic will deduce that
> 1 was not shifted off the end, and will add a nsw flag to the shift.
>
> Thus this transform potentially upgrades an undef value to a trap value: if
> later on some pass discovers for example that y is big enough that it shifts 1
> off the end then now you get a trap value while before this transform you got
> an undef.  Yet trap values are defined to only occur when violating a nsw/nuw/
> exact flag on an operation, but there was no such flag in the original code!
> I don't know if this matters but it seems a bit dubious to me.

I don't see how the difference between an undef value and a trap value
matters here; dividing by undef and dividing by trap have the same
result: UB.  And I don't see any reason to guarantee that the
optimizer will never introduce trap values (assuming the semantics of
the program don't change).

-Eli