On Fri, 19 Jun 2026 05:18:40 GMT, Jatin Bhateja <[email protected]> wrote:
>> As per the discussion on JDK-8370691-Float16Vector Support pull request >> https://github.com/openjdk/jdk/pull/28002#issuecomment-4652163477 >> adding the handling to Canonicalize NaN lane encodings held in Float16Vector >> lanes so that all NaN representations, >> including signaling ones, computes the same hash code. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin >> >> --------- >> - [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 with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains two additional > commits since the last revision: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8386255 > - 8386255: Float16Vector NaN canonicalization for hashCode computation src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java line 3742: > 3740: // including signaling ones, contribute the same hash code. > 3741: for (int i = 0; i < a.length; i++) { > 3742: a[i] = > Float16.float16ToShortBits(Float16.shortBitsToFloat16(a[i])); It might be better to check whether the bitpattern is a `NaN` instead of going through the `Float16` allocation (which relies on inlining and escape analysis to be eliminated, at least until **Valhalla** arrives and `Float16` becomes a real value class) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31587#discussion_r3444264411
