It it now possible to check if a function with a given name and a given linkage exists in one of the modules,
even if the current module contains a function with this name but a difference linkage.
This is useful e.g. for performing a lookup of pre-specializations.
These APIs are useful e.g. for quickly finding pre-specialisations by their names.
The existence check is very light-weight and does not try to deserialize bodies of SIL functions.
This feature is required for the implementation of pre-specialization, because one needs to check if a specialized SIL function with a given name exists in the standard library.
Swift SVN r30307
Before, providing a full SILFunction declaration object with a proper SILType was the only way to link a function. And constructing such a SILFunction declaration by hand using low-level SIL APIs is very annoying and requires a lot of code to be written. This new linkFunction API allows for a lookup using SILDeclRef and essentially performs linking of a SILFunction by its mangled name (assuming this name is unique), which is much easier to invoke. The new API is useful, e.g. when you need to link a well-known function from a standard library.
Swift SVN r26252
Also into a separate file.
Before (swift/Serialization/SerializedModuleLoader.h):
ModuleStatus
SerializedModuleLoader::ValidationInfo
SerializedModuleLoader::ExtendedValidationInfo
SerializedModuleLoader::isSerializedAST
SerializedModuleLoader::validateSerializedAST
After (swift/Serialization/Validation.h):
serialization::Status
serialization::ValidationInfo
serialization::ExtendedValidationInfo
serialization::isSerializedAST
serialization::validateSerializedAST
No functionality change, just a lot of renaming and a bit of reorganizing.
Swift SVN r25226
The deserializer holds a reference to the deserialized SILFunction, which
prevents Dead Function Elimination from erasing them.
We have a tradeoff on how often we should clean up the unused deserialized
SILFunctions. If we clean up at every optimization iteration, we may
end up deserializing the same SILFunction multiple times. For now, we clean
up only after we are done with the optimization iteration.
rdar://17046033
Swift SVN r18697
It is reasonable that one module has a declaration for a SILFunction while
another module has the definition. We return from lookupSILFunction when
we find a definition and keep looking when a declaration is found from
a module.
rdar://16815627
Swift SVN r17586
This patch adds in the necessary infrastructure for lazily deserializing
witness tables. This is done by following the same approach as the
deserialization/serialization of SILFunction.
Now if one calls SILModule::lookUpWitnessTable and the given witness table is a
definition, the SILModule will attempt to deserialize it from one of the other
modules.
Swift SVN r15403
getAll deserializes all SIL (except for globals). This enables us to iterate
over the SILModules once instead of once for first SILFunctions, then VTables,
then WitnessTables which is just inefficient.
Swift SVN r14176
We add two records in sil_block to specify a witness table record and a method
entry record. Out of the four entry types, only "Method" is handled in this
commit.
Two records are also added to sil_index_block to search for a specific witness
table given a unique identifier. The interface lookupWitnessTable is not
implemented yet.
Right now, we serialize a witness table only when sil-serialize-all is on and
deserialize all witness tables in the module when sil-link-all is on.
rdar://15722175
Swift SVN r13000
In general, this forces SILGen and IRGen code that's grabbing
a declaration to state whether it's doing so to define it.
Change SIL serialization to serialize the linkage of functions
and global variables, which means also serializing declarations.
Change the deserializer to use this stored linkage, even when
only deserializing a declaration, and to call a callback to
inform the client that it has deserialized a new entity.
Take advantage of that callback in the linking pass to alter
the deserialized linkage as appropriate for the fact that we
imported the declaration. This computation should really take
advantage of the relationship between modules, but currently
it does not.
Swift SVN r12090
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
Part of the FileUnit restructuring. A serialized module is now represented as
a TranslationUnit containing a single SerializedASTFile.
As part of this change, the FileUnit interface has been made virtual, rather
than switching on the Kind in every accessor. We think the operations
performed on files are sufficiently high-level that this shouldn't affect us.
A nice side effect of all this is that we now properly model the visibility
of modules imported into source files. Previously, we would always consider
the top-level imports of all files within a target, whether re-exported or
not.
We may still end up wanting to distinguish properties of a complete Swift
module file from a partial AST file, but we can do that within
SerializedModuleLoader.
Swift SVN r10832
We add two records in sil_block to specify a Vtable and its entry list. Two
records are also added in sil_index_block for mapping from name to ID and
from ID to bit offset.
Two functions are added to SerializedSILLoader: to look up a specific VTable
given the class name or to deserialize all VTables in all SILModules. The latter
is mostly used for testing.
We serialize a VTable if the class is fragile and deserialize it via
SerializedSILLoader::lookupVTable.
Swift SVN r9746
Add command line argument -sil-link-all and -sil-serialize-all for testing
purpose.
Do not create new SILFunction for de-serialized SIL, instead update the
existing declaration with the de-serialized SILFunction.
Add testing case to cover partial_apply.
Swift SVN r8410
SerializedSILLoader to hold a list of SIL deserializers.
Also add an intial implementation of a linking pass that is run right after
SILGen to link the declaration of SILFunction to the actual definition in
the serialized module.
We add two blocks to the serialized module: a sil index block that
maps identifier to a function ID and also holds a list of function offsets,
and a sil block for the actual SILFunctions. We can probably use subblock
instead of two top-level blocks.
The serialization/de-serialization of the function hash table and the function
offsets are implemented. But we are missing handling of types (see FIXME in
the code).
ModuleFile::Serialized is made public to be used by SIL deserializer, as well
as ModuleFile::getType.
The SIL deserializer holds a pointer to the ModuleFile, it gets the sil cursor
and the sil index cursor from the ModuleFile. The other option is for SIL
deserializer to find the start of the two sil blocks within itself, thus having
less coupling with ModuleFile.
No testing case yet because we are missing handling of types.
Swift SVN r8206
