[vector] RFC: Add scalable shapes for Arm Scalable Vector Extension

[Ningsheng Jian (Arm Technology China)]

Hi Vladimir,

Thanks a lot for your comments! 

>
> First of all, it's great to see Arm looking into Vector API! Welcome!
> 
> > As you may know that Arm SVE architecturally supports scalable vector length,
> from 128 to 2048bits, multiple of 128bits. Currently Vector API only supports 64,
> 128, 256 and 512 bit vector shapes. It's inappropriate to pre-generate all SVE
> supported shapes, hence, we propose a new type of vector for scalable length
> (or length agnostic) shapes.
> >
> > Webrev:
> > http://cr.openjdk.java.net/~njian/sve/vectorapi.webrev00/
> >
> > Could you please help to take a look at this? The *ScalableVector are the new
> scalable length vectors and to be compatible with existing architectures, the
> preferredSpecies() will return those known species first.
> 
> Overall, I like how it shapes out. There are some aspects I'd like to clarify though.
> 
> The name (*ScalableVector) is slightly misleading to me, but I'm fine with it.  I
> interpret new shapes as representing vectors of maximally supported size at
> runtime without specifying the actual size.
> 

I am happy to change the name if you have some suggestion. The new shapes are representing current (SVE) hardware supported (max) vector register size, and the actual size is known at runtime. 

> New shapes don't interoperate well with existing ones, so unless you change
> how vector shapes are checked (==), at runtime scalable and fixed shape variants
> shouldn't meet. That leads to the next question: how do you expect vector
> shape changing operation working (resize(), rebracket(), cast()) with new variants?
> 

Those vector changing operations are in my TODO list. The scalable shapes are actually fixed length shape during runtime, so I think it is possible to implement those operations. But I am still don't quite understand the motivation and use cases of  those vector shape changing APIs. Could you please help to explain a bit?

> > We are working on SVE support on OpenJDK, and current Vector API's intrinsics
> can really help us on our SVE backend work. We have an initial prototype which
> adds SVE backend and updates a bit for current register allocator to support
> scalable length vector types. Our WIP SVE backend shows that this scalable
> vector proposal works fine with current Vector API intrinsics. We would like to
> collect your comments about this scalable vector patch so that we can move
> forward for the SVE backend support. I notice that Vladimir is also thinking about
> alternative loop shapes, that's really helpful for SVE! We will also take a look at
> that further.
> 
> It's very encouraging to hear existing intrinsics generalize well to SVE. Looking
> forward to seeing the results of SVE backend work. Feel free to share your pain
> points while implementing it.

Thanks! We will also evaluate the Arm NEON implementation and performance for current Vector API.

Thanks,
Ningsheng