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
And we really want to take advantage of them in String's Owner enum so we don't waste space (<rdar://problem/15787975>). This gets the size of ContiguousUTF16Slice down to 24 bytes from 32.
Swift SVN r12119
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
If there's no script-mode file in a module, don't produce a top_level_code SILFunction for it, and don't consider emitting an LLVM global_ctor for it. We should never emit static constructors from user code anymore.
Swift SVN r11644
Remove the initialize_var instruction now that DI fully diagnoses initialization problems. Change String-to-NSString bridging to explicitly invoke String's default constructor; it was the last remaining user of initialize_var. Remove dead code to emit an implicit default constructor without a body.
Swift SVN r11066
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
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
Build a nominal type descriptor when we emit the metadata or generic metadata pattern for a nominal type, and put a reference into the formerly null slot in the struct or enum metadata. We need to make a place for them in class metadata; that'll come next.
Swift SVN r9492
- Change type attribute printing logic (in astprinter and the demangler)
to print in the new syntax
- Change the swift parser to only accept type attributes in the new syntax.
- Update canParseTypeTupleBody to lookahead over new-syntax type attributes.
- Update the testsuite to use the new syntax.
Swift SVN r9273
John noted that LLVM's ABI rules for Integers of Unusual Size cause them to be aligned like the largest native integer type even inside packed structs, making them unsuited for byte-accurate layout in cases where the payload is a non-power-of-two size, so we have to bite the bullet and lay them out as arrays of i8, bitcasting to the payload type to load and store the payload and tag parts.
This still colors outside of the lines a bit because loading or storing e.g. an i72 is going to touch an i128's worth of memory. Baby steps. It'd be nice to be able to load and reconsistute the i72 without having to load and mask together all of the individual bytes.
Swift SVN r9058
LLVM's normal data layout doesn't jive with our own StructLayout's more aggressive use of padding space, and causes problems such as <rdar://problem/14336903>. Because we do our own alignment and stride management, we can safely use LLVM packed struct types with manual padding to get the level of control we need to accurately reflect our desired struct layout.
Swift SVN r9056
If the enum gets laid out with a non-power-of-two payload and an extra tag, such as { i72, i2 }, then LLVM's natural location for the extra tag is going to be different from where we actually want it, so let's do our own byte offset calculation by bitcasting to i8* and gepping instead of trying to gep the struct directly.
Swift SVN r9023
