<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 25, 2017, at 4:22 PM, Karl Wagner <<a href="mailto:razielim@gmail.com" class="">razielim@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 24 Jan 2017, at 20:10, Andrew Trick via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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: <a href="https://github.com/apple/swift/pull/6922" class="">https://github.com/apple/swift/pull/6922</a>.</div><div class=""><br class=""></div><div class="">Rendered Proposal: <a href="https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7" class="">https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7</a></div><div class=""><br class=""></div><div class="">Markdown:</div></div><span id="cid:C86860D7-D6FE-4B9C-9AA0-3E205316CAF6@fritz.box" class=""><silval-proposal-1.md></span><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">-Andy</div></div>
_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev" class="">https://lists.swift.org/mailman/listinfo/swift-dev</a><br class=""></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">So as far as those things are considerations, I’m really happy with this proposal.</div><div class=""><br class=""></div><div class="">- Karl</div></div></div></blockquote></div><div class=""><br class=""></div>Thanks. I appreciate the encouragement. I’m actually trying not to add more complexity without offering some way to reason about it.<br class=""><div class=""><br class=""></div><div class="">I added another section to the proposal that offers some background:</div><div class=""></div><div class=""><a href="https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7#sil-types-and-argument-conventions" class="">https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7#sil-types-and-argument-conventions</a></div><div class=""><br class=""></div><div class="">...</div><div class=""><div class="">Here's how this design fits into broader picture of the layers of</div><div class="">abstraction in the type system:</div><div class=""><br class=""></div><div class="">- Formal types: The AST types directly exposed by the language.</div><div class=""> (e.g. `T?`)</div><div class=""><br class=""></div><div class="">- Canonical types: desugared formal AST types.</div><div class=""> (e.g. `Optional<T>`)</div><div class=""><br class=""></div><div class="">- Lowered types: Canonical types in the ASTContext that can be</div><div class=""> directly referenced by SIL. These "formalize" some properties of the</div><div class=""> ABI. For example, they make the ownership and indirection of</div><div class=""> function arguments explicit. These formalized conventions must match</div><div class=""> on both the caller and callee side of every call. Lowered types</div><div class=""> include types that aren't part of the language's formal type</div><div class=""> system. See SILFunctionType. Although these types have been lowered</div><div class=""> for use by SIL, they exist independent of a SILModule.</div><div class=""> (e.g. `@in Optional<T>`)</div><div class=""><br class=""></div><div class="">- SIL types: The actual type associated with a SIL value. These merely</div><div class=""> wrap a lowered type with a flag indicating whether the SIL value</div><div class=""> has indirect SIL semantics. i.e. whether the value is an address or</div><div class=""> an object type. SIL types are part of a SILModule, and reflect the</div><div class=""> SILModule's conventions. Mapping lowered types to SIL types is</div><div class=""> specific to the current SIL stage.</div><div class=""> (`e.g. $Optional<T>`)</div><div class=""><br class=""></div><div class="">- SIL storage types: These are SIL types with lowered addresses. They</div><div class=""> represent the ABI requirements for indirection and storage of SIL</div><div class=""> objects. In the "lowered" SIL stage, the SIL type of every value is</div><div class=""> its storage type. Lowered types directly correspond to SIL storage</div><div class=""> types. For example, if a function parameter has an `@in` lowered type, then</div><div class=""> the storage type of the corresponding SIL argument is an address.</div><div class=""> (`e.g. $*Optional<T>`)</div><div class=""><br class=""></div><div class="">- LLVM types: Represent the ABI requirements in terms of C types. This</div><div class=""> could introduce additional indirection, but I'd like to handle most</div><div class=""> if not all of that in SIL address lowering.</div><div class=""> (e.g. `%Sq* noalias nocapture, %swift.type* %T`)</div><div class=""> </div><div class="">So to recap, if you ask for the SIL type corresponding to a formal</div><div class="">convention, you'll get the SIL *storage* type</div><div class="">(e.g. `$*Optional<T>`). If you ask for the SIL type for a function</div><div class="">argument corresponding to the same formal parameter, you will get the</div><div class="">right level of indirection for the current SIL stage</div><div class="">(e.g. `$Optional<T>`). In short, the lowered type may specify a calling</div><div class="">convention that expects indirect storage, while the SIL type may be</div><div class="">direct.</div></div><div class=""><br class=""></div></body></html>