On Wed, 28 Jan 2026 16:42:47 GMT, Paul Sandoz <[email protected]> wrote:
>>> 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. Hi @PaulSandoz , As planned all the generic portions of PR were split out of this PR and integrated separately into JDK mainline. What we have now is centered around Float16 changes. Please let me know your comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-4082973627
