Re: What to do with new-ra for GCC 4.0

[bernds_cb1 at t-online dot de (Bernd Schmidt)]

Ulrich Weigand wrote:
> With two more problems fixed (not counting a couple of trivial warning
> fixes to get by -Werror), I can now bootstrap the C compiler on both
> s390 and s390x.  (Full bootstrap/regtest with all languages is still
> in progress.)

Great.

> The first problem is yet another too-eager removal of output reloads
> in the inheritance code; I fixed this by adding in inherit_one_chain:

Yes, I stumbled across this one myself yesterday while trying to debug 
the i386 bootstrap failure.  I have a vague feeling of deja vu with some 
of these bugs; I think the most advanced version of this code was eaten 
by a harddisk crash a few years ago :-(
I wonder if it would be sufficient just to check for REG_DEAD notes.  If 
those are accurate, all the other code could just go away.

> The second problem occurs in the situation where an insn has only an
> optional output reload, and an address reload for that output reload.
> In this case, if the optional reload is disabled, the address reload
> is required in the main insn.

> However, since scan_rtx counts the address reload as feeding only
> into the output reload, the address reload gets assigned an order
> that lies *after* the main insn.  Unfortunately this causes 
> emit_reload_insns to actually *emit* the address reload *after*
> the main insn, even if the optional reload was disabled ...
>
> I'm not exactly sure what the proper fix is.  My current solution
> that appears to work is to change scan_rtx so that such reloads
> count as feeding *both* the main insn and the optional reload,
> like so:

I seem to recall this problem as well, but I'm not entirely sure how 
best to fix it.  The underlying problem is that enabling or disabling 
optional reloads can change register lifetimes.  Putting reload insns in 
the wrong place is one symptom, making an existing allocation invalid 
could be another.  Your patch probably fixes the first, but at the 
expense of potentially suboptimal code generation (if the optional 
reload is enabled, the address reload should be put after the main 
insn).  I think enable/disable_optional are probably too simpleminded in 
their current form.

> B.t.w. I noticed that find_reloads generates a whole lot of optional reloads
> of class NO_REGS.  All these must be ignored as no register can satisfy then,
> so I wonder why they should be generated in the first place.  The unreloaded_uses
> mechanism should handle these cases even in the absence of a reload, right?

That's probably better, yes.

Thanks for all your help.  I've made a new diff; to avoid spamming the 
lists with huge patches I've put it up on
  http://www.electronghost.co.uk/~bernds
The new version should correct most of the problems you reported, plus 
one or two other ones.  Let me know how this one works for you.


Bernd