Fwd: Questions on PA machine description?

[Jeffrey A Law]

  In message < 36F811ED.32912006@americasm01.nt.com >you write:
  > I started trying to look at the haifa_sched.c file.  I can't really see
  > where insns dependent on the current one in the ready queue are
  > removed.  I'm looking in the loop on ready[] in schedule_block().  My
  > guess is that somehow schedule_insn does this, but I'm not sure.
Yes.

schedule_insn walks over the INSN_DEPEND list and decrements the dependency
count for all the instructions which are dependent on INSN.  If the dependency
count goes to zero, then the dependent insn is added to the ready queue.

  for (link = INSN_DEPEND (insn); link != 0; link = XEXP (link, 1))
    {
      rtx next = XEXP (link, 0);
      int cost = insn_cost (insn, link, next);

      INSN_TICK (next) = MAX (INSN_TICK (next), clock + cost);

      if ((INSN_DEP_COUNT (next) -= 1) == 0)
	{
[ ... ]
          /* Adjust the priority of NEXT and either put it on the ready
             list or queue it.  */
          adjust_priority (next);
          if (effective_cost <= 1)
            ready[n_ready++] = next;
          else
            queue_insn (next, effective_cost);
	}

  > My first thought is that instead of removing dependent instructions from
  > ready to insn_queue, move them to a temporary queue when the delay
  > (cost?) is 0.  Then, if the ready queue is empty but can_issue_more is
  > still live, pull one insn from the temp queue.  Repeat this second loop
  > until can_issue_more is empty or the temp queue is empty.  The return
  > everything else back to the insn_queue.
I think we'd be better off going ahead and adding stuff to the ready queue,
even if there are some insns in the ready queue.  The more insns we expose to
the scheduler as ready, the better.

Consider targets which allow sethi/lo_sum instructions (which have a
dependency) to issue together (hypersparc & PA8000 come to mind).  If we
have such a pair, we want to go ahead and issue them together, even if there
are other insns in the ready queue.  We know they will fire together and it
also minimizes the lifetime of the temporary holding the output form the sethi
instrution (which is important on the PA since there's only one register which
can hold the value from a sethi).


  > I may just be babbling.  Does this make any sense?  How is the ready
  > queue sorted?
SCHED_SORT, then MD_SCHED_REORDER

The generic sorting algorithm is in rank_for_schedule.  targets can override
the default sort via MD_SCHED_REORDER.

jeff