-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8347645: C2: XOR bounded value handling blocks constant folding #23089
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
Conversation
|
👋 Welcome back j3graham! A progress list of the required criteria for merging this PR into |
|
@j3graham This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. 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 96 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. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@eme64, @merykitty, @jaskarth, @iwanowww) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
|
The code for this optimization seems to be present already in the |
|
Created https://bugs.openjdk.org/browse/JDK-8347645 for you. The causes are #2776 and #4136. I think the right way forward is to remove XorI/LNode::Value and move the code to their add_ring, which has lower priority than constant folding, instead. However I am not a hotspot/JIT engineer, so don't take my words for granted. |
|
Thanks for creating the bug. I have left the x ^x =0 check in Value because it was operating on the Node rather than the Type. I moved the rest into add_ring. Done for Int, Long to follow. |
|
@j3graham Since this is a performance improvement: do you have any benchmark that shows a speedup? |
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.
Thanks for working on this!
I have not yet looked at the VM cpp changes yet.
Some comments about the test:
Please move it to:
test/hotspot/jtreg/compiler/c2/gvn/TestXor.java
The comments sometimes mention c3 etc, but there may only be a c or x. Please fix them ;)
The tests should also do result verification. Currently you only check that we have the expected nodes, but constant folding could have bugs we would not catch this way. What I usually do:
Compute some GOLDEN, which should be computed in interpreter, and then with a @Check method you can compare the result to that GOLDEN value.
Plus: it would be nice if the constants could be picked at random. You can do that with a public static final int CON = random_value.
Best would be if you could use the new Generators, see
./test/hotspot/jtreg/compiler/lib/generators/Generators.java
Let me know if you need any more help with that.
|
|
|
Thanks for the feedback. I've updated the tests as suggested. |
|
Thanks.
There's usually a lot of invariants a function assumes and it's simply impractical to encode everything in the name. Speaking of this particular case (
So,
I'm fine with placing it under |
I find it easier to think of it as calculating the upperbound of the xor of 2 non-negative integers whose upperbounds are given in the parameters. |
|
Renamed to |
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.
Overall, looks good.
Some minor comments follow.
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!
|
@j3graham I gave it a quick look, and it looks even better now. Let me run testing again before you integrate! Please ping me in 24h for the results! |
|
Hi @eme64, any news on test results? |
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.
Testing looks good :)
|
/sponsor |
|
/integrate |
|
/sponsor |
|
Going to push as commit 37f8e41.
Your commit was automatically rebased without conflicts. |
|
Thank you all for your help. I’m looking forward to #17508 making these kinds of optimizations more systematic. |


An interaction between xor bounds optimization and constant folding resulted in xor over constants not being optimized. This has a noticeable effect on
Long.expandwith a constant mask, on architectures that don't have instructions equivalent toPDEPto be used in an intrinsic.This change moves logic from the
Xor(L|I)Node::Valuemethods into theadd_ringmethods, and gives priority to constant-folding. A static method was separated out to facilitate direct unit-testing. It also (subjectively) simplified the calculation of the upper bound and added an explanation of the reasoning behind it.In addition to testing for constant folding over xor, IR tests were added to
XorINodeIdealizationTestsandXorLNodeIdealizationTeststo cover these related items:x ^ x = 0Also
test_xor_node.cppwas added to more extensively test the correctness of the bounds optimization. It exhaustively tests ranges of 4-bit numbers as well as at the high and low end of the affected types.Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23089/head:pull/23089$ git checkout pull/23089Update a local copy of the PR:
$ git checkout pull/23089$ git pull https://git.openjdk.org/jdk.git pull/23089/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 23089View PR using the GUI difftool:
$ git pr show -t 23089Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23089.diff
Using Webrev
Link to Webrev Comment