Re: avoid unnecessary register saves for setjmp

[Richard Earnshaw <rearnsha@arm.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
> restored.

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).

R.