[pull] main from llvm:main - #1718
Merged
Merged
Conversation
#212806) In a gpu.func, allow allocating local arrays of gpu.mma_matrix, e.g. `memref.alloca() : memref<Nx!gpu.mma_matrix<HxW, ...>`. Extend the SPIRV conversion to convert such memrefs to `%ARR = spirv.Variable: spv.ptr<spv.array<N x coopmatrix>, Function>`, which can be conveniently indexed with `spirv.AccessChain %ARR[i]`. This enables arrays of CoopMMA matrices both at the `gpu` and `spirv` levels. Signed-off-by: Fabrizio Indirli <fabrizio.indirli@arm.com>
…red/UAV memory (#212663) Compiling HLSL `InterlockedOr`/`InterlockedAdd`/`InterlockedXor` against `groupshared` (or UAV) destinations through the clang HLSL -> SPIR-V path produced SPIR-V that `spirv-val` rejects for Vulkan. Illegal OpCapability Linkage: groupshared variables are emitted as `external hidden addrspace(3)` (Workgroup) declarations. `getSpirvLinkageTypeFor` gave any non-interface declaration `Import` linkage, which adds a `LinkageAttributes` decoration and forces `OpCapability` Linkage, which is illegal in a Vulkan shader. Fix: in a shader environment (no linker), Workgroup/Private declarations get no linkage. Fixes: llvm/offload-test-suite#1404 Assisted by: Github Copilot
…#213451) Load the checked-in core `linux-aarch64-pac.core` from `lldb/test/API/functionalities/postmortem/elf-core/` with its binary and ask for a `char16_t *` summary at the start of `.text`: ``` (lldb) settings set target.max-string-summary-length 8 (lldb) expression -l c++ -- (char16_t *)0x400140 (char16_t *) $0 = 0x0000000000400140 unable to read data (lldb) memory read -s1 -c16 0x400140 0x00400140: 3f 23 03 d5 ff 83 00 d1 fd 7b 01 a9 fd 43 00 91 ?#.......{...C.. ``` `memory read` prints the very bytes the summary just claimed it could not read. Both go through `Target::ReadMemory()`, which reuses a single `Status &error` for the process read and for the file-cache fallback at the end of the function, and `Target::ReadMemoryFromFileCache()` only ever sets that `Status`, it never clears it. So when the process read fails outright and the fallback then satisfies the whole request, `ReadMemory()` returns the correct bytes with the failed process read's message still in `error`. `memory read` only compares the returned count against the requested length, so it is fine, but `Target::ReadStringFromMemory()`, which `StringPrinter` uses for UTF-16 and UTF-32, gives up on `error.Fail()`, and `SBTarget::ReadMemory()` hands the same stale `Status` to any scripted client. Core files reach this routinely. `ProcessMachCore` and `ProcessElfCore` both report `IsAlive()`, so the process read is attempted and fails for a page that was not dumped into the core, and the fallback then serves that page out of the binary on disk. In this core the `PT_LOAD` covering `.text` has `p_filesz == 0`. Clear `error` before the fallback so the bytes and the `Status` describe the same read, and let the fallback report a short read itself: `ReadMemoryFromFileCache()` sets an error when it reads nothing, but not when `ObjectFile::ReadSectionData()` clamps a request that overruns the section. A short read is only a failure when a live read already produced nothing, hence the `ProcessIsValid()` guard: without it a target with no process, say one made from a `.o` file where the fallback is the only reader, fails legitimate short reads. `Target::ReadInstructions()` asks for `GetMaximumOpcodeByteSize() * count` bytes and bails on `error.Fail()`, so it could no longer disassemble the tail of a section. The one change for callers is that a full read served by the fallback now reports success. (The session lowers `target.max-string-summary-length` to keep the request inside this binary's small `.text`; a larger request really is a short read and still reports an error.) ``` (lldb) expression -l c++ -- (char16_t *)0x400140 (char16_t *) $0 = 0x0000000000400140 u"⌿픃菿턀篽꤁䏽" ``` A unit test in `lldb/unittests/Target/MemoryTest.cpp` drives the fallback with a process that cannot produce a byte, checking that a full read succeeds and a short one does not, and `test_read_only_cstring` in `TestLinuxCore.py` gains an `SBTarget::ReadMemory()` check on the core it already loads.
The FIR optimizer extension points (FIROptEarly, FIRInliner, FIROptLast)
all
run after HLFIR has been lowered to FIR, so the HLFIR intrinsic
operations
(hlfir.sum, hlfir.matmul, ...) are gone by the time they run.
Transformations
that need to see those operations have nowhere to attach.
Add two extension points to createHLFIRToFIRPassPipeline:
* HLFIROptEarly, at the start of the pipeline, before any HLFIR
simplification or inlining.
* HLFIROptLast, just before createLowerHLFIRIntrinsics.
Drivers register passes through registerHLFIROptEarlyEPCallbacks and
registerHLFIROptLastEPCallbacks on MLIRToLLVMPassPipelineConfig. The
invoke
methods are const so they can be called on the const config the HLFIR
pipeline
receives.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…13933) SparseConstantPropagation restored the operation only when `fold` did not return any fold results. But a folder can mutate the op in place and still return out-of-place results or fail, e.g. `vector.extract` folds constant dynamic positions into static ones before attempting further folds. The constants fed to `fold` are speculative lattice values, so the mutation bakes a possibly-wrong constant into the IR. SCCP would permanently replace a loop-carried dynamic index with its first lattice value for example. Fix: Restore the original operands and attributes after every fold call, regardless of its outcome. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
…3668) When the loop vectoriser calls addDiffRuntimeChecks it goes to a lot of effort to avoid generating multiple copies of the VF calculation by caching the first instance. However, now that ScalarEvolution has a getElementCount function we can simplify this code significantly, especially since SCEVs are also implicitly cached. Make greater use of SCEVs for computation also has the side-effect of improving code quality in the memory check blocks, which is important when estimating costs of these checks. You can see this in some tests like LoopVectorize/AArch64/sve-runtime-check-size-based-threshold.ll where the threshold for entering the loop has been relaxed. Ideally, all computation in addDiffRuntimeChecks should be done using SCEV because there are presumably other folds that can be applied to the comparisons. However, I'd keep things simple in this PR and deal with that in a follow-on PR.
Newline at the end of a file is a standard convention in the `libc++` codebase, but it's not enforced via `clang-format`. Current PR enables this check: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#insertnewlineateof
This fixes 13034b3 (#212194). Buildkite error link: https://buildkite.com/llvm-project/upstream-bazel/builds?commit=13034b3a22058f6bc49553268b051bdc6aa4efa1 Co-authored-by: Google Bazel Bot <google-bazel-bot@google.com>
Update the expected codegen as-needed.
The added test ended up being out-of-memory (OOM) killed, because GVN computed the same equality facts through exponentially many paths. Co-authored-by: Katy Thackray <katy.thackray2@arm.com>
…VECREDUCE_AND/OR/XOR support (#199544) The middle-end (SLP, VectorCombine and InstCombine) recognition and handling of vector logic reduction patterns is sufficient now, so the backend can work with ISD::VECREDUCE_AND/OR/XOR nodes directly.
When a function type directive appears after a symbol definition, use the ARM or Thumb state in which the label was emitted instead of the active state at the type directive. This can happen when an end-of-function macro emits .type alongside .size to avoid repeating both directives. If the ARM/Thumb state at the macro differs from the state in which the function label was defined, the late .type directive would otherwise use the wrong state. Record labels emitted in Thumb state and add coverage for late type directives in both directions. This matches GNU assembler behavior. Developed with AI assistance; reviewed and tested manually. Fixes #211376
…ixes (#214164) These got lost in a merge at some point
It was always a bit weird that these were the only functions under __math/ which were not in the __math namespace and were not in the global namespace. This also led to a workaround in the C++20 modules testing. Instead, move math special functions under __cmath/, which will contain APIs that are part of `<cmath>` but not `<math.h>`.
…arwin (#213748) It should be possible to produce a per-target include directory even on Apple platforms. That's not the way we ship the library by default, but there's no reason not to allow selecting that configuration.
…214020) This makes all benchmark-related utilities consistently rely on a virtual environment containing libcxx/utils/requirements.txt instead of some scripts installing their dependencies explicitly, which is duplicate work in most cases.
After splitting up <__locale> into sub-headers, we can now use the granular includes from the rest of the code and remove <__locale>.
…#213634) Extends the static memory planner (#209106) to handle two scf.if patterns that previously errored or were silently missed. **What changed** Replaced the hand-rolled `BufferViewFlowOpInterface` DFS with the shared `BufferViewFlowAnalysis`. This covers arith.select, scf.if/for results, cf branches, and view ops in one place — no new interface needed. Two new cases are handled: 1. Alloc flows through an `scf.if` result; `dealloc` is on that result. `resolve()` finds the alias and picks up the dealloc. 2. Alloc is in the entry block; `dealloc` is inside an `scf.if` body. `findAncestorOpInBlock` anchors the lifetime to the enclosing `scf.if` — conservative but correct. A reverse-alias guard (`resolveReverse`) handles the unsafe case where a dealloc may also free a *nested* alloc not managed by the arena. That alloc is conservatively skipped rather than miscompiled. **Test changes** - Tests 11–14 added: scf.if nested dealloc, scf.if result alias, nested alloc skip, shared-dealloc conservative skip. - Error test 2 updated: scf.if-nested dealloc is now valid, replaced with a `cf.br` sibling-block escaping case.
As part of this test, we check the capacity available on the filesystem and compare it against an expected capacity. However, on some filesystems, the capacity is actually computed and may change depending on filesystem usage. This creates a race condition since the disk may be filling up (by e.g. other running tests) between the two calls. For that same reason, other checks for the available size were using an approximate equality up to a delta. Use the same approach for the capacity here.
BranchProbabilityAnalysis uses CycleInfo, but BFI doesn't, causing the somewhat redundant construction of an extra LoopInfo. Avoid this by porting BFI to use CycleInfo. This requires a minor change to the BFI implementation to avoid incorrect results with irreducible loops that show up as nested but don't show up as nested loops -- such cycle entries are skipped now. (Such an entry heads a loop the cycle absorbed, and which entry keeps a nested cycle of its own depends on the order the search found the entries in.) @crossloops reaches c1 and c2 alike, yet only c1 heads a nested cycle, so seeding it gave c1 a loop scale c2 never got and their frequencies came out 0.68571 and 1.1429 where the test derives 1.0 for both. Represent none of those entries and leave the region to computeIrreducibleMass, which decomposes it from the reverse postorder as it does when LoopInfo finds no natural loop there. Passing the parent down also fixes the loop nest: &Loops.back() is whichever loop was created last, not the enclosing one, and every crash on this branch came from that. Co-authored-by: Fangrui Song <i@maskray.me>
…ath> (#213084) Some of `<random>` functionality depends on the system's `math.h` header instead of `__math/FOO.h`. System's are just undefined symbol to be linked, but the `__math/FOO.h` are implemented with potentially constexpr-friendly builtins. Also, some of the functionality seems to be using `__math::` namespace and some doesn't, seemingly randomly. This PR fixes such inconsistency, avoids using non-constexpr functions from the system's `math.h`, and in turn removes obstacles for P3791 `constexpr <random>`. Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
… allocatable variables (#186765) Fixes - #186743 This patch fixes flang crashes and invalid IR when using user-defined reductions (declare reduction) with allocatable variables (scalars, 1D, 2D arrays). Previously, flang would either crash during FIR lowering or emit bad LLVM IR (type mismatch in _FortranAAssign and llvm.memcpy). The fix ensures that declare_reduction ops are created for the correct boxed type when the reduction variable is allocatable or pointer. This works for both integer and character types.
…s in TableGen (#192802) Add support for folding logical operations with 8-bit immediates into memory operands for i16, i32, and i64 types to target LSB. It handles both 12-bit (NI, OI, XI) and 20-bit signed (NIY, OIY, XIY) displacements. --------- Co-authored-by: anoopkg6 <anoopkg6@github.com>
Soffset can come in as a pointer (converted to int); the common case is a constant addrspace(6) pointer.
…x86-64-v4 test coverage (#214180)
…iltins (#214142) buildConstantInt truncated the raw constant to its low bit instead of testing it against zero, silently miscompiling calls like work_group_all(4) to false
…211529) Follow-up to #208491. ### What this does 1. In `getArithmeticInstrCost`, before the vector paths, price a scalar integer div/rem by a constant as its real sequence: **5** for `UDIV`/`SDIV`, **6** for `UREM`/`SREM` (the extra multiply-back and subtract), **+2** for the `CodeSize`/`SizeAndLatency` cost kinds. Power-of-two divisors lower to a shift and are left to the generic handling. 2. With the scalar lane priced correctly, the `9` workaround is no longer needed, so **restore the honest `vXi64` divide/remainder vector costs** that #208491 lowered: uniform `15`, non-uniform `19` (signed) / `22` (unsigned). The cost model now reports the sequence it actually emits, and the vector forms still win: by a comfortable margin rather than by one. The value is intentionally divisor-independent: `TTI` does not see the constant, and whether the magic number needs the extra "add" fixup only moves the count by one or two, within the tolerance of a cost label. ### Testing - `Analysis/CostModel/X86/{div,rem}.ll` regenerated: every scalar `udiv`/`sdiv`/`urem`/`srem`-by-constant row moves from `1` to `5`/`6` (larger cost kinds `+2`), and the `vXi64` vector rows move from `9` back to `15`/`19`/`22`. - `Transforms/SLPVectorizer/X86/idiv-by-const.ll` and four SLP tests that carry constant-divisor div/rem (`non-schedulable-user-different-bb`, `reused-extract-scalar-lanes`, `split-node-reused-in-later-vector`, `split-vector-operand-with-reuses`) are regenerated; each still vectorizes. Part of #37771. ### AI Usage Disclosure This PR was prepared with the assistance of Claude Code.
Found this in #214000 when looking through the generated `__init__.py`. [`SBProcessInfo::GetProcessInfoAtIndex`](https://lldb.llvm.org/python_api/lldb.SBProcessInfoList.html#lldb.SBProcessInfoList.GetProcessInfoAtIndex) takes a reference to an info that it fills instead of returning one. So we need to pass that `ProcessInfo` to it.
Follow up to #196960. So that when more types are added, the hierarchy is clear. RegisterType -> RegisterTypeEnum -> RegisterTypeFlags (in future also...) -> RegisterTypeUnion -> RegisterTypeVector Renamed and moved the test file as it will cover all the classes derived from RegisterType.
Previously `ArrayBoundChecker` had a utility function called `getRegionName` that acted as a wrapper around `MemRegion::getDescriptiveName` and provided fallback descriptions like "the heap area" or "the string literal" in cases when there was no exact name and `Memregion::getDescriptiveName` just returned an empty string. As this functionality may be useful for other checkers in the future, this commit moves it to `getDescriptiveName`, which now gains a second optional parameter called `AllowFallback` (which defaults to false). Calling `getDescriptiveName` with `AllowFallback == true` is almost equivalent to the utility function `getRegionName`: the only difference is that `getDescriptiveName` uses `getRawMemorySpace()` to remain independent of the current `State` -- while `getRegionName` took the `Space` (calculated with `Reg->getMemorySpace(State)`) as an argument. This introduces a very minor functional change in `security.ArrayBoundChecker`: if a symbolic region was originally created in the Unknown memory space but later we deduced that it is on the heap, then before this commit it was described as "the heap area" but now it is referred to as "the region". As this is a very rare situation and the new, less specific message is also completely acceptable, I don't think that we need to complicate the code to preserve the old behavior. This commit eliminates the useless variable `VariableName` from `getDescriptiveName`, other technical debt is left unchanged.
Depends on #212115 rdar://183254267 Assisted-By: claude
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )