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
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
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
For dynamic generic types, this emits the sequence of operations to turn a value witness table template into a full, valid value witness table. For now, leave it stubbed out as empty, except for dynamic singleton unions, where we copy the size, flags, and stride from the lone element's table.
Swift SVN r8014
Dynamic forms of these methods will ultimately move to the fully general TypeInfo class, but for now I'm focusing on getting fixed-layout unions working. Set up methods on FixedTypeInfo for getting the fixed count of extra inhabitants and the spare bit mask for a type. Have the default implementation of extra inhabitants count use the spare bits. For now, only actually set spare bits for types with IR-level single scalar non-power-of-two integer representation (e.g., i1, or i21).
Swift SVN r7289
the new LoadableTypeInfo refinement interface.
This protects against bugs which would introduce unbalanced
allocations of temporary memory.
Swift SVN r7227
handling non-fixed layouts.
This uncovered a bug where we weren't rounding up the header
size to the element alignment when allocating an array of archetypes.
Writing up a detailed test case for *that* revealed that we were
never initializing the length field of heap arrays. Fixing that
caused a bunch of tests to crash trying to release stuff. So...
I've left this in a workaround state right now because I have to
catch a plane.
Swift SVN r4804
Implement ElementAddrInst for lvalue tuples, and implement the AllocArray, IndexAddr, and IntegerValue insts used to lower variadic tuples. (Actually compiling code that uses variadic tuples still requires support for SpecializeInst and generic functions.)
Swift SVN r3781
Implement SIL-to-IR lowering for allocation, deallocation, load, store, and branching instructions so that local variables and branching control flow can be used. Add a Fibonacci loop test to exercise the new instructions.
Swift SVN r3767
Add a path through IRGenModule to optionally codegen FuncDecls using their corresponding SIL Functions when constructed with a SILModule. Jury-rig an IRGenSILFunction subclass of IRGenFunction that does the bare minimum necessary to compile "hello world" from SIL. There are some impedance mismatches between irgen and SIL that need to be smoothed out, particularly the AST-dependent way irgen currently handles function calls. Nonetheless, `swift -sil-i hello.swift` works!
Swift SVN r3759
There is an apparent case where sema isn't computing the varargs injection function when it should (example 'd'), I'll look at that next.
Swift SVN r3028
This is kindof a pain in a few places where the type system
doesn't propagate canonicality. Also, member initializations
are always direct-initializations and so are allowed to use
explicit constructors, which is a hole in our canonicality
tracking. But overall I like the idea of always working
with canonical types.
Swift SVN r2893
analysis for patterns.
Major changes:
1. We no longer try to compute the types of functions in the parser.
2. The type of a function always matches the type of the argument patterns.
3. Every FuncDecl now has a corresponding FuncExpr; that FuncExpr might not
have a body, though.
4. We now use a new class "ExprHandle" so that both a pattern and a type
can hold a reference to the same expression.
Hopefully this will be a more reasonable foundation for further changes to
how we compute the types of FuncDecls in generics and for the implementation
of type location information.
Swift SVN r2370
level of IR struct type. At first we were emitting two layers
because structs were secretly tuples, and then more recently
we were emitting two layers to avoid having to adjust a bunch
of tests. Just bite the bullet now; it makes the IR a lot
cleaner, and it's never going to be easier.
Swift SVN r1824
It does seem silly for this to all be templated, but I couldn't
really see a very elegant solution given how I wanted things to
be genericized.
...interestingly, a ?t.t[] type would have done nicely for some
of this.
Swift SVN r1807
I'm not completely sure this is the representation we want, but it isn't much code to rip out if we decide to represent it some other way.
While I'm in the area, also fix a case where tuple->tuple conversion wasn't working.
Swift SVN r1748
first, we weren't registering the cleanup for the temporary
if it needed materialization, and second, we were potentially
double-consuming cleanups associated with the l-value, e.g.
subscript indices.
Swift SVN r1631
