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]
Other format: [Raw text]

Minor PPro/P2/P3 scheduling fixes



[ Richard -- these are the two buglets I mentioned in the hallway last
  week.  For various reasons I went ahead and tracked them down. ]

While working on the DFA scheduler for the PPro/P2/P3 pipelines I ran into
cases where we had multiple insns in the ready queue which did not have
functional conflicts and which should all be able to decode together in
the 4:1:1 template for the PPro/P2/P3.  Yet the insns would not issue
together.

There are two underlying problems.

First let's consider what happens in ix86_sched_reorder when there is only one
instruction in the ready queue:

  if (n_ready < 2)
    goto out;
[ ... ]
out:
  return ix86_issue_rate ();

Note this will not call ix86_sched_reorder_ppro as it seems rather pointless
to do so.  Unfortunately, skipping the call to ix86_sched_reorder_ppro
results in ix86_sched_data.ppro.issued_this_cycle not being initialized
properly.  it, it'll have the value zero the first time this happens.

Now let's look at what happens in ix86_variable_issue:

    case PROCESSOR_PENTIUMPRO:
    {
    [ ... ]
    }

    return --ix86_sched_data.ppro.issued_this_cycle
    

This results in returning a negative value from ix86_variable_issue, definitely
not a good thing.  If only one insn goes into the ready queue the next cycle,
then ix86_sched_data.ppro.issued_this_cycle just keeps getting a more negative
value.  Whee, fun.  Easily fixed.

The second issue is a typo/thinko in ix86_sched_reorder_ppro.  Let's assume
that there are two insns in the ready queue.  The key variables to look at
are READY and E_READY which are passed in via ix86_sched_reorder. 

READY is the head of the ready queue.  We compute E_READY via:

  rtx *e_ready = ready + n_ready - 1;

The key thing to realize is that if e_ready == ready, then there is precisely
one insn in the ready queue, if e_ready < ready, then there are no insns in
the ready queue.

Now examine this code in ix86_sched_reorder_ppro:

        if (ready >= e_ready)
          goto ppro_done;

Yow!  This causes is to ignore one insn in the ready queue when trying
to pack intructions.



Bootstrapped and regression tested on x86-linux.  Installed into the mainline
sources.

	* i386.c (ix86_sched_reorder_ppro): Fix typo/thinko.
	(ix86_sched_reorder): Make sure to initialize scheduling
	data even when there's only one insn in the ready queue.

Index: i386.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.402
diff -c -3 -p -r1.402 i386.c
*** i386.c	19 May 2002 09:50:19 -0000	1.402
--- i386.c	21 May 2002 23:41:16 -0000
*************** ix86_sched_reorder_ppro (ready, e_ready)
*** 10404,10410 ****
    for (i = 1; i < 3; ++i)
      if (decode[i] == NULL)
        {
! 	if (ready >= e_ready)
  	  goto ppro_done;
  
  	insnp = e_ready;
--- 10404,10410 ----
    for (i = 1; i < 3; ++i)
      if (decode[i] == NULL)
        {
! 	if (ready > e_ready)
  	  goto ppro_done;
  
  	insnp = e_ready;
*************** ix86_sched_reorder (dump, sched_verbose,
*** 10448,10455 ****
    int n_ready = *n_readyp;
    rtx *e_ready = ready + n_ready - 1;
  
    if (n_ready < 2)
!     goto out;
  
    switch (ix86_cpu)
      {
--- 10448,10461 ----
    int n_ready = *n_readyp;
    rtx *e_ready = ready + n_ready - 1;
  
+   /* Make sure to go ahead and initialize key items in 
+      ix86_sched_data if we are not going to bother trying to
+      reorder the ready queue.  */
    if (n_ready < 2)
!     {
!       ix86_sched_data.ppro.issued_this_cycle = 1;
!       goto out;
!     }
  
    switch (ix86_cpu)
      {
















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