summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/Inline/inline_invoke.ll
Commit message (Collapse)AuthorAgeFilesLines
* [PM] Move the collection of call sites to a more appropriate placeChandler Carruth2016-12-271-0/+1
| | | | | | | | | | | | | | | | | | | | | inside of `InlineFunction`. Prior to this, call instructions are specifically being rewritten and replaced within the inlined region, invalidating some of the call sites. Several of these regions are using the same technique to walk the inlined region so this seems clearly safe up to this point. I've also added a short circuit to the scan for call sites based on what other code is doing. With this, the most common crash I've found in the new inliner code is fixed. I've turned it on for another test case that covers this scenario. I'll make my way through most of the other inliner test cases just to get some easy coverage next. llvm-svn: 290562
* Sort the enums in Attributes.h in case insensitive alphabetical order.Akira Hatanaka2015-11-111-1/+1
| | | | | | | | | Sort the enums in preparation for moving the attributes to a table-gen file. rdar://problem/19836465 llvm-svn: 252692
* Emit argmemonly attribute for intrinsics.Igor Laevsky2015-08-131-1/+2
| | | | | | Differential Revision: http://reviews.llvm.org/D11352 llvm-svn: 244920
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-171-23/+23
| | | | | | | | | | | | | | | | | | | 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
* Fix inlining to not produce duplicate landingpad clausesMark Seaborn2013-12-081-5/+0
| | | | | | | | | | | | | | | | | | | | | | | Before this change, inlining one "invoke" into an outer "invoke" call site can lead to the outer landingpad's catch/filter clauses being copied multiple times into the resulting landingpad. This happens: * when the inlined function contains multiple "resume" instructions, because forwardResume() copies the clauses but is called multiple times; * when the inlined function contains a "resume" and a "call", because HandleCallsInBlockInlinedThroughInvoke() copies the clauses but is redundant with forwardResume(). Fix this by deduplicating the code. This problem doesn't lead to any incorrect execution; it's only untidy. This change will make fixing PR17872 a little easier. llvm-svn: 196710
* Update test. There may be multiple catches, but those will be cleaned up.Bill Wendling2013-03-221-0/+5
| | | | llvm-svn: 177758
* Use references to attribute groups on the call/invoke instructions.Bill Wendling2013-02-221-1/+6
| | | | | | | Listing all of the attributes for the callee of a call/invoke instruction is way too much and makes the IR unreadable. Use references to attributes instead. llvm-svn: 175877
* Update to new EH scheme.Bill Wendling2011-09-021-95/+34
| | | | llvm-svn: 138989
* Auto upgrade the old EH scheme to use the new one. This is on a trial basis. IfBill Wendling2011-08-271-34/+101
| | | | | | things to disasterously over night, this can be reverted. llvm-svn: 138702
* SplitCriticalEdge can sometimes split the edge from an invoke to a landingJohn McCall2011-06-091-1/+92
| | | | | | | | | | | | pad, separating the exception and selector calls from the new lpad. Teaching it not to do that, or to properly adjust the CFG afterwards, is out of scope because it would require the other edges to the landing pad to be split as well (effectively). Instead, just recover from the most likely cases during inlining. The best long-term solution is to change the exception representation and commit to either requiring or not requiring the more complex edge-splitting logic; this is just a shorter-term hack. llvm-svn: 132799
* First, do no harm -- even if we can't find a selector for an enclosingJohn McCall2011-06-011-2/+29
| | | | | | | landing pad, forward llvm.eh.resume calls to it instead of turning them invalidly into invokes. llvm-svn: 132382
* Add the test case for phis in the outer landing pad during the inliner'sJohn McCall2011-05-301-1/+111
| | | | | | forwarding of eh.resume that I promised yesterday. llvm-svn: 132307
* Implement and document the llvm.eh.resume intrinsic, which isJohn McCall2011-05-281-13/+18
| | | | | | | | | | | | | | | | | transformed by the inliner into a branch to the enclosing landing pad (when inlined through an invoke). If not so optimized, it is lowered DWARF EH preparation into a call to _Unwind_Resume (or _Unwind_SjLj_Resume as appropriate). Its chief advantage is that it takes both the exception value and the selector value as arguments, meaning that there is zero effort in recovering these; however, the frontend is required to pass these down, which is not actually particularly difficult. Also document the behavior of landing pads a bit better, and make it clearer that it's okay that personality functions don't always land at landing pads. This is just a fact of life. Don't write optimizations that rely on pushing things over an unwind edge. llvm-svn: 132253
* Fix the inliner to maintain the current de facto invoke semantics:John McCall2011-05-271-0/+103
- the selector for the landing pad must provide all available information about the handlers, filters, and cleanups within that landing pad - calls to _Unwind_Resume must be converted to branches to the enclosing lpad so as to avoid re-entering the unwinder when the lpad claimed it was going to handle the exception in some way This is quite specific to libUnwind-based unwinding. In an effort to not interfere too badly with other unwinders, and with existing hacks in frontends, this only triggers on _Unwind_Resume (not _Unwind_Resume_or_Rethrow) and does nothing with selectors if it cannot find a selector call for either lpad. llvm-svn: 132200
OpenPOWER on IntegriCloud