RFR: 8332265: RISC-V: Materialize pointers faster by using a temp register

[Fei Yang]

On Thu, 16 May 2024 07:52:40 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Yes, but it's a long term job, as you need to free a register in many cases. (in non-call sites places) All callsites should be easy to change as you have plenty of callee saved registers which are already saved when using movptr.

OK, I guess this might be a good compromise. Inspired by PPC's `Assembler::load_const`, `MacroAssembler::get_const` and `MacroAssembler::patch_const` [1-3], I think we could have a similar design. Adding one extra tmp register param for `movptr` like `void movptr(Register Rd, address addr, int32_t &offset, Register tmp=noreg);`, we can factor out `li48` then. The only difference compared with PPC's solution is that that we will have different sizes depending on whether we could find a tmp register for `movptr`. But I guess that's not a big issue? We can add a reference param (say, `size`) to existing `is_movptr_at/is_movptr`, we get the correct size when checking the instruction sequence and return this in `size`. I don't think it's a good idea to have more `li` variants like `li48`. We should also remove the existing `li64` which is not used anywhere. Could you please consider this?

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/ppc/assembler_ppc.cpp#L323
[2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp#L327
[3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp#L349

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

PR Comment: https://git.openjdk.org/jdk/pull/19246#issuecomment-2119537134