Update 2026 04 16 - #28
Merged
Merged
Conversation
Supported Ops: `and`, `or`, `xor`
Supported Ops: `fmin` and `fmax`
Supported Ops: `fadd` and `fsub`
…191804) OpenCL any()/all() builtins receive integer vectors, but OpAny/OpAll require boolean vector inputs per the SPIR-V spec related to llvm#190736
…m#192214) LinkGraphLinkingLayer and ObjectLinkingLayer will start requiring a jitlink::JITLinkMemoryManager argument in an upcoming commit. In preparation for that, this patch threads a MemMgr argument through the LLJITBuilder::ObjectLinkingLayerCreator factory type. Note: This patch does not thread the argument through the C API (LLVMOrcLLJITBuilderObjectLinkingLayerCreatorFunction) yet so as to not break compatibility. All current users of the C API construct RuntimeDyld instances, which would have to ignore this argument anyway. If we don't update the LLVMOrcLLJITBuilderObjectLinkingLayerCreatorFunction type before RuntimeDyld is removed then that will be a good time to update it, since all existing users were going to have to rewrite their code anyway.
…vm#190002) The 32-bit and 64-bit branch of the code has the same pattern of using `__builtin_bswapXX` when available (before trying to use `_byteswap_XXXXX`). But the 16-bit branch doesn't do this (it only tries to use the latter). It seems `__builtin_bswap16` is a thing (see [doc](https://gcc.gnu.org/onlinedocs/gcc/Byte-Swapping-Builtins.html)), so I wonder if we just forgot to use it in the 16-bit branch. Adding it and hope it helps (i.e. faster than the default shift-and-or approach).
…VERSE_ITERATION (llvm#192087) AllocaOp::destructure iterated over usedIndices (SmallPtrSet) whose order depends on pointer values, causing allocas for destructured subslots to be emitted in a non-deterministic order when LLVM_REVERSE_ITERATION is enabled. Sort indices ascending by integer value before creating allocas to guarantee a stable output order. Update four test cases in sroa-intrinsics.mlir whose CHECK patterns relied on the old non-deterministic ordering. Assisted-by: Claude Code Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
This patch fixes an issue in the MLIR bytecode reader where use-lists were incorrectly reconstructed when they had permutations that are not own inverse. Fixed the use-list reconstruction mapping logic in to correctly restore the stable memory order of uses, both full shuffle and index-pair encodings consistently. Gemini/LLM assisted.
) The idea for this commit is to show how `formatv()` format strings need to be constructed in order to achieve the same output as with `format()`. This relates to llvm#35980. Co-authored-by: Sergei Barannikov <barannikov88@gmail.com>
…rs (llvm#192218) Split convertFuncOpToLLVMFuncOp into focused helper functions for signature conversion, llvm.func creation, attribute propagation, and C-wrapper handling. This reduces nesting and improves readability while preserving existing lowering behavior.
[gn build] Port c9f09d3
[gn build] Port c365068
[gn build] Port 5d7a143
This ended up being a fairly common pattern: a copy operation on a structure with an array inside of it. Classic-Codegen has a few different ways of initializing/copying an array, of which this is one. However, this patch uses the array-init functionality we already have. This ends up being a bit verbose, but will make sure we don't have to worry about separately handling throwing types/etc for this AST node. Additionally, this has to handle the ArrayInitIndexExpr, but that is as simple as making sure we properly cache the index value when doing our initialization.
Similar to the previous Expr-change that I made, this does the same with pointers-to-arrays (and other types). The new implementation is effectively a copy/paste of the classic-codegen, so it maintains our current invariants/assumptions about changes via emitLoadOfLValue.
This ends up being pretty much copy/paste from classic-codegen, so it doesn't have anything particularly novel. I DID switch the return type of the helper function to be a variant instead of a manually-put-together pair, and switched to range-for, but otherwise it should be identical. However, I was uanble to reproduce a few of the branches, so NYIs were left in place until we can figure them out. At least some of them are going to be for RValue versions.
… for unranked->ranked cast (llvm#189249) When one-shot-bufferize with bufferize-function-boundaries is used and a function returns a ranked tensor that is produced by casting from an unranked intermediate (e.g. a call to a function returning tensor<*xf32>), the foldMemRefCasts post-processing step incorrectly unpacked the memref.cast from unranked to ranked memref, downgrading the function return type to the unranked memref type and using the unranked value as the return operand. The fix is in unpackCast(): do not unpack a cast whose source is an unranked memref and whose result is a ranked memref, since doing so would lose type specificity. Fixes llvm#176739 Assisted-by: Claude Code
…StrengthReduction (llvm#188955) PowIStrengthReduction::matchAndRewrite was creating the `one` constant (using complex::ConstantOp::create for complex::PowiOp) before the threshold check that guards whether the rewrite is profitable. When the exponent exceeds the threshold, the pattern returned failure() after IR was already modified, violating MLIR_ENABLE_EXPENSIVE_PATTERN_API_CHECKS. Fix: reorder so the abs(exponent) computation and threshold check occur before any IR creation. Assisted-by: Claude Code Fix a failure present with MLIR_ENABLE_EXPENSIVE_PATTERN_API_CHECKS=ON.
…mbol internal error (llvm#189360) When a statement function shadows a host-associated internal procedure name, HandleStmtFunction creates a local symbol but leaves name.symbol pointing to the host SubprogramNameDetails. Because of that stale pointer, AnalyzeStmtFunctionStmt exits early (it expects SubprogramDetails), so the RHS is never resolved and flang emits a false `internal error: "Internal: no symbol found".` Clearing name.symbol after creating the local shadow symbol lets it re-resolve correctly and fixes the issue. --------- Co-authored-by: Chandra Ghale <ghale@pe34genoa.hpc.amslabs.hpecorp.net>
…ed value type (NFC) (llvm#192258) This fixes the build on some platform where the inferred count differs.
This relates to llvm#35980.
…lvm#192180) Before this PR, `FactsGenerator` handled cast nodes with `VisitImplicitCastExpr` (`CastKind` switch case) and `VisitCXXFunctionalCastExpr` (handle`gsl::Pointer` types). Other explicit casts (`CStyleCastExpr`, `CXXStaticCastExpr`, ...) had no handler, so origin was silently dropped. This is the root cause of llvm#190912: the dangle in `a = StringView(s);` is missed even though the equivalent `StringView tmp(s); a = tmp;` is reported. The policy for "does this cast propagate origin?" is a function of `CastKind`, independent of whether the cast is implicit or explicit. This PR replaces `VisitImplicitCastExpr` with a generic `VisitCastExpr`. `VisitCXXFunctionalCastExpr` is retained only to preserve the `handleTestPoint` logic, then delegates to `VisitCastExpr`. This mirrors `clang/lib/AST/ExprConstant.cpp`, where each evaluator implements only `VisitCastExpr` and switches on `CastKind`; the few ExprClass-specific overrides (e.g., `VisitCXXDynamicCastExpr`) exist solely to attach constexpr-validity diagnostics before delegating back. Scope: the set of `CastKind`s that propagate origin is unchanged. Fixes: llvm#190912
…d functions (llvm#191817) co_await/co_yield expressions are not allowed in default arguments. We were checking they do not appear outside of function contexts, which include default arguments of the corresponding function, but it missed default arguments of functions declared in the body of another functions. Because parsing default argument isn't done in a dedicated scope, we do additional checks in `ActOnParamDefaultArgument`. Because the checks is done in two places, we cannot introduce a more precise diagnostic. It might be worth considering a parse scope for default arguments in the future. Fixes llvm#98923
…192400) If the lower 2 bytes are the same and are the only bytes used we can use pli.b instead of lui+addi.
…2485) The stack clash probing loop generated in `emitDynamicProbedAlloc` used a signed comparison (`RISCV::COND_BLT`) to determine when the allocation target had been reached. In 32-bit mode, memory addresses above `0x80000000` have the sign bit set. If the stack pointer lands in this region, treating the addresses as signed integers causes the comparison logic to fail. This patch changes the condition code to `RISCV::COND_BLTU` (Branch if Less Than Unsigned), which generates an unsigned comparison. This ensures that addresses are treated correctly as unsigned quantities on all targets. On 64-bit systems, this change has no practical effect on valid user-space addresses because they do not use the sign bit (being restricted to the lower half of the address space). However, using unsigned comparison is the correct behavior for pointer arithmetic and bounds checks. Link: llvm#192355
llvm#190461) The `code-block` directives in MemorySanitizer.rst and ThreadSanitizer.rst were missing a leading period (`. code-block` instead of `.. code-block`). This syntax error caused Sphinx to fail to recognize the directives, resulting in the the subsequent C code being rendered as plain text rather than a syntax-highlighted block. The currently broken rendering on the official docs can be seen [here](https://clang.llvm.org/docs/MemorySanitizer.html#interaction-of-inlining-with-disabling-sanitizer-instrumentation) and [here](https://clang.llvm.org/docs/ThreadSanitizer.html#interaction-of-inlining-with-disabling-sanitizer-instrumentation). Fixed the typos to ensure proper HTML rendering.
Tests uses 'touch -a' which is known to fail on macOS.
…llvm#192501) Any hoisting across `acc.compute_region` needs to be wired through block arguments as the region is `IsolatedFromAbove`. Thus update `ACCImplicitDeclare` to do so by using new API `wireHoistedValueThroughIns` which handles the value wiring after hoisting.
When creating an outline function for device code we're not setting the right calling convention when the target is SPIRV. This results in the calls to the function to be removed by the InstCombine pass as it thinks is not callable.
This pulls in this fix bazel-contrib/rules_python#3420
Ensure that `Value`s are used in the `ValueRange` construction to avoid failure: `error: call of overloaded ValueRange(mlir::acc::ParWidthOp&) is ambiguous`
…lvm#192525) Follow-up to llvm#192289. Swap the remaining `std::unordered_set`/ `std::unordered_map` containers in `Instrumentation.cpp` for `DenseSet`/ `DenseMap`: the `BBToSkip` param and `Visited` local in `hasAArch64ExclusiveMemop`, and `BBToSkip`, `BBToID`, `VisitedSet` in `instrumentFunction`. Drop the now-unused `<unordered_set>` include. The swap removes per-element heap allocations on the hot path, stops inserting empty buckets on probes where a miss is possible, and replaces hashed-bucket traversal over node-based storage with lookups over inline `DenseMap` storage. `BBToID` reads keep `operator[]` since the map is pre-populated for every basic block of the function, so no default-construct path is ever taken. NFC. Measured on `llvm-bolt -instrument` against a relocations-linked clang-23: -1.3% instrumentation-pass wall time, peak RSS unchanged (dominated by instrumentation output size).
Before the patch, even with the same synthetic function name, they counted as different functions, because the file name was different. This makes it easier to analyze data in performance profiles. `pprof -lines -top <somefile> | grep __ubsan_check_pointer_overflow` Before: ``` 60368049443 6.26% 6.26% 60383492016 6.26% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/TSVC/tsc.inc (inline) 43746146224 4.53% 10.79% 43763767409 4.54% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/SciMark2-C/SparseCompRow.c (inline) 11670846196 1.21% 26.03% 11673592781 1.21% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/ASC_Sequoia/AMGmk/csr_matvec.c (inline) 7948730683 0.82% 29.07% 7949496154 0.82% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/ASC_Sequoia/IRSmk/rmatmult3.c (inline) 7442972883 0.77% 30.62% 7447647795 0.77% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/mafft/Galign11.c (inline) 7181873035 0.74% 32.88% 7182846509 0.74% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/ASC_Sequoia/AMGmk/relax.c (inline) 7086681860 0.73% 33.61% 7086681860 0.73% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/SciMark2-C/FFT.c (inline) 6634628163 0.69% 35.03% 6644529197 0.69% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/Olden/em3d/make_graph.c (inline) 5778832834 0.6% 37.55% 5778832835 0.6% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/SciMark2-C/LU.c (inline) 5707159214 0.59% 38.14% 5707159214 0.59% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/SciMark2-C/Random.c (inline) 5265117200 0.55% 40.99% 5266753453 0.55% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/Trimaran/netbench-url/search.c (inline) ``` After: ``` 143372006423 14.76% 14.76% 143426398982 14.76% __ubsan_check_pointer_overflow sanitizer/ubsan_interface.h (inline) 16972753760 1.75% 31.03% 16979483803 1.75% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/TSVC/tsc.inc (inline) 14296973786 1.47% 32.50% 14297951231 1.47% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/SciMark2-C/SparseCompRow.c (inline) 7857020738 0.81% 36.93% 7857966628 0.81% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/ASC_Sequoia/AMGmk/csr_matvec.c (inline) 6956467376 0.72% 41.47% 6958074907 0.72% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/Olden/em3d/make_graph.c (inline) 5502783427 0.57% 45.07% 5502783429 0.57% __ubsan_check_pointer_overflow test-suite/MultiSource/Benchmarks/SciMark2-C/LU.c (inline) ```
Implemented getcontext and setcontext for x86_64 architecture in LLVM libc. These functions use inline assembly with naked attributes to capture and restore the exact register state. Added: * src/ucontext/getcontext.h and setcontext.h * src/ucontext/x86_64/getcontext.cpp and setcontext.cpp * Hermetic integration test for register preservation. * Unit tests for basic functionality and signal mask preservation. Updated entrypoints for x86_64 Linux.
Related to llvm#185382 CIR lowering for pairwise-minimum intrinsics (https://arm-software.github.io/acle/neon_intrinsics/advsimd.html#pairwise-minimum) Port tests from `clang/test/CodeGen/AArch64/neon_intrinsics.c` to `clang/test/CodeGen/AArch64/neon/intrinsics.c`
…llvm#192532) Reverts llvm#192073 Reason for revert: This change caused build failures on Windows when compiling libcxx.
- Add missing "CHECK:" lines to testcases. - Improve checking to be a bit more readable. - Move "rm" testcases to the bottom in anticipation of future refactoring.
closes llvm#125914 Introduce `SupressLambdaBody` `PrintingPolicy` that is used only for constexpr diagnostics. This ensures `--print-ast` still works the same. I also considered other approaches such as modifying the `PrintingPolicy` in the current `AstContext`, but that might cause unexpected changes. Add two tests: 1. To ast-printer-lambda to ensure `--print-ast` works the same. 2. Ensure lambda body is not printed for constexpr diagnostics.
Add nickdesaulniers as an owner for Android libc++ CI
…192164) Add support for invoke/landingpad/resume instructions in the BPF backend so that Rust programs compiled with panic=unwind can run cleanup code (Drop implementations) when bpf_throw fires. Changes: 1. BPFISelLowering: Define exception pointer and selector registers (both R0) so SelectionDAG can lower landingpad instructions. 2. BPFAsmPrinter::emitFunctionBodyEnd: Emit a .bpf_cleanup section with a flat table of (begin, end, landing_pad) triples using R_BPF_64_NODYLD32 relocations. The .bpf_cleanup section layout (12 bytes per entry): u32 begin // start of the invoke region u32 end // end of the invoke region u32 landing_pad // address of the cleanup block The invoke region [begin, end) includes argument setup instructions before the call. The runtime checks begin <= PC < end to find the matching landing pad. Landing pad blocks survive optimization because invoke maintains CFG edges to them throughout codegen, same as every other backend. The standard .gcc_except_table and .eh_frame are also emitted by the existing DwarfCFIException handler; libbpf will ignore them. In runtime: - bpf_throw() is called (from panic handler) - Kernel walks the BPF call stack with arch_bpf_stack_walk() - For each frame, look up current PC in .bpf_cleanup table - If match found: redirect execution to the cleanup function . cleanup function runs Drop impls (bpf_free, rcu_read_unlock, etc.) . calls _Unwind_Resume() which is patched to just 'ret' by the verifier . bpf_throw() pops frame goes to next - If no match: go to next frame Signed-off-by: Alexei Starovoitov <ast@kernel.org> Co-authored-by: Alexei Starovoitov <ast@kernel.org>
…allVector Reviewers: Pull Request: llvm#192540
Add a transform dialect type denoting additional invariants on payload IR usable for pre/post-conditions of a transformation. The invariants are defined as a list of attributes in the type parameter, where the attribute implements the interface for invariant-checking. This allows clients to factor out, explicify and deduplicate precondition verification logic. This required adding support for Transform dialect extensions injecting attributes into the dialects similarly to how they already do this for operations and types. Co-authored-by: Tim Gymnich <tim@gymni.ch> Co-authored-by: Martin Lücke <martin.luecke@amd.com> Assisted-by: Claude Opus 4.3 / Cursor Co-authored-by: Tim Gymnich <tim@gymni.ch> Co-authored-by: Martin Lücke <martin.luecke@amd.com>
…ents (llvm#192513) Semantic was wrongly flagging derived-type components as two device resident object. Update how we collect symbols and count the number of device resident object.
) Fixed llvm#190672. The issue is caused by invalid intermediate IR when `getSCEV()` is called during transformation: the exiting block of `pre-loop` did not re-connect to preheader of the `post-loop`, causing `LI.verify()` unable to correctly recompute another LoopInfo for verification. To fix, reconnect the edge earlier before calling `getSCEV()`. Also moved the DT updates to more appropriate places right after IR control flow has changed. and added a few LI and DT verifications to improve robustness of the pass.
…ominated by root Reviewers: Pull Request: llvm#192556
Requested by Shafik: llvm#188904 (comment)
This fixes b3cbad3. Co-authored-by: Google Bazel Bot <google-bazel-bot@google.com>
This patch handles most of the scaffolding for synthetic variable support that isn't directly tied to functional changes. This patch will be used by one following patch that actually modifies the lldb_private::StackFrame API to allow us to fetch synthetic variables. There were a couple important/interesting decisions made in this patch that should be noted: - Any value type may be synthetic, which is why it's a mask applied over the top of another value type. - When printing frame variables with `fr v`, default to showing synthetic variables. This new value type mask makes some of the ValueType handling more interesting, but since nothing generates objects with this mask until the next patch, we can land the concept in this patch in some amount of isolation.
Previously, these LL instructions were expanded to software emulation calls, causing performance overhead in benchmarks. By making these operations legal and providing patterns, we can generate efficient code using the new instructions.
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
20 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.
New rust release means pull in changes