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