[IR] Remove terminatepad

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255522 91177308-0d34-0410-b5e6-96231b3b80d8

2 files changed, 12 insertions, 73 deletions

diff --git a/docs/ExceptionHandling.rst b/docs/ExceptionHandling.rst
index f89e3027d5d..74827c02a27 100644
--- a/docs/ExceptionHandling.rst
+++ b/docs/ExceptionHandling.rst
@@ -615,15 +615,11 @@ purposes.
 The following new instructions are considered "exception handling pads", in that
 they must be the first non-phi instruction of a basic block that may be the
 unwind destination of an EH flow edge:
-``catchswitch``, ``catchpad``, ``cleanuppad``, and ``terminatepad``.
+``catchswitch``, ``catchpad``, and ``cleanuppad``.
 As with landingpads, when entering a try scope, if the
 frontend encounters a call site that may throw an exception, it should emit an
 invoke that unwinds to a ``catchswitch`` block. Similarly, inside the scope of a
-C++ object with a destructor, invokes should unwind to a ``cleanuppad``. The
-``terminatepad`` instruction exists to represent ``noexcept`` and throw
-specifications with one combined instruction. All potentially throwing calls in
-a ``noexcept`` function should transitively unwind to a terminateblock. Throw
-specifications are not implemented by MSVC, and are not yet supported.
+C++ object with a destructor, invokes should unwind to a ``cleanuppad``.
 
 New instructions are also used to mark the points where control is transferred
 out of a catch/cleanup handler (which will correspond to exits from the
@@ -634,9 +630,9 @@ by normal execution executes a ``cleanupret`` instruction, which is a terminator
 indicating where the active exception will unwind to next.
 
 Each of these new EH pad instructions has a way to identify which action should
-be considered after this action. The ``catchswitch`` and ``terminatepad``
-instructions are terminators, and have a unwind destination operand analogous
-to the unwind destination of an invoke.  The ``cleanuppad`` instruction is not
+be considered after this action. The ``catchswitch`` instruction is a terminator
+and has an unwind destination operand analogous to the unwind destination of an
+invoke.  The ``cleanuppad`` instruction is not
 a terminator, so the unwind destination is stored on the ``cleanupret``
 instruction instead. Successfully executing a catch handler should resume
 normal control flow, so neither ``catchpad`` nor ``catchret`` instructions can
@@ -707,7 +703,9 @@ all of the new IR instructions:
     catchret from %catch to label %return
 
   lpad.terminate:                                   ; preds = %catch.body, %lpad.catch
-    terminatepad within none [void ()* @"\01?terminate@@YAXXZ"] unwind to caller
+    cleanuppad within none []
+    call void @"\01?terminate@@YAXXZ"
+    unreachable
   }
 
 Funclet parent tokens
@@ -725,8 +723,7 @@ The ``catchswitch`` instruction does not create a funclet, but it produces a
 token that is always consumed by its immediate successor ``catchpad``
 instructions. This ensures that every catch handler modelled by a ``catchpad``
 belongs to exactly one ``catchswitch``, which models the dispatch point after a
-C++ try. The ``terminatepad`` instruction cannot contain lexically nested
-funclets inside the termination action, so it does not produce a token.
+C++ try.
 
 Here is an example of what this nesting looks like using some hypothetical
 C++ code:
diff --git a/docs/LangRef.rst b/docs/LangRef.rst
index e4197a1d225..5f4c4b1eeab 100644
--- a/docs/LangRef.rst
+++ b/docs/LangRef.rst
@@ -5004,7 +5004,6 @@ The terminator instructions are: ':ref:`ret <i_ret>`',
 ':ref:`resume <i_resume>`', ':ref:`catchswitch <i_catchswitch>`',
 ':ref:`catchret <i_catchret>`',
 ':ref:`cleanupret <i_cleanupret>`',
-':ref:`terminatepad <i_terminatepad>`',
 and ':ref:`unreachable <i_unreachable>`'.
 
 .. _i_ret:
@@ -5388,8 +5387,7 @@ The ``parent`` argument is the token of the funclet that contains the
 this operand may be the token ``none``.
 
 The ``default`` argument is the label of another basic block beginning with a
-"pad" instruction, one of ``cleanuppad``, ``terminatepad``, or
-``catchswitch``.
+"pad" instruction, one of ``cleanuppad`` or ``catchswitch``.
 
 The ``handlers`` are a list of successor blocks that each begin with a
 :ref:`catchpad <i_catchpad>` instruction.
@@ -5473,7 +5471,7 @@ The pad may then be "exited" in one of three ways:
     is undefined behavior if any descendant pads have been entered but not yet
     exited.
 2)  implicitly via a call (which unwinds all the way to the current function's caller),
-    or via a ``catchswitch``, ``cleanupret``, or ``terminatepad`` that unwinds to caller.
+    or via a ``catchswitch`` or a ``cleanupret`` that unwinds to caller.
 3)  implicitly via an unwind edge whose destination EH pad isn't a descendant of
     the ``catchpad``.  When the ``catchpad`` is exited in this manner, it is
     undefined behavior if the destination EH pad has a parent which is not an
@@ -5589,62 +5587,6 @@ Example:
       cleanupret from %cleanup unwind to caller
       cleanupret from %cleanup unwind label %continue
 
-.. _i_terminatepad:
-
-'``terminatepad``' Instruction
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Syntax:
-"""""""
-
-::
-
-      terminatepad within <token> [<args>*] unwind label <exception label>
-      terminatepad within <token> [<args>*] unwind to caller
-
-Overview:
-"""""""""
-
-The '``terminatepad``' instruction is used by `LLVM's exception handling
-system <ExceptionHandling.html#overview>`_ to specify that a basic block
-is a terminate block --- one where a personality routine may decide to
-terminate the program.
-The ``args`` correspond to whatever information the personality
-routine requires to know if this is an appropriate place to terminate the
-program. Control is transferred to the ``exception`` label if the
-personality routine decides not to terminate the program for the
-in-flight exception.
-
-Arguments:
-""""""""""
-
-The instruction takes a list of arbitrary values which are interpreted
-by the :ref:`personality function <personalityfn>`.
-
-The ``terminatepad`` may be given an ``exception`` label to
-transfer control to if the in-flight exception matches the ``args``.
-
-Semantics:
-""""""""""
-
-When the call stack is being unwound due to an exception being thrown,
-the exception is compared against the ``args``. If it matches,
-then control is transfered to the ``exception`` basic block. Otherwise,
-the program is terminated via personality-specific means. Typically,
-the first argument to ``terminatepad`` specifies what function the
-personality should defer to in order to terminate the program.
-
-The ``terminatepad`` instruction is both a terminator and a "pad" instruction,
-meaning that is always the only non-phi instruction in the basic block.
-
-Example:
-""""""""
-
-.. code-block:: llvm
-
-      ;; A terminate block which only permits integers.
-      terminatepad within none [i8** @_ZTIi] unwind label %continue
-
 .. _i_unreachable:
 
 '``unreachable``' Instruction
@@ -8686,7 +8628,7 @@ The pad may then be "exited" in one of three ways:
     is undefined behavior if any descendant pads have been entered but not yet
     exited.
 2)  implicitly via a call (which unwinds all the way to the current function's caller),
-    or via a ``catchswitch``, ``cleanupret``, or ``terminatepad`` that unwinds to caller.
+    or via a ``catchswitch`` or a ``cleanupret`` that unwinds to caller.
 3)  implicitly via an unwind edge whose destination EH pad isn't a descendant of
     the ``cleanuppad``.  When the ``cleanuppad`` is exited in this manner, it is
     undefined behavior if the destination EH pad has a parent which is not an