[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