@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1996, 1998, 1999, 2000, 2001,
-@c 2002, 2003 Free Software Foundation, Inc.
+@c 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
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.
+* 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.
predication.
* Constant Definitions::Defining symbolic constants that can be used in the
md file.
+* Macros:: Using macros 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 has one operand, a string constant containing a
+comma-separated list of RTX code names (in lower case). It evaluates
+to true if @var{op} has any of the listed codes.
+
+@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.
+@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
@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}
@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.
+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.
@cindex @samp{#} in constraint
@item #
@table @code
@item REG_CLASS_FROM_LETTER
-Register class constraints (usually lower case).
+Register class constraints (usually lowercase).
@item CONST_OK_FOR_LETTER_P
Immediate constant constraints, for non-floating point constants of
-word size or smaller precision (usually upper case).
+word size or smaller precision (usually uppercase).
@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).
+constants of greater than word size precision (usually uppercase).
@item EXTRA_CONSTRAINT
Special cases of registers or memory. This macro is not required, and
@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
A symbol in the text segment of the current file
@end table
+@item Uv
+A memory reference suitable for VFP load/store insns (reg+constant offset)
+
+@item Uy
+A memory reference suitable for iWMMXt load/store instructions.
+
+@item Uq
+A memory reference suitable for the ARMv4 ldrsb instruction.
+
@item AVR family---@file{avr.h}
@table @code
@item l
A floating point constant 0.0
@end table
-@item IBM RS6000---@file{rs6000.h}
+@item PowerPC and IBM RS6000---@file{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
@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)
+For x86-64 it is equivalent to @samp{r} class (for 8-bit instructions that
+do not use upper halves).
@item Q
-@samp{a}, @code{b}, @code{c}, or @code{d} register. (for 8-bit instructions,
-that do use upper halves)
+@samp{a}, @code{b}, @code{c}, or @code{d} register (for 8-bit instructions,
+that do use upper halves).
@item R
Legacy register---equivalent to @code{r} class in i386 mode.
Standard 80387 floating point constant
@end table
-@item Intel 960---@file{i960.h}
-@table @code
-@item f
-Floating point register (@code{fp0} to @code{fp3})
-
-@item l
-Local register (@code{r0} to @code{r15})
-
-@item b
-Global register (@code{g0} to @code{g15})
-
-@item d
-Any local or global register
-
-@item I
-Integers from 0 to 31
-
-@item J
-0
-
-@item K
-Integers from @minus{}31 to 0
-
-@item G
-Floating point 0
-
-@item H
-Floating point 1
-@end table
-
@item Intel IA-64---@file{ia64.h}
@table @code
@item a
The constant zero
@item P
-0 or -1 for @code{dep} instruction
+0 or @minus{}1 for @code{dep} instruction
@item Q
Non-volatile memory for floating-point loads and stores
@end table
+@item Blackfin family---@file{bfin.h}
+@table @code
+@item a
+P register
+
+@item d
+D register
+
+@item z
+A call clobbered P register.
+
+@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 B
+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 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 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
+
+@item Q
+Any SYMBOL_REF.
+@end table
+
@item IP2K---@file{ip2k.h}
@table @code
@item a
Non-SP registers (everything except @samp{SP})
@item R
-Indirect thru @samp{IP} - Avoid this except for @code{QImode}, since we
+Indirect through @samp{IP}---Avoid this except for @code{QImode}, since we
can't access extra bytes
@item S
-Indirect thru @samp{SP} or @samp{DP} with short displacement (0..127)
+Indirect through @samp{SP} or @samp{DP} with short displacement (0..127)
@item T
Data-section immediate value
@item Motorola 68HC11 & 68HC12 families---@file{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
lower floating-point register on the SPARC-V9 architecture.
@item e
-Floating-point register. It is equivalent to @samp{f} on the
+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.
Floating-point condition code register.
@item d
-Lower floating-point register. It is only valid on the SPARC-V9
+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
+Floating-point register. It is only valid on the SPARC-V9 architecture
when the Visual Instruction Set is available.
@item h
Even register
@item W
-Memory address for @samp{e} constraint registers.
+Memory address for @samp{e} constraint registers
+
+@item Y
+Vector zero
@end table
@item a
Address register (general purpose register except r0)
+@item c
+Condition code register
+
@item d
Data register (arbitrary general purpose register)
Signed 16-bit constant (@minus{}32768--32767)
@item L
-Unsigned 16-bit constant (0--65535)
+Value appropriate as displacement.
+@table @code
+ @item (0..4095)
+ for short displacement
+ @item (-524288..524287)
+ for long displacement
+@end table
+
+@item M
+Constant integer with a value of 0x7fffffff.
+
+@item N
+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 it's other parts.
@item Q
-Memory reference without index register
+Memory reference without index register and with short displacement.
+
+@item R
+Memory reference with index register and short displacement.
@item S
-Symbolic constant suitable for use with the @code{larl} instruction
+Memory reference without index register but with long displacement.
+
+@item T
+Memory reference with index register and long displacement.
+
+@item U
+Pointer with short displacement.
+
+@item W
+Pointer with long displacement.
+
+@item Y
+Shift count operand.
@end table
@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.
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.
consecutive memory locations, operand 1 is the first register, and
operand 2 is a constant: the number of consecutive registers.
+@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_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}} instruction pattern
@item @samp{push@var{m}}
Output a push instruction. Operand 0 is value to push. Used only when
@cindex @code{udiv@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}
+@itemx @samp{div@var{m}3}, @samp{udiv@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{mulhisi3} instruction pattern
@item @samp{mulhisi3}
@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}
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}.
@cindex @code{ashr@var{m}3} instruction pattern
@cindex @code{lshr@var{m}3} instruction pattern
@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
+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.
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
+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.
+@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{clrmem@var{m}} instruction pattern
+@item @samp{clrmem@var{m}}
+Block clear 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 clear is the second operand, in mode @var{m}. See
+@samp{movmem@var{m}} for a discussion of the choice of mode.
The third operand is the known alignment of the destination, in the form
of a @code{const_int} rtx. Thus, if the compiler knows that the
destination is word-aligned, it may provide the value 4 for this
operand.
-The use for multiple @code{clrstr@var{m}} is as for @code{movstr@var{m}}.
+The use for multiple @code{clrmem@var{m}} is as for @code{movmem@var{m}}.
@cindex @code{cmpstr@var{m}} instruction pattern
@item @samp{cmpstr@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{movstr@var{m}}. The two memory blocks specified are compared
+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
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
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
the abnormal return path.
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
+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},
Targets that do not support write prefetches or locality hints can ignore
the values of operands 1 and 2.
+@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.
+
+The ``nand'' operation is @code{op0 & ~op1}.
+
+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.
+
@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
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
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
@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,
+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{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
+@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
(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;
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 location of the file,
-specifies the include file to be in @file{gcc/config/target/filestuff}. The
+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
* 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}.
+@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
+@end ifset
+@ifset INTERNALS
@node Processor pipeline description
@subsection Specifying processor pipeline description
@cindex processor pipeline description
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
+of successor instructions (or demands nop instructions, e.g.@: for some
MIPS processors).
There are two major kinds of interlock delays in modern processors.
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
+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}). Currently GCC
-provides two alternative ways to describe processor parallelism,
-both described below. The first method is outlined in the next section;
-it was once the only method provided by GCC, and thus is used in a number
-of exiting ports. The second, and preferred method, specifies functional
-unit reservations for groups of instructions with the aid of @dfn{regular
-expressions}. This is called the @dfn{automaton based description}.
+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 automaton based
-description is more sophisticated and based on a deterministic finite
-state automaton (@acronym{DFA}) and therefore faster than one
-generated from the old description. Furthermore, its speed is not dependent
-on processor complexity. The instruction issue is possible if there is
-a transition from one automaton state to another one.
-
-You can use either model to describe processor pipeline
-characteristics or even mix them. You could use the old description
-for some processor submodels and the @acronym{DFA}-based one for other
-processor submodels.
-
-In general, using the automaton based description is preferred. Its
-model is richer and makes it possible to more accurately describe
-pipeline characteristics of processors, which results in improved
-code quality (although sometimes only marginally). It will also be
-used as an infrastructure to implement sophisticated and practical
-instruction scheduling which will try many instruction sequences to
-choose the best one.
-
-
-@menu
-* Old pipeline description:: Specifying information for insn scheduling.
-* Automaton pipeline description:: Describing insn pipeline characteristics.
-* Comparison of the two descriptions:: Drawbacks of the old pipeline description
-@end menu
-
-@node Old pipeline description
-@subsubsection Specifying Function Units
-@cindex old pipeline description
-@cindex function units, for scheduling
-
-On most @acronym{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 @acronym{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:
-
-@smallexample
-(define_function_unit @var{name} @var{multiplicity} @var{simultaneity}
- @var{test} @var{ready-delay} @var{issue-delay}
- [@var{conflict-list}])
-@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 @acronym{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:
+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.}.
-@smallexample
-(define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 0)
-@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:
-
-@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")])
-@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.
-
-@node Automaton pipeline description
-@subsubsection Describing instruction pipeline characteristics
@cindex automaton based pipeline description
-
-This section describes constructions of the automaton based processor
-pipeline description. The order of constructions within the machine
-description file is not important.
+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
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
+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.
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
+be used for future code generation goals (e.g.@: to generate
@acronym{VLIW} insn templates).
@smallexample
allof = allof "+" repeat
| repeat
-
+
repeat = element "*" number
| element
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
+recognize complicated bypasses, e.g.@: when the consumer is only an address
of insn @samp{store} (not a stored value).
@findex exclusion_set
separated by commas.
@var{patterns} is a string giving patterns of functional units
-separated by comma. Currently pattern is is one unit or 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
+(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.
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. You can not
-query functional unit reservations in nondeterministic automaton
-states.
+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
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
+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
@end smallexample
-@node Comparison of the two descriptions
-@subsubsection Drawbacks of the old pipeline description
-@cindex old pipeline description
-@cindex automaton based pipeline description
-@cindex processor functional units
-@cindex interlock delays
-@cindex instruction latency time
-@cindex pipeline hazard recognizer
-@cindex data bypass
-
-The old instruction level parallelism description and the pipeline
-hazards recognizer based on it have the following drawbacks in
-comparison with the @acronym{DFA}-based ones:
-
-@itemize @bullet
-@item
-Each functional unit is believed to be reserved at the instruction
-execution start. This is a very inaccurate model for modern
-processors.
-
-@item
-An inadequate description of instruction latency times. The latency
-time is bound with a functional unit reserved by an instruction not
-with the instruction itself. In other words, the description is
-oriented to describe at most one unit reservation by each instruction.
-It also does not permit to describe special bypasses between
-instruction pairs.
-
-@item
-The implementation of the pipeline hazard recognizer interface has
-constraints on number of functional units. This is a number of bits
-in integer on the host machine.
-
-@item
-The interface to the pipeline hazard recognizer is more complex than
-one to the automaton based pipeline recognizer.
-
-@item
-An unnatural description when you write a unit and a condition which
-selects instructions using the unit. Writing all unit reservations
-for an instruction (an instruction class) is more natural.
-
-@item
-The recognition of the interlock delays has a slow implementation. The GCC
-scheduler supports structures which describe the unit reservations.
-The more functional units a processor has, the slower its pipeline hazard
-recognizer will be. Such an implementation would become even slower when we
-allowed to
-reserve functional units not only at the instruction execution start.
-In an automaton based pipeline hazard recognizer, speed is not dependent
-on processor complexity.
-@end itemize
-
+@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 Macros
+@section Macros
+@cindex macros 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 macro
+facilities to make this process easier.
+
+@menu
+* Mode Macros:: Generating variations of patterns for different modes.
+* Code Macros:: Doing the same for codes.
+@end menu
+
+@node Mode Macros
+@subsection Mode Macros
+@cindex mode macros 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 macros 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 Macros:: Defining a new mode macro.
+* String Substitutions:: Combining mode macros with string substitutions
+* Examples:: Examples
+@end menu
+
+@node Defining Mode Macros
+@subsubsection Defining Mode Macros
+@findex define_mode_macro
+
+The syntax for defining a mode macro is:
+
+@smallexample
+(define_mode_macro @var{name} [(@var{mode1} "@var{cond1}") ... (@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_macro 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_macro 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.
+
+Macros are applied in the order they are defined. This can be
+significant if two macros are used in a construct that requires
+string substitutions. @xref{String Substitutions}.
+
+@node String Substitutions
+@subsubsection String Substitution in Mode Macros
+@findex define_mode_attr
+
+If an @file{.md} file construct uses mode macros, each version of the
+construct will often need slightly different strings. 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.
+@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}") ... (@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{:macro} with @var{:mode}, it will
+scan each string in the pattern for sequences of the form
+@code{<@var{macro}:@var{attr}>}, where @var{attr} is the name of
+a mode attribute. If the attribute is defined for @var{mode}, the
+whole @code{<...>} sequence will be replaced by the appropriate
+attribute value.
+
+For example, suppose an @file{.md} file has:
+
+@smallexample
+(define_mode_macro 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"}.
+
+The @code{@var{macro}:} prefix may be omitted, in which case the
+substitution will be attempted for every macro expansion.
+
+@node Examples
+@subsubsection Mode Macro Examples
+
+Here is an example from the MIPS port. It defines the following
+modes and attributes (among others):
+
+@smallexample
+(define_mode_macro 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 Macros
+@subsection Code Macros
+@cindex code macros in @file{.md} files
+@findex define_code_macro
+@findex define_code_attr
+
+Code macros operate in a similar way to mode macros. @xref{Mode Macros}.
+
+The construct:
+
+@smallexample
+(define_code_macro @var{name} [(@var{code1} "@var{cond1}") ... (@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 macros, 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 Macros}.
+
+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}") ... (@var{coden} "@var{valuen}")])
+@end smallexample
+
+Here's an example of code macros in action, taken from the MIPS port:
+
+@smallexample
+(define_code_macro 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;
+@})
+
+...
+@end smallexample
+
+@end ifset
OSDN Git Service
