Unwind a hack whose stated purpose was to register a potential member
edge from an extension to the extended type. In reality, this only
registered a plain member dependency on 'deinit'. This edge is
insufficient in isolation to cause a rebuild of a dependent file in the
case where a type and its extension live in separate files. However, we
appear to have been saved by the redundancy in edge registration because the
lookup for the extended type will register a top-level or nominal
dependency (for an unqualified or qualified reference respectively). The
worry there is if a protocol conformance edge *should* flip a previously
private nominal dependency edge to a cascading edge. In such a case, the
old code would not have been able to make the cascading edge promotion,
and we would have potentially miscompiled by not rescheduling dependent
jobs.
Introduce DirectOperatorLookupRequest &
DirectPrecedenceGroupLookupRequest that lookup
operator and precedence groups within a given
file or module without looking through imports.
These will eventually be used as the basis for the
new operator lookup implementation, but for now
just use them when querying lookup results from
serialized module files.
Global initializers are executed only once.
Therefore it's possible to hoist such an initializer call to a loop pre-header - in case there are no conflicting side-effects in the loop before the call.
Also, the call must post-dominate the loop pre-header. Otherwise it would be executed speculatively.
For example: hoist out of loops where the loop count could be 0.
We did this on purpose. But, if not wrong, it's at least very confusing if the initializer has observable side effects.
Instead let CSE and LICM do the job and handle initializer side-effects correctly.
rdar://problem/60292679
Detect stores to globals which get the address from an addressor call (and not from global_addr).
This kind of SIL is currently not generated, so most likely this bug does not show up. But as soon as we CSE addressor calls, it can be a real problem.
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.
`@differentiable` attribute on protocol requirements and non-final class
members now produces derivative function entries in witness tables and vtables.
This enables `witness_method` and `class_method` differentiation.
Existing type-checking rules:
- Witness declarations of `@differentiable` protocol requirements must have a
`@differentiable` attribute with the same configuration (or a configuration
with superset parameter indices).
- Witness table derivative function entries are SILGen'd for `@differentiable`
witness declarations.
- Class vtable derivative function entries are SILGen'd for non-final
`@differentiable` class members.
- These derivative entries can be overridden or inherited, just like other
vtable entries.
Resolves TF-1212.
I am doing this move for two reasons:
1. This file only works directly with parts of the PassManager.
2. In the SILOptimizer, we do not have files in the top level of the file tree
and instead group them in one of the subject subfolders.
`@differentiable` attribute on protocol requirements and non-final class members
will produce derivative function entries in witness tables and vtables.
This patch adds an optional derivative function configuration
(`AutoDiffDerivativeFunctionIdentifier`) to `SILDeclRef` to represent these
derivative function entries.
Derivative function configurations consist of:
- A derivative function kind (JVP or VJP).
- Differentiability parameter indices.
Resolves TF-1209.
Enables TF-1212: upstream derivative function entries in witness tables/vtables.
Generate SIL differentiability witnesses from `@differentiable` and
`@derivative` declaration attributes.
Add SILGen utilities for:
- Emiting differentiability witnesses.
- Creating derivative function thunks, which are used as entries in
differentiability witnesses.
When users register a custom derivative function, it is necessary to create a
thunk with the expected derivative type computed from the original function's
type. This is important for consistent typing and consistent differentiability
witness entry mangling.
See `SILGenModule::getOrCreateCustomDerivativeThunk` documentation for details.
Resolves TF-1138.
Update SIL derivative function type calculation for substituted function types.
`SILFunctionType::getAutoDiff{Derivative,Transpose}FunctionType` now handle
substituted original function types.
The derivative type of a (un)substituted original function type is also
(un)substituted.
Turn macro metaprogramming into template metaprogramming by defining a new kind of request that runs operator lookups.
This is the final piece of the puzzle for requestification of the current referenced name tracker system.
We want to be able to use mangled names to refer to protocol conformances in addition to type
metadata. Provide an ASTMangler method that can render an arbitrary abstract or concrete
`ProtocolConformanceRef`, factoring it out of the code used to emit conditional conformance arguments
in `appendProtocolConformance`.
