Thanks. I appreciate the encouragement. I’m actually trying not to add more complexity without offering some way to reason about it.
I added another section to the proposal that offers some background:
Here's how this design fits into broader picture of the layers of
abstraction in the type system:
- Formal types: The AST types directly exposed by the language.
- Canonical types: desugared formal AST types.
- Lowered types: Canonical types in the ASTContext that can be
directly referenced by SIL. These "formalize" some properties of the
ABI. For example, they make the ownership and indirection of
function arguments explicit. These formalized conventions must match
on both the caller and callee side of every call. Lowered types
include types that aren't part of the language's formal type
system. See SILFunctionType. Although these types have been lowered
for use by SIL, they exist independent of a SILModule.
(e.g. `@in Optional<T>`)
- SIL types: The actual type associated with a SIL value. These merely
wrap a lowered type with a flag indicating whether the SIL value
has indirect SIL semantics. i.e. whether the value is an address or
an object type. SIL types are part of a SILModule, and reflect the
SILModule's conventions. Mapping lowered types to SIL types is
specific to the current SIL stage.
- SIL storage types: These are SIL types with lowered addresses. They
represent the ABI requirements for indirection and storage of SIL
objects. In the "lowered" SIL stage, the SIL type of every value is
its storage type. Lowered types directly correspond to SIL storage
types. For example, if a function parameter has an `@in` lowered type, then
the storage type of the corresponding SIL argument is an address.
- LLVM types: Represent the ABI requirements in terms of C types. This
could introduce additional indirection, but I'd like to handle most
if not all of that in SIL address lowering.
(e.g. `%Sq* noalias nocapture, %swift.type* %T`)
So to recap, if you ask for the SIL type corresponding to a formal
convention, you'll get the SIL *storage* type
(e.g. `$*Optional<T>`). If you ask for the SIL type for a function
argument corresponding to the same formal parameter, you will get the
right level of indirection for the current SIL stage
(e.g. `$Optional<T>`). In short, the lowered type may specify a calling
convention that expects indirect storage, while the SIL type may be
On Jan 25, 2017, at 4:22 PM, Karl Wagner <firstname.lastname@example.org> wrote:
On 24 Jan 2017, at 20:10, Andrew Trick via swift-dev <email@example.com <mailto:firstname.lastname@example.org>> wrote:
I’m sending out a proposal for fundamentally changing SIL. This work feeds into generic code optimization, resilience, semantic ARC, and SIL ownership. This was discussed at length back in October—some info went out on swift-dev—but I realized there hasn’t been a formal proposal. So here it is. I want to make sure enough people have seen this before pushing my PR that puts the infrastructure in place: https://github.com/apple/swift/pull/6922.
Rendered Proposal: https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7
swift-dev mailing list
I won’t pretend to understand all of the implications of this, but as a newcomer to the codebase I found SILGen (particularly lowering) extremely confusing to unpick.
The simplification and separation described here makes a lot of sense to me, and I believe it would make it easier for myself and others to contribute to the project. As do your comments in the PR about using consistent idioms throughout the compiler.
So as far as those things are considerations, I’m really happy with this proposal.