Allow for re-using monomorphizations in upstream crates. #48779

michaelwoerister · 2018-03-06T13:49:46Z

Followup to #48611. This implementation is pretty much finished modulo failing tests if there are any. Not quite ready for review yet though.

DESCRIPTION

This PR introduces a share-generics mode for RLIBs and Rust dylibs. When a crate is compiled in this mode, two things will happen:

before instantiating a monomorphization in the current crate, the compiler will look for that monomorphization in all upstream crates and link to it, if possible.
monomorphizations are not internalized during partitioning. Instead they are added to the list of symbols exported from the crate.

This results in less code being translated and LLVMed. However, there are also downsides:

it will impede optimization somewhat, since fewer functions can be internalized, and
Rust dylibs will have bigger symbol tables since they'll also export monomorphizations.

Consequently, this PR only enables the shared-generics mode for opt-levels No, Less, Size, and MinSize, and for when incremental compilation is activated. -O2 and -O3 will still generate generic functions per-crate.

Another thing to note is that this has a somewhat similar effect as MIR-only RLIBs, in that monomorphizations are shared, but it is less effective because it cannot share monomorphizations between sibling crates:

         A        <--- defines `fn foo<T>() { .. }`
       /   \
      /     \
     B       C    <--- both call `foo<u32>()`
      \     /
       \   /
         D        <--- calls `foo<u32>()` too

With share-generics, both B and C have to instantiate foo<u32> and only D can re-use it (from either B or C). With MIR-only RLIBs, B and C would not instantiate anything, and in D we would then only instantiate foo<u32> once.
On the other hand, when there are many leaf crates in the graph (e.g. when compiling many individual test binaries) then the share-generics approach will often be more effective.

TODO

Add codegen test that makes sure monomorphizations can be internalized in non-Rust binaries.
Add codegen-units test that makes sure we share generics.
Add run-make test that makes sure we don't export any monomorphizations from non-Rust binaries.
Review for reproducible-builds implications.

rust-highfive · 2018-03-06T13:49:48Z

r? @estebank

(rust_highfive has picked a reviewer for you, use r? to override)

michaelwoerister · 2018-03-06T14:05:35Z

@bors try

bors · 2018-03-06T14:05:45Z

⌛ Trying commit 35c9b1f2f0a365187789fc684cdb5eba9afb81dd with merge 55221f5e2d6d5c71f6b89674eb29f2a213f415ef...

bors · 2018-03-06T16:10:49Z

☀️ Test successful - status-travis
State: approved= try=True

michaelwoerister · 2018-03-06T20:04:21Z

@Mark-Simulacrum, could you do a perf run for this too, please?

Mark-Simulacrum · 2018-03-07T02:35:10Z

Perf queued. Probably about 40-45 minutes until it starts.

michaelwoerister · 2018-03-07T09:06:42Z

Thanks, @Mark-Simulacrum! Here's the link:
http://perf.rust-lang.org/compare.html?start=6f2100b92cb14fbea2102701af6a3ac5814bd06c&end=55221f5e2d6d5c71f6b89674eb29f2a213f415ef&stat=instructions%3Au
(doesn't seem to have run yet though)

michaelwoerister · 2018-03-07T12:07:32Z

@Mark-Simulacrum, the results don't seem to be available yet. Is it still in the queue or has something gone wrong?

Mark-Simulacrum · 2018-03-07T14:11:49Z

Hm, it does look like something went wrong -- I've restarted the build.

michaelwoerister · 2018-03-07T16:33:59Z

Will the link be the same?

Mark-Simulacrum · 2018-03-07T16:53:58Z

Hm, it failed again -- I'm going to try and keep an eye on it and hopefully diagnose why, it also turns out we weren't properly logging the failures for try builds previously so I've now corrected that as well.

Mark-Simulacrum · 2018-03-07T23:41:38Z

URL works now!

michaelwoerister · 2018-03-08T08:59:17Z

Thanks, Mark!

michaelwoerister · 2018-03-08T09:08:49Z

OK, so those numbers look good. I had hoped that they would be even better though. It looks like it's mostly small functions that get re-used. But yeah, -15.9% for tokio-web-push, I'll take it :)

michaelwoerister · 2018-03-08T09:47:02Z

@rust-lang/compiler & @alexcrichton, do you have any objections to pursuing this further? There's a description at the top and performance numbers are here: http://perf.rust-lang.org/compare.html?start=6f2100b92cb14fbea2102701af6a3ac5814bd06c&end=55221f5e2d6d5c71f6b89674eb29f2a213f415ef&stat=instructions%3Au

alexcrichton · 2018-03-08T15:47:34Z

Awesome work here @michaelwoerister! It's pretty neat how it's not to difficult to play around with various schemes like this these days :)

One concern I might have here is the size of binaries but given that this only affects debug mode rather than optimized then I guess it doesn't matter too much? We rely on -ffunction-sections to pretty aggressively prune dead code but if the symbols are all exported then I think even for binaries they'll stick around?

In general though seems like a great idea to me to keep pursuing, any bugs or surprises along the way we can probably smooth over!

For the diamond problem you gisted above, is this what all that "link once ODR" stuff is for in LLVM? I feel like that's all basically intended for optimized binaries linking only one copy rather than for debug mode, so it may not benefit us much if we don't turn this on in optimized mode. Speaking of optimized mode though, we may actually be able to get some nice wins here with available_externally in LLVM. That'd allow optimized mode to inline all the upstream copies but we get to completely skip codegen for them. Perhaps something to pursue down the road!

michaelwoerister · 2018-03-08T16:07:33Z

We rely on -ffunction-sections to pretty aggressively prune dead code but if the symbols are all exported then I think even for binaries they'll stick around?

The monomorphizations are still assigned SymbolExportLevel::Rust, so for executables, cdylibs, and staticlibs, the linker script should hide them. I'll better add a test for that though.

We could look into LinkOnceODR but I remember it causing problems for MingGW. It would only reduce the size of linked artifacts, not compile times though, I think, as we'd still have to translate and optimize twice in the example above. Otoh, it might make symbol naming a bit less complicated.

michaelwoerister · 2018-03-08T16:08:09Z

Also, thanks for the feedback, @alexcrichton! :)

alexcrichton · 2018-03-08T16:10:31Z

Oh right that's true, I'd sort of doubt that LinkOnceODR is portable enough for us to effectively leverage it...

I think that for executables we don't currently pass linker scripts/symbol whitelists, but AFAIK that's because we just never have before. We could likely start now!

michaelwoerister · 2018-03-08T16:19:16Z

I think that for executables we don't currently pass linker scripts/symbol whitelists

OK, I'll make sure we do as part of the PR.

nikomatsakis · 2018-03-08T16:36:14Z

We discussed this in the @rust-lang/compiler meeting today. Everybody felt pretty good about it. It'd be nice to land this and possibly do further experimentation to see if we can enable in optimized builds without hurting perf.

…hare-generics

…upport Rust dylibs.

michaelwoerister · 2018-04-06T12:08:05Z

@bors r=alexcrichton

bors · 2018-04-06T12:08:06Z

📌 Commit 61991a5 has been approved by alexcrichton

bors · 2018-04-06T15:01:34Z

⌛ Testing commit 61991a5 with merge 7678d50...

Allow for re-using monomorphizations in upstream crates. Followup to #48611. This implementation is pretty much finished modulo failing tests if there are any. Not quite ready for review yet though. ### DESCRIPTION This PR introduces a `share-generics` mode for RLIBs and Rust dylibs. When a crate is compiled in this mode, two things will happen: - before instantiating a monomorphization in the current crate, the compiler will look for that monomorphization in all upstream crates and link to it, if possible. - monomorphizations are not internalized during partitioning. Instead they are added to the list of symbols exported from the crate. This results in less code being translated and LLVMed. However, there are also downsides: - it will impede optimization somewhat, since fewer functions can be internalized, and - Rust dylibs will have bigger symbol tables since they'll also export monomorphizations. Consequently, this PR only enables the `shared-generics` mode for opt-levels `No`, `Less`, `Size`, and `MinSize`, and for when incremental compilation is activated. `-O2` and `-O3` will still generate generic functions per-crate. Another thing to note is that this has a somewhat similar effect as MIR-only RLIBs, in that monomorphizations are shared, but it is less effective because it cannot share monomorphizations between sibling crates: ``` A <--- defines `fn foo<T>() { .. }` / \ / \ B C <--- both call `foo<u32>()` \ / \ / D <--- calls `foo<u32>()` too ``` With `share-generics`, both `B` and `C` have to instantiate `foo<u32>` and only `D` can re-use it (from either `B` or `C`). With MIR-only RLIBs, `B` and `C` would not instantiate anything, and in `D` we would then only instantiate `foo<u32>` once. On the other hand, when there are many leaf crates in the graph (e.g. when compiling many individual test binaries) then the `share-generics` approach will often be more effective. ### TODO - [x] Add codegen test that makes sure monomorphizations can be internalized in non-Rust binaries. - [x] Add codegen-units test that makes sure we share generics. - [x] Add run-make test that makes sure we don't export any monomorphizations from non-Rust binaries. - [x] Review for reproducible-builds implications.

bors · 2018-04-06T17:38:37Z

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 7678d50 to master...

eddyb · 2019-04-11T06:49:26Z

src/librustc_metadata/schema.rs

@@ -531,3 +530,9 @@ impl_stable_hash_for!(struct GeneratorData<'tcx> { layout });
 // Tags used for encoding Spans:
 pub const TAG_VALID_SPAN: u8 = 0;
 pub const TAG_INVALID_SPAN: u8 = 1;
+
+#[derive(RustcEncodable, RustcDecodable)]
+pub struct EncodedExportedSymbols {


This should have a comment on it, that it's used to avoid adding a 'tcx parameter to CrateRoot (which I'm not even sure is a problem, if covariant, we'd just store it as 'static).

rust-highfive assigned estebank Mar 6, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 6, 2018

michaelwoerister unassigned estebank Mar 6, 2018

michaelwoerister force-pushed the share-generics4 branch from 9a1af56 to 710e4d6 Compare March 7, 2018 12:57

michaelwoerister mentioned this pull request Mar 8, 2018

Compiler Performance Tracking Issue #48547

Open

michaelwoerister force-pushed the share-generics4 branch 2 times, most recently from be1e8f6 to d4264dc Compare March 13, 2018 13:50

michaelwoerister changed the title ~~WIP: Allow for re-using monomorphizations in upstream crates.~~ Allow for re-using monomorphizations in upstream crates. Mar 13, 2018

michaelwoerister added 14 commits April 6, 2018 12:14

Move export level computation to reachable_non_generics query.

435477d

Allow for re-using monomorphizations from upstream crates.

4f6d05d

Make generics sharing the default for non-optimized builds.

8d95c86

Remove the (inaccurate) symbol_export_level query.

e203b3a

Allow for internalizing monomorphizations that cannot be shared.

9b90674

Adapt codegen-unit test to shared-generics.

5316a45

Select upstream monomorphizations in a stable way.

213ef11

Fix some rebasing fallout.

a1a986c

Don't internalize generics that are re-exported

2d2cf03

Make sure that generics are internalized in executables even with -Zs…

94d36cf

…hare-generics

Add codegen-units test for shared-generics.

69c7f5c

Update a few comments about symbol visibility.

ec55390

Allow for re-using hidden monomorphizations on platforms that don't s…

07704a4

…upport Rust dylibs.

Update run-make/symbol-visibility to also cover shared-generics

61991a5

michaelwoerister force-pushed the share-generics4 branch from 679ba55 to 61991a5 Compare April 6, 2018 10:14

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 6, 2018

bors merged commit 61991a5 into rust-lang:master Apr 6, 2018

bors mentioned this pull request Apr 6, 2018

Introduce RangeInclusive::{new, start, end} methods and make the fields private. #49724

Merged

hanna-kruppe mentioned this pull request Jul 25, 2018

Make Vec derefing inlinable #52704

Closed

michaelwoerister mentioned this pull request Apr 2, 2019

Experiment with sharing monomorphized code between crates #47317

Closed

eddyb reviewed Apr 11, 2019

View reviewed changes

ehuss mentioned this pull request Sep 9, 2019

Using profile-overrides results in both optimized and unoptimized versions of the same crate in linked executable #63484

Closed

alessandrod mentioned this pull request Feb 11, 2022

Reduce compiled program sizes by reducing serialization bloat solana-labs/solana#23075

Closed

EFanZh mentioned this pull request Jul 17, 2023

Binary size optimization experiment rust-lang/log#569

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow for re-using monomorphizations in upstream crates. #48779

Allow for re-using monomorphizations in upstream crates. #48779

michaelwoerister commented Mar 6, 2018 •

edited

Loading

rust-highfive commented Mar 6, 2018

michaelwoerister commented Mar 6, 2018

bors commented Mar 6, 2018

bors commented Mar 6, 2018

michaelwoerister commented Mar 6, 2018

Mark-Simulacrum commented Mar 7, 2018

michaelwoerister commented Mar 7, 2018

michaelwoerister commented Mar 7, 2018

Mark-Simulacrum commented Mar 7, 2018

michaelwoerister commented Mar 7, 2018

Mark-Simulacrum commented Mar 7, 2018

Mark-Simulacrum commented Mar 7, 2018

michaelwoerister commented Mar 8, 2018

michaelwoerister commented Mar 8, 2018

michaelwoerister commented Mar 8, 2018

alexcrichton commented Mar 8, 2018

michaelwoerister commented Mar 8, 2018

michaelwoerister commented Mar 8, 2018

alexcrichton commented Mar 8, 2018

michaelwoerister commented Mar 8, 2018

nikomatsakis commented Mar 8, 2018

michaelwoerister commented Apr 6, 2018

bors commented Apr 6, 2018

bors commented Apr 6, 2018

bors commented Apr 6, 2018

eddyb Apr 11, 2019

Allow for re-using monomorphizations in upstream crates. #48779

Allow for re-using monomorphizations in upstream crates. #48779

Conversation

michaelwoerister commented Mar 6, 2018 • edited Loading

DESCRIPTION

TODO

rust-highfive commented Mar 6, 2018

michaelwoerister commented Mar 6, 2018

bors commented Mar 6, 2018

bors commented Mar 6, 2018

michaelwoerister commented Mar 6, 2018

Mark-Simulacrum commented Mar 7, 2018

michaelwoerister commented Mar 7, 2018

michaelwoerister commented Mar 7, 2018

Mark-Simulacrum commented Mar 7, 2018

michaelwoerister commented Mar 7, 2018

Mark-Simulacrum commented Mar 7, 2018

Mark-Simulacrum commented Mar 7, 2018

michaelwoerister commented Mar 8, 2018

michaelwoerister commented Mar 8, 2018

michaelwoerister commented Mar 8, 2018

alexcrichton commented Mar 8, 2018

michaelwoerister commented Mar 8, 2018

michaelwoerister commented Mar 8, 2018

alexcrichton commented Mar 8, 2018

michaelwoerister commented Mar 8, 2018

nikomatsakis commented Mar 8, 2018

michaelwoerister commented Apr 6, 2018

bors commented Apr 6, 2018

bors commented Apr 6, 2018

bors commented Apr 6, 2018

eddyb Apr 11, 2019

Choose a reason for hiding this comment

michaelwoerister commented Mar 6, 2018 •

edited

Loading