Re: PPC64: Poor StrictMath performance due to non-optimized compilation

On Mon, Nov 28, 2016 at 2:34 PM, Gustavo Romero wrote: > Hi Volker, > > On 25-11-2016 14:32, Volker Simonis wrote: >> On Fri, Nov 25, 2016 at 3:51 PM, Andrew Haley wrote: >>> On 22/11/16 09:57, Andrew Haley wrote: On 22/11/16 00:41, Gustavo

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Volker, On 25-11-2016 14:32, Volker Simonis wrote: > On Fri, Nov 25, 2016 at 3:51 PM, Andrew Haley wrote: >> On 22/11/16 09:57, Andrew Haley wrote: >>> On 22/11/16 00:41, Gustavo Romero wrote: Do you know if the gap between Math and StrictMath is also huge on aarch64?

Re: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Volker, Sorry for not replying earlier, it was day-off on Friday here... On 25-11-2016 11:32, Volker Simonis wrote: > Hi Gustavo, > > we've realized that we have exactly the same problem on Linux/s390 so > I hope you don't mind that I've updated the bug and the webrev to also > include the

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

On Fri, Nov 25, 2016 at 3:51 PM, Andrew Haley wrote: > On 22/11/16 09:57, Andrew Haley wrote: >> On 22/11/16 00:41, Gustavo Romero wrote: >>> Do you know if the gap between Math and StrictMath is also huge on aarch64? >> >> I'll try to have a look. > > The gap is just the same as

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

On 22/11/16 09:57, Andrew Haley wrote: > On 22/11/16 00:41, Gustavo Romero wrote: >> Do you know if the gap between Math and StrictMath is also huge on aarch64? > > I'll try to have a look. The gap is just the same as PPC. Andrew.

Re: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

Looks good. /Erik On 2016-11-25 14:32, Volker Simonis wrote: Hi Gustavo, we've realized that we have exactly the same problem on Linux/s390 so I hope you don't mind that I've updated the bug and the webrev to also include the fix for Linux/s390:

Re: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Gustavo, we've realized that we have exactly the same problem on Linux/s390 so I hope you don't mind that I've updated the bug and the webrev to also include the fix for Linux/s390: http://cr.openjdk.java.net/~simonis/webrevs/2016/8170153.top/

Re: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Erik, On 23-11-2016 12:29, Erik Joelsson wrote: > Build changes look ok. > > In CoreLibraries.gmk, I think it would have been ok to keep the conditional > checking (OPENJDK_TARGET_CPU_ARCH, ppc), but this certainly works too. Thanks a lot for reviewing the change. Regards, Gustavo

RE: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

ppc-aix-port-...@openjdk.java.net; Java Core Libs <core-libs-...@openjdk.java.net>; hotspot-...@openjdk.java.net Subject: Re: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation Hi Gustavo, thanks a lot for tracking this down! The change looks good and I a can sponsor it on

Re: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Martin, On 23-11-2016 12:38, Doerr, Martin wrote: > Hi Gustavo, > > thanks for providing the webrevs. > > I have ran the StrictMath jck tests which fail when building with -O3 and > without -ffp-contract=off: > FailedTests: > api/java_lang/StrictMath/desc.html#acos >

Re: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Volker, On 23-11-2016 12:05, Volker Simonis wrote: > thanks a lot for tracking this down! Happy to contribute :) > The change looks good and I a can sponsor it once you get another > review from the build group and the FC Extension Request was approved. Thanks a lot for sponsoring it! >

Re: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

Build changes look ok. In CoreLibraries.gmk, I think it would have been ok to keep the conditional checking (OPENJDK_TARGET_CPU_ARCH, ppc), but this certainly works too. /Erik On 2016-11-22 01:43, Gustavo Romero wrote: Hi, Could the following change be reviewed, please? webrev 1/2:

Re: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Gustavo, thanks a lot for tracking this down! The change looks good and I a can sponsor it once you get another review from the build group and the FC Extension Request was approved. In general I'd advise to sign the OCTLA [1] to get access to the Java SE TCK [2] as this contains quite a lot

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

On 22/11/16 00:41, Gustavo Romero wrote: > Do you know if the gap between Math and StrictMath is also huge on aarch64? I'll try to have a look. Andrew.

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

On 11/21/16 4:27 PM, Gustavo Romero wrote: Hi Joe, On 17-11-2016 19:33, joe darcy wrote: Currently, optimization for building fdlibm is disabled, except for the "solaris" OS target [1]. The reason for that is because historically the Solaris compilers have had sufficient discipline and

RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi, Could the following change be reviewed, please? webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/ webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/jdk/ bug:https://bugs.openjdk.java.net/browse/JDK-8170153 It enables fdlibm optimization on Linux PPC64 LE & BE and hence

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Hello, On 11/21/2016 4:34 PM, Gustavo Romero wrote: Hi Chris, On 17-11-2016 19:48, Chris Plummer wrote: The fdlibm code relies on aliasing a two-element array of int with a double to do bit-level reads and writes of floating-point values. As I understand it, the C spec allows compilers to

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Derek, On 17-11-2016 20:47, White, Derek wrote: > Hi Joe, > > Although neither a floating point expert (as I think I've proven to you over > the years), or a gcc expert, I checked with our in-house gcc expert and got > this following answer: > > "Yes using -fno-strict-aliasing fixes

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Chris, On 17-11-2016 19:48, Chris Plummer wrote: >> The fdlibm code relies on aliasing a two-element array of int with a double >> to do bit-level reads and writes of floating-point values. As I understand >> it, the C spec allows compilers to assume >> values of different types don't

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Joe, On 17-11-2016 19:33, joe darcy wrote: Currently, optimization for building fdlibm is disabled, except for the "solaris" OS target [1]. >>> The reason for that is because historically the Solaris compilers have had >>> sufficient discipline and control regarding floating-point

RE: PPC64: Poor StrictMath performance due to non-optimized compilation

vo Romero <grom...@linux.vnet.ibm.com>; ppc-aix-port-...@openjdk.java.net; hotspot-...@openjdk.java.net; core-libs-...@openjdk.java.net Cc: build-dev <build-dev@openjdk.java.net> Subject: Re: PPC64: Poor StrictMath performance due to non-optimized compilation On 11/17/16 1:33 PM, joe darcy wrote: > Hi

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

On 11/17/16 1:33 PM, joe darcy wrote: Hi Gustavo, On 11/17/2016 10:31 AM, Gustavo Romero wrote: Hi Joe, Thanks a lot for your valuable comments. On 17-11-2016 15:35, joe darcy wrote: Currently, optimization for building fdlibm is disabled, except for the "solaris" OS target [1]. The

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Gustavo, On 11/17/2016 10:31 AM, Gustavo Romero wrote: Hi Joe, Thanks a lot for your valuable comments. On 17-11-2016 15:35, joe darcy wrote: Currently, optimization for building fdlibm is disabled, except for the "solaris" OS target [1]. The reason for that is because historically the

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Joe, Thanks a lot for your valuable comments. On 17-11-2016 15:35, joe darcy wrote: >> Currently, optimization for building fdlibm is disabled, except for the >> "solaris" OS target [1]. > > The reason for that is because historically the Solaris compilers have had > sufficient discipline

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Erik, On 17-11-2016 07:17, Erik Joelsson wrote: > Overall this looks reasonable to me. However, if we want to introduce a new > possible tuple for specifying compilation flags to SetupNativeCompilation, we > (the build team) would prefer if we used > OPENJDK_TARGET_CPU instead of

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi David, On 17-11-2016 00:31, David Holmes wrote: > Adding in build-dev as they need to scrutinize all build changes. Thanks a lot. Regards, Gustavo

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Hello, On 11/16/2016 5:45 PM, Gustavo Romero wrote: Hi, Currently, optimization for building fdlibm is disabled, except for the "solaris" OS target [1]. The reason for that is because historically the Solaris compilers have had sufficient discipline and control regarding floating-point

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Hello, Overall this looks reasonable to me. However, if we want to introduce a new possible tuple for specifying compilation flags to SetupNativeCompilation, we (the build team) would prefer if we used OPENJDK_TARGET_CPU instead of OPENJDK_TARGET_CPU_ARCH. /Erik On 2016-11-17 03:31, David

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Adding in build-dev as they need to scrutinize all build changes. David On 17/11/2016 11:45 AM, Gustavo Romero wrote: Hi, Currently, optimization for building fdlibm is disabled, except for the "solaris" OS target [1]. As a consequence on PPC64 (Linux) StrictMath methods like, but not