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.
Pull up the following revisions(s) (requested by joe in ticket #1315):
sys/dev/raidframe/rf_disks.c: revision 1.96-1.97
Use the right assertions to ensure that all IOs are suspended.
zero indicates that IOs resume.
PR kern/60477
sysutils/rdfind: add support for xxhash
In the current form - the support for xxhash depends on whether or not
xxhash is installed in the system where the port is built. See
https://github.com/pauldreik/rdfind#development.
This commit makes (lack of) support for xxhash explicit. If the option
is enabled - the xxhash is added to dependencies and built into rdfind,
if disabled - xxhash support is disabled even if the library is present
in the system.
Reviewed by: dtxdf
Differential Revision: https://reviews.freebsd.org/D58398
[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&`.
