We don't want to have to recover from a mangled name whether a function call is to an IRGen-lowered builtin, so add an instruction for referencing builtins.
Swift SVN r4919
Move AbstractCC into SILType and make it an attribute of SILTypes for functions. Add a ConvertCCInst to represent calling convention conversions. Give SILFunctions a linkage attribute. Add logic to SILGen to calculate these attributes for SILConstants based on their attached decls.
IRGen doesn't use these new attributes yet. I'll hook that up when I move mangling over.
Swift SVN r4886
Replace 'constant_ref' with 'function_ref', which references a SILFunction directly, and 'global_addr', which references a global variable VarDecl. Get rid of the SILConstant-to-SILFunction mapping in SILModule and replace it with an ilist of SILFunctions. Allow SILFunctions to be 'external' by not having any blocks in their body.
For now, SILFunctions still carry around their SILConstant "name", because name mangling and IRGen still rely on access to the original decl in order to recover IRGen information, which unfortunately leaves IRGen's CodeRefs in a gross, awkward intermediate state. Lifting mangling, AbstractCC, and other linkage attributes to SIL should clear up this up.
Swift SVN r4865
The value semantics primitives load/move/assign/init/destroy lower trivially to SIL value semantics operators, and the bridge casting operations introduce r/r semantics that should be visible to the ARC optimizer, so move the lowering for these builtins up to SILGen. Add a BUILTIN_SIL_OPERATION metaprogramming macro to Builtins.def, and add a facility similar to IRGen's former SpecializedCallEmission so we can handle builtin call emissions as special cases.
This also sets up the framework for eventually reintroducing special-case handling of known functions like &&, ||, Bool.getLogicValue, Int.convertFromIntegerLiteral, etc. in SILGen.
Swift SVN r4862
Add an IsaInst to represent type tests, and implement SILGen for IsSubtypeExpr AST nodes. Get rid of SuperIsArchetypeExpr because it's not really necessary to have it different from IsaSubtype--the SIL and IR behavior is identical.
Swift SVN r4855
Create a UnaryInstructionBase that factors all the boilerplate out of all the unary instructions. It'll be easy to generalize to all fixed-arity instructions, but let's start simple. No functionality change.
Swift SVN r4854
Teach SILGen how to emit the implicit elementwise constructor for structs and the implicit default constructor for classes, and eliminate the now dead IRGen code for them. Add a StructInst SIL instruction to represent constructing a loadable struct value from elements, analogous to TupleInst for tuples.
Swift SVN r4778
Otherwise we try to release junk pointers when we reassign class fields in the struct. Add an attribute to InitializeVarInst so that when dataflow analysis comes online, it knows that these InitializeVars need to be eliminated and can't be lowered to default constructor calls (since we're already in a constructor).
Swift SVN r4730
type, though; I had to define a WriteAsOperand function and
add a front() method to SILFunction to get this to work.
Rip out my dominators implementation and replace it with
LLVM's. I'd forgotten that LLVM's was actually generic.
Swift SVN r4717
take a const ValueBase* instead of a SILValue, implement SILArgument
cases for a few visitors and opt others out explicitly, and assert
that classes in the SIL value hierarchy override their superclass's
classof.
Swift SVN r4705
string_literal can have a two-element tuple type (with any labels) or a Builtin.RawPointer type, so print the type of the string_literal when emitting SIL.
Swift SVN r4699
On second thought, having SILConstant be able to point to a TLCD is going
against the goal of making SILConstant be a "SILGen thing". I'll find another
approach.
Swift SVN r4680
Function and compound types have a bunch of extra calling convention and uncurrying info stuffed into a "SILTypeInfo" object that until now had to be fetched through the SILModule. Change the representation of SILType to be a PointerUnion of CanType and SILTypeInfo*, and move the uncurry level onto the SILTypeInfo for functions, so that SILTypeInfo is available directly through the SILType and SILType can go back to being pointer-sized.
Swift SVN r4582
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
In top-level code, global variables are notionally local variables of the "main" function, but we give them global storage as an implementation detail. Add the ability to represent physical global variables to SILConstant, and emit top-level-code global variable initializers and references in terms of the physical address.
Swift SVN r4479
Swift doesn't yet type-check function thinness, so variables, arguments, and return values are always thick. When we store, pass as argument, or return a function value that SIL tracks as thin, emit a new 'thin_to_thick_function' instruction to represent converting the type to the thick type and adding a null context pointer.
Swift SVN r4470
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
Reference and call uncurried function applications when appropriate to the call site, following the same logic implemented in CallEmission/CalleeSource in IRGen. Add ClassMethodInst and SuperMethodInst instructions to represent method and super dispatch. Change how closures and ClosureInst are represented in SIL so that closures are functions with an extra implicit uncurry level and so that ClosureInst applies the outer uncurries of an uncurried function type to give a curried type as a result. This breaks...pretty much everything else SIL-dependent; I'll clean it up next.
Swift SVN r4368
Pack the uncurry level onto SILConstant, and modify SILConstant constructors to determine the natural uncurry level of their referenced entity by default. While we're here, improve how SILConstant represents different kinds of constants by using a real enum for the kind. Type closure entry points by giving them an extra curry level for their context. The implementation of ApplyInst and ClosureInst hasn't been updated yet, so tests that lower closures to SIL are temporarily broken.
Swift SVN r4354
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
Rename 'ZeroAddr' to 'InitializeVar' and remove ZeroValue since only things with memory locations should ever be in a 'default-initialize' state. Add a ModuleInst so we don't need to use ZeroValue as a hack to represent ModuleExpr values.
Swift SVN r4319
Converting from a protocol type to a more general protocol type is different at the implementation level from converting a concrete type to a protocol type, since the witness tables and concrete value can be copied directly from the original existential container to the new without adding another indirection. This instruction represents that operation.
Swift SVN r3887
Upcasting isn't quite a no-op like the other implicit conversions because the underlying pointer type still needs to be bitcast. The additional semantic information will be useful for SIL consumers as well.
Swift SVN r3872
Remove the filter that only irgenned SIL functions for FuncDecls so that we emit functions for all SIL decls, and disable the old paths for properties, constructors, and destructors when a SIL module is present. Unfortunately this breaks class constructors because SIL and IRGen don't agree on how initializing constructors should work. I need to sync with John to figure out how to fix that.
Swift SVN r3827
This is inconsistent with ElementAddr and Extract, but allows all the hairy logic of accessing class fields in IRGen to stand without a bunch of pointless refactoring.
Swift SVN r3778
ExistentialMethod -> ProtocolMethod for better specificity.
[De]AllocExistential -> [De]InitExistential because it doesn't necessarily allocate anything.
Swift SVN r3710
Add a new SILConstant kind to refer to the initializer of a ConstructorDecl. Emit class constructors as separate allocating and initializing functions named SILConstant(CD) and SILConstant(CD, Initializer) so that derived classes will be able to invoke their superclass constructor.
Swift SVN r3686
Add a new "kind" to SILConstant so that SIL can reference destructors without decls. Generate a destructor for classes even if they don't have an explicit destructor. If a class has a base class, call the base class destructor instead of dealloc_ref-ing the current instance.
Swift SVN r3665
Add an instruction to represent super-to-archetype downcasts. Since archetypes are address-only, it needs to take a reference to the destination archetype as a parameter.
Swift SVN r3643
Needed to represent deinitializing a partially-initialized existential in which the value witness table has been populated by alloc_existential but the value has not been initialized yet.
Swift SVN r3565
Move SILType to its own header, and make it its own container type consisting of a Type with an "isAddress" bit for representing address types. Move the "isAddressOnly" information from SILGen's TypeInfo onto SILType as a second bit, because address-only-ness is extremely useful for verification outside of SILGen. Instead of mangling function types during type lowering, rely on the fact that SILType is no longer a Type to force us to mangle argument and return types when we see them. (We may eventually need SILFunctionType and SILTupleType things to represent lowered SIL function and tuple types containing addresses, but for now we can lower function and tuple components as needed.)
Swift SVN r3551
