The principal difficulty here is that we need accessing the
value witness table for a type to be an efficient operation,
but there (obviously) isn't a VWT field for ObjC classes.
Placing this field after the metatype would tend to bloat
metatypes by quite a bit. Placing it before is best, but
it introduces an unfortunate difference between the address
point of a metatype and the address of the global symbol.
That, however, can be fixed with appropriate linker support.
Still, for now this is rather unfortunately over-subtle.
Swift SVN r3307
The motivations here are that (1) the parametric types
that actually need the 'self' argument don't necessarily
all want to do what tuples do and put the VWT relative
to the metatype at some definable offset and (2)
recovering type parameters from the metatype is much
better defined than also hopping some relationship back.
Plus this allows VWTs to be shared across instances of
generic types. Also, I'm going to need to add a VW
that takes a metatype, and consistency seems right here.
If keeping two values live is actually punishing, I
might have to reconsider this. But the VWT is at least
always recoverable from the metatype, so....
I ended up abstracting the thing that GenHeap was doing
in order to save archetypes for arrays, because I
needed it to save metatypes instead of VWTs and because
it really needed abstractin'.
Swift SVN r3096
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
This requires us to potentially copy the value witness tables for
generic struct types as part of computing layout, but that's not
the end of the world (although it will rely on a future patch
to split value witnesses out from protocol witness tables).
Oh, and add a value witness for stride, changing Builtin.strideof
to use that.
Swift SVN r2829
in with the new!
Random notes:
1. I had to XFAIL 4 IRGen tests; I'll file radars on them.
2. I preserved SliceStringByte and renamed it StringByteData because
it has some String-specific functionality.
3. There's a small IRGen patch included which fixes a couple of runtime
failures involving generic array new.
Swift SVN r2644
swift_retain calls. The pertinent difference is that the former can be
marked nocapture, allowing general LLVM optimizations more flexibility.
With this change, early-cse is able to zap 9 more instructions, and 3
more functions are able to be marked nocapture by functionattrs in the
stdlib.
Swift SVN r2043
match the actual entrypoints vended by the runtime:
1) there is no swift_slowRawAlloc
2) swift_deallocObject takes two arguments
Also, make all calls to swift_allocObject go through a common
function so that we can easily use optimized entrypoints if the
runtime provides them.
Swift SVN r1993
pointer TypeInfo more conveniently. Have this class return true for
isSingleRetainablePointer(). Further specialize the implementations
of the value witnesses so that we no longer ever require type-specific
witnesses for reference types.
Swift SVN r1900
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
heap allocations it makes, and switch swift_alloc over to pass
that pointer in as well as the alignment. Also, compute
whether a type is POD during its generation and cache that in
the object, and introduce a method on TypeInfo to destroy an
object in memory.
Swift SVN r1356
