llvm-mirror/test/CodeGen/AArch64/big-callframe.ll

; RUN: llc -o - %s -verify-machineinstrs | FileCheck %s
; XFAIL: *
; Make sure we use a frame pointer and fp relative addressing for the emergency
; spillslot when we have gigantic callframes.
; CHECK-LABEL: func:
; CHECK: stur {{.*}}, [x29, #{{.*}}] // 8-byte Folded Spill
; CHECK: ldur {{.*}}, [x29, #{{.*}}] // 8-byte Folded Reload
target triple = "aarch64--"
declare void @extfunc([4096 x i64]* byval %p)
define void @func([4096 x i64]* %z) {
  %lvar = alloca [31 x i8]
  %v = load volatile [31 x i8], [31 x i8]* %lvar
  store volatile [31 x i8] %v, [31 x i8]* %lvar
  call void @extfunc([4096 x i64]* byval %z)
  ret void
}
AArch64: Fix emergency spillslot being out of reach for large callframes Re-commit of r322200: The testcase shouldn't hit machineverifiers anymore with r322917 in place. Large callframes (calls with several hundreds or thousands or parameters) could lead to situations in which the emergency spillslot is out of range to be addressed relative to the stack pointer. This commit forces the use of a frame pointer in the presence of large callframes. This commit does several things: - Compute max callframe size at the end of instruction selection. - Add mirFileLoaded target callback. Use it to compute the max callframe size after loading a .mir file when the size wasn't specified in the file. - Let TargetFrameLowering::hasFP() return true if there exists a callframe > 255 bytes. - Always place the emergency spillslot close to FP if we have a frame pointer. - Note that `useFPForScavengingIndex()` would previously return false when a base pointer was available leading to the emergency spillslot getting allocated late (that's the whole effect of this callback). Which made no sense to me so I took this case out: Even though the emergency spillslot is technically not referenced by FP in this case we still want it allocated early. Differential Revision: https://reviews.llvm.org/D40876 llvm-svn: 322919 2018-01-19 04:16:36 +01:00			`; RUN: llc -o - %s -verify-machineinstrs \| FileCheck %s`
Revert "AArch64: Omit callframe setup/destroy when not necessary" This reverts commit r322917 due to multiple performance regressions in spec2006 and spec2017. XFAILed llvm/test/CodeGen/AArch64/big-callframe.ll which initially motivated this change. llvm-svn: 323683 2018-01-29 20:56:42 +01:00			`; XFAIL: *`
AArch64: Fix emergency spillslot being out of reach for large callframes Re-commit of r322200: The testcase shouldn't hit machineverifiers anymore with r322917 in place. Large callframes (calls with several hundreds or thousands or parameters) could lead to situations in which the emergency spillslot is out of range to be addressed relative to the stack pointer. This commit forces the use of a frame pointer in the presence of large callframes. This commit does several things: - Compute max callframe size at the end of instruction selection. - Add mirFileLoaded target callback. Use it to compute the max callframe size after loading a .mir file when the size wasn't specified in the file. - Let TargetFrameLowering::hasFP() return true if there exists a callframe > 255 bytes. - Always place the emergency spillslot close to FP if we have a frame pointer. - Note that `useFPForScavengingIndex()` would previously return false when a base pointer was available leading to the emergency spillslot getting allocated late (that's the whole effect of this callback). Which made no sense to me so I took this case out: Even though the emergency spillslot is technically not referenced by FP in this case we still want it allocated early. Differential Revision: https://reviews.llvm.org/D40876 llvm-svn: 322919 2018-01-19 04:16:36 +01:00			`; Make sure we use a frame pointer and fp relative addressing for the emergency`
			`; spillslot when we have gigantic callframes.`
			`; CHECK-LABEL: func:`
			`; CHECK: stur {{.}}, [x29, #{{.}}] // 8-byte Folded Spill`
			`; CHECK: ldur {{.}}, [x29, #{{.}}] // 8-byte Folded Reload`
			`target triple = "aarch64--"`
			`declare void @extfunc([4096 x i64]* byval %p)`
			`define void @func([4096 x i64]* %z) {`
			`%lvar = alloca [31 x i8]`
			`%v = load volatile [31 x i8], [31 x i8]* %lvar`
			`store volatile [31 x i8] %v, [31 x i8]* %lvar`
			`call void @extfunc([4096 x i64]* byval %z)`
			`ret void`
			`}`