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

[Hamlin Li]

On Wed, 19 Jun 2024 12:35:09 GMT, Robbin Ehn <rehn 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?

Thanks @robehn @RealFYang for your reviewing.

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

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