From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1211 invoked by alias); 7 May 2003 23:01:39 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 1179 invoked from network); 7 May 2003 23:01:38 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 7 May 2003 23:01:38 -0000 Received: from prospero.boston.redhat.com (sebastian-int.corp.redhat.com [172.16.52.221]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h47N1bi03701; Wed, 7 May 2003 19:01:37 -0400 Received: by prospero.boston.redhat.com (Postfix, from userid 4046) id 6E49FF8EB7; Wed, 7 May 2003 19:01:38 -0400 (EDT) To: Mark Mitchell Cc: gcc@gcc.gnu.org, Jason Merrill Subject: Re: __attribute__((cleanup(function)) versus try/finally From: Jason Merrill In-Reply-To: <1052345885.5665.64.camel@doubledemon.codesourcery.com> (Mark Mitchell's message of "07 May 2003 15:18:01 -0700") References: <1052245742.2583.315.camel@doubledemon.codesourcery.com> <1052249890.31850.338.camel@doubledemon.codesourcery.com> <1052256289.2583.412.camel@doubledemon.codesourcery.com> <1052345885.5665.64.camel@doubledemon.codesourcery.com> Date: Wed, 07 May 2003 23:01:00 -0000 Message-ID: User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg00724.txt.bz2 On 07 May 2003 15:18:01 -0700, Mark Mitchell wrote: > Now, with my scheme this function has no handler code; i.e, the EH > run-time library will never transfer control back to this function. Yes. With the alternative look-aside optimization I mentioned, the same would be true. And it wouldn't even require a library call to register the cleanup. > Even when using setjmp/longjmp the cost is just one setjmp at the start > of the function, so that the stack can be unwound. I think the longjmp_unwind scheme uses multiple setjmps, though I'm not sure; it doesn't have the benefit of the whole-function analysis that the compiler can do when inserting EH code. > If pthread_cleanup_push uses try/finally, it's my understanding that > there will be multiple calls to setjmp, before each of the calls to g. I'm pretty sure there's just one at the beginning of the function, emitted if needed. The parallel look-aside optimization for the setjmp case could be to register EH cleanups via a call into the EH runtime much like pthread_cleanup_push; this would avoid the need for any setjmps if a function only has cleanups. > And in the non-setjmp case, there will be landing pads and unwind > information for each of the exception regions, rather than just one for > the entire function. Landing pads, yes, but they're just one instruction unless an optimizer has moved code there, in which case it's presumably beneficial. Unwind info is always per-function. There is, however, an entry in the LSDA for each region, typically 4 bytes in a small function. The look-aside optimization would make this larger, of course. > Adding EH to C is a very dramatic change. The spirit of C is "no hidden > stuff." Calling exceptions "zero-cost" is a lie; we say that because > they require no additional instructions be executed unless an exception > is thrown, not because they actually have no cost. The unwind tables > are a significant cost, for example. Significant, but not unreasonable IMO. As I mentioned, Irix and Tru64 always emit them. We always emit them for S/390 and x86-64. Always emitting them for pthreads code seems appropriate to me, and much easier than creating a whole new system to deal with what is basically an already solved problem. > To that end, I've toyed with the following idea: > > - When building a library written in C, provide two sets of entry points > for the globally visible functions >[...] This sounds like a rather heavy weight solution to this problem. I'd much rather re-use mechanisms we already have. > This kind of solution is awfully attractive if you're on an embedded > system. (I want pthreads on my cell-phone, but I sure don't want to have > extra unwind info around. I want to be able to support C++, but if it's > not in use, I don't want to have to pay the cost of supporting C++ by my > making my C libraries bigger.) Then you probably want to use setjmp/longjmp exceptions. With the optimization described above, it would be no more expensive than the old mechanism. Jason