8354383: C2: enable sinking of Type nodes out of loop#25396
8354383: C2: enable sinking of Type nodes out of loop#25396rwestrel wants to merge 4 commits intoopenjdk:masterfrom
Conversation
|
👋 Welcome back roland! A progress list of the required criteria for merging this PR into |
|
@rwestrel 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 371 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 |
Webrevs
|
TobiHartmann
left a comment
There was a problem hiding this comment.
That looks good to me but given that we had quite a few bugs in that area in the past, I would suggest to only integrate into JDK 26 after the fork on June 05, 2025.
| !n->is_OpaqueNotNull() && | ||
| !n->is_OpaqueInitializedAssertionPredicate() && | ||
| !n->is_OpaqueTemplateAssertionPredicate() && | ||
| !n->is_Type()) { |
There was a problem hiding this comment.
I cannot remember exactly, how often was it a problem without JDK-8349479? If it was more common, we might want to only allow it when KillPathsReachableByDeadTypeNode is set.
There was a problem hiding this comment.
I made that change.
As far as I remember, the logic removed by JDK-8319372 played a key role in those failures. Not sure if any were still reproducible after than one.
There was a problem hiding this comment.
Yes, that matches what I remember. Maybe JDK-8319372 can now be reverted with JDK-8349479 in?
Sounds reasonable to me. |
| !n->is_OpaqueNotNull() && | ||
| !n->is_OpaqueInitializedAssertionPredicate() && | ||
| !n->is_OpaqueTemplateAssertionPredicate() && | ||
| !n->is_Type()) { |
There was a problem hiding this comment.
Yes, that matches what I remember. Maybe JDK-8319372 can now be reverted with JDK-8349479 in?
Co-authored-by: Christian Hagedorn <christian.hagedorn@oracle.com>
I think it would be safe but I'm unclear if it's worth doing or not. |
|
I'm not sure either, we would not to further investigate if we can find cases that benefit from it. Should we file an RFE either way? |
|
|
@TobiHartmann @chhagedorn thanks for the reviews. |
|
/integrate |
|
Going to push as commit a2f99fd.
Your commit was automatically rebased without conflicts. |
PhaseIdealLoop::try_sink_out_of_loop()excludesTypenodes becausewe ran into some issues where a
Typenode is sunk and then becomestopbut the control path of its uses doesn't become unreachable.8349479 should have fixed that so that exception no longer makes
sense.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25396/head:pull/25396$ git checkout pull/25396Update a local copy of the PR:
$ git checkout pull/25396$ git pull https://git.openjdk.org/jdk.git pull/25396/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 25396View PR using the GUI difftool:
$ git pr show -t 25396Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25396.diff
Using Webrev
Link to Webrev Comment