[SCEV] Fix PR26207

In some cases, the max backedge taken count can be more conservative
than the exact backedge taken count (for instance, because
ScalarEvolution::getRange is not control-flow sensitive whereas
computeExitLimitFromICmp can be).  In these cases,
computeExitLimitFromCond (specifically the bit that deals with `and` and
`or` instructions) can create an ExitLimit instance with a
`SCEVCouldNotCompute` max backedge count expression, but a computable
exact backedge count expression.  This violates an implicit SCEV
assumption: a computable exact BE count should imply a computable max BE
count.

This change

 - Makes the above implicit invariant explicit by adding an assert to
   ExitLimit's constructor

 - Changes `computeExitLimitFromCond` to be more robust around
   conservative max backedge counts

llvm-svn: 258184

1 files changed, 20 insertions, 0 deletions

diff --git a/llvm/test/Transforms/IndVarSimplify/pr26207.ll b/llvm/test/Transforms/IndVarSimplify/pr26207.ll
new file mode 100644
index 00000000000..9d351e09857
--- /dev/null
+++ b/llvm/test/Transforms/IndVarSimplify/pr26207.ll
@@ -0,0 +1,20 @@
+; RUN: opt -S -indvars < %s | FileCheck %s
+
+target triple = "x86_64-unknown-linux-gnu"
+
+define void @main(i16 %in) {
+; CHECK-LABEL: @main(
+  br label %bb2
+
+bb2:                                              ; preds = %bb1.i, %bb2, %0
+  %_tmp44.i = icmp slt i16 %in, 2
+  br i1 %_tmp44.i, label %bb1.i, label %bb2
+
+bb1.i:                                            ; preds = %bb1.i, %bb2
+  %_tmp25.i = phi i16 [ %in, %bb2 ], [ %_tmp6.i, %bb1.i ]
+  %_tmp6.i = add nsw i16 %_tmp25.i, 1
+  %_tmp10.i = icmp sge i16 %_tmp6.i, 2
+  %exitcond.i = icmp eq i16 %_tmp6.i, 2
+  %or.cond = and i1 %_tmp10.i, %exitcond.i
+  br i1 %or.cond, label %bb2, label %bb1.i
+}