On Mon, Dec 8, 2008 at 12:55 AM, Eric Rannaud <[EMAIL PROTECTED]>wrote:
> On Sun, Dec 07, 2008 at 10:37:52PM -0500, Jonathan S. Shapiro wrote: > > The answer is a bit cheesy: BitC does not declare raised exceptions as > part > > of a function type. Since *any* function can raise an exception > > Why? Why aren't exceptions thrown at least declared with the function? > Why can't we have functions known to not throw exceptions? > > There are a number of advantages: > - documentation, > - optimization: if the runtime cost in cycles of being able to catch > exceptions can essentially be zero... > - less uncaught exceptions. The documentation point is valid, but that only requires optional declaration. I actually agree that we should have that, and I overlooked it. It's completely separate from having exceptions be part of function signature. The "less uncaught exceptions" argument presumes that exceptions should be caught. In my experience, caught exceptions fall into three categories: 1. Catch very near throw. Catcher has direct understanding of what is going on, and can recover in detail. 2. Catch several frames above throw. In this case we are testing for specific cases that are recoverable, and all others will not be. The remaining cases are handled by a catch-all, and are not explicitly caught in any case. 3. Catch wrapping a trial call, where the entire sub-call is permitted to fail. In this case you usually don't care what exception was thrown, or if you do, it is only for diagnostic purposes. So I don't buy the "less uncaught exceptions" argument. It doesn't fit observed use in the field. But the thing I really want to go into hear is optimization: There is no exception handling scheme in which catch blocks can be optimized away completely in the absence of whole-program compilation, because in practice any code can raise an exception through allocation failure. BitC is not C++. There are no destructors (this is by design), so no code for those. Note that even in C++ such code is not "in line" and does not impact optimization. So as a practical matter, the only optimization cost of exceptions is to constrain the registerization of values that are live at the beginning of the catch handler block. These can still be registerized; the constraint is simply that you need to know which registers they are in and there is some desire to place them in call-saved registers. That isn't a big constraint in practice. So I'm not at all clear what optimization advantage you anticipate here. The runtime cost of a try/catch block is either zero (if frames are unwindable) or four instructions (to link/unlink the catch frame context). Try blocks in inner loops are quite rare, so this doesn't seem like a terribly critical case to optimize. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
