-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Link std
statically in rustc_driver
#122362
Conversation
This comment has been minimized.
This comment has been minimized.
d3ef302
to
9506132
Compare
why can't this be done in Will this PR require all custom drivers (including our tools) to use |
does this mean that external tools using rustc driver now also need to use this flag? would be nice if the duplicate std error message mentioned that. |
This comment has been minimized.
This comment has been minimized.
The global allocator must be statically linked with
I made the |
This could probably use a perf run as there could be some ThinLTO interactions. |
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Link `std` statically in `rustc_driver` This makes `rustc_driver` statically link to `std`. This is done by not passing `-C prefer-dynamic` when building `rustc_driver`. However building `rustc-main` won't work currently as it tries to dynamically link to both `rustc_driver` and `std` resulting in a crate graph with `std` duplicated. To fix that new command line option `-Z prefer_deps_of_dynamic` is added which prevents linking to a dylib if there's a static variant of it already statically linked into another dylib dependency. The main motivation for this change is to enable `#[global_allocator]` to be used in `rustc_driver` allowing overriding the allocator used in rustc on all platforms.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Use `mimalloc` as `global_allocator` for `rustc_driver` This changes the Rust global allocator for `rustc_driver` to `mimalloc`, leaving LLVM unaffected. Based on rust-lang#122362.
Finished benchmarking commit (380a85b): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 672.448s -> 671.639s (-0.12%) |
} | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of all this interspersed logic would it be possible to at the end iterate over all dylibs and mark all crates they have linked into them as IncludedFromDylib
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if that's correct. The current logic starts by picking the dylibs then adding other crates as needed. That seems less likely to end up with missing crates than removing them after.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My suggestion is not to remove crates, but to change their linkage to IncludeFromDylib after it has determined which crates to include.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what I mean by remove as IncludeFromDylib
won't be linked to the crate. It also won't work with the current duplicate crate detection as that happens as the crates are added.
@@ -1810,6 +1810,8 @@ options! { | |||
"use a more precise version of drop elaboration for matches on enums (default: yes). \ | |||
This results in better codegen, but has caused miscompilations on some tier 2 platforms. \ | |||
See #77382 and #74551."), | |||
prefer_deps_of_dynamic: bool = (false, parse_bool, [TRACKED], | |||
"prefer linking to static dependencies of dynamic libraries over available dynamic libraries (default: no)"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it works robustly, I feel like this should be unconditionally enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, but I'm not confident in there being no regressions. We don't really have many dylib and multi crate type tests.
let can_be_rustc_dep = filename.starts_with("rustc_driver-") | ||
|| filename.starts_with("librustc_driver-") | ||
|| build_compiler.stage == 0; | ||
if can_be_rustc_dep |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this extra logic needed for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's to prevent the std
dynamic library from also being included with the compiler, as it's no longer needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds like it'd be worth a comment in the code. (That's probably true most times a reviewer had a question that was answered by a clarification without code change.)
@@ -2028,10 +2028,16 @@ impl<'a> Builder<'a> { | |||
// When we build Rust dylibs they're all intended for intermediate | |||
// usage, so make sure we pass the -Cprefer-dynamic flag instead of | |||
// linking all deps statically into the dylib. | |||
if matches!(mode, Mode::Std | Mode::Rustc) { | |||
if matches!(mode, Mode::Std) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you will need to add Mode::Codegen
here as -Cprefer-dynamic
is no longer implied when linking librustc_driver.so
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how there's any change to -C prefer-dynamic
for other crates?
This doesn't need to block this PR, but we should probably either ignore or modify these failing tests in the dist builders that run tests. It's wasteful to ship a 12 MiB file in our dist artifacts that is unused. |
…obk,lqd,bjorn3,Kobzol Link `std` statically in `rustc_driver` This makes `rustc_driver` statically link to `std`. This is done by not passing `-C prefer-dynamic` when building `rustc_driver`. However building `rustc-main` won't work currently as it tries to dynamically link to both `rustc_driver` and `std` resulting in a crate graph with `std` duplicated. To fix that new command line option `-Z prefer_deps_of_dynamic` is added which prevents linking to a dylib if there's a static variant of it already statically linked into another dylib dependency. The main motivation for this change is to enable `#[global_allocator]` to be used in `rustc_driver` allowing overriding the allocator used in rustc on all platforms. --- Instead of adding `-Z prefer_deps_of_dynamic`, this PR is changed to crate opt-in to the linking change via the `rustc_private` feature instead, as that would be typically needed to link to `rustc_driver` anyway. --- try-job: aarch64-apple try-job: x86_64-msvc try-job: i686-mingw try-job: dist-x86_64-msvc try-job: aarch64-gnu
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
Lol. @bors retry |
☀️ Test successful - checks-actions |
🎉 |
Finished benchmarking commit (9cb1998): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary 1.8%, secondary 1.8%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -1.1%, secondary -2.4%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 758.668s -> 756.29s (-0.31%) |
Now we need `#![feature(rustc_private)]` in the `main.rs` See the original PR rust-lang/rust#122362 And the PR in another tool that requires the same change trailofbits/dylint#1298 Update lock file too
…, r=onur-ozkan Do not copy libstd dynamic library to sysroot Since rust-lang#122362, rustc links statically to libstd.[so|dll]. Which means that the libstd.[so|dll] file no longer has to be in the rustc sysroot. However, we are currently still shipping this file, in every new release of Rust, for no reason, it's just wasted bytes. This PR removes the dynamic library file from the built sysroot. However, it is not yet performed on Windows, because stage0 incremental tests start failing there (see description of the issue [here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Failing.20incr.20tests.20on.20Windows.20when.20std.2Edll.20is.20missing/near/474507064)). This is an extended version of rust-lang#128986. CC `@Zoxc`
…ozkan Do not copy libstd dynamic library to sysroot Since rust-lang/rust#122362, rustc links statically to libstd.[so|dll]. Which means that the libstd.[so|dll] file no longer has to be in the rustc sysroot. However, we are currently still shipping this file, in every new release of Rust, for no reason, it's just wasted bytes. This PR removes the dynamic library file from the built sysroot. However, it is not yet performed on Windows, because stage0 incremental tests start failing there (see description of the issue [here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Failing.20incr.20tests.20on.20Windows.20when.20std.2Edll.20is.20missing/near/474507064)). This is an extended version of rust-lang/rust#128986. CC `@Zoxc`
This seems to have broken the |
This makes
rustc_driver
statically link tostd
. This is done by not passing-C prefer-dynamic
when buildingrustc_driver
. However buildingrustc-main
won't work currently as it tries to dynamically link to bothrustc_driver
andstd
resulting in a crate graph withstd
duplicated. To fix that new command line option-Z prefer_deps_of_dynamic
is added which prevents linking to a dylib if there's a static variant of it already statically linked into another dylib dependency.The main motivation for this change is to enable
#[global_allocator]
to be used inrustc_driver
allowing overriding the allocator used in rustc on all platforms.Instead of adding
-Z prefer_deps_of_dynamic
, this PR is changed to crate opt-in to the linking change via therustc_private
feature instead, as that would be typically needed to link torustc_driver
anyway.try-job: aarch64-apple
try-job: x86_64-msvc
try-job: i686-mingw
try-job: dist-x86_64-msvc
try-job: aarch64-gnu