Patch to decrease time of building minimal delay issue table for the DFA scheduler

Vladimir N. Makarov vmakarov@redhat.com
Sat May 4 08:32:00 GMT 2002


Jan Hubicka wrote:

> >  In message <20020503225832.GI23248@atrey.karlin.mff.cuni.cz>, Jan Hubicka
> > writes:
> >  > Just curious, how large is resulting insn-attrtab file?
> >  > In my experiments large genattrtab times just signalized large files so
> >  > I split the automatons.  You will probably find usefull to model decoders,
> >  > ieu and fp as separate beasts.
> > The DFA will eventually be factored and simplified.  RIght now the point
> > behind that particular DFA is to 100% model the existing pipeline description
> > for the PPro/P2/P3.
> Hmm, does splitting of automatons affect the scheduling somewhat?
> I believe that the old scheduler units are independent, so if you use separate
> automaton for each unit (in old sense, not new one), it should still result in
> same schedule, or am I missing something?

   The splitting automata should not affect on the result insn schedules.  It
affects only on size of the result tables.  It also makes function
state_transition slightly slower because to check possibility of insn issue the
code checks more automata.  You should not be afraid to have many automata (e.g.
use separate automata for each subtarget) because the code checks only automata to
which the units of the insn reservation belong.  So if the insn reservation
contains two units belonging different automata, the code will check only the two
different automata even if the .md file contains hundred automata.

  There is also one constraint, if the units mentioned in
exclusion_set/presence_set/absence_set, they should belong the same automata.  The
genautomata.c always checks this.

Vlad




More information about the Gcc-patches mailing list