RFR: 8318218: RISC-V: C2 CompressBits [v6]

Fei Yang fyang at openjdk.org
Mon Nov 13 06:37:01 UTC 2023


On Fri, 10 Nov 2023 11:43:16 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review the change to add intrinsic for CompressBits for Long & Integer?
>> Thanks!
>> 
>> ## Test
>> pass jtreg test:
>> test/jdk/java/lang/CompressExpand*.java
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reserve all used v register; use t0 directly

Changes requested by fyang (Reviewer).

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

> 1689: 
> 1690:   // load the src data(in bits) to be compressed.
> 1691:   vsetivli(x0, 1, sew, lmul);

A default `lmul` of `m1` is enough to perform the succeeding `vmv_s_x` instuction as specified by the RVV spec.

The integer scalar read/write instructions transfer a single value between a scalar x register and element 0 of a vector
register. The instructions ignore LMUL and vector register groups.

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

> 1701:   // load the mask data(in bits).
> 1702:   vsetivli(x0, 1, sew, lmul);
> 1703:   vmv_v_x(v0, mask);

Shouldn't this be `vmv_s_x(v0, mask)` instead of `vmv_v_x(v0, mask)`? The `vcompress.vm` instruction is expecting a vector mask register. Also the preceding `vsetivli` should be changed to use a default `lmul` of `m1` at the same time.

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

> 1708:   vmseq_vi(v0, v8, 1);
> 1709:   // store result back.
> 1710:   vsetivli(x0, 1, sew, lmul);

Similar here. This `vsetivli` instruction should be changed to use a default lmul of m1

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

PR Review: https://git.openjdk.org/jdk/pull/16481#pullrequestreview-1726607955
PR Review Comment: https://git.openjdk.org/jdk/pull/16481#discussion_r1390664667
PR Review Comment: https://git.openjdk.org/jdk/pull/16481#discussion_r1390666669
PR Review Comment: https://git.openjdk.org/jdk/pull/16481#discussion_r1390667506


More information about the hotspot-dev mailing list