Skip to content

Conversation

@marcrasi
Copy link

Removes some jvp: and vjp: from the stdlib. This is partial progress towards unblocking TF-1001.

Some bugfixes were necessary:

  • DenseMapInfo<AutoDiffConfig> wasn't canonicalizing the GenericSignature, causing equivalent configs to appear distinct.
  • @derivative(of:) typechecking was not taking the generic signature into account when comparing actual/expected differential/pullback types, causing incorrect "incorrect pullback type" diagnositcs.
  • In deserialization, MF.getIdentifier doesn't work on special identifiers like init, so @derivative(of: init) didn't work.

Open style question: When we have a choice about whether to put a @differentiable attribute on the original declaration, should we? This PR leaves all the @differentiable attributes, but it should also work if this PR removes them.

@marcrasi marcrasi requested review from dan-zheng and rxwei December 13, 2019 01:55
Copy link
Contributor

@dan-zheng dan-zheng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

If rewriting @differentiable(jvp:vjp:) to @derivative in the stdlib required compiler changes, is it possible to add unit tests for the compiler changes to ensure coverage beyond stdlib compilation?

I wonder what issues prevented rewriting @differentiable(jvp:vjp:) without the compiler changes. Edit: I should've read the PR description more carefully, sorry - I see it mentions "incorrect pullback type" diagnostics.

auto vectorTy = valueResultConf.getTypeWitnessByName(
valueResultType, Ctx.Id_TangentVector);

// Compute the actual differential/pullback type that we use for comparison
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: #28738 upstreams @derivative type-checking to master. I can handle cherry-picking this fix to master after that PR is merged.

I wonder if it's possible to write a unit test that can be upstreamed with the fix?

Food for thought: after code is upstreamed, perhaps we should make changes on master and merge them (or let them be merged) to tensorflow. This saves some effort compared with committing to both tensorflow and master, since code must eventually land in master.

auto *ptr = llvm::DenseMapInfo<void *>::getEmptyKey();
return {static_cast<IndexSubset *>(ptr), static_cast<IndexSubset *>(ptr),
DenseMapInfo<GenericSignature>::getEmptyKey()};
nullptr};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For future reference: I wonder what errors arise from using DenseMapInfo<GenericSignature>::getEmptyKey() here?

@rxwei
Copy link
Contributor

rxwei commented Dec 13, 2019

When we have a choice about whether to put a @differentiable attribute on the original declaration, should we?

I believe we should, for libraries that are built for distribution.

}

extension Tracked where T : Differentiable, T == T.TangentVector {
@usableFromInline
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note for later: We should make @derivative and @transpose imply @usableFromInline for internal declarations.

@dan-zheng
Copy link
Contributor

Some patches depend on this PR, so let's try to merge it now.

@dan-zheng
Copy link
Contributor

@swift-ci Please test tensorflow

@marcrasi
Copy link
Author

Good idea about the unit tests. I'll write some and send a followup PR, so that I don't block merging this.

@marcrasi marcrasi merged commit e5915f7 into tensorflow Dec 13, 2019
@marcrasi marcrasi deleted the marcrasi-retrodiff-2 branch December 13, 2019 20:00
@marcrasi
Copy link
Author

When we have a choice about whether to put a @differentiable attribute on the original declaration, should we?

I believe we should, for libraries that are built for distribution.

Sounds good to me. Therefore, I will keep the @differentiable attributes while removing vjp:/jvp:, with one exception: I'll remove @differentiable from all non-differentiation-related stdlib functions, because we want to avoid modifying any existing stdlib files while upstreaming.

dan-zheng added a commit to dan-zheng/swift that referenced this pull request Dec 18, 2019
Upstream `@derivative` attribute type-checking fixes regarding derivative
generic signatures with all concrete generic parameters.

Cherry-picked from:
- swiftlang#28762
- swiftlang#28772
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

Successfully merging this pull request may close these issues.

4 participants