-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8369646: Detection of redundant conversion patterns in add_users_of_use_to_worklist is too restrictive #27900
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
base: master
Are you sure you want to change the base?
Conversation
|
👋 Welcome back bmaillard! A progress list of the required criteria for merging this PR into |
|
@benoitmaillard 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 235 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. ➡️ To integrate this PR with the above commit message to the |
|
@benoitmaillard The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
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, looks good, thanks!
| * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions | ||
| * -XX:CompileCommand=compileonly,compiler.c2.TestEliminateRedundantConversionSequences::test* | ||
| * -XX:-TieredCompilation -Xbatch -XX:VerifyIterativeGVN=1110 compiler.c2.TestEliminateRedundantConversionSequences | ||
| * -XX:-TieredCompilation -Xbatch -XX:VerifyIterativeGVN=1110 |
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.
You could either add a separate run with -XX:+StressIGVN without a fixed seed or just add -XX:+StressIGVN here. I guess the latter is good enough.
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.
I agree, and I just added -XX:+StressIGVN to the existing run.
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, thanks!
| * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions | ||
| * -XX:CompileCommand=compileonly,compiler.c2.TestEliminateRedundantConversionSequences::test* | ||
| * -XX:-TieredCompilation -Xbatch -XX:VerifyIterativeGVN=1110 compiler.c2.TestEliminateRedundantConversionSequences | ||
| * -XX:-TieredCompilation -Xbatch -XX:VerifyIterativeGVN=1110 |
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, 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 :)
| // ConvF2L->ConvL2F->ConvF2L | ||
| // ConvI2F->ConvF2I->ConvI2F | ||
| // Note: there may be other 3-nodes conversion chains that would require to be added here, but these | ||
| // are the only ones that are known to trigger missed optimizations otherwise |
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.
You may want to update the description, and give a bit of extra information. Because you are saying n does not have to be a conversion, but it may be that n is about to be replaced with a conversion, right?
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.
Yes, in some cases add_users_of_use_to_worklist is called with the node about to be replaced as argument n. The point is that we might replace n with a node that already has other uses, and we only want to notify the uses for which there is a potential change.
But this is in no way specific to this one optimization, so I think adding something here would cause more confusion than anything else. Perhaps we should update the description of add_users_of_use_to_worklist then?
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.
Right, this is not specific to this optimization here. Why not add something at the level of add_users_of_use_to_worklist.
This PR addresses a missed optimization opportunity in
PhaseIterGVN. The missed optimization is the simplification of redundant conversion patterns of the shapeConvX2Y->ConvY2X->ConvX2Y.This optimization pattern is implemented as an ideal optimization on
ConvX2Ynodes. Because it depends on the input of the input of the node in question, we need to have an appropriate notification mechanism inPhaseIterGVN::add_users_of_use_to_worklist. The notification for this pattern was added in JDK-8359603.However, that fix was based on the wrong assumption that in
PhaseIterGVN::add_users_of_use_to_worklist, argumentnis already the optimized node. However in some cases this argument is actually the node that is about to get replaced.This happens for example in
PhaseIterGVN::transform_old. If we find that nodekreturned byIdealactually already exists by callinghash_find_insert(k), we calladd_users_to_worklist(k).As we replace node
kwithi, andias a different opcode thank, then we cannot use the opcode ofkto detect the redundant conversion pattern.The bug was quite intermittent and only showed up in some cases with
-XX:+StressIGVN.Proposed Fix
We make the detection of the pattern less specific by only looking at the opcode of the user of
n, and not directly the opcode ofn. This is consistent with the detection of other patterns inPhaseIterGVN::add_users_of_use_to_worklist.Testing
-XX:+StressIGVNand a fixed stress seedThank you for reviewing!
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27900/head:pull/27900$ git checkout pull/27900Update a local copy of the PR:
$ git checkout pull/27900$ git pull https://git.openjdk.org/jdk.git pull/27900/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 27900View PR using the GUI difftool:
$ git pr show -t 27900Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27900.diff
Using Webrev
Link to Webrev Comment