aboutsummaryrefslogtreecommitdiffstats
path: root/test/Transforms/SROA/alignment.ll
diff options
context:
space:
mode:
authorChandler Carruth <chandlerc@gmail.com>2012-10-01 12:16:54 +0000
committerChandler Carruth <chandlerc@gmail.com>2012-10-01 12:16:54 +0000
commit673850aa2dceb8fe1b7a20b72339bf803af8609f (patch)
tree36c32dd5a1769c76218f88ba8c118ea451d27d7a /test/Transforms/SROA/alignment.ll
parent90012586f79895a8104e1e65689041fec52d788d (diff)
downloadexternal_llvm-673850aa2dceb8fe1b7a20b72339bf803af8609f.zip
external_llvm-673850aa2dceb8fe1b7a20b72339bf803af8609f.tar.gz
external_llvm-673850aa2dceb8fe1b7a20b72339bf803af8609f.tar.bz2
Fix several issues with alignment. We weren't always accounting for type
alignment requirements of the new alloca. As one consequence which was reported as a bug by Duncan, we overaligned memcpy calls to ranges of allocas after they were rewritten to types with lower alignment requirements. Other consquences are possible, but I don't have any test cases for them. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164937 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'test/Transforms/SROA/alignment.ll')
-rw-r--r--test/Transforms/SROA/alignment.ll31
1 files changed, 31 insertions, 0 deletions
diff --git a/test/Transforms/SROA/alignment.ll b/test/Transforms/SROA/alignment.ll
index 02a6755..192b77e 100644
--- a/test/Transforms/SROA/alignment.ll
+++ b/test/Transforms/SROA/alignment.ll
@@ -83,3 +83,34 @@ entry:
call void @llvm.memcpy.p0i8.p0i8.i32(i8* %b_gep, i8* %x, i32 18, i32 2, i1 false)
ret void
}
+
+%struct.S = type { i8, { i64 } }
+
+define void @test4() {
+; This test case triggered very strange alginment behavior with memcpy due to
+; strang splitting. Reported by Duncan.
+; CHECK: @test4
+
+entry:
+ %D.2113 = alloca %struct.S
+ %Op = alloca %struct.S
+ %D.2114 = alloca %struct.S
+ %gep1 = getelementptr inbounds %struct.S* %Op, i32 0, i32 0
+ store i8 0, i8* %gep1, align 8
+ %gep2 = getelementptr inbounds %struct.S* %Op, i32 0, i32 1, i32 0
+ %cast = bitcast i64* %gep2 to double*
+ store double 0.000000e+00, double* %cast, align 8
+ store i64 0, i64* %gep2, align 8
+ %dst1 = bitcast %struct.S* %D.2114 to i8*
+ %src1 = bitcast %struct.S* %Op to i8*
+ call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dst1, i8* %src1, i32 16, i32 8, i1 false)
+ %dst2 = bitcast %struct.S* %D.2113 to i8*
+ %src2 = bitcast %struct.S* %D.2114 to i8*
+ call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dst2, i8* %src2, i32 16, i32 8, i1 false)
+; We get 3 memcpy calls with various reasons to shrink their alignment to 1.
+; CHECK: @llvm.memcpy.p0i8.p0i8.i32(i8* %{{.*}}, i8* %{{.*}}, i32 3, i32 1, i1 false)
+; CHECK: @llvm.memcpy.p0i8.p0i8.i32(i8* %{{.*}}, i8* %{{.*}}, i32 8, i32 1, i1 false)
+; CHECK: @llvm.memcpy.p0i8.p0i8.i32(i8* %{{.*}}, i8* %{{.*}}, i32 11, i32 1, i1 false)
+
+ ret void
+}