NVPTX: Add target names in TargetParser
Track the canonical sm name and other target information.
This will eventually be used to reduce the pain of maintaining
OffloadArch in clang; all of the dijoint targets share an
enum which makes target specific covered switches annoying.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
[AArch64] Mark FIXED_REGS register class as non-allocatable (#212250)
FIXED_REGS is not used for register allocation, but since it overlaps
the GPR classes via FP and SP, TableGen merges VG and FFR into the GPR
pressure set, giving it a static limit of 35.
The underlying GPR32all class has 33 registers: W0-W30, WZR, and WSP.
WZR and WSP are always reserved, leaving up to 31 allocatable registers
depending on whether W29 (FP) and W30 (LR) are reserved.
Marking FIXED_REGS non-allocatable removes VG and FFR from the pressure
set, reducing its static limit from 35 to 33 and its dynamic limit from
33 to 31. The corrected limit changes scheduling decisions made by the
register-pressure heuristics, which explains the test churn.
Assisted-by: codex
NVPTX: Add target names in TargetParser
Track the canonical sm name and other target information.
This will eventually be used to reduce the pain of maintaining
OffloadArch in clang; all of the dijoint targets share an
enum which makes target specific covered switches annoying.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
[AMDGPU] Fix incorrect VM_VSRC simplification after async instruction (#212481)
Add ASYNC_CNT to the list of VMEM counters. The implication is that only
if all these counters are zero can we know that there are no outstanding
VMEM instructions, so VM_VSRC must be zero.
[LLVM][CodeGen][SVE] Add ElementSize information to fp compare, continuous/replicating load and store instructions (#204821)
This information was originally used to implement MOVPFRX support.
However https://github.com/llvm/llvm-project/pull/204820 uses the same
information to determine which bits of an instruction's predicate
operand are used so that PTRUE instructions can be coalesced.
MOVPRFXable instructions are a subset of all predicated instructions, so
this patch extends some non-MOVPRFXable instructions with ElementSize
information.
DAG: Use poison in getLoad/getStore for offsets
The painful part of this is due to a few unfortunate things.
1. poison is legalized to undef
2. Non-indexed load/store encode the offset as an undef (which is
not like a TargetConstant, and does get legalized)
3. 2 asserts in DAGCombiner expect identical load/store nodes,
which assumes the offset will be preserved and not converted
between poison and undef
4. The getLoad/getStore overloads are a mess, and a path was missing
to recreate the store case with the original offset.
AMDGPU/GlobalISel: Fix Vcc reg bank apply method for sgpr i1 input (#212532)
Need to clean up high bits on sgpr bool use, simlar to Sgpr32AExtBoolInReg.
G_AMDGPU_COPY_VCC_SCC assumes clean (zero) high bits in sgpr i32 input.
This should be combined away in most cases, for example if input is result
of a compare. But should stay for example for truncated input from s_load.
[libc++] Mark LWG3133 as Complete and add valarray operator[] safety tests (#208145)
This verifies that libc++ has implemented the resolution of LWG3133,
which modernizes the requirements on `T` for `std::complex<T>` and
`std::valarray<T>` in [numeric.requirements].
- No code changes were needed for `std::valarray<T>`: its `operator[]`
already indexes through a raw pointer and never relies on a
user-overloadable `operator&`, so it already conforms to the revised
wording.
- Added o`perator_hijacker`-based tests to `valarray`'s
`access.pass.cpp`/`const_access.pass.cpp`, confirming `operator[]`
doesn't rely on a user-overloadable `operator&`.
QuantileType relax quantileType conditions and inheritance issue (#204793)
# Recategorize QuantileType as Storage Format, Not Quantization Scheme
## Summary
Reclassify `QuantileType` from inheriting `QuantizedType` to functioning
as a pure storage type.
## Motivation
### QuantileType is a Storage Format, Not a Quantization Scheme
After careful consideration, there was a conclusion reached that
**QuantileType should not be registered as a subtype of QuantizedType**.
The architectural distinction is critical:
- **QuantizedType** represents different quantization schemes (uniform,
per-axis, etc.), semantic operations that map values into a
[25 lines not shown]
[flang] Remove legacy stack-arrays and memory-allocation-opt passes
The unified allocation-placement pass now supersedes both the heap-to-stack
stack-arrays pass and the stack-to-heap memory-allocation-opt pass, and is the
default in the FIR optimizer pipeline. Remove the two legacy passes: their
TableGen definitions, the MemoryAllocation.cpp source, the memory-allocation-opt
command-line options, the enable-allocation-placement fallback switch, and the
addMemoryAllocationOpt pipeline helper. The pass-only portions of
StackArrays.cpp are dropped while its analysis and rewrite pattern, now shared
with allocation-placement, are kept.
The legacy tests are retargeted onto allocation-placement to show it reproduces
both prior behaviors: the stack-arrays tests use "stack-arrays=true", and the
memory-allocation-opt tests use the default policy (runtime-sized and big
constant-size temporaries go on the heap).
[flang] Enable allocation-placement pass by default
Make the unified allocation-placement pass the default in the FIR optimizer
pipeline in place of the legacy stack-arrays and memory-allocation-opt passes,
by defaulting -enable-allocation-placement to true. Passing
-enable-allocation-placement=false restores the legacy passes for comparison.
Add a -disable-allocation-placement switch that skips the pass entirely (wired
through addAllocationPlacement like the other optimizer passes), so codegen
tests can opt out of placement policy independently of the legacy fallback.
Update the pipeline-dump tests to expect AllocationPlacement, and disable the
pass in the alloca/allocmem codegen tests (alloc.fir, coordinateof.fir) so they
keep testing lowering rather than placement policy. Document the unified pass,
its policy, thresholds, and options in fstack-arrays.md.
[flang] Wire allocation-placement into the optimizer pipeline (experimental)
Add a hidden -enable-allocation-placement flag that, when set, replaces the
stack-arrays and memory-allocation-opt passes in the default FIR optimizer
pipeline with the unified allocation-placement pass. The flag is off by
default, so the legacy passes remain the default path and behavior is
unchanged.
When enabled, the pass runs with its default byte-size thresholds; the
-fstack-arrays strategy is forwarded through the new stackArrays option.
[Offload] Enable offload test on Windows (#212480)
Description:
This change enables the offload test build on Windows by adding
compatibility guards around libomptarget test suites.
Why:
libomptarget is not available on Windows. Without these guards, CMake
fails when referencing the missing omptarget target. With these guards,
Windows builds complete successfully and run available tests (using
check-offload-unit), while Linux/macOS builds remain unaffected.
[flang] Add policy-driven allocation-placement pass - memory passes unification [2/5] (#210742)
Introduce a new function-level pass, allocation-placement, that unifies
the stack/heap placement decisions currently split between the
stack-arrays and memory-allocation-opt passes. For each array allocation
it consults a policy to decide whether it should live on the stack
(fir.alloca) or the heap (fir.allocmem) and rewrites it accordingly,
reusing fir::replaceAllocas for stack-to-heap and the StackArrays
analysis/rewrite for heap-to-stack (so heap-to-stack only happens where
it is provably safe).
The default policy (AllocationPlacementPolicy.h) is threshold-driven:
- small constant-size arrays go on the stack within a per-function stack
budget, otherwise on the heap;
- big constant-size arrays: user variables stay on the stack,
temporaries go on the heap;
- runtime-sized arrays go on the heap;
- an aggressive mode places all arrays on the stack (best effort). User
variables are distinguished from compiler temporaries via the presence
[6 lines not shown]
[APINotes] Diagnose invalid Where.Parameters selectors (#209408)
This PR adds diagnostics for exact `Where.Parameters` selectors on top
of the existing parsing, serialization, and Sema matching support.
It diagnoses duplicate exact selectors during API notes conversion,
including duplicate `Where.Parameters: []`, while still allowing broad
name-only entries and same-name entries with different selectors.
It also adds reader/Sema support to warn under `-Wapinotes` when an
exact selector in API notes does not match any visible overload. The
reader can now enumerate stored exact selectors for global functions and
C++ methods, and Sema compares those against the selector candidates
derived from the visible overload set.
The diagnostic path follows the same matching policy as Sema, including
the desugared alias fallback, so valid matched selectors do not produce
false warnings.
[9 lines not shown]
[clang][bytecode][NFC] Add CHECK markers for functions in test (#212699)
We aren't testing the existence of the function in the output here, but
without these markers, debugging test failures here can become very
cumbersome.
[X86] Remove TuningFastSHLDRotate from BMI2 targets (#211217)
This flag has no effect at `x86-64-v3` or `v4`. It only enables a pseudo
that lowers `rotl`/`rotr` by immediate to `shld $imm, %reg, %reg`, but a
higher-priority `RORX` pattern matches the same case and always wins the
iSel tie.
Both patterns match `rotl(GR64, imm)`; only their `AddedComplexity`
differs:
```
// X86InstrShiftRotate.td:507 -- SHLD-rotate pseudo, complexity 5
let Predicates = [HasFastSHLDRotate], AddedComplexity = 5, ... in {
def SHLDROT64ri : ... [(set GR64:$dst, (rotl GR64:$src1, (i8 imm:$shamt)))]>;
}
// X86InstrShiftRotate.td:602 -- RORX pattern, complexity 10, only needs BMI2
let AddedComplexity = 10 in {
def : Pat<(rotl GR64:$src, (i8 imm:$shamt)),
[7 lines not shown]
[Docs][AMDGPU] availability/visibility in addrspace(3)
addrspace(3) on AMDGPU corresponds to LDS, which is a fast memory directly
accessed by all threads in a workgroup (there is no intervening cache). Thus,
any accesses to this addrspace have built-in availability and visibility at
"workgroup" scope.
AMDGPU: Add supports-wgp subtarget feature
Whether the hardware supports WGP (work-group processor) execution mode is a
fixed per-GPU capability, distinct from the per-kernel cumode selection. Add
a dedicated feature instead of inferring from the generation and instructions.
Co-authored-by: Claude (Claude-Opus-4.8)
