The bug showed up as a compile-time assertion failure:
Assertion `NumBits >= MIN_INT_BITS && "bitwidth too small"' failed
when building msan tests on x86-64.
Prior to r236850, this bug was masked due to a bogus alignment check,
which also accidentally rejected non-byte-sized accesses. Afterwards,
an invalid ElementSizeBytes == 0 got further into the function, and
triggered the assertion failure.
It would probably be a good idea to allow it to handle merging stores
of unusual widths as well, but for now, to un-break it, I'm just
making the minimal fix.
Differential Revision: http://reviews.llvm.org/D9626
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236927
91177308-0d34-0410-b5e6-
96231b3b80d8
bool NoVectors = DAG.getMachineFunction().getFunction()->hasFnAttribute(
Attribute::NoImplicitFloat);
+ // This function cannot currently deal with non-byte-sized memory sizes.
+ if (ElementSizeBytes * 8 != MemVT.getSizeInBits())
+ return false;
+
// Don't merge vectors into wider inputs.
if (MemVT.isVector() || !MemVT.isSimple())
return false;
--- /dev/null
+; RUN: llc -march=x86-64 < %s
+
+; Ensure that MergeConsecutiveStores doesn't crash when dealing with
+; i1 operands.
+
+%struct.X = type { i1, i1 }
+
+@b = common global %struct.X zeroinitializer, align 4
+
+define void @foo() {
+entry:
+ store i1 0, i1* getelementptr inbounds (%struct.X, %struct.X* @b, i64 0, i32 0), align 4
+ store i1 0, i1* getelementptr inbounds (%struct.X, %struct.X* @b, i64 0, i32 1), align 1
+ ret void
+}