From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27682 invoked by alias); 27 Nov 2003 09:21:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 27674 invoked from network); 27 Nov 2003 09:21:45 -0000 Received: from unknown (HELO nondot.org) (128.174.245.159) by sources.redhat.com with SMTP; 27 Nov 2003 09:21:45 -0000 Received: by nondot.org (Postfix, from userid 501) id BE41617C035; Thu, 27 Nov 2003 04:21:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by nondot.org (Postfix) with ESMTP id BAE6E24C299; Thu, 27 Nov 2003 03:21:54 -0600 (CST) Date: Thu, 27 Nov 2003 09:43:00 -0000 From: Chris Lattner To: Andrew Haley Cc: Zack Weinberg , , Jim Wilson , Subject: Re: avoid unnecessary register saves for setjmp In-Reply-To: <16325.49560.414002.838896@cuddles.cambridge.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-11/txt/msg02145.txt.bz2 On Thu, 27 Nov 2003, Andrew Haley wrote: > > Not at all. For example, somewhat confusingly, the LLVM->C backend > > actually turns "stack unwinding" operations into setjmp/longjmp > > calls. This is basically equivalent to SJLJ exception handling, > > with all of it's problems, but the point is that you don't _NEED_ > > to include an unwinder. > > Well, okay: the front end has turned sjlj into exceptions, and the > back end has turned it all back again. It _can_ turn it all back again. SJLJ is a horribly inefficient way to implement exceptions in a C++ type of world (lots of dtors to run, catch blocks, exception specs to check, etc). For C it's probably fine. > We get the advantage of better analysis in the middle. No problem > there; I am only referring to user-visible changes. As far as user visible changes, the biggest problem is the change in ABI. -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/