llvm.org GIT mirror llvm / 7fbce77
Add idea git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@638 91177308-0d34-0410-b5e6-96231b3b80d8 Chris Lattner 18 years ago
1 changed file(s) with 56 addition(s) and 0 deletion(s). Raw diff Collapse all Expand all
0 Date: Tue, 18 Sep 2001 00:38:37 -0500 (CDT)
1 From: Chris Lattner
2 To: Vikram S. Adve
3 Subject: Idea for a simple, useful link time optimization
6 In C++ programs, exceptions suck, and here's why:
8 1. In virtually all function calls, you must assume that the function
9 throws an exception, unless it is defined as 'nothrow'. This means
10 that every function call has to have code to invoke dtors on objects
11 locally if one is thrown by the function. Most functions don't throw
12 exceptions, so this code is dead [with all the bad effects of dead
13 code, including icache pollution].
14 2. Declaring a function nothrow causes catch blocks to be added to every
15 call that isnot provably nothrow. This makes them very slow.
16 3. Extra extraneous exception edges reduce the opportunity for code
17 motion.
18 4. EH is typically implemented with large lookup tables. Ours is going to
19 be much smaller (than the "standard" way of doing it) to start with,
20 but eliminating it entirely would be nice. :)
21 5. It is physically impossible to correctly put (accurate, correct)
22 exception specifications on generic, templated code. But it is trivial
23 to analyze instantiations of said code.
24 6. Most large C++ programs throw few exceptions. Most well designed
25 programs only throw exceptions in specific planned portions of the
26 code.
28 Given our _planned_ model of handling exceptions, all of this would be
29 pretty trivial to eliminate through some pretty simplistic interprocedural
30 analysis. The DCE factor alone could probably be pretty significant. The
31 extra code motion opportunities could also be exploited though...
33 Additionally, this optimization can be implemented in a straight forward
34 conservative manner, allowing libraries to be optimized or individual
35 files even (if there are leaf functions visible in the translation unit
36 that are called).
38 I think it's a reasonable optimization that hasn't really been addressed
39 (because assembly is way too low level for this), and could have decent
40 payoffs... without being a overly complex optimization.
42 After I wrote all of that, I found this page that is talking about
43 basically the same thing I just wrote, except that it is translation unit
44 at a time, tree based approach:
45 http://www.ocston.org/~jls/ehopt.html
47 but is very useful from "expected gain" and references perspective. Note
48 that their compiler is apparently unable to inline functions that use
49 exceptions, so there numbers are pretty worthless... also our results
50 would (hopefully) be better because it's interprocedural...
52 What do you think?
54 -Chris