Fix PR48542: reload register contents reuse crossing setjmp

[Hans-Peter Nilsson]

On Thu, 14 Jul 2011, Ulrich Weigand wrote:
> Jeff Law wrote:
> > On 06/15/11 21:46, Hans-Peter Nilsson wrote:
> > > 	PR rtl-optimization/48542
> > > 	* reload.c (find_equiv_reg): Stop looking when finding a
> > > 	setjmp-type call.
> > > 	* reload1.c (reload_as_needed): Invalidate all reload
> > > 	registers when crossing a setjmp-type call.
> > OK.
> > Jeff
>
> I see that this went already in, but I'm wondering why this
> change should be necessary.  As far as register use is
> concerned, setjmp ought to behave just like a regular function:
> if a register is call-clobbered, reload will not attempt to
> use it across a function call (*any* function call) anyway;
> but if the register is call-saved, setjmp really ought to
> restore the old value, *both* times it returns, and so reuse
> ought to be allowed ...

First of all, if this changes (back) in reload, then it should
change in IRA too.

Right; you do have a point.  I *think* my excuse would be that I
stopped thinking further when I saw that IRA doesn't allocate
registers across setjmp.

Changing this will make a difference for architectures (ABIs)
that don't save call-saved registers in the prologue but rather
for each call.  Crazy and suboptimal?  Not if you use register
windows or a register stack where you just (automatically as
part of the call insn or sequence) update a register number or
pointer for the call "save".  So MMIX is one, I guess sparc and
ia64 could be others, it seems so at a glance.  It all depends
on their setjmp/longjmp implementations of course, I don't have
the whole picture.

If you change this, such ports will then have to handle calls to
setjmp differently to other functions; not call-save across
those setjmp calls or else the call-saved register will be
picked up instead of the one saved at setjmp (restored at
longjmp).

The difference would be better code across calls to setjmp (and
related secondary effects in the setjmp-calling function) for
everyone else, but what is in place with the committed patch now
*is* consistent and correct and not needing special handling
regarding register-saving, AFAICT.

brgds, H-P