@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1996, 1998, 1999, 2000, 2001,
-@c 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009
+@c 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
@c Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
instructs the compiler to first split the insn, and then output the
resulting instructions separately. This helps eliminate redundancy in the
output templates. If you have a @code{define_insn} that needs to emit
-multiple assembler instructions, and there is an matching @code{define_split}
+multiple assembler instructions, and there is a matching @code{define_split}
already defined, then you can simply use @code{#} as the output template
instead of writing an output template that emits the multiple assembler
instructions.
operand can be a memory reference, and which kinds of address; whether the
operand may be an immediate constant, and which possible values it may
have. Constraints can also require two operands to match.
+Side-effects aren't allowed in operands of inline @code{asm}, unless
+@samp{<} or @samp{>} constraints are used, because there is no guarantee
+that the side-effects will happen exactly once in an instruction that can update
+the addressing register.
@ifset INTERNALS
@menu
@cindex @samp{<} in constraint
@item @samp{<}
A memory operand with autodecrement addressing (either predecrement or
-postdecrement) is allowed.
+postdecrement) is allowed. In inline @code{asm} this constraint is only
+allowed if the operand is used exactly once in an instruction that can
+handle the side-effects. Not using an operand with @samp{<} in constraint
+string in the inline @code{asm} pattern at all or using it in multiple
+instructions isn't valid, because the side-effects wouldn't be performed
+or would be performed more than once. Furthermore, on some targets
+the operand with @samp{<} in constraint string must be accompanied by
+special instruction suffixes like @code{%U0} instruction suffix on PowerPC
+or @code{%P0} on IA-64.
@cindex @samp{>} in constraint
@item @samp{>}
A memory operand with autoincrement addressing (either preincrement or
-postincrement) is allowed.
+postincrement) is allowed. In inline @code{asm} the same restrictions
+as for @samp{<} apply.
@cindex @samp{r} in constraint
@cindex registers in constraints
A floating point constant 0.0
@item R
-Integer constant in the range -6 @dots{} 5.
+Integer constant in the range @minus{}6 @dots{} 5.
@item Q
A memory address based on Y or Z pointer with displacement.
Constant that fits in 5 bits
@item L
-Constant that is one of -1, 4, -4, 7, 8, 12, 16, 20, 32, 48
+Constant that is one of @minus{}1, 4, @minus{}4, 7, 8, 12, 16, 20, 32, 48
@item G
Floating point constant that is legal for store immediate
@item b
Address base register
+@item d
+Floating point register (containing 64-bit value)
+
@item f
-Floating point register
+Floating point register (containing 32-bit value)
@item v
-Vector register
+Altivec vector register
+
+@item wd
+VSX vector register to hold vector double data
+
+@item wf
+VSX vector register to hold vector float data
+
+@item ws
+VSX vector register to hold scalar float data
+
+@item wa
+Any VSX register
@item h
@samp{MQ}, @samp{CTR}, or @samp{LINK} register
@samp{CR} register (condition register)
@item z
-@samp{FPMEM} stack memory for FPR-GPR transfers
+@samp{XER[CA]} carry bit (part of the XER register)
@item I
Signed 16-bit constant
Integer/Floating point constant that can be loaded into a register using
three instructions
+@item m
+Memory operand.
+Normally, @code{m} does not allow addresses that update the base register.
+If @samp{<} or @samp{>} constraint is also used, they are allowed and
+therefore on PowerPC targets in that case it is only safe
+to use @samp{m<>} in an @code{asm} statement if that @code{asm} statement
+accesses the operand exactly once. The @code{asm} statement must also
+use @samp{%U@var{<opno>}} as a placeholder for the ``update'' flag in the
+corresponding load or store instruction. For example:
+
+@smallexample
+asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val));
+@end smallexample
+
+is correct but:
+
+@smallexample
+asm ("st %1,%0" : "=m<>" (mem) : "r" (val));
+@end smallexample
+
+is not.
+
+@item es
+A ``stable'' memory operand; that is, one which does not include any
+automodification of the base register. This used to be useful when
+@samp{m} allowed automodification of the base register, but as those are now only
+allowed when @samp{<} or @samp{>} is used, @samp{es} is basically the same
+as @samp{m} without @samp{<} and @samp{>}.
+
@item Q
-Memory operand that is an offset from a register (@samp{m} is preferable
-for @code{asm} statements)
+Memory operand that is an offset from a register (it is usually better
+to use @samp{m} or @samp{es} in @code{asm} statements)
@item Z
-Memory operand that is an indexed or indirect from a register (@samp{m} is
-preferable for @code{asm} statements)
+Memory operand that is an indexed or indirect from a register (it is
+usually better to use @samp{m} or @samp{es} in @code{asm} statements)
@item R
AIX TOC entry
@item W
Vector constant that does not require memory
+@item j
+Vector constant that is all zeros.
+
@end table
@item Intel 386---@file{config/i386/constraints.md}
The @code{di} 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).
+The @code{a} and @code{d} registers. This class is used for instructions
+that return double word results in the @code{ax:dx} register pair. Single
+word values will be allocated either in @code{ax} or @code{dx}.
+For example on i386 the following implements @code{rdtsc}:
+
+@smallexample
+unsigned long long rdtsc (void)
+@{
+ unsigned long long tick;
+ __asm__ __volatile__("rdtsc":"=A"(tick));
+ return tick;
+@}
+@end smallexample
+
+This is not correct on x86_64 as it would allocate tick in either @code{ax}
+or @code{dx}. You have to use the following variant instead:
+
+@smallexample
+unsigned long long rdtsc (void)
+@{
+ unsigned int tickl, tickh;
+ __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh));
+ return ((unsigned long long)tickh << 32)|tickl;
+@}
+@end smallexample
+
@item f
Any 80387 floating-point (stack) register.
Floating-point register
@item m
-Memory operand.
-Remember that @samp{m} allows postincrement and postdecrement which
+Memory operand. If used together with @samp{<} or @samp{>},
+the operand can have postincrement and postdecrement which
require printing with @samp{%Pn} on IA-64.
-Use @samp{S} to disallow postincrement and postdecrement.
@item G
Floating-point constant 0.0 or 1.0
Integer constant in the range 1 to 4 for @code{shladd} instruction
@item S
-Memory operand except postincrement and postdecrement
+Memory operand except postincrement and postdecrement. This is
+now roughly the same as @samp{m} when not used together with @samp{<}
+or @samp{>}.
@end table
@item FRV---@file{config/frv/frv.h}
Any register except accumulators or CC.
@item Ksh
-Signed 16 bit integer (in the range -32768 to 32767)
+Signed 16 bit integer (in the range @minus{}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)
+Signed 7 bit integer (in the range @minus{}64 to 63)
@item Ku7
Unsigned 7 bit integer (in the range 0 to 127)
Unsigned 5 bit integer (in the range 0 to 31)
@item Ks4
-Signed 4 bit integer (in the range -8 to 7)
+Signed 4 bit integer (in the range @minus{}8 to 7)
@item Ks3
-Signed 3 bit integer (in the range -3 to 4)
+Signed 3 bit integer (in the range @minus{}3 to 4)
@item Ku3
Unsigned 3 bit integer (in the range 0 to 7)
Used to match function return values.
@item Is3
--8 @dots{} 7
+@minus{}8 @dots{} 7
@item IS1
--128 @dots{} 127
+@minus{}128 @dots{} 127
@item IS2
--32768 @dots{} 32767
+@minus{}32768 @dots{} 32767
@item IU2
0 @dots{} 65535
@item In4
--8 @dots{} -1 or 1 @dots{} 8
+@minus{}8 @dots{} @minus{}1 or 1 @dots{} 8
@item In5
--16 @dots{} -1 or 1 @dots{} 16
+@minus{}16 @dots{} @minus{}1 or 1 @dots{} 16
@item In6
--32 @dots{} -1 or 1 @dots{} 32
+@minus{}32 @dots{} @minus{}1 or 1 @dots{} 32
@item IM2
--65536 @dots{} -1
+@minus{}65536 @dots{} @minus{}1
@item Ilb
An 8 bit value with exactly one bit set.
$r1h
@end table
+@item MeP---@file{config/mep/constraints.md}
+@table @code
+
+@item a
+The $sp register.
+
+@item b
+The $tp register.
+
+@item c
+Any control register.
+
+@item d
+Either the $hi or the $lo register.
+
+@item em
+Coprocessor registers that can be directly loaded ($c0-$c15).
+
+@item ex
+Coprocessor registers that can be moved to each other.
+
+@item er
+Coprocessor registers that can be moved to core registers.
+
+@item h
+The $hi register.
+
+@item j
+The $rpc register.
+
+@item l
+The $lo register.
+
+@item t
+Registers which can be used in $tp-relative addressing.
+
+@item v
+The $gp register.
+
+@item x
+The coprocessor registers.
+
+@item y
+The coprocessor control registers.
+
+@item z
+The $0 register.
+
+@item A
+User-defined register set A.
+
+@item B
+User-defined register set B.
+
+@item C
+User-defined register set C.
+
+@item D
+User-defined register set D.
+
+@item I
+Offsets for $gp-rel addressing.
+
+@item J
+Constants that can be used directly with boolean insns.
+
+@item K
+Constants that can be moved directly to registers.
+
+@item L
+Small constants that can be added to registers.
+
+@item M
+Long shift counts.
+
+@item N
+Small constants that can be compared to registers.
+
+@item O
+Constants that can be loaded into the top half of registers.
+
+@item S
+Signed 8-bit immediates.
+
+@item T
+Symbols encoded for $tp-rel or $gp-rel addressing.
+
+@item U
+Non-constant addresses for loading/saving coprocessor registers.
+
+@item W
+The top half of a symbol's value.
+
+@item Y
+A register indirect address without offset.
+
+@item Z
+Symbolic references to the control bus.
+
+@end table
+
+@item MicroBlaze---@file{config/microblaze/constraints.md}
+@table @code
+@item d
+A general register (@code{r0} to @code{r31}).
+
+@item z
+A status register (@code{rmsr}, @code{$fcc1} to @code{$fcc7}).
+
+@end table
+
@item MIPS---@file{config/mips/constraints.md}
@table @code
@item d
or @code{ori}.
@item N
-A constant in the range -65535 to -1 (inclusive).
+A constant in the range @minus{}65535 to @minus{}1 (inclusive).
@item O
A signed 15-bit constant.
@end table
+@item Moxie---@file{config/moxie/constraints.md}
+@table @code
+@item A
+An absolute address
+
+@item B
+An offset address
+
+@item W
+A register indirect memory operand
+
+@item I
+A constant in the range of 0 to 255.
+
+@item N
+A constant in the range of 0 to @minus{}255.
+
+@end table
+
+@item PDP-11---@file{config/pdp11/constraints.md}
+@table @code
+@item a
+Floating point registers AC0 through AC3. These can be loaded from/to
+memory with a single instruction.
+
+@item d
+Odd numbered general registers (R1, R3, R5). These are used for
+16-bit multiply operations.
+
+@item f
+Any of the floating point registers (AC0 through AC5).
+
+@item G
+Floating point constant 0.
+
+@item I
+An integer constant that fits in 16 bits.
+
+@item J
+An integer constant whose low order 16 bits are zero.
+
+@item K
+An integer constant that does not meet the constraints for codes
+@samp{I} or @samp{J}.
+
+@item L
+The integer constant 1.
+
+@item M
+The integer constant @minus{}1.
+
+@item N
+The integer constant 0.
+
+@item O
+Integer constants @minus{}4 through @minus{}1 and 1 through 4; shifts by these
+amounts are handled as multiple single-bit shifts rather than a single
+variable-length shift.
+
+@item Q
+A memory reference which requires an additional word (address or
+offset) after the opcode.
+
+@item R
+A memory reference that is encoded within the opcode.
+
+@end table
+
+@item RX---@file{config/rx/constraints.md}
+@table @code
+@item Q
+An address which does not involve register indirect addressing or
+pre/post increment/decrement addressing.
+
+@item Symbol
+A symbol reference.
+
+@item Int08
+A constant in the range @minus{}256 to 255, inclusive.
+
+@item Sint08
+A constant in the range @minus{}128 to 127, inclusive.
+
+@item Sint16
+A constant in the range @minus{}32768 to 32767, inclusive.
+
+@item Sint24
+A constant in the range @minus{}8388608 to 8388607, inclusive.
+
+@item Uint04
+A constant in the range 0 to 15, inclusive.
+
+@end table
+
@need 1000
@item SPARC---@file{config/sparc/sparc.h}
@table @code
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.
+A constant in the range [@minus{}64, 63] for shift/rotate instructions.
@item J
An unsigned 7-bit constant for conversion/nop/channel instructions.
@table @code
@item (0..4095)
for short displacement
-@item (-524288..524287)
+@item (@minus{}524288..524287)
for long displacement
@end table
@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 way an @samp{o} constraint can handle any memory operand.
The syntax and semantics are otherwise identical to
@code{define_constraint}.
The constraints on a @samp{mov@var{m}} must permit moving any hard
register to any other hard register provided that
@code{HARD_REGNO_MODE_OK} permits mode @var{m} in both registers and
-@code{REGISTER_MOVE_COST} applied to their classes returns a value of 2.
+@code{TARGET_REGISTER_MOVE_COST} applied to their classes returns a value
+of 2.
It is obligatory to support floating point @samp{mov@var{m}}
instructions into and out of any registers that can hold fixed point
@itemx @samp{and@var{m}3}, @samp{ior@var{m}3}, @samp{xor@var{m}3}
Similar, for other arithmetic operations.
+@cindex @code{fma@var{m}4} instruction pattern
+@item @samp{fma@var{m}4}
+Multiply operand 2 and operand 1, then add operand 3, storing the
+result in operand 0. All operands must have mode @var{m}. This
+pattern is used to implement the @code{fma}, @code{fmaf}, and
+@code{fmal} builtin functions from the ISO C99 standard. The
+@code{fma} operation may produce different results than doing the
+multiply followed by the add if the machine does not perform a
+rounding step between the operations.
+
+@cindex @code{fms@var{m}4} instruction pattern
+@item @samp{fms@var{m}4}
+Like @code{fma@var{m}4}, except operand 3 subtracted from the
+product instead of added to the product. This is represented
+in the rtl as
+
+@smallexample
+(fma:@var{m} @var{op1} @var{op2} (neg:@var{m} @var{op3}))
+@end smallexample
+
+@cindex @code{fnma@var{m}4} instruction pattern
+@item @samp{fnma@var{m}4}
+Like @code{fma@var{m}4} except that the intermediate product
+is negated before being added to operand 3. This is represented
+in the rtl as
+
+@smallexample
+(fma:@var{m} (neg:@var{m} @var{op1}) @var{op2} @var{op3})
+@end smallexample
+
+@cindex @code{fnms@var{m}4} instruction pattern
+@item @samp{fnms@var{m}4}
+Like @code{fms@var{m}4} except that the intermediate product
+is negated before subtracting operand 3. This is represented
+in the rtl as
+
+@smallexample
+(fma:@var{m} (neg:@var{m} @var{op1}) @var{op2} (neg:@var{m} @var{op3}))
+@end smallexample
+
@cindex @code{min@var{m}3} instruction pattern
@cindex @code{max@var{m}3} instruction pattern
@item @samp{smin@var{m}3}, @samp{smax@var{m}3}
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}
+@item @samp{lround@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 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}
+@item @samp{lfloor@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 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}
+@item @samp{lceil@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 rounding up and store in
operand 0 (which has mode @var{n}).
@item @samp{one_cmpl@var{m}2}
Store the bitwise-complement of operand 1 into operand 0.
-@cindex @code{cmp@var{m}} instruction pattern
-@item @samp{cmp@var{m}}
-Compare operand 0 and operand 1, and set the condition codes.
-The RTL pattern should look like this:
-
-@smallexample
-(set (cc0) (compare (match_operand:@var{m} 0 @dots{})
- (match_operand:@var{m} 1 @dots{})))
-@end smallexample
-
-@cindex @code{tst@var{m}} instruction pattern
-@item @samp{tst@var{m}}
-Compare operand 0 against zero, and set the condition codes.
-The RTL pattern should look like this:
-
-@smallexample
-(set (cc0) (match_operand:@var{m} 0 @dots{}))
-@end smallexample
-
-@samp{tst@var{m}} patterns should not be defined for machines that do
-not use @code{(cc0)}. Doing so would confuse the optimizer since it
-would no longer be clear which @code{set} operations were comparisons.
-The @samp{cmp@var{m}} patterns should be used instead.
-
@cindex @code{movmem@var{m}} instruction pattern
@item @samp{movmem@var{m}}
Block move instruction. The destination and source blocks of memory
and operand 3 is a constant describing the known alignment
of the beginning of the string.
-@cindex @code{float@var{mn}2} instruction pattern
+@cindex @code{float@var{m}@var{n}2} instruction pattern
@item @samp{float@var{m}@var{n}2}
Convert signed integer operand 1 (valid for fixed point mode @var{m}) to
floating point mode @var{n} and store in operand 0 (which has mode
@var{n}).
-@cindex @code{floatuns@var{mn}2} instruction pattern
+@cindex @code{floatuns@var{m}@var{n}2} instruction pattern
@item @samp{floatuns@var{m}@var{n}2}
Convert unsigned integer operand 1 (valid for fixed point mode @var{m})
to floating point mode @var{n} and store in operand 0 (which has mode
@var{n}).
-@cindex @code{fix@var{mn}2} instruction pattern
+@cindex @code{fix@var{m}@var{n}2} instruction pattern
@item @samp{fix@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 and store in operand 0 (which
If the machine description defines this pattern, it also needs to
define the @code{ftrunc} pattern.
-@cindex @code{fixuns@var{mn}2} instruction pattern
+@cindex @code{fixuns@var{m}@var{n}2} instruction pattern
@item @samp{fixuns@var{m}@var{n}2}
Convert operand 1 (valid for floating point mode @var{m}) to fixed
point mode @var{n} as an unsigned number and store in operand 0 (which
integer value, still represented in floating point mode @var{m}, and
store it in operand 0 (valid for floating point mode @var{m}).
-@cindex @code{fix_trunc@var{mn}2} instruction pattern
+@cindex @code{fix_trunc@var{m}@var{n}2} instruction pattern
@item @samp{fix_trunc@var{m}@var{n}2}
Like @samp{fix@var{m}@var{n}2} but works for any floating point value
of mode @var{m} by converting the value to an integer.
-@cindex @code{fixuns_trunc@var{mn}2} instruction pattern
+@cindex @code{fixuns_trunc@var{m}@var{n}2} instruction pattern
@item @samp{fixuns_trunc@var{m}@var{n}2}
Like @samp{fixuns@var{m}@var{n}2} but works for any floating point
value of mode @var{m} by converting the value to an integer.
-@cindex @code{trunc@var{mn}2} instruction pattern
+@cindex @code{trunc@var{m}@var{n}2} instruction pattern
@item @samp{trunc@var{m}@var{n}2}
Truncate operand 1 (valid for mode @var{m}) to mode @var{n} and
store in operand 0 (which has mode @var{n}). Both modes must be fixed
point or both floating point.
-@cindex @code{extend@var{mn}2} instruction pattern
+@cindex @code{extend@var{m}@var{n}2} instruction pattern
@item @samp{extend@var{m}@var{n}2}
Sign-extend operand 1 (valid for mode @var{m}) to mode @var{n} and
store in operand 0 (which has mode @var{n}). Both modes must be fixed
point or both floating point.
-@cindex @code{zero_extend@var{mn}2} instruction pattern
+@cindex @code{zero_extend@var{m}@var{n}2} instruction pattern
@item @samp{zero_extend@var{m}@var{n}2}
Zero-extend operand 1 (valid for mode @var{m}) to mode @var{n} and
store in operand 0 (which has mode @var{n}). Both modes must be fixed
point.
-@cindex @code{fract@var{mn}2} instruction pattern
+@cindex @code{fract@var{m}@var{n}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}
or fixed-point to floating-point.
When overflows or underflows happen, the results are undefined.
-@cindex @code{satfract@var{mn}2} instruction pattern
+@cindex @code{satfract@var{m}@var{n}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}
When overflows or underflows happen, the instruction saturates the
results to the maximum or the minimum.
-@cindex @code{fractuns@var{mn}2} instruction pattern
+@cindex @code{fractuns@var{m}@var{n}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}
fixed-point to unsigned integer.
When overflows or underflows happen, the results are undefined.
-@cindex @code{satfractuns@var{mn}2} instruction pattern
+@cindex @code{satfractuns@var{m}@var{n}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}).
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.
-Value stored is nonzero iff the condition @var{cond} is true.
-@var{cond} is the name of a comparison operation expression code, such
-as @code{eq}, @code{lt} or @code{leu}.
-
-You specify the mode that the operand must have when you write the
-@code{match_operand} expression. The compiler automatically sees
-which mode you have used and supplies an operand of that mode.
+@cindex @code{cstore@var{mode}4} instruction pattern
+@item @samp{cstore@var{mode}4}
+Store zero or nonzero in operand 0 according to whether a comparison
+is true. Operand 1 is a comparison operator. Operand 2 and operand 3
+are the first and second operand of the comparison, respectively.
+You specify the mode that operand 0 must have when you write the
+@code{match_operand} expression. The compiler automatically sees which
+mode you have used and supplies an operand of that mode.
The value stored for a true condition must have 1 as its low bit, or
else must be negative. Otherwise the instruction is not suitable and
you should omit it from the machine description. You describe to the
compiler exactly which value is stored by defining the macro
@code{STORE_FLAG_VALUE} (@pxref{Misc}). If a description cannot be
-found that can be used for all the @samp{s@var{cond}} patterns, you
-should omit those operations from the machine description.
-
-These operations may fail, but should do so only in relatively
-uncommon cases; if they would fail for common cases involving
-integer comparisons, it is best to omit these patterns.
-
-If these operations are omitted, the compiler will usually generate code
-that copies the constant one to the target and branches around an
-assignment of zero to the target. If this code is more efficient than
-the potential instructions used for the @samp{s@var{cond}} pattern
-followed by those required to convert the result into a 1 or a zero in
-@code{SImode}, you should omit the @samp{s@var{cond}} operations from
-the machine description.
-
-@cindex @code{b@var{cond}} instruction pattern
-@item @samp{b@var{cond}}
-Conditional branch instruction. Operand 0 is a @code{label_ref} that
-refers to the label to jump to. Jump if the condition codes meet
-condition @var{cond}.
-
-Some machines do not follow the model assumed here where a comparison
-instruction is followed by a conditional branch instruction. In that
-case, the @samp{cmp@var{m}} (and @samp{tst@var{m}}) patterns should
-simply store the operands away and generate all the required insns in a
-@code{define_expand} (@pxref{Expander Definitions}) for the conditional
-branch operations. All calls to expand @samp{b@var{cond}} patterns are
-immediately preceded by calls to expand either a @samp{cmp@var{m}}
-pattern or a @samp{tst@var{m}} pattern.
-
-Machines that use a pseudo register for the condition code value, or
-where the mode used for the comparison depends on the condition being
-tested, should also use the above mechanism. @xref{Jump Patterns}.
-
-The above discussion also applies to the @samp{mov@var{mode}cc} and
-@samp{s@var{cond}} patterns.
+found that can be used for all the possible comparison operators, you
+should pick one and use a @code{define_expand} to map all results
+onto the one you chose.
+
+These operations may @code{FAIL}, but should do so only in relatively
+uncommon cases; if they would @code{FAIL} for common cases involving
+integer comparisons, it is best to restrict the predicates to not
+allow these operands. Likewise if a given comparison operator will
+always fail, independent of the operands (for floating-point modes, the
+@code{ordered_comparison_operator} predicate is often useful in this case).
+
+If this pattern is omitted, the compiler will generate a conditional
+branch---for example, it may copy a constant one to the target and branching
+around an assignment of zero to the target---or a libcall. If the predicate
+for operand 1 only rejects some operators, it will also try reordering the
+operands and/or inverting the result value (e.g.@: by an exclusive OR).
+These possibilities could be cheaper or equivalent to the instructions
+used for the @samp{cstore@var{mode}4} pattern followed by those required
+to convert a positive result from @code{STORE_FLAG_VALUE} to 1; in this
+case, you can and should make operand 1's predicate reject some operators
+in the @samp{cstore@var{mode}4} pattern, or remove the pattern altogether
+from the machine description.
@cindex @code{cbranch@var{mode}4} instruction pattern
@item @samp{cbranch@var{mode}4}
A label to jump to if the index has a value outside the bounds.
@end enumerate
-The table is a @code{addr_vec} or @code{addr_diff_vec} inside of a
+The table is an @code{addr_vec} or @code{addr_diff_vec} inside of a
@code{jump_insn}. The number of elements in the table is one plus the
difference between the upper bound and the lower bound.
@cindex @code{check_stack} instruction pattern
@item @samp{check_stack}
-If stack checking cannot be done on your system by probing the stack with
-a load or store instruction (@pxref{Stack Checking}), define this pattern
-to perform the needed check and signaling an error if the stack
-has overflowed. The single operand is the location in the stack furthest
-from the current stack pointer that you need to validate. Normally,
-on machines where this pattern is needed, you would obtain the stack
-limit from a global or thread-specific variable or register.
+If stack checking (@pxref{Stack Checking}) cannot be done on your system by
+probing the stack, define this pattern to perform the needed check and signal
+an error if the stack has overflowed. The single operand is the address in
+the stack farthest from the current stack pointer that you need to validate.
+Normally, on platforms where this pattern is needed, you would obtain the
+stack limit from a global or thread-specific variable or register.
+
+@cindex @code{probe_stack} instruction pattern
+@item @samp{probe_stack}
+If stack checking (@pxref{Stack Checking}) can be done on your system by
+probing the stack but doing it with a ``store zero'' instruction is not valid
+or optimal, define this pattern to do the probing differently and signal an
+error if the stack has overflowed. The single operand is the memory reference
+in the stack that needs to be probed.
@cindex @code{nonlocal_goto} instruction pattern
@item @samp{nonlocal_goto}
@cindex @code{builtin_setjmp_receiver} instruction pattern
@item @samp{builtin_setjmp_receiver}
-This pattern, if defined, contains code needed at the site of an
+This pattern, if defined, contains code needed at the site of a
built-in setjmp that isn't needed at the site of a nonlocal goto. You
will not normally need to define this pattern. A typical reason why you
might need this pattern is if some value, such as a pointer to a global
kind of signal to be raised. Among other places, it is used by the Java
front end to signal `invalid array index' exceptions.
-@cindex @code{conditional_trap} instruction pattern
-@item @samp{conditional_trap}
+@cindex @code{ctrap@var{MM}4} instruction pattern
+@item @samp{ctrap@var{MM}4}
Conditional trap instruction. Operand 0 is a piece of RTL which
-performs a comparison. Operand 1 is the trap code, an integer.
+performs a comparison, and operands 1 and 2 are the arms of the
+comparison. Operand 3 is the trap code, an integer.
-A typical @code{conditional_trap} pattern looks like
+A typical @code{ctrap} pattern looks like
@smallexample
-(define_insn "conditional_trap"
+(define_insn "ctrapsi4"
[(trap_if (match_operator 0 "trap_operator"
- [(cc0) (const_int 0)])
- (match_operand 1 "const_int_operand" "i"))]
+ [(match_operand 1 "register_operand")
+ (match_operand 2 "immediate_operand")])
+ (match_operand 3 "const_int_operand" "i"))]
""
"@dots{}")
@end smallexample
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}}.
+For targets where the success or failure of the compare-and-swap
+operation is available via the status flags, it is possible to
+avoid a separate compare operation and issue the subsequent
+branch or store-flag operation immediately after the compare-and-swap.
+To this end, GCC will look for a @code{MODE_CC} set in the
+output of @code{sync_compare_and_swap@var{mode}}; if the machine
+description includes such a set, the target should also define special
+@code{cbranchcc4} and/or @code{cstorecc4} instructions. GCC will then
+be able to take the destination of the @code{MODE_CC} set and pass it
+to the @code{cbranchcc4} or @code{cstorecc4} pattern as the first
+operand of the comparison (the second will be @code{(const_int 0)}).
@cindex @code{sync_add@var{mode}} instruction pattern
@cindex @code{sync_sub@var{mode}} instruction pattern
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
@cindex Dependent Patterns
@cindex Interdependence of Patterns
-Every machine description must have a named pattern for each of the
-conditional branch names @samp{b@var{cond}}. The recognition template
-must always have the form
-
-@smallexample
-(set (pc)
- (if_then_else (@var{cond} (cc0) (const_int 0))
- (label_ref (match_operand 0 "" ""))
- (pc)))
-@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
-
-@smallexample
-(set (pc)
- (if_then_else (@var{cond} (cc0) (const_int 0))
- (pc)
- (label_ref (match_operand 0 "" ""))))
-@end smallexample
-
-@noindent
-They are necessary because jump optimization can turn direct-conditional
-branches into reverse-conditional branches.
-
-It is often convenient to use the @code{match_operator} construct to
-reduce the number of patterns that must be specified for branches. For
-example,
-
-@smallexample
-(define_insn ""
- [(set (pc)
- (if_then_else (match_operator 0 "comparison_operator"
- [(cc0) (const_int 0)])
- (pc)
- (label_ref (match_operand 1 "" ""))))]
- "@var{condition}"
- "@dots{}")
-@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
@cindex jump instruction patterns
@cindex defining jump instruction patterns
-For most machines, GCC assumes that the machine has a condition code.
-A comparison insn sets the condition code, recording the results of both
-signed and unsigned comparison of the given operands. A separate branch
-insn tests the condition code and branches or not according its value.
-The branch insns come in distinct signed and unsigned flavors. Many
-common machines, such as the VAX, the 68000 and the 32000, work this
-way.
-
-Some machines have distinct signed and unsigned compare instructions, and
-only one set of conditional branch instructions. The easiest way to handle
-these machines is to treat them just like the others until the final stage
-where assembly code is written. At this time, when outputting code for the
-compare instruction, peek ahead at the following branch using
-@code{next_cc0_user (insn)}. (The variable @code{insn} refers to the insn
-being output, in the output-writing code in an instruction pattern.) If
-the RTL says that is an unsigned branch, output an unsigned compare;
-otherwise output a signed compare. When the branch itself is output, you
-can treat signed and unsigned branches identically.
-
-The reason you can do this is that GCC always generates a pair of
-consecutive RTL insns, possibly separated by @code{note} insns, one to
-set the condition code and one to test it, and keeps the pair inviolate
-until the end.
-
-To go with this technique, you must define the machine-description macro
-@code{NOTICE_UPDATE_CC} to do @code{CC_STATUS_INIT}; in other words, no
-compare instruction is superfluous.
-
-Some machines have compare-and-branch instructions and no condition code.
-A similar technique works for them. When it is time to ``output'' a
-compare instruction, record its operands in two static variables. When
-outputting the branch-on-condition-code instruction that follows, actually
-output a compare-and-branch instruction that uses the remembered operands.
-
-It also works to define patterns for compare-and-branch instructions.
-In optimizing compilation, the pair of compare and branch instructions
-will be combined according to these patterns. But this does not happen
-if optimization is not requested. So you must use one of the solutions
-above in addition to any special patterns you define.
-
-In many RISC machines, most instructions do not affect the condition
-code and there may not even be a separate condition code register. On
-these machines, the restriction that the definition and use of the
-condition code be adjacent insns is not necessary and can prevent
-important optimizations. For example, on the IBM RS/6000, there is a
-delay for taken branches unless the condition code register is set three
-instructions earlier than the conditional branch. The instruction
-scheduler cannot perform this optimization if it is not permitted to
-separate the definition and use of the condition code register.
-
-On these machines, do not use @code{(cc0)}, but instead use a register
-to represent the condition code. If there is a specific condition code
-register in the machine, use a hard register. If the condition code or
-comparison result can be placed in any general register, or if there are
-multiple condition registers, use a pseudo register.
-
-@findex prev_cc0_setter
-@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
-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
-and use of the condition code must be adjacent (separated only by
-@code{note} insns) allowing flags in @code{cc_status} to be used.
-(@xref{Condition Code}.) Also, the comparison and branch insns can be
-located from each other by using the functions @code{prev_cc0_setter}
-and @code{next_cc0_user}.
-
-However, this is not true on machines that do not use @code{(cc0)}. On
-those machines, no assumptions can be made about the adjacency of the
-compare and branch insns and the above methods cannot be used. Instead,
-we use the machine mode of the condition code register to record
-different formats of the condition code register.
-
-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 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
-for signed and unsigned quantities, like most IBM processors), they can
-be specified at that time.
-
-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
-discussed above, we have the pattern
-
-@smallexample
-(define_insn ""
- [(set (reg:CC_NOOV 0)
- (compare:CC_NOOV
- (plus:SI (match_operand:SI 0 "register_operand" "%r")
- (match_operand:SI 1 "arith_operand" "rI"))
- (const_int 0)))]
- ""
- "@dots{}")
-@end smallexample
-
-The @code{SELECT_CC_MODE} macro on the SPARC returns @code{CC_NOOVmode}
-for comparisons whose argument is a @code{plus}.
+GCC does not assume anything about how the machine realizes jumps.
+The machine description should define a single pattern, usually
+a @code{define_expand}, which expands to all the required insns.
+
+Usually, this would be a comparison insn to set the condition code
+and a separate branch insn testing the condition code and branching
+or not according to its value. For many machines, however,
+separating compares and branches is limiting, which is why the
+more flexible approach with one @code{define_expand} is used in GCC.
+The machine description becomes clearer for architectures that
+have compare-and-branch instructions but no condition code. It also
+works better when different sets of comparison operators are supported
+by different kinds of conditional branches (e.g. integer vs. floating-point),
+or by conditional branches with respect to conditional stores.
+
+Two separate insns are always used if the machine description represents
+a condition code register using the legacy RTL expression @code{(cc0)},
+and on most machines that use a separate condition code register
+(@pxref{Condition Code}). For machines that use @code{(cc0)}, in
+fact, the set and use of the condition code must be separate and
+adjacent@footnote{@code{note} insns can separate them, though.}, thus
+allowing flags in @code{cc_status} to be used (@pxref{Condition Code}) and
+so that the comparison and branch insns could be located from each other
+by using the functions @code{prev_cc0_setter} and @code{next_cc0_user}.
+
+Even in this case having a single entry point for conditional branches
+is advantageous, because it handles equally well the case where a single
+comparison instruction records the results of both signed and unsigned
+comparison of the given operands (with the branch insns coming in distinct
+signed and unsigned flavors) as in the x86 or SPARC, and the case where
+there are distinct signed and unsigned compare instructions and only
+one set of conditional branch instructions as in the PowerPC.
@end ifset
@ifset INTERNALS
@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{(plus (mult (neg B) C) A)} 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
-on machines where @code{cc0} is used (@pxref{Jump Patterns}). On other
-machines, there are rare cases where the compiler might want to construct
-a @code{compare} with a constant as the first operand. However, these
-cases are not common enough for it to be worthwhile to provide a pattern
-matching a constant as the first operand unless the machine actually has
-such an instruction.
+if the first argument is a condition code register or @code{(cc0)}.
+@item
An operand of @code{neg}, @code{not}, @code{mult}, @code{plus}, or
@code{minus} is made the first operand under the same conditions as
above.
(plus:@var{m} (plus:@var{m} @var{x} @var{y}) @var{constant})
@end smallexample
-@item
-On machines that do not use @code{cc0},
-@code{(compare @var{x} (const_int 0))} will be converted to
-@var{x}.
-
@cindex @code{zero_extract}, canonicalization of
@cindex @code{sign_extract}, canonicalization of
@item
jumps, or simple conditional jump instructions. Additionally it must attach a
@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
+it was a simple conditional jump, @minus{}1 otherwise. To simplify
recomputing of edge frequencies, the new sequence is required to have only
forward jumps to the newly created labels.
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
+@findex define_enum_attr
+@anchor{define_enum_attr}
+Another way of defining an attribute is to use:
+
+@smallexample
+(define_enum_attr "@var{attr}" "@var{enum}" @var{default})
+@end smallexample
+
+This works in just the same way as @code{define_attr}, except that
+the list of values is taken from a separate enumeration called
+@var{enum} (@pxref{define_enum}). This form allows you to use
+the same list of values for several attributes without having to
+repeat the list each time. For example:
+
+@smallexample
+(define_enum "processor" [
+ model_a
+ model_b
+ @dots{}
+])
+(define_enum_attr "arch" "processor"
+ (const (symbol_ref "target_arch")))
+(define_enum_attr "tune" "processor"
+ (const (symbol_ref "target_tune")))
+@end smallexample
+
+defines the same attributes as:
+
+@smallexample
+(define_attr "arch" "model_a,model_b,@dots{}"
+ (const (symbol_ref "target_arch")))
+(define_attr "tune" "model_a,model_b,@dots{}"
+ (const (symbol_ref "target_tune")))
+@end smallexample
+
+but without duplicating the processor list. The second example defines two
+separate C enums (@code{attr_arch} and @code{attr_tune}) whereas the first
+defines a single C enum (@code{processor}).
@end ifset
@ifset INTERNALS
@node Expressions
The constants that are defined with a define_constant are also output
in the insn-codes.h header file as #defines.
+
+@cindex enumerations
+@findex define_c_enum
+You can also use the machine description file to define enumerations.
+Like the constants defined by @code{define_constant}, these enumerations
+are visible to both the machine description file and the main C code.
+
+The syntax is as follows:
+
+@smallexample
+(define_c_enum "@var{name}" [
+ @var{value0}
+ @var{value1}
+ @dots{}
+ @var{valuen}
+])
+@end smallexample
+
+This definition causes the equivalent of the following C code to appear
+in @file{insn-constants.h}:
+
+@smallexample
+enum @var{name} @{
+ @var{value0} = 0,
+ @var{value1} = 1,
+ @dots{}
+ @var{valuen} = @var{n}
+@};
+#define NUM_@var{cname}_VALUES (@var{n} + 1)
+@end smallexample
+
+where @var{cname} is the capitalized form of @var{name}.
+It also makes each @var{valuei} available in the machine description
+file, just as if it had been declared with:
+
+@smallexample
+(define_constants [(@var{valuei} @var{i})])
+@end smallexample
+
+Each @var{valuei} is usually an upper-case identifier and usually
+begins with @var{cname}.
+
+You can split the enumeration definition into as many statements as
+you like. The above example is directly equivalent to:
+
+@smallexample
+(define_c_enum "@var{name}" [@var{value0}])
+(define_c_enum "@var{name}" [@var{value1}])
+@dots{}
+(define_c_enum "@var{name}" [@var{valuen}])
+@end smallexample
+
+Splitting the enumeration helps to improve the modularity of each
+individual @code{.md} file. For example, if a port defines its
+synchronization instructions in a separate @file{sync.md} file,
+it is convenient to define all synchronization-specific enumeration
+values in @file{sync.md} rather than in the main @file{.md} file.
+
+Some enumeration names have special significance to GCC:
+
+@table @code
+@item unspecv
+@findex unspec_volatile
+If an enumeration called @code{unspecv} is defined, GCC will use it
+when printing out @code{unspec_volatile} expressions. For example:
+
+@smallexample
+(define_c_enum "unspecv" [
+ UNSPECV_BLOCKAGE
+])
+@end smallexample
+
+causes GCC to print @samp{(unspec_volatile @dots{} 0)} as:
+
+@smallexample
+(unspec_volatile ... UNSPECV_BLOCKAGE)
+@end smallexample
+
+@item unspec
+@findex unspec
+If an enumeration called @code{unspec} is defined, GCC will use
+it when printing out @code{unspec} expressions. GCC will also use
+it when printing out @code{unspec_volatile} expressions unless an
+@code{unspecv} enumeration is also defined. You can therefore
+decide whether to keep separate enumerations for volatile and
+non-volatile expressions or whether to use the same enumeration
+for both.
+@end table
+
+@findex define_enum
+@anchor{define_enum}
+Another way of defining an enumeration is to use @code{define_enum}:
+
+@smallexample
+(define_enum "@var{name}" [
+ @var{value0}
+ @var{value1}
+ @dots{}
+ @var{valuen}
+])
+@end smallexample
+
+This directive implies:
+
+@smallexample
+(define_c_enum "@var{name}" [
+ @var{cname}_@var{cvalue0}
+ @var{cname}_@var{cvalue1}
+ @dots{}
+ @var{cname}_@var{cvaluen}
+])
+@end smallexample
+
+@findex define_enum_attr
+where @var{cvaluei} is the capitalized form of @var{valuei}.
+However, unlike @code{define_c_enum}, the enumerations defined
+by @code{define_enum} can be used in attribute specifications
+(@pxref{define_enum_attr}).
@end ifset
@ifset INTERNALS
@node Iterators