This attribute indicates that the given SILFunction has to be
added to "accessible functions" section and could be looked up
at runtime using a special API.
I am adding this to make it easy to determine if a SILFunction that is not inout
aliasable is captured. This is useful when emitting certain types of
diagnostics like I need to emit with move only.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
This invalidation kind is used when a compute-effects pass changes function effects.
Also, let optimization passes which don't change effects only invalidate the `FunctionBody` and not `Everything`.
We had two notions of canonical types, one is the structural property
where it doesn't contain sugared types, the other one where it does
not contain reducible type parameters with respect to a generic
signature.
Rename the second one to a 'reduced type'.
Andy some time ago already created the new API but didn't go through and update
the old occurences. I did that in this PR and then deprecated the old API. The
tree is clean, so I could just remove it, but I decided to be nicer to
downstream people by deprecating it first.
This ensures that opened archetypes always inherit any outer generic parameters from the context in which they reside. This matters because class bounds may bind generic parameters from these outer contexts, and without the outer context you can wind up with ill-formed generic environments like
<τ_0_0, where τ_0_0 : C<T>, τ_0_0 : P>
Where T is otherwise unbound because there is no entry for it among the generic parameters of the environment's associated generic signature.
There are three major changes here:
1. The addition of "SILFunctionTypeRepresentation::CXXMethod".
2. C++ methods are imported with their members *last*. Then the arguments are switched when emitting the IR for an application of the function.
3. Clang decls are now marked as foreign witnesses.
These are all steps towards being able to have C++ protocol conformance.
Start treating the null {Can}GenericSignature as a regular signature
with no requirements and no parameters. This not only makes for a much
safer abstraction, but allows us to simplify a lot of the clients of
GenericSignature that would previously have to check for null before
using the abstraction.
Instead, put the archetype->instrution map into SIlModule.
SILOpenedArchetypesTracker tried to maintain and reconstruct the mapping locally, e.g. during a use of SILBuilder.
Having a "global" map in SILModule makes the whole logic _much_ simpler.
I'm wondering why we didn't do this in the first place.
This requires that opened archetypes must be unique in a module - which makes sense. This was the case anyway, except for keypath accessors (which I fixed in the previous commit) and in some sil test files.
While cloning arguments for existential specializer, do not create copy
for object types. Currently, for guaranteed parameter types it
unnecessarily creates a copy and cleans it up with a destroy. The
discrepency is seen when cloning an instruction like open_existential_ref
which was previously using guaranteed operand and had guaranteed
forwarding ownership, is now replaced to have the owned copy as its
operand during cloning.
When there are no non-type dead args, DeadArgumentTransform should not
specialize the function. While marking dead type args as not dead, make
sure we go over all the args.
If not, a dead type arg will be attempted to be deleted later on in
FunctionSignatureTransform::DeadArgumentFinalizeOptimizedFunction.
Add handling for repeated specialization and remove an incorrect
assertion in
ExistentialTransform::createExistentialSpecializedFunctionName():
assert(!F->getModule().hasFunction(MangledName));
The ExistentialSpecializer replaces the original function with a thunk
to a newly specialized function. Repeated attempts to specialize the
same function bail out because the pass avoids reoptimizing thunks.
Ultimately, the intention is that the thunks will all be inlined into
their callers. Dead function elimination will then remove the
thunks. If the original function was itself a specialization, then the
GenericSpecialize may regenerate the original again in non-thunk form.
Consider the pipeline:
- GenericSpecializer
- ExistentialSpecializer
- Inliner
- DeadFunctionElimination
- GenericSpecializer
- ExistentialSpecializer
This is not a problem with the ExistentialSpecializer itself. In fact,
it may respecialize the same function in different ways, for example
specializing more of the arguments each time. Each different
specialization transforms the original function into a thunk, that
thunk is inlined, and the newly specialized code is called directly.
Of course, the ExistentialSpecializer may also decide to respecialize
a function the same way as before. When doing this, it still needs to
produce the thunk, which was dead function eliminated since last
specialization of the same function. However, it can simply reuse the
previous specialization by performing a name lookup first.
The design problem is that the SILModule makes assumptions about
duplicate symbols when managing symbol memory but does not provide a
robust way to protect against such duplicate symbols. That will be
improved in a separate commit.
Minimal fix for: rdar://72135512 The ExistentialSpecializer crashes
This makes it easier to understand conceptually why a ValueOwnershipKind with
Any ownership is invalid and also allowed me to explicitly document the lattice
that relates ownership constraints/value ownership kinds.
I can not update all of the tests until I fix SILCombine and we move the
ownership lowering to right before the existential specializer (the sil tests
depend on the former and the swift tests depend on both). But this at least
begins updating the tests and ensures that the updates do not break the pass
when we run it on non-ossa code.
ExistentialSpecializer could be building the function type from a
witness_method. We cannot attach a witnessProtocolConformance to the
newly specialized thin function.
If a function is annotated with @_semantics("optimize.sil.specialize.owned2guarantee.never") its arguments will not be converted from owned to guaranteed.
This is just fixing an assert violation. I also needed to add support for
target-sil-opt(mock-sdk: ...) so I added support to lit for that here.
<rdar://problem/62262811>
This simplifies the handling of the subdirectories in the SIL and
SILOptimizer paths. Create individual libraries as object libraries
which allows the analysis of the source changes to be limited in scope.
Because these are object libraries, this has 0 overhead compared to the
previous implementation. However, string operations over the filenames
are avoided. The cost for this is that any new sub-library needs to be
added into the list rather than added with the special local function.
This became necessary after recent function type changes that keep
substituted generic function types abstract even after substitution to
correctly handle automatic opaque result type substitution.
Instead of performing the opaque result type substitution as part of
substituting the generic args the underlying type will now be reified as
part of looking at the parameter/return types which happens as part of
the function convention apis.
rdar://62560867
The existential -> generic transformation in FSO didn't preserve the argument declaration.
This caused an assert to hit in a later FSO transformation.
rdar://problem/61206439
https://bugs.swift.org/browse/SR-12487
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 is not implemented--we don't substitute the original archetypes
properly or even create a well-formed generic signature.
It doesn't make sense to me for the ExistentialSpecializer to work on
a generic before it has been fully specialized anyway. The premise of
this pass is that the generic specializer will be able to fully
specialize after generating a new "temporary" generic parameter.
Fixes rdar://56923071; [SR-11714]: Compiler crash when generic class is passed as
a parameter to a function accepting a generic class
The ExistentialSpecializer incorrectly assumed that an existential's conformances match an opened archetype. They don't. Opened archetypes strip inherited conformances per the ABI for generic argument passing. Existential values retain those inherited conformances (for some inexplicable reason).
- Rename ASTContext::getExistentialSignature() to
getOpenedArchetypeSiganture() because it was doing exactly the wrong
thing for existentials.
- Fix ConcreteExistentialInfo to produce the correct SubstitutionMap.
- Fix ExistentialSpecializer to generate the correct conformances for
init_existential by adding a collectExistentialConformances() helper.
Fixes <rdar://problem/57025861> "Assertion failed: (conformances.size() == numConformanceRequirements)" in ExistentialSpecializer on inlined code
