trans: Treat generics like regular functions, not like #[inline] function, during CGU partitioning #38944
Conversation
…ate. Two crates will often instantiate the same generic functions. Since we don't make any attempt to re-use these instances cross-crate, we would run into symbol conflicts for anything with external linkage. In order to avoid this, this commit makes the compiler incorporate the ID of the instantiating crate into the symbol hash. This way equal generic instances will have different symbols names when used in different crates.
…tions during CGU partitioning.
|
The first commit (Disambiguate generic instance symbol names by instantiating crate) is very unexpected to me. AFAIK, we currently use comdat linkage to resolve these collisions, which also allows the linker to combine identical instantiation from multiple crates. And except for the mingw linker limitations, I'm not aware of any problems with that. Yet this commit seems to be a complete departure from that strategy. Could you elaborate on the rationale for that change? |
Sure. We've actually used COMDAT sections/WeakODR linkage only for a brief period (between April and June, I think) and then switched to internal copies for all generic instances. Internal linkage has allowed us to use the same symbol names everywhere without getting naming conflicts. The main reason for switching was the MinGW issue but also that WeakODR functions would optimize a lot worse in LLVM. For some reason, LLVM doesn't seem to really trust the "one definition rule". I think it's a worthwhile goal to get by without COMDAT sections, just to avoid some complexity. |
|
Interesting! But I still wonder why the current strategy needs to change at all — is this in preparation of trying to reuse instantiations from upstream crates? |
|
No, it's primarily to make incremental compilation more effective. Cross-CGU inlining is very bad for re-usability. |
|
@bors r+ |
|
📌 Commit fc9dfca has been approved by |
| @@ -302,10 +302,13 @@ impl<'a> CrateLoader<'a> { | |||
| crate_root.def_path_table.decode(&metadata) | |||
| }); | |||
|
|
|||
| let exported_symbols = crate_root.exported_symbols.decode(&metadata).collect(); | |||
There was a problem hiding this comment.
Huh, I thought I had removed this... At least it's by DefIndex not by symbol name.
|
⌛ Testing commit fc9dfca with merge ffce217... |
|
💔 Test failed - status-travis |
|
OS/X linker segfault cc #38878 |
|
@bors retry |
|
⌛ Testing commit fc9dfca with merge 29077d1... |
|
💔 Test failed - status-travis |
|
⌛ Testing commit fc9dfca with merge ed8f513... |
|
💔 Test failed - status-travis |
|
@bors: retry
|
…=nikomatsakis trans: Treat generics like regular functions, not like #[inline] function, during CGU partitioning This PR makes generics be treated just like regular functions during CGU partitioning: + the function instantiation is placed in a codegen unit based on the function's DefPath, + unless it is marked with `#[inline]` -- which causes a private copy of the function to be placed in every referencing codegen unit. This has the following effects: + Multi codegen unit builds will become faster because code for generic functions is duplicated less. + Multi codegen unit builds might have lower runtime performance, since generics are not available for inlining automatically any more. + Single codegen unit builds are not affected one way or the other. This partitioning scheme is particularly good for incremental compilation as it drastically reduces the number of false positives during codegen unit invalidation. I'd love to have a benchmark suite for estimating the effect on runtime performance for changes like this one. r? @nikomatsakis cc @rust-lang/compiler
|
☀️ Test successful - status-appveyor, status-travis |
This PR makes generics be treated just like regular functions during CGU partitioning:
#[inline]-- which causes a private copy of the function to be placed in every referencing codegen unit.This has the following effects:
This partitioning scheme is particularly good for incremental compilation as it drastically reduces the number of false positives during codegen unit invalidation.
I'd love to have a benchmark suite for estimating the effect on runtime performance for changes like this one.
r? @nikomatsakis
cc @rust-lang/compiler