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

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?

cheers,
--renato

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

On 28 November 2016 at 09:15, Alex Bradbury <asb at asbradbury.org>
wrote:
> 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.
Thanks! This is really helpful!

> The proposal includes a vsetvl instruction (slide 20) which returns
> the minimum of the hardware vector length and requested vector length.
I haven't seen a similar instruction in SVE yet, but the compulsory
predicate on all instructions kinda make that redundant, since you can
always use it to calculate the number of "affected" lanes, and thus
only increment the "right" amount per iteration and not rely on
additional instructions. But this also seem to fit the concept of
"vscale", so if you say:

  %scale = i64 vscale

In RISC-V, this would literally translate to:

  vsetvl t0, a0

Then you could use it to increment the induction variable(s):

  %index.next = add nuw nsw i64 %index, mul (i64 %scale, i64 4)
  %index2.next = add nuw nsw i64 %index, mul (i64 %scale, i64 16)

If using "vscale" directly, the back-end would have to know which
instructions it's pertinent to:

  %index.next = add nuw nsw i64 %index, mul (i64 vscale, i64 4)
  %index2.next = add nuw nsw i64 %index, mul (i64 vscale, i64 16)

If we assume that "vscale" is constant throughout the module, then
it's irrelevant. If there could be some change, this becomes a
problem, as you'd need a validity domain, which %scale would give you
for free.

Paul,

This is one of the issues we have to get right before any IR changes
are in effect, to make sure we won't need to change it again soon. In
SVE, such an operation would be a NOP, as the back-end is already
tracking it via the predicate registers.

cheers,
--renato