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/X86/stack-probe-size.ll

78 lines
1.6 KiB
LLVM
Raw Normal View History

X86: Allow the stack probe size to be configurable per function LLVM emits stack probes on Windows targets to ensure that the stack is correctly accessed. However, the amount of stack allocated before emitting such a probe is hardcoded to 4096. It is desirable to have this be configurable so that a function might opt-out of stack probes. Our level of granularity is at the function level instead of, say, the module level to permit proper generation of code after LTO. Patch by Andrew H! N.B. The inliner needs to be updated to properly consider what happens after inlining a function with a specific stack-probe-size into another function with a different stack-probe-size. llvm-svn: 225360
2015-01-08 02:14:07 +08:00
; This test is attempting to detect that the compiler correctly generates stack
; probe calls when the size of the local variables exceeds the specified stack
; probe size.
;
; Testing the default value of 4096 bytes makes sense, because the default
; stack probe size equals the page size (4096 bytes for all x86 targets), and
; this is unlikely to change in the future.
;
Add a target environment for CoreCLR. Although targeting CoreCLR is similar to targeting MSVC, there are certain important differences that the backend must be aware of (e.g. differences in stack probes, EH, and library calls). Differential Revision: http://reviews.llvm.org/D11012 llvm-svn: 245115
2015-08-15 06:41:43 +08:00
; RUN: llc -mtriple=i686-windows-msvc < %s | FileCheck %s
X86: Allow the stack probe size to be configurable per function LLVM emits stack probes on Windows targets to ensure that the stack is correctly accessed. However, the amount of stack allocated before emitting such a probe is hardcoded to 4096. It is desirable to have this be configurable so that a function might opt-out of stack probes. Our level of granularity is at the function level instead of, say, the module level to permit proper generation of code after LTO. Patch by Andrew H! N.B. The inliner needs to be updated to properly consider what happens after inlining a function with a specific stack-probe-size into another function with a different stack-probe-size. llvm-svn: 225360
2015-01-08 02:14:07 +08:00
target datalayout = "e-m:w-p:32:32-i64:64-f80:32-n8:16:32-S32"
define i32 @test1() "stack-probe-size"="0" {
%buffer = alloca [4095 x i8]
ret i32 0
; CHECK-LABEL: _test1:
; CHECK-NOT: subl $4095, %esp
; CHECK: movl $4095, %eax
; CHECK: calll __chkstk
}
define i32 @test2() {
%buffer = alloca [4095 x i8]
ret i32 0
; CHECK-LABEL: _test2:
; CHECK-NOT: movl $4095, %eax
; CHECK: subl $4095, %esp
; CHECK-NOT: calll __chkstk
}
define i32 @test3() "stack-probe-size"="8192" {
%buffer = alloca [4095 x i8]
ret i32 0
; CHECK-LABEL: _test3:
; CHECK-NOT: movl $4095, %eax
; CHECK: subl $4095, %esp
; CHECK-NOT: calll __chkstk
}
define i32 @test4() "stack-probe-size"="0" {
%buffer = alloca [4096 x i8]
ret i32 0
; CHECK-LABEL: _test4:
; CHECK-NOT: subl $4096, %esp
; CHECK: movl $4096, %eax
; CHECK: calll __chkstk
}
define i32 @test5() {
%buffer = alloca [4096 x i8]
ret i32 0
; CHECK-LABEL: _test5:
; CHECK-NOT: subl $4096, %esp
; CHECK: movl $4096, %eax
; CHECK: calll __chkstk
}
define i32 @test6() "stack-probe-size"="8192" {
%buffer = alloca [4096 x i8]
ret i32 0
; CGECK-LABEL: _test6:
; CGECK-NOT: movl $4096, %eax
; CGECK: subl $4096, %esp
; CGECK-NOT: calll __chkstk
}