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