optimize-options.html

自己收集的linux入门到学懂高级编程书集 包括linux程序设计第三版

     <br><dt><code>-fprofile-generate</code>
     <dd>

     <p>Enable options usually used for instrumenting application to produce
profile useful for later recompilation with profile feedback based
optimization.  You must use <code>-fprofile-generate</code> both when
compiling and when linking your program.

     <p>The following options are enabled: <code>-fprofile-arcs</code>, <code>-fprofile-values</code>, <code>-fvpt</code>.

     <br><dt><code>-fprofile-use</code>
     <dd>Enable profile feedback directed optimizations, and optimizations
generally profitable only with profile feedback available.

     <p>The following options are enabled: <code>-fbranch-probabilities</code>,
<code>-fvpt</code>, <code>-funroll-loops</code>, <code>-fpeel-loops</code>, <code>-ftracer</code>.

   </dl>

   <p>The following options control compiler behavior regarding floating
point arithmetic.  These options trade off between speed and
correctness.  All must be specifically enabled.

     <dl>
<dt><code>-ffloat-store</code>
     <dd>Do not store floating point variables in registers, and inhibit other
options that might change whether a floating point value is taken from a
register or memory.

     <p>This option prevents undesirable excess precision on machines such as
the 68000 where the floating registers (of the 68881) keep more
precision than a <code>double</code> is supposed to have.  Similarly for the
x86 architecture.  For most programs, the excess precision does only
good, but a few programs rely on the precise definition of IEEE floating
point.  Use <code>-ffloat-store</code> for such programs, after modifying
them to store all pertinent intermediate computations into variables.

     <br><dt><code>-ffast-math</code>
     <dd>Sets <code>-fno-math-errno</code>, <code>-funsafe-math-optimizations</code>, <br>
<code>-fno-trapping-math</code>, <code>-ffinite-math-only</code>,
<code>-fno-rounding-math</code> and <code>-fno-signaling-nans</code>.

     <p>This option causes the preprocessor macro <code>__FAST_MATH__</code> to be defined.

     <p>This option should never be turned on by any <code>-O</code> option since
it can result in incorrect output for programs which depend on
an exact implementation of IEEE or ISO rules/specifications for
math functions.

     <br><dt><code>-fno-math-errno</code>
     <dd>Do not set ERRNO after calling math functions that are executed
with a single instruction, e.g., sqrt.  A program that relies on
IEEE exceptions for math error handling may want to use this flag
for speed while maintaining IEEE arithmetic compatibility.

     <p>This option should never be turned on by any <code>-O</code> option since
it can result in incorrect output for programs which depend on
an exact implementation of IEEE or ISO rules/specifications for
math functions.

     <p>The default is <code>-fmath-errno</code>.

     <br><dt><code>-funsafe-math-optimizations</code>
     <dd>Allow optimizations for floating-point arithmetic that (a) assume
that arguments and results are valid and (b) may violate IEEE or
ANSI standards.  When used at link-time, it may include libraries
or startup files that change the default FPU control word or other
similar optimizations.

     <p>This option should never be turned on by any <code>-O</code> option since
it can result in incorrect output for programs which depend on
an exact implementation of IEEE or ISO rules/specifications for
math functions.

     <p>The default is <code>-fno-unsafe-math-optimizations</code>.

     <br><dt><code>-ffinite-math-only</code>
     <dd>Allow optimizations for floating-point arithmetic that assume
that arguments and results are not NaNs or +-Infs.

     <p>This option should never be turned on by any <code>-O</code> option since
it can result in incorrect output for programs which depend on
an exact implementation of IEEE or ISO rules/specifications.

     <p>The default is <code>-fno-finite-math-only</code>.

     <br><dt><code>-fno-trapping-math</code>
     <dd>Compile code assuming that floating-point operations cannot generate
user-visible traps.  These traps include division by zero, overflow,
underflow, inexact result and invalid operation.  This option implies
<code>-fno-signaling-nans</code>.  Setting this option may allow faster
code if one relies on "non-stop" IEEE arithmetic, for example.

     <p>This option should never be turned on by any <code>-O</code> option since
it can result in incorrect output for programs which depend on
an exact implementation of IEEE or ISO rules/specifications for
math functions.

     <p>The default is <code>-ftrapping-math</code>.

     <br><dt><code>-frounding-math</code>
     <dd>Disable transformations and optimizations that assume default floating
point rounding behavior.  This is round-to-zero for all floating point
to integer conversions, and round-to-nearest for all other arithmetic
truncations.  This option should be specified for programs that change
the FP rounding mode dynamically, or that may be executed with a
non-default rounding mode.  This option disables constant folding of
floating point expressions at compile-time (which may be affected by
rounding mode) and arithmetic transformations that are unsafe in the
presence of sign-dependent rounding modes.

     <p>The default is <code>-fno-rounding-math</code>.

     <p>This option is experimental and does not currently guarantee to
disable all GCC optimizations that are affected by rounding mode. 
Future versions of GCC may provide finer control of this setting
using C99's <code>FENV_ACCESS</code> pragma.  This command line option
will be used to specify the default state for <code>FENV_ACCESS</code>.

     <br><dt><code>-fsignaling-nans</code>
     <dd>Compile code assuming that IEEE signaling NaNs may generate user-visible
traps during floating-point operations.  Setting this option disables
optimizations that may change the number of exceptions visible with
signaling NaNs.  This option implies <code>-ftrapping-math</code>.

     <p>This option causes the preprocessor macro <code>__SUPPORT_SNAN__</code> to
be defined.

     <p>The default is <code>-fno-signaling-nans</code>.

     <p>This option is experimental and does not currently guarantee to
disable all GCC optimizations that affect signaling NaN behavior.

     <br><dt><code>-fsingle-precision-constant</code>
     <dd>Treat floating point constant as single precision constant instead of
implicitly converting it to double precision constant.

   </dl>

   <p>The following options control optimizations that may improve
performance, but are not enabled by any <code>-O</code> options.  This
section includes experimental options that may produce broken code.

     <dl>
<dt><code>-fbranch-probabilities</code>
     <dd>After running a program compiled with <code>-fprofile-arcs</code>
(see <a href="Debugging-Options.html#Debugging%20Options">Options for Debugging Your Program or <code>gcc</code></a>), you can compile it a second time using
<code>-fbranch-probabilities</code>, to improve optimizations based on
the number of times each branch was taken.  When the program
compiled with <code>-fprofile-arcs</code> exits it saves arc execution
counts to a file called <code></code><var>sourcename</var><code>.gcda</code> for each source
file  The information in this data file is very dependent on the
structure of the generated code, so you must use the same source code
and the same optimization options for both compilations.

     <p>With <code>-fbranch-probabilities</code>, GCC puts a
<code>REG_BR_PROB</code> note on each <code>JUMP_INSN</code> and <code>CALL_INSN</code>. 
These can be used to improve optimization.  Currently, they are only
used in one place: in <code>reorg.c</code>, instead of guessing which path a
branch is mostly to take, the <code>REG_BR_PROB</code> values are used to
exactly determine which path is taken more often.

     <br><dt><code>-fprofile-values</code>
     <dd>If combined with <code>-fprofile-arcs</code>, it adds code so that some
data about values of expressions in the program is gathered.

     <p>With <code>-fbranch-probabilities</code>, it reads back the data gathered
from profiling values of expressions and adds <code>REG_VALUE_PROFILE</code>
notes to instructions for their later usage in optimizations.

     <p>Enabled with <code>-fprofile-generate</code> and <code>-fprofile-use</code>.

     <br><dt><code>-fvpt</code>
     <dd>If combined with <code>-fprofile-arcs</code>, it instructs the compiler to add
a code to gather information about values of expressions.

     <p>With <code>-fbranch-probabilities</code>, it reads back the data gathered
and actually performs the optimizations based on them. 
Currently the optimizations include specialization of division operation
using the knowledge about the value of the denominator.

     <p>Enabled with <code>-fprofile-generate</code> and <code>-fprofile-use</code>.

     <br><dt><code>-frename-registers</code>
     <dd>Attempt to avoid false dependencies in scheduled code by making use
of registers left over after register allocation.  This optimization
will most benefit processors with lots of registers.  Depending on the
debug information format adopted by the target, however, it can
make debugging impossible, since variables will no longer stay in
a "home register".

     <p>Not enabled by default at any level because it has known bugs.

     <br><dt><code>-fnew-ra</code>
     <dd>Use a graph coloring register allocator.  Currently this option is meant
for testing, so we are interested to hear about miscompilations with
<code>-fnew-ra</code>.

     <br><dt><code>-ftracer</code>
     <dd>Perform tail duplication to enlarge superblock size. This transformation
simplifies the control flow of the function allowing other optimizations to do
better job.

     <p>Enabled with <code>-fprofile-use</code>.

     <br><dt><code>-funroll-loops</code>
     <dd>Unroll loops whose number of iterations can be determined at compile time or
upon entry to the loop.  <code>-funroll-loops</code> implies
<code>-frerun-cse-after-loop</code>.  It also turns on complete loop peeling
(i.e. complete removal of loops with small constant number of iterations). 
This option makes code larger, and may or may not make it run faster.

     <p>Enabled with <code>-fprofile-use</code>.

     <br><dt><code>-funroll-all-loops</code>
     <dd>Unroll all loops, even if their number of iterations is uncertain when
the loop is entered.  This usually makes programs run more slowly. 
<code>-funroll-all-loops</code> implies the same options as
<code>-funroll-loops</code>.

     <br><dt><code>-fpeel-loops</code>
     <dd>Peels the loops for that there is enough information that they do not
roll much (from profile feedback).  It also turns on complete loop peeling
(i.e. complete removal of loops with small constant number of iterations).

     <p>Enabled with <code>-fprofile-use</code>.

     <br><dt><code>-funswitch-loops</code>
     <dd>Move branches with loop invariant conditions out of the loop, with duplicates
of the loop on both branches (modified according to result of the condition).

     <br><dt><code>-fold-unroll-loops</code>
     <dd>Unroll loops whose number of iterations can be determined at compile
time or upon entry to the loop, using the old loop unroller whose loop
recognition is based on notes from frontend.  <code>-fold-unroll-loops</code> implies
both <code>-fstrength-reduce</code> and <code>-frerun-cse-after-loop</code>.  This
option makes code larger, and may or may not make it run faster.

     <br><dt><code>-fold-unroll-all-loops</code>
     <dd>Unroll all loops, even if their number of iterations is uncertain when
the loop is entered. This is done using the old loop unroller whose loop
recognition is based on notes from frontend.  This usually makes programs run more slowly. 
<code>-fold-unroll-all-loops</code> implies the same options as
<code>-fold-unroll-loops</code>.

     <br><dt><code>-fprefetch-loop-arrays</code>
     <dd>If supported by the target machine, generate instructions to prefetch
memory to improve the performance of loops that access large arrays.

     <p>Disabled at level <code>-Os</code>.

     <br><dt><code>-ffunction-sections</code>
     <dd><dt><code>-fdata-sections</code>
     <dd>Place each function or data item into its own section in the output
file if the target supports arbitrary sections.  The name of the
function or the name of the data item determines the section's name
in the output file.

     <p>Use these options on systems where the linker can perform optimizations
to improve locality of reference in the instruction space.  Most systems
using the ELF object format and SPARC processors running Solaris 2 have
linkers with such optimizations.  AIX may have these optimizations in
the future.

     <p>Only use these options when there are significant benefits from doing