[PATCH] D80545: [AMDGPU/MemOpsCluster] Let mem ops clustering logic also consider number of clustered bytes
Mahesha S via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu May 28 07:35:12 PDT 2020
hsmhsm marked an inline comment as done.
hsmhsm added inline comments.
================
Comment at: llvm/lib/Target/AMDGPU/SIInstrInfo.cpp:298-299
+ const TargetRegisterInfo *TRI) const {
+ const MachineOperand *DstOp = getDstMemOperand(LdSt);
+ Width = DstOp ? getDstOpSizeInBytes(LdSt, DstOp) : 0;
+
----------------
hsmhsm wrote:
> foad wrote:
> > Move this below the mayLoadOrStore check. Then, does getDstMemOperand ever fail?
> Fixed it. However, I do not know much about the functionality guarantee of `mayLoadOrStore()`. So for the purpose of safety, I have added an `if stmt` to check if `DstOp` is `null or not`, and return `false` if it is `null`.
Apparently, above `if stmt` resulted in one unit test failure. Hence reverted it back. And again, assuming here that `DstOp` will not be `null` is also NOT guaranteed, We seem to be getting `null` in many unit test cases, and hence assuming it non-null will again result in many test failures. Now there two possibilities
(1) `getDstMemOperand()` might not be handling all the cases OR
(2) `getDstMemOperand()` is handling all the cases, but, it is expected that `DstOp` will be `null` in few cases even though, `mayLoadOrStore()` is true.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D80545/new/
https://reviews.llvm.org/D80545
More information about the llvm-commits
mailing list