Update LLVM to 22.1.7#196
Merged
cuviper merged 17 commits intoJun 12, 2026
Merged
Conversation
…86728) Windows EH requires exception objects allocated on stack. But there is no reliable way to identify them. CoroSplit employs a best-effort algorithm to determine whether allocas persist on the stack or the frame, which may result in miscompilation when Windows exceptions are used. This patch proposes that we treat allocas used by catchpad as exception objects and never place them on the frame. A verifier check is added to enforce that operands of catchpad are either constants or allocas. Close llvm#143235 Close llvm#153949 Close llvm#182584
…lvm#190732) (llvm#195983) Close llvm#190333 For the test case, the root cause of the problem is, the compiler thought the declaration of `operator &&` in consumer.cpp may change the meaning of '&&' in the requrie clause of `F::operator()`. But it doesn't make sense. Here we skip profiling the callee to solve the problem. Note that we've already record the kind of the operator. So '&&' and '||' won't be confused. --- See the discussion in llvm#194283 For the new found pattern that we may have other binary operator (e.g., operator +) in the require clause, e.g., ```C++ template <typename T, typename U> requires requires(T t, U u) { t + u; } void operator()(T, U) {} ``` This is a new problem and we need to solve it in other PR. (cherry picked from commit 2751c7e)
…et (llvm#198129) `initSectionsAndLocalSyms` and `makeDefined` memset the storage to zero and then placement-new a Symbol-derived object into it. Placement new begins a new object's lifetime. The standard does not seem to guarantee the memset bytes carry into members the constructor leaves uninitialized. lld built by GCC 16 can make Valgrind report reads of Symbol::flags (via getSymSectionIndex during finalizeSections) as uses of uninitialized values (ClangBuiltLinux/linux#2162). This patch reinstates the per-field initialization that commit 7787427 ("[ELF] Avoid redundant assignment to Symbol fields. NFC") had replaced with a bulk memset. (cherry picked from commit 905a88b)
…uctions generation" (llvm#198306) Fixes llvm#198254
Summary: This check exists to encode the policy that this is only intended to be built with a just-built compiler. In practice it's a little too strict and breaks pretty much every six months when the version bumps or when people try to build a separate patch. Just demote to a warning. (cherry picked from commit 13da33e)
Ensure that use of the GNU driver does not change the library name on Windows. We would check the build tools being MSVC rather than targeting Windows to select the output name. (cherry picked from commit 687e66c)
…a and small constants (llvm#196801) The combine introduced in 55aff64 lowers scalar i128 compares into vector compares by reissuing the original loads as v16i8 loads. However, the combine was reusing the original MachineMemOperand without modification. If the original i128 load carries !range metadata, the MMO encodes that range using i128 values. Reusing this MMO for a v16i8 load is incorrect as range metadata is only valid for integer scalar types and its bitwidth must match the memory VT. This patch fixes this by creating a new MachineMemOperand for the vector vector load. Additionally, we restrict the combine for constant operands to avoid cases that are better handled by scalar lowering. Small constants (fit within 16 bits) are excluded to prevent generating suboptimal vector compares. (cherry picked from commit 1907b58)
(cherry picked from commit 0e3a96d)
…SHUFB) on VBMI targets (llvm#182852) Minor improvement for llvm#137422 (cherry picked from commit 8f5880d)
…ute call on VBMI targets (llvm#183109) Shuffle combining fails to fold the inner shuffles first, but luckily the LanePermuteAnd* methods are enough if we have VPERMB as a fallback Fixes llvm#137422 (cherry picked from commit 1b9fea0)
… INT_TO_FP (llvm#198705) When lowering an i64 load in LowerINT_TO_FP, we were forwarding the original !range metadata to a new f64 load. This is invalid because the metadata no longer matches the value type/semantics, and can trigger assertions when lowering i64 to fp (double or float) conversions. This patch fixes this by passing a nullptr for the Ranges operand when calling getLoad() and adds extra test cases to cover signed/unsigned i64 to f32/f64 conversions and to ensure they do not assert when the !range metadata is present. The assertion this patch attempts to fix is: ``` Assertion failed: (!MMO->getRanges() || (mdconst::extract<ConstantInt>(MMO->getRanges()->getOperand(0)) ->getBitWidth() == MemVT.getScalarSizeInBits() && MemVT.isInteger())) && "Range metadata and load type must match!" ``` This assert was originally seen when building Rust on AIX. (cherry picked from commit 78f5f77)
…#200060) Just like for PAGEBASE_REL21, the immediate in SECREL_HIGH12A is the byte offset, not a page offset. The byte level offset is added to the symbol offset, which only then after that gets shifted right by 12. This makes the handling of this immediate consistent with what MS link.exe does. The existing testcase had a zero immediate in the instruction for this relocation. This makes it clear that immediate offsets with SECREL_HIGH12A do work fine, where the byte level offsets end up carrying over to the upper bits. (cherry picked from commit 5c95f6a)
… element (llvm#199703) According to [associative.reqmts] `extract(k)` returns the _first_ element in the container with key equivalent to k. (cherry picked from commit 72871f6)
When combineCCMask is called on a TM node with two constant operands, and all of the bits in the mask are active, the existing APInt bit access goes off the overall length of the integer by one. This commit fixes that by using the index value of the leftmost active bit, rather than the number of active bits. (cherry picked from commit 78eca55)
…lvm#200322) WebAssemblyLateEHPrepare::addCatchRefsAndThrowRefs was using Catch->getIterator()->getNextNode() to find the insertion position after the CATCH (or CATCH_ALL) instruction in an EH pad. If the CATCH/CATCH_ALL instruction is the last instruction in the basic block, getNextNode() returns nullptr, which causees a crash when passed to BuildMI. This patch fixes it by using std::next(Catch->getIterator()) which returns MBB.end() if the catch is the last instruction, and the overload of BuildMI that takes an iterator correctly handles BB.end(). Fixes llvm#197077 Assisted-By: Gemini (cherry picked from commit dc40fcc)
Member
|
I took the liberty of fixing the title and description to 22, but I can't do anything about your branch name. 😉 This looks good, but I'll wait for the CI check before merging. |
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
15 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.
LLVM 22.1.7 contains fixes for the following PowerPC specific issues produced by Rust:
These issues are causing crashes in the
powerpc64le-unknown-linux-gnunightly build.