For most types, this is really only useful in the presence of
an unimplemented operation, but for empty types this does come
up quite reasonably.
Swift SVN r4897
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
The resultType of a function call from IRGen::CallEmission's point of view is still its Swift return type, which is different from the ApplyInst's result type when an apply instruction has an indirect return. Fix that, and un-XFAIL the parts of test/IRGen/protocols.swift that test witness table and witness method emission.
Swift SVN r4860
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
dead methods, and moving emitInvoke to CallInvocation.
An interesting semantic change of this is that we're now calling getResultType
on the function type every time IGF is constructed, which exposed some latent
bugs. Specifically two places in GenObjC are trying to extra curry level two
from function types like "SomeObject -> (value : SomeObject) -> ()" which
doesn't make sense. I switched them to get curry level 1, but this definitely
needs some close review.
Swift SVN r4852
Port IRGen's calculation of consumed arguments and return value semantics to SILGen, and use it to handle the ownership semantics of calls. Refactor the handling of properties and other clients of emitApply so they can properly hand ownership semantics down to it.
This should let all the moribund cleanup management code in IRGen die. Unfortunately Scope appears to be tied into scoped calculated metadata caching so it's not quite ready to die.
Swift SVN r4834
handling non-fixed layouts.
This uncovered a bug where we weren't rounding up the header
size to the element alignment when allocating an array of archetypes.
Writing up a detailed test case for *that* revealed that we were
never initializing the length field of heap arrays. Fixing that
caused a bunch of tests to crash trying to release stuff. So...
I've left this in a workaround state right now because I have to
catch a plane.
Swift SVN r4804
seems that this is not a good idea, because it seems statically live from the SIL
SuperToArchetypeInst. However, apparently nothing in the testsuite exercises
this code, so I'll need to discuss and a testcase to know how much logic needs
to be ressurrected from SVN. rdar://13681541
Swift SVN r4800
