Differential emitter generic support #2
Conversation
This file contains 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
bartchr808
force-pushed
the
differential-emitter
branch
2 times, most recently
from
e472a75
to
cbd0fa2
Compare
bartchr808
force-pushed
the
differential-emitter
branch
from
4e60732
to
1883ac1
Compare
bartchr808
force-pushed
the
differential-emitter-generic-support
branch
8 times, most recently
from
e58d9c6
to
b3a80a8
Compare
This should curtail merge conflicts in the future
…wiftlang#26887) VBR fields can store up to 64 bits of info in N-bit units, where the top bit describes whether there are further units to come. See http://llvm.org/docs/BitCodeFormat.html for more information. In the cases of the fields changed here, these are all usually-small values that can /occasionally/ get a lot larger; a VBR field allows us to pick a reasonable default while still not setting a maximum. Swiftmodule size micro-optimization. No functionality change; due to LLVM bitstream being a self-describing container format, this does not actually break compatibility.
…ip the switch to enable this on the tests/rest of the world.
…_borrow, load_borrow where all users can accept a guaranteed parameter. I previously implemented this only for functions so I didn't need to use the linear lifetime checker to determine if all destroys where within the lifetime of the borrowed value. That was just to be incremental. In this commit, I unleash the whole optimization.
… prefer to loading via interfaces ABI checker imports Swift frameworks by using Swift interfaces for various reasons. The existing way of controlling preferred importing mechanism is by setting an environment variable (SWIFT_FORCE_MODULE_LOADING), which may lead to performance issues because the stdlib could also be loaded in this way. This patch adds a new front-end option to specify module names for which we prefer to importing via Swift interface. The option currently is only accessible via swift-api-digester. rdar://54559888
[Request Evaluator] Begin Formalizing Zones
…ac23243588bb03b3f435c62
…nterface-for-module Frontend: add a front-end option to specify module names for which we prefer loading via interfaces
…d2fc16ee80001e7a767ab77 [ownership] Enable ownership lowering on overlays. I still need to fl…
…s crasher. (swiftlang#26900) Resolves [TF-783](https://bugs.swift.org/browse/TF-783).
…alue [ConstraintSystem] Be more principled about recording r-value -> l-value fix
…` types
If there is an argument-to-parameter conversion which is associated with
`inout` parameter, subtyping is now permitted, types have to be identical.
```swift
protocol P {}
struct S : P {}
func foo(_: inout P) {}
var s = S()
foo(&s) // `s` has to be defined as `P` e.g. `var s: P = S()`
// to be used as an argument to `inout P` parameter.
```
…ith the AbstractGenericSignatureRequest
It causes SwiftOnoneSupport to fail to compile, with error "swift: /usr/local/google/home/marcrasi/swift-merge/swift/lib/SILOptimizer/Utils/Generics.cpp:1864: swift::SILFunction *swift::GenericFuncSpecializer::tryCreateSpecialization(): Assertion `!SpecializedF->hasOwnership()' failed." Since we don't depend on constexpr any more, this removal shouldn't break anything.
This reverts commit d80b1d3.
…e3e81032ed3ccaae7417568
…oduce callables. (swiftlang#24299). They are duplicates.
…inks. (swiftlang#27032)" (swiftlang#27142) This reverts commit 2de0021.
… memory leaks. (swiftlang#27199) The `autodiff_function_extract` instruction behaves like `tuple_extract`, where it extracts some element from an aggregate. Its operand should have the same ownership kind as that of `tuple_extract`. That is, it should be defined as `CONSTANT_OR_TRIVIAL_OWNERSHIP_INST(Guaranteed, AutoDiffFunctionInst)` in ValueOwnershipKindClassifier. However, this is currently defined wrongly as `FORWARDING_OWNERSHIP_INST(AutoDiffFunctionExtract)`, which caused a bug in the differentiation transform to be uncaught: VJPEmitter and JVPEmitter in the differentiation transform is performing `autodiff_function_extract` on an `@owned` `@differentiable` function, which caused associated functions that are not extracted to be not released: ``` %f = autodiff_function %original %f_vjp = autodiff_function_extract [vjp] %f ... // %f is not released, and not caught by ownership verification! ``` After we fix the operand ownership kind for `autodiff_function_extract`, all these cases are now caught by ownership verification. The reproducer in [TF-795](https://bugs.swift.org/browse/TF-795) and most differentiation tests are failing to compile because ownership verification caught the bug in AD-generated code. The existing AD test suite is serving as good test cases for this ownership error. To fix this, VJPEmitter and JVPEmitter are now changed to emit borrows of `@differentiable` functions and copies of associated functions and property destroying the `@differentiable` function: ``` %f = autodiff_function %original %f_borrowed = begin_borrow %f %f_vjp_extracted = autodiff_function_extract [vjp] %f_borrowed %f_vjp = copy_value %f_vjp_extracted end_borrow %f_borrowed destroy_value %f ``` Fixes [TF-795](https://bugs.swift.org/browse/TF-795).
Filed TF-796 with more context.
Fix logic for deriving `VectorProtocol` for derived `TangentVector` struct.
…` on macOS. (swiftlang#27206) Previously, the default RPATH was set to `/usr/lib/swift`. This caused linker issues on macOS, as tensorflow-branch-specific modules like TensorFlow and Python do not exist in `/usr/lib/swift`. This patch defaults the `-toolchain-stdlib-rpath` flag to be true, so the default RPATH is the toolchain standard library instead of `/usr/lib/swift`. With this default, the linker issues are fixed. A `-no-toolchain-stdlib-path` flag is added to opt out of this default, making `/usr/lib/swift` the RPATH. Add positive/negative tests. `swift test` works on macOS for packages that import/use TensorFlow again. Partially reverts swiftlang#24787. Resolves TF-797.
swiftlang#27217) The `--rebuild` flag has been renamed to `--clean`.
It had gotten out-of-sync with the equivalent check in stdlib/public/core/FloatingPointTypes.swift.gyb, so this change copies it verbatim from there.
Previously, `ProtocolConformanceRef::getTypeWitnessByName` returned a null type.
Now, it returns a dependent member type with an error base type:
```
(dependent_member_type assoc_type=Swift.(file).Differentiable.TangentVector
(base=error_type
(original_type=bound_generic_struct_type decl=main.(file).TF_521@tf-521.swift:1:8
(primary_archetype_type address=0x7fe08d860660
conforms_to=Swift.(file).Differentiable
conforms_to=Swift.(file).FloatingPoint name=T
(nested_type=Exponent <<unresolved>>)
(nested_type=IntegerLiteralType <<unresolved>>)
(nested_type=Magnitude <<unresolved>>)
(nested_type=Stride <<unresolved>>)
(nested_type=TangentVector =T)))))
```
Explicitly check whether types have error in `conformsToDifferentiable`.
`-Xfrontend -enable-ownership-stripping-after-serialization` for swiftCore causes test/AutoDiff/array.swift to crash (regarding calls to `Array.recursivelyAllKeyPaths`). SR-11336 seems related and is reproducible from master. Disabling flag for swiftCore (and all other standard library modules) until SR-11336 is resolved. Temporarily disable affected test SILOptimizer/pound_assert.swift. TF-799 tracks re-enabling the test.
Merge tag 'swift-DEVELOPMENT-SNAPSHOT-2019-09-02-a' into tensorflow
…ftlang#27233) Bazel produces multiple TensorFlow library artifacts: ``` $ ls -alh tensorflow/bazel-bin/tensorflow 18B libtensorflow.so -> libtensorflow.so.1 23B libtensorflow.so.1 -> libtensorflow.so.1.14.0 277M libtensorflow.so.1.14.0 ``` Previously, TensorFlow libraries were copied via `cp -p`. This did not preserve symlinks, leading to library duplication: ``` $ ls -alh <TOOLCHAIN_BEFORE>.xctoolchain/usr/lib/swift/macosx 18B libtensorflow.so -> libtensorflow.so.1 277M libtensorflow.so.1 277M libtensorflow.so.1.14.0 # duplicate library ``` Now, `cp -a` is used, which preserves symlinks: ``` $ ls -alh <TOOLCHAIN_AFTER>.xctoolchain/usr/lib/swift/macosx 18B libtensorflow.so -> libtensorflow.so.1 277M libtensorflow.so.1 ``` This combined with removing libtensorflow_framework.so dependency (swiftlang#27029) led to a macOS toolchain size reduction from 3.99 GB to 3.62 GB on the tensorflow-0.5 branch.
…-emitter-generic-support
Follow-up to swiftlang#26928 for reverse-mode. TF-788 tracks re-enabling the warning.
- Handle `copy_value` and `destroy_addr` in "should differentiate" logic. These should be visited if they have an active operand. - Add differential visitors for `destroy_value` and `destroy_addr`.
Remove precondition that argument must be tuple-typed to simplify call sites. Clean up call site code and doc comments.
dan-zheng
force-pushed
the
differential-emitter-generic-support
branch
from
36a1083
to
b86bfd4
Compare
TF-800 tracks special-case activity analysis and "should differentiate" logic regarding tuple-typed `apply` results.
dan-zheng
force-pushed
the
differential-emitter-generic-support
branch
from
b86bfd4
to
d3155ed
Compare
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.
No description provided.