Now the SILLinkage for functions and global variables is according to the swift visibility (private, internal or public).
In addition, the fact whether a function or global variable is considered as fragile, is kept in a separate flag at SIL level.
Previously the linkage was used for this (e.g. no inlining of less visible functions to more visible functions). But it had no effect,
because everything was public anyway.
For now this isFragile-flag is set for public transparent functions and for everything if a module is compiled with -sil-serialize-all,
i.e. for the stdlib.
For details see <rdar://problem/18201785> Set SILLinkage correctly and better handling of fragile functions.
The benefits of this change are:
*) Enable to eliminate unused private and internal functions
*) It should be possible now to use private in the stdlib
*) The symbol linkage is as one would expect (previously almost all symbols were public).
More details:
Specializations from fragile functions (e.g. from the stdlib) now get linkonce_odr,default
linkage instead of linkonce_odr,hidden, i.e. they have public visibility.
The reason is: if such a function is called from another fragile function (in the same module),
then it has to be visible from a third module, in case the fragile caller is inlined but not
the specialized function.
I had to update lots of test files, because many CHECK-LABEL lines include the linkage, which has changed.
The -sil-serialize-all option is now handled at SILGen and not at the Serializer.
This means that test files in sil format which are compiled with -sil-serialize-all
must have the [fragile] attribute set for all functions and globals.
The -disable-access-control option doesn't help anymore if the accessed module is not compiled
with -sil-serialize-all, because the linker will complain about unresolved symbols.
A final note: I tried to consider all the implications of this change, but it's not a low-risk change.
If you have any comments, please let me know.
Swift SVN r22215
Update SILGen to create SILGlobalVariable and SILGlobalAddrInst instead of
GlobalAddrInst. When we see a definition for a global variable, we create
the corrsponding SILGlobalVariable definition.
When creating SILGlobalVariable from a global VarDecl, we mangle the global
VarDecl in the same way as we mangle it at IRGen. The SILLinkage is also
set in the same way as we set it at IRGen.
At IRGen, we use the associated VarDecl for SILGlobalVariable if it exists,
to have better debugging information.
We set the initializer for SILGlobalVariable definition only.
We also handle SILGlobalAddrInst in various SILPasses, in the similar way
as we handle GlobalAddrInst.
rdar://15493694
Swift SVN r21887
...so that they don't get dead-stripped out of an executable...
...so that they can be accessed by unit tests (or in-process plug-ins).
In Swift, marking something 'public' is a deliberate action (unlike in C),
so anything marked 'public' should be left in the final binary...even when
we're building an executable.
We currently /also/ mark the symbols for internal and private decls as
external as well, so they also won't be stripped. Hopefully that will
change soon.
rdar://problem/18173029
Swift SVN r21815
This is a simple, trivialy, not-even-half-way-there solution to weak
leaking of Objective-C classes introduced after the deployment
target. It only works for Objective-C classes and C global variables
that Clang consideres to be "weak imported". However, this bare
minimum should be enough to develop an app (by jumping through various
hoops) that uses new functionality when its
available. <rdar://problem/17296490>, which I've restricted in scope
to capture this.
Swift SVN r20956
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
Teach IRGen to honor the linkage of SILWitnessTables, and teach SILGen to emit witness tables and protocol witness thunks for external definitions with shared linkage. Fixes <rdar://problem/16264703>.
Swift SVN r14908
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
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
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
Note that this lowering currently assumes that the static type of the class is its dynamic type. This should be a flag on the dealloc_ref instruction, not an assumption.
Swift SVN r12144
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
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
Produce protocol descriptors when we see a protocol definition in the current module. If the protocol is @objc, go through the existing path for generating full Protocol* metadata for objc objects; otherwise, emit our layout-compatible but strong-external-linkage Swift protocol descriptor record.
Swift SVN r9867
Build a nominal type descriptor when we emit the metadata or generic metadata pattern for a nominal type, and put a reference into the formerly null slot in the struct or enum metadata. We need to make a place for them in class metadata; that'll come next.
Swift SVN r9492
Add a SILLinkage mode "Deserialized" to make sure IRGen will emit
hidden symbols for deserialized SILFunction.
Inside SIL linker, set Linkage to external if we only have a declaration for
a callee function.
Both sil block and decl block in a module can emit an array of substitutions.
To share the serialization between SILSerializer and Serializer, we modify
the interface to pass in the abbreviation codes to write functions and to
pass in a cursor to read functions.
We now correctly handle the serialization of Substitutions in SpecializeInst.
For a deserialized SILFunction, we now temporarily set its SILLocation and
DebugScope to an empty FileLocation. Once mandatory inliner sets the SILLocation
to the location of ApplyInst, a null SILLocation and a null DebugScope
may work for a deserialized SILFunction.
Update testing cases to reflect that we are now inlining transparent functions
from modules, or to disable SILDeserializer for now (I am not sure how to update
those testing cases).
Swift SVN r8582
Lazily-generated currying thunks will require the same IR-level linkonce_odr linkage as clang thunks currently do, so generalize the name of the existing SIL-level linkage specifier 'clang_thunk'.
Swift SVN r8122
Among other things this enables mangled names for tuples.
This adds a pointer to the DeclContext to SILFunction and which is used
to provide the necessary context to the Mangler.
Fixes rdar://problem/14808764 and rdar://problem/14813658.
Swift SVN r8070
We need to handle three cases:
- If a protocol conformance has no associated types, or the associated type witnesses all have statically resolvable metadata, we can expose a *direct* witness table symbol.
- If a protocol conformance has associated types with runtime-instantiated metadata, we need to gate the witness table behind a *lazy* initializer function to fill in the metadata fields.
- If a protocol conformance has associated types where the type or one of its conformances are *dependent* on its parent's generic parameters, we need to instantiate multiple witness tables at runtime.
Swift SVN r6805
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
the debug info, to aid the debugger in figuring out the implementation
language of a given type in multi-language environments.
FYI, where applicable, we also emit the
DW_AT_APPLE_runtime_class(DW_AT_lang_Swift) attribute.
The demangler accepts type names with the "_Tt" prefix without the --type
switch.
Swift SVN r6714
their types.
- DebugTypeInfo holds all type info we need to emit debug information.
- Type info is limited to name, location, and storage size.
- As a side-effect: verbose LLVM IR allocas in debug builds!
Swift SVN r5980
Sever the last load-bearing link between SILFunction and SILConstant by naming SILFunctions with their mangled symbol names. Move the core of the mangler up to SIL, and teach SILGen how to use it to mangle a SILConstant.
Swift SVN r4964
Replace 'constant_ref' with 'function_ref', which references a SILFunction directly, and 'global_addr', which references a global variable VarDecl. Get rid of the SILConstant-to-SILFunction mapping in SILModule and replace it with an ilist of SILFunctions. Allow SILFunctions to be 'external' by not having any blocks in their body.
For now, SILFunctions still carry around their SILConstant "name", because name mangling and IRGen still rely on access to the original decl in order to recover IRGen information, which unfortunately leaves IRGen's CodeRefs in a gross, awkward intermediate state. Lifting mangling, AbstractCC, and other linkage attributes to SIL should clear up this up.
Swift SVN r4865
CapturingExprs get mapped to referenceable SILConstants by SILGen instead of getting emitted in-place as in IRGen, so they need LinkEntities and mangling. For now I just mangle them all to "closure", which matches what old IRGen does.
Swift SVN r4477
Add a mangling for 'block converter' functions and for [objc_block] function types. [objc_block] types also need their own HeapTypeInfo representation that uses ObjC retain/release. When we see a BridgeToBlockExpr, feed the function pointer and context from the Swift closure to the external conversion function and hope we get a block back.
Swift SVN r3899
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
