Skip to content
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

omit record_accesses function when collecting MonoItems #97168

Merged
merged 1 commit into from
May 26, 2022

Conversation

SparrowLii
Copy link
Member

@SparrowLii SparrowLii commented May 19, 2022

This PR fixes the FIXME in the impl of record_accesses function.
[Edit] We can call instantiation_mode when push the MonoItem into neighbors. This avoids extra local variables accesses: SmallVec<[_; 128]>

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label May 19, 2022
@rust-highfive
Copy link
Collaborator

r? @cjgillot

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 19, 2022
@cjgillot
Copy link
Contributor

IIUC, the point was to avoid calling instanciation_mode from inside the lock. Why can we now do it?

@SparrowLii
Copy link
Member Author

IIUC, the point was to avoid calling instanciation_mode from inside the lock. Why can we now do it?

It makes sense! Sorry for mistaking the meaning of this FIXME earlier. I have made the corresponding changes.

fn record_accesses<'a>(
&mut self,
source: MonoItem<'tcx>,
new_targets: impl Iterator<Item = &'a (Spanned<MonoItem<'tcx>>, bool)> + ExactSizeIterator,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can take a simple slice, no need to be more general than necessary.

for (i, (target, inline)) in new_targets.iter().enumerate() {
self.targets.push(*target);
if *inline {
for (i, target) in new_targets.enumerate() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please prefer destructuring the tuple, the intent is clearer.

.into_iter()
.filter_map(|root| root.node.is_instantiable(tcx).then_some(root.node))
.filter_map(|root| root.0.node.is_instantiable(tcx).then_some(root.0.node))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we destructure the tuple here?

output.extend(methods);
.map(|item| {
let item = create_fn_mono_item(tcx, item, source);
let inlined = if is_root {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where does this logic come from?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Judging inlining does seem a little out of place here. I added the extend method to the MonoItems so it looks more reasonable

@@ -226,6 +225,24 @@ pub struct InliningMap<'tcx> {
inlines: GrowableBitSet<usize>,
}

struct MonoItems<'tcx> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you document this struct and its fields?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure

collect_items_rec(tcx, neighbour, visited, recursion_depths, recursion_limit, inlining_map);
inlining_map.lock_mut().record_accesses(starting_point.node, neighbors.items.iter());

for neighbour in neighbors.items {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please destructure the tuple here too.

@SparrowLii
Copy link
Member Author

Thanks for reviewing! I made the corresponding changes and it looks clearer

@SparrowLii SparrowLii requested a review from cjgillot May 25, 2022 13:15
Copy link
Contributor

@cjgillot cjgillot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @SparrowLii! Looking good.
Two nits, and then r=me.

} else {
item.node.instantiation_mode(self.tcx) == InstantiationMode::LocalCopy
};
self.items.push((item, inlined));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function can be implemented as self.extend([item]).

struct MonoItems<'tcx> {
// Whether the collecting start from the root. The mono
// items will not be inlined if so.
is_root: bool,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is not accurate. The questions is whether we need to compute instantiation_mode, not about inlining.
Proposed redaction: "When collecting from the root, we do not need to compute whether items will need to be inlined."
Should this be named compute_inlining?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Such a comment is indeed more accurate

@SparrowLii
Copy link
Member Author

@bors r=cjgillot

@bors
Copy link
Contributor

bors commented May 26, 2022

@SparrowLii: 🔑 Insufficient privileges: Not in reviewers

@SparrowLii
Copy link
Member Author

@cjgillot It seems that we need you to r+ here

@cjgillot
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented May 26, 2022

📌 Commit 480e603 has been approved by cjgillot

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 26, 2022
@bors
Copy link
Contributor

bors commented May 26, 2022

⌛ Testing commit 480e603 with merge 1ab9893...

@bors
Copy link
Contributor

bors commented May 26, 2022

☀️ Test successful - checks-actions
Approved by: cjgillot
Pushing 1ab9893 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 26, 2022
@bors bors merged commit 1ab9893 into rust-lang:master May 26, 2022
@rustbot rustbot added this to the 1.63.0 milestone May 26, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (1ab9893): comparison url.

Instruction count

  • Primary benchmarks: no relevant changes found
  • Secondary benchmarks: 😿 relevant regressions found
mean1 max count2
Regressions 😿
(primary)
N/A N/A 0
Regressions 😿
(secondary)
0.7% 1.1% 5
Improvements 🎉
(primary)
N/A N/A 0
Improvements 🎉
(secondary)
N/A N/A 0
All 😿🎉 (primary) N/A N/A 0

Max RSS (memory usage)

Results
  • Primary benchmarks: no relevant changes found
  • Secondary benchmarks: mixed results
mean1 max count2
Regressions 😿
(primary)
N/A N/A 0
Regressions 😿
(secondary)
2.4% 2.4% 1
Improvements 🎉
(primary)
N/A N/A 0
Improvements 🎉
(secondary)
-1.9% -2.3% 2
All 😿🎉 (primary) N/A N/A 0

Cycles

Results
  • Primary benchmarks: 🎉 relevant improvement found
  • Secondary benchmarks: 🎉 relevant improvements found
mean1 max count2
Regressions 😿
(primary)
N/A N/A 0
Regressions 😿
(secondary)
N/A N/A 0
Improvements 🎉
(primary)
-2.9% -2.9% 1
Improvements 🎉
(secondary)
-3.2% -3.7% 2
All 😿🎉 (primary) -2.9% -2.9% 1

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

  1. the arithmetic mean of the percent change 2 3

  2. number of relevant changes 2 3

nnethercote added a commit to nnethercote/rust that referenced this pull request May 31, 2023
PR rust-lang#97168 was created to address this comment in `record_accesses`:

// We collect this into a `SmallVec` to avoid calling `is_inlining_candidate` in the lock.
// FIXME: Call `is_inlining_candidate` when pushing to `neighbors` in `collect_items_rec`
// instead to avoid creating this `SmallVec`.

It removed the need for the `SmallVec` (a good thing) by introducing
`MonoItems`, which introduced some additional complexity (a bad thing).

However, the reason the `SmallVec` was being used in the first place --
"to avoid calling `is_inlining_candidate` in the lock" -- isn't
necessary, as far as I can tell. Perhaps it was at one point.

So this commit just moves what is left of the call to
`is_inlining_candidate` -- a call the innocuous `instantiation_mode` --
inside the lock. This avoids the complexity of `MonoItems` sometimes
computing inlining data and sometimes not.
@nnethercote nnethercote mentioned this pull request May 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants