[15] RFR (M): 8136414: Large performance penalty declaring a method strictfp on strict-only platforms

[Tobias Hartmann]

Hi Vladimir,

looks good to me!

You may want to do some whitespace cleanup in graphKit.cpp before pushing (for example, around
parentheses in lines 2330, 2346, 2360, 2374).

Thanks,
Tobias

On 07.02.20 10:37, Vladimir Ivanov wrote:
> 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;
>    }