From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20961 invoked by alias); 27 Nov 2003 19:59:00 -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 20954 invoked from network); 27 Nov 2003 19:58:59 -0000 Received: from unknown (HELO nondot.org) (128.174.245.159) by sources.redhat.com with SMTP; 27 Nov 2003 19:58:59 -0000 Received: by nondot.org (Postfix, from userid 501) id 12D7717C035; Thu, 27 Nov 2003 14:59:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by nondot.org (Postfix) with ESMTP id 0FB5924C29A; Thu, 27 Nov 2003 13:59:12 -0600 (CST) Date: Thu, 27 Nov 2003 20:44:00 -0000 From: Chris Lattner To: Jan Vroonhof Cc: gcc-patches@gcc.gnu.org Subject: Re: avoid unnecessary register saves for setjmp In-Reply-To: <5cad8ef043da68f2a3332f00bd6a186a3fc6195b@mail.esmertec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-11/txt/msg02188.txt.bz2 > >> To be fair, an argument against this change is that it would break > >> code that uses setjmp and longjmp to implement coroutine linkage. > >> (The set/get/make/swapcontext calls are better for this, but that > >> doesn't mean everyone uses them.) > > Doesn't it also convert longjmp from an O(1) in to an O(nr off stack frames) > operation? Yes, if you use unwinding to implement it. You can obviously use SJLJ to implement the exception runtime, retaining the same complexity. The normal design decision is to favor non-exceptional control flow, even if that means changing exception throws to take O(n). In practice, stack unwinding is still very fast. > > I don't believe that this is actually legal ANSI C. You can only return > > to a place that has been setjmp'd to, there is no way to 'construct' a > > jmpbuf. Likewise, you cannot setjmp, return from the setjmp'ing function, > > then longjmp back to the 'dead' jmpbuf. > > It might not be ANSI C, but it does work on most systems for user > level threading (essentially implementing swapcontext by direct > manipulation of the jmbuf). There is lots of useful things people do > with C that are not strictly ANSI/ISO C. In fact that kind of low > level control is often exactly the reason to use C in the first place. As Zach said, they should be using getcontext/swapcontext/makecontext. jmpbuf's do not hold the entire register state for the processor. -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/