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
