Skip to content
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

[SR-13689] derivative of @_alwaysEmitIntoClient function #54445

Open
marcrasi mannequin opened this issue Jan 10, 2020 · 1 comment
Open

[SR-13689] derivative of @_alwaysEmitIntoClient function #54445

marcrasi mannequin opened this issue Jan 10, 2020 · 1 comment

Comments

@marcrasi
Copy link
Mannequin

@marcrasi marcrasi mannequin commented Jan 10, 2020

Previous ID SR-13689
Radar rdar://problem/70017725
Original Reporter @marcrasi
Type Sub-task
Additional Detail from JIRA
Votes 0
Component/s
Labels Sub-task
Assignee None
Priority Medium

md5: 967b747ece099c24e9dac8020bc59125

Parent-Task:

  • SR-13659 Retroactive derivative registration

relates to:

  • TF-1347 Find a better workaround for SIMDVector

Issue Description:

Many things go wrong when you try to register a derivative of an @_alwaysEmitIntoClient function.

Negative tests demonstrating the problem: #29129

Explanation and possible solutions:

What's happening is:

  • When the differentiation pass is processing `gradient(at: 0, in: f)`, it finds the differentiability config arising from the `@derivative(of: f)`, and creates a corresponding differentiability witness declaration.

  • The linker tries to link references to that witness to an actual definition.

  • There is no actual definition because the witness linkage is PublicNonABI, which means that the witness does not get emitted into the library.

Some possible fixes are:

  • Make it so that the differentiability witness is Public instead of PublicNonABI. An obstacle for this approach is that TBDGen currently bases its decision on whether to emit a TBD entry on the linkage of the original function. So TBD doesn't won't emit a TBD entry for the witness for a PublicNonABI function. We could overcome this obstacle by teaching TBDGen to use the linkage of the derivative function instead of the linkage of the original function.

  • Teach the differentiation pass about PublicNonABI witnesses. Specifically:

    • Put information about the witness linkage in the `DerivativeFunctionConfigurationList`.

    • Make the pass create a decl with the appropriate linkage based on that information.

    • Teach something to deserialize these witnesses. (Maybe SIL/Linker.cpp is the correct place to do this, if the linking pass runs after differentiation. However, if the linking pass runs before differentiation, maybe we'll need the differentiation pass to deserialize these).

My initial thought is that the second approach is better because we want the visibility/linkage/etc of the derivative functions to always be as close to the original functions as possible.

@rxwei
Copy link
Member

@rxwei rxwei commented Oct 6, 2020

@swift-ci create

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant