summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/WinEHPrepare.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [WinEH] Avoid holding references to BlockColor (DenseMap) entries while ↵Andrew Kaylor2016-12-141-1/+5
| | | | | | | | inserting new elements Differential Revision: https://reviews.llvm.org/D27693 llvm-svn: 289694
* Fix comment typos. NFC.Simon Pilgrim2016-11-201-2/+2
| | | | | | Identified by Pedro Giffuni in PR27636. llvm-svn: 287490
* Use StringRef in Pass/PassManager APIs (NFC)Mehdi Amini2016-10-011-1/+1
| | | | llvm-svn: 283004
* Revert "Don't invoke getName() from Function::isIntrinsic().", rL276942.Justin Lebar2016-07-281-6/+2
| | | | | | | | | This broke some out-of-tree AMDGPU tests that relied on the old behavior wherein isIntrinsic() would return true for any function that starts with "llvm.". And in general that change will not play nicely with out-of-tree backends. llvm-svn: 277087
* Don't invoke getName() from Function::isIntrinsic().Justin Lebar2016-07-271-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: getName() involves a hashtable lookup, so is expensive given how frequently isIntrinsic() is called. (In particular, many users cast to IntrinsicInstr or one of its subclasses before calling getIntrinsicID().) This has an incidental functional change: Before, isIntrinsic() would return true for any function whose name started with "llvm.", even if it wasn't properly an intrinsic. The new behavior seems more correct to me, because it's strange to say that isIntrinsic() is true, but getIntrinsicId() returns "not an intrinsic". Some callers want the old behavior -- they want to know whether the caller is a recognized intrinsic, or might be one in some other version of LLVM. For them, we added Function::hasLLVMReservedName(), which checks whether the name starts with "llvm.". This change is good for a 1.5% e2e speedup compiling a large Eigen benchmark. Reviewers: bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D22065 llvm-svn: 276942
* revert http://reviews.llvm.org/D21101Etienne Bergeron2016-06-301-39/+0
| | | | llvm-svn: 274251
* [exceptions] Upgrade exception handlers when stack protector is usedEtienne Bergeron2016-06-301-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: MSVC provide exception handlers with enhanced information to deal with security buffer feature (/GS). To be more secure, the security cookies (GS and SEH) are validated when unwinding the stack. The following code: ``` void f() {} void foo() { __try { f(); } __except(1) { f(); } } ``` Reviewers: majnemer, rnk Subscribers: thakis, llvm-commits, chrisha Differential Revision: http://reviews.llvm.org/D21101 llvm-svn: 274239
* Revert "[SimplifyCFG] Stop inserting calls to llvm.trap for UB"David Majnemer2016-06-251-3/+3
| | | | | | This reverts commit r273778, it seems to break UBSan :/ llvm-svn: 273779
* [SimplifyCFG] Stop inserting calls to llvm.trap for UBDavid Majnemer2016-06-251-3/+3
| | | | | | | | | | | | | | | | | SimplifyCFG had logic to insert calls to llvm.trap for two very particular IR patterns: stores and invokes of undef/null. While InstCombine canonicalizes certain undefined behavior IR patterns to stores of undef, phase ordering means that this cannot be relied upon in general. There are much better tools than llvm.trap: UBSan and ASan. N.B. I could be argued into reverting this change if a clear argument as to why it is important that we synthesize llvm.trap for stores, I'd be hard pressed to see why it'd be useful for invokes... llvm-svn: 273778
* IR: RF_IgnoreMissingValues => RF_IgnoreMissingLocals, NFCDuncan P. N. Exon Smith2016-04-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Clarify what this RemapFlag actually means. - Change the flag name to match its intended behaviour. - Clearly document that it's not supposed to affect globals. - Add a host of FIXMEs to indicate how to fix the behaviour to match the intent of the flag. RF_IgnoreMissingLocals should only affect the behaviour of RemapInstruction for function-local operands; namely, for operands of type Argument, Instruction, and BasicBlock. Currently, it is *only* passed into RemapInstruction calls (and the transitive MapValue calls that it makes). When I split Metadata from Value I didn't understand the flag, and I used it in a bunch of places for "global" metadata. This commit doesn't have any functionality change, but prepares to cleanup MapMetadata and MapValue. llvm-svn: 265628
* [WinEH] Don't remove unannotated inline-asm callsDavid Majnemer2016-02-261-2/+3
| | | | | | | | Inline-asm calls aren't annotated with funclet bundle operands because they don't throw and cannot be inlined through. We shouldn't require them to bear an funclet bundle operand. llvm-svn: 261942
* [WinEH] Visit 'unwind to caller' catchswitches nested in catchswitchesDavid Majnemer2016-02-231-4/+8
| | | | | | | We had the right logic for the nested cleanuppad case but omitted it for catchswitches. llvm-svn: 261615
* [WinEH] Prevent EH state numbering from skipping nested cleanup pads that ↵Andrew Kaylor2016-02-121-6/+14
| | | | | | | | never return Differential Revision: http://reviews.llvm.org/D17208 llvm-svn: 260733
* Revert r258580 and r258581.David Majnemer2016-02-011-113/+0
| | | | | | | | | | | | | | | | | | | | | | | | Those commits created an artificial edge from a cleanup to a synthesized catchswitch in order to get the MSVC personality routine to execute cleanups which don't cleanupret and are not wrapped by a catchswitch. This worked well enough but is not a complete solution in situations where there the cleanup infinite loops. However, the real deal breaker behind this approach comes about from a degenerate case where the cleanup is post-dominated by unreachable *and* throws an exception. This ends poorly because the catchswitch will inadvertently catch the exception. Because of this we should go back to our previous behavior of not executing certain cleanups (identical behavior with the Itanium ABI implementation in clang, GCC and ICC). N.B. I think this could be salvaged by making the catchpad rethrow the exception and properly transforming throwing calls in the cleanup into invokes. llvm-svn: 259338
* [WinEH] Don't miscompile cleanups which conditionally unwind to callerDavid Majnemer2016-01-231-1/+2
| | | | | | | | | | | | | | | | A cleanup can have paths which unwind or end up in unreachable. If there is an unreachable path *and* a path which unwinds to caller, we would mistakenly inject an unwind path to a catchswitch on the unreachable path. This results in a verifier assertion firing because the cleanup unwinds to two different places: to the caller and to the catchswitch. This occured because we used getCleanupRetUnwindDest to determine if the cleanuppad had no cleanuprets. This is incorrect, getCleanupRetUnwindDest returns null for cleanuprets which unwind to caller. llvm-svn: 258651
* [WinEH] Let cleanups post-dominated by unreachable get executedDavid Majnemer2016-01-221-0/+112
| | | | | | | | | | | | | | | | | | | | | | | | | Cleanups in C++ are a little weird. They are only guaranteed to be reliably executed if, and only if, there is a viable catch handler which can handle the exception. This means that reachability of a cleanup is lexically determined by it being nested with a try-block which unwinds to a catch. It is *cannot* be reasoned about by examining the control flow edges leaving a cleanup. Usually this is not a problem. It becomes a problem when there are *no* edges out of a cleanup because we believed that code post-dominated by the cleanup is dead. In LLVM's case, this code is what informs the personality routine about the presence of a suitable catch handler. However, the lack of edges to that catch handler makes the handler become unreachable which causes us to remove it. By removing the handler, the cleanup becomes unreachable. Instead, inject a catch-all handler with every cleanup that has no unwind edges. This will allow us to properly unwind the stack. This fixes PR25997. llvm-svn: 258580
* [WinEH] Rename CatchReturnInst::getParentPad, NFCJoseph Tremoulet2016-01-151-2/+2
| | | | | | | | | | | | | | | | Summary: Rename to getCatchSwitchParentPad, to make it more clear which ancestor the "parent" in question is. Add a comment pointing out the key feature that the returned pad indicates which funclet contains the successor block. Reviewers: rnk, andrew.w.kaylor, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16222 llvm-svn: 257933
* [WinEH] Update WinEHFuncInfo if StackColoring merges allocasDavid Majnemer2016-01-081-3/+4
| | | | | | | | | | | | | | | 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
* [WinEH] Remove calculateCatchReturnSuccessorColorsDavid Majnemer2016-01-061-18/+0
| | | | | | | | | | | | | | The functionality that calculateCatchReturnSuccessorColors provides was once non-trivial: it was a computation layered on top of funclet coloring. These days, LLVM IR directly encodes what calculateCatchReturnSuccessorColors computed, obsoleting the need for it. No functionality change is intended. llvm-svn: 256965
* [WinEH] Update CoreCLR EH state numberingJoseph Tremoulet2016-01-041-61/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fix the CLR state numbering to generate correct tables, and update the lit test to verify them. The CLR numbering assigns one state number to each catchpad and cleanuppad. It also computes two tree-like relations over states: 1) Each state has a "HandlerParentState", which is the state of the next outer handler enclosing this state's handler (same as nearest ancestor per the ParentPad linkage on EH pads, but skipping over catchswitches). 2) Each state has a "TryParentState", which: a) for a catchpad that's not the last handler on its catchswitch, is the state of the next catchpad on that catchswitch. b) for all other pads, is the state of the pad whose try region is the next outer try region enclosing this state's try region. The "try regions are not present as such in the IR, but will be inferred based on the placement of invokes and pads which reach each other by exceptional exits. Catchswitches do not get their own states, but each gets mapped to the state of its first catchpad. Table generation requires each state's "unwind dest" state to have a lower state number than the given state. Since HandlerParentState can be computed as a function of a pad's ParentPad, and TryParentState can be computed as a function of its unwind dest and the TryParentStates of its children, the CLR state numbering algorithm first computes HandlerParentState in a top-down pass, then computes TryParentState in a bottom-up pass. Also reword some comments/names in the CLR EH table generation to make the distinction between the different kinds of "parent" clear. Reviewers: rnk, andrew.w.kaylor, majnemer Subscribers: AndyAyers, llvm-commits Differential Revision: http://reviews.llvm.org/D15325 llvm-svn: 256760
* WinEHPrepare.cpp: Suppress a warning for -Asserts. [-Wunused-variable]NAKAMURA Takumi2016-01-031-4/+2
| | | | llvm-svn: 256694
* [WinEH] Update catchrets with cloned successorsJoseph Tremoulet2016-01-021-4/+38
| | | | | | | | | | | | | | | | | | | | Summary: Add a pass to update catchrets when their successors get cloned; the existing pass doesn't catch these because it walks the funclet whose blocks are being cloned but the catchret is in a child funclet. Also update the test for removing incoming PHI values; when the predecessor is a catchret, the relevant color is the catchret's parentPad, not its block's color. Reviewers: andrew.w.kaylor, rnk, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15840 llvm-svn: 256689
* [WinEH] Add additional verificationDavid Majnemer2016-01-021-4/+7
| | | | | | | | Recolor the IR to make sure our computed colors are not hiding any bugs. Also, verifyFunction if we are running some post-preparation operations; some of these operations can hide latent bugs. llvm-svn: 256687
* [ptr-traits] Sink a constructor definition to the .cpp file and addChandler Carruth2015-12-291-0/+4
| | | | | | | | | | | | missing includes so that the pointee types for DenseMap pointer keys and such are complete prior to us querying the pointer traits for them. This is part of a series of patches to allow LLVM to check for complete pointee types when computing its pointer traits. This is absolutely necessary to get correct (or reproducible) results for things like how many low bits are guaranteed to be zero. llvm-svn: 256550
* [WinEH] Don't visit the same catchswitch twiceDavid Majnemer2015-12-231-7/+15
| | | | | | | | | | | | | We visited the same catchswitch twice because it was both the child of another funclet and the predecessor of a cleanuppad. Instead, change the numbering algorithm to only recurse if the unwind destination of the inner funclet agrees with the unwind destination of the catchswitch. This fixes PR25926. llvm-svn: 256317
* [WinEH] Use operand bundles to describe call sitesDavid Majnemer2015-12-151-18/+50
| | | | | | | | | | | | | | | | | SimplifyCFG allows tail merging with code which terminates in unreachable which, in turn, makes it possible for an invoke to end up in a funclet which it was not originally part of. Using operand bundles on invokes allows us to determine whether or not an invoke was part of a funclet in the source program. Furthermore, it allows us to unambiguously answer questions about the legality of inlining into call sites which the personality may have trouble with. Differential Revision: http://reviews.llvm.org/D15517 llvm-svn: 255674
* [IR] Remove terminatepadDavid Majnemer2015-12-141-42/+0
| | | | | | | | | | | | | It turns out that terminatepad gives little benefit over a cleanuppad which calls the termination function. This is not sufficient to implement fully generic filters but MSVC doesn't support them which makes terminatepad a little over-designed. Depends on D15478. Differential Revision: http://reviews.llvm.org/D15479 llvm-svn: 255522
* [IR] Reformulate LLVM's EH funclet IRDavid Majnemer2015-12-121-1350/+335
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
* Move EH-specific helper functions to a more appropriate placeDavid Majnemer2015-12-021-1/+1
| | | | | | No functionality change is intended. llvm-svn: 254562
* [WinEH] Disable most forms of demotionReid Kleckner2015-11-191-117/+5
| | | | | | | | | | Now that the register allocator knows about the barriers on funclet entry and exit, testing has shown that this is unnecessary. We still demote PHIs on unsplittable blocks due to the differences between the IR CFG and the Machine CFG. llvm-svn: 253619
* [WinEH] Fix problem with removing an element from a SetVector while iterating.Andrew Kaylor2015-11-121-11/+5
| | | | | | Patch provided by Yaron Keren. (Thanks!) llvm-svn: 252913
* [WinEH] Re-committing r252249 (Clone funclets with multiple parents) with ↵Andrew Kaylor2015-11-091-34/+1005
| | | | | | | | additional fixes for determinism problems Differential Revision: http://reviews.llvm.org/D14454 llvm-svn: 252508
* Revert r252249 (and r252255, r252258), "[WinEH] Clone funclets with multiple ↵NAKAMURA Takumi2015-11-061-977/+14
| | | | | | | | parents" It behaved flaky due to iterating pointer key values on std::set and std::map. llvm-svn: 252279
* Fix build warningsAndrew Kaylor2015-11-061-4/+4
| | | | llvm-svn: 252255
* [WinEH] Clone funclets with multiple parentsAndrew Kaylor2015-11-061-14/+977
| | | | | | | | | | Windows EH funclets need to always return to a single parent funclet. However, it is possible for earlier optimizations to combine funclets (probably based on one funclet having an unreachable terminator) in such a way that this condition is violated. These changes add code to the WinEHPrepare pass to detect situations where a funclet has multiple parents and clone such funclets, fixing up the unwind and catch return edges so that each copy of the funclet returns to the correct parent funclet. Differential Revision: http://reviews.llvm.org/D13274?id=39098 llvm-svn: 252249
* [WinEH] Fix CatchRetSuccessorColorMap accountingJoseph Tremoulet2015-10-161-2/+0
| | | | | | | | | | | | | | | | Summary: We now use the block for the catchpad itself, rather than its normal successor, as the funclet entry. Putting the normal successor in the map leads downstream funclet membership computations to erroneous results. Reviewers: majnemer, rnk Subscribers: rnk, llvm-commits Differential Revision: http://reviews.llvm.org/D13798 llvm-svn: 250552
* [WinEH] Remove dead code/includes from WinEHPrepareDavid Majnemer2015-10-161-29/+2
| | | | | | No functionality change is intended. llvm-svn: 250545
* [WinEH] Fix endpad coloring/numberingJoseph Tremoulet2015-10-161-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: When a cleanup's cleanupendpad or cleanupret targets a catchendpad, stop trying to propagate the cleanup's parent's color to the catchendpad, since what's needed is the cleanup's grandparent's color and the catchendpad will get that color from the catchpad linkage already. We already had this exclusion for invokes, but were missing it for cleanupendpad/cleanupret. Also add a missing line that tags cleanupendpads' states in the EHPadStateMap, without with lowering invokes that target cleanupendpads which unwind to other handlers (and so don't have the -1 state) will fail. This fixes the reduced IR repro in PR25163. Reviewers: majnemer, andrew.w.kaylor, rnk Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13797 llvm-svn: 250534
* [WinEH] Remove CatchObjRecoverIdxDavid Majnemer2015-10-121-1/+0
| | | | | | | CatchObjRecoverIdx was used for the old scheme, it is no longer relevant. llvm-svn: 250065
* [WinEH] Remove more dead codeDavid Majnemer2015-10-101-6/+2
| | | | | | wineh-parent is dead, so is ValueOrMBB. llvm-svn: 249920
* [WinEH] Delete the old landingpad implementation of Windows EHReid Kleckner2015-10-091-2447/+16
| | | | | | | | | | | 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
* CodeGen: Remove implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-10-091-36/+42
| | | | | | | Finish removing implicit ilist iterator conversions from LLVMCodeGen. I'm sure there are lots more of these in lib/CodeGen/*/. llvm-svn: 249915
* [WinEH] Fix cleanup state numberingJoseph Tremoulet2015-10-091-4/+20
| | | | | | | | | | | | | | | | | | | Summary: - Recurse from cleanupendpads to their cleanuppads, to make sure the cleanuppad is visited if it has a cleanupendpad but no cleanupret. - Check for and avoid double-processing cleanuppads, to allow for them to have multiple cleanuprets (plus cleanupendpads). - Update Cxx state numbering to visit toplevel cleanupendpads and to recurse from cleanupendpads to their preds, to ensure we number any funclets in inlined cleanups. SEH state numbering already did this. Reviewers: rnk Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13374 llvm-svn: 249792
* [WinEH] Remove unreachable blocks before preparationDavid Majnemer2015-10-071-5/+5
| | | | | | | | | | | | | We remove unreachable blocks because it is pointless to consider them for coloring. However, we still had stale pointers to these blocks in some data structures after we removed them from the function. Instead, remove the unreachable blocks before attempting to do anything with the function. This fixes PR25099. llvm-svn: 249617
* [WinEH] Set NoModuleLevelChanges in clone flagsJoseph Tremoulet2015-10-071-2/+7
| | | | | | | | | | | | | | | | Summary: This is necessary to keep the cloner from making bogus copies of debug metadata attached to the IR it is cloning. Also, avoid running RemapInstruction over all instructions in the common case that no cloning was performed. Reviewers: rnk, andrew.w.kaylor, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13514 llvm-svn: 249591
* [WinEH] Update CoreCLR EH for catchpad MBBsJoseph Tremoulet2015-10-071-2/+2
| | | | | | | | | | | | | | | Summary: Set the pad MBB as a funclet entry for CoreCLR as well as MSVCCXX, and update state numbering to put the catchpad block rather than its normal successor into the unwind map. Reviewers: majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13492 llvm-svn: 249569
* [SEH] Add llvm.eh.exceptioncode intrinsicReid Kleckner2015-10-071-8/+9
| | | | | | This will support the Clang __exception_code intrinsic. llvm-svn: 249492
* [WinEH] Create a separate MBB for funclet prologuesDavid Majnemer2015-10-061-3/+2
| | | | | | | | | | | | | | | | Our current emission strategy is to emit the funclet prologue in the CatchPad's normal destination. This is problematic because intra-funclet control flow to the normal destination is not erroneous and results in us reevaluating the prologue if said control flow is taken. Instead, use the CatchPad's location for the funclet prologue. This correctly models our desire to have unwind edges evaluate the prologue but edges to the normal destination result in typical control flow. Differential Revision: http://reviews.llvm.org/D13424 llvm-svn: 249483
* [WinEH] Implement state numbering for CoreCLRJoseph Tremoulet2015-10-061-0/+85
| | | | | | | | | | | | | | | | Summary: Assign one state number per handler/funclet, tracking parent state, handler type, and catch type token. State numbers are arranged such that ancestors have lower state numbers than their descendants. Reviewers: majnemer, andrew.w.kaylor, rnk Subscribers: pgavlin, AndyAyers, llvm-commits Differential Revision: http://reviews.llvm.org/D13450 llvm-svn: 249457
* [WinEH] Recognize CoreCLR personality functionJoseph Tremoulet2015-10-061-2/+2
| | | | | | | | | | | | | | | Summary: - Add CoreCLR to if/else ladders and switches as appropriate. - Rename isMSVCEHPersonality to isFuncletEHPersonality to better reflect what it captures. Reviewers: majnemer, andrew.w.kaylor, rnk Subscribers: pgavlin, AndyAyers, llvm-commits Differential Revision: http://reviews.llvm.org/D13449 llvm-svn: 249455
OpenPOWER on IntegriCloud