On Mon, 22 Aug 2022 14:05:49 GMT, Fei Yang <fy...@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
