-@c Copyright (C) 1988, 89, 92, 93, 94, 96, 1998 Free Software Foundation, Inc.
+@c Copyright (C) 1988, 89, 92, 93, 94, 96, 1998, 2000 Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
* Dependent Patterns:: Having one pattern may make you need another.
* Jump Patterns:: Special considerations for patterns for jump insns.
* Insn Canonicalizations::Canonicalization of Instructions
-* Peephole Definitions::Defining machine-specific peephole optimizations.
* Expander Definitions::Generating a sequence of several RTL insns
- for a standard operation.
-* Insn Splitting:: Splitting Instructions into Multiple Instructions
+ for a standard operation.
+* Insn Splitting:: Splitting Instructions into Multiple Instructions.
+* Peephole Definitions::Defining machine-specific peephole optimizations.
* Insn Attributes:: Specifying the value of attributes for generated insns.
+* Conditional Execution::Generating @code{define_insn} patterns for
+ predication.
@end menu
@node Patterns
Names that are not thus known and used in RTL-generation have no
effect; they are equivalent to no name at all.
+For the purpose of debugging the compiler, you may also specify a
+name beginning with the @samp{*} character. Such a name is used only
+for identifying the instruction in RTL dumps; it is entirely equivalent
+to having a nameless pattern for all other purposes.
+
@item
The @dfn{RTL template} (@pxref{RTL Template}) is a vector of incomplete
RTL expressions which show what the instruction should look like. It is
predicate function, and that function is solely responsible for
deciding whether the expression to be matched ``has'' that mode.
-@findex address
-@item (address (match_operand:@var{m} @var{n} "address_operand" ""))
-This complex of expressions is a placeholder for an operand number
-@var{n} in a ``load address'' instruction: an operand which specifies
-a memory location in the usual way, but for which the actual operand
-value used is the address of the location, not the contents of the
-location.
-
-@code{address} expressions never appear in RTL code, only in machine
-descriptions. And they are used only in machine descriptions that do
-not use the operand constraint feature. When operand constraints are
-in use, the letter @samp{p} in the constraint serves this purpose.
-
-@var{m} is the machine mode of the @emph{memory location being
-addressed}, not the machine mode of the address itself. That mode is
-always the same on a given target machine (it is @code{Pmode}, which
-normally is @code{SImode}), so there is no point in mentioning it;
-thus, no machine mode is written in the @code{address} expression. If
-some day support is added for machines in which addresses of different
-kinds of objects appear differently or are used differently (such as
-the PDP-10), different formats would perhaps need different machine
-modes and these modes might be written in the @code{address}
-expression.
@end table
@node Output Template
* Class Preferences:: Constraints guide which hard register to put things in.
* Modifiers:: More precise control over effects of constraints.
* Machine Constraints:: Existing constraints for some particular machines.
-* No Constraints:: Describing a clean machine without constraints.
@end menu
@end ifset
the letters that are allowed:
@table @asis
+@item whitespace
+Whitespace characters are ignored and can be inserted at any position
+except the first. This enables each alternative for different operands to
+be visually aligned in the machine description even if they have different
+number of constraints and modifiers.
+
@cindex @samp{m} in constraint
@cindex memory references in constraints
@item @samp{m}
identifies an operand that is both input and output; all other operands
are assumed to be input only.
+If you specify @samp{=} or @samp{+} in a constraint, you put it in the
+first character of the constraint string.
+
@cindex @samp{&} in constraint
@cindex earlyclobber operand
@item &
independent @samp{E} or @samp{F} instead)
@end table
+@item AVR family---@file{avr.h}
+@table @code
+@item l
+Registers from r0 to r15
+
+@item a
+Registers from r16 to r23
+
+@item d
+Registers from r16 to r31
+
+@item w
+Register from r24 to r31. This registers can be used in @samp{addw} command
+
+@item e
+Pointer register (r26 - r31)
+
+@item b
+Base pointer register (r28 - r31)
+
+@item t
+Temporary register r0
+
+@item x
+Register pair X (r27:r26)
+
+@item y
+Register pair Y (r29:r28)
+
+@item z
+Register pair Z (r31:r30)
+
+@item I
+Constant greater than -1, less than 64
+
+@item J
+Constant greater than -64, less than 1
+
+@item K
+Constant integer 2
+
+@item L
+Constant integer 0
+
+@item M
+Constant that fits in 8 bits
+
+@item N
+Constant integer -1
+
+@item O
+Constant integer 8
+
+@item P
+Constant integer 1
+
+@item G
+A floating point constant 0.0
+@end table
+
@item IBM RS6000---@file{rs6000.h}
@table @code
@item b
Signed 13 bit constant, sign-extended to 32 or 64 bits
@item Q
-Memory reference that can be loaded with one instruction (@samp{m} is
-more appropriate for @code{asm} statements)
+Floating-point constant whose integral representation can
+be moved into an integer register using a single sethi
+instruction
+
+@item R
+Floating-point constant whose integral representation can
+be moved into an integer register using a single mov
+instruction
@item S
-Constant, or memory address
+Floating-point constant whose integral representation can
+be moved into an integer register using a high/lo_sum
+instruction sequence
@item T
Memory address aligned to an 8-byte boundary
@item U
Even register
-@end table
+
@end table
-@ifset INTERNALS
-@node No Constraints
-@subsection Not Using Constraints
-@cindex no constraints
-@cindex not using constraints
-
-Some machines are so clean that operand constraints are not required. For
-example, on the Vax, an operand valid in one context is valid in any other
-context. On such a machine, every operand constraint would be @samp{g},
-excepting only operands of ``load address'' instructions which are
-written as if they referred to a memory location's contents but actual
-refer to its address. They would have constraint @samp{p}.
-
-@cindex empty constraints
-For such machines, instead of writing @samp{g} and @samp{p} for all
-the constraints, you can choose to write a description with empty constraints.
-Then you write @samp{""} for the constraint in every @code{match_operand}.
-Address operands are identified by writing an @code{address} expression
-around the @code{match_operand}, not by their constraints.
-
-When the machine description has just empty constraints, certain parts
-of compilation are skipped, making the compiler faster. However,
-few machines actually do not need constraints; all machine descriptions
-now in existence use constraints.
-@end ifset
+@item TMS320C3x/C4x---@file{c4x.h}
+@table @code
+@item a
+Auxiliary (address) register (ar0-ar7)
+
+@item b
+Stack pointer register (sp)
+
+@item c
+Standard (32 bit) precision integer register
+
+@item f
+Extended (40 bit) precision register (r0-r11)
+
+@item k
+Block count register (bk)
+
+@item q
+Extended (40 bit) precision low register (r0-r7)
+
+@item t
+Extended (40 bit) precision register (r0-r1)
+
+@item u
+Extended (40 bit) precision register (r2-r3)
+
+@item v
+Repeat count register (rc)
+
+@item x
+Index register (ir0-ir1)
+
+@item y
+Status (condition code) register (st)
+
+@item z
+Data page register (dp)
+
+@item G
+Floating-point zero
+
+@item H
+Immediate 16 bit floating-point constant
+
+@item I
+Signed 16 bit constant
+
+@item J
+Signed 8 bit constant
+
+@item K
+Signed 5 bit constant
+
+@item L
+Unsigned 16 bit constant
+
+@item M
+Unsigned 8 bit constant
+
+@item N
+Ones complement of unsigned 16 bit constant
+
+@item O
+High 16 bit constant (32 bit constant with 16 LSBs zero)
+
+@item Q
+Indirect memory reference with signed 8 bit or index register displacement
+
+@item R
+Indirect memory reference with unsigned 5 bit displacement
+
+@item S
+Indirect memory reference with 1 bit or index register displacement
+
+@item T
+Direct memory reference
+
+@item U
+Symbolic address
+
+@end table
+@end table
@ifset INTERNALS
@node Standard Names
to mode @var{m}. The effect on the rest of the register is undefined.
This class of patterns is special in several ways. First of all, each
-of these names @emph{must} be defined, because there is no other way
-to copy a datum from one place to another.
+of these names up to and including full word size @emph{must} be defined,
+because there is no other way to copy a datum from one place to another.
+If there are patterns accepting operands in larger modes,
+@samp{mov@var{m}} must be defined for integer modes of those sizes.
Second, these patterns are not used solely in the RTL generation pass.
Even the reload pass can generate move insns to copy values from stack
The above discussion also applies to the @samp{mov@var{mode}cc} and
@samp{s@var{cond}} patterns.
+@cindex @code{jump} instruction pattern
+@item @samp{jump}
+A jump inside a function; an unconditional branch. Operand 0 is the
+@code{label_ref} of the label to jump to. This pattern name is mandatory
+on all machines.
+
@cindex @code{call} instruction pattern
@item @samp{call}
Subroutine call instruction returning no value. Operand 0 is the
normally need to define this pattern. A typical reason why you might
need this pattern is if some value, such as a pointer to a global table,
must be restored when the frame pointer is restored. Note that a nonlocal
-goto only ocurrs within a unit-of-translation, so a global table pointer
+goto only occurs within a unit-of-translation, so a global table pointer
that is shared by all functions of a given module need not be restored.
There are no arguments.
The @code{sibcall_epilogue} pattern must not clobber any arguments used for
parameter passing or any stack slots for arguments passed to the current
function.
+
+@cindex @code{trap} instruction pattern
+@item @samp{trap}
+This pattern, if defined, signals an error, typically by causing some
+kind of signal to be raised. Among other places, it is used by the Java
+frontend to signal `invalid array index' exceptions.
+
+@cindex @code{conditional_trap} instruction pattern
+@item @samp{conditional_trap}
+Conditional trap instruction. Operand 0 is a piece of RTL which
+performs a comparison. Operand 1 is the trap code, an integer.
+
+A typical @code{conditional_trap} pattern looks like
+
+@smallexample
+(define_insn "conditional_trap"
+ [(trap_if (match_operator 0 "trap_operator"
+ [(cc0) (const_int 0)])
+ (match_operand 1 "const_int_operand" "i"))]
+ ""
+ "@dots{}")
+@end smallexample
+
@end table
@node Pattern Ordering
additional modes are required (as for the add example mentioned above in
the Sparc), define the macro @code{EXTRA_CC_MODES} to list the
additional modes required (@pxref{Condition Code}). Also define
-@code{EXTRA_CC_NAMES} to list the names of those modes and
@code{SELECT_CC_MODE} to choose a mode given an operand of a compare.
If it is known during RTL generation that a different mode will be
@end itemize
-@node Peephole Definitions
-@section Machine-Specific Peephole Optimizers
-@cindex peephole optimizer definitions
-@cindex defining peephole optimizers
+@node Expander Definitions
+@section Defining RTL Sequences for Code Generation
+@cindex expander definitions
+@cindex code generation RTL sequences
+@cindex defining RTL sequences for code generation
-In addition to instruction patterns the @file{md} file may contain
-definitions of machine-specific peephole optimizations.
+On some target machines, some standard pattern names for RTL generation
+cannot be handled with single insn, but a sequence of RTL insns can
+represent them. For these target machines, you can write a
+@code{define_expand} to specify how to generate the sequence of RTL.
-The combiner does not notice certain peephole optimizations when the data
-flow in the program does not suggest that it should try them. For example,
-sometimes two consecutive insns related in purpose can be combined even
-though the second one does not appear to use a register computed in the
-first one. A machine-specific peephole optimizer can detect such
-opportunities.
+@findex define_expand
+A @code{define_expand} is an RTL expression that looks almost like a
+@code{define_insn}; but, unlike the latter, a @code{define_expand} is used
+only for RTL generation and it can produce more than one RTL insn.
-@need 1000
-A definition looks like this:
+A @code{define_expand} RTX has four operands:
-@smallexample
-(define_peephole
- [@var{insn-pattern-1}
- @var{insn-pattern-2}
- @dots{}]
- "@var{condition}"
- "@var{template}"
- "@var{optional insn-attributes}")
-@end smallexample
+@itemize @bullet
+@item
+The name. Each @code{define_expand} must have a name, since the only
+use for it is to refer to it by name.
-@noindent
-The last string operand may be omitted if you are not using any
-machine-specific information in this machine description. If present,
-it must obey the same rules as in a @code{define_insn}.
+@item
+The RTL template. This is a vector of RTL expressions representing
+a sequence of separate instructions. Unlike @code{define_insn}, there
+is no implicit surrounding @code{PARALLEL}.
-In this skeleton, @var{insn-pattern-1} and so on are patterns to match
-consecutive insns. The optimization applies to a sequence of insns when
-@var{insn-pattern-1} matches the first one, @var{insn-pattern-2} matches
-the next, and so on.@refill
+@item
+The condition, a string containing a C expression. This expression is
+used to express how the availability of this pattern depends on
+subclasses of target machine, selected by command-line options when GNU
+CC is run. This is just like the condition of a @code{define_insn} that
+has a standard name. Therefore, the condition (if present) may not
+depend on the data in the insn being matched, but only the
+target-machine-type flags. The compiler needs to test these conditions
+during initialization in order to learn exactly which named instructions
+are available in a particular run.
-Each of the insns matched by a peephole must also match a
-@code{define_insn}. Peepholes are checked only at the last stage just
-before code generation, and only optionally. Therefore, any insn which
-would match a peephole but no @code{define_insn} will cause a crash in code
-generation in an unoptimized compilation, or at various optimization
-stages.
+@item
+The preparation statements, a string containing zero or more C
+statements which are to be executed before RTL code is generated from
+the RTL template.
-The operands of the insns are matched with @code{match_operands},
-@code{match_operator}, and @code{match_dup}, as usual. What is not
-usual is that the operand numbers apply to all the insn patterns in the
-definition. So, you can check for identical operands in two insns by
-using @code{match_operand} in one insn and @code{match_dup} in the
-other.
+Usually these statements prepare temporary registers for use as
+internal operands in the RTL template, but they can also generate RTL
+insns directly by calling routines such as @code{emit_insn}, etc.
+Any such insns precede the ones that come from the RTL template.
+@end itemize
-The operand constraints used in @code{match_operand} patterns do not have
-any direct effect on the applicability of the peephole, but they will
-be validated afterward, so make sure your constraints are general enough
-to apply whenever the peephole matches. If the peephole matches
-but the constraints are not satisfied, the compiler will crash.
+Every RTL insn emitted by a @code{define_expand} must match some
+@code{define_insn} in the machine description. Otherwise, the compiler
+will crash when trying to generate code for the insn or trying to optimize
+it.
-It is safe to omit constraints in all the operands of the peephole; or
-you can write constraints which serve as a double-check on the criteria
-previously tested.
+The RTL template, in addition to controlling generation of RTL insns,
+also describes the operands that need to be specified when this pattern
+is used. In particular, it gives a predicate for each operand.
-Once a sequence of insns matches the patterns, the @var{condition} is
-checked. This is a C expression which makes the final decision whether to
-perform the optimization (we do so if the expression is nonzero). If
-@var{condition} is omitted (in other words, the string is empty) then the
-optimization is applied to every sequence of insns that matches the
-patterns.
+A true operand, which needs to be specified in order to generate RTL from
+the pattern, should be described with a @code{match_operand} in its first
+occurrence in the RTL template. This enters information on the operand's
+predicate into the tables that record such things. GNU CC uses the
+information to preload the operand into a register if that is required for
+valid RTL code. If the operand is referred to more than once, subsequent
+references should use @code{match_dup}.
-The defined peephole optimizations are applied after register allocation
-is complete. Therefore, the peephole definition can check which
-operands have ended up in which kinds of registers, just by looking at
-the operands.
+The RTL template may also refer to internal ``operands'' which are
+temporary registers or labels used only within the sequence made by the
+@code{define_expand}. Internal operands are substituted into the RTL
+template with @code{match_dup}, never with @code{match_operand}. The
+values of the internal operands are not passed in as arguments by the
+compiler when it requests use of this pattern. Instead, they are computed
+within the pattern, in the preparation statements. These statements
+compute the values and store them into the appropriate elements of
+@code{operands} so that @code{match_dup} can find them.
-@findex prev_active_insn
-The way to refer to the operands in @var{condition} is to write
-@code{operands[@var{i}]} for operand number @var{i} (as matched by
-@code{(match_operand @var{i} @dots{})}). Use the variable @code{insn}
-to refer to the last of the insns being matched; use
-@code{prev_active_insn} to find the preceding insns.
-
-@findex dead_or_set_p
-When optimizing computations with intermediate results, you can use
-@var{condition} to match only when the intermediate results are not used
-elsewhere. Use the C expression @code{dead_or_set_p (@var{insn},
-@var{op})}, where @var{insn} is the insn in which you expect the value
-to be used for the last time (from the value of @code{insn}, together
-with use of @code{prev_nonnote_insn}), and @var{op} is the intermediate
-value (from @code{operands[@var{i}]}).@refill
-
-Applying the optimization means replacing the sequence of insns with one
-new insn. The @var{template} controls ultimate output of assembler code
-for this combined insn. It works exactly like the template of a
-@code{define_insn}. Operand numbers in this template are the same ones
-used in matching the original sequence of insns.
-
-The result of a defined peephole optimizer does not need to match any of
-the insn patterns in the machine description; it does not even have an
-opportunity to match them. The peephole optimizer definition itself serves
-as the insn pattern to control how the insn is output.
-
-Defined peephole optimizers are run as assembler code is being output,
-so the insns they produce are never combined or rearranged in any way.
-
-Here is an example, taken from the 68000 machine description:
-
-@smallexample
-(define_peephole
- [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4)))
- (set (match_operand:DF 0 "register_operand" "=f")
- (match_operand:DF 1 "register_operand" "ad"))]
- "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
- "*
-@{
- rtx xoperands[2];
- xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1);
-#ifdef MOTOROLA
- output_asm_insn (\"move.l %1,(sp)\", xoperands);
- output_asm_insn (\"move.l %1,-(sp)\", operands);
- return \"fmove.d (sp)+,%0\";
-#else
- output_asm_insn (\"movel %1,sp@@\", xoperands);
- output_asm_insn (\"movel %1,sp@@-\", operands);
- return \"fmoved sp@@+,%0\";
-#endif
-@}
-")
-@end smallexample
-
-@need 1000
-The effect of this optimization is to change
-
-@smallexample
-@group
-jbsr _foobar
-addql #4,sp
-movel d1,sp@@-
-movel d0,sp@@-
-fmoved sp@@+,fp0
-@end group
-@end smallexample
-
-@noindent
-into
-
-@smallexample
-@group
-jbsr _foobar
-movel d1,sp@@
-movel d0,sp@@-
-fmoved sp@@+,fp0
-@end group
-@end smallexample
-
-@ignore
-@findex CC_REVERSED
-If a peephole matches a sequence including one or more jump insns, you must
-take account of the flags such as @code{CC_REVERSED} which specify that the
-condition codes are represented in an unusual manner. The compiler
-automatically alters any ordinary conditional jumps which occur in such
-situations, but the compiler cannot alter jumps which have been replaced by
-peephole optimizations. So it is up to you to alter the assembler code
-that the peephole produces. Supply C code to write the assembler output,
-and in this C code check the condition code status flags and change the
-assembler code as appropriate.
-@end ignore
-
-@var{insn-pattern-1} and so on look @emph{almost} like the second
-operand of @code{define_insn}. There is one important difference: the
-second operand of @code{define_insn} consists of one or more RTX's
-enclosed in square brackets. Usually, there is only one: then the same
-action can be written as an element of a @code{define_peephole}. But
-when there are multiple actions in a @code{define_insn}, they are
-implicitly enclosed in a @code{parallel}. Then you must explicitly
-write the @code{parallel}, and the square brackets within it, in the
-@code{define_peephole}. Thus, if an insn pattern looks like this,
-
-@smallexample
-(define_insn "divmodsi4"
- [(set (match_operand:SI 0 "general_operand" "=d")
- (div:SI (match_operand:SI 1 "general_operand" "0")
- (match_operand:SI 2 "general_operand" "dmsK")))
- (set (match_operand:SI 3 "general_operand" "=d")
- (mod:SI (match_dup 1) (match_dup 2)))]
- "TARGET_68020"
- "divsl%.l %2,%3:%0")
-@end smallexample
-
-@noindent
-then the way to mention this insn in a peephole is as follows:
-
-@smallexample
-(define_peephole
- [@dots{}
- (parallel
- [(set (match_operand:SI 0 "general_operand" "=d")
- (div:SI (match_operand:SI 1 "general_operand" "0")
- (match_operand:SI 2 "general_operand" "dmsK")))
- (set (match_operand:SI 3 "general_operand" "=d")
- (mod:SI (match_dup 1) (match_dup 2)))])
- @dots{}]
- @dots{})
-@end smallexample
-
-@node Expander Definitions
-@section Defining RTL Sequences for Code Generation
-@cindex expander definitions
-@cindex code generation RTL sequences
-@cindex defining RTL sequences for code generation
-
-On some target machines, some standard pattern names for RTL generation
-cannot be handled with single insn, but a sequence of RTL insns can
-represent them. For these target machines, you can write a
-@code{define_expand} to specify how to generate the sequence of RTL.
-
-@findex define_expand
-A @code{define_expand} is an RTL expression that looks almost like a
-@code{define_insn}; but, unlike the latter, a @code{define_expand} is used
-only for RTL generation and it can produce more than one RTL insn.
-
-A @code{define_expand} RTX has four operands:
-
-@itemize @bullet
-@item
-The name. Each @code{define_expand} must have a name, since the only
-use for it is to refer to it by name.
-
-@findex define_peephole
-@item
-The RTL template. This is just like the RTL template for a
-@code{define_peephole} in that it is a vector of RTL expressions
-each being one insn.
-
-@item
-The condition, a string containing a C expression. This expression is
-used to express how the availability of this pattern depends on
-subclasses of target machine, selected by command-line options when GNU
-CC is run. This is just like the condition of a @code{define_insn} that
-has a standard name. Therefore, the condition (if present) may not
-depend on the data in the insn being matched, but only the
-target-machine-type flags. The compiler needs to test these conditions
-during initialization in order to learn exactly which named instructions
-are available in a particular run.
-
-@item
-The preparation statements, a string containing zero or more C
-statements which are to be executed before RTL code is generated from
-the RTL template.
-
-Usually these statements prepare temporary registers for use as
-internal operands in the RTL template, but they can also generate RTL
-insns directly by calling routines such as @code{emit_insn}, etc.
-Any such insns precede the ones that come from the RTL template.
-@end itemize
-
-Every RTL insn emitted by a @code{define_expand} must match some
-@code{define_insn} in the machine description. Otherwise, the compiler
-will crash when trying to generate code for the insn or trying to optimize
-it.
-
-The RTL template, in addition to controlling generation of RTL insns,
-also describes the operands that need to be specified when this pattern
-is used. In particular, it gives a predicate for each operand.
-
-A true operand, which needs to be specified in order to generate RTL from
-the pattern, should be described with a @code{match_operand} in its first
-occurrence in the RTL template. This enters information on the operand's
-predicate into the tables that record such things. GNU CC uses the
-information to preload the operand into a register if that is required for
-valid RTL code. If the operand is referred to more than once, subsequent
-references should use @code{match_dup}.
-
-The RTL template may also refer to internal ``operands'' which are
-temporary registers or labels used only within the sequence made by the
-@code{define_expand}. Internal operands are substituted into the RTL
-template with @code{match_dup}, never with @code{match_operand}. The
-values of the internal operands are not passed in as arguments by the
-compiler when it requests use of this pattern. Instead, they are computed
-within the pattern, in the preparation statements. These statements
-compute the values and store them into the appropriate elements of
-@code{operands} so that @code{match_dup} can find them.
-
-There are two special macros defined for use in the preparation statements:
-@code{DONE} and @code{FAIL}. Use them with a following semicolon,
-as a statement.
+There are two special macros defined for use in the preparation statements:
+@code{DONE} and @code{FAIL}. Use them with a following semicolon,
+as a statement.
@table @code
addition of a large constant in two insns on a RISC machine, the way to
split the addition into two insns is machine-dependent.
-@cindex define_split
+@findex define_split
The @code{define_split} definition tells the compiler how to split a
complex insn into several simpler insns. It looks like this:
definitions, one for the insns that are valid and one for the insns that
are not valid.
+For the common case where the pattern of a define_split exactly matches the
+pattern of a define_insn, use @code{define_insn_and_split}. It looks like
+this:
+
+@smallexample
+(define_insn_and_split
+ [@var{insn-pattern}]
+ "@var{condition}"
+ "@var{output-template}"
+ "@var{split-condition}"
+ [@var{new-insn-pattern-1}
+ @var{new-insn-pattern-2}
+ @dots{}]
+ "@var{preparation statements}"
+ [@var{insn-attributes}])
+
+@end smallexample
+
+@var{insn-pattern}, @var{condition}, @var{output-template}, and
+@var{insn-attributes} are used as in @code{define_insn}. The
+@var{new-insn-pattern} vector and the @var{preparation-statements} are used as
+in a @code{define_split}. The @var{split-condition} is also used as in
+@code{define_split}, with the additional behavior that if the condition starts
+with @samp{&&}, the condition used for the split will be the constructed as a
+logical "and" of the split condition with the insn condition. For example,
+from i386.md:
+
+@smallexample
+(define_insn_and_split "zero_extendhisi2_and"
+ [(set (match_operand:SI 0 "register_operand" "=r")
+ (zero_extend:SI (match_operand:HI 1 "register_operand" "0")))
+ (clobber (reg:CC 17))]
+ "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size"
+ "#"
+ "&& reload_completed"
+ [(parallel [(set (match_dup 0) (and:SI (match_dup 0) (const_int 65535)))
+ (clobber (reg:CC 17))])]
+ ""
+ [(set_attr "type" "alu1")])
+
+@end smallexample
+
+In this case, the actual split condition will be
+"TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed."
+
+The @code{define_insn_and_split} construction provides exactly the same
+functionality as two separate @code{define_insn} and @code{define_split}
+patterns. It exists for compactness, and as a maintenance tool to prevent
+having to ensure the two patterns' templates match.
+
+@node Peephole Definitions
+@section Machine-Specific Peephole Optimizers
+@cindex peephole optimizer definitions
+@cindex defining peephole optimizers
+
+In addition to instruction patterns the @file{md} file may contain
+definitions of machine-specific peephole optimizations.
+
+The combiner does not notice certain peephole optimizations when the data
+flow in the program does not suggest that it should try them. For example,
+sometimes two consecutive insns related in purpose can be combined even
+though the second one does not appear to use a register computed in the
+first one. A machine-specific peephole optimizer can detect such
+opportunities.
+
+There are two forms of peephole definitions that may be used. The
+original @code{define_peephole} is run at assembly output time to
+match insns and substitute assembly text. Use of @code{define_peephole}
+is deprecated.
+
+A newer @code{define_peephole2} matches insns and substitutes new
+insns. The @code{peephole2} pass is run after register allocation
+but before scheduling, which may result in much better code for
+targets that do scheduling.
+
+@menu
+* define_peephole:: RTL to Text Peephole Optimizers
+* define_peephole2:: RTL to RTL Peephole Optimizers
+@end menu
+
+@node define_peephole
+@subsection RTL to Text Peephole Optimizers
+@findex define_peephole
+
+@need 1000
+A definition looks like this:
+
+@smallexample
+(define_peephole
+ [@var{insn-pattern-1}
+ @var{insn-pattern-2}
+ @dots{}]
+ "@var{condition}"
+ "@var{template}"
+ "@var{optional insn-attributes}")
+@end smallexample
+
+@noindent
+The last string operand may be omitted if you are not using any
+machine-specific information in this machine description. If present,
+it must obey the same rules as in a @code{define_insn}.
+
+In this skeleton, @var{insn-pattern-1} and so on are patterns to match
+consecutive insns. The optimization applies to a sequence of insns when
+@var{insn-pattern-1} matches the first one, @var{insn-pattern-2} matches
+the next, and so on.@refill
+
+Each of the insns matched by a peephole must also match a
+@code{define_insn}. Peepholes are checked only at the last stage just
+before code generation, and only optionally. Therefore, any insn which
+would match a peephole but no @code{define_insn} will cause a crash in code
+generation in an unoptimized compilation, or at various optimization
+stages.
+
+The operands of the insns are matched with @code{match_operands},
+@code{match_operator}, and @code{match_dup}, as usual. What is not
+usual is that the operand numbers apply to all the insn patterns in the
+definition. So, you can check for identical operands in two insns by
+using @code{match_operand} in one insn and @code{match_dup} in the
+other.
+
+The operand constraints used in @code{match_operand} patterns do not have
+any direct effect on the applicability of the peephole, but they will
+be validated afterward, so make sure your constraints are general enough
+to apply whenever the peephole matches. If the peephole matches
+but the constraints are not satisfied, the compiler will crash.
+
+It is safe to omit constraints in all the operands of the peephole; or
+you can write constraints which serve as a double-check on the criteria
+previously tested.
+
+Once a sequence of insns matches the patterns, the @var{condition} is
+checked. This is a C expression which makes the final decision whether to
+perform the optimization (we do so if the expression is nonzero). If
+@var{condition} is omitted (in other words, the string is empty) then the
+optimization is applied to every sequence of insns that matches the
+patterns.
+
+The defined peephole optimizations are applied after register allocation
+is complete. Therefore, the peephole definition can check which
+operands have ended up in which kinds of registers, just by looking at
+the operands.
+
+@findex prev_active_insn
+The way to refer to the operands in @var{condition} is to write
+@code{operands[@var{i}]} for operand number @var{i} (as matched by
+@code{(match_operand @var{i} @dots{})}). Use the variable @code{insn}
+to refer to the last of the insns being matched; use
+@code{prev_active_insn} to find the preceding insns.
+
+@findex dead_or_set_p
+When optimizing computations with intermediate results, you can use
+@var{condition} to match only when the intermediate results are not used
+elsewhere. Use the C expression @code{dead_or_set_p (@var{insn},
+@var{op})}, where @var{insn} is the insn in which you expect the value
+to be used for the last time (from the value of @code{insn}, together
+with use of @code{prev_nonnote_insn}), and @var{op} is the intermediate
+value (from @code{operands[@var{i}]}).@refill
+
+Applying the optimization means replacing the sequence of insns with one
+new insn. The @var{template} controls ultimate output of assembler code
+for this combined insn. It works exactly like the template of a
+@code{define_insn}. Operand numbers in this template are the same ones
+used in matching the original sequence of insns.
+
+The result of a defined peephole optimizer does not need to match any of
+the insn patterns in the machine description; it does not even have an
+opportunity to match them. The peephole optimizer definition itself serves
+as the insn pattern to control how the insn is output.
+
+Defined peephole optimizers are run as assembler code is being output,
+so the insns they produce are never combined or rearranged in any way.
+
+Here is an example, taken from the 68000 machine description:
+
+@smallexample
+(define_peephole
+ [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4)))
+ (set (match_operand:DF 0 "register_operand" "=f")
+ (match_operand:DF 1 "register_operand" "ad"))]
+ "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
+ "*
+@{
+ rtx xoperands[2];
+ xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1);
+#ifdef MOTOROLA
+ output_asm_insn (\"move.l %1,(sp)\", xoperands);
+ output_asm_insn (\"move.l %1,-(sp)\", operands);
+ return \"fmove.d (sp)+,%0\";
+#else
+ output_asm_insn (\"movel %1,sp@@\", xoperands);
+ output_asm_insn (\"movel %1,sp@@-\", operands);
+ return \"fmoved sp@@+,%0\";
+#endif
+@}
+")
+@end smallexample
+
+@need 1000
+The effect of this optimization is to change
+
+@smallexample
+@group
+jbsr _foobar
+addql #4,sp
+movel d1,sp@@-
+movel d0,sp@@-
+fmoved sp@@+,fp0
+@end group
+@end smallexample
+
+@noindent
+into
+
+@smallexample
+@group
+jbsr _foobar
+movel d1,sp@@
+movel d0,sp@@-
+fmoved sp@@+,fp0
+@end group
+@end smallexample
+
+@ignore
+@findex CC_REVERSED
+If a peephole matches a sequence including one or more jump insns, you must
+take account of the flags such as @code{CC_REVERSED} which specify that the
+condition codes are represented in an unusual manner. The compiler
+automatically alters any ordinary conditional jumps which occur in such
+situations, but the compiler cannot alter jumps which have been replaced by
+peephole optimizations. So it is up to you to alter the assembler code
+that the peephole produces. Supply C code to write the assembler output,
+and in this C code check the condition code status flags and change the
+assembler code as appropriate.
+@end ignore
+
+@var{insn-pattern-1} and so on look @emph{almost} like the second
+operand of @code{define_insn}. There is one important difference: the
+second operand of @code{define_insn} consists of one or more RTX's
+enclosed in square brackets. Usually, there is only one: then the same
+action can be written as an element of a @code{define_peephole}. But
+when there are multiple actions in a @code{define_insn}, they are
+implicitly enclosed in a @code{parallel}. Then you must explicitly
+write the @code{parallel}, and the square brackets within it, in the
+@code{define_peephole}. Thus, if an insn pattern looks like this,
+
+@smallexample
+(define_insn "divmodsi4"
+ [(set (match_operand:SI 0 "general_operand" "=d")
+ (div:SI (match_operand:SI 1 "general_operand" "0")
+ (match_operand:SI 2 "general_operand" "dmsK")))
+ (set (match_operand:SI 3 "general_operand" "=d")
+ (mod:SI (match_dup 1) (match_dup 2)))]
+ "TARGET_68020"
+ "divsl%.l %2,%3:%0")
+@end smallexample
+
+@noindent
+then the way to mention this insn in a peephole is as follows:
+
+@smallexample
+(define_peephole
+ [@dots{}
+ (parallel
+ [(set (match_operand:SI 0 "general_operand" "=d")
+ (div:SI (match_operand:SI 1 "general_operand" "0")
+ (match_operand:SI 2 "general_operand" "dmsK")))
+ (set (match_operand:SI 3 "general_operand" "=d")
+ (mod:SI (match_dup 1) (match_dup 2)))])
+ @dots{}]
+ @dots{})
+@end smallexample
+
+@node define_peephole2
+@subsection RTL to RTL Peephole Optimizers
+@findex define_peephole2
+
+The @code{define_peephole2} definition tells the compiler how to
+substitute one sequence of instructions for another sequence,
+what additional scratch registers may be needed and what their
+lifetimes must be.
+
+@smallexample
+(define_peephole2
+ [@var{insn-pattern-1}
+ @var{insn-pattern-2}
+ @dots{}]
+ "@var{condition}"
+ [@var{new-insn-pattern-1}
+ @var{new-insn-pattern-2}
+ @dots{}]
+ "@var{preparation statements}")
+@end smallexample
+
+The definition is almost identical to @code{define_split}
+(@pxref{Insn Splitting}) except that the pattern to match is not a
+single instruction, but a sequence of instructions.
+
+It is possible to request additional scratch registers for use in the
+output template. If appropriate registers are not free, the pattern
+will simply not match.
+
+@findex match_scratch
+@findex match_dup
+Scratch registers are requested with a @code{match_scratch} pattern at
+the top level of the input pattern. The allocated register (initially) will
+be dead at the point requested within the original sequence. If the scratch
+is used at more than a single point, a @code{match_dup} pattern at the
+top level of the input pattern marks the last position in the input sequence
+at which the register must be available.
+
+Here is an example from the IA-32 machine description:
+
+@smallexample
+(define_peephole2
+ [(match_scratch:SI 2 "r")
+ (parallel [(set (match_operand:SI 0 "register_operand" "")
+ (match_operator:SI 3 "arith_or_logical_operator"
+ [(match_dup 0)
+ (match_operand:SI 1 "memory_operand" "")]))
+ (clobber (reg:CC 17))])]
+ "! optimize_size && ! TARGET_READ_MODIFY"
+ [(set (match_dup 2) (match_dup 1))
+ (parallel [(set (match_dup 0)
+ (match_op_dup 3 [(match_dup 0) (match_dup 2)]))
+ (clobber (reg:CC 17))])]
+ "")
+@end smallexample
+
+@noindent
+This pattern tries to split a load from its use in the hopes that we'll be
+able to schedule around the memory load latency. It allocates a single
+@code{SImode} register of class @code{GENERAL_REGS} (@code{"r"}) that needs
+to be live only at the point just before the arithmetic.
+
+A real example requring extended scratch lifetimes is harder to come by,
+so here's a silly made-up example:
+
+@smallexample
+(define_peephole2
+ [(match_scratch:SI 4 "r")
+ (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" ""))
+ (set (match_operand:SI 2 "" "") (match_dup 1))
+ (match_dup 4)
+ (set (match_operand:SI 3 "" "") (match_dup 1))]
+ "@var{determine 1 does not overlap 0 and 2}"
+ [(set (match_dup 4) (match_dup 1))
+ (set (match_dup 0) (match_dup 4))
+ (set (match_dup 2) (match_dup 4))]
+ (set (match_dup 3) (match_dup 4))]
+ "")
+@end smallexample
+
+@noindent
+If we had not added the @code{(match_dup 4)} in the middle of the input
+sequence, it might have been the case that the register we chose at the
+beginning of the sequence is killed by the first or second @code{set}.
+
@node Insn Attributes
@section Instruction Attributes
@cindex insn attributes
conflict. We welcome any examples of how function unit conflicts work
in such processors and suggestions for their representation.
@end ifset
+
+@node Conditional Execution
+@section Conditional Execution
+@cindex conditional execution
+@cindex predication
+
+A number of architectures provide for some form of conditional
+execution, or predication. The hallmark of this feature is the
+ability to nullify most of the instructions in the instruction set.
+When the instruction set is large and not entirely symmetric, it
+can be quite tedious to describe these forms directly in the
+@file{.md} file. An alternative is the @code{define_cond_exec} template.
+
+@findex define_cond_exec
+@smallexample
+(define_cond_exec
+ [@var{predicate-pattern}]
+ "@var{condition}"
+ "@var{output template}")
+@end smallexample
+
+@var{predicate-pattern} is the condition that must be true for the
+insn to be executed at runtime and should match a relational operator.
+One can use @code{match_operator} to match several relational operators
+at once. Any @code{match_operand} operands must have no more than one
+alternative.
+
+@var{condition} is a C expression that must be true for the generated
+pattern to match.
+
+@findex current_insn_predicate
+@var{output template} is a string similar to the @code{define_insn}
+output template (@pxref{Output Template}), except that the @samp{*}
+and @samp{@@} special cases do not apply. This is only useful if the
+assembly text for the predicate is a simple prefix to the main insn.
+In order to handle the general case, there is a global variable
+@code{current_insn_predicate} that will contain the entire predicate
+if the current insn is predicated, and will otherwise be @code{NULL}.
+
+When @code{define_cond_exec} is used, an implicit reference to
+the @code{predicable} instruction attribute is made.
+@xref{Insn Attributes}. This attribute must be boolean (i.e. have
+exactly two elements in its @var{list-of-values}). Further, it must
+not be used with complex expressions. That is, the default and all
+uses in the insns must be a simple constant, not dependant on the
+alternative or anything else.
+
+For each @code{define_insn} for which the @code{predicable}
+attribute is true, a new @code{define_insn} pattern will be
+generated that matches a predicated version of the instruction.
+For example,
+
+@smallexample
+(define_insn "addsi"
+ [(set (match_operand:SI 0 "register_operand" "r")
+ (plus:SI (match_operand:SI 1 "register_operand" "r")
+ (match_operand:SI 2 "register_operand" "r")))]
+ "@var{test1}"
+ "add %2,%1,%0")
+
+(define_cond_exec
+ [(ne (match_operand:CC 0 "register_operand" "c")
+ (const_int 0))]
+ "@var{test2}"
+ "(%0)")
+@end smallexample
+
+@noindent
+generates a new pattern
+
+@smallexample
+(define_insn ""
+ [(cond_exec
+ (ne (match_operand:CC 3 "register_operand" "c") (const_int 0))
+ (set (match_operand:SI 0 "register_operand" "r")
+ (plus:SI (match_operand:SI 1 "register_operand" "r")
+ (match_operand:SI 2 "register_operand" "r"))))]
+ "(@var{test2}) && (@var{test1})"
+ "(%3) add %2,%1,%0")
+@end smallexample
OSDN Git Service
