-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8261914: IfNode::fold_compares_helper faces non-canonicalized bool when running JRuby JSON workload #2707
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 |
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.
okay
@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 75 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 |
return false; | ||
} | ||
assert(this_bool->_test.is_less() && !fail->_con, "incorrect test"); |
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 should lead with "this test was canonicalized" comment? Missed during the move, I think.
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 also find it a bit weird to even have the assert on this path, as we tested all cases in the if-chain before, and the only path to this assert is through lt
and le
-- which is is_less
? Maybe I am missing something, though.
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 also find it a bit weird to even have the assert on this path, as we tested all cases in the if-chain before, and the only path to this assert is through
lt
andle
-- which isis_less
? Maybe I am missing something, though.
I kept it because of the !fail->_con part of the assert. I kept the whole assert and move it around because I'm lazy, I guess.
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.
That's fine. Keep the comment, though?
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
/integrate |
@rwestrel Since your change was applied there have been 75 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 20c93b3. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
The assert fires because the current IfNode's condition was not
canonicalized when it's being folded with a dominating
IfNode. idealize_test() should have taken care of that because it
executed before fold_compares() but it didn't because:
Node* new_b = phase->transform( new BoolNode(b->in(1), bt.negate()) );
if( !new_b->is_Bool() ) return NULL;
caused it to bail out. new_b is a constant. This happens because of
the order in which nodes are processed by IGVN. The If's current Bool
would also constant fold but it's in the IGVN worklist and hasn't been
processed yet.
The fix I propose is to keep Aleksey's defensive fix but to check that
the Bool input is indeed about to be transformed by IGVN and that that
would cause the IfNode to be reprocessed.
I tried to write a test case but didn't succeed. The 2 If nodes come
from a tableswitch that's transformed into a series of If based on
profile data. I couldn't reproduce the profile data with a simple test
case.
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/2707/head:pull/2707
$ git checkout pull/2707