-
Notifications
You must be signed in to change notification settings - Fork 14.3k
release/20.x: [ScalarEvolution] Handle addrec incoming value in isImpliedViaMerge() (#126236) #126492
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@dtcxzyw What do you think about merging this PR to the release branch? |
@llvm/pr-subscribers-llvm-transforms @llvm/pr-subscribers-llvm-analysis Author: None (llvmbot) ChangesRequested by: @nikic Full diff: https://github.com/llvm/llvm-project/pull/126492.diff 2 Files Affected:
diff --git a/llvm/lib/Analysis/ScalarEvolution.cpp b/llvm/lib/Analysis/ScalarEvolution.cpp
index 2ce40877b523e10..c71202c8dd58e4d 100644
--- a/llvm/lib/Analysis/ScalarEvolution.cpp
+++ b/llvm/lib/Analysis/ScalarEvolution.cpp
@@ -12402,6 +12402,12 @@ bool ScalarEvolution::isImpliedViaMerge(CmpPredicate Pred, const SCEV *LHS,
// iteration of a loop.
if (!properlyDominates(L, LBB))
return false;
+ // Addrecs are considered to properly dominate their loop, so are missed
+ // by the previous check. Discard any values that have computable
+ // evolution in this loop.
+ if (auto *Loop = LI.getLoopFor(LBB))
+ if (hasComputableLoopEvolution(L, Loop))
+ return false;
if (!ProvedEasily(L, RHS))
return false;
}
diff --git a/llvm/test/Transforms/IndVarSimplify/pr126012.ll b/llvm/test/Transforms/IndVarSimplify/pr126012.ll
new file mode 100644
index 000000000000000..5189fe020dd3bfd
--- /dev/null
+++ b/llvm/test/Transforms/IndVarSimplify/pr126012.ll
@@ -0,0 +1,53 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --version 5
+; RUN: opt -S -passes=indvars < %s | FileCheck %s
+
+; Do not infer that %cmp is true. The %indvar3 input of %indvar2 comes from
+; a previous iteration, so we should not compare it to a value from the current
+; iteration.
+define i32 @test() {
+; CHECK-LABEL: define i32 @test() {
+; CHECK-NEXT: [[ENTRY:.*]]:
+; CHECK-NEXT: br label %[[FOR_PREHEADER:.*]]
+; CHECK: [[FOR_PREHEADER]]:
+; CHECK-NEXT: [[INDVAR1:%.*]] = phi i32 [ 0, %[[ENTRY]] ], [ [[PHI:%.*]], %[[FOR_INC:.*]] ]
+; CHECK-NEXT: [[INDVAR2:%.*]] = phi i32 [ 1, %[[ENTRY]] ], [ [[INDVAR3:%.*]], %[[FOR_INC]] ]
+; CHECK-NEXT: [[INDVAR3]] = phi i32 [ 0, %[[ENTRY]] ], [ [[INC:%.*]], %[[FOR_INC]] ]
+; CHECK-NEXT: [[COND1:%.*]] = icmp eq i32 [[INDVAR3]], 0
+; CHECK-NEXT: br i1 [[COND1]], label %[[FOR_INC]], label %[[FOR_END:.*]]
+; CHECK: [[FOR_END]]:
+; CHECK-NEXT: [[CMP:%.*]] = icmp ugt i32 [[INDVAR2]], 0
+; CHECK-NEXT: [[EXT:%.*]] = zext i1 [[CMP]] to i32
+; CHECK-NEXT: br label %[[FOR_INC]]
+; CHECK: [[FOR_INC]]:
+; CHECK-NEXT: [[PHI]] = phi i32 [ [[EXT]], %[[FOR_END]] ], [ 0, %[[FOR_PREHEADER]] ]
+; CHECK-NEXT: [[INC]] = add nuw nsw i32 [[INDVAR3]], 1
+; CHECK-NEXT: [[EXITCOND:%.*]] = icmp eq i32 [[INDVAR3]], 2
+; CHECK-NEXT: br i1 [[EXITCOND]], label %[[FOR_EXIT:.*]], label %[[FOR_PREHEADER]]
+; CHECK: [[FOR_EXIT]]:
+; CHECK-NEXT: [[INDVAR1_LCSSA:%.*]] = phi i32 [ [[INDVAR1]], %[[FOR_INC]] ]
+; CHECK-NEXT: ret i32 [[INDVAR1_LCSSA]]
+;
+entry:
+ br label %for.preheader
+
+for.preheader:
+ %indvar1 = phi i32 [ 0, %entry ], [ %phi, %for.inc ]
+ %indvar2 = phi i32 [ 1, %entry ], [ %indvar3, %for.inc ]
+ %indvar3 = phi i32 [ 0, %entry ], [ %inc, %for.inc ]
+ %cond1 = icmp eq i32 %indvar3, 0
+ br i1 %cond1, label %for.inc, label %for.end
+
+for.end:
+ %cmp = icmp sgt i32 %indvar2, 0
+ %ext = zext i1 %cmp to i32
+ br label %for.inc
+
+for.inc:
+ %phi = phi i32 [ %ext, %for.end ], [ 0, %for.preheader ]
+ %inc = add i32 %indvar3, 1
+ %exitcond = icmp eq i32 %indvar3, 2
+ br i1 %exitcond, label %for.exit, label %for.preheader
+
+for.exit:
+ ret i32 %indvar1
+}
|
(cherry picked from commit ae08969)
…llvm#126236) The code already guards against values coming from a previous iteration using properlyDominates(). However, addrecs are considered to properly dominate the loop they are defined in. Handle this special case separately, by checking for expressions that have computable loop evolution (this should cover cases like a zext of an addrec as well). I considered changing the definition of properlyDominates() instead, but decided against it. The current definition is useful in other context, e.g. when deciding whether an expression is safe to expand in a given block. Fixes llvm#126012. (cherry picked from commit 7aed53e)
@nikic (or anyone else). If you would like to add a note about this fix in the release notes (completely optional). Please reply to this comment with a one or two sentence description of the fix. When you are done, please add the release:note label to this PR. |
Backport ae08969 7aed53e
Requested by: @nikic