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

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 7 09:50:12 PST 2017


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.


> At the worst case, any common code that can never work for scalable vectors would be guarded by the "scalable" flag.

In the case of SIMD vs. SVE, I imagine the EVT functions above would
be "simple if/else on the scalable flag" wrappers. In the case where
RISC V is different, or if Intel wants to avoid larger vector sizes
for AVX1024, it would be slightly more complicated, but not by much.

Overall the idea looks sane and simple to me. Of course, we need to
wait for other people to offer their arguments, but having some code
to look at would help to gauge the amount of changes necessary (I'm
not expecting much).

A simple split for this series would be: new helpers working on SIMD,
new types supported, then expanded helpers to support scalable types.

cheers,
--renato


More information about the llvm-dev mailing list