RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS [v4]

[Robbin Ehn]

On Tue, 7 Oct 2025 08:13:32 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Yes, maybe.
>> 
>> I just don't understand why vector length is something different than zicboz block size.
>> E.g.
>> 
>> CacheLineSize                             // gets cache-line size
>> VM_Version::ext::zic64b();                // gets 64b cache-line size
>> VM_Version::non_ext::zicboz_block_size(); // gets cache block size
>> VM_Version::cpu_vector_length();          // private, gets vector register length (HW), should be size not length IMHO
>> MaxVectorSize                             // gets vector register length (-+ cmd-line)
>> 
>> 
>> When I am actually using these value in MASM/stubs/instrinsic/etc.. I don't care where this value came from.
>> If it's command line or RVI extension or if we with some other mean figured this setting out.
>> 
>> I think it would be nice to try to get a consistent API in VM_Version.
>> But I don't think that is possible (due to global flags), but I think we can at least do something better here, no?
>> 
>> As it is now it really hard to review as I need to double check if the correct setting was used.
>
> Maybe just keep the original names, and use them as pretty too? The code looks like `VM_Version::non_ext::zicboz_block_size()`, and the printed feature "pretty" name would be "zicboz_block_size".

But why is not vector size/length called:
`VM_Version::non_ext::rvv_vlen()`  or similar ? Should it ?

Should VM_Version::non_ext and VM_Version::ext be private, so we create a public:
VM_Version::ziboz_block_size() ?

I added:
`static bool supports_fencei_barrier() { return ext_Zifencei.enabled(); }`


Was this wrong? Should I have used `VM_Version::ext_Zifencei.enabled()` in MASM ?

Can we agree to one consistent way?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27562#discussion_r2409975644