David Majnemer c8b1f095a3 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-17 20:52:32 +00:00
..
basic.ll	[Statepoints] Support for "patchable" statepoints.	2015-05-12 23:52:24 +00:00
call_gc_result.ll	[PlaceSafepoints] Assertion on that gc_result can not have preceding phis should only apply to invoke statepoint	2015-05-18 19:02:25 +00:00
call-in-loop.ll	[Statepoints] Support for "patchable" statepoints.	2015-05-12 23:52:24 +00:00
finite-loops.ll	[Statepoints] Support for "patchable" statepoints.	2015-05-12 23:52:24 +00:00
invokes.ll	Move the personality function from LandingPadInst to Function	2015-06-17 20:52:32 +00:00
memset.ll	[PlaceSafepoints] Stop special casing some intrinsics	2015-05-19 23:40:11 +00:00
patchable-statepoints.ll	Move the personality function from LandingPadInst to Function	2015-06-17 20:52:32 +00:00
split-backedge.ll	[Statepoints] Support for "patchable" statepoints.	2015-05-12 23:52:24 +00:00
statepoint-calling-conventions.ll	Move the personality function from LandingPadInst to Function	2015-06-17 20:52:32 +00:00
statepoint-coreclr.ll	Add a GCStrategy for CoreCLR	2015-05-20 01:07:23 +00:00
statepoint-format.ll	Move the personality function from LandingPadInst to Function	2015-06-17 20:52:32 +00:00
statepoint-frameescape.ll	[Statepoints] Support for "patchable" statepoints.	2015-05-12 23:52:24 +00:00