[5.7] Pre-specialization fixes cherry-picks #58826
Merged
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
This is a cherry-pick of PR#58642 PR#58687 PR#58701 PR#58723 PR#58760 PR#58642 Eager specializer: Fix pre-specialization of imported code We must no pre-specialize imported code (except if this was explicitly called for by the importing module). Therefore, don't pre-specialize `shared` definitions based on their pre-specialization attributes. Rather, only pre-specialize if the pre-specialization is called for using a `target: "theFunctionToSpecialize"` parameter. Run OnonePrespecializations before serialization so that module native functions are not yet marked `shared` and can be identified as native. rdar://92337361 PR#58687 CrossModuleOptimization: Don't serialize pre-specialized public entry points We should continue to use the public pre-specialized entry point from another module. But not block other uses of generic specializations. PR#58701 SILFunctionBuilder: Don't create [serialized] function post serialization This might fix the randomly occuring errors of: ``` SIL verification failed: cannot have a serialized function after the module has been serialized: !F->isSerialized() || !mod.isSerialized() || mod.isParsedAsSerializedSIL() ``` PR#58723 GenericSpecialization: Move once initialization of pre-specializations earlier before the first query for pre-specialziations PR#58760 swiftinterface: print _specialize functions with targetFunction parameter in .swiftinterface If we have an internal function with a `_specialize` attribute that has a `targetFunction:` parameter we want the function to appear in the .swiftinterface file such that the exported specialization can be picked up by the compiler.
|
@swift-ci test |
1 similar comment
|
@swift-ci test |
tbkka
approved these changes
Jun 1, 2022
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.
This is a cherry-pick of
PR #58642
PR #58687
PR #58701
PR #58723
PR #58760
PR#58642 Eager specializer: Fix pre-specialization of imported code
We must no pre-specialize imported code (except if this was explicitly
called for by the importing module).
Therefore, don't pre-specialize
shareddefinitions based on theirpre-specialization attributes.
Rather, only pre-specialize if the pre-specialization is called for
using a
target: "theFunctionToSpecialize"parameter.Run OnonePrespecializations before serialization so that module native functions
are not yet marked
sharedand can be identified as native.rdar://92337361
PR#58687 CrossModuleOptimization: Don't serialize pre-specialized public entry points
We should continue to use the public pre-specialized entry point from another module. But not block other uses of generic specializations.
PR#58701 SILFunctionBuilder: Don't create [serialized] function post serialization
This might fix the randomly occuring errors of:
PR#58723 GenericSpecialization: Move once initialization of pre-specializations earlier before the first query for pre-specialziations
PR#58760 swiftinterface: print _specialize functions with targetFunction parameter in .swiftinterface
If we have an internal function with a
_specializeattribute that hasa
targetFunction:parameter we want the function to appear in the.swiftinterface file such that the exported specialization can be picked up by
the compiler.