RFR: 8318158: RISC-V: implement roundD/roundF intrinsics [v2]

[Vladimir Kempik]

On Sun, 12 Nov 2023 09:34:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> But doing fadd 0.5 to the number, which can't have fractional part, in rdn mode becomes no-op.
>> At least on single precision floats it works:
>> fadd(-8388609.0, +0.5, rdn) results in -8388609.0
>> and the mode for both fadd and fcvt will be the same, (perf tests showed no difference on thead tho)
>
> Maybe. I didn't try it, but on a great big out-of-order machine changing floating-point modes can be fantastically expensive, forcing ops in progress to retire, changing mode, and then continuing. Effectively it's as bad as a mispredict. Given that a correct solution that doesn't involve changing modes is available, I don't see why you wouldn't use it.

I have consulted with our h/w team and they told me next:
multi-issue FP Unit can process few (data-independent) fp instructions at a time, even if they have different rounding mode.
The only issue is when the rounding mode is set to dynamic rounding (aka get it from csr), but it's not our case here

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16382#discussion_r1390820971