RFR: 8345146: [PPC64] Make intrinsic conversions between bit representations of half precision values and floats [v3]

[Richard Reingruber]

On Mon, 2 Dec 2024 14:13:15 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make sure interpreter entries are not called on Power8 or older.
>
> src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp line 700:
> 
>> 698:       LIR_Opr tmp = new_register(T_FLOAT);
>> 699:       // f2hf treats tmp as live_in. Workaround: initialize to some value.
>> 700:       __ move(LIR_OprFact::floatConst(-0.0), tmp); // just to satisfy LinearScan
> 
> @vnkozlov What do you think about introducing a dummy `LIR_Op0` which provides an undefined float for such workarounds (separate RFE)? That could be used on multiple platforms.

I'm trying to understand this. Wouldn't `_floatToFloat16` naturally be modeled as a `LIR_Op1`? `LIR_Op1` cannot currently accomodate a tmp. That's why `LIR_Op2` is used. Is that correct?
If so, wouldn't it be best to add a tmp to `LIR_Op1`? 
And if we don't want to do that then we could still use `LIR_O2::_tmp1`, can't we? This is a [little experiment](https://github.com/reinrich/jdk/commit/c34ef322c7eb9708afb804e08fec6bc4933260e5) which does so. Binary16Conversion.java succeeds with it.
And if we don't want to change shared code then we could have one float scratch register that's not allocated by linear scan.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22433#discussion_r1870316991