[PATCH] D156099: [AMDGPU] Add True16 register classes.

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 27 18:22:10 PDT 2023


arsenm added inline comments.


================
Comment at: llvm/test/CodeGen/AMDGPU/subreg-undef-def-with-other-subreg-defs.mir:31
   ; CHECK-NEXT:   [[DS_READ_B32_gfx9_:%[0-9]+]]:vgpr_32 = DS_READ_B32_gfx9 [[V_MOV_B32_e32_]], 0, 0, implicit $exec :: (load (s32), addrspace 3)
-  ; CHECK-NEXT:   INLINEASM &"", 1 /* sideeffect attdialect */, 851978 /* regdef:VGPR_HI16 */, def %0, 2147549193 /* reguse tiedto:$1 */, %0(tied-def 3)
-  ; CHECK-NEXT:   INLINEASM &"", 1 /* sideeffect attdialect */, 851977 /* reguse:VGPR_HI16 */, [[DS_READ_B32_gfx9_]]
-  ; CHECK-NEXT:   INLINEASM &"", 1 /* sideeffect attdialect */, 851978 /* regdef:VGPR_HI16 */, def undef %0.sub0, 851978 /* regdef:VGPR_HI16 */, def undef %0.sub1
+  ; CHECK-NEXT:   INLINEASM &"", 1 /* sideeffect attdialect */, 851978 /* regdef:VGPR_16 */, def %0, 2147549193 /* reguse tiedto:$1 */, %0(tied-def 3)
+  ; CHECK-NEXT:   INLINEASM &"", 1 /* sideeffect attdialect */, 851977 /* reguse:VGPR_16 */, [[DS_READ_B32_gfx9_]]
----------------
Joe_Nash wrote:
> arsenm wrote:
> > Joe_Nash wrote:
> > > Unrelated to this patch, but I don't understand the purpose of these tests. It looks like we are referencing register classes by number in the test input. Therefore any time we modify the number of register classes the tests changes their meaning.
> > The raw number thing is a syntactical inconvenience from how inlineasm is represented. Ideally the mir printer/parser would produce something nicer. I think the purpose of the test is reasonably clear from the comment at the top
> How can one determine if the change in output is still correct? The different RC choices in coalescer-early-clobber-subreg.mir are even more abstract. Is the RC to be ignored?
the printed class name should be correct, you just get the added bonus random number. Fur the purpose of this test the class doesn't really matter. However there are no 16-bit values in this test, so I don't understand how this ended up with any vgpr16 references in the first place


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156099/new/

https://reviews.llvm.org/D156099



More information about the llvm-commits mailing list