[PATCH] D22869: [LV] Generate both scalar and vector integer induction variables
Michael Kuperstein via llvm-commits
llvm-commits at lists.llvm.org
Thu Jul 28 13:15:07 PDT 2016
mkuper added a comment.
Out of curiosity - what does the final generate code end up looking with and without this patch, for cases where we have both a scalar and a vector use?
It seems like it should be better, I'm wondering how much.
================
Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:1973
@@ -1975,1 +1972,3 @@
+bool InnerLoopVectorizer::shouldScalarizeIntInduction(Instruction *IV) const {
+ if (Legal->isUniformAfterVectorization(IV))
----------------
Why "Int"? I mean, it may be called only from widenIntInduction now, but I don't really see a reason to bake it into the name, the logic is independent of the IV type.
Regardless, I find the use of "scalarize" sort of confusing. It evokes the notion of constructing a vector, and then extracting the scalars, which is the opposite of what we're doing. Maybe something like needsScalarInduction, and then a matching name for the variable below?
(If you find the current terminology clearer, I won't insist on this, this could be just my own bias.)
================
Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:1977
@@ +1976,3 @@
+ for (auto *U : IV->users())
+ if (!OrigLoop->isLoopInvariant(U))
+ if (Legal->isScalarAfterVectorization(cast<Instruction>(U)))
----------------
Why do we need !isLoopInvariant(U)? If the use is loop invariant, shouldn't it necessarily be a scalar?
(Assuming we do need it, why two separate ifs, and not a && ?)
https://reviews.llvm.org/D22869
More information about the llvm-commits
mailing list