[PATCH] D134423: [AMDGPU] Fix vgpr2sgpr copy analysis to check scalar operands of buffer instructions use scalar registers.
krishna chaitanya sankisa via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Nov 2 11:10:37 PDT 2022
skc7 added inline comments.
================
Comment at: llvm/lib/Target/AMDGPU/SIFixSGPRCopies.cpp:914
+ for (auto &U : MRI->use_instructions(Reg)) {
+ if (TRI->isSGPRReg(*MRI, Reg) && !TII->isVALU(*Inst))
Users.push_back(&U);
----------------
alex-t wrote:
> What is the reason for swapping these lines?
> if this
> ```
> TRI->isSGPRReg(*MRI, Reg) && !TII->isVALU(*Inst)
> ```
> is not true we don't need to process register users.
Fixed previous patch. Swap for and if was my mistake. Also added check for AMDGPU::SReg_32RegClass used by soffset of MUBUF/MTBUF.
================
Comment at: llvm/lib/Target/AMDGPU/SIFixSGPRCopies.cpp:922
+ const MachineOperand *soffsetMO =
+ TII->getNamedOperand(U, AMDGPU::OpName::soffset);
+
----------------
alex-t wrote:
> skc7 wrote:
> > foad wrote:
> > > I don't understand why we need special cases for particular named operands. Why can't this be inferred from the operand's register class? @alex-t?
> > soffset and srsrc need to be scalar registers in mubuf/mtbuf instructions.. Check for use of COPY's result is done here for these operands.
> The fact that the specific use requires SGPR surely can be checked for any use.
> What I don't like here is the hack forcing the decision to be made for v_readfistlane.
> The algorithm that makes a decision is a complex tradeoff and we should not "tune" it in such a way for each particular case. I would consider the "SGPR required" as a weight value for the solver rather than the ultimate condition.
HasMBUFScalarReg flag would be set to true for scalar operands of MUBUF/MTBUF. This would lower copy to use v_readfirstlane_b32.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D134423/new/
https://reviews.llvm.org/D134423
More information about the llvm-commits
mailing list