llvm/docs/HistoricalNotes/2001-09-18-OptimizeExceptions.txt

Date: Tue, 18 Sep 2001 00:38:37 -0500 (CDT)
From: Chris Lattner <sabre@nondot.org>
To: Vikram S. Adve <vadve@cs.uiuc.edu>
Subject: Idea for a simple, useful link time optimization


In C++ programs, exceptions suck, and here's why:

1. In virtually all function calls, you must assume that the function
   throws an exception, unless it is defined as 'nothrow'.  This means
   that every function call has to have code to invoke dtors on objects
   locally if one is thrown by the function.  Most functions don't throw
   exceptions, so this code is dead [with all the bad effects of dead
   code, including icache pollution].
2. Declaring a function nothrow causes catch blocks to be added to every
   call that isnot  provably nothrow.  This makes them very slow.
3. Extra extraneous exception edges reduce the opportunity for code
   motion.
4. EH is typically implemented with large lookup tables.  Ours is going to
   be much smaller (than the "standard" way of doing it) to start with,
   but eliminating it entirely would be nice. :)
5. It is physically impossible to correctly put (accurate, correct)
   exception specifications on generic, templated code.  But it is trivial
   to analyze instantiations of said code.
6. Most large C++ programs throw few exceptions.  Most well designed
   programs only throw exceptions in specific planned portions of the
   code.

Given our _planned_ model of handling exceptions, all of this would be
pretty trivial to eliminate through some pretty simplistic interprocedural
analysis.  The DCE factor alone could probably be pretty significant.  The
extra code motion opportunities could also be exploited though...

Additionally, this optimization can be implemented in a straight forward
conservative manner, allowing libraries to be optimized or individual
files even (if there are leaf functions visible in the translation unit
that are called).

I think it's a reasonable optimization that hasn't really been addressed
(because assembly is way too low level for this), and could have decent
payoffs... without being a overly complex optimization.

After I wrote all of that, I found this page that is talking about
basically the same thing I just wrote, except that it is translation unit
at a time, tree based approach:
http://www.ocston.org/~jls/ehopt.html

but is very useful from "expected gain" and references perspective.  Note
that their compiler is apparently unable to inline functions that use
exceptions, so there numbers are pretty worthless... also our results
would (hopefully) be better because it's interprocedural...

What do you think?

-Chris