RFR: 8321010: RISC-V: C2 RoundVF [v3]

[Fei Yang]

On Tue, 9 Apr 2024 17:20:07 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/riscv_v.ad line 3678:
>> 
>>> 3676:     __ java_round_float_v(as_VectorRegister($dst$$reg), as_VectorRegister($src$$reg),
>>> 3677:                           as_FloatRegister($tmp$$reg));
>>> 3678:     __ csrwi(CSR_FRM, C2_MacroAssembler::rne);
>> 
>> I don't think it's necessary to restore `CSR_FRM` to `rne` after `java_round_float_v`. As I remembered, we always set the required rounding mode in other places where it makes an effect. Similar for vround_d.
>
> Seems it should be unnecessary, but without it, 
> 1. there will be test failure. e.g. test_suba which uses `vsub_fp` intrinsic, and it does not set rounding mode explicitly, also `vsub_fp`, `vdiv_fp`, and so on.
> 2. an assert at `src/hotspot/os/linux/os_linux.cpp:1948` which is triggered at the end of program (when calling System.exit in the test).

Ah, I see. I don't think it's safe for `vsub_fp`, `vdiv_fp`, etc to depend on some uncertain dynamic rounding mode on Java code entry. And it seems that the RISC-V ISA spec even doesn't specifies a default dynamic rounding mode. This reminds me that we might be lacking some pieces of the puzzle.

If we want to keep the `RNE` (Round to Nearest) rounding mode for Java code (like you do in this PR), we will also need to save and restore the default floating-point control state when we enter and leave Java code perfering `RNE`. Something similar for aarch64: https://bugs.openjdk.org/browse/JDK-8319973. Then we can remove the existing settings of rounding mode in file riscv_v.ad (grep "csrwi(CSR_FRM"), which should be good for performance. I would suggest we fix this in another PR before we continue with this one. Let me know if you are interested : -)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17745#discussion_r1558783467