X-Git-Url: http://plrg.eecs.uci.edu/git/?p=oota-llvm.git;a=blobdiff_plain;f=docs%2FLangRef.rst;h=5f8a3a5a4a9874f99b190283814d1cdb7860a98c;hp=650d18b9ba464e5866e13d36cc2124c84f774d94;hb=4b85564ba4a41465155b9128a68e5e14fea78365;hpb=fe9953a02c963403dd2e2fbda2f4c596cd6a4704 diff --git a/docs/LangRef.rst b/docs/LangRef.rst index 650d18b9ba4..5f8a3a5a4a9 100644 --- a/docs/LangRef.rst +++ b/docs/LangRef.rst @@ -5447,74 +5447,6 @@ Example: dispatch2: %cs2 = catchswitch within %parenthandler [label %handler0] unwind label %cleanup -.. _i_catchpad: - -'``catchpad``' Instruction -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Syntax: -""""""" - -:: - - = catchpad within [*] - -Overview: -""""""""" - -The '``catchpad``' instruction is used by `LLVM's exception handling -system `_ to specify that a basic block -begins a catch handler --- one where a personality routine attempts to transfer -control to catch an exception. - -Arguments: -"""""""""" - -The ``catchswitch`` operand must always be a token produced by a -:ref:`catchswitch ` instruction in a predecessor block. This -ensures that each ``catchpad`` has exactly one predecessor block, and it always -terminates in a ``catchswitch``. - -The ``args`` correspond to whatever information the personality routine -requires to know if this is an appropriate handler for the exception. Control -will transfer to the ``catchpad`` if this is the first appropriate handler for -the exception. - -The ``resultval`` has the type :ref:`token ` and is used to match the -``catchpad`` to corresponding :ref:`catchrets ` and other nested EH -pads. - -Semantics: -"""""""""" - -When the call stack is being unwound due to an exception being thrown, the -exception is compared against the ``args``. If it doesn't match, control will -not reach the ``catchpad`` instruction. The representation of ``args`` is -entirely target and personality function-specific. - -Like the :ref:`landingpad ` instruction, the ``catchpad`` -instruction must be the first non-phi of its parent basic block. - -The meaning of the tokens produced and consumed by ``catchpad`` and other "pad" -instructions is described in the -`Windows exception handling documentation\ `_. - -When a ``catchpad`` has been "entered" but not yet "exited" (as -described in the `EH documentation\ `_), -it is undefined behavior to execute a :ref:`call ` or :ref:`invoke ` -that does not carry an appropriate :ref:`"funclet" bundle `. - -Example: -"""""""" - -.. code-block:: llvm - - dispatch: - %cs = catchswitch within none [label %handler0] unwind to caller - ;; A catch block which can catch an integer. - handler0: - %tok = catchpad within %cs [i8** @_ZTIi] - .. _i_catchret: '``catchret``' Instruction @@ -7004,7 +6936,7 @@ name ```` corresponding to a metadata node with one ``i32`` entry of value 1. The existence of the ``!nontemporal`` metadata on the instruction tells the optimizer and code generator that this load is not expected to be reused in the cache. The code generator may select special -instructions to save cache bandwidth, such as the MOVNT instruction on +instructions to save cache bandwidth, such as the ``MOVNT`` instruction on x86. The optional ``!invariant.group`` metadata must reference a @@ -8598,6 +8530,74 @@ Example: catch i8** @_ZTIi filter [1 x i8**] [@_ZTId] +.. _i_catchpad: + +'``catchpad``' Instruction +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +:: + + = catchpad within [*] + +Overview: +""""""""" + +The '``catchpad``' instruction is used by `LLVM's exception handling +system `_ to specify that a basic block +begins a catch handler --- one where a personality routine attempts to transfer +control to catch an exception. + +Arguments: +"""""""""" + +The ``catchswitch`` operand must always be a token produced by a +:ref:`catchswitch ` instruction in a predecessor block. This +ensures that each ``catchpad`` has exactly one predecessor block, and it always +terminates in a ``catchswitch``. + +The ``args`` correspond to whatever information the personality routine +requires to know if this is an appropriate handler for the exception. Control +will transfer to the ``catchpad`` if this is the first appropriate handler for +the exception. + +The ``resultval`` has the type :ref:`token ` and is used to match the +``catchpad`` to corresponding :ref:`catchrets ` and other nested EH +pads. + +Semantics: +"""""""""" + +When the call stack is being unwound due to an exception being thrown, the +exception is compared against the ``args``. If it doesn't match, control will +not reach the ``catchpad`` instruction. The representation of ``args`` is +entirely target and personality function-specific. + +Like the :ref:`landingpad ` instruction, the ``catchpad`` +instruction must be the first non-phi of its parent basic block. + +The meaning of the tokens produced and consumed by ``catchpad`` and other "pad" +instructions is described in the +`Windows exception handling documentation\ `_. + +When a ``catchpad`` has been "entered" but not yet "exited" (as +described in the `EH documentation\ `_), +it is undefined behavior to execute a :ref:`call ` or :ref:`invoke ` +that does not carry an appropriate :ref:`"funclet" bundle `. + +Example: +"""""""" + +.. code-block:: llvm + + dispatch: + %cs = catchswitch within none [label %handler0] unwind to caller + ;; A catch block which can catch an integer. + handler0: + %tok = catchpad within %cs [i8** @_ZTIi] + .. _i_cleanuppad: '``cleanuppad``' Instruction @@ -8657,10 +8657,6 @@ described in the `EH documentation\ `_ it is undefined behavior to execute a :ref:`call ` or :ref:`invoke ` that does not carry an appropriate :ref:`"funclet" bundle `. -It is undefined behavior for the ``cleanuppad`` to exit via an unwind edge which -does not transitively unwind to the same destination as a constituent -``cleanupret``. - Example: """"""""