-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Mandatory SIL linker pass #15930
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
Merged
slavapestov
merged 4 commits into
swiftlang:master
from
slavapestov:mandatory-sil-linker-pass
Apr 14, 2018
Merged
Mandatory SIL linker pass #15930
slavapestov
merged 4 commits into
swiftlang:master
from
slavapestov:mandatory-sil-linker-pass
Apr 14, 2018
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
As a first step to getting mandatory inlining out of the business of 'linking' (walking the function graph and deserializing all referenced functions), add a new optimizer pass which links everything in the mandatory pipeline. For now this is mostly NFC, except it regresses an optimization I made recently by linking in bodies of methods of deserialized vtables eagerly. This will be addressed in upcoming patches.
PublicNonABI function declarations deserialize as HiddenExternal, then become SharedExternal after the body has been deserialized. So try deserializing HiddenExternal too. NFC until mandatory inlining is no longer eagerly deserializing.
Transparent function bodies are in fact available externally.
We only need to deserialize the function itself, not its transitive dependencies. Also, only deserialize a function after we've checked that its transparent. For now, this doesn't reduce the volume of SIL linking, because the mandatory linker pass still links everything. But we're almost there.
@swift-ci Please smoke test |
@swift-ci Please smoke benchmark |
Build comment file:Optimized (O)Regression (7)
Improvement (6)
No Changes (409)
Unoptimized (Onone)Regression (19)
Improvement (15)
No Changes (388)
Hardware Overview
|
This was referenced Apr 14, 2018
gottesmm
reviewed
Apr 16, 2018
if (CalleeFunction->empty()) { | ||
// FIXME: Remove 'Mode' | ||
if (Mode != SILOptions::LinkingMode::LinkNone) | ||
AI.getModule().loadFunction(CalleeFunction); |
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 this function has the wrong name. Imagine a naive reader... what is the difference in between loadFunction and linkFunction without reading comments... they seem the same to me.
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.
Perform "linking" (transitive deserialization) in a separate mandatory pass from mandatory inlining. Mandatory inlining only has to deserialize transparent functions now. Mostly NFC because the mandatory linking is still too eager to deserialize everything; I'm bisecting #15894 to make sure I'm not regressing performance.