The only real change here is that module-wide IR (autolinking and ObjC
runtime flags) have been pushed up from emitTranslationUnit (now
emitSourceFile) to its only caller, performIRGeneration.
Swift SVN r9075
Start out with pointer spare bits, heap object alignment, null page size, and ObjC reserved bits, and provide static values for X86-64 and for a worst-case generic platform.
Swift SVN r7833
These value witness table entries will be conditionally available for types that support specialized union representation through extra inhabitants and/or spare bits and for union value witnesses:
- storeExtraInhabitant, to store an extra inhabitant representation;
- getExtraInhabitantIndex, to recognize an extra inhabitant representation;
- getUnionTag, to get a union's discriminator; and
- inplaceProjectUnionData, to extract the value in place from a union.
This just sets up the enumerators and related IR types and mangling; nothing emits these witnesses yet.
Swift SVN r7234
and lexical scopes, which can be enabled through the new -g option.
When -g is enabled, line tables and scopes compile all the way
down to DWARF.
Changes to SIL:
- In addition to a SILLocation, every instruction now also has a pointer
to a SILDebugScope (its containing lexical scope).
- Added LexicalScope, which is to be used for all Scopes we want to show
up in the debug info.
Swift SVN r5772
Use the new swift_dynamicCastIndirect runtime functions to implement casts from opaque archetype and existential types to concrete types.
Swift SVN r5684
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
method to handle function attributes, just pass in a list of function
attributes. Among other things, things that were formerly calling
createReadnoneRuntimeFunction to get nounwond, now make it explicit.
Swift SVN r5170
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
Emit the deallocObject runtime call inside the deallocating destructor for a heap object, instead of inside swift_release. This will allow for heap objects with known size to directly call fast deallocator entry points and potentially custom deallocators in the future.
Swift SVN r5027
To be able to get the dynamic type of a generic value, the 'typeof' operation needs to be part of the value witness for the type. Add 'typeof' to the value witness table layout, and in the runtime, provide standard typeof witnesses for static, Swift class, and ObjC class values.
Swift SVN r5013
Change the destroying destructor entry point ABI to take 'this' as the appropriate type instead of as %swift.refcounted. Emit the deallocating destructor in IRGen when we see the ClassDecl, not when we see the SILFunction for the destructor. This frees us from having to worry about whether a SILFunction came from a destructor decl. We won't be able to reconstruct that once SILFunctions are pre-mangled.
While we're here, repaint some bikesheds so it's clearer that SIL and SILGen work with the destroying destructor.
Swift SVN r4908
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
Per John's comments, make a GenericBox struct to represent the layout of a generic box allocation, move all the layout calculations into methods on GenericBox, and alter swift_deallocBox to take the type as an argument so that it's future-proofed for when we start special-casing certain types in allocBox.
Swift SVN r4613
Add a runtime function that, given a generic type metadata pointer, allocates a heap object capable of containing a value of that type. This is a first-pass implementation that always does the worst case thing of stuffing the type metadata into the box with the value and using its value witness table to size, align, and destroy the box. Use swift_allocBox to implement ArchetypeTypeInfo::allocate correctly for heap object allocations. This means SIL's alloc_box $T now works for archetypes, and a simple generics test now (almost) compiles through SIL!
Swift SVN r4599
For Objective-C super calls, build an objc_super struct value containing the receiver and class/metaclass object and pass it to objc_msgSendSuper2. For Swift super calls, emit a direct call to the super implementation.
Swift SVN r4023
In 10.9, the method cache now takes up two words, and the vtable is gone.
Code compiled statically will work fine, but runtime classes need to fill
the rest of the method cache with zero, instead of an address.
I tested this on 10.8 as well and it seems to do no harm.
Swift SVN r3910
IRGen was generating the exact same signature for the initializing/allocating constructors and destroying/deallocating destructors. Make it do the right thing by typing the initializing constructor as Swift T -> (...) -> T and the destroying destructor as LLVM void(%swift.refcounted*). (This will later change to '%swift.refcounted*(%swift.refcounted*)' pending some irgen/runtime cleanup.)
Swift SVN r3837
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
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
Introduce a new swift_dynamicCast pair that take in a general metatype
pointer, rather than the more specific class-metatype pointer used for
class downcasts, and grab the class out of that general metatype
pointer, which may actually be an Objective-C wrapper. This is
slightly slower, but it works for the super-to-archetype cases like
T(an_NSObject), where T can have either kind of metadata.
NSTypedArray<T> is actually run-time type checked now, yay!
Swift SVN r3564
This variant of swift_dynamicCast requires us to have data that's
guaranteed to be class metadata, but it's not always natural to
generate class metadata. No functionality change yet.
Swift SVN r3562
We add a new runtime entry point, swift_dynamicCastUnconditional(),
that aborts when the cast fails. We'll probably want to throw an
exception in the future, but this is fine for now.
Swift SVN r3554
Notably, there is still no support for +1 return values,
so we'll leak when doing alloc/init and so on; but this gets
the fundamentals in place. A lot of the extra stuff in here
is dealing with mapping between metatypes and class objects.
Swift SVN r3425
The interesting thing here is that we need runtime support in
order to generate references to metatypes for classes, mostly
because normal ObjC classes don't have all the information we want
in a metatype (which for now just means the VWT pointer).
We'll need to be able to reverse this mapping when finding a
class pointer to hand off to, say, an Objective-C class method,
of course.
Swift SVN r3424
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
