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

[Ulrich Weigand <uweigand at de dot ibm dot com>]

I wrote:

> I've needed the following changes to build the C compiler and run its
> test suite without regressions on s390; I haven't attempted bootstrap or
> the other languages yet.

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.)

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:

      if (! noninherited_use && this->next_same == last)
        {
          if ((this->rli->type == RLI_OUTPUTRELOAD
               && GET_CODE (rl->out_reg) != REG)
              || (this->rli->type == RLI_INPUTRELOAD
                  && ! find_regno_note (this->chain->insn, REG_DEAD,
                                        REGNO (head_rtx))
                  && ! (last && sets_full_reg_p (last))))
            noninherited_use = 1;

+      if (! noninherited_use && last)
+        for (chain = this->chain; chain != last->chain; chain = chain->next)
+          if (GET_CODE (chain->insn) == JUMP_INSN)
+            noninherited_use = 1;
        }

We can only delete the output reload if the whole chain from it to
'last' (which destroys the value) contains no jump; the preceding
code checked this property only up to 'this'.


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:

      if (is_output == 0)
        {
          add_feed (reload_in_insn, rli);
          if (rl->scanned_input)
            return;
          if (! just_mark)
            rl->scanned_input = 1;
          if (rl->optional)
            {
              scan_rtx (chain, &contents, 0, reload_in_insn, 0, 0, 1);
              scan_rtx (chain, &contents, 0, rli, 0, 0, 1);
            }
          else
            scan_rtx (chain, &rl->in, 0, reload_in_insn, 0, 0, 1);
        }
      else
        {
          rl->reginfo.earlyclobber |= is_output == 2;
          add_feed (rli, reload_out_insn);
          if (rl->scanned_output)
            return;
          if (! just_mark)
            rl->scanned_output = 1;
          if (rl->optional)
            {
              scan_rtx (chain, &contents, is_output, reload_out_insn, 0, 0, 1);
              scan_rtx (chain, &contents, is_output, rli, 0, 0, 1);
            }
          else
            scan_rtx (chain, &rl->out, is_output, reload_out_insn, 0, 0, 1);
        }

(I'm wondering what exactly the difference between contents and rl->out means ...)

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?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  Linux on zSeries Development
  Ulrich.Weigand@de.ibm.com