llvm dev - Sep 2019 - Adding support for vscale

I've posted two patches on Phabricator to add support for VScale in LLVM.

A brief recap on `vscale`:
The scalable vector type in LLVM IR is defined as `<vscale x n x m>`, to
create types such as `<vscale x 16 x i8>` for a scalable vector with at
least 16 bytes. In the definition of the scalable type, `vscale` is specified as
a positive constant of type integer that will only be known at runtime but is
guaranteed to be constant throughout the program.

The first patch [1] adds support for `vscale` as a symbolic constant to the LLVM
IR so that it can be used in address calculations, induction variable updates
and other places where the `vscale` property needs to be used to generate code
for scalable vectors.
The second patch [2] adds the ISD::VSCALE node which, if supported by the
target, can be materialised into an instruction that returns the runtime value
for `vscale`. It can also be used to be folded into addressing modes, like
needed for SVE/SVE2 reg+imm load/store instructions.

I'm aware that Graham has discussed this before at previous dev meetings and
that some had their reservations about exposing this as a Constant explicitly.
But the reasons for doing so are because the value is inherently constant. If it
is not constant, this would violate the definition of the scalable type. This
change enforces that. Also, vscale is expected to be used in addressing modes,
so moving/hoisting or any kind of GVN/CSE would obfuscate the use of vscale for
these purposes and would need to be untangled in passes like CodeGenPrep.

Hopefully the patches help clearing up any questions/reservations people may
have had previously (and if not, I hope this thread can be the platform to
discuss these).

[1] https://reviews.llvm.org/D68202
[2] https://reviews.llvm.org/D68203

On Mon, Sep 30, 2019 at 2:30 AM Sander De Smalen via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> I've posted two patches on Phabricator to add support for VScale in
LLVM.
>
> A brief recap on `vscale`:
> The scalable vector type in LLVM IR is defined as `<vscale x n x m>`,
to create types such as `<vscale x 16 x i8>` for a scalable vector with at
least 16 bytes. In the definition of the scalable type, `vscale` is specified as
a positive constant of type integer that will only be known at runtime but is
guaranteed to be constant throughout the program.
RISC-V RVV explicitly allows changing VL (which I am assuming is the
same as vscale) at runtime, so VL wouldn't be a constant.
Additionally, we (libre-riscv) are working on a similar scalar vectors
ISA called SimpleV that also allows changing VL at runtime and we are
planning on basing it on LLVM's scalable vector support.
>
> [1] https://reviews.llvm.org/D68202
> [2] https://reviews.llvm.org/D68203
Jacob Lifshay

On Tuesday, October 1, 2019, Jacob Lifshay <programmerjake at gmail.com>
wrote:
> On Mon, Sep 30, 2019 at 2:30 AM Sander De Smalen via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > I've posted two patches on Phabricator to add support for VScale
in LLVM.

Excellent!

> >
> > A brief recap on `vscale`:
> > The scalable vector type in LLVM IR is defined as `<vscale x n x
m>`, to
> create types such as `<vscale x 16 x i8>` for a scalable vector with
at
> least 16 bytes. In the definition of the scalable type, `vscale` is
> specified as a positive constant of type integer that will only be known at
> runtime but is guaranteed to be constant throughout the program.

Ah.  Right.  There is something known as data-dependent fail-on-first,
which does not match with the assertion that vscale will be constant.

Yes any given vector would be vscale long and it is good to be able to
runtime declare such vectors: loops in assembler may be generated which
sets VL (a Control Status Register declaring the number of elements to be
processed in any given loop iteration)

However for e.g memcpy or strcpy or anything else which is *not* fixed
length and not even the program knows how long the vector will be, there is
data-dependent fail-on-first.

A related thread goes through this, pay attention to Stephen's questions
and it becomes clear:
https://groups.google.com/forum/?nomobile=true#!topic/comp.arch/3z3PlCwdq8U

A link to ARM SVE ffirst capability is also proved in that thread.  Yes,
SVE has ffirst although it is a SIMD variant rather than one that affects
VL.

> RISC-V RVV explicitly allows changing VL (which I am assuming is the
> same as vscale) at runtime, so VL wouldn't be a constant.

This would be good to clarify, Sander. On first reading it seems to me that
vscale is intended to be the actual full vector size, not related to VL.

Regardless, setting it even as *runtime* constant seems to be a red flag.

What is vscale intended for, and how does it relate to Cray-like Vector
Length?

> Additionally, we (libre-riscv) are working on a similar scalar vectors
> ISA called SimpleV that also allows changing VL at runtime and we are
> planning on basing it on LLVM's scalable vector support.

Both SV and RVV are based on Cray VL which is a runtime global CSR setting
the number of elements to be processed in any given vector loop.

The difference is that RVV *requests* a VL and is arbitrarily *allocated*
an actual VL (less than or equal to the requested VL), where in SV you get
exactly what is requested and if overallocated an illegal instruction is
raised.


>
> >
> > [1] https://reviews.llvm.org/D68202
> > [2] https://reviews.llvm.org/D68203
>
> Jacob Lifshay
>

-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191001/222d6846/attachment.html>