summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/WinEHPrepare.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [opaque pointer types] Pass value type to LoadInst creation.James Y Knight2019-02-011-3/+6
| | | | | | | | | This cleans up all LoadInst creation in LLVM to explicitly pass the value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57172 llvm-svn: 352911
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [TI removal] Make variables declared as `TerminatorInst` and initializedChandler Carruth2018-10-151-2/+2
| | | | | | | | | | | | | by `getTerminator()` calls instead be declared as `Instruction`. This is the biggest remaining chunk of the usage of `getTerminator()` that insists on the narrow type and so is an easy batch of updates. Several files saw more extensive updates where this would cascade to requiring API updates within the file to use `Instruction` instead of `TerminatorInst`. All of these were trivial in nature (pervasively using `Instruction` instead just worked). llvm-svn: 344502
* [IR] Replace `isa<TerminatorInst>` with `isTerminator()`.Chandler Carruth2018-08-261-3/+2
| | | | | | | | | | | | This is a bit awkward in a handful of places where we didn't even have an instruction and now we have to see if we can build one. But on the whole, this seems like a win and at worst a reasonable cost for removing `TerminatorInst`. All of this is part of the removal of `TerminatorInst` from the `Instruction` type hierarchy. llvm-svn: 340701
* Remove trailing spaceFangrui Song2018-07-301-1/+1
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
* Move Analysis/Utils/Local.h back to TransformsDavid Blaikie2018-06-041-1/+1
| | | | | | | | | | Review feedback from r328165. Split out just the one function from the file that's used by Analysis. (As chandlerc pointed out, the original change only moved the header and not the implementation anyway - which was fine for the one function that was used (since it's a template/inlined in the header) but not in general) llvm-svn: 333954
* [WebAssembly] Add Wasm exception handling prepare passHeejin Ahn2018-05-311-5/+19
| | | | | | | | | | | | | | | | Summary: This adds a pass that transforms a program to be prepared for Wasm exception handling. This is using Windows EH instructions and based on the previous Wasm EH proposal. (https://github.com/WebAssembly/exception-handling/blob/master/proposals/Exceptions.md) Reviewers: dschuff, majnemer Subscribers: jfb, mgorny, sbc100, jgravelle-google, JDevlieghere, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D43746 llvm-svn: 333696
* [WebAssembly] Add Wasm personality and isScopedEHPersonality()Heejin Ahn2018-05-171-3/+3
| | | | | | | | | | | | | | | | | | | | | Summary: - Add wasm personality function - Re-categorize the existing `isFuncletEHPersonality()` function into two different functions: `isFuncletEHPersonality()` and `isScopedEHPersonality(). This becomes necessary as wasm EH uses scoped EH instructions (catchswitch, catchpad/ret, and cleanuppad/ret) but not outlined funclets. - Changed some callsites of `isFuncletEHPersonality()` to `isScopedEHPersonality()` if they are related to scoped EH IR-level stuff. Reviewers: majnemer, dschuff, rnk Subscribers: jfb, sbc100, jgravelle-google, eraman, JDevlieghere, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D45559 llvm-svn: 332667
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-15/+16
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* Fix a couple of layering violations in TransformsDavid Blaikie2018-03-211-1/+1
| | | | | | | | | | | | | Remove #include of Transforms/Scalar.h from Transform/Utils to fix layering. Transforms depends on Transforms/Utils, not the other way around. So remove the header and the "createStripGCRelocatesPass" function declaration (& definition) that is unused and motivated this dependency. Move Transforms/Utils/Local.h into Analysis because it's used by Analysis/MemoryBuiltins.cpp. llvm-svn: 328165
* Use phi ranges to simplify code. No functionality change intended.Benjamin Kramer2017-12-301-18/+8
| | | | llvm-svn: 321585
* Guard print() functions only used by dump() functions.Florian Hahn2017-07-311-0/+2
| | | | | | | | | | | | | | | | | | | Summary: Since r293359, most dump() function are only defined when `!defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)` holds. print() functions only used by dump() functions are now unused in release builds, generating lots of warnings. This patch only defines some print() functions if they are used. Reviewers: MatzeB Reviewed By: MatzeB Subscribers: arsenm, mzolotukhin, nhaehnle, llvm-commits Differential Revision: https://reviews.llvm.org/D35949 llvm-svn: 309553
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* CodeGen: Rename DEBUG_TYPE to match passnamesMatthias Braun2017-05-251-1/+1
| | | | | | | | Rename the DEBUG_TYPE to match the names of corresponding passes where it makes sense. Also establish the pattern of simply referencing DEBUG_TYPE instead of repeating the passname where possible. llvm-svn: 303921
* [LegacyPassManager] Remove TargetMachine constructorsFrancis Visoiu Mistrih2017-05-181-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This provides a new way to access the TargetMachine through TargetPassConfig, as a dependency. The patterns replaced here are: * Passes handling a null TargetMachine call `getAnalysisIfAvailable<TargetPassConfig>`. * Passes not handling a null TargetMachine `addRequired<TargetPassConfig>` and call `getAnalysis<TargetPassConfig>`. * MachineFunctionPasses now use MF.getTarget(). * Remove all the TargetMachine constructors. * Remove INITIALIZE_TM_PASS. This fixes a crash when running `llc -start-before prologepilog`. PEI needs StackProtector, which gets constructed without a TargetMachine by the pass manager. The StackProtector pass doesn't handle the case where there is no TargetMachine, so it segfaults. Related to PR30324. Differential Revision: https://reviews.llvm.org/D33222 llvm-svn: 303360
* Allow DataLayout to specify addrspace for allocas.Matt Arsenault2017-04-101-2/+4
| | | | | | | | | | | | | | | | | | | | | | | LLVM makes several assumptions about address space 0. However, alloca is presently constrained to always return this address space. There's no real way to avoid using alloca, so without this there is no way to opt out of these assumptions. The problematic assumptions include: - That the pointer size used for the stack is the same size as the code size pointer, which is also the maximum sized pointer. - That 0 is an invalid, non-dereferencable pointer value. These are problems for AMDGPU because alloca is used to implement the private address space, which uses a 32-bit index as the pointer value. Other pointers are 64-bit and behave more like LLVM's notion of generic address space. By changing the address space used for allocas, we can change our generic pointer type to be LLVM's generic pointer type which does have similar properties. llvm-svn: 299888
* [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
OpenPOWER on IntegriCloud