LLVM21 bug workaround: getFixedValue() - #9374
Open
mcourteaux wants to merge 3 commits into
Open
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #9374 +/- ##
==========================================
- Coverage 70.03% 69.99% -0.04%
==========================================
Files 261 261
Lines 79223 79231 +8
Branches 19312 19313 +1
==========================================
- Hits 55487 55461 -26
- Misses 17923 17938 +15
- Partials 5813 5832 +19 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Member
|
We are about to delete support for llvm 21 after the next release, but no objections to merging this - this is a good fix to go into the Halide 22 release, which is still supposed to support llvm 21. |
alexreinking
approved these changes
Aug 24, 2026
5 tasks
LLVM 21's LoopAccessAnalysis::getStrideFromAddRec() queries a scalable-vector access type's fixed element count without guarding against ScalableVectorType, hitting a fatal assertion (TypeSize::getFixedValue on a scalable TypeSize) inside LoopLoadEliminationPass, which the default O3 pipeline always runs regardless of Halide's own loop-opt settings. Fixed upstream in LLVM 22. Loop load elimination looks for opportunities to forward a store to a later load across loop iterations, which Halide-generated code essentially never benefits from, so skip it entirely on affected SVE targets under the buggy LLVM versions via PassInstrumentationCallbacks::registerShouldRunOptionalPassCallback rather than crash (or, in a no-asserts LLVM build, silently compute a bogus stride). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
These tests were skipped under LLVM 21 + SVE2 because they tripped a TypeSize::getFixedValue() assertion in LoopAccessAnalysis, reached via LLVM's LoopLoadEliminationPass. The previous commit skips that pass on SVE targets under LLVM < 22, which should make the underlying crash unreachable; drop the test-level skips so CI on real ARM hardware can confirm. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The unnamed llvm::Any parameter of the LoopLoadEliminationPass-skipping lambda was passed by value; clang-tidy flags this as an unnecessary copy since it's not used at all except as an unused reference param. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
alexreinking
force-pushed
the
mcourteaux/llvm21-load-elim-workaround
branch
from
August 24, 2026 20:21
a01623a to
7c72fc2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Test to see if Claude's analysis on a recent issue I ran into is indeed the fix for more than just my particular use case, but so many other tests which are just skipped now, due to LLVM 21 bug: llvm/llvm-project@d1500d12be60 (PR #169764)
Fixes [no tracking issue it seems]
Checklist