[objc-arc] Do not mismatch up retains inside a for loop with releases outside said...
authorMichael Gottesman <mgottesman@apple.com>
Thu, 18 Apr 2013 05:39:45 +0000 (05:39 +0000)
committerMichael Gottesman <mgottesman@apple.com>
Thu, 18 Apr 2013 05:39:45 +0000 (05:39 +0000)
commit0556900b260eed881a2f47a2b5267ae3a7cc7ae0
tree52ee4c83f19137ad18305a7edf6c58e6cfb8152d
parent8a709208ede8eb387a2911c5ba11e5acf8cc69ae
[objc-arc] Do not mismatch up retains inside a for loop with releases outside said for loop in the presense of differing provenance caused by escaping blocks.

This occurs due to an alloca representing a separate ownership from the
original pointer. Thus consider the following pseudo-IR:

  objc_retain(%a)
  for (...) {
    objc_retain(%a)
    %block <- %a
    F(%block)
    objc_release(%block)
  }
  objc_release(%a)

From the perspective of the optimizer, the %block is a separate
provenance from the original %a. Thus the optimizer pairs up the inner
retain for %a and the outer release from %a, resulting in segfaults.

This is fixed by noting that the signature of a mismatch of
retain/releases inside the for loop is a Use/CanRelease top down with an
None bottom up (since bottom up the Retain-CanRelease-Use-Release
sequence is completed by the inner objc_retain, but top down due to the
differing provenance from the objc_release said sequence is not
completed). In said case in CheckForCFGHazards, we now clear the state
of %a implying that no pairing will occur.

Additionally a test case is included.

rdar://12969722

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179747 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Transforms/ObjCARC/ObjCARCOpts.cpp
test/Transforms/ObjCARC/cfg-hazards.ll