When complicated expressions are broken down into subexpressions

with multiplication by constants distributed through, occasionally
those subexpressions can include both x and -x. For now, if this
condition is discovered within LSR, just prune such cases away,
as they won't be profitable. This fixes a "zero allocated in a
base register" assertion failure.

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

diff --git a/lib/Transforms/Scalar/LoopStrengthReduce.cpp b/lib/Transforms/Scalar/LoopStrengthReduce.cpp
index b6ef718ce1636e08e3fcb06171e391c47c452fb1..11f218793476a625ca33c72c5e540e277f0b1545 100644 (file)
--- a/lib/Transforms/Scalar/LoopStrengthReduce.cpp
+++ b/lib/Transforms/Scalar/LoopStrengthReduce.cpp
@@ -2012,8 +2012,14 @@ void LSRInstance::GenerateCombinations(LSRUse &LU, unsigned LUIdx,
       F.BaseRegs.push_back(BaseReg);
   }
   if (Ops.size() > 1) {
-    F.BaseRegs.push_back(SE.getAddExpr(Ops));
-    (void)InsertFormula(LU, LUIdx, F);
+    const SCEV *Sum = SE.getAddExpr(Ops);
+    // TODO: If Sum is zero, it probably means ScalarEvolution missed an
+    // opportunity to fold something. For now, just ignore such cases
+    // rather than procede with zero in a register.
+    if (!Sum->isZero()) {
+      F.BaseRegs.push_back(Sum);
+      (void)InsertFormula(LU, LUIdx, F);
+    }
   }
 }