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

[Saito, Hideki via llvm-dev]

>That sounds like an excellent idea! Any concrete ideas/plans how people could get involved, besides doing reviews?

Let's talk about this in the RFC context. http://lists.llvm.org/pipermail/llvm-dev/2017-December/119523.html.
Divergence Analysis work mentioned there is a good example.

Thanks,
Hideki 

-----Original Message-----
From: Florian Hahn [mailto:florian.hahn at arm.com] 
Sent: Wednesday, December 06, 2017 6:21 AM
To: Renato Golin <renato.golin at linaro.org>; Saito, Hideki <hideki.saito at intel.com>
Cc: llvm-dev at lists.llvm.org; nd <nd at arm.com>
Subject: Re: [llvm-dev] [LV][VPlan] Status Update on VPlan ----- where we are currently, and what's ahead of us

Hi,

On 06/12/2017 09:37, Renato Golin via llvm-dev wrote:
> 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.
>

That sounds like an excellent idea! Any concrete ideas/plans how people could get involved, besides doing reviews?

Cheers,
Florian