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
For non-generic, non-property, non-instance-method curried functions, emit SIL thunks for all of the intermediate curry levels. The generic, property, and instance method cases need some additional SIL and irgen work to support, but aren't well supported by the current backend, so I'll leave them to be dealt with later. This causes the SliceUInt8 test to break down in IRGen; I'll fix that next.
Swift SVN r4715
different routine which tries to print some extra context
before triggering an assert.
For now, this is just the instruction and its basic block,
but I think a nicer output would be something like
%0 = ...
%1 = ...
-> %2 = ...
%3 = ...
br ...
Swift SVN r4711
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
ArchetypeMethodInst, like ProtocolMethodInst, actually needs to be modeled as returning a thick function type, in order to represent the metadata parameter to the witness table function. With that change to SILGen, implement ArchetypeMethodInst IRGen.
Swift SVN r4688
Doug found that the verifier would admit a DowncastInst that took an lvalue as the input, which is bogus. Refine the verifier rules for DowncastInst so it only admits class rvalues and destination types.
Swift SVN r4685
The Verifier wasn't actually verifying function bodies, because I neglected to visit the actual basic blocks after checking the entry point arguments in verifySILFunction. This revealed a SILType identity issue where TypeConverter::getLoweredType and SILType::getEmptyTupleType returned non-identical SILTypes for the empty tuple type; fix that by removing SILType::getEmptyTupleType, moving TypeConverter into SILModule, and forcing all SILType creation through TypeConverter.
Swift SVN r4616
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
Add code to the verifier to verify that the entry point BB for a function has the right argument types for its function type, return instructions match the function type, and branch instruction arguments match the branched-to BB.
Swift SVN r4487
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
FunctionConversionExpr was converting the type of SIL values to thick function types without emitting SIL to create the dummy context, which was confusing IRGen.
Swift SVN r4476
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
Emit constant_refs as having thin function type and introduce context with closure instructions. Add checks to the verifier that function reference operations act on the right level of thinness.
Swift SVN r4432
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
Properly emit a SpecializeInst for an uncurried call to a generic method of a nongeneric class, where there are only generic parameters on the second uncurry level and the outermost function type appears monomorphic.
Swift SVN r4410
Add SILGen support for recently-added super.constructor and collection literal expr nodes. Remove the default visitExpr hack and add stubs for the handful of expr nodes remaining to implement.
Swift SVN r4406
Update value type constructor generation to go back to left-to-right uncurried argument emission. Fix the uncurry level of specializations generated during constructor/destructor emission. Update the 'lifetime' test.
Swift SVN r4386
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
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
John recommended this because it has a number of benefits:
- It avoids a retain/release cycle, because 'this' can be passed to the initializer at +1 and just received back at +1.
- The allocating constructor can thus tail call the initializing constructor.
- If we end up needing to support rogue ObjC initializers that change self, we're set up to do so.
Swift SVN r3836
I was being lazy by not mangling the context arguments onto the types of closure SIL constants and then having ClosureInst pass the type of its callee through T -> T. Now closure functions get emitted with the right types, ClosureInst properly partially applies the type, and the SIL Verifier properly checks that the argument types all line up correctly.
Swift SVN r3815
Archetypes and projected existentials have the type %swift.opaque* and not i8*, so I need a corresponding SIL type to be able to model the ProjectExistential operation. We might also end up needing the builtin type for other low-level things down the line.
Swift SVN r3793
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
Fully and consistently destructure tuples when in a function argument context, and require that ApplyInst always take destructured arguments corresponding to the lowered argument types as its inputs. This eliminates a ton of finicky special-case code all over the place and also has the nice fringe benefit of avoiding a bunch of useless TupleInsts that were being emitted before. Currently this breaks variadic tuple fields and argument writeback. I'll fix variadic tuple fields soon. The argument writeback sucked anyway and I'll do it right later.
Swift SVN r3730
ExistentialMethod -> ProtocolMethod for better specificity.
[De]AllocExistential -> [De]InitExistential because it doesn't necessarily allocate anything.
Swift SVN r3710
