[5.0] [Runtime] Cache and unique based on protocol conformance descriptors, not witness tables #20774
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
The conformance cache was caching the witness table for a conformance `T: P`, where `T` is a concrete type and `P` is a protocol. However, it essentially picked one of potentially many witness tables for that conformance, because retroactive conformances might produce different results from different modules. Make the conformance cache what is says it is: a cache of the conformance descriptor for a given `T: P`, potentially filtered by a module (when requested). Clients of the conformance cache can choose how to interpret the protocol conformance descriptor, e.g., by instantiating a witness table. We can bring back a specific conformance cache for swift_conformsToProtocol() if it is profitable. (cherry picked from commit 0af2af00a739a4d912d2a9c3b196449e4164484f) (cherry picked from commit d9bb81b)
…metadata. Metadata uniquing might encounter witness tables that were distinctly generated but come from identical descriptors. Handle this case in metadata uniquing be looking into the protocol conformance descriptors themselves. (cherry picked from commit 32f577a)
Rather than scanning the type descriptor each time we perform a comparison or hash of a metadata cache entry, do so only once to establish the number of key parameters and the number of witness tables. Use those values to more efficiently compare keys. (cherry picked from commit 06807c2)
Rather than scanning through the generic parameters and generic requirements each time we form a key for the generic metadata cache, compute these values once, when the cache itself is first initialized. (cherry picked from commit 3948114)
|
@swift-ci please test |
AnnaZaks
approved these changes
Nov 26, 2018
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.
The conformance cache was caching the witness table for a conformance
T: P, whereTis a concrete type andPis a protocol. However, itessentially picked one of potentially many witness tables for that
conformance, because retroactive conformances might produce different results
from different modules.
Make the conformance cache what is says it is: a cache of the conformance
descriptor for a given
T: P. Clients of the conformance cache can choose how to interpretthe protocol conformance descriptor, e.g., by instantiating a witness table with a
particular set of arguments.
Moreover, unique metadata entries based on conformance descriptors, rather than witness tables.
This is both a correctness fix (when there are multiple, synthesized conformances in multiple modules)
and enables future optimizations (e.g., the use of pre-specialized witness tables).