[PATCH] D46827: [LV] Add VPInstruction to VPRecipe transformation.

[Hideki Saito via Phabricator via llvm-commits]

hsaito added a comment.

In https://reviews.llvm.org/D46827#1099973, @dcaballe wrote:

> In https://reviews.llvm.org/D46827#1099761, @fhahn wrote:
>
> > The only problem is that the recipe generation depends on the cost model and we  probably have to duplicate some code from the inner loop vectorizer in the VPlan native path, until we gradually replace them by VPlan implementations. I think that would give us a stable starting point (the VPlan native path should pass all existing inner loop vectorizer tests) and would help us to work towards VPlan native inner loop vectorization at a steady pace. Does this make sense?
>
>
> What is the main dependence with cost model? Maybe @hsaito could have it into account since he is looking at how to refactor the current cost model.
>  In any case, I don't think we have to replicate too much code if we start with something simple, even if we generate inefficient code at the beginning. For example, I don't think we initially need the `DeadInstructions` code, anything related to masking or uniformity (since only uniform branches are allowed in the native path for now) or interleave accesses. That should simplify a lot the VPInstruction2VPRecipe step.


I'm working on CostModel starting from the last part, i.e., walk HCFG and VPRecipes/VPInstructions instead of BBs and Instructions, to compute the cost (and going backwards). There are bunch of decision processes, e.g., memref should be vectorized or serialized, that also need to be "converted" before the entire CostModel becomes VPlan ready ---- and the last part certainly depends on those decisions. I plan to create IR versions (which is existing code) and VPlan versions (new code), make sure we can compare side by side, become comfortable to switch to VPlan versions, and then finally retire the IR versions.


https://reviews.llvm.org/D46827