New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8265917: Different values computed by C2 and interpreter/C1 for Math.pow(x, 2.0) on x86_32 #3677
Conversation
…pow(x, 2.0) on x86_32
|
/test |
@DamonFool |
@DamonFool The |
Webrevs
|
I think you should fix 32-bit version of Also add C Java lib code also has this optimization: Only 32-bit x86 stub is missing it: The stub is generated only on x86:
I suggest to fix it to be consistent with the rest of VM and Java lib code. |
Hi @vnkozlov , Math.pow(x, 2.0) has been optimized for x86_32. Thanks. |
Testing: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good.
Okay. |
@DamonFool This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 58 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
|
Thanks @vnkozlov for your review. Let's wait for a second review of this change. |
|
||
assert_different_registers(tmp, eax, ecx, edx); | ||
|
||
address static_const_table_pow = (address)_static_const_table_pow; | ||
static double DOUBLE2 = 2.0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Constants in the 64-bit code and _static_const_table_pow
above use ATTRIBUTE_ALIGNED
. Should we add that for DOUBLE2
as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @TobiHartmann ,
Thanks for your review.
Yes, it seem better to be with ATTRIBUTE_ALIGNED.
Updated.
|
||
bind(start); | ||
subl(rsp, 120); | ||
movl(Address(rsp, 64), tmp); | ||
lea(tmp, ExternalAddress(static_const_table_pow)); | ||
movsd(xmm0, Address(rsp, 128)); | ||
movsd(xmm1, Address(rsp, 136)); | ||
|
||
// Special case: pow(x, 2.0) => x * x |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
64-bit code also handles Special case: pow(x, 0.5) => sqrt(x)
. Don't we need to add that as well for consistency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
64-bit code also handles
Special case: pow(x, 0.5) => sqrt(x)
. Don't we need to add that as well for consistency?
This is the bug fix for C2's optimization of pow(x, 2.0).
pow(x, 0.5) will be handled in JDK-8265940 .
Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
Thanks @TobiHartmann . @vnkozlov , are you OK with the latest change? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Latest version with alignment is good.
Thanks @vnkozlov . |
@DamonFool Since your change was applied there have been 58 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 889d246. |
Hi all,
C2 may produce different results for Math.pow(x, 2.0) compared with interpreter/C1 on x86_32.
E.g., for Math.pow(1.0 / 2047, 2.0):
The reason is that C2 will replace Math.pow(x, 2.0) with x*x.
However, there is no such optimization for interpreter/C1 on x86_32.
The fix just disables C2's opt for Math.pow(x, 2.0) on x86_32 since nobody (or very few people) would run x86_32.
And we don't have a plan to implement such opt on x86_32.
Another reason to fix this bug is that we need this patch to extend C2's opt for Math.pow(x, 0.5) on other platforms.
Thanks.
Best regards,
Jie
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3677/head:pull/3677
$ git checkout pull/3677
Update a local copy of the PR:
$ git checkout pull/3677
$ git pull https://git.openjdk.java.net/jdk pull/3677/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 3677
View PR using the GUI difftool:
$ git pr show -t 3677
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3677.diff