This reverts commit 1b3d29a163, reversing
changes made to b32424953e.
We're seeing a handful of issues from turning on inlining of generics,
so I'm reverting to unblock the bots.
The reason we are using the parsing heuristic is to ensure that we do
not need to update a ton of test cases. This makes sense since in
general, when parsing we are creating new code that is running for the
first time through the compiler. On the other hand, in
serialization/deserialization we expect to get back exactly the
SILFunction that we serialized. So it makes sense to explicitly
preserve whether we have ownership qualification or not.
rdar://28851920
Over the past day or so I have been thinking about how we are going to need to
manage verification of semantic ARC semantics in the pass pipeline. Specifically
the Eliminator pass really needs to be a function pass to ensure that we can
transparently put it at any stage of the optimization pipeline. This means that
just having a flag on the SILVerifier that states whether or not ownership is
enabled is not sufficient for our purposes. Instead, while staging in the SIL
ownership model, we need a bit on all SILFunctions to state whether the function
has been run through the ownership model eliminator so that the verifier can
ensure that we are in a world with "SIL ownership" or in a world without "SIL
ownership", never in a world with only some "SIL ownership" instructions. We
embed this distinction in SIL by creating the concept of a function with
"qualified ownership" and a function with "unqualified ownership".
Define a function with "qualified ownership" as a function that contains no
instructions with "unqualified ownership" (i.e. unqualified load) and a function
with "unqualified ownership" as a function containing such no "ownership
qualified" instructions (i.e. load [copy]) and at least 1 unqualified ownership
instruction.
This commit embeds this distinction into SILFunction in a manner that is
transparently ignored when compiling with SIL ownership disabled. This is done
by representing qualified or unqualified ownership via an optional Boolean on
SILFunction. If the Boolean is None, then SILOwnership is not enabled and the
verifier/passes can work as appropriate. If the Boolean is not None, then it
states whether or not the function has been run through the Ownership Model
Eliminator and thus what invariants the verifier should enforce.
How does this concept flow through the compilation pipeline for functions in a
given module? When SIL Ownership is enabled, all SILFunctions that are produced
in a given module start with "qualified ownership" allowing them to contain SIL
ownership instructions. After the Ownership Model eliminator has run, the
Ownership Model sets the "unqualified" ownership flag on the SILFunction stating
that no more ownership qualified instructions are allowed to be seen in the
given function.
But what about functions that are parsed or are deserialized from another
module? Luckily, given the manner in which we have categories our functions, we
can categorize functions directly without needing to add anything to the parser
or to the deserializer. This is done by enforcing that it is illegal to have a
function with qualified ownership and unqualified ownership instructions and
asserting that functions without either are considered qualified.
rdar://28685236
My earlier patch started serializing SIL basic blocks using the RPOT order. While it works, changing the existing order of BBs during the serialization may be very surprising for users. After all, serialization is not supposed to transform the code.
Therefore, this patch follows a different approach. It uses the existing order of BBs during the serialization. When it deserializes SIL and detects a use of an opened archetype before its definition, it basically introduced a forward definition of this opened archetype. Later on, when the actual definition of the opened archetype is found, it replaces the forward definition. There is a correctness check at the end of a SIL function deserialization, which verifies that there are no forward definitions of opened archetypes left unresoved.
Till now there was no way in SIL to explicitly express a dependency of an instruction on any opened archetypes used by it. This was a cause of many errors and correctness issues. In many cases the code was moved around without taking into account these dependencies, which resulted in breaking the invariant that any uses of an opened archetype should be dominated by the definition of this archetype.
This patch does the following:
- Map opened archetypes to the instructions defining them, i.e. to open_existential instructions.
- Introduce a helper class SILOpenedArchetypesTracker for creating and maintaining such mappings.
- Introduce a helper class SILOpenedArchetypesState for providing a read-only API for looking up available opened archetypes.
- Each SIL instruction which uses an opened archetype as a type gets an additional opened archetype operand representing a dependency of the instruction on this archetype. These opened archetypes operands are an in-memory representation. They are not serialized. Instead, they are re-constructed when reading binary or textual SIL files.
- SILVerifier was extended to conduct more thorough checks related to the usage of opened archetypes.
Till now there was no way in SIL to explicitly express a dependency of an instruction on any opened archetypes used by it. This was a cause of many errors and correctness issues. In many cases the code was moved around without taking into account these dependencies, which resulted in breaking the invariant that any uses of an opened archetype should be dominated by the definition of this archetype.
This patch does the following:
- Map opened archetypes to the instructions defining them, i.e. to open_existential instructions.
- Introduce a helper class SILOpenedArchetypesTracker for creating and maintaining such mappings.
- Introduce a helper class SILOpenedArchetypesState for providing a read-only API for looking up available opened archetypes.
- Each SIL instruction which uses an opened archetype as a type gets an additional opened archetype operand representing a dependency of the instruction on this archetype. These opened archetypes operands are an in-memory representation. They are not serialized. Instead, they are re-constructed when reading binary or textual SIL files.
- SILVerifier was extended to conduct more thorough checks related to the usage of opened archetypes.
Till now there was no way in SIL to explicitly express a dependency of an instruction on any opened archetypes used by it. This was a cause of many errors and correctness issues. In many cases the code was moved around without taking into account these dependencies, which resulted in breaking the invariant that any uses of an opened archetype should be dominated by the definition of this archetype.
This patch does the following:
- Map opened archetypes to the instructions defining them, i.e. to open_existential instructions.
- Introduce a helper class SILOpenedArchetypesTracker for creating and maintaining such mappings.
- Introduce a helper class SILOpenedArchetypesState for providing a read-only API for looking up available opened archetypes.
- Each SIL instruction which uses an opened archetype as a type gets an additional opened archetype operand representing a dependency of the instruction on this archetype. These opened archetypes operands are an in-memory representation. They are not serialized. Instead, they are re-constructed when reading binary or textual SIL files.
- SILVerifier was extended to conduct more thorough checks related to the usage of opened archetypes.
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.
As there are no instructions left which produce multiple result values, this is a NFC regarding the generated SIL and generated code.
Although this commit is large, most changes are straightforward adoptions to the changes in the ValueBase and SILValue classes.
This shouldn't affect anything in practice but it's best to be deterministic.
(Although I'm not sure why the previous mode was nondeterministic.)
Swift SVN r28580
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
We currently do not serialize the body of global addressors. To make
"sil-opt swiftmodule" pass verification, we change the linkage for
the deserialized empty global addressors from public to public external.
rdar://18021024
Swift SVN r22370
Mandatory-inlined (aka transparent functions) are still treated as if they
had the location and scope of the call site. <rdar://problem/14845844>
Support inline scopes once we have an optimizing SIL-based inliner
Patch by Adrian Prantl.
Swift SVN r18835
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
The on-disk hashtable is moving from clang to llvm. This updates some
consumers for the new path and namespace. I've also shortened the
make_range(data_begin(), data_end()) calls on the hash table to just
use data().
Swift SVN r16537
OnDiskIterableChainedHashTable interface introduced in CFE 206189.
Thanks to Justin for guiding me through this!
The test-failures I was worried about after I originally committed this
turned out to be unrelated.
Swift SVN r16340
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
This fixes a bug where we were deserializing a function with a call to a shared
linkage function. The shared linkage function was never deserialized causing an
assertion to fire due to shared linkage functions always needing a definition.
I am planning on implementing lazy deserialization of vtable functions.
Swift SVN r14581
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
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
SILFunction is null.
When the input SILFunction is null, we create a SILFunction. A null input
SILFunction can happen when deserializing SILVTable.
Swift SVN r9736
