57 lines
2.6 KiB
Plaintext
57 lines
2.6 KiB
Plaintext
|
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
|
||
|
|
|