This is the mail archive of the gcc@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]

Re: issues with first scheduling pass on SH4


> I am planning to use something like INSN_REG_WEIGHT
> to keep a count of register pressure. When this reaches
> a threshold, check if an insn which reduces the register pressure
> can be selected from the ready queue (R). If there is no such insn
> in the ready queue then probably such an insn can be
> selected from the stalled queue (Q), because in some cases it is
> cheaper to take a few stalls than spilling e.g DFmode values for

We have recently also experimented with scheduling instructions
directly from the stalled queue (Q) instead of the ready
queue (R) (to solve a different problem though). Following is
a general description of what we did.
The specific context we're dealing with is given at the end.

The current structure of schedule_block() (haifa-sched.c) is roughly:

0 while(there are unscheduled insns in block){
1  - do{
       advance_one_cycle();
      Q->R;
     }while(ready list is empty);
2  - ready_sort();
3  - for (;;){
4     - if (ready.n_ready == 0 || !can_issue_more || ...) break;
5     - insn <- choose_ready();
6        cost <- state_transition(insn) (and other checks);
7     - if(cost >= 1) continue;
8     - advance = schedule_insn(insn);
9     - ready_sort();
10   }
11  - ....
12 }

We made the following two changes:

1. Added in schedule_block() a (conditional) call to a function
that selectively moves insns from Q to R:

1- if (condition1)
2-   early_queue_to_ready();

The above code can be inserted either (1) when R becomes empty,
right before giving up on scheduling additional instructions
in the current cycle (i.e. before line 4),
or (2) whenever new instructions maybe added into R,
before R is sorted (before lines 2 and 9).

The "condition1" can be, in your case, something like:
  (!reload_completed && INSN_REG_WEIGHT > threshold)

2. Implemented early_queue_to_ready():

1- for (insn = scan the queue in-order; ... ; ...){
2   - cost <- state_transition(insn) (and other checks);
3   - if (cost < 0 && ok_for_early_schedule(insn)){
4     - remove insn from Q, and add it to the ready list.
5     - if (condition2)
6          break;
7     }
8   }

(line 2 should be identical to line 6 in schedule_block() above,
to avoid creating an infinite R->Q->R... loop).
The "ok_for_early_schedule(insn)" can check, in your case,
if insn reduces high register pressure.
The "condition2" can restrict the number of instructions removed
from the queue to one at a time, or more if desired.

The idea is that the R&Q lists hold the insns ordered according to
latency/critical-path considerations, which are still important,
but we want to override them occasionally (in case (2) above, or fill
potentially "vacant" slots in case (1)) with some "premature"
but "important" insns.

Maybe this general scheme could fit your purposes too?

dorit


The problem we are trying to solve is in the context of the rs6000
port of gcc; we want to allow the scheduler to schedule additional
insns in the "current" cycle (except for "costly" dependent queued insns),
in order to better match the groups formed by the instruction dispatcher
in the processor. In our case, the "condition1" is:
  (reload_completed && ready.n_ready == 0 && can_issue_more)
and our implementation for "ok_for_early_schdule(insn)" checks
that the queued insn is not "costly dependent" upon "recently"
scheduled instructions; "costly dependences" are determined by
a target specific hook, and "recently scheduled" can be controlled
by a flag.
Hopefully we'll submit the full patch soon ...


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