RFR: 8332689: RISC-V: Use load instead of trampolines [v7]

[Hamlin Li]

On Wed, 5 Jun 2024 13:14:35 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi all, please consider!
>> 
>> Today we do JAL to **dest** if **dest** is in reach (+/- 1 MB).
>> Using a very small application or running very short time we have fast patchable calls.
>> But any normal application running longer will increase the code size and code chrun/fragmentation.
>> So whatever or not you get hot fast calls rely on luck.
>> 
>> To be patchable and get code cache reach we also emit a stub trampoline which we can point the JAL to.
>> This would be the common case for a patchable call.
>> 
>> Code stream:
>> JAL <trampo>
>> Stubs:
>> AUIPC
>> LD
>> JALR
>> <DEST>
>> 
>> 
>> On some CPUs L1D and L1I can't contain the same cache line, which means the tramopline stub can bounce from L1I->L1D->L1I, which is expensive.
>> Even if you don't have that problem having a call to a jump is not the fastest way.
>> Loading the address avoids the pitsfalls of cmodx.
>> 
>> This patch suggest to solve the problems with trampolines, we take small penalty in the naive case of JAL to **dest**,
>> and instead do by default:
>> 
>> Code stream:
>> AUIPC
>> LD
>> JALR
>> Stubs:
>> <DEST>
>> 
>> An experimental option for turning trampolines back on exists.
>> 
>> It should be possible to enhanced this with the WIP [Zjid](https://github.com/riscv/riscv-j-extension) by changing the JALR to JAL and nop out the auipc+ld (as the current proposal of Zjid forces the I-fetcher to fetch instruction in order (meaning we will avoid a lot issues which arm has)) when in reach and vice-versa.
>> 
>> Numbers from VF2 (I have done them a few times, they are always overall in favor of this patch):
>> 
>> fop                                        (msec)    2239       |  2128       =  0.950424
>> h2                                         (msec)    18660      |  16594      =  0.889282
>> jython                                     (msec)    22022      |  21925      =  0.995595
>> luindex                                    (msec)    2866       |  2842       =  0.991626
>> lusearch                                   (msec)    4108       |  4311       =  1.04942
>> lusearch-fix                               (msec)    4406       |  4116       =  0.934181
>> pmd                                        (msec)    5976       |  5897       =  0.98678
>> jython                                     (msec)    22022      |  21925      =  0.995595
>> Avg:                                       0.974112                              
>> fop(xcomp)                                 (msec)    2721       |  2714       =  0.997427
>> h2(xcomp) ...
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove tmp file

Some comments.

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 981:

> 979: }
> 980: 
> 981: void MacroAssembler::load_link(const address source, Register temp) {

maybe modify to `load_jump_link` or `load_link_jump`?

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 987:

> 985:   int64_t distance = source - pc();
> 986:   assert(is_simm32(distance), "Must be");
> 987:   Assembler::auipc(temp, (int32_t)distance + 0x800);

Is it possible to use `jal` instead of the instruction sequence when is_simm21 == true as in jump_link?

src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 1571:

> 1569:   };
> 1570: 
> 1571:   enum NativeShortCall {

Thanks for moving these into a separate name space, looks much better.

Seems the naming convention of enum is with "_", not sure if we need to stick to it. NativeShortCall also looks good.

src/hotspot/cpu/riscv/nativeInst_riscv.cpp line 519:

> 517: 
> 518: address NativeCall::instruction_address() const {
> 519:   if (!UseTrampolines) {

use positive condition? similar suggestion for below conditions.

src/hotspot/cpu/riscv/nativeInst_riscv.hpp line 72:

> 70:   bool is_jump()                            const { return MacroAssembler::is_jump_at(addr_at(0));        }
> 71:   bool is_call()                            const { return is_call_at(addr_at(0));                        }
> 72:   static bool is_call_at(address addr);

Is this indirection of `is_call_at` necessary? seems only is_call is calling is_call_at?

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

PR Review: https://git.openjdk.org/jdk/pull/19453#pullrequestreview-2102103344
PR Review Comment: https://git.openjdk.org/jdk/pull/19453#discussion_r1629630445
PR Review Comment: https://git.openjdk.org/jdk/pull/19453#discussion_r1630196965
PR Review Comment: https://git.openjdk.org/jdk/pull/19453#discussion_r1629989406
PR Review Comment: https://git.openjdk.org/jdk/pull/19453#discussion_r1630248686
PR Review Comment: https://git.openjdk.org/jdk/pull/19453#discussion_r1630234949