2003-01-09 Vladimir Makarov <vmakarov@redhat.com>

Merging changes from itanium-sched-branch: git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@61132 138bc75d-0d04-0410-961f-82ee72b054a4
author: vmakarov <vmakarov@138bc75d-0d04-0410-961f-82ee72b054a4> 2003-01-09 23:15:34 +0000
committer: vmakarov <vmakarov@138bc75d-0d04-0410-961f-82ee72b054a4> 2003-01-09 23:15:34 +0000
commit: 58ada791d3cb97df7eae8ab3db29f9a5d4149e79 (patch)
tree: 4c2dc43818bfc1ad93057e3973541f95b57fd3cc /gcc/doc
parent: e7bf79cf831a76f2e0d6c514f704aebcb6c389e8 (diff)
download: gcc-58ada791d3cb97df7eae8ab3db29f9a5d4149e79.tar.gz
3 files changed, 133 insertions, 23 deletions
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2adb009c46a..8b3e365a550 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9519,6 +9519,14 @@ A fixed register is one that the register allocator can not use.  This is
 useful when compiling kernel code.  A register range is specified as
 two registers separated by a dash.  Multiple register ranges can be
 specified separated by a comma.
+
+@item -mearly-stop-bits
+@itemx -mno-early-stop-bits
+@opindex mearly-stop-bits
+@opindex mno-early-stop-bits
+Allow stop bits to be placed earlier than immediately preceding the
+instruction that triggered the stop bit.  This can improve instruction
+scheduling, but does not always do so.
 @end table
 
 @node D30V Options
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 2d90de4537d..5b91c082680 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -5586,16 +5586,23 @@ which the unit is bound.  The automaton should be described in
 construction @code{define_automaton}.  You should give
 @dfn{automaton-name}, if there is a defined automaton.
 
+The assignment of units to automata are constrained by the uses of the
+units in insn reservations.  The most important constraint is: if a
+unit reservation is present on a particular cycle of an alternative
+for an insn reservation, then some unit from the same automaton must
+be present on the same cycle for the other alternatives of the insn
+reservation.  The rest of the constraints are mentioned in the
+description of the subsequent constructions.
+
 @findex define_query_cpu_unit
 @cindex querying function unit reservations
 The following construction describes CPU functional units analogously
-to @code{define_cpu_unit}.  If we use automata without their
-minimization, the reservation of such units can be queried for an
-automaton state.  The instruction scheduler never queries reservation
-of functional units for given automaton state.  So as a rule, you
-don't need this construction.  This construction could be used for
-future code generation goals (e.g. to generate @acronym{VLIW} insn
-templates).
+to @code{define_cpu_unit}.  The reservation of such units can be
+queried for an automaton state.  The instruction scheduler never
+queries reservation of functional units for given automaton state.  So
+as a rule, you don't need this construction.  This construction could
+be used for future code generation goals (e.g. to generate
+@acronym{VLIW} insn templates).
 
 @smallexample
 (define_query_cpu_unit @var{unit-names} [@var{automaton-name}])
@@ -5744,7 +5751,9 @@ of insn @samp{store} (not a stored value).
 
 @findex exclusion_set
 @findex presence_set
+@findex final_presence_set
 @findex absence_set
+@findex final_absence_set
 @cindex VLIW
 @cindex RISC
 Usually the following three constructions are used to describe
@@ -5754,13 +5763,19 @@ used for @acronym{RISC} processors too.
 
 @smallexample
 (exclusion_set @var{unit-names} @var{unit-names})
-(presence_set @var{unit-names} @var{unit-names})
-(absence_set @var{unit-names} @var{unit-names})
+(presence_set @var{unit-names} @var{patterns})
+(final_presence_set @var{unit-names} @var{patterns})
+(absence_set @var{unit-names} @var{patterns})
+(final_absence_set @var{unit-names} @var{patterns})
 @end smallexample
 
 @var{unit-names} is a string giving names of functional units
 separated by commas.
 
+@var{patterns} is a string giving patterns of functional units
+separated by comma.  Currently pattern is is one unit or units
+separated by white-spaces.
+
 The first construction (@samp{exclusion_set}) means that each
 functional unit in the first string can not be reserved simultaneously
 with a unit whose name is in the second string and vice versa.  For
@@ -5771,22 +5786,75 @@ point insns or only double floating point insns.
 
 The second construction (@samp{presence_set}) means that each
 functional unit in the first string can not be reserved unless at
-least one of units whose names are in the second string is reserved.
-This is an asymmetric relation.  For example, it is useful for
-description that @acronym{VLIW} @samp{slot1} is reserved after
-@samp{slot0} reservation.
-
-The third construction (@samp{absence_set}) means that each functional
-unit in the first string can be reserved only if each unit whose name
-is in the second string is not reserved.  This is an asymmetric
-relation (actually @samp{exclusion_set} is analogous to this one but
-it is symmetric).  For example, it is useful for description that
-@acronym{VLIW} @samp{slot0} can not be reserved after @samp{slot1} or
-@samp{slot2} reservation.
+least one of pattern of units whose names are in the second string is
+reserved.  This is an asymmetric relation.  For example, it is useful
+for description that @acronym{VLIW} @samp{slot1} is reserved after
+@samp{slot0} reservation.  We could describe it by the following
+construction
+
+@smallexample
+(presence_set "slot1" "slot0")
+@end smallexample
+
+Or @samp{slot1} is reserved only after @samp{slot0} and unit @samp{b0}
+reservation.  In this case we could write
+
+@smallexample
+(presence_set "slot1" "slot0 b0")
+@end smallexample
+
+The third construction (@samp{final_presence_set}) is analogous to
+@samp{presence_set}.  The difference between them is when checking is
+done.  When an instruction is issued in given automaton state
+reflecting all current and planned unit reservations, the automaton
+state is changed.  The first state is a source state, the second one
+is a result state.  Checking for @samp{presence_set} is done on the
+source state reservation, checking for @samp{final_presence_set} is
+done on the result reservation.  This construction is useful to
+describe a reservation which is actually two subsequent reservations.
+For example, if we use
+
+@smallexample
+(presence_set "slot1" "slot0")
+@end smallexample
+
+the following insn will be never issued (because @samp{slot1} requires
+@samp{slot0} which is absent in the source state).
+
+@smallexample
+(define_reservation "insn_and_nop" "slot0 + slot1")
+@end smallexample
+
+but it can be issued if we use analogous @samp{final_presence_set}.
+
+The forth construction (@samp{absence_set}) means that each functional
+unit in the first string can be reserved only if each pattern of units
+whose names are in the second string is not reserved.  This is an
+asymmetric relation (actually @samp{exclusion_set} is analogous to
+this one but it is symmetric).  For example, it is useful for
+description that @acronym{VLIW} @samp{slot0} can not be reserved after
+@samp{slot1} or @samp{slot2} reservation.  We could describe it by the
+following construction
+
+@smallexample
+(absence_set "slot2" "slot0, slot1")
+@end smallexample
+
+Or @samp{slot2} can not be reserved if @samp{slot0} and unit @samp{b0}
+are reserved or @samp{slot1} and unit @samp{b1} are reserved.  In
+this case we could write
+
+@smallexample
+(absence_set "slot2" "slot0 b0, slot1 b1")
+@end smallexample
 
 All functional units mentioned in a set should belong to the same
 automaton.
 
+The last construction (@samp{final_absence_set}) is analogous to
+@samp{absence_set} but checking is done on the result (state)
+reservation.  See comments for @samp{final_presence_set}.
+
 @findex automata_option
 @cindex deterministic finite state automaton
 @cindex nondeterministic finite state automaton
@@ -5804,8 +5872,8 @@ code.  Currently there are the following options:
 @itemize @bullet
 @item
 @dfn{no-minimization} makes no minimization of the automaton.  This is
-only worth to do when we are going to query CPU functional unit
-reservations in an automaton state.
+only worth to do when we are debugging the description and need to
+look more accurately at reservations of states.
 
 @item
 @dfn{time} means printing additional time statistics about
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 53ba81288d0..45f38f0f921 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -5629,6 +5629,16 @@ scheduling one insn causes other insns to become ready in the same
 cycle.  These other insns can then be taken into account properly.
 @end deftypefn
 
+@deftypefn {Target Hook} void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK (rtx @var{head}, rtx @var{tail})
+This hook is called after evaluation forward dependencies of insns in
+chain given by two parameter values (@var{head} and @var{tail}
+correspondingly) but before insns scheduling of the insn chain.  For
+example, it can be used for better insn classification if it requires
+analysis of dependencies.  This hook can use backward and forward
+dependencies of the insn scheduler because they are already
+calculated.
+@end deftypefn
+
 @deftypefn {Target Hook} void TARGET_SCHED_INIT (FILE *@var{file}, int @var{verbose}, int @var{max_ready})
 This hook is executed by the scheduler at the beginning of each block of
 instructions that are to be scheduled.  @var{file} is either a null
@@ -5715,6 +5725,30 @@ schedules to choose the best one.
 The default is no multipass scheduling.
 @end deftypefn
 
+@deftypefn {Target Hook} int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD (rtx)
+
+This hook controls what insns from the ready insn queue will be
+considered for the multipass insn scheduling.  If the hook returns
+zero for insn passed as the parameter, the insn will be not chosen to
+be issued.
+
+The default is that any ready insns can be choosen to be issued.
+@end deftypefn
+
+@deftypefn {Target Hook} int TARGET_SCHED_DFA_NEW_CYCLE (FILE *, int, rtx, int, int, int *)
+
+This hook is called by the insn scheduler before issuing insn passed
+as the third parameter on given cycle.  If the hook returns nonzero,
+the insn is not issued on given processors cycle.  Instead of that,
+the processor cycle is advanced.  If the value passed through the last
+parameter is zero, the insn ready queue is not sorted on the new cycle
+start as usually.  The first parameter passes file for debugging
+output.  The second one passes the scheduler verbose level of the
+debugging output.  The forth and the fifth parameter values are
+correspondingly processor cycle on which the previous insn has been
+issued and the current processor cycle.
+@end deftypefn
+
 @deftypefn {Target Hook} void TARGET_SCHED_INIT_DFA_BUBBLES (void)
 The @acronym{DFA}-based scheduler could take the insertion of nop
 operations for better insn scheduling into account.  It can be done
author	vmakarov <vmakarov@138bc75d-0d04-0410-961f-82ee72b054a4>	2003-01-09 23:15:34 +0000
committer	vmakarov <vmakarov@138bc75d-0d04-0410-961f-82ee72b054a4>	2003-01-09 23:15:34 +0000
commit	58ada791d3cb97df7eae8ab3db29f9a5d4149e79 (patch)
tree	4c2dc43818bfc1ad93057e3973541f95b57fd3cc /gcc/doc
parent	e7bf79cf831a76f2e0d6c514f704aebcb6c389e8 (diff)
download	gcc-58ada791d3cb97df7eae8ab3db29f9a5d4149e79.tar.gz