It's not clear if all of these are always initialized before their
uses, so it seems reasonable to default initialize them to
predictable behavior.
Swift SVN r17612
When deserializing, the serialized sil loader attempts to first lookup
from its SILModule the witness table to attempt to grab a witness table
declaration. Before this patch if the SILModule could not find it, it
would attempt to deserialize it. In certain edge cases this would cause
us to attempt to deserialize a function definition which violates the
invariant that that should never happen.
This patch adds an argument to SILModule::lookUpWitnessTable that
enables you to turn off the lazy deserialization behavior. The default
argument gives the current behavior which should be used everywhere
except for the deserializer.
Swift SVN r16740
An unsafe cast from a base to a derived class isn't really all that different from one from Builtin.NativeObject to an arbitrary class, so relax this pair of instructions to allow an arbitrary bitcast. This only combines the instructions; it doesn't attempt to simplify any codegen that was emitting round-trip casts before yet.
Swift SVN r16736
This allows the payload for a loadable enum to be unsafely projected without branching, enabling more enum optimizations when switch branches can be culled or when indirect enum code can be promoted.
Swift SVN r16729
This was part of the original weak design that
there was never any particular reason to rush the
implementation for. It's convenient to do this now
so that we can use it to implement Unmanaged<T> for
importing CF types.
Swift SVN r16693
The implied semantics are:
- side-effects can occur any time before the first invocation.
- all calls to the same global_init function have the same side-effects.
- any operation that may observe the initializer's side-effects must be
preceded by a call to the initializer.
This is currently true if the function is an addressor that was lazily
generated from a global variable access. Note that the initialization
function itself does not need this attribute. It is private and only
called within the addressor.
Swift SVN r16683
Give us a way to formally represent autoreleases in SIL separate from autoreleased returns, allowing us to lifetime-extend inner pointer parameters the lazy way and hopefully clean up some asmname hacks in the stdlib implementation too.
Swift SVN r16632
Before this fix, we can't deserialize any SILFunction with generic outer
parameters.
We do not have the decl associated with the generic parameter list at SIL level,
so instead of using a nullptr decl, we serialize the outer generic parameters
directly.
rdar://16630493
Swift SVN r16562
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
Add project_block_storage, to project the capture storage from within a block_storage, and init_block_storage_header, to represent filling out the block header.
Swift SVN r16358
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
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
