Re: RFC: mips SB-1 DFA scheduler

[Paul Koning <pkoning at equallogic dot com>]

I have a question that may be based on misunderstanding how the DFA
scheduling machinery works...

*************** mips_issue_rate (void)
*** 9347,9352 ****
--- 9412,9424 ----
      case PROCESSOR_R9000:
        return 2;
  
+     case PROCESSOR_SB1:
+       /* This is actually 4, but we get better performance if we claim 3.
+ 	 This is partly because of unwanted speculative code motion with the
+ 	 larger number, and partly because in most common cases we can't
+ 	 reach the theoretical max of 4.  */
+       return 3;
+ 
      default:
        return 1;
      }
*************** mips_use_dfa_pipeline_interface (void)
*** 9375,9380 ****
--- 9448,9533 ----
      }
  }
  
+ /* Implements TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHAED.  Return how
+    many instructions the scheduler should examine when trying to determine the
+    best packing of pending ready instructions into issue slots.  */
+ 
+ static int
+ mips_multipass_dfa_lookahead (void)
+ {
+   if (mips_tune == PROCESSOR_SB1)
+     return 4;
+ 
+   return 0;
+ }

If we have four issue slots to fill, don't we want to look ahead a
fair amount MORE than 4 insns to find the four that are the best
choices to issue right now?  (If that's not what this "lookahead"
thing is meant to do, its docs could stand some improvement.)  I
wonder if that accounts for the fact that you didn't see an
improvement with an issue_rate of 4, as one would expect.  Certainly
it isn't hard to fill all 4 issue slots in hand-written assembly code,
and the compiler really should be able to do as well.  To mention a
trivial example, a buffer checksumming loop should be able to use four
slots per cycle.

Out of curiosity, does this use any of the DFA scheduling work I did?
I guess it doesn't; looking back at what Chris posted a while back,
that was only the bare skeleton.

    paul