[llvm] 06210d5 - ExceptionHandling documentation tweaks.
James Y Knight via llvm-commits
llvm-commits at lists.llvm.org
Mon Jan 16 17:36:48 PST 2023
Author: James Y Knight
Date: 2023-01-16T20:36:09-05:00
New Revision: 06210d50c05d211c9ea99d1ddfd9e474027f124f
URL: https://github.com/llvm/llvm-project/commit/06210d50c05d211c9ea99d1ddfd9e474027f124f
DIFF: https://github.com/llvm/llvm-project/commit/06210d50c05d211c9ea99d1ddfd9e474027f124f.diff
LOG: ExceptionHandling documentation tweaks.
Delete mention of the llvm.eh.begincatch/llvm.eh.endcatch intrinsics,
and remove them from a few remaining test-cases. These intrinsics were
from a previous attempt at implementing Windows exception-handling,
but were removed from LLVM in 2015.
Also mention that dynamic exception specifications ("throw filters")
were removed from the spec in C++17.
Added:
Modified:
llvm/docs/ExceptionHandling.rst
llvm/test/CodeGen/X86/win32-eh-states.ll
llvm/test/CodeGen/X86/win32-eh.ll
Removed:
llvm/test/Analysis/Lint/cppeh-catch-intrinsics-clean.ll
################################################################################
diff --git a/llvm/docs/ExceptionHandling.rst b/llvm/docs/ExceptionHandling.rst
index ebd3cbd3d9372..c35491a5590cd 100644
--- a/llvm/docs/ExceptionHandling.rst
+++ b/llvm/docs/ExceptionHandling.rst
@@ -189,8 +189,9 @@ sequentially from first to last. The clauses have the following meanings:
being thrown does *not* match any of the types in the list (which, for C++,
are again specified as ``std::type_info`` pointers).
- - C++ front-ends use this to implement C++ exception specifications, such as
- "``void foo() throw (ExcType1, ..., ExcTypeN) { ... }``".
+ - C++ front-ends use this to implement the C++ exception specifications, such as
+ "``void foo() throw (ExcType1, ..., ExcTypeN) { ... }``". (Note: this
+ functionality was deprecated in C++11 and removed in C++17.)
- When this clause is matched, the selector value will be negative.
@@ -278,10 +279,10 @@ landing pad.
Throw Filters
-------------
-C++ allows the specification of which exception types may be thrown from a
-function. To represent this, a top level landing pad may exist to filter out
-invalid types. To express this in LLVM code the :ref:`i_landingpad` will have a
-filter clause. The clause consists of an array of type infos.
+Prior to C++17, C++ allowed the specification of which exception types may be
+thrown from a function. To represent this, a top level landing pad may exist to
+filter out invalid types. To express this in LLVM code the :ref:`i_landingpad`
+will have a filter clause. The clause consists of an array of type infos.
``landingpad`` will return a negative value
if the exception does not match any of the type infos. If no match is found then
a call to ``__cxa_call_unexpected`` should be made, otherwise
@@ -292,8 +293,6 @@ having more than one cleanup is pointless). The LLVM C++ front-end can generate
such ``landingpad`` instructions due to inlining creating nested exception
handling scopes.
-.. _undefined:
-
Restrictions
------------
@@ -337,70 +336,6 @@ function. This value can be used to compare against the result of
Uses of this intrinsic are generated by the C++ front-end.
-.. _llvm.eh.begincatch:
-
-``llvm.eh.begincatch``
-----------------------
-
-.. code-block:: llvm
-
- void @llvm.eh.begincatch(i8* %ehptr, i8* %ehobj)
-
-
-This intrinsic marks the beginning of catch handling code within the blocks
-following a ``landingpad`` instruction. The exact behavior of this function
-depends on the compilation target and the personality function associated
-with the ``landingpad`` instruction.
-
-The first argument to this intrinsic is a pointer that was previously extracted
-from the aggregate return value of the ``landingpad`` instruction. The second
-argument to the intrinsic is a pointer to stack space where the exception object
-should be stored. The runtime handles the details of copying the exception
-object into the slot. If the second parameter is null, no copy occurs.
-
-Uses of this intrinsic are generated by the C++ front-end. Many targets will
-use implementation-specific functions (such as ``__cxa_begin_catch``) instead
-of this intrinsic. The intrinsic is provided for targets that require a more
-abstract interface.
-
-When used in the native Windows C++ exception handling implementation, this
-intrinsic serves as a placeholder to delimit code before a catch handler is
-outlined. When the handler is outlined, this intrinsic will be replaced
-by instructions that retrieve the exception object pointer from the frame
-allocation block.
-
-
-.. _llvm.eh.endcatch:
-
-``llvm.eh.endcatch``
-----------------------
-
-.. code-block:: llvm
-
- void @llvm.eh.endcatch()
-
-
-This intrinsic marks the end of catch handling code within the current block,
-which will be a successor of a block which called ``llvm.eh.begincatch''.
-The exact behavior of this function depends on the compilation target and the
-personality function associated with the corresponding ``landingpad``
-instruction.
-
-There may be more than one call to ``llvm.eh.endcatch`` for any given call to
-``llvm.eh.begincatch`` with each ``llvm.eh.endcatch`` call corresponding to the
-end of a
diff erent control path. All control paths following a call to
-``llvm.eh.begincatch`` must reach a call to ``llvm.eh.endcatch``.
-
-Uses of this intrinsic are generated by the C++ front-end. Many targets will
-use implementation-specific functions (such as ``__cxa_begin_catch``) instead
-of this intrinsic. The intrinsic is provided for targets that require a more
-abstract interface.
-
-When used in the native Windows C++ exception handling implementation, this
-intrinsic serves as a placeholder to delimit code before a catch handler is
-outlined. After the handler is outlined, this intrinsic is simply removed.
-
-
.. _llvm.eh.exceptionpointer:
``llvm.eh.exceptionpointer``
diff --git a/llvm/test/Analysis/Lint/cppeh-catch-intrinsics-clean.ll b/llvm/test/Analysis/Lint/cppeh-catch-intrinsics-clean.ll
deleted file mode 100644
index 1bc673098f4ec..0000000000000
--- a/llvm/test/Analysis/Lint/cppeh-catch-intrinsics-clean.ll
+++ /dev/null
@@ -1,109 +0,0 @@
-; RUN: opt -passes=lint -disable-output < %s
-
-; This test is meant to prove that the verifier does not report errors for correct
-; use of the llvm.eh.begincatch and llvm.eh.endcatch intrinsics.
-
-target triple = "x86_64-pc-windows-msvc"
-
-declare void @llvm.eh.begincatch(ptr, ptr)
-
-declare void @llvm.eh.endcatch()
-
- at _ZTIi = external constant ptr
-
-; Function Attrs: uwtable
-define void @test_ref_clean() personality ptr @__CxxFrameHandler3 {
-entry:
- invoke void @_Z9may_throwv()
- to label %try.cont unwind label %lpad
-
-lpad: ; preds = %entry
- %0 = landingpad { ptr, i32 }
- catch ptr @_ZTIi
- %exn = extractvalue { ptr, i32 } %0, 0
- %sel = extractvalue { ptr, i32 } %0, 1
- %1 = call i32 @llvm.eh.typeid.for(ptr @_ZTIi)
- %matches = icmp eq i32 %sel, %1
- br i1 %matches, label %catch, label %eh.resume
-
-catch: ; preds = %lpad
- call void @llvm.eh.begincatch(ptr %exn, ptr null)
- call void @_Z10handle_intv()
- br label %invoke.cont2
-
-invoke.cont2: ; preds = %catch
- call void @llvm.eh.endcatch()
- br label %try.cont
-
-try.cont: ; preds = %invoke.cont2, %entry
- ret void
-
-eh.resume: ; preds = %catch.dispatch
- resume { ptr, i32 } %0
-}
-
-; Function Attrs: uwtable
-define void @test_ref_clean_multibranch() personality ptr @__CxxFrameHandler3 {
-entry:
- invoke void @_Z9may_throwv()
- to label %invoke.cont unwind label %lpad
-
-invoke.cont:
- invoke void @_Z9may_throwv()
- to label %invoke.cont unwind label %lpad1
-
-lpad: ; preds = %entry
- %0 = landingpad { ptr, i32 }
- catch ptr @_ZTIi
- %exn = extractvalue { ptr, i32 } %0, 0
- %sel = extractvalue { ptr, i32 } %0, 1
- %1 = call i32 @llvm.eh.typeid.for(ptr @_ZTIi)
- %matches = icmp eq i32 %sel, %1
- br i1 %matches, label %catch, label %eh.resume
-
- invoke void @_Z9may_throwv()
- to label %try.cont unwind label %lpad
-
-lpad1: ; preds = %entry
- %l1.0 = landingpad { ptr, i32 }
- cleanup
- catch ptr @_ZTIi
- %exn1 = extractvalue { ptr, i32 } %l1.0, 0
- %sel1 = extractvalue { ptr, i32 } %l1.0, 1
- %l1.1 = call i32 @llvm.eh.typeid.for(ptr @_ZTIi)
- %matchesl1 = icmp eq i32 %sel1, %l1.1
- br i1 %matchesl1, label %catch, label %eh.resume
-
-catch: ; preds = %lpad, %lpad1
- %exn2 = phi ptr [%exn, %lpad], [%exn1, %lpad1]
- %sel2 = phi i32 [%sel, %lpad], [%sel1, %lpad1]
- call void @llvm.eh.begincatch(ptr %exn2, ptr null)
- call void @_Z10handle_intv()
- %matches1 = icmp eq i32 %sel2, 0
- br i1 %matches1, label %invoke.cont2, label %invoke.cont3
-
-invoke.cont2: ; preds = %catch
- call void @llvm.eh.endcatch()
- br label %try.cont
-
-invoke.cont3: ; preds = %catch
- call void @llvm.eh.endcatch()
- br label %eh.resume
-
-try.cont: ; preds = %invoke.cont2, %entry
- ret void
-
-eh.resume: ; preds = %catch.dispatch
- %lpad.val = insertvalue { ptr, i32 } undef, i32 0, 1
- resume { ptr, i32 } %lpad.val
-}
-
-declare void @_Z9may_throwv()
-
-declare i32 @__CxxFrameHandler3(...)
-
-; Function Attrs: nounwind readnone
-declare i32 @llvm.eh.typeid.for(ptr)
-
-declare void @_Z10handle_intv()
-
diff --git a/llvm/test/CodeGen/X86/win32-eh-states.ll b/llvm/test/CodeGen/X86/win32-eh-states.ll
index ea94fed1ab7a5..42ae5b060e6f4 100644
--- a/llvm/test/CodeGen/X86/win32-eh-states.ll
+++ b/llvm/test/CodeGen/X86/win32-eh-states.ll
@@ -21,8 +21,6 @@
declare void @may_throw(i32)
declare i32 @__CxxFrameHandler3(...)
-declare void @llvm.eh.begincatch(ptr, ptr)
-declare void @llvm.eh.endcatch()
declare i32 @llvm.eh.typeid.for(ptr)
$"\01??_R0H at 8" = comdat any
diff --git a/llvm/test/CodeGen/X86/win32-eh.ll b/llvm/test/CodeGen/X86/win32-eh.ll
index 75e0f63996110..82dc4beaf972b 100644
--- a/llvm/test/CodeGen/X86/win32-eh.ll
+++ b/llvm/test/CodeGen/X86/win32-eh.ll
@@ -4,8 +4,6 @@ declare void @may_throw_or_crash()
declare i32 @_except_handler3(...)
declare i32 @_except_handler4(...)
declare i32 @__CxxFrameHandler3(...)
-declare void @llvm.eh.begincatch(ptr, ptr)
-declare void @llvm.eh.endcatch()
declare i32 @llvm.eh.typeid.for(ptr)
define internal i32 @catchall_filt() {
More information about the llvm-commits
mailing list