RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter
David Holmes
dholmes at openjdk.org
Wed Feb 22 04:05:30 UTC 2023
On Wed, 22 Feb 2023 02:08:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:
> Change the java/lang/float.java and the corresponding shared runtime constant expression evaluation to generate QNaN.
> The HW instructions generate QNaNs and not SNaNs for floating point instructions. This happens across double, float, and float16 data types. The most significant bit of mantissa is set to 1 for QNaNs.
I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have three mechanisms for implementing this functionality:
1. The interpreted Java code
2. The compiled non-intrinisc sharedRuntime code
3. The compiler intrinsic that uses a hardware instruction.
Unless the hardware instructions for all relevant CPUs behave exactly the same, then I don't see how we can have parity of behaviour across these three mechanisms.
The observed behaviour may be surprising but it seems not to be a bug. And is this even a real concern - would real programs actually need to peek at the raw bits and so see the difference, or does it suffice to handle Nan's opaquely?
-------------
PR: https://git.openjdk.org/jdk/pull/12704
More information about the core-libs-dev
mailing list