Uh oh!
There was an error while loading. Please reload this page.
bootstrap: Link LLVM as a dylib with ThinLTO (take 2) - #57286
Merged
Conversation
When building a distributed compiler on Linux where we use ThinLTO to create the LLVM shared object this commit switches the compiler to dynamically linking that LLVM artifact instead of statically linking to LLVM. The primary goal here is to reduce CI compile times, avoiding two+ ThinLTO builds of all of LLVM. By linking dynamically to LLVM we'll reuse the one ThinLTO step done by LLVM's build itself. Lots of discussion about this change can be found [here] and down. A perf run will show whether this is worth it or not! [here]: rust-lang#53245 (comment)
It's only meant for rustc, so we should only install it once!
rust-highfive
commented
Jan 2, 2019
Contributor
(rust_highfive has picked a reviewer for you, use r? to override) |
Merged
nikomatsakis
commented
Jan 3, 2019
Contributor
@bors r+ |
bors
commented
Jan 3, 2019
Collaborator
📌 Commit 71fed3a has been approved by |
Mark-Simulacrum added a commit
to Mark-Simulacrum/rust
that referenced
this pull request
Jan 3, 2019
…atsakis bootstrap: Link LLVM as a dylib with ThinLTO (take 2) When building a distributed compiler on Linux where we use ThinLTO to create the LLVM shared object this commit switches the compiler to dynamically linking that LLVM artifact instead of statically linking to LLVM. The primary goal here is to reduce CI compile times, avoiding two+ ThinLTO builds of all of LLVM. By linking dynamically to LLVM we'll reuse the one ThinLTO step done by LLVM's build itself. Lots of discussion about this change can be found [here] and down. A perf run will show whether this is worth it or not! [here]: rust-lang#53245 (comment) --- This PR previously landed in rust-lang#56944, caused rust-lang#57111, and was reverted in rust-lang#57116. I've added one more commit here which should fix the breakage that we saw.
bors
commented
Jan 6, 2019
Collaborator
bors added a commit
that referenced
this pull request
Jan 6, 2019
bootstrap: Link LLVM as a dylib with ThinLTO (take 2) When building a distributed compiler on Linux where we use ThinLTO to create the LLVM shared object this commit switches the compiler to dynamically linking that LLVM artifact instead of statically linking to LLVM. The primary goal here is to reduce CI compile times, avoiding two+ ThinLTO builds of all of LLVM. By linking dynamically to LLVM we'll reuse the one ThinLTO step done by LLVM's build itself. Lots of discussion about this change can be found [here] and down. A perf run will show whether this is worth it or not! [here]: #53245 (comment) --- This PR previously landed in #56944, caused #57111, and was reverted in #57116. I've added one more commit here which should fix the breakage that we saw.
bors
commented
Jan 6, 2019
Collaborator
☀️ Test successful - status-appveyor, status-travis |
alexcrichton added a commit
to alexcrichton/rust
that referenced
this pull request
Jan 7, 2019
This commit is intended on fixing a regression from rust-lang#57286 where the distributed LLVM shared library unfortunately depends on a dynamic copy of libstdc++, meaning we're no longer as binary compatible as we thought! This tweaks the build of LLVM as out distribution is slightly different now, and is hoped to fix the issue. Closesrust-lang#57426
bors added a commit
that referenced
this pull request
Jan 7, 2019
Build LLVM with -static-libstdc++ on dist builds This commit is intended on fixing a regression from #57286 where the distributed LLVM shared library unfortunately depends on a dynamic copy of libstdc++, meaning we're no longer as binary compatible as we thought! This tweaks the build of LLVM as out distribution is slightly different now, and is hoped to fix the issue. Closes#57426
alexcrichton added a commit
to alexcrichton/rust
that referenced
this pull request
Jan 8, 2019
This commit is intended on fixing a regression from rust-lang#57286 where the distributed LLVM shared library unfortunately depends on a dynamic copy of libstdc++, meaning we're no longer as binary compatible as we thought! This tweaks the build of LLVM as out distribution is slightly different now, and is hoped to fix the issue. Closesrust-lang#57426
alexcrichton added a commit
to alexcrichton/rust
that referenced
this pull request
Jan 8, 2019
This commit is intended on fixing a regression from rust-lang#57286 where the distributed LLVM shared library unfortunately depends on a dynamic copy of libstdc++, meaning we're no longer as binary compatible as we thought! This tweaks the build of LLVM as out distribution is slightly different now, and is hoped to fix the issue. Closesrust-lang#57426
bors added a commit
that referenced
this pull request
Jan 8, 2019
Build LLVM with -static-libstdc++ on dist builds This commit is intended on fixing a regression from #57286 where the distributed LLVM shared library unfortunately depends on a dynamic copy of libstdc++, meaning we're no longer as binary compatible as we thought! This tweaks the build of LLVM as out distribution is slightly different now, and is hoped to fix the issue. Closes#57426
tmandry
commented
Nov 27, 2019
Member
@alexcrichton was there ever a perf run to see the impact on compiler performance? I ask because we've seen as much as a 10-20% improvement from linking LLVM statically to clang. (cc @petrhosek) I expect that something that large would have been noticed in the release perf run, but maybe there is a potential win here (at least, for someone who wants to build their own toolchain). |
petrhosek
commented
Nov 27, 2019
Contributor
Would it be possible to provide an option to statically link LLVM even when using ThinLTO? I understand that you may not want to do this because of your CI resource constraints, but in our case it's something we would always want to use since CI resources aren't a problem. |
alexcrichton
commented
Dec 2, 2019
MemberAuthor
@tmandry hm this is long enough ago I don't quite remember, but might be good to check and see! The main motivation for this was CI time though, since statically linking LLVM to rustc means running all of LLVM through ThinLTO twice, once for it's own dylib and once for rustc, which can be extremely expensive on CI. @petrhosek yeah definitely, we should definitely support this! We may already given various matrices of configuration options, but if not a PR to add one sounds great. |
This file contains hidden or 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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
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.
When building a distributed compiler on Linux where we use ThinLTO to
create the LLVM shared object this commit switches the compiler to
dynamically linking that LLVM artifact instead of statically linking to
LLVM. The primary goal here is to reduce CI compile times, avoiding two+
ThinLTO builds of all of LLVM. By linking dynamically to LLVM we'll
reuse the one ThinLTO step done by LLVM's build itself.
Lots of discussion about this change can be found here and down. A
perf run will show whether this is worth it or not!
This PR previously landed in #56944, caused #57111, and was reverted in #57116. I've added one more commit here which should fix the breakage that we saw.