[PATCH] D20474: when calculating RegUsages, ignore instructions which are uniformed after vectorization

Wei Mi via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 8 14:39:05 PDT 2016


wmi added inline comments.

================
Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:5350
@@ -5349,3 +5349,3 @@
       // Only examine Loads, Stores and PHINodes.
       if (!isa<LoadInst>(it) && !isa<StoreInst>(it) && !isa<PHINode>(it))
         continue;
----------------
mkuper wrote:
> Another side point - should we remove this?
> Looking at http://reviews.llvm.org/rL172178, the reason that we only look at loads, stores, and PHIs is that "We don't have a detailed analysis on which values are vectorized and which stay scalars in the vectorized loop so we use another method. We look at reduction variables, loads and stores, which are the only ways to get information in and out of loop iterations".
> 
> That was true at the time, but since then we've gained a precise way of knowing which instructions are uniform, and with this patch will actually use that for ValuesToIgnore. So this check will now only miss instructions that ought to be taken into account, right?
Yes, it makes sense to remove it.

================
Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:6175
@@ -6174,4 +6174,3 @@
 
-  // Ignore induction phis that are only used in either GetElementPtr or ICmp
-  // instruction to exit loop. Induction variables usually have large types and
-  // can have big impact when estimating register usage.
+  // Ignore induction phis that are only used in either GetElementPtr or
+  // Uniform instruction since we don't need vector versions for such induction
----------------
mkuper wrote:
> This isn't directly related to this patch - but wouldn't this be true only for consecutive GEPs? (e.g. see D20789)
Every GEP (no matter it is consecutive or not) will be scalarized. It is not related with the load/store using the GEP.  If the induction variable is only used in GEP, it will not be vectorized, right?  


Repository:
  rL LLVM

http://reviews.llvm.org/D20474





More information about the llvm-commits mailing list