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/catchpad-lifetime.ll

92 lines
2.7 KiB
LLVM
Raw Normal View History

[WinEH] Update WinEHFuncInfo if StackColoring merges allocas Windows EH keeping track of which frame index corresponds to a catchpad in order to inform the runtime where the catch parameter should be initialized. LLVM's optimizations are able to prove that the memory used by the catch parameter can be reused with another memory optimization, changing it's frame index. We need to keep WinEHFuncInfo up to date with respect to this or we will miscompile/assert. This fixes PR26069. llvm-svn: 257158
2016-01-08 16:03:55 +08:00
; RUN: llc < %s | FileCheck %s
target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
target triple = "x86_64-pc-windows-msvc"
declare void @throw()
declare i32 @__CxxFrameHandler3(...)
define void @test1() personality i32 (...)* @__CxxFrameHandler3 {
entry:
%alloca2 = alloca i8*, align 4
%alloca1 = alloca i8*, align 4
store volatile i8* null, i8** %alloca1
invoke void @throw()
to label %unreachable unwind label %catch.dispatch
; CHECK-LABEL: test1:
[X86] Don't give catch objects a displacement of zero Catch objects with a displacement of zero do not initialize a catch object. The displacement is relative to %rsp at the end of the function's prologue for x86_64 targets. If we place an object at the top-of-stack, we will end up wit a displacement of zero resulting in our catch object remaining uninitialized. Address this by creating our catch objects as fixed objects. We will ensure that the UnwindHelp object is created after the catch objects so that no catch object will have a displacement of zero. Differential Revision: http://reviews.llvm.org/D17823 llvm-svn: 262546
2016-03-03 08:01:25 +08:00
; CHECK: movq $0, -8(%rbp)
[WinEH] Update WinEHFuncInfo if StackColoring merges allocas Windows EH keeping track of which frame index corresponds to a catchpad in order to inform the runtime where the catch parameter should be initialized. LLVM's optimizations are able to prove that the memory used by the catch parameter can be reused with another memory optimization, changing it's frame index. We need to keep WinEHFuncInfo up to date with respect to this or we will miscompile/assert. This fixes PR26069. llvm-svn: 257158
2016-01-08 16:03:55 +08:00
; CHECK: callq throw
catch.dispatch: ; preds = %entry
%cs = catchswitch within none [label %catch.pad] unwind to caller
catch.pad: ; preds = %catch.dispatch
%cp = catchpad within %cs [i8* null, i32 0, i8** %alloca1]
store volatile i8* null, i8** %alloca1
%bc1 = bitcast i8** %alloca1 to i8*
Add address space mangling to lifetime intrinsics In preparation for allowing allocas to have non-0 addrspace. llvm-svn: 299876
2017-04-11 04:18:21 +08:00
call void @llvm.lifetime.end.p0i8(i64 4, i8* nonnull %bc1)
[WinEH] Update WinEHFuncInfo if StackColoring merges allocas Windows EH keeping track of which frame index corresponds to a catchpad in order to inform the runtime where the catch parameter should be initialized. LLVM's optimizations are able to prove that the memory used by the catch parameter can be reused with another memory optimization, changing it's frame index. We need to keep WinEHFuncInfo up to date with respect to this or we will miscompile/assert. This fixes PR26069. llvm-svn: 257158
2016-01-08 16:03:55 +08:00
%bc2 = bitcast i8** %alloca2 to i8*
Add address space mangling to lifetime intrinsics In preparation for allowing allocas to have non-0 addrspace. llvm-svn: 299876
2017-04-11 04:18:21 +08:00
call void @llvm.lifetime.start.p0i8(i64 4, i8* %bc2)
[WinEH] Update WinEHFuncInfo if StackColoring merges allocas Windows EH keeping track of which frame index corresponds to a catchpad in order to inform the runtime where the catch parameter should be initialized. LLVM's optimizations are able to prove that the memory used by the catch parameter can be reused with another memory optimization, changing it's frame index. We need to keep WinEHFuncInfo up to date with respect to this or we will miscompile/assert. This fixes PR26069. llvm-svn: 257158
2016-01-08 16:03:55 +08:00
store volatile i8* null, i8** %alloca1
unreachable
; CHECK-LABEL: "?catch$2@?0?test1@4HA"
[X86] Don't give catch objects a displacement of zero Catch objects with a displacement of zero do not initialize a catch object. The displacement is relative to %rsp at the end of the function's prologue for x86_64 targets. If we place an object at the top-of-stack, we will end up wit a displacement of zero resulting in our catch object remaining uninitialized. Address this by creating our catch objects as fixed objects. We will ensure that the UnwindHelp object is created after the catch objects so that no catch object will have a displacement of zero. Differential Revision: http://reviews.llvm.org/D17823 llvm-svn: 262546
2016-03-03 08:01:25 +08:00
; CHECK: movq $0, -8(%rbp)
; CHECK: movq $0, -8(%rbp)
[WinEH] Update WinEHFuncInfo if StackColoring merges allocas Windows EH keeping track of which frame index corresponds to a catchpad in order to inform the runtime where the catch parameter should be initialized. LLVM's optimizations are able to prove that the memory used by the catch parameter can be reused with another memory optimization, changing it's frame index. We need to keep WinEHFuncInfo up to date with respect to this or we will miscompile/assert. This fixes PR26069. llvm-svn: 257158
2016-01-08 16:03:55 +08:00
; CHECK: ud2
unreachable: ; preds = %entry
unreachable
}
; CHECK-LABEL: $cppxdata$test1:
[X86] Don't give catch objects a displacement of zero Catch objects with a displacement of zero do not initialize a catch object. The displacement is relative to %rsp at the end of the function's prologue for x86_64 targets. If we place an object at the top-of-stack, we will end up wit a displacement of zero resulting in our catch object remaining uninitialized. Address this by creating our catch objects as fixed objects. We will ensure that the UnwindHelp object is created after the catch objects so that no catch object will have a displacement of zero. Differential Revision: http://reviews.llvm.org/D17823 llvm-svn: 262546
2016-03-03 08:01:25 +08:00
; CHECK: .long 56 # CatchObjOffset
[WinEH] Update WinEHFuncInfo if StackColoring merges allocas Windows EH keeping track of which frame index corresponds to a catchpad in order to inform the runtime where the catch parameter should be initialized. LLVM's optimizations are able to prove that the memory used by the catch parameter can be reused with another memory optimization, changing it's frame index. We need to keep WinEHFuncInfo up to date with respect to this or we will miscompile/assert. This fixes PR26069. llvm-svn: 257158
2016-01-08 16:03:55 +08:00
[WinEH] CatchHandler which don't have catch objects in StackColoring StackColoring rewrites the frame indicies of operations involving allocas if it can find that the life time of two objects do not overlap. MSVC EH needs to be kept aware of this if happens in the event that a catch object has moved around. However, we represent the non-existance of a catch object with a sentinel frame index (INT_MAX). This sentinel also happens to be the EmptyKey of the SlotRemap DenseMap. Testing for whether or not we need to translate the frame index fails in this case because we call the count method on the DenseMap with the EmptyKey, leading to assertions. Instead, check if it is our sentinel value before trying to look into the DenseMap. This fixes PR26073. llvm-svn: 257182
2016-01-09 01:24:47 +08:00
define void @test2() personality i32 (...)* @__CxxFrameHandler3 {
entry:
%alloca2 = alloca i8*, align 4
%alloca1 = alloca i8*, align 4
store volatile i8* null, i8** %alloca1
invoke void @throw()
to label %unreachable unwind label %catch.dispatch
; CHECK-LABEL: test2:
; CHECK: movq $0, -16(%rbp)
; CHECK: callq throw
catch.dispatch: ; preds = %entry
%cs = catchswitch within none [label %catch.pad] unwind to caller
catch.pad: ; preds = %catch.dispatch
%cp = catchpad within %cs [i8* null, i32 0, i8** null]
store volatile i8* null, i8** %alloca1
%bc1 = bitcast i8** %alloca1 to i8*
Add address space mangling to lifetime intrinsics In preparation for allowing allocas to have non-0 addrspace. llvm-svn: 299876
2017-04-11 04:18:21 +08:00
call void @llvm.lifetime.end.p0i8(i64 4, i8* nonnull %bc1)
[WinEH] CatchHandler which don't have catch objects in StackColoring StackColoring rewrites the frame indicies of operations involving allocas if it can find that the life time of two objects do not overlap. MSVC EH needs to be kept aware of this if happens in the event that a catch object has moved around. However, we represent the non-existance of a catch object with a sentinel frame index (INT_MAX). This sentinel also happens to be the EmptyKey of the SlotRemap DenseMap. Testing for whether or not we need to translate the frame index fails in this case because we call the count method on the DenseMap with the EmptyKey, leading to assertions. Instead, check if it is our sentinel value before trying to look into the DenseMap. This fixes PR26073. llvm-svn: 257182
2016-01-09 01:24:47 +08:00
%bc2 = bitcast i8** %alloca2 to i8*
Add address space mangling to lifetime intrinsics In preparation for allowing allocas to have non-0 addrspace. llvm-svn: 299876
2017-04-11 04:18:21 +08:00
call void @llvm.lifetime.start.p0i8(i64 4, i8* %bc2)
[WinEH] CatchHandler which don't have catch objects in StackColoring StackColoring rewrites the frame indicies of operations involving allocas if it can find that the life time of two objects do not overlap. MSVC EH needs to be kept aware of this if happens in the event that a catch object has moved around. However, we represent the non-existance of a catch object with a sentinel frame index (INT_MAX). This sentinel also happens to be the EmptyKey of the SlotRemap DenseMap. Testing for whether or not we need to translate the frame index fails in this case because we call the count method on the DenseMap with the EmptyKey, leading to assertions. Instead, check if it is our sentinel value before trying to look into the DenseMap. This fixes PR26073. llvm-svn: 257182
2016-01-09 01:24:47 +08:00
store volatile i8* null, i8** %alloca1
unreachable
; CHECK-LABEL: "?catch$2@?0?test2@4HA"
; CHECK: movq $0, -16(%rbp)
; CHECK: movq $0, -16(%rbp)
; CHECK: ud2
unreachable: ; preds = %entry
unreachable
}
; CHECK-LABEL: $cppxdata$test2:
; CHECK: .long 0 # CatchObjOffset
[WinEH] Update WinEHFuncInfo if StackColoring merges allocas Windows EH keeping track of which frame index corresponds to a catchpad in order to inform the runtime where the catch parameter should be initialized. LLVM's optimizations are able to prove that the memory used by the catch parameter can be reused with another memory optimization, changing it's frame index. We need to keep WinEHFuncInfo up to date with respect to this or we will miscompile/assert. This fixes PR26069. llvm-svn: 257158
2016-01-08 16:03:55 +08:00
; Function Attrs: argmemonly nounwind
Add address space mangling to lifetime intrinsics In preparation for allowing allocas to have non-0 addrspace. llvm-svn: 299876
2017-04-11 04:18:21 +08:00
declare void @llvm.lifetime.start.p0i8(i64, i8* nocapture) #0
[WinEH] Update WinEHFuncInfo if StackColoring merges allocas Windows EH keeping track of which frame index corresponds to a catchpad in order to inform the runtime where the catch parameter should be initialized. LLVM's optimizations are able to prove that the memory used by the catch parameter can be reused with another memory optimization, changing it's frame index. We need to keep WinEHFuncInfo up to date with respect to this or we will miscompile/assert. This fixes PR26069. llvm-svn: 257158
2016-01-08 16:03:55 +08:00
; Function Attrs: argmemonly nounwind
Add address space mangling to lifetime intrinsics In preparation for allowing allocas to have non-0 addrspace. llvm-svn: 299876
2017-04-11 04:18:21 +08:00
declare void @llvm.lifetime.end.p0i8(i64, i8* nocapture) #0
[WinEH] Update WinEHFuncInfo if StackColoring merges allocas Windows EH keeping track of which frame index corresponds to a catchpad in order to inform the runtime where the catch parameter should be initialized. LLVM's optimizations are able to prove that the memory used by the catch parameter can be reused with another memory optimization, changing it's frame index. We need to keep WinEHFuncInfo up to date with respect to this or we will miscompile/assert. This fixes PR26069. llvm-svn: 257158
2016-01-08 16:03:55 +08:00
attributes #0 = { argmemonly nounwind }