-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8345299: C2: some nodes can still have incorrect control after do_range_check() #22485
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 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 158 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
|
chhagedorn
left a comment
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. Do you have a regression test where this leads to an actual failure?
I don't. This seems unlikely to cause issues with the current code. I ran into this while working on JDK-8275202 where new code I've added is failing. |
|
I see, thanks for background! |
vnkozlov
left a comment
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.
Few comments.
| // new pre_limit can push Bool/Cmp/Opaque nodes down (when one of the eliminated condition has parameters that are not | ||
| // loop invariant in the pre loop. | ||
| set_ctrl(pre_opaq, new_limit_ctrl); |
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.
Can you update this comment to explain different control settings as you did in PR's description.
| // new main_limit can push Bool/Cmp nodes down (when one of the eliminated condition has parameters that are not loop | ||
| // invariant in the pre loop. | ||
| // invariant in the pre loop). | ||
| set_ctrl(opqzm, new_limit_ctrl); |
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.
Update this comment too.
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.
Both done in new commit. Do the comments look ok to you?
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
vnkozlov
left a comment
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.
|
@vnkozlov @chhagedorn thanks for the reviews |
|
/integrate |
|
Going to push as commit d9a2213.
Your commit was automatically rebased without conflicts. |
8339733 fixed controls for updated pre/main limits during
do_range_check(). However, it missed one issue:
Control for the new limits is computed in
new_limit_ctrlfor bothpre and main loops.
new_limit_ctrlis currently initialized from thepre limit control but it also needs to take the main loop limit
control into account as sometimes, the main loop limit control is
below the pre limit and pre loop entry control.
8339733 also introduced a couple bugs. Control of the
Bool/Cmpnodes are updated for the pre and main loop to
new_limit_ctrl. Butthat's incorrect because
new_limit_ctrlmay be above the pre loopwhile the
Bool/Cmpfor the pre loop are in the loop (because theydepend on the loop iv) and for the main loop are after the pre loop
(because they depend on the iv out of the pre loop). I fixed this for
the pre loop by setting control for the
Bool/Cmpto be as late aspossible. For the main loop, no change appears to be required as
control computed by c2 is already late enough. I've added an assert
instead.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/22485/head:pull/22485$ git checkout pull/22485Update a local copy of the PR:
$ git checkout pull/22485$ git pull https://git.openjdk.org/jdk.git pull/22485/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 22485View PR using the GUI difftool:
$ git pr show -t 22485Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22485.diff
Using Webrev
Link to Webrev Comment