[PATCH] [LoopVectorize]Teach Loop Vectorizer about interleaved memory access
Renato Golin
renato.golin at linaro.org
Thu May 21 02:18:33 PDT 2015
================
Comment at: lib/Analysis/LoopAccessAnalysis.cpp:1059-1060
@@ +1058,4 @@
+ // FIXME: As currently we can't handle predicated access, return directly.
+ if (IsPred)
+ return;
+
----------------
HaoLiu wrote:
> mzolotukhin wrote:
> > Why not to return right after we discovered the block needs predication?
> It's slightly different.
> We still support a predicted block if it doesn't have load/store. Because the vectorization of interleaved loads/stores won't break any dependences.
> But if a predicted block has loads/stores, we need to handle an interleave group contains mixed normal loads/stores and predicted loads/stores.
>
>
This might be a case for indexed loads on AVX, but for now, let's keep it simple. :)
================
Comment at: lib/Analysis/LoopAccessAnalysis.cpp:1075-1076
@@ +1074,4 @@
+
+ // Filter eligible groups and set the insert position. We only keep the load
+ // group that has small gaps (less than half Delta) and the fully interleaved
+ // store group (has no gap).
----------------
HaoLiu wrote:
> mzolotukhin wrote:
> > What's the rationale behind this? It might be inefficient to vectorize a group with a huge gap, but isn't it a question for cost-model rather than for the analysis?
> This is just a conservative way. I think generally if a group missing more than half members, it is not very beneficial to do vectorization. Also it sounds not reasonable to still call it "interleaved" group.
>
> But I agree with you that it's cost-model's work to decide whether it is beneficial.
> The new patch keeps all load groups.
> There is also a new situation that: the cost of a load group with a huge gap may even be expensive than the scalar operations. Then I think we need to replace with scalar operations. I've added a FIXME in the new patch as I haven't found an efficient way to fix this.
>
>
I also agree that the cost model should get this right, but currently, there is no way it can do that.
However, since the interleaved vectorisation is not enabled by default, I think keeping all the groups and fixing the cost model later is the right thing to do.
http://reviews.llvm.org/D9368
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
More information about the llvm-commits
mailing list