RFR: 8338021: Support new unsigned and saturating vector operators in VectorAPI [v13]

Jatin Bhateja jbhateja at openjdk.org
Mon Oct 21 08:45:59 UTC 2024


On Thu, 19 Sep 2024 06:28:35 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>>> > > Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?
>>> > 
>>> > 
>>> > Nomenclature is suggested by Paul.
>>> 
>>> @PaulSandoz Do you want to limit these **scalar** operations to a class name that implies **vector** use?
>>> 
>> 
>> It's whatever math functions are required to in support of vector operations (as the JavaDoc indicates) that are not provided by other classes such as the boxed primitives or `java.lang.Math`.
>> 
>> 
>> /**
>>  * The class {@code VectorMath} contains methods for performing
>>  * scalar numeric operations in support of vector numeric operations.
>>  */
>> public final class VectorMath {
>> 
>> 
>> These are referenced by the vector operators e.g.,
>> 
>> 
>>     /** Produce saturating {@code a+b}.  Integral only.
>>      * @see VectorMath#addSaturating(int, int)
>>      */
>>     public static final Binary SADD = binary("SADD", "+", VectorSupport.VECTOR_OP_SADD, VO_NOFP);
>> 
>> 
>> And in addition these methods would be used by any tail computation (and the fallback code).
>> 
>> At the moment we are uncertain whether such operations should reside elsewhere and we did not want to block progress. I am not beholden to the name, but so far i cannot think of a concise alternative.`VectorOperatorMath` is arguably more precise but more verbose.
>
>> > > > Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?
>> > > 
>> > > 
>> > > Nomenclature is suggested by Paul.
>> > 
>> > 
>> > @PaulSandoz Do you want to limit these **scalar** operations to a class name that implies **vector** use?
>> 
>> It's whatever math functions are required to in support of vector operations (as the JavaDoc indicates) that are not provided by other classes such as the boxed primitives or `java.lang.Math`.
> 
> Ok. I suppose these methods could eventually be moved to `java.lang.Math` or some other `java.lang` class, when the VectorAPI goes out of incubator mode?
> 
> I feel like these saturating operations, and also the unsigned ops could find a more wider use, away from (explicit) vector usage. For example, the saturating operations are nice because they prevent overflows, and in some cases that would be very nice to have readily available.

Hi @eme64 , 

Can you kindly review following changes, rest of the portions are already reviewed and approved.

https://github.com/openjdk/jdk/pull/20507/commits/2b0fa01633875926595656d8dcfd539c334f23a3

https://github.com/openjdk/jdk/pull/20507/commits/c56508899b000b8b1eb6755c901798a2a3685ef5

Best Regards,
Jatin

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2426005754


More information about the core-libs-dev mailing list