I need to add in the non-lazy linking pass before I can properly test
this. But I did not want to leave this bug in the wild. Expect the test
in the next bit.
Swift SVN r15544
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 means that every witness table in a SILModule must be in the
protocol conformance -> witness table map. We still return nullptr if
there is no such witness table.
Swift SVN r15399
This also teaches IRGen not to emit WitnessTable declarations. This
causes them to be left as unknown symbols in the resulting executable.
Swift SVN r15361
The if statement therein was just going to keep getting bigger and
bigger especially since I am going to add support for witness_method
among other things.
Swift SVN r15360
This reverts commit r14623. I will recommit this when I reenable deserialization
of witness tables/vtables. This will enable the deserialization of SILFunctions
by default from the stdlib by avoiding the lack of external witness
tables/vtables.
Swift SVN r14786
Some recent work done by John have unblocked deserialization of SILFunctions. We
still can not properly deserialize witness tables/vtables but enabling by
default deserialization of SILFunctions from the stdlib is a good first step
toward reaching our performance goals.
There will be forthcoming commits which removes Benchmarks.swift and all of the
infrastructure we have in place for compiling benchmarks in the standard
library.
Swift SVN r14750
Right now it is not wired up. That is coming in forthcoming commits. I am trying
to be very incremental about this.
This series of patches will fix an assertion triggered by us not deserializing
functions from vtables appropriately. Doing linking lazily fixes that issue and
does the "right thing".
The work is being done in consultation with John, Joe, and Jordan.
Swift SVN r14479
Don't try to set the generic params of a reabstraction thunk until we've established it hasn't already been defined, fixing an issue where the same generic reabstraction pattern occurred in different contexts and we ended up clobbering the archetypes of a thunk that was already defined in terms of other archetypes.
Swift SVN r13964
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
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
Even if the type is the DeclaredTypeInContext of the nominal, we still want the substitution list for generic specialization. Ideally the AST would always have a SpecializedProtocolConformance when we refer to a generic type instance, but our representation makes that difficult.
Swift SVN r12887
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
Ideally this wouldn't be necessary, but the type substitution APIs required by generic specialization and SIL verification currently require a Module* pointer, and it's obnoxious to have to pass it down separately everywhere it's needed. Longer-term the reliance on Modules for type substitution might be able to go away.
Swift SVN r9866
to interpose on the SIL linking process. Under the
following conditions:
- a function is called by the current SILModule;
- that function is transparent and empty in the
generated SIL;
- the SIL linker doesn't find a serialized
version of it; and
- the external client (right now, LLDB) has a
SILExternalSource installed in the SILModule;
the SIL linker will query the SILExternalSource
via lookupSILFunction.
This interface will be used by LLDB to provide
SIL accessors for a program's variables when they
are referred to by Swift expressions.
Swift SVN r9452
This reverts r8624 and compensates by passing the TU to the SILModule printer when needed.
This addresses concerns that Jordan and Sean had raised.
Swift SVN r8678
Make the functions support a wider range of builtins and store types to make
it possible.
This is an optimization - the cached ID will be used for builtin identification,
instead of retrieval of the string name and using it as the key.
Swift SVN r7390
The cache is stored in the SILModule.
Add getIntrinsicID() as a member of BuiltinFunctionRefInst.
Test by using the new method in the CCP pass.
Swift SVN r7311
Modules can be in either 'Raw' or 'Canonical' form, with different invariants on each. We don't actually distinguish those invariants yet, but this patch adds the field to SILModule and adds a "sil_stage" declaration to SIL printer/parser syntax.
Swift SVN r6793
If -nsstring-is-string is enabled, lower Strings in cc(c) and cc(objc) function types to NSString, and when calling them, insert calls to StringToNSString/NSStringToString to perform the bridging conversion.
This isn't quite ready for prime-time yet, because we still need to emit the inverse bridging for ObjC method thunks, and I haven't tested the IRGen end of things yet.
Swift SVN r5355
Generate and cache SILFunctionTypeInfo from Swift types on the fly, and simplify the SILType representation down to a CanType and isAddress bit.
Swift SVN r5298
This frees up an extra bit in SILType, which we can expose to LLVM through
PointerLikeTypeTraits. Use this bit in a PointerUnion, which allows simplifying
ValueBase, which happened to be the last use of the isInvalid() state.
Swift SVN r5218
