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
This will be tested in the next commit (which required it). The commit
is going to update a bunch of tests at the same time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232350 91177308-0d34-0410-b5e6-96231b3b80d8
These refactored computations check whether or not we are at a stage
of the sequence where we can perform a match. This patch moves the
computation out of the main dataflow and into
{BottomUp,TopDown}PtrState.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231439 91177308-0d34-0410-b5e6-96231b3b80d8
This initialization occurs when we see a new retain or release. Before
we performed the actual initialization inline in the dataflow. That is
just messy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231438 91177308-0d34-0410-b5e6-96231b3b80d8
This will enable the main ObjCARCOpts dataflow to work with higher
level concepts such as "can this ptr state be modified by this ref
count" and not need to understand the nitty gritty details of how that
is determined. This makes the dataflow cleaner.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231437 91177308-0d34-0410-b5e6-96231b3b80d8
This is different from CanAlterRefCount since CanDecrementRefCount is
attempting to prove specifically whether or not an instruction can
decrement instead of the more general question of whether it can
decrement or increment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229936 91177308-0d34-0410-b5e6-96231b3b80d8
This is much better than the previous manner of just using
short-curcuiting booleans from:
1. A "naive" efficiency perspective: we do not have to rely on the
compiler to change the short circuiting boolean operations into a
switch.
2. An understanding perspective by making the implicit behavior of
negative predicates explicit.
3. A maintainability perspective through the covered switch flag making
it easy to know where to update code when adding new ARCInstKinds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229906 91177308-0d34-0410-b5e6-96231b3b80d8
I also renamed ObjCARCUtil.cpp -> ARCInstKind.cpp. That file only contained
items related to ARCInstKind anyways.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229905 91177308-0d34-0410-b5e6-96231b3b80d8
The RCIdentity root ("Reference Count Identity Root") of a value V is a
dominating value U for which retaining or releasing U is equivalent to
retaining or releasing V. In other words, ARC operations on V are
equivalent to ARC operations on U.
This is a useful property to ascertain since we can use this in the ARC
optimizer to make it easier to match up ARC operations by always mapping
ARC operations to RCIdentityRoots instead of pointers themselves. Then
we perform pairing of retains, releases which are applied to the same
RCIdentityRoot.
In general, the two ways that we see RCIdentical values in ObjC are via:
1. PointerCasts
2. Forwarding Calls that return their argument verbatim.
As such in ObjC, two RCIdentical pointers must always point to the same
memory location.
Previously this concept was implicit in the code and various methods
that dealt with this concept were given functional names that did not
conform to any name in the "ARC" model. This often times resulted in
code that was hard for the non-ARC acquanted to understand resulting in
unhappiness and confusion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229796 91177308-0d34-0410-b5e6-96231b3b80d8
The main method of ObjCARCContract is really large and busy. By refactoring this
out, it becomes easier to reason about.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229794 91177308-0d34-0410-b5e6-96231b3b80d8
There is no reason for this state to be exposed as public. The single element
constructor was superfulous in light of the single element ArrayRef
constructor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226424 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r225059. I think MSVC 2012 has a problem with this. This is
an attempt to fix one of the MSVC 2012 bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225065 91177308-0d34-0410-b5e6-96231b3b80d8
These just delegate to the underlying vector type in the MapVector.
Also just add in some sanity unittests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220687 91177308-0d34-0410-b5e6-96231b3b80d8
This is something that I have found to be very useful in my work and I
wanted to contribute it back to the community since several people in
the past have asked me for something along these lines. (Jakob, I know
this has been a while coming ; )]
The way you use this is you create a script that takes in as its first
argument a count. The script passes into LLVM the count via a command
line flag that disables a pass after LLVM has run after the pass has
run for count number of times. Then the script invokes a test of some
sort and indicates whether LLVM successfully compiled the test via the
scripts exit status. Then you invoke bisect as follows:
bisect --start=<start_num> --end=<end_num> ./script.sh "%(count)s"
And bisect will continually call ./script.sh with various counts using
the exit status to determine success and failure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214610 91177308-0d34-0410-b5e6-96231b3b80d8
This was due to arithmetic overflow in the getNumBits() computation. Now we
cast BitWidth to a uint64_t so that does not occur during the computation. After
the computation is complete, the uint64_t is truncated when the function
returns.
I know that this is not something that is likely to happen, but it *IS* a valid
input and we should not blow up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199609 91177308-0d34-0410-b5e6-96231b3b80d8
IMHO At some point BasicBlock should be refactored along the lines of
MachineBasicBlock so that successors/weights are actually embedded within the
block. Now is not that time though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197303 91177308-0d34-0410-b5e6-96231b3b80d8
This is slightly more interesting than the previous batch of changes.
Specifically:
1. We refactor getSpillWeight to take a MachineBlockFrequencyInfo (MBFI)
object. This enables us to completely encapsulate the actual manner we
use the MachineBlockFrequencyInfo to get our spill weights. This yields
cleaner code since one does not need to fetch the actual block frequency
before getting the spill weight if all one wants it the spill weight. It
also gives us access to entry frequency which we need for our
computation.
2. Instead of having getSpillWeight take a MachineBasicBlock (as one
might think) to look up the block frequency via the MBFI object, we
instead take in a MachineInstr object. The reason for this is that the
method is supposed to return the spill weight for an instruction
according to the comments around the function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197296 91177308-0d34-0410-b5e6-96231b3b80d8
BlockFrequencies can only be printed relative to their entry frequency. Thus
since the entry frequency is no longer necessarily a static constant on the
BlockFrequency class and is instead a potentially dynamic value taken from
BlockFrequencyImpl, we must necessarily print it via a method on
BlockFrequencyImpl.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197285 91177308-0d34-0410-b5e6-96231b3b80d8
This is a property associated with a function, not with BlockFrequency data.
Additionally it loosens the artifical requirement that the entry frequency
arbitrarily be the same for every function.
There is a series of patches forthcoming updating various code that uses the old
way of getting a block frequency to the new location.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197284 91177308-0d34-0410-b5e6-96231b3b80d8
There is no reason to use std::deque here over std::vector. Thus given the
performance differences inbetween the two it makes sense to change deque to
vector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196524 91177308-0d34-0410-b5e6-96231b3b80d8
This is useful for debugging issues in the BlockFrequency implementation
since one can easily visualize where probability mass and other errors
occur in the propagation.
This is the MI version of r194654.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196183 91177308-0d34-0410-b5e6-96231b3b80d8
We already have a method for returning one loop latch but for some
reason no one has committed one for returning loop latches in the case
where there are multiple latches.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195410 91177308-0d34-0410-b5e6-96231b3b80d8
This change is the first in a series of changes improving LLVM's Block
Frequency propogation implementation to not lose probability mass in
branchy code when propogating block frequency information from a basic
block to its successors. This patch is a simple infrastructure
improvement that does not actually modify the block frequency
algorithm. The specific changes are:
1. Changes the division algorithm used when scaling block frequencies by
branch probabilities to a short division algorithm. This gives us the
remainder for free as well as provides a nice speed boost. When I
benched the old routine and the new routine on a Sandy Bridge iMac with
disabled turbo mode performing 8192 iterations on an array of length
32768, I saw ~600% increase in speed in mean/median performance.
2. Exposes a scale method that returns a remainder. This is important so
we can ensure that when we scale a block frequency by some branch
probability BP = N/D, the remainder from the division by D can be
retrieved and propagated to other children to ensure no probability mass
is lost (more to come on this).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194950 91177308-0d34-0410-b5e6-96231b3b80d8
This is useful for debugging issues in the BlockFrequency implementation since
one can easily visualize where probability mass and other errors occur in the
propagation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194654 91177308-0d34-0410-b5e6-96231b3b80d8
Due to the previously added overflow checks, we can have a retain/release
relation that is one directional. This occurs specifically when we run into an
additive overflow causing us to drop state in only one direction. If that
occurs, we should bail and not optimize that retain/release instead of
asserting.
Apologies for the size of the testcase. It is necessary to cause the additive
cfg overflow to trigger.
rdar://15377890
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194083 91177308-0d34-0410-b5e6-96231b3b80d8
One optimization simplify-cfg performs is the converting of switches to
lookup tables if the switch has > 4 cases. This is done by:
1. Finding the max/min case value and calculating the switch case range.
2. Create a lookup table basic block.
3. Perform a check in the switch's BB to see if the input value is in
the switch's case range. If the input value satisfies said predicate
branch to the lookup table BB, otherwise branch to the switch's default
destination BB using the default value as the result.
The conditional check consists of subtracting the min case value of the
table from any input iN value and then ensuring that said value is
unsigned less than the size of the lookup table represented as an iN
value.
If the lookup table is a covered lookup table, the size of the table will be N
which is 0 as an iN value. Thus the comparison will be an `icmp ult` of an iN
value against 0 which is always false yielding the incorrect result.
This patch fixes this problem by recognizing if we have a covered lookup table
and if we do, unconditionally jumps to the lookup table BB since the covering
property of the lookup table implies no input values could not be handled by
said BB.
rdar://15268442
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193045 91177308-0d34-0410-b5e6-96231b3b80d8
Sometimes a copy from a vreg -> vreg sneaks into the middle of a terminator
sequence. It is safe to slice this into the stack protector success bb.
This fixes PR16979.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191260 91177308-0d34-0410-b5e6-96231b3b80d8
This is a part of a series of patches that have been sitting fallow on a
personal branch that I have been messing with for a bit.
The patches start to flesh out the python llvm-c wrapper to the point where you can:
1. Load Modules from Bitcode/Dump/Print them.
2. Iterate over Functions from those modules/get their names/dump them.
3. Iterate over the BasicBlocks from said function/get the BB's name/dump it.
4. Iterate over the Instructions in said BasicBlocks/get the instructions
name/dump the instruction.
My main interest in developing this was to be able to gather statistics about
LLVM IR using python scripts to speed up statistical profiling of different IR
level transformations (hence the focus on printing/dumping/getting names).
This is a gift from me to the LLVM community = ).
I am going to be committing the patches slowly over the next bit as I have time
to prepare the patches.
The overall organization follows the c-api like the bindings that are already
implemented.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190388 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r189913.
Talked with Eric on IRC. I am going to XFAIL the failing test since it
is using what Eric described as "the member hack" which was needed on
that old GDB.
Sorry for the noise!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189914 91177308-0d34-0410-b5e6-96231b3b80d8
Iterator of std::vector may be implemented as a raw pointer. In
this case begin iterators are rvalues and cannot be incremented.
For example, this is the case with STDCXX implementation of vector.
Patch by Konstantin Tokarev <annulen@yandex.ru>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189911 91177308-0d34-0410-b5e6-96231b3b80d8
The reason that I am turning off this optimization is that there is an
additional case where a block can escape that has come up. Specifically, this
occurs when a block is used in a scope outside of its current scope.
This can cause a captured retainable object pointer whose life is preserved by
the objc_retainBlock to be deallocated before the block is invoked.
An example of the code needed to trigger the bug is:
----
\#import <Foundation/Foundation.h>
int main(int argc, const char * argv[]) {
void (^somethingToDoLater)();
{
NSObject *obj = [NSObject new];
somethingToDoLater = ^{
[obj self]; // Crashes here
};
}
NSLog(@"test.");
somethingToDoLater();
return 0;
}
----
In the next commit, I remove all the dead code that results from this.
Once I put in the fixing commit I will bring back the tests that I deleted in
this commit.
rdar://14802782.
rdar://14868830.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189869 91177308-0d34-0410-b5e6-96231b3b80d8
Michael Gottesman