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

[Severin Gehwolf]

Hi Andrew,

Thanks for the review. Once I have jdk8u-fix-yes I'll push the patch.

Cheers,
Severin

On Wed, 2019-05-01 at 07:02 +0100, Andrew John Hughes wrote:
> On 30/04/2019 12:37, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could I please get a review for this 8u backport related to fdlibm
> > optimization on Linux? The JDK 12 patch doesn't apply as-is as the JDK
> > 8 build system is drastically different from JDK 11+.
> > 
> 
> It's not "drastically different" as regards the top-level and jdk areas.
> HotSpot is another matter.
> 
> The main difference in this change is we're supporting gcc < 4.6, which
> is sensible.
> 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8210416
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/jdk8/02/
> > 
> > The main differences to the original fix are: a) optimization level and
> > b) additional hook for older GCC. This backport keeps the optimization
> > level at -O3 (HIGH) over -O2 (LOW) for JDK 8u as this would otherwise
> > regress Linux ppc64{,le} which currently use -O3. As the current code
> > has the implicit assumption of ppc64 being compiled on older GCCs too
> > (JDK-8172053), this backport maintains compatibility in this regard. If
> > -ffp-contract=off is not available, a machine specific set of flags is
> > being used if the compiler supports them (-mno-fused-madd -fno-strict-
> > aliasing).
> > 
> > For older GCCs (< 4.6) specific machine flags are being used. That is,
> > for ppc64{,le} and x86{,_64}. ppc64{,le} machine specific flags have
> > already been determined (See JDK-8172053). x86_64 and x86 have the same
> > machine specific flags available, so I've used them there too[1].
> > 
> > Testing: build/test on gcc 8.x Linux x86_64. build/test on gcc 4.4.7
> > x86_64/ppc64. Manual inspection of build logs for fdlibm files (e.g.
> > w_asin.c).
> > 
> > Thoughts?
> > 
> > Thanks,
> > Severin
> > 
> > [1] https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
> > 
> > 
> > 
> > 
> > 
> 
> Looks good to me. This is how JDK-8172053 should have been handled to
> begin with, rather than making assumptions (and indeed, that's how I
> fixed it [0] [1])
> 
> [0] http://icedtea.classpath.org/hg/icedtea8-forest/rev/d5760f7cce54
> [1] http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/3642a826880b