[all-commits] [llvm/llvm-project] 4ac9b5: [AMDGPU] Verify VGPR tuple alignment from the oper...
Valery Pykhtin via All-commits
all-commits at lists.llvm.org
Wed Sep 9 06:19:15 PDT 2026
Branch: refs/heads/users/vpykhtin/amdgpu-align-verifier-reframe
Home: https://github.com/llvm/llvm-project
Commit: 4ac9b563698da5b71c2729b373a2ad4034b91b64
https://github.com/llvm/llvm-project/commit/4ac9b563698da5b71c2729b373a2ad4034b91b64
Author: Valery Pykhtin <valery.pykhtin at amd.com>
Date: 2026-09-09 (Wed, 09 Sep 2026)
Changed paths:
M llvm/lib/Target/AMDGPU/SIInstrInfo.cpp
M llvm/lib/Target/AMDGPU/SIRegisterInfo.cpp
M llvm/lib/Target/AMDGPU/SIRegisterInfo.h
M llvm/test/CodeGen/AMDGPU/verify-ds-gws-align.mir
M llvm/test/CodeGen/AMDGPU/verify-gfx90a-aligned-vgprs.mir
M llvm/test/MachineVerifier/AMDGPU/unsupported-subreg-index-aligned-vgpr-check.mir
M llvm/test/MachineVerifier/AMDGPU/unsupported-unaligned-vgpr-check-vsrc-operand.mir
Log Message:
-----------
[AMDGPU] Verify VGPR tuple alignment from the operand register class
The machine verifier decided VGPR tuple alignment with isProperlyAlignedRC(),
which inspects only the register's own class. Alignment is not really a property
of the register in isolation: whether a 64-bit tuple must be even-aligned depends
on the operand it feeds, and on mixed-alignment targets the same register class
can be required to be aligned in one operand and exempt in another. Inspecting
only the register also conflates alignment with unrelated problems - a register
that is simply the wrong bank or size for the operand came out as "requires even
aligned vector registers" as well.
Make the operand's register class the source of truth instead: a register is
misaligned only when it does not satisfy the operand's class but its even-aligned
same-bank/width equivalent (SIRegisterInfo::getAlignedEquivalentRC) would. A
register that fits neither is a genuine class or bank mismatch and is left to the
illegal-register and sub-register checks. So an AGPR in a VGPR|SGPR (VS_64)
operand is now reported as an illegal register, and a wrong-size register (e.g. a
64-bit VGPR in a 128-bit MFMA source) or an invalid sub-register index is
reported by those checks alone, no longer doubled up as an "even aligned" error.
This drops the redundant diagnostics in tests.
Deriving the requirement from the operand class also lets several special cases
go away. The RegClass == -1 early-out is hoisted so the operand class is always
valid, and the V_MOV_B64_PSEUDO / AV_MOV_B64_IMM_PSEUDO / spill exemptions are
dropped: those operands use unaligned register classes (VReg_64, AV_64, and the
spill classes), which every register already satisfies, so the comparison never
flags them. Inline-asm operands (RegClass == -1) are no longer alignment-checked,
matching the prior FIXME that they were never meaningfully verified.
The same reasoning removes the DS_GWS-specific alignment check: on subtargets
that require aligned VGPRs the DS_GWS data0 operand has the AV_64_Align2 register
class, so the operand-class check above already diagnoses its alignment and the
separate check is redundant. The image vaddr operand is a plain VGPR_32 whose
class cannot encode even-alignment, so its dedicated position check is kept.
Co-Authored-By: Claude <noreply at anthropic.com>
Commit: eb16d6773ac4044bd4d901b82755ac6ba2499b96
https://github.com/llvm/llvm-project/commit/eb16d6773ac4044bd4d901b82755ac6ba2499b96
Author: Valery Pykhtin <valery.pykhtin at amd.com>
Date: 2026-09-09 (Wed, 09 Sep 2026)
Changed paths:
M llvm/lib/Target/AMDGPU/SIInstrInfo.cpp
M llvm/lib/Target/AMDGPU/SIRegisterInfo.cpp
M llvm/lib/Target/AMDGPU/SIRegisterInfo.h
M llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp
M llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.h
Log Message:
-----------
[AMDGPU] Match the AsmParser's operand-side check and share its helper
In the upcoming PR AsmParser performs the same alignment check but differently:
it tests whether a concrete physreg, which carries no regclass, is in the
relaxed operand's regclass.
Change the verifier to work the same way, reusing
AMDGPUBaseInfo::getUnalignedEquivalentRC.
Co-Authored-By: Claude <noreply at anthropic.com>
Commit: 90acd6cf5007a22e9e8639e0bc26d7b51e0111c8
https://github.com/llvm/llvm-project/commit/90acd6cf5007a22e9e8639e0bc26d7b51e0111c8
Author: Valery Pykhtin <valery.pykhtin at amd.com>
Date: 2026-09-09 (Wed, 09 Sep 2026)
Changed paths:
M llvm/lib/Target/AMDGPU/SIInstrInfo.cpp
M llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp
M llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.h
M llvm/test/CodeGen/AMDGPU/verify-ds-gws-align.mir
M llvm/test/CodeGen/AMDGPU/verify-gfx90a-aligned-vgprs.mir
M llvm/test/CodeGen/AMDGPU/verify-image.mir
M llvm/test/CodeGen/AMDGPU/verify-vimage-vsample.mir
M llvm/test/MachineVerifier/AMDGPU/unsupported-unaligned-vgpr-check-vsrc-operand.mir
Log Message:
-----------
[AMDGPU] Drop the redundant operand register-class verifier check
The generic MachineVerifier already rejects a register operand whose
class does not fit the instruction's operand class, for both virtual
(hasSuperClassEq / getMatchingSuperRegClass) and physical (contains)
registers, using the HwMode-resolved operand class. On subtargets that
require aligned VGPRs that class is the even-aligned one, so the generic
check catches a misaligned tuple on its own.
Remove SIInstrInfo::verifyInstruction's own alignment and physical
register-class checks and the now-unused getUnalignedEquivalentRC helper.
Misaligned tuples now report the generic "Illegal virtual/physical
register for instruction" instead of "Subtarget requires even aligned
vector registers"; a bad physical class reports the same instead of
"Operand has incorrect register class".
Compare: https://github.com/llvm/llvm-project/compare/d8b59c024c09...90acd6cf5007
To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications
More information about the All-commits
mailing list