]>
Commit | Line | Data |
---|---|---|
223e47cc LB |
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 |