They have no effect. The pre-inliner run may be enabling some
specialization at this point. If it turns out that is not the case, I'll
remove those runs and delete the pass.
Swift SVN r26792
To set the PassKind automatically, I needed to refactor some code of the pass manager and the pass definitions.
The main changes are:
1) SILPassManager now has an add-function for each pass: PM.add(createP()) -> PM.addP()
2) I removed the ARGS argument in Passes.def, which we didn't use anyway.
Swift SVN r26756
I measured zero performance regressions on the test suite. I added an early
CSE pass because of a specific example in one of the tests where the inliner
brought in an integer literal that needed to be CSE-ed before inst-combine
could fold a comparison into a constant, and simplify-cfg get rid of that
constant.
Representing our literal values as instructions (e.g. integer_literal) forces
us to run CSE constantly. We also need to re-run InstCombine very frequently
because InstSimplifier is not allowed to create new instructions!
Swift SVN r26736
After many attempts I found that the change in this commit does not regress
the performance of the test suite. The passes that I added in this commit come
to replace the late 'SSAPasses' pipe. I am still not completely sure why there
is such a strong dependency between SimplifyCFG and InstCombine.
Swift SVN r26658
This commit splits DominanceAnalysis into two analysis (Dom and PDom) that
can be cached and invalidates using the common FunctionAnalysisBase interface
independent of one another.
Swift SVN r26643
I completely missed that one of the CondFailOpt optimization was already implemented in SimplifyCFG.
I move the other optimization also into SimplifyCFG because both share some code.
Swift SVN r26626
We can now remove overflow checks by analyzing control flow. For example:
func foo(x : Int) {
if x > 2 {
x - 2 // overflow check removed
}
}
We also remove overflow checks that are guarded by other (stronger) checks:
func bar(x : Int) {
x + 1 // removed
x + 5
x + 2 // removed
}
With this change we are able to remove dozens of checks from the swift standard
library. However, only the only test in the test suite that becomes faster is
Fibonacci (1.3x).
Swift SVN r26054
This helps to clean up alloc_stack (+ related) instructions which are not necessary anymore
if a function with address-parameters is inlined.
Swift SVN r24916
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
This pass removes pin/unpin pairs that are not interleaved by a may-release of
the pin's operand.
This will be needed when we turn on John's work on safe array accessors.
Swift SVN r24434
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
fixing <rdar://problem/19268443> DI should reject this call to transparent function
with the other patch to infer @autoclosure arguments as @__noescape automatically in
the stdlib, there is no stdlib patch required at all.
Swift SVN r24211
This reverts commit r24142.
Even though the tests were broken by r24141, now that there are more
commits on top of it, reverting just r24141 does not fix tests. I'm
reverting r24141, r24142 and r24143.
Swift SVN r24149
This fixes some serious DI problems where it would be broken with transparent
functions like ++.
Previously, this had to be reverted because we were relying on mandatory inlining
to inline closure-taking stdlib functions (like &&/||) before inout deshadowing
happened. With mandatory inlining moved after inout deshadowing, we were getting
a lot of inout shadow temporaries around, which notably defeated important COW
optimizations by increasing refcounts in unpredictable ways.
The new @__noescape attribute handles this for us now, because @__noescape closures
(like the autoclosure arguments to ||/&&) no longer block inout deshadowing.
Swift SVN r24142
In the swift-602-branch, these are forward declared in one of the
headers included in this file yielded a compilation error. Rather than
just fixing the compilation failure on that branch, this commit makes
the entire file more redundent since who knows in the future these two
types may be forward declared again.
Swift SVN r24066
This flag enables one to specify a json file that expresses a specific
pipeline in the following format:
[
[
"$PASS_MANAGER_ID",
"run_n_times"|"run_to_fixed_point",
$NUM_ITERATIONS,
"$PASS1", "$PASS2", ...
],
...
]
This will make it easier to experiment with different pass pipelines by
allowing:
1. Automatic generation of pass pipelines without needing to recompile
the compiler itself.
2. Simple scripting of pass pipelines via the json meta language.
3. Enabling the easy expression and reproducability of a specific
pipeline ordering via radar.
In the next commit I will provide a python library for the generation of these
json files with a few types of pipeline generators already created.
Swift SVN r24055
We know that a native swift array that does not need an element type check is
not going to change to an nsarray, or to an array that needs an element type
check. This allows us to specialize array code.
The array semantic calls 'array.props.isCocoa/needsElementTypeCheck' returns
said array properties for a read.
func f(a : A[AClass]) {
for i in 0..a.count {
let b = a.props.isCocoa()
.. += _getElement(a, i, b)
}
}
==>
func f(a : A[AClass]) {
let b2 = a.props.isCocoa()
if (!b2) {
for i in 0..a.count {
.. += _getElement(a, i, false)
}
} else {
for i in 0..a.count {
let b = a.props.isCocoa
.. += _getElement(a, i, b)
}
}
}
The stdlib will be changed to use array.props calls in a future commit.
rdar://17955309
Swift SVN r23689
This adds an analysis to the compiler that identifies types that are may store
to memory on destruction.
It adds a compiler known protocol _DestructorSafeContainer that allows the
standard library to identify containers whose destructor's memory effects
depends strictly on the type parameters of the container.
Array<T> : _DestructorSafeContainer {} may not store to memory during
destruction if the bound T is a type that does not store to memory on
destruction.
This is needed to deduce that for example Array<Array<Int>> is does not store to
memory on destruction (e.g during a call to release).
rdar://18940376
Swift SVN r23242
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
terminators"
This is an assumption that the SSAUpdater makes. Verify that we preserve this
property.
With changes to the test cases, SIL documentation and add a critical edge (non
cond_br only) splitting pass to the mandatory pipeline.
This reapplies commit 22775.
Swift SVN r22803
Also, only hoist releases into switch regions late in the pipeline.
I made retain sinking more aggressive so that we can move more retains into (and
then hopefully out of) switch regions.
Hoisting releases up into switch regions blocks moving the retains out of the
switch region. To remove retain/releases we would have to iterate between
codemotion and global-arc-opts. Instead just don't move releases into switch
regions until late in the pipeline (the late iteration of the SSAPasses).
This fixes the remaining regressions from the array changes in RC4. And gives
some nice further gains.
-O results speedup(SU) = minbefore/minafter:
TEST``````````SMPL`MIN``MAX```MEAN``SD```MEDIAN`MIN``MAX``MEAN`SD```MEDIAN``SU
Forest````````10```4985`5456``5319``156``5376```4423`4914`4700`169``4789````1.12
ImageProc`````10```7852`7873``7858``6````7857```8260`8272`8264`3````8263````0.95
InsertionSort`10```6098`6109``6104``3````6104```6720`6736`6726`4````6727````0.90
PrimeNum``````10```9202`18296`12514`2690`12368``4098`7552`5953`1164`6319````2.24
Prims`````````10```2058`3486``2787``513``3025```1877`2429`2049`196``2007````1.09
QuickSort`````10```6101`6116``6107``5````6107```6380`6415`6396`11```6398````0.95
RC4```````````10```8639`8684``8655``14```8653```7821`7926`7876`32```7880````1.10
Richards``````10```2243`2254``2249``3````2250```1729`1740`1736`3````1738````1.29
StrToInt``````10```4298`4317``4309``6````4310```4090`4107`4097`6````4098````1.05
StringWalk````10```6478`6511``6486``10```6482```5784`5797`5790`4````5790````1.11
Walsh`````````10```5971`7374``6831``515``7103```4780`4803`4789`7````4788````1.24
InsertionSort: Looking at the profile of insertion sort the regression is not
due to increased retain/release traffic. In fact, it is hard to tell where
those 10% come from.
Quicksort: The quicksort function is identical and takes 95% of the time. Not
clear where the 5% are coming from. It is not extra retain/release traffic
AFAICT.
ImageProc: Same story as InsertionSort.
rdar://17653593
Swift SVN r22694
This is important since to be more aggressive we are ignoring incoming values
that are no-payload enums since as far as we are concerned they do not matter
since retains, releases on those values are no-ops.
Swift SVN r21932
The cache is needed to ensure we do not run into compile time problems once we
start looking through Phi Nodes.
The analysis is currently disabled and just returns
SILValue::stripRCIdentityPreservingOps. I am going to thread it through the rest
of the passes that use that call. Then I am going to hide
stripRCIdentityPreservingArgs. Finally post OzU, I am going to enable the pass.
rdar://18300069
Swift SVN r21891
PerfTests -----
Before
Totals,54,93821,93821,93821,0,0
Totals,54,86755,86755,86755,0,0
After
Totals,54,93610,93610,93610,0,0
Totals,54,85780,85780,85780,0,0
We may be able to tune BoostFactor for closure in PerformanceInliner.
Swift SVN r21312
Fixes
<rdar://problem/16755460> Specialize functions that are partially applied to constant values
This seems to have little effect on our current benchmark suite except
for the one I wrote specifically for this optimization. We get 4x
speedup on calling reduce to sum a range.
Swift SVN r21248
