RFR: 8300258: C2: vectorization fails on simple ByteBuffer loop

Emanuel Peter epeter at openjdk.org
Wed Feb 8 11:01:43 UTC 2023


On Mon, 6 Feb 2023 14:15:19 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The loop that doesn't vectorize is:
> 
> 
> public static void testByteLong4(byte[] dest, long[] src, int start, int stop) {
>     for (int i = start; i < stop; i++) {
>         UNSAFE.putLongUnaligned(dest, 8 * i + baseOffset, src[i]);
>     }
> }
> 
> 
> It's from a micro-benchmark in the panama
> repo. `SuperWord::find_adjacent_refs() `prevents it from vectorizing
> because it finds it cannot properly align the loop and, from the
> comment in the code, that:
> 
> 
> // Can't allow vectorization of unaligned memory accesses with the
> // same type since it could be overlapped accesses to the same array.
> 
> 
> The test for "same type" is implemented by looking at the memory
> operation type which in this case is overly conservative as the loop
> above is reading and writing with long loads/stores but from and to
> arrays of different types that can't overlap. Actually, with such
> mismatched accesses, it's also likely an incorrect test (reading and
> writing could be to the same array with loads/stores that use
> different operand size) eventhough I couldn't write a test case that
> would trigger an incorrect execution.
> 
> As a fix, I propose implementing the "same type" test by looking at
> memory aliases instead.

@rwestrel is there a reason why you only replaced these two instances of `same_velt_type`?
The logic of "same type" is also used later on in the code of `SuperWord::find_adjacent_refs()`.
For example when we have `create_pack == false`, we remove all memops and packs of the "same type". Do you not want to change that too?

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

PR: https://git.openjdk.org/jdk/pull/12440


More information about the hotspot-compiler-dev mailing list