RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9]

[Jatin Bhateja]

On Wed, 7 Jan 2026 06:55:45 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> 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
>
> test/jdk/jdk/incubator/vector/Float16Vector64Tests.java line 1893:
> 
>> 1891:         VectorMask<Float16> m = three.compare(VectorOperators.LE, higher);
>> 1892:         assert(m.allTrue());
>> 1893:         m = higher.min((short)-1).test(VectorOperators.IS_NEGATIVE);
> 
> I find that `higher.min((short)-1)` produces a float16 vector of 4 NaNs. So are we testing for negative NaNs with `VectorOperators.IS_NEGATIVE`? Is it more reasonable to test `VectorOperators.IS_NAN` instead?

Thanks for catching this, all the Float16Vector lanes and short argument passed to shorthand APIs are assumed to be encoded in IEEE 754 binary 16 format,  we should be passing Float16 bit representation of -1 here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2667602759