Distinguish invocation and pattern substitutions on SILFunctionType #30272
Conversation
|
@swift-ci Please test |
|
Build failed |
|
Build failed |
rjmccall
force-pushed
the
invocation-sil-function-subs
branch
from
7792f76 to
d936204
Compare
|
@swift-ci Please test. |
rjmccall
changed the title
|
Build failed |
|
Does |
|
Build failed |
Great point; I'll fix that, either in this PR if it needs a re-run or in a follow-up. |
|
@swift-ci Please test source compatibility |
rjmccall
force-pushed
the
invocation-sil-function-subs
branch
from
d936204 to
10df547
Compare
|
Okay, full tests passed. Made some minor changes and re-testing. |
|
@swift-ci Please smoke test and merge. |
1 similar comment
|
@swift-ci Please smoke test and merge. |
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.
rjmccall
force-pushed
the
invocation-sil-function-subs
branch
from
10df547 to
ceff414
Compare
|
@swift-ci Please smoke test and merge. |
1 similar comment
|
@swift-ci Please smoke test and merge. |
|
@swift-ci Please clean smoke test OS X |
|
@swift-ci Please clean smoke test OS X platform |
|
Thanks @rjmccall! In addition to SIL.rst, it might be a good idea to mention the new syntax and generic signature behavior in the Swift Forums development thread: https://forums.swift.org/t/improving-the-representation-of-polymorphic-interfaces-in-sil-with-substituted-function-types/29711 |
Great idea! I've posted in that thread. |
4 participants
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
implicitbit 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:
The lowered signature of
P.foois<Self: P> (@in_guaranteed Self) -> (). Without this change, the lowered signature ofA.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.