RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation

[David Holmes]

Correction ...

On 13/09/2018 8:31 AM, David Holmes wrote:
> On 12/09/2018 6:16 PM, Severin Gehwolf wrote:
>> On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
>>> But I don't understand why the optimization setting is being tied to the
>>> availability of the -ffp-contract flag?
>>
>> In configure we perform a check for gcc or clang whether that flag is
>> supported. If it is, it would be non-empty exactly having -ffp-contract
>> as value. It could be another set of flags for other arches if somebody
>> wanted to do the same, fwiw. In JDK 8, for example, it's "-mno-fused-
>> madd -fno-strict-aliasing" for ppc64:
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/2660b127b407/make/lib/CoreLibraries.gmk#l63 
>>
>>
>> We need support for that flag (or a set of flags) when we optimize
>> fdlibm since otherwise we would lose precision. If the flag is empty
>> we'd not optimize as we can't guarantee precision. That's why we tie
>> optimization to the availability of that flag. The expectation is for
>> this flag to be available on gcc/clang arches only at this point. Does
>> that make sense?
> 
> Yes that makes sense - thanks. I didn't quite glean that from the comment:
> 
>    42 # If FDLIBM_CFLAGS is non-empty we know that we can optimize
>    43 # fdlibm by adding those extra C flags. Currently GCC,

I think this should say "when adding" not "by adding".

Thanks,
David

>    44 # and clang only.
>    45 ifneq ($(FDLIBM_CFLAGS), )
>    46   BUILD_LIBFDLIBM_OPTIMIZATION := LOW
> 
> But now I can read it and understand.
> 
> Thanks,
> David
> 
>> Thanks,
>> Severin
>>