[llvm-dev] [LV][VPlan] Status Update on VPlan ----- where we are currently, and what's ahead of us

[Renato Golin via llvm-dev]

Hi Hideki/Ayal/Gil et. al,

First of all, thank you very much for the (past, current and future)
efforts in the vectoriser. It's much appreciated!


On 6 December 2017 at 00:21, Saito, Hideki via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> With the first patch, we introduced the concept of VPlan to LV and started explicitly recording decisions like interleave memory access optimization and serialization. In the first patch, we resisted introducing VPInstructions ----- and introduced VPRecipes instead, in an attempt to avoid duplicating Instructions in the abstract HCFG Representation (i.e., abstract Instructions in HCFG that is separate from incoming IR Instructions). As we moved on, it became more and more apparent that we have a need to introduce new abstract Instructions (see https://reviews.llvm.org/D38676 for more details)  which also requires representation of new use-def relations that does not exist in incoming IR Instructions. As a result, with the second patch, as part of explicitly modeling masking in VPlan, we introduced VPInstruction, which is an abstraction of IR Instruction.

This was expected, as we move into a radically different model. I
think the current approach to implement & refactor is a good one and
we must continue like that. Pushing for too many features will break
the compiler and too much refactoring will break the spirits of
everyone involved.


> Additional Work Needed to Handle Higher Complexity:
> ---------------------------------------------------
> * Construct VPlan near the beginning of LV (right after Legal or Must-Vectorize directive check)
>
> Additional Work Needed for Outer Loop Auto-Vectorization:
> ---------------------------------------------------------
> * Legality check
> * Cost modeling (compare it to inner loop vectorization strategy in apples-to-apples manner).

On these points, we may need to make it more clear what happens when.
There is an overall legality check, but there also may be
VPlan-specific legality issues (especially as we move to outer-loop
vectorisation) that will not be obvious before we create the VPlans.

I'm not too worried about illegal transformations made legal by VPlans
(for example Polyhedral or inner-loop LICM), but the other way round,
where we may break things outside a VPlan (for instance, A->C is legal
but A->B->C is not). I can't think of anything right now (why I used
"A" and "B"), but I'd welcome thoughts on the impact of more complex
VPlans on the whole legality->cost->transform model.


> Summary of the current state of VPlan infrastructure project is presented, and the remaining steps towards outer loop vectorization is listed. We are currently at a point where we can slow down the refactoring effort for the purpose of expediting the big functionality boost: outer loop vectorization ----- and by doing so encourage more participation from the wider LLVM community in the refactoring effort to expedite the overall transition to the VPlan framework.

Sounds like a plan!

cheers,
--renato