[pull] main from llvm:main - #1728
Merged
Merged
Conversation
…entations (#213331) Add a C API that lets an external library provide a CAS implementation, along with an LLVM-side adapter that exposes such a plugin as an ObjectStore/ActionCache pair. The pieces are: - llvm-c/CAS/PluginAPI_types.h and llvm-c/CAS/PluginAPI_functions.h: the C API that a plugin implements. Versioned via LLCAS_VERSION_{MAJOR,MINOR}; both the client and the plugin exchange their versions so implementations can stay compatible across changes. - lib/CAS/PluginAPI.h and lib/CAS/PluginAPI_functions.def: the table of function pointers resolved from the loaded library. The .def file records whether each symbol is required, so optional functionality (storage size reporting, pruning, validation, file-based store/export) can be omitted by a plugin and is then feature-detected at runtime. - lib/CAS/PluginCAS.cpp: PluginObjectStore and PluginActionCache, created via the new cas::createPluginCASDatabases(). - tools/libCASPluginTest: a mock implementation of the C API, backed by UnifiedOnDiskCache. It can be pointed at a second on-disk path to simulate "uploading"/"downloading" objects to/from a distributed CAS, which is what lets the distributed code paths be exercised in-tree. Because it is only ever used for testing, it caps its on-disk mappings at a small size; it links its own copy of LLVMCAS, so the limit a test binary sets for itself does not reach it. - unittests/CAS/PluginCASTest.cpp: covers loading the plugin and the materialization behavior when a key is found remotely but its node graph is only faulted in lazily. - A PluginCAS instantiation of the shared CASTest suite, so the plugin is run against the same ObjectStore and ActionCache tests as the in-memory and on-disk implementations. CASTestingEnv now holds shared_ptr, since createPluginCASDatabases() hands out shared ownership of the underlying plugin instance. The plugin is only built when LLVM_ENABLE_ONDISK_CAS is enabled, as the mock implementation is built on UnifiedOnDiskCache.
Older versions of the library trigger warnigns that were introduced in newer versions of Clang. That's expected, and building with -Werror simply causes the test suite to fail when it would run fine, with warnings.
Add support for SPV_KHR_untyped_pointers, which replaces typed OpTypePointer with OpTypeUntypedPointerKHR for ordinary data pointers. An untyped pointer no longer carries its pointee, so the element type that used to live in the pointer type is now supplied per instruction: the Data Type of OpUntypedVariableKHR, the Base Type of the OpUntyped*AccessChainKHR family, the element size for async copy and prefetch, and so on. These are taken from the element types the backend already deduces for the typed path. Pointers whose pointee has to keep its type stay typed even with the extension enabled: opaque builtin types (images, samplers, pipes, events), function pointers, and byval/byref/sret aggregate arguments. The implementation targets the compute path for now. The Shader/Vulkan path is not covered. This includes OpUntypedArrayLengthKHR. Assisted-by: Claude Code Opus 4.8
isValid returned as soon as it saw a compact DW_OP_regN or DW_OP_bregN operation, or a valid DW_OP_LLVM_entry_value. Operations after that point skipped the remaining checks. Let's keep walking the expression. DW_OP_regx and DW_OP_bregx already leave the switch and continue validating the expression, so this makes the compact forms validate their suffixes too. Entry-value suffixes are also intentional here. This adds no register-specific suffix rule. DWARF 5 requires a register location to stand alone as an entire object or piece, while accepted DWARF issue 230524.1 permits a register location followed by a dereference in DWARF 6. Since isValid() does not know the emitted DWARF version, we keep it limited to applying its existing checks to the suffix. Test each early-return path with a different invalid suffix: a stack value followed by a dereference, a DW_OP_LLVM_arg without its index, and a second entry value later in the expression. Also keep DW_OP_reg0 followed by DW_OP_deref valid. isValid has no dwarf version checking and DWARF 6 permits that form; this does not claim it is valid DWARF 5 output. Tested with make check. Assisted by AI.
…c.ll` (#214047) ...and add RUN lines with scalable vectors there.
The pattern of computing a memory operand index via `X86II::getMemoryOperandNo(Desc.TSFlags) + X86II::getOperandBias(Desc)` occurs in a number of places in the X86 backend. This puts that logic into a helper function called `getMemoryOperandIdx` and simplifies instances across the backend.
) Tracking issue: #201242 See the [migration guide] for more information. [migration guide]: https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines This is the mechanical rename for part 2/4 of the remaining bugprone check documentation. The rewrite is provided by the next PR in this stack.
…4419) Tracking issue: #201242 See the [migration guide] for more information. [migration guide]: https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines This rewrites part 2/4 of the remaining bugprone check documentation from reST to MyST Markdown. AI Usage: This was prepared with rst2myst and GPT5.6-assisted cleanup. I manually verified that the documentation renders as expected. Preview site: https://broken.life/llvm-staging/bugprone-markdown-port/
## Summary LLVM IR `DICompileUnit` supports an optional `dialect:` field as part of its `DISourceLanguageName`, for example: ``` !0 = distinct !DICompileUnit( language: DW_LANG_C, file: !1, dialect: DW_LLVM_LANG_DIALECT_simt ) ``` The MLIR LLVM dialect previously modeled only the base `sourceLanguage`, so LLVM IR import dropped the dialect and MLIR-to-LLVMIR export could not emit it. This patch adds `sourceLanguageDialect` to `#llvm.di_compile_unit`, defaulting to `0`, and wires it through: - MLIR LLVM dialect attribute parsing/printing - recursive debug-info cloning - LLVM dialect bytecode - LLVM IR export - LLVM IR import - C API construction, while preserving the existing constructor behavior with a default dialect The new MLIR format is: ``` #llvm.di_compile_unit< id = distinct[0]<>, sourceLanguage = DW_LANG_C, sourceLanguageDialect = DW_LLVM_LANG_DIALECT_simt, file = #file > ``` AI assistance from codex was used in this MR.
This fixes 45f1b25 (#210373). Buildkite error link: https://buildkite.com/llvm-project/upstream-bazel/builds?commit=45f1b25a0d069a2cee0632e1d1df4ff3342f136e Co-authored-by: Google Bazel Bot <google-bazel-bot@google.com>
Intends to fix the failure from #212013 (comment). I overlooked that the original code returned an empty `TypeAndOrName` if no type with the specified name was found: https://github.com/llvm/llvm-project/blob/9b1218ce69e06a22699bc196888fc0396d989c81/lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABIRuntime.cpp#L84-L88 In my PR, I always returned a `TypeAndOrName` with a name set. With this change, we only set return a non-empty `TypeAndOrName` if there was any type with the specified name.
…13744) If both operands are non-negative, we can perform unsigned queries in the signed system. This complements the fact transfer, and allows us to handle more queries. This improves results in a number of workloads dtcxzyw/llvm-opt-benchmark-nightly#847 Alive2 Proof: https://alive2.llvm.org/ce/z/Sh9ZYR Compile-time in the noise https://llvm-compile-time-tracker.com/compare.php?from=0b5405cb6986cc0d9ddb7a1a11b8d6792bf4101b&to=045f39a70c5445a30788c041d9d1b6636117d4ea&stat=instructions:u PR: #213744
Fix a couple of typos in the docs.
This patch renames the recently introduced Traits.td to BuiltinTraits.td to match the name we chose for the utility header (#210838).
Add test coverage for miscompiles with histograms and multiple uses of bucket value and increment. While touching the file, modernize the existing test + check lines as well.
`cir::VectorType::getABIAlignment` returned `NextPowerOf2` of the type's size in bits, but the hook answers in bytes, and `NextPowerOf2` is strictly greater so it doubles a size that is already a power of two. A one-element vector of double reported 128 where its alignment is 8. Convert the size to bytes and round up with `PowerOf2Ceil`, which leaves an exact power of two alone. This matches how `llvm::DataLayout` aligns a vector that has no explicit layout entry. Assisted-by: Cursor / claude-opus-5
A namespace-scope `Pair g = makePair();` crashes x86_64 calling-convention lowering. Coercing the call's register-pair return needs a temporary alloca, and the code asked the enclosing function for its entry block to hold it. LoweringPrepare runs after this pass, so the initializer is still sitting in its cir.global ctor region with no enclosing cir.func, and getParentOfType returned null. `emitCoercion` and `emitCoercionToMemory` now take the block to use directly, and `coercionSlotBlock` picks it: the function's entry block when there is one, otherwise the entry block of the outermost region below the module. That block dominates the whole body and travels with it into whatever function LoweringPrepare later outlines the body into. This is a prerequisite for enabling x86_64 calling-convention lowering by default. Assisted-by: Cursor / claude-opus-5
…ion (#214838) It's target-specific and unnecessary here.
#212368) In some cases, a reference to a structured binding is value-dependent. I think this has been possible since they were originally defined in C++17. C++26 makes it easier to trigger issues, though. CWG 2984 proposes a resolution to this issue, but the proposed resolution makes a bunch of cases value-dependent where it isn't really necessary. A comment in the code describes my alternative. Fixes #211930
Use DW_OP_LLVM_fragment for the source-variable fragment example. The previous DW_OP_bit_piece form is not valid in LLVM DIExpression metadata - the other code was changed a bit ago, this is just some documentation that didn't catch up.
`-Wlifetime-safety` crashes on a call to an explicit object member
function whose object parameter is an rvalue reference, when the call
passes at least one further argument:
```c++
struct Foo {
template <typename T>
int get(this Foo &&self, T) { return self.field; }
int field;
};
void call() { Foo().get(0); }
```
`handleMovedArgsInCall` pairs `Args[I]` with `getParamDecl(I - 1)`,
assuming the object argument has no corresponding `ParmVarDecl`. An
explicit object parameter is a `ParmVarDecl`, so the offset misaligned
them and the object parameter got paired with the following argument,
which has no origins. So the assert dereferenced the null `OriginList`.
The same offset appears in `IsArgLifetimeBound`, where it reads
`lifetimebound` off the wrong parameter instead of crashing. I have left
that for a separate change.
Fixes #204210
---------
Co-authored-by: NeKon69 <nobodqwe@gmail.com>
Tail calls in functions with a swifterror parameter aren't supported yet and there's a guard against this but the same guard is missing in the memcpy/memmove/memset libcall paths, which caused a miscompile/crash. Apply this guard in those places. swiftlang/swift#90477 rdar://181625760
Move emission of the "long-double-type" module flag out of PowerPC and into generic code, so it describes the long double format for all targets. Co-authored-by: Claude (Claude-Opus-4.8) <noreply@anthropic.com>
…ops (#214532) Give `affine.load`, `affine.store`, `affine.vector_load` and `affine.vector_store` the same optional `alignment` attribute that `memref.load`/`memref.store` and `vector.load`/`vector.store` already carry, via the same `AlignmentAttrOpInterface` and `IntValidAlignment` constraint, and keep it standing where those ops are rebuilt: - `--lower-affine` forwards the alignment onto the `memref`/`vector` access it creates (previously it was dropped, since the lowering rebuilds the access without carrying attributes over). - The map-composition canonicalizer (`SimplifyAffineOp`) carries the alignment over when it rebuilds an access with a composed map. **Motivation.** Without a way to state alignment on the affine ops, a frontend that raises an under-aligned llvm access through affine and back must either give up on raising it, or watch the alignment silently upgrade to the element type's ABI alignment on the way back down. That upgrade is a miscompile: clang emits `load i128, align 8` for a 16-byte member swap at a struct offset that is 8 mod 16; round-tripped through affine without the alignment, the load comes back `align 16` and the backend is entitled to `movaps`, which traps on the real address. (Found in the wild raising MFEM through polygeist-style passes; the out-of-tree pipeline currently has to lower attributed affine accesses itself before `--lower-affine` to avoid the drop — this patch makes that workaround unnecessary.) Tests: round-trip parsing (`Dialect/Affine/ops.mlir`), verifier rejection of non-power-of-two alignment (`invalid.mlir`), alignment forwarding in `--lower-affine` for both scalar and vector forms (`Conversion/AffineToStandard/lower-affine.mlir`), and preservation through map-composition canonicalization (`canonicalize.mlir`). Assisted-by: Claude --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This follows what has been done for other targets. Follow-up commits will port each pass and add them to this pipeline. Assisted-by: AI
…4829) GetSharedModule falls back on the symbol locator plugins when the spec does not already name a binary it can open, and it does so while holding the global module list lock. Locating a binary or symbol file can potentially be quite slow, so we should have the option to opt out of that, for example, if we already did the search upfront.
- This PR replaces existing ARM builtin functions with TableGen. - The `.td` file returns identical header names & type signatures as the `.def` generated headers and types - The change has been tested via the following: - `check-clang-tablegen` - `check-clang-sema` - `check-clang-codegen-arm` - `check-clang-codegen` - `clang-check` - `check-clang` - None of the above returned errors or warnings - The translation is mostly done via a translation script written in Python - [Link to translation script](https://github.com/patricklapgar/python_scripts/blob/main/llvm/clang/arm_tablegen_mig.py) - [Link to translation script test suite](https://github.com/patricklapgar/python_scripts/blob/main/llvm/clang/test_arm_tablegen_mig.py) - Disclaimer: Both the translation script and its test suite were made w/ assistance from AI (IBM Bob)
Fix ppc build after #213331. libCASPluginTest should link libpthread since the mock implementation uses a threadpool.
When these appear in an AttributedStmt, we have to annotate the call with these attributes. This patch implements them for all of the CallOpInterface types.
…r explicit-shape-bounds-spec (#203030) Since Lower and large parts of Semantics depend on ShapeSpec being a scalar bound, implement a class RankOneBoundElement that does just this. Since there is no syntactic representation for this node kind, have both unparse.cpp and mod-file.cpp emit the original rank-1 integer array expression instead of scalarized versions. Analyze does semantic checks, then repackages into an array of scalarized ShapeSpec pairs instead of a pair of arrays. Lower implementation in follow-up stack PR. Also, fix pre-existing bug where overriding dimension spec in entity-decl throws away and fails to type check the array-spec provided in dimension spec.
…tin*overflow' (#214553) For a binary operation 'A op B' and a result type 'T', these builtins return true/false for whether the operation's result is a value 'T' cannot hold. CSA models this by computing the operation's result in a temporary type and comparing it against the bounds of 'T'. However, the temporary type is only twice as wide as 'T', not the operands. When either operand is wider than 'T's doubled width, the result of 'A op B' can silently wrap around before the comparison, producing a false negative. The solution is to find the proper type to temporarily hold the result of 'A op B' from types of 'A' and 'B'. rdar://184263112 --------- Co-authored-by: Balázs Benics <benicsbalazs@gmail.com>
Summary: This wasn't included in the list of flags to forward.
`$ git ls-files '*.gn' '*.gni' | xargs llvm/utils/gn/gn.py format`
…mpat.h (#214569) Remove extra semicolon after API_HELPER_OPTIONAL macro invocation which is flagged as incompatible with C++98 [-Wc++98-compat-extra-semi].
…NFC) (#214740) This is a small improvement for `stage1-aarch64-O3`: https://llvm-compile-time-tracker.com/compare.php?from=94af8651da4a1b907a8ea2acb698d72aad3df722&to=ce67ef155e8fc7945a6ec930a12e5762a45fa00b&stat=instructions:u
Non-power-of-2 VF support (-slp-vectorize-non-power-of-2) was wired into the `load/store/reduction` paths but not into `tryToVectorizeList`, so `buildvector/insertelement` seeds like <15 x half> were split into power-of-2 pieces instead of a single vector op. Consult `isAllowedNonPowerOf2VF()` when computing `MaxVF` and in the inner full-vector guard so supported widths are tried. No change unless `-slp-vectorize-non-power-of-2` is enabled. https://godbolt.org/z/1b8GebPEW
This fixes de8c11a (#208380). Buildkite error link: https://buildkite.com/llvm-project/upstream-bazel/builds?commit=de8c11a669810b7043462a94fe34dfdbe5a1c8bf Co-authored-by: Google Bazel Bot <google-bazel-bot@google.com>
PlatformDarwinKernel::GetSharedModuleKernel unconditionally dereferenced the process to reach the target's debug file search paths. The Process * is the wrong thing to be threading through Platform::GetSharedModule. Refactor Platform::GetSharedModule to take a `Target &` and get the process from the target if we really need it.
This patch organizes the lit tests by introducing a directory structure, separating them by pass, and renaming them when needed. This will become increasingly useful for navigating through the lit tests as we keep adding more tests and more passes. This also drops boilerplate.ll as it was one of the early tests that checked the vectorizer's boilerplate and is no longer needed.
…212625) NameResolver used a StringMap<uint64_t> to count duplicate names. StringMap owns its keys, so every uniquify()/getUniquifiedNameCount() query allocated a full copy of each (potentially large, mangled) symbol name. During discoverFileObjects on a large binary, this string-key duplication accounted for ~2 GB (1 to 2% of RSS) of allocations in StringMap::try_emplace_with_hash -> StringMapEntry::create -> allocateWithKey. Replace the StringMap with a DenseMap<pair<uint64_t,uint64_t>, uint64_t> keyed by a 128-bit xxh3 hash of the name. No string is ever stored: each distinct name costs a fixed-size entry regardless of length. A 128-bit hash makes collisions effectively impossible, so the per-name counts (and therefore the generated 'Name/ID' unique names) are identical to the string-keyed map and remain reproducible to match profile (fdata) names. Also clear the map at the end of discoverFileObjects, since the resolver is not needed afterwards; all NR.uniquify()/getUniquifiedNameCount() calls occur within that function's dynamic extent (including processRelocations and registerFragments).
… of RawPtrRef(LocalVars|Member)Checker (#214102) The `RawPtrRefLocalVarsChecker` and `RawPtrRefMemberChecker` forgot to call `Report->setDeclWithIssue()` for some bug reports. Without the call, the HTML reports miss the enclosing Decl and have hash collision on distinct diagnostics. The added `clang/test/Analysis/Checkers/WebKit/html-diag-dedup-members.cpp` example is a reproducer of this kind of issue we observed in WebKit. In addition, refactored `GetEnclosingDeclContextSignature` for simplicity and supporting ObjC Decls. rdar://183700416 Assisted-by: Claude sonnet --------- Co-authored-by: Balázs Benics <benicsbalazs@gmail.com>
This is part of larger effort to support address spaces in lldb https://discourse.llvm.org/t/rfc-address-spaces-support-in-lldb/91222/ This PR introduces the definition of AddressSpace and ProcessAddress classes, which are foundational for next PRs Stack: 1. #206370 (this PR) - the classes 2. #214088 ProcessAddress adoption (NFC) 3. #214089 Generic address space support
found_platform_binary was tested but never assigned, so the early return it guards was dead and LoadCoreFileImages reported failure for a corefile whose only image a Platform plugin had already taken care of. The caller reads that as "no binary found in the metadata" and goes on to scan low memory for a UUID that has no reason to be there. While here, stop assuming the module has an object file before asking it for its sections. A binary located by an external symbol server is turned into a Module without checking that it parses, and LoadBinaryInTarget guards the same dereference on the other branch. Assisted-by: Claude
…214632) The download path was derived only from the key and the PDB name, so two lookups (from different threads) potentially raced the same file path. Avoid this by creating using a unique suffix. 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 : )