diff options
author | Chandler Carruth <chandlerc@gmail.com> | 2012-10-13 10:49:33 +0000 |
---|---|---|
committer | Chandler Carruth <chandlerc@gmail.com> | 2012-10-13 10:49:33 +0000 |
commit | 07525a6be6bce604f3b528c91973ac4e66742266 (patch) | |
tree | 96d66d8fdab7bb502cd9042ed36a58796b180e45 /test/Transforms/SROA/alignment.ll | |
parent | ac104272d9fc42af8dc6853853b96d489685e5a7 (diff) | |
download | external_llvm-07525a6be6bce604f3b528c91973ac4e66742266.zip external_llvm-07525a6be6bce604f3b528c91973ac4e66742266.tar.gz external_llvm-07525a6be6bce604f3b528c91973ac4e66742266.tar.bz2 |
Teach SROA to cope with wrapper aggregates. These show up a lot in ABI
type coercion code, especially when targetting ARM. Things like [1
x i32] instead of i32 are very common there.
The goal of this logic is to ensure that when we are picking an alloca
type, we look through such wrapper aggregates and across any zero-length
aggregate elements to find the simplest type possible to form a type
partition.
This logic should (generally speaking) rarely fire. It only ends up
kicking in when an alloca is accessed using two different types (for
instance, i32 and float), and the underlying alloca type has wrapper
aggregates around it. I noticed a significant amount of this occurring
looking at stepanov_abstraction generated code for arm, and suspect it
happens elsewhere as well.
Note that this doesn't yet address truly heinous IR productions such as
PR14059 is concerning. Those result in mismatched *sizes* of types in
addition to mismatched access and alloca types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165870 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'test/Transforms/SROA/alignment.ll')
-rw-r--r-- | test/Transforms/SROA/alignment.ll | 31 |
1 files changed, 0 insertions, 31 deletions
diff --git a/test/Transforms/SROA/alignment.ll b/test/Transforms/SROA/alignment.ll index 945ad91..ad5fb6c 100644 --- a/test/Transforms/SROA/alignment.ll +++ b/test/Transforms/SROA/alignment.ll @@ -84,37 +84,6 @@ entry: ret void } -%struct.S = type { i8, { i64 } } - -define void @test4() { -; This test case triggered very strange alignment behavior with memcpy due to -; strange 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 -} - define void @test5() { ; Test that we preserve underaligned loads and stores when splitting. ; CHECK: @test5 |