[6.2][AutoDiff] Support custom derivatives for @_alwaysEmitIntoClient funcs #85291
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
…tions (swiftlang#78908) Consider an `@_alwaysEmitIntoClient` function and a custom derivative defined for it. Previously, such a combination resulted different errors under different circumstances. Sometimes, there were linker errors due to missing derivative function symbol - these occurred when we tried to find the derivative in a module, while it should have been emitted into client's code (and it did not happen). Sometimes, there were SIL verification failures like this: ``` SIL verification failed: internal/private function cannot be serialized or serializable: !F->isAnySerialized() || embedded ``` Linkage and serialization options for the derivative were not handled properly, and, instead of PublicNonABI linkage, we had Private one which is unsupported for serialization - but we need to serialize `@_alwaysEmitIntoClient` functions so the client's code is able to see them. This patch resolves the issue and adds proper handling of custom derivatives of `@_alwaysEmitIntoClient` functions. Note that either both the function and its custom derivative or none of them should have `@_alwaysEmitIntoClient` attribute, mismatch in this attribute is not supported. The following cases are handled (assume that in each case client's code uses the derivative). 1. Both the function and its derivative are defined in a single file in one module. 2. Both the function and its derivative are defined in different files which are compiled to a single module. 3. The function is defined in one module, its derivative is defined in another module. 4. The function and the derivative are defined as members of a protocol extension in two separate modules - one for the function and one for the derivative. A struct conforming the protocol is defined in the third module. 5. The function and the derivative are defined as members of a struct extension in two separate modules - one for the function and one for the derivative. The changes allow to define derivatives for methods of `SIMD`. Fixes swiftlang#54445
|
Tagging @JaapWijnen |
|
|
@swift-ci please test |
kovdan01
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Consider an
@_alwaysEmitIntoClientfunction and a custom derivative definedfor it. Previously, such a combination resulted different errors under different
circumstances.
Sometimes, there were linker errors due to missing derivative function symbol -
these occurred when we tried to find the derivative in a module, while it
should have been emitted into client's code (and it did not happen).
Sometimes, there were SIL verification failures like this:
Linkage and serialization options for the derivative were not handled properly,
and, instead of PublicNonABI linkage, we had Private one which is unsupported
for serialization - but we need to serialize
@_alwaysEmitIntoClientfunctionsso the client's code is able to see them.
This patch resolves the issue and adds proper handling of custom derivatives
of
@_alwaysEmitIntoClientfunctions. Note that either both the function andits custom derivative or none of them should have
@_alwaysEmitIntoClientattribute, mismatch in this attribute is not supported.
The following cases are handled (assume that in each case client's code uses
the derivative).
Both the function and its derivative are defined in a single file in one module.
Both the function and its derivative are defined in different files which
are compiled to a single module.
The function is defined in one module, its derivative is defined in another
module.
The function and the derivative are defined as members of a protocol extension in two separate modules - one for the function and one for the
derivative. A struct conforming the protocol is defined in the third
module.
The function and the derivative are defined as members of a struct extension in two separate modules - one for the function and one for the
derivative.
The changes allow to define derivatives for methods of
SIMD.Fixes #54445