RFR: 8320397: RISC-V: Avoid passing t0 as temp register to MacroAssembler:: cmpxchg_obj_header/cmpxchgptr
Robbin Ehn
rehn at openjdk.org
Fri Dec 1 08:48:06 UTC 2023
On Wed, 29 Nov 2023 11:58:31 GMT, Gui Cao <gcao at openjdk.org> wrote:
> MacroAssembler::cmpxchg/cmpxchgptr/cmpxchg_obj_header is non-trivial on linux-riscv64 platform. Passing t0(aka x5) as temporary register to this functions can also be error prone. As a reserved scratch register, t0 is implicitly clobberred by various assembler functions. @robehn can you help review this PR?
> This issue is used to track avoid passing t0 as a temporary register in the following cases:
> 1. avoid passing t0 as temp register to MacroAssembler::cmpxchg/cmpxchgptr/cmpxchg_obj_header.
> 2. avoid passing t0 as temp register to x_load_barrier and x_load_barrier_slow_path function in x_riscv.ad
> 3. avoid passing t0 as temp register to z_store_barrier and z_color function in z_riscv.ad
>
> Note that I didn't touch MacroAssembler::cmpxchg because it seems to me that this function is designed that it allows t0 to be used as the result register. As the result register will be set on exits, there should be no risk when using t0 for receiving the result.
> https://github.com/openjdk/jdk/blob/e44d4b24ed794957c47c140ab6f15544efa2b278/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L2910-L2925
>
> ### Testing:
> - [x] Run tier1-3 tests on qemu 8.1.50 with UseRVV (release)
> - [x] Run tier1-3 tests with SiFive unmatched (release)
My time is a bit constrained right now, hopefully I can look at this next week.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/16880#issuecomment-1835697810
More information about the hotspot-dev
mailing list