summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/WinEH/cppeh-similar-catch-blocks.ll
Commit message (Collapse)AuthorAgeFilesLines
* [WinEH] Delete the old landingpad implementation of Windows EHReid Kleckner2015-10-091-394/+0
| | | | | | | | | | | The new implementation works at least as well as the old implementation did. Also delete the associated preparation tests. They don't exercise interesting corner cases of the new implementation. All the codegen tests of the EH tables have already been ported. llvm-svn: 249918
* Rename llvm.frameescape and llvm.framerecover to localescape and localrecoverReid Kleckner2015-07-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Initially, these intrinsics seemed like part of a family of "frame" related intrinsics, but now I think that's more confusing than helpful. Initially, the LangRef specified that this would create a new kind of allocation that would be allocated at a fixed offset from the frame pointer (EBP/RBP). We ended up dropping that design, and leaving the stack frame layout alone. These intrinsics are really about sharing local stack allocations, not frame pointers. I intend to go further and add an `llvm.localaddress()` intrinsic that returns whatever register (EBP, ESI, ESP, RBX) is being used to address locals, which should not be confused with the frame pointer. Naming suggestions at this point are welcome, I'm happy to re-run sed. Reviewers: majnemer, nicholas Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11011 llvm-svn: 241633
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-171-12/+12
| | | | | | | | | | | | | | | | | | | 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
* [WinEH] C++ EH state numbering fixesAndrew Kaylor2015-05-201-1/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D9787 llvm-svn: 237854
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-04-241-7/+7
| | | | | | | | | | the invoke instruction Same as r235145 for the call instruction - the justification, tradeoffs, etc are all the same. The conversion script worked the same without any false negatives (after replacing 'call' with 'invoke'). llvm-svn: 235755
* [WinEH] Fixes for a few cppeh failures.Andrew Kaylor2015-04-171-0/+394
Differential Review: http://reviews.llvm.org/D9065 llvm-svn: 235239
OpenPOWER on IntegriCloud