RFR: 8334396: RISC-V: verify perf of ReverseBytesI/L

[Robbin Ehn]

On Mon, 17 Jun 2024 14:38:37 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review the patch?
> 
> The test data below shows that, if zbb is not supported on current hardware, then intrinsic brings perf regression rather than benefit.
> So, ReverseBytesI/L should only be enabled when zbb is supported.
> 
> ## Test data
> existing benchmark:
> test/micro/org/openjdk/bench/java/lang/Longs.java, reverseBytes()
> test/micro/org/openjdk/bench/java/lang/Integers.java, reverseBytes()
> 
> all tests running below with rvv disabled.
> tested on K230-CanMV
> 
> 1. -XX:-UseZbb, intrinsic enabled by default
> o.o.b.j.lang.Integers.reverseBytes N/A 500 avgt 6128.125 ns/op
> o.o.b.j.lang.Longs.reverseBytes N/A 500 avgt 10807.930 ns/op
> 
> 2. -XX:+UseZbb, intrinsic enabled by default
> o.o.b.j.lang.Integers.reverseBytes N/A 500 avgt 1788.990 ns/op
> o.o.b.j.lang.Longs.reverseBytes N/A 500 avgt 1113.734 ns/op
> 
> 3. -XX:-UseZbb, and disable ReverseBytesI/L instrinsic
> o.o.b.j.lang.Integers.reverseBytes N/A 500 avgt 3552.902 ns/op
> o.o.b.j.lang.Longs.reverseBytes N/A 500 avgt 4586.980 ns/op

Hi, a Q.

The cost in AD file is:
`ins_cost(ALU_COST * 2);`

Without ZBB it looks like it should be 17x.
As we don't know if the alternative is alwasy cheaper, so why not set the cost correctly and the compiler would do the right thing ?
Meaning we can still have instrinsic but with correct cost?

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

PR Comment: https://git.openjdk.org/jdk/pull/19750#issuecomment-2178594236