SIL has it, though a perfect Swift program written against a perfect Swift standard library run through perfect optimization passes should never emit it.
Swift SVN r6556
Neither order is particularly great yet, but getting them in sync will help us keep SIL.rst coverage up as we add/remove instructions in the future.
Swift SVN r6457
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
