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

Fei Yang fyang at openjdk.org
Fri Mar 8 07:53:02 UTC 2024


On Thu, 7 Mar 2024 12:20:40 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Seems not necessary currently, unless in the future there is other extension starting with `zfh`, e.g. `zfhX`, but seems that chance is low IMHO.
>> And, I think it might not work for the last extension in the CPU feature string if it's with a comma (as the cpu feature string is converted from a list to string, so the last one will not ending with a`,` ? ), so for new and long named extensions, it should be without a comma.
>
> Thanks for testing!

> Seems not necessary currently, unless in the future there is other extension starting with `zfh`, e.g. `zfhX`, but seems that chance is low IMHO. And, I think it might not work for the last extension in the CPU feature string if it's with a comma (as the cpu feature string is converted from a list to string, so the last one will not ending with a`,` ? ), so for new and long named extensions, it should be without a comma.

Yeah, that makes sense to me. I think we should remove this comma from conditions `(os.arch == "riscv64" & vm.cpu.features ~= ".*zfh,.*")` on jdk master. Can you fix that? Then we will have a more simpler rule when writing those conditions. That is, for single-character extensions like `c` or `v`, we need to add this comma. But for multi-character extensions like `zfh` or `zvfh`, we should not have it to avoid the issue you mentioned.

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

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


More information about the hotspot-dev mailing list