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

[Sacha Coppey]

On Mon, 22 Aug 2022 14:05:49 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add space in switch
>
> 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.

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

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