This is the mail archive of the
mailing list for the GCC project.
Re: avoid unnecessary register saves for setjmp
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Jim Wilson <wilson at specifixinc dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>, gcc-patches at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Date: Sat, 22 Nov 2003 14:36:56 +0000
- Subject: Re: avoid unnecessary register saves for setjmp
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> 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.
> > 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
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).
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).