-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8348411: C2: Remove the control input of LoadKlassNode and LoadNKlassNode #23274
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 qamai! A progress list of the required criteria for merging this PR into |
|
@merykitty 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 no new commits pushed to the ➡️ To integrate this PR with the above commit message to the |
|
@merykitty The following labels 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 lists. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
| && !too_many_traps(Deoptimization::Reason_array_check) | ||
| && !tak->klass_is_exact() | ||
| if (MonomorphicArrayCheck && !too_many_traps(Deoptimization::Reason_array_check) && !tak->klass_is_exact() | ||
| && tak != TypeInstKlassPtr::OBJECT) { |
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'd also turn tak != TypeInstKlassPtr::OBJECT into tak->isa_aryklassptr() to stress the intention.
(Please, keep the original formatting here.)
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.
Done, I assume you meant the formatting of the comment below, 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.
No, I referred to the original shape of the condition (1 check per line). IMO it is easier to follow.
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 (w/ minor cleanup suggestions).
Testing (hs-tier1 - hs-tier4) results are clean.
| && !too_many_traps(Deoptimization::Reason_array_check) | ||
| && !tak->klass_is_exact() | ||
| if (MonomorphicArrayCheck && !too_many_traps(Deoptimization::Reason_array_check) && !tak->klass_is_exact() | ||
| && tak != TypeInstKlassPtr::OBJECT) { |
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.
No, I referred to the original shape of the condition (1 check per line). IMO it is easier to follow.
|
@iwanowww Thanks a lot for your reviews and testing, I hope I have addressed all of your concerns. |
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.
Nice cleanup.
Though it looks like you are doing more than remove the ctrl input. I don't know the code very well, so I have some questions ;)
| if (MonomorphicArrayCheck && | ||
| !too_many_traps(Deoptimization::Reason_array_check) && | ||
| !tak->klass_is_exact() && | ||
| tak->isa_aryklassptr()) { |
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 like an implicit nullptr check. Not allowed by code style ;)
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 quickly explain this change from tak != TypeInstKlassPtr::OBJECT so I don't need to investigate myself, please?
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 like an implicit nullptr check. Not allowed by code style ;)
But the verb here is isa and we use these as a bool a lot, though :/
Can you quickly explain this change from tak != TypeInstKlassPtr::OBJECT so I don't need to investigate myself, please?
The bottom type of an array can be either Object or an array of some kind, so tak != TypeInstKlassPtr::OBJECT is the same as tak->isa_aryklassptr().
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.
Ah great, thanks for the explanation!
| // | ||
| // See issue JDK-8057622 for details. | ||
|
|
||
| always_see_exact_class = true; |
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.
Why is it ok to remove this?
If this branch is not taken, it used to be false, and would lead to something different below...
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.
The only use of this is to decide if we need to attach a control input to the LoadKlass. As the control input is not needed, this can be removed.
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.
Got it, 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, thanks for the explanations!
I see we did not yet run internal tests for the last commit, though it is only formatting, so most most likely ok.
But the state of the code is also 2 weeks old, so it would be good if you merged and launched testing again before integration, just in case ;)
|
@eme64 I have merged the change with master, could you help me initiate the testing process, please? Thanks very much. |
|
@merykitty Testing launched! |
|
@merykitty Testing is all passing! |
|
Thanks a lot for your reviews and testing! |
|
Going to push as commit e9278de.
Your commit was automatically rebased without conflicts. |
|
@merykitty Pushed as commit e9278de. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Hi,
This patch removes the control input of
LoadKlassNodeandLoadNKlassNode. They can only have a control input if created insideParse::array_store_check(), the reason given is:But this seems incorrect, the load from the constant type can be done regardless, and it will be constant-folded. This patch only makes that more formal and cleanup
LoadKlassNode::can_remove_control.Please take a look and leave your reviews, thanks a lot.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23274/head:pull/23274$ git checkout pull/23274Update a local copy of the PR:
$ git checkout pull/23274$ git pull https://git.openjdk.org/jdk.git pull/23274/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 23274View PR using the GUI difftool:
$ git pr show -t 23274Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23274.diff
Using Webrev
Link to Webrev Comment