[all-commits] [llvm/llvm-project] 2bbe58: [AMDGPU] Verify VGPR tuple alignment from the oper...

Valery Pykhtin via All-commits all-commits at lists.llvm.org
Wed Sep 9 22:34:04 PDT 2026


  Branch: refs/heads/users/vpykhtin/amdgpu-align-verifier-reframe
  Home:   https://github.com/llvm/llvm-project
  Commit: 2bbe5809a17a5c5bf643890f1ed5f1acbdbede32
      https://github.com/llvm/llvm-project/commit/2bbe5809a17a5c5bf643890f1ed5f1acbdbede32
  Author: Valery Pykhtin <valery.pykhtin at amd.com>
  Date:   2026-09-10 (Thu, 10 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: 92034545adc4dbe5206ca2a5f6abb3f501796a44
      https://github.com/llvm/llvm-project/commit/92034545adc4dbe5206ca2a5f6abb3f501796a44
  Author: Valery Pykhtin <valery.pykhtin at amd.com>
  Date:   2026-09-10 (Thu, 10 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: b84aee3af655edb108b878044c06e7f4034ea197
      https://github.com/llvm/llvm-project/commit/b84aee3af655edb108b878044c06e7f4034ea197
  Author: Valery Pykhtin <valery.pykhtin at amd.com>
  Date:   2026-09-10 (Thu, 10 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/90acd6cf5007...b84aee3af655

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