-@c Copyright (C) 1988-2018 Free Software Foundation, Inc.
+@c Copyright (C) 1988-2024 Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
* Debug Information:: Expressions representing debugging information.
* Insns:: Expression types for entire insns.
* Calls:: RTL representation of function call insns.
+* RTL SSA:: An on-the-side SSA form for RTL
* Sharing:: Some expressions are unique; others *must* be copied.
* Reading RTL:: Reading textual RTL from a file.
@end menu
@item RTX_OBJ
An RTX code that represents an actual object, such as a register
(@code{REG}) or a memory location (@code{MEM}, @code{SYMBOL_REF}).
-@code{LO_SUM}) is also included; instead, @code{SUBREG} and
-@code{STRICT_LOW_PART} are not in this class, but in class @code{x}.
+@code{LO_SUM} is also included; instead, @code{SUBREG} and
+@code{STRICT_LOW_PART} are not in this class, but in class
+@code{RTX_EXTRA}.
@item RTX_CONST_OBJ
An RTX code that represents a constant object. @code{HIGH} is also
@item RTX_COMM_ARITH
An RTX code for a commutative binary operation, such as @code{PLUS} or
@code{AND}. @code{NE} and @code{EQ} are comparisons, so they have class
-@code{<}.
+@code{RTX_COMM_COMPARE}.
@item RTX_BIN_ARITH
An RTX code for a non-commutative binary operation, such as @code{MINUS},
is safe to assume that all comparison operations have format @code{ee}.
@table @code
-@item 1
+@item RTX_UNARY
All codes of this class have format @code{e}.
-@item <
-@itemx c
-@itemx 2
+@item RTX_BIN_ARITH
+@itemx RTX_COMM_ARITH
+@itemx RTX_COMM_COMPARE
+@itemx RTX_COMPARE
All codes of these classes have format @code{ee}.
-@item b
-@itemx 3
+@item RTX_BITFIELD_OPS
+@itemx RTX_TERNARY
All codes of these classes have format @code{eee}.
-@item i
+@item RTX_INSN
All codes of this class have formats that begin with @code{iuueiee}.
@xref{Insns}. Note that not all RTL objects linked onto an insn chain
-are of class @code{i}.
+are of class @code{RTX_INSN}.
-@item o
-@itemx m
-@itemx x
+@item RTX_CONST_OBJ
+@itemx RTX_OBJ
+@itemx RTX_MATCH
+@itemx RTX_EXTRA
You can make no assumptions about the format of these codes.
@end table
@findex volatil
@cindex @samp{/v} in RTL dump
-@item volatil
@cindex volatile memory references
+@item volatil
In a @code{mem}, @code{asm_operands}, or @code{asm_input}
expression, it is 1 if the memory
reference is volatile. Volatile memory references may not be deleted,
``Condition Code'' mode represents the value of a condition code, which
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} (@pxref{Condition Code}).
+the condition code. (@pxref{Condition Code}).
@findex BLKmode
@item BLKmode
@code{HCmode}, @code{SCmode}, @code{DCmode}, @code{XCmode}, and
@code{TCmode}.
-@findex MODE_FUNCTION
-@item MODE_FUNCTION
-Algol or Pascal function variables including a static chain.
-(These are not currently implemented).
-
@findex MODE_CC
@item MODE_CC
Modes representing condition code values. These are @code{CCmode} plus
Operations in these modes may be executed as NOPs depending on hardware
features and environment setup.
+@findex MODE_OPAQUE
+@item MODE_OPAQUE
+This is a mode class for modes that don't want to provide operations
+other than register moves, memory moves, loads, stores, and
+@code{unspec}s. They have a size and precision and that's all.
+
@findex MODE_RANDOM
@item MODE_RANDOM
This is a catchall mode class for modes which don't fit into the above
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_double_zero
+The host dependency for the number of integers used to store a double
+value makes it problematic for machine descriptions to use expressions
+of code @code{const_double} and therefore a syntactic alias has been
+provided:
+
+@smallexample
+(const_double_zero:@var{m})
+@end smallexample
+
+standing for:
+
+@smallexample
+(const_double:@var{m} 0 0 @dots{})
+@end smallexample
+
+for matching the floating-point value zero, possibly the only useful one.
+
@findex CONST_WIDE_INT
@item (const_wide_int:@var{m} @var{nunits} @var{elt0} @dots{})
This contains an array of @code{HOST_WIDE_INT}s that is large enough
@code{HOST_WIDE_INT}s implied by the mode size.
@findex CONST_WIDE_INT_ELT
-@item CONST_WIDE_INT_NUNITS (@var{code},@var{i})
+@item CONST_WIDE_INT_ELT (@var{code},@var{i})
Returns the @code{i}th element of the array. Element 0 is contains
the low order bits of the constant.
Thus the first 6 elements (@samp{@{ 0, 1, 2, 6, 3, 8 @}}) are enough
to determine the whole sequence; we refer to them as the ``encoded''
elements. They are the only elements present in the square brackets
-for variable-length @code{const_vector}s (i.e. for
+for variable-length @code{const_vector}s (i.e.@: for
@code{const_vector}s whose mode @var{m} has a variable number of
elements). However, as a convenience to code that needs to handle
both @code{const_vector}s and @code{parallel}s, all elements are
@findex high
@item (high:@var{m} @var{exp})
-Represents the high-order bits of @var{exp}, usually a
-@code{symbol_ref}. The number of bits is machine-dependent and is
+Represents the high-order bits of @var{exp}.
+The number of bits is machine-dependent and is
normally the number of bits specified in an instruction that initializes
the high order bits of a register. It is used with @code{lo_sum} to
represent the typical two-instruction sequence used in RISC machines to
-reference a global memory location.
-
-@var{m} should be @code{Pmode}.
+reference large immediate values and/or link-time constants such
+as global memory addresses. In the latter case, @var{m} is @code{Pmode}
+and @var{exp} is usually a constant expression involving @code{symbol_ref}.
@end table
@findex CONST0_RTX
two target macros, @code{WORDS_BIG_ENDIAN} and @code{BYTES_BIG_ENDIAN}:
@itemize
-@item
@cindex @code{WORDS_BIG_ENDIAN}, effect on @code{subreg}
+@item
@code{WORDS_BIG_ENDIAN}, if set to 1, says that byte number zero is
part of the most significant word; otherwise, it is part of the least
significant word.
-@item
@cindex @code{BYTES_BIG_ENDIAN}, effect on @code{subreg}
+@item
@code{BYTES_BIG_ENDIAN}, if set to 1, says that byte number zero is
the most significant byte within a word; otherwise, it is the least
significant byte within a word.
@code{WORDS_BIG_ENDIAN}. However, most parts of the compiler treat
floating point values as if they had the same endianness as integer
values. This works because they handle them solely as a collection of
-integer values, with no particular numerical value. Only real.c and
+integer values, with no particular numerical value. Only real.cc and
the runtime libraries care about @code{FLOAT_WORDS_BIG_ENDIAN}.
Thus,
@end table
A @code{MODE_PARTIAL_INT} mode behaves as if it were as wide as the
-corresponding @code{MODE_INT} mode, except that it has an unknown
-number of undefined bits. For example:
+corresponding @code{MODE_INT} mode, except that it has a number of
+undefined bits, which are determined by the precision of the
+mode.
+
+For example, on a little-endian target which defines @code{PSImode}
+to have a precision of 20 bits:
@smallexample
(subreg:PSI (reg:SI 0) 0)
@end smallexample
+accesses the low 20 bits of @samp{(reg:SI 0)}.
+
@findex REGMODE_NATURAL_SIZE
-accesses the whole of @samp{(reg:SI 0)}, but the exact relationship
-between the @code{PSImode} value and the @code{SImode} value is not
-defined. If we assume @samp{REGMODE_NATURAL_SIZE (DImode) <= 4},
+Continuing with a @code{PSImode} precision of 20 bits, if we assume
+@samp{REGMODE_NATURAL_SIZE (DImode) <= 4},
then the following two @code{subreg}s:
@smallexample
(subreg:PSI (reg:DI 0) 4)
@end smallexample
-represent independent 4-byte accesses to the two halves of
-@samp{(reg:DI 0)}. Both @code{subreg}s have an unknown number
-of undefined bits.
+represent accesses to the low 20 bits of the two halves of
+@samp{(reg:DI 0)}.
If @samp{REGMODE_NATURAL_SIZE (PSImode) <= 2} then these two @code{subreg}s:
represent independent 2-byte accesses that together span the whole
of @samp{(reg:PSI 0)}. Storing to the first @code{subreg} does not
-affect the value of the second, and vice versa. @samp{(reg:PSI 0)}
-has an unknown number of undefined bits, so the assignment:
+affect the value of the second, and vice versa, so the assignment:
@smallexample
(set (subreg:HI (reg:PSI 0) 0) (reg:HI 4))
@end smallexample
-does not guarantee that @samp{(subreg:HI (reg:PSI 0) 0)} has the
-value @samp{(reg:HI 4)}.
+sets the low 16 bits of @samp{(reg:PSI 0)} to @samp{(reg:HI 4)}, and
+the high 4 defined bits of @samp{(reg:PSI 0)} retain their
+original value. The behavior here is the same as for
+normal @code{subreg}s, when there are no
+@code{MODE_PARTIAL_INT} modes involved.
@cindex @code{TARGET_CAN_CHANGE_MODE_CLASS} and subreg semantics
The rules above apply to both pseudo @var{reg}s and hard @var{reg}s.
@code{scratch} is usually present inside a @code{clobber} operation
(@pxref{Side Effects}).
-@findex cc0
-@cindex condition code register
-@item (cc0)
-This refers to the machine's condition code register. It has no
-operands and may not have a machine mode. There are two ways to use it:
-
-@itemize @bullet
-@item
-To stand for a complete set of condition code flags. This is best on
-most machines, where each comparison sets the entire series of flags.
-
-With this technique, @code{(cc0)} may be validly used in only two
-contexts: as the destination of an assignment (in test and compare
-instructions) and in comparison operators comparing against zero
-(@code{const_int} with value zero; that is to say, @code{const0_rtx}).
-
-@item
-To stand for a single flag that is the result of a single condition.
-This is useful on machines that have only a single flag bit, and in
-which comparison instructions must specify the condition to test.
-
-With this technique, @code{(cc0)} may be validly used in only two
-contexts: as the destination of an assignment (in test and compare
-instructions) where the source is a comparison operator, and as the
-first operand of @code{if_then_else} (in a conditional branch).
-@end itemize
-
-@findex cc0_rtx
-There is only one expression object of code @code{cc0}; it is the
-value of the variable @code{cc0_rtx}. Any attempt to create an
-expression of code @code{cc0} will return @code{cc0_rtx}.
-
-Instructions can set the condition code implicitly. On many machines,
-nearly all instructions set the condition code based on the value that
-they compute or store. It is not necessary to record these actions
-explicitly in the RTL because the machine description includes a
-prescription for recognizing the instructions that do so (by means of
-the macro @code{NOTICE_UPDATE_CC}). @xref{Condition Code}. Only
-instructions whose sole purpose is to set the condition code, and
-instructions that use the condition code, need mention @code{(cc0)}.
-
On some machines, the condition code register is given a register number
-and a @code{reg} is used instead of @code{(cc0)}. This is usually the
-preferable approach if only a small subset of instructions modify the
-condition code. Other machines store condition codes in general
+and a @code{reg} is used.
+Other machines store condition codes in general
registers; in such cases a pseudo register should be used.
Some machines, such as the SPARC and RS/6000, have two sets of
arithmetic instructions, one that sets and one that does not set the
condition code. This is best handled by normally generating the
instruction that does not set the condition code, and making a pattern
-that both performs the arithmetic and sets the condition code register
-(which would not be @code{(cc0)} in this case). For examples, search
-for @samp{addcc} and @samp{andcc} in @file{sparc.md}.
+that both performs the arithmetic and sets the condition code register.
+For examples, search for @samp{addcc} and @samp{andcc} in @file{sparc.md}.
@findex pc
-@item (pc)
@cindex program counter
+@item (pc)
This represents the machine's program counter. It has no operands and
may not have a machine mode. @code{(pc)} may be validly used only in
certain specific contexts in jump instructions.
This expression represents the sum of @var{x} and the low-order bits
of @var{y}. It is used with @code{high} (@pxref{Constants}) to
-represent the typical two-instruction sequence used in RISC machines
-to reference a global memory location.
+represent the typical two-instruction sequence used in RISC machines to
+reference large immediate values and/or link-time constants such
+as global memory addresses. In the latter case, @var{m} is @code{Pmode}
+and @var{y} is usually a constant expression involving @code{symbol_ref}.
The number of low order bits is machine-dependent but is
-normally the number of bits in a @code{Pmode} item minus the number of
+normally the number of bits in mode @var{m} minus the number of
bits set by @code{high}.
-@var{m} should be @code{Pmode}.
-
@findex minus
@findex ss_minus
@findex us_minus
However, they can pretend to do so when only the sign of the result will
be used, which is the case when the result is stored in the condition
code. And that is the @emph{only} way this kind of expression may
-validly be used: as a value to be stored in the condition codes, either
-@code{(cc0)} or a register. @xref{Comparisons}.
+validly be used: as a value to be stored in the condition codes, in a
+register. @xref{Comparisons}.
The mode @var{m} is not related to the modes of @var{x} and @var{y}, but
-instead is the mode of the condition code value. If @code{(cc0)} is
-used, it is @code{VOIDmode}. Otherwise it is some mode in class
+instead is the mode of the condition code value. It is some mode in class
@code{MODE_CC}, often @code{CCmode}. @xref{Condition Code}. If @var{m}
-is @code{VOIDmode} or @code{CCmode}, the operation returns sufficient
+is @code{CCmode}, the operation returns sufficient
information (in an unspecified format) so that any comparison operator
can be applied to the result of the @code{COMPARE} operation. For other
modes in class @code{MODE_CC}, the operation only returns a subset of
For unsigned widening multiplication, use the same idiom, but with
@code{zero_extend} instead of @code{sign_extend}.
+@findex smul_highpart
+@findex umul_highpart
+@cindex high-part multiplication
+@cindex multiplication high part
+@item (smul_highpart:@var{m} @var{x} @var{y})
+@itemx (umul_highpart:@var{m} @var{x} @var{y})
+Represents the high-part multiplication of @var{x} and @var{y} carried
+out in machine mode @var{m}. @code{smul_highpart} returns the high part
+of a signed multiplication, @code{umul_highpart} returns the high part
+of an unsigned multiplication.
+
@findex fma
+@cindex fused multiply-add
@item (fma:@var{m} @var{x} @var{y} @var{z})
Represents the @code{fma}, @code{fmaf}, and @code{fmal} builtin
functions, which compute @samp{@var{x} * @var{y} + @var{z}}
Represents the value @var{x} with the order of bytes reversed, carried out
in mode @var{m}, which must be a fixed-point machine mode.
The mode of @var{x} must be @var{m} or @code{VOIDmode}.
+
+@findex bitreverse
+@item (bitreverse:@var{m} @var{x})
+Represents the value @var{x} with the order of bits reversed, carried out
+in mode @var{m}, which must be a fixed-point machine mode.
+The mode of @var{x} must be @var{m} or @code{VOIDmode}.
+
+@findex copysign
+@item (copysign:@var{m} @var{x} @var{y})
+Represents the value @var{x} with the sign of @var{y}.
+Both @var{x} and @var{y} must have floating point machine mode @var{m}.
@end table
@node Comparisons
@code{VOIDmode}.
@cindex condition codes
-There are two ways that comparison operations may be used. The
-comparison operators may be used to compare the condition codes
-@code{(cc0)} against zero, as in @code{(eq (cc0) (const_int 0))}. Such
-a construct actually refers to the result of the preceding instruction
-in which the condition codes were set. The instruction setting the
-condition code must be adjacent to the instruction using the condition
-code; only @code{note} insns may separate them.
-
-Alternatively, a comparison operation may directly compare two data
+A comparison operation compares two data
objects. The mode of the comparison is determined by the operands; they
must both be valid for a common machine mode. A comparison with both
operands constant would be invalid as the machine mode could not be
deduced from it, but such a comparison should never exist in RTL due to
constant folding.
-In the example above, if @code{(cc0)} were last set to
-@code{(compare @var{x} @var{y})}, the comparison operation is
-identical to @code{(eq @var{x} @var{y})}. Usually only one style
+Usually only one style
of comparisons is supported on a particular machine, but the combine
-pass will try to merge the operations to produce the @code{eq} shown
+pass will try to merge operations to produce code like
+@code{(eq @var{x} @var{y})},
in case it exists in the context of the particular insn involved.
Inequality comparisons come in two flavors, signed and unsigned. Thus,
The mode @var{m} is the same as the mode that would be used for
@var{loc} if it were a register.
-A @code{sign_extract} can not appear as an lvalue, or part thereof,
+A @code{sign_extract} cannot appear as an lvalue, or part thereof,
in RTL.
@findex zero_extract
@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, 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.
-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).
+@code{const_int} (or another expression, if the selection can be made at
+runtime) for each of the subparts of the result vector, giving the 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{x1} @var{x2})
represented by @var{lval}. @var{lval} must be an expression
representing a place that can be stored in: @code{reg} (or @code{subreg},
@code{strict_low_part} or @code{zero_extract}), @code{mem}, @code{pc},
-@code{parallel}, or @code{cc0}.
+or @code{parallel}.
If @var{lval} is a @code{reg}, @code{subreg} or @code{mem}, it has a
machine mode; then @var{x} must be valid for that mode.
If @var{lval} is a @code{zero_extract}, then the referenced part of
the bit-field (a memory or register reference) specified by the
@code{zero_extract} is given the value @var{x} and the rest of the
-bit-field is not changed. Note that @code{sign_extract} can not
+bit-field is not changed. Note that @code{sign_extract} cannot
appear in @var{lval}.
-If @var{lval} is @code{(cc0)}, it has no machine mode, and @var{x} may
-be either a @code{compare} expression or a value that may have any mode.
-The latter case represents a ``test'' instruction. The expression
-@code{(set (cc0) (reg:@var{m} @var{n}))} is equivalent to
-@code{(set (cc0) (compare (reg:@var{m} @var{n}) (const_int 0)))}.
-Use the former expression to save space during the compilation.
-
If @var{lval} is a @code{parallel}, it is used to represent the case of
a function returning a structure in multiple registers. Each element
of the @code{parallel} is an @code{expr_list} whose first operand is a
@code{mem}; these unusual patterns are used to represent jumps through
branch tables.
-If @var{lval} is neither @code{(cc0)} nor @code{(pc)}, the mode of
+If @var{lval} is not @code{(pc)}, the mode of
@var{lval} must not be @code{VOIDmode} and the mode of @var{x} must be
valid for the mode of @var{lval}.
instead. The @code{use} RTX is most commonly useful to describe that
a fixed register is implicitly used in an insn. It is also safe to use
in patterns where the compiler knows for other reasons that the result
-of the whole pattern is variable, such as @samp{movmem@var{m}} or
+of the whole pattern is variable, such as @samp{cpymem@var{m}} or
@samp{call} patterns.
During the reload phase, an insn that has a @code{use} as pattern
instruction this way:
@smallexample
-(parallel [(set (cc0) (reg:SI 34))
+(parallel [(set (reg:CC CC_REG) (reg:SI 34))
(set (pc) (if_then_else
- (eq (cc0) (const_int 0))
+ (eq (reg:CC CC_REG) (const_int 0))
(label_ref @dots{})
(pc)))])
@end smallexample
assembler code---often @code{reg}, @code{mem} or constant expressions.
This would not be well-formed RTL at any other stage in compilation,
but it is OK then because no further optimization remains to be done.
-However, the definition of the macro @code{NOTICE_UPDATE_CC}, if
-any, must deal with such insns if you define any peephole optimizations.
@findex cond_exec
@item (cond_exec [@var{cond} @var{expr}])
@item (sequence [@var{insns} @dots{}])
Represents a sequence of insns. If a @code{sequence} appears in the
chain of insns, then each of the @var{insns} that appears in the sequence
-must be suitable for appearing in the chain of insns, i.e. must satisfy
+must be suitable for appearing in the chain of insns, i.e.@: must satisfy
the @code{INSN_P} predicate.
After delay-slot scheduling is completed, an insn and all the insns that
The only place that cares about the distinction between static, global,
and weak alternate entry points, besides the front-end code that creates
them, is the function @code{output_alternate_entry_point}, in
-@file{final.c}.
+@file{final.cc}.
To set the kind of a label, use the @code{SET_LABEL_KIND} macro.
@findex NOTE_INSN_BEGIN_STMT
@item NOTE_INSN_BEGIN_STMT
This note is used to generate @code{is_stmt} markers in line number
-debuggign information. It indicates the beginning of a user
+debugging information. It indicates the beginning of a user
statement.
@findex NOTE_INSN_INLINE_ENTRY
a symbolic representation that locates the pattern in the @file{md}
file as some small positive or negative offset from a named pattern.
-@findex LOG_LINKS
-@item LOG_LINKS (@var{i})
-A list (chain of @code{insn_list} expressions) giving information about
-dependencies between instructions within a basic block. Neither a jump
-nor a label may come between the related insns. These are only used by
-the schedulers and by combine. This is a deprecated data structure.
-Def-use and use-def chains are now preferred.
-
@findex REG_NOTES
@item REG_NOTES (@var{i})
A list (chain of @code{expr_list}, @code{insn_list} and @code{int_list}
information pertaining to the registers used in this insn.
@end table
-The @code{LOG_LINKS} field of an insn is a chain of @code{insn_list}
-expressions. Each of these has two operands: the first is an insn,
-and the second is another @code{insn_list} expression (the next one in
-the chain). The last @code{insn_list} in the chain has a null pointer
-as second operand. The significant thing about the chain is which
-insns appear in it (as first operands of @code{insn_list}
-expressions). Their order is not significant.
-
-This list is originally set up by the flow analysis pass; it is a null
-pointer until then. Flow only adds links for those data dependencies
-which can be used for instruction combination. For each insn, the flow
-analysis pass adds a link to insns which store into registers values
-that are used for the first time in this insn.
-
-The @code{REG_NOTES} field of an insn is a chain similar to the
-@code{LOG_LINKS} field but it includes @code{expr_list} and @code{int_list}
-expressions in addition to @code{insn_list} expressions. There are several
+The @code{REG_NOTES} field of an insn is a chain that includes
+@code{expr_list} and @code{int_list} expressions as well as @code{insn_list}
+expressions. There are several
kinds of register notes, which are distinguished by the machine mode, which
in a register note is really understood as being an @code{enum reg_note}.
The first operand @var{op} of the note is data whose meaning depends on
Register notes are of three classes: They may say something about an
input to an insn, they may say something about an output of an insn, or
-they may create a linkage between two insns. There are also a set
-of values that are only used in @code{LOG_LINKS}.
+they may create a linkage between two insns.
These register notes annotate inputs to an insn:
@findex REG_NONNEG
@item REG_NONNEG
The register @var{op} is known to have a nonnegative value when this
-insn is reached. This is used so that decrement and branch until zero
-instructions, such as the m68k dbra, can be matched.
+insn is reached. This is used by special looping instructions
+that terminate when the register goes negative.
-The @code{REG_NONNEG} note is added to insns only if the machine
-description has a @samp{decrement_and_branch_until_zero} pattern.
+The @code{REG_NONNEG} note is added only to @samp{doloop_end}
+insns, if its pattern uses a @code{ge} condition.
@findex REG_LABEL_OPERAND
@item REG_LABEL_OPERAND
insn has one of a pair of notes that points to a second insn, which has
the inverse note pointing back to the first insn.
-@table @code
-@findex REG_CC_SETTER
-@findex REG_CC_USER
-@item REG_CC_SETTER
-@itemx REG_CC_USER
-On machines that use @code{cc0}, the insns which set and use @code{cc0}
-set and use @code{cc0} are adjacent. However, when branch delay slot
-filling is done, this may no longer be true. In this case a
-@code{REG_CC_USER} note will be placed on the insn setting @code{cc0} to
-point to the insn using @code{cc0} and a @code{REG_CC_SETTER} note will
-be placed on the insn using @code{cc0} to point to the insn setting
-@code{cc0}.
-@end table
-
-These values are only used in the @code{LOG_LINKS} field, and indicate
-the type of dependency that each link represents. Links which indicate
-a data dependence (a read after write dependence) do not use any code,
-they simply have mode @code{VOIDmode}, and are printed without any
-descriptive text.
-
@table @code
@findex REG_DEP_TRUE
@item REG_DEP_TRUE
containing a single @code{clobber} follow immediately after the call to
indicate which registers.
+@node RTL SSA
+@section On-the-Side SSA Form for RTL
+@cindex SSA, RTL form
+@cindex RTL SSA
+
+The patterns of an individual RTL instruction describe which registers
+are inputs to that instruction and which registers are outputs from
+that instruction. However, it is often useful to know where the
+definition of a register input comes from and where the result of
+a register output is used. One way of obtaining this information
+is to use the RTL SSA form, which provides a Static Single Assignment
+representation of the RTL instructions.
+
+The RTL SSA code is located in the @file{rtl-ssa} subdirectory of the GCC
+source tree. This section only gives a brief overview of it; please
+see the comments in the source code for more details.
+
+@menu
+* Using RTL SSA:: What a pass needs to do to use the RTL SSA form
+* RTL SSA Instructions:: How instructions are represented and organized
+* RTL SSA Basic Blocks:: How instructions are grouped into blocks
+* RTL SSA Resources:: How registers and memory are represented
+* RTL SSA Accesses:: How register and memory accesses are represented
+* RTL SSA Phi Nodes:: How multiple sources are combined into one
+* RTL SSA Access Lists:: How accesses are chained together
+* Changing RTL Instructions:: How to use the RTL SSA framework to change insns
+@end menu
+
+@node Using RTL SSA
+@subsection Using RTL SSA in a pass
+
+A pass that wants to use the RTL SSA form should start with the following:
+
+@smallexample
+#define INCLUDE_ALGORITHM
+#define INCLUDE_FUNCTIONAL
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "backend.h"
+#include "rtl.h"
+#include "df.h"
+#include "rtl-ssa.h"
+@end smallexample
+
+All the RTL SSA code is contained in the @code{rtl_ssa} namespace,
+so most passes will then want to do:
+
+@smallexample
+using namespace rtl_ssa;
+@end smallexample
+
+However, this is purely a matter of taste, and the examples in the rest of
+this section do not require it.
+
+The RTL SSA represention is an optional on-the-side feature that applies
+on top of the normal RTL instructions. It is currently local to individual
+RTL passes and is not maintained across passes.
+
+However, in order to allow the RTL SSA information to be preserved across
+passes in future, @samp{crtl->ssa} points to the current function's
+SSA form (if any). Passes that want to use the RTL SSA form should
+first do:
+
+@smallexample
+crtl->ssa = new rtl_ssa::function_info (@var{fn});
+@end smallexample
+
+where @var{fn} is the function that the pass is processing.
+(Passes that are @code{using namespace rtl_ssa} do not need
+the @samp{rtl_ssa::}.)
+
+Once the pass has finished with the SSA form, it should do the following:
+
+@smallexample
+free_dominance_info (CDI_DOMINATORS);
+if (crtl->ssa->perform_pending_updates ())
+ cleanup_cfg (0);
+
+delete crtl->ssa;
+crtl->ssa = nullptr;
+@end smallexample
+
+The @code{free_dominance_info} call is necessary because
+dominance information is not currently maintained between RTL passes.
+The next two lines commit any changes to the RTL instructions that
+were queued for later; see the comment above the declaration of
+@code{perform_pending_updates} for details. The final two lines
+discard the RTL SSA form and free the associated memory.
+
+@node RTL SSA Instructions
+@subsection RTL SSA Instructions
+
+@cindex RPO
+@cindex reverse postorder
+@cindex instructions, RTL SSA
+@findex rtl_ssa::insn_info
+RTL SSA instructions are represented by an @code{rtl_ssa::insn_info}.
+These instructions are chained together in a single list that follows
+a reverse postorder (RPO) traversal of the function. This means that
+if any path through the function can execute an instruction @var{I1}
+and then later execute an instruction @var{I2} for the first time,
+@var{I1} appears before @var{I2} in the list@footnote{Note that this
+order is different from the order of the underlying RTL instructions,
+which follow machine code order instead.}.
+
+Two RTL SSA instructions can be compared to find which instruction
+occurs earlier than the other in the RPO@. One way to do this is
+to use the C++ comparison operators, such as:
+
+@example
+*@var{insn1} < *@var{insn2}
+@end example
+
+Another way is to use the @code{compare_with} function:
+
+@example
+@var{insn1}->compare_with (@var{insn2})
+@end example
+
+This expression is greater than zero if @var{insn1} comes after @var{insn2}
+in the RPO, less than zero if @var{insn1} comes before @var{insn2} in the
+RPO, or zero if @var{insn1} and @var{insn2} are the same. This order is
+maintained even if instructions are added to the function or moved around.
+
+The main purpose of @code{rtl_ssa::insn_info} is to hold
+SSA information about an instruction. However, it also caches
+certain properties of the instruction, such as whether it is an
+inline assembly instruction, whether it has volatile accesses, and so on.
+
+@node RTL SSA Basic Blocks
+@subsection RTL SSA Basic Blocks
+
+@cindex basic blocks, RTL SSA
+@findex basic_block
+@findex rtl_ssa::bb_info
+RTL SSA instructions (@pxref{RTL SSA Instructions}) are organized into
+basic blocks, with each block being represented by an @code{rtl_ssa:bb_info}.
+There is a one-to-one mapping between these @code{rtl_ssa:bb_info}
+structures and the underlying CFG @code{basic_block} structures
+(@pxref{Basic Blocks}).
+
+@cindex ``real'' instructions, RTL SSA
+@anchor{real RTL SSA insns}
+If a CFG basic block @var{bb} contains an RTL instruction @var{insn},
+the RTL SSA represenation of @var{bb} also contains an RTL SSA representation
+of @var{insn}@footnote{Note that this excludes non-instruction things like
+@code{note}s and @code{barrier}s that also appear in the chain of RTL
+instructions.}. Within RTL SSA, these instructions are referred to as
+``real'' instructions. These real instructions fall into two groups:
+debug instructions and nondebug instructions. Only nondebug instructions
+should affect code generation decisions.
+
+In addition, each RTL SSA basic block has two ``artificial''
+instructions: a ``head'' instruction that comes before all the real
+instructions and an ``end'' instruction that comes after all real
+instructions. These instructions exist to represent things that
+are conceptually defined or used at the start and end of a basic block.
+The instructions always exist, even if they do not currently do anything.
+
+Like instructions, these blocks are chained together in a reverse
+postorder. This list includes the entry block (which always comes
+first) and the exit block (which always comes last).
+
+@cindex extended basic blocks, RTL SSA
+@findex rtl_ssa::ebb_info
+RTL SSA basic blocks are chained together into ``extended basic blocks''
+(EBBs), represented by an @code{rtl_ssa::ebb_info}. Extended basic
+blocks contain one or more basic blocks. They have the property
+that if a block @var{bby} comes immediately after a block @var{bbx}
+in an EBB, then @var{bby} can only be reached by @var{bbx}; in other words,
+@var{bbx} is the sole predecessor of @var{bby}.
+
+Each extended basic block starts with an artificial ``phi node''
+instruction. This instruction defines all phi nodes for the EBB
+(@pxref{RTL SSA Phi Nodes}). (Individual blocks in an EBB do not
+need phi nodes because their live values can only come from one source.)
+
+The contents of a function are therefore represented using a
+four-level hierarchy:
+
+@itemize @bullet
+@item
+functions (@code{rtl_ssa::function_info}), which contain @dots{}
+
+@item
+extended basic blocks (@code{rtl_ssa::ebb_info}), which contain @dots{}
+
+@item
+basic blocks (@code{rtl_ssa::bb_info}), which contain @dots{}
+
+@item
+instructions (@code{rtl_ssa::insn_info})
+@end itemize
+
+In dumps, a basic block is identified as @code{bb@var{n}}, where @var{n}
+is the index of the associated CFG @code{basic_block} structure.
+An EBB is in turn identified by the index of its first block.
+For example, an EBB that contains @samp{bb10}, @code{bb5}, @code{bb6}
+and @code{bb9} is identified as @var{ebb10}.
+
+@node RTL SSA Resources
+@subsection RTL SSA Resources
+
+The RTL SSA form tracks two types of ``resource'': registers and memory.
+Each hard and pseudo register is a separate resource. Memory is a
+single unified resource, like it is in GIMPLE (@pxref{GIMPLE}).
+
+Each resource has a unique identifier. The unique identifier for a
+register is simply its register number. The unique identifier for
+memory is a special register number called @code{MEM_REGNO}.
+
+Since resource numbers so closely match register numbers, it is sometimes
+convenient to refer to them simply as register numbers, or ``regnos''
+for short. However, the RTL SSA form also provides an abstraction
+of resources in the form of @code{rtl_ssa::resource_info}.
+This is a lightweight class that records both the regno of a resource
+and the @code{machine_mode} that the resource has (@pxref{Machine Modes}).
+It has functions for testing whether a resource is a register or memory.
+In principle it could be extended to other kinds of resource in future.
+
+@node RTL SSA Accesses
+@subsection RTL SSA Register and Memory Accesses
+
+In the RTL SSA form, most reads or writes of a resource are
+represented as a @code{rtl_ssa::access_info}@footnote{The exceptions
+are call clobbers, which are generally represented separately.
+See the comment above @code{rtl_ssa::insn_info} for details.}.
+These @code{rtl_ssa::access_info}s are organized into the following
+class hierarchy:
+
+@findex rtl_ssa::access_info
+@findex rtl_ssa::use_info
+@findex rtl_ssa::def_info
+@findex rtl_ssa::clobber_info
+@findex rtl_ssa::set_info
+@findex rtl_ssa::phi_info
+@smallexample
+rtl_ssa::access_info
+ |
+ +-- rtl_ssa::use_info
+ |
+ +-- rtl_ssa::def_info
+ |
+ +-- rtl_ssa::clobber_info
+ |
+ +-- rtl_ssa::set_info
+ |
+ +-- rtl_ssa::phi_info
+@end smallexample
+
+A @code{rtl_ssa::use_info} represents a read or use of a resource and
+a @code{rtl_ssa::def_info} represents a write or definition of a resource.
+As in the main RTL representation, there are two basic types of
+definition: clobbers and sets. The difference is that a clobber
+leaves the register with an unspecified value that cannot be used
+or relied on by later instructions, while a set leaves the register
+with a known value that later instructions could use if they wanted to.
+A @code{rtl_ssa::clobber_info} represents a clobber and
+a @code{rtl_ssa::set_info} represent a set.
+
+Each @code{rtl_ssa::use_info} records which single @code{rtl_ssa::set_info}
+provides the value of the resource; this is null if the resource is
+completely undefined at the point of use. Each @code{rtl_ssa::set_info}
+in turn records all the @code{rtl_ssa::use_info}s that use its value.
+
+If a value of a resource can come from multiple sources,
+a @code{rtl_ssa::phi_info} brings those multiple sources together
+into a single definition (@pxref{RTL SSA Phi Nodes}).
+
+@node RTL SSA Phi Nodes
+@subsection RTL SSA Phi Nodes
+
+@cindex phi nodes, RTL SSA
+@findex rtl_ssa::phi_info
+If a resource is live on entry to an extended basic block and if the
+resource's value can come from multiple sources, the extended basic block
+has a ``phi node'' that collects together these multiple sources.
+The phi node conceptually has one input for each incoming edge of
+the extended basic block, with the input specifying the value of
+the resource on that edge. For example, suppose a function contains
+the following RTL:
+
+@smallexample
+;; Basic block bb3
+@dots{}
+(set (reg:SI R1) (const_int 0)) ;; A
+(set (pc) (label_ref bb5))
+
+;; Basic block bb4
+@dots{}
+(set (reg:SI R1) (const_int 1)) ;; B
+;; Fall through
+
+;; Basic block bb5
+;; preds: bb3, bb4
+;; live in: R1 @dots{}
+(code_label bb5)
+@dots{}
+(set (reg:SI @var{R2})
+ (plus:SI (reg:SI R1) @dots{})) ;; C
+@end smallexample
+
+The value of R1 on entry to block 5 can come from either A or B@.
+The extended basic block that contains block 5 would therefore have a
+phi node with two inputs: the first input would have the value of
+R1 defined by A and the second input would have the value of
+R1 defined by B@. This phi node would then provide the value of
+R1 for C (assuming that R1 does not change again between
+the start of block 5 and C).
+
+Since RTL is not a ``native'' SSA representation, these phi nodes
+simply collect together definitions that already exist. Each input
+to a phi node for a resource @var{R} is itself a definition of
+resource @var{R} (or is null if the resource is completely
+undefined for a particular incoming edge). This is in contrast
+to a native SSA representation like GIMPLE, where the phi inputs
+can be arbitrary expressions. As a result, RTL SSA phi nodes
+never involve ``hidden'' moves: all moves are instead explicit.
+
+Phi nodes are represented as a @code{rtl_ssa::phi_node}.
+Each input to a phi node is represented as an @code{rtl_ssa::use_info}.
+
+@node RTL SSA Access Lists
+@subsection RTL SSA Access Lists
+
+All the definitions of a resource are chained together in reverse postorder.
+In general, this list can contain an arbitrary mix of both sets
+(@code{rtl_ssa::set_info}) and clobbers (@code{rtl_ssa::clobber_info}).
+However, it is often useful to skip over all intervening clobbers
+of a resource in order to find the next set. The list is constructed
+in such a way that this can be done in amortized constant time.
+
+All uses (@code{rtl_ssa::use_info}) of a given set are also chained
+together into a list. This list of uses is divided into three parts:
+
+@enumerate
+@item
+uses by ``real'' nondebug instructions (@pxref{real RTL SSA insns})
+
+@item
+uses by real debug instructions
+
+@item
+uses by phi nodes (@pxref{RTL SSA Phi Nodes})
+@end enumerate
+
+The first and second parts individually follow reverse postorder.
+The third part has no particular order.
+
+@cindex degenerate phi node, RTL SSA
+The last use by a real nondebug instruction always comes earlier in
+the reverse postorder than the next definition of the resource (if any).
+This means that the accesses follow a linear sequence of the form:
+
+@itemize @bullet
+@item
+first definition of resource R
+
+@itemize @bullet
+@item
+first use by a real nondebug instruction of the first definition of resource R
+
+@item
+@dots{}
+
+@item
+last use by a real nondebug instruction of the first definition of resource R
+@end itemize
+
+@item
+second definition of resource R
+
+@itemize @bullet
+@item
+first use by a real nondebug instruction of the second definition of resource R
+
+@item
+@dots{}
+
+@item
+last use by a real nondebug instruction of the second definition of resource R
+@end itemize
+
+@item
+@dots{}
+
+@item
+last definition of resource R
+
+@itemize @bullet
+@item
+first use by a real nondebug instruction of the last definition of resource R
+
+@item
+@dots{}
+
+@item
+last use by a real nondebug instruction of the last definition of resource R
+@end itemize
+@end itemize
+
+(Note that clobbers never have uses; only sets do.)
+
+This linear view is easy to achieve when there is only a single definition
+of a resource, which is commonly true for pseudo registers. However,
+things are more complex if code has a structure like the following:
+
+@smallexample
+// ebb2, bb2
+R = @var{va}; // A
+if (@dots{})
+ @{
+ // ebb2, bb3
+ use1 (R); // B
+ @dots{}
+ R = @var{vc}; // C
+ @}
+else
+ @{
+ // ebb4, bb4
+ use2 (R); // D
+ @}
+@end smallexample
+
+The list of accesses would begin as follows:
+
+@itemize @bullet
+@item
+definition of R by A
+
+@itemize @bullet
+@item
+use of A's definition of R by B
+@end itemize
+
+@item
+definition of R by C
+@end itemize
+
+The next access to R is in D, but the value of R that D uses comes from
+A rather than C@.
+
+This is resolved by adding a phi node for @code{ebb4}. All inputs to this
+phi node have the same value, which in the example above is A's definition
+of R@. In other circumstances, it would not be necessary to create a phi
+node when all inputs are equal, so these phi nodes are referred to as
+``degenerate'' phi nodes.
+
+The full list of accesses to R is therefore:
+
+@itemize @bullet
+@item
+definition of R by A
+
+@itemize @bullet
+@item
+use of A's definition of R by B
+@end itemize
+
+@item
+definition of R by C
+
+@item
+definition of R by ebb4's phi instruction, with the input coming from A
+
+@itemize @bullet
+@item
+use of the ebb4's R phi definition of R by B
+@end itemize
+@end itemize
+
+Note that A's definition is also used by ebb4's phi node, but this
+use belongs to the third part of the use list described above and
+so does not form part of the linear sequence.
+
+It is possible to ``look through'' any degenerate phi to the ultimate
+definition using the function @code{look_through_degenerate_phi}.
+Note that the input to a degenerate phi is never itself provided
+by a degenerate phi.
+
+At present, the SSA form takes this principle one step further
+and guarantees that, for any given resource @var{res}, one of the
+following is true:
+
+@itemize
+@item
+The resource has a single definition @var{def}, which is not a phi node.
+Excluding uses of undefined registers, all uses of @var{res} by real
+nondebug instructions use the value provided by @var{def}.
+
+@item
+Excluding uses of undefined registers, all uses of @var{res} use
+values provided by definitions that occur earlier in the same
+extended basic block. These definitions might come from phi nodes
+or from real instructions.
+@end itemize
+
+@node Changing RTL Instructions
+@subsection Using the RTL SSA framework to change instructions
+
+@findex rtl_ssa::insn_change
+There are various routines that help to change a single RTL instruction
+or a group of RTL instructions while keeping the RTL SSA form up-to-date.
+This section first describes the process for changing a single instruction,
+then goes on to describe the differences when changing multiple instructions.
+
+@menu
+* Changing One RTL SSA Instruction::
+* Changing Multiple RTL SSA Instructions::
+@end menu
+
+@node Changing One RTL SSA Instruction
+@subsubsection Changing One RTL SSA Instruction
+
+Before making a change, passes should first use a statement like the
+following:
+
+@smallexample
+auto attempt = crtl->ssa->new_change_attempt ();
+@end smallexample
+
+Here, @code{attempt} is an RAII object that should remain in scope
+for the entire change attempt. It automatically frees temporary
+memory related to the changes when it goes out of scope.
+
+Next, the pass should create an @code{rtl_ssa::insn_change} object
+for the instruction that it wants to change. This object specifies
+several things:
+
+@itemize @bullet
+@item
+what the instruction's new list of uses should be (@code{new_uses}).
+By default this is the same as the instruction's current list of uses.
+
+@item
+what the instruction's new list of definitions should be (@code{new_defs}).
+By default this is the same as the instruction's current list of
+definitions.
+
+@item
+where the instruction should be located (@code{move_range}).
+This is a range of instructions after which the instruction could
+be placed, represented as an @code{rtl_ssa::insn_range}.
+By default the instruction must remain at its current position.
+@end itemize
+
+If a pass was attempting to change all these properties of an instruction
+@code{insn}, it might do something like this:
+
+@smallexample
+rtl_ssa::insn_change change (insn);
+change.new_defs = @dots{};
+change.new_uses = @dots{};
+change.move_range = @dots{};
+@end smallexample
+
+This @code{rtl_ssa::insn_change} only describes something that the
+pass @emph{might} do; at this stage, nothing has actually changed.
+
+As noted above, the default @code{move_range} requires the instruction
+to remain where it is. At the other extreme, it is possible to allow
+the instruction to move anywhere within its extended basic block,
+provided that all the new uses and definitions can be performed
+at the new location. The way to do this is:
+
+@smallexample
+change.move_range = insn->ebb ()->insn_range ();
+@end smallexample
+
+In either case, the next step is to make sure that move range is
+consistent with the new uses and definitions. The way to do this is:
+
+@smallexample
+if (!rtl_ssa::restrict_movement (change))
+ return false;
+@end smallexample
+
+This function tries to limit @code{move_range} to a range of instructions
+at which @code{new_uses} and @code{new_defs} can be correctly performed.
+It returns true on success or false if no suitable location exists.
+
+The pass should also tentatively change the pattern of the instruction
+to whatever form the pass wants the instruction to have. This should use
+the facilities provided by @file{recog.cc}. For example:
+
+@smallexample
+rtl_insn *rtl = insn->rtl ();
+insn_change_watermark watermark;
+validate_change (rtl, &PATTERN (rtl), new_pat, 1);
+@end smallexample
+
+will tentatively replace @code{insn}'s pattern with @code{new_pat}.
+
+These changes and the construction of the @code{rtl_ssa::insn_change}
+can happen in either order or be interleaved.
+
+After the tentative changes to the instruction are complete,
+the pass should check whether the new pattern matches a target
+instruction or satisfies the requirements of an inline asm:
+
+@smallexample
+if (!rtl_ssa::recog (attempt, change))
+ return false;
+@end smallexample
+
+This step might change the instruction pattern further in order to
+make it match. It might also add new definitions or restrict the range
+of the move. For example, if the new pattern did not match in its original
+form, but could be made to match by adding a clobber of the flags
+register, @code{rtl_ssa::recog} will check whether the flags register
+is free at an appropriate point. If so, it will add a clobber of the
+flags register to @code{new_defs} and restrict @code{move_range} to
+the locations at which the flags register can be safely clobbered.
+
+Even if the proposed new instruction is valid according to
+@code{rtl_ssa::recog}, the change might not be worthwhile.
+For example, when optimizing for speed, the new instruction might
+turn out to be slower than the original one. When optimizing for
+size, the new instruction might turn out to be bigger than the
+original one.
+
+Passes should check for this case using @code{change_is_worthwhile}.
+For example:
+
+@smallexample
+if (!rtl_ssa::change_is_worthwhile (change))
+ return false;
+@end smallexample
+
+If the change passes this test too then the pass can perform the change using:
+
+@smallexample
+confirm_change_group ();
+crtl->ssa->change_insn (change);
+@end smallexample
+
+Putting all this together, the change has the following form:
+
+@smallexample
+auto attempt = crtl->ssa->new_change_attempt ();
+
+rtl_ssa::insn_change change (insn);
+change.new_defs = @dots{};
+change.new_uses = @dots{};
+change.move_range = @dots{};
+
+if (!rtl_ssa::restrict_movement (change))
+ return false;
+
+insn_change_watermark watermark;
+// Use validate_change etc. to change INSN's pattern.
+@dots{}
+if (!rtl_ssa::recog (attempt, change)
+ || !rtl_ssa::change_is_worthwhile (change))
+ return false;
+
+confirm_change_group ();
+crtl->ssa->change_insn (change);
+@end smallexample
+
+@node Changing Multiple RTL SSA Instructions
+@subsubsection Changing Multiple RTL SSA Instructions
+
+The process for changing multiple instructions is similar
+to the process for changing single instructions
+(@pxref{Changing One RTL SSA Instruction}). The pass should
+again start the change attempt with:
+
+@smallexample
+auto attempt = crtl->ssa->new_change_attempt ();
+@end smallexample
+
+and keep @code{attempt} in scope for the duration of the change
+attempt. It should then construct an @code{rtl_ssa::insn_change}
+for each change that it wants to make.
+
+After this, it should combine the changes into a sequence of
+@code{rtl_ssa::insn_change} pointers. This sequence must be in
+reverse postorder; the instructions will remain strictly in the
+order that the sequence specifies.
+
+For example, if a pass is changing exactly two instructions,
+it might do:
+
+@smallexample
+rtl_ssa::insn_change *changes[] = @{ &change1, &change2 @};
+@end smallexample
+
+where @code{change1}'s instruction must come before @code{change2}'s.
+Alternatively, if the pass is changing a variable number of
+instructions, it might build up the sequence in a
+@code{vec<rtl_ssa::insn_change *>}.
+
+By default, @code{rtl_ssa::restrict_movement} assumes that all
+instructions other than the one passed to it will remain in their
+current positions and will retain their current uses and definitions.
+When changing multiple instructions, it is usually more effective
+to ignore the other instructions that are changing. The sequencing
+described above ensures that the changing instructions remain
+in the correct order with respect to each other.
+The way to do this is:
+
+@smallexample
+if (!rtl_ssa::restrict_movement_ignoring (change, insn_is_changing (changes)))
+ return false;
+@end smallexample
+
+Similarly, when @code{rtl_ssa::restrict_movement} is detecting
+whether a register can be clobbered, it by default assumes that
+all other instructions will remain in their current positions and
+retain their current form. It is again more effective to ignore
+changing instructions (which might, for example, no longer need
+to clobber the flags register). The way to do this is:
+
+@smallexample
+if (!rtl_ssa::recog_ignoring (attempt, change, insn_is_changing (changes)))
+ return false;
+@end smallexample
+
+When changing multiple instructions, the important question is usually
+not whether each individual change is worthwhile, but whether the changes
+as a whole are worthwhile. The way to test this is:
+
+@smallexample
+if (!rtl_ssa::changes_are_worthwhile (changes))
+ return false;
+@end smallexample
+
+The process for changing single instructions makes sure that one
+@code{rtl_ssa::insn_change} in isolation is valid. But when changing
+multiple instructions, it is also necessary to test whether the
+sequence as a whole is valid. For example, it might be impossible
+to satisfy all of the @code{move_range}s at once.
+
+Therefore, once the pass has a sequence of changes that are
+individually correct, it should use:
+
+@smallexample
+if (!crtl->ssa->verify_insn_changes (changes))
+ return false;
+@end smallexample
+
+to check whether the sequence as a whole is valid. If all checks pass,
+the final step is:
+
+@smallexample
+confirm_change_group ();
+crtl->ssa->change_insns (changes);
+@end smallexample
+
+Putting all this together, the process for a two-instruction change is:
+
+@smallexample
+auto attempt = crtl->ssa->new_change_attempt ();
+
+rtl_ssa::insn_change change1 (insn1);
+change1.new_defs = @dots{};
+change1.new_uses = @dots{};
+change1.move_range = @dots{};
+
+rtl_ssa::insn_change change2 (insn2);
+change2.new_defs = @dots{};
+change2.new_uses = @dots{};
+change2.move_range = @dots{};
+
+rtl_ssa::insn_change *changes[] = @{ &change1, &change2 @};
+
+auto is_changing = insn_is_changing (changes);
+if (!rtl_ssa::restrict_movement_ignoring (change1, is_changing)
+ || !rtl_ssa::restrict_movement_ignoring (change2, is_changing))
+ return false;
+
+insn_change_watermark watermark;
+// Use validate_change etc. to change INSN1's and INSN2's patterns.
+@dots{}
+if (!rtl_ssa::recog_ignoring (attempt, change1, is_changing)
+ || !rtl_ssa::recog_ignoring (attempt, change2, is_changing)
+ || !rtl_ssa::changes_are_worthwhile (changes)
+ || !crtl->ssa->verify_insn_changes (changes))
+ return false;
+
+confirm_change_group ();
+crtl->ssa->change_insns (changes);
+@end smallexample
+
@node Sharing
@section Structure Sharing Assumptions
@cindex sharing of RTL components
@item
There is only one @code{pc} expression.
-@cindex @code{cc0}, RTL sharing
-@item
-There is only one @code{cc0} expression.
-
@cindex @code{const_double}, RTL sharing
@item
There is only one @code{const_double} expression with value 0 for
@item
During initial RTL generation, shared structure is freely introduced.
After all the RTL for a function has been generated, all shared
-structure is copied by @code{unshare_all_rtl} in @file{emit-rtl.c},
+structure is copied by @code{unshare_all_rtl} in @file{emit-rtl.cc},
after which the above rules are guaranteed to be followed.
@findex copy_rtx_if_shared
To read an RTL object from a file, call @code{read_rtx}. It takes one
argument, a stdio stream, and returns a single RTL object. This routine
-is defined in @file{read-rtl.c}. It is not available in the compiler
+is defined in @file{read-rtl.cc}. It is not available in the compiler
itself, only the various programs that generate the compiler back end
from the machine description.
projects / thirdparty / gcc.git / blobdiff