When projecting an existential into an opened archetype, bind the
archetype with metadata and witness tables extracted from the
existential. Tweak SILGen so that it doesn't destroy the opened
archetype value an extra two times.
Use an executable testcase to ensure end-to-end operation, because we
still don't have a parsable form existential projection to opened
archetype instructions.
Swift SVN r13755
Reapply r13532 fixes for dealing with arguments that should be exploded
for C/Obj-C functions.
This gets us a bit closer to properly generating the correct types for
arguments. The remaining piece is generating all the argument types at
once rather than one at a time, which also requires being able to always
generate Clang types for the Swift types we see in the signatures of
these functions.
Swift SVN r13638
This gets us a bit closer to properly generating the correct types for
arguments. The remaining piece is generating all the argument types at
once rather than one at a time.
That part cannot happen until we can always generate Clang types for
the Swift types we see in the signatures of these functions.
Swift SVN r13532
Currently only inline functions referenced from Swift source files, or
from the REPL, will get IR generated for them. Inline functions
referenced by other inline functions will require additional effort to
generate properly.
With this change we use the clang::CodeGenerator-created llvm::Module
for all IR generation in Swift. This is perhaps undesirable, but
unavoidable given the interface the public Clang APIs expose, which do
not allow for building a ModuleBuilder that borrows an existing
llvm::Module.
Also unfortunate is the hack to generate a UsedAttr for each imported
inline function, but the public Clang APIs do not provide a way to only
emit deferred decls without emitting other things (e.g. module flags
that conflict with what the Swift IRGen emits). Note that we do not do
IRGen for every inline function in the module - only the ones that the
importer pulls in, which appears to be only those transitively
referenced from Swift code.
Swift SVN r13134
I forgot to update this case from an implementation that doesn't work. Factor out the common implementation with the other cases and use it in both places. This enables the libraries and tests to build and run with -DSWIFT_RUNTIME_CHECKS=OFF.
Swift SVN r12609
Now that we unique equivalent archetypes and lower interface types from the AST, we can convert IRGen over to using the interface types of the SILFunctionType when expanding out an LLVM function signature.
Swift SVN r12566
We shouldn't store to one size and load as another, and shouldn't need
to handle things like truncation and extension of numeric types, either.
Swift SVN r12530
Previously we coerced only struct return types, but we actually need to
be able to coerce scalar types as well, e.g. differing pointer types
when the ABI type differs from the type used in the body of the
function.
Swift SVN r12527
Rename TypeInfo::isSingleRetainablePointer to TypeInfo::isSingleSwiftRetainablePointer, and add an isSingleUnknownRetainablePointer entry point to ask whether a type has any single-refcounted representation, native or not. Use that to provide the same nullable-pointer and pointer-with-tag optimizations for copying and destroying enums with ObjC payloads as we do for Swift class payloads.
Swift SVN r12410
In the long term we want more detailed configurability of runtime checks, but for our short-term performance work we just want a blanket on/off switch. Add a StripRuntimeChecks SIL pass that, as a start, converts invocations of checked overflow builtins to the equivalent unchecked builtins and kills cond_fails. Expose it through the compiler with a -disable-all-runtime-checks switch.
NB: I haven't tested building the stdlib or running the tests with the switch thrown yet.
Swift SVN r12379
A type may be treated as a by-value return in SIL but still be lowered to an indirect return in IR if it's big enough, so handle this case in the partial application forwarder. Fixes <rdar://problem/15826328>.
Swift SVN r12351
We want to be able to share this both for signature type generation and
Objective-C type encoding.
A separate implementation file will follow when I expand the
functionality for more than just imported struct types.
Swift SVN r12137
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
Teach SILGen to emit a -dealloc method that runs user code, destroys
instance variables, and then calls up to the superclass dealloc. Teach
IRGen to deal with Objective-C destructor methods and add -dealloc to
the instance method table.
There are a few things still wrong here: we're emitting both a Swift
destructor and -dealloc, even though only one of them should ever
actually be used. Additionally, instance variables shouldn't be
destroyed in -dealloc, but in .cxx_destruct, so they persist until the
last of the -dealloc methods is invoked.
Swift SVN r12115
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
In general, this forces SILGen and IRGen code that's grabbing
a declaration to state whether it's doing so to define it.
Change SIL serialization to serialize the linkage of functions
and global variables, which means also serializing declarations.
Change the deserializer to use this stored linkage, even when
only deserializing a declaration, and to call a callback to
inform the client that it has deserialized a new entity.
Take advantage of that callback in the linking pass to alter
the deserialized linkage as appropriate for the fact that we
imported the declaration. This computation should really take
advantage of the relationship between modules, but currently
it does not.
Swift SVN r12090
When partial_applying a generic we still need to handle trivial abstraction changes such as bitcasting pointers to archetypes at the IR level. Along with the previous commit this fixes <rdar://problem/15597271>.
Swift SVN r11621
We should be able to cut out another layer of IRGen grime now.
This does XFAIL one test, test/Prototypes/TextFormatting.swift, which fails because of a weird archetype ordering in a nested substitution list. This should get sorted out by switching to interface types, so I'm going to let it go until then.
Swift SVN r11618
Use the 'thin' bit set by SIL to decide whether a metatype lowers to an empty type or not. In GenPoly we still need to accommodate unlowered metatypes to keep protocol witnesses limping along; hopefully that code can be killed soon. With this change we now lower @cc(witness_method) consistently for static methods.
Swift SVN r11535
This change updates signature generation as well as IR generation for
calls and returns so that the correct ABI types are generated for the
results of @objc functions.
Swift SVN r11527
Add a new SourceKind for PolymorphicConvention, 'WitnessSelf', which always introduces a final 'Self' metadata argument to the signature and uses it to fulfill all of the generic parameters of the Self type, regardless of the SIL-level polymorphic signature of the function.
Swift SVN r11467
Derive the appropriate ExtraData for a SILFunctionType from its thinness and calling convention. Consider @!thin @cc(witness_method) as having ExtraData::Metatype. This should eliminate all of the unspoken gentleperson's agreements that let thin and witness functions survive IRGen currently when we can turn on SIL witness tables.
Swift SVN r11446
Reapply r11184 with fixes for makefile builds.
Use CodeGenABITypes to determine which return values should be indirect
in @objc methods.
Swift SVN r11226
