pr4926: ARM requires the stack pointer to be aligned, even for leaf functions.
For the AAPCS ABI, SP must always be 4-byte aligned, and at any "public
interface" it must be 8-byte aligned. For the older ARM APCS ABI, the stack
alignment is just always 4 bytes. For X86, we currently align SP at
entry to a function (e.g., to 16 bytes for Darwin), but no stack alignment
is needed at other times, such as for a leaf function.
After discussing this with Dan, I decided to go with the approach of adding
a new "TransientStackAlignment" field to TargetFrameInfo. This value
specifies the stack alignment that must be maintained even in between calls.
It defaults to 1 except for ARM, where it is 4. (Some other targets may
also want to set this if they have similar stack requirements. It's not
currently required for PPC because it sets targetHandlesStackFrameRounding
and handles the alignment in target-specific code.) The existing StackAlignment
value specifies the alignment upon entry to a function, which is how we've
been using it anyway.
llvm-svn: 82767
2009-09-25 16:41:49 +02:00
|
|
|
; RUN: llc < %s -march=arm -mattr=+neon | FileCheck %s
|
|
|
|
|
; pr4926
|
|
|
|
|
|
2010-06-17 17:18:27 +02:00
|
|
|
define void @test_vget_lanep16() nounwind {
|
pr4926: ARM requires the stack pointer to be aligned, even for leaf functions.
For the AAPCS ABI, SP must always be 4-byte aligned, and at any "public
interface" it must be 8-byte aligned. For the older ARM APCS ABI, the stack
alignment is just always 4 bytes. For X86, we currently align SP at
entry to a function (e.g., to 16 bytes for Darwin), but no stack alignment
is needed at other times, such as for a leaf function.
After discussing this with Dan, I decided to go with the approach of adding
a new "TransientStackAlignment" field to TargetFrameInfo. This value
specifies the stack alignment that must be maintained even in between calls.
It defaults to 1 except for ARM, where it is 4. (Some other targets may
also want to set this if they have similar stack requirements. It's not
currently required for PPC because it sets targetHandlesStackFrameRounding
and handles the alignment in target-specific code.) The existing StackAlignment
value specifies the alignment upon entry to a function, which is how we've
been using it anyway.
llvm-svn: 82767
2009-09-25 16:41:49 +02:00
|
|
|
entry:
|
|
|
|
|
%arg0_poly16x4_t = alloca <4 x i16> ; <<4 x i16>*> [#uses=1]
|
|
|
|
|
%out_poly16_t = alloca i16 ; <i16*> [#uses=1]
|
|
|
|
|
%"alloca point" = bitcast i32 0 to i32 ; <i32> [#uses=0]
|
2011-11-15 00:03:21 +01:00
|
|
|
; CHECK: vldr
|
pr4926: ARM requires the stack pointer to be aligned, even for leaf functions.
For the AAPCS ABI, SP must always be 4-byte aligned, and at any "public
interface" it must be 8-byte aligned. For the older ARM APCS ABI, the stack
alignment is just always 4 bytes. For X86, we currently align SP at
entry to a function (e.g., to 16 bytes for Darwin), but no stack alignment
is needed at other times, such as for a leaf function.
After discussing this with Dan, I decided to go with the approach of adding
a new "TransientStackAlignment" field to TargetFrameInfo. This value
specifies the stack alignment that must be maintained even in between calls.
It defaults to 1 except for ARM, where it is 4. (Some other targets may
also want to set this if they have similar stack requirements. It's not
currently required for PPC because it sets targetHandlesStackFrameRounding
and handles the alignment in target-specific code.) The existing StackAlignment
value specifies the alignment upon entry to a function, which is how we've
been using it anyway.
llvm-svn: 82767
2009-09-25 16:41:49 +02:00
|
|
|
%0 = load <4 x i16>* %arg0_poly16x4_t, align 8 ; <<4 x i16>> [#uses=1]
|
|
|
|
|
%1 = extractelement <4 x i16> %0, i32 1 ; <i16> [#uses=1]
|
|
|
|
|
store i16 %1, i16* %out_poly16_t, align 2
|
|
|
|
|
br label %return
|
|
|
|
|
|
|
|
|
|
return: ; preds = %entry
|
|
|
|
|
ret void
|
|
|
|
|
}
|
