[pull] main from llvm:main - #1712
Merged
Merged
Conversation
…213716) Applying them when they already present is a wasted allocation and can also cause trouble in the Swift compiler that can complain about duplicated attributes. rdar://174868727
This partially reverts 15bb4a9 ([IR] Make semantics of strictfp consistent v2, #211769) due to a verifier failure in real-world code, disabling just the verifier-check with a FIXME. The reason for a partial manual-revert is because a clean revert doesn't apply cleanly: in particular, the LangRef is untouched by this patch. Ref: #211769 (comment)
…1448) Tracking issue: #201242 See the [migration guide] for more information. [migration guide]: https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines This is the initial straight rename commit. It will probably break the docs build, but it has to be a separate PR for blame preservation purposes.
…211449) Tracking issue: #201242 See the [migration guide] for more information. [migration guide]: https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines This is a stacked PR based on #211448 , which will be a standalone commit that renames *.rst -> *.md before this PR lands for history preservation purposes. Unlike the other changes in this series, most of these changes are from the generator script. Ignore all files under checks/ except `list.md`, that is hand-modified. I confirmed that running the generator script produces no changes. Notably, the generator script *added new files*, since it seems there are new checks since the script was run.
We can mark this issue as completed because the fix for LWG 3116 is already implemented in <scoped_allocator>, and no further tests are needed. Why no further tests are needed: The existing test suite in libcxx/test/std/utilities/allocator.adaptor/allocator.adaptor.members/construct.pass.cpp already provides full coverage for the scenario explained in lwg3116. This test suite instantiates nested scoped allocators (using A1 and A2) and calls .construct(). Because std::allocator_traits cannot be instantiated with a reference type (e.g., A1&), this test suite would fail to compile if the reference-stripping fix were missing. Closes #100244
A copyable lane holding a single-use fmul a, b is modeled as fmuladd(a, b, -0.0), which equals fmul a, b (the add of -0.0 is exact and preserves signed zeros), so the multiply dies instead of being computed and gathered. Applied only when every copyable lane is such an fmul; multi-use fmuls and mixed copyables keep the addend/multiplicand modeling. On a tie between fmuladd and fmul main ops, fmuladd is preferred only when the fmuls are absorbed profitably: single-use, operands not part of the list and vectorizable as multiplicand operands. Reviewers: bababuck, hiraditya, RKSimon Pull Request: #213369
…#213726) SystemZISD::MEMMOVE requires an i64 length operand, but Size was passed raw. A constant size literal can be represented as i32, causing a SelectionDAG verifier crash observed when compiling SPEC CPU benchmarks wrf, cam4 and fotonik3d with -march=z17 -O3. Fix by zero-extending Size to i64 before building the node. Co-authored-by: anoop.kumar6@ibm.com <anoopk@b35lp63.lnxne.boe>
We had a problem where a new expression that required both a null check of the allocated pointer and a cleanup of temporaries values created for the initializer was causing us to generate an unterminated cleanup scope. This was happening because we weren't pre-creating a cleanup scope around the entire expression for the temporary and ended up emitting it in an unexpected location. This change adds a check for the null-checked new expression in `ConditionalEvaluationFinder` and wraps the call to emit the initializer with `ConditionEvalulation::begin/endEvaluation` calls. Note that I have sunk the `begin/endEvaluation` into the `emitInit` lambda so that it can surround just the `emitNewInitializer` call and not the `enterNewDeleteCleanup` call, which creates a local cleanup scope for the case where the allocation succeeded but the constructor throws an exception. Classic codegen calls `begin/endEvaluation` at a higher level and ends up using an active flag for the allocation delete cleanup even though the flag is always true when that cleanup is reached. Assisted-by: Cursor / various models
Clang configuration files may contain frontend-specific options. So building Objective C files with the clang++ may fail due to an option not being available for the C frontend. Clean up the code slightly and pick the correct compiler based on the file extension.
… b, -0.0)" This reverts commit f338032 to fix https://lab.llvm.org/buildbot/#/builders/227/builds/3894. Reviewers: Pull Request: #213741
Under -fstack-protector-all, stack_protector_ignore on a local is inert. The warning is therefore accurate, and it stays useful in user code -- an opt-out that silently does nothing is worth knowing about. The warning is not actionable when the attribute comes from a system header macro and so this change disables it in system macros. Behavior is otherwise unchanged. The attribute was already being ignored, so suppressing the diagnostic hides nothing. Also extend stack-protector-metadata.ll to cover the remaining protection levels: test3/test4 for sspreq, where the opt-out metadata is ignored, and test5/test6 for sspstrong, where it is honored. Only ssp was covered before. rdar://173529401
This change adds tracking of floating-point constraints via the CIRGenFPOptionsRAII object, deriving the state from the FP features in effect tracking in the Clang AST. When we are about to generate an operation that may require floating point constraints, a CIRGenFPOptionsRAII object is used to get the effective floating-point state from the expression for which we are generating the operations. This object in turn sets the floating-point state of the CIRGenBuilder which uses these settings to determine whether a cir::FenvAttr should be attached to generated objects and, if so, what its state should be. This does not cover complex operations, AArch64 builtins, or global constructors. Those will be updated in follow-up changes. Assisted-by: Cursor / various models
Use `bundle-vec(bottom-up)` or `bundle-vec(top-down)` to run the bottom-up or top-down bundle vectorizer, respectively. For example: ``` opt -passes=sandbox-vectorizer \ -sbvec-collect-seeds=loads \ -sbvec-passes="seed-collection<tr-save,bundle-vec(top-down),tr-accept>" \ input.ll -S -o out.ll opt -passes=sandbox-vectorizer \ -sbvec-collect-seeds=stores \ -sbvec-passes="seed-collection<tr-save,bundle-vec(bottom-up),tr-accept>" \ input.ll -S -o out.ll ``` This commit is NFC, except the BundleVec requiring the user to specify the direction upon invocation.
A Wasm module carries the identifier its linker gave it in a `build_id` custom section, whose payload is the length of the identifier followed by its bytes. That identifier is the only thing that tells one build of a module from another. `wasm-ld` emits the section only when asked, so the API test build asks for it. A module linked without one still has no UUID.
A copyable lane holding a single-use fmul a, b is modeled as fmuladd(a, b, -0.0), which equals fmul a, b (the add of -0.0 is exact and preserves signed zeros), so the multiply dies instead of being computed and gathered. Applied only when every copyable lane is such an fmul; multi-use fmuls and mixed copyables keep the addend/multiplicand modeling. On a tie between fmuladd and fmul main ops, fmuladd is preferred only when the fmuls are absorbed profitably: single-use, operands not part of the list and vectorizable as multiplicand operands. Original Pull Request: #213369 Recommit after the fix for the revert in 9e8e0d4 Reviewers: Pull Request: #213757
This isn't used in clang for any builtin, so don't leak this.
#191278) …folded overflowing offsets EmitGEPOffsetInBytes has two paths: for fully constant GEPs it subtracts pointer values and always returns OffsetOverflows=false, but for non-constant GEPs it iterates operands using checked arithmetic. The assertion in EmitCheckedInBoundsGEP assumed a constant TotalOffset implies no overflow, conflating the two paths. In the non-constant path, the offset can be entirely constant-folded (constant index * constant element size) while the GEP itself remains non-constant (runtime base pointer). If that arithmetic overflows intptr_t, we get a constant TotalOffset with OffsetOverflows=true, triggering the assertion. This is easily hit on 16-bit targets like MSP430 with realistic struct array indices. Remove the assertion. The existing codegen already handles this correctly: the constant OffsetOverflows=true propagates into the check condition, making the sanitizer always fire at runtime. Fixes: #48168 Assisted-by: Kiro CLI / Claude Opus 4.6 (1M context)
) This is an issue in AMDGPUAsmParser.cpp self-build, we have a lot of record elements (~360k+!) in an array that causes us to have this TU be near-never-ending(hour+). Classic codegen compiles this sub-minute on my machine. With this patch, we are only about a 30% increase in time. Note: Claude wrote much of the tests after I got through every exception I could think of. I think this covers everything, and I hope there is no missing coverage.
…g minidump (#212641) **Issue** An internal failing test found a latent bug in lldb's save-core (minidump writer). When it saved a memory range that had an unreadable page in it, it: - stopped at that page and threw away the readable memory after it, Result: We couldnot get the stack traces from the minidump. in the below example the **current logic is bailing out at the 6th region and not writing other 70 regions.** ``` [satyajanga@devgpu011.eag2 ~/fbsource/fbcode (eacbfddefa|remote/master)]$ lldb (lldb) file /data/users/satyajanga/fbsource/buck-out/v2/art/fbcode/55005549ebc49982/sand/tests/__Coro__/Coro Current executable set to '/data/users/satyajanga/fbsource/buck-out/v2/art/fbcode/55005549ebc49982/sand/tests/__Coro__/Coro' (x86_64). (lldb) b coro.cpp:44 Breakpoint 1: where = Coro`::co_main() + 197 at coro.cpp:44, address = 0x00000000002335a5 (lldb) r Process 3374177 launched: '/data/users/satyajanga/fbsource/buck-out/v2/art/fbcode/55005549ebc49982/sand/tests/__Coro__/Coro' (x86_64) warning: (x86_64) /data/users/satyajanga/fbsource/buck-out/v2/art/fbcode/55005549ebc49982/sand/tests/__Coro__/__Coro__shared_libs_symlink_tree/libfolly_futures_tree.so unable to locate separate debug file (dwo, dwp). Debugging will be degraded (troubleshoot with https://fburl.com/missing_dwo) Process 3374177 stopped * thread #9, name = 'GlobalCPUThread', stop reason = breakpoint 1.1 frame #0: 0x00000000002335a5 Coro`::co_main() at coro.cpp:44 (lldb) script Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D. >>> target = lldb.debugger.GetSelectedTarget() >>> process = target.GetProcess() >>> regions = process.GetMemoryRegions() >>> len(regions) 76 >>> for i in range(len(regions)): ... region = regions[i] ... if not region.IsReadable(): ... continue ... base, end = region.GetRegionBase(), region.GetRegionEnd() ... size = end - base ... name = region.GetName() or "" ... error = lldb.SBError() ... data = process.ReadMemory(base, size, error) ... bytes_read = len(data) if data else 0 ... if error.Success() and bytes_read == size: ... continue ... print(f" FAILED to read region {i}, {name} ") ... FAILED to read region 6, FAILED to read region 8, FAILED to read region 10, FAILED to read region 12, FAILED to read region 15, FAILED to read region 65, [vvar] FAILED to read region 66, [vvar_vclock] >>> ``` **Fix** Rewrote ReadWriteMemoryInChunks in MinidumpFileBuilder.cpp to: save the readable bytes, zero-fill the unreadable page, keep going, and record the exact number of bytes actually written. That keeps the dump aligned and preserves memory after a hole. **Test** Added an lldb API test that builds a memory region with a readable page followed by an unreadable tail, saves a core of it, and checks the readable data comes back intact
Followup to fix the generated proxy header after #211428. Assisted-by: Automated tooling, human reviewed.
Traditionally we maintained 2 parallel feature mechanisms, one in clang (later moved to TargetParser), with largely mirrored subtarget features defined in the backend. Start directly taking feature information from the backend and putting it into TargetParser. This is still in a compromise mid-migration state. We still have both the legacy "ArchAttr" bitfield integer, plus a new AMDGPUFeatureBitset field stored in the table, which isn't yet exported. For the moment, the new bitset is only used to populate the feature string name map, which is the big maintainability win. This also lists an explicit subset of exported features to avoid churn. Co-authored-by: Claude (Claude-Opus-4.8)
fixes #213340 This was simple fix we just had to change the order in which we were doing the splitting and widdening. This change prioritize splitting G_FATAN2 vectors wider than four elements before attempting power-of-two widening, which G_FATAN2 does not support. Add float and half coverage for vector widths 6, 8, 9, 12, and 16.
Migrated tests - TestDAP_extendedStackTrace.py - TestDAP_source.py - TestDAP_source_x86.py
Drop the raw line number when matching the expected location.
This problem was reported at <#182405 (comment)> for the case of very large loop probabilities. The biggest issue is that, when using linear and quadratic equations to determine loop latch probabilities, asserts introduced by PR #182405 to verify the accuracy of the resulting loop body frequency can fail. Another issue is that iterations introduced by PR #182404 and PR #182405 terminate upon achieving a desired accuracy, but they can iterate longer than necessary, wasting time achieving higher accuracy than desired. This patch fixes the accuracy calculations to use relative differences instead of absolute differences. It updates existing tests that reveal the impact on the N>2 uniform case. Its adds new tests to cover the N=1, N=2, and N>2 fast cases.
…3595) Thread local storage isn't universally supported on all architectures. Only enable it for the ones that are known to support it. rdar://183822457
Reviewers: Pull Request: #213781
We had grown 2 parallel parsing implementations for triple+gpu name+feature flag target ID strings. Mostly eliminate the redundant clang version. Co-authored-by: Claude (Opus 4.8)
…lect cond, a, b) (#199688) (select_cc (select cond, x, y), x, a, b, eq) which could be simplified to (select cond, a, b)
A union whose CIR type ends up with no members keeps its whole size in
its
padding field, and `UnionType::getTypeSizeInBits` returned early in
exactly that
case, before reaching the padding. A union need not look empty in the
source to
land there: a lone zero-length bitfield is dropped during lowering,
leaving the
same no-storage state.
A record embedding such a union was then laid out wrong. In an unpacked
record
`insertPadding` pads whenever the end of the members placed so far,
rounded up
to the next member's alignment, falls short of that member's offset, so
a union
measuring zero earns a pad the AST layout does not have. In C++,
`struct { union {} e; int x; }` loaded `x` from byte 8 rather than 4,
and an
array of that struct had a 12-byte stride, not 8. With the union
`alignas(16)`,
the load came from byte 32 rather than 16.
The zero also reached `lowerUnion`, which sizes a union's padding as its
layout
size less its storage member's, so `union { union {} e; }` emitted a
two-byte
type for a one-byte union.
Sum the storage and padding contributions instead of returning early.
The
has-storage path is unchanged, and a C empty union stays at size zero
because it
has no padding field to add.
`UnionType::getABIAlignment` keeps its early return. Union padding is
always a
char or an array of char, so folding it in cannot change the alignment
of
anything CIRGen emits.
…t use rewrite mechanism (#212920) During lowering of declare target'd variables we generate new global variables for device that replace the use of the pre-existing global variable. In Flang we currently rewrite this for each target region, but that's not enough to cover indirect use cases inside of declare target functions which can be imported into the module and utilised inside of a target region. This PR tries to extend the scope of the rewriting to the module than a per target region rewrite. It does so by creating a mechanism where we can register globals for replacement which will trigger on finalization of the OMPIRBuilder. This is required as due to the ordering of lowering for MLIR, where we generate the replacement global at the beginning of the module before any uses have been generated, effectively meaning we cannot replace the uses at that point. So, we defer the replacement to the OMPIRBuilder as there is no deferral mechanism directly in the OpenMP MLIR lowering. The alternative might be to rebind the global maps in ModuleTranslation (which requires extending ModuleTranslation a bit and might not be looked apon as a great alteration from the MLIR community) so that the old global points to the new one, but in practice this doesn't work particularly well for declare target link/usm variables as they neccesitate a load and the act of rebinding the global doesn't indicate to the lowering that the load is required. So, the OMPIRBuilder method allows us more flexibility to make this (and other) required alterations.
Aligned bundling partitions instructions into fixed-size, naturally aligned groups called bundles and guarantees that no instruction crosses a bundle boundary, giving the instruction stream a single canonical decoding. It is a building block for software-based fault isolation: control flow cannot jump into the middle of an instruction to manufacture a different, unchecked sequence, and when combined with masking of indirect branch targets it constrains control flow to a statically verifiable set of locations. The previous target-independent implementation was removed in #148781, which simplified MC by eliminating per-fragment BundlePadding, the virtual emitInstToData, and BundleGroupBeforeFirstInst. This change reimplements the feature in the X86 backend on top of the existing MCBoundaryAlignFragment infrastructure added for branch alignment, keeping the generic MC surface smaller: * AsmParser parses .bundle_align_mode, .bundle_lock and .bundle_unlock and dispatches them through new MCStreamer hooks. * MCAssembler holds the bundle size, MCObjectStreamer tracks whether a locked group is open, and MCBoundaryAlignFragment gains an align_to_end bit. No new per-fragment padding state. * Padding is decided at layout time by computeBoundaryAlignSize, which pads only when an instruction or a locked group would cross a boundary, and NOP emission goes through writeControlledNops. * X86AsmBackend opens a boundary-align fragment for each instruction, or one for a whole bundle-locked group, and reports the group size error at layout. Improvements over the prior implementation: * NOPs never span a bundle boundary. * Labels never move. * Bundle locks may not nest. * Padding can be folded into neighboring instructions as otherwise ignored prefixes rather than standalone NOPs, reusing the existing --x86-pad-max-prefix-size option. Padding is only ever traded within the bundle that holds it, so nothing moves across a boundary. * No codegen change and no extra layout work when the directives are not used. Bundling is supported for X86 ELF only and the directives are rejected elsewhere. Restrictions: bundle mode may be set once per file and cannot be changed or turned off, it is incompatible with -x86-align-branch and -mbranches-within-32B-boundaries, locked groups are allowed only in executable sections, must fit within one bundle, must be closed before a section change, and may not end in a bare instruction prefix. Documented in llvm/docs/AlignedBundling.rst, with tests in llvm/test/MC/X86/AlignedBundling. --------- Co-authored-by: Taehyun Noh <taehyun@utexas.edu> Co-authored-by: Fangrui Song <i@maskray.me>
Assisted-by: OpenAI Codex --------- Co-authored-by: jeffniu-openai <jeffniu@openai.com>
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 : )