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

[Martin Doerr]

On Thu, 5 Dec 2024 09:25:11 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> 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.
>
>> 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?
> 
> I didn't write that code, but I believe that this is 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.
> 
> I like this proposal. But I prefer doing that in a separate RFE for all affected platforms.
> 
>> 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.
> 
> I strongly prefer the solution above.

Filed [JDK-8345609](https://bugs.openjdk.org/browse/JDK-8345609).

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

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