RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
Hamlin Li
mli at openjdk.org
Wed Feb 28 14:22:54 UTC 2024
On Wed, 28 Feb 2024 05:00:13 GMT, Fei Yang <fyang at openjdk.org> wrote:
>> We still want to give end users the ability to disable extensions if things are broken. The flags would be the only way if we rely on hwprobe + vendor specific flags (like https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L232-L260, and which I'm surprised not more hw vendors have added their own)
>
>> We still want to give end users the ability to disable extensions if things are broken. The flags would be the only way if we rely on hwprobe + vendor specific flags (like
>
> That make sense to me. In the long run, we should depend on hwprobe + vendor specific code to auto-enable or disable certain RV extensions on certain hardwares. But I agree on that there should be some options of `DIAGNOSTIC` kind to help diagnose issues and find workarounds. I am OK to make this option an `EXPERIMENTAL` one at the current stage. But we should turn them into the `DIAGNOSTIC` kind in the future when we have the hardwares and hwprobe is capable to satisfy our needs. Mind you, we are lacking one option for https://github.com/openjdk/jdk/pull/17122 in that respect. Let me know if you going to add one.
>
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L232-L260, and which I'm surprised not more hw vendors have added their own)
>
> That will depend on the vendors. Given that the current RV hardwares are not that rich in RV extensions, I guess there isn't much to tune.
Thanks for comments and discussion, made UseZvfh experimental.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1506039298
More information about the hotspot-dev
mailing list