> On Jan 25, 2017, at 4:22 PM, Karl Wagner <razie...@gmail.com> wrote: > > >> On 24 Jan 2017, at 20:10, Andrew Trick via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.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 >> <https://github.com/apple/swift/pull/6922>. >> >> Rendered Proposal: >> https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7 >> <https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7> >> >> Markdown: >> <silval-proposal-1.md> >> >> -Andy >> _______________________________________________ >> swift-dev mailing list >> swift-dev@swift.org <mailto:swift-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-dev > > 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. > > - Karl
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: https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7#sil-types-and-argument-conventions <https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7#sil-types-and-argument-conventions> ... 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. (e.g. `T?`) - Canonical types: desugared formal AST types. (e.g. `Optional<T>`) - 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. (`e.g. $Optional<T>`) - 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. (`e.g. $*Optional<T>`) - 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 direct.
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
