Peter Steinmetz <[EMAIL PROTECTED]> writes:

> Currently, within the ready_sort macro in haifa-sched.c, the call to qsort
> is passed "rank_for_schedule" to help it decide which of two instructions
> should be placed further towards the front of the ready list.
> Rank_for_schedule uses a set of ordered heuristics (rank, priority, etc.)
> to make this decision.  The set of heuristics is fixed for all target
> machines.
> 
> There can be cases, however, where a target machine may want to define
> heuristics driven by specific characteristics of that machine.  Those
> heuristics may be meaningless on other targets.
> 
> Likewise, a given target machine may prefer a different order in which to
> check the heuristics, possibly going as far as checking them in a different
> order based on which pass of the scheduler is running.
> 
> I'd be interested in seeing "rank_for_schedule" converted into a scheduler
> target hook.  Target machines would then have the flexibility to define
> further heuristics for determining sort order.  The default for an
> undefined hook would be to use the current algorithm,
> 
> One could go a step further and break each heuristic out into a separate
> function.  This would allow target machines to specify to the scheduler a
> list of which heuristics to apply and an order in which to apply them.  A
> target machine could also define its own heuristic functions and include
> them in the heuristic ordering for that target.  In addition, a different
> set of heuristics, or a different ordering could be applied based on which
> pass of the scheduler is running.
> 
> I'd like to start experimenting with this, but would appreciate any
> comments or suggestions from others that may be familiar with this code.

This seems like a good idea to me.

In the past, I've changed the code to track register pressure as it
goes along, and rank by register pressure ahead of priority when the
pressure was getting close to the number of available registers.  This
gave me good results on XScale.  I never got around to tracking
register pressure by register class, though.  On x86 it might be
interesting to enable to first scheduling pass but to always use
register pressure first when ranking instructions.

I'll note that although this wasn't a difficult change, the harder
part was not in rank_for_schedule, it was in updating the register
pressure information for the other instructions after choosing an
instruction in which the register formerly died, but after the
rearrangement was now used by a later instruction.

Ian

Reply via email to