RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic
Yuri Gaevsky
duke at openjdk.org
Tue Feb 20 14:09:54 UTC 2024
On Tue, 20 Feb 2024 11:11:33 GMT, Fei Yang <fyang at openjdk.org> wrote:
>> Hello All,
>>
>> Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported.
>>
>> Thank you,
>> -Yuri Gaevsky
>>
>> **Correctness checks:**
>> hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4.
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4256:
>
>> 4254:
>> 4255: bind(VEC_LOOP);
>> 4256: vsetvli(t0, cnt, Assembler::e8, Assembler::m8);
>
> I see `e8` element size is always used here for all cases. Maybe we could make use of some larger element size (according to `log2_array_indxscale` input) to improve the code? Especiall, the part for handling `idx`.
The ```e8``` is used here to avoid "unaligned-access-penalties" because:
(a)
[jdk.internal.util.ArraysSupport::vectorizedMismatch()](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java#L92) doesn't require that the given arrays are aligned to the size of array elements:
* <p>The given offsets, in bytes, need not be aligned according to the
* given log<sub>2</sub> size the array elements. More specifically, an
* offset modulus the size need not be zero.
and
(b) RVV specification states:
8. Vector Memory Alignment Constraints
...
If an element accessed by a vector memory instruction is not naturally aligned to the size of the element, either the element
is transferred successfully or an address misaligned exception is raised on that element.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17750#discussion_r1495881809
More information about the hotspot-dev
mailing list