Fix PR16651, an assert introduced in my recent re-work of the innards of

SROA.

The crux of the issue is that now we track uses of a partition of the
alloca in two places: the iterators over the partitioning uses and the
previously collected split uses vector. We weren't accounting for the
fact that the split uses might invalidate integer widening in ways other
than due to their width (in this case due to being volatile).

Further reduced testcase added to the tests.

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

1 files changed, 3 insertions, 9 deletions

diff --git a/lib/Transforms/Scalar/SROA.cpp b/lib/Transforms/Scalar/SROA.cpp
index 41e96d625a..91d5240eb5 100644
--- a/lib/Transforms/Scalar/SROA.cpp
+++ b/lib/Transforms/Scalar/SROA.cpp
@@ -1694,20 +1694,14 @@ isIntegerWideningViable(const DataLayout &TD, Type *AllocaTy,
       !canConvertValue(TD, IntTy, AllocaTy))
     return false;
 
-  // If we have no actual uses of this partition, we're forming a fully
-  // splittable partition. Assume all the operations are easy to widen (they
-  // are if they're splittable), and just check that it's a good idea to form
-  // a single integer.
-  if (I == E)
-    return TD.isLegalInteger(SizeInBits);
-
   uint64_t Size = TD.getTypeStoreSize(AllocaTy);
 
   // While examining uses, we ensure that the alloca has a covering load or
   // store. We don't want to widen the integer operations only to fail to
   // promote due to some other unsplittable entry (which we may make splittable
-  // later).
-  bool WholeAllocaOp = false;
+  // later). However, if there are only splittable uses, go ahead and assume
+  // that we cover the alloca.
+  bool WholeAllocaOp = (I != E) ? false : TD.isLegalInteger(SizeInBits);
 
   for (; I != E; ++I)
     if (!isIntegerWideningViableForPartitioning(TD, AllocaTy, AllocBeginOffset,