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
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
This is refactored code from AllocBoxToStack with some small forward
looking changes. The user passes in a ReleaseTracker object that via a
closure decides what users are acceptable. I am going to use this in
closure specialization to remove dead closures.
The main limitation currently is that the code:
1. Assumes that the user deals with any issues relating to whether or
not the value is local.
2. Only visits the direct users of the value instead of visiting the
users recursively. This is safe for my uses now since I will only accept
users that are retains or releases. These have no uses.
The reason why I am leaving in these limitations is I am trying to limit
the amount of changes to the code.
Swift SVN r25048
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
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
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
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
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
Also fixed a small bug related to how we handle arguments. We were not
clearing the state of the argument when we saw a potential decrement of
the argument.
<rdar://problem/17013194>
Swift SVN r18706
that an apply which may decrement ref counts can not decrement a value with
reference semantics if we can prove the value does not alias any of the applies
arguments.
Swift SVN r14120
