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

[Paul Sandoz]

On Tue, 27 Jan 2026 18:25:25 GMT, Paul Sandoz <psandoz 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 34 commits:
>> 
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>>  - Clanups
>>  - Refactoring vectorIntrinsics
>>  - Refactoring and cleanups
>>  - Refactoring and cleanups
>>  - Review comments resolutions
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>>  - Adding testpoint for JDK-8373574
>>  - Review comments resolutions
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
>>  - ... and 24 more: https://git.openjdk.org/jdk/compare/0f1b96a5...ce5768fa
>
>> We will still need to create T_FLOAT16 basic type and associate it with Float16 LaneType, why not directly pass these basic types to intrinsic entry point ?
> 
> The strong feedback from HotSpot folks, which i agree with, is adding a new enum value to `BasicType` is not the way to go - it is too disruptive and does not scale. Sorry if i misled you earlier on, it was my intention in feedback to propose something that was limited in scope to vector support.
> 
> The thought about a proxy class was motivated by a question i had - what would we do if `Float16.class` was already present in `java.base`? and answers to that might motivate what we do now in preparation for when that happens. Regardless i think we need to separate out the Vector API's direct dependence on BasicType and its values. Instead we should define our own constants for the vector element types, and provide mapping of those to BasicType values which might result in "erasure" to the carrier type. We should adjust/adapt LaneType accordingly. Does that make sense to you?

> Hi @PaulSandoz , Yes this looks good to me, I have modified the patch accordingly.

Thanks, i think this is much better, more localized.

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

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3812429459