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

[Renato Golin via llvm-dev]

On 1 December 2016 at 17:24, Paul Walker <Paul.Walker at arm.com> wrote:
> 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.

We should focus on the controversial topics. Maybe a better approach
would be to spawn smaller, contrived RFCs, for each of them.

The first two: vscale and stepvector need more eyes. I think one RFC
each would be more productive than one for both, as they're related,
but mostly orthogonal.

The rest can wait, I think.


> 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".

I apologise if that came out as related to your design, it wasn't
meant to be. Ethereal, as I meant, is the upstream understanding of
the nuances of SVE. Understanding that is require for us to approve
changes to the IR, which will affect *everyone*. No one is judging the
quality of the design or the capacity of the team that did it. We're
just making sure that the design will be the best "for LLVM".

Given that this is an open community, "the best" is whatever is the
consensus of most of our developers at a given time. But for that,
those developers need to have a hard look at it and be happy that the
design is sound, from their own knowledge of LLVM.

Different engineers will look at it from different angles. Experts in
different areas (vectorizer, alias analysis, opencl, openmp, hardware,
etc) will shed a different light and we'll have to weight all of it to
get the clearest picture we can before approving any given design.
It's very likely that the final design will be quite different than
what you've done, and that's not a reflection of its quality, just a
necessary process to integrate it into a community that is far larger
than any one of us can see.

The important thing to protect here is that high-level IR changes (for
example, the representation of vector types in the binary form) has to
pay the costs associated with it, which are not negligible.

The other factor I tried to be clear about is that the initial
implementation can be different than the final one, and hopefully less
invasive until we're sure that it's stable and correct.

Even if the final design end up identical to your original one, the
path that we'll thread to get there will be far less clear and direct,
and this is perfectly fine.


> 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.

AFAIK, this is the case of OpenCL, PTX, AMD. I don't think this is the
case for SVE nor RISC-V scalable vector extension. We must find a
single solution for both.


> *The elementcount->vscale and seriesvector->stepvector updates are syntax rather than structural changes.

The new vector representation is a structural one. Vscale is a simpler
change, but step vector is one that needs a lot more context and
explaining.

The key discussion here is to know what do they *can* mean, not just
the subset that we need to worry about now. Once we change the IR, we
should really not do it again soon.


>  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.

If we can express the needed semantics in existing IR, we should not
create new constructs, *especially* in a design phase.

If later on we find that an IR change is interesting to simplify the
patterns, we can discuss this later. Right now we should be focusing
on how to represent scalable vectors to allow the concept to be
introduced in LLVM, not how to "best" work with them in the far
future.

cheers,
--renato