Chris Lattner | 7fbce77 | 2001-09-19 13:52:01 +0000 | [diff] [blame] | 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 | |