-@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.
@end menu
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
@item y
@samp{CR} register (condition register)
+@item z
+@samp{FPMEM} stack memory for FPR-GPR transfers
+
@item I
Signed 16 bit constant
@item J
-Constant whose low 16 bits are 0
+Unsigned 16 bit constant shifted left 16 bits (use @samp{L} instead for
+@code{SImode} constants)
@item K
-Constant whose high 16 bits are 0
+Unsigned 16 bit constant
@item L
-Constant suitable as a mask operand
+Signed 16 bit constant shifted left 16 bits
@item M
Constant larger than 31
AIX TOC entry
@item S
-Windows NT SYMBOL_REF
+Constant suitable as a 64-bit mask operand
@item T
-Windows NT LABEL_REF
+Constant suitable as a 32-bit mask operand
@item U
System V Release 4 small data area reference
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
machines explicit memory references will get optional reloads.
If a scratch register is required to move an object to or from memory,
-it can be allocated using @code{gen_reg_rtx} prior to reload. But this
-is impossible during and after reload. If there are cases needing
+it can be allocated using @code{gen_reg_rtx} prior to life analysis.
+
+If there are cases needing
scratch registers after reload, you must define
@code{SECONDARY_INPUT_RELOAD_CLASS} and perhaps also
@code{SECONDARY_OUTPUT_RELOAD_CLASS} to detect them, and provide
patterns @samp{reload_in@var{m}} or @samp{reload_out@var{m}} to handle
them. @xref{Register Classes}.
+@findex no_new_pseudos
+The global variable @code{no_new_pseudos} can be used to determine if it
+is unsafe to create new pseudo registers. If this variable is nonzero, then
+it is unsafe to call @code{gen_reg_rtx} to allocate a new pseudo.
+
The constraints on a @samp{mov@var{m}} must permit moving any hard
register to any other hard register provided that
@code{HARD_REGNO_MODE_OK} permits mode @var{m} in both registers and
multiplication.
@cindex @code{smul@var{m}3_highpart} instruction pattern
-@item @samp{mul@var{m}3_highpart}
+@item @samp{smul@var{m}3_highpart}
Perform a signed multiplication of operands 1 and 2, which have mode
@var{m}, and store the most significant half of the product in operand 0.
The least significant half of the product is discarded.
Machines that use a pseudo register for the condition code value, or
where the mode used for the comparison depends on the condition being
-tested, should also use the above mechanism. @xref{Jump Patterns}
+tested, should also use the above mechanism. @xref{Jump Patterns}.
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
When saving the stack pointer, operand 0 is the save area and operand 1
is the stack pointer. The mode used to allocate the save area defaults
to @code{Pmode} but you can override that choice by defining the
-@code{STACK_SAVEAREA_MODE} macro (@pxref{Storage_Layout}). You must
+@code{STACK_SAVEAREA_MODE} macro (@pxref{Storage Layout}). You must
specify an integral mode, or @code{VOIDmode} if no save area is needed
for a particular type of save (either because no save is needed or
because a machine-specific save area can be used). 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.
You will not normally need to define this pattern unless you also define
@code{builtin_setjmp_setup}. The single argument is a pointer to the
@code{jmp_buf}.
+
+@cindex @code{eh_epilogue} instruction pattern
+@item @samp{eh_epilogue}
+This pattern, if defined, affects the way @code{__builtin_eh_return},
+and thence @code{__throw} are built. It is intended to allow communication
+between the exception handling machinery and the normal epilogue code
+for the target.
+
+The pattern takes three arguments. The first is the exception context
+pointer. This will have already been copied to the function return
+register appropriate for a pointer; normally this can be ignored. The
+second argument is an offset to be added to the stack pointer. It will
+have been copied to some arbitrary call-clobbered hard reg so that it
+will survive until after reload to when the normal epilogue is generated.
+The final argument is the address of the exception handler to which
+the function should return. This will normally need to copied by the
+pattern to some special register.
+
+This pattern must be defined if @code{RETURN_ADDR_RTX} does not yield
+something that can be reliably and permanently modified, i.e. a fixed
+hard register or a stack memory reference.
+
+@cindex @code{prologue} instruction pattern
+@item @samp{prologue}
+This pattern, if defined, emits RTL for entry to a function. The function
+entry is resposible for setting up the stack frame, initializing the frame
+pointer register, saving callee saved registers, etc.
+
+Using a prologue pattern is generally preferred over defining
+@code{FUNCTION_PROLOGUE} to emit assembly code for the prologue.
+
+The @code{prologue} pattern is particularly useful for targets which perform
+instruction scheduling.
+
+@cindex @code{epilogue} instruction pattern
+@item @samp{epilogue}
+This pattern, if defined, emits RTL for exit from a function. The function
+exit is resposible for deallocating the stack frame, restoring callee saved
+registers and emitting the return instruction.
+
+Using an epilogue pattern is generally preferred over defining
+@code{FUNCTION_EPILOGUE} to emit assembly code for the prologue.
+
+The @code{epilogue} pattern is particularly useful for targets which perform
+instruction scheduling or which have delay slots for their return instruction.
+
+@cindex @code{sibcall_epilogue} instruction pattern
+@item @samp{sibcall_epilogue}
+This pattern, if defined, emits RTL for exit from a function without the final
+branch back to the calling function. This pattern will be emitted before any
+sibling call (aka tail call) sites.
+
+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
-
-In addition to instruction patterns the @file{md} file may contain
-definitions of machine-specific peephole optimizations.
+@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
-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.
+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.
-@need 1000
-A definition looks like this:
+@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.
-@smallexample
-(define_peephole
- [@var{insn-pattern-1}
- @var{insn-pattern-2}
- @dots{}]
- "@var{condition}"
- "@var{template}"
- "@var{optional insn-attributes}")
-@end smallexample
+A @code{define_expand} RTX has four operands:
-@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}.
+@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.
-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 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}.
-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 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.
-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.
+@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 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.
+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
-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.
+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.
-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 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.
-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.
+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}.
-@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.
+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,
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.
+@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
must be non-negative.
The value of a numeric attribute can be specified either with a
-@code{const_int} or as an integer represented as a string in
-@code{const_string}, @code{eq_attr} (see below), and @code{set_attr}
-(@pxref{Tagging Insns}) expressions.
+@code{const_int}, or as an integer represented as a string in
+@code{const_string}, @code{eq_attr} (see below), @code{attr},
+@code{symbol_ref}, simple arithmetic expressions, and @code{set_attr}
+overrides on specific instructions (@pxref{Tagging Insns}).
@cindex @code{const_string} and attributes
@item (const_string @var{value})
@code{attr_flag} is only used during delay slot scheduling and has no
meaning to other passes of the compiler.
+
+@findex attr
+@item (attr @var{name})
+The value of another attribute is returned. This is most useful
+for numeric attributes, as @code{eq_attr} and @code{attr_flag}
+produce more efficient code for non-numeric attributes.
@end table
@node Tagging Insns
OSDN Git Service
