[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