[PATCH] D65884: [ARM] MVE Tail Predication
Sjoerd Meijer via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Sep 3 06:20:18 PDT 2019
SjoerdMeijer added a comment.
If I am not mistaken, there is no test with a nested-loop. Would probably be good to test that too.
================
Comment at: lib/Target/ARM/MVETailPredication.cpp:301
+ unsigned ElementWidth = VecTy->getScalarSizeInBits();
+ if (Lanes * ElementWidth != 128 || Lanes == 128)
+ return false;
----------------
SjoerdMeijer wrote:
> A few nits I forgot to mention in my previous message:
>
> Replace constant 128 with `TTI.getRegisterBitWidth(true)`?
>
> And I don't think I understand the `Lanes == 128` part.
thanks for adding the comment, I still think you can use TTI.getRegisterBitWidth(true) here
================
Comment at: lib/Target/ARM/MVETailPredication.cpp:177
+ auto &SE = getAnalysis<ScalarEvolutionWrapperPass>().getSE();
+ TPCandidate Candidate(L);
+ bool Changed = Candidate.TryConvert(Setup->getArgOperand(0), SE);
----------------
For me, personally, creating a TPCandidate class doesn't add an abstraction that is really useful or clearer as literally the only thing it captures is 1 list, i.e. `MaskedInsts`, and we don't have multiple candidates and the lifetime of this object is extremely short. So, a simplification/clean-up in my opinion, is to get rid of the class and then we just have 3 local helper functions, and one variable that we pass thought. This is probably a nit, and/or a style preference.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D65884/new/
https://reviews.llvm.org/D65884
More information about the llvm-commits
mailing list