Manman implemented this optimization a while ago, but it was not enabled by default.
<rdar://problem/18169093> Eliminate trivial global initializers by replacing them with sil_global constants.
Swift SVN r27685
In r26152 a crash was fixed that had been introduced by previous
improvements, but as a result of fixing the crash some cases where we
previously devirtualized were disabled with the intent that they would
be reenabled after further refactoring work was completed.
This commit restores that functionality and reenables the tests.
Swift SVN r27575
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
reference to something of class type. This is required to model
RebindSelfInConstructorExpr correctly to DI, since in the class case,
self.init and super.init *take* a value out of class box so that it
can pass the +1 value without performing an extra retain. Nothing
else in the compiler uninitializes a DI-controlled memory object
like this, so nothing else needs this. DI really doesn't like something
going from initialized to uninitialized.
Yes, I feel super-gross about this and am really unhappy about it. I
may end up reverting this if I can find an alternate solution to this
problem.
Swift SVN r27525
Fix a few places in diagnose unreachable, which were emitting false diagnostics after enabling this optimization.
This commit does not disable and remove the special-casing for bridging conversions in the CSApply yet. Let's wait a bit and see that everything works properly after my recent cast optimizations changes. If everything is OK, we can remove the code from CSApply.
This time it does not break the Alamofire external project (rdar://20579035).
rdar://20467603
Swift SVN r27513
In hasOnlyRetainReleaseUsers() we both assert that the retain/release
are balanced, as well as do a normal check and bail.
The assert is overzealous since we can legitimately have cases where the
releases are removed due to being unreachable. In this case we should
just do the normal check and bail.
Fixes rdar://problem/20565974.
Swift SVN r27476
This commit adds a flag to disable optimizations on a specific functions. The
primary motivation of this patch is to allow the optimizer developers to reduce
testcasese by disabling optimizations of parts of the code without having to
recompile the compiler or inspect SIL. The annotations "inline(never)"
and "optimize.none" can go a long way.
The second motivation for this patch is to allow our internal adopters to work
around compiler bugs.
rar://19745484
Usage:
@semantics("optimize.never")
public func miscompile() { ... }
Swift SVN r27475
in a initializer" diagnostic by chasing dataflow information more aggressively. We now generally
point at the problematic return instead of the init containing it.
Swift SVN r27474
When emiting logic for conditional destruction of a variable, we weren't considering
a delegated init as a store to the variable that needed to be tracked. This caused us
to miscompile situations like this testcase where the self.init was conditional:
struct X {
var c : C
init() { c = C()}
init?(a : Bool) {
if a { self.init() }
return nil
}
}
This was exposed by other work, but needs to be fixed in any case.
Swift SVN r27471
We still don't actually handle these correctly, but at least
we have sensible information for them now.
Also, remember that we're working with canonical generic
signatures in more places.
Swift SVN r27388
Fix a few places in diagnose unreachable, which were emitting false diagnostics after enabling this optimization.
This commit does not disable and remove the special-casing for bridging conversions in the CSApply yet. Let's wait a bit and see that everything works properly after my recent cast optimizations changes. If everything is OK, we can remove the code from CSApply.
Swift SVN r27379
Even when we don't know for sure if a bridged cast would succeed, we still want to lower it to produce a more efficient code that does not performs conformance checks at run-time.
This is useful when performing casts optimizations as a guaranteed optimization.
Swift SVN r27377
It was producing a checked_cast_add_br, which took a metatype inst as it's argument, which is simply wrong, as it is not an address type. SILVerifier was complaining about it. Now we produce an equivalent peephole, but with a correct instruction sequence, which makes SILVerifier happy.
Swift SVN r27375
Sometimes, during intermediate optimization steps, the operands of produced checked_cast_addr_br instructions do not actually have address types.
Don't try to optimize further in such cases. Let the optimizer clean-up those instructions.
Swift SVN r27373
I noticed under Instruments that the bridged casts opts produced a code that was leaking in some cases. Therefore I took the change to re-visit the code and to clean-up the logic for insertion of retains and releases.
Swift SVN r27371
When casts optimizations were lowering bridged casts from ObjC to Swift, they were producing internally an intermediate cast from an ObjC type into the expected ObjC type of a bridged cast, before converting this expected ObjC type into a Swift type. In many cases, this resulted in a useless intermediate cast where both types were the same and such a cast would be eliminated afterwards. E.g.
unconditional_checked_cast A to B // where A is ObjC type and B is a Swift type
was lowered into:
unconditional_checked_cast A to B. _ObjectiveCType // Often useless as A is equal to B. _ObjectiveCType already.
unconditional_checked_cast B._ObjectiveCType to B
This small inefficiency is fixed now. This problem was no observable from outside the optimization pass, it just required additional processing, therefore there is no test-case.
Swift SVN r27370
The GlobalPropertyOpt pass performs a static analysis over the whole module.
If it can prove that an array property call (_getArrayPropertyIsNativeNoTypeCheck) always yiels true,
then it replaces the call with a literal-true.
The pass runs on the high-level SIL using the array semantics calls.
Currently it only handles the isNativeNoTypeCheck array property, but in future it might handle additinal properties
(therefore I chose this general name for it).
It gives +24% on DeltaBlue.
Swift SVN r27361
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
