From 29a4b5dc0d754c9a45f62a8af0cc36e8de4f968d Mon Sep 17 00:00:00 2001 From: Sanjoy Das Date: Tue, 19 Jan 2016 20:53:51 +0000 Subject: [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 --- llvm/lib/Analysis/ScalarEvolution.cpp | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'llvm/lib/Analysis') diff --git a/llvm/lib/Analysis/ScalarEvolution.cpp b/llvm/lib/Analysis/ScalarEvolution.cpp index dd42fb115a2..ed640acfda5 100644 --- a/llvm/lib/Analysis/ScalarEvolution.cpp +++ b/llvm/lib/Analysis/ScalarEvolution.cpp @@ -5367,6 +5367,14 @@ ScalarEvolution::computeExitLimitFromCond(const Loop *L, BECount = EL0.Exact; } + // There are cases (e.g. PR26207) where computeExitLimitFromCond is able + // to be more aggressive when computing BECount than when computing + // MaxBECount. In these cases it is possible for EL0.Exact and EL1.Exact + // to match, but for EL0.Max and EL1.Max to not. + if (isa(MaxBECount) && + !isa(BECount)) + MaxBECount = BECount; + return ExitLimit(BECount, MaxBECount); } if (BO->getOpcode() == Instruction::Or) { -- cgit v1.2.3