Skip to content

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

Merged
merged 2 commits into from
Feb 11, 2025

Conversation

llvmbot
Copy link
Member

@llvmbot llvmbot commented Feb 10, 2025

Backport ae08969 7aed53e

Requested by: @nikic

@llvmbot llvmbot requested a review from nikic as a code owner February 10, 2025 09:38
@llvmbot llvmbot added this to the LLVM 20.X Release milestone Feb 10, 2025
@llvmbot
Copy link
Member Author

llvmbot commented Feb 10, 2025

@dtcxzyw What do you think about merging this PR to the release branch?

@llvmbot llvmbot requested a review from dtcxzyw February 10, 2025 09:38
@llvmbot llvmbot added llvm:analysis Includes value tracking, cost tables and constant folding llvm:transforms labels Feb 10, 2025
@llvmbot
Copy link
Member Author

llvmbot commented Feb 10, 2025

@llvm/pr-subscribers-llvm-transforms

@llvm/pr-subscribers-llvm-analysis

Author: None (llvmbot)

Changes

Backport ae08969 7aed53e

Requested by: @nikic


Full diff: https://github.com/llvm/llvm-project/pull/126492.diff

2 Files Affected:

  • (modified) llvm/lib/Analysis/ScalarEvolution.cpp (+6)
  • (added) llvm/test/Transforms/IndVarSimplify/pr126012.ll (+53)
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)
@tstellar tstellar merged commit af970cd into llvm:release/20.x Feb 11, 2025
8 of 10 checks passed
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
llvm:analysis Includes value tracking, cost tables and constant folding llvm:transforms
Projects
Development

Successfully merging this pull request may close these issues.

4 participants