Re: Fix PR48542: reload register contents reuse crossing setjmp

["Ulrich Weigand" <uweigand@de.ibm.com>]

Hans-Peter Nilsson wrote:
> On Thu, 14 Jul 2011, Ulrich Weigand wrote:
> > 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).

Well, the way I see it is that "setjmp" ought to be using the
same ABI as regular function calls, whatever that is on any
platform.  The implementation of setjmp/longjmp then has to
take care to set up things so that, on the second return from
setjmp, the caller does not notice any differences, so that it
can use the same code to implement the call to setjmp as it
would to implement any other calls.

On many systems, this simply involves restoring the values of
all call-saved registers.  On systems with more complex ABI,
this might instead involve more complex operations like fiddlling
with a register stack / register windows to set them up so they
look as required to continue with a regular function return.

But whatever it is, all that "weirdness" ought to be confined
to within the implementation of setjmp / longjmp.


That said, you are right that there is existing code in GCC
that treats "setjmp" specially.  This is not just IRA, but in
fact all over the place: CSE, regstat, scheduler, ...

It appears all this is to handle the problem that at least on
some platforms, setjmp seems to violate the rules I thought
it was supposed to follow.  See e.g. the comment in CSE:

  /* Don't cse over a call to setjmp; on some machines (eg VAX)
     the regs restored by the longjmp come from a later time
     than the setjmp.  */

Now this is IMHO a bit unfortunate.  However, I agree that if
we do treat setjmp differently in some places, we need to do
so *everywhere*.

Given that, I withdraw my objection to the reload patch.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com