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

[Vladimir Ivanov]

>>>> 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.
>>>
>>> Thanks for the detailed explanation. So, which checks do you mean here? Do
>> you mean this [1]? I find that current Java implementations already has some
>> runtime length checks. One thing we need to consider is the ambiguity between
>> existing sizes and scalable size. Current VectorIntrinsics.reinterpret() just tries to
>> get the shape from size (library_call.cpp:get_exact_klass_for_vector_box) instead
>> of getting the real class from input argument, which will lead to
>> ClassCastException. Maybe that can be fixed by adding real klass type to the
>> reinterpret function.
>>
>> The checks I referred to are the casts on vector shapes which are part of every
>> vector operation (e.g., [2]), but they don't immediately relate to shape-changing
>> operations.
>>
> 
> OK, but I would expect the normal operations between SV and other vectors are illegal, though they may have the same size, since users usually don't know the real size of SV. We should treat SV different from other vectors.

Yes, the checks currently in place effectively forbid mixing vectors of 
different shapes. But API allows to reshape/cast vectors to arbitrary 
shapes and that may cause problems if equivalent shapes meet at runtime.

Since concrete vector shapes aren't part of API, I believe it is 
possible to exclude duplicating shapes at runtime. For example, SVs can 
be used as a substitute for *512V shapes on 512-bit SVE or 
AVX512-capable hardware. It seems current JDK-JVM interface 
(VectorIntrinsics) should fit SV purposes well (both on x86 & ARM), but 
it would be very interesting to hear your experience.

API allows to query vectors of smaller/larger sizes than hardware 
natively supports and implementation has to support that (even if 
performance suffers). It means SV shapes can coexist at runtime with 
existing shapes (*64V/.../*512V) and casts/reshapes between all those 
shapes should work.

Best regards,
Vladimir Ivanov

>> It seems I had some wrong assumptions when coming up with the examples.
>> Sorry for the confusion. Taking those into account, here's my take on current
>> state of vector shape changing operations w.r.t. SV shapes.
>>
>> There'll be 30 vector shapes in total (5 sizes x 6 element types):
>>     * Byte64V, Byte128V, Byte256V, Byte512V, ByteSV
>>     * Short64V, ..., ShortSV
>>     ...
>>     * Double64V, Double128V, ... Double512V, DoubleSV
>>
>> Depending on hardware, SVs may alias with "explicitly sized" shapes (e.g., IntSV is
>> equivalent to Int512V on AVX512 capable H/W).
>>
>> (1) Vector.rebracket(): works fine for SVs since vector size (in bits) stays the same:
>> IntSV <-> LongSV <-> ... <-> DoubleSV.
>>
>> (2) Vector.resize(): SV->SV doesn't make sense and the operation should involve
>> both SV and existing vector shapes: IntSV <-> Int64V/Int128V/.../Int512V. The
>> ambiguity you mention can cause problems and needs to be carefully handled to
>> avoid 2 equivalent shapes to meet at runtime. Otherwise, vector shape checks I
>> mentioned earlier should be changed.
>>
> 
> Yes, we will try to address this issue carefully in the follow-up webrev.
> 
>> (3) Vector.cast(): SV->SV, SV<->64V/.../512V
>>       * size-preserving transformations (int <-> float):
>>         SV->SV work fine: IntSV <-> FloatSV, LongSV <-> DoubleSV;
>>
>>       * widening casts (e.g., int->long)
>>         SV->SV/64V/...:  truncate upper part of the vector, since SVs already
>> represent widest vector shapes;
>>         64V/...->SV: either truncated or filled with defaults depending on actual size
>>
>>       * narrowing casts (e.g., long->int)
>>         SV->SV/64V/...: fill upper part of SV with defaults;
>>         64V/...->SV: either truncated or filled with defaults depending on actual size
>>
> 
> Thanks,
> Ningsheng
>