JDK-8210764 : Update avx512 implementation
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: x86
  • Submitted: 2018-09-14
  • Updated: 2020-11-11
  • Resolved: 2018-09-24
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 12
11.0.2Fixed 12 b13Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
Recently there have been couple of high priority issues with regards to avx512 high bank of XMM register (XMM16-XMM31) usage by C2: JDK-8207746, JDK-8209735

Please find below a patch which attempts to clean up the XMM register handling by using register groups:

http://cr.openjdk.java.net/~vdeshpande/xmm_reg/webrev.01/

The patch provides a restricted set of registers to the match rules in the ad file based on the underlying architecture.

The aim is to remove special handling/workaround from macro assembler and assembler.

By removing the special handling, the patch reduces the overall code size by about 1800 lines of code. 

Best Regards,
Sandhya
Comments
Fix Request: These changes fix the underlying issue of dynamic size for the generated code for avx512 which was fixed only in jdk12 by the JDK-8209594 fix. In JDK 11 we disabled AVX512 by setting default value of UseAVX to 2 which does not prevent a customer to set it to 3 on command line and hit the original issue. JDK-8210764 and JDK-8211251 rewrote AVX512 implementation to avoid this issue. With JDK-8211272, it fixed the 32-bit build issue after JDK 8210764. So we need to integrate all the 3 fixes JDK-8210764, JDK-8211272, and JDK-8211251 together as they depend on each other. We did run jtreg tests on various platforms, did tests with Lucene in Elasticsearch's container. All the testing verified the fixes. The changes can be applied cleanly to jdk11u sources, so we would not need a new RFR.
26-10-2018

And I ran tier1-tier3+Xcomp mach5 testing of 11u patch which combined 3 fixes JDK-8210764, JDK-8211272, and JDK-8211251. And tier1-tier5+Xcomp specifically on avx512 machine. No new failures.
26-10-2018

http://cr.openjdk.java.net/~vdeshpande/xmm_reg/webrev.04/ Fixed LIR_Assembler::negate() definition on all platforms.
24-09-2018

webrev.03 failed build on SPARC due to shared changes in C1. Previously it was hidden by other SPARC build bug.
20-09-2018

Webrev.03 testing passed clean with only known pre-existing failures
20-09-2018

http://cr.openjdk.java.net/%7Evdeshpande/xmm_reg/webrev.03/
19-09-2018

Testing found few failures.
15-09-2018

Have to fix cpu/x86/c1_FrameMap_x86.cpp to remove next lines - _xmm_regs[16] = xmm16; - _xmm_regs[17] = xmm17; - _xmm_regs[18] = xmm18; ... - _xmm_regs[29] = xmm29; - _xmm_regs[30] = xmm30; - _xmm_regs[31] = xmm31;
14-09-2018

It also should enable avx512 by reversing JDK-8209735 change.
14-09-2018