LLVM21 bug workaround: getFixedValue() - #9374
Open
mcourteaux wants to merge 4 commits into
Open
Conversation
mcourteaux
changed the title
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #9374 +/- ##
==========================================
+ Coverage 69.89% 70.08% +0.18%
==========================================
Files 261 261
Lines 79362 79370 +8
Branches 19349 19350 +1
==========================================
+ Hits 55474 55629 +155
+ Misses 17926 17906 -20
+ Partials 5962 5835 -127 ☔ 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
alexreinking
force-pushed
the
mcourteaux/llvm21-load-elim-workaround
branch
from
August 24, 2026 20:21
a01623a to
7c72fc2
Compare
Contributor
Author
|
There is an indefinite hang in |
alexreinking
requested changes
Aug 25, 2026
alexreinking
left a comment
alexreinking
left a comment
Member
There was a problem hiding this comment.
Invalidating my previous accept pending investigation into the vector-reductions hang.
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>
The skip removed in the previous commit attributed this test's LLVM 21 failure entirely to the LoopLoadEliminationPass getFixedValue() assert, but its original comment also noted a hang under LLVM 20 tied to the same upstream fix. Investigation shows the hang is a separate, Halide-side bug: the reduce-padding recursion in CodeGen_ARM::codegen_across_vector_reduce can fail to converge for some SVE2 vector-reduce shapes, independent of LoopLoadEliminationPass. Restore the skip so this test doesn't hang CI; the other 11 test skips removed previously only ever hit the assert, not a hang, and stay removed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
mcourteaux
force-pushed
the
mcourteaux/llvm21-load-elim-workaround
branch
from
August 26, 2026 07:02
772305e to
a68de1f
Compare
5 tasks
Contributor
Author
|
Conclusion: this hang was pre-existing, and the corresponding skip got incorrectly disabled by thinking it would have been fixed by this PR. Claude prepared a separate fix for this, but for the sake of reviewing and merging smaller PRs, I have open PR here: #9396 |
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
3 participants
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