You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
600 lines
34 KiB
HTML
600 lines
34 KiB
HTML
4 years ago
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||
|
|
<html>
|
||
|
|
<!-- Copyright (C) 1988-2018 Free Software Foundation, Inc.
|
||
|
|
|
||
|
|
Permission is granted to copy, distribute and/or modify this document
|
||
|
|
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||
|
|
any later version published by the Free Software Foundation; with the
|
||
|
|
Invariant Sections being "Funding Free Software", the Front-Cover
|
||
|
|
Texts being (a) (see below), and with the Back-Cover Texts being (b)
|
||
|
|
(see below). A copy of the license is included in the section entitled
|
||
|
|
"GNU Free Documentation License".
|
||
|
|
|
||
|
|
(a) The FSF's Front-Cover Text is:
|
||
|
|
|
||
|
|
A GNU Manual
|
||
|
|
|
||
|
|
(b) The FSF's Back-Cover Text is:
|
||
|
|
|
||
|
|
You have freedom to copy and modify this GNU Manual, like GNU
|
||
|
|
software. Copies published by the Free Software Foundation raise
|
||
|
|
funds for GNU development. -->
|
||
|
|
<!-- Created by GNU Texinfo 6.4, http://www.gnu.org/software/texinfo/ -->
|
||
|
|
<head>
|
||
|
|
<title>Scheduling (GNU Compiler Collection (GCC) Internals)</title>
|
||
|
|
|
||
|
|
<meta name="description" content="Scheduling (GNU Compiler Collection (GCC) Internals)">
|
||
|
|
<meta name="keywords" content="Scheduling (GNU Compiler Collection (GCC) Internals)">
|
||
|
|
<meta name="resource-type" content="document">
|
||
|
|
<meta name="distribution" content="global">
|
||
|
|
<meta name="Generator" content="makeinfo">
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||
|
|
<link href="index.html#Top" rel="start" title="Top">
|
||
|
|
<link href="Option-Index.html#Option-Index" rel="index" title="Option Index">
|
||
|
|
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
|
||
|
|
<link href="Target-Macros.html#Target-Macros" rel="up" title="Target Macros">
|
||
|
|
<link href="Sections.html#Sections" rel="next" title="Sections">
|
||
|
|
<link href="Costs.html#Costs" rel="prev" title="Costs">
|
||
|
|
<style type="text/css">
|
||
|
|
<!--
|
||
|
|
a.summary-letter {text-decoration: none}
|
||
|
|
blockquote.indentedblock {margin-right: 0em}
|
||
|
|
blockquote.smallindentedblock {margin-right: 0em; font-size: smaller}
|
||
|
|
blockquote.smallquotation {font-size: smaller}
|
||
|
|
div.display {margin-left: 3.2em}
|
||
|
|
div.example {margin-left: 3.2em}
|
||
|
|
div.lisp {margin-left: 3.2em}
|
||
|
|
div.smalldisplay {margin-left: 3.2em}
|
||
|
|
div.smallexample {margin-left: 3.2em}
|
||
|
|
div.smalllisp {margin-left: 3.2em}
|
||
|
|
kbd {font-style: oblique}
|
||
|
|
pre.display {font-family: inherit}
|
||
|
|
pre.format {font-family: inherit}
|
||
|
|
pre.menu-comment {font-family: serif}
|
||
|
|
pre.menu-preformatted {font-family: serif}
|
||
|
|
pre.smalldisplay {font-family: inherit; font-size: smaller}
|
||
|
|
pre.smallexample {font-size: smaller}
|
||
|
|
pre.smallformat {font-family: inherit; font-size: smaller}
|
||
|
|
pre.smalllisp {font-size: smaller}
|
||
|
|
span.nolinebreak {white-space: nowrap}
|
||
|
|
span.roman {font-family: initial; font-weight: normal}
|
||
|
|
span.sansserif {font-family: sans-serif; font-weight: normal}
|
||
|
|
ul.no-bullet {list-style: none}
|
||
|
|
-->
|
||
|
|
</style>
|
||
|
|
|
||
|
|
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<body lang="en">
|
||
|
|
<a name="Scheduling"></a>
|
||
|
|
<div class="header">
|
||
|
|
<p>
|
||
|
|
Next: <a href="Sections.html#Sections" accesskey="n" rel="next">Sections</a>, Previous: <a href="Costs.html#Costs" accesskey="p" rel="prev">Costs</a>, Up: <a href="Target-Macros.html#Target-Macros" accesskey="u" rel="up">Target Macros</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
|
||
|
|
</div>
|
||
|
|
<hr>
|
||
|
|
<a name="Adjusting-the-Instruction-Scheduler"></a>
|
||
|
|
<h3 class="section">18.17 Adjusting the Instruction Scheduler</h3>
|
||
|
|
|
||
|
|
<p>The instruction scheduler may need a fair amount of machine-specific
|
||
|
|
adjustment in order to produce good code. GCC provides several target
|
||
|
|
hooks for this purpose. It is usually enough to define just a few of
|
||
|
|
them: try the first ones in this list first.
|
||
|
|
</p>
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fISSUE_005fRATE"></a>Target Hook: <em>int</em> <strong>TARGET_SCHED_ISSUE_RATE</strong> <em>(void)</em></dt>
|
||
|
|
<dd><p>This hook returns the maximum number of instructions that can ever
|
||
|
|
issue at the same time on the target machine. The default is one.
|
||
|
|
Although the insn scheduler can define itself the possibility of issue
|
||
|
|
an insn on the same cycle, the value can serve as an additional
|
||
|
|
constraint to issue insns on the same simulated processor cycle (see
|
||
|
|
hooks ‘<samp>TARGET_SCHED_REORDER</samp>’ and ‘<samp>TARGET_SCHED_REORDER2</samp>’).
|
||
|
|
This value must be constant over the entire compilation. If you need
|
||
|
|
it to vary depending on what the instructions are, you must use
|
||
|
|
‘<samp>TARGET_SCHED_VARIABLE_ISSUE</samp>’.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fVARIABLE_005fISSUE"></a>Target Hook: <em>int</em> <strong>TARGET_SCHED_VARIABLE_ISSUE</strong> <em>(FILE *<var>file</var>, int <var>verbose</var>, rtx_insn *<var>insn</var>, int <var>more</var>)</em></dt>
|
||
|
|
<dd><p>This hook is executed by the scheduler after it has scheduled an insn
|
||
|
|
from the ready list. It should return the number of insns which can
|
||
|
|
still be issued in the current cycle. The default is
|
||
|
|
‘<samp><var>more</var> <span class="nolinebreak">-</span> 1<!-- /@w --></samp>’ for insns other than <code>CLOBBER</code> and
|
||
|
|
<code>USE</code>, which normally are not counted against the issue rate.
|
||
|
|
You should define this hook if some insns take more machine resources
|
||
|
|
than others, so that fewer insns can follow them in the same cycle.
|
||
|
|
<var>file</var> is either a null pointer, or a stdio stream to write any
|
||
|
|
debug output to. <var>verbose</var> is the verbose level provided by
|
||
|
|
<samp>-fsched-verbose-<var>n</var></samp>. <var>insn</var> is the instruction that
|
||
|
|
was scheduled.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fADJUST_005fCOST"></a>Target Hook: <em>int</em> <strong>TARGET_SCHED_ADJUST_COST</strong> <em>(rtx_insn *<var>insn</var>, int <var>dep_type1</var>, rtx_insn *<var>dep_insn</var>, int <var>cost</var>, unsigned int <var>dw</var>)</em></dt>
|
||
|
|
<dd><p>This function corrects the value of <var>cost</var> based on the
|
||
|
|
relationship between <var>insn</var> and <var>dep_insn</var> through a
|
||
|
|
dependence of type dep_type, and strength <var>dw</var>. It should return the new
|
||
|
|
value. The default is to make no adjustment to <var>cost</var>. This can be
|
||
|
|
used for example to specify to the scheduler using the traditional pipeline
|
||
|
|
description that an output- or anti-dependence does not incur the same cost
|
||
|
|
as a data-dependence. If the scheduler using the automaton based pipeline
|
||
|
|
description, the cost of anti-dependence is zero and the cost of
|
||
|
|
output-dependence is maximum of one and the difference of latency
|
||
|
|
times of the first and the second insns. If these values are not
|
||
|
|
acceptable, you could use the hook to modify them too. See also
|
||
|
|
see <a href="Processor-pipeline-description.html#Processor-pipeline-description">Processor pipeline description</a>.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fADJUST_005fPRIORITY"></a>Target Hook: <em>int</em> <strong>TARGET_SCHED_ADJUST_PRIORITY</strong> <em>(rtx_insn *<var>insn</var>, int <var>priority</var>)</em></dt>
|
||
|
|
<dd><p>This hook adjusts the integer scheduling priority <var>priority</var> of
|
||
|
|
<var>insn</var>. It should return the new priority. Increase the priority to
|
||
|
|
execute <var>insn</var> earlier, reduce the priority to execute <var>insn</var>
|
||
|
|
later. Do not define this hook if you do not need to adjust the
|
||
|
|
scheduling priorities of insns.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fREORDER"></a>Target Hook: <em>int</em> <strong>TARGET_SCHED_REORDER</strong> <em>(FILE *<var>file</var>, int <var>verbose</var>, rtx_insn **<var>ready</var>, int *<var>n_readyp</var>, int <var>clock</var>)</em></dt>
|
||
|
|
<dd><p>This hook is executed by the scheduler after it has scheduled the ready
|
||
|
|
list, to allow the machine description to reorder it (for example to
|
||
|
|
combine two small instructions together on ‘<samp>VLIW</samp>’ machines).
|
||
|
|
<var>file</var> is either a null pointer, or a stdio stream to write any
|
||
|
|
debug output to. <var>verbose</var> is the verbose level provided by
|
||
|
|
<samp>-fsched-verbose-<var>n</var></samp>. <var>ready</var> is a pointer to the ready
|
||
|
|
list of instructions that are ready to be scheduled. <var>n_readyp</var> is
|
||
|
|
a pointer to the number of elements in the ready list. The scheduler
|
||
|
|
reads the ready list in reverse order, starting with
|
||
|
|
<var>ready</var>[<var>*n_readyp</var> - 1] and going to <var>ready</var>[0]. <var>clock</var>
|
||
|
|
is the timer tick of the scheduler. You may modify the ready list and
|
||
|
|
the number of ready insns. The return value is the number of insns that
|
||
|
|
can issue this cycle; normally this is just <code>issue_rate</code>. See also
|
||
|
|
‘<samp>TARGET_SCHED_REORDER2</samp>’.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fREORDER2"></a>Target Hook: <em>int</em> <strong>TARGET_SCHED_REORDER2</strong> <em>(FILE *<var>file</var>, int <var>verbose</var>, rtx_insn **<var>ready</var>, int *<var>n_readyp</var>, int <var>clock</var>)</em></dt>
|
||
|
|
<dd><p>Like ‘<samp>TARGET_SCHED_REORDER</samp>’, but called at a different time. That
|
||
|
|
function is called whenever the scheduler starts a new cycle. This one
|
||
|
|
is called once per iteration over a cycle, immediately after
|
||
|
|
‘<samp>TARGET_SCHED_VARIABLE_ISSUE</samp>’; it can reorder the ready list and
|
||
|
|
return the number of insns to be scheduled in the same cycle. Defining
|
||
|
|
this hook can be useful if there are frequent situations where
|
||
|
|
scheduling one insn causes other insns to become ready in the same
|
||
|
|
cycle. These other insns can then be taken into account properly.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fMACRO_005fFUSION_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_SCHED_MACRO_FUSION_P</strong> <em>(void)</em></dt>
|
||
|
|
<dd><p>This hook is used to check whether target platform supports macro fusion.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fMACRO_005fFUSION_005fPAIR_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_SCHED_MACRO_FUSION_PAIR_P</strong> <em>(rtx_insn *<var>prev</var>, rtx_insn *<var>curr</var>)</em></dt>
|
||
|
|
<dd><p>This hook is used to check whether two insns should be macro fused for
|
||
|
|
a target microarchitecture. If this hook returns true for the given insn pair
|
||
|
|
(<var>prev</var> and <var>curr</var>), the scheduler will put them into a sched
|
||
|
|
group, and they will not be scheduled apart. The two insns will be either
|
||
|
|
two SET insns or a compare and a conditional jump and this hook should
|
||
|
|
validate any dependencies needed to fuse the two insns together.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fDEPENDENCIES_005fEVALUATION_005fHOOK"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK</strong> <em>(rtx_insn *<var>head</var>, rtx_insn *<var>tail</var>)</em></dt>
|
||
|
|
<dd><p>This hook is called after evaluation forward dependencies of insns in
|
||
|
|
chain given by two parameter values (<var>head</var> and <var>tail</var>
|
||
|
|
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.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fINIT"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_INIT</strong> <em>(FILE *<var>file</var>, int <var>verbose</var>, int <var>max_ready</var>)</em></dt>
|
||
|
|
<dd><p>This hook is executed by the scheduler at the beginning of each block of
|
||
|
|
instructions that are to be scheduled. <var>file</var> is either a null
|
||
|
|
pointer, or a stdio stream to write any debug output to. <var>verbose</var>
|
||
|
|
is the verbose level provided by <samp>-fsched-verbose-<var>n</var></samp>.
|
||
|
|
<var>max_ready</var> is the maximum number of insns in the current scheduling
|
||
|
|
region that can be live at the same time. This can be used to allocate
|
||
|
|
scratch space if it is needed, e.g. by ‘<samp>TARGET_SCHED_REORDER</samp>’.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fFINISH"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_FINISH</strong> <em>(FILE *<var>file</var>, int <var>verbose</var>)</em></dt>
|
||
|
|
<dd><p>This hook is executed by the scheduler at the end of each block of
|
||
|
|
instructions that are to be scheduled. It can be used to perform
|
||
|
|
cleanup of any actions done by the other scheduling hooks. <var>file</var>
|
||
|
|
is either a null pointer, or a stdio stream to write any debug output
|
||
|
|
to. <var>verbose</var> is the verbose level provided by
|
||
|
|
<samp>-fsched-verbose-<var>n</var></samp>.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fINIT_005fGLOBAL"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_INIT_GLOBAL</strong> <em>(FILE *<var>file</var>, int <var>verbose</var>, int <var>old_max_uid</var>)</em></dt>
|
||
|
|
<dd><p>This hook is executed by the scheduler after function level initializations.
|
||
|
|
<var>file</var> is either a null pointer, or a stdio stream to write any debug output to.
|
||
|
|
<var>verbose</var> is the verbose level provided by <samp>-fsched-verbose-<var>n</var></samp>.
|
||
|
|
<var>old_max_uid</var> is the maximum insn uid when scheduling begins.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fFINISH_005fGLOBAL"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_FINISH_GLOBAL</strong> <em>(FILE *<var>file</var>, int <var>verbose</var>)</em></dt>
|
||
|
|
<dd><p>This is the cleanup hook corresponding to <code>TARGET_SCHED_INIT_GLOBAL</code>.
|
||
|
|
<var>file</var> is either a null pointer, or a stdio stream to write any debug output to.
|
||
|
|
<var>verbose</var> is the verbose level provided by <samp>-fsched-verbose-<var>n</var></samp>.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fDFA_005fPRE_005fCYCLE_005fINSN"></a>Target Hook: <em>rtx</em> <strong>TARGET_SCHED_DFA_PRE_CYCLE_INSN</strong> <em>(void)</em></dt>
|
||
|
|
<dd><p>The hook returns an RTL insn. The automaton state used in the
|
||
|
|
pipeline hazard recognizer is changed as if the insn were scheduled
|
||
|
|
when the new simulated processor cycle starts. Usage of the hook may
|
||
|
|
simplify the automaton pipeline description for some <acronym>VLIW</acronym>
|
||
|
|
processors. If the hook is defined, it is used only for the automaton
|
||
|
|
based pipeline description. The default is not to change the state
|
||
|
|
when the new simulated processor cycle starts.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fINIT_005fDFA_005fPRE_005fCYCLE_005fINSN"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN</strong> <em>(void)</em></dt>
|
||
|
|
<dd><p>The hook can be used to initialize data used by the previous hook.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fDFA_005fPOST_005fCYCLE_005fINSN"></a>Target Hook: <em>rtx_insn *</em> <strong>TARGET_SCHED_DFA_POST_CYCLE_INSN</strong> <em>(void)</em></dt>
|
||
|
|
<dd><p>The hook is analogous to ‘<samp>TARGET_SCHED_DFA_PRE_CYCLE_INSN</samp>’ but used
|
||
|
|
to changed the state as if the insn were scheduled when the new
|
||
|
|
simulated processor cycle finishes.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fINIT_005fDFA_005fPOST_005fCYCLE_005fINSN"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN</strong> <em>(void)</em></dt>
|
||
|
|
<dd><p>The hook is analogous to ‘<samp>TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN</samp>’ but
|
||
|
|
used to initialize data used by the previous hook.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fDFA_005fPRE_005fADVANCE_005fCYCLE"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE</strong> <em>(void)</em></dt>
|
||
|
|
<dd><p>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</samp>’ but used
|
||
|
|
to change the state in more complicated situations - e.g., when advancing
|
||
|
|
state on a single insn is not enough.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fDFA_005fPOST_005fADVANCE_005fCYCLE"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_DFA_POST_ADVANCE_CYCLE</strong> <em>(void)</em></dt>
|
||
|
|
<dd><p>The hook to notify target that new simulated cycle has just started.
|
||
|
|
The hook is analogous to ‘<samp>TARGET_SCHED_DFA_POST_CYCLE_INSN</samp>’ but used
|
||
|
|
to change the state in more complicated situations - e.g., when advancing
|
||
|
|
state on a single insn is not enough.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fFIRST_005fCYCLE_005fMULTIPASS_005fDFA_005fLOOKAHEAD"></a>Target Hook: <em>int</em> <strong>TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD</strong> <em>(void)</em></dt>
|
||
|
|
<dd><p>This hook controls better choosing an insn from the ready insn queue
|
||
|
|
for the <acronym>DFA</acronym>-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 ()</samp>’
|
||
|
|
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</acronym> processor, the code could actually solve the problem of
|
||
|
|
packing simple insns into the <acronym>VLIW</acronym> insn. Of course, if the
|
||
|
|
rules of <acronym>VLIW</acronym> packing are described in the automaton.
|
||
|
|
</p>
|
||
|
|
<p>This code also could be used for superscalar <acronym>RISC</acronym>
|
||
|
|
processors. Let us consider a superscalar <acronym>RISC</acronym> processor
|
||
|
|
with 3 pipelines. Some insns can be executed in pipelines <var>A</var> or
|
||
|
|
<var>B</var>, some insns can be executed only in pipelines <var>B</var> or
|
||
|
|
<var>C</var>, and one insn can be executed in pipeline <var>B</var>. The
|
||
|
|
processor may issue the 1st insn into <var>A</var> and the 2nd one into
|
||
|
|
<var>B</var>. In this case, the 3rd insn will wait for freeing <var>B</var>
|
||
|
|
until the next cycle. If the scheduler issues the 3rd insn the first,
|
||
|
|
the processor could issue all 3 insns per cycle.
|
||
|
|
</p>
|
||
|
|
<p>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.
|
||
|
|
</p>
|
||
|
|
<p>The default is no multipass scheduling.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fFIRST_005fCYCLE_005fMULTIPASS_005fDFA_005fLOOKAHEAD_005fGUARD"></a>Target Hook: <em>int</em> <strong>TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD</strong> <em>(rtx_insn *<var>insn</var>, int <var>ready_index</var>)</em></dt>
|
||
|
|
<dd>
|
||
|
|
<p>This hook controls what insns from the ready insn queue will be
|
||
|
|
considered for the multipass insn scheduling. If the hook returns
|
||
|
|
zero for <var>insn</var>, the insn will be considered in multipass scheduling.
|
||
|
|
Positive return values will remove <var>insn</var> from consideration on
|
||
|
|
the current round of multipass scheduling.
|
||
|
|
Negative return values will remove <var>insn</var> from consideration for given
|
||
|
|
number of cycles.
|
||
|
|
Backends should be careful about returning non-zero for highest priority
|
||
|
|
instruction at position 0 in the ready list. <var>ready_index</var> is passed
|
||
|
|
to allow backends make correct judgements.
|
||
|
|
</p>
|
||
|
|
<p>The default is that any ready insns can be chosen to be issued.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fFIRST_005fCYCLE_005fMULTIPASS_005fBEGIN"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN</strong> <em>(void *<var>data</var>, signed char *<var>ready_try</var>, int <var>n_ready</var>, bool <var>first_cycle_insn_p</var>)</em></dt>
|
||
|
|
<dd><p>This hook prepares the target backend for a new round of multipass
|
||
|
|
scheduling.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fFIRST_005fCYCLE_005fMULTIPASS_005fISSUE"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE</strong> <em>(void *<var>data</var>, signed char *<var>ready_try</var>, int <var>n_ready</var>, rtx_insn *<var>insn</var>, const void *<var>prev_data</var>)</em></dt>
|
||
|
|
<dd><p>This hook is called when multipass scheduling evaluates instruction INSN.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fFIRST_005fCYCLE_005fMULTIPASS_005fBACKTRACK"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK</strong> <em>(const void *<var>data</var>, signed char *<var>ready_try</var>, int <var>n_ready</var>)</em></dt>
|
||
|
|
<dd><p>This is called when multipass scheduling backtracks from evaluation of
|
||
|
|
an instruction.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fFIRST_005fCYCLE_005fMULTIPASS_005fEND"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END</strong> <em>(const void *<var>data</var>)</em></dt>
|
||
|
|
<dd><p>This hook notifies the target about the result of the concluded current
|
||
|
|
round of multipass scheduling.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fFIRST_005fCYCLE_005fMULTIPASS_005fINIT"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT</strong> <em>(void *<var>data</var>)</em></dt>
|
||
|
|
<dd><p>This hook initializes target-specific data used in multipass scheduling.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fFIRST_005fCYCLE_005fMULTIPASS_005fFINI"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI</strong> <em>(void *<var>data</var>)</em></dt>
|
||
|
|
<dd><p>This hook finalizes target-specific data used in multipass scheduling.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fDFA_005fNEW_005fCYCLE"></a>Target Hook: <em>int</em> <strong>TARGET_SCHED_DFA_NEW_CYCLE</strong> <em>(FILE *<var>dump</var>, int <var>verbose</var>, rtx_insn *<var>insn</var>, int <var>last_clock</var>, int <var>clock</var>, int *<var>sort_p</var>)</em></dt>
|
||
|
|
<dd><p>This hook is called by the insn scheduler before issuing <var>insn</var>
|
||
|
|
on cycle <var>clock</var>. If the hook returns nonzero,
|
||
|
|
<var>insn</var> is not issued on this processor cycle. Instead,
|
||
|
|
the processor cycle is advanced. If *<var>sort_p</var>
|
||
|
|
is zero, the insn ready queue is not sorted on the new cycle
|
||
|
|
start as usually. <var>dump</var> and <var>verbose</var> specify the file and
|
||
|
|
verbosity level to use for debugging output.
|
||
|
|
<var>last_clock</var> and <var>clock</var> are, respectively, the
|
||
|
|
processor cycle on which the previous insn has been issued,
|
||
|
|
and the current processor cycle.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fIS_005fCOSTLY_005fDEPENDENCE"></a>Target Hook: <em>bool</em> <strong>TARGET_SCHED_IS_COSTLY_DEPENDENCE</strong> <em>(struct _dep *<var>_dep</var>, int <var>cost</var>, int <var>distance</var>)</em></dt>
|
||
|
|
<dd><p>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</var> is the dependence
|
||
|
|
being evaluated. The second parameter <var>cost</var> is the cost of the
|
||
|
|
dependence as estimated by the scheduler, and the third
|
||
|
|
parameter <var>distance</var> is the distance in cycles between the two insns.
|
||
|
|
The hook returns <code>true</code> if considering the distance between the two
|
||
|
|
insns the dependence between them is considered costly by the target,
|
||
|
|
and <code>false</code> otherwise.
|
||
|
|
</p>
|
||
|
|
<p>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.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fH_005fI_005fD_005fEXTENDED"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_H_I_D_EXTENDED</strong> <em>(void)</em></dt>
|
||
|
|
<dd><p>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.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fALLOC_005fSCHED_005fCONTEXT"></a>Target Hook: <em>void *</em> <strong>TARGET_SCHED_ALLOC_SCHED_CONTEXT</strong> <em>(void)</em></dt>
|
||
|
|
<dd><p>Return a pointer to a store large enough to hold target scheduling context.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fINIT_005fSCHED_005fCONTEXT"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_INIT_SCHED_CONTEXT</strong> <em>(void *<var>tc</var>, bool <var>clean_p</var>)</em></dt>
|
||
|
|
<dd><p>Initialize store pointed to by <var>tc</var> to hold target scheduling context.
|
||
|
|
It <var>clean_p</var> is true then initialize <var>tc</var> as if scheduler is at the
|
||
|
|
beginning of the block. Otherwise, copy the current context into <var>tc</var>.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fSET_005fSCHED_005fCONTEXT"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_SET_SCHED_CONTEXT</strong> <em>(void *<var>tc</var>)</em></dt>
|
||
|
|
<dd><p>Copy target scheduling context pointed to by <var>tc</var> to the current context.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fCLEAR_005fSCHED_005fCONTEXT"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_CLEAR_SCHED_CONTEXT</strong> <em>(void *<var>tc</var>)</em></dt>
|
||
|
|
<dd><p>Deallocate internal data in target scheduling context pointed to by <var>tc</var>.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fFREE_005fSCHED_005fCONTEXT"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_FREE_SCHED_CONTEXT</strong> <em>(void *<var>tc</var>)</em></dt>
|
||
|
|
<dd><p>Deallocate a store for target scheduling context pointed to by <var>tc</var>.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fSPECULATE_005fINSN"></a>Target Hook: <em>int</em> <strong>TARGET_SCHED_SPECULATE_INSN</strong> <em>(rtx_insn *<var>insn</var>, unsigned int <var>dep_status</var>, rtx *<var>new_pat</var>)</em></dt>
|
||
|
|
<dd><p>This hook is called by the insn scheduler when <var>insn</var> has only
|
||
|
|
speculative dependencies and therefore can be scheduled speculatively.
|
||
|
|
The hook is used to check if the pattern of <var>insn</var> 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</var> describes the type of requested
|
||
|
|
speculation. If the return value equals 1 then <var>new_pat</var> is assigned
|
||
|
|
the generated speculative pattern.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fNEEDS_005fBLOCK_005fP"></a>Target Hook: <em>bool</em> <strong>TARGET_SCHED_NEEDS_BLOCK_P</strong> <em>(unsigned int <var>dep_status</var>)</em></dt>
|
||
|
|
<dd><p>This hook is called by the insn scheduler during generation of recovery code
|
||
|
|
for <var>insn</var>. It should return <code>true</code>, if the corresponding check
|
||
|
|
instruction should branch to recovery code, or <code>false</code> otherwise.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fGEN_005fSPEC_005fCHECK"></a>Target Hook: <em>rtx</em> <strong>TARGET_SCHED_GEN_SPEC_CHECK</strong> <em>(rtx_insn *<var>insn</var>, rtx_insn *<var>label</var>, unsigned int <var>ds</var>)</em></dt>
|
||
|
|
<dd><p>This hook is called by the insn scheduler to generate a pattern for recovery
|
||
|
|
check instruction. If <var>mutate_p</var> is zero, then <var>insn</var> is a
|
||
|
|
speculative instruction for which the check should be generated.
|
||
|
|
<var>label</var> 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</var> is nonzero, then
|
||
|
|
a pattern for a branchy check corresponding to a simple check denoted by
|
||
|
|
<var>insn</var> should be generated. In this case <var>label</var> can’t be null.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fSET_005fSCHED_005fFLAGS"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_SET_SCHED_FLAGS</strong> <em>(struct spec_info_def *<var>spec_info</var>)</em></dt>
|
||
|
|
<dd><p>This hook is used by the insn scheduler to find out what features should be
|
||
|
|
enabled/used.
|
||
|
|
The structure *<var>spec_info</var> should be filled in by the target.
|
||
|
|
The structure describes speculation types that can be used in the scheduler.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fCAN_005fSPECULATE_005fINSN"></a>Target Hook: <em>bool</em> <strong>TARGET_SCHED_CAN_SPECULATE_INSN</strong> <em>(rtx_insn *<var>insn</var>)</em></dt>
|
||
|
|
<dd><p>Some instructions should never be speculated by the schedulers, usually
|
||
|
|
because the instruction is too expensive to get this wrong. Often such
|
||
|
|
instructions have long latency, and often they are not fully modeled in the
|
||
|
|
pipeline descriptions. This hook should return <code>false</code> if <var>insn</var>
|
||
|
|
should not be speculated.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fSMS_005fRES_005fMII"></a>Target Hook: <em>int</em> <strong>TARGET_SCHED_SMS_RES_MII</strong> <em>(struct ddg *<var>g</var>)</em></dt>
|
||
|
|
<dd><p>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</var> 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.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fDISPATCH"></a>Target Hook: <em>bool</em> <strong>TARGET_SCHED_DISPATCH</strong> <em>(rtx_insn *<var>insn</var>, int <var>x</var>)</em></dt>
|
||
|
|
<dd><p>This hook is called by Haifa Scheduler. It returns true if dispatch scheduling
|
||
|
|
is supported in hardware and the condition specified in the parameter is true.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fDISPATCH_005fDO"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_DISPATCH_DO</strong> <em>(rtx_insn *<var>insn</var>, int <var>x</var>)</em></dt>
|
||
|
|
<dd><p>This hook is called by Haifa Scheduler. It performs the operation specified
|
||
|
|
in its second parameter.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fEXPOSED_005fPIPELINE"></a>Target Hook: <em>bool</em> <strong>TARGET_SCHED_EXPOSED_PIPELINE</strong></dt>
|
||
|
|
<dd><p>True if the processor has an exposed pipeline, which means that not just
|
||
|
|
the order of instructions is important for correctness when scheduling, but
|
||
|
|
also the latencies of operations.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fREASSOCIATION_005fWIDTH"></a>Target Hook: <em>int</em> <strong>TARGET_SCHED_REASSOCIATION_WIDTH</strong> <em>(unsigned int <var>opc</var>, machine_mode <var>mode</var>)</em></dt>
|
||
|
|
<dd><p>This hook is called by tree reassociator to determine a level of
|
||
|
|
parallelism required in output calculations chain.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fSCHED_005fFUSION_005fPRIORITY"></a>Target Hook: <em>void</em> <strong>TARGET_SCHED_FUSION_PRIORITY</strong> <em>(rtx_insn *<var>insn</var>, int <var>max_pri</var>, int *<var>fusion_pri</var>, int *<var>pri</var>)</em></dt>
|
||
|
|
<dd><p>This hook is called by scheduling fusion pass. It calculates fusion
|
||
|
|
priorities for each instruction passed in by parameter. The priorities
|
||
|
|
are returned via pointer parameters.
|
||
|
|
</p>
|
||
|
|
<p><var>insn</var> is the instruction whose priorities need to be calculated.
|
||
|
|
<var>max_pri</var> is the maximum priority can be returned in any cases.
|
||
|
|
<var>fusion_pri</var> is the pointer parameter through which <var>insn</var>’s
|
||
|
|
fusion priority should be calculated and returned.
|
||
|
|
<var>pri</var> is the pointer parameter through which <var>insn</var>’s priority
|
||
|
|
should be calculated and returned.
|
||
|
|
</p>
|
||
|
|
<p>Same <var>fusion_pri</var> should be returned for instructions which should
|
||
|
|
be scheduled together. Different <var>pri</var> should be returned for
|
||
|
|
instructions with same <var>fusion_pri</var>. <var>fusion_pri</var> is the major
|
||
|
|
sort key, <var>pri</var> is the minor sort key. All instructions will be
|
||
|
|
scheduled according to the two priorities. All priorities calculated
|
||
|
|
should be between 0 (exclusive) and <var>max_pri</var> (inclusive). To avoid
|
||
|
|
false dependencies, <var>fusion_pri</var> of instructions which need to be
|
||
|
|
scheduled together should be smaller than <var>fusion_pri</var> of irrelevant
|
||
|
|
instructions.
|
||
|
|
</p>
|
||
|
|
<p>Given below example:
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample"> ldr r10, [r1, 4]
|
||
|
|
add r4, r4, r10
|
||
|
|
ldr r15, [r2, 8]
|
||
|
|
sub r5, r5, r15
|
||
|
|
ldr r11, [r1, 0]
|
||
|
|
add r4, r4, r11
|
||
|
|
ldr r16, [r2, 12]
|
||
|
|
sub r5, r5, r16
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
<p>On targets like ARM/AArch64, the two pairs of consecutive loads should be
|
||
|
|
merged. Since peephole2 pass can’t help in this case unless consecutive
|
||
|
|
loads are actually next to each other in instruction flow. That’s where
|
||
|
|
this scheduling fusion pass works. This hook calculates priority for each
|
||
|
|
instruction based on its fustion type, like:
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample"> ldr r10, [r1, 4] ; fusion_pri=99, pri=96
|
||
|
|
add r4, r4, r10 ; fusion_pri=100, pri=100
|
||
|
|
ldr r15, [r2, 8] ; fusion_pri=98, pri=92
|
||
|
|
sub r5, r5, r15 ; fusion_pri=100, pri=100
|
||
|
|
ldr r11, [r1, 0] ; fusion_pri=99, pri=100
|
||
|
|
add r4, r4, r11 ; fusion_pri=100, pri=100
|
||
|
|
ldr r16, [r2, 12] ; fusion_pri=98, pri=88
|
||
|
|
sub r5, r5, r16 ; fusion_pri=100, pri=100
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
<p>Scheduling fusion pass then sorts all ready to issue instructions according
|
||
|
|
to the priorities. As a result, instructions of same fusion type will be
|
||
|
|
pushed together in instruction flow, like:
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample"> ldr r11, [r1, 0]
|
||
|
|
ldr r10, [r1, 4]
|
||
|
|
ldr r15, [r2, 8]
|
||
|
|
ldr r16, [r2, 12]
|
||
|
|
add r4, r4, r10
|
||
|
|
sub r5, r5, r15
|
||
|
|
add r4, r4, r11
|
||
|
|
sub r5, r5, r16
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
<p>Now peephole2 pass can simply merge the two pairs of loads.
|
||
|
|
</p>
|
||
|
|
<p>Since scheduling fusion pass relies on peephole2 to do real fusion
|
||
|
|
work, it is only enabled by default when peephole2 is in effect.
|
||
|
|
</p>
|
||
|
|
<p>This is firstly introduced on ARM/AArch64 targets, please refer to
|
||
|
|
the hook implementation for how different fusion types are supported.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a name="index-TARGET_005fEXPAND_005fDIVMOD_005fLIBFUNC"></a>Target Hook: <em>void</em> <strong>TARGET_EXPAND_DIVMOD_LIBFUNC</strong> <em>(rtx <var>libfunc</var>, machine_mode <var>mode</var>, rtx <var>op0</var>, rtx <var>op1</var>, rtx *<var>quot</var>, rtx *<var>rem</var>)</em></dt>
|
||
|
|
<dd><p>Define this hook for enabling divmod transform if the port does not have
|
||
|
|
hardware divmod insn but defines target-specific divmod libfuncs.
|
||
|
|
</p></dd></dl>
|
||
|
|
|
||
|
|
<hr>
|
||
|
|
<div class="header">
|
||
|
|
<p>
|
||
|
|
Next: <a href="Sections.html#Sections" accesskey="n" rel="next">Sections</a>, Previous: <a href="Costs.html#Costs" accesskey="p" rel="prev">Costs</a>, Up: <a href="Target-Macros.html#Target-Macros" accesskey="u" rel="up">Target Macros</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|