RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation
david.holmes at oracle.com
Thu Sep 13 01:00:57 UTC 2018
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:
>> 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".
> 44 # and clang only.
> 45 ifneq ($(FDLIBM_CFLAGS), )
> 46 BUILD_LIBFDLIBM_OPTIMIZATION := LOW
> But now I can read it and understand.
More information about the core-libs-dev