@c Copyright (C) 1988, 1989, 1992, 1994, 1997, 1998, 1999, 2000, 2001, 2002,
-@c 2003, 2004, 2005, 2006, 2007, 2008
+@c 2003, 2004, 2005, 2006, 2007, 2008, 2010
@c Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
@cindex representation of RTL
@cindex Register Transfer Language (RTL)
-Most of the work of the compiler is done on an intermediate representation
-called register transfer language. In this language, the instructions to be
-output are described, pretty much one by one, in an algebraic form that
-describes what the instruction does.
+The last part of the compiler work is done on a low-level intermediate
+representation called Register Transfer Language. In this language, the
+instructions to be output are described, pretty much one by one, in an
+algebraic form that describes what the instruction does.
RTL is inspired by Lisp lists. It has both an internal form, made up of
structures that point at other structures, and a textual form that is used
* Side Effects:: Expressions for storing in registers, etc.
* Incdec:: Embedded side-effects for autoincrement addressing.
* Assembler:: Representing @code{asm} with operands.
+* Debug Information:: Expressions representing debugging information.
* Insns:: Expression types for entire insns.
* Calls:: RTL representation of function call insns.
* Sharing:: Some expressions are unique; others *must* be copied.
@item RTX_TERNARY
An RTX code for other three input operations. Currently only
-@code{IF_THEN_ELSE} and @code{VEC_MERGE}.
+@code{IF_THEN_ELSE}, @code{VEC_MERGE}, @code{SIGN_EXTRACT},
+@code{ZERO_EXTRACT}, and @code{FMA}.
@item RTX_INSN
An RTX code for an entire instruction: @code{INSN}, @code{JUMP_INSN}, and
@findex MEM_ALIGN
@item MEM_ALIGN (@var{x})
The known alignment in bits of the memory reference.
+
+@findex MEM_ADDR_SPACE
+@item MEM_ADDR_SPACE (@var{x})
+The address space of the memory reference. This will commonly be zero
+for the generic address space.
@end table
@item REG
@findex RTL_CONST_CALL_P
@cindex @code{call_insn} and @samp{/u}
@cindex @code{unchanging}, in @code{call_insn}
-@item RTLCONST_OR_PURE_CALL_P (@var{x})
+@item RTL_CONST_CALL_P (@var{x})
In a @code{call_insn} indicates that the insn represents a call to a
const function. Stored in the @code{unchanging} field and printed as
@samp{/u}.
@findex RTL_PURE_CALL_P
@cindex @code{call_insn} and @samp{/i}
@cindex @code{return_val}, in @code{call_insn}
-@item RTLCONST_OR_PURE_CALL_P (@var{x})
+@item RTL_PURE_CALL_P (@var{x})
In a @code{call_insn} indicates that the insn represents a call to a
pure function. Stored in the @code{return_val} field and printed as
@samp{/i}.
Most uses of @code{SYMBOL_REF_FLAG} are historic and may be subsumed
by @code{SYMBOL_REF_FLAGS}. Certainly use of @code{SYMBOL_REF_FLAGS}
is mandatory if the target requires more than one bit of storage.
+
+@findex PREFETCH_SCHEDULE_BARRIER_P
+@cindex @code{prefetch} and @samp{/v}
+@cindex @code{volatile}, in @code{prefetch}
+@item PREFETCH_SCHEDULE_BARRIER_P (@var{x})
+In a @code{prefetch}, indicates that the prefetch is a scheduling barrier.
+No other INSNs will be moved over it.
+Stored in the @code{volatil} field and printed as @samp{/v}.
@end table
These are the fields to which the above macros refer:
In @code{label_ref} and @code{reg_label} expressions, 1 means a reference
to a non-local label.
+In @code{prefetch} expressions, 1 means that the containing insn is a
+scheduling barrier.
+
In an RTL dump, this flag is represented as @samp{/v}.
@end table
is a machine-specific set of bits used to represent the result of a
comparison operation. Other machine-specific modes may also be used for
the condition code. These modes are not used on machines that use
-@code{cc0} (see @pxref{Condition Code}).
+@code{cc0} (@pxref{Condition Code}).
@findex BLKmode
@item BLKmode
@code{constm1_rtx} will point to the same object.
@findex const_double
-@item (const_double:@var{m} @var{addr} @var{i0} @var{i1} @dots{})
+@item (const_double:@var{m} @var{i0} @var{i1} @dots{})
Represents either a floating-point constant of mode @var{m} or an
integer constant too large to fit into @code{HOST_BITS_PER_WIDE_INT}
bits but small enough to fit within twice that number of bits (GCC
does not provide a mechanism to represent even larger constants). In
the latter case, @var{m} will be @code{VOIDmode}.
+@findex CONST_DOUBLE_LOW
+If @var{m} is @code{VOIDmode}, the bits of the value are stored in
+@var{i0} and @var{i1}. @var{i0} is customarily accessed with the macro
+@code{CONST_DOUBLE_LOW} and @var{i1} with @code{CONST_DOUBLE_HIGH}.
+
+If the constant is floating point (regardless of its precision), then
+the number of integers used to store the value depends on the size of
+@code{REAL_VALUE_TYPE} (@pxref{Floating Point}). The integers
+represent a floating point number, but not precisely in the target
+machine's or host machine's floating point format. To convert them to
+the precise bit pattern used by the target machine, use the macro
+@code{REAL_VALUE_TO_TARGET_DOUBLE} and friends (@pxref{Data Output}).
+
@findex const_fixed
-@item (const_fixed:@var{m} @var{addr})
+@item (const_fixed:@var{m} @dots{})
Represents a fixed-point constant of mode @var{m}.
-The data structure, which contains data with the size of two
-@code{HOST_BITS_PER_WIDE_INT} and the associated fixed-point mode,
-is access with the macro @code{CONST_FIXED_VALUE}. The high part of data
-is accessed with @code{CONST_FIXED_VALUE_HIGH}; the low part is accessed
-with @code{CONST_FIXED_VALUE_LOW}.
+The operand is a data structure of type @code{struct fixed_value} and
+is accessed with the macro @code{CONST_FIXED_VALUE}. The high part of
+data is accessed with @code{CONST_FIXED_VALUE_HIGH}; the low part is
+accessed with @code{CONST_FIXED_VALUE_LOW}.
@findex const_vector
@item (const_vector:@var{m} [@var{x0} @var{x1} @dots{}])
Represents a vector constant. The square brackets stand for the vector
containing the constant elements. @var{x0}, @var{x1} and so on are
-the @code{const_int} or @code{const_double} elements.
+the @code{const_int}, @code{const_double} or @code{const_fixed} elements.
The number of units in a @code{const_vector} is obtained with the macro
@code{CONST_VECTOR_NUNITS} as in @code{CONST_VECTOR_NUNITS (@var{v})}.
where @var{v} is the vector constant and @var{n} is the element
desired.
-@findex CONST_DOUBLE_MEM
-@findex CONST_DOUBLE_CHAIN
-@var{addr} is used to contain the @code{mem} expression that corresponds
-to the location in memory that at which the constant can be found. If
-it has not been allocated a memory location, but is on the chain of all
-@code{const_double} expressions in this compilation (maintained using an
-undisplayed field), @var{addr} contains @code{const0_rtx}. If it is not
-on the chain, @var{addr} contains @code{cc0_rtx}. @var{addr} is
-customarily accessed with the macro @code{CONST_DOUBLE_MEM} and the
-chain field via @code{CONST_DOUBLE_CHAIN}.
-
-@findex CONST_DOUBLE_LOW
-If @var{m} is @code{VOIDmode}, the bits of the value are stored in
-@var{i0} and @var{i1}. @var{i0} is customarily accessed with the macro
-@code{CONST_DOUBLE_LOW} and @var{i1} with @code{CONST_DOUBLE_HIGH}.
-
-If the constant is floating point (regardless of its precision), then
-the number of integers used to store the value depends on the size of
-@code{REAL_VALUE_TYPE} (@pxref{Floating Point}). The integers
-represent a floating point number, but not precisely in the target
-machine's or host machine's floating point format. To convert them to
-the precise bit pattern used by the target machine, use the macro
-@code{REAL_VALUE_TO_TARGET_DOUBLE} and friends (@pxref{Data Output}).
-
-@findex CONST0_RTX
-@findex CONST1_RTX
-@findex CONST2_RTX
-The macro @code{CONST0_RTX (@var{mode})} refers to an expression with
-value 0 in mode @var{mode}. If mode @var{mode} is of mode class
-@code{MODE_INT}, it returns @code{const0_rtx}. If mode @var{mode} is of
-mode class @code{MODE_FLOAT}, it returns a @code{CONST_DOUBLE}
-expression in mode @var{mode}. Otherwise, it returns a
-@code{CONST_VECTOR} expression in mode @var{mode}. Similarly, the macro
-@code{CONST1_RTX (@var{mode})} refers to an expression with value 1 in
-mode @var{mode} and similarly for @code{CONST2_RTX}. The
-@code{CONST1_RTX} and @code{CONST2_RTX} macros are undefined
-for vector modes.
-
@findex const_string
@item (const_string @var{str})
Represents a constant string with value @var{str}. Currently this is
The @code{label_ref} contains a mode, which is usually @code{Pmode}.
Usually that is the only mode for which a label is directly valid.
+@findex const
@item (const:@var{m} @var{exp})
Represents a constant that is the result of an assembly-time
arithmetic computation. The operand, @var{exp}, is an expression that
@var{m} should be @code{Pmode}.
@end table
+@findex CONST0_RTX
+@findex CONST1_RTX
+@findex CONST2_RTX
+The macro @code{CONST0_RTX (@var{mode})} refers to an expression with
+value 0 in mode @var{mode}. If mode @var{mode} is of mode class
+@code{MODE_INT}, it returns @code{const0_rtx}. If mode @var{mode} is of
+mode class @code{MODE_FLOAT}, it returns a @code{CONST_DOUBLE}
+expression in mode @var{mode}. Otherwise, it returns a
+@code{CONST_VECTOR} expression in mode @var{mode}. Similarly, the macro
+@code{CONST1_RTX (@var{mode})} refers to an expression with value 1 in
+mode @var{mode} and similarly for @code{CONST2_RTX}. The
+@code{CONST1_RTX} and @code{CONST2_RTX} macros are undefined
+for vector modes.
+
@node Regs and Memory
@section Registers and Memory
@cindex RTL register expressions
a multi-part @code{reg} that actually refers to several registers.
Each pseudo register has a natural mode. If it is necessary to
-operate on it in a different mode, the pseudo register must be
+operate on it in a different mode, the register must be
enclosed in a @code{subreg}.
+There are currently three supported types for the first operand of a
+@code{subreg}:
+@itemize
+@item pseudo registers
+This is the most common case. Most @code{subreg}s have pseudo
+@code{reg}s as their first operand.
+
+@item mem
+@code{subreg}s of @code{mem} were common in earlier versions of GCC and
+are still supported. During the reload pass these are replaced by plain
+@code{mem}s. On machines that do not do instruction scheduling, use of
+@code{subreg}s of @code{mem} are still used, but this is no longer
+recommended. Such @code{subreg}s are considered to be
+@code{register_operand}s rather than @code{memory_operand}s before and
+during reload. Because of this, the scheduling passes cannot properly
+schedule instructions with @code{subreg}s of @code{mem}, so for machines
+that do scheduling, @code{subreg}s of @code{mem} should never be used.
+To support this, the combine and recog passes have explicit code to
+inhibit the creation of @code{subreg}s of @code{mem} when
+@code{INSN_SCHEDULING} is defined.
+
+The use of @code{subreg}s of @code{mem} after the reload pass is an area
+that is not well understood and should be avoided. There is still some
+code in the compiler to support this, but this code has possibly rotted.
+This use of @code{subreg}s is discouraged and will most likely not be
+supported in the future.
+
+@item hard registers
It is seldom necessary to wrap hard registers in @code{subreg}s; such
registers would normally reduce to a single @code{reg} rtx. This use of
-@code{subregs} is discouraged and may not be supported in the future.
+@code{subreg}s is discouraged and may not be supported in the future.
+
+@end itemize
+
+@code{subreg}s of @code{subreg}s are not supported. Using
+@code{simplify_gen_subreg} is the recommended way to avoid this problem.
@code{subreg}s come in two distinct flavors, each having its own
usage and rules:
@end smallexample
Paradoxical @code{subreg}s can be used as both lvalues and rvalues.
+When used as an lvalue, the low-order bits of the source value
+are stored in @var{reg} and the high-order bits are discarded.
When used as an rvalue, the low-order bits of the @code{subreg} are
-taken from @var{reg} while the high-order bits are left undefined.
-When used as an lvalue, the low-order bits of the source value are
-stored in @var{reg} and the high-order bits are discarded.
+taken from @var{reg} while the high-order bits may or may not be
+defined.
+
+The high-order bits of rvalues are in the following circumstances:
+
+@itemize
+@item @code{subreg}s of @code{mem}
+When @var{m2} is smaller than a word, the macro @code{LOAD_EXTEND_OP},
+can control how the high-order bits are defined.
+
+@item @code{subreg} of @code{reg}s
+The upper bits are defined when @code{SUBREG_PROMOTED_VAR_P} is true.
+@code{SUBREG_PROMOTED_UNSIGNED_P} describes what the upper bits hold.
+Such subregs usually represent local variables, register variables
+and parameter pseudo variables that have been promoted to a wider mode.
+
+@end itemize
@var{bytenum} is always zero for a paradoxical @code{subreg}, even on
big-endian targets.
(set @var{z} (subreg:SI (reg:HI @var{x}) 0))
@end smallexample
-would set the lower two bytes of @var{z} to @var{y} and set the upper two
-bytes to an unknown value.
+would set the lower two bytes of @var{z} to @var{y} and set the upper
+two bytes to an unknown value assuming @code{SUBREG_PROMOTED_VAR_P} is
+false.
@item Normal subregs
When @var{m1} is at least as narrow as @var{m2} the @code{subreg}
expression is called @dfn{normal}.
-Normal @code{subreg}s restrict consideration to certain bits of @var{reg}.
-There are two cases. If @var{m1} is smaller than a word, the
-@code{subreg} refers to the least-significant part (or @dfn{lowpart})
-of one word of @var{reg}. If @var{m1} is word-sized or greater, the
-@code{subreg} refers to one or more complete words.
+Normal @code{subreg}s restrict consideration to certain bits of
+@var{reg}. There are two cases. If @var{m1} is smaller than a word,
+the @code{subreg} refers to the least-significant part (or
+@dfn{lowpart}) of one word of @var{reg}. If @var{m1} is word-sized or
+greater, the @code{subreg} refers to one or more complete words.
When used as an lvalue, @code{subreg} is a word-based accessor.
Storing to a @code{subreg} modifies all the words of @var{reg} that
with the @code{SUBREG_REG} macro and the second operand is customarily
accessed with the @code{SUBREG_BYTE} macro.
-@code{subreg}s of @code{subreg}s are not supported. Using
-@code{simplify_gen_subreg} is the recommended way to avoid this problem.
-
It has been several years since a platform in which
-@code{BYTES_BIG_ENDIAN} was not equal to @code{WORDS_BIG_ENDIAN} has
+@code{BYTES_BIG_ENDIAN} not equal to @code{WORDS_BIG_ENDIAN} has
been tested. Anyone wishing to support such a platform in the future
may be confronted with code rot.
other memories. Thus it may be used as a memory barrier in epilogue
stack deallocation patterns.
-@findex addressof
-@item (addressof:@var{m} @var{reg})
-This RTX represents a request for the address of register @var{reg}. Its mode
-is always @code{Pmode}. If there are any @code{addressof}
-expressions left in the function after CSE, @var{reg} is forced into the
-stack and the @code{addressof} expression is replaced with a @code{plus}
-expression for the address of its stack slot.
-
@findex concat
@item (concat@var{m} @var{rtx} @var{rtx})
This RTX represents the concatenation of two other RTXs. This is used
For unsigned widening multiplication, use the same idiom, but with
@code{zero_extend} instead of @code{sign_extend}.
+@findex fma
+@item (fma:@var{m} @var{x} @var{y} @var{z})
+Represents the @code{fma}, @code{fmaf}, and @code{fmal} builtin
+functions that do a combined multiply of @var{x} and @var{y} and then
+adding to@var{z} without doing an intermediate rounding step.
+
@findex div
@findex ss_div
@cindex division
use @code{rotate}.
@findex abs
+@findex ss_abs
@cindex absolute value
@item (abs:@var{m} @var{x})
+@item (ss_abs:@var{m} @var{x})
Represents the absolute value of @var{x}, computed in mode @var{m}.
+@code{ss_abs} ensures that an out-of-bounds result saturates to the
+maximum signed value.
+
@findex sqrt
@cindex square root
@findex vec_select
@item (vec_select:@var{m} @var{vec1} @var{selection})
This describes an operation that selects parts of a vector. @var{vec1} is
-the source vector, @var{selection} is a @code{parallel} that contains a
+the source vector, and @var{selection} is a @code{parallel} that contains a
@code{const_int} for each of the subparts of the result vector, giving the
-number of the source subpart that should be stored into it.
+number of the source subpart that should be stored into it.
+The result mode @var{m} is either the submode for a single element of
+@var{vec1} (if only one subpart is selected), or another vector mode
+with that element submode (if multiple subparts are selected).
@findex vec_concat
@item (vec_concat:@var{m} @var{vec1} @var{vec2})
@findex fix
@item (fix:@var{m} @var{x})
-When @var{m} is a fixed point mode, represents the result of
+When @var{m} is a floating-point mode, represents the result of
+converting floating point value @var{x} (valid for mode @var{m}) to an
+integer, still represented in floating point mode @var{m}, by rounding
+towards zero.
+
+When @var{m} is a fixed-point mode, represents the result of
converting floating point value @var{x} to mode @var{m}, regarded as
signed. How rounding is done is not specified, so this operation may
be used validly in compiling C code only for integer-valued operands.
fixed point mode @var{m}, regarded as unsigned. How rounding is done
is not specified.
-@findex fix
-@item (fix:@var{m} @var{x})
-When @var{m} is a floating point mode, represents the result of
-converting floating point value @var{x} (valid for mode @var{m}) to an
-integer, still represented in floating point mode @var{m}, by rounding
-towards zero.
-
@findex fract_convert
@item (fract_convert:@var{m} @var{x})
Represents the result of converting fixed-point value @var{x} to
When a @code{clobber} expression for a register appears inside a
@code{parallel} with other side effects, the register allocator
guarantees that the register is unoccupied both before and after that
-insn. However, the reload phase may allocate a register used for one of
-the inputs unless the @samp{&} constraint is specified for the selected
-alternative (@pxref{Modifiers}). You can clobber either a specific hard
+insn if it is a hard register clobber. For pseudo-register clobber,
+the register allocator and the reload pass do not assign the same hard
+register to the clobber and the input operands if there is an insn
+alternative containing the @samp{&} constraint (@pxref{Modifiers}) for
+the clobber and the hard register is in register classes of the
+clobber in the alternative. You can clobber either a specific hard
register, a pseudo register, or a @code{scratch} expression; in the
latter two cases, GCC will allocate a hard register that is available
there for use as a temporary.
In some situations, it may be tempting to add a @code{use} of a
register in a @code{parallel} to describe a situation where the value
of a special register will modify the behavior of the instruction.
-An hypothetical example might be a pattern for an addition that can
+A hypothetical example might be a pattern for an addition that can
either wrap around or use saturating addition depending on the value
of a special control register:
@var{m} must be the machine mode for pointers on the machine in use.
The expression @var{y} must be one of three forms:
-@table @code
@code{(plus:@var{m} @var{x} @var{z})},
@code{(minus:@var{m} @var{x} @var{z})}, or
@code{(plus:@var{m} @var{x} @var{i})},
-@end table
where @var{z} is an index register and @var{i} is a constant.
Here is an example of its use:
When an @code{asm} statement has multiple output values, its insn has
several such @code{set} RTX's inside of a @code{parallel}. Each @code{set}
-contains a @code{asm_operands}; all of these share the same assembler
+contains an @code{asm_operands}; all of these share the same assembler
template and vectors, but each contains the constraint for the respective
output operand. They are also distinguished by the output-operand index
number, which is 0, 1, @dots{} for successive output operands.
+@node Debug Information
+@section Variable Location Debug Information in RTL
+@cindex Variable Location Debug Information in RTL
+
+Variable tracking relies on @code{MEM_EXPR} and @code{REG_EXPR}
+annotations to determine what user variables memory and register
+references refer to.
+
+Variable tracking at assignments uses these notes only when they refer
+to variables that live at fixed locations (e.g., addressable
+variables, global non-automatic variables). For variables whose
+location may vary, it relies on the following types of notes.
+
+@table @code
+@findex var_location
+@item (var_location:@var{mode} @var{var} @var{exp} @var{stat})
+Binds variable @code{var}, a tree, to value @var{exp}, an RTL
+expression. It appears only in @code{NOTE_INSN_VAR_LOCATION} and
+@code{DEBUG_INSN}s, with slightly different meanings. @var{mode}, if
+present, represents the mode of @var{exp}, which is useful if it is a
+modeless expression. @var{stat} is only meaningful in notes,
+indicating whether the variable is known to be initialized or
+uninitialized.
+
+@findex debug_expr
+@item (debug_expr:@var{mode} @var{decl})
+Stands for the value bound to the @code{DEBUG_EXPR_DECL} @var{decl},
+that points back to it, within value expressions in
+@code{VAR_LOCATION} nodes.
+
+@end table
+
@node Insns
@section Insns
@cindex insns
insn in the @code{sequence} expression. You can use these expressions
to find the containing @code{sequence} expression.
-Every insn has one of the following six expression codes:
+Every insn has one of the following expression codes:
@table @code
@findex insn
Appears at the start of the function body, after the function
prologue.
+@findex NOTE_INSN_VAR_LOCATION
+@findex NOTE_VAR_LOCATION
+@item NOTE_INSN_VAR_LOCATION
+This note is used to generate variable location debugging information.
+It indicates that the user variable in its @code{VAR_LOCATION} operand
+is at the location given in the RTL expression, or holds a value that
+can be computed by evaluating the RTL expression from that static
+point in the program up to the next such note for the same user
+variable.
+
@end table
These codes are printed symbolically when they appear in debugging dumps.
+
+@findex debug_insn
+@findex INSN_VAR_LOCATION
+@item debug_insn
+The expression code @code{debug_insn} is used for pseudo-instructions
+that hold debugging information for variable tracking at assignments
+(see @option{-fvar-tracking-assignments} option). They are the RTL
+representation of @code{GIMPLE_DEBUG} statements
+(@ref{@code{GIMPLE_DEBUG}}), with a @code{VAR_LOCATION} operand that
+binds a user variable tree to an RTL representation of the
+@code{value} in the corresponding statement. A @code{DEBUG_EXPR} in
+it stands for the value bound to the corresponding
+@code{DEBUG_EXPR_DECL}.
+
+Throughout optimization passes, binding information is kept in
+pseudo-instruction form, so that, unlike notes, it gets the same
+treatment and adjustments that regular instructions would. It is the
+variable tracking pass that turns these pseudo-instructions into var
+location notes, analyzing control flow, value equivalences and changes
+to registers and memory referenced in value expressions, propagating
+the values of debug temporaries and determining expressions that can
+be used to compute the value of each user variable at as many points
+(ranges, actually) in the program as possible.
+
+Unlike @code{NOTE_INSN_VAR_LOCATION}, the value expression in an
+@code{INSN_VAR_LOCATION} denotes a value at that specific point in the
+program, rather than an expression that can be evaluated at any later
+point before an overriding @code{VAR_LOCATION} is encountered. E.g.,
+if a user variable is bound to a @code{REG} and then a subsequent insn
+modifies the @code{REG}, the note location would keep mapping the user
+variable to the register across the insn, whereas the insn location
+would keep the variable bound to the value, so that the variable
+tracking pass would emit another location note for the variable at the
+point in which the register is modified.
+
@end table
@cindex @code{TImode}, in @code{insn}
The @code{REG_NONNEG} note is added to insns only if the machine
description has a @samp{decrement_and_branch_until_zero} pattern.
-@findex REG_NO_CONFLICT
-@item REG_NO_CONFLICT
-This insn does not cause a conflict between @var{op} and the item
-being set by this insn even though it might appear that it does.
-In other words, if the destination register and @var{op} could
-otherwise be assigned the same register, this insn does not
-prevent that assignment.
-
-Insns with this note are usually part of a block that begins with a
-@code{clobber} insn specifying a multi-word pseudo register (which will
-be the output of the block), a group of insns that each set one word of
-the value and have the @code{REG_NO_CONFLICT} note attached, and a final
-insn that copies the output to itself with an attached @code{REG_EQUAL}
-note giving the expression being computed. This block is encapsulated
-with @code{REG_LIBCALL} and @code{REG_RETVAL} notes on the first and
-last insns, respectively.
-
@findex REG_LABEL_OPERAND
@item REG_LABEL_OPERAND
This insn uses @var{op}, a @code{code_label} or a @code{note} of type
@findex REG_LABEL_TARGET
@item REG_LABEL_TARGET
-This insn is a @code{jump_insn} but not a @code{addr_vec} or
+This insn is a @code{jump_insn} but not an @code{addr_vec} or
@code{addr_diff_vec}. It uses @var{op}, a @code{code_label} as a
direct or indirect jump target. Its purpose is similar to that of
@code{REG_LABEL_OPERAND}. This note is only present if the insn has
@findex REG_CROSSING_JUMP
@item REG_CROSSING_JUMP
-This insn is an branching instruction (either an unconditional jump or
+This insn is a branching instruction (either an unconditional jump or
an indirect jump) which crosses between hot and cold sections, which
could potentially be very far apart in the executable. The presence
-of this note indicates to other optimizations that this this branching
+of this note indicates to other optimizations that this branching
instruction should not be ``collapsed'' into a simpler branching
construct. It is used when the optimization to partition basic blocks
into hot and cold sections is turned on.
the inverse note pointing back to the first insn.
@table @code
-@findex REG_RETVAL
-@item REG_RETVAL
-This insn copies the value of a multi-insn sequence (for example, a
-library call), and @var{op} is the first insn of the sequence (for a
-library call, the first insn that was generated to set up the arguments
-for the library call).
-
-Loop optimization uses this note to treat such a sequence as a single
-operation for code motion purposes and flow analysis uses this note to
-delete such sequences whose results are dead.
-
-A @code{REG_EQUAL} note will also usually be attached to this insn to
-provide the expression being computed by the sequence.
-
-These notes will be deleted after reload, since they are no longer
-accurate or useful.
-
-@findex REG_LIBCALL
-@item REG_LIBCALL
-This is the inverse of @code{REG_RETVAL}: it is placed on the first
-insn of a multi-insn sequence, and it points to the last one.
-
-These notes are deleted after reload, since they are no longer useful or
-accurate.
-
@findex REG_CC_SETTER
@findex REG_CC_USER
@item REG_CC_SETTER
This is used on an RTX_FRAME_RELATED_P insn wherein the attached expression
is used in place of the actual insn pattern. This is done in cases where
the pattern is either complex or misleading.
-
-@findex REG_LIBCALL_ID
-@item REG_LIBCALL_ID
-This is used to specify that an insn is part of a libcall. Each libcall
-in a function has a unique id, and all the insns that are part of that
-libcall will have a REG_LIBCALL_ID note attached with the same ID.
@end table
For convenience, the machine mode in an @code{insn_list} or
The proper way to interface GCC to a new language front end is with
the ``tree'' data structure, described in the files @file{tree.h} and
-@file{tree.def}. The documentation for this structure (@pxref{Trees})
+@file{tree.def}. The documentation for this structure (@pxref{GENERIC})
is incomplete.
OSDN Git Service
