Add real ThinLTO mode #3489
Draft
Add real ThinLTO mode #3489
+162
−46
Conversation
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
6 tasks
aykevl
force-pushed
the
builder-real-thinlto
branch
2 times, most recently
from
c3a5e87 to
0a531e2
Compare
Create it in a separate LLVM module that is then linked. This refactor is useful for the -lto=thin build mode. I checked the binary size difference and while the machine code of most binaries did change, there was no change in binary size (except for one smoke test with -opt=1, which doesn't really count).
I found that with `-lto=thin` and by setting the llvm.ident metadata, source level debugging finally works on MacOS! The downside is of course that it requires `-lto=thin`, which is barely supported.
We use ThinLTO for linking, but we use it in a way that doesn't give most of its benefits: we merge all the bitcode files into a single LLVM module and run some optimizations on it before linking. Therefore, this works more like a traditional "full" LTO link rather than a true thin link. This commit adds a new experimental -lto=thin option to do a true ThinLTO link. The main benefit is that linking will be a lot faster, especially for large programs consisting of many packages. At the moment, it only works for programs that don't do interface type asserts and don't call interface methods. It also probably won't work on WebAssembly and baremetal systems. But it's part of a larger goal towards a truly incremental build system: #2870 Once interface type asserts and method calls are converted to a vtable-like implementation, most programs should just work on linux/darwin/windows.
aykevl
force-pushed
the
builder-real-thinlto
branch
from
0a531e2 to
2de0635
Compare
|
@dgryski this also includes a small patch that finally enables source-level debugging on MacOS:
(This only works with |
This was referenced Feb 26, 2023
|
Seems like some actual build problems on this @aykevl please take a look. |
|
@deadprogram yeah I saw it. Frustratingly, I can't reproduce the MacOS issue locally. To fix both issues (Windows and MacOS), I think I need to do the interface refactor first. |
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.
We use ThinLTO for linking, but we use it in a way that doesn't give most of its benefits: we merge all the bitcode files into a single LLVM module and run some optimizations on it before linking. Therefore, this works more like a traditional "full" LTO link rather than a true thin link.
This PR adds a new experimental
-lto=thinoption to do a true ThinLTO link. The main benefit is that linking will be a lot faster especially for large programs consisting of many packages.At the moment, it only works for programs that don't do interface type asserts and don't call interface methods. It also probably won't work on WebAssembly and baremetal systems. But it's part of a larger goal towards a truly incremental build system: #2870
Once interface type asserts and method calls are converted to a vtable-like implementation, most programs should just work on linux/darwin/windows.