JDK-8308949 : C2 SuperWord: assert(vmask != nullptr) failed: vector mask should be generated
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,21
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2023-05-26
  • Updated: 2023-07-17
  • Resolved: 2023-07-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
Bad combination of:
-XX:+PostLoopMultiversioning -XX:-DoReserveCopyInSuperWord

Tested with AVX512.

Without PostLoopMultiversioning we would not create vector mask.
With DoReserveCopyInSuperWord we would just bail out of SuperWord::output.

I see that PostLoopMultiversioning is generally not very stable, given these issues, I guess that is why it is an experimental flag: JDK-8304774 JDK-8301904  JDK-8301657

JDK17 SIGSEGV with this:
java -XX:CompileCommand=compileonly,Test::test -Xbatch -XX:+UnlockExperimentalVMOptions -XX:+PostLoopMultiversioning -XX:-DoReserveCopyInSuperWord Test.java


Master hits assert with this:
./java -XX:CompileCommand=compileonly,Test::test -XX:+TraceNewVectors -XX:+TraceSuperWord -XX:-Verbose -Xbatch -XX:+TraceLoopOpts -XX:+UnlockExperimentalVMOptions -XX:+PostLoopMultiversioning -XX:-DoReserveCopyInSuperWord Test.java


# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/oracle-work/jdk-fork2/open/src/hotspot/share/opto/superword.cpp:2708), pid=1527892, tid=1527905
#  assert(vmask != nullptr) failed: vector mask should be generated
#
# JRE version: Java(TM) SE Runtime Environment (21.0) (slowdebug build 21-internal-LTS-2023-05-24-0919094.emanuel...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (slowdebug 21-internal-LTS-2023-05-24-0919094.emanuel..., mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1472d09]  SuperWord::output()+0x689
Comments
No need to fix this anymore since related code has been removed
17-07-2023

ILW = Crash in post loop vectorization, single test and with experimental feature, use -XX:-PostLoopMultiversioning = HLL = P4
30-05-2023

[~epeter] Thanks for focusing on this. Right, today's PostLoopMultiversioning is still problematic and the legacy code is hard to maintain. We now propose to deprecate multi-versioning and completely re-implement the post loop vectorization. We have been working on it internally for a while. I just sent a heads-up email (https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2023-May/065349.html) to the hotspot-compiler-dev list about this. I will let you know once we have updates.
29-05-2023

Note: Test.java is basically LoopRangeStrideTest::countDownLoop from this test: test/hotspot/jtreg/compiler/vectorization/runner/LoopRangeStrideTest.java
26-05-2023

[~pli] I see you recently filed the other bugs. What is the reason that PostLoopMultiversioning is still experimental? Is it just that it is not yet stable?
26-05-2023

Suggestion for fix, see here: https://github.com/openjdk/jdk/pull/14168 Basically: we should move the checks in "create_post_loop_vmask" to be performed before we enter SuperWord::output, and then have it guaranteed that we get a vmask. The basic design should be that all checks in general are done before SuperWord::output, and in SuperWord::output itself we only apply.
26-05-2023