+@deftypefn {Target Hook} void TARGET_SCHED_DFA_PRE_CYCLE_ADVANCE (void)
+The hook to notify target that the current simulated cycle is about to finish.
+The hook is analogous to @samp{TARGET_SCHED_DFA_PRE_CYCLE_INSN} but used
+to change the state in more complicated situations - e.g., when advancing
+state on a single insn is not enough.
+@end deftypefn
+
+@deftypefn {Target Hook} void TARGET_SCHED_DFA_POST_CYCLE_ADVANCE (void)
+The hook to notify target that new simulated cycle has just started.
+The hook is analogous to @samp{TARGET_SCHED_DFA_POST_CYCLE_INSN} but used
+to change the state in more complicated situations - e.g., when advancing
+state on a single insn is not enough.
+@end deftypefn
+
+@deftypefn {Target Hook} int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD (void)
+This hook controls better choosing an insn from the ready insn queue
+for the @acronym{DFA}-based insn scheduler. Usually the scheduler
+chooses the first insn from the queue. If the hook returns a positive
+value, an additional scheduler code tries all permutations of
+@samp{TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD ()}
+subsequent ready insns to choose an insn whose issue will result in
+maximal number of issued insns on the same cycle. For the
+@acronym{VLIW} processor, the code could actually solve the problem of
+packing simple insns into the @acronym{VLIW} insn. Of course, if the
+rules of @acronym{VLIW} packing are described in the automaton.
+
+This code also could be used for superscalar @acronym{RISC}
+processors. Let us consider a superscalar @acronym{RISC} processor
+with 3 pipelines. Some insns can be executed in pipelines @var{A} or
+@var{B}, some insns can be executed only in pipelines @var{B} or
+@var{C}, and one insn can be executed in pipeline @var{B}. The
+processor may issue the 1st insn into @var{A} and the 2nd one into
+@var{B}. In this case, the 3rd insn will wait for freeing @var{B}
+until the next cycle. If the scheduler issues the 3rd insn the first,
+the processor could issue all 3 insns per cycle.
+
+Actually this code demonstrates advantages of the automaton based
+pipeline hazard recognizer. We try quickly and easy many insn
+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 chosen 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} bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct dep_def *@var{_dep}, int @var{cost}, int @var{distance})
+This hook is used to define which dependences are considered costly by
+the target, so costly that it is not advisable to schedule the insns that
+are involved in the dependence too close to one another. The parameters
+to this hook are as follows: The first parameter @var{_dep} is the dependence
+being evaluated. The second parameter @var{cost} is the cost of the
+dependence, and the third
+parameter @var{distance} is the distance in cycles between the two insns.
+The hook returns @code{true} if considering the distance between the two
+insns the dependence between them is considered costly by the target,
+and @code{false} otherwise.
+
+Defining this hook can be useful in multiple-issue out-of-order machines,
+where (a) it's practically hopeless to predict the actual data/resource
+delays, however: (b) there's a better chance to predict the actual grouping
+that will be formed, and (c) correctly emulating the grouping can be very
+important. In such targets one may want to allow issuing dependent insns
+closer to one another---i.e., closer than the dependence distance; however,
+not in cases of "costly dependences", which this hooks allows to define.
+@end deftypefn
+
+@deftypefn {Target Hook} void TARGET_SCHED_H_I_D_EXTENDED (void)
+This hook is called by the insn scheduler after emitting a new instruction to
+the instruction stream. The hook notifies a target backend to extend its
+per instruction data structures.
+@end deftypefn
+
+@deftypefn {Target Hook} void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void)
+Return a pointer to a store large enough to hold target scheduling context.
+@end deftypefn
+
+@deftypefn {Target Hook} void TARGET_SCHED_INIT_SCHED_CONTEXT (void *@var{tc}, bool @var{clean_p})
+Initialize store pointed to by @var{tc} to hold target scheduling context.
+It @var{clean_p} is true then initialize @var{tc} as if scheduler is at the
+beginning of the block. Otherwise, make a copy of the current context in
+@var{tc}.
+@end deftypefn
+
+@deftypefn {Target Hook} void TARGET_SCHED_SET_SCHED_CONTEXT (void *@var{tc})
+Copy target scheduling context pointer to by @var{tc} to the current context.
+@end deftypefn
+
+@deftypefn {Target Hook} void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *@var{tc})
+Deallocate internal data in target scheduling context pointed to by @var{tc}.
+@end deftypefn
+
+@deftypefn {Target Hook} void TARGET_SCHED_FREE_SCHED_CONTEXT (void *@var{tc})
+Deallocate a store for target scheduling context pointed to by @var{tc}.
+@end deftypefn
+
+@deftypefn {Target Hook} void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void)
+Return a pointer to a store large enough to hold target scheduling context.
+@end deftypefn
+
+@deftypefn {Target Hook} void TARGET_SCHED_INIT_SCHED_CONTEXT (void *@var{tc}, bool @var{clean_p})
+Initialize store pointed to by @var{tc} to hold target scheduling context.
+It @var{clean_p} is true then initialize @var{tc} as if scheduler is at the
+beginning of the block. Otherwise, make a copy of the current context in
+@var{tc}.
+@end deftypefn
+
+@deftypefn {Target Hook} void TARGET_SCHED_SET_SCHED_CONTEXT (void *@var{tc})
+Copy target scheduling context pointer to by @var{tc} to the current context.
+@end deftypefn
+
+@deftypefn {Target Hook} void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *@var{tc})
+Deallocate internal data in target scheduling context pointed to by @var{tc}.
+@end deftypefn
+
+@deftypefn {Target Hook} void TARGET_SCHED_FREE_SCHED_CONTEXT (void *@var{tc})
+Deallocate a store for target scheduling context pointed to by @var{tc}.
+@end deftypefn
+
+@deftypefn {Target Hook} int TARGET_SCHED_SPECULATE_INSN (rtx @var{insn}, int @var{request}, rtx *@var{new_pat})
+This hook is called by the insn scheduler when @var{insn} has only
+speculative dependencies and therefore can be scheduled speculatively.
+The hook is used to check if the pattern of @var{insn} has a speculative
+version and, in case of successful check, to generate that speculative
+pattern. The hook should return 1, if the instruction has a speculative form,
+or -1, if it doesn't. @var{request} describes the type of requested
+speculation. If the return value equals 1 then @var{new_pat} is assigned
+the generated speculative pattern.
+@end deftypefn
+
+@deftypefn {Target Hook} int TARGET_SCHED_NEEDS_BLOCK_P (rtx @var{insn})
+This hook is called by the insn scheduler during generation of recovery code
+for @var{insn}. It should return nonzero, if the corresponding check
+instruction should branch to recovery code, or zero otherwise.
+@end deftypefn
+
+@deftypefn {Target Hook} rtx TARGET_SCHED_GEN_CHECK (rtx @var{insn}, rtx @var{label}, int @var{mutate_p})
+This hook is called by the insn scheduler to generate a pattern for recovery
+check instruction. If @var{mutate_p} is zero, then @var{insn} is a
+speculative instruction for which the check should be generated.
+@var{label} is either a label of a basic block, where recovery code should
+be emitted, or a null pointer, when requested check doesn't branch to
+recovery code (a simple check). If @var{mutate_p} is nonzero, then
+a pattern for a branchy check corresponding to a simple check denoted by
+@var{insn} should be generated. In this case @var{label} can't be null.
+@end deftypefn
+
+@deftypefn {Target Hook} int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC (rtx @var{insn})
+This hook is used as a workaround for
+@samp{TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD} not being
+called on the first instruction of the ready list. The hook is used to
+discard speculative instruction that stand first in the ready list from
+being scheduled on the current cycle. For non-speculative instructions,
+the hook should always return nonzero. For example, in the ia64 backend
+the hook is used to cancel data speculative insns when the ALAT table
+is nearly full.
+@end deftypefn
+
+@deftypefn {Target Hook} void TARGET_SCHED_SET_SCHED_FLAGS (unsigned int *@var{flags}, spec_info_t @var{spec_info})
+This hook is used by the insn scheduler to find out what features should be
+enabled/used. @var{flags} initially may have either the SCHED_RGN or SCHED_EBB
+bit set. This denotes the scheduler pass for which the data should be
+provided. The target backend should modify @var{flags} by modifying
+the bits corresponding to the following features: USE_DEPS_LIST, USE_GLAT,
+DETACH_LIFE_INFO, and DO_SPECULATION@. For the DO_SPECULATION feature
+an additional structure @var{spec_info} should be filled by the target.
+The structure describes speculation types that can be used in the scheduler.
+@end deftypefn
+
+@deftypefn {Target Hook} int TARGET_SCHED_SMS_RES_MII (struct ddg *@var{g})
+This hook is called by the swing modulo scheduler to calculate a
+resource-based lower bound which is based on the resources available in
+the machine and the resources required by each instruction. The target
+backend can use @var{g} to calculate such bound. A very simple lower
+bound will be used in case this hook is not implemented: the total number
+of instructions divided by the issue rate.
+@end deftypefn
+
+@node Sections
+@section Dividing the Output into Sections (Texts, Data, @dots{})
+@c the above section title is WAY too long. maybe cut the part between
+@c the (...)? --mew 10feb93
+
+An object file is divided into sections containing different types of
+data. In the most common case, there are three sections: the @dfn{text
+section}, which holds instructions and read-only data; the @dfn{data
+section}, which holds initialized writable data; and the @dfn{bss
+section}, which holds uninitialized data. Some systems have other kinds
+of sections.
+
+@file{varasm.c} provides several well-known sections, such as
+@code{text_section}, @code{data_section} and @code{bss_section}.
+The normal way of controlling a @code{@var{foo}_section} variable
+is to define the associated @code{@var{FOO}_SECTION_ASM_OP} macro,
+as described below. The macros are only read once, when @file{varasm.c}
+initializes itself, so their values must be run-time constants.
+They may however depend on command-line flags.
+
+@emph{Note:} Some run-time files, such @file{crtstuff.c}, also make
+use of the @code{@var{FOO}_SECTION_ASM_OP} macros, and expect them
+to be string literals.
+
+Some assemblers require a different string to be written every time a
+section is selected. If your assembler falls into this category, you
+should define the @code{TARGET_ASM_INIT_SECTIONS} hook and use
+@code{get_unnamed_section} to set up the sections.
+
+You must always create a @code{text_section}, either by defining
+@code{TEXT_SECTION_ASM_OP} or by initializing @code{text_section}
+in @code{TARGET_ASM_INIT_SECTIONS}. The same is true of
+@code{data_section} and @code{DATA_SECTION_ASM_OP}. If you do not
+create a distinct @code{readonly_data_section}, the default is to
+reuse @code{text_section}.
+
+All the other @file{varasm.c} sections are optional, and are null
+if the target does not provide them.
+
+@defmac TEXT_SECTION_ASM_OP
+A C expression whose value is a string, including spacing, containing the
+assembler operation that should precede instructions and read-only data.
+Normally @code{"\t.text"} is right.
+@end defmac
+
+@defmac HOT_TEXT_SECTION_NAME
+If defined, a C string constant for the name of the section containing most
+frequently executed functions of the program. If not defined, GCC will provide
+a default definition if the target supports named sections.
+@end defmac
+
+@defmac UNLIKELY_EXECUTED_TEXT_SECTION_NAME
+If defined, a C string constant for the name of the section containing unlikely
+executed functions in the program.
+@end defmac
+
+@defmac DATA_SECTION_ASM_OP