Edge SILFunction one step closer to independence from SILFunctionType context by taking the generic param list as a separate constructor parameter, and serializing those params alongside the function record. For now we still pass in the context params from the SILFunctionType in most cases, because the logic for finding the generic params tends to be entangled in type lowering, but this pushes the problem up a step.
Thanks Jordan for helping work out the serialization changes needed.
Swift SVN r13036
Teach SILGen to emit a -dealloc method that runs user code, destroys
instance variables, and then calls up to the superclass dealloc. Teach
IRGen to deal with Objective-C destructor methods and add -dealloc to
the instance method table.
There are a few things still wrong here: we're emitting both a Swift
destructor and -dealloc, even though only one of them should ever
actually be used. Additionally, instance variables shouldn't be
destroyed in -dealloc, but in .cxx_destruct, so they persist until the
last of the -dealloc methods is invoked.
Swift SVN r12115
We will generate these in SILGen when we see a NormalProtocolConformance, to provide a mapping of method requirements to witnesses for types.
Swift SVN r10900
This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
This will let us control linkage and emit new variables independent of the AST in SILGen. In particular, for lazy global initialization, we need to emit a unique internal once predicate for every top-level pattern binding. Switching everything over is a bit much to reengineer all at once, so for now, it can coexist with the globals map that is already there.
Swift SVN r10509
Ideally this wouldn't be necessary, but the type substitution APIs required by generic specialization and SIL verification currently require a Module* pointer, and it's obnoxious to have to pass it down separately everywhere it's needed. Longer-term the reliance on Modules for type substitution might be able to go away.
Swift SVN r9866
SILFunction that it references. Use this in the mandatory inlining
pass to remove deserialized transparent functions, to clean up the
-emit-sil output of the compiler (and presumably speed up compile
time). This implements rdar://15272652
Swift SVN r9699
to interpose on the SIL linking process. Under the
following conditions:
- a function is called by the current SILModule;
- that function is transparent and empty in the
generated SIL;
- the SIL linker doesn't find a serialized
version of it; and
- the external client (right now, LLDB) has a
SILExternalSource installed in the SILModule;
the SIL linker will query the SILExternalSource
via lookupSILFunction.
This interface will be used by LLDB to provide
SIL accessors for a program's variables when they
are referred to by Swift expressions.
Swift SVN r9452
Once we have multiple SourceFiles in a TranslationUnit, it no longer makes
sense to say "only SILGen decls starting from element N" without specifying
which source file you mean.
Also, clarify ownership by having performSILGeneration return a unique_ptr
instead of just a bare pointer.
Swift SVN r9112
When we walk a ClassDecl, generate its vtable, first pulling in decls from its ancestor classes, then overlaying overridden or new decls as we discover them.
Swift SVN r8947
These will provide a SIL-level representation of class_method dispatch, mapping from dynamically-dispatched SILDeclRefs to SILFunctions so that devirtualization passes will be able to promote a class_method for a statically-known type to a function_ref without going all the way back to the AST.
Swift SVN r8943
Make ApplyInst and PartialApplyInst directly take substitutions for generic functions instead of trying to stage out substitutions separately. The legacy reasons for doing this are gone.
Swift SVN r8747
This reverts r8624 and compensates by passing the TU to the SILModule printer when needed.
This addresses concerns that Jordan and Sean had raised.
Swift SVN r8678
Make the functions support a wider range of builtins and store types to make
it possible.
This is an optimization - the cached ID will be used for builtin identification,
instead of retrieval of the string name and using it as the key.
Swift SVN r7390
The cache is stored in the SILModule.
Add getIntrinsicID() as a member of BuiltinFunctionRefInst.
Test by using the new method in the CCP pass.
Swift SVN r7311
Added a -v(verbose) option to swift that will trigger verbose printing in SIL
Printer. SIL Printer will print the location info only in the verbose mode.
Here is the example of the format - only the line and colon are displayed for
brevity:
%24 = apply %13(%22) : $[cc(method), thin] ((), [byref] Bool) -> Builtin.Int1 // user: %26 line:46:10
(This will be used to test the validity of SILLocation info.)
Swift SVN r6991
Modules can be in either 'Raw' or 'Canonical' form, with different invariants on each. We don't actually distinguish those invariants yet, but this patch adds the field to SILModule and adds a "sil_stage" declaration to SIL printer/parser syntax.
Swift SVN r6793
"SILConstant" doesn't really describe its role in SIL anymore, which is to provide a reference to a Swift declaration in a SIL instruction, such as a method or nominal type field.
Swift SVN r6559
Add a convenience SILModule::getTypeLoweringInfo forwarder, and move the emitRetainRValue and emitReleaseRValue helpers from SILGenFunction to SILBuilder so they're more readily available to non-SILGen passes. Add an emitDestroyAddress helper that emits nothing, destroy_addr, or load + release based on the value semantics of the referenced type.
Swift SVN r6431
This flag makes ASTContext and SILModule's allocators go through malloc instead of using bump pointer allocators, so that GuardMalloc or similar tools can be used to look for memory bugs.
Swift SVN r5472
If -nsstring-is-string is enabled, lower Strings in cc(c) and cc(objc) function types to NSString, and when calling them, insert calls to StringToNSString/NSStringToString to perform the bridging conversion.
This isn't quite ready for prime-time yet, because we still need to emit the inverse bridging for ObjC method thunks, and I haven't tested the IRGen end of things yet.
Swift SVN r5355
Generate and cache SILFunctionTypeInfo from Swift types on the fly, and simplify the SILType representation down to a CanType and isAddress bit.
Swift SVN r5298
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
