This patch adds transformVPInstrucintroduces inner loop vectorization to the VPlan native path
and code generationsToVPRecipes, to transform a for VPInstruction based VPlans using the
VPInstruction VPlan to one with VPRecipes. This allows us to moveToVPRecipe transformation.
Currently we only support vectorization with user-provided vectorization
towards VPInstruction based VPlans,factor and assume an interleave count of 1. while still being able to re-useWe also do not run interleaved
the VPRecipes for code-generation for nowaccess analysis.
This patch updatIt also enables the inner loop vectorizer to use VPlanHCFGBuilder toVplan native path for some existing inner loop
build the initial VPlans and to use transformVPInstructionsToVPRecipesvectorizer tests. All tests which set the vector width should pass when
when executing arun through the VPlann native path.
This patch just moves things around and makes things clearer, but it modifiesis a stepping stone to get code generation for outer loops and also
for the inner loop vectorizermigration to VPInstruction based codegen. I think we should try to use as many parts of VPlanFor outer loop
for inner loop vectorization as well, to make sure we get as muchwe have to add support for generating code for the inner
testing early on. But I am not entirely sure if it would be better to haveloop PHI nodes and induction variables and adjust the cost model to
a completely separate inner loop vectorization path in the VPlan native path, to
eliminate the risk of breaking things in the inner loop vectorizers.widen/scalarize the right instructions.
To get VPInstruction based codegen, we can replace 1 recipe type at a
What do you think?
The test case changes are due to the fact that scalarization happens later now (at the time of the Vplan execution), thus the position changedtime, while we can still test inner loop vectorization through the VPlan