Re: avoid unnecessary register saves for setjmp

[Jim Wilson <wilson@specifixinc.com>]

On Fri, 2003-11-21 at 09:55, Daniel Jacobowitz wrote:
> I recently spent some time investigating this same code.  I was working
> on an ARM target with the iWMMXt extension set, which includes a number
> of additional registers.  The existing setjmp implementation on that
> target did not save them, but things worked anyway; I dug, and this was
> how.

We could perhaps use NON_SAVING_SETJMP for this, but I think fixing
setjmp is a better solution.  Assuming it needs to save any of the
iWMMXt registers.

> Speaking of Altivec, at least the GNU/Linux glibc setjmp implementation
> doesn't save Altivec registers either.  I posted a patch for this about
> three years ago and it was never incorporated.  So we may see problems
> reported from that side.

PR 12817 is from people asking gcc to not save the altivec registers
around setjmp, because it isn't supposed to.  So at least some PowerPC
folks believe that this register saving is wrong.

> I discussed this on IRC with a few people; I don't remember who all of
> them were, but definitely including H-P.  My conclusion from the
> discussion was that the setjmp standard library function is _not_
> mandated by C99 to save all registers.  I do not know of any psABI
> documents which specify the saved registers either.  So I am a little
> uncomfortable with your patch.

Yes, setjmp is not required to save registers.  Gcc knows this, and
avoids allocating pseudos to registers if the pseudo lives across a
setjmp.  We don't need to save unused registers to make this work.
Also, keep in mind that gcc versions from 1.0 to 3.0.4 did not do this
extra saving, and setjmp worked fine for them.  Users have to use
volatile if they want a local variable to live across a setjmp call.

> Er... actually, upon second inspection, the code I was referring to was
> regs_live_at_setjmp in flow.c.  I'm not sure whether the code you are
> removing from reload1.c will change the behavior I describe, after
> all.

This code isn't affected by my patch.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com