-@c Copyright (C) 1988,89,92,93,94,96 Free Software Foundation, Inc.
+@c Copyright (C) 1988, 89, 92, 93, 94, 96, 1998 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
Like @code{match_op_dup}, but for @code{match_parallel} instead of
@code{match_operator}.
+@findex match_insn
+@item (match_insn @var{predicate})
+Match a complete insn. Unlike the other @code{match_*} recognizers,
+@code{match_insn} does not take an operand number.
+
+The machine mode @var{m} of @code{match_insn} works like that of
+@code{match_operand}: it is passed as the second argument to the
+predicate function, and that function is solely responsible for
+deciding whether the expression to be matched ``has'' that mode.
+
+@findex match_insn2
+@item (match_insn2 @var{n} @var{predicate})
+Match a complete insn.
+
+The machine mode @var{m} of @code{match_insn2} works like that of
+@code{match_operand}: it is passed as the second argument to the
+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
* 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
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 &
@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
@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
-
-@ifset INTERNALS
@node Standard Names
@section Standard Pattern Names For Generation
@cindex standard pattern names
Here is a table of the instruction names that are meaningful in the RTL
generation pass of the compiler. Giving one of these names to an
instruction pattern tells the RTL generation pass that it can use the
-pattern in to accomplish a certain task.
+pattern to accomplish a certain task.
@table @asis
@cindex @code{mov@var{m}} instruction pattern
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.
@item @samp{movstr@var{m}}
Block move instruction. The addresses of the destination and source
strings are the first two operands, and both are in mode @code{Pmode}.
+
The number of bytes to move is the third operand, in mode @var{m}.
+Usually, you specify @code{word_mode} for @var{m}. However, if you can
+generate better code knowing the range of valid lengths is smaller than
+those representable in a full word, you should provide a pattern with a
+mode corresponding to the range of values you can handle efficiently
+(e.g., @code{QImode} for values in the range 0--127; note we avoid numbers
+that appear negative) and also a pattern with @code{word_mode}.
The fourth operand is the known shared alignment of the source and
destination, in the form of a @code{const_int} rtx. Thus, if the
compiler knows that both source and destination are word-aligned,
it may provide the value 4 for this operand.
+Descriptions of multiple @code{movstr@var{m}} patterns can only be
+beneficial if the patterns for smaller modes have fewer restrictions
+on their first, second and fourth operands. Note that the mode @var{m}
+in @code{movstr@var{m}} does not impose any restriction on the mode of
+individually moved data units in the block.
+
These patterns need not give special consideration to the possibility
that the source and destination strings might overlap.
@item @samp{clrstr@var{m}}
Block clear instruction. The addresses of the destination string is the
first operand, in mode @code{Pmode}. The number of bytes to clear is
-the second operand, in mode @var{m}.
+the second operand, in mode @var{m}. See @samp{movstr@var{m}} for
+a discussion of the choice of mode.
The third operand is the known alignment of the destination, in the form
of a @code{const_int} rtx. Thus, if the compiler knows that the
destination is word-aligned, it may provide the value 4 for this
operand.
+The use for multiple @code{clrstr@var{m}} is as for @code{movstr@var{m}}.
+
@cindex @code{cmpstr@var{m}} instruction pattern
@item @samp{cmpstr@var{m}}
Block compare instruction, with five operands. Operand 0 is the output;
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.
@item @samp{call}
Subroutine call instruction returning no value. Operand 0 is the
function to call; operand 1 is the number of bytes of arguments pushed
-(in mode @code{SImode}, except it is normally a @code{const_int});
-operand 2 is the number of registers used as operands.
+as a @code{const_int}; operand 2 is the number of registers used as
+operands.
On most machines, operand 2 is not actually stored into the RTL
pattern. It is supplied for the sake of some RISC machines which need
@end enumerate
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 is the
-mode of operand 0. 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 stack pointer and operand 1 is the
-save area for restore operations. If @samp{save_stack_block} is
-defined, operand 0 must not be @code{VOIDmode} since these saves can be
-arbitrarily nested.
+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
+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
+stack pointer and operand 1 is the save area for restore operations. If
+@samp{save_stack_block} is defined, operand 0 must not be
+@code{VOIDmode} since these saves can be arbitrarily nested.
A save area is a @code{mem} that is at a constant offset from
@code{virtual_stack_vars_rtx} when the stack pointer is saved for use by
Emit code to generate a non-local goto, e.g., a jump from one function
to a label in an outer function. This pattern has four arguments,
each representing a value to be used in the jump. The first
-argument is to be loadedd into the frame pointer, the second is
+argument is to be loaded into the frame pointer, the second is
the address to branch to (code to dispatch to the actual label),
the third is the address of a location where the stack is saved,
and the last is the address of the label, to be placed in the
nonlocal goto after the code already generated by GNU CC. You will not
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. There are no
-arguments.
+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
+that is shared by all functions of a given module need not be restored.
+There are no arguments.
@cindex @code{exception_receiver} instruction pattern
@item @samp{exception_receiver}
table, must be restored after control flow is branched to the handler of
an exception. There are no arguments.
+@cindex @code{builtin_setjmp_setup} instruction pattern
+@item @samp{builtin_setjmp_setup}
+This pattern, if defined, contains additional code needed to initialize
+the @code{jmp_buf}. You will not 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. Though it is
+preferred that the pointer value be recalculated if possible (given the
+address of a label for instance). The single argument is a pointer to
+the @code{jmp_buf}. Note that the buffer is five words long and that
+the first three are normally used by the generic mechanism.
+
@cindex @code{builtin_setjmp_receiver} instruction pattern
@item @samp{builtin_setjmp_receiver}
This pattern, if defined, contains code needed at the site of an
builtin setjmp that isn't needed at the site of a nonlocal goto. You
will not 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. This pattern is called immediate after the
-call to @code{__dummy} has been emitted. There are no arguments.
+table, must be restored. It takes one argument, which is the label
+to which builtin_longjmp transfered control; this pattern may be emitted
+at a small offset from that label.
+
+@cindex @code{builtin_longjmp} instruction pattern
+@item @samp{builtin_longjmp}
+This pattern, if defined, performs the entire action of the longjmp.
+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.
@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.
-
-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.
-
-@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 Expander Definitions
@section Defining RTL Sequences for Code Generation
@cindex expander definitions
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.
+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}.
@item
The condition, a string containing a C expression. This expression is
(match_dup 2)))]
""
"operands[2]
- = force_reg (SImode, gen_rtx (CONST_INT,
- VOIDmode, 65535)); ")
+ = force_reg (SImode, GEN_INT (65535)); ")
@end smallexample
@strong{Note:} If the @code{define_expand} is used to serve a
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:
if (low & 0x8000)
high++, low |= 0xffff0000;
- operands[3] = gen_rtx (CONST_INT, VOIDmode, high << 16);
- operands[4] = gen_rtx (CONST_INT, VOIDmode, low);
+ operands[3] = GEN_INT (high << 16);
+ operands[4] = GEN_INT (low);
@}")
@end smallexample
int sextc = (c << 16) >> 16;
int xorv = c ^ sextc;
- operands[4] = gen_rtx (CONST_INT, VOIDmode, xorv);
- operands[5] = gen_rtx (CONST_INT, VOIDmode, sextc);
+ operands[4] = GEN_INT (xorv);
+ operands[5] = GEN_INT (sextc);
@}")
@end smallexample
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
If defined, modifies the length assigned to instruction @var{insn} as a
function of the context in which it is used. @var{length} is an lvalue
that contains the initially computed length of the insn and should be
-updated with the correct length of the insn. If updating is required,
-@var{insn} must not be a varying-length insn.
+updated with the correct length of the insn.
This macro will normally not be required. A case in which it is
required is the ROMP. On this machine, the size of an @code{addr_vec}
OSDN Git Service
