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

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


  Branch: refs/heads/users/vpykhtin/amdgpu-align-verifier-reframe
  Home:   https://github.com/llvm/llvm-project
  Commit: ddc28440b073deba911c47f00226b3033ef83f10
      https://github.com/llvm/llvm-project/commit/ddc28440b073deba911c47f00226b3033ef83f10
  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: 78337c3d777a0850badcc5453b91698ff39fa175
      https://github.com/llvm/llvm-project/commit/78337c3d777a0850badcc5453b91698ff39fa175
  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: 4e808fbe9f618602d1738c05c457c076f77f4a29
      https://github.com/llvm/llvm-project/commit/4e808fbe9f618602d1738c05c457c076f77f4a29
  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/b84aee3af655...4e808fbe9f61

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