* 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.
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
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
*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
