[ValueTracking] fix bug computing isKnownToBeAPowerOfTwo() with arithmetic shift right (PR25900)

[spatel]

Summary

This is a fix for:
https://llvm.org/bugs/show_bug.cgi?id=25900

If we think that an arithmetic right shift of a power of two is always a power of two, an sdiv gets wrongly converted to udiv.
I didn't see a way to simplify the test case further.

[majnemer]

LGTM

lib/Analysis/ValueTracking.cpp

1748–1749 ↗

(On Diff #43795)

I wouldn't worry about this case here. I think canonicalization should be responsible for making sure that an arithmetic shift right can be turned into a logical shift right.

[spatel]

lib/Analysis/ValueTracking.cpp

1748–1749 ↗

(On Diff #43795)

Sounds good - I'll remove the TODO. Thanks for the prompt review!

llvm/trunk/lib/Analysis/ValueTracking.cpp

bool isKnownToBeAPowerOfTwo(Value *V, bool OrZero, unsigned Depth,
   if (match(V, m_LShr(m_SignBit(), m_Value())))
     return true;
 
   // The remaining tests are all recursive, so bail out if we hit the limit.
   if (Depth++ == MaxDepth)
     return false;
 
   Value *X = nullptr, *Y = nullptr;
-  // A shift of a power of two is a power of two or zero.
+  // A shift left or a logical shift right of a power of two is a power of two
+  // or zero.
   if (OrZero && (match(V, m_Shl(m_Value(X), m_Value())) ||
-                 match(V, m_Shr(m_Value(X), m_Value()))))
+                 match(V, m_LShr(m_Value(X), m_Value()))))
     return isKnownToBeAPowerOfTwo(X, /*OrZero*/ true, Depth, Q, DL);
 
   if (ZExtInst *ZI = dyn_cast<ZExtInst>(V))
     return isKnownToBeAPowerOfTwo(ZI->getOperand(0), OrZero, Depth, Q, DL);
 
   if (SelectInst *SI = dyn_cast<SelectInst>(V))
     return isKnownToBeAPowerOfTwo(SI->getTrueValue(), OrZero, Depth, Q, DL) &&
            isKnownToBeAPowerOfTwo(SI->getFalseValue(), OrZero, Depth, Q, DL);

llvm/trunk/test/Analysis/ValueTracking/known-power-of-two.ll

+; RUN: opt -S -instcombine < %s | FileCheck %s
+
+; https://llvm.org/bugs/show_bug.cgi?id=25900
+; An arithmetic shift right of a power of two is not a power
+; of two if the original value is the sign bit. Therefore,
+; we can't transform the sdiv into a udiv.
+
+define i32 @pr25900(i32 %d) {
+  %and = and i32 %d, -2147483648
+; The next 3 lines prevent another fold from masking the bug.
+  %ext = zext i32 %and to i64
+  %or = or i64 %ext, 4294967296
+  %trunc = trunc i64 %or to i32
+  %ashr = ashr exact i32 %trunc, 31
+  %div = sdiv i32 4, %ashr
+  ret i32 %div
+
+; CHECK: sdiv
+}
+