From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4171 invoked by alias); 22 Nov 2003 16:26:57 -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 4160 invoked from network); 22 Nov 2003 16:26:55 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 22 Nov 2003 16:26:55 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1ANab0-0001ba-2K; Sat, 22 Nov 2003 11:26:54 -0500 Date: Sat, 22 Nov 2003 16:33:00 -0000 From: Daniel Jacobowitz To: Richard.Earnshaw@arm.com Cc: Jim Wilson , gcc-patches@gcc.gnu.org Subject: Re: avoid unnecessary register saves for setjmp Message-ID: <20031122162654.GA6032@nevyn.them.org> Mail-Followup-To: Richard.Earnshaw@arm.com, Jim Wilson , gcc-patches@gcc.gnu.org References: <1069490758.1024.191.camel@leaf.tuliptree.org> <200311221436.hAMEauN16800@pc960.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311221436.hAMEauN16800@pc960.cambridge.arm.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-11/txt/msg01824.txt.bz2 On Sat, Nov 22, 2003 at 02:36:56PM +0000, Richard Earnshaw wrote: > > On Fri, 2003-11-21 at 19:08, Daniel Jacobowitz wrote: > > > Here's the difficulty: changing the size of jmp_buf. > > > > That is a good point. Still, we shouldn't penalize targets that have > > defined setjmp correctly. So I suggest using NON_SAVING_SETJMP for > > this. This will do what you want if you define it for your target. > > I'll go ahead and fix NON_SAVING_SETJMP to make it usable. If we do do this, is it relatively easy to make it a runtime switch instead? This would depend on compiler options. > > > Sure - but that assumes that all unused call-saved registers are > > > restored by the setjmp. So then it is required to save registers to > > > get reasonable behavior. > > > > You are confusing two different issues here. setjmp is not required to > > restore call-used registers. Thus any value stored in a register in > > this function may not be restored when longjmp is called. This is why > > the C language standard says that local automatic non-volatile variables > > may not be restored by longjmp. However, setjmp is required to restore > > the original context, and that means call-saved registers must be > > restored. A setjmp call is not allowed to clobber locals in the parent > > function, which is what would happen if call-saved registers were not > > restored. But, as in many things, the division of labor between the compiler's emitted call to setjmp and the setjmp implementation is weakly specified. which is an array type suitable for holding the information needed to restore a calling environment. The environment of a call to the setjmp macro consists of information sufficient for a call to the longjmp function to return execution to the correct block and invocation of that block, were it called recursively. It does not include the state of the floating-point status flags, of open files, or of any other component of the abstract machine. A setjmp which saves just a minimal number of registers in the jmp_buf and runtime code which restores them from the stack if setjmp returns non-zero, would satisfy the standard. At least that's my reading; it may well be wrong. > In the EABI we've been developing for the ARM we've been very careful to > say that only the setjmp and longjmp functions can know the contents and > layout of a jmp_buf. This allows a function to use co-processor registers > that are call saved and to be used in the middle of a call sequence > without upsetting any other conforming code. Hence only the C library > needs to know the list of co-processors that are in use (and it is > entitled to enter into other private conspiracies to determine the > registers that need to be saved. We've even designed the EH > implementation in a way that will allow this to work as well (the unwinder > will only try to execute instructions to access a particular co-processor > once it has found a description of that co-processor in the unwind list). How do you intend to implement this in practice? I'm not concerned with the contents or layout of a jmp_buf; conforming programs can't get at them. But user programs declare jmp_buf, which implies that they know its size. And there's no way I can think of to dynamically allocate additional space if the jmp_buf is insufficiently large. Are you simply defining a very large jmp_buf for expansion? This is the problem I encountered on both PowerPC and ARM. I'm very curious to hear any solutions to it. > IMO gcc should not be trying to second guess the complete set of registers > that a setjmp/longjmp pair need to save and restore. In otherwords we > should not be building in setjmp and longjmp (in any case, it's likely on > ARM that the library function will be more efficient, since it can use > load and store multiple instructions). For new ABIs this is well and good. For something like Altivec being added to existing GNU/Linux systems, it's dramatically less good. Right now we either waste performance (before this patch) or violate the Motorola specifications on which registers should be saved (after) because the system library does not have room for Altivec in its jmp_buf. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer