[PATCH] D52559: [AMDGPU] Divergence driven instruction selection. Shift operations.

Alexander via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 27 09:46:08 PDT 2018


alex-t added inline comments.


================
Comment at: lib/Target/AMDGPU/VOP3Instructions.td:399
+let Predicates = [isVI] in {
+def : AMDGPUPat <
+ (shl i64:$x, i32:$y),
----------------
rampitec wrote:
> alex-t wrote:
> > rampitec wrote:
> > > Why not GCNPat?
> > > Why divergence is not checked?
> > > Why do you need it at all if you have patgen enabled for these instructions above?
> > On VI+ we have no V_LSHL_B64 only V_LSHLREV_B64, same for sra, srl.
> > So, we cannot select in case we have, let's say, shl with src0 i64 and src1 i32.
> > The aim of these patterns to swap operands. Current implementation does this in 
> > SIInstrInfo::moveToVALU
> > 
> >     case AMDGPU::S_LSHL_B64:
> >       if (ST.getGeneration() >= AMDGPUSubtarget::VOLCANIC_ISLANDS) {
> >         NewOpcode = AMDGPU::V_LSHLREV_B64;
> >         **swapOperands(Inst);**
> >       }
> Then what the code "def V_LSHLREV_B64 : VOP3Inst <"v_lshlrev_b64", VOP_PAT_GEN<VOP3_Profile<VOP_I64_I32_I64>>, shl>" 8 lines above does? Isn't it the same?
No. The code you've mentioned defines the pattern for:

 Divergent node that has

1. shl operator
2. i64 result, i32 src0 and i64 src1

it is okay for v_lshlREV - it shifts src1 64 bits to i32 src0 positions

what if we have the opposite order of operands? On SICI we'd select v_lshl since
that order fits. On VI we have only v_lshlREV so we need to swap operands.


https://reviews.llvm.org/D52559





More information about the llvm-commits mailing list