[VPlan] Simplify extracts of the last lane of live-ins (#231312)
Live-ins are single scalars, so simplify their extracts like other
single-scalar live-in values.
This allows reusing a single resume phi for multiple reductions whose
results fold to the same live-in.
[llvm][test] Add -filetype=null to llc disable-mir-output-verify test (#231305)
The -passes=no-op-machine-function RUN lines did not specify
-filetype=null, causing llc to attempt to write to the source directory
(which fails when the test input directory is read-only). Follow-up to
663669080864 (#228248 ).
[LAA] Include the load types of written pointers in runtime check bounds. (#231039)
canCheckPtrAtRT creates the runtime check pointers of a pointer that is
both loaded and stored only via its write access, with the types in
Accesses[{Ptr, true}]. Those are the stored types only.
Also include the types the pointer is used in loads. Create runtime
checks for the largest fixed and scalable types, if any.
This fixes a miscompile where the pointer is used to load a wider type
than it stores to.
[LV] Allow stride-scaled canonical IV users when preparing the epilogue (#231307)
convertToStridedAccesses computes the base pointer of a strided access
from the canonical IV, as a mul by the stride (simplified to a shl for a
power-of-2 stride). preparePlanForEpilogueVectorLoop asserted that the
canonical IV is only used by its increment, casts, ScalarIVSteps or
DerivedIV, so forcing epilogue vectorization of a loop with a strided
access hit the assertion.
Offsetting the canonical IV by the main loop's resume value is correct
for those users too, as they are linear in the canonical IV. Allow them
in the assertion.
[LV] Add test for FindIV reduction with wrapping truncated IV (NFC). (#231297)
Add a test where the truncated IV's signed range excludes the sentinel
value, but the IV wraps. The min reduction currently returns the wrong
value.
WebAssembly: Take the exception model from the module flag
The WebAssembly EH passes chose whether and how to run from
MCAsmInfo::getExceptionHandlingType() and TargetOptions::ExceptionModel,
A module that asked for Wasm EH through the module flag alone would have
its invokes rewritten by LowerInvoke before WasmEHPrepare ran.
Schedule the passes unconditionally and read the module flag inside the
passes instead. Passes for other models can noop on the models they are
not intended for.
Co-authored-by: Claude Opus 5 <noreply at anthropic.com>
TableGen: Emit GlobalISel combiner apply roots in a deterministic order
Rules with more than one apply root emitted them in an order that
depended on pointer values, so the generated combiners for AArch64,
AMDGPU and RISC-V changed between runs. Use a SetVector instead of a
DenseSet.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[AMDGPU][NFC] Clean up packed convert tests (#229178)
Drop intrinsic declarations. Convert kernel tests to amdgpu_ps
functions returning the result, with inreg args for SGPR operands
instead of kernarg loads. amdgpu_ps avoids the callable function
prolog and epilog. Merge check prefixes where SDAG, GlobalISel and
subtargets now produce identical output.
gfx1250 tests use the default calling convention: entry functions
there get a workaround sequence longer than that prolog.
TableGen: Pack the RecordVal used flag with its type (#231288)
Every record holds a copy of every field it inherits, so RecordVal makes
up most of tablegen's memory use. Store the used flag alongside the
field kind in the spare low bits of the type pointer instead of in a
separate bool. This shrinks RecordVal from 56 to 48 bytes.
Parsing AMDGPU.td with llvm-tblgen --null-backend, peak memory drops
from 934 MB to 834 MB with 10% fewer page faults.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
AMDGPU: Only use 16-bit atomic loads when D16 preserves unused bits (#230944)
Make the atomic load/store legality match the hardware operand
structure. A 16-bit atomic load only produces a real 16-bit result
with the true16 D16 loads, which require d16PreservesUnusedBits. With
SRAMECC enabled the true16 patterns use a 32-bit load and extract the
low half, so promote i16, f16 and bf16 atomic loads to an i32 extending
load instead. Atomic stores remain 16-bit with real true16, since the
store source is a 16-bit register regardless.
Remove the true16 sramecc atomic load patterns which are now dead.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[MISched] Fix cluster dump crash (#231176)
The test case would crash before this patch because in that context the
SUnit can be an ExitSU thus it would assert inside the new SUnit
operator<<. Should use `dumpNodeName()`.
I plan to fix other callers in a followup - though those callers are not
crashing but merely print a "random" number.
[AMDGPU] Make xnack-support generic any feature. NFCI (#231290)
This allows to include targets with and w/o xnack into a same
generic target. Generic target shall have xnack enabled in this
case.
[MLIR][ROCDL] Note the deprecation of the <4 x i32> buffer ops
While we don't have a way to flag a MLIR op as deprecated yet, go
ahead and add a note to the old `<4 x i32>` intriinsic ops that
they're actively deprecated.
AI disclosure: Claude made this edit, though I checked the wording and
wrote up this message.
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[AMDGPU][docs] Document the <4 x i32> buffer intrinsic deprecation
Flag the deprecation of <4 x i32> buffer intrinsics in the release
notes, flagging the migration path and the s.buffer.load subtleties.
AI disclosure: Claude did draft some of this, but I deleted basically
all of it and the words are mine
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[AMDGPU] Warn for using <4 x i32> buffer intrinsics
The buffer intrinsics that take their resource as a <4 x i32> have been
documented as deprecated in IntrinsicsAMDGPU.td for some time, but only
in a TableGen comment, so nothing told users about it. They've all got
`ptr addrspace(8)` counterparts now that #209243 landed, so we can be
slightly more official about asking people to move.
The warning lives in AMDGPUAsmPrinter::doInitialization next to the
no-subarch deprecation warning.
We warn once per intrinsic used, not once per call (it'd cause
unbounded warning spam) and not once per declaration (it'd catch the
same intrinsic but with different types repeatedly). We try to be
clever to point at a specific call if we can find one with a debug
location.
Users can pass -amdgpu-warn-deprecated-buffer-intrinsics=0 to suppress
this.
[5 lines not shown]
[AMDGPU][NFC] Add d16 integer coverage for raw.ptr.buffer.load.format
raw.ptr.buffer.load.format didn't have test coverage for the d16
paths, while other related intrinsics (like the non-`.ptr` versions)
did. This commit fixes the issue.
AI disclosure: Claude wrote these tests
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[AMDGPU] Let llvm.amdgcn.raw.ptr.buffer.load.format also return any type
While llvm.amdgcn.raw.buffer.load.format can handle any type, and so
can llvm.amdgcn.struct.ptr.buffer.load.format,
llvm.amdgcn.raw.ptr.buffer.format is restricted to floats for some
reason, probably somebody forgetting to loosen it.
This commit fixes the issue so integer-format typed loads can migrate
off of the non-pointer intrinsic.
AI disclosure: Claude noticed it when I asked it draft up a stronger
deprecation for the non-ptr intrinsics, and I wrote the commit message.
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[AMDGPU][NFC] Pre-commit test for integer raw.ptr.buffer.load.format
llvm.amdgcn.raw.ptr.buffer.load.format is restricted to floats for
some reason, even though it doesn't need to be (per its non-`.ptr`
counterpart). Pre-commit tests for the integer form.
AI disclosure: Claude wrote these tests, I wrote the message, the big
comment is temporary.
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[AMDGPU][NFC] Use ptr ops in ptr.buffer.atomic.fadd_rtn_errors.ll
llvm.amdgcn.ptr.buffer.atomic.fadd_rtn_errors.ll had tests that were
using the deprecated `<4 x i32>` intrinsics. This commit fixes the
issue.
AI disclosure: Claude found this and made the change, I wrote this
message and reviewed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
lldb: Try to fix flaky tests
The lldb api test are extremely flaky and have been pissing me off for
a long time. These constantly block my automerges, usually at least
once per day. This was exceptionally painful during the recent github
breakage where automerge was the only way to submit anything. This is
a pure slop fix.
Wait for the private state thread before destroying a process
StopForDestroyOrDetach only halted the process if the public or private
state was running. After an SBProcess::Continue from another thread, both
can say stopped while the private state thread is still handling the next
stop. DestroyImpl then discarded thread plans concurrently with it, which
hit the "Can't pop the base thread plan" assert.
Let the private state thread finish its pending events first, and also
halt if the last broadcast state was running.
[5 lines not shown]
[DAG] isConstOrConstSplat - add handling for ISD::MERGE_VALUES nodes (#231220)
Also ensure isBoolConstant gets its ValueType from the SDValue's correct
ResNo
Addresses the missed constant fold identified in #228877
[AMDGPU] Refactor builtin tests for gfx1310 runs. NFC (#231284)
Move builtins gfx1310 lacks from builtins-amdgcn-gfx1250.cl to
builtins-amdgcn-gfx1250-only.cl so the remainder can also run on
gfx1310. Moved checks are unchanged.
Add gfx1250 and gfx1310 runs to builtins-amdgcn-gfx12.cl and gfx1310
runs to the barrier llc tests.
Assisted by: Claude
