--- gcc/gcc.info-12 2018/04/24 17:51:24 1.1 +++ gcc/gcc.info-12 2018/04/24 18:01:49 1.1.1.4 @@ -1,1150 +1,1054 @@ -This is Info file gcc.info, produced by Makeinfo-1.43 from the input +This is Info file gcc.info, produced by Makeinfo-1.49 from the input file gcc.texi. This file documents the use and the internals of the GNU compiler. Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc. - Permission is granted to make and distribute verbatim copies of -this manual provided the copyright notice and this permission notice -are preserved on all copies. + Permission is granted to make and distribute verbatim copies of this +manual provided the copyright notice and this permission notice are +preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also -that the section entitled "GNU General Public License" is included -exactly as in the original, and provided that the entire resulting -derived work is distributed under the terms of a permission notice -identical to this one. +that the sections entitled "GNU General Public License" and "Protect +Your Freedom--Fight `Look And Feel'" are included exactly as in the +original, and provided that the entire resulting derived work is +distributed under the terms of a permission notice identical to this +one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified -versions, except that the section entitled "GNU General Public -License" and this permission notice may be included in translations -approved by the Free Software Foundation instead of in the original -English. +versions, except that the sections entitled "GNU General Public +License" and "Protect Your Freedom--Fight `Look And Feel'", and this +permission notice, may be included in translations approved by the Free +Software Foundation instead of in the original English.  -File: gcc.info, Node: Storage Layout, Next: Type Layout, Prev: Run-time Target, Up: Machine Macros +File: gcc.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc -Storage Layout -============== +Standard Names for Patterns Used in Generation +============================================== - Note that the definitions of the macros in this table which are -sizes or alignments measured in bits do not need to be constant. They -can be C expressions that refer to static variables, such as the -`target_flags'. *Note Run-time Target::. - -`BITS_BIG_ENDIAN' - Define this macro to be the value 1 if the most significant bit - in a byte has the lowest number; otherwise define it to be the - value zero. This means that bit-field instructions count from - the most significant bit. If the machine has no bit-field - instructions, this macro is irrelevant. - - This macro does not affect the way structure fields are packed - into bytes or words; that is controlled by `BYTES_BIG_ENDIAN'. - -`BYTES_BIG_ENDIAN' - Define this macro to be 1 if the most significant byte in a word - has the lowest number. - -`WORDS_BIG_ENDIAN' - Define this macro to be 1 if, in a multiword object, the most - significant word has the lowest number. - -`BITS_PER_UNIT' - Number of bits in an addressable storage unit (byte); normally 8. - -`BITS_PER_WORD' - Number of bits in a word; normally 32. - -`MAX_BITS_PER_WORD' - Maximum number of bits in a word. If this is undefined, the - default is `BITS_PER_WORD'. Otherwise, it is the constant value - that is the largest value that `BITS_PER_WORD' can have at - run-time. - -`UNITS_PER_WORD' - Number of storage units in a word; normally 4. - -`POINTER_SIZE' - Width of a pointer, in bits. - -`PARM_BOUNDARY' - Normal alignment required for function parameters on the stack, in - bits. All stack parameters receive least this much alignment - regardless of data type. On most machines, this is the same as - the size of an integer. - -`STACK_BOUNDARY' - Define this macro if you wish to preserve a certain alignment for - the stack pointer. The definition is a C expression for the - desired alignment (measured in bits). - - If `PUSH_ROUNDING' is not defined, the stack will always be - aligned to the specified boundary. If `PUSH_ROUNDING' is defined - and specifies a less strict alignment than `STACK_BOUNDARY', the - stack may be momentarily unaligned while pushing arguments. - -`FUNCTION_BOUNDARY' - Alignment required for a function entry point, in bits. - -`BIGGEST_ALIGNMENT' - Biggest alignment that any data type can require on this machine, - in bits. - -`BIGGEST_FIELD_ALIGNMENT' - Biggest alignment that any structure field can require on this - machine, in bits. - -`MAX_OFILE_ALIGNMENT' - Biggest alignment supported by the object file format of this - machine. Use this macro to limit the alignment which can be - specified using the `__attribute__ ((aligned (N)))' construct. - If not defined, the default value is `BIGGEST_ALIGNMENT'. - -`DATA_ALIGNMENT (TYPE, BASIC-ALIGN)' - If defined, a C expression to compute the alignment for a static - variable. TYPE is the data type, and BASIC-ALIGN is the - alignment that the object would ordinarily have. The value of - this macro is used instead of that alignment to align the object. - - If this macro is not defined, then BASIC-ALIGN is used. - - One use of this macro is to increase alignment of medium-size - data to make it all fit in fewer cache lines. Another is to - cause character arrays to be word-aligned so that `strcpy' calls - that copy constants to character arrays can be done inline. - -`CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN)' - If defined, a C expression to compute the alignment given to a - constant that is being placed in memory. CONSTANT is the - constant and BASIC-ALIGN is the alignment that the object would - ordinarily have. The value of this macro is used instead of that - alignment to align the object. - - If this macro is not defined, then BASIC-ALIGN is used. - - The typical use of this macro is to increase alignment for string - constants to be word aligned so that `strcpy' calls that copy - constants can be done inline. - -`EMPTY_FIELD_BOUNDARY' - Alignment in bits to be given to a structure bit field that - follows an empty field such as `int : 0;'. - -`STRUCTURE_SIZE_BOUNDARY' - Number of bits which any structure or union's size must be a - multiple of. Each structure or union's size is rounded up to a - multiple of this. - - If you do not define this macro, the default is the same as - `BITS_PER_UNIT'. - -`STRICT_ALIGNMENT' - Define this if instructions will fail to work if given data not - on the nominal alignment. If instructions will merely go slower - in that case, do not define this macro. - -`PCC_BITFIELD_TYPE_MATTERS' - Define this if you wish to imitate the way many other C compilers - handle alignment of bitfields and the structures that contain - them. - - The behavior is that the type written for a bitfield (`int', - `short', or other integer type) imposes an alignment for the - entire structure, as if the structure really did contain an - ordinary field of that type. In addition, the bitfield is placed - within the structure so that it would fit within such a field, - not crossing a boundary for it. - - Thus, on most machines, a bitfield whose type is written as `int' - would not cross a four-byte boundary, and would force four-byte - alignment for the whole structure. (The alignment used may not - be four bytes; it is controlled by the other alignment - parameters.) - - If the macro is defined, its definition should be a C expression; - a nonzero value for the expression enables this behavior. - - Note that if this macro is not defined, or its value is zero, some - bitfields may cross more than one alignment boundary. The - compiler can support such references if there are `insv', `extv', - and `extzv' insns that can directly reference memory. - - The other known way of making bitfields work is to define - `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then - every structure can be accessed with fullwords. - - Unless the machine has bitfield instructions or you define - `STRUCTURE_SIZE_BOUNDARY' that way, you must define - `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. - -`BITFIELD_NBYTES_LIMITED' - Like PCC_BITFIELD_TYPE_MATTERS except that its effect is limited - to aligning a bitfield within the structure. - -`ROUND_TYPE_SIZE (STRUCT, SIZE, ALIGN)' - Define this macro as an expression for the overall size of a - structure (given by STRUCT as a tree node) when the size computed - from the fields is SIZE and the alignment is ALIGN. - - The default is to round SIZE up to a multiple of ALIGN. - -`ROUND_TYPE_ALIGN (STRUCT, COMPUTED, SPECIFIED)' - Define this macro as an expression for the alignment of a - structure (given by STRUCT as a tree node) if the alignment - computed in the usual way is COMPUTED and the alignment - explicitly specified was SPECIFIED. - - The default is to use SPECIFIED if it is larger; otherwise, use - the smaller of COMPUTED and `BIGGEST_ALIGNMENT' - -`MAX_FIXED_MODE_SIZE' - An integer expression for the size in bits of the largest integer - machine mode that should actually be used. All integer machine - modes of this size or smaller can be used for structures and - unions with the appropriate sizes. If this macro is undefined, - `GET_MODE_BITSIZE (DImode)' is assumed. - -`CHECK_FLOAT_VALUE (MODE, VALUE)' - A C statement to validate the value VALUE (of type `double') for - mode MODE. This means that you check whether VALUE fits within - the possible range of values for mode MODE on this target - machine. The mode MODE is always `SFmode' or `DFmode'. - - If VALUE is not valid, you should call `error' to print an error - message and then assign some valid value to VALUE. Allowing an - invalid value to go through the compiler can produce incorrect - assembler code which may even cause Unix assemblers to crash. - - This macro need not be defined if there is no work for it to do. - -`TARGET_FLOAT_FORMAT' - A code distinguishing the floating point format of the target - machine. There are three defined values: - - `IEEE_FLOAT_FORMAT' - This code indicates IEEE floating point. It is the default; - there is no need to define this macro when the format is - IEEE. - - `VAX_FLOAT_FORMAT' - This code indicates the peculiar format used on the Vax. - - `UNKNOWN_FLOAT_FORMAT' - This code indicates any other format. - - The value of this macro is compared with `HOST_FLOAT_FORMAT' - (*note Config::.) to determine whether the target machine has the - same format as the host machine. If any other formats are - actually in use on supported machines, new codes should be - defined for them. + 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 in 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. The effect on the rest of the register is undefined. + + This class of patterns is special in several ways. First of all, + each of these names *must* be defined, because there is no other + way to copy a datum from one place to another. + + 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. Look in `spur.md' to see how + the requirement can be satisfied. + + 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 reload. + But this is impossible during and after reload. If there are + cases needing scratch registers 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 constraints on a `moveM' 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 `moveM' 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 `moveM' + 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 `moveM' 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::.. + +`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. + +`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. + +`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. + +`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', `lshlM3', `lshrM3', `rotlM3', `rotrM3' + Other shift and rotate instructions, analogous to the `ashlM3' + instructions. + + Logical and arithmetic left shift are the same. Machines that do + not allow negative shift counts often have only one instruction for + shifting left. On such machines, you should define a pattern named + `ashlM3' and leave `lshlM3' undefined. + +`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. + + 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. + + These patterns need not give special consideration to the + possibility that the source and destination strings might overlap. + +`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. + +`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. + +`truncMN' + 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. + +`extendMN' + 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_extendMN' + 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. + +`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 `sCOND' patterns. + +`call' + Subroutine call instruction returning no value. Operand 0 is the + function to call; operand 1 is the number of bytes of arguments + pushed (in mode `SImode', except it is normally 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 non-zero. 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 non-zero, the use of + these patterns increases the number of functions for which the + frame pointer can be eliminated, if desired. + +`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 non-zero 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. + +`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' is defined 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. + +`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' operate + similarly 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 is the mode of operand 0. 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 operand 0 from the stack pointer to create space for for + dynamically allocated data. + + Do not define this pattern if all that must be done is the + subtraction. On 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.  -File: gcc.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Machine Macros +File: gcc.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc -Layout of Source Language Data Types -==================================== +When the Order of Patterns Matters +================================== - These macros define the sizes and other characteristics of the -standard basic data types used in programs being compiled. Unlike the -macros in the previous section, these apply to specific features of C -and related languages, rather than to fundamental aspects of storage -layout. - -`INT_TYPE_SIZE' - A C expression for the size in bits of the type `int' on the - target machine. If you don't define this, the default is one - word. - -`SHORT_TYPE_SIZE' - A C expression for the size in bits of the type `short' on the - target machine. If you don't define this, the default is half a - word. (If this would be less than one storage unit, it is - rounded up to one unit.) - -`LONG_TYPE_SIZE' - A C expression for the size in bits of the type `long' on the - target machine. If you don't define this, the default is one - word. - -`LONG_LONG_TYPE_SIZE' - A C expression for the size in bits of the type `long long' on the - target machine. If you don't define this, the default is two - words. - -`CHAR_TYPE_SIZE' - A C expression for the size in bits of the type `char' on the - target machine. If you don't define this, the default is one - quarter of a word. (If this would be less than one storage unit, - it is rounded up to one unit.) - -`FLOAT_TYPE_SIZE' - A C expression for the size in bits of the type `float' on the - target machine. If you don't define this, the default is one - word. - -`DOUBLE_TYPE_SIZE' - A C expression for the size in bits of the type `double' on the - target machine. If you don't define this, the default is two - words. - -`LONG_DOUBLE_TYPE_SIZE' - A C expression for the size in bits of the type `long double' on - the target machine. If you don't define this, the default is two - words. - -`DEFAULT_SIGNED_CHAR' - An expression whose value is 1 or 0, according to whether the type - `char' should be signed or unsigned by default. The user can - always override this default with the options `-fsigned-char' and - `-funsigned-char'. - -`DEFAULT_SHORT_ENUMS' - A C expression to determine whether to give an `enum' type only - as many bytes as it takes to represent the range of possible - values of that type. A nonzero value means to do that; a zero - value means all `enum' types should be allocated like `int'. - - If you don't define the macro, the default is 0. - -`SIZE_TYPE' - A C expression for a string describing the name of the data type - to use for size values. The typedef name `size_t' is defined - using the contents of the string. - - The string can contain more than one keyword. If so, separate - them with spaces, and write first any length keyword, then - `unsigned' if appropriate, and finally `int'. The string must - exactly match one of the data type names defined in the function - `init_decl_processing' in the file `c-decl.c'. You may not omit - `int' or change the order--that would cause the compiler to crash - on startup. - - If you don't define this macro, the default is `"long unsigned - int"'. - -`PTRDIFF_TYPE' - A C expression for a string describing the name of the data type - to use for the result of subtracting two pointers. The typedef - name `ptrdiff_t' is defined using the contents of the string. See - `SIZE_TYPE' above for more information. - - If you don't define this macro, the default is `"long int"'. - -`WCHAR_TYPE' - A C expression for a string describing the name of the data type - to use for wide characters. The typedef name `wchar_t' is - defined using the contents of the string. See `SIZE_TYPE' above - for more information. - - If you don't define this macro, the default is `"int"'. - -`WCHAR_TYPE_SIZE' - A C expression for the size in bits of the data type for wide - characters. This is used in `cpp', which cannot make use of - `WCHAR_TYPE'. - -`OBJC_INT_SELECTORS' - Define this macro if the type of Objective C selectors should be - `int'. - - If this macro is not defined, then selectors should have the type - `struct objc_selector *'. - -`OBJC_NONUNIQUE_SELECTORS' - Define this macro if Objective C selector-references will be made - unique by the linker (this is the default). In this case, each - selector-reference will be given a separate assembler label. - Otherwise, the selector-references will be gathered into an array - with a single assembler label. - -`MULTIBYTE_CHARS' - Define this macro to enable support for multibyte characters in - the input to GNU CC. This requires that the host system support - the ANSI C library functions for converting multibyte characters - to wide characters. - -`TARGET_BELL' - A C constant expression for the integer value for escape sequence - `\a'. - -`TARGET_BS' -`TARGET_TAB' -`TARGET_NEWLINE' - C constant expressions for the integer values for escape sequences - `\b', `\t' and `\n'. - -`TARGET_VT' -`TARGET_FF' -`TARGET_CR' - C constant expressions for the integer values for escape sequences - `\v', `\f' and `\r'. + 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.  -File: gcc.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Machine Macros +File: gcc.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc -Register Usage -============== +Interdependence of Patterns +=========================== - This section explains how to describe what registers the target -machine has, and how (in general) they can be used. - - The description of which registers a specific instruction can use is -done with register classes; see *Note Register Classes::. For -information on using registers to access a stack frame, see *Note -Frame Registers::. For passing values in registers, see *Note -Register Arguments::. For returning values in registers, see *Note -Scalar Return::. - -* Menu: - -* Register Basics:: Number and kinds of registers. -* Allocation Order:: Order in which registers are allocated. -* Values in Registers:: What kinds of values each reg can hold. -* Leaf Functions:: Renumbering registers for leaf functions. -* Stack Registers:: Handling a register stack such as 80387. -* Obsolete Register Macros:: Macros formerly used for the 80387. - - -File: gcc.info, Node: Register Basics, Next: Allocation Order, Up: Registers - -Basic Characteristics of Registers ----------------------------------- - -`FIRST_PSEUDO_REGISTER' - Number of hardware registers known to the compiler. They receive - numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first - pseudo register's number really is assigned the number - `FIRST_PSEUDO_REGISTER'. - -`FIXED_REGISTERS' - An initializer that says which registers are used for fixed - purposes all throughout the compiled code and are therefore not - available for general allocation. These would include the stack - pointer, the frame pointer (except on machines where that can be - used as a general register when no frame pointer is needed), the - program counter on machines where that is considered one of the - addressable registers, and any other numbered register with a - standard use. - - This information is expressed as a sequence of numbers, separated - by commas and surrounded by braces. The Nth number is 1 if - register N is fixed, 0 otherwise. - - The table initialized from this macro, and the table initialized - by the following one, may be overridden at run time either - automatically, by the actions of the macro - `CONDITIONAL_REGISTER_USAGE', or by the user with the command - options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'. - -`CALL_USED_REGISTERS' - Like `FIXED_REGISTERS' but has 1 for each register that is - clobbered (in general) by function calls as well as for fixed - registers. This macro therefore identifies the registers that - are not available for general allocation of values that must live - across function calls. - - If a register has 0 in `CALL_USED_REGISTERS', the compiler - automatically saves it on function entry and restores it on - function exit, if the register is used within the function. - -`CONDITIONAL_REGISTER_USAGE' - Zero or more C statements that may conditionally modify two - variables `fixed_regs' and `call_used_regs' (both of type `char - []') after they have been initialized from the two preceding - macros. - - This is necessary in case the fixed or call-clobbered registers - depend on target flags. - - You need not define this macro if it has no work to do. - - If the usage of an entire class of registers depends on the target - flags, you may indicate this to GCC by using this macro to modify - `fixed_regs' and `call_used_regs' to 1 for each of the registers - in the classes which should not be used by GCC. Also define the - macro `REG_CLASS_FROM_LETTER' to return `NO_REGS' if it is called - with a letter for a class that shouldn't be used. - - (However, if this class is not included in `GENERAL_REGS' and all - of the insn patterns whose constraints permit this class are - controlled by target switches, then GCC will automatically avoid - using these registers when the target switches are opposed to - them.) - -`NON_SAVING_SETJMP' - If this macro is defined and has a nonzero value, it means that - `setjmp' and related functions fail to save the registers, or that - `longjmp' fails to restore them. To compensate, the compiler - avoids putting variables in registers in functions that use - `setjmp'. + 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. You must ensure that the +predicate permits all objects allowed by the constraints to prevent the +compiler from crashing. + + 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.  -File: gcc.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers - -Order of Allocation of Registers --------------------------------- - -`REG_ALLOC_ORDER' - If defined, an initializer for a vector of integers, containing - the numbers of hard registers in the order in which GNU CC should - prefer to use them (from most preferred to least). - - If this macro is not defined, registers are used lowest numbered - first (all else being equal). - - One use of this macro is on machines where the highest numbered - registers must always be saved and the save-multiple-registers - instruction supports only sequences of consecutive registers. On - such machines, define `REG_ALLOC_ORDER' to be an initializer that - lists the highest numbered allocatable register first. - -`ORDER_REGS_FOR_LOCAL_ALLOC' - A C statement (sans semicolon) to choose the order in which to - allocate hard registers for pseudo-registers local to a basic - block. - - Store the desired order of registers in the array - `reg_alloc_order'. Element 0 should be the register to allocate - first; element 1, the next register; and so on. - - The macro body should not assume anything about the contents of - `reg_alloc_order' before execution of the macro. +File: gcc.info, Node: Jump Patterns, Next: Insn Canonicalizations, Prev: Dependent Patterns, Up: Machine Desc - On most machines, it is not necessary to define this macro. +Defining Jump Instruction Patterns +================================== - -File: gcc.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers - -How Values Fit in Registers ---------------------------- + For most machines, GNU CC 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 GNU CC 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 `EXTRA_CC_NAMES' +to list the names of those modes and `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)))] + "" + "...") - This section discusses the macros that describe which kinds of -values (specifically, which machine modes) each register can hold, and -how many consecutive registers are needed for a given mode. - -`HARD_REGNO_NREGS (REGNO, MODE)' - A C expression for the number of consecutive hard registers, - starting at register number REGNO, required to hold a value of - mode MODE. - - On a machine where all registers are exactly one word, a suitable - definition of this macro is - - #define HARD_REGNO_NREGS(REGNO, MODE) \ - ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \ - / UNITS_PER_WORD)) - -`HARD_REGNO_MODE_OK (REGNO, MODE)' - A C expression that is nonzero if it is permissible to store a - value of mode MODE in hard register number REGNO (or in several - registers starting with that one). For a machine where all - registers are equivalent, a suitable definition is - - #define HARD_REGNO_MODE_OK(REGNO, MODE) 1 - - It is not necessary for this macro to check for the numbers of - fixed registers, because the allocation mechanism considers them - to be always occupied. - - On some machines, double-precision values must be kept in even/odd - register pairs. The way to implement that is to define this macro - to reject odd register numbers for such modes. - - The minimum requirement for a mode to be OK in a register is that - the `movMODE' instruction pattern support moves between the - register and any other hard register for which the mode is OK; - and that moving a value into the register and back out not alter - it. - - Since the same instruction used to move `SImode' will work for all - narrower integer modes, it is not necessary on any machine for - `HARD_REGNO_MODE_OK' to distinguish between these modes, provided - you define patterns `movhi', etc., to take advantage of this. - This is useful because of the interaction between - `HARD_REGNO_MODE_OK' and `MODES_TIEABLE_P'; it is very desirable - for all integer modes to be tieable. - - Many machines have special registers for floating point - arithmetic. Often people assume that floating point machine - modes are allowed only in floating point registers. This is not - true. Any registers that can hold integers can safely *hold* a - floating point machine mode, whether or not floating arithmetic - can be done on it in those registers. Integer move instructions - can be used to move the values. - - On some machines, though, the converse is true: fixed-point - machine modes may not go in floating registers. This is true if - the floating registers normalize any value stored in them, - because storing a non-floating value there would garble it. In - this case, `HARD_REGNO_MODE_OK' should reject fixed-point machine - modes in floating registers. But if the floating registers do - not automatically normalize, if you can store any bit pattern in - one and retrieve it unchanged without a trap, then any machine - mode may go in a floating register and this macro should say so. - - The primary significance of special floating registers is rather - that they are the registers acceptable in floating point - arithmetic instructions. However, this is of no concern to - `HARD_REGNO_MODE_OK'. You handle it by writing the proper - constraints for those instructions. - - On some machines, the floating registers are especially slow to - access, so that it is better to store a value in a stack frame - than in such a register if floating point arithmetic is not being - done. As long as the floating registers are not in class - `GENERAL_REGS', they will not be used unless some pattern's - constraint asks for one. - -`MODES_TIEABLE_P (MODE1, MODE2)' - A C expression that is nonzero if it is desirable to choose - register allocation so as to avoid move instructions between a - value of mode MODE1 and a value of mode MODE2. - - If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R, - MODE2)' are ever different for any R, then `MODES_TIEABLE_P - (MODE1, MODE2)' must be zero. + The `SELECT_CC_MODE' macro on the Sparc returns `CC_NOOVmode' for +comparisons whose argument is a `plus'.  -File: gcc.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers +File: gcc.info, Node: Insn Canonicalizations, Next: Peephole Definitions, Prev: Jump Patterns, Up: Machine Desc -Handling Leaf Functions ------------------------ +Canonicalization of Instructions +================================ - On some machines, a leaf function (i.e., one which make no calls) -can run more efficiently if it does not make its own register window. -Often this means it is required to receive its arguments in the -registers where they are passed by the caller, instead of the -registers where they would normally arrive. Also, the leaf function -may use only those registers for its own variables and temporaries. - - GNU CC assigns register numbers before it knows whether the -function is suitable for leaf function treatment. So it needs to -renumber the registers in order to output a leaf function. The -following macros accomplish this. - -`LEAF_REGISTERS' - A C initializer for a vector, indexed by hard register number, - which contains 1 for a register that is allowable in a candidate - for leaf function treatment. - - If leaf function treatment involves renumbering the registers, - then the registers marked here should be the ones before - renumbering--those that GNU CC would ordinarily allocate. The - registers which will actually be used in the assembler code, - after renumbering, should not be marked with 1 in this vector. - - Define this macro only if the target machine offers a way to - optimize the treatment of leaf functions. - -`LEAF_REG_REMAP (REGNO)' - A C expression whose value is the register number to which REGNO - should be renumbered, when a function is treated as a leaf - function. - - If REGNO is a register number which should not appear in a leaf - function before renumbering, then the expression should yield -1, - which will cause the compiler to abort. - - Define this macro only if the target machine offers a way to - optimize the treatment of leaf functions, and registers need to - be renumbered to do this. - -`REG_LEAF_ALLOC_ORDER' - If defined, an initializer for a vector of integers, containing - the numbers of hard registers in the order in which the GNU CC - should prefer to use them (from most preferred to least) in a - leaf function. If this macro is not defined, REG_ALLOC_ORDER is - used for both non-leaf and leaf-functions. - - Normally, it is necessary for `FUNCTION_PROLOGUE' and -`FUNCTION_EPILOGUE' to treat leaf functions specially. The C variable -`leaf_function' is nonzero for such a function. + There are often cases where multiple RTL expressions could represent +an operation performed by a single machine instruction. This situation +is most commonly encountered with logical, branch, and +multiply-accumulate instructions. In such cases, the compiler attempts +to convert these multiple RTL expressions into a single canonical form +to reduce the number of insn patterns required. + + In addition to algebraic simplifications, following canonicalizations +are performed: + + * For commutative and comparison operators, a constant is always + made the second operand. If a machine only supports a constant as + the second operand, only patterns that match a constant in the + second operand need be supplied. + + For these operators, if only one operand is a `neg', `not', + `mult', `plus', or `minus' expression, it will be the first + operand. + + * For the `compare' operator, a constant is always the second operand + on machines where `cc0' is used (*note Jump Patterns::.). On other + machines, there are rare cases where the compiler might want to + construct a `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. + + An operand of `neg', `not', `mult', `plus', or `minus' is made the + first operand under the same conditions as above. + + * `(minus X (const_int N))' is converted to `(plus X (const_int + -N))'. + + * Within address computations (i.e., inside `mem'), a left shift is + converted into the appropriate multiplication by a power of two. + + De`Morgan's Law is used to move bitwise negation inside a bitwise + logical-and or logical-or operation. If this results in only one + operand being a `not' expression, it will be the first one. + + A machine that has an instruction that performs a bitwise + logical-and of one operand with the bitwise negation of the other + should specify the pattern for that instruction as + + (define_insn "" + [(set (match_operand:M 0 ...) + (and:M (not:M (match_operand:M 1 ...)) + (match_operand:M 2 ...)))] + "..." + "...") + + Similarly, a pattern for a "NAND" instruction should be written + + (define_insn "" + [(set (match_operand:M 0 ...) + (ior:M (not:M (match_operand:M 1 ...)) + (not:M (match_operand:M 2 ...))))] + "..." + "...") + + In both cases, it is not necessary to include patterns for the many + logically equivalent RTL expressions. + + * The only possible RTL expressions involving both bitwise + exclusive-or and bitwise negation are `(xor:M X) Y)' and `(not:M + (xor:M X Y))'. + + * The sum of three items, one of which is a constant, will only + appear in the form + + (plus:M (plus:M X Y) CONSTANT) + + * On machines that do not use `cc0', `(compare X (const_int 0))' + will be converted to X. + + * Equality comparisons of a group of bits (usually a single bit) + with zero will be written using `zero_extract' rather than the + equivalent `and' or `sign_extract' operations.  -File: gcc.info, Node: Stack Registers, Next: Obsolete Register Macros, Prev: Leaf Functions, Up: Registers - -Registers That Form a Stack ---------------------------- - - There are special features to handle computers where some of the -"registers" form a stack, as in the 80387 coprocessor for the 80386. -Stack registers are normally written by pushing onto the stack, and are -numbered relative to the top of the stack. - - Currently, GNU CC can only handle one group of stack-like -registers, and they must be consecutively numbered. - -`STACK_REGS' - Define this if the machine has any stack-like registers. - -`FIRST_STACK_REG' - The number of the first stack-like register. This one is the top - of the stack. - -`LAST_STACK_REG' - The number of the last stack-like register. This one is the - bottom of the stack. +File: gcc.info, Node: Peephole Definitions, Next: Expander Definitions, Prev: Insn Canonicalizations, Up: Machine Desc - -File: gcc.info, Node: Obsolete Register Macros, Prev: Stack Registers, Up: Registers - -Obsolete Macros for Controlling Register Usage ----------------------------------------------- - - These features do not work very well. They exist because they used -to be required to generate correct code for the 80387 coprocessor of -the 80386. They are no longer used by that machine description and -may be removed in a later version of the compiler. Don't use them! - -`OVERLAPPING_REGNO_P (REGNO)' - If defined, this is a C expression whose value is nonzero if hard - register number REGNO is an overlapping register. This means a - hard register which overlaps a hard register with a different - number. (Such overlap is undesirable, but occasionally it allows - a machine to be supported which otherwise could not be.) This - macro must return nonzero for *all* the registers which overlap - each other. GNU CC can use an overlapping register only in - certain limited ways. It can be used for allocation within a - basic block, and may be spilled for reloading; that is all. - - If this macro is not defined, it means that none of the hard - registers overlap each other. This is the usual situation. - -`INSN_CLOBBERS_REGNO_P (INSN, REGNO)' - If defined, this is a C expression whose value should be nonzero - if the insn INSN has the effect of mysteriously clobbering the - contents of hard register number REGNO. By "mysterious" we mean - that the insn's RTL expression doesn't describe such an effect. - - If this macro is not defined, it means that no insn clobbers - registers mysteriously. This is the usual situation; all else - being equal, it is best for the RTL expression to show all the - activity. - -`PRESERVE_DEATH_INFO_REGNO_P (REGNO)' - If defined, this is a C expression whose value is nonzero if - accurate `REG_DEAD' notes are needed for hard register number - REGNO at the time of outputting the assembler code. When this is - so, a few optimizations that take place after register allocation - and could invalidate the death notes are not done when this - register is involved. - - You would arrange to preserve death info for a register when some - of the code in the machine description which is executed to write - the assembler code looks at the death notes. This is necessary - only when the actual hardware feature which GNU CC thinks of as a - register is not actually a register of the usual sort. (It - might, for example, be a hardware stack.) - - If this macro is not defined, it means that no death notes need - to be preserved. This is the usual situation. - - -File: gcc.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Machine Macros - -Register Classes -================ - - On many machines, the numbered registers are not all equivalent. -For example, certain registers may not be allowed for indexed -addressing; certain registers may not be allowed in some instructions. - These machine restrictions are described to the compiler using -"register classes". - - You define a number of register classes, giving each one a name and -saying which of the registers belong to it. Then you can specify -register classes that are allowed as operands to particular -instruction patterns. - - In general, each register will belong to several classes. In fact, -one class must be named `ALL_REGS' and contain all the registers. -Another class must be named `NO_REGS' and contain no registers. Often -the union of two classes will be another class; however, this is not -required. - - One of the classes must be named `GENERAL_REGS'. There is nothing -terribly special about the name, but the operand constraint letters -`r' and `g' specify this class. If `GENERAL_REGS' is the same as -`ALL_REGS', just define it as a macro which expands to `ALL_REGS'. - - Order the classes so that if class X is contained in class Y then X -has a lower class number than Y. - - The way classes other than `GENERAL_REGS' are specified in operand -constraints is through machine-dependent operand constraint letters. -You can define such letters to correspond to various classes, then use -them in operand constraints. - - You should define a class for the union of two classes whenever some -instruction allows both classes. For example, if an instruction allows -either a floating point (coprocessor) register or a general register -for a certain operand, you should define a class -`FLOAT_OR_GENERAL_REGS' which includes both of them. Otherwise you -will get suboptimal code. - - You must also specify certain redundant information about the -register classes: for each class, which classes contain it and which -ones are contained in it; for each pair of classes, the largest class -contained in their union. - - When a value occupying several consecutive registers is expected in -a certain class, all the registers used must belong to that class. -Therefore, register classes cannot be used to enforce a requirement for -a register pair to start with an even-numbered register. The way to -specify this requirement is with `HARD_REGNO_MODE_OK'. - - Register classes used for input-operands of bitwise-and or shift -instructions have a special requirement: each such class must have, for -each fixed-point machine mode, a subclass whose registers can transfer -that mode to or from memory. For example, on some machines, the -operations for single-byte values (`QImode') are limited to certain -registers. When this is so, each register class that is used in a -bitwise-and or shift instruction must have a subclass consisting of -registers from which single-byte values can be loaded or stored. This -is so that `PREFERRED_RELOAD_CLASS' can always have a possible value -to return. - -`enum reg_class' - An enumeral type that must be defined with all the register class - names as enumeral values. `NO_REGS' must be first. `ALL_REGS' - must be the last register class, followed by one more enumeral - value, `LIM_REG_CLASSES', which is not a register class but rather - tells how many classes there are. - - Each register class has a number, which is the value of casting - the class name to type `int'. The number serves as an index in - many of the tables described below. - -`N_REG_CLASSES' - The number of distinct register classes, defined as follows: - - #define N_REG_CLASSES (int) LIM_REG_CLASSES - -`REG_CLASS_NAMES' - An initializer containing the names of the register classes as C - string constants. These names are used in writing some of the - debugging dumps. - -`REG_CLASS_CONTENTS' - An initializer containing the contents of the register classes, - as integers which are bit masks. The Nth integer specifies the - contents of class N. The way the integer MASK is interpreted is - that register R is in the class if `MASK & (1 << R)' is 1. - - When the machine has more than 32 registers, an integer does not - suffice. Then the integers are replaced by sub-initializers, - braced groupings containing several integers. Each - sub-initializer must be suitable as an initializer for the type - `HARD_REG_SET' which is defined in `hard-reg-set.h'. - -`REGNO_REG_CLASS (REGNO)' - A C expression whose value is a register class containing hard - register REGNO. In general there is more that one such class; - choose a class which is "minimal", meaning that no smaller class - also contains the register. - -`BASE_REG_CLASS' - A macro whose definition is the name of the class to which a valid - base register must belong. A base register is one used in an - address which is the register value plus a displacement. - -`INDEX_REG_CLASS' - A macro whose definition is the name of the class to which a valid - index register must belong. An index register is one used in an - address where its value is either multiplied by a scale factor or - added to another register (as well as added to a displacement). - -`REG_CLASS_FROM_LETTER (CHAR)' - A C expression which defines the machine-dependent operand - constraint letters for register classes. If CHAR is such a - letter, the value should be the register class corresponding to - it. Otherwise, the value should be `NO_REGS'. - -`REGNO_OK_FOR_BASE_P (NUM)' - A C expression which is nonzero if register number NUM is - suitable for use as a base register in operand addresses. It may - be either a suitable hard register or a pseudo register that has - been allocated such a hard register. - -`REGNO_OK_FOR_INDEX_P (NUM)' - A C expression which is nonzero if register number NUM is - suitable for use as an index register in operand addresses. It - may be either a suitable hard register or a pseudo register that - has been allocated such a hard register. - - The difference between an index register and a base register is - that the index register may be scaled. If an address involves - the sum of two registers, neither one of them scaled, then either - one may be labeled the "base" and the other the "index"; but - whichever labeling is used must fit the machine's constraints of - which registers may serve in each capacity. The compiler will - try both labelings, looking for one that is valid, and will - reload one or both registers only if neither labeling works. - -`PREFERRED_RELOAD_CLASS (X, CLASS)' - A C expression that places additional restrictions on the - register class to use when it is necessary to copy value X into a - register in class CLASS. The value is a register class; perhaps - CLASS, or perhaps another, smaller class. On many machines, the - definition - - #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS - - is safe. - - Sometimes returning a more restrictive class makes better code. - For example, on the 68000, when X is an integer constant that is - in range for a `moveq' instruction, the value of this macro is - always `DATA_REGS' as long as CLASS includes the data registers. - Requiring a data register guarantees that a `moveq' will be used. - - If X is a `const_double', by returning `NO_REGS' you can force X - into a memory constant. This is useful on certain machines where - immediate floating values cannot be loaded into certain kinds of - registers. - -`LIMIT_RELOAD_CLASS (MODE, CLASS)' - A C expression that places additional restrictions on the - register class to use when it is necessary to be able to hold a - value of mode MODE in a reload register for which class CLASS - would ordinarily be used. - - Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when - there are certain modes that simply can't go in certain reload - classes. - - The value is a register class; perhaps CLASS, or perhaps another, - smaller class. - - Don't define this macro unless the target machine has limitations - which require the macro to do something nontrivial. - -`SECONDARY_RELOAD_CLASS (CLASS, MODE, X)' -`SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)' -`SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)' - Many machines have some registers that cannot be copied directly - to or from memory or even from other types of registers. An - example is the `MQ' register, which on most machines, can only be - copied to or from general registers, but not memory. Some - machines allow copying all registers to and from memory, but - require a scratch register for stores to some memory locations - (e.g., those with symbolic address on the RT, and those with - certain symbolic address on the Sparc when compiling PIC). In - some cases, both an intermediate and a scratch register are - required. - - You should define these macros to indicate to the reload phase - that it may need to allocate at least one register for a reload - in addition to the register to contain the data. Specifically, - if copying X to a register CLASS in MODE requires an intermediate - register, you should define `SECONDARY_INPUT_RELOAD_CLASS' to - return the largest register class all of whose registers can be - used as intermediate registers or scratch registers. - - If copying a register CLASS in MODE to X requires an intermediate - or scratch register, you should define - `SECONDARY_OUTPUT_RELOAD_CLASS' to return the largest register - class required. If the requirements for input and output reloads - are the same, the macro `SECONDARY_RELOAD_CLASS' should be used - instead of defining both macros identically. - - The values returned by these macros are often `GENERAL_REGS'. - Return `NO_REGS' if no spare register is needed; i.e., if X can - be directly copied to or from a register of CLASS in MODE without - requiring a scratch register. Do not define this macro if it - would always return `NO_REGS'. - - If a scratch register is required (either with or without an - intermediate register), you should define patterns for - `reload_inM' or `reload_outM', as required (*note Standard - Names::.. These patterns, which will normally be implemented - with a `define_expand', should be similar to the `movM' patterns, - except that operand 2 is the scratch register. - - Define constraints for the reload register and scratch register - that contain a single register class. If the original reload - register (whose class is CLASS) can meet the constraint given in - the pattern, the value returned by these macros is used for the - class of the scratch register. Otherwise, two additional reload - registers are required. Their classes are obtained from the - constraints in the insn pattern. - - X might be a pseudo-register or a `subreg' of a pseudo-register, - which could either be in a hard register or in memory. Use - `true_regnum' to find out; it will return -1 if the pseudo is in - memory and the hard register number if it is in a register. - - These macros should not be used in the case where a particular - class of registers can only be copied to memory and not to - another class of registers. In that case, secondary reload - registers are not needed and would not be helpful. Instead, a - stack location must be used to perform the copy and the `movM' - pattern should use memory as a intermediate storage. This case - often occurs between floating-point and general registers. - -`SMALL_REGISTER_CLASSES' - Normally the compiler will avoid choosing spill registers from - registers that have been explicitly mentioned in the rtl (these - registers are normally those used to pass parameters and return - values). However, some machines have so few registers of certain - classes that there would not be enough registers to use as spill - registers if this were done. - - On those machines, you should define `SMALL_REGISTER_CLASSES'. - When it is defined, the compiler allows registers explicitly used - in the rtl to be used as spill registers but prevents the - compiler from extending the lifetime of these registers. - - Defining this macro is always safe, but unnecessarily defining - this macro will reduce the amount of optimizations that can be - performed in some cases. If this macro is not defined but needs - to be, the compiler will run out of reload registers and print a - fatal error message. - - For most machines, this macro should not be defined. - -`CLASS_MAX_NREGS (CLASS, MODE)' - A C expression for the maximum number of consecutive registers of - class CLASS needed to hold a value of mode MODE. - - This is closely related to the macro `HARD_REGNO_NREGS'. In - fact, the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' - should be the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' - for all REGNO values in the class CLASS. - - This macro helps control the handling of multiple-word values in - the reload pass. - - Three other special macros describe which operands fit which -constraint letters. - -`CONST_OK_FOR_LETTER_P (VALUE, C)' - A C expression that defines the machine-dependent operand - constraint letters that specify particular ranges of integer - values. If C is one of those letters, the expression should - check that VALUE, an integer, is in the appropriate range and - return 1 if so, 0 otherwise. If C is not one of those letters, - the value should be 0 regardless of VALUE. - -`CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)' - A C expression that defines the machine-dependent operand - constraint letters that specify particular ranges of - `const_double' values. - - If C is one of those letters, the expression should check that - VALUE, an RTX of code `const_double', is in the appropriate range - and return 1 if so, 0 otherwise. If C is not one of those - letters, the value should be 0 regardless of VALUE. - - `const_double' is used for all floating-point constants and for - `DImode' fixed-point constants. A given letter can accept either - or both kinds of values. It can use `GET_MODE' to distinguish - between these kinds. - -`EXTRA_CONSTRAINT (VALUE, C)' - A C expression that defines the optional machine-dependent - constraint letters that can be used to segregate specific types - of operands, usually memory references, for the target machine. - Normally this macro will not be defined. If it is required for a - particular target machine, it should return 1 if VALUE - corresponds to the operand type represented by the constraint - letter C. If C is not defined as an extra constraint, the value - returned should be 0 regardless of VALUE. - - For example, on the ROMP, load instructions cannot have their - output in r0 if the memory reference contains a symbolic address. - Constraint letter `Q' is defined as representing a memory - address that does *not* contain a symbolic address. An - alternative is specified with a `Q' constraint on the input and - `r' on the output. The next alternative specifies `m' on the - input and a register class that does not include r0 on the output. - - -File: gcc.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Machine Macros - -Describing Stack Layout and Calling Conventions -=============================================== - -* Menu: - -* Frame Layout:: -* Frame Registers:: -* Elimination:: -* Stack Arguments:: -* Register Arguments:: -* Scalar Return:: -* Aggregate Return:: -* Caller Saves:: -* Function Entry:: -* Profiling:: - - -File: gcc.info, Node: Frame Layout, Next: Frame Registers, Up: Stack and Calling +Defining Machine-Specific Peephole Optimizers +============================================= -Basic Stack Layout ------------------- + In addition to instruction patterns the `md' file may contain +definitions of machine-specific peephole optimizations. -`STACK_GROWS_DOWNWARD' - Define this macro if pushing a word onto the stack moves the stack - pointer to a smaller address. - - When we say, "define this macro if ...," it means that the - compiler checks this macro only with `#ifdef' so the precise - definition used does not matter. - -`FRAME_GROWS_DOWNWARD' - Define this macro if the addresses of local variable slots are at - negative offsets from the frame pointer. - -`ARGS_GROW_DOWNWARD' - Define this macro if successive arguments to a function occupy - decreasing addresses on the stack. - -`STARTING_FRAME_OFFSET' - Offset from the frame pointer to the first local variable slot to - be allocated. - - If `FRAME_GROWS_DOWNWARD', the next slot's offset is found by - subtracting the length of the first slot from - `STARTING_FRAME_OFFSET'. Otherwise, it is found by adding the - length of the first slot to the value `STARTING_FRAME_OFFSET'. - -`STACK_POINTER_OFFSET' - Offset from the stack pointer register to the first location at - which outgoing arguments are placed. If not specified, the - default value of zero is used. This is the proper value for most - machines. - - If `ARGS_GROW_DOWNWARD', this is the offset to the location above - the first location at which outgoing arguments are placed. - -`FIRST_PARM_OFFSET (FUNDECL)' - Offset from the argument pointer register to the first argument's - address. On some machines it may depend on the data type of the - function. - - If `ARGS_GROW_DOWNWARD', this is the offset to the location above - the first argument's address. - -`STACK_DYNAMIC_OFFSET (FUNDECL)' - Offset from the stack pointer register to an item dynamically - allocated on the stack, e.g., by `alloca'. - - The default value for this macro is `STACK_POINTER_OFFSET' plus - the length of the outgoing arguments. The default is correct for - most machines. See `function.c' for details. - -`DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)' - A C expression whose value is RTL representing the address in a - stack frame where the pointer to the caller's frame is stored. - Assume that FRAMEADDR is an RTL expression for the address of the - stack frame itself. - - If you don't define this macro, the default is to return the value - of FRAMEADDR--that is, the stack frame address is also the - address of the stack word that points to the previous frame. + The combiner does not notice certain peephole optimizations when the +data flow in the program does not suggest that it should try them. For +example, sometimes two consecutive insns related in purpose can be +combined even though the second one does not appear to use a register +computed in the first one. A machine-specific peephole optimizer can +detect such opportunities. + + A definition looks like this: + + (define_peephole + [INSN-PATTERN-1 + INSN-PATTERN-2 + ...] + "CONDITION" + "TEMPLATE" + "OPTIONAL INSN-ATTRIBUTES") + +The last string operand may be omitted if you are not using any +machine-specific information in this machine description. If present, +it must obey the same rules as in a `define_insn'. + + In this skeleton, INSN-PATTERN-1 and so on are patterns to match +consecutive insns. The optimization applies to a sequence of insns when +INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, +and so on. + + Each of the insns matched by a peephole must also match a +`define_insn'. Peepholes are checked only at the last stage just +before code generation, and only optionally. Therefore, any insn which +would match a peephole but no `define_insn' will cause a crash in code +generation in an unoptimized compilation, or at various optimization +stages. + + The operands of the insns are matched with `match_operands', +`match_operator', and `match_dup', as usual. What is not usual is that +the operand numbers apply to all the insn patterns in the definition. +So, you can check for identical operands in two insns by using +`match_operand' in one insn and `match_dup' in the other. + + The operand constraints used in `match_operand' patterns do not have +any direct effect on the applicability of the peephole, but they will +be validated afterward, so make sure your constraints are general enough +to apply whenever the peephole matches. If the peephole matches but +the constraints are not satisfied, the compiler will crash. + + It is safe to omit constraints in all the operands of the peephole; +or you can write constraints which serve as a double-check on the +criteria previously tested. + + Once a sequence of insns matches the patterns, the CONDITION is +checked. This is a C expression which makes the final decision whether +to perform the optimization (we do so if the expression is nonzero). If +CONDITION is omitted (in other words, the string is empty) then the +optimization is applied to every sequence of insns that matches the +patterns. + + The defined peephole optimizations are applied after register +allocation is complete. Therefore, the peephole definition can check +which operands have ended up in which kinds of registers, just by +looking at the operands. + + The way to refer to the operands in CONDITION is to write +`operands[I]' for operand number I (as matched by `(match_operand I +...)'). Use the variable `insn' to refer to the last of the insns +being matched; use `prev_nonnote_insn' to find the preceding insns. + + When optimizing computations with intermediate results, you can use +CONDITION to match only when the intermediate results are not used +elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where INSN +is the insn in which you expect the value to be used for the last time +(from the value of `insn', together with use of `prev_nonnote_insn'), +and OP is the intermediate value (from `operands[I]'). + + Applying the optimization means replacing the sequence of insns with +one new insn. The TEMPLATE controls ultimate output of assembler code +for this combined insn. It works exactly like the template of a +`define_insn'. Operand numbers in this template are the same ones used +in matching the original sequence of insns. + + The result of a defined peephole optimizer does not need to match +any of the insn patterns in the machine description; it does not even +have an opportunity to match them. The peephole optimizer definition +itself serves as the insn pattern to control how the insn is output. + + Defined peephole optimizers are run as assembler code is being +output, so the insns they produce are never combined or rearranged in +any way. + + Here is an example, taken from the 68000 machine description: + + (define_peephole + [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) + (set (match_operand:DF 0 "register_operand" "=f") + (match_operand:DF 1 "register_operand" "ad"))] + "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" + "* + { + rtx xoperands[2]; + xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1); + #ifdef MOTOROLA + output_asm_insn (\"move.l %1,(sp)\", xoperands); + output_asm_insn (\"move.l %1,-(sp)\", operands); + return \"fmove.d (sp)+,%0\"; + #else + output_asm_insn (\"movel %1,sp@\", xoperands); + output_asm_insn (\"movel %1,sp@-\", operands); + return \"fmoved sp@+,%0\"; + #endif + } + ") + + The effect of this optimization is to change + + jbsr _foobar + addql #4,sp + movel d1,sp@- + movel d0,sp@- + fmoved sp@+,fp0 + +into + + jbsr _foobar + movel d1,sp@ + movel d0,sp@- + fmoved sp@+,fp0 + + INSN-PATTERN-1 and so on look *almost* like the second operand of +`define_insn'. There is one important difference: the second operand +of `define_insn' consists of one or more RTX's enclosed in square +brackets. Usually, there is only one: then the same action can be +written as an element of a `define_peephole'. But when there are +multiple actions in a `define_insn', they are implicitly enclosed in a +`parallel'. Then you must explicitly write the `parallel', and the +square brackets within it, in the `define_peephole'. Thus, if an insn +pattern looks like this, + + (define_insn "divmodsi4" + [(set (match_operand:SI 0 "general_operand" "=d") + (div:SI (match_operand:SI 1 "general_operand" "0") + (match_operand:SI 2 "general_operand" "dmsK"))) + (set (match_operand:SI 3 "general_operand" "=d") + (mod:SI (match_dup 1) (match_dup 2)))] + "TARGET_68020" + "divsl%.l %2,%3:%0") + +then the way to mention this insn in a peephole is as follows: + + (define_peephole + [... + (parallel + [(set (match_operand:SI 0 "general_operand" "=d") + (div:SI (match_operand:SI 1 "general_operand" "0") + (match_operand:SI 2 "general_operand" "dmsK"))) + (set (match_operand:SI 3 "general_operand" "=d") + (mod:SI (match_dup 1) (match_dup 2)))]) + ...] + ...)  \ No newline at end of file