On Wed, 17 Dec 2025 12:56:01 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/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 > > Jatin Bhateja has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 23 commits: > > - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Including test changes from Bhavana Kilambi (ARM) > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Optimizing tail handling > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Cleanups > - Fix failing jtreg test in CI > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Cleanups > - ... and 13 more: https://git.openjdk.org/jdk/compare/5e7ae281...703f313d Just some quick comments for now. I think this is better heading in the right direction. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java line 436: > 434: } else { > 435: assert(Float16.valueOf(i).intValue() == i); > 436: } It would be clearer if the same pattern is copied as for the other types. Assign and assert, no need to check bounds. We don't need to be performant here. (This code may become even clearer when we can leverage patterns on the primitive types and custom numeric types.) src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java line 3083: > 3081: * @return a {@code Float16Vector} with the same shape and > information content > 3082: */ > 3083: public abstract Float16Vector reinterpretAsFloat16s(); At some point we should consider consolidating these methods into one which accepts the lane element type as an argument. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java line 277: > 275: if (etype == Float16.class) { > 276: etype = short.class; > 277: } My suggestion may not worth it, but i was wondering if we could get the lane type and then use the carrier type, rather then encoding this more specifically. ------------- PR Review: https://git.openjdk.org/jdk/pull/28002#pullrequestreview-3636482293 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2669808367 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2669818576 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2669827315
