| 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 | |