57 lines · plain
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 optimization5 6 7In C++ programs, exceptions suck, and here's why:8 91. In virtually all function calls, you must assume that the function10 throws an exception, unless it is defined as 'nothrow'. This means11 that every function call has to have code to invoke dtors on objects12 locally if one is thrown by the function. Most functions don't throw13 exceptions, so this code is dead [with all the bad effects of dead14 code, including icache pollution].152. Declaring a function nothrow causes catch blocks to be added to every16 call that isnot provably nothrow. This makes them very slow.173. Extra extraneous exception edges reduce the opportunity for code18 motion.194. EH is typically implemented with large lookup tables. Ours is going to20 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 trivial24 to analyze instantiations of said code.256. Most large C++ programs throw few exceptions. Most well designed26 programs only throw exceptions in specific planned portions of the27 code.28 29Given our _planned_ model of handling exceptions, all of this would be30pretty trivial to eliminate through some pretty simplistic interprocedural31analysis. The DCE factor alone could probably be pretty significant. The32extra code motion opportunities could also be exploited though...33 34Additionally, this optimization can be implemented in a straight forward35conservative manner, allowing libraries to be optimized or individual36files even (if there are leaf functions visible in the translation unit37that are called).38 39I think it's a reasonable optimization that hasn't really been addressed40(because assembly is way too low level for this), and could have decent41payoffs... without being a overly complex optimization.42 43After I wrote all of that, I found this page that is talking about44basically the same thing I just wrote, except that it is translation unit45at a time, tree based approach:46http://www.ocston.org/~jls/ehopt.html47 48but is very useful from "expected gain" and references perspective. Note49that their compiler is apparently unable to inline functions that use50exceptions, so there numbers are pretty worthless... also our results51would (hopefully) be better because it's interprocedural...52 53What do you think?54 55-Chris56 57