Add machine_dependent_reorg2

[Richard Sandiford]

law@redhat.com writes:
> In message <wvnel1h6clf.fsf@talisman.cambridge.redhat.com>, Richard Sandiford writes:
>  >law@redhat.com writes:
>  >> And we can't do this like every other port during assembly output because?
>  >
>  >"Every other port"? ;)  I thought nop-inserting assemblers were
>  >the exception rather than the rule.
> During assembly output, not by the assembler :-)

Doh!  Sorry for not reading what was there...

>  >But the motivation in this case is to get a better idea about
>  >instruction alignment.  There are targets for which it is more
>  >efficient to align branch insns.  And there are targets that
>  >can only dual issue insns when the first one is 8-byte aligned.
>  >
>  >If we knew what alignment instructions had, we could do
>  >something like align_align_insns().
> Seems to me you could actually do this in reorg.

Like Richard said, the problem is that dbr happens after the existing
mdr pass.  Some ports (sh I think) rely on that.  The mips16 mdr
optimisations are probably best done before dbr as well, even though
we only have call slots to fill in that case.

So the patch I posted added a second reorg pass that gets run
after dbr.  The alternative suggestions so far have been:

  - add target hooks like:

      void (*before_pass) (enum dump_file_index);
      void (*after_pass) (enum dump_file_index);

    which both of you seemed to think might bite back later.  And I can
    understand that. ;)

  - call dbr_schedule from with the mips reorg, like ia64 does for sched2:

      int mips_flag_delayed_branch;

      override_options ()
      {
        ...
        mips_flag_delayed_branch = flag_delayed_branch;
        flag_delayed_branch = 0;
        ...
      }

      mips_reorg ()
      {
        ... pre dbr stuff ...
        if (mips_flag_delayed_branch)
          dbr_schedule (...);
        ... post dbr stuff ...
      }

My main concern with the second idea is that any other port which
wants a post-dbr reorg will have to pull the same trick.  ISTR seeing
an sh patch from Alex that did some constant pool stuff after dbr.

I'm happy to do it the second way though if that seems best.

> I'm assuming that all the other wonderful things the MIPS assembler does
> to your code are somehow being avoided (.nomacro .noreorder?)   Otherwise
> your work will largely go to waste when the assembler gets started.

Right.  If a function doesn't contain inline asm, we'd put the whole
thing in noreorder/nomacro.

Richard