alpha sjlj exception handling

alpha sjlj exception handling

[Richard Henderson]

So I decided to track down some of the errors we get on Alpha with the
exception bits -- using sjlj still, since it is supposed to be using
the non-local goto support, it ought to work at least a little bit.

And I find that the generated code somehow expects the call-saved
registers to be preserved even though no one seems to save them.

From looking at what anyone is emitting, I would think at a non-local
goto label we would have to assume all registers except for the fp and
sp, which we restored getting back here, are dead. 

Where is this supposed to happen in the regular case of non-local goto?


r~

Re: alpha sjlj exception handling

[Jim Wilson]

	And I find that the generated code somehow expects the call-saved
	registers to be preserved even though no one seems to save them.

This problem might be related to the recent flow changes.

	Where is this supposed to happen in the regular case of non-local goto?

A function that is the target of a non-local goto will have the global variable
current_function_has_nonlocal_label set.  local-alloc/global/reload all know
that if this variable is set, then pseudos whose lifetime crosses a function
call must be handled specially.  I think this special treatment ends up
generating code in such a way that the call saved register problem goes away.
I am not sure if it is because they are somehow saved/restore though, or
whether they somehow avoid using the registers when they won't be saved and
restored.  The builtin setjmp code does not set this variable.

Another consideration here, there is a bit of special code in reload that
handles the NOTE_INSN_SETJMP that used to be generated by the builtin setjmp
code.  The code looks suspicious to me, but perhaps it was doing something
important that needs to be reimplemented some other way.

Jim

Re: alpha sjlj exception handling

[Jeffrey A Law]

  In message < 199711072009.MAA10173@cygnus.com >you write:
  > 	Where is this supposed to happen in the regular case of non-local goto?
  > 
  > A function that is the target of a non-local goto will have the global variable
  > current_function_has_nonlocal_label set.  local-alloc/global/reload all know
  > that if this variable is set, then pseudos whose lifetime crosses a function
  > call must be handled specially.
Correct.

This happens in local-alloc.c:find_free_reg

  /* Don't let a pseudo live in a reg across a function call
     if we might get a nonlocal goto.  */
  if (current_function_has_nonlocal_label
      && qty_n_calls_crossed[qty] > 0)
    return -1;

I assume global & reload have similar checks.


I brought up the question about call clobbered regs and their interaction
with the EH code and Kenner said it "couldn't happen" and he refused to
elaborate why.  Note this was with our old unwinder code, not sjlj exceptions.

I note that we now set current_function_has_nonlocal_label inside some
of our dwarf code for exception handling.  So for normal EH this problem
has been "solved".

However, I doubt it's been fixed for sjlj exceptions; seems to me if you
set current_function_has_nonlocal_label for sjlj exceptions then you should
be OK.

I would think it could be set unconditionally if EH is being used for now --
in the future we might consider turning it off if none of the EH regions
are actually used.


jeff

Re: alpha sjlj exception handling

[Jason Merrill]

>>>>> Jeffrey A Law <law@cygnus.com> writes:

> I brought up the question about call clobbered regs and their interaction
> with the EH code and Kenner said it "couldn't happen" and he refused to
> elaborate why.

Probably because GNAT doesn't let anything defined ouside of a catch block
and used inside live in a register.

Jason