-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
8347645: C2: XOR bounded value handling blocks constant folding #23089
base: master
Are you sure you want to change the base?
Conversation
👋 Welcome back j3graham! A progress list of the required criteria for merging this PR into |
❗ This change is not yet ready to be integrated. |
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. |
test/hotspot/jtreg/compiler/c2/irTests/XorINodeIdealizationTests.java
Outdated
Show resolved
Hide resolved
Very nice, I think the patch looks good, please do another round of style refinement. In particular, make sure that there is no white space after |
Thanks. I've done another round of format fixing. I've also simplified the IR tests so they don't try to cover as much as gtest does, and added equivalent tests for long. I have temporarily left the more elaborate tests commented out in XorINodeIdealizationTests. I will remove them if nobody thinks they are worth keeping. |
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.
Otherwise LGTM, very nice tests, thanks very much!
test/hotspot/jtreg/compiler/c2/irTests/XorINodeIdealizationTests.java
Outdated
Show resolved
Hide resolved
@j3graham Can you please update the PR description at the top? The current version does not reflect the most up-to-date explanations, right? I would like to see a nice summary, what cases were covered before and what cases you are now covering additionally. I'll increase the number of reviewers as this looks like a substantial change. /reviewers 2 reviewer |
I also see that #2776 and #4136 were mentioned here. Both of those are related an have no IR tests of their own, yikes! We have to ensure that we cover those old cases, and then new ones here, so that we do not get any accidental regressions. Maybe that's all already covered in other existing tests or the tests you added. Can you please provide a summary of all tests and what cases they cover in the PR description? It would help a lot for reviewing. |
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.
@j3graham Thanks for taking this on! It's great to see someone clean this up and make sure all the cases optimize as expected!
I have updated the summary to be more informative. I believe the related optimizations are now covered in tests. |
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.
This looks really nice! I just have 2 small comments here.
test/hotspot/jtreg/compiler/c2/irTests/XorINodeIdealizationTests.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Jasmine Karthikeyan <[email protected]>
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 the update! It looks good to me.
Hi, @eme64, do you have any additional comments on this PR? |
An interaction between xor bounds optimization and constant folding resulted in xor over constants not being optimized. This has a noticeable effect on
Long.expand
with a constant mask, on architectures that don't have instructions equivalent toPDEP
to be used in an intrinsic.This change moves logic from the
Xor(L|I)Node::Value
methods into theadd_ring
methods, 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
XorINodeIdealizationTests
andXorLNodeIdealizationTests
to cover these related items:x ^ x = 0
Also
test_xor_node.cpp
was 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
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23089/head:pull/23089
$ git checkout pull/23089
Update a local copy of the PR:
$ git checkout pull/23089
$ git pull https://git.openjdk.org/jdk.git pull/23089/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 23089
View PR using the GUI difftool:
$ git pr show -t 23089
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23089.diff
Using Webrev
Link to Webrev Comment
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23089/head:pull/23089
$ git checkout pull/23089
Update a local copy of the PR:
$ git checkout pull/23089
$ git pull https://git.openjdk.org/jdk.git pull/23089/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 23089
View PR using the GUI difftool:
$ git pr show -t 23089
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23089.diff
Using Webrev
Link to Webrev Comment