Give an overview of the entire compiler pipeline followed by some description of where we're at and where we want to be with SILGen and the following SIL passes.
Swift SVN r6418
Archetype and protocol 'x.metatype' expressions eventually need to do a dynamic lookup, like 'x.metatype' for classes. These instructions represent that lookup.
Swift SVN r4534
All the other implicit conversions have been given their own instructions, so specialize this ill-specified instruction to its one remaining use, for converting compatible function types.
Swift SVN r4482
Make converting a SIL address to a Builtin.RawPointer its own instruction separate from implicit_convert, which will let me get rid of a goofy edge case in IRGenSIL.
Swift SVN r4412
We want to port CallEmission to the SIL level to handle uncurrying, but IRGen needs to have the original signature of a function available to it so that it can maintain the correct calling convention for different ABIs independent of SIL. Instead of flattening curried function types in SIL and losing that information, add an uncurryLevel to SILType so it can represent the type of an entry point at a given uncurry level. Unfortunately, this makes SILType outgrow a single word, so the way Value unions SILType and SILTypeList folding sets needs to be tweaked too.
Swift SVN r4345
This is more in line with how IRGen currently behaves and with how loadable values are passed, and will make optimization of address-only functions easier.
Swift SVN r4343
We need 'class_method' and 'super_method' to represent dynamic dispatch on class methods. We also need 'class_metatype' and 'existential_metatype' to obtain the runtime metatypes of class instances and existential containers.
Swift SVN r4321
zero_addr^Winitialize_var is a thing that should be magicked away either by turning subsequent assignments into initializations or by becoming a default constructor call. I don't think we need zero_value because 'initialize' pseudo-values should always originate from memory locations.
Swift SVN r4318
Conform to IRGen's curried calling convention by emitting param patterns in reverse order, with the indirect return argument (if any) coming first.
Swift SVN r3777
Consistently use "existential container" to refer to the protocol-typed container object and "concrete value" to refer to the subobject owned by the existential container. Simplify the example a bit by removing the extraneous function call.
Swift SVN r3711
Change the name of the implementation detail underlying protocol and protocol composition types to "existential container" while replacing references to "existential type" with "protocol or protocol composition type".
Swift SVN r3709
Loadable types are passed and returned at +1. Address-only arguments are passed by reference and callee-copied. Address-only return values are passed as an implicit argument to caller-owned uninitialized memory and are callee-initialized.
Swift SVN r3525
Also repaint the "existential" bikeshed since there's a loud preference for talking about existentials as existentials within the implementation.
Swift SVN r3523
Describe a `ref_element_addr` instruction for extracting elements from reference types and a `generalize` instruction for representation conversion of generic values.
Swift SVN r3432
Derives the address of a member from the address of a fragile value type. SIL extract : SIL element_addr :: LLVM extractvalue : LLVM getelementptr. Also add SILVerifier checks for ExtractInst and ElementAddrInst that they deal only in values and addresses, respectively.
Swift SVN r3391
We'll need some additional instructions to describe initialization of existentials and existential method calls: `alloc_existential` to initialize an existential's witness and substitution table(s) and provide access to its storage, and `existential_method_ref`/`project_existential` to obtain a method handle from an existential and the opaque reference to hand down to the method.
Swift SVN r3348
After discussion with John, we decided that we need to be able to deallocate a partially-initialized box during initializer execution, in case an initializer expression ends up unwinding before a value is fully initialized. When optimizing reference type allocations, it would also better to expose the destructor call and release operations directly instead of hiding them inside an instruction.
Swift SVN r3291
Value types should not require destruction beyond `release`-ing their reference type members. `release` for reference types and `destroy_addr` for address-only types should cover all cleanup needs.
Swift SVN r3264
- Tighten up terminology, for instance, define what a "box" actually is
- Describe how operands can have zero, one, or many values
- Describe that only %operands are valid operands and loading constants, ints, and other literals requires distinct insns
- Make releasing a reftype and destroying a value distinct
- Describe how stack allocation of boxes and reftypes work
- Name address-only type operations `destroy_addr` and `copy_addr` to avoid confusion with rvalue operations
- Describe the full set of aggregate manipulation functions
- Clean up instruction notation to avoid ambiguities
- Throw in notes about things we need to design at some point
Swift SVN r3211
