[PATCH] D127664: [AMDGPU] gfx11 ldsdir intrinsics and ISel
Matt Arsenault via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jun 16 14:00:09 PDT 2022
arsenm added inline comments.
================
Comment at: llvm/lib/Target/AMDGPU/LDSDIRInstructions.td:96
+ (f32 (int_amdgcn_lds_direct_load M0)),
+ (LDS_DIRECT_LOAD 0)
+>;
----------------
rampitec wrote:
> Joe_Nash wrote:
> > rampitec wrote:
> > > Joe_Nash wrote:
> > > > rampitec wrote:
> > > > > How does that work? It seems to ignore M0 argument.
> > > > Because LDS_DIRECT_LOAD has an implicit use of M0. In llvm.amdgcn.lds.direct.load.ll it seems to work as it should given that.
> > > Right, it uses M0, but where is a link from the call argument and actual store of that value into M0?
> > I don't know, but maybe this helps to explain? Dump from AMDGPUGenGlobalISel.inc
> > // Label 2092: @108525
> > GIM_Try, /*On fail goto*//*Label 2093*/ 108577, // Rule ID 3516 //
> > GIM_CheckIntrinsicID, /*MI*/0, /*Op*/1, Intrinsic::amdgcn_lds_direct_load,
> > GIM_CheckType, /*MI*/0, /*Op*/0, /*Type*/GILLT_s32,
> > GIM_CheckType, /*MI*/0, /*Op*/2, /*Type*/GILLT_s32,
> > GIM_CheckRegBankForClass, /*MI*/0, /*Op*/0, /*RC*/AMDGPU::VGPR_32RegClassID,
> > GIM_CheckRegBankForClass, /*MI*/0, /*Op*/2, /*RC*/AMDGPU::M0_CLASSRegClassID,
> > // (intrinsic_w_chain:{ *:[f32] } 1864:{ *:[iPTR] }, M0:{ *:[i32] }) => (LDS_DIRECT_LOAD:{ *:[f32] } 0:{ *:[i8] })
> > GIR_BuildMI, /*InsnID*/1, /*Opcode*/TargetOpcode::COPY,
> > GIR_AddRegister, /*InsnID*/1, AMDGPU::M0, /*AddRegisterRegFlags*/RegState::Define,
> > GIR_Copy, /*NewInsnID*/1, /*OldInsnID*/0, /*OpIdx*/2, // M0
> > GIR_BuildMI, /*InsnID*/0, /*Opcode*/AMDGPU::LDS_DIRECT_LOAD,
> > GIR_Copy, /*NewInsnID*/0, /*OldInsnID*/0, /*OpIdx*/0, // vdst
> > GIR_AddImm, /*InsnID*/0, /*Imm*/0,
> > GIR_MergeMemOperands, /*InsnID*/0, /*MergeInsnID's*/0, GIU_MergeMemOperands_EndOfList,
> > GIR_EraseFromParent, /*InsnID*/0,
> > GIR_ConstrainSelectedInstOperands, /*InsnID*/0,
> > // GIR_Coverage, 3516,
> > GIR_Done,
> > // Label 2093: @108577
> > GIM_Reject,
> OK, I must admit I still do not understand how does it work, but it obviously does.
The physical register takes the place in the pattern of what normally would be a named virtual input, like VReg_32:$src1
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D127664/new/
https://reviews.llvm.org/D127664
More information about the llvm-commits
mailing list