Bump to 3c2731ce46f01a984a9cc1807207de8d333bc350 [Mar 23]#1192
Open
jorickert wants to merge 1796 commits into
Open
Bump to 3c2731ce46f01a984a9cc1807207de8d333bc350 [Mar 23]#1192jorickert wants to merge 1796 commits into
jorickert wants to merge 1796 commits into
Conversation
Follow the X86 renaming. > "Relocation modifier" suggests adjustments happen during the linker's relocation step rather than the assembler's expression evaluation. > "Relocation specifier" is clear, aligns with Arm and IBM’s usage, and fits the assembler's role seamlessly. In addition, rename MipsMCExpr::getKind, which confusingly shadows the base class getKind.
Follow the X86 and Mips renaming. > "Relocation modifier" suggests adjustments happen during the linker's relocation step rather than the assembler's expression evaluation. > "Relocation specifier" is clear, aligns with Arm and IBM’s usage, and fits the assembler's role seamlessly. In addition, rename *MCExpr::getKind, which confusingly shadows the base class getKind.
Use the more appropriate term "relocation specifier" and avoid the variable name `Kind`, which conflicts with MCExpr and FixupKind.
DenseSet, SmallPtrSet, SmallSet, SetVector, and StringSet recently gained C++23-style insert_range. This patch replaces: Dest.insert(Src.begin(), Src.end()); with: Dest.insert_range(Src); This patch does not touch custom begin like succ_begin for now.
DenseSet, SmallPtrSet, SmallSet, SetVector, and StringSet recently gained C++23-style insert_range. This patch replaces: Dest.insert(Src.begin(), Src.end()); with: Dest.insert_range(Src); This patch does not touch custom begin like succ_begin for now.
Follow the X86 and Mips renaming. > "Relocation modifier" suggests adjustments happen during the linker's relocation step rather than the assembler's expression evaluation. > "Relocation specifier" is clear, aligns with Arm and IBM AIX's documentation, and fits the assembler's role seamlessly. In addition, rename *MCExpr::getKind, which confusingly shadows the base class getKind.
Follow the X86, Mips, and RISCV renaming. > "Relocation modifier" suggests adjustments happen during the linker's relocation step rather than the assembler's expression evaluation. > "Relocation specifier" is clear, aligns with Arm and IBM AIX's documentation, and fits the assembler's role seamlessly. In addition, rename *MCExpr::getKind, which confusingly shadows the base class getKind.
The aarch64-cond-br-tuning pass transforms a CBZX instruction into a conditional branch (B.cond). One of the by products of the transformation is that the source instruction of the CBZX, which is an ANDXri instruction, gets transformed into a ANDSXri instruction, however this transformation doesn't preserve it's debug instruction number. This patch fixes that issue.
Co-authored-by: Jérôme Duval <jerome.duval@gmail.com>
Follow the X86, Mips, and RISCV renaming. > "Relocation modifier" suggests adjustments happen during the linker's relocation step rather than the assembler's expression evaluation. > "Relocation specifier" is clear, aligns with Arm and IBM AIX's documentation, and fits the assembler's role seamlessly. In addition, rename *MCExpr::getKind, which confusingly shadows the base class getKind.
Add MemorySSA checks in some GVN tests. This is first patch of the series and many more might come based on tests pass/fail.
In error cases, the base might be None. Fixes llvm/llvm-project#132257
Follow the X86, Mips, and RISCV renaming. > "Relocation modifier" suggests adjustments happen during the linker's relocation step rather than the assembler's expression evaluation. > "Relocation specifier" is clear, aligns with Arm and IBM AIX's documentation, and fits the assembler's role seamlessly. In addition, rename *MCExpr::getKind, which confusingly shadows the base class getKind.
Currently, 'wide' i32 simd multiplication, with extended i8 elements, will perform the multiplication with i32 So, for IR like the following: ``` %wide.a = sext <8 x i8> %a to <8 x i32> %wide.b = sext <8 x i8> %a to <8 x i32> %mul = mul <8 x i32> %wide.a, %wide.b ret <8 x i32> %mul ``` We would generate the following sequence: ``` i16x8.extend_low_i8x16_s $push6=, $1 local.tee $push5=, $3=, $pop6 i32x4.extmul_low_i16x8_s $push0=, $pop5, $3 v128.store 0($0), $pop0 i8x16.shuffle $push1=, $1, $1, 4, 5, 6, 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 i16x8.extend_low_i8x16_s $push4=, $pop1 local.tee $push3=, $1=, $pop4 i32x4.extmul_low_i16x8_s $push2=, $pop3, $1 v128.store 16($0), $pop2 return ``` But now we perform the multiplication with i16, resulting in: ``` i16x8.extmul_low_i8x16_s $push3=, $1, $1 local.tee $push2=, $1=, $pop3 i32x4.extend_high_i16x8_s $push0=, $pop2 v128.store 16($0), $pop0 i32x4.extend_low_i16x8_s $push1=, $1 v128.store 0($0), $pop1 return ```
Follow the X86, Mips, and RISCV renaming. > "Relocation modifier" suggests adjustments happen during the linker's relocation step rather than the assembler's expression evaluation. > "Relocation specifier" is clear, aligns with Arm and IBM AIX's documentation, and fits the assembler's role seamlessly. In addition, rename *MCExpr::getKind, which confusingly shadows the base class getKind. The parseSpecifier name follows Sparc.
The previous implementation incorrectly calculated incoming values from loop backedges, as demonstrated by the tests. The issue was that it did not distinguish between live-in and live-out values for blocks. This patch addresses the problem and fixes llvm/llvm-project#131761. To avoid bloating storage in `R.Defines`, processing data has been moved to a temporary map `BBInfos`. This change helps manage heap allocation more efficiently and likely improves caching.
The LoopInterchange cost-model consists of several decision rules. They
are called one by one, and if some rule can determine the profitability,
then the subsequent rules aren't called. In the current implementation,
the rule for `CacheCostAnalysis` is called first, and if it fails to
determine the profitability, then the rule for vectorization is called.
However, there are cases where interchanging loops for vectorization
makes the code faster even if such exchanges are detrimental to the
cache. For example, exchanging the inner two loops in the following
example looks about x3 faster in my local (compiled with `-O3
-mcpu=neoverse-v2 -mllvm -cache-line-size=64`), even though it's
rejected by the rule based on cache cost. (NOTE: LoopInterchange cannot
exchange these loops due to legality checks. This should also be
improved.)
```c
__attribute__((aligned(64))) float aa[256][256],bb[256][256],cc[256][256],
dd[256][256],ee[256][256],ff[256][256];
// Alternative of TSVC s231 with more array accesses than the original.
void s231_alternative() {
for (int nl = 0; nl < 100*(100000/256); nl++) {
for (int i = 0; i < 256; ++i) {
for (int j = 1; j < 256; j++) {
aa[j][i] = aa[j-1][i] + bb[j][i] + cc[i][j]
+ dd[i][j] + ee[i][j] + ff[i][j];
}
}
}
}
```
This patch introduces a new option to prioritize the vectorization rule
over the cache cost rule.
Related issue: #131130
---------
Co-authored-by: Florian Hahn <flo@fhahn.com>
In preparation for adding more gadget kinds to detect, streamline issue reporting. Rename classes representing issue reports. In particular, rename `Annotation` base class to `Report`, as it has nothing to do with "annotations" in `MCPlus` terms anymore. Remove references to "return instructions" from variable names and report messages, use generic terms instead. Rename NonPacProtectedRetAnalysis to PAuthGadgetScanner. Remove `GeneralDiagnostic` as a separate class, make `GenericReport` (former `GenDiag`) store `std::string Text` directly. Remove unused `operator=` and `operator==` methods, as `Report`s are created on the heap and referenced via `shared_ptr`s. Introduce `GadgetKind` class - currently, it only wraps a `const char *` description to display to the user. This description is intended to be a per-gadget-kind constant (or a few hard-coded constants), so no need to store it to `std::string` field in each report instance. To handle both free-form `GenericReport`s and statically-allocated messages without unnecessary overhead, move printing of the report header to the base class (and take the message argument as a `StringRef`).
…ith reduction clause. (#129938) Initial Parse/Sema support for reduction over private variable with reduction clause. Section 7.6.10 in in OpenMP 6.0 spec. - list item in a reduction clause can now be private in the enclosing context. - Added support for _original-sharing-modifier_ with reduction clause. --------- Co-authored-by: Chandra Ghale <ghale@pe31.hpc.amslabs.hpecorp.net>
Building clang under UBsan, it reported an integer overflow in this function when the input value was -2^63, because it's UB to pass the maximum negative value of an integer type to `std::abs`. Fixed by adding a new absolute-value function in `MathExtras.h` whose return type is the unsigned version of the argument type, and using that instead. (This seems like the kind of thing C++ should have already had, but apparently it doesn't, and I couldn't find an existing one in LLVM Support either.)
Fix getAccessRelation for 0-d memref accesses in certain cases. Fixes corner case crashes when using scalrep, affine dep analysis, etc. Fixes: llvm/llvm-project#132163
On Mac x86-64, the debugserver reports a register ('ds' at least) but
returns an error when we try to read it. Just skip storing such
registers in snapshots so we won't try to restore them.
We don't count canceled jobs on GCP, so we shouldn't count canceled jobs on Buildkite neither. Signed-off-by: Nathan Gauër <brioche@google.com>
Currently, we use `csrr` with `vlenb` to obtain the `VLEN`, but this is not the only option. We can also use `vsetvli` with `e8`/`m1` to get `VLENMAX`, which is equal to the VLEN. This method is preferable on some microarchitectures and makes it easier to obtain values like `VLEN * 2`, `VLEN * 4`, or `VLEN * 8`, reducing the number of instructions needed to calculate VLEN multiples. However, this approach is *NOT* always interchangeable, as it changes the state of `VTYPE` and `VL`, which can alter the behavior of vector instructions, potentially causing incorrect code generation if applied after a vsetvli insertion. Therefore, we limit its use to the prologue/epilogue for now, as there are no vector operations within the prologue/epilogue sequence. With further analysis, we may extend this approach beyond the prologue/epilogue in the future, but starting here should be a good first step. This feature is gurded by the `+prefer-vsetvli-over-read-vlenb` feature, which is disabled by default for now.
…(#130565) At the moment if we decide to enable tail-folding we do not include the cost of generating the mask per VF. This can mean we make some poor choices of VF, which is definitely true for SVE-enabled AArch64 targets where mask generation for fixed-width vectors is more expensive than for scalable vectors. I've added a VPInstruction::computeCost function to return the costs of the ActiveLaneMask and ExplicitVectorLength operations. Unfortunately, in order to prevent asserts firing I've also had to duplicate the same code in the legacy cost model to make sure the chosen VFs match up. I've wrapped this up in a ifndef NDEBUG for now. The alternative would be to disable the assert completely when tail-folding, which I imagine is just as bad. New tests added: Transforms/LoopVectorize/AArch64/sve-tail-folding-cost.ll Transforms/LoopVectorize/RISCV/tail-folding-cost.ll
The RISC-V Debug Specification defines multiple names for these CSRs. https://github.com/riscv/riscv-debug-spec/releases/tag/1.0
…(#132268) - Move LLVMDISubrangeTypeMetadataKind to end of LLVMMetadataKind enum. Inserting a new enum constant in the middle of the enum breaks the ABI for that enum. Commit e298fc2 introduced this issue, which was revealed because the OCaml binding tests failed. - Bring OCaml bindings up to date with LLVMMetadataKind enum.
DenseSet recently gained a range constructor: DenseSet<T> Dest(llvm::from_range, Src); This patch adds the same signature to SmallSetVector for consistency.
We can use *Set::insert_range to collapse:
for (auto Elem : Range)
Set.insert(E);
down to:
Set.insert_range(Range);
In some cases, we can further fold that into the set declaration.
…TED` (#132593) And use it for test cases that became constant-evaluation-suitable due to P2562R1. `TEST_STD_AT_LEAST_(20|23)_OR_RUNTIME_EVALUATED` are the precedents.
The "extensible_" prefix on these files was inherited from LLVM, where it distinguished the dynamic RTTI APIs from the LLVM's custom static RTTI APIs. In the ORC runtime these files will be used to hold all of our RTTI APIs (the current dynamic ones, and any static ones added in the future), so we shouldn't use this prefix.
Add all types pattern for bitcast on VReg_512
We can use *Set::insert_range to collapse:
for (auto Elem : Range)
Set.insert(E);
down to:
Set.insert_range(Range);
A bare-bones version of LLVM's unique_function: this behaves like a std::unique_function, except that it supports move only callable types. This will be used in upcoming improvements to the ORC runtime.
…3c2731ce46f01a984a9cc1807207de8d333bc350
jorickert
marked this pull request as ready for review
July 23, 2026 08:41
jorickert
requested review from
F-Stuckmann,
SagarMaheshwari99,
abhinay-anubola,
abnikant,
andcarminati,
katerynamuts,
khallouh,
konstantinschwarz,
martien-de-jong,
mludevid,
niwinanto,
philippjh and
stephenneuendorffer
as code owners
July 23, 2026 08:41
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
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.
Skipped/reverted the following changes:
7c11d05 2025-03-21 [mlir][TosaToLinalg] Exit after
notifyMatchFailure(#132012)4dd7fea 2025-03-21 [mlir][tosa] Add more error_if checks for Resize Op (#132290)
fbc1038 2025-03-19 [mlir][TosaToLinalg] Only support ranked tensor for
reduceandgather(#131805)1456eab 2025-03-19 [mlir][tosa] Finalize profile-based validation for TOSA v1.0 (#131208)
b251c29 2025-03-18 [mlir][tosa] Update PadOp examples in the dialect description (#131919)
0c34d7a 2025-03-17 [mlir][tosa] Require operand/result tensors of at least rank 1 for some operations
(#131335)
955c02d 2025-03-14 [mlir][tosa] Check for compile time constants in the validation pass (#131123)
1c45514 2025-03-13 [mlir][tosa] Fix bug causing quantized pad const creation crash (#131125)
c44c905 2025-03-12 [mlir][tosa] Add error if verification to pooling operators (#130052)
913d077 2025-03-11 [mlir][tosa] Change Rescale zero points to be inputs (#130340)
89fa592 2025-03-11 [mlir][tosa] Update Matmul description to align with spec (#130835)
933221e 2025-03-10 [mlir][tosa] Rename RFFT2D
inputtoinput_real(#130614)483c23f 2025-03-10 [mlir][tosa] Switch zero point of negate to input variable type (#129758)
3fb8cb6 2025-03-10 [mlir][tosa] Add support for EXT-DOUBLEROUND and EXT-INEXACTROUND (#130337)
967ab7e 2025-03-10 [mlir][TOSA] Fix linalg lowering of depthwise conv2d (#130293)
highlight commits:
2c35cb6 2025-03-16 [MC] Remove unneeded getNumFixupKinds
7722d75 2025-03-15 [MC] evaluateAsRelocatableImpl: remove the Fixup argument
441c9a9 2025-03-22 [MC] Delete deprecated fixELFSymbolsInTLSFixups
6962cf1 2025-03-14 Rename ExpandLargeFpConvertPass to ExpandFpPass (#131128)
llvm/llvm-project#127943 conflicts with our changes for affine maps, I just update the test for the current output, we may need to come back to this in the future
llvm/llvm-project#132252 Split clang/lib/CodeGen/CGBuiltin.cpp, did the same for our AIE builtins and moved them to llvm-project/clang/lib/CodeGen/TargetBuiltins/AIE.cpp