RFR: 8291550: RISC-V: jdk uses misaligned memory access when AvoidUnalignedAccess enabled [v9]

Vladimir Kempik vkempik at openjdk.org
Wed May 10 14:29:34 UTC 2023


On Wed, 10 May 2023 13:54:56 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add strig_equals patch to prevent misaligned access there
>
> src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 1166:
> 
>> 1164:   slli(cnt1, cnt1, LogBitsPerByte);
>> 1165:   sll(tmp1, tmp1, cnt1);
>> 1166:   bnez(tmp1, DONE);
> 
> I guess the following sequence would help better utilize the instruction pipeline stall:
> 
>   ld(tmp1, Address(a1));
>   ld(tmp2, Address(a2));
>   neg(cnt1, cnt1);
>   slli(cnt1, cnt1, LogBitsPerByte);
>   xorr(tmp1, tmp1, tmp2);
>   sll(tmp1, tmp1, cnt1);
>   bnez(tmp1, DONE);

that is hard to say.

OoO arches such as thead - don't care about the location of xor opcode here

In order uarches, such as u74/hifive might be affected by such change. however, the memory at address a1/a2 very likely would already be in the l1d cache, due to previous accesses in the same function, so it will be pretty cheap.
u74 is dual-issue, so it may execute these two loads (from l1d$) in parallel, having these addresses cached in l1d would make such optimisation hard to spot.

To say for sure, need to check with jmh test org.openjdk.bench.java.lang.StringEquals on hifive

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13645#discussion_r1189992511


More information about the hotspot-dev mailing list