-@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1996, 1998, 1999, 2000, 2001, 2002
+@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1996, 1998, 1999, 2000, 2001,
+@c 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009
@c Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
* Example:: An explained example of a @code{define_insn} pattern.
* RTL Template:: The RTL template defines what insns match a pattern.
* Output Template:: The output template says how to make assembler code
- from such an insn.
+ from such an insn.
* Output Statement:: For more generality, write C code to output
- the assembler code.
-* Constraints:: When not all operands are general operands.
+ the assembler code.
+* Predicates:: Controlling what kinds of operands can be used
+ for an insn.
+* Constraints:: Fine-tuning operand selection.
* Standard Names:: Names mark patterns to use for code generation.
* Pattern Ordering:: When the order of patterns makes a difference.
* Dependent Patterns:: Having one pattern may make you need another.
* Looping Patterns:: How to define patterns for special looping insns.
* Insn Canonicalizations::Canonicalization of Instructions
* Expander Definitions::Generating a sequence of several RTL insns
- for a standard operation.
+ for a standard operation.
* Insn Splitting:: Splitting Instructions into Multiple Instructions.
-* Including Patterns:: Including Patterns in Machine Descriptions.
+* Including Patterns:: Including Patterns in Machine Descriptions.
* 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.
+ predication.
* Constant Definitions::Defining symbolic constants that can be used in the
md file.
+* Iterators:: Using iterators to generate patterns from a template.
@end menu
@node Overview
Here is an actual example of an instruction pattern, for the 68000/68020.
-@example
+@smallexample
(define_insn "tstsi"
[(set (cc0)
(match_operand:SI 0 "general_operand" "rm"))]
return \"tstl %0\";
return \"cmpl #0,%0\";
@}")
-@end example
+@end smallexample
@noindent
This can also be written using braced strings:
-@example
+@smallexample
(define_insn "tstsi"
[(set (cc0)
(match_operand:SI 0 "general_operand" "rm"))]
return "tstl %0";
return "cmpl #0,%0";
@})
-@end example
+@end smallexample
This is an instruction that sets the condition codes based on the value of
a general operand. It has no condition, so any insn whose RTL description
used only in @code{match_dup} expressions have higher values than all
other operand numbers.
-@var{predicate} is a string that is the name of a C function that accepts two
-arguments, an expression and a machine mode. During matching, the
-function will be called with the putative operand as the expression and
-@var{m} as the mode argument (if @var{m} is not specified,
-@code{VOIDmode} will be used, which normally causes @var{predicate} to accept
-any mode). If it returns zero, this instruction pattern fails to match.
-@var{predicate} may be an empty string; then it means no test is to be done
-on the operand, so anything which occurs in this position is valid.
+@var{predicate} is a string that is the name of a function that
+accepts two arguments, an expression and a machine mode.
+@xref{Predicates}. During matching, the function will be called with
+the putative operand as the expression and @var{m} as the mode
+argument (if @var{m} is not specified, @code{VOIDmode} will be used,
+which normally causes @var{predicate} to accept any mode). If it
+returns zero, this instruction pattern fails to match.
+@var{predicate} may be an empty string; then it means no test is to be
+done on the operand, so anything which occurs in this position is
+valid.
Most of the time, @var{predicate} will reject modes other than @var{m}---but
not always. For example, the predicate @code{address_operand} uses
@var{constraint} controls reloading and the choice of the best register
class to use for a value, as explained later (@pxref{Constraints}).
+If the constraint would be an empty string, it can be omitted.
People are often unclear on the difference between the constraint and the
predicate. The predicate helps decide whether a given insn matches the
pattern. The constraint plays no role in this decision; instead, it
controls various decisions in the case of an insn which does match.
-@findex general_operand
-On CISC machines, the most common @var{predicate} is
-@code{"general_operand"}. This function checks that the putative
-operand is either a constant, a register or a memory reference, and that
-it is valid for mode @var{m}.
-
-@findex register_operand
-For an operand that must be a register, @var{predicate} should be
-@code{"register_operand"}. Using @code{"general_operand"} would be
-valid, since the reload pass would copy any non-register operands
-through registers, but this would make GCC do extra work, it would
-prevent invariant operands (such as constant) from being removed from
-loops, and it would prevent the register allocator from doing the best
-possible job. On RISC machines, it is usually most efficient to allow
-@var{predicate} to accept only objects that the constraints allow.
-
-@findex immediate_operand
-For an operand that must be a constant, you must be sure to either use
-@code{"immediate_operand"} for @var{predicate}, or make the instruction
-pattern's extra condition require a constant, or both. You cannot
-expect the constraints to do this work! If the constraints allow only
-constants, but the predicate allows something else, the compiler will
-crash when that case arises.
-
@findex match_scratch
@item (match_scratch:@var{m} @var{n} @var{constraint})
This expression is also a placeholder for operand number @var{n}
@smallexample
int
-commutative_operator (x, mode)
+commutative_integer_operator (x, mode)
rtx x;
enum machine_mode mode;
@{
enum rtx_code code = GET_CODE (x);
if (GET_MODE (x) != mode)
return 0;
- return (GET_RTX_CLASS (code) == 'c'
+ return (GET_RTX_CLASS (code) == RTX_COMM_ARITH
|| code == EQ || code == NE);
@}
@end smallexample
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.
-
@end table
@node Output Template
clrmem %0")
@end group
@end smallexample
+
+@node Predicates
+@section Predicates
+@cindex predicates
+@cindex operand predicates
+@cindex operator predicates
+
+A predicate determines whether a @code{match_operand} or
+@code{match_operator} expression matches, and therefore whether the
+surrounding instruction pattern will be used for that combination of
+operands. GCC has a number of machine-independent predicates, and you
+can define machine-specific predicates as needed. By convention,
+predicates used with @code{match_operand} have names that end in
+@samp{_operand}, and those used with @code{match_operator} have names
+that end in @samp{_operator}.
+
+All predicates are Boolean functions (in the mathematical sense) of
+two arguments: the RTL expression that is being considered at that
+position in the instruction pattern, and the machine mode that the
+@code{match_operand} or @code{match_operator} specifies. In this
+section, the first argument is called @var{op} and the second argument
+@var{mode}. Predicates can be called from C as ordinary two-argument
+functions; this can be useful in output templates or other
+machine-specific code.
+
+Operand predicates can allow operands that are not actually acceptable
+to the hardware, as long as the constraints give reload the ability to
+fix them up (@pxref{Constraints}). However, GCC will usually generate
+better code if the predicates specify the requirements of the machine
+instructions as closely as possible. Reload cannot fix up operands
+that must be constants (``immediate operands''); you must use a
+predicate that allows only constants, or else enforce the requirement
+in the extra condition.
+
+@cindex predicates and machine modes
+@cindex normal predicates
+@cindex special predicates
+Most predicates handle their @var{mode} argument in a uniform manner.
+If @var{mode} is @code{VOIDmode} (unspecified), then @var{op} can have
+any mode. If @var{mode} is anything else, then @var{op} must have the
+same mode, unless @var{op} is a @code{CONST_INT} or integer
+@code{CONST_DOUBLE}. These RTL expressions always have
+@code{VOIDmode}, so it would be counterproductive to check that their
+mode matches. Instead, predicates that accept @code{CONST_INT} and/or
+integer @code{CONST_DOUBLE} check that the value stored in the
+constant will fit in the requested mode.
+
+Predicates with this behavior are called @dfn{normal}.
+@command{genrecog} can optimize the instruction recognizer based on
+knowledge of how normal predicates treat modes. It can also diagnose
+certain kinds of common errors in the use of normal predicates; for
+instance, it is almost always an error to use a normal predicate
+without specifying a mode.
+
+Predicates that do something different with their @var{mode} argument
+are called @dfn{special}. The generic predicates
+@code{address_operand} and @code{pmode_register_operand} are special
+predicates. @command{genrecog} does not do any optimizations or
+diagnosis when special predicates are used.
+
+@menu
+* Machine-Independent Predicates:: Predicates available to all back ends.
+* Defining Predicates:: How to write machine-specific predicate
+ functions.
+@end menu
+
+@node Machine-Independent Predicates
+@subsection Machine-Independent Predicates
+@cindex machine-independent predicates
+@cindex generic predicates
+
+These are the generic predicates available to all back ends. They are
+defined in @file{recog.c}. The first category of predicates allow
+only constant, or @dfn{immediate}, operands.
+
+@defun immediate_operand
+This predicate allows any sort of constant that fits in @var{mode}.
+It is an appropriate choice for instructions that take operands that
+must be constant.
+@end defun
+
+@defun const_int_operand
+This predicate allows any @code{CONST_INT} expression that fits in
+@var{mode}. It is an appropriate choice for an immediate operand that
+does not allow a symbol or label.
+@end defun
+
+@defun const_double_operand
+This predicate accepts any @code{CONST_DOUBLE} expression that has
+exactly @var{mode}. If @var{mode} is @code{VOIDmode}, it will also
+accept @code{CONST_INT}. It is intended for immediate floating point
+constants.
+@end defun
+
+@noindent
+The second category of predicates allow only some kind of machine
+register.
+
+@defun register_operand
+This predicate allows any @code{REG} or @code{SUBREG} expression that
+is valid for @var{mode}. It is often suitable for arithmetic
+instruction operands on a RISC machine.
+@end defun
+
+@defun pmode_register_operand
+This is a slight variant on @code{register_operand} which works around
+a limitation in the machine-description reader.
+
+@smallexample
+(match_operand @var{n} "pmode_register_operand" @var{constraint})
+@end smallexample
+
+@noindent
+means exactly what
+
+@smallexample
+(match_operand:P @var{n} "register_operand" @var{constraint})
+@end smallexample
+
+@noindent
+would mean, if the machine-description reader accepted @samp{:P}
+mode suffixes. Unfortunately, it cannot, because @code{Pmode} is an
+alias for some other mode, and might vary with machine-specific
+options. @xref{Misc}.
+@end defun
+
+@defun scratch_operand
+This predicate allows hard registers and @code{SCRATCH} expressions,
+but not pseudo-registers. It is used internally by @code{match_scratch};
+it should not be used directly.
+@end defun
+
+@noindent
+The third category of predicates allow only some kind of memory reference.
+
+@defun memory_operand
+This predicate allows any valid reference to a quantity of mode
+@var{mode} in memory, as determined by the weak form of
+@code{GO_IF_LEGITIMATE_ADDRESS} (@pxref{Addressing Modes}).
+@end defun
+
+@defun address_operand
+This predicate is a little unusual; it allows any operand that is a
+valid expression for the @emph{address} of a quantity of mode
+@var{mode}, again determined by the weak form of
+@code{GO_IF_LEGITIMATE_ADDRESS}. To first order, if
+@samp{@w{(mem:@var{mode} (@var{exp}))}} is acceptable to
+@code{memory_operand}, then @var{exp} is acceptable to
+@code{address_operand}. Note that @var{exp} does not necessarily have
+the mode @var{mode}.
+@end defun
+
+@defun indirect_operand
+This is a stricter form of @code{memory_operand} which allows only
+memory references with a @code{general_operand} as the address
+expression. New uses of this predicate are discouraged, because
+@code{general_operand} is very permissive, so it's hard to tell what
+an @code{indirect_operand} does or does not allow. If a target has
+different requirements for memory operands for different instructions,
+it is better to define target-specific predicates which enforce the
+hardware's requirements explicitly.
+@end defun
+
+@defun push_operand
+This predicate allows a memory reference suitable for pushing a value
+onto the stack. This will be a @code{MEM} which refers to
+@code{stack_pointer_rtx}, with a side-effect in its address expression
+(@pxref{Incdec}); which one is determined by the
+@code{STACK_PUSH_CODE} macro (@pxref{Frame Layout}).
+@end defun
+
+@defun pop_operand
+This predicate allows a memory reference suitable for popping a value
+off the stack. Again, this will be a @code{MEM} referring to
+@code{stack_pointer_rtx}, with a side-effect in its address
+expression. However, this time @code{STACK_POP_CODE} is expected.
+@end defun
+
+@noindent
+The fourth category of predicates allow some combination of the above
+operands.
+
+@defun nonmemory_operand
+This predicate allows any immediate or register operand valid for @var{mode}.
+@end defun
+
+@defun nonimmediate_operand
+This predicate allows any register or memory operand valid for @var{mode}.
+@end defun
+
+@defun general_operand
+This predicate allows any immediate, register, or memory operand
+valid for @var{mode}.
+@end defun
+
+@noindent
+Finally, there is one generic operator predicate.
+
+@defun comparison_operator
+This predicate matches any expression which performs an arithmetic
+comparison in @var{mode}; that is, @code{COMPARISON_P} is true for the
+expression code.
+@end defun
+
+@node Defining Predicates
+@subsection Defining Machine-Specific Predicates
+@cindex defining predicates
+@findex define_predicate
+@findex define_special_predicate
+
+Many machines have requirements for their operands that cannot be
+expressed precisely using the generic predicates. You can define
+additional predicates using @code{define_predicate} and
+@code{define_special_predicate} expressions. These expressions have
+three operands:
+
+@itemize @bullet
+@item
+The name of the predicate, as it will be referred to in
+@code{match_operand} or @code{match_operator} expressions.
+
+@item
+An RTL expression which evaluates to true if the predicate allows the
+operand @var{op}, false if it does not. This expression can only use
+the following RTL codes:
+
+@table @code
+@item MATCH_OPERAND
+When written inside a predicate expression, a @code{MATCH_OPERAND}
+expression evaluates to true if the predicate it names would allow
+@var{op}. The operand number and constraint are ignored. Due to
+limitations in @command{genrecog}, you can only refer to generic
+predicates and predicates that have already been defined.
+
+@item MATCH_CODE
+This expression evaluates to true if @var{op} or a specified
+subexpression of @var{op} has one of a given list of RTX codes.
+
+The first operand of this expression is a string constant containing a
+comma-separated list of RTX code names (in lower case). These are the
+codes for which the @code{MATCH_CODE} will be true.
+
+The second operand is a string constant which indicates what
+subexpression of @var{op} to examine. If it is absent or the empty
+string, @var{op} itself is examined. Otherwise, the string constant
+must be a sequence of digits and/or lowercase letters. Each character
+indicates a subexpression to extract from the current expression; for
+the first character this is @var{op}, for the second and subsequent
+characters it is the result of the previous character. A digit
+@var{n} extracts @samp{@w{XEXP (@var{e}, @var{n})}}; a letter @var{l}
+extracts @samp{@w{XVECEXP (@var{e}, 0, @var{n})}} where @var{n} is the
+alphabetic ordinal of @var{l} (0 for `a', 1 for 'b', and so on). The
+@code{MATCH_CODE} then examines the RTX code of the subexpression
+extracted by the complete string. It is not possible to extract
+components of an @code{rtvec} that is not at position 0 within its RTX
+object.
+
+@item MATCH_TEST
+This expression has one operand, a string constant containing a C
+expression. The predicate's arguments, @var{op} and @var{mode}, are
+available with those names in the C expression. The @code{MATCH_TEST}
+evaluates to true if the C expression evaluates to a nonzero value.
+@code{MATCH_TEST} expressions must not have side effects.
+
+@item AND
+@itemx IOR
+@itemx NOT
+@itemx IF_THEN_ELSE
+The basic @samp{MATCH_} expressions can be combined using these
+logical operators, which have the semantics of the C operators
+@samp{&&}, @samp{||}, @samp{!}, and @samp{@w{? :}} respectively. As
+in Common Lisp, you may give an @code{AND} or @code{IOR} expression an
+arbitrary number of arguments; this has exactly the same effect as
+writing a chain of two-argument @code{AND} or @code{IOR} expressions.
+@end table
+
+@item
+An optional block of C code, which should execute
+@samp{@w{return true}} if the predicate is found to match and
+@samp{@w{return false}} if it does not. It must not have any side
+effects. The predicate arguments, @var{op} and @var{mode}, are
+available with those names.
+
+If a code block is present in a predicate definition, then the RTL
+expression must evaluate to true @emph{and} the code block must
+execute @samp{@w{return true}} for the predicate to allow the operand.
+The RTL expression is evaluated first; do not re-check anything in the
+code block that was checked in the RTL expression.
+@end itemize
+
+The program @command{genrecog} scans @code{define_predicate} and
+@code{define_special_predicate} expressions to determine which RTX
+codes are possibly allowed. You should always make this explicit in
+the RTL predicate expression, using @code{MATCH_OPERAND} and
+@code{MATCH_CODE}.
+
+Here is an example of a simple predicate definition, from the IA64
+machine description:
+
+@smallexample
+@group
+;; @r{True if @var{op} is a @code{SYMBOL_REF} which refers to the sdata section.}
+(define_predicate "small_addr_symbolic_operand"
+ (and (match_code "symbol_ref")
+ (match_test "SYMBOL_REF_SMALL_ADDR_P (op)")))
+@end group
+@end smallexample
+
+@noindent
+And here is another, showing the use of the C block.
+
+@smallexample
+@group
+;; @r{True if @var{op} is a register operand that is (or could be) a GR reg.}
+(define_predicate "gr_register_operand"
+ (match_operand 0 "register_operand")
+@{
+ unsigned int regno;
+ if (GET_CODE (op) == SUBREG)
+ op = SUBREG_REG (op);
+
+ regno = REGNO (op);
+ return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno));
+@})
+@end group
+@end smallexample
+
+Predicates written with @code{define_predicate} automatically include
+a test that @var{mode} is @code{VOIDmode}, or @var{op} has the same
+mode as @var{mode}, or @var{op} is a @code{CONST_INT} or
+@code{CONST_DOUBLE}. They do @emph{not} check specifically for
+integer @code{CONST_DOUBLE}, nor do they test that the value of either
+kind of constant fits in the requested mode. This is because
+target-specific predicates that take constants usually have to do more
+stringent value checks anyway. If you need the exact same treatment
+of @code{CONST_INT} or @code{CONST_DOUBLE} that the generic predicates
+provide, use a @code{MATCH_OPERAND} subexpression to call
+@code{const_int_operand}, @code{const_double_operand}, or
+@code{immediate_operand}.
+
+Predicates written with @code{define_special_predicate} do not get any
+automatic mode checks, and are treated as having special mode handling
+by @command{genrecog}.
+
+The program @command{genpreds} is responsible for generating code to
+test predicates. It also writes a header file containing function
+declarations for all machine-specific predicates. It is not necessary
+to declare these predicates in @file{@var{cpu}-protos.h}.
@end ifset
@c Most of this node appears by itself (in a different place) even
@cindex operand constraints
@cindex constraints
-Each @code{match_operand} in an instruction pattern can specify a
-constraint for the type of operands allowed.
+Each @code{match_operand} in an instruction pattern can specify
+constraints for the operands allowed. The constraints allow you to
+fine-tune matching within the set of operands allowed by the
+predicate.
+
@end ifset
@ifclear INTERNALS
@node Constraints
* Multi-Alternative:: When an insn has two alternative constraint-patterns.
* Class Preferences:: Constraints guide which hard register to put things in.
* Modifiers:: More precise control over effects of constraints.
+* Disable Insn Alternatives:: Disable insn alternatives using the @code{enabled} attribute.
* Machine Constraints:: Existing constraints for some particular machines.
+* Define Constraints:: How to define machine-specific constraints.
+* C Constraint Interface:: How to test constraints from C code.
@end menu
@end ifset
@item @samp{m}
A memory operand is allowed, with any kind of address that the machine
supports in general.
+Note that the letter used for the general memory constraint can be
+re-defined by a back end using the @code{TARGET_MEM_CONSTRAINT} macro.
@cindex offsettable address
@cindex @samp{o} in constraint
@item @samp{i}
An immediate integer operand (one with constant value) is allowed.
This includes symbolic constants whose values will be known only at
-assembly time.
+assembly time or later.
@cindex @samp{n} in constraint
@item @samp{n}
@cindex @samp{F} in constraint
@item @samp{F}
-An immediate floating operand (expression code @code{const_double}) is
-allowed.
+An immediate floating operand (expression code @code{const_double} or
+@code{const_vector}) is allowed.
@cindex @samp{G} in constraint
@cindex @samp{H} in constraint
digit should come last.
This number is allowed to be more than a single digit. If multiple
-digits are encountered consecutavely, they are interpreted as a single
+digits are encountered consecutively, they are interpreted as a single
decimal integer. There is scant chance for ambiguity, since to-date
it has never been desirable that @samp{10} be interpreted as matching
either operand 1 @emph{or} operand 0. Should this be desired, one
particular classes of registers or other arbitrary operand types.
@samp{d}, @samp{a} and @samp{f} are defined on the 68000/68020 to stand
for data, address and floating point registers.
-
-@ifset INTERNALS
-The machine description macro @code{REG_CLASS_FROM_LETTER} has first
-cut at the otherwise unused letters. If it evaluates to @code{NO_REGS},
-then @code{EXTRA_CONSTRAINT} is evaluated.
-
-A typical use for @code{EXTRA_CONSTRANT} would be to distinguish certain
-types of memory references that affect other insn operands.
-@end ifset
@end table
@ifset INTERNALS
@noindent
the first pattern would not apply at all, because this insn does not
contain two identical subexpressions in the right place. The pattern would
-say, ``That does not look like an add instruction; try other patterns.''
+say, ``That does not look like an add instruction; try other patterns''.
The second pattern would say, ``Yes, that's an add instruction, but there
-is something wrong with it.'' It would direct the reload pass of the
+is something wrong with it''. It would direct the reload pass of the
compiler to generate additional insns to make the constraint true. The
results might look like this:
@dots{})
@end smallexample
@end ifset
+GCC can only handle one commutative pair in an asm; if you use more,
+the compiler may fail. Note that you need not use the modifier if
+the two alternatives are strictly identical; this would only waste
+time in the reload pass. The modifier is not operational after
+register allocation, so the result of @code{define_peephole2}
+and @code{define_split}s performed after reload cannot rely on
+@samp{%} to make the intended insn match.
@cindex @samp{#} in constraint
@item #
@samp{I}, usually the letter indicating the most common
immediate-constant format.
-For each machine architecture, the
-@file{config/@var{machine}/@var{machine}.h} file defines additional
-constraints. These constraints are used by the compiler itself for
-instruction generation, as well as for @code{asm} statements; therefore,
-some of the constraints are not particularly interesting for @code{asm}.
-The constraints are defined through these macros:
-
-@table @code
-@item REG_CLASS_FROM_LETTER
-Register class constraints (usually lower case).
-
-@item CONST_OK_FOR_LETTER_P
-Immediate constant constraints, for non-floating point constants of
-word size or smaller precision (usually upper case).
-
-@item CONST_DOUBLE_OK_FOR_LETTER_P
-Immediate constant constraints, for all floating point constants and for
-constants of greater than word size precision (usually upper case).
-
-@item EXTRA_CONSTRAINT
-Special cases of registers or memory. This macro is not required, and
-is only defined for some machines.
-@end table
-
-Inspecting these macro definitions in the compiler source for your
-machine is the best way to be certain you have the right constraints.
-However, here is a summary of the machine-dependent constraints
-available on some particular machines.
+Each architecture defines additional constraints. These constraints
+are used by the compiler itself for instruction generation, as well as
+for @code{asm} statements; therefore, some of the constraints are not
+particularly useful for @code{asm}. Here is a summary of some of the
+machine-dependent constraints available on some particular machines;
+it includes both constraints that are useful for @code{asm} and
+constraints that aren't. The compiler source file mentioned in the
+table heading for each architecture is the definitive reference for
+the meanings of that architecture's constraints.
@table @emph
-@item ARM family---@file{arm.h}
+@item ARM family---@file{config/arm/arm.h}
@table @code
@item f
Floating-point register
+@item w
+VFP floating-point register
+
@item F
One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0, 4.0, 5.0
or 10.0
@item S
A symbol in the text segment of the current file
-@end table
-
-@item AMD 29000 family---@file{a29k.h}
-@table @code
-@item l
-Local register 0
-
-@item b
-Byte Pointer (@samp{BP}) register
-
-@item q
-@samp{Q} register
-
-@item h
-Special purpose register
-
-@item A
-First accumulator register
-
-@item a
-Other accumulator register
-
-@item f
-Floating point register
-
-@item I
-Constant greater than 0, less than 0x100
-
-@item J
-Constant greater than 0, less than 0x10000
-
-@item K
-Constant whose high 24 bits are on (1)
-
-@item L
-16-bit constant whose high 8 bits are on (1)
-
-@item M
-32-bit constant whose high 16 bits are on (1)
-
-@item N
-32-bit negative constant that fits in 8 bits
-@item O
-The constant 0x80000000 or, on the 29050, any 32-bit constant
-whose low 16 bits are 0.
+@item Uv
+A memory reference suitable for VFP load/store insns (reg+constant offset)
-@item P
-16-bit negative constant that fits in 8 bits
+@item Uy
+A memory reference suitable for iWMMXt load/store instructions.
-@item G
-@itemx H
-A floating point constant (in @code{asm} statements, use the machine
-independent @samp{E} or @samp{F} instead)
+@item Uq
+A memory reference suitable for the ARMv4 ldrsb instruction.
@end table
-@item AVR family---@file{avr.h}
+@item AVR family---@file{config/avr/constraints.md}
@table @code
@item l
Registers from r0 to r15
@item G
A floating point constant 0.0
+
+@item R
+Integer constant in the range -6 @dots{} 5.
+
+@item Q
+A memory address based on Y or Z pointer with displacement.
+@end table
+
+@item CRX Architecture---@file{config/crx/crx.h}
+@table @code
+
+@item b
+Registers from r0 to r14 (registers without stack pointer)
+
+@item l
+Register r16 (64-bit accumulator lo register)
+
+@item h
+Register r17 (64-bit accumulator hi register)
+
+@item k
+Register pair r16-r17. (64-bit accumulator lo-hi pair)
+
+@item I
+Constant that fits in 3 bits
+
+@item J
+Constant that fits in 4 bits
+
+@item K
+Constant that fits in 5 bits
+
+@item L
+Constant that is one of -1, 4, -4, 7, 8, 12, 16, 20, 32, 48
+
+@item G
+Floating point constant that is legal for store immediate
+@end table
+
+@item Hewlett-Packard PA-RISC---@file{config/pa/pa.h}
+@table @code
+@item a
+General register 1
+
+@item f
+Floating point register
+
+@item q
+Shift amount register
+
+@item x
+Floating point register (deprecated)
+
+@item y
+Upper floating point register (32-bit), floating point register (64-bit)
+
+@item Z
+Any register
+
+@item I
+Signed 11-bit integer constant
+
+@item J
+Signed 14-bit integer constant
+
+@item K
+Integer constant that can be deposited with a @code{zdepi} instruction
+
+@item L
+Signed 5-bit integer constant
+
+@item M
+Integer constant 0
+
+@item N
+Integer constant that can be loaded with a @code{ldil} instruction
+
+@item O
+Integer constant whose value plus one is a power of 2
+
+@item P
+Integer constant that can be used for @code{and} operations in @code{depi}
+and @code{extru} instructions
+
+@item S
+Integer constant 31
+
+@item U
+Integer constant 63
+
+@item G
+Floating-point constant 0.0
+
+@item A
+A @code{lo_sum} data-linkage-table memory operand
+
+@item Q
+A memory operand that can be used as the destination operand of an
+integer store instruction
+
+@item R
+A scaled or unscaled indexed memory operand
+
+@item T
+A memory operand for floating-point loads and stores
+
+@item W
+A register indirect memory operand
+@end table
+
+@item picoChip family---@file{picochip.h}
+@table @code
+@item k
+Stack register.
+
+@item f
+Pointer register. A register which can be used to access memory without
+supplying an offset. Any other register can be used to access memory,
+but will need a constant offset. In the case of the offset being zero,
+it is more efficient to use a pointer register, since this reduces code
+size.
+
+@item t
+A twin register. A register which may be paired with an adjacent
+register to create a 32-bit register.
+
+@item a
+Any absolute memory address (e.g., symbolic constant, symbolic
+constant + offset).
+
+@item I
+4-bit signed integer.
+
+@item J
+4-bit unsigned integer.
+
+@item K
+8-bit signed integer.
+
+@item M
+Any constant whose absolute value is no greater than 4-bits.
+
+@item N
+10-bit signed integer
+
+@item O
+16-bit signed integer.
+
@end table
-@item IBM RS6000---@file{rs6000.h}
+@item PowerPC and IBM RS6000---@file{config/rs6000/rs6000.h}
@table @code
@item b
Address base register
@item f
Floating point register
+@item v
+Vector register
+
@item h
@samp{MQ}, @samp{CTR}, or @samp{LINK} register
Floating point constant that can be loaded into a register with one
instruction per word
+@item H
+Integer/Floating point constant that can be loaded into a register using
+three instructions
+
@item Q
Memory operand that is an offset from a register (@samp{m} is preferable
for @code{asm} statements)
+@item Z
+Memory operand that is an indexed or indirect from a register (@samp{m} is
+preferable for @code{asm} statements)
+
@item R
AIX TOC entry
+@item a
+Address operand that is an indexed or indirect from a register (@samp{p} is
+preferable for @code{asm} statements)
+
@item S
Constant suitable as a 64-bit mask operand
@item U
System V Release 4 small data area reference
-@end table
-@item Intel 386---@file{i386.h}
-@table @code
-@item q
-@samp{a}, @code{b}, @code{c}, or @code{d} register for the i386.
-For x86-64 it is equivalent to @samp{r} class. (for 8-bit instructions that
-do not use upper halves)
+@item t
+AND masks that can be performed by two rldic@{l, r@} instructions
-@item Q
-@samp{a}, @code{b}, @code{c}, or @code{d} register. (for 8-bit instructions,
-that do use upper halves)
+@item W
+Vector constant that does not require memory
-@item R
-Legacy register---equivalent to @code{r} class in i386 mode.
-(for non-8-bit registers used together with 8-bit upper halves in a single
-instruction)
+@end table
-@item A
-Specifies the @samp{a} or @samp{d} registers. This is primarily useful
-for 64-bit integer values (when in 32-bit mode) intended to be returned
-with the @samp{d} register holding the most significant bits and the
-@samp{a} register holding the least significant bits.
+@item Intel 386---@file{config/i386/constraints.md}
+@table @code
+@item R
+Legacy register---the eight integer registers available on all
+i386 processors (@code{a}, @code{b}, @code{c}, @code{d},
+@code{si}, @code{di}, @code{bp}, @code{sp}).
-@item f
-Floating point register
+@item q
+Any register accessible as @code{@var{r}l}. In 32-bit mode, @code{a},
+@code{b}, @code{c}, and @code{d}; in 64-bit mode, any integer register.
-@item t
-First (top of stack) floating point register
+@item Q
+Any register accessible as @code{@var{r}h}: @code{a}, @code{b},
+@code{c}, and @code{d}.
-@item u
-Second floating point register
+@ifset INTERNALS
+@item l
+Any register that can be used as the index in a base+index memory
+access: that is, any general register except the stack pointer.
+@end ifset
@item a
-@samp{a} register
+The @code{a} register.
@item b
-@samp{b} register
+The @code{b} register.
@item c
-@samp{c} register
+The @code{c} register.
@item d
-@samp{d} register
-
-@item D
-@samp{di} register
+The @code{d} register.
@item S
-@samp{si} register
+The @code{si} register.
-@item x
-@samp{xmm} SSE register
+@item D
+The @code{di} register.
-@item y
-MMX register
+@item A
+The @code{a} and @code{d} registers, as a pair (for instructions that
+return half the result in one and half in the other).
-@item I
-Constant in range 0 to 31 (for 32-bit shifts)
+@item f
+Any 80387 floating-point (stack) register.
+
+@item t
+Top of 80387 floating-point stack (@code{%st(0)}).
+
+@item u
+Second from top of 80387 floating-point stack (@code{%st(1)}).
+
+@item y
+Any MMX register.
+
+@item x
+Any SSE register.
+
+@item Yz
+First SSE register (@code{%xmm0}).
+
+@ifset INTERNALS
+@item Y2
+Any SSE register, when SSE2 is enabled.
+
+@item Yi
+Any SSE register, when SSE2 and inter-unit moves are enabled.
+
+@item Ym
+Any MMX register, when inter-unit moves are enabled.
+@end ifset
+
+@item I
+Integer constant in the range 0 @dots{} 31, for 32-bit shifts.
@item J
-Constant in range 0 to 63 (for 64-bit shifts)
+Integer constant in the range 0 @dots{} 63, for 64-bit shifts.
@item K
-@samp{0xff}
+Signed 8-bit integer constant.
@item L
-@samp{0xffff}
+@code{0xFF} or @code{0xFFFF}, for andsi as a zero-extending move.
@item M
-0, 1, 2, or 3 (shifts for @code{lea} instruction)
+0, 1, 2, or 3 (shifts for the @code{lea} instruction).
@item N
-Constant in range 0 to 255 (for @code{out} instruction)
+Unsigned 8-bit integer constant (for @code{in} and @code{out}
+instructions).
+
+@ifset INTERNALS
+@item O
+Integer constant in the range 0 @dots{} 127, for 128-bit shifts.
+@end ifset
+
+@item G
+Standard 80387 floating point constant.
+
+@item C
+Standard SSE floating point constant.
+
+@item e
+32-bit signed integer constant, or a symbolic reference known
+to fit that range (for immediate operands in sign-extending x86-64
+instructions).
@item Z
-Constant in range 0 to @code{0xffffffff} or symbolic reference known to fit specified range.
-(for using immediates in zero extending 32-bit to 64-bit x86-64 instructions)
+32-bit unsigned integer constant, or a symbolic reference known
+to fit that range (for immediate operands in zero-extending x86-64
+instructions).
+
+@end table
+
+@item Intel IA-64---@file{config/ia64/ia64.h}
+@table @code
+@item a
+General register @code{r0} to @code{r3} for @code{addl} instruction
+
+@item b
+Branch register
+
+@item c
+Predicate register (@samp{c} as in ``conditional'')
+
+@item d
+Application register residing in M-unit
@item e
-Constant in range @minus{}2147483648 to 2147483647 or symbolic reference known to fit specified range.
-(for using immediates in 64-bit x86-64 instructions)
+Application register residing in I-unit
+
+@item f
+Floating-point register
+
+@item m
+Memory operand.
+Remember that @samp{m} allows postincrement and postdecrement which
+require printing with @samp{%Pn} on IA-64.
+Use @samp{S} to disallow postincrement and postdecrement.
@item G
-Standard 80387 floating point constant
+Floating-point constant 0.0 or 1.0
+
+@item I
+14-bit signed integer constant
+
+@item J
+22-bit signed integer constant
+
+@item K
+8-bit signed integer constant for logical instructions
+
+@item L
+8-bit adjusted signed integer constant for compare pseudo-ops
+
+@item M
+6-bit unsigned integer constant for shift counts
+
+@item N
+9-bit signed integer constant for load and store postincrements
+
+@item O
+The constant zero
+
+@item P
+0 or @minus{}1 for @code{dep} instruction
+
+@item Q
+Non-volatile memory for floating-point loads and stores
+
+@item R
+Integer constant in the range 1 to 4 for @code{shladd} instruction
+
+@item S
+Memory operand except postincrement and postdecrement
@end table
-@item Intel 960---@file{i960.h}
+@item FRV---@file{config/frv/frv.h}
@table @code
+@item a
+Register in the class @code{ACC_REGS} (@code{acc0} to @code{acc7}).
+
+@item b
+Register in the class @code{EVEN_ACC_REGS} (@code{acc0} to @code{acc7}).
+
+@item c
+Register in the class @code{CC_REGS} (@code{fcc0} to @code{fcc3} and
+@code{icc0} to @code{icc3}).
+
+@item d
+Register in the class @code{GPR_REGS} (@code{gr0} to @code{gr63}).
+
+@item e
+Register in the class @code{EVEN_REGS} (@code{gr0} to @code{gr63}).
+Odd registers are excluded not in the class but through the use of a machine
+mode larger than 4 bytes.
+
@item f
-Floating point register (@code{fp0} to @code{fp3})
+Register in the class @code{FPR_REGS} (@code{fr0} to @code{fr63}).
+
+@item h
+Register in the class @code{FEVEN_REGS} (@code{fr0} to @code{fr63}).
+Odd registers are excluded not in the class but through the use of a machine
+mode larger than 4 bytes.
@item l
-Local register (@code{r0} to @code{r15})
+Register in the class @code{LR_REG} (the @code{lr} register).
-@item b
-Global register (@code{g0} to @code{g15})
+@item q
+Register in the class @code{QUAD_REGS} (@code{gr2} to @code{gr63}).
+Register numbers not divisible by 4 are excluded not in the class but through
+the use of a machine mode larger than 8 bytes.
-@item d
-Any local or global register
+@item t
+Register in the class @code{ICC_REGS} (@code{icc0} to @code{icc3}).
+
+@item u
+Register in the class @code{FCC_REGS} (@code{fcc0} to @code{fcc3}).
+
+@item v
+Register in the class @code{ICR_REGS} (@code{cc4} to @code{cc7}).
+
+@item w
+Register in the class @code{FCR_REGS} (@code{cc0} to @code{cc3}).
+
+@item x
+Register in the class @code{QUAD_FPR_REGS} (@code{fr0} to @code{fr63}).
+Register numbers not divisible by 4 are excluded not in the class but through
+the use of a machine mode larger than 8 bytes.
+
+@item z
+Register in the class @code{SPR_REGS} (@code{lcr} and @code{lr}).
+
+@item A
+Register in the class @code{QUAD_ACC_REGS} (@code{acc0} to @code{acc7}).
+
+@item B
+Register in the class @code{ACCG_REGS} (@code{accg0} to @code{accg7}).
+
+@item C
+Register in the class @code{CR_REGS} (@code{cc0} to @code{cc7}).
+
+@item G
+Floating point constant zero
@item I
-Integers from 0 to 31
+6-bit signed integer constant
@item J
-0
+10-bit signed integer constant
-@item K
-Integers from @minus{}31 to 0
+@item L
+16-bit signed integer constant
-@item G
-Floating point 0
+@item M
+16-bit unsigned integer constant
+
+@item N
+12-bit signed integer constant that is negative---i.e.@: in the
+range of @minus{}2048 to @minus{}1
+
+@item O
+Constant zero
+
+@item P
+12-bit signed integer constant that is greater than zero---i.e.@: in the
+range of 1 to 2047.
+
+@end table
+
+@item Blackfin family---@file{config/bfin/constraints.md}
+@table @code
+@item a
+P register
+
+@item d
+D register
+
+@item z
+A call clobbered P register.
+
+@item q@var{n}
+A single register. If @var{n} is in the range 0 to 7, the corresponding D
+register. If it is @code{A}, then the register P0.
+
+@item D
+Even-numbered D register
+
+@item W
+Odd-numbered D register
+
+@item e
+Accumulator register.
+
+@item A
+Even-numbered accumulator register.
+
+@item B
+Odd-numbered accumulator register.
+
+@item b
+I register
+
+@item v
+B register
+
+@item f
+M register
+
+@item c
+Registers used for circular buffering, i.e. I, B, or L registers.
+
+@item C
+The CC register.
+
+@item t
+LT0 or LT1.
+
+@item k
+LC0 or LC1.
+
+@item u
+LB0 or LB1.
+
+@item x
+Any D, P, B, M, I or L register.
+
+@item y
+Additional registers typically used only in prologues and epilogues: RETS,
+RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and USP.
+
+@item w
+Any register except accumulators or CC.
+
+@item Ksh
+Signed 16 bit integer (in the range -32768 to 32767)
+
+@item Kuh
+Unsigned 16 bit integer (in the range 0 to 65535)
+
+@item Ks7
+Signed 7 bit integer (in the range -64 to 63)
+
+@item Ku7
+Unsigned 7 bit integer (in the range 0 to 127)
+
+@item Ku5
+Unsigned 5 bit integer (in the range 0 to 31)
+
+@item Ks4
+Signed 4 bit integer (in the range -8 to 7)
+
+@item Ks3
+Signed 3 bit integer (in the range -3 to 4)
+
+@item Ku3
+Unsigned 3 bit integer (in the range 0 to 7)
+
+@item P@var{n}
+Constant @var{n}, where @var{n} is a single-digit constant in the range 0 to 4.
+
+@item PA
+An integer equal to one of the MACFLAG_XXX constants that is suitable for
+use with either accumulator.
+
+@item PB
+An integer equal to one of the MACFLAG_XXX constants that is suitable for
+use only with accumulator A1.
+
+@item M1
+Constant 255.
+
+@item M2
+Constant 65535.
+
+@item J
+An integer constant with exactly a single bit set.
+
+@item L
+An integer constant with all bits set except exactly one.
@item H
-Floating point 1
+
+@item Q
+Any SYMBOL_REF.
@end table
-@item MIPS---@file{mips.h}
+@item M32C---@file{config/m32c/m32c.c}
+@table @code
+@item Rsp
+@itemx Rfb
+@itemx Rsb
+@samp{$sp}, @samp{$fb}, @samp{$sb}.
+
+@item Rcr
+Any control register, when they're 16 bits wide (nothing if control
+registers are 24 bits wide)
+
+@item Rcl
+Any control register, when they're 24 bits wide.
+
+@item R0w
+@itemx R1w
+@itemx R2w
+@itemx R3w
+$r0, $r1, $r2, $r3.
+
+@item R02
+$r0 or $r2, or $r2r0 for 32 bit values.
+
+@item R13
+$r1 or $r3, or $r3r1 for 32 bit values.
+
+@item Rdi
+A register that can hold a 64 bit value.
+
+@item Rhl
+$r0 or $r1 (registers with addressable high/low bytes)
+
+@item R23
+$r2 or $r3
+
+@item Raa
+Address registers
+
+@item Raw
+Address registers when they're 16 bits wide.
+
+@item Ral
+Address registers when they're 24 bits wide.
+
+@item Rqi
+Registers that can hold QI values.
+
+@item Rad
+Registers that can be used with displacements ($a0, $a1, $sb).
+
+@item Rsi
+Registers that can hold 32 bit values.
+
+@item Rhi
+Registers that can hold 16 bit values.
+
+@item Rhc
+Registers chat can hold 16 bit values, including all control
+registers.
+
+@item Rra
+$r0 through R1, plus $a0 and $a1.
+
+@item Rfl
+The flags register.
+
+@item Rmm
+The memory-based pseudo-registers $mem0 through $mem15.
+
+@item Rpi
+Registers that can hold pointers (16 bit registers for r8c, m16c; 24
+bit registers for m32cm, m32c).
+
+@item Rpa
+Matches multiple registers in a PARALLEL to form a larger register.
+Used to match function return values.
+
+@item Is3
+-8 @dots{} 7
+
+@item IS1
+-128 @dots{} 127
+
+@item IS2
+-32768 @dots{} 32767
+
+@item IU2
+0 @dots{} 65535
+
+@item In4
+-8 @dots{} -1 or 1 @dots{} 8
+
+@item In5
+-16 @dots{} -1 or 1 @dots{} 16
+
+@item In6
+-32 @dots{} -1 or 1 @dots{} 32
+
+@item IM2
+-65536 @dots{} -1
+
+@item Ilb
+An 8 bit value with exactly one bit set.
+
+@item Ilw
+A 16 bit value with exactly one bit set.
+
+@item Sd
+The common src/dest memory addressing modes.
+
+@item Sa
+Memory addressed using $a0 or $a1.
+
+@item Si
+Memory addressed with immediate addresses.
+
+@item Ss
+Memory addressed using the stack pointer ($sp).
+
+@item Sf
+Memory addressed using the frame base register ($fb).
+
+@item Ss
+Memory addressed using the small base register ($sb).
+
+@item S1
+$r1h
+@end table
+
+@item MIPS---@file{config/mips/constraints.md}
@table @code
@item d
-General-purpose integer register
+An address register. This is equivalent to @code{r} unless
+generating MIPS16 code.
@item f
-Floating-point register (if available)
+A floating-point register (if available).
@item h
-@samp{Hi} register
+Formerly the @code{hi} register. This constraint is no longer supported.
@item l
-@samp{Lo} register
+The @code{lo} register. Use this register to store values that are
+no bigger than a word.
@item x
-@samp{Hi} or @samp{Lo} register
+The concatenated @code{hi} and @code{lo} registers. Use this register
+to store doubleword values.
+
+@item c
+A register suitable for use in an indirect jump. This will always be
+@code{$25} for @option{-mabicalls}.
+
+@item v
+Register @code{$3}. Do not use this constraint in new code;
+it is retained only for compatibility with glibc.
@item y
-General-purpose integer register
+Equivalent to @code{r}; retained for backwards compatibility.
@item z
-Floating-point status register
+A floating-point condition code register.
@item I
-Signed 16-bit constant (for arithmetic instructions)
+A signed 16-bit constant (for arithmetic instructions).
@item J
-Zero
+Integer zero.
@item K
-Zero-extended 16-bit constant (for logic instructions)
+An unsigned 16-bit constant (for logic instructions).
@item L
-Constant with low 16 bits zero (can be loaded with @code{lui})
+A signed 32-bit constant in which the lower 16 bits are zero.
+Such constants can be loaded using @code{lui}.
@item M
-32-bit constant which requires two instructions to load (a constant
-which is not @samp{I}, @samp{K}, or @samp{L})
+A constant that cannot be loaded using @code{lui}, @code{addiu}
+or @code{ori}.
@item N
-Negative 16-bit constant
+A constant in the range -65535 to -1 (inclusive).
@item O
-Exact power of two
+A signed 15-bit constant.
@item P
-Positive 16-bit constant
+A constant in the range 1 to 65535 (inclusive).
@item G
-Floating point zero
-
-@item Q
-Memory reference that can be loaded with more than one instruction
-(@samp{m} is preferable for @code{asm} statements)
+Floating-point zero.
@item R
-Memory reference that can be loaded with one instruction
-(@samp{m} is preferable for @code{asm} statements)
-
-@item S
-Memory reference in external OSF/rose PIC format
-(@samp{m} is preferable for @code{asm} statements)
+An address that can be used in a non-macro load or store.
@end table
-@item Motorola 680x0---@file{m68k.h}
+@item Motorola 680x0---@file{config/m68k/constraints.md}
@table @code
@item a
Address register
@item f
68881 floating-point register, if available
-@item x
-Sun FPA (floating-point) register, if available
-
-@item y
-First 16 Sun FPA registers, if available
-
@item I
Integer in the range 1 to 8
@item M
Signed number whose magnitude is greater than 0x100
+@item N
+Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate
+
+@item O
+16 (for rotate using swap)
+
+@item P
+Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate
+
+@item R
+Numbers that mov3q can handle
+
@item G
Floating point constant that is not a 68881 constant
-@item H
-Floating point constant that can be used by Sun FPA
+@item S
+Operands that satisfy 'm' when -mpcrel is in effect
+
+@item T
+Operands that satisfy 's' when -mpcrel is not in effect
+
+@item Q
+Address register indirect addressing mode
+
+@item U
+Register offset addressing
+
+@item W
+const_call_operand
+
+@item Cs
+symbol_ref or const
+
+@item Ci
+const_int
+
+@item C0
+const_int 0
+
+@item Cj
+Range of signed numbers that don't fit in 16 bits
+
+@item Cmvq
+Integers valid for mvq
+
+@item Capsw
+Integers valid for a moveq followed by a swap
+
+@item Cmvz
+Integers valid for mvz
+
+@item Cmvs
+Integers valid for mvs
+
+@item Ap
+push_operand
+
+@item Ac
+Non-register operands allowed in clr
+
@end table
-@item Motorola 68HC11 & 68HC12 families---@file{m68hc11.h}
+@item Motorola 68HC11 & 68HC12 families---@file{config/m68hc11/m68hc11.h}
@table @code
@item a
-Register 'a'
+Register `a'
@item b
-Register 'b'
+Register `b'
@item d
-Register 'd'
+Register `d'
@item q
An 8-bit register
Stack pointer register
@item x
-Register 'x'
+Register `x'
@item y
-Register 'y'
+Register `y'
@item z
-Pseudo register 'z' (replaced by 'x' or 'y' at the end)
+Pseudo register `z' (replaced by `x' or `y' at the end)
@item A
An address register: x, y or z
@end table
@need 1000
-@item SPARC---@file{sparc.h}
+@item SPARC---@file{config/sparc/sparc.h}
@table @code
@item f
-Floating-point register that can hold 32- or 64-bit values.
+Floating-point register on the SPARC-V8 architecture and
+lower floating-point register on the SPARC-V9 architecture.
@item e
-Floating-point register that can hold 64- or 128-bit values.
+Floating-point register. It is equivalent to @samp{f} on the
+SPARC-V8 architecture and contains both lower and upper
+floating-point registers on the SPARC-V9 architecture.
+
+@item c
+Floating-point condition code register.
+
+@item d
+Lower floating-point register. It is only valid on the SPARC-V9
+architecture when the Visual Instruction Set is available.
+
+@item b
+Floating-point register. It is only valid on the SPARC-V9 architecture
+when the Visual Instruction Set is available.
+
+@item h
+64-bit global or out register for the SPARC-V8+ architecture.
+
+@item D
+A vector constant
@item I
Signed 13-bit constant
lower 32-bit range are all zero. Must be used instead of @samp{K} for
modes wider than @code{SImode}
+@item O
+The constant 4096
+
@item G
Floating-point zero
instruction
@item S
-Floating-point constant whose integral representation can
-be moved into an integer register using a high/lo_sum
-instruction sequence
+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
+
+@item W
+Memory address for @samp{e} constraint registers
+
+@item Y
+Vector zero
+
+@end table
+
+@item SPU---@file{config/spu/spu.h}
+@table @code
+@item a
+An immediate which can be loaded with the il/ila/ilh/ilhu instructions. const_int is treated as a 64 bit value.
+
+@item c
+An immediate for and/xor/or instructions. const_int is treated as a 64 bit value.
+
+@item d
+An immediate for the @code{iohl} instruction. const_int is treated as a 64 bit value.
+
+@item f
+An immediate which can be loaded with @code{fsmbi}.
+
+@item A
+An immediate which can be loaded with the il/ila/ilh/ilhu instructions. const_int is treated as a 32 bit value.
+
+@item B
+An immediate for most arithmetic instructions. const_int is treated as a 32 bit value.
+
+@item C
+An immediate for and/xor/or instructions. const_int is treated as a 32 bit value.
+
+@item D
+An immediate for the @code{iohl} instruction. const_int is treated as a 32 bit value.
+
+@item I
+A constant in the range [-64, 63] for shift/rotate instructions.
+
+@item J
+An unsigned 7-bit constant for conversion/nop/channel instructions.
+
+@item K
+A signed 10-bit constant for most arithmetic instructions.
+
+@item M
+A signed 16 bit immediate for @code{stop}.
+
+@item N
+An unsigned 16-bit constant for @code{iohl} and @code{fsmbi}.
+
+@item O
+An unsigned 7-bit constant whose 3 least significant bits are 0.
+
+@item P
+An unsigned 3-bit constant for 16-byte rotates and shifts
+
+@item R
+Call operand, reg, for indirect calls
+
+@item S
+Call operand, symbol, for relative calls.
@item T
-Memory address aligned to an 8-byte boundary
+Call operand, const_int, for absolute calls.
@item U
-Even register
+An immediate which can be loaded with the il/ila/ilh/ilhu instructions. const_int is sign extended to 128 bit.
@item W
-Memory address for @samp{e} constraint registers.
+An immediate for shift and rotate instructions. const_int is treated as a 32 bit value.
+
+@item Y
+An immediate for and/xor/or instructions. const_int is sign extended as a 128 bit.
+
+@item Z
+An immediate for the @code{iohl} instruction. const_int is sign extended to 128 bit.
@end table
-@item TMS320C3x/C4x---@file{c4x.h}
+@item S/390 and zSeries---@file{config/s390/s390.h}
@table @code
@item a
-Auxiliary (address) register (ar0-ar7)
-
-@item b
-Stack pointer register (sp)
+Address register (general purpose register except r0)
@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)
+Condition code register
-@item G
-Floating-point zero
+@item d
+Data register (arbitrary general purpose register)
-@item H
-Immediate 16-bit floating-point constant
+@item f
+Floating-point register
@item I
-Signed 16-bit constant
+Unsigned 8-bit constant (0--255)
@item J
-Signed 8-bit constant
+Unsigned 12-bit constant (0--4095)
@item K
-Signed 5-bit constant
+Signed 16-bit constant (@minus{}32768--32767)
@item L
-Unsigned 16-bit constant
+Value appropriate as displacement.
+@table @code
+@item (0..4095)
+for short displacement
+@item (-524288..524287)
+for long displacement
+@end table
@item M
-Unsigned 8-bit constant
+Constant integer with a value of 0x7fffffff.
@item N
-Ones complement of unsigned 16-bit constant
-
-@item O
-High 16-bit constant (32-bit constant with 16 LSBs zero)
+Multiple letter constraint followed by 4 parameter letters.
+@table @code
+@item 0..9:
+number of the part counting from most to least significant
+@item H,Q:
+mode of the part
+@item D,S,H:
+mode of the containing operand
+@item 0,F:
+value of the other parts (F---all bits set)
+@end table
+The constraint matches if the specified part of a constant
+has a value different from its other parts.
@item Q
-Indirect memory reference with signed 8-bit or index register displacement
+Memory reference without index register and with short displacement.
@item R
-Indirect memory reference with unsigned 5-bit displacement
+Memory reference with index register and short displacement.
@item S
-Indirect memory reference with 1 bit or index register displacement
+Memory reference without index register but with long displacement.
@item T
-Direct memory reference
+Memory reference with index register and long displacement.
@item U
-Symbolic address
+Pointer with short displacement.
+
+@item W
+Pointer with long displacement.
+
+@item Y
+Shift count operand.
@end table
-@item S/390 and zSeries---@file{s390.h}
+@item Score family---@file{config/score/score.h}
@table @code
+@item d
+Registers from r0 to r32.
+
+@item e
+Registers from r0 to r16.
+
+@item t
+r8---r11 or r22---r27 registers.
+
+@item h
+hi register.
+
+@item l
+lo register.
+
+@item x
+hi + lo register.
+
+@item q
+cnt register.
+
+@item y
+lcb register.
+
+@item z
+scb register.
+
@item a
-Address register (general purpose register except r0)
+cnt + lcb + scb register.
-@item d
-Data register (arbitrary general purpose register)
+@item c
+cr0---cr15 register.
+
+@item b
+cp1 registers.
@item f
-Floating-point register
+cp2 registers.
+
+@item i
+cp3 registers.
+
+@item j
+cp1 + cp2 + cp3 registers.
@item I
-Unsigned 8-bit constant (0--255)
+High 16-bit constant (32-bit constant with 16 LSBs zero).
@item J
-Unsigned 12-bit constant (0--4095)
+Unsigned 5 bit integer (in the range 0 to 31).
@item K
-Signed 16-bit constant (@minus{}32768--32767)
+Unsigned 16 bit integer (in the range 0 to 65535).
@item L
-Unsigned 16-bit constant (0--65535)
+Signed 16 bit integer (in the range @minus{}32768 to 32767).
-@item Q
-Memory reference without index register
+@item M
+Unsigned 14 bit integer (in the range 0 to 16383).
-@item S
-Symbolic constant suitable for use with the @code{larl} instruction
+@item N
+Signed 14 bit integer (in the range @minus{}8192 to 8191).
+@item Z
+Any SYMBOL_REF.
@end table
-@item Xstormy16---@file{stormy16.h}
+@item Xstormy16---@file{config/stormy16/stormy16.h}
@table @code
@item a
Register r0.
A memory reference that is a stack pop.
@item S
-A memory reference that refers to an constant address of known value.
+A memory reference that refers to a constant address of known value.
@item T
The register indicated by Rx (not implemented yet).
@item U
A constant that is not between 2 and 15 inclusive.
+@item Z
+The constant 0.
+
@end table
-@item Xtensa---@file{xtensa.h}
+@item Xtensa---@file{config/xtensa/constraints.md}
@table @code
@item a
General-purpose 32-bit register
@end table
@ifset INTERNALS
+@node Disable Insn Alternatives
+@subsection Disable insn alternatives using the @code{enabled} attribute
+@cindex enabled
+
+The @code{enabled} insn attribute may be used to disable certain insn
+alternatives for machine-specific reasons. This is useful when adding
+new instructions to an existing pattern which are only available for
+certain cpu architecture levels as specified with the @code{-march=}
+option.
+
+If an insn alternative is disabled, then it will never be used. The
+compiler treats the constraints for the disabled alternative as
+unsatisfiable.
+
+In order to make use of the @code{enabled} attribute a back end has to add
+in the machine description files:
+
+@enumerate
+@item
+A definition of the @code{enabled} insn attribute. The attribute is
+defined as usual using the @code{define_attr} command. This
+definition should be based on other insn attributes and/or target flags.
+The @code{enabled} attribute is a numeric attribute and should evaluate to
+@code{(const_int 1)} for an enabled alternative and to
+@code{(const_int 0)} otherwise.
+@item
+A definition of another insn attribute used to describe for what
+reason an insn alternative might be available or
+not. E.g. @code{cpu_facility} as in the example below.
+@item
+An assignment for the second attribute to each insn definition
+combining instructions which are not all available under the same
+circumstances. (Note: It obviously only makes sense for definitions
+with more than one alternative. Otherwise the insn pattern should be
+disabled or enabled using the insn condition.)
+@end enumerate
+
+E.g. the following two patterns could easily be merged using the @code{enabled}
+attribute:
+
+@smallexample
+
+(define_insn "*movdi_old"
+ [(set (match_operand:DI 0 "register_operand" "=d")
+ (match_operand:DI 1 "register_operand" " d"))]
+ "!TARGET_NEW"
+ "lgr %0,%1")
+
+(define_insn "*movdi_new"
+ [(set (match_operand:DI 0 "register_operand" "=d,f,d")
+ (match_operand:DI 1 "register_operand" " d,d,f"))]
+ "TARGET_NEW"
+ "@@
+ lgr %0,%1
+ ldgr %0,%1
+ lgdr %0,%1")
+
+@end smallexample
+
+to:
+
+@smallexample
+
+(define_insn "*movdi_combined"
+ [(set (match_operand:DI 0 "register_operand" "=d,f,d")
+ (match_operand:DI 1 "register_operand" " d,d,f"))]
+ ""
+ "@@
+ lgr %0,%1
+ ldgr %0,%1
+ lgdr %0,%1"
+ [(set_attr "cpu_facility" "*,new,new")])
+
+@end smallexample
+
+with the @code{enabled} attribute defined like this:
+
+@smallexample
+
+(define_attr "cpu_facility" "standard,new" (const_string "standard"))
+
+(define_attr "enabled" ""
+ (cond [(eq_attr "cpu_facility" "standard") (const_int 1)
+ (and (eq_attr "cpu_facility" "new")
+ (ne (symbol_ref "TARGET_NEW") (const_int 0)))
+ (const_int 1)]
+ (const_int 0)))
+
+@end smallexample
+
+@end ifset
+
+@ifset INTERNALS
+@node Define Constraints
+@subsection Defining Machine-Specific Constraints
+@cindex defining constraints
+@cindex constraints, defining
+
+Machine-specific constraints fall into two categories: register and
+non-register constraints. Within the latter category, constraints
+which allow subsets of all possible memory or address operands should
+be specially marked, to give @code{reload} more information.
+
+Machine-specific constraints can be given names of arbitrary length,
+but they must be entirely composed of letters, digits, underscores
+(@samp{_}), and angle brackets (@samp{< >}). Like C identifiers, they
+must begin with a letter or underscore.
+
+In order to avoid ambiguity in operand constraint strings, no
+constraint can have a name that begins with any other constraint's
+name. For example, if @code{x} is defined as a constraint name,
+@code{xy} may not be, and vice versa. As a consequence of this rule,
+no constraint may begin with one of the generic constraint letters:
+@samp{E F V X g i m n o p r s}.
+
+Register constraints correspond directly to register classes.
+@xref{Register Classes}. There is thus not much flexibility in their
+definitions.
+
+@deffn {MD Expression} define_register_constraint name regclass docstring
+All three arguments are string constants.
+@var{name} is the name of the constraint, as it will appear in
+@code{match_operand} expressions. If @var{name} is a multi-letter
+constraint its length shall be the same for all constraints starting
+with the same letter. @var{regclass} can be either the
+name of the corresponding register class (@pxref{Register Classes}),
+or a C expression which evaluates to the appropriate register class.
+If it is an expression, it must have no side effects, and it cannot
+look at the operand. The usual use of expressions is to map some
+register constraints to @code{NO_REGS} when the register class
+is not available on a given subarchitecture.
+
+@var{docstring} is a sentence documenting the meaning of the
+constraint. Docstrings are explained further below.
+@end deffn
+
+Non-register constraints are more like predicates: the constraint
+definition gives a Boolean expression which indicates whether the
+constraint matches.
+
+@deffn {MD Expression} define_constraint name docstring exp
+The @var{name} and @var{docstring} arguments are the same as for
+@code{define_register_constraint}, but note that the docstring comes
+immediately after the name for these expressions. @var{exp} is an RTL
+expression, obeying the same rules as the RTL expressions in predicate
+definitions. @xref{Defining Predicates}, for details. If it
+evaluates true, the constraint matches; if it evaluates false, it
+doesn't. Constraint expressions should indicate which RTL codes they
+might match, just like predicate expressions.
+
+@code{match_test} C expressions have access to the
+following variables:
+
+@table @var
+@item op
+The RTL object defining the operand.
+@item mode
+The machine mode of @var{op}.
+@item ival
+@samp{INTVAL (@var{op})}, if @var{op} is a @code{const_int}.
+@item hval
+@samp{CONST_DOUBLE_HIGH (@var{op})}, if @var{op} is an integer
+@code{const_double}.
+@item lval
+@samp{CONST_DOUBLE_LOW (@var{op})}, if @var{op} is an integer
+@code{const_double}.
+@item rval
+@samp{CONST_DOUBLE_REAL_VALUE (@var{op})}, if @var{op} is a floating-point
+@code{const_double}.
+@end table
+
+The @var{*val} variables should only be used once another piece of the
+expression has verified that @var{op} is the appropriate kind of RTL
+object.
+@end deffn
+
+Most non-register constraints should be defined with
+@code{define_constraint}. The remaining two definition expressions
+are only appropriate for constraints that should be handled specially
+by @code{reload} if they fail to match.
+
+@deffn {MD Expression} define_memory_constraint name docstring exp
+Use this expression for constraints that match a subset of all memory
+operands: that is, @code{reload} can make them match by converting the
+operand to the form @samp{@w{(mem (reg @var{X}))}}, where @var{X} is a
+base register (from the register class specified by
+@code{BASE_REG_CLASS}, @pxref{Register Classes}).
+
+For example, on the S/390, some instructions do not accept arbitrary
+memory references, but only those that do not make use of an index
+register. The constraint letter @samp{Q} is defined to represent a
+memory address of this type. If @samp{Q} is defined with
+@code{define_memory_constraint}, a @samp{Q} constraint can handle any
+memory operand, because @code{reload} knows it can simply copy the
+memory address into a base register if required. This is analogous to
+the way a @samp{o} constraint can handle any memory operand.
+
+The syntax and semantics are otherwise identical to
+@code{define_constraint}.
+@end deffn
+
+@deffn {MD Expression} define_address_constraint name docstring exp
+Use this expression for constraints that match a subset of all address
+operands: that is, @code{reload} can make the constraint match by
+converting the operand to the form @samp{@w{(reg @var{X})}}, again
+with @var{X} a base register.
+
+Constraints defined with @code{define_address_constraint} can only be
+used with the @code{address_operand} predicate, or machine-specific
+predicates that work the same way. They are treated analogously to
+the generic @samp{p} constraint.
+
+The syntax and semantics are otherwise identical to
+@code{define_constraint}.
+@end deffn
+
+For historical reasons, names beginning with the letters @samp{G H}
+are reserved for constraints that match only @code{const_double}s, and
+names beginning with the letters @samp{I J K L M N O P} are reserved
+for constraints that match only @code{const_int}s. This may change in
+the future. For the time being, constraints with these names must be
+written in a stylized form, so that @code{genpreds} can tell you did
+it correctly:
+
+@smallexample
+@group
+(define_constraint "[@var{GHIJKLMNOP}]@dots{}"
+ "@var{doc}@dots{}"
+ (and (match_code "const_int") ; @r{@code{const_double} for G/H}
+ @var{condition}@dots{})) ; @r{usually a @code{match_test}}
+@end group
+@end smallexample
+@c the semicolons line up in the formatted manual
+
+It is fine to use names beginning with other letters for constraints
+that match @code{const_double}s or @code{const_int}s.
+
+Each docstring in a constraint definition should be one or more complete
+sentences, marked up in Texinfo format. @emph{They are currently unused.}
+In the future they will be copied into the GCC manual, in @ref{Machine
+Constraints}, replacing the hand-maintained tables currently found in
+that section. Also, in the future the compiler may use this to give
+more helpful diagnostics when poor choice of @code{asm} constraints
+causes a reload failure.
+
+If you put the pseudo-Texinfo directive @samp{@@internal} at the
+beginning of a docstring, then (in the future) it will appear only in
+the internals manual's version of the machine-specific constraint tables.
+Use this for constraints that should not appear in @code{asm} statements.
+
+@node C Constraint Interface
+@subsection Testing constraints from C
+@cindex testing constraints
+@cindex constraints, testing
+
+It is occasionally useful to test a constraint from C code rather than
+implicitly via the constraint string in a @code{match_operand}. The
+generated file @file{tm_p.h} declares a few interfaces for working
+with machine-specific constraints. None of these interfaces work with
+the generic constraints described in @ref{Simple Constraints}. This
+may change in the future.
+
+@strong{Warning:} @file{tm_p.h} may declare other functions that
+operate on constraints, besides the ones documented here. Do not use
+those functions from machine-dependent code. They exist to implement
+the old constraint interface that machine-independent components of
+the compiler still expect. They will change or disappear in the
+future.
+
+Some valid constraint names are not valid C identifiers, so there is a
+mangling scheme for referring to them from C@. Constraint names that
+do not contain angle brackets or underscores are left unchanged.
+Underscores are doubled, each @samp{<} is replaced with @samp{_l}, and
+each @samp{>} with @samp{_g}. Here are some examples:
+
+@c the @c's prevent double blank lines in the printed manual.
+@example
+@multitable {Original} {Mangled}
+@item @strong{Original} @tab @strong{Mangled} @c
+@item @code{x} @tab @code{x} @c
+@item @code{P42x} @tab @code{P42x} @c
+@item @code{P4_x} @tab @code{P4__x} @c
+@item @code{P4>x} @tab @code{P4_gx} @c
+@item @code{P4>>} @tab @code{P4_g_g} @c
+@item @code{P4_g>} @tab @code{P4__g_g} @c
+@end multitable
+@end example
+
+Throughout this section, the variable @var{c} is either a constraint
+in the abstract sense, or a constant from @code{enum constraint_num};
+the variable @var{m} is a mangled constraint name (usually as part of
+a larger identifier).
+
+@deftp Enum constraint_num
+For each machine-specific constraint, there is a corresponding
+enumeration constant: @samp{CONSTRAINT_} plus the mangled name of the
+constraint. Functions that take an @code{enum constraint_num} as an
+argument expect one of these constants.
+
+Machine-independent constraints do not have associated constants.
+This may change in the future.
+@end deftp
+
+@deftypefun {inline bool} satisfies_constraint_@var{m} (rtx @var{exp})
+For each machine-specific, non-register constraint @var{m}, there is
+one of these functions; it returns @code{true} if @var{exp} satisfies the
+constraint. These functions are only visible if @file{rtl.h} was included
+before @file{tm_p.h}.
+@end deftypefun
+
+@deftypefun bool constraint_satisfied_p (rtx @var{exp}, enum constraint_num @var{c})
+Like the @code{satisfies_constraint_@var{m}} functions, but the
+constraint to test is given as an argument, @var{c}. If @var{c}
+specifies a register constraint, this function will always return
+@code{false}.
+@end deftypefun
+
+@deftypefun {enum reg_class} regclass_for_constraint (enum constraint_num @var{c})
+Returns the register class associated with @var{c}. If @var{c} is not
+a register constraint, or those registers are not available for the
+currently selected subtarget, returns @code{NO_REGS}.
+@end deftypefun
+
+Here is an example use of @code{satisfies_constraint_@var{m}}. In
+peephole optimizations (@pxref{Peephole Definitions}), operand
+constraint strings are ignored, so if there are relevant constraints,
+they must be tested in the C condition. In the example, the
+optimization is applied if operand 2 does @emph{not} satisfy the
+@samp{K} constraint. (This is a simplified version of a peephole
+definition from the i386 machine description.)
+
+@smallexample
+(define_peephole2
+ [(match_scratch:SI 3 "r")
+ (set (match_operand:SI 0 "register_operand" "")
+ (mult:SI (match_operand:SI 1 "memory_operand" "")
+ (match_operand:SI 2 "immediate_operand" "")))]
+
+ "!satisfies_constraint_K (operands[2])"
+
+ [(set (match_dup 3) (match_dup 1))
+ (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))]
+
+ "")
+@end smallexample
+
@node Standard Names
@section Standard Pattern Names For Generation
@cindex standard pattern names
@table @asis
@cindex @code{mov@var{m}} instruction pattern
@item @samp{mov@var{m}}
-Here @var{m} stands for a two-letter machine mode name, in lower case.
+Here @var{m} stands for a two-letter machine mode name, in lowercase.
This instruction pattern moves data with that machine mode from operand
1 to operand 0. For example, @samp{movsi} moves full-word data.
it can be allocated using @code{gen_reg_rtx} prior to life analysis.
If there are cases which need scratch registers during or after reload,
-you must define @code{SECONDARY_INPUT_RELOAD_CLASS} and/or
-@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}.
+you must provide an appropriate secondary_reload target hook.
-@findex no_new_pseudos
-The global variable @code{no_new_pseudos} can be used to determine if it
+@findex can_create_pseudo_p
+The macro @code{can_create_pseudo_p} 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.
@cindex @code{reload_out} instruction pattern
@item @samp{reload_in@var{m}}
@itemx @samp{reload_out@var{m}}
+These named patterns have been obsoleted by the target hook
+@code{secondary_reload}.
+
Like @samp{mov@var{m}}, but used when a scratch register is required to
move between operand 0 and operand 1. Operand 2 describes the scratch
register. See the discussion of the @code{SECONDARY_RELOAD_CLASS}
the @samp{movstrict@var{m}} instruction is guaranteed not to alter
any of the register except the part which belongs to mode @var{m}.
+@cindex @code{movmisalign@var{m}} instruction pattern
+@item @samp{movmisalign@var{m}}
+This variant of a move pattern is designed to load or store a value
+from a memory address that is not naturally aligned for its mode.
+For a store, the memory will be in operand 0; for a load, the memory
+will be in operand 1. The other operand is guaranteed not to be a
+memory, so that it's easy to tell whether this is a load or store.
+
+This pattern is used by the autovectorizer, and when expanding a
+@code{MISALIGNED_INDIRECT_REF} expression.
+
@cindex @code{load_multiple} instruction pattern
@item @samp{load_multiple}
Load several consecutive memory locations into consecutive registers.
@code{set} of one register from the appropriate memory location (you may
also need @code{use} or @code{clobber} elements). Use a
@code{match_parallel} (@pxref{RTL Template}) to recognize the insn. See
-@file{a29k.md} and @file{rs6000.md} for examples of the use of this insn
-pattern.
+@file{rs6000.md} for examples of the use of this insn pattern.
@cindex @samp{store_multiple} instruction pattern
@item @samp{store_multiple}
consecutive memory locations, operand 1 is the first register, and
operand 2 is a constant: the number of consecutive registers.
-@cindex @code{push@var{m}} instruction pattern
-@item @samp{push@var{m}}
-Output an push instruction. Operand 0 is value to push. Used only when
+@cindex @code{vec_set@var{m}} instruction pattern
+@item @samp{vec_set@var{m}}
+Set given field in the vector value. Operand 0 is the vector to modify,
+operand 1 is new value of field and operand 2 specify the field index.
+
+@cindex @code{vec_extract@var{m}} instruction pattern
+@item @samp{vec_extract@var{m}}
+Extract given field from the vector value. Operand 1 is the vector, operand 2
+specify field index and operand 0 place to store value into.
+
+@cindex @code{vec_extract_even@var{m}} instruction pattern
+@item @samp{vec_extract_even@var{m}}
+Extract even elements from the input vectors (operand 1 and operand 2).
+The even elements of operand 2 are concatenated to the even elements of operand
+1 in their original order. The result is stored in operand 0.
+The output and input vectors should have the same modes.
+
+@cindex @code{vec_extract_odd@var{m}} instruction pattern
+@item @samp{vec_extract_odd@var{m}}
+Extract odd elements from the input vectors (operand 1 and operand 2).
+The odd elements of operand 2 are concatenated to the odd elements of operand
+1 in their original order. The result is stored in operand 0.
+The output and input vectors should have the same modes.
+
+@cindex @code{vec_interleave_high@var{m}} instruction pattern
+@item @samp{vec_interleave_high@var{m}}
+Merge high elements of the two input vectors into the output vector. The output
+and input vectors should have the same modes (@code{N} elements). The high
+@code{N/2} elements of the first input vector are interleaved with the high
+@code{N/2} elements of the second input vector.
+
+@cindex @code{vec_interleave_low@var{m}} instruction pattern
+@item @samp{vec_interleave_low@var{m}}
+Merge low elements of the two input vectors into the output vector. The output
+and input vectors should have the same modes (@code{N} elements). The low
+@code{N/2} elements of the first input vector are interleaved with the low
+@code{N/2} elements of the second input vector.
+
+@cindex @code{vec_init@var{m}} instruction pattern
+@item @samp{vec_init@var{m}}
+Initialize the vector to given values. Operand 0 is the vector to initialize
+and operand 1 is parallel containing values for individual fields.
+
+@cindex @code{push@var{m}1} instruction pattern
+@item @samp{push@var{m}1}
+Output a push instruction. Operand 0 is value to push. Used only when
@code{PUSH_ROUNDING} is defined. For historical reason, this pattern may be
missing and in such case an @code{mov} expander is used instead, with a
@code{MEM} expression forming the push operation. The @code{mov} expander
must have mode @var{m}. This can be used even on two-address machines, by
means of constraints requiring operands 1 and 0 to be the same location.
+@cindex @code{ssadd@var{m}3} instruction pattern
+@cindex @code{usadd@var{m}3} instruction pattern
@cindex @code{sub@var{m}3} instruction pattern
+@cindex @code{sssub@var{m}3} instruction pattern
+@cindex @code{ussub@var{m}3} instruction pattern
@cindex @code{mul@var{m}3} instruction pattern
+@cindex @code{ssmul@var{m}3} instruction pattern
+@cindex @code{usmul@var{m}3} instruction pattern
@cindex @code{div@var{m}3} instruction pattern
+@cindex @code{ssdiv@var{m}3} instruction pattern
@cindex @code{udiv@var{m}3} instruction pattern
+@cindex @code{usdiv@var{m}3} instruction pattern
@cindex @code{mod@var{m}3} instruction pattern
@cindex @code{umod@var{m}3} instruction pattern
-@cindex @code{smin@var{m}3} instruction pattern
-@cindex @code{smax@var{m}3} instruction pattern
@cindex @code{umin@var{m}3} instruction pattern
@cindex @code{umax@var{m}3} instruction pattern
@cindex @code{and@var{m}3} instruction pattern
@cindex @code{ior@var{m}3} instruction pattern
@cindex @code{xor@var{m}3} instruction pattern
-@item @samp{sub@var{m}3}, @samp{mul@var{m}3}
-@itemx @samp{div@var{m}3}, @samp{udiv@var{m}3}, @samp{mod@var{m}3}, @samp{umod@var{m}3}
-@itemx @samp{smin@var{m}3}, @samp{smax@var{m}3}, @samp{umin@var{m}3}, @samp{umax@var{m}3}
+@item @samp{ssadd@var{m}3}, @samp{usadd@var{m}3}
+@item @samp{sub@var{m}3}, @samp{sssub@var{m}3}, @samp{ussub@var{m}3}
+@item @samp{mul@var{m}3}, @samp{ssmul@var{m}3}, @samp{usmul@var{m}3}
+@itemx @samp{div@var{m}3}, @samp{ssdiv@var{m}3}
+@itemx @samp{udiv@var{m}3}, @samp{usdiv@var{m}3}
+@itemx @samp{mod@var{m}3}, @samp{umod@var{m}3}
+@itemx @samp{umin@var{m}3}, @samp{umax@var{m}3}
@itemx @samp{and@var{m}3}, @samp{ior@var{m}3}, @samp{xor@var{m}3}
Similar, for other arithmetic operations.
+
@cindex @code{min@var{m}3} instruction pattern
@cindex @code{max@var{m}3} instruction pattern
-@itemx @samp{min@var{m}3}, @samp{max@var{m}3}
-Floating point min and max operations. If both operands are zeros,
-or if either operand is NaN, then it is unspecified which of the two
-operands is returned as the result.
-
+@item @samp{smin@var{m}3}, @samp{smax@var{m}3}
+Signed minimum and maximum operations. When used with floating point,
+if both operands are zeros, or if either operand is @code{NaN}, then
+it is unspecified which of the two operands is returned as the result.
+
+@cindex @code{reduc_smin_@var{m}} instruction pattern
+@cindex @code{reduc_smax_@var{m}} instruction pattern
+@item @samp{reduc_smin_@var{m}}, @samp{reduc_smax_@var{m}}
+Find the signed minimum/maximum of the elements of a vector. The vector is
+operand 1, and the scalar result is stored in the least significant bits of
+operand 0 (also a vector). The output and input vector should have the same
+modes.
+
+@cindex @code{reduc_umin_@var{m}} instruction pattern
+@cindex @code{reduc_umax_@var{m}} instruction pattern
+@item @samp{reduc_umin_@var{m}}, @samp{reduc_umax_@var{m}}
+Find the unsigned minimum/maximum of the elements of a vector. The vector is
+operand 1, and the scalar result is stored in the least significant bits of
+operand 0 (also a vector). The output and input vector should have the same
+modes.
+
+@cindex @code{reduc_splus_@var{m}} instruction pattern
+@item @samp{reduc_splus_@var{m}}
+Compute the sum of the signed elements of a vector. The vector is operand 1,
+and the scalar result is stored in the least significant bits of operand 0
+(also a vector). The output and input vector should have the same modes.
+
+@cindex @code{reduc_uplus_@var{m}} instruction pattern
+@item @samp{reduc_uplus_@var{m}}
+Compute the sum of the unsigned elements of a vector. The vector is operand 1,
+and the scalar result is stored in the least significant bits of operand 0
+(also a vector). The output and input vector should have the same modes.
+
+@cindex @code{sdot_prod@var{m}} instruction pattern
+@item @samp{sdot_prod@var{m}}
+@cindex @code{udot_prod@var{m}} instruction pattern
+@item @samp{udot_prod@var{m}}
+Compute the sum of the products of two signed/unsigned elements.
+Operand 1 and operand 2 are of the same mode. Their product, which is of a
+wider mode, is computed and added to operand 3. Operand 3 is of a mode equal or
+wider than the mode of the product. The result is placed in operand 0, which
+is of the same mode as operand 3.
+
+@cindex @code{ssum_widen@var{m3}} instruction pattern
+@item @samp{ssum_widen@var{m3}}
+@cindex @code{usum_widen@var{m3}} instruction pattern
+@item @samp{usum_widen@var{m3}}
+Operands 0 and 2 are of the same mode, which is wider than the mode of
+operand 1. Add operand 1 to operand 2 and place the widened result in
+operand 0. (This is used express accumulation of elements into an accumulator
+of a wider mode.)
+
+@cindex @code{vec_shl_@var{m}} instruction pattern
+@cindex @code{vec_shr_@var{m}} instruction pattern
+@item @samp{vec_shl_@var{m}}, @samp{vec_shr_@var{m}}
+Whole vector left/right shift in bits.
+Operand 1 is a vector to be shifted.
+Operand 2 is an integer shift amount in bits.
+Operand 0 is where the resulting shifted vector is stored.
+The output and input vectors should have the same modes.
+
+@cindex @code{vec_pack_trunc_@var{m}} instruction pattern
+@item @samp{vec_pack_trunc_@var{m}}
+Narrow (demote) and merge the elements of two vectors. Operands 1 and 2
+are vectors of the same mode having N integral or floating point elements
+of size S@. Operand 0 is the resulting vector in which 2*N elements of
+size N/2 are concatenated after narrowing them down using truncation.
+
+@cindex @code{vec_pack_ssat_@var{m}} instruction pattern
+@cindex @code{vec_pack_usat_@var{m}} instruction pattern
+@item @samp{vec_pack_ssat_@var{m}}, @samp{vec_pack_usat_@var{m}}
+Narrow (demote) and merge the elements of two vectors. Operands 1 and 2
+are vectors of the same mode having N integral elements of size S.
+Operand 0 is the resulting vector in which the elements of the two input
+vectors are concatenated after narrowing them down using signed/unsigned
+saturating arithmetic.
+
+@cindex @code{vec_pack_sfix_trunc_@var{m}} instruction pattern
+@cindex @code{vec_pack_ufix_trunc_@var{m}} instruction pattern
+@item @samp{vec_pack_sfix_trunc_@var{m}}, @samp{vec_pack_ufix_trunc_@var{m}}
+Narrow, convert to signed/unsigned integral type and merge the elements
+of two vectors. Operands 1 and 2 are vectors of the same mode having N
+floating point elements of size S@. Operand 0 is the resulting vector
+in which 2*N elements of size N/2 are concatenated.
+
+@cindex @code{vec_unpacks_hi_@var{m}} instruction pattern
+@cindex @code{vec_unpacks_lo_@var{m}} instruction pattern
+@item @samp{vec_unpacks_hi_@var{m}}, @samp{vec_unpacks_lo_@var{m}}
+Extract and widen (promote) the high/low part of a vector of signed
+integral or floating point elements. The input vector (operand 1) has N
+elements of size S@. Widen (promote) the high/low elements of the vector
+using signed or floating point extension and place the resulting N/2
+values of size 2*S in the output vector (operand 0).
+
+@cindex @code{vec_unpacku_hi_@var{m}} instruction pattern
+@cindex @code{vec_unpacku_lo_@var{m}} instruction pattern
+@item @samp{vec_unpacku_hi_@var{m}}, @samp{vec_unpacku_lo_@var{m}}
+Extract and widen (promote) the high/low part of a vector of unsigned
+integral elements. The input vector (operand 1) has N elements of size S.
+Widen (promote) the high/low elements of the vector using zero extension and
+place the resulting N/2 values of size 2*S in the output vector (operand 0).
+
+@cindex @code{vec_unpacks_float_hi_@var{m}} instruction pattern
+@cindex @code{vec_unpacks_float_lo_@var{m}} instruction pattern
+@cindex @code{vec_unpacku_float_hi_@var{m}} instruction pattern
+@cindex @code{vec_unpacku_float_lo_@var{m}} instruction pattern
+@item @samp{vec_unpacks_float_hi_@var{m}}, @samp{vec_unpacks_float_lo_@var{m}}
+@itemx @samp{vec_unpacku_float_hi_@var{m}}, @samp{vec_unpacku_float_lo_@var{m}}
+Extract, convert to floating point type and widen the high/low part of a
+vector of signed/unsigned integral elements. The input vector (operand 1)
+has N elements of size S@. Convert the high/low elements of the vector using
+floating point conversion and place the resulting N/2 values of size 2*S in
+the output vector (operand 0).
+
+@cindex @code{vec_widen_umult_hi_@var{m}} instruction pattern
+@cindex @code{vec_widen_umult_lo__@var{m}} instruction pattern
+@cindex @code{vec_widen_smult_hi_@var{m}} instruction pattern
+@cindex @code{vec_widen_smult_lo_@var{m}} instruction pattern
+@item @samp{vec_widen_umult_hi_@var{m}}, @samp{vec_widen_umult_lo_@var{m}}
+@itemx @samp{vec_widen_smult_hi_@var{m}}, @samp{vec_widen_smult_lo_@var{m}}
+Signed/Unsigned widening multiplication. The two inputs (operands 1 and 2)
+are vectors with N signed/unsigned elements of size S@. Multiply the high/low
+elements of the two vectors, and put the N/2 products of size 2*S in the
+output vector (operand 0).
@cindex @code{mulhisi3} instruction pattern
@item @samp{mulhisi3}
Similar widening-multiplication instructions that do unsigned
multiplication.
+@cindex @code{usmulqihi3} instruction pattern
+@cindex @code{usmulhisi3} instruction pattern
+@cindex @code{usmulsidi3} instruction pattern
+@item @samp{usmulqihi3}, @samp{usmulhisi3}, @samp{usmulsidi3}
+Similar widening-multiplication instructions that interpret the first
+operand as unsigned and the second operand as signed, then do a signed
+multiplication.
+
@cindex @code{smul@var{m}3_highpart} instruction pattern
@item @samp{smul@var{m}3_highpart}
Perform a signed multiplication of operands 1 and 2, which have mode
@item @samp{umul@var{m}3_highpart}
Similar, but the multiplication is unsigned.
+@cindex @code{madd@var{m}@var{n}4} instruction pattern
+@item @samp{madd@var{m}@var{n}4}
+Multiply operands 1 and 2, sign-extend them to mode @var{n}, add
+operand 3, and store the result in operand 0. Operands 1 and 2
+have mode @var{m} and operands 0 and 3 have mode @var{n}.
+Both modes must be integer or fixed-point modes and @var{n} must be twice
+the size of @var{m}.
+
+In other words, @code{madd@var{m}@var{n}4} is like
+@code{mul@var{m}@var{n}3} except that it also adds operand 3.
+
+These instructions are not allowed to @code{FAIL}.
+
+@cindex @code{umadd@var{m}@var{n}4} instruction pattern
+@item @samp{umadd@var{m}@var{n}4}
+Like @code{madd@var{m}@var{n}4}, but zero-extend the multiplication
+operands instead of sign-extending them.
+
+@cindex @code{ssmadd@var{m}@var{n}4} instruction pattern
+@item @samp{ssmadd@var{m}@var{n}4}
+Like @code{madd@var{m}@var{n}4}, but all involved operations must be
+signed-saturating.
+
+@cindex @code{usmadd@var{m}@var{n}4} instruction pattern
+@item @samp{usmadd@var{m}@var{n}4}
+Like @code{umadd@var{m}@var{n}4}, but all involved operations must be
+unsigned-saturating.
+
+@cindex @code{msub@var{m}@var{n}4} instruction pattern
+@item @samp{msub@var{m}@var{n}4}
+Multiply operands 1 and 2, sign-extend them to mode @var{n}, subtract the
+result from operand 3, and store the result in operand 0. Operands 1 and 2
+have mode @var{m} and operands 0 and 3 have mode @var{n}.
+Both modes must be integer or fixed-point modes and @var{n} must be twice
+the size of @var{m}.
+
+In other words, @code{msub@var{m}@var{n}4} is like
+@code{mul@var{m}@var{n}3} except that it also subtracts the result
+from operand 3.
+
+These instructions are not allowed to @code{FAIL}.
+
+@cindex @code{umsub@var{m}@var{n}4} instruction pattern
+@item @samp{umsub@var{m}@var{n}4}
+Like @code{msub@var{m}@var{n}4}, but zero-extend the multiplication
+operands instead of sign-extending them.
+
+@cindex @code{ssmsub@var{m}@var{n}4} instruction pattern
+@item @samp{ssmsub@var{m}@var{n}4}
+Like @code{msub@var{m}@var{n}4}, but all involved operations must be
+signed-saturating.
+
+@cindex @code{usmsub@var{m}@var{n}4} instruction pattern
+@item @samp{usmsub@var{m}@var{n}4}
+Like @code{umsub@var{m}@var{n}4}, but all involved operations must be
+unsigned-saturating.
+
@cindex @code{divmod@var{m}4} instruction pattern
@item @samp{divmod@var{m}4}
Signed division that produces both a quotient and a remainder.
@item @samp{udivmod@var{m}4}
Similar, but does unsigned division.
+@anchor{shift patterns}
@cindex @code{ashl@var{m}3} instruction pattern
-@item @samp{ashl@var{m}3}
+@cindex @code{ssashl@var{m}3} instruction pattern
+@cindex @code{usashl@var{m}3} instruction pattern
+@item @samp{ashl@var{m}3}, @samp{ssashl@var{m}3}, @samp{usashl@var{m}3}
Arithmetic-shift operand 1 left by a number of bits specified by operand
2, and store the result in operand 0. Here @var{m} is the mode of
operand 0 and operand 1; operand 2's mode is specified by the
instruction pattern, and the compiler will convert the operand to that
-mode before generating the instruction.
+mode before generating the instruction. The meaning of out-of-range shift
+counts can optionally be specified by @code{TARGET_SHIFT_TRUNCATION_MASK}.
+@xref{TARGET_SHIFT_TRUNCATION_MASK}. Operand 2 is always a scalar type.
@cindex @code{ashr@var{m}3} instruction pattern
@cindex @code{lshr@var{m}3} instruction pattern
@cindex @code{rotr@var{m}3} instruction pattern
@item @samp{ashr@var{m}3}, @samp{lshr@var{m}3}, @samp{rotl@var{m}3}, @samp{rotr@var{m}3}
Other shift and rotate instructions, analogous to the
-@code{ashl@var{m}3} instructions.
+@code{ashl@var{m}3} instructions. Operand 2 is always a scalar type.
+
+@cindex @code{vashl@var{m}3} instruction pattern
+@cindex @code{vashr@var{m}3} instruction pattern
+@cindex @code{vlshr@var{m}3} instruction pattern
+@cindex @code{vrotl@var{m}3} instruction pattern
+@cindex @code{vrotr@var{m}3} instruction pattern
+@item @samp{vashl@var{m}3}, @samp{vashr@var{m}3}, @samp{vlshr@var{m}3}, @samp{vrotl@var{m}3}, @samp{vrotr@var{m}3}
+Vector shift and rotate instructions that take vectors as operand 2
+instead of a scalar type.
@cindex @code{neg@var{m}2} instruction pattern
-@item @samp{neg@var{m}2}
+@cindex @code{ssneg@var{m}2} instruction pattern
+@cindex @code{usneg@var{m}2} instruction pattern
+@item @samp{neg@var{m}2}, @samp{ssneg@var{m}2}, @samp{usneg@var{m}2}
Negate operand 1 and store the result in operand 0.
@cindex @code{abs@var{m}2} instruction pattern
Store the square root of operand 1 into operand 0.
The @code{sqrt} built-in function of C always uses the mode which
-corresponds to the C data type @code{double}.
+corresponds to the C data type @code{double} and the @code{sqrtf}
+built-in function uses the mode which corresponds to the C data
+type @code{float}.
+
+@cindex @code{fmod@var{m}3} instruction pattern
+@item @samp{fmod@var{m}3}
+Store the remainder of dividing operand 1 by operand 2 into
+operand 0, rounded towards zero to an integer.
+
+The @code{fmod} built-in function of C always uses the mode which
+corresponds to the C data type @code{double} and the @code{fmodf}
+built-in function uses the mode which corresponds to the C data
+type @code{float}.
+
+@cindex @code{remainder@var{m}3} instruction pattern
+@item @samp{remainder@var{m}3}
+Store the remainder of dividing operand 1 by operand 2 into
+operand 0, rounded to the nearest integer.
+
+The @code{remainder} built-in function of C always uses the mode
+which corresponds to the C data type @code{double} and the
+@code{remainderf} built-in function uses the mode which corresponds
+to the C data type @code{float}.
+
+@cindex @code{cos@var{m}2} instruction pattern
+@item @samp{cos@var{m}2}
+Store the cosine of operand 1 into operand 0.
+
+The @code{cos} built-in function of C always uses the mode which
+corresponds to the C data type @code{double} and the @code{cosf}
+built-in function uses the mode which corresponds to the C data
+type @code{float}.
+
+@cindex @code{sin@var{m}2} instruction pattern
+@item @samp{sin@var{m}2}
+Store the sine of operand 1 into operand 0.
+
+The @code{sin} built-in function of C always uses the mode which
+corresponds to the C data type @code{double} and the @code{sinf}
+built-in function uses the mode which corresponds to the C data
+type @code{float}.
+
+@cindex @code{exp@var{m}2} instruction pattern
+@item @samp{exp@var{m}2}
+Store the exponential of operand 1 into operand 0.
+
+The @code{exp} built-in function of C always uses the mode which
+corresponds to the C data type @code{double} and the @code{expf}
+built-in function uses the mode which corresponds to the C data
+type @code{float}.
+
+@cindex @code{log@var{m}2} instruction pattern
+@item @samp{log@var{m}2}
+Store the natural logarithm of operand 1 into operand 0.
+
+The @code{log} built-in function of C always uses the mode which
+corresponds to the C data type @code{double} and the @code{logf}
+built-in function uses the mode which corresponds to the C data
+type @code{float}.
+
+@cindex @code{pow@var{m}3} instruction pattern
+@item @samp{pow@var{m}3}
+Store the value of operand 1 raised to the exponent operand 2
+into operand 0.
+
+The @code{pow} built-in function of C always uses the mode which
+corresponds to the C data type @code{double} and the @code{powf}
+built-in function uses the mode which corresponds to the C data
+type @code{float}.
+
+@cindex @code{atan2@var{m}3} instruction pattern
+@item @samp{atan2@var{m}3}
+Store the arc tangent (inverse tangent) of operand 1 divided by
+operand 2 into operand 0, using the signs of both arguments to
+determine the quadrant of the result.
+
+The @code{atan2} built-in function of C always uses the mode which
+corresponds to the C data type @code{double} and the @code{atan2f}
+built-in function uses the mode which corresponds to the C data
+type @code{float}.
+
+@cindex @code{floor@var{m}2} instruction pattern
+@item @samp{floor@var{m}2}
+Store the largest integral value not greater than argument.
+
+The @code{floor} built-in function of C always uses the mode which
+corresponds to the C data type @code{double} and the @code{floorf}
+built-in function uses the mode which corresponds to the C data
+type @code{float}.
+
+@cindex @code{btrunc@var{m}2} instruction pattern
+@item @samp{btrunc@var{m}2}
+Store the argument rounded to integer towards zero.
+
+The @code{trunc} built-in function of C always uses the mode which
+corresponds to the C data type @code{double} and the @code{truncf}
+built-in function uses the mode which corresponds to the C data
+type @code{float}.
+
+@cindex @code{round@var{m}2} instruction pattern
+@item @samp{round@var{m}2}
+Store the argument rounded to integer away from zero.
+
+The @code{round} built-in function of C always uses the mode which
+corresponds to the C data type @code{double} and the @code{roundf}
+built-in function uses the mode which corresponds to the C data
+type @code{float}.
+
+@cindex @code{ceil@var{m}2} instruction pattern
+@item @samp{ceil@var{m}2}
+Store the argument rounded to integer away from zero.
+
+The @code{ceil} built-in function of C always uses the mode which
+corresponds to the C data type @code{double} and the @code{ceilf}
+built-in function uses the mode which corresponds to the C data
+type @code{float}.
+
+@cindex @code{nearbyint@var{m}2} instruction pattern
+@item @samp{nearbyint@var{m}2}
+Store the argument rounded according to the default rounding mode
+
+The @code{nearbyint} built-in function of C always uses the mode which
+corresponds to the C data type @code{double} and the @code{nearbyintf}
+built-in function uses the mode which corresponds to the C data
+type @code{float}.
+
+@cindex @code{rint@var{m}2} instruction pattern
+@item @samp{rint@var{m}2}
+Store the argument rounded according to the default rounding mode and
+raise the inexact exception when the result differs in value from
+the argument
+
+The @code{rint} built-in function of C always uses the mode which
+corresponds to the C data type @code{double} and the @code{rintf}
+built-in function uses the mode which corresponds to the C data
+type @code{float}.
+
+@cindex @code{lrint@var{m}@var{n}2}
+@item @samp{lrint@var{m}@var{n}2}
+Convert operand 1 (valid for floating point mode @var{m}) to fixed
+point mode @var{n} as a signed number according to the current
+rounding mode and store in operand 0 (which has mode @var{n}).
+
+@cindex @code{lround@var{m}@var{n}2}
+@item @samp{lround@var{m}2}
+Convert operand 1 (valid for floating point mode @var{m}) to fixed
+point mode @var{n} as a signed number rounding to nearest and away
+from zero and store in operand 0 (which has mode @var{n}).
+
+@cindex @code{lfloor@var{m}@var{n}2}
+@item @samp{lfloor@var{m}2}
+Convert operand 1 (valid for floating point mode @var{m}) to fixed
+point mode @var{n} as a signed number rounding down and store in
+operand 0 (which has mode @var{n}).
+
+@cindex @code{lceil@var{m}@var{n}2}
+@item @samp{lceil@var{m}2}
+Convert operand 1 (valid for floating point mode @var{m}) to fixed
+point mode @var{n} as a signed number rounding up and store in
+operand 0 (which has mode @var{n}).
+
+@cindex @code{copysign@var{m}3} instruction pattern
+@item @samp{copysign@var{m}3}
+Store a value with the magnitude of operand 1 and the sign of operand
+2 into operand 0.
+
+The @code{copysign} built-in function of C always uses the mode which
+corresponds to the C data type @code{double} and the @code{copysignf}
+built-in function uses the mode which corresponds to the C data
+type @code{float}.
@cindex @code{ffs@var{m}2} instruction pattern
@item @samp{ffs@var{m}2}
The @code{ffs} built-in function of C always uses the mode which
corresponds to the C data type @code{int}.
+@cindex @code{clz@var{m}2} instruction pattern
+@item @samp{clz@var{m}2}
+Store into operand 0 the number of leading 0-bits in @var{x}, starting
+at the most significant bit position. If @var{x} is 0, the
+@code{CLZ_DEFINED_VALUE_AT_ZERO} (@pxref{Misc}) macro defines if
+the result is undefined or has a useful value.
+@var{m} is the mode of operand 0; operand 1's mode is
+specified by the instruction pattern, and the compiler will convert the
+operand to that mode before generating the instruction.
+
+@cindex @code{ctz@var{m}2} instruction pattern
+@item @samp{ctz@var{m}2}
+Store into operand 0 the number of trailing 0-bits in @var{x}, starting
+at the least significant bit position. If @var{x} is 0, the
+@code{CTZ_DEFINED_VALUE_AT_ZERO} (@pxref{Misc}) macro defines if
+the result is undefined or has a useful value.
+@var{m} is the mode of operand 0; operand 1's mode is
+specified by the instruction pattern, and the compiler will convert the
+operand to that mode before generating the instruction.
+
+@cindex @code{popcount@var{m}2} instruction pattern
+@item @samp{popcount@var{m}2}
+Store into operand 0 the number of 1-bits in @var{x}. @var{m} is the
+mode of operand 0; operand 1's mode is specified by the instruction
+pattern, and the compiler will convert the operand to that mode before
+generating the instruction.
+
+@cindex @code{parity@var{m}2} instruction pattern
+@item @samp{parity@var{m}2}
+Store into operand 0 the parity of @var{x}, i.e.@: the number of 1-bits
+in @var{x} modulo 2. @var{m} is the mode of operand 0; operand 1's mode
+is specified by the instruction pattern, and the compiler will convert
+the operand to that mode before generating the instruction.
+
@cindex @code{one_cmpl@var{m}2} instruction pattern
@item @samp{one_cmpl@var{m}2}
Store the bitwise-complement of operand 1 into operand 0.
would no longer be clear which @code{set} operations were comparisons.
The @samp{cmp@var{m}} patterns should be used instead.
-@cindex @code{movstr@var{m}} instruction pattern
-@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}.
+@cindex @code{movmem@var{m}} instruction pattern
+@item @samp{movmem@var{m}}
+Block move instruction. The destination and source blocks of memory
+are the first two operands, and both are @code{mem:BLK}s with an
+address 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
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
+Optional operands 5 and 6 specify expected alignment and size of block
+respectively. The expected alignment differs from alignment in operand 4
+in a way that the blocks are not required to be aligned according to it in
+all cases. This expected alignment is also in bytes, just like operand 4.
+Expected size, when unknown, is set to @code{(const_int -1)}.
+
+Descriptions of multiple @code{movmem@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
+in @code{movmem@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.
-@cindex @code{clrstr@var{m}} instruction pattern
-@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}. 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
+@cindex @code{movstr} instruction pattern
+@item @samp{movstr}
+String copy instruction, with @code{stpcpy} semantics. Operand 0 is
+an output operand in mode @code{Pmode}. The addresses of the
+destination and source strings are operands 1 and 2, and both are
+@code{mem:BLK}s with addresses in mode @code{Pmode}. The execution of
+the expansion of this pattern should store in operand 0 the address in
+which the @code{NUL} terminator was stored in the destination string.
+
+@cindex @code{setmem@var{m}} instruction pattern
+@item @samp{setmem@var{m}}
+Block set instruction. The destination string is the first operand,
+given as a @code{mem:BLK} whose address is in mode @code{Pmode}. The
+number of bytes to set is the second operand, in mode @var{m}. The value to
+initialize the memory with is the third operand. Targets that only support the
+clearing of memory should reject any value that is not the constant 0. See
+@samp{movmem@var{m}} for a discussion of the choice of mode.
+
+The fourth 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}}.
+Optional operands 5 and 6 specify expected alignment and size of block
+respectively. The expected alignment differs from alignment in operand 4
+in a way that the blocks are not required to be aligned according to it in
+all cases. This expected alignment is also in bytes, just like operand 4.
+Expected size, when unknown, is set to @code{(const_int -1)}.
+
+The use for multiple @code{setmem@var{m}} is as for @code{movmem@var{m}}.
+
+@cindex @code{cmpstrn@var{m}} instruction pattern
+@item @samp{cmpstrn@var{m}}
+String compare instruction, with five operands. Operand 0 is the output;
+it has mode @var{m}. The remaining four operands are like the operands
+of @samp{movmem@var{m}}. The two memory blocks specified are compared
+byte by byte in lexicographic order starting at the beginning of each
+string. The instruction is not allowed to prefetch more than one byte
+at a time since either string may end in the first byte and reading past
+that may access an invalid page or segment and cause a fault. The
+effect of the instruction is to store a value in operand 0 whose sign
+indicates the result of the comparison.
@cindex @code{cmpstr@var{m}} instruction pattern
@item @samp{cmpstr@var{m}}
-Block compare instruction, with five operands. Operand 0 is the output;
-it has mode @var{m}. The remaining four operands are like the operands
-of @samp{movstr@var{m}}. The two memory blocks specified are compared
-byte by byte in lexicographic order. The effect of the instruction is
+String compare instruction, without known maximum length. Operand 0 is the
+output; it has mode @var{m}. The second and third operand are the blocks of
+memory to be compared; both are @code{mem:BLK} with an address in mode
+@code{Pmode}.
+
+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.
+
+The two memory blocks specified are compared byte by byte in lexicographic
+order starting at the beginning of each string. The instruction is not allowed
+to prefetch more than one byte at a time since either string may end in the
+first byte and reading past that may access an invalid page or segment and
+cause a fault. The effect of the instruction is to store a value in operand 0
+whose sign indicates the result of the comparison.
+
+@cindex @code{cmpmem@var{m}} instruction pattern
+@item @samp{cmpmem@var{m}}
+Block compare instruction, with five operands like the operands
+of @samp{cmpstr@var{m}}. The two memory blocks specified are compared
+byte by byte in lexicographic order starting at the beginning of each
+block. Unlike @samp{cmpstr@var{m}} the instruction can prefetch
+any bytes in the two memory blocks. The effect of the instruction is
to store a value in operand 0 whose sign indicates the result of the
comparison.
has mode @var{n}). This instruction's result is defined only when
the value of operand 1 is an integer.
+If the machine description defines this pattern, it also needs to
+define the @code{ftrunc} pattern.
+
@cindex @code{fixuns@var{mn}2} instruction pattern
@item @samp{fixuns@var{m}@var{n}2}
Convert operand 1 (valid for floating point mode @var{m}) to fixed
store in operand 0 (which has mode @var{n}). Both modes must be fixed
point.
+@cindex @code{fract@var{mn}2} instruction pattern
+@item @samp{fract@var{m}@var{n}2}
+Convert operand 1 of mode @var{m} to mode @var{n} and store in
+operand 0 (which has mode @var{n}). Mode @var{m} and mode @var{n}
+could be fixed-point to fixed-point, signed integer to fixed-point,
+fixed-point to signed integer, floating-point to fixed-point,
+or fixed-point to floating-point.
+When overflows or underflows happen, the results are undefined.
+
+@cindex @code{satfract@var{mn}2} instruction pattern
+@item @samp{satfract@var{m}@var{n}2}
+Convert operand 1 of mode @var{m} to mode @var{n} and store in
+operand 0 (which has mode @var{n}). Mode @var{m} and mode @var{n}
+could be fixed-point to fixed-point, signed integer to fixed-point,
+or floating-point to fixed-point.
+When overflows or underflows happen, the instruction saturates the
+results to the maximum or the minimum.
+
+@cindex @code{fractuns@var{mn}2} instruction pattern
+@item @samp{fractuns@var{m}@var{n}2}
+Convert operand 1 of mode @var{m} to mode @var{n} and store in
+operand 0 (which has mode @var{n}). Mode @var{m} and mode @var{n}
+could be unsigned integer to fixed-point, or
+fixed-point to unsigned integer.
+When overflows or underflows happen, the results are undefined.
+
+@cindex @code{satfractuns@var{mn}2} instruction pattern
+@item @samp{satfractuns@var{m}@var{n}2}
+Convert unsigned integer operand 1 of mode @var{m} to fixed-point mode
+@var{n} and store in operand 0 (which has mode @var{n}).
+When overflows or underflows happen, the instruction saturates the
+results to the maximum or the minimum.
+
@cindex @code{extv} instruction pattern
@item @samp{extv}
Extract a bit-field from operand 1 (a register or memory operand), where
be valid for @code{word_mode}.
The RTL generation pass generates this instruction only with constants
-for operands 2 and 3.
+for operands 2 and 3 and the constant is never zero for operand 2.
The bit-field value is sign-extended to a full word integer
before it is stored in operand 0.
Operands 1 and 2 must be valid for @code{word_mode}.
The RTL generation pass generates this instruction only with constants
-for operands 1 and 2.
+for operands 1 and 2 and the constant is never zero for operand 1.
@cindex @code{mov@var{mode}cc} instruction pattern
@item @samp{mov@var{mode}cc}
If the machine does not have conditional move instructions, do not
define these patterns.
+@cindex @code{add@var{mode}cc} instruction pattern
+@item @samp{add@var{mode}cc}
+Similar to @samp{mov@var{mode}cc} but for conditional addition. Conditionally
+move operand 2 or (operands 2 + operand 3) into operand 0 according to the
+comparison in operand 1. If the comparison is true, operand 2 is moved into
+operand 0, otherwise (operand 2 + operand 3) is moved.
+
@cindex @code{s@var{cond}} instruction pattern
@item @samp{s@var{cond}}
Store zero or nonzero in the operand according to the condition codes.
The above discussion also applies to the @samp{mov@var{mode}cc} and
@samp{s@var{cond}} patterns.
+@cindex @code{cbranch@var{mode}4} instruction pattern
+@item @samp{cbranch@var{mode}4}
+Conditional branch instruction combined with a compare instruction.
+Operand 0 is a comparison operator. Operand 1 and operand 2 are the
+first and second operands of the comparison, respectively. Operand 3
+is a @code{label_ref} that refers to the label to jump to.
+
@cindex @code{jump} instruction pattern
@item @samp{jump}
A jump inside a function; an unconditional branch. Operand 0 is the
@item
A label to jump to if the index has a value outside the bounds.
-(If the machine-description macro @code{CASE_DROPS_THROUGH} is defined,
-then an out-of-bounds index drops through to the code following
-the jump table instead of jumping to this label. In that case,
-this label is not actually used by the @samp{casesi} instruction,
-but it is always provided as an operand.)
@end enumerate
The table is a @code{addr_vec} or @code{addr_diff_vec} inside of a
maintaining the back chain. Define this pattern to emit those
operations in addition to updating the stack pointer.
-@cindex @code{probe} instruction pattern
-@item @samp{probe}
-Some machines require instructions to be executed after space is
-allocated from the stack, for example to generate a reference at
-the bottom of the stack.
-
-If you need to emit instructions before the stack has been adjusted,
-put them into the @samp{allocate_stack} pattern. Otherwise, define
-this pattern to emit the required instructions.
-
-No operands are provided.
-
@cindex @code{check_stack} instruction pattern
@item @samp{check_stack}
If stack checking cannot be done on your system by probing the stack with
built. It is intended to handle non-trivial actions needed along
the abnormal return path.
-The pattern takes two arguments. The first is an offset to be applied
-to the stack pointer. It will have been copied to some appropriate
-location (typically @code{EH_RETURN_STACKADJ_RTX}) which will survive
-until after reload to when the normal epilogue is generated.
-The second 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 or memory location.
+The address of the exception handler to which the function should return
+is passed as operand to this pattern. It will normally need to copied by
+the pattern to some special register or memory location.
+If the pattern needs to determine the location of the target call
+frame in order to do so, it may use @code{EH_RETURN_STACKADJ_RTX},
+if defined; it will have already been assigned.
-This pattern only needs to be defined if call frame exception handling
-is to be used, and simple moves involving @code{EH_RETURN_STACKADJ_RTX}
-and @code{EH_RETURN_HANDLER_RTX} are not sufficient.
+If this pattern is not defined, the default action will be to simply
+copy the return address to @code{EH_RETURN_HANDLER_RTX}. Either
+that macro or this pattern needs to be defined if call frame exception
+handling is to be used.
@cindex @code{prologue} instruction pattern
@anchor{prologue instruction pattern}
Targets that do not support write prefetches or locality hints can ignore
the values of operands 1 and 2.
-@cindex @code{cycle_display} instruction pattern
-@item @samp{cycle_display}
-
-This pattern, if present, will be emitted by the instruction scheduler at
-the beginning of each new clock cycle. This can be used for annotating the
-assembler output with cycle counts. Operand 0 is a @code{const_int} that
-holds the clock cycle.
+@cindex @code{blockage} instruction pattern
+@item @samp{blockage}
+
+This pattern defines a pseudo insn that prevents the instruction
+scheduler from moving instructions across the boundary defined by the
+blockage insn. Normally an UNSPEC_VOLATILE pattern.
+
+@cindex @code{memory_barrier} instruction pattern
+@item @samp{memory_barrier}
+
+If the target memory model is not fully synchronous, then this pattern
+should be defined to an instruction that orders both loads and stores
+before the instruction with respect to loads and stores after the instruction.
+This pattern has no operands.
+
+@cindex @code{sync_compare_and_swap@var{mode}} instruction pattern
+@item @samp{sync_compare_and_swap@var{mode}}
+
+This pattern, if defined, emits code for an atomic compare-and-swap
+operation. Operand 1 is the memory on which the atomic operation is
+performed. Operand 2 is the ``old'' value to be compared against the
+current contents of the memory location. Operand 3 is the ``new'' value
+to store in the memory if the compare succeeds. Operand 0 is the result
+of the operation; it should contain the contents of the memory
+before the operation. If the compare succeeds, this should obviously be
+a copy of operand 2.
+
+This pattern must show that both operand 0 and operand 1 are modified.
+
+This pattern must issue any memory barrier instructions such that all
+memory operations before the atomic operation occur before the atomic
+operation and all memory operations after the atomic operation occur
+after the atomic operation.
+
+@cindex @code{sync_compare_and_swap_cc@var{mode}} instruction pattern
+@item @samp{sync_compare_and_swap_cc@var{mode}}
+
+This pattern is just like @code{sync_compare_and_swap@var{mode}}, except
+it should act as if compare part of the compare-and-swap were issued via
+@code{cmp@var{m}}. This comparison will only be used with @code{EQ} and
+@code{NE} branches and @code{setcc} operations.
+
+Some targets do expose the success or failure of the compare-and-swap
+operation via the status flags. Ideally we wouldn't need a separate
+named pattern in order to take advantage of this, but the combine pass
+does not handle patterns with multiple sets, which is required by
+definition for @code{sync_compare_and_swap@var{mode}}.
+
+@cindex @code{sync_add@var{mode}} instruction pattern
+@cindex @code{sync_sub@var{mode}} instruction pattern
+@cindex @code{sync_ior@var{mode}} instruction pattern
+@cindex @code{sync_and@var{mode}} instruction pattern
+@cindex @code{sync_xor@var{mode}} instruction pattern
+@cindex @code{sync_nand@var{mode}} instruction pattern
+@item @samp{sync_add@var{mode}}, @samp{sync_sub@var{mode}}
+@itemx @samp{sync_ior@var{mode}}, @samp{sync_and@var{mode}}
+@itemx @samp{sync_xor@var{mode}}, @samp{sync_nand@var{mode}}
+
+These patterns emit code for an atomic operation on memory.
+Operand 0 is the memory on which the atomic operation is performed.
+Operand 1 is the second operand to the binary operator.
+
+This pattern must issue any memory barrier instructions such that all
+memory operations before the atomic operation occur before the atomic
+operation and all memory operations after the atomic operation occur
+after the atomic operation.
+
+If these patterns are not defined, the operation will be constructed
+from a compare-and-swap operation, if defined.
+
+@cindex @code{sync_old_add@var{mode}} instruction pattern
+@cindex @code{sync_old_sub@var{mode}} instruction pattern
+@cindex @code{sync_old_ior@var{mode}} instruction pattern
+@cindex @code{sync_old_and@var{mode}} instruction pattern
+@cindex @code{sync_old_xor@var{mode}} instruction pattern
+@cindex @code{sync_old_nand@var{mode}} instruction pattern
+@item @samp{sync_old_add@var{mode}}, @samp{sync_old_sub@var{mode}}
+@itemx @samp{sync_old_ior@var{mode}}, @samp{sync_old_and@var{mode}}
+@itemx @samp{sync_old_xor@var{mode}}, @samp{sync_old_nand@var{mode}}
+
+These patterns are emit code for an atomic operation on memory,
+and return the value that the memory contained before the operation.
+Operand 0 is the result value, operand 1 is the memory on which the
+atomic operation is performed, and operand 2 is the second operand
+to the binary operator.
+
+This pattern must issue any memory barrier instructions such that all
+memory operations before the atomic operation occur before the atomic
+operation and all memory operations after the atomic operation occur
+after the atomic operation.
+
+If these patterns are not defined, the operation will be constructed
+from a compare-and-swap operation, if defined.
+
+@cindex @code{sync_new_add@var{mode}} instruction pattern
+@cindex @code{sync_new_sub@var{mode}} instruction pattern
+@cindex @code{sync_new_ior@var{mode}} instruction pattern
+@cindex @code{sync_new_and@var{mode}} instruction pattern
+@cindex @code{sync_new_xor@var{mode}} instruction pattern
+@cindex @code{sync_new_nand@var{mode}} instruction pattern
+@item @samp{sync_new_add@var{mode}}, @samp{sync_new_sub@var{mode}}
+@itemx @samp{sync_new_ior@var{mode}}, @samp{sync_new_and@var{mode}}
+@itemx @samp{sync_new_xor@var{mode}}, @samp{sync_new_nand@var{mode}}
+
+These patterns are like their @code{sync_old_@var{op}} counterparts,
+except that they return the value that exists in the memory location
+after the operation, rather than before the operation.
+
+@cindex @code{sync_lock_test_and_set@var{mode}} instruction pattern
+@item @samp{sync_lock_test_and_set@var{mode}}
+
+This pattern takes two forms, based on the capabilities of the target.
+In either case, operand 0 is the result of the operand, operand 1 is
+the memory on which the atomic operation is performed, and operand 2
+is the value to set in the lock.
+
+In the ideal case, this operation is an atomic exchange operation, in
+which the previous value in memory operand is copied into the result
+operand, and the value operand is stored in the memory operand.
+
+For less capable targets, any value operand that is not the constant 1
+should be rejected with @code{FAIL}. In this case the target may use
+an atomic test-and-set bit operation. The result operand should contain
+1 if the bit was previously set and 0 if the bit was previously clear.
+The true contents of the memory operand are implementation defined.
+
+This pattern must issue any memory barrier instructions such that the
+pattern as a whole acts as an acquire barrier, that is all memory
+operations after the pattern do not occur until the lock is acquired.
+
+If this pattern is not defined, the operation will be constructed from
+a compare-and-swap operation, if defined.
+
+@cindex @code{sync_lock_release@var{mode}} instruction pattern
+@item @samp{sync_lock_release@var{mode}}
+
+This pattern, if defined, releases a lock set by
+@code{sync_lock_test_and_set@var{mode}}. Operand 0 is the memory
+that contains the lock; operand 1 is the value to store in the lock.
+
+If the target doesn't implement full semantics for
+@code{sync_lock_test_and_set@var{mode}}, any value operand which is not
+the constant 0 should be rejected with @code{FAIL}, and the true contents
+of the memory operand are implementation defined.
+
+This pattern must issue any memory barrier instructions such that the
+pattern as a whole acts as a release barrier, that is the lock is
+released only after all previous memory operations have completed.
+
+If this pattern is not defined, then a @code{memory_barrier} pattern
+will be emitted, followed by a store of the value to the memory operand.
+
+@cindex @code{stack_protect_set} instruction pattern
+@item @samp{stack_protect_set}
+
+This pattern, if defined, moves a @code{Pmode} value from the memory
+in operand 1 to the memory in operand 0 without leaving the value in
+a register afterward. This is to avoid leaking the value some place
+that an attacker might use to rewrite the stack guard slot after
+having clobbered it.
+
+If this pattern is not defined, then a plain move pattern is generated.
+
+@cindex @code{stack_protect_test} instruction pattern
+@item @samp{stack_protect_test}
+
+This pattern, if defined, compares a @code{Pmode} value from the
+memory in operand 1 with the memory in operand 0 without leaving the
+value in a register afterward and branches to operand 2 if the values
+weren't equal.
+
+If this pattern is not defined, then a plain compare pattern and
+conditional branch pattern is used.
+
+@cindex @code{clear_cache} instruction pattern
+@item @samp{clear_cache}
+
+This pattern, if defined, flushes the instruction cache for a region of
+memory. The region is bounded to by the Pmode pointers in operand 0
+inclusive and operand 1 exclusive.
+
+If this pattern is not defined, a call to the library function
+@code{__clear_cache} is used.
@end table
+@end ifset
+@c Each of the following nodes are wrapped in separate
+@c "@ifset INTERNALS" to work around memory limits for the default
+@c configuration in older tetex distributions. Known to not work:
+@c tetex-1.0.7, known to work: tetex-2.0.2.
+@ifset INTERNALS
@node Pattern Ordering
@section When the Order of Patterns Matters
@cindex Pattern Ordering
pattern for convert-a-byte smart enough to deal properly with any
constant value.
+@end ifset
+@ifset INTERNALS
@node Dependent Patterns
@section Interdependence of Patterns
@cindex Dependent Patterns
conditional branch names @samp{b@var{cond}}. The recognition template
must always have the form
-@example
+@smallexample
(set (pc)
(if_then_else (@var{cond} (cc0) (const_int 0))
(label_ref (match_operand 0 "" ""))
(pc)))
-@end example
+@end smallexample
@noindent
In addition, every machine description must have an anonymous pattern
for each of the possible reverse-conditional branches. Their templates
look like
-@example
+@smallexample
(set (pc)
(if_then_else (@var{cond} (cc0) (const_int 0))
(pc)
(label_ref (match_operand 0 "" ""))))
-@end example
+@end smallexample
@noindent
They are necessary because jump optimization can turn direct-conditional
reduce the number of patterns that must be specified for branches. For
example,
-@example
+@smallexample
(define_insn ""
[(set (pc)
(if_then_else (match_operator 0 "comparison_operator"
(label_ref (match_operand 1 "" ""))))]
"@var{condition}"
"@dots{}")
-@end example
+@end smallexample
In some cases machines support instructions identical except for the
machine mode of one or more operands. For example, there may be
``sign-extend halfword'' and ``sign-extend byte'' instructions whose
patterns are
-@example
+@smallexample
(set (match_operand:SI 0 @dots{})
(extend:SI (match_operand:HI 1 @dots{})))
(set (match_operand:SI 0 @dots{})
(extend:SI (match_operand:QI 1 @dots{})))
-@end example
+@end smallexample
@noindent
Constant integers do not specify a machine mode, so an instruction to
that supports register-register add insns by examining the operands and
generating the appropriate machine instruction.
+@end ifset
+@ifset INTERNALS
@node Jump Patterns
@section Defining Jump Instruction Patterns
@cindex jump instruction patterns
@findex next_cc0_user
On some machines, the type of branch instruction generated may depend on
the way the condition code was produced; for example, on the 68k and
-Sparc, setting the condition code directly from an add or subtract
+SPARC, setting the condition code directly from an add or subtract
instruction does not clear the overflow bit the way that a test
instruction does, so a different branch instruction must be used for
some conditional branches. For machines that use @code{(cc0)}, the set
Registers used to store the condition code value should have a mode that
is in class @code{MODE_CC}. Normally, it will be @code{CCmode}. If
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{SELECT_CC_MODE} to choose a mode given an operand of a compare.
+the SPARC), define them in @file{@var{machine}-modes.def}
+(@pxref{Condition Code}). Also define @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
required (for example, if the machine has separate compare instructions
If the cases that require different modes would be made by instruction
combination, the macro @code{SELECT_CC_MODE} determines which machine
mode should be used for the comparison result. The patterns should be
-written using that mode. To support the case of the add on the Sparc
+written using that mode. To support the case of the add on the SPARC
discussed above, we have the pattern
@smallexample
"@dots{}")
@end smallexample
-The @code{SELECT_CC_MODE} macro on the Sparc returns @code{CC_NOOVmode}
+The @code{SELECT_CC_MODE} macro on the SPARC returns @code{CC_NOOVmode}
for comparisons whose argument is a @code{plus}.
+@end ifset
+@ifset INTERNALS
@node Looping Patterns
@section Defining Looping Instruction Patterns
@cindex looping instruction patterns
@cindex defining looping instruction patterns
-Some machines have special jump instructions that can be utilised to
+Some machines have special jump instructions that can be utilized to
make loops more efficient. A common example is the 68000 @samp{dbra}
instruction which performs a decrement of a register and a branch if the
result was greater than zero. Other machines, in particular digital
@group
(define_insn "decrement_and_branch_until_zero"
[(set (pc)
- (if_then_else
- (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am")
- (const_int -1))
- (const_int 0))
- (label_ref (match_operand 1 "" ""))
- (pc)))
+ (if_then_else
+ (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am")
+ (const_int -1))
+ (const_int 0))
+ (label_ref (match_operand 1 "" ""))
+ (pc)))
(set (match_dup 0)
- (plus:SI (match_dup 0)
- (const_int -1)))]
+ (plus:SI (match_dup 0)
+ (const_int -1)))]
"find_reg_note (insn, REG_NONNEG, 0)"
"@dots{}")
@end group
@group
(define_insn "decrement_and_branch_until_zero"
[(set (pc)
- (if_then_else
- (ge (match_operand:SI 0 "general_operand" "+d*am")
- (const_int 1))
- (label_ref (match_operand 1 "" ""))
- (pc)))
+ (if_then_else
+ (ge (match_operand:SI 0 "general_operand" "+d*am")
+ (const_int 1))
+ (label_ref (match_operand 1 "" ""))
+ (pc)))
(set (match_dup 0)
- (plus:SI (match_dup 0)
- (const_int -1)))]
+ (plus:SI (match_dup 0)
+ (const_int -1)))]
"find_reg_note (insn, REG_NONNEG, 0)"
"@dots{}")
@end group
may become redundant and removed by the flow pass.
+@end ifset
+@ifset INTERNALS
@node Insn Canonicalizations
@section Canonicalization of Instructions
@cindex canonicalization of instructions
operand, only patterns that match a constant in the second operand need
be supplied.
+@item
+For associative operators, a sequence of operators will always chain
+to the left; for instance, only the left operand of an integer @code{plus}
+can itself be a @code{plus}. @code{and}, @code{ior}, @code{xor},
+@code{plus}, @code{mult}, @code{smin}, @code{smax}, @code{umin}, and
+@code{umax} are associative when applied to integers, and sometimes to
+floating-point.
+
+@item
@cindex @code{neg}, canonicalization of
@cindex @code{not}, canonicalization of
@cindex @code{mult}, canonicalization of
@code{mult}, @code{plus}, or @code{minus} expression, it will be the
first operand.
+@item
+In combinations of @code{neg}, @code{mult}, @code{plus}, and
+@code{minus}, the @code{neg} operations (if any) will be moved inside
+the operations as far as possible. For instance,
+@code{(neg (mult A B))} is canonicalized as @code{(mult (neg A) B)}, but
+@code{(plus (mult (neg A) B) C)} is canonicalized as
+@code{(minus A (mult B C))}.
+
@cindex @code{compare}, canonicalization of
@item
For the @code{compare} operator, a constant is always the second operand
@code{minus} is made the first operand under the same conditions as
above.
+@item
+@code{(ltu (plus @var{a} @var{b}) @var{b})} is converted to
+@code{(ltu (plus @var{a} @var{b}) @var{a})}. Likewise with @code{geu} instead
+of @code{ltu}.
+
@item
@code{(minus @var{x} (const_int @var{n}))} is converted to
@code{(plus @var{x} (const_int @var{-n}))}.
@cindex @code{and}, canonicalization of
@cindex De Morgan's law
@item
-De`Morgan's Law is used to move bitwise negation inside a bitwise
+De Morgan's Law is used to move bitwise negation inside a bitwise
logical-and or logical-or operation. If this results in only one
operand being a @code{not} expression, it will be the first one.
operand with the bitwise negation of the other should specify the pattern
for that instruction as
-@example
+@smallexample
(define_insn ""
[(set (match_operand:@var{m} 0 @dots{})
(and:@var{m} (not:@var{m} (match_operand:@var{m} 1 @dots{}))
(match_operand:@var{m} 2 @dots{})))]
"@dots{}"
"@dots{}")
-@end example
+@end smallexample
@noindent
Similarly, a pattern for a ``NAND'' instruction should be written
-@example
+@smallexample
(define_insn ""
[(set (match_operand:@var{m} 0 @dots{})
(ior:@var{m} (not:@var{m} (match_operand:@var{m} 1 @dots{}))
(not:@var{m} (match_operand:@var{m} 2 @dots{}))))]
"@dots{}"
"@dots{}")
-@end example
+@end smallexample
In both cases, it is not necessary to include patterns for the many
logically equivalent RTL expressions.
The sum of three items, one of which is a constant, will only appear in
the form
-@example
+@smallexample
(plus:@var{m} (plus:@var{m} @var{x} @var{y}) @var{constant})
-@end example
+@end smallexample
@item
On machines that do not use @code{cc0},
@end itemize
+Further canonicalization rules are defined in the function
+@code{commutative_operand_precedence} in @file{gcc/rtlanal.c}.
+
+@end ifset
+@ifset INTERNALS
@node Expander Definitions
@section Defining RTL Sequences for Code Generation
@cindex expander definitions
= force_reg (SImode, GEN_INT (65535)); ")
@end smallexample
-@strong{Note:} If the @code{define_expand} is used to serve a
+@emph{Note:} If the @code{define_expand} is used to serve a
standard binary or unary arithmetic operation or a bit-field operation,
then the last insn it generates must not be a @code{code_label},
@code{barrier} or @code{note}. It must be an @code{insn},
itself. Such an insn will generate no code, but it can avoid problems
in the compiler.
+@end ifset
+@ifset INTERNALS
@node Insn Splitting
@section Defining How to Split Instructions
@cindex insn splitting
@cindex instruction splitting
@cindex splitting instructions
-There are two cases where you should specify how to split a pattern into
-multiple insns. On machines that have instructions requiring delay
-slots (@pxref{Delay Slots}) or that have instructions whose output is
-not available for multiple cycles (@pxref{Function Units}), the compiler
-phases that optimize these cases need to be able to move insns into
-one-instruction delay slots. However, some insns may generate more than one
-machine instruction. These insns cannot be placed into a delay slot.
+There are two cases where you should specify how to split a pattern
+into multiple insns. On machines that have instructions requiring
+delay slots (@pxref{Delay Slots}) or that have instructions whose
+output is not available for multiple cycles (@pxref{Processor pipeline
+description}), the compiler phases that optimize these cases need to
+be able to move insns into one-instruction delay slots. However, some
+insns may generate more than one machine instruction. These insns
+cannot be placed into a delay slot.
Often you can rewrite the single insn as a list of individual insns,
each corresponding to one machine instruction. The disadvantage of
(set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))]
"
@{
- /* Get the constant we are comparing against, C, and see what it
+ /* @r{Get the constant we are comparing against, C, and see what it
looks like sign-extended to 16 bits. Then see what constant
- could be XOR'ed with C to get the sign-extended value. */
+ could be XOR'ed with C to get the sign-extended value.} */
int c = INTVAL (operands[2]);
int sextc = (c << 16) >> 16;
jump. When new sequence contains multiple jump instructions or new labels,
more assistance is needed. Splitter is required to create only unconditional
jumps, or simple conditional jump instructions. Additionally it must attach a
-@code{REG_BR_PROB} note to each conditional jump. An global variable
-@code{split_branch_probability} hold the probability of original branch in case
+@code{REG_BR_PROB} note to each conditional jump. A global variable
+@code{split_branch_probability} holds the probability of the original branch in case
it was an simple conditional jump, @minus{}1 otherwise. To simplify
-recomputing of edge frequencies, new sequence is required to have only
+recomputing of edge frequencies, the new sequence is required to have only
forward jumps to the newly created labels.
@findex define_insn_and_split
"&& reload_completed"
[(parallel [(set (match_dup 0)
(and:SI (match_dup 0) (const_int 65535)))
- (clobber (reg:CC 17))])]
+ (clobber (reg:CC 17))])]
""
[(set_attr "type" "alu1")])
patterns. It exists for compactness, and as a maintenance tool to prevent
having to ensure the two patterns' templates match.
+@end ifset
+@ifset INTERNALS
@node Including Patterns
@section Including Patterns in Machine Descriptions.
@cindex insn includes
@findex include
The @code{include} pattern tells the compiler tools where to
look for patterns that are in files other than in the file
-@file{.md}. This is used only at build time and there is no preprocessing allowed.
+@file{.md}. This is used only at build time and there is no preprocessing allowed.
It looks like:
@end smallexample
-Where @var{pathname} is a string that specifies the the location of the file,
-specifies the include file to be in @file{gcc/config/target/filestuff}. The
+Where @var{pathname} is a string that specifies the location of the file,
+specifies the include file to be in @file{gcc/config/target/filestuff}. The
directory @file{gcc/config/target} is regarded as the default directory.
order; the standard default directory come after.
+@end ifset
+@ifset INTERNALS
@node Peephole Definitions
@section Machine-Specific Peephole Optimizers
@cindex peephole optimizer definitions
* define_peephole2:: RTL to RTL Peephole Optimizers
@end menu
+@end ifset
+@ifset INTERNALS
@node define_peephole
@subsection RTL to Text Peephole Optimizers
@findex define_peephole
"FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
@{
rtx xoperands[2];
- xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1);
+ 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);
@dots{})
@end smallexample
+@end ifset
+@ifset INTERNALS
@node define_peephole2
@subsection RTL to RTL Peephole Optimizers
@findex define_peephole2
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}.
+@end ifset
+@ifset INTERNALS
@node Insn Attributes
@section Instruction Attributes
@cindex insn attributes
* Insn Lengths:: Computing the length of insns.
* Constant Attributes:: Defining attributes that are constant.
* Delay Slots:: Defining delay slots required for a machine.
-* Function Units:: Specifying information for insn scheduling.
+* Processor pipeline description:: Specifying information for insn scheduling.
@end menu
+@end ifset
+@ifset INTERNALS
@node Defining Attributes
@subsection Defining Attributes and their Values
@cindex defining attributes and their values
A @samp{#define} is written for the symbol @samp{HAVE_ATTR_@var{name}}.
@item
-An enumeral class is defined for @samp{attr_@var{name}} with
+An enumerated class is defined for @samp{attr_@var{name}} with
elements of the form @samp{@var{upper-name}_@var{upper-value}} where
-the attribute name and value are first converted to upper case.
+the attribute name and value are first converted to uppercase.
@item
A function @samp{get_attr_@var{name}} is defined that is passed an insn and
defined and the function to obtain the attribute's value will return
@code{int}.
+There are attributes which are tied to a specific meaning. These
+attributes are not free to use for other purposes:
+
+@table @code
+@item length
+The @code{length} attribute is used to calculate the length of emitted
+code chunks. This is especially important when verifying branch
+distances. @xref{Insn Lengths}.
+
+@item enabled
+The @code{enabled} attribute can be defined to prevent certain
+alternatives of an insn definition from being used during code
+generation. @xref{Disable Insn Alternatives}.
+
+@end table
+
+@end ifset
+@ifset INTERNALS
@node Expressions
@subsection Attribute Expressions
@cindex attribute expressions
produce more efficient code for non-numeric attributes.
@end table
+@end ifset
+@ifset INTERNALS
@node Tagging Insns
@subsection Assigning Attribute Values to Insns
@cindex tagging insns
in a @code{define_asm_attributes} should be the maximum possible length
of a single machine instruction.
+@end ifset
+@ifset INTERNALS
@node Attr Example
@subsection Example of Attribute Specifications
@cindex attribute specifications example
code since they will set the condition code to a value corresponding to the
full-word result.
+@end ifset
+@ifset INTERNALS
@node Insn Lengths
@subsection Computing the Length of an Insn
@cindex insn lengths, computing
For many machines, multiple types of branch instructions are provided, each
for different length branch displacements. In most cases, the assembler
will choose the correct instruction to use. However, when the assembler
-cannot do so, GCC can when a special attribute, the @samp{length}
+cannot do so, GCC can when a special attribute, the @code{length}
attribute, is defined. This attribute must be defined to have numeric
values by specifying a null string in its @code{define_attr}.
-In the case of the @samp{length} attribute, two additional forms of
+In the case of the @code{length} attribute, two additional forms of
arithmetic terms are allowed in test expressions:
@table @code
@cindex @code{addr_vec}, length of
@cindex @code{addr_diff_vec}, length of
For normal insns, the length will be determined by value of the
-@samp{length} attribute. In the case of @code{addr_vec} and
+@code{length} attribute. In the case of @code{addr_vec} and
@code{addr_diff_vec} insn patterns, the length is computed as
the number of vectors multiplied by the size of each vector.
The following macros can be used to refine the length computation:
@table @code
-@findex FIRST_INSN_ADDRESS
-@item FIRST_INSN_ADDRESS
-When the @code{length} insn attribute is used, this macro specifies the
-value to be assigned to the address of the first insn in a function. If
-not specified, 0 is used.
-
@findex ADJUST_INSN_LENGTH
@item ADJUST_INSN_LENGTH (@var{insn}, @var{length})
If defined, modifies the length assigned to instruction @var{insn} as a
(const_int 6)))])
@end smallexample
+@end ifset
+@ifset INTERNALS
@node Constant Attributes
@subsection Constant Attributes
@cindex constant attributes
but may not use either the @code{match_operand} form or @code{eq_attr}
forms involving insn attributes.
+@end ifset
+@ifset INTERNALS
@node Delay Slots
@subsection Delay Slot Scheduling
@cindex delay slots, defining
@end smallexample
@c the above is *still* too long. --mew 4feb93
-@node Function Units
-@subsection Specifying Function Units
-@cindex function units, for scheduling
-
-On most RISC machines, there are instructions whose results are not
-available for a specific number of cycles. Common cases are instructions
-that load data from memory. On many machines, a pipeline stall will result
-if the data is referenced too soon after the load instruction.
-
-In addition, many newer microprocessors have multiple function units, usually
-one for integer and one for floating point, and often will incur pipeline
-stalls when a result that is needed is not yet ready.
-
-The descriptions in this section allow the specification of how much
-time must elapse between the execution of an instruction and the time
-when its result is used. It also allows specification of when the
-execution of an instruction will delay execution of similar instructions
-due to function unit conflicts.
-
-For the purposes of the specifications in this section, a machine is
-divided into @dfn{function units}, each of which execute a specific
-class of instructions in first-in-first-out order. Function units that
-accept one instruction each cycle and allow a result to be used in the
-succeeding instruction (usually via forwarding) need not be specified.
-Classic RISC microprocessors will normally have a single function unit,
-which we can call @samp{memory}. The newer ``superscalar'' processors
-will often have function units for floating point operations, usually at
-least a floating point adder and multiplier.
-
-@findex define_function_unit
-Each usage of a function units by a class of insns is specified with a
-@code{define_function_unit} expression, which looks like this:
+@end ifset
+@ifset INTERNALS
+@node Processor pipeline description
+@subsection Specifying processor pipeline description
+@cindex processor pipeline description
+@cindex processor functional units
+@cindex instruction latency time
+@cindex interlock delays
+@cindex data dependence delays
+@cindex reservation delays
+@cindex pipeline hazard recognizer
+@cindex automaton based pipeline description
+@cindex regular expressions
+@cindex deterministic finite state automaton
+@cindex automaton based scheduler
+@cindex RISC
+@cindex VLIW
+
+To achieve better performance, most modern processors
+(super-pipelined, superscalar @acronym{RISC}, and @acronym{VLIW}
+processors) have many @dfn{functional units} on which several
+instructions can be executed simultaneously. An instruction starts
+execution if its issue conditions are satisfied. If not, the
+instruction is stalled until its conditions are satisfied. Such
+@dfn{interlock (pipeline) delay} causes interruption of the fetching
+of successor instructions (or demands nop instructions, e.g.@: for some
+MIPS processors).
+
+There are two major kinds of interlock delays in modern processors.
+The first one is a data dependence delay determining @dfn{instruction
+latency time}. The instruction execution is not started until all
+source data have been evaluated by prior instructions (there are more
+complex cases when the instruction execution starts even when the data
+are not available but will be ready in given time after the
+instruction execution start). Taking the data dependence delays into
+account is simple. The data dependence (true, output, and
+anti-dependence) delay between two instructions is given by a
+constant. In most cases this approach is adequate. The second kind
+of interlock delays is a reservation delay. The reservation delay
+means that two instructions under execution will be in need of shared
+processors resources, i.e.@: buses, internal registers, and/or
+functional units, which are reserved for some time. Taking this kind
+of delay into account is complex especially for modern @acronym{RISC}
+processors.
+
+The task of exploiting more processor parallelism is solved by an
+instruction scheduler. For a better solution to this problem, the
+instruction scheduler has to have an adequate description of the
+processor parallelism (or @dfn{pipeline description}). GCC
+machine descriptions describe processor parallelism and functional
+unit reservations for groups of instructions with the aid of
+@dfn{regular expressions}.
+
+The GCC instruction scheduler uses a @dfn{pipeline hazard recognizer} to
+figure out the possibility of the instruction issue by the processor
+on a given simulated processor cycle. The pipeline hazard recognizer is
+automatically generated from the processor pipeline description. The
+pipeline hazard recognizer generated from the machine description
+is based on a deterministic finite state automaton (@acronym{DFA}):
+the instruction issue is possible if there is a transition from one
+automaton state to another one. This algorithm is very fast, and
+furthermore, its speed is not dependent on processor
+complexity@footnote{However, the size of the automaton depends on
+processor complexity. To limit this effect, machine descriptions
+can split orthogonal parts of the machine description among several
+automata: but then, since each of these must be stepped independently,
+this does cause a small decrease in the algorithm's performance.}.
+
+@cindex automaton based pipeline description
+The rest of this section describes the directives that constitute
+an automaton-based processor pipeline description. The order of
+these constructions within the machine description file is not
+important.
+
+@findex define_automaton
+@cindex pipeline hazard recognizer
+The following optional construction describes names of automata
+generated and used for the pipeline hazards recognition. Sometimes
+the generated finite state automaton used by the pipeline hazard
+recognizer is large. If we use more than one automaton and bind functional
+units to the automata, the total size of the automata is usually
+less than the size of the single automaton. If there is no one such
+construction, only one finite state automaton is generated.
+
+@smallexample
+(define_automaton @var{automata-names})
+@end smallexample
+
+@var{automata-names} is a string giving names of the automata. The
+names are separated by commas. All the automata should have unique names.
+The automaton name is used in the constructions @code{define_cpu_unit} and
+@code{define_query_cpu_unit}.
+
+@findex define_cpu_unit
+@cindex processor functional units
+Each processor functional unit used in the description of instruction
+reservations should be described by the following construction.
+
+@smallexample
+(define_cpu_unit @var{unit-names} [@var{automaton-name}])
+@end smallexample
+
+@var{unit-names} is a string giving the names of the functional units
+separated by commas. Don't use name @samp{nothing}, it is reserved
+for other goals.
+
+@var{automaton-name} is a string giving the name of the automaton with
+which the unit is bound. The automaton should be described in
+construction @code{define_automaton}. You should give
+@dfn{automaton-name}, if there is a defined automaton.
+
+The assignment of units to automata are constrained by the uses of the
+units in insn reservations. The most important constraint is: if a
+unit reservation is present on a particular cycle of an alternative
+for an insn reservation, then some unit from the same automaton must
+be present on the same cycle for the other alternatives of the insn
+reservation. The rest of the constraints are mentioned in the
+description of the subsequent constructions.
+
+@findex define_query_cpu_unit
+@cindex querying function unit reservations
+The following construction describes CPU functional units analogously
+to @code{define_cpu_unit}. The reservation of such units can be
+queried for an automaton state. The instruction scheduler never
+queries reservation of functional units for given automaton state. So
+as a rule, you don't need this construction. This construction could
+be used for future code generation goals (e.g.@: to generate
+@acronym{VLIW} insn templates).
+
+@smallexample
+(define_query_cpu_unit @var{unit-names} [@var{automaton-name}])
+@end smallexample
+
+@var{unit-names} is a string giving names of the functional units
+separated by commas.
+
+@var{automaton-name} is a string giving the name of the automaton with
+which the unit is bound.
+
+@findex define_insn_reservation
+@cindex instruction latency time
+@cindex regular expressions
+@cindex data bypass
+The following construction is the major one to describe pipeline
+characteristics of an instruction.
+
+@smallexample
+(define_insn_reservation @var{insn-name} @var{default_latency}
+ @var{condition} @var{regexp})
+@end smallexample
+
+@var{default_latency} is a number giving latency time of the
+instruction. There is an important difference between the old
+description and the automaton based pipeline description. The latency
+time is used for all dependencies when we use the old description. In
+the automaton based pipeline description, the given latency time is only
+used for true dependencies. The cost of anti-dependencies is always
+zero and the cost of output dependencies is the difference between
+latency times of the producing and consuming insns (if the difference
+is negative, the cost is considered to be zero). You can always
+change the default costs for any description by using the target hook
+@code{TARGET_SCHED_ADJUST_COST} (@pxref{Scheduling}).
+
+@var{insn-name} is a string giving the internal name of the insn. The
+internal names are used in constructions @code{define_bypass} and in
+the automaton description file generated for debugging. The internal
+name has nothing in common with the names in @code{define_insn}. It is a
+good practice to use insn classes described in the processor manual.
+
+@var{condition} defines what RTL insns are described by this
+construction. You should remember that you will be in trouble if
+@var{condition} for two or more different
+@code{define_insn_reservation} constructions is TRUE for an insn. In
+this case what reservation will be used for the insn is not defined.
+Such cases are not checked during generation of the pipeline hazards
+recognizer because in general recognizing that two conditions may have
+the same value is quite difficult (especially if the conditions
+contain @code{symbol_ref}). It is also not checked during the
+pipeline hazard recognizer work because it would slow down the
+recognizer considerably.
+
+@var{regexp} is a string describing the reservation of the cpu's functional
+units by the instruction. The reservations are described by a regular
+expression according to the following syntax:
+
+@smallexample
+ regexp = regexp "," oneof
+ | oneof
+
+ oneof = oneof "|" allof
+ | allof
+
+ allof = allof "+" repeat
+ | repeat
+
+ repeat = element "*" number
+ | element
+
+ element = cpu_function_unit_name
+ | reservation_name
+ | result_name
+ | "nothing"
+ | "(" regexp ")"
+@end smallexample
+
+@itemize @bullet
+@item
+@samp{,} is used for describing the start of the next cycle in
+the reservation.
+
+@item
+@samp{|} is used for describing a reservation described by the first
+regular expression @strong{or} a reservation described by the second
+regular expression @strong{or} etc.
+
+@item
+@samp{+} is used for describing a reservation described by the first
+regular expression @strong{and} a reservation described by the
+second regular expression @strong{and} etc.
+
+@item
+@samp{*} is used for convenience and simply means a sequence in which
+the regular expression are repeated @var{number} times with cycle
+advancing (see @samp{,}).
+
+@item
+@samp{cpu_function_unit_name} denotes reservation of the named
+functional unit.
+
+@item
+@samp{reservation_name} --- see description of construction
+@samp{define_reservation}.
+
+@item
+@samp{nothing} denotes no unit reservations.
+@end itemize
+
+@findex define_reservation
+Sometimes unit reservations for different insns contain common parts.
+In such case, you can simplify the pipeline description by describing
+the common part by the following construction
+
+@smallexample
+(define_reservation @var{reservation-name} @var{regexp})
+@end smallexample
+
+@var{reservation-name} is a string giving name of @var{regexp}.
+Functional unit names and reservation names are in the same name
+space. So the reservation names should be different from the
+functional unit names and can not be the reserved name @samp{nothing}.
+
+@findex define_bypass
+@cindex instruction latency time
+@cindex data bypass
+The following construction is used to describe exceptions in the
+latency time for given instruction pair. This is so called bypasses.
+
+@smallexample
+(define_bypass @var{number} @var{out_insn_names} @var{in_insn_names}
+ [@var{guard}])
+@end smallexample
+
+@var{number} defines when the result generated by the instructions
+given in string @var{out_insn_names} will be ready for the
+instructions given in string @var{in_insn_names}. The instructions in
+the string are separated by commas.
+
+@var{guard} is an optional string giving the name of a C function which
+defines an additional guard for the bypass. The function will get the
+two insns as parameters. If the function returns zero the bypass will
+be ignored for this case. The additional guard is necessary to
+recognize complicated bypasses, e.g.@: when the consumer is only an address
+of insn @samp{store} (not a stored value).
+
+@findex exclusion_set
+@findex presence_set
+@findex final_presence_set
+@findex absence_set
+@findex final_absence_set
+@cindex VLIW
+@cindex RISC
+The following five constructions are usually used to describe
+@acronym{VLIW} processors, or more precisely, to describe a placement
+of small instructions into @acronym{VLIW} instruction slots. They
+can be used for @acronym{RISC} processors, too.
+
+@smallexample
+(exclusion_set @var{unit-names} @var{unit-names})
+(presence_set @var{unit-names} @var{patterns})
+(final_presence_set @var{unit-names} @var{patterns})
+(absence_set @var{unit-names} @var{patterns})
+(final_absence_set @var{unit-names} @var{patterns})
+@end smallexample
+
+@var{unit-names} is a string giving names of functional units
+separated by commas.
+
+@var{patterns} is a string giving patterns of functional units
+separated by comma. Currently pattern is one unit or units
+separated by white-spaces.
+
+The first construction (@samp{exclusion_set}) means that each
+functional unit in the first string can not be reserved simultaneously
+with a unit whose name is in the second string and vice versa. For
+example, the construction is useful for describing processors
+(e.g.@: some SPARC processors) with a fully pipelined floating point
+functional unit which can execute simultaneously only single floating
+point insns or only double floating point insns.
+
+The second construction (@samp{presence_set}) means that each
+functional unit in the first string can not be reserved unless at
+least one of pattern of units whose names are in the second string is
+reserved. This is an asymmetric relation. For example, it is useful
+for description that @acronym{VLIW} @samp{slot1} is reserved after
+@samp{slot0} reservation. We could describe it by the following
+construction
+
+@smallexample
+(presence_set "slot1" "slot0")
+@end smallexample
+
+Or @samp{slot1} is reserved only after @samp{slot0} and unit @samp{b0}
+reservation. In this case we could write
+
+@smallexample
+(presence_set "slot1" "slot0 b0")
+@end smallexample
+
+The third construction (@samp{final_presence_set}) is analogous to
+@samp{presence_set}. The difference between them is when checking is
+done. When an instruction is issued in given automaton state
+reflecting all current and planned unit reservations, the automaton
+state is changed. The first state is a source state, the second one
+is a result state. Checking for @samp{presence_set} is done on the
+source state reservation, checking for @samp{final_presence_set} is
+done on the result reservation. This construction is useful to
+describe a reservation which is actually two subsequent reservations.
+For example, if we use
+
+@smallexample
+(presence_set "slot1" "slot0")
+@end smallexample
+
+the following insn will be never issued (because @samp{slot1} requires
+@samp{slot0} which is absent in the source state).
+
+@smallexample
+(define_reservation "insn_and_nop" "slot0 + slot1")
+@end smallexample
+
+but it can be issued if we use analogous @samp{final_presence_set}.
+
+The forth construction (@samp{absence_set}) means that each functional
+unit in the first string can be reserved only if each pattern of units
+whose names are in the second string is not reserved. This is an
+asymmetric relation (actually @samp{exclusion_set} is analogous to
+this one but it is symmetric). For example it might be useful in a
+@acronym{VLIW} description to say that @samp{slot0} cannot be reserved
+after either @samp{slot1} or @samp{slot2} have been reserved. This
+can be described as:
+
+@smallexample
+(absence_set "slot0" "slot1, slot2")
+@end smallexample
+
+Or @samp{slot2} can not be reserved if @samp{slot0} and unit @samp{b0}
+are reserved or @samp{slot1} and unit @samp{b1} are reserved. In
+this case we could write
+
+@smallexample
+(absence_set "slot2" "slot0 b0, slot1 b1")
+@end smallexample
+
+All functional units mentioned in a set should belong to the same
+automaton.
+
+The last construction (@samp{final_absence_set}) is analogous to
+@samp{absence_set} but checking is done on the result (state)
+reservation. See comments for @samp{final_presence_set}.
+
+@findex automata_option
+@cindex deterministic finite state automaton
+@cindex nondeterministic finite state automaton
+@cindex finite state automaton minimization
+You can control the generator of the pipeline hazard recognizer with
+the following construction.
+
+@smallexample
+(automata_option @var{options})
+@end smallexample
+
+@var{options} is a string giving options which affect the generated
+code. Currently there are the following options:
+
+@itemize @bullet
+@item
+@dfn{no-minimization} makes no minimization of the automaton. This is
+only worth to do when we are debugging the description and need to
+look more accurately at reservations of states.
+
+@item
+@dfn{time} means printing time statistics about the generation of
+automata.
+
+@item
+@dfn{stats} means printing statistics about the generated automata
+such as the number of DFA states, NDFA states and arcs.
+
+@item
+@dfn{v} means a generation of the file describing the result automata.
+The file has suffix @samp{.dfa} and can be used for the description
+verification and debugging.
+
+@item
+@dfn{w} means a generation of warning instead of error for
+non-critical errors.
+
+@item
+@dfn{ndfa} makes nondeterministic finite state automata. This affects
+the treatment of operator @samp{|} in the regular expressions. The
+usual treatment of the operator is to try the first alternative and,
+if the reservation is not possible, the second alternative. The
+nondeterministic treatment means trying all alternatives, some of them
+may be rejected by reservations in the subsequent insns.
+
+@item
+@dfn{progress} means output of a progress bar showing how many states
+were generated so far for automaton being processed. This is useful
+during debugging a @acronym{DFA} description. If you see too many
+generated states, you could interrupt the generator of the pipeline
+hazard recognizer and try to figure out a reason for generation of the
+huge automaton.
+@end itemize
+
+As an example, consider a superscalar @acronym{RISC} machine which can
+issue three insns (two integer insns and one floating point insn) on
+the cycle but can finish only two insns. To describe this, we define
+the following functional units.
+
+@smallexample
+(define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline")
+(define_cpu_unit "port0, port1")
+@end smallexample
+
+All simple integer insns can be executed in any integer pipeline and
+their result is ready in two cycles. The simple integer insns are
+issued into the first pipeline unless it is reserved, otherwise they
+are issued into the second pipeline. Integer division and
+multiplication insns can be executed only in the second integer
+pipeline and their results are ready correspondingly in 8 and 4
+cycles. The integer division is not pipelined, i.e.@: the subsequent
+integer division insn can not be issued until the current division
+insn finished. Floating point insns are fully pipelined and their
+results are ready in 3 cycles. Where the result of a floating point
+insn is used by an integer insn, an additional delay of one cycle is
+incurred. To describe all of this we could specify
@smallexample
-(define_function_unit @var{name} @var{multiplicity} @var{simultaneity}
- @var{test} @var{ready-delay} @var{issue-delay}
- [@var{conflict-list}])
+(define_cpu_unit "div")
+
+(define_insn_reservation "simple" 2 (eq_attr "type" "int")
+ "(i0_pipeline | i1_pipeline), (port0 | port1)")
+
+(define_insn_reservation "mult" 4 (eq_attr "type" "mult")
+ "i1_pipeline, nothing*2, (port0 | port1)")
+
+(define_insn_reservation "div" 8 (eq_attr "type" "div")
+ "i1_pipeline, div*7, div + (port0 | port1)")
+
+(define_insn_reservation "float" 3 (eq_attr "type" "float")
+ "f_pipeline, nothing, (port0 | port1))
+
+(define_bypass 4 "float" "simple,mult,div")
@end smallexample
-@var{name} is a string giving the name of the function unit.
-
-@var{multiplicity} is an integer specifying the number of identical
-units in the processor. If more than one unit is specified, they will
-be scheduled independently. Only truly independent units should be
-counted; a pipelined unit should be specified as a single unit. (The
-only common example of a machine that has multiple function units for a
-single instruction class that are truly independent and not pipelined
-are the two multiply and two increment units of the CDC 6600.)
-
-@var{simultaneity} specifies the maximum number of insns that can be
-executing in each instance of the function unit simultaneously or zero
-if the unit is pipelined and has no limit.
-
-All @code{define_function_unit} definitions referring to function unit
-@var{name} must have the same name and values for @var{multiplicity} and
-@var{simultaneity}.
-
-@var{test} is an attribute test that selects the insns we are describing
-in this definition. Note that an insn may use more than one function
-unit and a function unit may be specified in more than one
-@code{define_function_unit}.
-
-@var{ready-delay} is an integer that specifies the number of cycles
-after which the result of the instruction can be used without
-introducing any stalls.
-
-@var{issue-delay} is an integer that specifies the number of cycles
-after the instruction matching the @var{test} expression begins using
-this unit until a subsequent instruction can begin. A cost of @var{N}
-indicates an @var{N-1} cycle delay. A subsequent instruction may also
-be delayed if an earlier instruction has a longer @var{ready-delay}
-value. This blocking effect is computed using the @var{simultaneity},
-@var{ready-delay}, @var{issue-delay}, and @var{conflict-list} terms.
-For a normal non-pipelined function unit, @var{simultaneity} is one, the
-unit is taken to block for the @var{ready-delay} cycles of the executing
-insn, and smaller values of @var{issue-delay} are ignored.
-
-@var{conflict-list} is an optional list giving detailed conflict costs
-for this unit. If specified, it is a list of condition test expressions
-to be applied to insns chosen to execute in @var{name} following the
-particular insn matching @var{test} that is already executing in
-@var{name}. For each insn in the list, @var{issue-delay} specifies the
-conflict cost; for insns not in the list, the cost is zero. If not
-specified, @var{conflict-list} defaults to all instructions that use the
-function unit.
-
-Typical uses of this vector are where a floating point function unit can
-pipeline either single- or double-precision operations, but not both, or
-where a memory unit can pipeline loads, but not stores, etc.
-
-As an example, consider a classic RISC machine where the result of a
-load instruction is not available for two cycles (a single ``delay''
-instruction is required) and where only one load instruction can be executed
-simultaneously. This would be specified as:
+To simplify the description we could describe the following reservation
@smallexample
-(define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 0)
+(define_reservation "finish" "port0|port1")
@end smallexample
-For the case of a floating point function unit that can pipeline either
-single or double precision, but not both, the following could be specified:
+and use it in all @code{define_insn_reservation} as in the following
+construction
@smallexample
-(define_function_unit
- "fp" 1 0 (eq_attr "type" "sp_fp") 4 4 [(eq_attr "type" "dp_fp")])
-(define_function_unit
- "fp" 1 0 (eq_attr "type" "dp_fp") 4 4 [(eq_attr "type" "sp_fp")])
+(define_insn_reservation "simple" 2 (eq_attr "type" "int")
+ "(i0_pipeline | i1_pipeline), finish")
@end smallexample
-@strong{Note:} The scheduler attempts to avoid function unit conflicts
-and uses all the specifications in the @code{define_function_unit}
-expression. It has recently come to our attention that these
-specifications may not allow modeling of some of the newer
-``superscalar'' processors that have insns using multiple pipelined
-units. These insns will cause a potential conflict for the second unit
-used during their execution and there is no way of representing that
-conflict. We welcome any examples of how function unit conflicts work
-in such processors and suggestions for their representation.
+@end ifset
+@ifset INTERNALS
@node Conditional Execution
@section Conditional Execution
@cindex conditional execution
"(%3) add %2,%1,%0")
@end smallexample
+@end ifset
+@ifset INTERNALS
@node Constant Definitions
@section Constant Definitions
@cindex constant definitions
The constants that are defined with a define_constant are also output
in the insn-codes.h header file as #defines.
@end ifset
+@ifset INTERNALS
+@node Iterators
+@section Iterators
+@cindex iterators in @file{.md} files
+
+Ports often need to define similar patterns for more than one machine
+mode or for more than one rtx code. GCC provides some simple iterator
+facilities to make this process easier.
+
+@menu
+* Mode Iterators:: Generating variations of patterns for different modes.
+* Code Iterators:: Doing the same for codes.
+@end menu
+
+@node Mode Iterators
+@subsection Mode Iterators
+@cindex mode iterators in @file{.md} files
+
+Ports often need to define similar patterns for two or more different modes.
+For example:
+
+@itemize @bullet
+@item
+If a processor has hardware support for both single and double
+floating-point arithmetic, the @code{SFmode} patterns tend to be
+very similar to the @code{DFmode} ones.
+
+@item
+If a port uses @code{SImode} pointers in one configuration and
+@code{DImode} pointers in another, it will usually have very similar
+@code{SImode} and @code{DImode} patterns for manipulating pointers.
+@end itemize
+
+Mode iterators allow several patterns to be instantiated from one
+@file{.md} file template. They can be used with any type of
+rtx-based construct, such as a @code{define_insn},
+@code{define_split}, or @code{define_peephole2}.
+
+@menu
+* Defining Mode Iterators:: Defining a new mode iterator.
+* Substitutions:: Combining mode iterators with substitutions
+* Examples:: Examples
+@end menu
+
+@node Defining Mode Iterators
+@subsubsection Defining Mode Iterators
+@findex define_mode_iterator
+
+The syntax for defining a mode iterator is:
+
+@smallexample
+(define_mode_iterator @var{name} [(@var{mode1} "@var{cond1}") @dots{} (@var{moden} "@var{condn}")])
+@end smallexample
+
+This allows subsequent @file{.md} file constructs to use the mode suffix
+@code{:@var{name}}. Every construct that does so will be expanded
+@var{n} times, once with every use of @code{:@var{name}} replaced by
+@code{:@var{mode1}}, once with every use replaced by @code{:@var{mode2}},
+and so on. In the expansion for a particular @var{modei}, every
+C condition will also require that @var{condi} be true.
+
+For example:
+
+@smallexample
+(define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
+@end smallexample
+
+defines a new mode suffix @code{:P}. Every construct that uses
+@code{:P} will be expanded twice, once with every @code{:P} replaced
+by @code{:SI} and once with every @code{:P} replaced by @code{:DI}.
+The @code{:SI} version will only apply if @code{Pmode == SImode} and
+the @code{:DI} version will only apply if @code{Pmode == DImode}.
+
+As with other @file{.md} conditions, an empty string is treated
+as ``always true''. @code{(@var{mode} "")} can also be abbreviated
+to @code{@var{mode}}. For example:
+
+@smallexample
+(define_mode_iterator GPR [SI (DI "TARGET_64BIT")])
+@end smallexample
+
+means that the @code{:DI} expansion only applies if @code{TARGET_64BIT}
+but that the @code{:SI} expansion has no such constraint.
+
+Iterators are applied in the order they are defined. This can be
+significant if two iterators are used in a construct that requires
+substitutions. @xref{Substitutions}.
+
+@node Substitutions
+@subsubsection Substitution in Mode Iterators
+@findex define_mode_attr
+
+If an @file{.md} file construct uses mode iterators, each version of the
+construct will often need slightly different strings or modes. For
+example:
+
+@itemize @bullet
+@item
+When a @code{define_expand} defines several @code{add@var{m}3} patterns
+(@pxref{Standard Names}), each expander will need to use the
+appropriate mode name for @var{m}.
+
+@item
+When a @code{define_insn} defines several instruction patterns,
+each instruction will often use a different assembler mnemonic.
+
+@item
+When a @code{define_insn} requires operands with different modes,
+using an iterator for one of the operand modes usually requires a specific
+mode for the other operand(s).
+@end itemize
+
+GCC supports such variations through a system of ``mode attributes''.
+There are two standard attributes: @code{mode}, which is the name of
+the mode in lower case, and @code{MODE}, which is the same thing in
+upper case. You can define other attributes using:
+
+@smallexample
+(define_mode_attr @var{name} [(@var{mode1} "@var{value1}") @dots{} (@var{moden} "@var{valuen}")])
+@end smallexample
+
+where @var{name} is the name of the attribute and @var{valuei}
+is the value associated with @var{modei}.
+
+When GCC replaces some @var{:iterator} with @var{:mode}, it will scan
+each string and mode in the pattern for sequences of the form
+@code{<@var{iterator}:@var{attr}>}, where @var{attr} is the name of a
+mode attribute. If the attribute is defined for @var{mode}, the whole
+@code{<@dots{}>} sequence will be replaced by the appropriate attribute
+value.
+
+For example, suppose an @file{.md} file has:
+
+@smallexample
+(define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
+(define_mode_attr load [(SI "lw") (DI "ld")])
+@end smallexample
+
+If one of the patterns that uses @code{:P} contains the string
+@code{"<P:load>\t%0,%1"}, the @code{SI} version of that pattern
+will use @code{"lw\t%0,%1"} and the @code{DI} version will use
+@code{"ld\t%0,%1"}.
+
+Here is an example of using an attribute for a mode:
+
+@smallexample
+(define_mode_iterator LONG [SI DI])
+(define_mode_attr SHORT [(SI "HI") (DI "SI")])
+(define_insn @dots{}
+ (sign_extend:LONG (match_operand:<LONG:SHORT> @dots{})) @dots{})
+@end smallexample
+
+The @code{@var{iterator}:} prefix may be omitted, in which case the
+substitution will be attempted for every iterator expansion.
+
+@node Examples
+@subsubsection Mode Iterator Examples
+
+Here is an example from the MIPS port. It defines the following
+modes and attributes (among others):
+
+@smallexample
+(define_mode_iterator GPR [SI (DI "TARGET_64BIT")])
+(define_mode_attr d [(SI "") (DI "d")])
+@end smallexample
+
+and uses the following template to define both @code{subsi3}
+and @code{subdi3}:
+
+@smallexample
+(define_insn "sub<mode>3"
+ [(set (match_operand:GPR 0 "register_operand" "=d")
+ (minus:GPR (match_operand:GPR 1 "register_operand" "d")
+ (match_operand:GPR 2 "register_operand" "d")))]
+ ""
+ "<d>subu\t%0,%1,%2"
+ [(set_attr "type" "arith")
+ (set_attr "mode" "<MODE>")])
+@end smallexample
+
+This is exactly equivalent to:
+
+@smallexample
+(define_insn "subsi3"
+ [(set (match_operand:SI 0 "register_operand" "=d")
+ (minus:SI (match_operand:SI 1 "register_operand" "d")
+ (match_operand:SI 2 "register_operand" "d")))]
+ ""
+ "subu\t%0,%1,%2"
+ [(set_attr "type" "arith")
+ (set_attr "mode" "SI")])
+
+(define_insn "subdi3"
+ [(set (match_operand:DI 0 "register_operand" "=d")
+ (minus:DI (match_operand:DI 1 "register_operand" "d")
+ (match_operand:DI 2 "register_operand" "d")))]
+ ""
+ "dsubu\t%0,%1,%2"
+ [(set_attr "type" "arith")
+ (set_attr "mode" "DI")])
+@end smallexample
+
+@node Code Iterators
+@subsection Code Iterators
+@cindex code iterators in @file{.md} files
+@findex define_code_iterator
+@findex define_code_attr
+
+Code iterators operate in a similar way to mode iterators. @xref{Mode Iterators}.
+
+The construct:
+
+@smallexample
+(define_code_iterator @var{name} [(@var{code1} "@var{cond1}") @dots{} (@var{coden} "@var{condn}")])
+@end smallexample
+
+defines a pseudo rtx code @var{name} that can be instantiated as
+@var{codei} if condition @var{condi} is true. Each @var{codei}
+must have the same rtx format. @xref{RTL Classes}.
+
+As with mode iterators, each pattern that uses @var{name} will be
+expanded @var{n} times, once with all uses of @var{name} replaced by
+@var{code1}, once with all uses replaced by @var{code2}, and so on.
+@xref{Defining Mode Iterators}.
+
+It is possible to define attributes for codes as well as for modes.
+There are two standard code attributes: @code{code}, the name of the
+code in lower case, and @code{CODE}, the name of the code in upper case.
+Other attributes are defined using:
+
+@smallexample
+(define_code_attr @var{name} [(@var{code1} "@var{value1}") @dots{} (@var{coden} "@var{valuen}")])
+@end smallexample
+
+Here's an example of code iterators in action, taken from the MIPS port:
+
+@smallexample
+(define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt
+ eq ne gt ge lt le gtu geu ltu leu])
+
+(define_expand "b<code>"
+ [(set (pc)
+ (if_then_else (any_cond:CC (cc0)
+ (const_int 0))
+ (label_ref (match_operand 0 ""))
+ (pc)))]
+ ""
+@{
+ gen_conditional_branch (operands, <CODE>);
+ DONE;
+@})
+@end smallexample
+
+This is equivalent to:
+
+@smallexample
+(define_expand "bunordered"
+ [(set (pc)
+ (if_then_else (unordered:CC (cc0)
+ (const_int 0))
+ (label_ref (match_operand 0 ""))
+ (pc)))]
+ ""
+@{
+ gen_conditional_branch (operands, UNORDERED);
+ DONE;
+@})
+
+(define_expand "bordered"
+ [(set (pc)
+ (if_then_else (ordered:CC (cc0)
+ (const_int 0))
+ (label_ref (match_operand 0 ""))
+ (pc)))]
+ ""
+@{
+ gen_conditional_branch (operands, ORDERED);
+ DONE;
+@})
+
+@dots{}
+@end smallexample
+
+@end ifset
projects / msp430-gcc.git / blobdiff