RFP: New vector operations and APIs.

[Bhateja, Jatin]

Hi All,

I have created a private branch for new operations / API support[1] for early feedback and for convenience of adding backend support for other targets,  one missing piece is x86 backend support for saturated operations which is work in progress.

Intrinsification of newly added core library routines and its auto-vectorization will be taken after completion of planned vector API support.

Best Regards,
Jatin
[1] https://github.com/jatin-bhateja/jdk/tree/vector_api_9th_incubation

> -----Original Message-----
> From: panama-dev <panama-dev-retn at openjdk.org> On Behalf Of Bhateja, Jatin
> Sent: Tuesday, May 14, 2024 8:30 PM
> To: Paul Sandoz <paul.sandoz at oracle.com>
> Cc: panama-dev at openjdk.org; John Rose <john.r.rose at oracle.com>;
> vladimir.x.ivanov at oracle.com; Viswanathan, Sandhya
> <sandhya.viswanathan at intel.com>
> Subject: RE: RFP: New vector operations and APIs.
> 
> 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.vecto
> > r/jdk
> > /incubator/vector/Vector.html#rearrange(jdk.incubator.vector.VectorShu
> > ffle,j
> > dk.incubator.vector.Vector)
> > > [3]
> > https://docs.oracle.com/en/java/javase/22/docs/api/jdk.incubator.vecto
> > r/jdk
> > /incubator/vector/Vector.html#selectFrom(jdk.incubator.vector.Vector)
> > >
> > >
> > >
> > >
> > >