[PATCH] [LoopVectorize]Teach Loop Vectorizer about interleaved memory access

[Hao Liu]

In http://reviews.llvm.org/D9368#177057, @anemet wrote:

> In http://reviews.llvm.org/D9368#176907, @HaoLiu wrote:
>
> > It's easy to move such analysis to LV, but I think it reasonable to analyze interleaved accesses in LoopAccessAnalysis:
> >
> >   (1) Regarding the name "LoopAccessAnalysis", which is responsible for analyzing accesses in a loop. The interleaved access group is a special kind of access in loop.
>
>
> True, I named it LAA because it’s a parallel dependence analysis framework to DependenceAnalysis but the focus is the same: dependence analysis plus run-time alias check generation for may-alias accesses.
>
> I don’t have a problem adding things to the analysis that are free to compute even if it’s only used by a single client of the analysis pass (consider Ashutosh’s recent StoreToInvariantAddress changes).  Here however we’re adding a potentially costly new analysis only required by a single client.
>
> >   (2) For clients other than LV, it could disable or enable such analysis. Or we could disable it by default and LV calls function like "analyzeInterleaving()" to do analysis. To achieve this is easy.
>
>
> Not really.  This is an analysis pass, transform passes may depend on it and the pipeline manager will run this pass depending on transform pass requirements and possibly rerun it if it got invalidated by prior transformations.
>
> As an example, consider this scenario.   LAA is performed because of Loop Distribution.  We end up not distributing the loop so the result of the analysis is intact and won’t be rerun.  Then comes LV but the analysis is lacking the interleaved access analysis part.
>
> Admittedly, we currently have a hack in LAA with regard to symbolic strides which would be similar to what you’re proposing.  That however is more of shortcoming of how LAA was split out from LV rather than an example to follow.
>
> >   (3) For other clients, I think we may also need to modify the memory dependence analysis, which is now dedicated to analyze dependences for loop vectorizer.
>
>
> I am not sure I understand this point.  Can you please elaborate?


I previously thought LoopAccessAnalysis is specific for LV, because there are a lot of LV specific data like C

In http://reviews.llvm.org/D9368#177057, @anemet wrote:

> In http://reviews.llvm.org/D9368#176907, @HaoLiu wrote:
>
> > It's easy to move such analysis to LV, but I think it reasonable to analyze interleaved accesses in LoopAccessAnalysis:
> >
> >   (1) Regarding the name "LoopAccessAnalysis", which is responsible for analyzing accesses in a loop. The interleaved access group is a special kind of access in loop.
>
>
> True, I named it LAA because it’s a parallel dependence analysis framework to DependenceAnalysis but the focus is the same: dependence analysis plus run-time alias check generation for may-alias accesses.
>
> I don’t have a problem adding things to the analysis that are free to compute even if it’s only used by a single client of the analysis pass (consider Ashutosh’s recent StoreToInvariantAddress changes).  Here however we’re adding a potentially costly new analysis only required by a single client.
>
> >   (2) For clients other than LV, it could disable or enable such analysis. Or we could disable it by default and LV calls function like "analyzeInterleaving()" to do analysis. To achieve this is easy.
>
>
> Not really.  This is an analysis pass, transform passes may depend on it and the pipeline manager will run this pass depending on transform pass requirements and possibly rerun it if it got invalidated by prior transformations.
>
> As an example, consider this scenario.   LAA is performed because of Loop Distribution.  We end up not distributing the loop so the result of the analysis is intact and won’t be rerun.  Then comes LV but the analysis is lacking the interleaved access analysis part.
>
> Admittedly, we currently have a hack in LAA with regard to symbolic strides which would be similar to what you’re proposing.  That however is more of shortcoming of how LAA was split out from LV rather than an example to follow.
>
> >   (3) For other clients, I think we may also need to modify the memory dependence analysis, which is now dedicated to analyze dependences for loop vectorizer.
>
>
> I am not sure I understand this point.  Can you please elaborate?


Hi Adam,

I think LoopAccessAnalysis is a specific analysis for LV, so it's reasonable to put interleaved access analysis in an analysis specific for LV. If LoopAccessAnalysis is not specific for LV, I agree that we should not put it here. Currently I don't have idea about how other clients could use such interleave information.

But I still wonder how "other" clients use this analysis, as it has a lot of LV specific code like "CanVecMem, force-vector-width, force-vector-interleave", .... I wonder how "other" clients could use such analysis. Adam, do you have any example about other clients using LoopAccessAnalysis?

Thanks
-Hao


http://reviews.llvm.org/D9368

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/