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

[Nick Lewycky]

Duncan Sands 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,

Dividing by zero actually generates a trap, not just undef. You could 
update the LangRef to make that explicit. The real question is whether 
it matters which instruction generates a trap. As the LangRef stands 
today, I'm pretty sure it doesn't.

I'm not entirely confident in whether that's still true once we adopt 
the Seattle model, but I think it's still safe. Adopt the what? This: 
http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-April/031247.html .

Nick

  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.
>
> Ciao, Duncan.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>