On Tue, 27 Jan 2026 18:25:25 GMT, Paul Sandoz <[email protected]> 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
