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 fi
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:
http://cr.openjdk.java.net/~simonis/webrevs/20
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/
http://cr.openjdk.java.net/~simonis/webrevs/2016/8
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 once you get another review from
the build group and the FC Extension Request was approved.
In general I&#
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
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
> javasoft.sqe.tests.api.
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!
> I
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: http:
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
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 contro
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 s
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 t
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 a
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 overlap
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 se
a.net;
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net
Cc: build-dev
Subject: 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,
>
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 reason
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 S
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 an
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 OPENJDK_TARG
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
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 sema
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 H
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 limited
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 limited to,
sin(), cos(), and tan() perform verify poor in comparison to the same methods
in Math class [2]:
25 matches
Mail list logo
