llvm/test/Transforms/ObjCARC, branch stable

Updated test0 of retain-not-declared.ll to reflect the fact that objc-arc-expand runs before objc-arc/objc-arc-contract.

2013-03-29T22:44:59Z

Specifically, objc-arc-expand will make sure that the objc_retainAutoreleasedReturnValue, objc_autoreleaseReturnValue, and ret will all have %call as an argument. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178382 91177308-0d34-0410-b5e6-96231b3b80d8

Add clang.arc.used to ModuleHasARC so ARC always runs if said call is present in a module.

2013-03-29T21:15:23Z

clang.arc.used is an interesting call for ARC since ObjCARCContract needs to run to remove said intrinsic to avoid a linker error (since the call does not exist). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178369 91177308-0d34-0410-b5e6-96231b3b80d8

Non optimizable objc_retainBlock calls are not forwarding.

2013-03-28T20:11:30Z

Since we handle optimizable objc_retainBlocks through strength reduction in OptimizableIndividualCalls, we know that all code after that point will only see non-optimizable objc_retainBlock calls. IsForwarding is only called by functions after that point, so it is ok to just classify objc_retainBlock as non-forwarding. . git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178285 91177308-0d34-0410-b5e6-96231b3b80d8

[ObjCARC] Strength reduce objc_retainBlock -> objc_retain if the objc_retainBlock is optimizable.

2013-03-28T20:11:19Z

If an objc_retainBlock has the copy_on_escape metadata attached to it AND if the block pointer argument only escapes down the stack, we are allowed to strength reduce the objc_retainBlock to to an objc_retain and thus optimize it. Current there is logic in the ARC data flow analysis to handle this case which is complicated and involved making distinctions in between objc_retainBlock and objc_retain in certain places and considering them the same in others. This patch simplifies said code by: 1. Performing the strength reduction in the initial ARC peephole analysis (ObjCARCOpts::OptimizeIndividualCalls). 2. Changes the ARC dataflow analysis (which runs after the peephole analysis) to consider all objc_retainBlock calls to not be optimizable (since if the call was optimizable, we would have strength reduced it already). This patch leaves in the infrastructure in the ARC dataflow analysis to handle this case, which due to 2 will just be dead code. I am doing this on purpose to separate the removal of the old code from the testing of the new code. . git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178284 91177308-0d34-0410-b5e6-96231b3b80d8

Added back in the test for arc-annotations.

2013-03-27T00:09:58Z

The test was removed since I had not turned off the test during release builds. This fails since ARC annotations support is conditionally compiled out during release builds. I added the proper requires header to assuage this issue. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178101 91177308-0d34-0410-b5e6-96231b3b80d8

Remove testcase. It's failing on some platforms but not others.

2013-03-26T01:10:03Z

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177956 91177308-0d34-0410-b5e6-96231b3b80d8

Hmm...not failing...odd

2013-03-26T01:08:02Z

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177955 91177308-0d34-0410-b5e6-96231b3b80d8

Temporarily XFAIL this test until Michael can look at it.

2013-03-26T00:46:31Z

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177953 91177308-0d34-0410-b5e6-96231b3b80d8

[ObjCARC Annotations] Added support for displaying the state of pointers at the bottom/top of BBs of the ARC dataflow analysis for both bottomup and topdown analyses.

2013-03-26T00:42:09Z

This will allow for verification and analysis of the merge function of the data flow analyses in the ARC optimizer. The actual implementation of this feature is by introducing calls to the functions llvm.arc.annotation.{bottomup,topdown}.{bbstart,bbend} which are only declared. Each such call takes in a pointer to a global with the same name as the pointer whose provenance is being tracked and a pointer whose name is one of our Sequence states and points to a string that contains the same name. To ensure that the optimizer does not consider these annotations in any way, I made it so that the annotations are considered to be of IC_None type. A test case is included for this commit and the previous ObjCARCAnnotation commit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177952 91177308-0d34-0410-b5e6-96231b3b80d8

Add an optimizer-side test case for ARC bug , fixed

2013-03-25T22:09:52Z

in the frontend with @clang.arc.use. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177928 91177308-0d34-0410-b5e6-96231b3b80d8