RFR: 8278584: compiler/vectorapi/VectorMaskLoadStoreTest.java failed with "Error: ShouldNotReachHere()" [v3]

Jie Fu jiefu at openjdk.java.net
Mon Dec 13 23:36:50 UTC 2021


On Mon, 13 Dec 2021 11:36:46 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi, unfortunately, the tests still don't verify the correctness of the compiled codes, what happened here is that the `IfNode` always goes in one direction make the other path an uncommon trap, the uncommon trap captures all nodes before it including the `VectorLongToMaskNode`, thus throw `ShouldNotReachHere` when trying to emit instructions. The result of the `VectorLongToMaskNode`, however, is only used to feed into the uncommon trap and not used in verification at all.
>> 
>> I propose we just store the mask into a boolean array using `toArray()` and compare the result in a for loop.
>> 
>>     0x00007f3e254efa40:   mov    %eax,-0x16000(%rsp)
>>     0x00007f3e254efa47:   push   %rbp
>>     0x00007f3e254efa48:   sub    $0x30,%rsp                   ;*synchronization entry
>>                                                               ; - org.openjdk.bench.vm.compiler.Sample::testByte64 at -1 (line 67)
>>     0x00007f3e254efa4c:   movzbl 0x18(%rsi),%r10d             ;*getfield checked {reexecute=0 rethrow=0 return_oop=0}
>>                                                               ; - org.openjdk.bench.vm.compiler.Sample::testByte64 at 14 (line 69)
>>     0x00007f3e254efa51:   test   %r10d,%r10d
>>     0x00007f3e254efa54:   je     0x00007f3e254efa69           // If (checked != 0), we return immediately
>>     ;; B2: #       out( N45 ) <- in( B1 )  Freq: 1
>>     0x00007f3e254efa56:   add    $0x30,%rsp
>>     0x00007f3e254efa5a:   pop    %rbp
>>     0x00007f3e254efa5b:   cmp    0x388(%r15),%rsp             ;   {poll_return}
>>     0x00007f3e254efa62:   ja     0x00007f3e254efadc
>>     0x00007f3e254efa68:   ret
>>     ;; B3: #       out( N45 ) <- in( B1 )  Freq: 4.76837e-07
>>     0x00007f3e254efa69:   mov    $0xffff,%r11d
>>     0x00007f3e254efa6f:   and    0x10(%rsi),%r11
>>     0x00007f3e254efa73:   movabs $0x101010101010101,%r8
>>     0x00007f3e254efa7d:   pdep   %r8,%r11,%r8
>>     0x00007f3e254efa82:   mov    %r11,%r9
>>     0x00007f3e254efa85:   vpxor  %xmm1,%xmm1,%xmm1
>>     0x00007f3e254efa89:   vmovq  %r8,%xmm1
>>     0x00007f3e254efa8e:   vmovq  %r8,%xmm0
>>     0x00007f3e254efa93:   movabs $0x101010101010101,%r8
>>     0x00007f3e254efa9d:   shr    $0x8,%r9
>>     0x00007f3e254efaa1:   pdep   %r8,%r9,%r8
>>     0x00007f3e254efaa6:   vpinsrq $0x1,%r8,%xmm1,%xmm1
>>     0x00007f3e254efaac:   vmovdqu %ymm1,%ymm0
>>     0x00007f3e254efab0:   mov    %rsi,%rbp
>>     0x00007f3e254efab3:   mov    %r10d,(%rsp)
>>     0x00007f3e254efab7:   vmovdqu %xmm0,0x10(%rsp)            ;*invokestatic maskReductionCoerced {reexecute=0 rethrow=0 return_oop=0}
>>                                                               ; - jdk.incubator.vector.Byte128Vector$Byte128Mask::toLong at 35 (line 735)
>>                                                               ; - org.openjdk.bench.vm.compiler.Sample::testByte64 at 21 (line 70)
>>     0x00007f3e254efabd:   mov    $0xffffff45,%esi
>>     0x00007f3e254efac2:   nop
>>     0x00007f3e254efac3:   call   0x00007f3e254bbf20           ; ImmutableOopMap {rbp=Oop }
>>                                                               ;*ifeq {reexecute=1 rethrow=0 return_oop=0}
>>                                                               ; - (reexecute) org.openjdk.bench.vm.compiler.Sample::testByte64 at 17 (line 69)
>>                                                               ;   {runtime_call UncommonTrapBlob}
>
>> Hi, unfortunately, the tests still don't verify the correctness of the compiled codes, what happened here is that the `IfNode` always goes in one direction make the other path an uncommon trap, the uncommon trap captures all nodes before it including the `VectorLongToMaskNode`, thus throw `ShouldNotReachHere` when trying to emit instructions. The result of the `VectorLongToMaskNode`, however, is only used to feed into the uncommon trap and not used in verification at all.
> 
> Nice catch! @merykitty 
> What do you think of the updated version? 
> Thanks.

> @DamonFool neat test fix, could you add a brief comment as to why disabling `_VectorMaskOp` is required?

Thanks @PaulSandoz for your testing.

The comment had been added.
Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/6808


More information about the hotspot-compiler-dev mailing list