around in the deserializer's .
1,2d
1i
Bump the reference count of a SILFunction as long as it's sitting
around in the deserializer's cache.
If we deserialize a function, then delete it, then deserialize
another reference to it, we'll end up pointing to a deleted
function. This was causing the bug where IRGen would assert
with "no order number for SIL function definition?"; I can't
seem to find a radar for that, though.
Also, deserialization test cases are hard to write and probably
inherently unstable.
Swift SVN r15908
This will be a signal to ARC optimization, RVO, and other lifetime-affecting optimizations that they should not shorten the lifetime of a value past a certain point. We need this for C pointer bridging. This adds the instruction, but does not add any knowledge of it to the ARC optimizers.
Swift SVN r15601
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 will help with ensuring that we do not create multiple witness
table "definitions" one of which is null. That situtation yields an
IRGen assertion to be hit since the external declaration (in the guise
of a definition) has a different type from the actual deserialized
definition.
Swift SVN r14999
In the short term, we need to be able to emit shared symbols for SILWitnessTables corresponding to Clang-imported modules, and soon, the generic specializer will need to be able to reference *_external witness tables deserialized from library modules.
Swift SVN r14887
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
alloc_ref_dynamic allocates an instance of a class type based on the
value in its metatype operand. Start emitting these instructions for
the allocating constructor of a complete object initializer (not yet
tested) and for the allocating constructor synthesized for an imported
Objective-C init method.
Still missing:
- IRGen still does the same thing as alloc_ref right now. That
change will follow.
- There are devirtualization opportunities when we know the value of
the metatype that would turn an alloc_ref_dynamic into an alloc_ref;
I'm not planning to do this optimization.
Swift SVN r14560
It's not forming the metatype for the protocol type (exists t: P. t).metatype, it's forming the existential of a metatype of a conforming type, exists t: P. (t.metatype).
Swift SVN r14520
Having one instruction to get the dynamic metatype of a (non-existential) value makes more sense from a generic specialization standpoint and should stave off inevitable crashers when archetype_metatypes get specialized. protocol_metatype remains separate because metatype existentials are more interesting.
Swift SVN r14499
We were wantonly applying 'upcast' to archetypes in some cases, and really, that's OK, since these instructions do the same thing (and generic specialization could turn archetype_ref_to_super into upcast). Make everyone's life easier by folding archetype_to_super into upcast. Fixes <rdar://problem/16192324>.
Swift SVN r14496
With this commit, we can deserialize the stdlib. Still running into
issues related to linking that requires a consultation with John. That
will come in a later commit.
Swift SVN r14365
lowered field type of a ref_element_addr's parent projection, rather than using
the unlowered siltype generated via creating a SILType from the field's
vardecl.
Swift SVN r14294
We should also remove it from IRGen's Explosion API; IRGen
should always use maximal explosion, and SILGen will tell us
whether or not we need to put that in memory somewhere.
But that can be a later commit.
Swift SVN r14242
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
This enables us to lookup a function from a key by avoiding the need to create
an identifier inside the OnDiskHashTable structure. Doing so would require an
ASTContext, something that is not available therein.
As a side effect this also makes OnDiskHashTable more efficient by just using a
StringRef reference instead of creating a uniqued identifier in the AST for
every deserialized node in the table.
Swift SVN r14169
- Parameterize maybeReadGenericParams' BitstreamCursor so that we can read from
the correct cursor when trying to read the generic params of a SILFunction.
- Only serialize the context generic params for SILFunctions for which we're
serializing a complete definition. This fixes issues with us getting the
wrong archetypes forward-declared from references in other modules.
In this version of the patch, we adjust the deserialization point for the
generic param list to correctly come before we check if the SILFunction block
is empty, and we add a kludge to keep the JIT from crapping itself when it sees
the same transparent definition in multiple REPL lines' modules
<rdar://problem/16094902>.
The previous commit solves a problem this exposed at r14050 in inout deshadowing
that caused memory corruption when transparent functions were imported. This
should now be safe to commit.
Swift SVN r14109
Introduce the SIL instructions thick_to_objc_metatype and
objc_to_thick_metatype to convert between the 'thick' and
'Objective-C' representations of a metatype. Most of this code is
trivial support code for these conversions: printing, parsing,
(de-)serialization, etc., for which testing will come online in
subsequent patches or is incidental in other tests.
Lower Objective-C metatype values down to objc_class* at the IR level
and implement IRGen support for these SIL instructions. SIL-only test
case at the moment because SILGen never creates these instructions.
Swift SVN r14087
- Parameterize maybeReadGenericParams' BitstreamCursor so that we can read from the correct cursor when trying to read the generic params of a SILFunction.
- Only serialize the context generic params for SILFunctions for which we're serializing a complete definition. This fixes issues with us getting the wrong archetypes forward-declared from references in other modules.
In this version of the patch, we adjust the deserialization point for the generic param list to correctly come before we check if the SILFunction block is empty, and we add a kludge to keep the JIT from crapping itself when it sees the same transparent definition in multiple REPL lines' modules <rdar://problem/16094902>.
Swift SVN r14030
- Parameterize maybeReadGenericParams' BitstreamCursor so that we can read from the correct cursor when trying to read the generic params of a SILFunction.
- Only serialize the context generic params for SILFunctions for which we're serializing a complete definition. This fixes issues with us getting the wrong archetypes forward-declared from references in other modules.
This gets me a clean build when applied against r13984.
Swift SVN r14005
Previously, we would just parse vars and subscripts with no definitions,
then let getters and setters be referenced arbitrarily later. This was
problematic for a number of reasons, not least of which, the .sil file
might be invalid.
Instead, change sil to require that a protocol style definition indicate
whether a vardecl/subscript is computed or not, and whether it is both
get-able and set-able, e.g. like "var x : Int { get }". Change the
sil printer to print decls in this form, and change the SILParser to
make SILDeclRef::Func values instead of ::Getter/Setter values.
One thing that this exposed is that we weren't correctly serializing the
accessor state in modules, so accessors would get detatched from their
AbstractStorageDecls when deserialized (and in fact, their ASD never got
deserialized at all in some cases). Fix this in the serialization of
the accessors.
NFC, other than the SIL printer and parser.
Swift SVN r13884
Riding off of project_existential[_ref] was convenient, but the
resuls are used quite differently. Note that open_existential[_ref]
still don't print/parse reasonably yet.
Swift SVN r13878
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.
Compared to r13036, this version of the patch includes the decls_block RecordKind enumerators for the GENERIC_PARAM_LIST layouts in the sil_block RecordKind enumerator, as Jordan had suggested before. r13036 caused buildbot failures when building for iOS, but I am unable to reproduce those failures locally now.
Swift SVN r13485
