RFR: 8322174: RISC-V: C2 VectorizedHashCode RVV Version [v27]

[Fei Yang]

On Fri, 15 Aug 2025 10:33:37 GMT, Yuri Gaevsky <duke at openjdk.org> wrote:

>> The patch adds possibility to use RVV instructions for faster vectorizedHashCode calculations on RVV v1.0.0 capable hardware.
>> 
>> Testing: hotspot/jtreg/compiler/ under QEMU-8.1 with RVV v1.0.0.
>
> Yuri Gaevsky has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - one more round of updates per recieved suggestions from reviewers.

src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2039:

> 2037:   beqz(t0, SCALAR_TAIL);
> 2038: 
> 2039:   vsetvli(t1, x0, Assembler::e32, Assembler::m2);

This `vsetvli` doesn't seem necessary to me. Maybe we can remove it and move the second `vsetvli` at L2046 here?
I am suggesting this code sequence:

  andi(t0, cnt, ~(stride - 1));
  beqz(t0, SCALAR_TAIL);

  la(t1, ExternalAddress(adr_pows31));
  lw(pow31_highest, Address(t1, -1 * sizeof(jint)));

  vsetvli(consumed, cnt, Assembler::e32, Assembler::m2);
  vle32_v(v_coeffs, t1); // 31^^(stride - 1) ... 31^^0
  vmv_v_x(v_sum, x0);

src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2044:

> 2042:   la(t1, ExternalAddress(adr_pows31));
> 2043:   lw(pow31_highest, Address(t1, -1 * sizeof(jint)));
> 2044:   vle32_v(v_coeffs, t1); // 31^^(MaxVectorSize-1)...31^^0

The code comment doesn't seem accurate considering vector register grouping.
Should it be: `31^^(stride - 1) ... 31^^0` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17413#discussion_r2280128427
PR Review Comment: https://git.openjdk.org/jdk/pull/17413#discussion_r2280127812