JDK-8269828 : corrections in some instruction patterns for KNL x86 platform
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,18
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • CPU: x86
  • Submitted: 2021-07-02
  • Updated: 2021-08-06
  • Resolved: 2021-07-08
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 17 JDK 18
17 b31Fixed 18Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
Currently a temporary operand with register class regD is used in rep_stos_evex and rep_stos_large_evex instruction patterns, whose encoding blocks calls xmm_clear_mem routine which has a VEX encoded instruction in the control path.
Thus regD class should be changed to legRegD on AVX512 platforms so that operand is always allocated from lower register bank (0-15).

There is one more issue related to usage of regD operand which is a scalar operand in a vector instruction, usually such cases may result into problems during spilling/restoration since only a scalar value is dumped and restored back, but in current context its a temporary operand may never get spilled.

Comments
The tests mentioned in the bug passed in JDK17 ATR
06-08-2021

Changeset: 168af2e6 Author: Jatin Bhateja <jbhateja@openjdk.org> Date: 2021-07-08 12:19:19 +0000 URL: https://git.openjdk.java.net/jdk17/commit/168af2e6b2343d6674fa053dcb09aca028e372bf
08-07-2021

[~jbhateja] Yes, you can take this bug. I don't see any more failures in these tests after I excluded AVX512DQ from KNL configuration in JDK-8269825 changes. I do see failures in new tests compiler/vectorapi/VectorCastShape*Test.java. I filed separate bug JDK-8269952.
06-07-2021

While these bugs will get resolved by mimicking exact KNL features. There is another issue in following instruction pattern // Small ClearArray AVX512 non-constant length. -instruct rep_stos_evex(eCXRegI cnt, eDIRegP base, regD tmp, kReg ktmp, eAXRegI zero, Universe dummy, eFlagsReg cr) %{ +instruct rep_stos_evex(eCXRegI cnt, eDIRegP base, legRegD tmp, kReg ktmp, eAXRegI zero, Universe dummy, eFlagsReg cr) %{ predicate(!((ClearArrayNode*)n)->is_large() && (UseAVX > 2)); match(Set dummy (ClearArray cnt base)); ins_cost(125); @@ -11644,7 +11644,7 @@ instruct rep_stos_large(eCXRegI cnt, eDIRegP base, regD tmp, eAXRegI zero, Unive %} // Large ClearArray AVX512. -instruct rep_stos_large_evex(eCXRegI cnt, eDIRegP base, regD tmp, kReg ktmp, eAXRegI zero, Universe dummy, eFlagsReg cr) %{ +instruct rep_stos_large_evex(eCXRegI cnt, eDIRegP base, legRegD tmp, kReg ktmp, eAXRegI zero, Universe dummy, eFlagsReg cr) %{ Problem: Usage of regD tmp operand. In xmm_clear_mem routine following VEX encoded instruction is used } else if (MaxVectorSize >= 32) { vpxor(xtmp, xtmp, xtmp, AVX_256bit); Thus regD should be changed to legRegD on AVX512 platforms so that operand is always allocated from lower register bank (0-15). There is one more issue related to usage of regD operand which is a scalar operand in a vector instruction, may result into spilling/restoration size issue for regD definition. But this being a temporary operand may never get spilled so in a way it should not pose any issue. If you suggest I can change the subject and use this JBS as an umbrella issue related to KNL bugs and post this fix for JDK-17.
06-07-2021

Rising Priority because some compiler tests (not only incubator/vector) failed.
06-07-2021

Hit the same failure with next tests compiler/c2/cr6340864/TestLongVect.java compiler/loopopts/superword/ReductionPerf.java compiler/loopopts/superword/RedTest_long.java
06-07-2021

Could be related to JDK-8269528 fix.
02-07-2021

ILW = MMH = P3
02-07-2021

You need to apply next change (add 'UseNewCode || '): src/hotspot/cpu/x86/vm_version_x86.hpp - static bool is_knights_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x57) || (extended_cpu_model() == 0x85))); } // Xeon Phi 3200/5200/7200 and Future Xeon Phi + static bool is_knights_family() { return UseNewCode || ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x57) || (extended_cpu_model() == 0x85))); } // Xeon Phi 3200/5200/7200 and Future Xeon Phi And run tests with flags '-XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+ UseNewCode' on avx512 machine. Or on KNL if you have one.
02-07-2021

[~jbhateja] please look.
02-07-2021