JDK-8217371 : Incorrect LP64 guard in x86.ad after JDK-8210764 (Update avx512 implementation)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • CPU: x86_64
  • Submitted: 2019-01-18
  • Updated: 2019-10-04
  • Resolved: 2019-01-30
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 11 JDK 13
11.0.5Fixed 13 b07Fixed
Related Reports
Relates :  
Description
x86.ad has checks like "ifndef LP64". Those do not work reliably. On x86_64, it is not defined for ADLC compilation, making the code always take the "not defined" branch. Note that the same file uses "ifdef _LP64" (note the underscore) at the same file.

If you fix that with proper "ifndef _LP64":

diff -r 2360f73c5514 src/hotspot/cpu/x86/x86.ad
--- a/src/hotspot/cpu/x86/x86.ad        Fri Jan 18 09:32:02 2019 +0100
+++ b/src/hotspot/cpu/x86/x86.ad        Fri Jan 18 10:02:35 2019 +0100
@@ -1685,5 +1685,5 @@
     case Op_VecD:
     case Op_VecX:
-#ifndef LP64
+#ifndef _LP64
       __ movdqu(as_XMMRegister(Matcher::_regEncode[dst_lo]), as_XMMRegister(Matcher::_regEncode[src_lo]));
 #else
@@ -1697,5 +1697,5 @@
       break;
     case Op_VecY:
-#ifndef LP64
+#ifndef _LP64
       __ vmovdqu(as_XMMRegister(Matcher::_regEncode[dst_lo]), as_XMMRegister(Matcher::_regEncode[src_lo]));
 #else
@@ -1758,5 +1758,5 @@
         break;
       case Op_VecX:
-#ifndef LP64
+#ifndef _LP64
         __ movdqu(as_XMMRegister(Matcher::_regEncode[reg]), Address(rsp, stack_offset));
 #else
@@ -1770,5 +1770,5 @@
         break;
       case Op_VecY:
-#ifndef LP64
+#ifndef _LP64
         __ vmovdqu(as_XMMRegister(Matcher::_regEncode[reg]), Address(rsp, stack_offset));
 #else
@@ -1796,5 +1796,5 @@
         break;
       case Op_VecX:
-#ifndef LP64
+#ifndef _LP64
         __ movdqu(Address(rsp, stack_offset), as_XMMRegister(Matcher::_regEncode[reg]));
 #else
@@ -1808,5 +1808,5 @@
         break;
       case Op_VecY:
-#ifndef LP64
+#ifndef _LP64
         __ vmovdqu(Address(rsp, stack_offset), as_XMMRegister(Matcher::_regEncode[reg]));
 #else

...then the build starts to fail on Linux x86_64 with:

/home/shade/trunks/jdk-jdk/src/hotspot/cpu/x86/assembler_x86.hpp:2135:8: note:   candidate expects 3 arguments, 4 provided
/home/shade/trunks/jdk-jdk/src/hotspot/cpu/x86/assembler_x86.hpp:2136:8: note: candidate: void Assembler::vextracti32x4(Address, XMMRegister, uint8_t)
   void vextracti32x4(Address dst, XMMRegister src, uint8_t imm8);
        ^~~~~~~~~~~~~
/home/shade/trunks/jdk-jdk/src/hotspot/cpu/x86/assembler_x86.hpp:2136:8: note:   candidate expects 3 arguments, 4 provided
/home/shade/trunks/jdk-jdk/src/hotspot/cpu/x86/x86.ad:1817:143: error: no matching function for call to 'MacroAssembler::vextracti64x4(Address, XMMRegister, XMMRegister, int)'
           __ vextracti64x4(Address(rsp, stack_offset), as_XMMRegister(Matcher::_regEncode[reg]), as_XMMRegister(Matcher::_regEncode[reg]), 0x0);
                                                                                                                                               ^

There is no 4-argument vextracti64x4 to be seen, indeed.

So, not only the LP64 is not taken, it does not even compile.
Comments
Fix Request (11u) This backport fixes the issue with AVX-512 support already backported to 11u, and also matches codebases (I see 11.0.6-oracle). Patch applies cleanly to 11u, passes tier1 tests.
31-07-2019

Please consider backporting it to 12u and 11u too, as JDK-8210764 got backported with this bug included.
11-02-2019

http://cr.openjdk.java.net/~sviswanathan/8217371/webrev.00/ The above webrev fixes the incorrect LP64 guard issue in x86.ad file. I have corrected the guard to _LP64 and updated the spill/fill instructions. This bug only affected the Knights family where AVX512VL is not supported. Tested it on SKX and Knights family with compiler jtreg tests.
27-01-2019

Hi Vladimir, Sandhya is taking this.
23-01-2019

[~vdeshpande] Please, look on this.
22-01-2019

http://cr.openjdk.java.net/~shade/8217371/build-skl.patch Above is the absolutely minimal thing that makes build pass on my SKL-X desktop. I am not sure the encoding for new insn is 100% correct. I suspect the "VM_Version::supports_avx512vl()" should be inverted, but after I do that, some hotspot tier1 tests start to fail. Without supports_avx512vl inversion, hotspot tier1 pass, and also that .ad branch where we emit new AVX512 code is not executed at all: I put ShouldNotReachHere, and tier1 passes with flying colors. We need our friends at Intel to come up with the proper patch, I guess?
22-01-2019

Wow, good catch Aleksey! ILW = Non-optimal instructions emitted by C2 due to incorrect macro check (only affects performance, no impact on correctness/stability), some AVX 512 instructions on x86_64, no workaround = MMH = P3
18-01-2019

Vladimir, please reassign as you see fit?
18-01-2019