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

[Ningsheng Jian (Arm Technology China)]

Hi Vladimir,

> 
> My understanding from the patch you shared is that vector size is fixed across
> the run and is set to maximally supported [1]
> 
> IMO "variable length" is misleading in a sense it may be erroneously interpreted
> as "vectors of that shape may be of different size at runtime", so user have to
> check for that. In that respect, "*Max*"
> clearly refers to *some* size (fixed across the run) without specifying what the
> actual size is, but user can query it at runtime.
> 

Yes, it is fixed across different run in the same system. OK, I will leave it open for now.

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

> 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