The current implementation of dealloc_stack in IR-gen is a
no-op, but that's very much wrong for types with non-trivial
local allocation requirements, e.g. archetypes. So we need
to be able to do non-trivial code here. However, that means
modeling both the buffer pointer and the allocated address
in SIL.
To make this more type-safe, introduce a SIL-specific
'[local_storage] T' type that represents the required
allocation for locally storing a T. alloc_stack now returns
one of those in additon to a *T, and dealloc_stack expects
the former.
IR-gen still implements dealloc_stack as a no-op, but
that's now easy to fix.
Swift SVN r6937
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783
Standardize on the more-common "superclass" and "subclass" terminology
throughout the compiler, rather than the odd mix of base/derived and
super/sub.
Also, have ClassDecl only store the Type of the superclass. Location
information will be part of the inheritance clause for parsed classes.
Swift SVN r6687
"SILConstant" doesn't really describe its role in SIL anymore, which is to provide a reference to a Swift declaration in a SIL instruction, such as a method or nominal type field.
Swift SVN r6559
The idea for now is that this is a SIL-only type used for
representing the storage of a weak or unowned reference.
Having it be its own type is pretty vital for reasonable
behavior in SIL and IR-generation, and it's likely that
this will surface into runtime metadata as well (hence
the mangling).
I've implemented a bunch of things that technically I don't
think are necessary if this stays out of the typechecker,
but it's easier to implement half-a-dozen "recurse into
the child type" methods now that it would be to find them
all later if we change our minds.
Swift SVN r6091
This adds builtin types Builtin.VecNxT, where N is a natural number
and T is a builtin type, which map down to the LLVM type <N x T>.
Update varous builtins to support vector arguments, e.g., binary
operations, comparisons, negation. Add InsertElement and
ExtractElement builtins for vectors.
On top of these builtins, add Vec4f and Vec4b structs to the standard
library, which provide 4xFloat and 4xBool vectors, respectively, with
basic support for arithmetic. These are mostly straw men, to be burned
down at our leisure.
Some issues as yet unresolved:
- Comparisons of Vec4f'ss are producing bogus Vec4b's, which I
haven't tracked down yet.
- We still don't support the shuffle builtin, although it should be
easy
- More testing!
Swift SVN r5820
Provide TypeInfo for class-bounded existentials, which represents them as an explosion comprising one witness table per subscribed protocol and then the class instance pointer as an ObjC-refcounted pointer. Provide lowerings for the SIL instructions that manipulate class-bounded existentials (except for existential-to-existential erasures, which aren't critical to getting basic operations working and will need some abstraction remapping to deal with class-bounded-to-opaque upcasts aside from the representation change).
Swift SVN r5579
We were using _TMdT_ as a type metadata pointer, but it's really a full metadata symbol we need to offset to get the type metadata address.
Swift SVN r5376
by the LLVM IR optimizer. Tuple metadata refs are now largely
readnone, function metadata refs are already readnone. There may be some
left that are not, but they can be handled later.
Swift SVN r5071
that handle the 2/3 element cases specially. These are not actually
optimized at the moment (they just call into swift_getTupleTypeMetadata)
but this could be done at some point.
This is a win for a couple reasons: this reduces the amount of code generated
inline and it allows swift_getTupleTypeMetadata2/3 to be marked readnone,
enabling CSE. As a driveby, optimize metadata refs of zero element tuples
to directly use _TMdT_, eliminating a branch from swift_getTupleTypeMetadata.
Swift SVN r5070
Represent protocol 'P.metatype' types using the type metadata of the contained metatype. Emit 'typeof' value witnesses for protocol types that project the existential container buffer and then call the 'typeof' witness for the contained value. Implement the SIL protocol_metatype instruction the same way.
You can't quite call static methods on protocols yet because protocol_method doesn't know how to look up static methods from an existential metatype yet.
This breaks references to protocol names—they will try to create an existential metatype that refers to the metadata of the protocol type itself, rather than to the metadata of a conforming type. <rdar://problem/13438779> would fix them.
Swift SVN r5033
John talked me out of this. We still want to cache metadata at the BB level, because even with SIL GVN, there are potentially redundant metadata bits at a level SIL doesn't know about.
Swift SVN r5030
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
Emit ObjC stubs and categories for methods defined in extensions of ObjC-compatible classes. This makes extensions of ObjC classes available to ObjC in statically compiled code. For immediate-mode code we'll still need to dynamically register extension methods using the ObjC runtime.
Swift SVN r4149
As Doug points out, we won't regress here. All Objective-C runtimes we care
about are correctly ignoring this bit.
<rdar://problem/13065246>
Swift SVN r4052
Push LLVM attribute generation from expandAbstractCC into getFunctionSignature and CallEmission so that they can generate sret and/or byval attributes per-argument according to the calling convention. Copy our bogus rule for emitting sret returns (more than three elements in the explosion) and reuse it to pass large struct values as byvals rather than as explosions. This should be good enough to get both 'NSRect' and
'NSRange', 'NSSize' etc. to pass correctly to ObjC methods. Next step is to set the AbstractCC correctly for imported func decls so that standalone C functions follow the same bogus rule.
Swift SVN r3993
While we don't have a model for overriding methods in Swift extensions yet,
overriding category methods is exactly like overriding any other Objective-C
method, and we shouldn't disallow it.
Swift SVN r3985
ObjC methods always need to be invoked through objc_msgSend, so they shouldn't have vtable slots, and Swift subclasses that override ObjC methods should always insert override slots into their vtables.
Swift SVN r3889
ObviouslUilabilityMacros.h is not the way to go when we're building against
10.9 SDKs on 10.8 systems. Since this is a temporary hack anyway, just make
it based on the the host syatem ake configuration time, and disable the
failing tests on 10.9.
Swift SVN r3851
The libobjc in current builds can't handle it. <rdar://problem/13046897>
We are going to want this bit set, though, so this hack should be
removed once a new libobjc is available. <rdar://problem/13065246>
Swift SVN r3839
and non-deallocating destructors and allocating/non-allocating
constructors.
Non-deallocating destructors might not play well with ObjC
classes; we might have to limit them to pure-swift hierarchies.
No functionality change except that I decided to not force
destructors to have internal linkage unconditionally.
Swift SVN r3814
The ObjC ABI requires these class fields to be initialized by
resolving symbols from the runtime. So this is a historical
requirement. Note that there is a desire to optimize this
even for ObjC, because in a project with many classes, these
can actually end up representing a significant fraction of
the external non-lazy relocations in the linked image. But
for now we follow the spec, as we must.
The ObjC ABI requires these to be taken from the runtime,
although there is an effort to make them not require external
relocations like this, since in large projects it can actually
add up to a large percentage of the non-lazy external relocs.
3,6d
2i
Swift SVN r3804
Archetypes and projected existentials have the type %swift.opaque* and not i8*, so I need a corresponding SIL type to be able to model the ProjectExistential operation. We might also end up needing the builtin type for other low-level things down the line.
Swift SVN r3793
The test changes are that we're setting a class body on
some types that we weren't before. For some of these,
this is okay; for others, it's more questionable, but
ultimately not *harmful*.
Swift SVN r3746
