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

[Vladimir Ivanov]

Thanks, Tobias.

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

Good catch. Will do.

Best regards,
Vladimir Ivanov

> 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;
>>     }