Don't rely on the fact that shift values are never very large, and thus

this substraction will result in small negative numbers at worst which
become very large positive numbers on assignment and are thus caught by
the <=4 check on the next line. The >0 check clearly intended to catch
these as negative numbers.

Spotted by inspection, and impossible to trigger given the shift widths
that can be used.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147773 91177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/lib/Target/X86/X86ISelDAGToDAG.cpp b/lib/Target/X86/X86ISelDAGToDAG.cpp
index 3c35763f82dedd9ca305a0b044f35e72dbcacd1b..1cc19b25d5e41999712d8ca4facb571ea5714701 100644 (file)
--- a/lib/Target/X86/X86ISelDAGToDAG.cpp
+++ b/lib/Target/X86/X86ISelDAGToDAG.cpp
@@ -996,7 +996,7 @@ bool X86DAGToDAGISel::MatchAddressRecursively(SDValue N, X86ISelAddressMode &AM,
     // allows us to convert the shift and and into an h-register extract and
     // a scaled index.
     if (Shift.getOpcode() == ISD::SRL && Shift.hasOneUse()) {
-      unsigned ScaleLog = 8 - C1->getZExtValue();
+      int ScaleLog = 8 - C1->getZExtValue();
       if (ScaleLog > 0 && ScaleLog < 4 &&
           C2->getZExtValue() == (UINT64_C(0xff) << ScaleLog)) {
         SDValue Eight = CurDAG->getConstant(8, MVT::i8);