maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/ARM/2009-09-24-spill-align.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

18 lines
649 B
LLVM
Raw Normal View History

ARM: fixup more tests to specify the target more explicitly This changes the tests that were targeting ARM EABI to explicitly specify the environment rather than relying on the default. This breaks with the new Windows on ARM support when running the tests on Windows where the default environment is no longer EABI. Take the opportunity to avoid a pointless redirect (helps when trying to debug with providing a command line invocation which can be copy and pasted) and removing a few greps in favour of FileCheck. llvm-svn: 205541
2014-04-04 00:01:44 +08:00
; RUN: llc -mtriple=arm-eabi -mattr=+neon %s -o - | FileCheck %s
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 22:41:49 +08:00
; pr4926
Remove arm_apcscc from the test files. It is the default and doing this matches what llvm-gcc and clang now produce. llvm-svn: 106221
2010-06-17 23:18:27 +08: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 22:41:49 +08: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]
ARM VLDR/VSTR instructions don't need a size suffix. Canonicallize on the non-suffixed form, but continue to accept assembly that has any correctly sized type suffix. llvm-svn: 144583
2011-11-15 07:03:21 +08:00
; CHECK: vldr
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%0 = load <4 x i16>, <4 x i16>* %arg0_poly16x4_t, align 8 ; <<4 x i16>> [#uses=1]
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 22:41:49 +08:00
%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
}