accessors.
Optimize these accessors by making them check for
BoundGenericXType instead of BoundGenericType and dyn_cast'ing
the Decl. (The latter used to be necessary before we split
BoundGenericType.)
Swift SVN r15037
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
This builtin returns true for types that might be ObjC class types. We want to use this builtin to optimize away NSArray handling for non-object Array types, so it needs to persist in SIL long enough for specialization to do its thing, but we never actually want to pay a runtime cost for this check, so always lower it to a constant value at IRGen time. Handle this by having canBeObjCClass return a tri-state "yes/maybe/no" result. In SILGen, we only fold away obviously "yes" or "no" cases, and in IRGen, we fold away "maybe" cases as "yes".
The optimizer will need to learn about this builtin too, but that part isn't done yet.
Swift SVN r13980
Add a 'Block' ExtraData kind, and teach IRGen how to pull the invocation pointer out of a block structure and pass the block object in the right place.
Swift SVN r13940
Adds generation of signext/zeroext for return value and arguments when
generating C/ObjC entrypoints.
<rdar://problem/16056735> tracks doing this more generally for call
sites as well as for native entrypoints.
Swift SVN r13862
Updates to signature expansion, entrypoint lowering, and callsite
lowering so that each selects the ABI types for all arguments at once
rather than an argument at a time (as well as considering whether the
return value is returned indirectly). This is required to get the
correct behavior in cases where we run out of argument registers and
need to pass arguments as indirect byvals.
This is mostly just refactoring existing code to move loops inside inner
functions as well as dealing with return values at the same time as
arguments.
Swift SVN r13781
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
