The main point of this change is to make sure that a shared function always has a body: both, in the optimizer pipeline and in the swiftmodule file.
This is important because the compiler always needs to emit code for a shared function. Shared functions cannot be referenced from outside the module.
In several corner cases we missed to maintain this invariant which resulted in unresolved-symbol linker errors.
As side-effect of this change we can drop the shared_external SIL linkage and the IsSerializable flag, which simplifies the serialization and linkage concept.
* rename "Name" to "Description" in the pass definition, because it's not really the pass name, but the description of a pass
* remove the getName() from Transforms (which actually returned the description of a pass)
* in debug printing, print the pass ID and not the pass description. It makes it easier to correlate the debug output to the actual pass implementation.
* remove the iteration numbering in the pass manager, because we only run a single iteration anyway.
At some point, pass definitions were heavily macro-ized. Pass
descriptive names were added in two places. This is not only redundant
but a source of confusion. You could waste a lot of time grepping for
the wrong string. I removed all the getName() overrides which, at
around 90 passes, was a fairly significant amount of code bloat.
Any pass that we want to be able to invoke by name from a tool
(sil-opt) or pipeline plan *should* have unique type name, enum value,
commend-line string, and name string. I removed a comment about the
various inliner passes that contradicted that.
Side note: We should be consistent with the policy that a pass is
identified by its type. We have a couple passes, LICM and CSE, which
currently violate that convention.
Also, add a third [serializable] state for functions whose bodies we
*can* serialize, but only do so if they're referenced from another
serialized function.
This will be used for bodies synthesized for imported definitions,
such as init(rawValue:), etc, and various thunks, but for now this
change is NFC.
It turned out that a significant part of a swiftmodule’s size is contributed by function declarations and types used by them. Therefore it is important to avoid emitting any functions or function declarations that are not needed by the module.
This change introduces the following changes:
- Function declarations should be serialized only if they are referenced by something that is serialized.
- Function bodies of functions with external linkage should never be serialized.
The only exception are shared_external functions. THis is a workaround, which will be removed in the future (see explanations in SILSerializer::writeSILFunction)
The result of the later change is that functions with external linkage are not put on the SIL serialization worklist and their bodies are not scanned, thus we do not detect references to the functions which are only referenced by functions with external linkage. In particular, the bodies of shared_external functions won’t be serialized at all if they are referenced only from functions with external linkage. And declarations of external functions referenced only from functions with external linkage won’t be serialized too.
With this changes SILSerializer emits significantly fewer function declarations.
Fixes rdar://30081040
The order of keys in a serialized hash map is deterministic (consistent
across runs of the same compiler and same input) but not specified
(not consistent across compiler versions or modified inputs). Tweak two
tests to avoid this issue: one by sorting the output, the other by
using CHECK-DAG to ignore ordering issues.
rdar://problem/25492781&25497592
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
We serialize shared_external linkage as shared since:
1. shared_external linkage is just a hack to tell the optimizer that a
shared function was deserialized.
2. We can not just serialize a declaration to a shared_external function
since shared_external functions still have linkonce_odr linkage at the LLVM
level. This means they must be defined not just declared.
Swift SVN r22562
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
*NOTE* This linkage is different from {Public,Hidden}External in that it has no
extra semantic meaning beyond shared.
The use of this linkage is to ensure that we do not serialize deserialized
shared functions. Those shared functions can always be re-deserialized from the
original module. This prevents a whole class of bugs related to the
creation of module cross references since all references to the shared
item go straight to the original module.
<rdar://problem/17772847>
Swift SVN r20375
Entities with shared linkage are allowed to be discarded if they are unused even
in a library context.
Previously we implemented this in the serializer, which introduced
needless complications. Now we leave that responsibility to the optimizer giving
simplicity.
Swift SVN r16150
Currently this consists of private functions and shared functions. Even
though shared functions are technically serializable, we only want to
serialize them if their serialization is requested.
Swift SVN r14825
