[llvm-dev] [RFC][SVE] Extend vector types to support SVE registers.

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 13 01:01:02 PDT 2017


On 7 March 2017 at 17:50, Renato Golin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi Paul,
>
> Nice to see new efforts in this area! :)
>
> On 7 March 2017 at 17:45, Paul Walker <Paul.Walker at arm.com> wrote:
>>         MVT::v2i32 -> MVT::nxv2i32
>>         MVT::v2i64 -> MVT::nxv2i64
>>         MVT::v4i32 -> MVT::nxv4i32
>>         MVT::v4i64 -> MVT::nxv4i64
>>         ....likewise for all <#Elements> and <ElementType> combinations
>
> I'm ok with this notation, which can be easily represented by an
> additional scalable flag.
>
>
>>         nxv2i8 TRUNC(nxv2i64 ADD((ZERO_EXTEND MVT::nxv2i8), (ZERO_EXTEND MVT::nxv2i8)))
>>
>> Much of the legalisation code is common to all targets and by introducing scalable vector MVTs they also apply to SVE as long as the "scalable" flag is preserved when transforming MVTs.
>
> This seems to work well with the new flag.
>
>
>> To achieve this we want to popularise the use of functions like EVT::getHalfSizedIntegerVT as well as replace some common code uses of getVectorNumElements with another function that passes #Elements and the "scalable" flag as opaque data, using operator overloading when extending/shrinking #Elements proportionately.
>
> This makes sense for SVE, which has the concept of "multiple
> multiples" of the scalar type instead of just larger vectors of
> unknown size. I don't know how RISC V does it, but it would be good to
> know if it's at least similar.

The RISC-V vector ISA remains a draft (see
https://github.com/riscv/riscv-isa-manual/blob/master/src/v.tex or
https://riscv.org/wp-content/uploads/2016/12/Wed0930-RISC-V-Vectors-Asanovic-UC-Berkeley-SiFive.pdf).
However, in its current incarnation there is no restriction that a
vector must be a given multiple of 128-bits. For any valid vector
configuration (e.g. a vector of F64 elements), you can depend on the
fact that requesting a vector length of 4 will always succeed.

Best,

Alex


More information about the llvm-dev mailing list