[PATCH] D28975: [LV] Introducing VPlan to model the vectorized code and drive its transformation
Renato Golin via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Apr 27 12:10:27 PDT 2017
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
More information about the llvm-commits
mailing list