We already invalidate all the analyses for each function we inline into,
so this shouldn't be necessary.
We should also be able to remove the invalidation of dominators for the
same reason, but I am getting one test failure when I do that so it
needs further investigation.
Swift SVN r26939
Changes compared to the original version:
I fixed the 2 bugs and added a test for the so far undetected missing range check bug.
To keep the SIL simple (4 basic blocks for arr[x]) I extracted the slow path for getElement into a
non-inlinable function.
On the other hand I inlined _typeCheck into the slow-path function.
This speeds up NSArray accesses because now only a single objectAtIndex is required for both
type checking and element retrieving.
Update on performance: DeltaBlue is now only 12% better (and not 25%). I suspect this is because
now Arnold's tail duplication cannot detect the ObjC call in the slow path.
Swift SVN r26935
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
Use FullApplySite rather than ApplyInst through data structures and
function signatures.
This change does not update the call graph to actually look at
TryApply. That will happen in a future change.
Swift SVN r26893
Add more checks and logic into emitSuccessfulIndirectUnconditionalCast and emitSuccessfulScalarUnconditionalCast, so that its clients in sil-combine can be simplified by avoiding looking into special cases.
Swift SVN r26885
Instead, add a removeEdge() and update code to use
getCallGraphEdge()/removeEdge() in cases where the apply may not be
represented in the call graph.
Swift SVN r26881
Before this commit, passes that were attempting to maintain the call
graph would actually build it if it wasn't already valid, just for the
sake of maintaining it.
Now we only maintain it if we already had a valid call graph built.
Swift SVN r26873
Now that we can check isNative and NoDTC (no deffered type check needed) with a single bit-mask operation,
it makes sense to have a single array property call for it.
I replaced the the semantics call array.props.needsElementTypeCheck with array.props.isNativeNoDTC,
which is the combination of isNative && !needsElementTypeCheck. I kept array.props.isNative, which is not used for now,
but might be useful in the future, e.g. for array operations which don't care about type checks.
The optimized SIL for a class array access arr[i] now contains the minimum of 4 basic blocks.
PerfTests show +25% for DeltaBlue and some improvemements for -Onone.
Swift SVN r26871
If current checked_cast_br is reachable via success, failure and unknown at the same time, then we simply don't know the outcome of the dominating check.
No jump-threading should be performed in this case.
I'll commit the test-case tomorrow. The test-case from the radar depends too much on the stdlib internals. We need something smaller and simpler.
rdar://20389307
Swift SVN r26841
We ignore calls to ArraySemantic functions when we hoist uniqueness checks. With
+0 self, this is disrupted by the release that now is in the caller instead of
the callee.
This patch fixes that problem by teaching COWArrayOpts about "guaranteed call
sequences". This is the following pattern:
retain(x)
... nothing that decrements reference counts ...
call f1(@guaranteed_self x)
... nothing that decrements or uses ref counts ...
call f2(@guaranteed_self x)
... nothing that decrements or uses ref counts ...
...
... nothing that decrements or uses ref counts ...
call f$(n-1)(@guaranteed_self x)
... nothing that decrements or uses ref counts ...
call fn(@guaranteed_self x)
... nothing that uses ref counts ...
release(x)
This pattern is created when there are a bunch of guaranteed calls together in a
row (which seems to happen at the "semantic" SIL level). We pattern match the
sequence and then verify that all of the calls are semantic calls. If the
verification succeeds, we can hoist the uniqueness check.
rdar://20340699
Swift SVN r26835
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
The optimization simplifies a condition if it is dominated by a terminating instruction with the same condition.
With this change we can also simplify non-terminator instructions, e.g. a cond_fail which is dominated by a cond_br,
or a select_enum which is dominated by a switch_enum.
I do not handle the pattern cond_br(select_enum) anymore, because SILCombine converts this to switch_enum anyway.
There is no notable effect on the benchmarks. But it simplifies the class array code a bit.
Swift SVN r26809
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
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
There was only one remaining user since it was removed from any function
interfaces, and that should really just use SmallVector directly.
Swift SVN r26790
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
Avoid running a pass a second time if the pass has its own optimize-until-no-more-changes loop.
This pass property can be configured.
Currently I assume that all our function passes don't need to run a second time (without other changes in between).
It further reduces the number of pass runs by about 6%. But this improvement is cosmetic. There is no significant compile time reduction.
There are no performance changes.
Swift SVN r26760
It avoids that a pass runs a second time if didn't make any changes in the previous run and no other pass changed the function in between.
rdar://problem/20336764
In this change I also removed the CompleteFunctions analysis which is now obsolete.
Some measurements with swiftbench (-wmo, single threaded):
It reduces the number of pass runs by about 28%. Because only passes are skipped that don't do anything, the effect on compile time is not so dramatic.
The time spent in runSILOptimizationPasses is reduced by ~9% which gives a total compile time reduction of about 3%.
Swift SVN r26757
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
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
