diff options
Diffstat (limited to 'docs/HistoricalNotes/2001-09-18-OptimizeExceptions.txt')
| -rw-r--r-- | docs/HistoricalNotes/2001-09-18-OptimizeExceptions.txt | 56 |
1 files changed, 0 insertions, 56 deletions
diff --git a/docs/HistoricalNotes/2001-09-18-OptimizeExceptions.txt b/docs/HistoricalNotes/2001-09-18-OptimizeExceptions.txt deleted file mode 100644 index 9379081..0000000 --- a/docs/HistoricalNotes/2001-09-18-OptimizeExceptions.txt +++ /dev/null @@ -1,56 +0,0 @@ -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 - |