+ `S'
+ Indirect memory reference with 1 bit or index register
+ displacement
+
+ `T'
+ Direct memory reference
+
+ `U'
+ Symbolic address
+
+
+_S/390 and zSeries--`s390.h'_
+
+ `a'
+ Address register (general purpose register except r0)
+
+ `d'
+ Data register (arbitrary general purpose register)
+
+ `f'
+ Floating-point register
+
+ `I'
+ Unsigned 8-bit constant (0-255)
+
+ `J'
+ Unsigned 12-bit constant (0-4095)
+
+ `K'
+ Signed 16-bit constant (-32768-32767)
+
+ `L'
+ Unsigned 16-bit constant (0-65535)
+
+ `Q'
+ Memory reference without index register
+
+ `S'
+ Symbolic constant suitable for use with the `larl' instruction
+
+
+_Xstormy16--`stormy16.h'_
+
+ `a'
+ Register r0.
+
+ `b'
+ Register r1.
+
+ `c'
+ Register r2.
+
+ `d'
+ Register r8.
+
+ `e'
+ Registers r0 through r7.
+
+ `t'
+ Registers r0 and r1.
+
+ `y'
+ The carry register.
+
+ `z'
+ Registers r8 and r9.
+
+ `I'
+ A constant between 0 and 3 inclusive.
+
+ `J'
+ A constant that has exactly one bit set.
+
+ `K'
+ A constant that has exactly one bit clear.
+
+ `L'
+ A constant between 0 and 255 inclusive.
+
+ `M'
+ A constant between -255 and 0 inclusive.
+
+ `N'
+ A constant between -3 and 0 inclusive.
+
+ `O'
+ A constant between 1 and 4 inclusive.
+
+ `P'
+ A constant between -4 and -1 inclusive.
+
+ `Q'
+ A memory reference that is a stack push.
+
+ `R'
+ A memory reference that is a stack pop.
+
+ `S'
+ A memory reference that refers to an constant address of
+ known value.
+
+ `T'
+ The register indicated by Rx (not implemented yet).
+
+ `U'
+ A constant that is not between 2 and 15 inclusive.
+
+
+_Xtensa--`xtensa.h'_
+
+ `a'
+ General-purpose 32-bit register
+
+ `b'
+ One-bit boolean register
+
+ `A'
+ MAC16 40-bit accumulator register
+
+ `I'
+ Signed 12-bit integer constant, for use in MOVI instructions
+
+ `J'
+ Signed 8-bit integer constant, for use in ADDI instructions
+
+ `K'
+ Integer constant valid for BccI instructions
+
+ `L'
+ Unsigned constant valid for BccUI instructions
+
+
+
+\1f
+File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc
+
+9.8 Standard Pattern Names For Generation
+=========================================
+
+Here is a table of the instruction names that are meaningful in the RTL
+generation pass of the compiler. Giving one of these names to an
+instruction pattern tells the RTL generation pass that it can use the
+pattern to accomplish a certain task.
+
+`movM'
+ Here M stands for a two-letter machine mode name, in lower case.
+ This instruction pattern moves data with that machine mode from
+ operand 1 to operand 0. For example, `movsi' moves full-word data.
+
+ If operand 0 is a `subreg' with mode M of a register whose own
+ mode is wider than M, the effect of this instruction is to store
+ the specified value in the part of the register that corresponds
+ to mode M. Bits outside of M, but which are within the same
+ target word as the `subreg' are undefined. Bits which are outside
+ the target word are left unchanged.
+
+ This class of patterns is special in several ways. First of all,
+ each of these names up to and including full word size _must_ be
+ defined, because there is no other way to copy a datum from one
+ place to another. If there are patterns accepting operands in
+ larger modes, `movM' must be defined for integer modes of those
+ sizes.
+
+ Second, these patterns are not used solely in the RTL generation
+ pass. Even the reload pass can generate move insns to copy values
+ from stack slots into temporary registers. When it does so, one
+ of the operands is a hard register and the other is an operand
+ that can need to be reloaded into a register.
+
+ Therefore, when given such a pair of operands, the pattern must
+ generate RTL which needs no reloading and needs no temporary
+ registers--no registers other than the operands. For example, if
+ you support the pattern with a `define_expand', then in such a
+ case the `define_expand' mustn't call `force_reg' or any other such
+ function which might generate new pseudo registers.
+
+ This requirement exists even for subword modes on a RISC machine
+ where fetching those modes from memory normally requires several
+ insns and some temporary registers.
+
+ During reload a memory reference with an invalid address may be
+ passed as an operand. Such an address will be replaced with a
+ valid address later in the reload pass. In this case, nothing may
+ be done with the address except to use it as it stands. If it is
+ copied, it will not be replaced with a valid address. No attempt
+ should be made to make such an address into a valid address and no
+ routine (such as `change_address') that will do so may be called.
+ Note that `general_operand' will fail when applied to such an
+ address.
+
+ The global variable `reload_in_progress' (which must be explicitly
+ declared if required) can be used to determine whether such special
+ handling is required.
+
+ The variety of operands that have reloads depends on the rest of
+ the machine description, but typically on a RISC machine these can
+ only be pseudo registers that did not get hard registers, while on
+ other machines explicit memory references will get optional
+ reloads.
+
+ If a scratch register is required to move an object to or from
+ memory, it can be allocated using `gen_reg_rtx' prior to life
+ analysis.
+
+ If there are cases which need scratch registers during or after
+ reload, you must define `SECONDARY_INPUT_RELOAD_CLASS' and/or
+ `SECONDARY_OUTPUT_RELOAD_CLASS' to detect them, and provide
+ patterns `reload_inM' or `reload_outM' to handle them. *Note
+ Register Classes::.
+
+ The global variable `no_new_pseudos' can be used to determine if it
+ is unsafe to create new pseudo registers. If this variable is
+ nonzero, then it is unsafe to call `gen_reg_rtx' to allocate a new
+ pseudo.
+
+ The constraints on a `movM' must permit moving any hard register
+ to any other hard register provided that `HARD_REGNO_MODE_OK'
+ permits mode M in both registers and `REGISTER_MOVE_COST' applied
+ to their classes returns a value of 2.
+
+ It is obligatory to support floating point `movM' instructions
+ into and out of any registers that can hold fixed point values,
+ because unions and structures (which have modes `SImode' or
+ `DImode') can be in those registers and they may have floating
+ point members.
+
+ There may also be a need to support fixed point `movM'
+ instructions in and out of floating point registers.
+ Unfortunately, I have forgotten why this was so, and I don't know
+ whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed
+ point values in floating point registers, then the constraints of
+ the fixed point `movM' instructions must be designed to avoid ever
+ trying to reload into a floating point register.
+
+`reload_inM'
+`reload_outM'
+ Like `movM', but used when a scratch register is required to move
+ between operand 0 and operand 1. Operand 2 describes the scratch
+ register. See the discussion of the `SECONDARY_RELOAD_CLASS'
+ macro in *note Register Classes::.
+
+ There are special restrictions on the form of the `match_operand's
+ used in these patterns. First, only the predicate for the reload
+ operand is examined, i.e., `reload_in' examines operand 1, but not
+ the predicates for operand 0 or 2. Second, there may be only one
+ alternative in the constraints. Third, only a single register
+ class letter may be used for the constraint; subsequent constraint
+ letters are ignored. As a special exception, an empty constraint
+ string matches the `ALL_REGS' register class. This may relieve
+ ports of the burden of defining an `ALL_REGS' constraint letter
+ just for these patterns.
+
+`movstrictM'
+ Like `movM' except that if operand 0 is a `subreg' with mode M of
+ a register whose natural mode is wider, the `movstrictM'
+ instruction is guaranteed not to alter any of the register except
+ the part which belongs to mode M.
+
+`load_multiple'
+ Load several consecutive memory locations into consecutive
+ registers. Operand 0 is the first of the consecutive registers,
+ operand 1 is the first memory location, and operand 2 is a
+ constant: the number of consecutive registers.
+
+ Define this only if the target machine really has such an
+ instruction; do not define this if the most efficient way of
+ loading consecutive registers from memory is to do them one at a
+ time.
+
+ On some machines, there are restrictions as to which consecutive
+ registers can be stored into memory, such as particular starting or
+ ending register numbers or only a range of valid counts. For those
+ machines, use a `define_expand' (*note Expander Definitions::) and
+ make the pattern fail if the restrictions are not met.
+
+ Write the generated insn as a `parallel' with elements being a
+ `set' of one register from the appropriate memory location (you may
+ also need `use' or `clobber' elements). Use a `match_parallel'
+ (*note RTL Template::) to recognize the insn. See `a29k.md' and
+ `rs6000.md' for examples of the use of this insn pattern.
+
+`store_multiple'
+ Similar to `load_multiple', but store several consecutive registers
+ into consecutive memory locations. Operand 0 is the first of the
+ consecutive memory locations, operand 1 is the first register, and
+ operand 2 is a constant: the number of consecutive registers.
+
+`pushM'
+ Output an push instruction. Operand 0 is value to push. Used
+ only when `PUSH_ROUNDING' is defined. For historical reason, this
+ pattern may be missing and in such case an `mov' expander is used
+ instead, with a `MEM' expression forming the push operation. The
+ `mov' expander method is deprecated.
+
+`addM3'
+ Add operand 2 and operand 1, storing the result in operand 0. All
+ operands must have mode M. This can be used even on two-address
+ machines, by means of constraints requiring operands 1 and 0 to be
+ the same location.
+
+`subM3', `mulM3'
+`divM3', `udivM3', `modM3', `umodM3'
+`sminM3', `smaxM3', `uminM3', `umaxM3'
+`andM3', `iorM3', `xorM3'
+ Similar, for other arithmetic operations.
+
+`minM3', `maxM3'
+ 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.
+
+`mulhisi3'
+ Multiply operands 1 and 2, which have mode `HImode', and store a
+ `SImode' product in operand 0.
+
+`mulqihi3', `mulsidi3'
+ Similar widening-multiplication instructions of other widths.
+
+`umulqihi3', `umulhisi3', `umulsidi3'
+ Similar widening-multiplication instructions that do unsigned
+ multiplication.
+
+`smulM3_highpart'
+ Perform a signed multiplication of operands 1 and 2, which have
+ mode M, and store the most significant half of the product in
+ operand 0. The least significant half of the product is discarded.
+
+`umulM3_highpart'
+ Similar, but the multiplication is unsigned.
+
+`divmodM4'
+ Signed division that produces both a quotient and a remainder.
+ Operand 1 is divided by operand 2 to produce a quotient stored in
+ operand 0 and a remainder stored in operand 3.
+
+ For machines with an instruction that produces both a quotient and
+ a remainder, provide a pattern for `divmodM4' but do not provide
+ patterns for `divM3' and `modM3'. This allows optimization in the
+ relatively common case when both the quotient and remainder are
+ computed.
+
+ If an instruction that just produces a quotient or just a remainder
+ exists and is more efficient than the instruction that produces
+ both, write the output routine of `divmodM4' to call
+ `find_reg_note' and look for a `REG_UNUSED' note on the quotient
+ or remainder and generate the appropriate instruction.
+
+`udivmodM4'
+ Similar, but does unsigned division.
+
+`ashlM3'
+ Arithmetic-shift operand 1 left by a number of bits specified by
+ operand 2, and store the result in operand 0. Here 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.
+
+`ashrM3', `lshrM3', `rotlM3', `rotrM3'
+ Other shift and rotate instructions, analogous to the `ashlM3'
+ instructions.
+
+`negM2'
+ Negate operand 1 and store the result in operand 0.
+
+`absM2'
+ Store the absolute value of operand 1 into operand 0.
+
+`sqrtM2'
+ Store the square root of operand 1 into operand 0.
+
+ The `sqrt' built-in function of C always uses the mode which
+ corresponds to the C data type `double'.
+
+`ffsM2'
+ Store into operand 0 one plus the index of the least significant
+ 1-bit of operand 1. If operand 1 is zero, store zero. 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.
+
+ The `ffs' built-in function of C always uses the mode which
+ corresponds to the C data type `int'.
+
+`one_cmplM2'
+ Store the bitwise-complement of operand 1 into operand 0.
+
+`cmpM'
+ Compare operand 0 and operand 1, and set the condition codes. The
+ RTL pattern should look like this:
+
+ (set (cc0) (compare (match_operand:M 0 ...)
+ (match_operand:M 1 ...)))
+
+`tstM'
+ Compare operand 0 against zero, and set the condition codes. The
+ RTL pattern should look like this:
+
+ (set (cc0) (match_operand:M 0 ...))
+
+ `tstM' patterns should not be defined for machines that do not use
+ `(cc0)'. Doing so would confuse the optimizer since it would no
+ longer be clear which `set' operations were comparisons. The
+ `cmpM' patterns should be used instead.
+
+`movstrM'
+ Block move instruction. The addresses of the destination and
+ source strings are the first two operands, and both are in mode
+ `Pmode'.
+
+ The number of bytes to move is the third operand, in mode M.
+ Usually, you specify `word_mode' for M. However, if you can
+ generate better code knowing the range of valid lengths is smaller
+ than those representable in a full word, you should provide a
+ pattern with a mode corresponding to the range of values you can
+ handle efficiently (e.g., `QImode' for values in the range 0-127;
+ note we avoid numbers that appear negative) and also a pattern
+ with `word_mode'.
+
+ The fourth operand is the known shared alignment of the source and
+ destination, in the form of a `const_int' rtx. Thus, if the
+ compiler knows that both source and destination are word-aligned,
+ it may provide the value 4 for this operand.
+
+ Descriptions of multiple `movstrM' 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 M in
+ `movstrM' 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.
+
+`clrstrM'
+ Block clear instruction. The addresses of the destination string
+ is the first operand, in mode `Pmode'. The number of bytes to
+ clear is the second operand, in mode M. See `movstrM' for a
+ discussion of the choice of mode.
+
+ The third operand is the known alignment of the destination, in
+ the form of a `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 `clrstrM' is as for `movstrM'.
+
+`cmpstrM'
+ Block compare instruction, with five operands. Operand 0 is the
+ output; it has mode M. The remaining four operands are like the
+ operands of `movstrM'. The two memory blocks specified are
+ compared byte by byte in lexicographic order. The effect of the
+ instruction is to store a value in operand 0 whose sign indicates
+ the result of the comparison.
+
+`strlenM'
+ Compute the length of a string, with three operands. Operand 0 is
+ the result (of mode M), operand 1 is a `mem' referring to the
+ first character of the string, operand 2 is the character to
+ search for (normally zero), and operand 3 is a constant describing
+ the known alignment of the beginning of the string.
+
+`floatMN2'
+ Convert signed integer operand 1 (valid for fixed point mode M) to
+ floating point mode N and store in operand 0 (which has mode N).
+
+`floatunsMN2'
+ Convert unsigned integer operand 1 (valid for fixed point mode M)
+ to floating point mode N and store in operand 0 (which has mode N).
+
+`fixMN2'
+ Convert operand 1 (valid for floating point mode M) to fixed point
+ mode N as a signed number and store in operand 0 (which has mode
+ N). This instruction's result is defined only when the value of
+ operand 1 is an integer.
+
+`fixunsMN2'
+ Convert operand 1 (valid for floating point mode M) to fixed point
+ mode N as an unsigned number and store in operand 0 (which has
+ mode N). This instruction's result is defined only when the value
+ of operand 1 is an integer.
+
+`ftruncM2'
+ Convert operand 1 (valid for floating point mode M) to an integer
+ value, still represented in floating point mode M, and store it in
+ operand 0 (valid for floating point mode M).
+
+`fix_truncMN2'
+ Like `fixMN2' but works for any floating point value of mode M by
+ converting the value to an integer.
+
+`fixuns_truncMN2'
+ Like `fixunsMN2' but works for any floating point value of mode M
+ by converting the value to an integer.
+
+`truncMN2'
+ Truncate operand 1 (valid for mode M) to mode N and store in
+ operand 0 (which has mode N). Both modes must be fixed point or
+ both floating point.
+
+`extendMN2'
+ Sign-extend operand 1 (valid for mode M) to mode N and store in
+ operand 0 (which has mode N). Both modes must be fixed point or
+ both floating point.
+
+`zero_extendMN2'
+ Zero-extend operand 1 (valid for mode M) to mode N and store in
+ operand 0 (which has mode N). Both modes must be fixed point.
+
+`extv'
+ Extract a bit-field from operand 1 (a register or memory operand),
+ where operand 2 specifies the width in bits and operand 3 the
+ starting bit, and store it in operand 0. Operand 0 must have mode
+ `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode';
+ often `word_mode' is allowed only for registers. Operands 2 and 3
+ must be valid for `word_mode'.
+
+ The RTL generation pass generates this instruction only with
+ constants for operands 2 and 3.
+
+ The bit-field value is sign-extended to a full word integer before
+ it is stored in operand 0.
+
+`extzv'
+ Like `extv' except that the bit-field value is zero-extended.
+
+`insv'
+ Store operand 3 (which must be valid for `word_mode') into a
+ bit-field in operand 0, where operand 1 specifies the width in
+ bits and operand 2 the starting bit. Operand 0 may have mode
+ `byte_mode' or `word_mode'; often `word_mode' is allowed only for
+ registers. Operands 1 and 2 must be valid for `word_mode'.
+
+ The RTL generation pass generates this instruction only with
+ constants for operands 1 and 2.
+
+`movMODEcc'
+ Conditionally move operand 2 or operand 3 into operand 0 according
+ to the comparison in operand 1. If the comparison is true,
+ operand 2 is moved into operand 0, otherwise operand 3 is moved.
+
+ The mode of the operands being compared need not be the same as
+ the operands being moved. Some machines, sparc64 for example,
+ have instructions that conditionally move an integer value based
+ on the floating point condition codes and vice versa.
+
+ If the machine does not have conditional move instructions, do not
+ define these patterns.
+
+`sCOND'
+ Store zero or nonzero in the operand according to the condition
+ codes. Value stored is nonzero iff the condition COND is true.
+ COND is the name of a comparison operation expression code, such
+ as `eq', `lt' or `leu'.
+
+ You specify the mode that the operand must have when you write the
+ `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 `STORE_FLAG_VALUE' (*note Misc::). If a description
+ cannot be found that can be used for all the `sCOND' 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
+ `sCOND' pattern followed by those required to convert the result
+ into a 1 or a zero in `SImode', you should omit the `sCOND'
+ operations from the machine description.
+
+`bCOND'
+ Conditional branch instruction. Operand 0 is a `label_ref' that
+ refers to the label to jump to. Jump if the condition codes meet
+ condition 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 `cmpM' (and `tstM') patterns should
+ simply store the operands away and generate all the required insns
+ in a `define_expand' (*note Expander Definitions::) for the
+ conditional branch operations. All calls to expand `bCOND'
+ patterns are immediately preceded by calls to expand either a
+ `cmpM' pattern or a `tstM' 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. *Note Jump
+ Patterns::.
+
+ The above discussion also applies to the `movMODEcc' and `sCOND'
+ patterns.
+
+`jump'
+ A jump inside a function; an unconditional branch. Operand 0 is
+ the `label_ref' of the label to jump to. This pattern name is
+ mandatory on all machines.
+
+`call'
+ Subroutine call instruction returning no value. Operand 0 is the
+ function to call; operand 1 is the number of bytes of arguments
+ pushed as a `const_int'; operand 2 is the number of registers used
+ as operands.
+
+ On most machines, operand 2 is not actually stored into the RTL
+ pattern. It is supplied for the sake of some RISC machines which
+ need to put this information into the assembler code; they can put
+ it in the RTL instead of operand 1.
+
+ Operand 0 should be a `mem' RTX whose address is the address of the
+ function. Note, however, that this address can be a `symbol_ref'
+ expression even if it would not be a legitimate memory address on
+ the target machine. If it is also not a valid argument for a call
+ instruction, the pattern for this operation should be a
+ `define_expand' (*note Expander Definitions::) that places the
+ address into a register and uses that register in the call
+ instruction.
+
+`call_value'
+ Subroutine call instruction returning a value. Operand 0 is the
+ hard register in which the value is returned. There are three more
+ operands, the same as the three operands of the `call' instruction
+ (but with numbers increased by one).
+
+ Subroutines that return `BLKmode' objects use the `call' insn.
+
+`call_pop', `call_value_pop'
+ Similar to `call' and `call_value', except used if defined and if
+ `RETURN_POPS_ARGS' is nonzero. They should emit a `parallel' that
+ contains both the function call and a `set' to indicate the
+ adjustment made to the frame pointer.
+
+ For machines where `RETURN_POPS_ARGS' can be nonzero, the use of
+ these patterns increases the number of functions for which the
+ frame pointer can be eliminated, if desired.
+
+`untyped_call'
+ Subroutine call instruction returning a value of any type.
+ Operand 0 is the function to call; operand 1 is a memory location
+ where the result of calling the function is to be stored; operand
+ 2 is a `parallel' expression where each element is a `set'
+ expression that indicates the saving of a function return value
+ into the result block.
+
+ This instruction pattern should be defined to support
+ `__builtin_apply' on machines where special instructions are needed
+ to call a subroutine with arbitrary arguments or to save the value
+ returned. This instruction pattern is required on machines that
+ have multiple registers that can hold a return value (i.e.
+ `FUNCTION_VALUE_REGNO_P' is true for more than one register).
+
+`return'
+ Subroutine return instruction. This instruction pattern name
+ should be defined only if a single instruction can do all the work
+ of returning from a function.
+
+ Like the `movM' patterns, this pattern is also used after the RTL
+ generation phase. In this case it is to support machines where
+ multiple instructions are usually needed to return from a
+ function, but some class of functions only requires one
+ instruction to implement a return. Normally, the applicable
+ functions are those which do not need to save any registers or
+ allocate stack space.
+
+ For such machines, the condition specified in this pattern should
+ only be true when `reload_completed' is nonzero and the function's
+ epilogue would only be a single instruction. For machines with
+ register windows, the routine `leaf_function_p' may be used to
+ determine if a register window push is required.
+
+ Machines that have conditional return instructions should define
+ patterns such as
+
+ (define_insn ""
+ [(set (pc)
+ (if_then_else (match_operator
+ 0 "comparison_operator"
+ [(cc0) (const_int 0)])
+ (return)
+ (pc)))]
+ "CONDITION"
+ "...")
+
+ where CONDITION would normally be the same condition specified on
+ the named `return' pattern.
+
+`untyped_return'
+ Untyped subroutine return instruction. This instruction pattern
+ should be defined to support `__builtin_return' on machines where
+ special instructions are needed to return a value of any type.
+
+ Operand 0 is a memory location where the result of calling a
+ function with `__builtin_apply' is stored; operand 1 is a
+ `parallel' expression where each element is a `set' expression
+ that indicates the restoring of a function return value from the
+ result block.
+
+`nop'
+ No-op instruction. This instruction pattern name should always be
+ defined to output a no-op in assembler code. `(const_int 0)' will
+ do as an RTL pattern.
+
+`indirect_jump'
+ An instruction to jump to an address which is operand zero. This
+ pattern name is mandatory on all machines.
+
+`casesi'
+ Instruction to jump through a dispatch table, including bounds
+ checking. This instruction takes five operands:
+
+ 1. The index to dispatch on, which has mode `SImode'.
+
+ 2. The lower bound for indices in the table, an integer constant.
+
+ 3. The total range of indices in the table--the largest index
+ minus the smallest one (both inclusive).
+
+ 4. A label that precedes the table itself.
+
+ 5. A label to jump to if the index has a value outside the
+ bounds. (If the machine-description macro
+ `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 `casesi' instruction, but it is always
+ provided as an operand.)
+
+ The table is a `addr_vec' or `addr_diff_vec' inside of a
+ `jump_insn'. The number of elements in the table is one plus the
+ difference between the upper bound and the lower bound.
+
+`tablejump'
+ Instruction to jump to a variable address. This is a low-level
+ capability which can be used to implement a dispatch table when
+ there is no `casesi' pattern.
+
+ This pattern requires two operands: the address or offset, and a
+ label which should immediately precede the jump table. If the
+ macro `CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then
+ the first operand is an offset which counts from the address of
+ the table; otherwise, it is an absolute address to jump to. In
+ either case, the first operand has mode `Pmode'.
+
+ The `tablejump' insn is always the last insn before the jump table
+ it uses. Its assembler code normally has no need to use the
+ second operand, but you should incorporate it in the RTL pattern so
+ that the jump optimizer will not delete the table as unreachable
+ code.
+
+`decrement_and_branch_until_zero'
+ Conditional branch instruction that decrements a register and
+ jumps if the register is nonzero. Operand 0 is the register to
+ decrement and test; operand 1 is the label to jump to if the
+ register is nonzero. *Note Looping Patterns::.
+
+ This optional instruction pattern is only used by the combiner,
+ typically for loops reversed by the loop optimizer when strength
+ reduction is enabled.
+
+`doloop_end'
+ Conditional branch instruction that decrements a register and
+ jumps if the register is nonzero. This instruction takes five
+ operands: Operand 0 is the register to decrement and test; operand
+ 1 is the number of loop iterations as a `const_int' or
+ `const0_rtx' if this cannot be determined until run-time; operand
+ 2 is the actual or estimated maximum number of iterations as a
+ `const_int'; operand 3 is the number of enclosed loops as a
+ `const_int' (an innermost loop has a value of 1); operand 4 is the
+ label to jump to if the register is nonzero. *Note Looping
+ Patterns::.
+
+ This optional instruction pattern should be defined for machines
+ with low-overhead looping instructions as the loop optimizer will
+ try to modify suitable loops to utilize it. If nested
+ low-overhead looping is not supported, use a `define_expand'
+ (*note Expander Definitions::) and make the pattern fail if
+ operand 3 is not `const1_rtx'. Similarly, if the actual or
+ estimated maximum number of iterations is too large for this
+ instruction, make it fail.
+
+`doloop_begin'
+ Companion instruction to `doloop_end' required for machines that
+ need to perform some initialization, such as loading special
+ registers used by a low-overhead looping instruction. If
+ initialization insns do not always need to be emitted, use a
+ `define_expand' (*note Expander Definitions::) and make it fail.
+
+`canonicalize_funcptr_for_compare'
+ Canonicalize the function pointer in operand 1 and store the result
+ into operand 0.
+
+ Operand 0 is always a `reg' and has mode `Pmode'; operand 1 may be
+ a `reg', `mem', `symbol_ref', `const_int', etc and also has mode
+ `Pmode'.
+
+ Canonicalization of a function pointer usually involves computing
+ the address of the function which would be called if the function
+ pointer were used in an indirect call.
+
+ Only define this pattern if function pointers on the target machine
+ can have different values but still call the same function when
+ used in an indirect call.
+
+`save_stack_block'
+`save_stack_function'
+`save_stack_nonlocal'
+`restore_stack_block'
+`restore_stack_function'
+`restore_stack_nonlocal'
+ Most machines save and restore the stack pointer by copying it to
+ or from an object of mode `Pmode'. Do not define these patterns on
+ such machines.
+
+ Some machines require special handling for stack pointer saves and
+ restores. On those machines, define the patterns corresponding to
+ the non-standard cases by using a `define_expand' (*note Expander
+ Definitions::) that produces the required insns. The three types
+ of saves and restores are:
+
+ 1. `save_stack_block' saves the stack pointer at the start of a
+ block that allocates a variable-sized object, and
+ `restore_stack_block' restores the stack pointer when the
+ block is exited.
+
+ 2. `save_stack_function' and `restore_stack_function' do a
+ similar job for the outermost block of a function and are
+ used when the function allocates variable-sized objects or
+ calls `alloca'. Only the epilogue uses the restored stack
+ pointer, allowing a simpler save or restore sequence on some
+ machines.
+
+ 3. `save_stack_nonlocal' is used in functions that contain labels
+ branched to by nested functions. It saves the stack pointer
+ in such a way that the inner function can use
+ `restore_stack_nonlocal' to restore the stack pointer. The
+ compiler generates code to restore the frame and argument
+ pointer registers, but some machines require saving and
+ restoring additional data such as register window information
+ or stack backchains. Place insns in these patterns to save
+ and restore any such required data.
+
+ When saving the stack pointer, operand 0 is the save area and
+ operand 1 is the stack pointer. The mode used to allocate the
+ save area defaults to `Pmode' but you can override that choice by
+ defining the `STACK_SAVEAREA_MODE' macro (*note Storage Layout::).
+ You must specify an integral mode, or `VOIDmode' if no save area
+ is needed for a particular type of save (either because no save is
+ needed or because a machine-specific save area can be used).
+ Operand 0 is the stack pointer and operand 1 is the save area for
+ restore operations. If `save_stack_block' is defined, operand 0
+ must not be `VOIDmode' since these saves can be arbitrarily nested.
+
+ A save area is a `mem' that is at a constant offset from
+ `virtual_stack_vars_rtx' when the stack pointer is saved for use by
+ nonlocal gotos and a `reg' in the other two cases.
+
+`allocate_stack'
+ Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 1
+ from the stack pointer to create space for dynamically allocated
+ data.
+
+ Store the resultant pointer to this space into operand 0. If you
+ are allocating space from the main stack, do this by emitting a
+ move insn to copy `virtual_stack_dynamic_rtx' to operand 0. If
+ you are allocating the space elsewhere, generate code to copy the
+ location of the space to operand 0. In the latter case, you must
+ ensure this space gets freed when the corresponding space on the
+ main stack is free.
+
+ Do not define this pattern if all that must be done is the
+ subtraction. Some machines require other operations such as stack
+ probes or maintaining the back chain. Define this pattern to emit
+ those operations in addition to updating the stack pointer.
+
+`probe'
+ Some machines require instructions to be executed after space is
+ allocated from the stack, for example to generate a reference at
+ the bottom of the stack.
+
+ If you need to emit instructions before the stack has been
+ adjusted, put them into the `allocate_stack' pattern. Otherwise,
+ define this pattern to emit the required instructions.
+
+ No operands are provided.
+
+`check_stack'
+ If stack checking cannot be done on your system by probing the
+ stack with a load or store instruction (*note 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.
+
+`nonlocal_goto'
+ Emit code to generate a non-local goto, e.g., a jump from one
+ function to a label in an outer function. This pattern has four
+ arguments, each representing a value to be used in the jump. The
+ first argument is to be loaded into the frame pointer, the second
+ is the address to branch to (code to dispatch to the actual label),
+ the third is the address of a location where the stack is saved,
+ and the last is the address of the label, to be placed in the
+ location for the incoming static chain.
+
+ On most machines you need not define this pattern, since GCC will
+ already generate the correct code, which is to load the frame
+ pointer and static chain, restore the stack (using the
+ `restore_stack_nonlocal' pattern, if defined), and jump indirectly
+ to the dispatcher. You need only define this pattern if this code
+ will not work on your machine.
+
+`nonlocal_goto_receiver'
+ This pattern, if defined, contains code needed at the target of a
+ nonlocal goto after the code already generated by GCC. You will
+ not normally need to define this pattern. A typical reason why
+ you might need this pattern is if some value, such as a pointer to
+ a global table, must be restored when the frame pointer is
+ restored. Note that a nonlocal goto only occurs within a
+ unit-of-translation, so a global table pointer that is shared by
+ all functions of a given module need not be restored. There are
+ no arguments.
+
+`exception_receiver'
+ This pattern, if defined, contains code needed at the site of an
+ exception handler that isn't needed at the site of a nonlocal
+ goto. You will not normally need to define this pattern. A
+ typical reason why you might need this pattern is if some value,
+ such as a pointer to a global table, must be restored after
+ control flow is branched to the handler of an exception. There
+ are no arguments.
+
+`builtin_setjmp_setup'
+ This pattern, if defined, contains additional code needed to
+ initialize the `jmp_buf'. You will not normally need to define
+ this pattern. A typical reason why you might need this pattern is
+ if some value, such as a pointer to a global table, must be
+ restored. Though it is preferred that the pointer value be
+ recalculated if possible (given the address of a label for
+ instance). The single argument is a pointer to the `jmp_buf'.
+ Note that the buffer is five words long and that the first three
+ are normally used by the generic mechanism.
+
+`builtin_setjmp_receiver'
+ This pattern, if defined, contains code needed at the site of an
+ 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 table, must be restored. It takes one
+ argument, which is the label to which builtin_longjmp transfered
+ control; this pattern may be emitted at a small offset from that
+ label.
+
+`builtin_longjmp'
+ This pattern, if defined, performs the entire action of the
+ longjmp. You will not normally need to define this pattern unless
+ you also define `builtin_setjmp_setup'. The single argument is a
+ pointer to the `jmp_buf'.
+
+`eh_return'
+ This pattern, if defined, affects the way `__builtin_eh_return',
+ and thence the call frame exception handling library routines, are
+ built. It is intended to handle non-trivial actions needed along
+ the abnormal return path.
+
+ The pattern takes two arguments. The first is an offset to be
+ applied to the stack pointer. It will have been copied to some
+ appropriate location (typically `EH_RETURN_STACKADJ_RTX') which
+ will survive until after reload to when the normal epilogue is
+ generated. The second argument is the address of the exception
+ handler to which the function should return. This will normally
+ need to copied by the pattern to some special register or memory
+ location.
+
+ This pattern only needs to be defined if call frame exception
+ handling is to be used, and simple moves involving
+ `EH_RETURN_STACKADJ_RTX' and `EH_RETURN_HANDLER_RTX' are not
+ sufficient.
+
+`prologue'
+ This pattern, if defined, emits RTL for entry to a function. The
+ function entry is responsible for setting up the stack frame,
+ initializing the frame pointer register, saving callee saved
+ registers, etc.
+
+ Using a prologue pattern is generally preferred over defining
+ `TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the
+ prologue.
+
+ The `prologue' pattern is particularly useful for targets which
+ perform instruction scheduling.
+
+`epilogue'
+ This pattern emits RTL for exit from a function. The function
+ exit is responsible for deallocating the stack frame, restoring
+ callee saved registers and emitting the return instruction.
+
+ Using an epilogue pattern is generally preferred over defining
+ `TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the
+ epilogue.
+
+ The `epilogue' pattern is particularly useful for targets which
+ perform instruction scheduling or which have delay slots for their
+ return instruction.
+
+`sibcall_epilogue'
+ This pattern, if defined, emits RTL for exit from a function
+ without the final branch back to the calling function. This
+ pattern will be emitted before any sibling call (aka tail call)
+ sites.
+
+ The `sibcall_epilogue' pattern must not clobber any arguments used
+ for parameter passing or any stack slots for arguments passed to
+ the current function.
+
+`trap'
+ This pattern, if defined, signals an error, typically by causing
+ some kind of signal to be raised. Among other places, it is used
+ by the Java front end to signal `invalid array index' exceptions.
+
+`conditional_trap'
+ Conditional trap instruction. Operand 0 is a piece of RTL which
+ performs a comparison. Operand 1 is the trap code, an integer.
+
+ A typical `conditional_trap' pattern looks like
+
+ (define_insn "conditional_trap"
+ [(trap_if (match_operator 0 "trap_operator"
+ [(cc0) (const_int 0)])
+ (match_operand 1 "const_int_operand" "i"))]
+ ""
+ "...")
+
+`prefetch'
+ This pattern, if defined, emits code for a non-faulting data
+ prefetch instruction. Operand 0 is the address of the memory to
+ prefetch. Operand 1 is a constant 1 if the prefetch is preparing
+ for a write to the memory address, or a constant 0 otherwise.
+ Operand 2 is the expected degree of temporal locality of the data
+ and is a value between 0 and 3, inclusive; 0 means that the data
+ has no temporal locality, so it need not be left in the cache
+ after the access; 3 means that the data has a high degree of
+ temporal locality and should be left in all levels of cache
+ possible; 1 and 2 mean, respectively, a low or moderate degree of
+ temporal locality.
+
+ Targets that do not support write prefetches or locality hints can
+ ignore the values of operands 1 and 2.
+
+`cycle_display'
+ This pattern, if present, will be emitted by the instruction
+ scheduler at the beginning of each new clock cycle. This can be
+ used for annotating the assembler output with cycle counts.
+ Operand 0 is a `const_int' that holds the clock cycle.
+
+
+\1f
+File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc
+
+9.9 When the Order of Patterns Matters
+======================================
+
+Sometimes an insn can match more than one instruction pattern. Then the
+pattern that appears first in the machine description is the one used.
+Therefore, more specific patterns (patterns that will match fewer
+things) and faster instructions (those that will produce better code
+when they do match) should usually go first in the description.
+
+ In some cases the effect of ordering the patterns can be used to hide
+a pattern when it is not valid. For example, the 68000 has an
+instruction for converting a fullword to floating point and another for
+converting a byte to floating point. An instruction converting an
+integer to floating point could match either one. We put the pattern
+to convert the fullword first to make sure that one will be used rather
+than the other. (Otherwise a large integer might be generated as a
+single-byte immediate quantity, which would not work.) Instead of
+using this pattern ordering it would be possible to make the pattern
+for convert-a-byte smart enough to deal properly with any constant
+value.
+
+\1f
+File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc
+
+9.10 Interdependence of Patterns
+================================
+
+Every machine description must have a named pattern for each of the
+conditional branch names `bCOND'. The recognition template must always
+have the form
+
+ (set (pc)
+ (if_then_else (COND (cc0) (const_int 0))
+ (label_ref (match_operand 0 "" ""))
+ (pc)))
+
+In addition, every machine description must have an anonymous pattern
+for each of the possible reverse-conditional branches. Their templates
+look like
+
+ (set (pc)
+ (if_then_else (COND (cc0) (const_int 0))
+ (pc)
+ (label_ref (match_operand 0 "" ""))))
+
+They are necessary because jump optimization can turn direct-conditional
+branches into reverse-conditional branches.
+
+ It is often convenient to use the `match_operator' construct to
+reduce the number of patterns that must be specified for branches. For
+example,
+
+ (define_insn ""
+ [(set (pc)
+ (if_then_else (match_operator 0 "comparison_operator"
+ [(cc0) (const_int 0)])
+ (pc)
+ (label_ref (match_operand 1 "" ""))))]
+ "CONDITION"
+ "...")
+
+ 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
+
+ (set (match_operand:SI 0 ...)
+ (extend:SI (match_operand:HI 1 ...)))
+
+ (set (match_operand:SI 0 ...)
+ (extend:SI (match_operand:QI 1 ...)))
+
+Constant integers do not specify a machine mode, so an instruction to
+extend a constant value could match either pattern. The pattern it
+actually will match is the one that appears first in the file. For
+correct results, this must be the one for the widest possible mode
+(`HImode', here). If the pattern matches the `QImode' instruction, the
+results will be incorrect if the constant value does not actually fit
+that mode.
+
+ Such instructions to extend constants are rarely generated because
+they are optimized away, but they do occasionally happen in nonoptimized
+compilations.
+
+ If a constraint in a pattern allows a constant, the reload pass may
+replace a register with a constant permitted by the constraint in some
+cases. Similarly for memory references. Because of this substitution,
+you should not provide separate patterns for increment and decrement
+instructions. Instead, they should be generated from the same pattern
+that supports register-register add insns by examining the operands and
+generating the appropriate machine instruction.
+
+\1f
+File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc
+
+9.11 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 `next_cc0_user (insn)'. (The variable
+`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 `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 `NOTICE_UPDATE_CC' to do `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 `(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.
+
+ 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 `(cc0)', the set and
+use of the condition code must be adjacent (separated only by `note'
+insns) allowing flags in `cc_status' to be used. (*Note Condition
+Code::.) Also, the comparison and branch insns can be located from
+each other by using the functions `prev_cc0_setter' and `next_cc0_user'.
+
+ However, this is not true on machines that do not use `(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 `MODE_CC'. Normally, it will be `CCmode'. If
+additional modes are required (as for the add example mentioned above in
+the Sparc), define the macro `EXTRA_CC_MODES' to list the additional
+modes required (*note Condition Code::). Also define `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 `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
+
+ (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)))]
+ ""
+ "...")
+
+ The `SELECT_CC_MODE' macro on the Sparc returns `CC_NOOVmode' for
+comparisons whose argument is a `plus'.
+
+\1f
+File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc
+
+9.12 Defining Looping Instruction Patterns
+==========================================
+
+Some machines have special jump instructions that can be utilised to
+make loops more efficient. A common example is the 68000 `dbra'
+instruction which performs a decrement of a register and a branch if the
+result was greater than zero. Other machines, in particular digital
+signal processors (DSPs), have special block repeat instructions to
+provide low-overhead loop support. For example, the TI TMS320C3x/C4x
+DSPs have a block repeat instruction that loads special registers to
+mark the top and end of a loop and to count the number of loop
+iterations. This avoids the need for fetching and executing a
+`dbra'-like instruction and avoids pipeline stalls associated with the
+jump.
+
+ GCC has three special named patterns to support low overhead looping.
+They are `decrement_and_branch_until_zero', `doloop_begin', and
+`doloop_end'. The first pattern, `decrement_and_branch_until_zero', is
+not emitted during RTL generation but may be emitted during the
+instruction combination phase. This requires the assistance of the
+loop optimizer, using information collected during strength reduction,
+to reverse a loop to count down to zero. Some targets also require the
+loop optimizer to add a `REG_NONNEG' note to indicate that the
+iteration count is always positive. This is needed if the target
+performs a signed loop termination test. For example, the 68000 uses a
+pattern similar to the following for its `dbra' instruction:
+
+ (define_insn "decrement_and_branch_until_zero"
+ [(set (pc)
+ (if_then_else
+ (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am")
+ (const_int -1))
+ (const_int 0))
+ (label_ref (match_operand 1 "" ""))
+ (pc)))
+ (set (match_dup 0)
+ (plus:SI (match_dup 0)
+ (const_int -1)))]
+ "find_reg_note (insn, REG_NONNEG, 0)"
+ "...")
+
+ Note that since the insn is both a jump insn and has an output, it
+must deal with its own reloads, hence the `m' constraints. Also note
+that since this insn is generated by the instruction combination phase
+combining two sequential insns together into an implicit parallel insn,
+the iteration counter needs to be biased by the same amount as the
+decrement operation, in this case -1. Note that the following similar
+pattern will not be matched by the combiner.
+
+ (define_insn "decrement_and_branch_until_zero"
+ [(set (pc)
+ (if_then_else
+ (ge (match_operand:SI 0 "general_operand" "+d*am")
+ (const_int 1))
+ (label_ref (match_operand 1 "" ""))
+ (pc)))
+ (set (match_dup 0)
+ (plus:SI (match_dup 0)
+ (const_int -1)))]
+ "find_reg_note (insn, REG_NONNEG, 0)"
+ "...")
+
+ The other two special looping patterns, `doloop_begin' and
+`doloop_end', are emitted by the loop optimizer for certain
+well-behaved loops with a finite number of loop iterations using
+information collected during strength reduction.
+
+ The `doloop_end' pattern describes the actual looping instruction
+(or the implicit looping operation) and the `doloop_begin' pattern is
+an optional companion pattern that can be used for initialization
+needed for some low-overhead looping instructions.
+
+ Note that some machines require the actual looping instruction to be
+emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting
+the true RTL for a looping instruction at the top of the loop can cause
+problems with flow analysis. So instead, a dummy `doloop' insn is
+emitted at the end of the loop. The machine dependent reorg pass checks
+for the presence of this `doloop' insn and then searches back to the
+top of the loop, where it inserts the true looping insn (provided there
+are no instructions in the loop which would cause problems). Any
+additional labels can be emitted at this point. In addition, if the
+desired special iteration counter register was not allocated, this
+machine dependent reorg pass could emit a traditional compare and jump
+instruction pair.
+
+ The essential difference between the
+`decrement_and_branch_until_zero' and the `doloop_end' patterns is that
+the loop optimizer allocates an additional pseudo register for the
+latter as an iteration counter. This pseudo register cannot be used
+within the loop (i.e., general induction variables cannot be derived
+from it), however, in many cases the loop induction variable may become
+redundant and removed by the flow pass.