incr.comp.: Don't automatically enable -Zshare-generics for incr. comp. builds. #54557
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rust-highfive
added
the
S-waiting-on-review
|
@bors: r+ |
|
📌 Commit 8fc7b5d has been approved by |
bors
added
S-waiting-on-bors
pietroalbini
added a commit
to pietroalbini/rust
that referenced
this pull request
Sep 25, 2018
…nerics-for-incr-comp, r=alexcrichton incr.comp.: Don't automatically enable -Zshare-generics for incr. comp. builds. So far the compiler would automatically enable sharing of monomorphizations for incremental builds. That was OK because without (Thin)LTO this could have very little impact on the runtime performance of the generated code. However, since rust-lang#53673, ThinLTO and incr. comp. can be combined, so the trade-off is not as clear anymore. This PR removes the automatic tie between the two options. Whether monomorphizations are shared between crates or not now _only_ depends on the optimization level. r? @alexcrichton
bors
added a commit
that referenced
this pull request
Sep 25, 2018
Rollup of 12 pull requests Successful merges: - #53518 (Add doc for impl From in char_convert) - #54058 (Introduce the partition_dedup/by/by_key methods for slices) - #54281 (Search box) - #54368 (Reduce code block sides padding) - #54498 (The project moved under the Mozilla umbrella) - #54518 (resolve: Do not block derive helper resolutions on single import resolutions) - #54522 (Fixed three small typos.) - #54529 (aarch64-pc-windows-msvc: Don't link libpanic_unwind to libtest.) - #54537 (Rename slice::exact_chunks() to slice::chunks_exact()) - #54539 (Fix js error) - #54557 (incr.comp.: Don't automatically enable -Zshare-generics for incr. comp. builds.) - #54558 (Improvements to finding LLVM's FileCheck) Failed merges: r? @ghost
|
Nominating for a beta-backport. This is one of the reasons why bootstrapping with |
michaelwoerister
added
beta-nominated
|
Seems like a risk-free patch. Approving for backport ahead of meeting to save time. |
pnkfelix
added
the
beta-accepted
pietroalbini
removed
the
beta-nominated
bors
added a commit
that referenced
this pull request
Oct 4, 2018
[beta] Rollup backports Merged and approved: * #54605: resolve: Disambiguate a subset of conflicts "macro_rules" vs "macro name in module" * #54557: incr.comp.: Don't automatically enable -Zshare-generics for incr. comp. builds. * #54759: do not normalize non-scalar constants to a ConstValue::ScalarPair Closes #54759 r? @ghost
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So far the compiler would automatically enable sharing of monomorphizations for incremental builds. That was OK because without (Thin)LTO this could have very little impact on the runtime performance of the generated code. However, since #53673, ThinLTO and incr. comp. can be combined, so the trade-off is not as clear anymore.
This PR removes the automatic tie between the two options. Whether monomorphizations are shared between crates or not now only depends on the optimization level.
r? @alexcrichton