Date: Tue, 06 May 2003 15:15:48 -0400 From: Jason Merrill To: Mark Mitchell Subject: Re: __attribute__((cleanup(function)) versus try/finally Message-ID: References: <1052245742.2583.315.camel@doubledemon.codesourcery.com> MIME-Version: 1.0 Content-length: 2086 On 06 May 2003 11:29:01 -0700, Mark Mitchell wrote: > A key point (which seems to be missed by most people in this dicussion) > is that you do not need a language extension to get the correct behavior. > > You simply need to have the exception-handling mechanism aware of the C > cleanup stack. That would be an extension too, wouldn't it? In any case, how are you thinking to do this? You've mentioned such a thing before, but I haven't noticed an implementation sketch. > In fact, that solution delivers maximum performance: > > (1) C functions do not need to have handler code inserted. > > (2) You do not have to transfer control from the EH mechanism to the > stack frame of the caller in order to perform the cleanups. > > The __attribute__ solution can be implemented with the same optimal > performance, but that does not seem to be the way in which people intend > to implement it. > The try/finally solution cannot be implemented with this same > performance; it will, in fact, exact a performance price, in terms of > both code space and the speed at which cleanups are run, on all > systems. On systems with setjmp/longjmp exceptions, both costs will be > very high indeed. Hmm. Are you talking about representing cleanups in the LSDA via a function pointer and a CFA offset for the argument object? That way you still need unwind info and PC range tables, but you don't put any code into the function itself. This strategy was discussed at the ABI meetings; I think Intel was advocating it. We all agreed that it was a valid approach, but most of us thought that having the cleanups inline offered more optimization opportunities (code motion into the landing pad, jumping between cleanups, inlining destructors, not forcing the object into the stack). It might make sense to do this for C functions, though. It's somewhat more complicated to do this sort of thing with try/finally, since it allows an arbitrary block of code, not just a call, but the GOTO_SUBROUTINE_EXPR expansion of TRY_FINALLY_EXPR is a very similar idea. Jason