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/gen-src.sh line 164: > 162: carriertype=short > 163: Carriertype=Short > 164: FPtype=FP16 Do we need this? Can we just explicitly declare `-KFP16` instead in the `Float16` case args? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/gen-src.sh line 171: > 169: lanebitsType=LT_SHORT > 170: fallbacktype=float > 171: args="$args -KbyteOrShort -KshortOrFP -KshortOrFloat16" Are the latter two used, I don't see any use in the templates. There are also a bunch of other variables and keys declared for various cases but AFAICT are not used in the templates. This makes it really hard to reason about this complex area. Although arguably garbage collecting all such variables and keys is potentially beyond this PR I think it is worth it for clarity and the impact is small. Just go through 'em one by one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r3198072782 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r3198088642
