On Mon, 22 Aug 2022 16:57:41 GMT, Sacha Coppey <d...@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
