generator/linux: Use the Swift 6.0 toolchain's lld #159
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
After Swift 6.0 the swift.org toolchain includes LLD, so it is not
necessary to install it separately from an LLVM archive. The LLD
provided by the swift.org toolchain is also a multiarch binary, so
the SDK will run on both x86_64 and aarch64 macOS hosts.
This change slightly reduces the size of a Swift 6.0 SDK because
currently these SDKs include two copies of LLD - one from the SDK
and one from LLVM. This is because LLD is typically installed as
a single binary with multiple symlinks pointing to it representing
different 'personalities' such as `ld.lld`, `wasm-ld` and so on. SDK
generator copies the `lld` binary in as `ld.lld`, overwriting one of
the symlinks:
-rwxr-xr-x 1 euanh staff 108M 14 Nov 2023 ld.lld
lrwxr-xr-x 1 euanh staff 3B 24 Oct 15:11 ld64.lld -> lld
-rwxr-xr-x 1 euanh staff 265M 24 Oct 19:28 lld
lrwxr-xr-x 1 euanh staff 3B 24 Oct 15:11 lld-link -> lld
lrwxr-xr-x 1 euanh staff 3B 24 Oct 15:11 wasm-ld -> lld
After this PR, we only have one copy of the `lld` binary:
lrwxr-xr-x 1 euanh staff 3B 24 Oct 15:11 ld.lld -> lld
lrwxr-xr-x 1 euanh staff 3B 24 Oct 15:11 ld64.lld -> lld
-rwxr-xr-x 1 euanh staff 265M 24 Oct 19:28 lld
lrwxr-xr-x 1 euanh staff 3B 24 Oct 15:11 lld-link -> lld
lrwxr-xr-x 1 euanh staff 3B 24 Oct 15:11 wasm-ld -> lld
This change does not significantly change the time to build a new
SDK with a warm cache (PR swiftlang#149), however the very first build with
a cold cache improves considerably because the LLVM archive does
not need to be downloaded and unpacked.
For example, two tests run one after the other on an M3 MacBook Air
with a fast network connection:
rm -rf Artifacts Bundles
swift run swift-sdk-generator make-linux-sdk --swift-version 6.0.2-RELEASE
`main`: 1m21s, (2.9GB in `Artifacts` directory)
this PR: 39s, (2.1GB in `Artifacts` directory)
|
@swift-ci test |
MaxDesiatov
approved these changes
Nov 28, 2024
The (I ran them before submitting but I'd lost the contents of the terminal. This is a fresh run.) |
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.
After Swift 6.0 the swift.org toolchain includes LLD, so it is not
necessary to install it separately from an LLVM archive. The LLD
provided by the swift.org toolchain is also a multiarch binary, so
the SDK will run on both x86_64 and aarch64 macOS hosts.
This change slightly reduces the size of a Swift 6.0 SDK because
currently these SDKs include two copies of LLD - one from the SDK
and one from LLVM. This is because LLD is typically installed as
a single binary with multiple symlinks pointing to it representing
different 'personalities' such as
ld.lld,wasm-ldand so on. SDKgenerator copies the
lldbinary in asld.lld, overwriting one ofthe symlinks:
After this PR, we only have one copy of the
lldbinary:This change does not significantly change the time to build a new
SDK with a warm cache (PR #149), however the very first build with
a cold cache improves considerably because the LLVM archive does
not need to be downloaded and unpacked.
For example, two tests run one after the other on an M3 MacBook Air
with a fast network connection:
main: 1m21s, (2.9GB inArtifactsdirectory)this PR: 39s, (2.1GB in
Artifactsdirectory)