| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
size.
llvm-svn: 186274
|
| |
|
|
|
|
| |
removed unnecessary mode: c++ lines from .cpp files.
llvm-svn: 186026
|
| |
|
|
|
|
|
|
| |
passed null do not trigger the assert.
The specific case of interest is when objc_retainBlock is passed null.
llvm-svn: 185885
|
| |
|
|
|
|
|
| |
Upon further reflection, the alias analysis part of r185764 is not a safe
change.
llvm-svn: 185770
|
| |
|
|
|
|
| |
not modify the ref count of an objc object and additionally are inert for modref purposes.
llvm-svn: 185769
|
| |
|
|
|
|
| |
references to entrypoint declarations as well.
llvm-svn: 185764
|
| |
|
|
|
|
| |
an llvm_unreachable after the switch to quiet -Wreturn_type errors.
llvm-svn: 185746
|
| |
|
|
|
|
|
|
| |
some small cleanups.
This fixes an issue that came up due to -fpermissive on the bots.
llvm-svn: 185744
|
| |
|
|
| |
llvm-svn: 185743
|
| |
|
|
| |
llvm-svn: 185742
|
| |
|
|
| |
llvm-svn: 185741
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first patch in a series of 3 patches which clean up how we create
runtime function declarations in the ARC optimizer when they do not exist
already in the IR.
Currently we have a bunch of duplicated code in ObjCARCOpts, ObjCARCContract
that does this. This patch refactors that code into a separate class called
ARCRuntimeEntryPoints which lazily creates the declarations for said
entrypoints.
The next two patches will consist of the work of refactoring
ObjCARCContract/ObjCARCOpts to use this new code.
llvm-svn: 185740
|
| |
|
|
|
|
| |
Thanks to Bill Wendling for pointing this out!
llvm-svn: 184593
|
| |
|
|
|
|
| |
PtrState.RRI private and delete the TODO.
llvm-svn: 184587
|
| |
|
|
|
|
| |
several methods on PtrState.
llvm-svn: 184586
|
| |
|
|
|
|
| |
PtrState.IsTrackingImpreciseRelease().
llvm-svn: 184583
|
| |
|
|
|
|
| |
PtrState.{IsCFGHazardAfflicted,SetCFGHazardAfflicted}.
llvm-svn: 184582
|
| |
|
|
|
|
| |
PtrState.GetReleaseMetadata() and PtrState.SetReleaseMetadata().
llvm-svn: 184534
|
| |
|
|
|
|
| |
PtrState.IsTailCallRelease() and PtrState.SetTailCallRelease().
llvm-svn: 184533
|
| |
|
|
|
|
|
|
|
|
|
|
| |
PtrState.IsKnownSafe and PtrState.SetKnownSafe.
This is apart of a series of patches to encapsulate PtrState.RRI and
make PtrState.RRI a private field of PtrState.
*NOTE* This is actually the second commit in the patch stream. I should
have put this note on the first such commit r184528.
llvm-svn: 184532
|
| |
|
|
| |
llvm-svn: 184531
|
| |
|
|
|
|
|
|
| |
RRInfo::Merge.
I also added some comments and performed minor code cleanups.
llvm-svn: 184528
|
| |
|
|
|
|
|
|
| |
TopDownPathCount/BottomUpPathCount.
rdar://12480535
llvm-svn: 183489
|
| |
|
|
|
|
|
|
| |
across CFG edges since even if it is safe to remove RR pairs, we may still be able to move a retain/release into a loop.
rdar://13949644
llvm-svn: 182670
|
| |
|
|
|
|
|
|
| |
the pass via the usage of a global data structure.
rdar://13750319
llvm-svn: 182669
|
| |
|
|
|
|
| |
from 3 to 2 to match the rest of ObjCARCOpts.
llvm-svn: 182557
|
| |
|
|
|
|
| |
consistent about their usage of periods.
llvm-svn: 181901
|
| |
|
|
| |
llvm-svn: 181760
|
| |
|
|
|
|
| |
pointer is known positive.
llvm-svn: 181745
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
if and only if we are both KnownSafeBU/KnownSafeTD rather than just either or.
In the presense of a block being initialized, the frontend will emit the
objc_retain on the original pointer and the release on the pointer loaded from
the alloca. The optimizer will through the provenance analysis realize that the
two are related (albiet different), but since we only require KnownSafe in one
direction, will match the inner retain on the original pointer with the guard
release on the original pointer. This is fixed by ensuring that in the presense
of allocas we only unconditionally remove pointers if both our retain and our
release are KnownSafe (i.e. we are KnownSafe in both directions) since we must
deal with the possibility that the frontend will emit what (to the optimizer)
appears to be unbalanced retain/releases.
An example of the miscompile is:
%A = alloca
retain(%x)
retain(%x) <--- Inner Retain
store %x, %A
%y = load %A
... DO STUFF ...
release(%y)
call void @use(%x)
release(%x) <--- Guarding Release
getting optimized to:
%A = alloca
retain(%x)
store %x, %A
%y = load %A
... DO STUFF ...
release(%y)
call void @use(%x)
rdar://13750319
llvm-svn: 181743
|
| |
|
|
|
|
| |
Suppresses an unused-variable warning in -Asserts builds.
llvm-svn: 181733
|
| |
|
|
|
|
| |
get{TopDown,BottomUp}PtrState will create a new PtrState object if it does not find a PtrState for Arg.
llvm-svn: 181726
|
| |
|
|
|
|
|
|
|
|
|
| |
OptimizeIndividualCalls.
This makes the statistics gathering completely independent of the actual
optimization occuring, preventing any sort of bleeding over from occuring.
Additionally, it simplifies a switch statement in the non-statistic gathering case.
llvm-svn: 181719
|
| |
|
|
|
|
|
|
| |
constructor enables
Patch by Robert Wilhelm.
llvm-svn: 181138
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the things, and renames it to CBindingWrapping.h. I also moved
CBindingWrapping.h into Support/.
This new file just contains the macros for defining different wrap/unwrap
methods.
The calls to those macros, as well as any custom wrap/unwrap definitions
(like for array of Values for example), are put into corresponding C++
headers.
Doing this required some #include surgery, since some .cpp files relied
on the fact that including Wrap.h implicitly caused the inclusion of a
bunch of other things.
This also now means that the C++ headers will include their corresponding
C API headers; for example Value.h must include llvm-c/Core.h. I think
this is harmless, since the C API headers contain just external function
declarations and some C types, so I don't believe there should be any
nasty dependency issues here.
llvm-svn: 180881
|
| |
|
|
|
|
| |
warning.
llvm-svn: 180700
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ObjCARCContract instead of ObjCARCOpts.
Turning retains into retainRV calls disrupts the data flow analysis in
ObjCARCOpts. Thus we move it as late as we can by moving it into
ObjCARCContract.
We leave in the conversion from retainRV -> retain in ObjCARCOpt since
it enables the dataflow analysis.
rdar://10813093
llvm-svn: 180698
|
| |
|
|
|
|
| |
optimization.
llvm-svn: 180697
|
| |
|
|
| |
llvm-svn: 180696
|
| |
|
|
| |
llvm-svn: 180694
|
| |
|
|
|
|
| |
ConnectTDBUTraversals so that I can prevent Changed = true from being set. This prevents an infinite loop.
llvm-svn: 180693
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
that were once autoreleaseRV instructions."
This reverts commit r180222.
I think this might tie in with a different problem which will require a
different approach potentially. I am reverting this in the case I need to go
down that second path.
My apologies for the noise. = /.
llvm-svn: 180590
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
were once autoreleaseRV instructions.
Due to the semantics of ARC, we must be extremely conservative with autorelease
calls inserted by the frontend since ARC gaurantees that said object will be in
the autorelease pool after that point, an optimization invariant that the
optimizer must respect.
On the other hand, we are allowed significantly more flexibility with
autoreleaseRV instructions.
Often times though this flexibility is disrupted by early transformations which
transform objc_autoreleaseRV => objc_autorelease if said instruction is no
longer being used as part of an RV pair (generally due to inlining). Since we
can not tell the difference in between an autorelease put into place by the
frontend and one created through said ``strength reduction'' we can not perform
these optimizations.
The addition of this set gets around said issues by allowing us to differentiate
in between said two cases.
rdar://problem/13697741.
llvm-svn: 180222
|
| |
|
|
| |
llvm-svn: 180221
|
| |
|
|
|
|
|
| |
or the C++ files themselves. This enables people to use
just a C compiler to interoperate with LLVM.
llvm-svn: 180063
|
| |
|
|
|
|
| |
NumPeeps and make sure that Changed is set to true.
llvm-svn: 179968
|
| |
|
|
| |
llvm-svn: 179967
|
| |
|
|
| |
llvm-svn: 179966
|
| |
|
|
| |
llvm-svn: 179965
|
| |
|
|
|
|
| |
large multi-level nested if statement.
llvm-svn: 179964
|