[swift-dev] Proposal: Opaque SIL values

[Andrew Trick]

> On Jan 25, 2017, at 4:22 PM, Karl Wagner <razielim at gmail.com> wrote:
> 
> 
>> On 24 Jan 2017, at 20:10, Andrew Trick via swift-dev <swift-dev at swift.org <mailto:swift-dev at 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 at swift.org <mailto:swift-dev at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170126/666bb9fd/attachment.html>