[AutoDiff] Support custom derivatives for @_alwaysEmitIntoClient functions #78908
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
Contributor
Author
|
Tagging @asl |
kovdan01
force-pushed
the
autodiff-alwaysEmitIntoClient
branch
from
196d2d4 to
c75bc66
Compare
kovdan01
force-pushed
the
autodiff-alwaysEmitIntoClient
branch
from
c75bc66 to
bb90693
Compare
kovdan01
requested review from
a team,
eeckstein,
hborla,
jckarter,
slavapestov and
xedin
as code owners
Contributor
Author
|
Tagging @JaapWijnen @rxwei |
Contributor
|
@swift-ci please test |
kovdan01
force-pushed
the
autodiff-alwaysEmitIntoClient
branch
from
bb90693 to
ffa5f81
Compare
Contributor
|
@swift-ci please test |
kovdan01
force-pushed
the
autodiff-alwaysEmitIntoClient
branch
from
ffa5f81 to
6bb9def
Compare
Contributor
|
@swift-ci please test |
kovdan01
force-pushed
the
autodiff-alwaysEmitIntoClient
branch
from
6bb9def to
0b9bf45
Compare
Contributor
|
@swift-ci please test |
Contributor
Author
|
Would be glad to see feedback from everyone interested |
Contributor
Author
|
Would be glad to see feedback from everyone interested |
4 similar comments
Contributor
Author
|
Would be glad to see feedback from everyone interested |
Contributor
Author
|
Would be glad to see feedback from everyone interested |
Contributor
Author
|
Would be glad to see feedback from everyone interested |
Contributor
Author
|
Would be glad to see feedback from everyone interested |
Contributor
|
@lorentey will you please take a look on stdlib changes? |
Contributor
|
@jckarter Can you take a look into sil linker part? Thanks! |
Contributor
Author
Contributor
|
@kovdan01 Will you please update the description? To summarize what is done, what is the issue, etc. |
Contributor
Author
Sure, I've updated the PR description. |
Contributor
Author
3 similar comments
Contributor
Author
Contributor
Author
Contributor
Author
stephentyrone
approved these changes
May 25, 2025
Contributor
stephentyrone
left a comment
stephentyrone
left a comment
There was a problem hiding this comment.
Stdlib and test changes are fine. Compiler changes all look reasonable, and do not effect code that isn't using differentiable Swift, so I'm OK with taking this.
kovdan01
added a commit
to kovdan01/swift
that referenced
this pull request
May 30, 2025
The PR swiftlang#81766 introduced some concrete SIMD operations, but `init(repeating:)` was temporarily disabled due to differentiation testing break. See: stephentyrone@7a00619 This PR contains two changes: 1. Define custom derivatives for concrete `init(repeating:)` so we do not fall into non-differentiability error diagnostic. 2. Add a fix to SIL linker so differentiability witness lookup is done when the original function has both `@_alwaysEmitIntoClient` and `@_transparent`. Similar changes were introduced previously in swiftlang#78908, but they only handled `@_alwaysEmitIntoClient` without `@_transparent`.
stephentyrone
pushed a commit
that referenced
this pull request
May 31, 2025
The PR #81766 introduced some concrete SIMD operations, but `init(repeating:)` was temporarily disabled due to differentiation testing break. See: stephentyrone@7a00619 This PR contains two changes: 1. Define custom derivatives for concrete `init(repeating:)` so we do not fall into non-differentiability error diagnostic. 2. Add a fix to SIL linker so differentiability witness lookup is done when the original function has both `@_alwaysEmitIntoClient` and `@_transparent`. Similar changes were introduced previously in #78908, but they only handled `@_alwaysEmitIntoClient` without `@_transparent`. <!-- If this pull request is targeting a release branch, please fill out the following form: https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1 Otherwise, replace this comment with a description of your changes and rationale. Provide links to external references/discussions if appropriate. If this pull request resolves any GitHub issues, link them like so: Resolves <link to issue>, resolves <link to another issue>. For more information about linking a pull request to an issue, see: https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue --> <!-- Before merging this pull request, you must run the Swift continuous integration tests. For information about triggering CI builds via @swift-ci, see: https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci Thank you for your contribution to Swift! -->
kovdan01
added a commit
to kovdan01/swift
that referenced
this pull request
Nov 3, 2025
…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
kovdan01
added a commit
to kovdan01/swift
that referenced
this pull request
Nov 3, 2025
…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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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