invoke.texi

早期freebsd实现

@item -g@var{level}
@itemx -ggdb@var{level}
@itemx -gstabs@var{level}
@itemx -gcoff@var{level}
@itemx -gxcoff@var{level}
@itemx -gdwarf@var{level}
Request debugging information and also use @var{level} to specify how
much information.  The default level is 2.

Level 1 produces minimal information, enough for making backtraces in
parts of the program that you don't plan to debug.  This includes
descriptions of functions and external variables, but no information
about local variables and no line numbers.

Level 3 includes extra information, such as all the macro definitions
present in the program.  Some debuggers support macro expansion when
you use @samp{-g3}.

@cindex @code{prof}
@item -p
Generate extra code to write profile information suitable for the
analysis program @code{prof}.

@cindex @code{gprof}
@item -pg
Generate extra code to write profile information suitable for the
analysis program @code{gprof}.

@cindex @code{tcov}
@item -a
Generate extra code to write profile information for basic blocks,
which will record the number of times each basic block is executed.
This data could be analyzed by a program like @code{tcov}.  Note,
however, that the format of the data is not what @code{tcov} expects.
Eventually GNU @code{gprof} should be extended to process this data.

@item -d@var{letters}
Says to make debugging dumps during compilation at times specified by
@var{letters}.  This is used for debugging the compiler.  The file names
for most of the dumps are made by appending a word to the source file
name (e.g.  @file{foo.c.rtl} or @file{foo.c.jump}).  Here are the
possible letters for use in @var{letters}, and their meanings:

@table @samp
@item M
Dump all macro definitions, at the end of preprocessing, and write no
output.
@item N
Dump all macro names, at the end of preprocessing.
@item D
Dump all macro definitions, at the end of preprocessing, in addition to
normal output.
@item y
Dump debugging information during parsing, to standard error.
@item r
Dump after RTL generation, to @file{@var{file}.rtl}.
@item x
Just generate RTL for a function instead of compiling it.  Usually used
with @samp{r}.
@item j
Dump after first jump optimization, to @file{@var{file}.jump}.
@item s
Dump after CSE (including the jump optimization that sometimes
follows CSE), to @file{@var{file}.cse}.
@item L
Dump after loop optimization, to @file{@var{file}.loop}.
@item t
Dump after the second CSE pass (including the jump optimization that
sometimes follows CSE), to @file{@var{file}.cse2}.
@item f
Dump after flow analysis, to @file{@var{file}.flow}.
@item c
Dump after instruction combination, to @file{@var{file}.combine}.
@item S
Dump after the first instruction scheduling pass, to
@file{@var{file}.sched}.
@item l
Dump after local register allocation, to@*
@file{@var{file}.lreg}.
@item g
Dump after global register allocation, to@*
@file{@var{file}.greg}.
@item R
Dump after the second instruction scheduling pass, to
@file{@var{file}.sched2}.
@item J
Dump after last jump optimization, to @file{@var{file}.jump2}.
@item d
Dump after delayed branch scheduling, to @file{@var{file}.dbr}.
@item k
Dump after conversion from registers to stack, to @file{@var{file}.stack}.
@item a
Produce all the dumps listed above.
@item m
Print statistics on memory usage, at the end of the run, to
standard error.
@item p
Annotate the assembler output with a comment indicating which
pattern and alternative was used.
@end table

@item -fpretend-float
When running a cross-compiler, pretend that the target machine uses the
same floating point format as the host machine.  This causes incorrect
output of the actual floating constants, but the actual instruction
sequence will probably be the same as GNU CC would make when running on
the target machine.

@item -save-temps
Store the usual ``temporary'' intermediate files permanently; place them
in the current directory and name them based on the source file.  Thus,
compiling @file{foo.c} with @samp{-c -save-temps} would produce files
@file{foo.i} and @file{foo.s}, as well as @file{foo.o}.
@end table

@node Optimize Options
@section Options That Control Optimization
@cindex optimize options
@cindex options, optimization

These options control various sorts of optimizations:

@table @code
@item -O
@itemx -O1
Optimize.  Optimizing compilation takes somewhat more time, and a lot
more memory for a large function.

Without @samp{-O}, the compiler's goal is to reduce the cost of
compilation and to make debugging produce the expected results.
Statements are independent: if you stop the program with a breakpoint
between statements, you can then assign a new value to any variable or
change the program counter to any other statement in the function and
get exactly the results you would expect from the source code.

Without @samp{-O}, only variables declared @code{register} are
allocated in registers.  The resulting compiled code is a little worse
than produced by PCC without @samp{-O}.

With @samp{-O}, the compiler tries to reduce code size and execution
time.

When @samp{-O} is specified, @samp{-fthread-jumps} and
@samp{-fdelayed-branch} are turned on.  On some machines other
flags may also be turned on.

@item -O2
Optimize even more.  Nearly all supported optimizations that do not
involve a space-speed tradeoff are performed.  As compared to @samp{-O},
this option increases both compilation time and the performance of the
generated code.

@samp{-O2} turns on all @samp{-f@var{flag}} options that enable more
optimization, except for @samp{-funroll-loops},
@samp{-funroll-all-loops} and @samp{-fomit-frame-pointer}.

@item -O0
Do not optimize.

If you use multiple @samp{-O} options, with or without level numbers,
the last such option is the one that is effective.
@end table

Options of the form @samp{-f@var{flag}} specify machine-independent
flags.  Most flags have both positive and negative forms; the negative
form of @samp{-ffoo} would be @samp{-fno-foo}.  In the table below,
only one of the forms is listed---the one which is not the default.
You can figure out the other form by either removing @samp{no-} or
adding it.

@table @code
@item -ffloat-store
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.

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} is supposed to have.  For most programs,
the excess precision does only good, but a few programs rely on the
precise definition of IEEE floating point.  Use @samp{-ffloat-store} for
such programs.

@item -fno-defer-pop
Always pop the arguments to each function call as soon as that function
returns.  For machines which must pop arguments after a function call,
the compiler normally lets arguments accumulate on the stack for several
function calls and pops them all at once.

@item -fforce-mem
Force memory operands to be copied into registers before doing
arithmetic on them.  This may produce better code by making all
memory references potential common subexpressions.  When they are
not common subexpressions, instruction combination should
eliminate the separate register-load.  I am interested in hearing
about the difference this makes.

@item -fforce-addr
Force memory address constants to be copied into registers before
doing arithmetic on them.  This may produce better code just as
@samp{-fforce-mem} may.  I am interested in hearing about the
difference this makes.

@item -fomit-frame-pointer
Don't keep the frame pointer in a register for functions that
don't need one.  This avoids the instructions to save, set up and
restore frame pointers; it also makes an extra register available
in many functions.  @strong{It also makes debugging impossible on
some machines.}

@ifset INTERNALS
On some machines, such as the Vax, this flag has no effect, because
the standard calling sequence automatically handles the frame pointer
and nothing is saved by pretending it doesn't exist.  The
machine-description macro @code{FRAME_POINTER_REQUIRED} controls
whether a target machine supports this flag.  @xref{Registers}.@refill
@end ifset
@ifclear INTERNALS
On some machines, such as the Vax, this flag has no effect, because
the standard calling sequence automatically handles the frame pointer
and nothing is saved by pretending it doesn't exist.  The
machine-description macro @code{FRAME_POINTER_REQUIRED} controls
whether a target machine supports this flag.  @xref{Registers,,Register
Usage, gcc.info, Using and Porting GCC}.@refill
@end ifclear

@item -fno-inline
Don't pay attention to the @code{inline} keyword.  Normally this option
is used to keep the compiler from expanding any functions inline.
Note that if you are not optimizing, no functions can be expanded inline.

@item -finline-functions
Integrate all simple functions into their callers.  The compiler
heuristically decides which functions are simple enough to be worth
integrating in this way.

If all calls to a given function are integrated, and the function is
declared @code{static}, then the function is normally not output as
assembler code in its own right.

@item -fkeep-inline-functions
Even if all calls to a given function are integrated, and the function
is declared @code{static}, nevertheless output a separate run-time
callable version of the function.

@item -fno-default-inline
Don't make member functions inline by default merely because they are
defined inside the class scope (C++ only).

@item -fno-function-cse
Do not put function addresses in registers; make each instruction that
calls a constant function contain the function's address explicitly.

This option results in less efficient code, but some strange hacks
that alter the assembler output may be confused by the optimizations
performed when this option is not used.

@item -ffast-math
This option allows GCC to violate some ANSI or IEEE rules/specifications
in the interest of optimizing code for speed.  For example, it allows
the compiler to assume arguments to the @code{sqrt} function are 
non-negative numbers.  

This option should never be turned on by any @samp{-O} option since 
it can result in incorrect output for programs which depend on 
an exact implementation of IEEE or ANSI rules/specifications for
math functions.

@item -felide-constructors
Elide constructors when this seems plausible (C++ only).  With this
option, GNU C++ initializes @code{y} directly from the call to @code{foo}
without going through a temporary in the following code:

@example
A foo ();
A y = foo ();
@end example

Without this option, GNU C++ first initializes @code{y} by calling the
appropriate constructor for type @code{A}; then assigns the result of
@code{foo} to a temporary; and, finally, replaces the initial value of
@code{y} with the temporary.

The default behavior (@samp{-fno-elide-constructors}) is specified by
the draft ANSI C++ standard.  If your program's constructors have side
effects, @samp{-felide-constructors} can change your program's behavior,
since some constructor calls may be omitted.

@item -fmemoize-lookups
@itemx -fsave-memoized
Use heuristics to compile faster (C++ only).  These heuristics are not
enabled by default, since they are only effective for certain input
files.  Other input files compile more slowly.

The first time the compiler must build a call to a member function (or
reference to a data member), it must (1) determine whether the class
implements member functions of that name; (2) resolve which member
function to call (which involves figuring out what sorts of type
conversions need to be made); and (3) check the visibility of the member
function to the caller.  All of this adds up to slower compilation.
Normally, the second time a call is made to that member function (or
reference to that data member), it must go through the same lengthy
process again.  This means that code like this

@example
cout << "This " << p << " has " << n << " legs.\n";
@end example

@noindent
makes six passes through all three steps.  By using a software cache, a
``hit'' significantly reduces this cost.  Unfortunately, using the cache
introduces another layer of mechanisms which must be implemented, and so
incurs its own overhead.  `-fmemoize-lookups' enables the software
cache.

Because access privileges (visibility) to members and member functions
may differ from one function context to the next, G++ may need to flush
the cache.  With the @samp{-fmemoize-lookups} flag, the cache is flushed
after every function that is compiled.  The @samp{-fsave-memoized} flag
enables the same software cache, but when the compiler determines that
the context of the last function compiled would yield the same access
privileges of the next function to compile, it preserves the cache.
This is most helpful when defining many member functions for the same
class: with the exception of member functions which are friends of other
classes, each member function has exactly the same access privileges as
every other, and the cache need not be flushed.
@end table

The following options control specific optimizations.  The @samp{-O2}
option turns on all of these optimizations except @samp{-funroll-loops}
and @samp{-funroll-all-loops}.  The @samp{-O} option usually turns on
the @samp{-fthread-jumps} and @samp{-fdelayed-branch} options, but
specific machines may change the default optimizations.

You can use the following flags in the rare cases when ``fine-tuning''
of optimizations to be performed is desired.

@table @code
@item -fstrength-reduce
Perform the optimizations of loop strength reduction and
elimination of iteration variables.

@item -fthread-jumps
Perform optimizations where we check to see if a jump branches to a
location where another comparison subsumed by the first is found.  If
so, the first branch is redirected to either the destination of the