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

Make new symbol mangling scheme default for compiler itself. #90054

Merged
merged 1 commit into from
Oct 23, 2021

Conversation

michaelwoerister
Copy link
Member

As suggest in #89917 (comment), this PR enables the new symbol mangling scheme for the compiler itself. The standard library is still compiled using the legacy mangling scheme so that the new symbol format does not show up in user code (yet).

r? @Mark-Simulacrum

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 19, 2021
@Mark-Simulacrum
Copy link
Member

Is it permissible to mix the mangling like this? I guess that makes sense -- presumably we're encoding a bit somewhere indicating the mangling for -Zshare-generics and the like?

r=me

@michaelwoerister
Copy link
Member Author

Yes, we re-construct which version is needed:

let instantiating_crate =
if avoid_cross_crate_conflicts { Some(compute_instantiating_crate()) } else { None };
// Pick the crate responsible for the symbol mangling version, which has to:
// 1. be stable for each instance, whether it's being defined or imported
// 2. obey each crate's own `-Z symbol-mangling-version`, as much as possible
// We solve these as follows:
// 1. because symbol names depend on both `def_id` and `instantiating_crate`,
// both their `CrateNum`s are stable for any given instance, so we can pick
// either and have a stable choice of symbol mangling version
// 2. we favor `instantiating_crate` where possible (i.e. when `Some`)
let mangling_version_crate = instantiating_crate.unwrap_or(def_id.krate);
let mangling_version = if mangling_version_crate == LOCAL_CRATE {
tcx.sess.opts.debugging_opts.get_symbol_mangling_version()
} else {
tcx.symbol_mangling_version(mangling_version_crate)
};

It's not particularly pretty.

@michaelwoerister
Copy link
Member Author

@bors r=Mark-Simulacrum

@bors
Copy link
Contributor

bors commented Oct 19, 2021

📌 Commit 456283c has been approved by Mark-Simulacrum

@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 19, 2021
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Oct 21, 2021
…piler, r=Mark-Simulacrum

Make new symbol mangling scheme default for compiler itself.

As suggest in rust-lang#89917 (comment), this PR enables the new symbol mangling scheme for the compiler itself. The standard library is still compiled using the legacy mangling scheme so that the new symbol format does not show up in user code (yet).

r? `@Mark-Simulacrum`
@jackh726
Copy link
Member

Given that #89917 had a perf effect. I think this shouldn't be rolled up. @bors rollup=never

@wesleywiser
Copy link
Member

It looks like most of the effects in #89917 are due to increased linker time which, while rustc will take longer to link, shouldn't make the compiler itself slower. However, no reason not to be cautious here as well 🙂

@bors
Copy link
Contributor

bors commented Oct 23, 2021

⌛ Testing commit 456283c with merge a3f7c4d...

@bors
Copy link
Contributor

bors commented Oct 23, 2021

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing a3f7c4d to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 23, 2021
@bors bors merged commit a3f7c4d into rust-lang:master Oct 23, 2021
@rustbot rustbot added this to the 1.58.0 milestone Oct 23, 2021
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (a3f7c4d): comparison url.

Summary: This change led to moderate relevant mixed results 🤷 in compiler performance.

  • Moderate improvement in instruction counts (up to -0.8% on incr-unchanged builds of deeply-nested-async)
  • Moderate regression in instruction counts (up to 0.4% on incr-unchanged builds of deep-vector)

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

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

@rustbot rustbot added the perf-regression Performance regression. label Oct 23, 2021
@Mark-Simulacrum Mark-Simulacrum added the perf-regression-triaged The performance regression has been triaged. label Oct 26, 2021
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. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. 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.

8 participants