[PATCH] D100684: [X86][CostModel] X86TTIImpl::getMemoryOpCost(): rewrite vector handling again
Roman Lebedev via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Apr 22 05:08:31 PDT 2021
lebedev.ri added inline comments.
================
Comment at: llvm/lib/Target/X86/X86TargetTransformInfo.cpp:3249
+ const int EltTyBytes = EltTyBits / 8;
+ assert(EltTyBytes != 0);
+
----------------
RKSimon wrote:
> Can this assert happen?
No, the previous assert would have fired already.
This is more to document the expected post-condition.
It is inferrable from the previous assert, but i thought this is more direct.
================
Comment at: llvm/lib/Target/X86/X86TargetTransformInfo.cpp:3258
+ int NumEltRemaining = SrcNumElt;
+ auto NumEltDone = [&]() { return SrcNumElt - NumEltRemaining; };
+
----------------
RKSimon wrote:
> This feels like it should be unnecessary.....
I don't want to have `int NumEltDone`, because then we will have to update two things (it and NumEltRemaining).
Should i inline it? I though giving it a name would make code more readable.
================
Comment at: llvm/lib/Target/X86/X86TargetTransformInfo.cpp:3262
+ const int MaxLegalOpSizeBytes = LT.second.getSizeInBits() / 8;
+ assert(MaxLegalOpSizeBytes != 0);
+
----------------
RKSimon wrote:
> assert message?
Same as previous assert, can't really happen, but i thought making it explicit might be good..
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D100684/new/
https://reviews.llvm.org/D100684
More information about the llvm-commits
mailing list