1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-01 08:23:21 +01:00
llvm-mirror/test/Transforms/SROA/fca.ll
Chandler Carruth 6e02238cee Teach the integer-promotion rewrite strategy to be endianness aware.
Sorry for this being broken so long. =/

As part of this, switch all of the existing tests to be Little Endian,
which is the behavior I was asserting in them anyways! Add in a new
big-endian test that checks the interesting behavior there.

Another part of this is to tighten the rules abotu when we perform the
full-integer promotion. This logic now rejects cases where there fully
promoted integer is a non-multiple-of-8 bitwidth or cases where the
loads or stores touch bits which are in the allocated space of the
alloca but are not loaded or stored when accessing the integer. Sadly,
these aren't really observable today as the rest of the pass will
already ensure the invariants hold. However, the latter situation is
likely to become a potential concern in the future.

Thanks to Benjamin and Duncan for early review of this patch. I'm still
looking into whether there are further endianness issues, please let me
know if anyone sees BE failures persisting past this.

llvm-svn: 165219
2012-10-04 10:39:28 +00:00

50 lines
1.5 KiB
LLVM

; RUN: opt < %s -sroa -S | FileCheck %s
; RUN: opt < %s -sroa -force-ssa-updater -S | FileCheck %s
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-n8:16:32:64"
define { i32, i32 } @test0(i32 %x, i32 %y) {
; CHECK: @test0
; CHECK-NOT: alloca
; CHECK: insertvalue { i32, i32 }
; CHECK: insertvalue { i32, i32 }
; CHECK: ret { i32, i32 }
entry:
%a = alloca { i32, i32 }
store { i32, i32 } undef, { i32, i32 }* %a
%gep1 = getelementptr inbounds { i32, i32 }* %a, i32 0, i32 0
store i32 %x, i32* %gep1
%gep2 = getelementptr inbounds { i32, i32 }* %a, i32 0, i32 1
store i32 %y, i32* %gep2
%result = load { i32, i32 }* %a
ret { i32, i32 } %result
}
define { i32, i32 } @test1(i32 %x, i32 %y) {
; FIXME: This may be too conservative. Duncan argues that we are allowed to
; split the volatile load and store here but must produce volatile scalar loads
; and stores from them.
; CHECK: @test1
; CHECK: alloca
; CHECK: alloca
; CHECK: load volatile { i32, i32 }*
; CHECK: store volatile { i32, i32 }
; CHECK: ret { i32, i32 }
entry:
%a = alloca { i32, i32 }
%b = alloca { i32, i32 }
%gep1 = getelementptr inbounds { i32, i32 }* %a, i32 0, i32 0
store i32 %x, i32* %gep1
%gep2 = getelementptr inbounds { i32, i32 }* %a, i32 0, i32 1
store i32 %y, i32* %gep2
%result = load volatile { i32, i32 }* %a
store volatile { i32, i32 } %result, { i32, i32 }* %b
ret { i32, i32 } %result
}