1Date: Tue, 18 Sep 2001 00:38:37 -0500 (CDT) 2From: Chris Lattner <sabre@nondot.org> 3To: Vikram S. Adve <vadve@cs.uiuc.edu> 4Subject: Idea for a simple, useful link time optimization 5 6 7In C++ programs, exceptions suck, and here's why: 8 91. 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]. 152. Declaring a function nothrow causes catch blocks to be added to every 16 call that isnot provably nothrow. This makes them very slow. 173. Extra extraneous exception edges reduce the opportunity for code 18 motion. 194. 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. :) 225. 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. 256. Most large C++ programs throw few exceptions. Most well designed 26 programs only throw exceptions in specific planned portions of the 27 code. 28 29Given our _planned_ model of handling exceptions, all of this would be 30pretty trivial to eliminate through some pretty simplistic interprocedural 31analysis. The DCE factor alone could probably be pretty significant. The 32extra code motion opportunities could also be exploited though... 33 34Additionally, this optimization can be implemented in a straight forward 35conservative manner, allowing libraries to be optimized or individual 36files even (if there are leaf functions visible in the translation unit 37that are called). 38 39I 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 41payoffs... without being a overly complex optimization. 42 43After I wrote all of that, I found this page that is talking about 44basically the same thing I just wrote, except that it is translation unit 45at a time, tree based approach: 46http://www.ocston.org/~jls/ehopt.html 47 48but is very useful from "expected gain" and references perspective. Note 49that their compiler is apparently unable to inline functions that use 50exceptions, so there numbers are pretty worthless... also our results 51would (hopefully) be better because it's interprocedural... 52 53What do you think? 54 55-Chris 56 57