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
We don't currently use this for anything, but if we have the module name
available and easy to access in the bitstream, we can drop the wrapper
around the serialized AST that's put into the binary itself for use by LLDB.
Swift SVN r12919
Currently when compiling with debug info, the AST gets serialized into the
.o file for use by the debugger. However, when we switch to one .o file
per .swift file, this won't really make sense any more. Instead, we should
collect all the ASTs at the end of the build and merge them together, then
write /that/ into the final binary.
This commit handles writing a serialized AST with an LLDB wrapper around it,
so that we can take a merged AST, write it out in the wrapper, and splice it
into the final binary using ld's -sectcreate option.
In the long run, we probably won't need the LLDB wrapper, but for now I'm
trying to disturb as little as possible. (It looks like the layout is
broken on 32-bit platforms, though...there was a problem with 64-bit
relocations in the existing SwiftASTStreamerPass, but nothing ever tried to
/read/ the new layout in 32 bits. I'm holding off on dealing with this
right now.)
Part of <rdar://problem/15786017>
Swift SVN r12667
Previously, cross-references just carried a chain of identifiers and a
top-level module, plus a type to validate against, a generic parameter index,
or an operator fixity. However, referencing "the first generic parameter
of the prefix function ++ that takes a ForwardIndex" requires /all three/
of these filters to unambiguously select the right declaration.
Now, cross-references consist of a chain of trailing records, one for each
link in the path. There are (currently) five kinds of links:
Type: a declaration that cannot have overloads
Value: a declaration that can have overloads (filtered by type)
Extension: filter to decls within extensions on another module
Operator:
- as the first path piece, an operator declaration
- as a later path piece, a fixity filter for operator functions
Generic Param: an indexed generic parameter of the previous result
This should allow us to uniquely cross-reference any Swift declaration we
need to.
Swift SVN r11399
There shouldn't ever be a reason to do this: if a conversion function is
ever selected by the type-checker, it's because the type the conversion
lives on was suggested by another constraint, which means we can do a
normal lookup for the conversion function.
This is actually the only thing being eagerly deserialized, so remove the
notion of eager deserialization altogether.
Swift SVN r11220
Allow archetype_method to look up a witness from a concrete ProtocolConformance record. This will allow generic specialization to apply to constrained generic functions independent of archetype_method devirtualization. <rdar://problem/14748543>
Swift SVN r10950
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
If given a SourceFile, only decls within that SourceFile will be serialized.
Decls within other SourceFiles are emitted using cross-references that refer
to the current module.
Known issues:
- External definitions won't be serialized by any source file. They probably
have to be serialized into /all/ of them.
- Nothing can actually /read/ a serialized partial-module yet. We need a
notion of a TranslationUnit that can contain both source and serialized
files, and we probably need loading to be more lazy.
Swift SVN r9978
ModuleID is compatible with IdentifierID, but uses 0 to mean “the builtin module”
and 1 to mean “the current module”. Anything else is a top-level module name,
as an identifier. As an implementation detail, 1 is now never a valid IdentifierID.
(0 remains “the empty string”.)
Using this, simplify the encoding of the owner of a conformance.
Swift SVN r9944
Put generic nominal type declarations through the same dependent-type
validation as generic functions, then capture their generic parameters
and requirements in their generic signature. This allows us to
re-instate the requirements in their dependent forms, before the
archetypes ruin them completely.
Swift SVN r8958
Add a SILLinkage mode "Deserialized" to make sure IRGen will emit
hidden symbols for deserialized SILFunction.
Inside SIL linker, set Linkage to external if we only have a declaration for
a callee function.
Both sil block and decl block in a module can emit an array of substitutions.
To share the serialization between SILSerializer and Serializer, we modify
the interface to pass in the abbreviation codes to write functions and to
pass in a cursor to read functions.
We now correctly handle the serialization of Substitutions in SpecializeInst.
For a deserialized SILFunction, we now temporarily set its SILLocation and
DebugScope to an empty FileLocation. Once mandatory inliner sets the SILLocation
to the location of ApplyInst, a null SILLocation and a null DebugScope
may work for a deserialized SILFunction.
Update testing cases to reflect that we are now inlining transparent functions
from modules, or to disable SILDeserializer for now (I am not sure how to update
those testing cases).
Swift SVN r8582
Add serialization/deserialization of the following SILInstructions:
BuiltinFunctionRefInst, IndexRawPointerInst, ModuleInst,
Conversion instructions:
RefToObjectPointerInst, UpcastInst, CoerceInst, AddressToPointerInst,
PointerToAddressInst, ObjectPointerToRefInst, RefToRawPointerInst,
RawPointerToRefInst, RefToUnownedInst, UnownedToRefInst
DestroyAddrInst, LoadInst, StrongReleaseInst, StrongRetainInst,
TupleElementAddrInst, TupleExtractInst
Make getModule in ModuleFile public to be used by SILDeserializer, also
make addModuleRef in Serializer public to be used by SILSerializer.
Update testing case to cover the above SILInstructions.
Swift SVN r8372
Use a worklist in SIL linking to traverse the newly serialized SILFunction.
Add serialization/deserialization of the following SILInstructions:
AllocArray, Apply, FunctionRef, IntegerLiteral, Metatype, StructExtract,
Struct and Tuple.
Make getDecl and getIdentifier in ModuleFile public to be used by
SILDeserializer, also make addDeclRef and addIdentifierRef in Serializer
public to be used by SILSerializer.
Update testing case to cover the above SILInstructions.
TODO: lookupSILFunction should replace the existing empty SILFunction instead
of creating a new SILFunction.
Swift SVN r8339
few SIL instructions types.
This will be tested when we have a SIL deserializer. Testing cases covering
each implemented SIL instruction will be added.
Swift SVN r8094
Add SerializeSIL.cpp for basic implementation of a SIL serializer.
serialize, serializeToStream, Serializer::writeToStream, and
Serializer::writeTranslationUnit all take an additional SILModule to pass it
to Serializer::writeSILFunctions.
Serializer::writeSILFunctions goes through all SILFunctions in a SILModule, and
serializes all SILFunctions that are transparent.
Swift SVN r7875
