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

[Renato Golin via Phabricator via llvm-commits]

rengolin added a comment.

So, I think the document is so good and can be very helpful in further communications, that I think it should be committed separately.

Once we all agree that the document explains what we really want (I mostly do), we can look at the transformations.

I mean, this is a big change and we want to get it right, so minimising the patch size and intrusiveness is a plus. About half of this patch is the document. :)

Makes sense?
--renato



================
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
----------------
Ayal wrote:
> rengolin wrote:
> > mkuper wrote:
> > > 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?
> > Right, this is what I didn't understand. We can do it both ways: one legal consulting all plans, or each plan consulting legal.
> > 
> > I'd prefer we act on plans for everything, as it would be a cleaner concept and an easier move.
> > 
> > As I wrote in another comment: first we iterate through all plans and discard all illegals, then we calculate the costs, sort and pick the best.
> > 
> > We could even (in the far future) have multiple costs per plan (VF, UF, code-size, hazards, etc) and sort by a formula that takes all of them into account.
> The current design performs all Legal checks before starting to work with VPlans, retaining the separation between correctness and performance  considerations. This could be revisited if desired.
> 
> If Legal determines that a loop cannot be vectorized at all, no VPlans are built.
> 
> If Legal determines that a loop can be vectorized but only under certain restrictions, all VPlans built will comply with all these restrictions, and offer distinct alternatives how to vectorize. Current restriction may be: VF small enough, pass runtime guards regarding potential aliasing and non-unit strides, handle cross-iteration dependencies such as reductions, 1st order recurrences, live-outs.
> 
> How to calculate the cost(s) of each VPlan and find the best one is subject to a separate, follow-up patch.
Right, this is what I meant. Filer all VPlans by legality first. I do like the idea that no illegal VPlan can exist.

Costs are for a later patch, I agree.


================
Comment at: docs/VectorizationPlan.rst:10
+
+- be a *lightweight* NFC patch;
+- show key aspects of VPlan's Hierarchical CFG concept;
----------------
I'll echo @mkuper here: drop the NFC.

Also, this is a document that will outlive the patch, so it should also not mention the patch at all.

If we want a document to help us design or explain the VPlan, then we need a VPlan document, not a document for a patch.

Don't get me wrong, not many people write documents, especially not for patches, so this is awesome!

But we need to think about its lifetime and format.


https://reviews.llvm.org/D28975