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/ehabi-handlerdata.ll

60 lines
1.6 KiB
LLVM
Raw Normal View History

More test case for r208715. The commit r208166 will cause some regression on ARM EHABI. This fix has been committed in r208715, and an assertion failure test case has been committed in r208770. This commit further extends the unittest so that the actual value in the handlerdata will be checked. llvm-svn: 208790
2014-05-15 00:37:32 +08:00
; ARM EHABI test for the handlerdata.
; This test case checks whether the handlerdata for exception
; handling is generated properly.
;
; (1) The handlerdata must not be empty.
; (2) LPStartEncoding == DW_EH_PE_omit
; (3) TTypeEncoding == DW_EH_PE_absptr
; (4) CallSiteEncoding == DW_EH_PE_udata4
; RUN: llc -mtriple arm-unknown-linux-gnueabi -filetype=asm -o - %s \
; RUN: | FileCheck %s
; RUN: llc -mtriple arm-unknown-linux-gnueabi -filetype=asm -o - %s \
; RUN: -relocation-model=pic \
; RUN: | FileCheck %s
declare void @throw_exception()
declare i32 @__gxx_personality_v0(...)
declare i8* @__cxa_begin_catch(i8*)
declare void @__cxa_end_catch()
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
define void @test1() personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) {
More test case for r208715. The commit r208166 will cause some regression on ARM EHABI. This fix has been committed in r208715, and an assertion failure test case has been committed in r208770. This commit further extends the unittest so that the actual value in the handlerdata will be checked. llvm-svn: 208790
2014-05-15 00:37:32 +08:00
entry:
invoke void @throw_exception() to label %try.cont unwind label %lpad
lpad:
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
%0 = landingpad { i8*, i32 }
More test case for r208715. The commit r208166 will cause some regression on ARM EHABI. This fix has been committed in r208715, and an assertion failure test case has been committed in r208770. This commit further extends the unittest so that the actual value in the handlerdata will be checked. llvm-svn: 208790
2014-05-15 00:37:32 +08:00
catch i8* null
%1 = extractvalue { i8*, i32 } %0, 0
%2 = tail call i8* @__cxa_begin_catch(i8* %1)
tail call void @__cxa_end_catch()
br label %try.cont
try.cont:
ret void
}
; CHECK: .globl test1
[MC] Use .p2align instead of .align For historic reasons, the behavior of .align differs between targets. Fortunately, there are alternatives, .p2align and .balign, which make the interpretation of the parameter explicit, and which behave consistently across targets. This patch teaches MC to use .p2align instead of .align, so that people reading code for multiple architectures don't have to remember which way each platform does its .align directive. Differential Revision: http://reviews.llvm.org/D16549 llvm-svn: 258750
2016-01-26 08:03:25 +08:00
; CHECK: .p2align 2
More test case for r208715. The commit r208166 will cause some regression on ARM EHABI. This fix has been committed in r208715, and an assertion failure test case has been committed in r208770. This commit further extends the unittest so that the actual value in the handlerdata will be checked. llvm-svn: 208790
2014-05-15 00:37:32 +08:00
; CHECK: .type test1,%function
; CHECK-LABEL: test1:
; CHECK: .fnstart
; CHECK: .personality __gxx_personality_v0
; CHECK: .handlerdata
[MC] Use .p2align instead of .align For historic reasons, the behavior of .align differs between targets. Fortunately, there are alternatives, .p2align and .balign, which make the interpretation of the parameter explicit, and which behave consistently across targets. This patch teaches MC to use .p2align instead of .align, so that people reading code for multiple architectures don't have to remember which way each platform does its .align directive. Differential Revision: http://reviews.llvm.org/D16549 llvm-svn: 258750
2016-01-26 08:03:25 +08:00
; CHECK: .p2align 2
More test case for r208715. The commit r208166 will cause some regression on ARM EHABI. This fix has been committed in r208715, and an assertion failure test case has been committed in r208770. This commit further extends the unittest so that the actual value in the handlerdata will be checked. llvm-svn: 208790
2014-05-15 00:37:32 +08:00
; CHECK-LABEL: GCC_except_table0:
; CHECK-LABEL: .Lexception0:
; CHECK: .byte 255 @ @LPStart Encoding = omit
; CHECK: .byte 0 @ @TType Encoding = absptr
; CHECK: .asciz
; CHECK: .byte 3 @ Call site Encoding = udata4
; CHECK: .long
; CHECK: .long
; CHECK: .long
; CHECK: .fnend