LLDB needs this in order to accurately test enums that use extra inhabitants of aggregates, for which we don't guarantee that we set all of the bits to an exact value. Allows lldb to address <rdar://problem/17787682>.
Swift SVN r20527
Don't use spare bits on platforms that use ObjC tagged pointers when an enum payload involves a class-constrained existential, archetype, or ObjC-defined class type. If a payload is of a Swift-defined class type, we can still assume it's a real pointer and use its spare bits. Add an @unsafe_no_objc_tagged_pointer attribute that can be applied to protocols to denote that existentials bounded by that protocol can use spare bits; this is necessary to preserve the layout of bridged Array and Dictionary types, which should not be bound to tagged pointer types in practice (fingers crossed). Fixes <rdar://problem/16270219>.
Swift SVN r18781
We were miscalculating the number of empty-payload cases representable by each tag value and failing to lower cases after the first two. Fixes <rdar://problem/17025341>.
Swift SVN r18620
for extra inhabitants.
For structs in particular, this eliminates a major source
of abstraction penatlies. For example, an optional struct
containing an object pointer is now represented the same
way as an optional object pointer, which is critical for
correctly importing CF types as Unmanaged<T>!.
In time, we should generalize this to consider all elements
as sources for extra inhabitants, as well as exploiting
spare bits in the representation, but getting the
single-element case right really provides the bulk of the
benefit.
This commit restores r17242 and r17243 with a fix to use
value witnesses that actually forward the right type metadata
down. We were already generating these value witnesses in
the dependent struct VWT pattern, but I was being too clever
and trying to use the underlying value witness directly.
Swift SVN r17267
This reverts commit r17242. We can't simply forward tuple element extra
inhabitant witnesses for the same reason laid out in the previous commit.
Swift SVN r17252
This reverts commit r17243. We can't just forward the extra inhabitant payloads
from a field, because they will end up receiving metadata for the incorrect
type and crashing.
Swift SVN r17251
extra inhabitants.
Obviously this should eventually be generalized to
take from any element, but this is good enough to
give us zero-cost abstraction via single-field structs.
Contains some bugfixes for the tuple-extra-inhabitant
changes as well, because test coverage for optional
structs is obviously quite a bit richer than for
optional tuples.
All of this is leading towards unblocking IRGen for
importing CFStringRef as Unmanaged<CFString>!.
Swift SVN r17243
extra inhabitants.
This is obviously not as general as it should be,
but it actually helps a lot.
I started doing enums assuming it would teach me
something about how to do it for structs, and it
kindof worked.
Swift SVN r17242
In value witness table generation, and probably other places, we're inappropriately assuming that 'initializeWithTake' is equivalent to a memcpy in all cases, which isn't true for types that carry weak references or for potentially other types in the future. Add an 'isBitwiseTakable' property to TypeInfos that can be checked to see whether a type is bitwise-takable.
Swift SVN r16799
Use this node to capture the argument name and its source location in
the AST. We're only building these in one place at the moment; the
rest will be updated soon.
Swift SVN r16581
pointer first.
This most important effect of this is that accesses to that
field don't need to be dynamically offsetted past an arbitrary
number of value witnesses, which is pretty nice for the
generic value witnesses.
Swift SVN r16243
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
r12934 solved the memory corruption issues applying this optimization for String, so now we get a nice branchless implementation of its release operation:
__TwxxOVSs16ContiguousString5Owner:
00000000000828f0 pushq %rbp
00000000000828f1 movq %rsp, %rbp
00000000000828f4 movabsq $0x9fffffffffffffff, %rax
00000000000828fe andq (%rdi), %rax
0000000000082901 movq %rax, %rdi
0000000000082904 popq %rbp
0000000000082905 jmpq 0x881d0
Swift SVN r12937
with two kinds, and some more specific predicates that clients can use.
The notion of 'computed or not' isn't specific enough for how properties
are accessed. We already have problems with ObjC properties that are
stored but usually accessed through getters and setters, and a bool here
isn't helping matters.
NFC.
Swift SVN r12593
Retaining and releasing String's HeapBuffer with objc_retain/objc_release is causing mysterious heap corruption issues I haven't been able to sort out. Turn this off so it doesn't bite other people before we sort it out.
Swift SVN r12465
This is easier to emit optimal code for on our target platforms, and is more likely to find a contiguous range of spare bits to place the tag in.
Swift SVN r12435
Rename TypeInfo::isSingleRetainablePointer to TypeInfo::isSingleSwiftRetainablePointer, and add an isSingleUnknownRetainablePointer entry point to ask whether a type has any single-refcounted representation, native or not. Use that to provide the same nullable-pointer and pointer-with-tag optimizations for copying and destroying enums with ObjC payloads as we do for Swift class payloads.
Swift SVN r12410
We can copy and destroy enum values where all of the payloads are references by just masking out the tag bits and handing the pointer to swift_retain/swift_release, instead of creating a diamond. This could be generalized to aggregate payloads that all have refcounted pointers in the same place, and to mixed ObjC/Swift refcounted pointers, but this covers the "easy" case we can do with the layout info IRGen already tracks.
Swift SVN r12405
Only claim spare bits we actually use as tag bits in the result of getTagBitsForPayloadCases(), and fix up some crashers in corner cases. Add some assertions so these APIs get tested as part of normal compiler runs, and some DEBUG() macros so interested compiler users can see what enum layout is doing with -debug-only=enum-layout. This should also lead to slightly better codegen for some multi-payload enums because we don't pointlessly try to gather spare bits from the entire payload anymore, only the bits we actually need to discern the tag.
Swift SVN r12314
Export EnumImplStrategy from the GenEnum.h header, and add some accessors that LLDB or other interested parties can use to work out how an enum is laid out:
- getElementsWithPayload() and getElementsWithNoPayload(), to pick out the cases that were laid out as nonempty and empty (including those that are considered no-payload due to empty type optimization);
- getBitPatternForNoPayloadElement() to return the unique bit pattern representing a no-payload case; and
- getTagBitsForPayloads() to return the bitmask of the discriminator tag for payload cases.
Swift SVN r12269
Offer spare bits unused by a multi-payload enum to outer enums for tag bit layout. Additionally, if an enum spills tag bits, offer the unused bits in that extra tag byte as spare bits as well. This lets us recover the last spilled bit in String, getting it down to an optimal-for-its-current-definition 32 bytes.
Swift SVN r12192
When doing struct layout for fixed-layout structs or tuples, combine the spare bit masks of their elements to form the spare bit mask of the aggregate, treating padding between elements as spare bits as well.
For now, disable using these spare bits to form extra inhabitants for structs and tuples; we would need additional runtime work to expose these extra inhabitants for correct generic runtime behavior. This puts us in a weird situation where 'enum { case A(Struct), B, C }' spills a bit but 'enum { case A(Struct), B(Struct), C }' doesn't, but the work to make the former happen isn't immediately critical for String optimization.
Swift SVN r12165
IRGen type conversion is invariant with respect to archetypes with the same set of constraints, so instead of redundantly generating a TypeInfo object and IR type for Optional<T> for every T everywhere, key TypeInfo objects using an "exemplar type" that we form using a folding set to collapse together archetypes with the same class-ness, superclass constraint, and protocol constraints.
This is a nice memory and IR size optimization, but will be essential for correctness when lowering interface types, because there is no unique context to ground a dependent type, and we need to lower the same generic parameter with the same context requirements to the same type whenever we instantiate it in order for the IR to type-check.
In this revision, we profile the nested archetypes of each recursively, which I neglected to take into account originally in r12112, causing failures when archetypes that differed by associated type constraints were incorrectly collapsed.
Swift SVN r12116
IRGen type conversion is invariant with respect to archetypes with the same set of constraints, so instead of redundantly generating a TypeInfo object and IR type for Optional<T> for every T everywhere, key TypeInfo objects using an "exemplar type" that we form using a folding set to collapse together archetypes with the same class-ness, superclass constraint, and protocol constraints.
This is a nice memory and IR size optimization, but will be essential for correctness when lowering interface types, because there is no unique context to ground a dependent type, and we need to lower the same generic parameter with the same context requirements to the same type whenever we instantiate it in order for the IR to type-check.
Swift SVN r12112
It's wasteful and doesn't match the IR we actually emit for switching and injecting multi-payload enums. Fixes <rdar://problem/15759464>.
Swift SVN r12055
Split 'destructive_switch_enum_addr' into separate 'switch_enum_addr' and 'take_enum_data_addr' instructions. This should unblock some optimization work we would like to do with enums.
Swift SVN r12015
Emphasize the fact that this address is only intended for initialization. When we split destructive_switch_enum_addr, there will be another similar instruction for destructively taking the payload out of an already-initialized enum.
Swift SVN r12000
A single-payload enum with a single-refcounted-pointer payload and a single empty case will use a nullable pointer representation, which can be handled directly by swift_retain and swift_release. Take advantage of this to avoid some branching when copying or destroying values of this shape, such as T? for class T.
Swift SVN r10556
Start using null-page values as extra inhabitants when laying out single-payload enums that contain class pointers as their payload type. Don't use inhabitants that set the lowest bit, to avoid trampling potential ObjC tagged pointer representations. This means that 'T?' for class type T now has a null pointer representation. Enums with multiple empty cases, as well as nested enums like 'T??', should now have optimal representations for class type T as well.
Note that we don't yet expose extra inhabitants for aggregates that contain heap object references, such as structs with class fields, Swift function types, or class-bounded existentials (even when the existential has no witness tables).
Swift SVN r10061
Also, the extra inhabitant lookup for native Swift no-payload enums is inappropriate for C enums. For now, expose no extra inhabitants from C enums.
Swift SVN r10006
Borrow the scalar type of the raw type as the representation type of C enums, and use the raw values from C as the discriminator values of the cases.
Swift SVN r9988
The payload type of a dependent single-payload enum is "empty" but we still need to run its destructor. Oops. Fixes <rdar://problem/15383966>.
Swift SVN r9932
Its job will be a bit more broad for generic structs, where it needs to fill field offsets into the metadata in addition to storing the final size, stride, and alignment information to the value witness table.
Swift SVN r9104
