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
Doing so is safe even though we have mock SDK. The include paths for
modules with the same name in the real and mock SDKs are different, and
the module files will be distinct (because they will have a different
hash).
This reduces test runtime on OS X by 30% and brings it under a minute on
a 16-core machine.
This also uncovered some problems with some tests -- even when run for
iOS configurations, some tests would still run with macosx triple. I
fixed the tests where I noticed this issue.
rdar://problem/19125022
Swift SVN r23683
This should have been done a long time ago since SILOptions are options that
should be able to effect everything SIL related. In this case I just want to
pass in a flag on the SILModule to enable +0 self. By putting it on the
SILModule I can conveniently check it in SILFunctionType without exposing any
internal state from SILFunctionType.cpp.
Swift SVN r23647
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
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 will be used for parsing sil generated from stdlib. We will ignore
the AST decls and instead import them from the module.
rdar://17979145
Swift SVN r22367
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
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
If we have function A calls function B with a closure C
func A {
B(...) {
// closure C
}
}
and the inliner decides to not inline B into A, it may be beneficial to generate
a specialized version of B to have
func A {
B_spec_with_C(..., arguments_to_closure_C)
}
SILCombine will optimize apply of partial_apply that are both in B_spec_with_C.
Then inliner can inline the closure to B_spec_with_C.
For profitability, we check the relative size of the callee B and the closure C.
We also check hotness of the callsite to B in A and callsites to the closure
inside B. For now, if closure is called inside a loop, we think it is
profitable.
I will add this to the pass manager in a follow-up patch.
rdar://16569736
Swift SVN r21216
Implements redundant bounds check elimination for basic blocks and along the
dominator tree of loops.
No induction variable based hoisting yet.
O3:
NBody , 473.00 , 122.00 , 294.2%
QuickSort , 477.00 , 310.00 , 53.9%
RC4 , 1022.00 , 736.00 , 38.6%
Walsh , 1781.00 , 1142.00 , 55.5%
No effect on Ofast.
Disabled for now.
Swift SVN r20199
This is not run by default unless one passes in the flag -Xllvm -enable-global-load-store-opts.
Also in order to make sure in the face of multi-bbs dead store elimination is
still correct, we use the post order dominator tree to determine if the dead
store is post dominated by the store that is causing it to be dead.
With this pass enabled, we see a 3.5% decrease in overall time in the precommit
bench and the following tests increase in speed by > 5%:
2Sum: 8.9%
Rectangles: 7.35%
Ackermann: 6.43%
StringBuilder: 6.16%
EditDistance: 5.71%
StringWalk: 5.58%
That means that 30% of our benchmarks increased in speed by > 5%. Many of the
other benchmarks increased in speed significantly but not as drmatically.
The only benchmark that regressed is SmallPt which I am looking into.
rdar://17680758
Swift SVN r20009
This ensures that if we have a bunch of passes in a row which modify the CFG, we
do not continually rebuild the post order, while at the same time preserving the
property of multiple passes which do not touch the CFG sharing the same post
order, reverse post order rather than recomputing them.
rdar://17654239
Swift SVN r19913
The induction variable analysis derives from the SCC visitor CRTP-style
and uses it to drive analysis to find the IVs of a function.
The current definition of induction variable is very weak, but enough to
use for very basic bounds-check elimination.
This is not quite ready for real use. There is an assert that I've
commented out that is firing but should not be, and that will require
some more investigation.
Swift SVN r19845
The main purpose of this pass is to hoist invariant loads out of loops. This
will enable llvm to vectorize loops with array accesses in Ofast once we hoist
the makeUnique functions.
Disabled for now.
rdar://17142604
Swift SVN r19713
The way this pass works is very similar to generic specialization except
that it turns the old function into a thunk that calls the newly created
function that has had the dead arguments removed.
This ensures that any place in the code where we were unable to see that
the old function was being called still works and also enables us to
cut down on code size increase due to code duplication since the
marshalling code for the thunk should be very small.
This is just the first part of a larger body of work that optimizes
function signatures. The plan is to include transforming loadable
pointer args to pass by value and to convert @owned arguments to
@gauranteed arguments.
<rdar://problem/17319928>
Swift SVN r18970
Dynamic languages are able to implement inline caches for virtual calls, but swift is statically compiled, so we have to guess the types at compile time. The early binding pass guesses that types at the bottom of the class hierarchy are not subclassed and emits direct calls to these passes. It converts class_method calls into the following code:
if (Instance is of time Foo) {
Foo::ping()
} else {
Instance->ping();
}
The check if an instance is of a specific type is inexpensive, it is simply a load+icmp sequence.
Swift SVN r18860
r18796 added a check that the standard library is always available when
not working in -parse-stdlib or SIL mode, but sil-opt and sil-extract have
no need to load the stdlib if the module file they're working on does not
depend on it. Treat these tools as if they are always in a -parse-stdlib mode.
This fixes the failure in witness_tables.sil, which is due to us pulling in
witness tables from all loaded modules.
Swift SVN r18807
In a loop like this:
var j = 2
for var i = 0; i < 100; ++i {
j += 3
}
it will completely eliminate j.
It does not yet support rewriting conditional branches as unconditional
branches in the cases where only empty blocks are control dependent on
an edge. Once this support is added, it will also completely eliminate
the loop itself.
Swift SVN r18615
