Perf Results:
RIGHT - Before (ms)
LEFT - After (ms)
TITLE LEFT RIGHT RIGHT/LEFT
InsertionSort 103721.00 110326.00 1.06
NSXMLParser 27031.00 29763.00 1.10
rdar://20355793
Swift SVN r26784
This is apart of the work to change ARC so that all of the dataflow operations
are delegated to visitors which allow for behavior to be specialized depending
on the transformation kind. This will allow for users to add new behavior to the
ARC optimizer will minimally touching the actual dataflow.
Swift SVN r26777
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
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
We were always treating terminators (even without arguments) as uses. This is
incorrect. With this patch we now say that a terminator can not use a ref count
pointer if all of the terminator's arguments conservatively can not alias the
pointer.
rdar://20335297
Swift SVN r26664
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
An RCStateTransition is (you guessed it) a transition in the state
of an RCIdentity. It abstracts operations such as:
1. The introduction of a new incremented RCID by an argument (and in
the future
an @owned return value).
2. Strong increment of an RC.
3. Strong decrement of an RC.
I will use this to move pin_removal into the ARC optimizer and will
open up the ARC optimizer to being able to match up unowned values in the
future. It additionally allows me to deduplicate code from
{TopDown,BottomUp}RefCountState into RefCountState, RCStateTransition.
Swift SVN r26608
We can sometimes determine exactly what we'll be calling by looking at
the callee of the partial_apply.
Nothing will directly make use of this yet, although it could perturb
the SCC ordering of the call graph.
Swift SVN r26586
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
Use the following equality: (x xor y) xor y == x.
With this in mind (a xor b) xor c can be replaced by:
a - if b and c are the same
b - if a and c are the same
c - if a and b are the same
rdar://20280322
Swift SVN r26568
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
TerminatorInsts. Now you can walk over the successor list of a terminator
and actually modify the SILSuccessor directly, allowing better CFG
transformations. NFC.
Swift SVN r26140
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
This reverts commit r25926.
This is not a safe assumption to make. The array implementation does call
Objective C functions which must be assumed to be may-release.
Swift SVN r26106
This reverts commit r26082.
We cannot assume that NSArray count or objectAtIndex don't not have side effects
that are observed from Swift. We have to assume they could change an object that
is visible from Swift and therefore they are may-release.
Swift SVN r26099
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
Sort call graph nodes in the CalleeSet (which is a SmallPtrSet) by the
ordinal we've assigned before iterating over them.
The caller edge list will change to a SmallPtrSet soon as well, and
technically this won't be necessary at that point, but I will probably
leave the sorting in as it doesn't hurt anything and will ensure that if
we need to change data structures again we'll continue to be
deterministic.
Swift SVN r26091
This enables it to move retain about critical objective c method calls such as
objectAtIndex and count used by Array.
Improves DeltaBlue by 35% at -O.
radar://20147568
Swift SVN r26082
We can't just recursively process types without caching. Instead mark a type as
safe before we recurse and reset this assumption if we proved otherwise on the
recursive traversal.
rdar://20132313
Swift SVN r26048
Read only array semantic functions such as "array.get_element" only have
balanced retain/release pairs in +0 self mode. Therefore, they are only a use of
the self pointer not a may-release or a guaranteed use. This means we can more
aggressively remove retain/release pairs accross such callees.
radar://20071261
Swift SVN r25926
For better consistency with other address-only instruction variants, and to open the door to new exciting existential representations (such as a refcounted boxed representation for ErrorType).
Swift SVN r25902
Previously this was scattered in various places . Now we have a simple model that
all CallGraphEdges, CallGraphNodes, and CallGraphSCCs are owned by the CallGraph
since they are allocated by the CallGraph's BumpPtrAllocator.
This additionally fixes a problem where we were calling delete on SCC's owned by
the BumpPtrAllocator.
Swift SVN r25522
This is currently disabled by default since this verification trips on
ToT when I checked a few days ago.
The current checks that are performed are:
1. For every (SILFunction, CallGraphNode) pair FuncPair in the SILFunction to
CallGraphNode map check that:
a. FuncPair.first is a SILFunction in the current module.
b. FuncPair.first is the SILFunction inside the CallGraphNode FuncPair.second.
c. All CallGraphEdges mapped to FuncPair.second have ApplyInsts which are in
the SILFunction FuncPair.first.
2. For every pair (ApplyInst, CallGraphEdge) ApplyPair in the Apply to
CallGraphEdge map, check that:
a. ApplyPair.second.getCallSite() == ApplyPair.first.
b. ApplyPair.first->getFunction() is in the SILFunction to
CallGraphNode map and the CallGraphEdge for ApplyPair is one of
CallSiteEdges in the mapped to CallGraphNode.
<rdar://problem/19944399>
Swift SVN r25520
This makes it easy to use the callgraph to determine what the Apply
actually calls instead of attempting to ascertain it in an adhoc
manner. This allows for the call graph analysis to be used as the one
point of truth for determing what an apply inst can call.
Swift SVN r25516
