On Mon, 8 Jun 2026 08:38:13 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 resolved This failure is `Float16` related, but looks like a test-bug / missing adaptations for Float16. I'm getting wrong results with `Float16Vector` from the fuzzer, with your latest fuzzer patch: `/home/empeter/Documents/oracle/jtreg/bin/jtreg -va -s -jdk:/home/empeter/Documents/oracle/jdk-fork1/build/linux-x64-debug/jdk -javaoptions:"-Djdk.test.lib.random.seed=-6492554722988565803 -XX:-BackgroundCompilation" -J-Djavatest.maxOutputSize=10000000 /home/empeter/Documents/oracle/jdk-fork1/open/test/hotspot/jtreg/compiler/vectorapi/VectorExpressionFuzzer.java` Error Output ------------ ERROR: Equality matching failed aParent: <none> bParent: <none> field: <root>.toArray -> to MemorySegment a: MemorySegment{ kind: heap, heapBase: [S@ebfe707, address: 0x0, byteSize: 16 } b: MemorySegment{ kind: heap, heapBase: [S@6c1f6481, address: 0x0, byteSize: 16 } MemorySegment a: heap base: [S@ebfe707 address: 0 byteSize: 16 MemorySegment b: heap base: [S@6c1f6481 address: 0 byteSize: 16 Value mismatch at byte offset: 15 00 00 00 7e 00 7e 00 7e 00 7e 00 7e 00 7e 00 fe ^^ 00 00 00 7e 00 7e 00 7e 00 7e 00 7e 00 7e 00 7e This is the relevant generated test: 703 static final Object GOLD_66 = test_66(); 704 705 @Test(allowNotCompilable = true) 706 public static Object test_66() { 707 try { 708 return Float16Vector.broadcast(Float16Vector.SPECIES_128, (short)0).lanewise(VectorOperators.FMA, Float16Vector.broadcast(Float16Vector.SPECIES_128, (short)31744), Float16Vector.broadcast(Float16Vector.SPECIES_128, (short)3 2256), VectorMask.fromLong(Float16Vector.SPECIES_128, 18014398509481982L)).lanewise(VectorOperators.FIRST_NONZERO, (short)0, Float16Vector.broadcast(Float16Vector.SPECIES_128, (short)-32768).test(VectorOperators.IS_DEFAULT) ); 709 } finally { 710 // Just so javac is happy if there are no exceptions to catch. 711 } 712 } 713 714 @Check(test = "test_66") 715 public static void check_66(Object result) { 716 Verify.checkEQ(result, GOLD_66); 717 } I think the issue is probably with the test, or more precisely with missing adaptation of `Verify.java` for the `Float16Vector`. https://github.com/openjdk/jdk/pull/30997/changes#r3372009665 The issue is that `Float16Vector::toArray` returns a `short[]`, and then comparing values may fail if we get different NaN bits. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-4647196480
