From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20836 invoked by alias); 27 Nov 2003 09:06:12 -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 20829 invoked from network); 27 Nov 2003 09:06:10 -0000 Received: from unknown (HELO nondot.org) (128.174.245.159) by sources.redhat.com with SMTP; 27 Nov 2003 09:06:10 -0000 Received: by nondot.org (Postfix, from userid 501) id E10BD17C035; Thu, 27 Nov 2003 04:06:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by nondot.org (Postfix) with ESMTP id D568A24C299; Thu, 27 Nov 2003 03:06:19 -0600 (CST) Date: Thu, 27 Nov 2003 09:19:00 -0000 From: Chris Lattner To: Zack Weinberg Cc: Richard.Earnshaw@arm.com, Jim Wilson , Subject: Re: avoid unnecessary register saves for setjmp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-11/txt/msg02141.txt.bz2 Zack Weinberg said: > I'm going to take this opportunity to throw in a suggestion I've made > before, which is that setjmp/longjmp should - always, not just when > special variants are used - be converted by the front end into > invocations of the exception-unwinding facility, which gives us tons > more control. This is exactly what we do in LLVM, which makes a lot of things much nicer. For example, because it uses the normal EH facilities in LLVM, inlining a longjmp'ing function into the setjmp'ing function automatically turns the stack unwinding operation into a direct branch, same as normal EH. This allows us to do aggressive optimizations on both the setjmp'ing and longjmp'ing functions: there are no special cases needed or optimizations disabled. The only negative of doing this is that it adds a lot of edges to the CFG's of some functions, but you have to represent the possible control flow SOMEHOW. :) Also, the normal LLVM EH pruner automatically deletes the edges from function calls that provably cannot unwind, so it gets rid of a lot of the problem. Just food for thought, -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/