Fix PR13969, a mini-phase-ordering issue with the new SROA pass.
authorChandler Carruth <chandlerc@gmail.com>
Thu, 4 Oct 2012 12:33:50 +0000 (12:33 +0000)
committerChandler Carruth <chandlerc@gmail.com>
Thu, 4 Oct 2012 12:33:50 +0000 (12:33 +0000)
commitb2d98c29170d99fb43de0244a7f4f93a8893c208
tree5d521d6e5eba234e346be95b6af054db6aa8cb35
parentf58747517cf2ba55c6f89a5ddc4de63be9e1362f
Fix PR13969, a mini-phase-ordering issue with the new SROA pass.

Currently, we re-visit allocas when something changes about the way they
might be *split* to allow better scalarization to take place. However,
we weren't handling the case when the *promotion* is what would change
the behavior of SROA. When an address derived from an alloca is stored
into another alloca, we consider the first to have escaped. If the
second is ever promoted to an SSA value, we will suddenly be able to run
the SROA pass on the first alloca.

This patch adds explicit support for this form if iteration. When we
detect a store of a pointer derived from an alloca, we flag the
underlying alloca for reprocessing after promotion. The logic works hard
to only do this when there is definitely going to be promotion and it
might remove impediments to the analysis of the alloca.

Thanks to Nick for the great test case and Benjamin for some sanity
check review.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165223 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Transforms/Scalar/SROA.cpp
test/Transforms/SROA/basictest.ll