JDK-8309660 : C2: failed: XMM register should be 0-15 (UseKNLSetting and ConvF2HF)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 20,21,22
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-06-08
  • Updated: 2023-07-12
  • Resolved: 2023-07-03
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.
JDK 22
22 b05Fixed
Related Reports
Relates :  
JDK-8309662 - [IR Framework] Add AlignVector to whitelist
Relates :  
JDK-8239331 - C2: AVX512VL isn't properly handled
Relates :  
JDK-8289552 - Make intrinsic conversions between bit representations of half precision values and floats
Description
Since JDK-20, this seems to reproduce:

/oracle-work/jdk-20.0.2/fastdebug/bin/java -XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting -XX:CompileCommand=compileonly,Test2::test -XX:CompileCommand=printcompilation,Test2::* -XX:-TieredCompilation Test2.java

Looks like bad combo of ConvF2HF and KNL.

-------------- Original Info ------------
During work for JDK-8308606 and JDK-8303113 I wanted to whitelist "AlignVector" in the IR framework. Then I hit this issue with test
compiler/vectorization/TestFloatConversionsVector.java

The "-XX:+UseKNLSetting -XX:+AlignVector" combo is not a real hardware.

I reduced it down to Test.java

./java -XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting -XX:+AlignVector -XX:CompileCommand=compileonly,Test::test -XX:CompileCommand=printcompilation,Test::* -XX:-TieredCompilation -XX:+TraceSuperWord Test.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/oracle-work/jdk-fork0/open/src/hotspot/cpu/x86/assembler_x86.cpp:11506), pid=1769078, tid=1769091
#  assert(((!attributes->uses_vl()) || (attributes->get_vector_len() == AVX_512bit) || (!_legacy_mode_vl) || (attributes->is_legacy_mode()))) failed: XMM register should be 0-15
#
# JRE version: Java(TM) SE Runtime Environment (21.0) (slowdebug build 21-internal-LTS-2023-06-07-1344422.emanuel...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (slowdebug 21-internal-LTS-2023-06-07-1344422.emanuel..., mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x655b2a]  Assembler::vex_prefix_and_encode(int, int, int, Assembler::VexSimdPrefix, Assembler::VexOpcode, InstructionAttr*)+0x15a
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /oracle-work/jdk-fork0/build/linux-x64-slowdebug/jdk/bin/core.1769078)
#
# An error report file with more information is saved as:
# /oracle-work/jdk-fork0/build/linux-x64-slowdebug/jdk/bin/hs_err_pid1769078.log
#
# Compiler replay data is saved as:
# /oracle-work/jdk-fork0/build/linux-x64-slowdebug/jdk/bin/replay_pid1769078.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
Comments
Changeset: 2c29705d Author: Emanuel Peter <epeter@openjdk.org> Date: 2023-07-03 06:50:16 +0000 URL: https://git.openjdk.org/jdk/commit/2c29705d7bc9cf3d9884abf81ba6d3eeff881d73
03-07-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/14379 Date: 2023-06-08 14:45:54 +0000
09-06-2023
Starts to fail after JDK-8289552.
09-06-2023
I think this is a bug / regression of JDK-8289552 [~svkamath] I see that you added it, what do you think? Or is it more complicated? [~jbhateja] [~sviswanathan] You reviewed it, so maybe you'd know too. https://github.com/openjdk/jdk/commit/07946aa49c97c93bd11675a9b0b90d07c83f2a94
08-06-2023
Here the draft PR: https://github.com/openjdk/jdk/pull/14379
08-06-2023
Node: 239 convF2HF_reg_reg === _ 244 240 [[ 238 ]] We are talking about this instruction: vcvtps2ph pre=Assembler::VEX_SIMD_66 opc=Assembler::VEX_OPCODE_0F_3A VEX.128.66.0F3A requires F16C https://www.felixcloutier.com/x86/vcvtps2ph We also check for that here: case Op_ConvF2HF: case Op_ConvHF2F: if (!VM_Version::supports_float16()) { return false; } But then we set "use_vl = true" in Assembler::vcvtps2ph. Even though we have never checked for AVX512VL, and it seems not to be present on KNL! if (is_intel()) { // Intel cpus specific settings if (is_knights_family()) { _features &= ~CPU_VZEROUPPER; _features &= ~CPU_AVX512BW; _features &= ~CPU_AVX512VL; _features &= ~CPU_AVX512DQ; _features &= ~CPU_AVX512_VNNI; _features &= ~CPU_AVX512_VAES; _features &= ~CPU_AVX512_VPOPCNTDQ; _features &= ~CPU_AVX512_VPCLMULQDQ; _features &= ~CPU_AVX512_VBMI; _features &= ~CPU_AVX512_VBMI2; _features &= ~CPU_CLWB; _features &= ~CPU_FLUSHOPT; _features &= ~CPU_GFNI; _features &= ~CPU_AVX512_BITALG; _features &= ~CPU_AVX512_IFMA; } } This patch makes it work, though I can only test it on my AVX512 machine: diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp b/src/hotspot/cpu/x86/assembler_x86.cpp index 2902abfc661..5686e349866 100644 --- a/src/hotspot/cpu/x86/assembler_x86.cpp +++ b/src/hotspot/cpu/x86/assembler_x86.cpp @@ -1944,7 +1944,7 @@ void Assembler::vcvtdq2pd(XMMRegister dst, XMMRegister src, int vector_len) { void Assembler::vcvtps2ph(XMMRegister dst, XMMRegister src, int imm8, int vector_len) { assert(VM_Version::supports_evex() || VM_Version::supports_f16c(), ""); - InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */ false, /* no_mask_reg */ true, /*uses_vl */ true); + InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */ false, /* no_mask_reg */ true, /*uses_vl */ false); int encode = vex_prefix_and_encode(src->encoding(), 0, dst->encoding(), VEX_SIMD_66, VEX_OPCODE_0F_3A, &attributes); emit_int24(0x1D, (0xC0 | encode), imm8); }
08-06-2023
ILW = Assertion failure on KNL, low, use -XX:-UseSuperWord or disable compilation of affected method = MLM = P4
08-06-2023
Update: it reproduces without AlignVector. It is hence really a KNL issue! /oracle-work/jdk-20.0.2/fastdebug/bin/java -XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting -XX:-AlignVector -XX:CompileCommand=compileonly,Test2::test -XX:CompileCommand=printcompilation,Test2::* -XX:-TieredCompilation -XX:+TraceSuperWord -XX:-Verbose Test2.java
08-06-2023
Ok, I can indeed reproduce it with JDK-20 now, with an example that also does not vectorize back there (strided access, not adjacent): /oracle-work/jdk-20.0.2/fastdebug/bin/java -XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting -XX:+AlignVector -XX:CompileCommand=compileonly,Test2::test -XX:CompileCommand=printcompilation,Test2::* -XX:-TieredCompilation -XX:+TraceSuperWord -XX:-Verbose Test2.java # assert(((!attributes->uses_vl()) || (attributes->get_vector_len() == AVX_512bit) || (!_legacy_mode_vl) || (attributes->is_legacy_mode()))) failed: XMM register should be 0-15
08-06-2023
It is indeed a "regression" from JDK-8298935. The issue is that since that change, this example does not vectorize anymore with AlignVector, and the issue seems to happen when we try to vectorize but fail to do so. We don't vectorize it anymore because we don't take in memops that were rejected during find_adjacent_refs, since that lead to some bugs. After find_adjacent_refs, we now only have the StoreC, the StoreF are rejected because they might not align with the StoreC. So vectorization becomes "Unprofitable". Need to figure out why that lets us hit the assert.
08-06-2023
This seems not to reproduce with jdk-20.0.2, so I'd assume it is a rather recent regression. And jdk-19.0.2 responds like this: Test.java:5: error: cannot find symbol s[i] = Float.floatToFloat16(f[i]);
08-06-2023
First investigation, values at assert: attributes->uses_vl() = true attributes->get_vector_len() == 0 AVX_512bit == 2 _legacy_mode_vl == true attributes->is_legacy_mode() == false
08-06-2023
May be related to JDK-8239331.
08-06-2023