When a type (class, enum, or struct) is annotated @main, it is required
to provide a function with the following signature:
static func main() -> ()
That function will be called when the executable the type is defined
within is launched.
TBD was missing several opaque type descriptor symbols. The root causes
are: (1) the AST API called by TBD doesn't return opaque type decl if
the decl is from a serialized AST; and (2) the access level of opaque
type decl isn't serialized so TBD considers them as internal.
This change fixes both.
rdar://61833970
Make sure we mangle opaque types using the same settings as the
debugger mangling (with OptimizeProtocolNames = false) to ensure
that we can reconstruct those names again.
Serialize derivative function configurations per module.
`@differentiable` and `@derivative` attributes register derivatives for
`AbstractFunctionDecl`s for a particular "derivative function configuration":
parameter indices and dervative generic signature.
To find `@derivative` functions registered in other Swift modules, derivative
function configurations must be serialized per module. When configurations for
a `AbstractFunctionDecl` are requested, all configurations from imported
modules are deserialized. This module serialization technique has precedent: it
is used for protocol conformances (e.g. extension declarations for a nominal
type) and Obj-C members for a class type.
Add `AbstractFunctionDecl::getDerivativeFunctionConfigurations` entry point
for accessing derivative function configurations.
In the differentiation transform: use
`AbstractFunctionDecl::getDerivativeFunctionConfigurations` to implement
`findMinimalDerivativeConfiguration` for canonical derivative function
configuration lookup, replacing `getMinimalASTDifferentiableAttr`.
Resolves TF-1100.
Add `linear_function` and `linear_function_extract` instructions.
`linear_function` creates a `@differentiable(linear)` function-typed value from
an original function operand and a transpose function operand (optional).
`linear_function_extract` extracts either the original or transpose function
value from a `@differentiable(linear)` function.
Resolves TF-1142 and TF-1143.
Delete `@differentiable` attribute `jvp:` and `vjp:` arguments for derivative
registration. `@derivative` attribute is now the canonical way to register
derivatives.
Resolves TF-1001.
Add `differentiable_function` and `differentiable_function_extract`
instructions.
`differentiable_function` creates a `@differentiable` function-typed
value from an original function operand and derivative function operands
(optional).
`differentiable_function_extract` extracts either the original or
derivative function value from a `@differentiable` function.
The differentiation transform canonicalizes `differentiable_function`
instructions, filling in derivative function operands if missing.
Resolves TF-1139 and TF-1140.
In order to allow this, I've had to rework the syntax of substituted function types; what was previously spelled `<T> in () -> T for <X>` is now spelled `@substituted <T> () -> T for <X>`. I think this is a nice improvement for readability, but it did require me to churn a lot of test cases.
Distinguishing the substitutions has two chief advantages over the existing representation. First, the semantics seem quite a bit clearer at use points; the `implicit` bit was very subtle and not always obvious how to use. More importantly, it allows the expression of generic function types that must satisfy a particular generic abstraction pattern, which was otherwise impossible to express.
As an example of the latter, consider the following protocol conformance:
```
protocol P { func foo() }
struct A<T> : P { func foo() {} }
```
The lowered signature of `P.foo` is `<Self: P> (@in_guaranteed Self) -> ()`. Without this change, the lowered signature of `A.foo`'s witness would be `<T> (@in_guaranteed A<T>) -> ()`, which does not preserve information about the conformance substitution in any useful way. With this change, the lowered signature of this witness could be `<T> @substituted <Self: P> (@in_guaranteed Self) -> () for <A<T>>`, which nicely preserves the exact substitutions which relate the witness to the requirement.
When we adopt this, it will both obviate the need for the special witness-table conformance field in SILFunctionType and make it far simpler for the SILOptimizer to devirtualize witness methods. This patch does not actually take that step, however; it merely makes it possible to do so.
As another piece of unfinished business, while `SILFunctionType::substGenericArgs()` conceptually ought to simply set the given substitutions as the invocation substitutions, that would disturb a number of places that expect that method to produce an unsubstituted type. This patch only set invocation arguments when the generic type is a substituted type, which we currently never produce in type-lowering.
My plan is to start by producing substituted function types for accessors. Accessors are an important case because the coroutine continuation function is essentially an implicit component of the function type which the current substitution rules simply erase the intended abstraction of. They're also used in narrower ways that should exercise less of the optimizer.
This patch implements movable guaranteed scopes in ossa. This pattern is
currently not generated anywhere in the compiler, but my hope is to begin
emitting these in SemanticARCOpts. The idea is that these model true phi nodes
and thus can be used to fuse multiple guaranteed scopes into one using br
instructions. This is treated similarly to how owned instructions are forwarded
through /all/ terminators. This will enable us to use the SILSSAUpdater with
guaranteed arguments as well as enable the expression of sets of borrow scopes
that minimally jointly-dominate a guaranteed argument. This will enable us to
express +0 merge points like the following:
```
bb1:
%0a = begin_borrow %0 : $Klass
br bb3(%0a : $Klass)
bb2:
%1a = load_borrow %1 : $*Klass
br bb3(%1a : $Klass)
bb3(%2 : @guaranteed $Klass)
...
end_borrow %2 : $Klass
```
I describe below what the semantics of guaranteed block arguments were
previously, what they are now, and a little bit of interesting things from a
semantic perspective around implicit sub-scope users.
Before this patch in ossa, guaranteed block arguments had two different sets of
semantics:
1. Given a checked_cast_br or a switch_enum, the guaranteed block argument was
treated like a forwarding instruction. As such, the guaranteed argument's did
not require an end_borrow and its uses were validated as part of the use list
of the switch_enum/checked_cast_br operand's borrow introducer. It also was
not classified as a BorrowScopeValueIntroducer since it was not introducing a
new scope.
2. Given any other predecessor terminator, we treated the guaranteed argument as
a complete sub-scope of its incoming values. Thus we required the guaranteed
argument to have its lifetime eneded by an end_borrow and that all incoming
values of the guaranteed argument to come from a borrow introducer whose set
of jointly post-dominating end_borrows also jointly post-dominates the set of
end_borrows associated with the guaranteed argument itself. Consider the
following example:
```
bb0:
%1 = begin_borrow %foo : $Foo // (1)
%2 = begin_borrow %foo2 : $Foo2 // (2)
cond_br ..., bb1, bb2
bb1:
br bb3(%1 : $Foo)
bb2:
br bb3(%2 : $Foo)
bb3(%3 : @guaranteed $Foo)
...
end_borrow %3 : $Foo // (3)
end_borrow %2 : $Foo // (4)
end_borrow %1 : $Foo // (5)
...
```
Notice how due to SSA, (1) and (2) must dominate (4) and (5) and thus must
dominate bb3, preventing the borrows from existing within bb1, bb2.
This dominance property is actively harmful to expressivity in SIL since it
means that guaranteed arguments can not be used to express (without contortion)
sil code patterns where an argument is jointly-dominated by a minimal set of
guaranteed incoming values. For instance, consider the following SIL example:
```
bb0:
cond_br ..., bb1, bb2
bb1:
%0 = load [copy] %globalAddr : $Foo
br bb3(%0 : $Foo)
bb2:
%1 = copy_value %guaranteedFunctionArg : $Foo
br bb3(%1 : $Foo):
bb3(%2 : @owned $Foo):
apply %useFoo(%2)
destroy_value %2 : $Foo
```
As a quick proof: Assume the previous rules for guaranteed arguments. Then to
promote the load [copy] -> load_borrow and the copy_value to a begin_borrow, we
would need to place an end_borrow in bb3. But neither bb1 or bb2 dominates bb3,
so we would violate SSA dominance rules.
To enable SIL to express this pattern, we introduce a third rule for terminator
in ossa that applies only to branch insts. All other branches that obeyed the
previous rules (cond_br), still follow the old rule. This is not on purpose, I
am just being incremental and changing things as I need to. Specifically,
guaranteed arguments whose incoming values are defined by branch instructions
now act as a move on guaranteed values. The intuition here is that these
arguments are acting as true phis in an SSA sense and thus are just new names
for the incoming values. This implies since it is just a new name (not a
semantic change) that the guaranteed incoming value's guaranteed scopes should
be fused into one scope. The natural way to model this is by treating branch
insts as consuming guaranteed values. This then lets us express the example
above without using copies as follows:
```
bb0:
cond_br ..., bb1, bb2
bb1:
%0 = load_borrow %globalAddr : $Foo
br bb3(%0 : $Foo) // consumes %0 and acts as %0's end_borrow.
bb2:
// We need to introduce a new begin_borrow here since function
// arguments are required to never be consumed.
%1 = begin_borrow %guaranteedFunctionArg : $Foo
br bb3(%1 : $Foo) // consumes %1 and acts as %1's end_borrow
// %2 continues the guaranteed scope of %0, %1. This time fused with one name.
bb3(%2 : @guaranteed $Foo):
apply %useFoo(%2)
// End the lifetime of %2 (which implicitly ends the lifetime of %0, %1).
end_borrow %2 : $Foo
...
```
The main complication for users is that now when attempting to discover the set
of implicit users on an owned or guaranteed value caused by their usage as an
argument of a borrow introducer like begin_borrow. For those who are unaware, a
begin_borrow places an implicit requirement on its parent value that the parent
value is alive for the entire part of the CFG where this begin_borrow is
live. Previously, one could just look for the end_borrows of the
begin_borrow. Now one must additionally look for consuming branch insts. This is
because the original value that is being borrowed from must be alive over the
entire web of guaranteed values. That is the entire web of guaranteed values act
as a liveness requirement on the begin_borrow's operand.
The way this is implemented is given a use that we are validating, if the use is
a BorrowScopeOperand (1), we see if the borrow scope operand consumes the given
guaranteed scope and forwards it into a borrow scope introducer. If so, we add
the list of consuming uses of the borrow scope introducer to the worklist to
visit and then iterate.
In order to avoid working with cycles, for now, the ownership verifier bans
liveness requiring uses that have cycles in them. This still allows us to have
loop carried guaranteed values.
(1) A BorrowScopeOperand is a concept that represents an operand to a SIL
instruction that begins a guaranteed scope of some sort. All BorrowScopeOperand
are thus at a minimum able to compute a compile time the static region in which
they implicitly use their operands. NOTE: We do not require the scope to be
represented as a SILValue in the same function.
We achieve some nice benefit by introducing this. Specifically:
1. We can optimize the pattern I mentioned above. This is a common pattern in
many frameworks that want to return a default object if a computation fails
(with the default object usually being some sort of global or static
var). This will let us optimize that case when the global is a let global.
2. The SSA Updater can now be used with guaranteed values without needing to
introduce extra copies. This will enable predictable mem opts to introduce
less copies and for semantic arc opts to optimize the remaining copies that
PMO exposes but does not insert itself.
rdar://56720519
The `differentiability_witness_function` instruction looks up a
differentiability witness function (JVP, VJP, or transpose) for a referenced
function via SIL differentiability witnesses.
Add round-trip parsing/serialization and IRGen tests.
Notes:
- Differentiability witnesses for linear functions require more support.
`differentiability_witness_function [transpose]` instructions do not yet
have IRGen.
- Nothing currently generates `differentiability_witness_function` instructions.
The differentiation transform does, but it hasn't been upstreamed yet.
Resolves TF-1141.
This will be used for compiler-driven type erasure for dynamic
replacement of functions with an opaque return type. For now, just
parse the attribute and ignore it.
When a swift module is generated from a swift interface file, we must
remember to setup the nested types tables. Plumb the flag down from the
frontend options.
In the future, we must remove the ability to turn this off. There's
literally zero reason to have this be a configuration option anymore.
Resolves rdar://59202687 and its many, many dupes.
SIL differentiability witnesses are a new top-level SIL construct mapping
an "original" SIL function and derivative configuration to derivative SIL
functions.
This patch adds `SILDifferentiabilityWitness` serialization/deserialization.
Resolves TF-1136.
As part of this, we have to change the type export rules to
prevent `@convention(c)` function types from being used in
exported interfaces if they aren't serializable. This is a
more conservative version of the original rule I had, which
was to import such function-pointer types as opaque pointers.
That rule would've completely prevented importing function-pointer
types defined in bridging headers and so simply doesn't work,
so we're left trying to catch the unsupportable cases
retroactively. This has the unfortunate consequence that we
can't necessarily serialize the internal state of the compiler,
but that was already true due to normal type uses of aggregate
types from bridging headers; if we can teach the compiler to
reliably serialize such types, we should be able to use the
same mechanisms for function types.
This PR doesn't flip the switch to use Clang function types
by default, so many of the clang-function-type-serialization
FIXMEs are still in place.
The change to introduce a "top-level" bit for VarDecls requires a
module format version bump, per https://github.com/apple/swift/pull/29024.
Fixes rdar://problem/59078925
The current way that VarDecl::isLazilyInitializedGlobal() is implemented does
not work in the debugger, since the DeclContext of all VarDecls are deserialized
Swift modules. By adding a bit to the VarDecl we can recover the fact that a
VarDecl was in fact a global even in the debugger.
<rdar://problem/58939370>
The `@noDerivative` attribute marks the non-differentiability parameters of a
`@differentiable` function type. All parameters except those marked with
`@noDerivative` are differentiability parameters.
For example, `@differentiable (Float, @noDerivative Float) -> Float` is only
differentiable with respect to its first parameter.
The `@noDerivative` attribute is represented as a
`SILParameterDifferentiability` bit on `SILParameterInfo`.
Add round-trip serialization tests.
Resolves TF-872.
The `@transpose(of:)` attribute registers a function as a transpose of another
function. This patch adds the `@transpose(of:)` attribute definition, syntax,
parsing, and printing.
Resolves TF-827.
Todos:
- Type-checking (TF-830, TF-1060).
- Enable serialization (TF-838).
- Use module-qualified names instead of custom qualified name syntax/parsing
(TF-1066).
State the previously unstated nested type requirement that CodingKeys adds to the witness requirements of a given type. The goal is to make this member cheap to synthesize, and independent of the expensive protocol conformance checks required to append it to the member list.
Further, this makes a clean conceptual separation between what I'm calling "nested type requirements" and actual type and value requirements.
With luck, we'll never have to use this attribute anywhere else.
The `@derivative(of:)` attribute registers a function as a derivative of another
function. This patch adds the `@derivative(of:)` attribute definition, syntax,
parsing, and printing.
Resolves TF-826.
Todos:
- Type-checking (TF-829).
- Serialization (TF-837).
This fixes a bug that made it impossible to read any subsequent Swift modules
out of a .swift_ast section a previous section had a size divisible by 4.
rdar://problem/57110020
We've changed *what* is serialized by changing the way
@_dynamicReplacement is type checked, but not *how* it's
serialized. Bump the format so there aren't strange incompatibilities
because of this.
We need this attribute to teach compiler to use a different name from the current
module name when generating runtime symbol names for a declaration. This is to serve
the workflow of refactoring a symbol from one library to another without breaking the existing
ABI.
This patch focuses on parsing and serializing the attribute, so @_originallyDefinedIn
will show up in AST, swiftinterface files and swiftmodule files.
rdar://55268186
SIL type lowering erases DynamicSelfType, so we generate
incorrect code when casting to DynamicSelfType. Fixing this
requires a fair amount of plumbing, but most of the
changes are mechanical.
Note that the textual SIL syntax for casts has changed
slightly; the target type is now a formal type without a '$',
not a SIL type.
Also, the unconditional_checked_cast_value and
checked_cast_value_br instructions now take the _source_
formal type as well, just like the *_addr forms they are
intended to replace.
The Bitstream part of Bitcode moved to llvm/Bitstream in LLVM. This
updates the uses in swift.
See r365091 [Bitcode] Move Bitstream to a separate library.
(cherry picked from commit 1cd8e19357)
This PR introduces `@differentiable` attribute to mark functions as differentiable. This PR only contains changes related to parsing the attribute. Type checking and other changes will be added in subsequent patches.
See https://github.com/apple/swift/pull/27506/files#diff-f3216f4188fd5ed34e1007e5a9c2490f for examples and tests for the new attribute.
This non-user-facing attribute is used to denote pointer parameters
which do not accept pointers produced from temporary pointer conversions
such as array-to-pointer, string-to-pointer, and in some cases
inout-to-pointer.
