[pull] main from llvm:main - #1722
Merged
Merged
Conversation
Previously MangleAndInterner held a DataLayout reference and mangled names via Mangler::getNameWithPrefix. Replace the stored DataLayout with an internal ManglingMode enum and mangle from that directly, so the class no longer needs to hold a DataLayout. Add two DataLayout-free constructors: one taking an ExecutionSession and an optional ABI name (deriving the mode from the session's target triple), and one taking an explicit ManglingMode. The existing DataLayout constructor is retained, now deriving the mode from the DataLayout. This lets MangleAndInterner be used where no DataLayout is available (e.g. from a bare ExecutionSession). Adds MangleAndInternerTest covering the triple- and mode-based construction paths.
…181331) This PR enables Tail Recursion Elimination (TRE) for functions where the accumulator operation is a shift (`shl`, `lshr`, `ashr`) by a constant amount -- i.e., pseudo-associative relation. As pointed out in #178805, `InstCombine` often strength-reduces multiplications (or `f(x-1) + f(x-1)`) into `shl`. Currently, TRE strictly requires operations to be associative and commutative: https://github.com/llvm/llvm-project/blob/05e908609227e1e8d993659e604a63668dfd2825/llvm/lib/Transforms/Scalar/TailRecursionElimination.cpp#L377-L379 This prevents TRE from transforming recursive shifts into loops, creating a phase-ordering problem where canonicalization blocks a structural optimization. This PR does **not** perform shift accumulator optimization when there are multiple base cases: it is reserved for future work. Fixes #178805.
This mainly consists of removing the UNIT_TEST_ONLY lines as previous patches made sure the tests work. The only slightly nontrivial part is adding support for C_TEST to the hermetic test macro. After this, the only UNIT_TEST_ONLY tests are those that require the MPFR library.
Implemented the sleep and usleep entrypoints for Linux. Refactored the syscall implementation out of the public nanosleep entrypoint into a standard internal syscall wrapper. Fixes #214293. Co-authored-by: Jeff Bailey <jbailey@raspberryginger.com>
Prevent legalisation of this opcode falling back to SDAG. In situations where a G_EXTRACT_SUBVECTOR is being performed on two vectors which aren't double/half the size of each other, represent the extract as build_vector(extract_vector_element, extract_vector_element, ...).
…213801) This PR adds a compiler-rt test (`instrprof-coroutine-profile.cpp`) to verify PGO profile counter generation and ingestion for C++20 coroutines. During investigating the iFDO profile ingested for coroutine pass, we found that the profile data contains entry counts for the original coroutine function (`foo`), but lacks the entry counters for the split `foo.resume` function. After inspecting [PassBuilderPipelines.cpp](https://github.com/llvm/llvm-project/blob/f7b7ec8d5542dcede1ae607aa74dfe36d7a3c530/llvm/lib/Passes/PassBuilderPipelines.cpp#L1273) confirms that `PGOInstrumentationGen` runs before `CoroSplitPass`. Therefore, - 1) the iFDO profile correctly ingests and associates profile counters with coroutine function `foo`. - 2) Separate function entry counters for `foo.resume` are not expected in the iFDO profile. Added `compiler-rt/test/profile/instrprof-coroutine-profile.cpp` and use `llvm-profdata show` verify coroutine profile data. The IR dump after `PGOInstrumentationGen` confirms that the function entry count is tracking by counter[6] in the 8-element counter for `foo`. ```llvm coro.alloc: ; preds = %entry call void @llvm.instrprof.increment(ptr @__profn__Z3fooi, i64 650973721613012168, i32 8, i32 6) %2 = call i64 @llvm.coro.size.i64() %call = call noalias noundef nonnull ptr @_Znwm(i64 noundef %2) #14 br label %coro.init coro.init: ; preds = %coro.alloc, %entry ``` Co-authored-by: Jin Huang <jingold@google.com>
(At least) two tests enabled by #213860 are failing on the amdgpu bot (which only runs hermetic tests). This patch skips them, but it a different way, so that they keep running in hermetic mode on supported targets. For the sched_test, I add a dependency on the sched_getscheduler target (used in the test) to trigger the auto-skipping logic. The memory utils test fails due to a missing cmp_is_expensive specialization, so I enable the test only on targets which have them (listing targets explicitly).
#214199) I did not realise that LLDB_TEST_COMPILER should be the C compiler, so I got: cxx = cc_dir / (cc_prefix + cxx_type + cc_ext) TypeError: can only concatenate str (not "NoneType") to str Config=aarch64-/usr/bin/g++ I have simplified the logic and added a more informative error: RuntimeError: Could not infer C++ compiler name from compiler type "g++" Added a note to the documentation. The CMake description does say "C compiler", but it's easy to gloss over that so I extended that to say how we get the C++ compiler.
…214166) The intrinsic already has it. The instructions may issue a wake-up signal on barrier completion so the set of waves that execute the instruction may not change. The test case shows taildup duplicating the MachineInstrs when `isConvergent=0`. Assisted-By: Claude Opus 4.8 Claude found the reproducer for me after I found the lack of `isConvergent=1` on those instructions.
Building on my recent commit 25d51a8 this commit moves the general-purpose bounds checking logic from ArrayBoundChecker.cpp to the new files BoundsChecking.{cpp,h}. This new library currently only serves the needs of `security.ArrayBound`, but it will be gradually expanded, generalized and used to bring other bounds checking checkers out of alpha stage. The code is moved without modifications, except for the removal of a TODO note that asks for moving the code into a separate library.
…213226) Add support for f4, f8, f16, bf16, and f64 constants backed by DenseResourceElementsAttr.
Expands checks in Linalg's tiling implementation in presence of semi-affine indexing maps to reject unsafe tiling configurations. Current tiling can produce incorrect results when tiling occurs on a dimension accessed via semi-affine map. This is due to lack of tile offset tracking as shift in tiled slices cannot be represented today using symbol-free indexing maps. Assisted-by: Claude
…local (#213543) LoanPropagation already keeps origins that cross block boundaries apart from those confined to one block, so that only the former take part in joins. Do the same for LiveOrigins, and share the single prepass that classifies them. Block-local origins are not merely a minor share of the liveness state: many expression origins are made live by a `UseFact` but never killed, because several `OriginFlow` sites propagate only the outermost origin of an expression's list (see the FIXMEs in `handleFunctionCall`), and a `StringLiteral` glvalue origin is only ever a flow's source. Those origins survived to the top of their block and then propagated backward across the whole function. In `EmitARMMVEBuiltinExpr`, of 68644 origins only 490 are persistent, and the liveness map at a block boundary peaked at 11725 entries; it now peaks at 326. `computePersistentOrigins` moves to `FactManager`, which computes it on first use and hands the same bit vector to both analyses. Sharing it is not just an optimization: if the two disagreed on which origins cross boundaries, an origin's liveness could outlive its loans, or the reverse, and the checker intersects the two. Since a block-local origin can still be live at a program point inside its own block, `getLiveOriginsAt` now returns both halves and callers visit each. Median of 7 interleaved runs of a baseline and a patched binary: | translation unit | LiveOrigins | analysis | Frontend | |-------------------------|--------------|----------|----------| | ByteCode/Disasm.cpp | 154.3 → 18.6 | -65.7% | -9.1% | | TargetBuiltins/ARM.cpp | 341.3 → 63.1 | -43.9% | -5.3% | | X86/X86ISelLowering.cpp | 60.1 → 48.2 | -3.3% | -0.3% | | Sema/SemaExprCXX.cpp | 44.5 → 42.0 | -0.4% | -0.4% | On Disasm.cpp MovedLoans and LifetimeChecker drop by 90.3% and 88.0% too, as both iterate the live-origin set at every fact they handle. The synthetic cases in clang/test/Analysis/LifetimeSafety/benchmark.py are unaffected: their origins are all persistent. Diagnostics are unchanged: -Wlifetime-safety-all output is identical on all four translation units above, ~31000 diagnostic lines in total. Assisted-by: Opus 5.0 Co-authored-by: Gabor Horvath <gaborh@apple.com>
Fixes #209193. `TargetLowering::expandPartialReduceMLA` handled UMLA, SMLA, and FMLA, but fell through to `llvm_unreachable` when expanding `PARTIAL_REDUCE_SUMLA`. This handles SUMLA by sign-extending the signed LHS and zero-extending the unsigned RHS before multiplication. The first commit precommits a SelectionDAG unit test that reproduces the assertion and verifies that expansion creates the expected extensions.
…e` and `unique_ptr` (#167211) libc++'s `tuple`'s move constructor is well-constrained when initially implemented. So this patch only adds test cases. For `unique_ptr`, its move constructor and move assignment operator were previously unconstrained and thus this patch changes them. There doesn't seem "obviously correct" approach for constraining in pre-C++20 modes, and this patch attempts to use `__nat` trick to avoid turning the functions into templates which are not move special functions. Some tests case are adjusted because false positive of move-assignability of `unique_ptr` is reduced. Comments are updated to reflect that move-constructibility is not actually required for `unique_ptr`'s deleter. This patch also explicitly deletes copy functions of `unique_ptr` in all modes. Previously, they are implicitly deleted since C++11 mode, although the standard wording always explicitly deletes them. Clang seems to be somehow buggy on propagating deleted-ness of special member functions from unnamed structs, while explicit deletion can act as a workaround. The title of this patch is adjusted to reflect the final resolution of LWG2899. --------- Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
PR #213860 enabled the test on GPU targets (which only runs hermetic tests), exposing two issues. The first one is passing "pointer" values as `int`s. On AMDGPU, this produced garbage in the high bits of the printed value, presumably the result of reading a short `int` as a (longer) `void *`. On other this probably worked because the value is passed in a register, which (implicitly) zeroes out high bits. I fix this by casting the argument to a `uintptr_t`. The second error is a crash in the wide char test. I restore status quo by disabling that part of the test, but I've filed #214433 to figure out a long term solution.
So we are using the generic interface that will work with all future RegisterType derived classes. Right now we'll only be asked to print RegisterTypeFlags, so there's a few dyn_cast to that. Later we will switch on the kind, and support rendering more types.
This significantly improves support for rematerializing registers with more than one definition. In particular, this includes cases where different lanes of a register are defined over multiple instructions. There are still a few restrictions that can hopefully be relaxed in the future. - All defining instructions must be part of the same rematerialization region. - No pure user of the register (i.e., an MI that doesn't also defined a part of the register) must read the register before its last definition. These constraints ensure that the underlying DAG representation maintained by the rematerializer is still valid, making this a relatively incremental improvement.
…patterns (#213698) `LowerContractionToNeonI8MMPattern` and `LowerContractionToNeonBFMMLAPattern` rewrite a `vector.contract` into several ops (multiple `arm_neon.intr.smmla`/`bfmmla` calls plus `extract/insert/shape_cast` scaffolding). When the matched `vector.contract` sits inside a `vector.mask` (e.g., from vectorizing a matmul with dynamically-shaped operands), this in-place multi-op rewrite violates `vector.mask`'s invariant that its region contain exactly **one** operation, and the verifier rejects the result: _error: 'vector.mask' op expects only one operation to mask_. Neither pattern checked for masking, unlike the generic contraction-lowering patterns. To fix the problem, we bail out via `notifyMatchFailure` when the contraction is masked, so it falls through to a different lowering path instead of producing invalid IR. Found while adding neon `linalg.matmul` e2e tests in #212809. AI was used to investigate the problem. --------- Signed-off-by: Federico Bruzzone <federico.bruzzone.i@gmail.com>
) VPRegionBlock::clone() creates the cloned loop region's canonical IV info via createLoopRegion(), which always starts with NUW set. If the original region's canonical IV had already had its NUW flag cleared the clone did not carry that over, leaving the cloned region's CanIVInfo inconsistent with the original. Propagate the cleared NUW flag to the clone so both regions agree on whether the canonical IV is NUW.
…C) (#214438) This also avoids copying the list of ModuleIDs.
The Apple runtime unroll preference in context only accepts single BB loops by `if (Header == Latch)`
Broadcasts from vectors to higher rank vectors get lowered recursively by iterating over leading dimensions to create "size(dimension)" insert ops. This cannot be done for scalable dimensions whose size is unknown. This PR prevents such transforms from occurring by stopping if the leading dimension is scalable.
Fixes #213966. Only globals whose uniqued name deconstructs to `NameKind::VARIABLE` were described. A Fortran named constant (PARAMETER) is mangled with EC and deconstructs to `NameKind::CONSTANT`, so it got no debug info at all and a debugger could not evaluate one, whether it was declared in a module or inside a procedure. A module constant is described the way a module variable already is, with a `DIGlobalVariable` scoped to the `DIModule`. A constant local to a procedure is described in the scope of that procedure. Two related fixes for entities whose global has internal linkage, which covers both a procedure local constant and a procedure local SAVE variable that was already being described: - `isLocalToUnit` was hardcoded to false, so these were marked `DW_AT_external`. It now follows the linkage of the global. - A linkage name was emitted for them. There is no external symbol for a debugger to match against, so it is now omitted, which is also what clang does for a function local static. Assisted by: Cursor --------- Co-authored-by: Cursor <cursoragent@cursor.com>
These had matching high latency and throughput numbers, which suggest they hadn't been updated since the itinerary conversion. Confirmed with Agner, uops.info and instlatx64 which report a consistent throughput of 2cy, latency seems to be about 4cy (uops.info just says <= 6cy) Noticed while trying to confirm #214191 vector reduction costs for atom type cpus, and llvm-mca was reporting some very odd numbers for bonnell.
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 : )