llvm dev - Dec 2016 - [RFC] Supporting ARM's SVE in LLVM

On Mon, Nov 28, 2016 at 7:37 AM Paul Walker via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> That is my intention with the stepvector patch (
> https://reviews.llvm.org/D27105).  You can see that the interface is
> common but for non-scalable vectors the result is its equivalent
> ConstantVector.  Once an agreed form is available
> LoopVectorize::getStepVector can be converted to become compatible with
> scalable vectors very easily, albeit being only a small step on a long
road.
>
Ok, I'm still catching up on this thread, but I think starting to review
patches is going to make it substantially harder to have a productive
conversation. We haven't yet really gotten to any kind of consensus around
the design, and until then I think it would be very helpful to keep
discussion focused on the high-level threads on llvm-dev rather than
fragmenting it into the commits list threads for the patches. I'm happy to
have patches as FYI examples, but they shouldn't be the focus of the
discussion.

Also, up the thread and even in this email there is significant talk about
a substantial change of design based on feedback from the dev meeting. But
there are over 40 emails already here and I've not found an actual concise
high level overview of the *new* design.

I suspect it would be helpful to start a fresh RFC thread with a *concise*
description of the new design so that folks can skip ahead and more
productively join that discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161129/b4cac842/attachment.html>

On 29 November 2016 at 21:33, Chandler Carruth <chandlerc at gmail.com>
wrote:
> Ok, I'm still catching up on this thread, but I think starting to
review
> patches is going to make it substantially harder to have a productive
> conversation. We haven't yet really gotten to any kind of consensus
around
> the design, and until then I think it would be very helpful to keep
> discussion focused on the high-level threads on llvm-dev rather than
> fragmenting it into the commits list threads for the patches. I'm happy
to
> have patches as FYI examples, but they shouldn't be the focus of the
> discussion.
For now, I'm treating the reviews as a concrete example of
implementation, not as a normal approved-merge series. Just like new
back-ends, this will take a lot more than just a few people to look at
it and "approve".

So, if you're worried that high-level decisions will be taken on those
(and subsequent) reviews by approving them, don't be.

Also, any design discussion *will* need to be in the list, not on the reviews.

If I pick up anything on the reviews that wasn't discussed on the
list, I'll make sure to mention it on the reviews (ie. "please, spawn
a new RFC").

> Also, up the thread and even in this email there is significant talk about
a
> substantial change of design based on feedback from the dev meeting. But
> there are over 40 emails already here and I've not found an actual
concise
> high level overview of the *new* design.
The refactoring, AFAICS, was just about vscale and stepvector, both of
which were mentioned on Graham's reply to my questions (the fifth
email on my list).

Everything else is still "working around the concept" of scalable
vectors, IR representation, shuffle/insert/extract semantics, etc.

> I suspect it would be helpful to start a fresh RFC thread with a *concise*
> description of the new design so that folks can skip ahead and more
> productively join that discussion.
There were more substantial comments along the thread than those.
We're not at the point where a new RFC would be beneficial, I think.

The thread has calmed down a bit, take your time to read. I just added
you to the reviews as a FYI, not for us to take any decision right
now. We still need to understand how scalable vectors will look like
in RISC-V, so we only change the IR if we really have to and only
once. But for that, we need context, which we don't have yet.

The bottom line is: we can't approve the high-leve IR changes until
we're sure it encompass all new syntax we need and doesn't break any
old syntax we already have. Unfortunately, for now, without more
information on SVE and RISC-V's scalable extension, everything is
mostly ethereal. But it's a conversation worth having.

cheers,
--renato

>>I suspect it would be helpful to start a fresh RFC thread with a
*concise*
>>description of the new design so that folks can skip ahead and more
>>productively join that discussion.
>There were more substantial comments along the thread than those.
>We're not at the point where a new RFC would be beneficial, I think.
If anybody sees value in collating the responses into a single RFC whose focus
is purely on scalable vectors (stripping away orthogonal topics like
predication) then please restate the request and I'll make it happen.
>The thread has calmed down a bit, take your time to read. I just added
>you to the reviews as a FYI, not for us to take any decision right
>now. We still need to understand how scalable vectors will look like
>in RISC-V, so we only change the IR if we really have to and only
>once. But for that, we need context, which we don't have yet.
>The bottom line is: we can't approve the high-leve IR changes until
>we're sure it encompass all new syntax we need and doesn't break any
>old syntax we already have. Unfortunately, for now, without more
>information on SVE and RISC-V's scalable extension, everything is
>mostly ethereal. But it's a conversation worth having.
I don't like the "ethereal" argument. I know I'm new to the
party but please don't think that applies to this proposal.  The type
related design has been in place for over two years with little* to no change. 
I believe the reason for this is because we came to it without much
consideration for SVE.  Instead we simply asked "How can LoopVectorize do
its job when the vector length is unknown during compilation?".  This is
why many of my answers end with "which is how non-scalable vectors do
it".

If there exists a sufficiently different variable length vector architecture
whereby this design doesn't fit then I suggest it will have larger
ramification than just the type system, potentially look very different to any
existing vector architecture and thus likely to require its own vectoriser.

This is just not the case with SVE.  Yes it has new and wacky instructions but
it also does the boring stuff, with LoopVectorize working well for SVE's
base level of vectorisation.

Paul!!!

*The elementcount->vscale and seriesvector->stepvector updates are syntax
rather than structural changes.  Creating the upstream patches gave us the
opportunity to remove either redundant information or work that can already be
expressed by existing IR.  Doing so allowed the proposal of new constants rather
than new instructions, but has no impact on how we vectorise.

	elementcount(<n x 4 x i8> undef) -> mul i64 vscale, i64 4
	elementcount(<n x 8 x i64> undef) -> mul i64 vscale, i64 8

	seriesvector(i32 0, i32 1) -> stepvector
	seriesvector(i32 5, i32 2) -> add(splat(5), mul(stepvector, splat(2)))