This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: new code for reorg.c


  In message <199812051237.MAA01759@htbrug.net.HCC.nl>you write:
  > Hello,
  > 
  > I genearted some new code for reorg.c to handle targets with more than
  > 1 delay slot. Currently only the c4x (3 delay slots) has these. I know
  > some one who is working on the sharc port (2 delay slots) for gcc that
  > also uses these patches.
  > I optimized the routine optimize_skip to handle more than 1 delay slot and
  > did the same for fill_eager_delay_slots.
  > I did test the new code with the torture tests and have used these new
  > functions for the last 2 months without problems.
Thanks!  This is something that's needed doing for a while.

  > 	(emit_delay_sequence) Allow SEQUENCE as input.
This seems wrong.  You should not be getting a sequence as the first arg to
emit_delay_sequence.  If you do, that indicates a problem elsewhere.

In optimize_skip you've got this code:


      next_active = next_active_insn (trial);
      if ((next_active == next_active_insn (JUMP_LABEL (insn)))
          || (next_active != 0
              && GET_CODE (next_active) == JUMP_INSN
              && JUMP_LABEL (insn) == JUMP_LABEL (next_active)
              && (simplejump_p (next_active)
                  || GET_CODE (PATTERN (next_active)) == RETURN)))
        {
          new_delay_list = add_to_delay_list (trial, new_delay_list);
          delay_list = new_delay_list;

          for (nslot = 0, list = delay_list; list; list = XEXP (list, 1))
            if (!eligible_for_annul_false (insn, nslot++, XEXP (list, 0),
                                           flags))
                break;

Doesn't this code lose if INSN already had some delay slots filled?  Note
that you initialize nslot to zero, not to the number of the first unfilled
slot.  If the nullification characteristics of the various delay slots are
different, this could lose.

It also seems to me like optimize_skip is suboptimal in some cases.

If you have multiple delay slots you (of course) want to try and fill them
all with this code.  But filling 2 of 3 can still be a win since it could
save you nops.

Let's assume we have a conditional jump with 3 delay slots that skips over
3 trial insns and that we can nullify delay slots when the branch is
taken.

Assume that the first two trial insns can be used to fill the first two
delay slots.  But for some reason the 3rd insn can not be used to fill the
last delay slot.

It seems to me that as written your code will return 0 in that case which
indicates that no delay slots were filled.

Can't you first verify that a trial can go into a delay slot.  If it can,
then you add it to "new_delay_list"?

Doing so would allow you to return new_delay_list instead of zero if you
ever encounter a trial insn you can put put into INSN's delay slot.

Or am I missing something important?

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]