llvm-project/llvm/test/Transforms/Inline/2003-09-22-PHINodesInExcept...

; RUN: opt < %s -inline -disable-output

define i32 @main() personality i32 (...)* @__gxx_personality_v0 {
entry:
        invoke void @__main( )
                        to label %Call2Invoke unwind label %LongJmpBlkPre

Call2Invoke:            ; preds = %entry
        br label %exit

LongJmpBlkPre:          ; preds = %Call2Invoke, %entry
        %i.3 = phi i32 [ 0, %entry ]
        %exn = landingpad {i8*, i32}
                 cleanup
        br label %exit

exit:
        ret i32 0
}

define void @__main() {
        call void @__llvm_getGlobalCtors( )
        call void @__llvm_getGlobalDtors( )
        ret void
}

declare i32 @__gxx_personality_v0(...)

declare void @__llvm_getGlobalCtors()

declare void @__llvm_getGlobalDtors()
Change tests from "opt %s" to "opt < %s" so that opt doesn't see the input filename so that opt doesn't print the input filename in the output so that grep lines in the tests don't unintentionally match strings in the input filename. llvm-svn: 81537 2009-09-12 02:01:28 +08:00			`; RUN: opt < %s -inline -disable-output`
new testcase which crashes the inliner, thanks Bugpoint! llvm-svn: 8663 2003-09-23 05:58:46 +08:00
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 i32 @main() personality i32 (...)* @__gxx_personality_v0 {`
new testcase which crashes the inliner, thanks Bugpoint! llvm-svn: 8663 2003-09-23 05:58:46 +08:00			`entry:`
Remove llvm-upgrade and update test cases. llvm-svn: 47793 2008-03-01 17:15:35 +08:00			`invoke void @__main( )`
			`to label %Call2Invoke unwind label %LongJmpBlkPre`
new testcase which crashes the inliner, thanks Bugpoint! llvm-svn: 8663 2003-09-23 05:58:46 +08:00
Remove llvm-upgrade and update test cases. llvm-svn: 47793 2008-03-01 17:15:35 +08:00			`Call2Invoke: ; preds = %entry`
Update to new EH scheme. llvm-svn: 138928 2011-09-01 09:08:21 +08:00			`br label %exit`
new testcase which crashes the inliner, thanks Bugpoint! llvm-svn: 8663 2003-09-23 05:58:46 +08:00
Remove llvm-upgrade and update test cases. llvm-svn: 47793 2008-03-01 17:15:35 +08:00			`LongJmpBlkPre: ; preds = %Call2Invoke, %entry`
Verifier: Call verifyModule() from llc and opt Change `llc` and `opt` to run `verifyModule()`. This ensures that we check the full module before `FunctionPass::doInitialization()` ever gets called (I was getting crashes in `DwarfDebug` instead of verifier failures when testing a WIP patch that checks operands of compile units). In `opt`, also move up debug-info-stripping so that it still runs before verification. There was a fair bit of broken code that was sitting in tree. Interestingly, some were cases of a `select` that referred to itself in `-instcombine` tests (apparently an intermediate result). I split them off to `*-noverify.ll` tests with RUN lines like this: opt < %s -S -disable-verify -instcombine \| opt -S \| FileCheck %s This avoids verifying the input file (so we can get the broken code into `-instcombine), but still verifies the output with a second call to `opt` (to verify that `-instcombine` will clean it up like it should). llvm-svn: 233432 2015-03-28 06:04:28 +08:00			`%i.3 = phi i32 [ 0, %entry ]`
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			`%exn = landingpad {i8*, i32}`
Update to new EH scheme. llvm-svn: 138928 2011-09-01 09:08:21 +08:00			`cleanup`
			`br label %exit`

			`exit:`
Remove llvm-upgrade and update test cases. llvm-svn: 47793 2008-03-01 17:15:35 +08:00			`ret i32 0`
new testcase which crashes the inliner, thanks Bugpoint! llvm-svn: 8663 2003-09-23 05:58:46 +08:00			`}`

Remove llvm-upgrade and update test cases. llvm-svn: 47793 2008-03-01 17:15:35 +08:00			`define void @__main() {`
			`call void @__llvm_getGlobalCtors( )`
			`call void @__llvm_getGlobalDtors( )`
			`ret void`
new testcase which crashes the inliner, thanks Bugpoint! llvm-svn: 8663 2003-09-23 05:58:46 +08:00			`}`

Update to new EH scheme. llvm-svn: 138928 2011-09-01 09:08:21 +08:00			`declare i32 @__gxx_personality_v0(...)`

Remove llvm-upgrade and update test cases. llvm-svn: 47793 2008-03-01 17:15:35 +08:00			`declare void @__llvm_getGlobalCtors()`

			`declare void @__llvm_getGlobalDtors()`
new testcase which crashes the inliner, thanks Bugpoint! llvm-svn: 8663 2003-09-23 05:58:46 +08:00