[PATCH] D105572: [AArch64][SME] Add load and store instructions

[Amara Emerson via Phabricator via llvm-commits]

aemerson added inline comments.


================
Comment at: llvm/test/CodeGen/AArch64/GlobalISel/regbank-inlineasm.mir:78
     ; CHECK-LABEL: name: inlineasm_virt_mixed_types
-    ; CHECK: INLINEASM &"mov $0, #0; mov $1, #0", 0 /* attdialect */, 655370 /* regdef:GPR32common */, def %0, 1245194 /* regdef:FPR64 */, def %1
+    ; CHECK: INLINEASM &"mov $0, #0; mov $1, #0", 0 /* attdialect */, 655370 /* regdef:GPR32common */, def %0, 1245194 /* regdef:WSeqPairsClass_with_sube32_in_MatrixIndexGPR32_12_15 */, def %1
     ; CHECK: [[COPY:%[0-9]+]]:gpr(s32) = COPY %0
----------------
c-rhodes wrote:
> david-arm wrote:
> > I realise adding a new class might have an effect on the other test files, but I'm not sure why this has changed from FPR64 to WSeqPairsClass_with_sube32_in_MatrixIndexGPR32_12_15 here?
> > I realise adding a new class might have an effect on the other test files, but I'm not sure why this has changed from FPR64 to WSeqPairsClass_with_sube32_in_MatrixIndexGPR32_12_15 here?
> 
> Not entirely sure myself to be honest, not being familiar with GlobalISel. @aemerson any thoughts on the difference here? 
I *think*, and please verify my theory here, that this is just because in this test we're hard coding an enum integer `1245194` for FPR64, as the operand for the INLINEASM instruction. If you add a new regclass that could be shifting the entries in the enum so `1245194` is no longer referencing FPR64. You should be able to just find the new integer value for FPR64 and change the test to use that.


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

https://reviews.llvm.org/D105572