This is the mail archive of the 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: Patch for AMD Dispatch Scheduler

On 08/12/2010 08:27 PM, reza yazdani wrote:
Dispatch scheduling is a new BD feature. It is composed of two parts: the scheduling part and the alignment part.

The scheduling part (this patch) arranges instructions to maximize the throughput of the hardware dispatcher. It makes sure dispatch widow boundaries are roughly observed. It is roughly, because the lengths of instructions, in number of bytes, are not known at the scheduling time. In x86 some instruction lengths may not be known until assembly time where information such as branch offsets are computed. Scheduling part is called once before register allocation and once after register allocation.

The alignment part (not in this patch) makes sure dispatch widows align at the correct boundaries.

Dispatch Scheduling is implemented as an extension to Haifa Scheduler pass. Scheduler is programed to follow x86-BD dispatching rules during the scheduling.

  I thought about this patch for a long time.  The insn scheduler is
very machine-dependent pass and it is hard to use the same model for
so different targets.  The insn scheduler reached a point where it has
too many hooks some of them is duplicated.  We need to do some work to
decrease number of hooks and their renaming.  For example, code for
add_to_dispatch_window call can be hidden in variable_issue or
dispatch_init in issue_rate or dfa_{pre,post}_cycle_insn.  Of course,
the work is not for you because it needs a lot of knowledge about GCC
insn scheduler.

As for the scheduler part of the patch. I think it is ok for now.
But if you used dfa pipeline hazard recognizer as Richard Henderson
mentioned, you would not need function ready_remove_first_dispatch and
you could use first cycle multi-pass insn scheduling (although it is
not necessary for your target because constraints do not depend on the
insn order in the window as for Itanium but it might change in future
who knows). You could also use modulo-scheduling which might be more
important for OOO processors than insn scheduling. You would not need
a new option too for dispatch scheduling. Writing for dfa description
of a new processor would require nontraditional programming like
defining new attributes for md insns and usage of them in dfa
description. I think it is too late for GCC4.6 to rewrite this all.
But I think it is worth to be considered for next GCC release. I guess you
could avoid the current implementation if you discussed the approach with the GCC
community before starting the implementation.

On the other hand, the current implementation of dfa pipeline hazard recognizer
has own disadvantage for x86/x86_64. The recognizer is considered to be too big
because of numerous automata.

The scheduler part of patch is ok for the trunk.


A new command line flag âmdispatch-scheduler is defined. This option sets flag_dispatch_scheduling. To perform dispatch scheduling â-march=bdver1â and Haifa Scheduling flags must all be selected on the command line.

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