On Thu, 28 May 2026 07:31:56 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 Some comments about documentation issues. There are some stale comments in other files now: `src/hotspot/cpu/aarch64/aarch64_vector_ad.m4` 244 // At the time of writing this, the Vector API has no half-float (FP16) species. 245 // Consequently, AddReductionVHF and MulReductionVHF are only produced by the 246 // auto-vectorizer, which requires strictly ordered semantics for FP reductions. 356 // Currently, the masked versions of the following 8 Float16 operations are disabled. 357 // When the support for Float16 vector classes is added in VectorAPI and the masked 358 // Float16 IR can be generated, these masked operations will be enabled and relevant 359 // backend support added. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java line 4036: > 4034: default: throw new IllegalArgumentException("Bad shape: " + > s); > 4035: } > 4036: } Is the element type really a `short`? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java line 369: > 367: LaneType ran = LaneType.of(to); > 368: return ConversionImpl.ofCast(dom, ran).check(from, to); > 369: } How coherent is it to talk of boxed versions of lane types now, since Float16 is not a primitive type, and cannot be boxed? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java line 682: > 680: public static final Conversion<Byte,Short> B2S = convert("B2S", 'C', > byte.class, short.class, VO_KIND_CAST, VO_ALL); > 681: /** Convert {@code byteVal} to {@code (Float16)byteVal}. */ > 682: public static final Conversion<Byte,Float16> B2H = convert("B2H", > 'C', byte.class, Float16.class, VO_KIND_CAST, VO_ALL); Float16 is not a primitive. What happens when you do a cast `(short)byteVal`? Is that sensible, or should we use the `Float.valueOf(...)` semantics? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 90: > 88: * {@code Float16} is currently a value-based class and therefore cannot > be optimally > 89: * used as the scalar element type of vector operations until it becomes > a value class > 90: * that behaves similarly to the primitive type {@code short} and arrays > of. End of sentence cut off? ------------- PR Review: https://git.openjdk.org/jdk/pull/28002#pullrequestreview-4379028794 PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-4562001786 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r3316233418 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r3316255585 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r3316244104 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r3316225228
