layouts. Introduce new SIL instructions to initialize
and open existential metatype values.
Don't actually, y'know, lift any of the restriction on
existential metatypes; just pointlessly burn extra
memory storing them.
Swift SVN r22592
This is controlled by a new isWholeModule() attribute in SILModule.
It gives about 9% code size reduction on the benchmark executables.
For test-suite reasons it is currently not done for the stdlib.
Swift SVN r22491
This is off by default and is a modified version of r21996 (reverted in r22001).
Update SILGlobalOpt to remove "once" call from addressor and set the
InitializerF for SILGlboalVariable if legal.
For calls to addressor in non-cold block, we check the addressor to find out
the globalinit_func and the associated SILGlobalVariable. If legal, we set
InitializerF of SILGlobalVariable and remove "once" call from addressor.
The current rules for legality:
1> the addressor contains a single "once" call and it calls globalinit_func.
2> the globalinit_func is called by "once" from a single location.
When we inline the addressor, the globalinit_func will be called by "once"
from multiple locations. After we remove the "once" from the addressor, the
inlined version will mistakely initialize the global variable again.
3> the globalinit_func is trivial as defined by
SILGlobalVariable::canBeStaticInitializer().
Update IRGen to generate constant initializers for global variables with static
initializers (i.e non-null InitializerF).
Joe's suggestion on having the static initializer to return the result instead
of storing it is not implemented in this commit. But we do verify that a static
initializer has a single store to the global variable. The suggestion is tracked
in rdar://18382039.
Implement rdar://16621368, rdar://18169093.
Swift SVN r22083
instances of Swift subclasses of ObjC classes.
We were already doing this in the runtime. This patch
unhides the runtime's mask word (swift_isaMask) and makes
IR-gen take advantage of it when it can.
Swift SVN r21592
If a type has to be passed or returned resiliently, it
will necessarily be passed indirectly, which is already
represented in SILFunctionType. There is no need to
represent this as a separate channel of information.
NFC. Also fixes a problem where the signature cache
for ExtraData::Block was writing past the end of an
array (but into the storage for an adjacent array
which was fortunately never used).
ExtraData should also disappear as a concept, but we're
still relying on that for existential protocol witnesses.
Swift SVN r21548
This handles things like NSSwapHostLongLongToBig and MKMapRectMake that
are static inline functions that themselves call other static inline
functions.
<rdar://problem/17227237>
Swift SVN r21080
This allows IRGen to complain about types it doesn't know how to lower yet, while still recovering well enough not to take the compiler down with it. This reduces the common "unimplemented enum layout" error to be a mere error instead of a compiler crash.
Swift SVN r20773
functions, and make those functions memoize the result.
This memoization can be both threadsafe and extremely
fast because of the memory ordering rules of the platforms
we're targeting: x86 is very permissive, and ARM has a
very convenient address-dependence rule which happens to
exactly match the semantics we need.
Swift SVN r20381
This current fix will initialize all objective C classes with the objective C runtime when any ObjC classes are defined in expressions
<rdar://problem/16029117>
Swift SVN r18037
We no longer emit any unnecessary objects just because
you import Foundation/Cocoa/whatever, at least from
IRGen; SILGen still does a ton of useless extra work.
Swift SVN r16920
...I hope. It is frustrating that testing this effectively
seems to require a massively different build environment.
More of rdar://16565958.
Swift SVN r16468
We should also remove it from IRGen's Explosion API; IRGen
should always use maximal explosion, and SILGen will tell us
whether or not we need to put that in memory somewhere.
But that can be a later commit.
Swift SVN r14242
rdar://13013457
'import Cocoa' is still generating a ton of unnecessary
global metadata, which causes some unused VWTs to be built,
but at least we no longer generate tons of useless global
functions. At least, we don't in IR-gen --- we still do
all the SILGen work for them.
Swift SVN r14224
We're mostly not that bad about this right now, but lazy
emission is going to wreak havoc.
Note that SILGen itself doesn't really make very good decisions
about the order in which to emit functions, but step one
towards fixing that is actually respecting it.
Swift SVN r14200
Introduce the SIL instructions thick_to_objc_metatype and
objc_to_thick_metatype to convert between the 'thick' and
'Objective-C' representations of a metatype. Most of this code is
trivial support code for these conversions: printing, parsing,
(de-)serialization, etc., for which testing will come online in
subsequent patches or is incidental in other tests.
Lower Objective-C metatype values down to objc_class* at the IR level
and implement IRGen support for these SIL instructions. SIL-only test
case at the moment because SILGen never creates these instructions.
Swift SVN r14087
Prior to r13134, the modules being constructed for IRGen always used the
LLVM global context due to <rdar://problem/15283227>, but the interface
should really take this as a parameter rather than baking the behavior
into IRGen.
Swift SVN r13260
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
at the cost of not necessarily catching bugs on targets that
don't completely initialize the structure.
NFC except that the generic target is slightly more aggressive.
Swift SVN r12895
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
It was convenient to just assume that the SILModule defines
the deallocating destructor function. This should probably
be represented somehow in e.g. the sil_vtable instead of
being an implicit dependency.
Swift SVN r12412
When we're using Objective-C's memory allocation, emit .cxx_construct
methods whenever we have instance variables with in-class
initializers. Presently, these methods are just empty stubs.
Swift SVN r12211
The Objective-C runtime executes the .cxx_destruct method after the
last -dealloc has executed when destroying an object, allowing the
instance variables to remain live even after the subclass's
destructor/-dealloc has executed, which is important for memory
safety. This fixes the majority of <rdar://problem/15136592>.
Note that IRGenModule::getAddrOfIVarDestroyer() contains an egregious
hack to find the ivar destructor SIL function via a linear
search. We need a better way to find SIL functions that we know exist,
because LinkEntity does not suffice.
Swift SVN r12206
The Swift entry point is required for the Swift metadata, while the
Objective-C entry point goes into the Objective-C metadata. As part of
this, stop emitting the destroying destructor for classes that use
Objective-C allocation: it won't work anyway.
Swift SVN r12199
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
SIL instruction. Implement IR-gen support for same. Fix
the parsing of SIL string literals to properly unescape them.
SIL-gen still emits UTF8 literals unconditionally.
Swift SVN r11904
Although Cocoa.framework re-exports AppKit, Foundation, and CoreData, an
arbitrary library does not re-export most of its imports. Normally this
would be fine, but the Clang importer can pull in types too eagerly and
then generate thunks and wrappers for things we don't care about. At least
for now, return to the behavior of autolinking /anything/ that gets visibly
imported.
<rdar://problem/15705923>
Swift SVN r11844
SILGen eagerly produces witness tables for all of the conformances defined in the module, which is what we want in order to make them runtime-unique. Have IRGen follow suit. This should address a ton of radars about breakage with non-unique conformances once SIL witnesses are turned on. We will need some runtime machinery to handle witness tables with dependent fields, but since we currently ignore the associated type fields of witnesses, we can get away with emitting direct references to all witness tables for now.
Swift SVN r11608
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
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
