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

[Paul Walker via llvm-dev]

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