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

[Vladimir Ivanov]

Hi Ningsheng,

>> 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.

Yes, I'd like the names to clearly manifest it's the vector of maximum 
size available at runtime. Maybe *MaxVector, but I'm not too happy with 
it as well.

>> 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?

There are 4 methods which change vector shape: resize/rebracket/reshape 
and cast.

   (1) Vector.resize() changes only vector length (either shrinking or 
widening) without touching element types:
   Int64Vector <-> Int128Vector <-> Int256Vector <-> Int512Vector

   Javadoc for Shape.resize() says [2]:
     * The lane elements of the input vector are copied without
     * modification to the resulting vector, but those lane elements, before
     * copying, may be truncated if the vector length is greater than this
     * species length, or appended to with default element values if the
     * vector length is less than this species length.


   (2) Vector.rebracket() changes only vector element type leaving 
vector size intact
   Byte256Vector <-> Short256Vector <-> Int256Vector <-> Long256Vector

   Javadoc says [3]:
     * The underlying bits of the input vector are copied without
     * modification to the resulting vector.


   (3) Vector.reshape generalizes resize() & rebracket() and enables 
arbitrary conversions between vector shapes:
   Byte64Vector <-> ... <-> Double512Vector
    * The underlying bits of the input vector are copied to the resulting
    * vector without modification, but those bits, before copying, may be
    * truncated if the vector bit size is greater than this species bit
    * size, or appended to with zero bits if the vector bit size is less
    * than this species bit size.


   (4) Vector.cast() allows arbitrary casts between vector shapes
   Byte64Vector <-> ... <-> Double512Vector

   Javadoc for Shape.cast() says [4]:
     * For each input vector lane up to the length of the input vector or
     * this species, which ever is the minimum, and where {@code N} is the
     * vector lane index, the element at index {@code N} of primitive type
     * {@code F} is converted, according to primitive conversion rules
     * specified by the Java Language Specification, to a value of primitive
     * type {@code E} and placed into the resulting vector at lane index
     * {@code N}.  If this species length is greater than the input
     * vector length then the default primitive value is placed into
     * subsequent lanes of the resulting vector.

Right now, resize(), rebracket(), and cast() are intrinsified on x86 
while reshape() is not.


So, my question boils down to: how vector shape checks are expected to 
work on *ScalableVectors in presence of operations which change vector size.

For example, IntScalableVector.rebracket() => LongScalableVector which 
is fine, but ISV.resize() => ISV is what I'm concerned about and 
existing checks aren't enough for *ScalableVectors unless you check 
their length at runtime.

>>> 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.

Looking forward to the results!

Best regards,
Vladimir Ivanov

[1]
<T extends Shape>
Vector<E, T> resize(Species<E, T> species);
...
* Transforms this vector to a vector of the given species shape {@code T},
* where this vector's element type {@code E} is preserved.
...

<F>
Vector<F, S> rebracket(Species<F, S> species);
...
* Transforms this vector to a vector of the given species element type
* {@code F}, where this vector's shape {@code S} is preserved.
...

<F, T extends Shape>
Vector<F, T> reshape(Species<F, T> species);
...
* Transforms this vector to a vector of the given species shape {@code T}
* and element type {@code F}.
...

<F, T extends Shape>
Vector<F, T> cast(Species<F, T> species);
...
      * Converts this vector to a vector of the given species shape 
{@code T} and
      * element type {@code F}.
...

[2] 
http://hg.openjdk.java.net/panama/dev/file/e8f06cc3fe82/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java#l1226

[3] 
http://hg.openjdk.java.net/panama/dev/file/e8f06cc3fe82/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java#l1193

[4] 
http://hg.openjdk.java.net/panama/dev/file/e8f06cc3fe82/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java#l1253