* 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
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}
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
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
@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
+entry is responsible 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
@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
+exit is responsible for deallocating the stack frame, restoring callee saved
registers and emitting the return instruction.
Using an epilogue pattern is generally preferred over defining
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
@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,
+A real example requiring extended scratch lifetimes is harder to come by,
so here's a silly made-up example:
@smallexample
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 dependent 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
