Re: [RFA:] Fix PR target/{18329,18330}, incorrect deletion ofoutput-reload

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Mon, 10 Jan 2005, Richard Henderson wrote:
> On Sun, Jan 09, 2005 at 10:26:01AM -0500, Hans-Peter Nilsson wrote:
> > In global allocation, pseudo 278 gets allocated a stack slot, but as
> > memory is not valid for move to the return-address-register rJ, it is
> > reloaded into register 2, which happens to be valid and live unto the
> > death of pseudo 278 on the "straight" execution path.
>
> Is r2 call saved?  It's not usual to pick call-saved registers for
> reload registers, so something seems fishy to begin with.

Yes, it's call-saved and also a LOCAL_REGNO.  Perhaps that
explains your spider sense tingling (reload1.c:1.458:reload:682).
Hmm, no, that shouldn't matter at all.  I forgot to mention that
global allocation seems to exit early for functions with
current_function_has_nonlocal_label (exactly to avoid keeping
stuff in registers it seems) so reload gets to really show off
that it can inherit reloads across basic blocks.  Still...

Looking at and stepping through find_reg for this case shows
that it doesn't care about call-savedness, neither does the
initialization of spill_cost.  Ouch.  So what makes you say it
is not usual?  Is it because ports usually have call-saved-regs
last in REG_ALLOC_ORDER?

> If it is call saved, then this could be valid in the non-exception
> case.

Do you refer to validity of the patch, or the events before
execution arrives at the patch site?  The events should still be
valid for exception cases methinks.

> > If non-call-exceptions should be covered as well
> > (nonlocal-goto and calls should cover "normal C++" call-exceptions)...
>
> Yes, non-call exceptions would be a problem.  As would normal exceptions,
> which your test:
>
> > +       if (CALL_P (i1) && current_function_has_nonlocal_label)
>
> does *not* handle.

I seem to have mixed up use of the nonlocal_goto_receiver
pattern (in absence of exception_receiver) with the setting of
current_function_has_nonlocal_label.  Sorry.

Anyway, handling non-call-exceptions would be a separate case
(not triggered by any existing test-case), so would call for a
separate patch.

>  What ought to be happening is that all of this
> deletion nonsense needs to be cropped across basic block boundaries.
>
> We should be able to notice those, at least.

This would lead to pessimization (until there's a sane register
allocator with equally sane reload), for targets with unfew
registers but only for rare cases, assuming nonlocal-gotos are
rare everywhere (Ada too?)

Updated patch follows.

brgds, H-P