Chandler Carruth e1a5243053 Fix a really nasty SROA bug with how we handled out-of-bounds memcpy ... intrinsics. Reported on the list by Evan with a couple of attempts to fix, but it took a while to dig down to the root cause. There are two overlapping bugs here, both centering around the circumstance of discovering a memcpy operand which is known to be completely outside the bounds of the alloca. First, we need to kill the *other* side of the memcpy if it was added to this alloca. Otherwise we'll factor it into our slicing and try to rewrite it even though we know for a fact that it is dead. This is made more tricky because we can visit the sides in either order. So we have to both kill the other side and skip instructions marked as dead. The latter really should be goodness in every case, but here is a matter of correctness. Second, we need to actually remove the *uses* of the alloca by the memcpy when queuing it for later deletion. Otherwise it may still be using the alloca when we go to promote it (if the rewrite re-uses the existing alloca instruction). Do this by factoring out the use-clobbering used when for nixing a Phi argument and re-using it across the operands of a to-be-deleted instruction. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199590 91177308-0d34-0410-b5e6-96231b3b80d8		2014-01-19 12:16:54 +00:00
..
alignment.ll
basictest.ll	Fix a really nasty SROA bug with how we handled out-of-bounds memcpy	2014-01-19 12:16:54 +00:00
big-endian.ll
fca.ll
phi-and-select.ll
vector-conversion.ll
vector-promotion.ll
vectors-of-pointers.ll