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/Mips/adjust-callstack-sp.ll

21 lines
851 B
LLVM
Raw Normal View History

[mips][mips16] MIPS16 is not a CPU/Architecture but is an ASE. Summary: The -mcpu=mips16 option caused the Integrated Assembler to crash because it couldn't figure out the architecture revision number to write to the .MIPS.abiflags section. This CPU definition has been removed because, like microMIPS, MIPS16 is an ASE to a base architecture. Reviewers: vkalintiris Subscribers: rkotler, llvm-commits, dsanders Differential Revision: http://reviews.llvm.org/D13656 llvm-svn: 250407
2015-10-15 22:34:23 +08:00
; RUN: llc < %s -march=mips -mattr=mips16 | FileCheck %s -check-prefix=M16
[mips] Make sure that we don't adjust the stack pointer by zero amount. Reviewers: dsanders Reviewed By: dsanders Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8638 llvm-svn: 233904
2015-04-02 18:14:54 +08:00
; RUN: llc < %s -march=mips -mcpu=mips2 | FileCheck %s -check-prefix=GP32
; RUN: llc < %s -march=mips -mcpu=mips32 | FileCheck %s -check-prefix=GP32
; RUN: llc < %s -march=mips -mcpu=mips32r6 | FileCheck %s -check-prefix=GP32
[mips] Don't derive the default ABI from the CPU in the backend. Summary: The backend has no reason to behave like a driver and should generally do as it's told (and error out if it can't) instead of trying to figure out what the API user meant. The default ABI is still derived from the arch component as a concession to backwards compatibility. API-users that previously passed an explicit CPU and a triple that was inconsistent with the CPU (e.g. mips-linux-gnu and mips64r2) may get a different ABI to what they got before. However, it's expected that there are no such users on the basis that CodeGen has been asserting that the triple is consistent with the selected ABI for several releases. API-users that were consistent or passed '' or 'generic' as the CPU will see no difference. Reviewers: sdardis, rafael Subscribers: rafael, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21466 llvm-svn: 273557
2016-06-23 20:42:53 +08:00
; RUN: llc < %s -march=mips -mcpu=mips3 -target-abi n64 | FileCheck %s -check-prefix=GP64
; RUN: llc < %s -march=mips -mcpu=mips64 -target-abi n64 | FileCheck %s -check-prefix=GP64
; RUN: llc < %s -march=mips -mcpu=mips64r6 -target-abi n64 | FileCheck %s -check-prefix=GP64
[mips] Make sure that we don't adjust the stack pointer by zero amount. Reviewers: dsanders Reviewed By: dsanders Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8638 llvm-svn: 233904
2015-04-02 18:14:54 +08:00
declare void @bar(i32*)
define void @foo(i32 %sz) {
; ALL-LABEL: foo:
[mips] Don't derive the default ABI from the CPU in the backend. Summary: The backend has no reason to behave like a driver and should generally do as it's told (and error out if it can't) instead of trying to figure out what the API user meant. The default ABI is still derived from the arch component as a concession to backwards compatibility. API-users that previously passed an explicit CPU and a triple that was inconsistent with the CPU (e.g. mips-linux-gnu and mips64r2) may get a different ABI to what they got before. However, it's expected that there are no such users on the basis that CodeGen has been asserting that the triple is consistent with the selected ABI for several releases. API-users that were consistent or passed '' or 'generic' as the CPU will see no difference. Reviewers: sdardis, rafael Subscribers: rafael, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21466 llvm-svn: 273557
2016-06-23 20:42:53 +08:00
; M16-NOT: addiu $sp, 0 # 16 bit inst
; GP32-NOT: addiu $sp, $sp, 0
; GP64-NOT: daddiu $sp, $sp, 0
[mips] Make sure that we don't adjust the stack pointer by zero amount. Reviewers: dsanders Reviewed By: dsanders Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8638 llvm-svn: 233904
2015-04-02 18:14:54 +08:00
%a = alloca i32, i32 %sz
call void @bar(i32* %a)
ret void
}