RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]

[Ludovic Henry]

On Wed, 28 Feb 2024 14:19:26 GMT, Hamlin Li <mli 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 
>> 
>> 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.

> 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.

Agreed on all of that! The lack of currently and widely available hardware with more of these extensions is what makes me want to keep them EXPERIMENTAL. But once we validated that these work on commercially available hardware, I would indeed move them out of EXPERIMENTAL, and I agree DIAGNOSTIC makes for a fine change.

Another question will be about backporting the EXPERIMENTAL -> DIAGNOSTIC. We can revisit later but I think we should be fairly proactive about that when the case arises. Do you see any issues that may come from it? Possibly we expect that's a breaking change as users would need to switch from `-XX:+UseExperimentalFeatures` to `-XX:+UseDiagnosticsFeatures`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1507456025