Update LLVM to 22.1.8#197
Merged
nikic merged 12 commits intoJun 17, 2026
Merged
Conversation
…tly in concept hashing (llvm#199617) They were sometimes incorrect because the written type doesn't contain an NNS which contains template parameters we're interested in. No release note because the bug broke MS STL and I want to backport it to the last 22.x release Fixes llvm#198663 (cherry picked from commit 06ffb65)
…t-lto-objects (llvm#200764) Building with --fat-lto-objects was added in llvm#140381 (cff9ae7). On macOS the tests are failing when building release binaries with many "The file was not recognized as a valid object file" errors, e.g.: 2026-01-16T12:54:26.0928880Z /Users/runner/work/llvm-project/llvm-project/build/tools/clang/stage2-instrumented-bins/tools/clang/stage2-bins/_CPack_Packages/Darwin/TXZ/LLVM-22.1.0-rc1-macOS-ARM64/bin/llvm-strip: error: '/Users/runner/work/llvm-project/llvm-project/build/tools/clang/stage2-instrumented-bins/tools/clang/stage2-bins/_CPack_Packages/Darwin/TXZ/LLVM-22.1.0-rc1-macOS-ARM64/lib/libLLVMAArch64AsmParser.a(AArch64AsmParser.cpp.o)': The file was not recognized as a valid object file It's assuming bitcode is embedded in section .llvm.lto (llvm/lib/Object/ObjectFile.cpp:80) but on MachO it's in __LLVM,__bitcode (llvm/lib/Object/MachOObjectFile.cpp:2184) llvm-bitcode-strip is a driver for the MachO bitcode_strip utility which handles this. Use this instead. Fixes llvm#176398. Assisted-by: codex (cherry picked from commit b8e768f)
…llvm#201509) All of i64, f64, v2i32, v4i16, v8i8 are assigned to the DoubleRegs register class (64-bit register pairs). A bitcast between any two of these types is a machine-level no-op (ie. the same physical register is reinterpreted with a different type). HexagonPatterns.td had NopCast_pat entries for all int-to-int bitcasts within DoubleRegs, and explicit patterns for f64 <-> i64, but was missing patterns for f64 <-> v2i32, f64 <-> v4i16, and f64 <-> v8i8. The same gap existed in IntRegs for f32 <-> v2i16 and f32 <-> v4i8. Without a tableGen pattern for "f64 = bitcast v2i32" node, the instruction selector crashed with: LLVM ERROR: Cannot select: t26: f64 = bitcast t6 t6: v2i32,ch = CopyFromReg t0, Register:v2i32 %2 Fix by adding the five missing NopCast_pat entries. Fixes: llvm#195495 (cherry picked from commit c005f73)
The BPF backend has no instruction-selection pattern for
`ISD::ATOMIC_FENCE`, so LLVM IR containing a fence instruction crashes
with `Cannot select: AtomicFence...`.
**Rust code snippet**
```
#[unsafe(no_mangle)]
pub fn entrypoint(_input: *mut u8) -> u64 {
core::sync::atomic::compiler_fence(core::sync::atomic::Ordering::SeqCst);
0
}
```
**LLVM IR**
```
; ModuleID = 'linked_module'
source_filename = "linked_module"
target datalayout = "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128"
target triple = "bpfel"
; Function Attrs: mustprogress nofree norecurse nosync nounwind willreturn
define dso_local noundef i64 @entrypoint(ptr noundef readnone captures(none) %0) unnamed_addr #0 {
fence syncscope("singlethread") seq_cst
ret i64 0
}
attributes #0 = { mustprogress nofree norecurse nosync nounwind willreturn "target-cpu"="generic" }
!llvm.ident = !{!0}
!0 = !{!"rustc version 1.97.0-nightly (f53b654a8 2026-04-30)"}
```
**Error**
```
LLVM ERROR: Cannot select: 0x7fcf7701a1c0: ch = AtomicFence 0x7fcf75718df8, TargetConstant:i64<7>, TargetConstant:i64<0>
In function: entrypoint
Stack dump:
0. Running pass 'Function Pass Manager' on module 'linked_module'.
1. Running pass 'BPF DAG->DAG Pattern Instruction Selection' on function '@entrypoint'
```
-----
**Fix**
This patch lowers single-thread (compiler) fences to `ISD::MEMBARRIER`
(no-op) and produces an error for cross-thread (runtime) fences.
On the "main" branch, Symbol no longer has the `used` member which was moved in PR llvm#190117 (commit 6a87416). Therefore, when the cherry pick from PR llvm#198129 (commit 905a88b) was merged to the "release/22.x" branch, the initialization of `used` was lost.
foldToMaskedStore (added in llvm@1c0ac80) rewrites store(vselect(cond, x, load(ptr)), ptr) -> masked_store(x, ptr, cond) passing the vselect condition straight through as the store mask. A masked store follows the IR convention of a vXi1 mask, but the condition can be a wider boolean vector. On AVX512F targets without VLX, a maxnum/minnum store-back lowers the NaN test with a legacy packed (CMPP) comparison whose result is a vXi32/vXi64 vector, so the masked store is created with a wide mask and LowerMSTORE asserts: Assertion `Mask.getSimpleValueType().getScalarType() == MVT::i1 && "Unexpected mask type"' failed. When the matching vXi1 type is legal, narrow the mask to it before building the masked store. Targets where vXi1 is illegal (e.g. AVX/AVX2) keep the wide mask and continue to lower it as a blend/vmaskmov, and targets whose vselect condition is already vXi1 (e.g. AArch64 SVE, RISC-V RVV) are unaffected. This fixes the crash at the source and lets the X86 LowerMSTORE keep its invariant of only ever seeing a vXi1 mask (no target-specific workaround). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> (cherry picked from commit e6bd788)
…llFramePseudoInstr` (llvm#195456) [ Upstream commit 589faed ] Revert `bltu` in probing loops to `blt` because commit f162be2 isn't applied on release/22.x yet. Link: llvm#192485 ("[RISCV] Use unsigned comparison for stack clash probing loop") --- This PR adds a call to `inlineStackProbe` immediately after `allocateStack` in `eliminateCallFramePseudoInstr`. This allows code generation for stack probe pseudoinstructions in non-entry BBs. Fixes llvm#195454.
Some VPlan transforms, like vectorizing fmin without fast-math, introduce AnyOfs, which have costs assigned in the VPlan-based cost model, but not the legacy cost model. Account for their cost like done for other similar VPInstrctions, like EVL. Fixes llvm#185867. (cherry picked from commit 475cc4f)
Fixes llvm#201780 Per https://www.w3.org/TR/wasm-core-2/#-hrefop-narrowmathrmnarrowmathsfu_m-n-i the saturation is signed, the truncation is unsigned. (cherry picked from commit c19fa5b)
…optional<T>` (llvm#194446) Resolves llvm#194415 - A constructor specifically meant for `optional<T&>` was left enabled for `optional<T>` - Fix it, and add a test to check for regression. - This patch also corrects the constraints for `optional(optional<U>&)` and `optional(const optional<U>&)` , as they were incorrectly disallowing [valid conversions](https://godbolt.org/z/1r5Ea7z5M) - Also, correct the `noexcept` specification. - Add tests for both corrections. (cherry picked from commit 239189c)
Author
|
Accidental typo with the branch naming - I meant LLVM 22.1.8 in my branch name. 😞 |
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
12 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.
This change updates LLVM to 22.1.8. The newest version of LLVM 22 contains the following fix: llvm@475cc4f
This change is required to fix the following assertion when building Rust on PPC64 AIX: