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