RFR: 8321010: RISC-V: C2 RoundVF [v3]
Hamlin Li
mli at openjdk.org
Wed Apr 10 13:10:11 UTC 2024
On Wed, 10 Apr 2024 03:21:35 GMT, Fei Yang <fyang at openjdk.org> wrote:
>> 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 spec even doesn't specify a default dynamic rounding mode in `frm` at the ISA level. This reminds me that we might be lacking some pieces of the puzzle.
>
> If we want to keep `RNE` (Round to Nearest) as a default dynamic rounding mode for Java code (like you do in this PR), we will also need to save and restore the floating-point control state perfering `RNE` when we enter and leave Java code. Something similar for aarch64: https://bugs.openjdk.org/browse/JDK-8319973. This will also help eliminate existing explict settings of dynamic rounding mode to `RNE` 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 : -)
Thanks for discussion.
Sure. Let me do some investigation and fix it first.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17745#discussion_r1559407042
More information about the hotspot-compiler-dev
mailing list