We specifically only handle cases of functions that are not visible externally
and for whom all function_refs to the function only have apply inst users.
<rdar://problem/19137435>
Swift SVN r23714
optimizer freezing releases in the epilogue of functions that match to
SILArguments. This allows us to treat all such SILArguments throughout the
entire function as having a post dominating release.
<rdar://problem/18923030>
Swift SVN r23253
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
Given a function F, this utility class attempts to match up owned arguments with
releases in the epilogue of the function.
I am refactoring this from FunctionSigOpts so I can use it in the ARC optimizer.
<rdar://problem/18923030>
Swift SVN r23219
canInstUseRefCountValues should have always been named
canInstNotUseRefCountValues. I don't remember how it get renamed as such. Even
though it is a little weird to have a "canNever" in a function name, it makes
sense here to contrast it with canUseValue which returns if a specific user can
use a ptr in a way that requires the ptr to be alive. This in contrast says that
a user can never use a ptr in a manner where the ptr must be alive. I.e. this is
a universal quantifier.
Swift SVN r22961
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
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
Currently, the pass just calls a local version of that function. After OzU, I
will enable the full pass (which is currently disabled behind a flag).
Swift SVN r21894
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
This follows the model of dominance info and allows me to create reachability
methods on SILBasicBlock without creating dependencies from swiftSIL to
swiftSILAnalysis.
Swift SVN r21866
This will hopefully make it clearer as we onboard people that
SimplifyInstruction should not add instructions to the IR by making it clearer
that it is an analysis, not a pass.
Swift SVN r21752
The old call graph remains, but the new call graph can obtained by
calling getCallGraph() on the analysis pass.
I'll move the few other passes that use the call graph over soon and
then rip out the old call graph.
No diffs in the stdlib.
Swift SVN r21565
With this change we generate the SCCs in the call graph (for the kinds
of calls we currently recognize) in bottom-up, which we can then
iterate over directly or in reverse for invocation- and
reverse-invocation-order traversal of the call graph.
(This still isn't hooked up - but will be after some dumping routines
and verification of the output).
Swift SVN r21552
This enables us to both check if any instructions may use or decrement a value
in an instruction range and if we find such an instruction know the furthest
where we can move the retain or release.
Swift SVN r21522
Sinking retains will simply make the unique check useless and eliminate
Array copies even when we need them.
Fix for:
<rdar://problem/18109082> ARC: make _isUniquelyReferenced a barrier to avoid lost copies
Swift SVN r21485
This will allow us to search in the order the roots are added which
should improve stability of our output. There is also an ordinal on each
node that we can use to choose order of traversing edges at a given call
site.
Swift SVN r21484
Previously we tracked a set of functions that could be called from a given
call site. Now we track a set of call graph nodes (each of which
represents a callable function). As a result we now create call graph
nodes for declarations rather than just definitions.
Swift SVN r21483
This is not yet hooked up. I want to add a dumper and some tests, and
need to implement code to do invocation- and reverse-invocation-ordering
over the SCCs of the call graph before it can fully replace the existing
code.
This call graph has edges for each call site, so it's really a
multigraph. Each call site tracks the set of functions that can be
called from that point. Currently that set is always a singleton since
we only handle applies of direct function_refs (like the existing call
graph). In time it will be expanded to handle other types of function
application.
Swift SVN r21407
We were adding call graph edges based on seeing a function_ref. Instead,
we'll only add them now based on a direct apply of a function_ref.
Also a minor refactoring to move the code that walks the blocks and
instructions of a function into its own method.
Swift SVN r21243
Before this commit we scanned the vtables every time we wanted to know who are the subclasses of a class. Now we scan the vtables just once.
Swift SVN r20847
Use it in loop rotation.
The pattern to update analysis information is:
// The AnalysisInfo was preserved for this function.
if (Changed) {
// Preserve the analyis for this function by decoupling it from the analysis
// cache.
auto PreservedAnalysis = Analysis.preserveAnalysis(Function);
// Invalidate analysis for this function.
PM.invalidateAnalysis(Function, InvalidationKind::CFG);
// Update the preserved analysis for this function.
Analysis.updateAnalysis(F, std::move(PreservedAnalysis));
}
Swift SVN r19918
In the current setup analysis information is not reused by new pass managers.
There is no point in having different pass managers. Instead, we can just remove
transformations, reset the internal state of the pass manager, and add new
transformation passes. Analysis information can be reused.
Reuse one pass manager in the pass pipeline so that we don't have to
unnecessarily recompute analysis information.
Swift SVN r19917
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 two functions are:
1. valueHasARCUsesInInstructionRange.
2. valueHasARCDecrementsInInstructionRange.
They operate on the range [Start, End).
I am going to use them in enum simplification and sil code motion.
Swift SVN r19893
