Semantic analysis should be guaranteeing that all conformances that
show up in the AST are complete. Until that day, work around the crash
in rdar://problem/20700616 by not specializing.
Swift SVN r27886
This updates the performance inliner to iterate on inlining in cases
where devirtualization or specialization after the first pass of
inlining expose new opportunities for inlining. Similarly, in some cases
inlining exposes new opportunities for devirtualization, e.g. when we
inline an initializer and can now see an alloc_ref that allows us to
devirtualize some class_methods.
The implementation currently has some inefficiencies which increase the
swift compilation time for the stdlib by around 3% (this is swift-time
only, no LLVM time, so overall time does not grow by this much).
Unfortunately the (unchanged) current implementation of the core
inlining trades off improved estimates of code growth for increased
compile time, and that plays a part in why compile time increases as
much as it does. Despite this, I have some ideas on how to win some of
that time back in future patches.
Performance differences are mixed, and this will likely require some
further inliner tuning to reduce or remove some of the losses seen here
at -O. I will open radars for the losses.
Wins:
DeltaBlue 10.2%
EditDistance 13.8%
SwiftStructuresInsertionSort 32.6%
SwiftStructuresStack 34.9%
Losses:
PopFrontArrayGeneric -12.7%
PrimeNum -19.0%
RC4 -30.7%
Sim2DArray -14.6%
There were a handful of wins and losses at Onone and Ounchecked as
well. I'll review the perf testing output and open radars accordingly.
The new test case shows an example of the power of the closer
integration here. We are able to completely devirtualize and inline a
series of class_method applies (10 deep in this case, but in theory
substantially deeper) in a single pass of the inliner, whereas before we
could only do a single level per pass of inlining & devirtualization.
Swift SVN r27561
During inlining we'll now attempt to first devirtualize and specialize
within the function that we're going to inline into. If we're successful
devirtualizing and inlining, and we'll attempt to inline into the newly
exposed callees first, before inlining into the function we began with.
This does not remove any existing passes of devirtualization or
specialization yet, partially because we don't completely handle all
cases that they handle at this point (e.g. specializing partial
applies).
We do end up specializing deeper into the call graph with this approach
than we did prior to this commit.
I will have some follow-on changes that integrate things further,
allowing us to devirtualize in more cases after inlining into a given
function.
I will also add some directed tests in a future commit.
I tested the stdlib build and this made no difference in build
times. Perhaps after removing other existing phases we'll recapture some
build time.
I'm not seeing reproducible performance differences with this change,
which is not a big surprise at this point. This sets us up for being
able to improve the compilation pipeline in a future release.
Swift SVN r27327
This leaves nothing but the helper for specializing an ApplySite in
Generics.h/Generics.cpp, and I expect to rename these files accordingly
at some point.
Swift SVN r26827
Another refactoring step towards splitting the generic specializer into
a pass vs. the cloner vs. a utility that can specialize a given
ApplySite.
Swift SVN r26817
More refactoring of generic specializer, on the path to making the this
new function the primary utility that can be used from other passes.
Swift SVN r26791
As with r26754, this is another step towards simplifying the generic
specializer interface. Since we now properly mangle and can therefore
test if we already have a specialization of this function, we no longer
need to do the bucketing to avoid duplicated work.
The stdlib build is as fast or faster, and the only diffs I see appear
to be either function ordering, UUIDs, or the bit of non-determinism
I've seen in block ordering.
Swift SVN r26765
This change removes some of the bucketing that was happening as part of
generic specialization. Now that we can properly mangle the specialized
function names and look up the previously specialized functions, this is
not necessary.
I verified that stdlib build times do not get longer with this change,
and that the generated SIL is virtually the same (virtually because we
have some non-determinism in our build at the moment:
rdar://problem/20304012).
Swift SVN r26754
threaded into IRGen; tests to follow when that's done.
I made a preliminary effort to make the inliner do the
right thing with try_apply, but otherwise tried to avoid
touching the optimizer any more than was required by the
removal of ApplyInstBase.
Swift SVN r26747
Use existing machinery of the generic specializer to produce generic specializations of closures referenced by partial_apply instructions. Thanks to the newly introduced ApplyInstBase class, the required changes in the generic specializer are very minimal.
rdar://19290942
Swift SVN r26582
Reapply r26362, which was reverted in r26363 because a couple test
updates were not included.
Remove a questionable change from r17803. Based on the
radar (rdar://problem/16809311), it seems like the core issue this was
trying to fix either has to do with serialization or mangling.
I'd argue that if this fix were the right fix for anything, we need to
apply the same fix to any pass that specializes (and we have several of
those now).
This change by itself doesn't seem to have much performance impact, but
it is required for future changes, specifically marking protocol witness
thunks as @transparent, which is required to get the benefits we'd like
from devirtualizing during mandatory inlining.
Swift SVN r26378
Remove a questionable change from r17803. Based on the
radar (rdar://problem/16809311), it seems like the core issue this was
trying to fix either has to do with serialization or mangling.
I'd argue that if this fix were the right fix for anything, we need to
apply the same fix to any pass that specializes (and we have several of
those now).
This change by itself doesn't seem to have much performance impact, but
it is required for future changes, specifically marking protocol witness
thunks as @transparent, which is required to get the benefits we'd like
from devirtualizing during mandatory inlining.
Swift SVN r26362
This can only happen in the closure specializer and the generic
specializer since all other specializations either copy the linkage of
the original function (function signature opts) or clone closures/thunks
which have shared linkage.
I put in a verifier check that makes sure we do not create shared
versions of these functions. The real problem has to do with serializing
these sorts of functions, but since we always serialize shared
functions, it makes sense to just ban it.
rdar://20082696
Swift SVN r26001
We currently run the generic specialize after the devirtualizer because
devirtualization can unblock generic specialization. This patch saves the
newly created ApplyInsts and attempts to specialize only them.
Swift SVN r25576
