On Wed, 6 May 2026 10:28:39 GMT, Jatin Bhateja <[email protected]> wrote:
>> Add a new Float16lVector type and corresponding concrete vector classes, in >> addition to existing primitive vector types, maintaining operation parity >> with the FloatVector type. >> - Add necessary inline expander support. >> - Enable intrinsification for a few vector operations, namely >> ADD/SUB/MUL/DIV/MAX/MIN/SQRT/FMA. >> - Use existing Float16 vector IR and backend support. >> - Extended the existing VectorAPI JTREG test suite for the newly added >> Float16Vector operations. >> >> The idea here is to first be at par with Float16 auto-vectorization support >> before intrinsifying new operations (conversions, reduction, etc). >> >> The following are the performance numbers for some of the selected >> Float16Vector benchmarking kernels compared to equivalent auto-vectorized >> Float16OperationsBenchmark kernels. >> >> <img width="1344" height="532" alt="image" >> src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a"; >> /> >> >> Initial RFP[1] was floated on the panama-dev mailing list. >> >> Kindly review the draft PR and share your feedback. >> >> Best Regards, >> Jatin >> >> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Jatin Bhateja has updated the pull request incrementally with one additional > commit since the last revision: > > Review comments resolution src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java line 68: > 66: * type ({@code Float16}) and the carrier type ({@code short}) will > 67: * remain distinct. > 68: */ Here's an alternative for the class doc: /** * A specialized {@link Vector} representing an ordered immutable sequence of * 16-bit data values in the IEEE 754 binary16 format. * <p> * The scalar {@linkplain Float16Vector#elementType() element type} of {@code Float16Vector} * is the class {@link Float16}, a <a href="{@docRoot}/java.base/java/lang/doc-files/ValueBased.html">value-based</a> * class holding 16-bit data in IEEE 754 binary16 format. However, the {@code Float16} * class is not used by vector operations that accept scalar element values, or * arrays of scalar element values. Instead, the primitive type {@code short} is * used to explicitly hold 16-bit data in IEEE 754 binary16 format. For such operations * it may be necessary to explicitly convert between floating-point values of {@code Float16} * or {@code float} and values of {@code short} using the appropriate conversion * methods on {@code Float16} or {@code Float}. * * @apiNote * {@code Float16} is currently a value-based class and therefore cannot be optimally * used as the scalar element type of vector operations until it becomes a value class * that behaves similarly to the primitive type {@code short} and arrays of. * For example, accessing {@code Float16} vectors using arrays requires those arrays be * {@code short[]} arrays. Accessing vectors using memory segments requires, naturally, * that consecutive 16-bits of memory hold 16-bit data values in the IEEE 754 binary16 * format. * @see Float16 * @see Float16#float16ToRawShortBits(Float16) * @see Float16#shortBitsToFloat16(short) * @see Float#floatToFloat16(float) * @see Float#float16ToFloat(short) */ I think it is better to avoid the term carrier type, backing storage element, and flat. It gets too much into implementation and optimization details and introduces terminology not used anyway else. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r3196579401
