Skip to content

[LoopVectorize] Clear stale CycleAnalysis after loop simplification - #218563

Open
Opriego wants to merge 1 commit into
llvm:mainfrom
Opriego:fix-loopvectorize-stale-cycle-after-simplify
Open

[LoopVectorize] Clear stale CycleAnalysis after loop simplification#218563
Opriego wants to merge 1 commit into
llvm:mainfrom
Opriego:fix-loopvectorize-stale-cycle-after-simplify

Conversation

@Opriego

@Opriego Opriego commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

Fixes #218392.

LoopVectorizePass::runImpl() simplifies loops before processing them. That
initial simplifyLoop() phase may change the CFG.

If CycleAnalysis was already cached by an earlier pass, the cached result
still describes the pre-simplified CFG. Later, processLoop() may request
BlockFrequencyAnalysis lazily from the cost model. Since BFI now depends on
CycleAnalysis, it can consume the stale cycle information and hit:

Assertion `Resolved >= Pred && "unhandled irreducible control flow"' failed.

Clear a cached CycleAnalysis immediately after the initial loop
simplification when the CFG changed, so a later BFI request recomputes cycle
information for the simplified CFG.

This is similar to #215237, which clears stale CycleAnalysis after
vectorizing a loop. This change covers the earlier CFG-changing simplification
phase before the first loop is processed.

Added a reduced regression test based on #218392.

Testing:

AI-assisted development tools were used during this contribution; I personally modified, reviewed, and validated the final patch

@github-actions

Copy link
Copy Markdown

Hello @Opriego 👋

Thank you for submitting a Pull Request (PR) to the LLVM Project. Since this is your first PR, here are a few useful links covering our main contribution policies and review practices.

  • All contributions to LLVM must follow our LLVM AI Tool Use Policy. In particular, if you used AI while working on this PR, remember to add a note to the PR description.
  • The LLVM Code-Review Policy and Practices document contains practical information about the PR process, including how patches are reviewed and accepted, and who can review a PR.
  • Our LLVM Developer Policy describes our expectations for code quality, commit summaries and contains notes on our CI system.

Please reply to this message to confirm that you have read these policies, especially the LLVM AI Tool Use Policy, and that any AI tool usage has been noted in the PR description.


Frequently asked questions

How do I add reviewers?

This PR will be automatically labeled, and the relevant teams will be notified. For some parts of the project, reviewers may also be added automatically.

You can also add reviewers manually using the Reviewers section on this page. If you cannot use that section, it is probably because you do not have write permissions for the repository. In that case, you can request a review by tagging reviewers in a comment using @ followed by their GitHub username.

What if there are no comments?

If you have not received any comments on your PR after a week, you can request a review by pinging the PR with a comment such as “Ping”. The common courtesy ping rate is once a week. Please remember that you are asking for volunteer time from other developers.

Are any special GitHub settings required to contribute to LLVM?

We only require contributors to have a public email address associated with their GitHub commits, see this section of LLVM Developer Policy for details.


If you have questions, feel free to leave a comment on this PR, or ask on LLVM Discord or LLVM Discourse.

Thank you,
The LLVM Community

@llvmorg-github-actions

Copy link
Copy Markdown

@llvm/pr-subscribers-vectorizers

Author: Oscar Priego (Opriego)

Changes

Fixes #218392.

LoopVectorizePass::runImpl() simplifies loops before processing them. That
initial simplifyLoop() phase may change the CFG.

If CycleAnalysis was already cached by an earlier pass, the cached result
still describes the pre-simplified CFG. Later, processLoop() may request
BlockFrequencyAnalysis lazily from the cost model. Since BFI now depends on
CycleAnalysis, it can consume the stale cycle information and hit:

Assertion `Resolved >= Pred && "unhandled irreducible control flow"' failed.

Clear a cached CycleAnalysis immediately after the initial loop
simplification when the CFG changed, so a later BFI request recomputes cycle
information for the simplified CFG.

This is similar to #215237, which clears stale CycleAnalysis after
vectorizing a loop. This change covers the earlier CFG-changing simplification
phase before the first loop is processed.

Added a reduced regression test based on #218392.

Testing:

  • bfi-stale-after-loop-simplify.ll: PASS
  • existing bfi-stale-crash.ll: PASS
  • exact #218392 reproducer:
    function(require<cycles>,loop-vectorize,print<block-freq>): exit 0

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

2 Files Affected:

  • (modified) llvm/lib/Transforms/Vectorize/LoopVectorize.cpp (+6)
  • (added) llvm/test/Transforms/LoopVectorize/bfi-stale-after-loop-simplify.ll (+25)
diff --git a/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp b/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
index 63f955538a8d7..97fd016a63d2c 100644
--- a/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
+++ b/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
@@ -8330,6 +8330,12 @@ LoopVectorizeResult LoopVectorizePass::runImpl(Function &F) {
     Changed |= CFGChanged |=
         simplifyLoop(L, DT, LI, SE, AC, nullptr, false /* PreserveLCSSA */);
 
+  // Loop simplification may change the CFG before processLoop() lazily requests
+  // BlockFrequencyAnalysis. Clear a cached CycleAnalysis so BFI recomputes it
+  // for the simplified CFG.
+  if (CFGChanged && FAM->getCachedResult<CycleAnalysis>(F))
+    FAM->clearAnalysis<CycleAnalysis>(F);
+
   // Build up a worklist of inner-loops to vectorize. This is necessary as
   // the act of vectorizing or partially unrolling a loop creates new loops
   // and can invalidate iterators across the loops.
diff --git a/llvm/test/Transforms/LoopVectorize/bfi-stale-after-loop-simplify.ll b/llvm/test/Transforms/LoopVectorize/bfi-stale-after-loop-simplify.ll
new file mode 100644
index 0000000000000..1dfe4882f9193
--- /dev/null
+++ b/llvm/test/Transforms/LoopVectorize/bfi-stale-after-loop-simplify.ll
@@ -0,0 +1,25 @@
+; RUN: opt < %s -passes='function(require<cycles>,loop-vectorize)' -disable-output
+
+; LoopVectorize simplifies loops before processing them. If CycleAnalysis was
+; cached before the pass, it must not be reused after loop simplification
+; changes the CFG when BlockFrequencyInfo is requested lazily.
+
+define i16 @f(i1 %c) {
+entry:
+  br label %header
+
+latch:
+  %iv.next = add i16 %iv, 1
+  %done = icmp eq i16 %iv.next, 0
+  br i1 %done, label %second, label %header
+
+header:
+  %iv = phi i16 [ 0, %entry ], [ %iv.next, %latch ]
+  br i1 %c, label %trap, label %latch
+
+trap:
+  unreachable
+
+second:
+  br i1 false, label %second, label %second
+}

@llvmorg-github-actions

Copy link
Copy Markdown

@llvm/pr-subscribers-llvm-transforms

Author: Oscar Priego (Opriego)

Changes

Fixes #218392.

LoopVectorizePass::runImpl() simplifies loops before processing them. That
initial simplifyLoop() phase may change the CFG.

If CycleAnalysis was already cached by an earlier pass, the cached result
still describes the pre-simplified CFG. Later, processLoop() may request
BlockFrequencyAnalysis lazily from the cost model. Since BFI now depends on
CycleAnalysis, it can consume the stale cycle information and hit:

Assertion `Resolved &gt;= Pred &amp;&amp; "unhandled irreducible control flow"' failed.

Clear a cached CycleAnalysis immediately after the initial loop
simplification when the CFG changed, so a later BFI request recomputes cycle
information for the simplified CFG.

This is similar to #215237, which clears stale CycleAnalysis after
vectorizing a loop. This change covers the earlier CFG-changing simplification
phase before the first loop is processed.

Added a reduced regression test based on #218392.

Testing:

  • bfi-stale-after-loop-simplify.ll: PASS
  • existing bfi-stale-crash.ll: PASS
  • exact #218392 reproducer:
    function(require&lt;cycles&gt;,loop-vectorize,print&lt;block-freq&gt;): exit 0

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

2 Files Affected:

  • (modified) llvm/lib/Transforms/Vectorize/LoopVectorize.cpp (+6)
  • (added) llvm/test/Transforms/LoopVectorize/bfi-stale-after-loop-simplify.ll (+25)
diff --git a/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp b/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
index 63f955538a8d7..97fd016a63d2c 100644
--- a/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
+++ b/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
@@ -8330,6 +8330,12 @@ LoopVectorizeResult LoopVectorizePass::runImpl(Function &F) {
     Changed |= CFGChanged |=
         simplifyLoop(L, DT, LI, SE, AC, nullptr, false /* PreserveLCSSA */);
 
+  // Loop simplification may change the CFG before processLoop() lazily requests
+  // BlockFrequencyAnalysis. Clear a cached CycleAnalysis so BFI recomputes it
+  // for the simplified CFG.
+  if (CFGChanged && FAM->getCachedResult<CycleAnalysis>(F))
+    FAM->clearAnalysis<CycleAnalysis>(F);
+
   // Build up a worklist of inner-loops to vectorize. This is necessary as
   // the act of vectorizing or partially unrolling a loop creates new loops
   // and can invalidate iterators across the loops.
diff --git a/llvm/test/Transforms/LoopVectorize/bfi-stale-after-loop-simplify.ll b/llvm/test/Transforms/LoopVectorize/bfi-stale-after-loop-simplify.ll
new file mode 100644
index 0000000000000..1dfe4882f9193
--- /dev/null
+++ b/llvm/test/Transforms/LoopVectorize/bfi-stale-after-loop-simplify.ll
@@ -0,0 +1,25 @@
+; RUN: opt < %s -passes='function(require<cycles>,loop-vectorize)' -disable-output
+
+; LoopVectorize simplifies loops before processing them. If CycleAnalysis was
+; cached before the pass, it must not be reused after loop simplification
+; changes the CFG when BlockFrequencyInfo is requested lazily.
+
+define i16 @f(i1 %c) {
+entry:
+  br label %header
+
+latch:
+  %iv.next = add i16 %iv, 1
+  %done = icmp eq i16 %iv.next, 0
+  br i1 %done, label %second, label %header
+
+header:
+  %iv = phi i16 [ 0, %entry ], [ %iv.next, %latch ]
+  br i1 %c, label %trap, label %latch
+
+trap:
+  unreachable
+
+second:
+  br i1 false, label %second, label %second
+}

@Opriego

Opriego commented Aug 25, 2026

Copy link
Copy Markdown
Contributor Author

Hello @Opriego 👋

Thank you for submitting a Pull Request (PR) to the LLVM Project. Since this is your first PR, here are a few useful links covering our main contribution policies and review practices.

  • All contributions to LLVM must follow our LLVM AI Tool Use Policy. In particular, if you used AI while working on this PR, remember to add a note to the PR description.
  • The LLVM Code-Review Policy and Practices document contains practical information about the PR process, including how patches are reviewed and accepted, and who can review a PR.
  • Our LLVM Developer Policy describes our expectations for code quality, commit summaries and contains notes on our CI system.

Please reply to this message to confirm that you have read these policies, especially the LLVM AI Tool Use Policy, and that any AI tool usage has been noted in the PR description.

Frequently asked questions

How do I add reviewers?

This PR will be automatically labeled, and the relevant teams will be notified. For some parts of the project, reviewers may also be added automatically.

You can also add reviewers manually using the Reviewers section on this page. If you cannot use that section, it is probably because you do not have write permissions for the repository. In that case, you can request a review by tagging reviewers in a comment using @ followed by their GitHub username.

What if there are no comments?

If you have not received any comments on your PR after a week, you can request a review by pinging the PR with a comment such as “Ping”. The common courtesy ping rate is once a week. Please remember that you are asking for volunteer time from other developers.

Are any special GitHub settings required to contribute to LLVM?

We only require contributors to have a public email address associated with their GitHub commits, see this section of LLVM Developer Policy for details.

If you have questions, feel free to leave a comment on this PR, or ask on LLVM Discord or LLVM Discourse.

Thank you, The LLVM Community

I confirm that I've read these policies

// Loop simplification may change the CFG before processLoop() lazily requests
// BlockFrequencyAnalysis. Clear a cached CycleAnalysis so BFI recomputes it
// for the simplified CFG.
if (CFGChanged && FAM->getCachedResult<CycleAnalysis>(F))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this, we can probably revert the code from #215237

@MaskRay
MaskRay requested a review from fhahn August 25, 2026 07:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

loop-vectorize crashes with Assertion `Resolved >= Pred && "unhandled irreducible control flow"' failed.

2 participants