[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