mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-12-16 11:30:51 +00:00
6bc127e1dd
The problem here is the infamous one direction known safe. I was hesitant to turn it off before b/c of the potential for regressions without an actual bug from users hitting the problem. This is that bug ; ). The main performance impact of having known safe in both directions is that often times it is very difficult to find two releases without a use in-between them since we are so conservative with determining potential uses. The one direction known safe gets around that problem by taking advantage of many situations where we have two retains in a row, allowing us to avoid that problem. That being said, the one direction known safe is unsafe. Consider the following situation: retain(x) retain(x) call(x) call(x) release(x) Then we know the following about the reference count of x: // rc(x) == N (for some N). retain(x) // rc(x) == N+1 retain(x) // rc(x) == N+2 call A(x) call B(x) // rc(x) >= 1 (since we can not release a deallocated pointer). release(x) // rc(x) >= 0 That is all the information that we can know statically. That means that we know that A(x), B(x) together can release (x) at most N+1 times. Lets say that we remove the inner retain, release pair. // rc(x) == N (for some N). retain(x) // rc(x) == N+1 call A(x) call B(x) // rc(x) >= 1 release(x) // rc(x) >= 0 We knew before that A(x), B(x) could release x up to N+1 times meaning that rc(x) may be zero at the release(x). That is not safe. On the other hand, consider the following situation where we have a must use of release(x) that x must be kept alive for after the release(x)**. Then we know that: // rc(x) == N (for some N). retain(x) // rc(x) == N+1 retain(x) // rc(x) == N+2 call A(x) call B(x) // rc(x) >= 2 (since we know that we are going to release x and that that release can not be the last use of x). release(x) // rc(x) >= 1 (since we can not deallocate the pointer since we have a must use after x). … // rc(x) >= 1 use(x) Thus we know that statically the calls to A(x), B(x) can together only release rc(x) N times. Thus if we remove the inner retain, release pair: // rc(x) == N (for some N). retain(x) // rc(x) == N+1 call A(x) call B(x) // rc(x) >= 1 … // rc(x) >= 1 use(x) We are still safe unless in the final … there are unbalanced retains, releases which would have caused the program to blow up anyways even before optimization occurred. The simplest form of must use is an additional release that has not been paired up with any retain (if we had paired the release with a retain and removed it we would not have the additional use). This fits nicely into the ARC framework since basically what you do is say that given any nested releases regardless of what is in between, the inner release is known safe. This enables us to get back the lost performance. <rdar://problem/19023795> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232351 91177308-0d34-0410-b5e6-96231b3b80d8 |
||
|---|---|---|
| .. | ||
| allocas.ll | ||
| apelim.ll | ||
| basic.ll | ||
| cfg-hazards.ll | ||
| contract-end-of-use-list.ll | ||
| contract-marker.ll | ||
| contract-storestrong-ivar.ll | ||
| contract-storestrong.ll | ||
| contract-testcases.ll | ||
| contract.ll | ||
| empty-block.ll | ||
| ensure-that-exception-unwind-path-is-visited.ll | ||
| escape.ll | ||
| expand.ll | ||
| gvn.ll | ||
| intrinsic-use-isolated.ll | ||
| intrinsic-use.ll | ||
| invoke.ll | ||
| move-and-form-retain-autorelease.ll | ||
| move-and-merge-autorelease.ll | ||
| nested.ll | ||
| path-overflow.ll | ||
| pointer-types.ll | ||
| post-inlining.ll | ||
| pr12270.ll | ||
| provenance.ll | ||
| retain-block-side-effects.ll | ||
| retain-not-declared.ll | ||
| rle-s2l.ll | ||
| rv.ll | ||
| split-backedge.ll | ||
| tail-call-invariant-enforcement.ll | ||
| weak-contract.ll | ||
| weak-copies.ll | ||
| weak-dce.ll | ||
| weak.ll | ||