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

   1 Date: Tue, 18 Sep 2001 00:38:37 -0500 (CDT)
   2 From: Chris Lattner <sabre@nondot.org>
   3 To: Vikram S. Adve <vadve@cs.uiuc.edu>
   4 Subject: Idea for a simple, useful link time optimization
   5
   6
   7 In C++ programs, exceptions suck, and here's why:
   8
   9 1. In virtually all function calls, you must assume that the function
  10    throws an exception, unless it is defined as 'nothrow'.  This means
  11    that every function call has to have code to invoke dtors on objects
  12    locally if one is thrown by the function.  Most functions don't throw
  13    exceptions, so this code is dead [with all the bad effects of dead
  14    code, including icache pollution].
  15 2. Declaring a function nothrow causes catch blocks to be added to every
  16    call that isnot  provably nothrow.  This makes them very slow.
  17 3. Extra extraneous exception edges reduce the opportunity for code
  18    motion.
  19 4. EH is typically implemented with large lookup tables.  Ours is going to
  20    be much smaller (than the "standard" way of doing it) to start with,
  21    but eliminating it entirely would be nice. :)
  22 5. It is physically impossible to correctly put (accurate, correct)
  23    exception specifications on generic, templated code.  But it is trivial
  24    to analyze instantiations of said code.
  25 6. Most large C++ programs throw few exceptions.  Most well designed
  26    programs only throw exceptions in specific planned portions of the
  27    code.
  28
  29 Given our _planned_ model of handling exceptions, all of this would be
  30 pretty trivial to eliminate through some pretty simplistic interprocedural
  31 analysis.  The DCE factor alone could probably be pretty significant.  The
  32 extra code motion opportunities could also be exploited though...
  33
  34 Additionally, this optimization can be implemented in a straight forward
  35 conservative manner, allowing libraries to be optimized or individual
  36 files even (if there are leaf functions visible in the translation unit
  37 that are called).
  38
  39 I think it's a reasonable optimization that hasn't really been addressed
  40 (because assembly is way too low level for this), and could have decent
  41 payoffs... without being a overly complex optimization.
  42
  43 After I wrote all of that, I found this page that is talking about
  44 basically the same thing I just wrote, except that it is translation unit
  45 at a time, tree based approach:
  46 http://www.ocston.org/~jls/ehopt.html
  47
  48 but is very useful from "expected gain" and references perspective.  Note
  49 that their compiler is apparently unable to inline functions that use
  50 exceptions, so there numbers are pretty worthless... also our results
  51 would (hopefully) be better because it's interprocedural...
  52
  53 What do you think?
  54
  55 -Chris
  56