llvm-6502/test/Transforms
Michael Gottesman 6bc127e1dd [objc-arc] Make the ARC optimizer more conservative by forcing it to be non-safe in both direction, but mitigate the problem by noting that we just care if there was a further use.
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
2015-03-16 07:02:36 +00:00
..
ADCE
AddDiscriminators Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
AlignmentFromAssumptions
ArgumentPromotion
AtomicExpand/ARM
BBVectorize
BDCE
BranchFolding
CodeExtractor
CodeGenPrepare
ConstantHoisting
ConstantMerge
ConstProp
CorrelatedValuePropagation
DeadArgElim Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
DeadStoreElimination Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
EarlyCSE
FunctionAttrs
GCOVProfiling Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
GlobalDCE
GlobalOpt
GVN
IndVarSimplify
Inline Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
InstCombine Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
InstMerge
InstSimplify Add a bunch of CHECK missing colons in tests. NFC. 2015-03-14 01:43:57 +00:00
Internalize
IPConstantProp
IRCE
JumpThreading
LCSSA
LICM Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
LoadCombine
LoopDeletion
LoopIdiom Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
LoopInterchange
LoopReroll
LoopRotate Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
LoopSimplify
LoopStrengthReduce
LoopUnroll
LoopUnswitch
LoopVectorize Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
LowerAtomic
LowerBitSets
LowerExpectIntrinsic
LowerInvoke
LowerSwitch
Mem2Reg Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
MemCpyOpt
MergeFunc
MetaRenamer
ObjCARC [objc-arc] Make the ARC optimizer more conservative by forcing it to be non-safe in both direction, but mitigate the problem by noting that we just care if there was a further use. 2015-03-16 07:02:36 +00:00
PartiallyInlineLibCalls
PhaseOrdering
PlaceSafepoints
PruneEH
Reassociate
Reg2Mem
RewriteStatepointsForGC
SampleProfile Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
Scalarizer Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
ScalarRepl Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
SCCP
SeparateConstOffsetFromGEP/NVPTX
SimplifyCFG Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
Sink
SLPVectorizer Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
SROA
StraightLineStrengthReduce
StripSymbols Verifier: Check debug info intrinsic arguments 2015-03-15 01:21:30 +00:00
StructurizeCFG
TailCallElim
TailDup
Util