[ObjCARC] Strength reduce objc_retainBlock -> objc_retain if the objc_retainBlock...
authorMichael Gottesman <mgottesman@apple.com>
Thu, 28 Mar 2013 20:11:19 +0000 (20:11 +0000)
committerMichael Gottesman <mgottesman@apple.com>
Thu, 28 Mar 2013 20:11:19 +0000 (20:11 +0000)
commit0d92a3c600b453f3aa4f50ba0189ccb1dbbc1580
tree9376372b17df91277c6c487cdeae56087d188ba5
parent810848d5b3bc53747722db0d30a21dc168c5503e
[ObjCARC] Strength reduce objc_retainBlock -> objc_retain if the objc_retainBlock is optimizable.

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.

<rdar://problem/13249661>.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178284 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Transforms/ObjCARC/ObjCARCOpts.cpp
test/Transforms/ObjCARC/basic.ll
test/Transforms/ObjCARC/no-objc-arc-exceptions.ll