[Bug c++/92823] New: Is that possible to optimize C++ exception??????????? I always HATE 2 phases of exception unwind

[euloanty at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92823

            Bug ID: 92823
           Summary: Is that possible to optimize C++ exception???????????
                    I always HATE 2 phases of exception unwind
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Keywords: EH
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: euloanty at live dot com
  Target Milestone: ---

This paper shows the possibility of optimizing the current exception model.
Just optimize lippincott function will yield huge benefits.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1676r0.pdf

Here is the proposal of Bjarne Stroustrup:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1947r0.pdf

Same with clang. It also does 2 phase unwinding.

Stroustrup C++ exceptions and alternatives P1947

I think that the current implementations of C++ exception handling are
sub-optimal from a performance
standpoint and could be improved:
• GCC always (even in optimized modes) walks the stack twice to provide better
debug support.
• Implementations use complete RTTI implementations to do type matching
(ostensibly to
simplify use of dynamic linking).
• Cross-function optimizations of exception handling are still rare.
• Special-purpose stack-unwinding and type-matching algorithms are not used for
systems with
special requirements (e.g., with no dynamic linking or tight memories).
• Some exception handling mechanisms cater for generalizations and alternatives
not mandated
by the standard.
• There seem to be no optimization of the original case of passing and catching
simple exceptions
by value. Given final, we can know that a given exception type isn’t the root
of a hierarchy.
• Use of the general free store for all exception objects, rather than
pre-allocated memory for
common and important exceptions as anticipated in the original design.
One reason for the relative poverty of optimizations seems to be that since
exceptions were considered
slow there seemed no reason to optimize them. Thus, exception handling is now
relatively slower than it
was in the 1990s. Other kinds of code have been significantly optimized since
then.
As an example of a missed opportunity, I can mention the Chinese-remainder fast
constant-time type
matching algorithm that I published in 2005 [Gibbs]. For closed systems and
relatively small class
hierarchies (as are increasingly common in embedded systems), this eliminates
almost all of the type
matching cost.
It may also be the case that the table-based implementation approach is
sub-optimal for tiny memories
compared to error-code/stack-marking implementation approaches. The possibility
of special-purpose
implementations of exception handling for special-purpose systems ought to be
explored. The
Edinburgh experiments [Renwick] are encouraging for this direction of
exploration.