[PATCH] D126989: [AMDGPU] gfx11 VOPC instructions

[Jay Foad via Phabricator via llvm-commits]

foad added inline comments.


================
Comment at: llvm/test/CodeGen/AMDGPU/move-load-addr-to-valu.mir:22
   ; GCN:   [[REG_SEQUENCE:%[0-9]+]]:vreg_64 = REG_SEQUENCE [[V_AND_B32_e64_]], %subreg.sub0, [[V_AND_B32_e64_1]], %subreg.sub1
-  ; GCN:   [[V_CMP_NE_U64_e64_:%[0-9]+]]:sreg_64_xexec = V_CMP_NE_U64_e64 [[REG_SEQUENCE]], 0, implicit $exec
+  ; GCN:   [[V_CMP_NE_U64_e64_:%[0-9]+]]:sreg_64_xexec = V_CMP_NE_U64_e64 0, [[REG_SEQUENCE]], implicit $exec
   ; GCN:   [[COPY3:%[0-9]+]]:vreg_64 = COPY [[REG_SEQUENCE]], implicit $exec
----------------
Joe_Nash wrote:
> rampitec wrote:
> > Why did it change? This is unexpected.
> These are the only changes to the tablegen record.
> field bit VOPC = 0; -> field bit VOPC = 1;
> bits<64> TSFlags (VOPC bit is now set)
> 
> There is no difference in the SIFixSGPRCopies output. It seems to me as if when the instruction is being constructed it is now commuted. Since this instruction should commute, do you think this is a bad change? 
> 
V_CMP_NE_U64_e64 is now marked as both VOPC and VOP3, which means that SIInstrInfo::legalizeOperands now sends it to legalizeOperandsVOP2 instead of legalizeOperandsVOP3. legalizeOperandsVOP2 commutes the operands.

This all feels slightly wrong. VOPC is an encoding, and V_CMP_NE_U64_e64 uses the VOP3 encoding not the VOPC encoding, so it should not be marked as VOPC - should it??


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126989