[MLIR][spirv] Shard generated operation definitions (NFC) (#221811)
Generate SPIR-V operation definitions in eight shards and use the
generated registration hook. Keep parser, printer, and verification
helpers in the existing implementation TU and expose them through a
private header.
Assisted-by: Codex
[AMDGPU] Route no-modifier reg-or-inline AsmParser operands through HwMode predicate
Convert the reg-or-inline operands with no modifiers (MFMA VGPR/AGPR
sources, VCSrc, v_pk_mov_b32, VOP scalar f64) from the fixed-class
isRegOrInlineNoMods to the HwMode-aware isRegOrInlineNoModsByHwMode, so an
odd-aligned tuple is rejected at the offending operand column instead of by
the validateVGPRAlign catch-all.
Co-Authored-By: Claude <noreply at anthropic.com>
[SPIRV] Add matrix type legalization for many float global opcodes (#220782)
fixes #220723
The issue in #220723 is that the global opcodes can not deduce the
element type when the input is a shuffle vector. This is the same issue
as #213783. All we have to do to fix this is to have deduceTypeFromUses
in the SPIRVPostLegalizer know that we need to look up the type from the
results register for these opcodes.
The secondary issue is that there were no matrix tests for any of these
global opcodes so I added them. I did not follow the template started by
the atan2 tests because those are overkill and testing way to much stuff
not related to opcode legalization.
Assisted on the tests by MAI-Code-1.1-Flash
[clang-format] Recognize the signed modifier for Verilog struct (#219694)
after
```SystemVerilog
struct packed signed {
int a;
} pack1;
```
before
```SystemVerilog
struct packed signed { int a; }
pack1;
```
CodeGen: Remove TargetOptions::PPCGenScalarMASSEntries
This was PPC specific and wasn't directly written by a generic cl::opt.
It also was inappropriately written based based on a check of the flag
in the TargetPassConfig, which is only likely to be the first use.
Co-authored-by: Claude (Claude-Opus-4.8)
[lld] Add caching for `--lto-partitions`
Add an opt-in cache for the (full) LTO partitions generated via `--lto-partitions=N` when `N > 1`.
This is primarily for AMDGPU but implemented in a target-agnostic way. The goal is to avoid recompiling entire very large modules (can be hundreds of megabytes of bitcode) if someone just changed a single function or two, which don't affect most partitions.
This uses the LTO Config hash + a hash of the bitcode module itself. This is a very conservative approach, we may be able to fine-tune it to improve cache hits if it turns out the hit rate is poor.
Solves LCOMPILER-59
[AMDGPU] Add synthetic apertures and use them for barriers
Define what a synthetic aperture is, and adjust the barrier AS
to use this new system. This makes the barrier AS even safer to
use as now we can use all 32 bits of it without ever risking
hitting a valid address of any kind (LDS or outside LDS).
[RFC][AMDGPU] Add BARRIER address space
Add a new BARRIER address space that is used for global variables that are used to represent the barrier IDs in GFX12.5.
These barrier addresses just have values corresponding 1-1 to barrier IDs. They are still implemented on top of LDS, but the offsetting happens during an addrspacecast to generic, not whenever the barrier GV is used.
The motivation for this is to make the relation between LDS and barrier GVs explicit in the compiler. It does add a bit more complexity, but that complexity was already there, just hidden by pretending barrier GVs were actual LDS.
[AMDGPU] Prefer packed minimum/maximum ops for two-input ops (#215449)
A two-input f16 fminimum or fmaximum operation should translate to a
packed two-input minimum/maximum instruction when the target supports
one.
It currently can be selected through the minimum3/maximum3 fallback
pattern instead. That emits a three-input instruction with one input
operand duplicated.
Keep the fallback for nested min/max expressions that can use the real
three-input instruction. Add a higher-priority direct pattern for
non-nested two-input operations on targets with packed IEEE
minimum/maximum opcodes.
[mlir][vector] Update `CastAwayTransfer{Read|Write}LeadingOneDim` (#219499)
Updates `CastAwayTransfer{Read|Write}LeadingOneDim` to use
`vector.shape_cast`, rather than `vector.extract`, as the canonical form
for stripping unit dimensions.
This change was originally implemented by @krzysz00 in #196206, but was
subsequently reverted in #199546. This PR intentionally restores only a
subset of #196206, making it easier to identify and triage any potential
regressions.
Co-authored-by: Krzysztof Drewniak <Krzysztof.Drewniak at amd.com>
[RISCV][GlobalISel] Fold large constant offsets in selectAddrRegImm (#219161)
Fold ADDI adjustment (AddiPair) for offsets in [-4096, 4094] and split
larger constants into materialized Hi + Lo12 offset, matching SDAG. Add
isWorthFoldingAdd to guard the split and extract the shared ADDI
renderer into renderAddiPair.
Assisted-by: Claude
[clang][AST] Fix infinite recursion when printing fully qualified template parameters (#219044)
This fixes an infinite recursion crash that was introduced in #206041.
When printing a `DeclRefExpr` using
`PrintingPolicy::FullyQualifiedName`, we were previously trying to print
the fully qualified name of all decls. However, when the decl is a
template parameter, its `DeclContext` is the template specialization
itself. If a template specialization's arguments depend on that same
template parameter (e.g., `template<int Count> struct
View<int[Count]>`), attempting to print the qualified name forces Clang
to recursively evaluate the enclosing context. This led to unbounded
recursion (`View<int[Count]>::Count` ->
`View<int[View<int[Count]>::Count]>::Count` and so on). Since template
parameters are inherently scoped to their template declarations and do
not require a fully qualified name, this patch resolves the issue by
skipping `printQualifiedName` if the decl is a template parameter
(`!VD->isTemplateParameter()`).
Fixes #218076.
