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

[David Holmes]

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,
   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
>