Change v64 datalayout in SPU.

The SPU ABI does not mention v64, and all examples
in C suggest v128 are treated similarily to arrays, 
we use array alignment for v64 too. This makes the 
alignment of e.g. [2 x <2 x i32>] behave "intuitively"
and similar to as if the elements were e.g. i32s.

This also makes an "unaligned store" test to be 
aligned, with different (but functionally equivalent)
code generated.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117360 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Kalle Raiskila 2010-10-26 10:45:47 +00:00
parent 15b337c28d
commit 505faa6b12
3 changed files with 16 additions and 3 deletions

View File

@ -81,7 +81,7 @@ namespace llvm {
/// properties of this subtarget.
const char *getTargetDataString() const {
return "E-p:32:32:128-f64:64:128-f32:32:128-i64:32:128-i32:32:128"
"-i16:16:128-i8:8:128-i1:8:128-a:0:128-v64:128:128-v128:128:128"
"-i16:16:128-i8:8:128-i1:8:128-a:0:128-v64:64:128-v128:128:128"
"-s:128:128-n32:64";
}
};

View File

@ -62,8 +62,7 @@ define %vec @test_insert(){
}
define void @test_unaligned_store() {
;CHECK: cdd $3, 8($3)
;CHECK: lqd
;CHECK: cdd
;CHECK: shufb
;CHECK: stqd
%data = alloca [4 x float], align 16 ; <[4 x float]*> [#uses=1]

View File

@ -61,3 +61,17 @@ define void @test_store( %vec %val, %vec* %ptr)
store %vec %val, %vec* %ptr
ret void
}
;Alignment of <2 x i32> is not *directly* defined in the ABI
;It probably is safe to interpret it as an array, thus having 8 byte
;alignment (according to ABI). This tests that the size of
;[2 x <2 x i32>] is 16 bytes, i.e. there is no padding between the
;two arrays
define <2 x i32>* @test_alignment( [2 x <2 x i32>]* %ptr)
{
; CHECK-NOT: ai $3, $3, 16
; CHECK: ai $3, $3, 8
; CHECK: bi $lr
%rv = getelementptr [2 x <2 x i32>]* %ptr, i32 0, i32 1
ret <2 x i32>* %rv
}