merge main into amd-staging#3093
Open
z1-cciauto wants to merge 19 commits into
Open
Conversation
This patch removes the llvm_unreachable in addPreISel so that one can implement a CodeGenPassBuilder that works without needing to implement this specific override, which matches the behavior in TargetPassConfig. Reviewers: paperchalice, arsenm, aeubanks Pull Request: llvm#206170
… maps [NFC] (llvm#205184) Several DenseMaps in the WebAssembly backend keyed by pointers were being iterated over, potentially leading to nondeterministic codegen (differing try/delegate nesting, virtual register allocation, or PHI node insertion) due to nondeterministsic pointer values. This patch replaces these DenseMaps with MapVectors to guarantee deterministic iteration order: - UnwindDestToTryRanges in WebAssemblyCFGStackify.cpp - EHPadToUnwindDest in WebAssemblyCFGStackify.cpp - EHPadToRethrows in WebAssemblyLateEHPrepare.cpp - UnwindDestToNewPreds in WebAssemblyLowerEmscriptenEHSjLj.cpp Fixes: llvm#204883 Co-authored-by: Ammar Askar <aaskar@google.com> Assisted-by: Antigravity
Make `@llvm.lifetime.end` poison the object content. This removes the need of special-casing for dead objects in `ExecutorBase::load()`, etc. See also [llvm#204932 (comment)](llvm#204932 (comment)).
…#206138) This reverts the commit 1e2d1bb. ProcessPoolExecutor.shutdown(wait=True) hangs on macOS 14 with Python 3.9: join_executor_internals() calls call_queue.join_thread() before p.join(), but macOS requires the inverse order. The feeder thread cannot drain until worker processes are joined, so join_thread() blocks forever. This is fixed upstream in CPython >= 3.12 but affects all earlier versions on macOS. Reverting to unblock the aarch64-darwin buildbot while a proper fix is worked out. The original changes and context can be found in llvm#202681
--check-prefix=CHECK is completely redundant, so remove it. Change was generated by Gemini, I manually reviewed the entire diff.
…segfault (llvm#204710) Commit 67e571d (llvm#179306) added lldbHost and lldbUtility to `LLDB_DRIVER_LINK_LIBS` A side-effect is that HostInfoBase.cpp, which contains the file-static `g_fields` pointer, is now compiled into both the lldb binary and liblldb.so, giving each its own independent `g_fields`. On ELF platforms this creates an interposition hazard. When `LLDB_ENABLE_DYNAMIC_SCRIPTINTERPRETERS` is set, AddLLDB.cmake switches all LLDB libraries to `CXX_VISIBILITY_PRESET=default` so that the version script can re-export private symbols needed by dynamically loaded plugins. The Python plugin calls `HostInfo::GetShlibDir()` directly, so extract-dynamic-script-interpreter-exports.py adds `HostInfoBase::GetShlibDir` to liblldb.so's exports (global: in the version script). `HostInfoBase::Initialize()` is not called by the plugin and stays local:. At runtime the dynamic linker resolves liblldb.so's PLT entry for `GetShlibDir()` to lldb's copy (ELF interposition: executable symbols win), which holds a never-initialized `g_fields == nullptr`. `Initialize()` was already called, but it ran on liblldb.so's own copy via the version-script-local binding. Dereferencing `nullptr + 0x108` (offset of `m_lldb_so_dir_once`) crashes in `pthread_once`. To fix this, pass `--exclude-libs,ALL` to the lldb executable on ELF platforms. This keeps every archive-contributed symbol (lldbHost, lldbUtility, LLVM libs) out of lldb's `.dynsym`, eliminating the interposition. liblldb.so's PLT for `GetShlibDir()` then finds only liblldb.so's own exported definition, so `Initialize()` and `GetShlibDir()` consistently operate on the same `g_fields`. The issue does not affect Darwin because Mach-O uses a two-level namespace: symbol references in liblldb.dylib are bound to a specific library at link time, so lldb's copy is never a candidate for resolution regardless of visibility. Tested-on: FreeBSD 15.1 arm64, Fedora 44 amd64 Closes: llvm#204643 Assisted-by: Claude Signed-off-by: Minsoo Choo <minsoo@minsoo.io>
I tightened linalg.contract so buffer-style uses cannot produce memref results. This keeps the op consistent with destination-style semantics and turns the bad input into a verifier error instead of letting later rewrites crash. Fixes llvm#205708
Looks like we can handle more of them these days.
…m#206145) llvm#200401 caused various ways to create a `shared_ptr` control block to reject any allocators which required a complete type. This patch allows allocators to again require a complete type.
ProcessorDefs and FeatureInfoDefs store strings together with constant data. Use the compact enum tables to avoid dynamic relocations for the strings.
Closes llvm#104375. LWG3498 was implemented in LLVM 18 together with P0053R7 via 7cc72a0.
…lvm#206212) Explicitly load VectorDialect as a dependent dialect in MathToAPFloatConversionPass to avoid unregistered dialect errors when generating vector ops. Fixes llvm#206093.
This is preliminary work for changing the representation of FeatureKV/SubTypeKV to need less relocations. As a first step, avoid all direct references to these pointers.
…206234) Build failures in C++20 mode due to deleted constructor preventing brace initialization. Reverts llvm#206178
The original runtime verification only multiplied static output dimensions per reassociation group and checked `srcDim % staticProduct` == 0, which failed to catch invalid dynamic dimension values. The new verification uses getMixedOutputShape() to get all output dimensions (static and dynamic), computes their product, and asserts `product == srcDim`. Fixes llvm#205981. Assisted-by: MiMo-V2.5-Pro
…#206234) (llvm#206237) Fix C++20 build by adding an explicit constructor. This also permits making the fields private. This reapplies llvm#206178. This reverts commit e44103c.
…sponding matcher (llvm#200502) A common pattern when dealing with vectors is to iterate over each element and check whether any element satisfies a condition. Introduce `Constant::containsMatchingVectorElement` to generalize this behavior along with a corresponding matcher `m_ContainsMatchingVectorElement` which checks whether any elements match the given subpattern. Remove function `llvm::maskContainsAllOneOrUndef` in favor of using this generalization instead. Co-authored-by: Ramkumar Ramachandra <r@artagnon.com>
ronlieb
approved these changes
Jun 27, 2026
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.
No description provided.