+
+define i32 @PR14572.2(<3 x i8> %x) {
+; Ensure that a split integer load which is wider than the type size of the
+; alloca (relying on the alloc size padding) doesn't trigger an assert.
+; CHECK: @PR14572.2
+
+entry:
+ %a = alloca <3 x i8>, align 4
+; CHECK-NOT: alloca
+
+ store <3 x i8> %x, <3 x i8>* %a, align 1
+ %cast = bitcast <3 x i8>* %a to i32*
+ %y = load i32, i32* %cast, align 4
+ ret i32 %y
+; CHECK: ret i32
+}
+
+define i32 @PR14601(i32 %x) {
+; Don't try to form a promotable integer alloca when there is a variable length
+; memory intrinsic.
+; CHECK-LABEL: @PR14601(
+
+entry:
+ %a = alloca i32
+; CHECK: alloca
+
+ %a.i8 = bitcast i32* %a to i8*
+ call void @llvm.memset.p0i8.i32(i8* %a.i8, i8 0, i32 %x, i32 1, i1 false)
+ %v = load i32, i32* %a
+ ret i32 %v
+}
+
+define void @PR15674(i8* %data, i8* %src, i32 %size) {
+; Arrange (via control flow) to have unmerged stores of a particular width to
+; an alloca where we incrementally store from the end of the array toward the
+; beginning of the array. Ensure that the final integer store, despite being
+; convertable to the integer type that we end up promoting this alloca toward,
+; doesn't get widened to a full alloca store.
+; CHECK-LABEL: @PR15674(
+
+entry:
+ %tmp = alloca [4 x i8], align 1
+; CHECK: alloca i32
+
+ switch i32 %size, label %end [
+ i32 4, label %bb4
+ i32 3, label %bb3
+ i32 2, label %bb2
+ i32 1, label %bb1
+ ]
+
+bb4:
+ %src.gep3 = getelementptr inbounds i8, i8* %src, i32 3
+ %src.3 = load i8, i8* %src.gep3
+ %tmp.gep3 = getelementptr inbounds [4 x i8], [4 x i8]* %tmp, i32 0, i32 3
+ store i8 %src.3, i8* %tmp.gep3
+; CHECK: store i8
+
+ br label %bb3
+
+bb3:
+ %src.gep2 = getelementptr inbounds i8, i8* %src, i32 2
+ %src.2 = load i8, i8* %src.gep2
+ %tmp.gep2 = getelementptr inbounds [4 x i8], [4 x i8]* %tmp, i32 0, i32 2
+ store i8 %src.2, i8* %tmp.gep2
+; CHECK: store i8
+
+ br label %bb2
+
+bb2:
+ %src.gep1 = getelementptr inbounds i8, i8* %src, i32 1
+ %src.1 = load i8, i8* %src.gep1
+ %tmp.gep1 = getelementptr inbounds [4 x i8], [4 x i8]* %tmp, i32 0, i32 1
+ store i8 %src.1, i8* %tmp.gep1
+; CHECK: store i8
+
+ br label %bb1
+
+bb1:
+ %src.gep0 = getelementptr inbounds i8, i8* %src, i32 0
+ %src.0 = load i8, i8* %src.gep0
+ %tmp.gep0 = getelementptr inbounds [4 x i8], [4 x i8]* %tmp, i32 0, i32 0
+ store i8 %src.0, i8* %tmp.gep0
+; CHECK: store i8
+
+ br label %end
+
+end:
+ %tmp.raw = bitcast [4 x i8]* %tmp to i8*
+ call void @llvm.memcpy.p0i8.p0i8.i32(i8* %data, i8* %tmp.raw, i32 %size, i32 1, i1 false)
+ ret void
+; CHECK: ret void
+}
+
+define void @PR15805(i1 %a, i1 %b) {
+; CHECK-LABEL: @PR15805(
+; CHECK-NOT: alloca
+; CHECK: ret void
+
+ %c = alloca i64, align 8
+ %p.0.c = select i1 undef, i64* %c, i64* %c
+ %cond.in = select i1 undef, i64* %p.0.c, i64* %c
+ %cond = load i64, i64* %cond.in, align 8
+ ret void
+}
+
+define void @PR15805.1(i1 %a, i1 %b) {
+; Same as the normal PR15805, but rigged to place the use before the def inside
+; of looping unreachable code. This helps ensure that we aren't sensitive to the
+; order in which the uses of the alloca are visited.
+;
+; CHECK-LABEL: @PR15805.1(
+; CHECK-NOT: alloca
+; CHECK: ret void
+
+ %c = alloca i64, align 8
+ br label %exit
+
+loop:
+ %cond.in = select i1 undef, i64* %c, i64* %p.0.c
+ %p.0.c = select i1 undef, i64* %c, i64* %c
+ %cond = load i64, i64* %cond.in, align 8
+ br i1 undef, label %loop, label %exit
+
+exit:
+ ret void
+}
+
+define void @PR16651.1(i8* %a) {
+; This test case caused a crash due to the volatile memcpy in combination with
+; lowering to integer loads and stores of a width other than that of the original
+; memcpy.
+;
+; CHECK-LABEL: @PR16651.1(
+; CHECK: alloca i16
+; CHECK: alloca i8
+; CHECK: alloca i8
+; CHECK: unreachable
+
+entry:
+ %b = alloca i32, align 4
+ %b.cast = bitcast i32* %b to i8*
+ call void @llvm.memcpy.p0i8.p0i8.i32(i8* %b.cast, i8* %a, i32 4, i32 4, i1 true)
+ %b.gep = getelementptr inbounds i8, i8* %b.cast, i32 2
+ load i8, i8* %b.gep, align 2
+ unreachable
+}
+
+define void @PR16651.2() {
+; This test case caused a crash due to failing to promote given a select that
+; can't be speculated. It shouldn't be promoted, but we missed that fact when
+; analyzing whether we could form a vector promotion because that code didn't
+; bail on select instructions.
+;
+; CHECK-LABEL: @PR16651.2(
+; CHECK: alloca <2 x float>
+; CHECK: ret void
+
+entry:
+ %tv1 = alloca { <2 x float>, <2 x float> }, align 8
+ %0 = getelementptr { <2 x float>, <2 x float> }, { <2 x float>, <2 x float> }* %tv1, i64 0, i32 1
+ store <2 x float> undef, <2 x float>* %0, align 8
+ %1 = getelementptr inbounds { <2 x float>, <2 x float> }, { <2 x float>, <2 x float> }* %tv1, i64 0, i32 1, i64 0
+ %cond105.in.i.i = select i1 undef, float* null, float* %1
+ %cond105.i.i = load float, float* %cond105.in.i.i, align 8
+ ret void
+}
+
+define void @test23(i32 %x) {
+; CHECK-LABEL: @test23(
+; CHECK-NOT: alloca
+; CHECK: ret void
+entry:
+ %a = alloca i32, align 4
+ store i32 %x, i32* %a, align 4
+ %gep1 = getelementptr inbounds i32, i32* %a, i32 1
+ %gep0 = getelementptr inbounds i32, i32* %a, i32 0
+ %cast1 = bitcast i32* %gep1 to i8*
+ %cast0 = bitcast i32* %gep0 to i8*
+ call void @llvm.memcpy.p0i8.p0i8.i32(i8* %cast1, i8* %cast0, i32 4, i32 1, i1 false)
+ ret void
+}
+
+define void @PR18615() {
+; CHECK-LABEL: @PR18615(
+; CHECK-NOT: alloca
+; CHECK: ret void
+entry:
+ %f = alloca i8
+ %gep = getelementptr i8, i8* %f, i64 -1
+ call void @llvm.memcpy.p0i8.p0i8.i32(i8* undef, i8* %gep, i32 1, i32 1, i1 false)
+ ret void
+}
+
+define void @test24(i8* %src, i8* %dst) {
+; CHECK-LABEL: @test24(
+; CHECK: alloca i64, align 16
+; CHECK: load volatile i64, i64* %{{[^,]*}}, align 1
+; CHECK: store volatile i64 %{{[^,]*}}, i64* %{{[^,]*}}, align 16
+; CHECK: load volatile i64, i64* %{{[^,]*}}, align 16
+; CHECK: store volatile i64 %{{[^,]*}}, i64* %{{[^,]*}}, align 1
+
+entry:
+ %a = alloca i64, align 16
+ %ptr = bitcast i64* %a to i8*
+ call void @llvm.memcpy.p0i8.p0i8.i32(i8* %ptr, i8* %src, i32 8, i32 1, i1 true)
+ call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dst, i8* %ptr, i32 8, i32 1, i1 true)
+ ret void
+}
+
+define float @test25() {
+; Check that we split up stores in order to promote the smaller SSA values.. These types
+; of patterns can arise because LLVM maps small memcpy's to integer load and
+; stores. If we get a memcpy of an aggregate (such as C and C++ frontends would
+; produce, but so might any language frontend), this will in many cases turn into
+; an integer load and store. SROA needs to be extremely powerful to correctly
+; handle these cases and form splitable and promotable SSA values.
+;
+; CHECK-LABEL: @test25(
+; CHECK-NOT: alloca
+; CHECK: %[[F1:.*]] = bitcast i32 0 to float
+; CHECK: %[[F2:.*]] = bitcast i32 1065353216 to float
+; CHECK: %[[SUM:.*]] = fadd float %[[F1]], %[[F2]]
+; CHECK: ret float %[[SUM]]
+
+entry:
+ %a = alloca i64
+ %b = alloca i64
+ %a.cast = bitcast i64* %a to [2 x float]*
+ %a.gep1 = getelementptr [2 x float], [2 x float]* %a.cast, i32 0, i32 0
+ %a.gep2 = getelementptr [2 x float], [2 x float]* %a.cast, i32 0, i32 1
+ %b.cast = bitcast i64* %b to [2 x float]*
+ %b.gep1 = getelementptr [2 x float], [2 x float]* %b.cast, i32 0, i32 0
+ %b.gep2 = getelementptr [2 x float], [2 x float]* %b.cast, i32 0, i32 1
+ store float 0.0, float* %a.gep1
+ store float 1.0, float* %a.gep2
+ %v = load i64, i64* %a
+ store i64 %v, i64* %b
+ %f1 = load float, float* %b.gep1
+ %f2 = load float, float* %b.gep2
+ %ret = fadd float %f1, %f2
+ ret float %ret
+}
+
+@complex1 = external global [2 x float]
+@complex2 = external global [2 x float]
+
+define void @test26() {
+; Test a case of splitting up loads and stores against a globals.
+;
+; CHECK-LABEL: @test26(
+; CHECK-NOT: alloca
+; CHECK: %[[L1:.*]] = load i32, i32* bitcast
+; CHECK: %[[L2:.*]] = load i32, i32* bitcast
+; CHECK: %[[F1:.*]] = bitcast i32 %[[L1]] to float
+; CHECK: %[[F2:.*]] = bitcast i32 %[[L2]] to float
+; CHECK: %[[SUM:.*]] = fadd float %[[F1]], %[[F2]]
+; CHECK: %[[C1:.*]] = bitcast float %[[SUM]] to i32
+; CHECK: %[[C2:.*]] = bitcast float %[[SUM]] to i32
+; CHECK: store i32 %[[C1]], i32* bitcast
+; CHECK: store i32 %[[C2]], i32* bitcast
+; CHECK: ret void
+
+entry:
+ %a = alloca i64
+ %a.cast = bitcast i64* %a to [2 x float]*
+ %a.gep1 = getelementptr [2 x float], [2 x float]* %a.cast, i32 0, i32 0
+ %a.gep2 = getelementptr [2 x float], [2 x float]* %a.cast, i32 0, i32 1
+ %v1 = load i64, i64* bitcast ([2 x float]* @complex1 to i64*)
+ store i64 %v1, i64* %a
+ %f1 = load float, float* %a.gep1
+ %f2 = load float, float* %a.gep2
+ %sum = fadd float %f1, %f2
+ store float %sum, float* %a.gep1
+ store float %sum, float* %a.gep2
+ %v2 = load i64, i64* %a
+ store i64 %v2, i64* bitcast ([2 x float]* @complex2 to i64*)
+ ret void
+}
+
+define float @test27() {
+; Another, more complex case of splittable i64 loads and stores. This example
+; is a particularly challenging one because the load and store both point into
+; the alloca SROA is processing, and they overlap but at an offset.
+;
+; CHECK-LABEL: @test27(
+; CHECK-NOT: alloca
+; CHECK: %[[F1:.*]] = bitcast i32 0 to float
+; CHECK: %[[F2:.*]] = bitcast i32 1065353216 to float
+; CHECK: %[[SUM:.*]] = fadd float %[[F1]], %[[F2]]
+; CHECK: ret float %[[SUM]]
+
+entry:
+ %a = alloca [12 x i8]
+ %gep1 = getelementptr [12 x i8], [12 x i8]* %a, i32 0, i32 0
+ %gep2 = getelementptr [12 x i8], [12 x i8]* %a, i32 0, i32 4
+ %gep3 = getelementptr [12 x i8], [12 x i8]* %a, i32 0, i32 8
+ %iptr1 = bitcast i8* %gep1 to i64*
+ %iptr2 = bitcast i8* %gep2 to i64*
+ %fptr1 = bitcast i8* %gep1 to float*
+ %fptr2 = bitcast i8* %gep2 to float*
+ %fptr3 = bitcast i8* %gep3 to float*
+ store float 0.0, float* %fptr1
+ store float 1.0, float* %fptr2
+ %v = load i64, i64* %iptr1
+ store i64 %v, i64* %iptr2
+ %f1 = load float, float* %fptr2
+ %f2 = load float, float* %fptr3
+ %ret = fadd float %f1, %f2
+ ret float %ret
+}
+
+define i32 @PR22093() {
+; Test that we don't try to pre-split a splittable store of a splittable but
+; not pre-splittable load over the same alloca. We "handle" this case when the
+; load is unsplittable but unrelated to this alloca by just generating extra
+; loads without touching the original, but when the original load was out of
+; this alloca we need to handle it specially to ensure the splits line up
+; properly for rewriting.
+;
+; CHECK-LABEL: @PR22093(
+; CHECK-NOT: alloca
+; CHECK: alloca i16
+; CHECK-NOT: alloca
+; CHECK: store volatile i16
+
+entry:
+ %a = alloca i32
+ %a.cast = bitcast i32* %a to i16*
+ store volatile i16 42, i16* %a.cast
+ %load = load i32, i32* %a
+ store i32 %load, i32* %a
+ ret i32 %load
+}
+
+define void @PR22093.2() {
+; Another way that we end up being unable to split a particular set of loads
+; and stores can even have ordering importance. Here we have a load which is
+; pre-splittable by itself, and the first store is also compatible. But the
+; second store of the load makes the load unsplittable because of a mismatch of
+; splits. Because this makes the load unsplittable, we also have to go back and
+; remove the first store from the presplit candidates as its load won't be
+; presplit.
+;
+; CHECK-LABEL: @PR22093.2(
+; CHECK-NOT: alloca
+; CHECK: alloca i16
+; CHECK-NEXT: alloca i8
+; CHECK-NOT: alloca
+; CHECK: store volatile i16
+; CHECK: store volatile i8
+
+entry:
+ %a = alloca i64
+ %a.cast1 = bitcast i64* %a to i32*
+ %a.cast2 = bitcast i64* %a to i16*
+ store volatile i16 42, i16* %a.cast2
+ %load = load i32, i32* %a.cast1
+ store i32 %load, i32* %a.cast1
+ %a.gep1 = getelementptr i32, i32* %a.cast1, i32 1
+ %a.cast3 = bitcast i32* %a.gep1 to i8*
+ store volatile i8 13, i8* %a.cast3
+ store i32 %load, i32* %a.gep1
+ ret void
+}
+
+define void @PR23737() {
+; CHECK-LABEL: @PR23737(
+; CHECK: store atomic volatile {{.*}} seq_cst
+; CHECK: load atomic volatile {{.*}} seq_cst
+entry:
+ %ptr = alloca i64, align 8
+ store atomic volatile i64 0, i64* %ptr seq_cst, align 8
+ %load = load atomic volatile i64, i64* %ptr seq_cst, align 8
+ ret void
+}
+
+define i16 @PR24463() {
+; Ensure we can handle a very interesting case where there is an integer-based
+; rewrite of the uses of the alloca, but where one of the integers in that is
+; a sub-integer that requires extraction *and* extends past the end of the
+; alloca. In this case, we should extract the i8 and then zext it to i16.
+;
+; CHECK-LABEL: @PR24463(
+; CHECK-NOT: alloca
+; CHECK: %[[SHIFT:.*]] = lshr i16 0, 8
+; CHECK: %[[TRUNC:.*]] = trunc i16 %[[SHIFT]] to i8
+; CHECK: %[[ZEXT:.*]] = zext i8 %[[TRUNC]] to i16
+; CHECK: ret i16 %[[ZEXT]]
+entry:
+ %alloca = alloca [3 x i8]
+ %gep1 = getelementptr inbounds [3 x i8], [3 x i8]* %alloca, i64 0, i64 1
+ %bc1 = bitcast i8* %gep1 to i16*
+ store i16 0, i16* %bc1
+ %gep2 = getelementptr inbounds [3 x i8], [3 x i8]* %alloca, i64 0, i64 2
+ %bc2 = bitcast i8* %gep2 to i16*
+ %load = load i16, i16* %bc2
+ ret i16 %load
+}