+2004-09-11 Kazu Hirata <kazu@cs.umass.edu>
+
+ * doc/cfg.texi, doc/hostconfig.texi, doc/install.texi,
+ doc/invoke.texi, doc/md.texi, doc/tm.texi, doc/tree-ssa.texi:
+ Insert @: after i.e. or e.g.
+
2004-09-10 Geoffrey Keating <geoffk@apple.com>
* tree-pretty-print.c (dump_decl_name): Print unnamed decls as
Each edge also contains a branch probability field: an integer in the
range from 0 to @code{REG_BR_PROB_BASE}. It represents probability of
passing control from the end of the @code{src} basic block to the
-@code{dest} basic block, i.e. the probability that control will flow
+@code{dest} basic block, i.e.@: the probability that control will flow
along this edge. The @code{EDGE_FREQUENCY} macro is available to
compute how frequently a given edge is taken. There is a @code{count}
field for each edge as well, representing same information as for a
It is also possible that a pass has to insert control flow instruction
into the middle of a basic block, thus creating an entry point in the
middle of the basic block, which is impossible by definition: The
-block must be split to make sure it only has one entry point, i.e. the
+block must be split to make sure it only has one entry point, i.e.@: the
head of the basic block. In the RTL representation, the
@code{find_sub_basic_blocks} may be used to split existing basic block
and add necessary edges. The CFG hook @code{split_block} may be used
@section Liveness information
@cindex Liveness representation
Liveness information is useful to determine whether some register is
-``live'' at given point of program, i.e. that it contains a value that
+``live'' at given point of program, i.e.@: that it contains a value that
may be used at a later point in the program. This information is
used, for instance, during register allocation, as the pseudo
registers only need to be assigned to a unique hard register or to a
string must fit in fifteen bytes. The full filename will be the
concatenation of: the prefix of the assembler file name, the string
resulting from applying this format to an index number, and a string
-unique to each dump file kind, e.g. @samp{rtl}.
+unique to each dump file kind, e.g.@: @samp{rtl}.
If you do not define this macro, GCC will use @samp{.%02d.}. You should
define this macro if using the default will create an invalid file name.
@samp{libgcj}. If this option is unspecified or disabled, AWT
will be non-functional. Current valid values are @option{gtk} and
@option{xlib}. Multiple libraries should be separated by a
-comma (i.e. @option{--enable-java-awt=gtk,xlib}).
+comma (i.e.@: @option{--enable-java-awt=gtk,xlib}).
@item --enable-gtk-cairo
Build the cairo Graphics2D implementation on GTK.
the GNU compiler (especially GCC 3.0.x versions), which lead to the
miscompilation of the stage1 compiler and the subsequent failure of the
bootstrap process. A workaround is to use GCC 3.2.3 as an intermediary
-stage, i.e. to bootstrap that compiler with the base compiler and then
+stage, i.e.@: to bootstrap that compiler with the base compiler and then
use it to bootstrap the final compiler.
GCC 3.4 triggers a code generation bug in versions 5.4 (Sun ONE Studio 7)
@var{auxname} is generated from the name of the output file, if
explicitly specified and it is not the final executable, otherwise it is
the basename of the source file. In both cases any suffix is removed
-(e.g. @file{foo.gcda} for input file @file{dir/foo.c}, or
+(e.g.@: @file{foo.gcda} for input file @file{dir/foo.c}, or
@file{dir/foo.gcda} for output file specified as @option{-o dir/foo.o}).
@itemize
Attempt to merge identical constants and identical variables.
This option implies @option{-fmerge-constants}. In addition to
-@option{-fmerge-constants} this considers e.g. even constant initialized
+@option{-fmerge-constants} this considers e.g.@: even constant initialized
arrays or initialized constant variables with integral or floating point
types. Languages like C or C++ require each non-automatic variable to
have distinct location, so using this option will result in non-conforming
Unroll loops whose number of iterations can be determined at compile time or
upon entry to the loop. @option{-funroll-loops} implies
@option{-frerun-cse-after-loop}. It also turns on complete loop peeling
-(i.e. complete removal of loops with small constant number of iterations).
+(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.
Enabled with @option{-fprofile-use}.
@opindex fpeel-loops
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).
+(i.e.@: complete removal of loops with small constant number of iterations).
Enabled with @option{-fprofile-use}.
Beside the different backchain location @option{-mkernel-backchain}
also changes stack frame layout breaking the ABI. This option
is intended to be used for code which internally needs a backchain but has
-to get by with a limited stack size e.g. the linux kernel.
+to get by with a limited stack size e.g.@: the linux kernel.
Internal unwinding code not using DWARF-2 info has to be able to locate the
return address of a function. That will be eased be the fact that
the return address of a function is placed two words below the backchain
this is a compile time check it doesn't need to be a real problem when the program
runs. It is intended to identify functions which most probably cause
a stack overflow. It is useful to be used in an environment with limited stack
-size e.g. the linux kernel.
+size e.g.@: the linux kernel.
@item -mwarn-dynamicstack
@opindex mwarn-dynamicstack
execution if its issue conditions are satisfied. If not, the
instruction is stalled until its conditions are satisfied. Such
@dfn{interlock (pipeline) delay} causes interruption of the fetching
-of successor instructions (or demands nop instructions, e.g. for some
+of successor instructions (or demands nop instructions, e.g.@: for some
MIPS processors).
There are two major kinds of interlock delays in modern processors.
constant. In most cases this approach is adequate. The second kind
of interlock delays is a reservation delay. The reservation delay
means that two instructions under execution will be in need of shared
-processors resources, i.e. buses, internal registers, and/or
+processors resources, i.e.@: buses, internal registers, and/or
functional units, which are reserved for some time. Taking this kind
of delay into account is complex especially for modern @acronym{RISC}
processors.
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
+be used for future code generation goals (e.g.@: to generate
@acronym{VLIW} insn templates).
@smallexample
defines an additional guard for the bypass. The function will get the
two insns as parameters. If the function returns zero the bypass will
be ignored for this case. The additional guard is necessary to
-recognize complicated bypasses, e.g. when the consumer is only an address
+recognize complicated bypasses, e.g.@: when the consumer is only an address
of insn @samp{store} (not a stored value).
@findex exclusion_set
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
example, the construction is useful for describing processors
-(e.g. some SPARC processors) with a fully pipelined floating point
+(e.g.@: some SPARC processors) with a fully pipelined floating point
functional unit which can execute simultaneously only single floating
point insns or only double floating point insns.
are issued into the second pipeline. Integer division and
multiplication insns can be executed only in the second integer
pipeline and their results are ready correspondingly in 8 and 4
-cycles. The integer division is not pipelined, i.e. the subsequent
+cycles. The integer division is not pipelined, i.e.@: the subsequent
integer division insn can not be issued until the current division
insn finished. Floating point insns are fully pipelined and their
results are ready in 3 cycles. Where the result of a floating point
@defmac ENABLE_EXECUTE_STACK
Define this macro if certain operations must be performed before executing
code located on the stack. The macro should expand to a series of C
-file-scope constructs (e.g. functions) and provide a unique entry point
+file-scope constructs (e.g.@: functions) and provide a unique entry point
named @code{__enable_execute_stack}. The target is responsible for
emitting calls to the entry point in the code, for example from the
@code{INITIALIZE_TRAMPOLINE} macro.
is the verbose level provided by @option{-fsched-verbose-@var{n}}.
@var{max_ready} 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}.
+scratch space if it is needed, e.g.@: by @samp{TARGET_SCHED_REORDER}.
@end deftypefn
@deftypefn {Target Hook} void TARGET_SCHED_FINISH (FILE *@var{file}, int @var{verbose})
the behavior to the default.
A subtlety for Microsoft Visual C/C++ style bit-field packing
-(e.g. -mms-bitfields) for targets that support it:
+(e.g.@: -mms-bitfields) for targets that support it:
When a bit-field is inserted into a packed record, the whole size
of the underlying type is used by one or more same-size adjacent
bit-fields (that is, if its long:3, 32 bits is used in the record,
This target hook returns @code{true} if it is safe to use a local alias
for a virtual function @var{fndecl} when constructing thunks,
@code{false} otherwise. By default, the hook returns @code{true} for all
-functions, if a target supports aliases (i.e. defines
+functions, if a target supports aliases (i.e.@: defines
@code{ASM_OUTPUT_DEF}), @code{false} otherwise,
@end deftypefn
In general, expressions in GIMPLE consist of an operation and the
appropriate number of simple operands; these operands must either be a
-GIMPLE rvalue (@code{is_gimple_val}), i.e. a constant or a register
+GIMPLE rvalue (@code{is_gimple_val}), i.e.@: a constant or a register
variable. More complex operands are factored out into temporaries, so
that
@smallexample
a statement whether a variable of these types has a killing definition.
If the variable does, then the statement is marked as having a
@dfn{must definition} of that variable. However, if a statement is only
-defining a part of the variable (i.e. a field in a structure), or if we
+defining a part of the variable (i.e.@: a field in a structure), or if we
know that a statement might define the variable but we cannot say for sure,
then we mark that statement as having a @dfn{may definition}. For
instance, given
projects / gcc.git / commitdiff