info for them and generally clean up the inline scope handling a bit.
Fix the debug scope handling for all clients of SILCloner, especially
the SIL-level spezializers and inliners.
This also adds a ton of additional assertions that will ensure that
future optimization passes won't mess with the debug info in a way that
could confuse the LLVM backend.
Swift SVN r18984
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
If a source file contains the main class for its module, then implicitly emit a top_level_code that invokes UIApplicationMain with the name of the marked class.
Swift SVN r18088
Pattern matching on whether or not the function was applied is fragile
in the face of various possible compositions in between the function_ref
and the apply (i.e. thin_to_thick_function as an example).
Lets be conservative and just always deserialize references to closures
during mandatory inlining when referenced via a function_ref so we avoid
this problem if additional instructions like this are added.
Swift SVN r17977
We now enforce via an assert that each witness table is unique and that
every protocol conformance that is referenceable from SIL must have a
witness table matched to it.
Also, I taught the linker that it should deserialize witness tables for
InitExistentialRefInst instructions, something that was missed before.
Swift SVN r17283
This is important since it enables one to analyze the type of the
conformance that the witness table implements which may be different
than the original type. This follows the precedent where we return the
Substitutions from the protocol conformance tree traversal.
Swift SVN r17220
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
Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
This enables us to get around timing issues when we create a SILModule before we
have finished loading all Swift Modules.
This manifested itself in sil-opt where we were unable to deserialize from the
standard library when optimizing a separate *.sil file.
Swift SVN r15670
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
