RFR: JDK-8290137: riscv: small refactoring for add_memory_int32/64

[Fei Yang]

On Mon, 18 Jul 2022 10:04:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Currently, add_memory_int32/64 for riscv can only add a sign-extended 12-bit immediate to memory since they call addi/addiw assembler direcly. This constraint could be relaxed when the given memory address is in the expected form: base register plus a sign-extended 12-bit offset. In this case, we can emit code for load + add/sub + store sequence adding arbitrary immediate to memory with no more than two scratch registers (t0 and t1) available.
>> 
>> We could also refactor these two functions into four seperate functions: increment, incrementw, decrement and decrementw, so that it will be more clear in code logic at the call sites.
>> 
>> Testing: tier1 tested on riscv64-linux unmatched board.
>
> src/hotspot/cpu/riscv/c1_LIRAssembler_arraycopy_riscv.cpp line 60:
> 
>> 58: #ifndef PRODUCT
>> 59:   if (PrintC1Statistics) {
>> 60:     __ incrementw(ExternalAddress((address)&Runtime1::_generic_arraycopystub_cnt));
> 
> Is it really `incrementw`, though? These counter fields are `int`-s, are they still 32-bit on RISC-V? If so, shouldn't it be `incrementl`?

@shipilev : Yes, the type of _generic_arraycopystub_cnt is int and it occupies 32-bit in memory on Linux/RISC-V. That's why we use incrementw here which increments a 32-bit memory operand. Note that incrementl works for 64-bit memory operand. Hope that explains. Thanks.

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

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