[15] RFR (M): 8136414: Large performance penalty declaring a method strictfp on strict-only platforms
    Vladimir Ivanov 
    vladimir.x.ivanov at oracle.com
       
    Fri Feb  7 09:37:53 UTC 2020
    
    
  
http://cr.openjdk.java.net/~vlivanov/8136414/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8136414
After JDK-7175279 [1] landed in the repo, it becomes possible to relax 
constrains on inlining between strict FP and non-strict FP methods on 
x86-64.
Since x86-64 doesn't use x87 anymore, the platform becomes strict-only 
and it's safe to mix strict and non-strict FP code.
The actual fix is a tiny change in doCall.cpp [2].
The rest is a refactoring which regularizes and cleans up related code:
   * removes RoundFPResults and UseStrictFP develop flags;
   * migrate all the checks to strict_fp_requires_explicit_rounding / 
pd_strict_fp_requires_explicit_rounding which are set true only on x86-32;
   * move related UseSSE checks to x86-specific code (or even x86-32 if 
UseSSE <= 2 is requires);
Testing: hs-precheckin-comp, tier1-4
Thanks!
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-7175279
[2] src/hotspot/share/opto/doCall.cpp
-  // Do not inline strict fp into non-strict code, or the reverse
-  if (caller->is_strict() ^ callee->is_strict()) {
+  // If explicit rounding is required, do not inline strict into 
non-strict code (or the reverse).
+  if (Matcher::strict_fp_requires_explicit_rounding &&
+      caller->is_strict() != callee->is_strict()) {
      allow_inline = false;
    }
    
    
More information about the hotspot-compiler-dev
mailing list