[PATCH] D21048: [LV] Enable vectorization of loops where the IV has an external use

Ayal Zaks via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 15 16:50:57 PDT 2016

Ayal added a comment.

In http://reviews.llvm.org/D21048#459423, @mkuper wrote:

> In http://reviews.llvm.org/D21048#459394, @Ayal wrote:
> > An alternative which I'm sure you thought of would be to fix/clean up such external users of IV's as a preparatory step (SimplifyIndVar?), eliminating them from the loop before starting to vectorize it. This may be a good thing to do early, for other "uses".
> Yes, in fact, that's what I've started with, but abandoned that direction.
>  This is a question of cost modeling. SimplifyIndVar will already clean this up if it considers generating the end value cheap enough. And it seems like this decision should not depend on whether it expects vectorization in the future or not.

It could potentially help other uses as well, but ok, they'd be hard to anticipate as well. The alternative was firstly referring to cleaning this up SimplifyIndVar-style after we decide to vectorize the loop and before we start creating an empty loop etc.

> > It may be somewhat more efficient to traverse the LCSSA phi's at the single exit block that are fed by allowed-to-exit IV's in order to fix/clean them up, instead of traversing mostly irrelevant internal uses in search for out-of-loop ones.



> I'm not sure it's much better. If the LCSSA phi uses the IV phi directly, it is. If it uses the value feeding into the IV phi, then we still need to find the IV this value belongs to. So, either have additional book-keeping, or go over the value's uses to find the phi.

or find the phi by looking at the defs feeding this value.

> If you think it may be significantly better, I can implement it, and see how it looks.

Ah, I would expect this to have negligible effect if any. Just noted to keep in mind if one does go back to implement the SimplifyIndVar alternative.

Comment at: llvm/trunk/lib/Transforms/Vectorize/LoopVectorize.cpp:3299-3300
@@ +3298,4 @@
+  // An external user of the penultimate value need to see EndValue - Step.
+  // The simplest way to get this is to recompute it from the constituent SCEVs,
+  // that is Start + (Step * (CRD - 1)).
+  for (User *U : OrigPhi->users()) {
mkuper wrote:
> Ayal wrote:
> > need[s]
> > 
> > "simplest" as it employs II.transform, which takes care of pointers as well; one could argue that doing EndValue - Step is simpler..
> Yes, I want this to fire for pointer IVs as well, just enabling it step-by-step.
BTW, another alternative is to extract the last element from the vectorized IV; or the element before last. But that is less amenable to further passes than the scalar computation.



More information about the llvm-commits mailing list