We can share a lookup cache entry under the generic metadata pattern when the witness table for a protocol conformance is shared among all instances of the type. (This happens to always be the case currently.)
Swift SVN r23062
Set up the basic logic for first looking into a cache then pulling in conformances from enqueued images and trying again for exact-matchable types (pretty much just nongeneric native value types).
Swift SVN r23053
The archetype builder is responsible for figuring out what should go
into a generic signature anyway, so move the generic signature
creation there. This will also allow us to eliminate some code
duplication across Sema and AST.
Fixes compiler crasher 033.
Swift SVN r23030
Set up lazy registration of a dyld add image callback that looks up the "__DATA,__swift1_proto" section in the loaded image. As a first-pass sanity check, just walk the section and dump the records.
Swift SVN r23025
This currently handles owned -> guaranteed argument conversion and dead argument
elimination.
RecursiveOwnedParameter||90.0%
ClassArrayGetter|||||||||23.3%
Life|||||||||||||||||||||16.7%
Prims||||||||||||||||||||11.2%
StringWalk|||||||||||||||5.7%
The next step is to implement SROA and address -> value optimizations.
rdar://16917049
Swift SVN r23023
Generic function signatures were including outer generic parameters,
but generic type signatures were not. This is a small part of the
problem with nested generics (in general), but also a useful cleanup
for generic signatures.
Swift SVN r23011
This will turn into "exactly" in a future commit, when we can build a
generic signature from an archetype builder (directly) and compare the
results.
Swift SVN r23010
without a valid SILDebugScope. An assertion in IRGenSIL prevents future
optimizations from regressing in this regard.
Introducing SILBuilderWithScope and SILBuilderwithPostprocess to ease the
transition.
This patch is large, but mostly mechanical.
<rdar://problem/18494573> Swift: Debugger is not stopping at the set breakpoint
Swift SVN r22978
If vtable or witness methods are never called, e.g. because they are completely devirtualized,
then they are removed from the tables and eliminated.
Another improvement of the new algorithm is that it is able to eliminate dead function cycles
(e.g. A() calls B() and vice versa).
Swift SVN r22969
canInstUseRefCountValues should have always been named
canInstNotUseRefCountValues. I don't remember how it get renamed as such. Even
though it is a little weird to have a "canNever" in a function name, it makes
sense here to contrast it with canUseValue which returns if a specific user can
use a ptr in a way that requires the ptr to be alive. This in contrast says that
a user can never use a ptr in a manner where the ptr must be alive. I.e. this is
a universal quantifier.
Swift SVN r22961
Per Joe, a low level retained-pointer-with-user-controlled-spare-bits
type would still be useful for space efficiency even on platforms that
don't need ObjC interop.
Swift SVN r22943
When we emit a witness table, build a protocol conformance record for it, and emit the list of all conformance records into a "__swift1_proto" section of the data segment.
Swift SVN r22939
This reverts r22923, which doesn't actually compile. The fix is probably
obvious (s/F/this/) but I didn't want to mess with it in case it's wrong.
Swift SVN r22933
We need to do this mainly to figure out when extensions can affect this file.
This is part of the intra-module dependency tracking work to implement
incremental rebuilds.
Part of rdar://problem/15353101
Swift SVN r22927
This tracks top-level qualified and unqualified lookups in the primary
source file, meaning we see all top-level names used in the file. This
is part of the intra-module dependency tracking work that can enable
incremental rebuilds.
This doesn't quite cover all of a file's dependencies. In particular, it
misses cases involving extensions defined in terms of typealiases, and
it doesn't yet track operator lookups. The whole scheme is also very
dependent on being used to track file-level dependencies; if C is a subclass
of B and B is a subclass of A, C doesn't appear to depend on A. It only
works because changing A will mark B as dirty.
Part of rdar://problem/15353101
Swift SVN r22925
Specifically:
1. Given a struct literal with only one stored non-trivial field, a ref count
operation on the struct is equivalent to a ref count operation on the field.
2. Given a tuple literal with only one non-trivial elt , a ref count
operation on the tuple is equivalent to a ref count operation on the elt.
3. Given a tuple_extract, if the tuple_extract is extracting the only
non-trivial element of the tuple, a ref count on the tuple_extract is equivalent
to a ref count on the original type.
rdar://18499023
Swift SVN r22902
We want to use the reserved space in the metadata pattern for protocol conformance caching, and this link lets us find the metadata pattern from an instance of the generic type.
Swift SVN r22898
Generated code on x86_64 for swift_retain and swift_release and
swift_allocObject are unchanged. arm64 is improved by using weaker
memory barriers, fixing rdar://17423624.
Swift SVN r22887
This is a type that has ownership of a reference while allowing access to the
spare bits inside the pointer, but which can also safely hold an ObjC tagged pointer
reference (with no spare bits of course). It additionally blesses one
Foundation-coordinated bit with the meaning of "has swift refcounting" in order
to get a faster short-circuit to native refcounting. It supports the following
builtin operations:
- Builtin.castToBridgeObject<T>(ref: T, bits: Builtin.Word) ->
Builtin.BridgeObject
Creates a BridgeObject that contains the bitwise-OR of the bit patterns of
"ref" and "bits". It is the user's responsibility to ensure "bits" doesn't
interfere with the reference identity of the resulting value. In other words,
it is undefined behavior unless:
castReferenceFromBridgeObject(castToBridgeObject(ref, bits)) === ref
This means "bits" must be zero if "ref" is a tagged pointer. If "ref" is a real
object pointer, "bits" must not have any non-spare bits set (unless they're
already set in the pointer value). The native discriminator bit may only be set
if the object is Swift-refcounted.
- Builtin.castReferenceFromBridgeObject<T>(bo: Builtin.BridgeObject) -> T
Extracts the reference from a BridgeObject.
- Builtin.castBitPatternFromBridgeObject(bo: Builtin.BridgeObject) -> Builtin.Word
Presents the bit pattern of a BridgeObject as a Word.
BridgeObject's bits are set up as follows on the various platforms:
i386, armv7:
No ObjC tagged pointers
Swift native refcounting flag bit: 0x0000_0001
Other available spare bits: 0x0000_0002
x86_64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0001
Swift native refcounting flag bit: 0x0000_0000_0000_0002
Other available spare bits: 0x7F00_0000_0000_0004
arm64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0000
Swift native refcounting flag bit: 0x4000_0000_0000_0000
Other available spare bits: 0x3F00_0000_0000_0007
TODO: BridgeObject doesn't present any extra inhabitants. It ought to at least provide null as an extra inhabitant for Optional.
Swift SVN r22880
This might not matter for the compiler, but both LLDB and SourceKit have to
deal with multiple ASTContexts and multiple SourceFiles all the time.
Swift SVN r22869
