RFP: New vector operations and APIs.

[Bhateja, Jatin]

Hi Paul,

> For the saturating operations in this proposal I would recommend focusing
> on the integral types, and we would need to add the scalar operations on
> the boxed types. Do you have any thoughts on other saturating operations?
> (perhaps as subsequent proposals based on demand/user-feedback)

Quoting John's suggestions from an internal communication.

"We should think about other unsigned operations, notably MIN, MAX, MUL, DIV.  The unsigned min/max guys are easy to emulate from Java: Just XOR the sign bit before doing the min/max, and then XOR it back (if necessary) after selecting the “winner”."

> It’s really powerful that we can state how the two-table selectFrom is
> composed from other vector operations. I suppose the index values can be
> out of bounds, so some checking is required before using the composed
> form and shuffle conversion?

As per API specification of two vector rearrange, exceptional indices are wrapped around without throwing an index out of bounds exception, as you rightly pointed out, newly
proposed API should throw an IndexOutOfBoundsException if an index lies outside two vector indices range i.e. [0, VEC_LANE_COUNT) before transforming vector to a wrapped index range shuffle.

Best Regards,
Jatin 

> -----Original Message-----
> From: Paul Sandoz <paul.sandoz at oracle.com>
> Sent: Monday, May 13, 2024 11:24 PM
> To: Bhateja, Jatin <jatin.bhateja at intel.com>
> Cc: panama-dev at openjdk.org; John Rose <john.r.rose at oracle.com>;
> Viswanathan, Sandhya <sandhya.viswanathan at intel.com>
> Subject: Re: RFP: New vector operations and APIs.
> 
> This proposal looks good to me, as is the target (the JDK 23 RDP 1 date is
> close).
> 
> For the saturating operations in this proposal I would recommend focusing
> on the integral types, and we would need to add the scalar operations on
> the boxed types. Do you have any thoughts on other saturating operations?
> (perhaps as subsequent proposals based on demand/user-feedback)
> 
> It’s really powerful that we can state how the two-table selectFrom is
> composed from other vector operations. I suppose the index values can be
> out of bounds, so some checking is required before using the composed
> form and shuffle conversion?
> 
> Paul.
> 
> > On May 12, 2024, at 6:55 PM, Bhateja, Jatin <jatin.bhateja at intel.com>
> wrote:
> >
> > Hi All,
> >
> > Please find below the proposal for adding new vector operators and API
> based on the user's feedback.
> >
> > A) New VectorAPI operations.
> >     . VectorOperators.SATURATING_UNSIGNED_ADD
> >     . VectorOperators.SATURATING_UNSIGNED_SUB
> >     . VectorOperators.SATURATING_ADD
> >     . VectorOperators.SATURATING_SUB
> >
> > Applicable Types for new operators:
> > Prosed vector operators are applicable to integral types since their values
> wraparound in over/underflowing scenarios after setting appropriate status
> flags.
> > For floating point types, as per IEEE 754 specs there are multiple schemes
> to handler underflow, one of them is gradual underflow[2] which transitions
> the value to subnormal range. Similarly, overflow implicitly.
> > saturates the floating-point value to a representable range or an Infinite
> value.
> > As the name suggest, these are saturating operations, i.e. the result of the
> computation is strictly capped by lower and upper bounds of the result type
> and is not wrapped around in underflowing or overflowing scenarios.
> >
> > B) New Vector API.
> >    . Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> >
> > Using index values stored in the lanes of this vector, assemble values
> stored in first (v1) and second (v2) vector arguments. Thus, first and second
> vector serves as a table, whose elements are selected by indexes in the
> current vector. API is applicable to all integral and floating-point types.  The
> result of this operation is semantically equivalent to expression
> Vector.blend(v1.rearrange(this.toShuffle(), v2,rearrange(this.toShuffle),
> this.toShuffle().laneIsValid()). This is a convenience API for an existing
> rearrange API[2], we already have such a convenience API
> "Vector.selectFrom(Vector)"[3] for single vector permute, proposed API
> extends it to two vector permute.
> >
> > Target Architecture Support:-
> > New operators should emit optimum instruction sequence for supported
> target platforms.
> >
> > We plan to target these extensions for JDK-24.
> >
> > Please let us know your comments.
> >
> > Best Regards,
> > Jatin
> >
> > [1] https://docs.oracle.com/cd/E19957-01/806-
> 3568/ncg_math.html#:~:text=How%20Does%20IEEE%20Arithmetic%20Treat%
> 20Underflow%3F
> > [2]
> https://docs.oracle.com/en/java/javase/22/docs/api/jdk.incubator.vector/jdk
> /incubator/vector/Vector.html#rearrange(jdk.incubator.vector.VectorShuffle,j
> dk.incubator.vector.Vector)
> > [3]
> https://docs.oracle.com/en/java/javase/22/docs/api/jdk.incubator.vector/jdk
> /incubator/vector/Vector.html#selectFrom(jdk.incubator.vector.Vector)
> >
> >
> >
> >
> >