These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
The old invalidation lattice was incorrect because changes to control flow could cause changes to the
call graph, so we've decided to change the way passes invalidate analysis. In the new scheme, the lattice
is replaced with a list of traits that passes preserve or invalidate. The current traits are Calls and Branches.
Now, passes report which traits they preserve, which is the opposite of the previous implementation where
passes needed to report what they invalidate.
Node: I tried to limit the changes in this commit to mechanical changes to ease the review. I will cleanup some
of the code in a following commit.
Swift SVN r26449
Rename LateDeadFunctionElimination into ExternalFunctionDefinitionsElimination.
Move ExternalFunctionDefinitionsElimination out of DeadFunctionElimination and make it a separate pass.
Move a common logic shared by DeadFunctionElimination and ExternalFunctionDefinitionsElimination into a newly created base class.
Make ExternalFunctionDefinitionsElimination pass eliminate just those external functions which are only reachable via vtables and witness_tables, but leave directly reachable function definitions in place. This gives LLVM more chances to analyze directly reachable functions for side-effects and perform better optimizations based on this. Once we have a proper IPO support for Swift, we can eliminate all external function definitions, including directly reachable ones, as there will be other ways to get information about their side-effects.
Swift SVN r24546
Doing it before dead functions elimination creates more opportunities for dead function removal, because function references from bodies of external functions do not need to be taken into account any more.
Swift SVN r24431
This pass is an extension of the dead function elimination, which additionally performs removal of external function definitions (i.e. function bodies) for a sake of improving the compile times by reducing the amount of code running through IRGen. It is safe, because such functions are defined elsewhere and where required only for analysis and optimization purposes.
This pass is supposed to run very late in the pipeline, after any passes that may need to look at the function bodies, i.e. after devirtualization, inlining and all specialization passes.
Swift SVN r24417
This fixes <rdar://problem/19198675> Swift Stdlib (Unoptimized+Asserts) #1639 tests failed (1_stdlib/DictionaryUnchecked.swift et al.)
Swift SVN r23843
If vtable or witness methods are never called, e.g. because they are completely devirtualized,
then they are removed from the tables and eliminated.
Another improvement of the new algorithm is that it is able to eliminate dead function cycles
(e.g. A() calls B() and vice versa).
Swift SVN r22969
This avoids that the deserializer(s) keep references to deserialized functions during the whole optimization passes
(especially dead function elimination).
I have seen no negative effect on compiletime. It seems to be a seldom event that a function is
deserialized twice because of not keeping the cache alive between linking passes.
I also simplified the final dead function elimination by just using the regular dead function elimination pass.
Swift SVN r22837
Eliminate the intermediate top_level_code function. Now that SIL is expressive enough to express a "main" function, there's no reason for it, and this eliminates a bunch of mystery code in IRGen to thunk from main to top_level_code by reaching for hardcoded symbol names. Demystify the special code for setting up C_ARGC and C_ARGV by having SILGen look for a transparent "_didEnterMain" hook in the stdlib and emit a call to it.
Swift SVN r22525
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
The old call graph remains, but the new call graph can obtained by
calling getCallGraph() on the analysis pass.
I'll move the few other passes that use the call graph over soon and
then rip out the old call graph.
No diffs in the stdlib.
Swift SVN r21565
The deserializer holds a reference to the deserialized SILFunction, which
prevents Dead Function Elimination from erasing them.
We have a tradeoff on how often we should clean up the unused deserialized
SILFunctions. If we clean up at every optimization iteration, we may
end up deserializing the same SILFunction multiple times. For now, we clean
up only after we are done with the optimization iteration.
rdar://17046033
Swift SVN r18697
