[PATCH] D22867: [LV] Untangle the concepts of uniform and scalar

Michael Kuperstein via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 29 11:28:33 PDT 2016


mkuper added a comment.

First of all, thanks a lot for working on untangling this!

I'll try to restate my understanding of what we should be doing - that I think aligns with Wei's.

We have three types of values:

1. Uniform scalar - every value for which we generate a single scalar - the primary IV, base pointer for consecutive pointer values, etc.
2. Non-uniform "scalar" - values that are non-uniform, but for which we generate VF scalar values, instead of a single vector. For instance, the "scalar IVs".
3. Non-uniform non-scalar - values that actually get vectorized.

(Perhaps we can adjust the terminology for (2) and (3) - my preference would be to call (3) "vector" and (2) "multi-scalar", but I'm open to other suggestions.)

In any case, as Wei wrote, we need two different groupings:
(a) One for 1 vs. 2 + 3, for operation cost estimation. This is what should go into ValuesNotWidened
(b) The other, for 1 + 2 vs. 3, for vector register pressure estimation.

After this patch we still seem to conflate the two - calculateRegisterUsage() assumes VecValuesToIgnore contains values in groups 3, but it will get 2 + 3.


================
Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:2005
@@ +2004,3 @@
+    // scalar after vectorization.
+    auto ScalarIndUpdate = all_of(IndUpdate->users(), [&](User *U) -> bool {
+      if (TheLoop->isLoopInvariant(U) || U == Ind)
----------------
Maybe return false early if !ScalarInd ?
There's no need to compute ScalarIndUpdate in that case, is there?


https://reviews.llvm.org/D22867





More information about the llvm-commits mailing list