Teach LoadStoreOpts to handle "let" variables properly. Such variables should be loaded only once and their loaded values can be reused. This is safe, because once assigned these variables cannot change their value.
Swift SVN r27915
Previous attempts to update the callgraph explicitly after calls to
linkFunction() weren't completely effective because we can deserialize
deeply and introduce multiple new function bodies in the process.
This gets us a bit closer, but only adds new call graph nodes. It does
not currently add edges for everything that gets deserialized (and this
is not fatal, so it is a step forward).
Swift SVN r27120
These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
I suspect this is a holdover from when I rewrote most of the call graph
code. In any event, it's unused since we store this in the call graph
itself.
Swift SVN r27072
Use the isPossiblyUsedExternally method of SILFunction, remove a
work-around for "main", and delete a big "how" comment that could easily
be made obsolete (and probably will soon).
Swift SVN r26983
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
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
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
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
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
Given a strong_pin for which we have not yet seen a strong_unpin, a safe
guaranteed call sequence is of the following form:
retain(x)
call f(@guaranteed x)
release(x)
where f is an array semantic call that we know does not touch globals and thus
are known to not change ref counts.
rdar://20305817
Swift SVN r26662
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
Before the change the RCIdentityAnalysis kept a single map that contained
the module's RC information. When function passes needed to invalidate the
analysis they had to clear the RC information for the entire module. The
problem was mitigated by the fact that we process one function at a time, and
we start processing a new function less frequently.
II adopted the DominanceAnalysis structure. We should probably implement
this functionality as CRTP.
Swift SVN r26636
Small tweak to function signature optimization so that it filters out
applies that might have multiple targets, as well as applies of partial
applies, which will take some updates to handle.
Resolves rdar://problem/19632244 and rdar://problem/20049782.
I've opened rdar://problem/20306331 to consider handling
apply-of-partial-apply at some point in the future.
Swift SVN r26585
This includes:
1. Extract instructions which extracts a trivial part of an aggregate that has
one RCIdentity.
2. Instructions which take a pointer out of ARC's control by converting it to a
trivial type. This is safe to do since we can assume that the object that is
convered is alive when the conversion happens. So assuming that we can
conservatively find all RC users, we will have at least one RC user that
post dominates the use (since otherwise we would be touching a dangling
pointer). We leave it to the user of the pass to determine what is safe to do
with this information. Potentially in the future it might make sense to return
this information as well so that a user can use that information directly.
rdar://20305817
Swift SVN r26583
Previously, we were being very conservative and were not trying to look through
any RCId uses. Now we understand how to look through RCIdentical instructions to
pair a pin and unpin. We also understand how to use the new getRCUses API on
RCIdentityAnalysis to get all uses of a value, looking through RCIdentical
instructions.
I also added some code to COWArrayOpts to teach it how to look through enum insts (which I needed).
Additionally I got stuck and added support for automatic indentation in Debug
statements. This is better than having to indent by hand every time.
There were no significant perf changes since this code was not being emitted by
the frontend. But without this +0 self causes COW to break.
rdar://20267677
Swift SVN r26529
The old invalidation lattice was incorrect because changes to control flow could cause changes to the
call graph, so we've decided to change the way passes invalidate analysis. In the new scheme, the lattice
is replaced with a list of traits that passes preserve or invalidate. The current traits are Calls and Branches.
Now, passes report which traits they preserve, which is the opposite of the previous implementation where
passes needed to report what they invalidate.
Node: I tried to limit the changes in this commit to mechanical changes to ease the review. I will cleanup some
of the code in a following commit.
Swift SVN r26449
This reverts commit r25925.
We cannot assume that these functions are not mayRelease because they call
Objective C functions which we must assume to be mayRelase.
Swift SVN r26107
Specifically, addEdgesForApply() and removeEdgesForApply() allow for
clients to notify the call graph of apply instructions that are being
added or removed by the client. This allows us to avoid dangling
pointers in the maps kept in the call graph and avoid invalidating the
entire call graph at the end of passes that choose to maintain it.
Also, markCallerEdgesOfCalleesIncomplete() makes it possible to notify
all the callees of an apply that is being removed that we no longer have
complete information about all of the callers.
What this change specifically does not do is recompute the bottom-up
ordering of SCCs or functions in the call graph.
I have some incomplete updates to the inliner to use this functionality,
and it doesn't appear to be completely broken, but at this point I would
say this is experimental and could change once we have more clients
making use of it.
Swift SVN r26097
Re-apply r26072 with a fix to ensure that we get stable bottom-up
orderings in the call grpah.
Using SmallPtrSet here makes sense, and paves the way to more reasonable
code for editing the call graph by clients.
One unfortunate casualty of this is the ArrayRevView that was used by
one client.
Swift SVN r26093
This reverts commit r26072, which could result in non-deterministic
bottom-up ordering in the call graph.
I'll reapply with a fix soon.
Swift SVN r26074
It makes more sense, and paves the way to more reasonable code for
editing the call graph by clients.
One unfortunate casualty of this is the ArrayRevView that was used by
one client.
Swift SVN r26072
