[jdk18] RFR: 8278889: AArch64: [vectorapi] VectorMaskLoadStoreTest.testMaskCast() test fail [v2]
Vladimir Kozlov
kvn at openjdk.java.net
Tue Dec 21 19:39:17 UTC 2021
On Tue, 21 Dec 2021 13:14:59 GMT, Eric Liu <eliu at openjdk.org> wrote:
>> This bug appears intermittently and it's caused by vmaskAll_immI[1]
>> when the vector mask size is smaller than max predicate size of running
>> machine. It generates an all-true predicate without considering those
>> inactive bits. That may result in the wrong result of VectorMask.toLong.
>> The problematic code is as below:
>>
>>
>> ShortVector.SPECIES_64.MaskAll(true).toLong()
>>
>> assembly:
>>
>> ptrue p0.h <= MaskAll(true)
>> mov z16.h, p0/z, #1
>> mov z17.h, #0
>> uzp1 z16.b, z16.b, z17.b
>> fmov x10, d16
>> orr x10, x10, x10, lsr #7
>> orr x10, x10, x10, lsr #14
>> orr x10, x10, x10, lsr #28
>> and x10, x10, #0xff
>>
>> (gdb) p/x $p0 # on an SVE machine with vector length as 64 in bytes
>> $1 = {0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55}
>>
>> Expected:
>> (gdb) p/x $p0
>> $1 = {0x55, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
>>
>>
>>
>> Considering MaskAll is used in VectorMask.fromLong() only for a special
>> case and relies on the mechanism of inline and intrinsification, even it
>> could be optimized out, this patch also adds test cases for MaskAll to
>> reproduce this issue stably.
>>
>> Also fix a small issue on register utilization for
>> sve_reduce_[max|min][D|F].
>>
>> [1] https://github.com/openjdk/jdk18/blob/master/src/hotspot/cpu/aarch64/aarch64_sve.ad#L416
>>
>> hotspot/compiler/vectorapi, jdk/incubator/vector passed on SVE enabled
>> system.
>>
>> Change-Id: I9631f26f9232ffe7a28b74f14062d945c32fa1fb
>
> Eric Liu has updated the pull request incrementally with one additional commit since the last revision:
>
> small fix
>
> Change-Id: Id71ebe5161fac08a689ee3ec538b485f6c172186
I ran tier1 and 3 tests in `test/hotspot/jtreg/gc/stress/gcbasher/` failed on macosx-aarch64:
java.lang.IllegalStateException
at gc.stress.gcbasher.ByteCursor.readUtf8(ByteCursor.java:110)
at gc.stress.gcbasher.Decompiler.decodeConstantPool(Decompiler.java:310)
at gc.stress.gcbasher.Decompiler.<init>(Decompiler.java:42)
at gc.stress.gcbasher.TestGCBasher.parseClassFiles(TestGCBasher.java:46)
at gc.stress.gcbasher.TestGCBasher.main(TestGCBasher.java:63)
at gc.stress.gcbasher.TestGCBasherWithG1.main(TestGCBasherWithG1.java:40)
It seems new failure.
-------------
Changes requested by kvn (Reviewer).
PR: https://git.openjdk.java.net/jdk18/pull/49
More information about the hotspot-compiler-dev
mailing list