[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