On Wed, 24 Aug 2022 07:55:47 GMT, Sacha Coppey <d...@openjdk.org> wrote:
>> This patch adds a partial JVMCI implementation for RISC-V, to allow using >> the GraalVM Native Image RISC-V LLVM backend, which does not use JVMCI for >> code emission. >> It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 packages, as >> well as implements a part of jvmciCodeInstaller_riscv64.cpp. To check for >> correctness, it enables JVMCI code installation tests on RISC-V. More >> testing is performed in Native Image. > > Sacha Coppey has updated the pull request incrementally with one additional > commit since the last revision: > > Add a comments for the change in deoptimization.hpp src/hotspot/cpu/riscv/jvmciCodeInstaller_riscv.cpp line 119: > 117: } > 118: jint vectorRegisterNumber = floatRegisterNumber - > FloatRegisterImpl::number_of_registers; > 119: if (vectorRegisterNumber >= 0 && vectorRegisterNumber - > VectorRegisterImpl::number_of_registers) { Maybe you want to check if `vectorRegisterNumber < VectorRegisterImpl::number_of_registers`. src/hotspot/share/runtime/deoptimization.hpp line 348: > 346: // incorrectly if the nmethod is compiled by JVMCI, causing the > 347: // method to return a negative index which is not -1 > 348: static int RISCV64_ONLY(__attribute__ ((noinline))) > trap_request_index(int trap_request) { I don't understand this change, because the semantics should be the same whether inline or not. What's the difference in the generated code by the c/c++ compiler? ------------- PR: https://git.openjdk.org/jdk/pull/9587