[PATCH] D49491: [RFC][VPlan, SLP] Add simple SLP analysis on top of VPlan.

Hideki Saito via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 18 12:33:42 PDT 2018


hsaito added a comment.

In https://reviews.llvm.org/D49491#1166978, @rengolin wrote:

> In https://reviews.llvm.org/D49491#1166927, @fhahn wrote:
>
> > That being said, some of the VPlan infrastructure is still emerging: initial VPInstruction based codegeneration and cost modelling is currently worked on for example. However I think considering SLP style vectorization as a VPlan2VPlan transformation (and others) early on would help to make sure the design of the VPlan infrastructure is general enough to cover a wide range of use cases.
>
>
> I can see the appeal in a proof-of-concept, and I don't oppose having it. But I'm not strongly in favour either.
>
> If more people think that option #2 above is the way to go, then this could turn out fine.
>
> But if more people prefer the option #1, then we would want to see what gets hoisted and how will the local implementations look like before we add VPlanSLP.


The fact of the matter is that the loop vectorization has a need to understand SLP and SLP vectorizer needs to understand Loop. As such, unless we want to build/maintain separate LoopVectorize+SLP and SLPVectorize+Loop, consolidation of LoopVectorization and SLPVectorization will inevitably happen sooner or later. From that perspective, ensuring that VPlan is the right infrastructure for such consolidation is a very important thing for us to do.
We don't necessarily have to choose between #1 and #2. Once we come to conclude that VPlan is promising enough for SLP, we can start VPlanize SLP vectorizer (#1) while #2 moves forward. We just need to make a conscious effort to converge the two, starting from sharing small chunks of code and then steadily increase sharing.


https://reviews.llvm.org/D49491





More information about the llvm-commits mailing list