RFR: 8290154: [JVMCI] partially implement JVMCI for RISC-V [v5]

[Fei Yang]

On Mon, 22 Aug 2022 16:57:41 GMT, Sacha Coppey <duke at openjdk.org> wrote:

>> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.riscv64/src/jdk/vm/ci/riscv64/RISCV64Kind.java line 54:
>> 
>>> 52:     V256_QWORD(32, QWORD),
>>> 53:     V256_SINGLE(32, SINGLE),
>>> 54:     V256_DOUBLE(32, DOUBLE);
>> 
>> I see some vector types are added here. Could you please explain the design here?
>> Please note that RISC-V Vector extension (RVV) uses variable length vectors which in this sense is similar to AArch64's SVE. The actual vector length depends on the hardware implementation and could be determind by reading from the corresponding CSR special register at runtime. I am not sure how JVMCI is supposed to support this.
>
> At the moment, only AArch64's Neon is supported by JVMCI, which means there is no other example for variable length vector architectures. I think that a correct implementation would indeed fetch the value of the corresponding CSR at runtime. This would mainly be needed in the `getLargestStorableKind` method, as it depends on the hardware. I imagine the values of those registers should also be accessible through the `HotSpotVMConfig`, to allow the compilers to know the hardware implementation.
> 
> In this case, the implementation is only used in Native Image, which currently does not implement the vector extension for RISC-V. Thus, I chose to manually define valid vector types, but since they can have a size up to 65536, I thought it would not be a good idea to define all of them.
> 
> Since this is not needed in the current Native Image LLVM backend for RISC-V, I'm not sure I would have the time to work on this, so if it would be better not to have those "placeholder" types, I can remove them for now.

Thanks for the explaination. Then I would suggest we remove those vector types together with the SIMD register definitions for now.

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

PR: https://git.openjdk.org/jdk/pull/9587