[PATCH] D28975: [LV] Introducing VPlan to model the vectorized code and drive its transformation

[Michael Kuperstein via Phabricator via llvm-commits]

mkuper added inline comments.


================
Comment at: docs/VectorizationPlan.rst:140
+OpenMP [6]_. This design to extend the Loop Vectorizer to outer loops supports
+and raises the importance of explicit vectorization beyond the current
+capabilities of Clang and LLVM. Namely, from currently forcing the
----------------
rengolin wrote:
> mkuper wrote:
> > I don't believe anything in this design raises the importance of explicit outer loop vectorization.
> > I think what you're trying to say is that if we want to support explicit outer loop vectorization (which I believe we do), the best way to do it would be using this design. Am I right?
> From the original RFC (linked in the description), the idea is that outer loops will add a lot more complexity to the vectoriser, which is already getting side-tracked by the multiple strategies. This effort is the first step in joining the strategies, which will be the sanest way forward to adding more functionality to the loop vectoriser, including outer loops and better interactions with Polly.
All of that is correct, I didn't mean to imply we should be handling outer loops *now*. :-)
I was just confused about the "raising the importance" part.


================
Comment at: docs/VectorizationPlan.rst:244
+   model and the code generation phases, where the cost estimation must
+   evaluate the to-be-generated code accurately.
+
----------------
rengolin wrote:
> Aligning cost and codegen will always have to rely on heuristics, even if we codegen multiple variations, as this is modelling IR, not assembly.
> 
> We should respect the cost analysis and we should strive to do the best we can, yes, but we shouldn't try to estimate the generated code **accurately** over other improvements.
I think "codegen" here means "the IR generated by the vectorizer", not "backend code generation". See line 123.
Actually getting the cost model to accurately estimate the cost of complex IR constructs is an orthogonal problem.


================
Comment at: docs/VectorizationPlan.rst:425
+
+   a. including those that take place after Legal, which is kept intact;
+   b. including those that use the Cost Model - refactor it slightly to expose
----------------
rengolin wrote:
> Couldn't different VPlans expose different legality issues? For example, for different combination of UFs and VFs?
I think this is why the design says that Legal would "encode constraints". I guess the LVP would have to consult Legal per-potential-VPlan to see whether it's feasible or not?


https://reviews.llvm.org/D28975