RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v2]

[Hamlin Li]

On Mon, 29 Sep 2025 02:45:59 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 181:
>> 
>>> 179:   }
>>> 180: 
>>> 181:   if (FLAG_IS_DEFAULT(AlignVector) && unaligned_vector.enabled()) {
>> 
>> Seems this `unaligned_vector.enabled` is not necessary?
>
> The purpose is to give a consistent view of how the these extensions should be used. That is we only use the value of the extension when it is enabled. Otherwise, we are relying on the default value -1, which doesn't seem safe to me. And it shouldn't be a issue in performance to have this check here. What do you think?

`-1` normally means error/fail/unsuccess, or something similar. The reason that `-1` was chosen as default value should have the same rational here. I wonder if the linux or a C api would choose `-1` to mean pass/success.
In the case of `AlignVector`, we only enable unaligned vector mem access when `value == MISALIGNED_VECTOR_FAST`, in this sense, w/wo `unaligned_vector.enabled()` produce the exact  same result.
In this sense, the `unaligned_vector.enabled()` is redundant.

In another hand, if the default value of a vm option `A` is true and its CPU feature is not enabled (for some reason), we should still set the default value of `A` as `cpu_feature_A.value() !=/== A_enabled_Value`, rather than only set it when it's enabled.
In this sense, it's safer to always set a VM option's default value based on its value in RVFeatureValue instance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27512#discussion_r2387300894