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

rustc_mir: track inlined callees in SourceScopeData. #68965

Merged
merged 18 commits into from
Oct 26, 2020

Conversation

eddyb
Copy link
Member

@eddyb eddyb commented Feb 8, 2020

We now record which MIR scopes are the roots of other (inlined) functions's scope trees, which allows us to generate the correct debuginfo in codegen, similar to what LLVM inlining generates.
This PR makes the ui test backtrace-debuginfo pass, if the MIR inliner is turned on by default.

Also, #[track_caller] is now correct in the face of MIR inlining (cc @anp).

Fixes #76997.

r? @rust-lang/wg-mir-opt

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 8, 2020
@wesleywiser

This comment has been minimized.

@Aaron1011

This comment has been minimized.

@eddyb

This comment has been minimized.

@Aaron1011

This comment has been minimized.

@eddyb
Copy link
Member Author

eddyb commented Feb 8, 2020

If a cross-crate #[track_caller] function is inlined into a non-#[track_caller] function

The #[track_caller]'s function's entire body can be ignored, since the "caller location" span will be that of the call site inside the non-#[track_caller] function.

However, you're right there is a problem, it's just not in inlining: #47809 (comment)

@eddyb
Copy link
Member Author

eddyb commented Feb 9, 2020

I want to see if the #[track_caller] changes add too much overhead:
@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented Feb 9, 2020

⌛ Trying commit c43d529 with merge 5f38376...

bors added a commit that referenced this pull request Feb 9, 2020
 rustc_mir: track inlined callees in SourceScopeData.

This would be a prerequisite for generating the correct debuginfo in codegen, which would look similar to what LLVM inlining generates (we should be able to "fake it" as well).

Also, `#[track_caller]` is now correct in the face of MIR inlining (cc @anp).

However, the debuginfo side isn't implemented yet. I might take a stab at it soon, not sure.

r? @rust-lang/wg-mir-opt
if let Some(source_info) = frame.current_source_info() {
// Walk up the `SourceScope`s, in case some of them are from MIR inlining.
let mut scope = source_info.scope;
loop {
Copy link
Member

Choose a reason for hiding this comment

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

Would be great if we could deduplicate this logic.

Copy link
Member Author

Choose a reason for hiding this comment

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

Probably a method on mir::Body?

@bors
Copy link
Contributor

bors commented Feb 9, 2020

☀️ Try build successful - checks-azure
Build commit: 5f38376 (5f3837675c20728121185495e89d73dc1ac55dfa)

@rust-timer
Copy link
Collaborator

Queued 5f38376 with parent a19edd6, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit 5f38376, comparison URL.

@eddyb
Copy link
Member Author

eddyb commented Feb 9, 2020

What this tells me is that walking up the scope tree for every get_caller_location is wasteful.
I'm wondering whether it would be better to add a separate "inlined call tree" or just another Option<SourceScope> for the "inline root" (a scope with inlined: Some(...)).

@eddyb
Copy link
Member Author

eddyb commented Feb 9, 2020

Added a second Option<SourceScope> parent chain that skips directly to the inlined root scope.
@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented Feb 9, 2020

⌛ Trying commit c8c1f61e4bdb0bea14c6df1ff69dd3a93f0fd149 with merge 43b730a168b06d9629d3e3a4a42a885eb565c2be...

@bors
Copy link
Contributor

bors commented Feb 9, 2020

☀️ Try build successful - checks-azure
Build commit: 43b730a168b06d9629d3e3a4a42a885eb565c2be (43b730a168b06d9629d3e3a4a42a885eb565c2be)

@rust-timer
Copy link
Collaborator

Queued 43b730a168b06d9629d3e3a4a42a885eb565c2be with parent 6dff769, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit 43b730a168b06d9629d3e3a4a42a885eb565c2be, comparison URL.

@bjorn3
Copy link
Member

bjorn3 commented Feb 10, 2020

syn-opt clean build has a 9% regression in mir->llvm translation (~3% overall regression) The rest of the regressions don't seem to have a noticable change in the self-profiling data.

@eddyb
Copy link
Member Author

eddyb commented Feb 10, 2020

This looks very similar to the last run except that there should be be no inlined_parent_scope for the loop to even be entered, this time, I'm confused.
The whole point of this second run was that it should be boring.

@bjorn3
Copy link
Member

bjorn3 commented Feb 10, 2020

The regressions are smaller this time.

@eddyb
Copy link
Member Author

eddyb commented Feb 10, 2020

The regressions are smaller this time.

Only for syn-opt, which is the noise generator.
This time there's even more 1% regressions.
Oh and if you look past the red, on both of them, there's a bunch of max: 0.6% and max: 0.4%.
So something is certainly going wrong.

@eddyb
Copy link
Member Author

eddyb commented Oct 23, 2020

r? @nagisa for LLVM (I wish we had GH teams specifically for review roles so I don't have to guess)

Copy link
Member

@nagisa nagisa left a comment

Choose a reason for hiding this comment

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

There are a number of tests for MIR / at MIR level that have changed, which is fine; I'd love to see a test against LLVM-IR too.

From what I've seen in MIR tests, we might also want to have a way to run only a specific MIR optimisation at least for test purposes… sometime down the line.

See comments, but otherwise the changes LGTM (though I didn't pay super close attention to MIR ones, trusting Oli's review).

span: Span,
) -> S {
// FIXME(eddyb) this should never be `None`.
let dbg_scope = self.dbg_scope.unwrap();
Copy link
Member

Choose a reason for hiding this comment

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

expect and/or unwrap_or_else(|| bug!(...))?


let arg_ty = self.monomorphize(&decl.ty);

let span = self.adjust_span_for_debugging(decl.source_info.span);
Copy link
Member

Choose a reason for hiding this comment

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

This pattern appears to be repeated multiple times throughout the codebase. It might make sense to just have a method that does these three steps in a single location? Not sure what'd it be named tho… adjusted_span_and_dbg_scope maybe?

@oli-obk
Copy link
Contributor

oli-obk commented Oct 26, 2020

From what I've seen in MIR tests, we might also want to have a way to run only a specific MIR optimisation at least for test purposes… sometime down the line.

The way mir opts are being run is being reworked, and I think something like overwriting the optimization pipeline on a per-opt basis was also on the menu

@nagisa
Copy link
Member

nagisa commented Oct 26, 2020

@bors r=nagisa,oli-obk

@bors
Copy link
Contributor

bors commented Oct 26, 2020

📌 Commit 2b3f009 has been approved by nagisa,oli-obk

@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 Oct 26, 2020
@wesleywiser wesleywiser added the A-mir-opt Area: MIR optimizations label Oct 26, 2020
@bors
Copy link
Contributor

bors commented Oct 26, 2020

⌛ Testing commit 2b3f009 with merge 0da6d42...

@bors
Copy link
Contributor

bors commented Oct 26, 2020

☀️ Test successful - checks-actions
Approved by: nagisa,oli-obk
Pushing 0da6d42 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 26, 2020
@bors bors merged commit 0da6d42 into rust-lang:master Oct 26, 2020
@rustbot rustbot added this to the 1.49.0 milestone Oct 26, 2020
@eddyb eddyb deleted the mir-inline-scope branch October 31, 2020 13:38
cuviper added a commit to cuviper/rust that referenced this pull request Jan 13, 2021
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Jan 14, 2021
llvm: Remove the unused context from CreateDebugLocation

This went unused in commit 88d874d, part of rust-lang#68965.
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Jan 14, 2021
llvm: Remove the unused context from CreateDebugLocation

This went unused in commit 88d874d, part of rust-lang#68965.
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Jan 14, 2021
llvm: Remove the unused context from CreateDebugLocation

This went unused in commit 88d874d, part of rust-lang#68965.
m-ou-se added a commit to m-ou-se/rust that referenced this pull request Jan 14, 2021
llvm: Remove the unused context from CreateDebugLocation

This went unused in commit 88d874d, part of rust-lang#68965.
m-ou-se added a commit to m-ou-se/rust that referenced this pull request Jan 14, 2021
llvm: Remove the unused context from CreateDebugLocation

This went unused in commit 88d874d, part of rust-lang#68965.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-mir-opt Area: MIR optimizations 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MIR inlining doesn't properly adjust SourceScopeData parent_scope fields.