RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter

[Sandhya Viswanathan]

On Wed, 22 Feb 2023 04:03:02 GMT, David Holmes <dholmes 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?

@dholmes-ora @jddarcy @TobiHartmann @vnkozlov   From @dean-long 's comment in the JBS entry, he sees the same result on AARCH64 and Intel, i.e. the output has the QNaN bit set.
Please let me know if we want to proceed with this PR or if it would be good to withdraw this. I am open to either suggestion. Please advice.

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

PR: https://git.openjdk.org/jdk/pull/12704