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

[Alex Bradbury via llvm-dev]

On 27 November 2016 at 16:54, Renato Golin <renato.golin at linaro.org> wrote:
> On 27 November 2016 at 16:51, Amara Emerson <amara.emerson at gmail.com> wrote:
>> There is nothing to stop other targets from using
>> stepvector/seriesvector. In fact for wide vector targets, often the IR
>> constant for representing a step vector is explicitly expressed as
>> <i32 0, i32 1, i32 2..> and so on (this gets really cumbersome when
>> your vector length is 512bits for example). That could be replaced by
>> a single "stepvector" constant, and it works the same for both
>> fixed-length and scalable vectors.
>
> Indeed! For this particular point, I think we should start there.
>
> Also, on a more general comment regarding David's point about Hwacha,
> maybe we could get some traction on the RISC-V front, to see if the
> proposal is acceptable on their end, since they're likely to be using
> this in the future in LLVM.
>
> Alex, any comments?

The RISC-V vector proposal is still in the development stage, but it
will inevitably be vector length agnostic much like Hwacha. Krste gave
a talk about his proposal for the 'V' extension last year
<https://riscv.org/wp-content/uploads/2015/06/riscv-vector-workshop-june2015.pdf>
and I'm looking forward to his update at the RISC-V Workshop this
Wednesday, not least because I'm hoping he'll have done my homework
for me and contrast his proposal to what is publicly known about SVE.
The proposal includes a vsetvl instruction (slide 20) which returns
the minimum of the hardware vector length and requested vector length.

I'll wait for the update on the proposed RISC-V vector extension
before really digging in to the SVE RFC on handling vector lengths. In
the mean time, are there any other vector-length agnostic
architectures that either have existing out-of-tree backends or may
have them in the future?

Best,

Alex