On Thu, 17 Oct 2024 23:11:07 GMT, Joe Darcy <da...@openjdk.org> wrote:
> Port of Float16 from java.lang in the lworld+fp16 branch to > jdk.incubabor.vector. Joe, our revised and now-current thinking about JIT support for the Float16 (both as a pre-Valhalla VBC and Valhalla value class) is that there should be zero need for any `@IntrinsicCandidate` markers in `Float16.java`. The two existing intrinsics in `Float.java` should be fully sufficient to cue the JIT to introduce FP16 types and operations in its IR. There is no need to help the JIT either recognize Float16 objects as special types, nor recognize the special interpretation of the `short` value field inside. It is very routine in the Valhalla JIT to strip off the boxing (i.e., the VBC-like Float16 details) and just deal directly with the payload (i.e., the `short` value). And it is also routine to change perspective on live values in the IR, depending on how they are used (i.e, via the two `Float` intrinsics), so that the IR ends up storing FP16 temps in whatever register class the CPU likes best. So, unless there is some reason I am not aware of, there does not need to be any intrinsic definition in `Float16.java`, nor even a comment that gestures at the possible existence of an intrinsic.] Note the economy of the resulting design: Two intrinsics at the Java level provide the JIT with ample opportunity (if it so desires) to organize an IR with a full FP16 type and all its typed operations. There is no need to surface such complexity in the Java source code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21574#issuecomment-2424264803
