X-Git-Url: https://oss.titaniummirror.com/gitweb?a=blobdiff_plain;f=gcc%2Fdoc%2Fgccint.info-10;fp=gcc%2Fdoc%2Fgccint.info-10;h=0000000000000000000000000000000000000000;hb=5a5369932a08c074943c94407697a5813002fd31;hp=ef52fd1dec843dbc9990b9585e49230628981da3;hpb=aaf7afc53d3ed4f6c811f6ec493d857ea0459573;p=msp430-gcc.git diff --git a/gcc/doc/gccint.info-10 b/gcc/doc/gccint.info-10 deleted file mode 100644 index ef52fd1d..00000000 --- a/gcc/doc/gccint.info-10 +++ /dev/null @@ -1,1058 +0,0 @@ -This is doc/gccint.info, produced by makeinfo version 4.5 from -doc/gccint.texi. - -INFO-DIR-SECTION Programming -START-INFO-DIR-ENTRY -* gccint: (gccint). Internals of the GNU Compiler Collection. -END-INFO-DIR-ENTRY - This file documents the internals of the GNU compilers. - - Published by the Free Software Foundation -59 Temple Place - Suite 330 -Boston, MA 02111-1307 USA - - Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, -1999, 2000, 2001, 2002 Free Software Foundation, Inc. - - Permission is granted to copy, distribute and/or modify this document -under the terms of the GNU Free Documentation License, Version 1.1 or -any later version published by the Free Software Foundation; with the -Invariant Sections being "GNU General Public License" and "Funding Free -Software", the Front-Cover texts being (a) (see below), and with the -Back-Cover Texts being (b) (see below). A copy of the license is -included in the section entitled "GNU Free Documentation License". - - (a) The FSF's Front-Cover Text is: - - A GNU Manual - - (b) The FSF's Back-Cover Text is: - - You have freedom to copy and modify this GNU Manual, like GNU -software. Copies published by the Free Software Foundation raise -funds for GNU development. - - -File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc - -Standard Pattern Names For Generation -===================================== - - Here is a table of the instruction names that are meaningful in the -RTL generation pass of the compiler. Giving one of these names to an -instruction pattern tells the RTL generation pass that it can use the -pattern to accomplish a certain task. - -`movM' - Here M stands for a two-letter machine mode name, in lower case. - This instruction pattern moves data with that machine mode from - operand 1 to operand 0. For example, `movsi' moves full-word data. - - If operand 0 is a `subreg' with mode M of a register whose own - mode is wider than M, the effect of this instruction is to store - the specified value in the part of the register that corresponds - to mode M. Bits outside of M, but which are within the same - target word as the `subreg' are undefined. Bits which are outside - the target word are left unchanged. - - This class of patterns is special in several ways. First of all, - each of these names up to and including full word size _must_ be - defined, because there is no other way to copy a datum from one - place to another. If there are patterns accepting operands in - larger modes, `movM' must be defined for integer modes of those - sizes. - - Second, these patterns are not used solely in the RTL generation - pass. Even the reload pass can generate move insns to copy values - from stack slots into temporary registers. When it does so, one - of the operands is a hard register and the other is an operand - that can need to be reloaded into a register. - - Therefore, when given such a pair of operands, the pattern must - generate RTL which needs no reloading and needs no temporary - registers--no registers other than the operands. For example, if - you support the pattern with a `define_expand', then in such a - case the `define_expand' mustn't call `force_reg' or any other such - function which might generate new pseudo registers. - - This requirement exists even for subword modes on a RISC machine - where fetching those modes from memory normally requires several - insns and some temporary registers. - - During reload a memory reference with an invalid address may be - passed as an operand. Such an address will be replaced with a - valid address later in the reload pass. In this case, nothing may - be done with the address except to use it as it stands. If it is - copied, it will not be replaced with a valid address. No attempt - should be made to make such an address into a valid address and no - routine (such as `change_address') that will do so may be called. - Note that `general_operand' will fail when applied to such an - address. - - The global variable `reload_in_progress' (which must be explicitly - declared if required) can be used to determine whether such special - handling is required. - - The variety of operands that have reloads depends on the rest of - the machine description, but typically on a RISC machine these can - only be pseudo registers that did not get hard registers, while on - other machines explicit memory references will get optional - reloads. - - If a scratch register is required to move an object to or from - memory, it can be allocated using `gen_reg_rtx' prior to life - analysis. - - If there are cases which need scratch registers during or after - reload, you must define `SECONDARY_INPUT_RELOAD_CLASS' and/or - `SECONDARY_OUTPUT_RELOAD_CLASS' to detect them, and provide - patterns `reload_inM' or `reload_outM' to handle them. *Note - Register Classes::. - - The global variable `no_new_pseudos' can be used to determine if it - is unsafe to create new pseudo registers. If this variable is - nonzero, then it is unsafe to call `gen_reg_rtx' to allocate a new - pseudo. - - The constraints on a `movM' must permit moving any hard register - to any other hard register provided that `HARD_REGNO_MODE_OK' - permits mode M in both registers and `REGISTER_MOVE_COST' applied - to their classes returns a value of 2. - - It is obligatory to support floating point `movM' instructions - into and out of any registers that can hold fixed point values, - because unions and structures (which have modes `SImode' or - `DImode') can be in those registers and they may have floating - point members. - - There may also be a need to support fixed point `movM' - instructions in and out of floating point registers. - Unfortunately, I have forgotten why this was so, and I don't know - whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed - point values in floating point registers, then the constraints of - the fixed point `movM' instructions must be designed to avoid ever - trying to reload into a floating point register. - -`reload_inM' -`reload_outM' - Like `movM', but used when a scratch register is required to move - between operand 0 and operand 1. Operand 2 describes the scratch - register. See the discussion of the `SECONDARY_RELOAD_CLASS' - macro in *note Register Classes::. - - There are special restrictions on the form of the `match_operand's - used in these patterns. First, only the predicate for the reload - operand is examined, i.e., `reload_in' examines operand 1, but not - the predicates for operand 0 or 2. Second, there may be only one - alternative in the constraints. Third, only a single register - class letter may be used for the constraint; subsequent constraint - letters are ignored. As a special exception, an empty constraint - string matches the `ALL_REGS' register class. This may relieve - ports of the burden of defining an `ALL_REGS' constraint letter - just for these patterns. - -`movstrictM' - Like `movM' except that if operand 0 is a `subreg' with mode M of - a register whose natural mode is wider, the `movstrictM' - instruction is guaranteed not to alter any of the register except - the part which belongs to mode M. - -`load_multiple' - Load several consecutive memory locations into consecutive - registers. Operand 0 is the first of the consecutive registers, - operand 1 is the first memory location, and operand 2 is a - constant: the number of consecutive registers. - - Define this only if the target machine really has such an - instruction; do not define this if the most efficient way of - loading consecutive registers from memory is to do them one at a - time. - - On some machines, there are restrictions as to which consecutive - registers can be stored into memory, such as particular starting or - ending register numbers or only a range of valid counts. For those - machines, use a `define_expand' (*note Expander Definitions::) and - make the pattern fail if the restrictions are not met. - - Write the generated insn as a `parallel' with elements being a - `set' of one register from the appropriate memory location (you may - also need `use' or `clobber' elements). Use a `match_parallel' - (*note RTL Template::) to recognize the insn. See `a29k.md' and - `rs6000.md' for examples of the use of this insn pattern. - -`store_multiple' - Similar to `load_multiple', but store several consecutive registers - into consecutive memory locations. Operand 0 is the first of the - consecutive memory locations, operand 1 is the first register, and - operand 2 is a constant: the number of consecutive registers. - -`pushM' - Output an push instruction. Operand 0 is value to push. Used - only when `PUSH_ROUNDING' is defined. For historical reason, this - pattern may be missing and in such case an `mov' expander is used - instead, with a `MEM' expression forming the push operation. The - `mov' expander method is deprecated. - -`addM3' - Add operand 2 and operand 1, storing the result in operand 0. All - operands must have mode M. This can be used even on two-address - machines, by means of constraints requiring operands 1 and 0 to be - the same location. - -`subM3', `mulM3' -`divM3', `udivM3', `modM3', `umodM3' -`sminM3', `smaxM3', `uminM3', `umaxM3' -`andM3', `iorM3', `xorM3' - Similar, for other arithmetic operations. - -`minM3', `maxM3' - Floating point min and max operations. If both operands are zeros, - or if either operand is NaN, then it is unspecified which of the - two operands is returned as the result. - -`mulhisi3' - Multiply operands 1 and 2, which have mode `HImode', and store a - `SImode' product in operand 0. - -`mulqihi3', `mulsidi3' - Similar widening-multiplication instructions of other widths. - -`umulqihi3', `umulhisi3', `umulsidi3' - Similar widening-multiplication instructions that do unsigned - multiplication. - -`smulM3_highpart' - Perform a signed multiplication of operands 1 and 2, which have - mode M, and store the most significant half of the product in - operand 0. The least significant half of the product is discarded. - -`umulM3_highpart' - Similar, but the multiplication is unsigned. - -`divmodM4' - Signed division that produces both a quotient and a remainder. - Operand 1 is divided by operand 2 to produce a quotient stored in - operand 0 and a remainder stored in operand 3. - - For machines with an instruction that produces both a quotient and - a remainder, provide a pattern for `divmodM4' but do not provide - patterns for `divM3' and `modM3'. This allows optimization in the - relatively common case when both the quotient and remainder are - computed. - - If an instruction that just produces a quotient or just a remainder - exists and is more efficient than the instruction that produces - both, write the output routine of `divmodM4' to call - `find_reg_note' and look for a `REG_UNUSED' note on the quotient - or remainder and generate the appropriate instruction. - -`udivmodM4' - Similar, but does unsigned division. - -`ashlM3' - Arithmetic-shift operand 1 left by a number of bits specified by - operand 2, and store the result in operand 0. Here M is the mode - of operand 0 and operand 1; operand 2's mode is specified by the - instruction pattern, and the compiler will convert the operand to - that mode before generating the instruction. - -`ashrM3', `lshrM3', `rotlM3', `rotrM3' - Other shift and rotate instructions, analogous to the `ashlM3' - instructions. - -`negM2' - Negate operand 1 and store the result in operand 0. - -`absM2' - Store the absolute value of operand 1 into operand 0. - -`sqrtM2' - Store the square root of operand 1 into operand 0. - - The `sqrt' built-in function of C always uses the mode which - corresponds to the C data type `double'. - -`ffsM2' - Store into operand 0 one plus the index of the least significant - 1-bit of operand 1. If operand 1 is zero, store zero. M is the - mode of operand 0; operand 1's mode is specified by the instruction - pattern, and the compiler will convert the operand to that mode - before generating the instruction. - - The `ffs' built-in function of C always uses the mode which - corresponds to the C data type `int'. - -`one_cmplM2' - Store the bitwise-complement of operand 1 into operand 0. - -`cmpM' - Compare operand 0 and operand 1, and set the condition codes. The - RTL pattern should look like this: - - (set (cc0) (compare (match_operand:M 0 ...) - (match_operand:M 1 ...))) - -`tstM' - Compare operand 0 against zero, and set the condition codes. The - RTL pattern should look like this: - - (set (cc0) (match_operand:M 0 ...)) - - `tstM' patterns should not be defined for machines that do not use - `(cc0)'. Doing so would confuse the optimizer since it would no - longer be clear which `set' operations were comparisons. The - `cmpM' patterns should be used instead. - -`movstrM' - Block move instruction. The addresses of the destination and - source strings are the first two operands, and both are in mode - `Pmode'. - - The number of bytes to move is the third operand, in mode M. - Usually, you specify `word_mode' for M. However, if you can - generate better code knowing the range of valid lengths is smaller - than those representable in a full word, you should provide a - pattern with a mode corresponding to the range of values you can - handle efficiently (e.g., `QImode' for values in the range 0-127; - note we avoid numbers that appear negative) and also a pattern - with `word_mode'. - - The fourth operand is the known shared alignment of the source and - destination, in the form of a `const_int' rtx. Thus, if the - compiler knows that both source and destination are word-aligned, - it may provide the value 4 for this operand. - - Descriptions of multiple `movstrM' patterns can only be beneficial - if the patterns for smaller modes have fewer restrictions on their - first, second and fourth operands. Note that the mode M in - `movstrM' does not impose any restriction on the mode of - individually moved data units in the block. - - These patterns need not give special consideration to the - possibility that the source and destination strings might overlap. - -`clrstrM' - Block clear instruction. The addresses of the destination string - is the first operand, in mode `Pmode'. The number of bytes to - clear is the second operand, in mode M. See `movstrM' for a - discussion of the choice of mode. - - The third operand is the known alignment of the destination, in - the form of a `const_int' rtx. Thus, if the compiler knows that - the destination is word-aligned, it may provide the value 4 for - this operand. - - The use for multiple `clrstrM' is as for `movstrM'. - -`cmpstrM' - Block compare instruction, with five operands. Operand 0 is the - output; it has mode M. The remaining four operands are like the - operands of `movstrM'. The two memory blocks specified are - compared byte by byte in lexicographic order. The effect of the - instruction is to store a value in operand 0 whose sign indicates - the result of the comparison. - -`strlenM' - Compute the length of a string, with three operands. Operand 0 is - the result (of mode M), operand 1 is a `mem' referring to the - first character of the string, operand 2 is the character to - search for (normally zero), and operand 3 is a constant describing - the known alignment of the beginning of the string. - -`floatMN2' - Convert signed integer operand 1 (valid for fixed point mode M) to - floating point mode N and store in operand 0 (which has mode N). - -`floatunsMN2' - Convert unsigned integer operand 1 (valid for fixed point mode M) - to floating point mode N and store in operand 0 (which has mode N). - -`fixMN2' - Convert operand 1 (valid for floating point mode M) to fixed point - mode N as a signed number and store in operand 0 (which has mode - N). This instruction's result is defined only when the value of - operand 1 is an integer. - -`fixunsMN2' - Convert operand 1 (valid for floating point mode M) to fixed point - mode N as an unsigned number and store in operand 0 (which has - mode N). This instruction's result is defined only when the value - of operand 1 is an integer. - -`ftruncM2' - Convert operand 1 (valid for floating point mode M) to an integer - value, still represented in floating point mode M, and store it in - operand 0 (valid for floating point mode M). - -`fix_truncMN2' - Like `fixMN2' but works for any floating point value of mode M by - converting the value to an integer. - -`fixuns_truncMN2' - Like `fixunsMN2' but works for any floating point value of mode M - by converting the value to an integer. - -`truncMN2' - Truncate operand 1 (valid for mode M) to mode N and store in - operand 0 (which has mode N). Both modes must be fixed point or - both floating point. - -`extendMN2' - Sign-extend operand 1 (valid for mode M) to mode N and store in - operand 0 (which has mode N). Both modes must be fixed point or - both floating point. - -`zero_extendMN2' - Zero-extend operand 1 (valid for mode M) to mode N and store in - operand 0 (which has mode N). Both modes must be fixed point. - -`extv' - Extract a bit-field from operand 1 (a register or memory operand), - where operand 2 specifies the width in bits and operand 3 the - starting bit, and store it in operand 0. Operand 0 must have mode - `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode'; - often `word_mode' is allowed only for registers. Operands 2 and 3 - must be valid for `word_mode'. - - The RTL generation pass generates this instruction only with - constants for operands 2 and 3. - - The bit-field value is sign-extended to a full word integer before - it is stored in operand 0. - -`extzv' - Like `extv' except that the bit-field value is zero-extended. - -`insv' - Store operand 3 (which must be valid for `word_mode') into a - bit-field in operand 0, where operand 1 specifies the width in - bits and operand 2 the starting bit. Operand 0 may have mode - `byte_mode' or `word_mode'; often `word_mode' is allowed only for - registers. Operands 1 and 2 must be valid for `word_mode'. - - The RTL generation pass generates this instruction only with - constants for operands 1 and 2. - -`movMODEcc' - Conditionally move operand 2 or operand 3 into operand 0 according - to the comparison in operand 1. If the comparison is true, - operand 2 is moved into operand 0, otherwise operand 3 is moved. - - The mode of the operands being compared need not be the same as - the operands being moved. Some machines, sparc64 for example, - have instructions that conditionally move an integer value based - on the floating point condition codes and vice versa. - - If the machine does not have conditional move instructions, do not - define these patterns. - -`sCOND' - Store zero or nonzero in the operand according to the condition - codes. Value stored is nonzero iff the condition COND is true. - COND is the name of a comparison operation expression code, such - as `eq', `lt' or `leu'. - - You specify the mode that the operand must have when you write the - `match_operand' expression. The compiler automatically sees which - mode you have used and supplies an operand of that mode. - - The value stored for a true condition must have 1 as its low bit, - or else must be negative. Otherwise the instruction is not - suitable and you should omit it from the machine description. You - describe to the compiler exactly which value is stored by defining - the macro `STORE_FLAG_VALUE' (*note Misc::). If a description - cannot be found that can be used for all the `sCOND' patterns, you - should omit those operations from the machine description. - - These operations may fail, but should do so only in relatively - uncommon cases; if they would fail for common cases involving - integer comparisons, it is best to omit these patterns. - - If these operations are omitted, the compiler will usually - generate code that copies the constant one to the target and - branches around an assignment of zero to the target. If this code - is more efficient than the potential instructions used for the - `sCOND' pattern followed by those required to convert the result - into a 1 or a zero in `SImode', you should omit the `sCOND' - operations from the machine description. - -`bCOND' - Conditional branch instruction. Operand 0 is a `label_ref' that - refers to the label to jump to. Jump if the condition codes meet - condition COND. - - Some machines do not follow the model assumed here where a - comparison instruction is followed by a conditional branch - instruction. In that case, the `cmpM' (and `tstM') patterns should - simply store the operands away and generate all the required insns - in a `define_expand' (*note Expander Definitions::) for the - conditional branch operations. All calls to expand `bCOND' - patterns are immediately preceded by calls to expand either a - `cmpM' pattern or a `tstM' pattern. - - Machines that use a pseudo register for the condition code value, - or where the mode used for the comparison depends on the condition - being tested, should also use the above mechanism. *Note Jump - Patterns::. - - The above discussion also applies to the `movMODEcc' and `sCOND' - patterns. - -`jump' - A jump inside a function; an unconditional branch. Operand 0 is - the `label_ref' of the label to jump to. This pattern name is - mandatory on all machines. - -`call' - Subroutine call instruction returning no value. Operand 0 is the - function to call; operand 1 is the number of bytes of arguments - pushed as a `const_int'; operand 2 is the number of registers used - as operands. - - On most machines, operand 2 is not actually stored into the RTL - pattern. It is supplied for the sake of some RISC machines which - need to put this information into the assembler code; they can put - it in the RTL instead of operand 1. - - Operand 0 should be a `mem' RTX whose address is the address of the - function. Note, however, that this address can be a `symbol_ref' - expression even if it would not be a legitimate memory address on - the target machine. If it is also not a valid argument for a call - instruction, the pattern for this operation should be a - `define_expand' (*note Expander Definitions::) that places the - address into a register and uses that register in the call - instruction. - -`call_value' - Subroutine call instruction returning a value. Operand 0 is the - hard register in which the value is returned. There are three more - operands, the same as the three operands of the `call' instruction - (but with numbers increased by one). - - Subroutines that return `BLKmode' objects use the `call' insn. - -`call_pop', `call_value_pop' - Similar to `call' and `call_value', except used if defined and if - `RETURN_POPS_ARGS' is nonzero. They should emit a `parallel' that - contains both the function call and a `set' to indicate the - adjustment made to the frame pointer. - - For machines where `RETURN_POPS_ARGS' can be nonzero, the use of - these patterns increases the number of functions for which the - frame pointer can be eliminated, if desired. - -`untyped_call' - Subroutine call instruction returning a value of any type. - Operand 0 is the function to call; operand 1 is a memory location - where the result of calling the function is to be stored; operand - 2 is a `parallel' expression where each element is a `set' - expression that indicates the saving of a function return value - into the result block. - - This instruction pattern should be defined to support - `__builtin_apply' on machines where special instructions are needed - to call a subroutine with arbitrary arguments or to save the value - returned. This instruction pattern is required on machines that - have multiple registers that can hold a return value (i.e. - `FUNCTION_VALUE_REGNO_P' is true for more than one register). - -`return' - Subroutine return instruction. This instruction pattern name - should be defined only if a single instruction can do all the work - of returning from a function. - - Like the `movM' patterns, this pattern is also used after the RTL - generation phase. In this case it is to support machines where - multiple instructions are usually needed to return from a - function, but some class of functions only requires one - instruction to implement a return. Normally, the applicable - functions are those which do not need to save any registers or - allocate stack space. - - For such machines, the condition specified in this pattern should - only be true when `reload_completed' is nonzero and the function's - epilogue would only be a single instruction. For machines with - register windows, the routine `leaf_function_p' may be used to - determine if a register window push is required. - - Machines that have conditional return instructions should define - patterns such as - - (define_insn "" - [(set (pc) - (if_then_else (match_operator - 0 "comparison_operator" - [(cc0) (const_int 0)]) - (return) - (pc)))] - "CONDITION" - "...") - - where CONDITION would normally be the same condition specified on - the named `return' pattern. - -`untyped_return' - Untyped subroutine return instruction. This instruction pattern - should be defined to support `__builtin_return' on machines where - special instructions are needed to return a value of any type. - - Operand 0 is a memory location where the result of calling a - function with `__builtin_apply' is stored; operand 1 is a - `parallel' expression where each element is a `set' expression - that indicates the restoring of a function return value from the - result block. - -`nop' - No-op instruction. This instruction pattern name should always be - defined to output a no-op in assembler code. `(const_int 0)' will - do as an RTL pattern. - -`indirect_jump' - An instruction to jump to an address which is operand zero. This - pattern name is mandatory on all machines. - -`casesi' - Instruction to jump through a dispatch table, including bounds - checking. This instruction takes five operands: - - 1. The index to dispatch on, which has mode `SImode'. - - 2. The lower bound for indices in the table, an integer constant. - - 3. The total range of indices in the table--the largest index - minus the smallest one (both inclusive). - - 4. A label that precedes the table itself. - - 5. A label to jump to if the index has a value outside the - bounds. (If the machine-description macro - `CASE_DROPS_THROUGH' is defined, then an out-of-bounds index - drops through to the code following the jump table instead of - jumping to this label. In that case, this label is not - actually used by the `casesi' instruction, but it is always - provided as an operand.) - - The table is a `addr_vec' or `addr_diff_vec' inside of a - `jump_insn'. The number of elements in the table is one plus the - difference between the upper bound and the lower bound. - -`tablejump' - Instruction to jump to a variable address. This is a low-level - capability which can be used to implement a dispatch table when - there is no `casesi' pattern. - - This pattern requires two operands: the address or offset, and a - label which should immediately precede the jump table. If the - macro `CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then - the first operand is an offset which counts from the address of - the table; otherwise, it is an absolute address to jump to. In - either case, the first operand has mode `Pmode'. - - The `tablejump' insn is always the last insn before the jump table - it uses. Its assembler code normally has no need to use the - second operand, but you should incorporate it in the RTL pattern so - that the jump optimizer will not delete the table as unreachable - code. - -`decrement_and_branch_until_zero' - Conditional branch instruction that decrements a register and - jumps if the register is nonzero. Operand 0 is the register to - decrement and test; operand 1 is the label to jump to if the - register is nonzero. *Note Looping Patterns::. - - This optional instruction pattern is only used by the combiner, - typically for loops reversed by the loop optimizer when strength - reduction is enabled. - -`doloop_end' - Conditional branch instruction that decrements a register and - jumps if the register is nonzero. This instruction takes five - operands: Operand 0 is the register to decrement and test; operand - 1 is the number of loop iterations as a `const_int' or - `const0_rtx' if this cannot be determined until run-time; operand - 2 is the actual or estimated maximum number of iterations as a - `const_int'; operand 3 is the number of enclosed loops as a - `const_int' (an innermost loop has a value of 1); operand 4 is the - label to jump to if the register is nonzero. *Note Looping - Patterns::. - - This optional instruction pattern should be defined for machines - with low-overhead looping instructions as the loop optimizer will - try to modify suitable loops to utilize it. If nested - low-overhead looping is not supported, use a `define_expand' - (*note Expander Definitions::) and make the pattern fail if - operand 3 is not `const1_rtx'. Similarly, if the actual or - estimated maximum number of iterations is too large for this - instruction, make it fail. - -`doloop_begin' - Companion instruction to `doloop_end' required for machines that - need to perform some initialization, such as loading special - registers used by a low-overhead looping instruction. If - initialization insns do not always need to be emitted, use a - `define_expand' (*note Expander Definitions::) and make it fail. - -`canonicalize_funcptr_for_compare' - Canonicalize the function pointer in operand 1 and store the result - into operand 0. - - Operand 0 is always a `reg' and has mode `Pmode'; operand 1 may be - a `reg', `mem', `symbol_ref', `const_int', etc and also has mode - `Pmode'. - - Canonicalization of a function pointer usually involves computing - the address of the function which would be called if the function - pointer were used in an indirect call. - - Only define this pattern if function pointers on the target machine - can have different values but still call the same function when - used in an indirect call. - -`save_stack_block' -`save_stack_function' -`save_stack_nonlocal' -`restore_stack_block' -`restore_stack_function' -`restore_stack_nonlocal' - Most machines save and restore the stack pointer by copying it to - or from an object of mode `Pmode'. Do not define these patterns on - such machines. - - Some machines require special handling for stack pointer saves and - restores. On those machines, define the patterns corresponding to - the non-standard cases by using a `define_expand' (*note Expander - Definitions::) that produces the required insns. The three types - of saves and restores are: - - 1. `save_stack_block' saves the stack pointer at the start of a - block that allocates a variable-sized object, and - `restore_stack_block' restores the stack pointer when the - block is exited. - - 2. `save_stack_function' and `restore_stack_function' do a - similar job for the outermost block of a function and are - used when the function allocates variable-sized objects or - calls `alloca'. Only the epilogue uses the restored stack - pointer, allowing a simpler save or restore sequence on some - machines. - - 3. `save_stack_nonlocal' is used in functions that contain labels - branched to by nested functions. It saves the stack pointer - in such a way that the inner function can use - `restore_stack_nonlocal' to restore the stack pointer. The - compiler generates code to restore the frame and argument - pointer registers, but some machines require saving and - restoring additional data such as register window information - or stack backchains. Place insns in these patterns to save - and restore any such required data. - - When saving the stack pointer, operand 0 is the save area and - operand 1 is the stack pointer. The mode used to allocate the - save area defaults to `Pmode' but you can override that choice by - defining the `STACK_SAVEAREA_MODE' macro (*note Storage Layout::). - You must specify an integral mode, or `VOIDmode' if no save area - is needed for a particular type of save (either because no save is - needed or because a machine-specific save area can be used). - Operand 0 is the stack pointer and operand 1 is the save area for - restore operations. If `save_stack_block' is defined, operand 0 - must not be `VOIDmode' since these saves can be arbitrarily nested. - - A save area is a `mem' that is at a constant offset from - `virtual_stack_vars_rtx' when the stack pointer is saved for use by - nonlocal gotos and a `reg' in the other two cases. - -`allocate_stack' - Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 1 - from the stack pointer to create space for dynamically allocated - data. - - Store the resultant pointer to this space into operand 0. If you - are allocating space from the main stack, do this by emitting a - move insn to copy `virtual_stack_dynamic_rtx' to operand 0. If - you are allocating the space elsewhere, generate code to copy the - location of the space to operand 0. In the latter case, you must - ensure this space gets freed when the corresponding space on the - main stack is free. - - Do not define this pattern if all that must be done is the - subtraction. Some machines require other operations such as stack - probes or maintaining the back chain. Define this pattern to emit - those operations in addition to updating the stack pointer. - -`probe' - Some machines require instructions to be executed after space is - allocated from the stack, for example to generate a reference at - the bottom of the stack. - - If you need to emit instructions before the stack has been - adjusted, put them into the `allocate_stack' pattern. Otherwise, - define this pattern to emit the required instructions. - - No operands are provided. - -`check_stack' - If stack checking cannot be done on your system by probing the - stack with a load or store instruction (*note Stack Checking::), - define this pattern to perform the needed check and signaling an - error if the stack has overflowed. The single operand is the - location in the stack furthest from the current stack pointer that - you need to validate. Normally, on machines where this pattern is - needed, you would obtain the stack limit from a global or - thread-specific variable or register. - -`nonlocal_goto' - Emit code to generate a non-local goto, e.g., a jump from one - function to a label in an outer function. This pattern has four - arguments, each representing a value to be used in the jump. The - first argument is to be loaded into the frame pointer, the second - is the address to branch to (code to dispatch to the actual label), - the third is the address of a location where the stack is saved, - and the last is the address of the label, to be placed in the - location for the incoming static chain. - - On most machines you need not define this pattern, since GCC will - already generate the correct code, which is to load the frame - pointer and static chain, restore the stack (using the - `restore_stack_nonlocal' pattern, if defined), and jump indirectly - to the dispatcher. You need only define this pattern if this code - will not work on your machine. - -`nonlocal_goto_receiver' - This pattern, if defined, contains code needed at the target of a - nonlocal goto after the code already generated by GCC. You will - not normally need to define this pattern. A typical reason why - you might need this pattern is if some value, such as a pointer to - a global table, must be restored when the frame pointer is - restored. Note that a nonlocal goto only occurs within a - unit-of-translation, so a global table pointer that is shared by - all functions of a given module need not be restored. There are - no arguments. - -`exception_receiver' - This pattern, if defined, contains code needed at the site of an - exception handler that isn't needed at the site of a nonlocal - goto. You will not normally need to define this pattern. A - typical reason why you might need this pattern is if some value, - such as a pointer to a global table, must be restored after - control flow is branched to the handler of an exception. There - are no arguments. - -`builtin_setjmp_setup' - This pattern, if defined, contains additional code needed to - initialize the `jmp_buf'. You will not normally need to define - this pattern. A typical reason why you might need this pattern is - if some value, such as a pointer to a global table, must be - restored. Though it is preferred that the pointer value be - recalculated if possible (given the address of a label for - instance). The single argument is a pointer to the `jmp_buf'. - Note that the buffer is five words long and that the first three - are normally used by the generic mechanism. - -`builtin_setjmp_receiver' - This pattern, if defined, contains code needed at the site of an - built-in setjmp that isn't needed at the site of a nonlocal goto. - You will not normally need to define this pattern. A typical - reason why you might need this pattern is if some value, such as a - pointer to a global table, must be restored. It takes one - argument, which is the label to which builtin_longjmp transfered - control; this pattern may be emitted at a small offset from that - label. - -`builtin_longjmp' - This pattern, if defined, performs the entire action of the - longjmp. You will not normally need to define this pattern unless - you also define `builtin_setjmp_setup'. The single argument is a - pointer to the `jmp_buf'. - -`eh_return' - This pattern, if defined, affects the way `__builtin_eh_return', - and thence the call frame exception handling library routines, are - built. It is intended to handle non-trivial actions needed along - the abnormal return path. - - The pattern takes two arguments. The first is an offset to be - applied to the stack pointer. It will have been copied to some - appropriate location (typically `EH_RETURN_STACKADJ_RTX') which - will survive until after reload to when the normal epilogue is - generated. The second argument is the address of the exception - handler to which the function should return. This will normally - need to copied by the pattern to some special register or memory - location. - - This pattern only needs to be defined if call frame exception - handling is to be used, and simple moves involving - `EH_RETURN_STACKADJ_RTX' and `EH_RETURN_HANDLER_RTX' are not - sufficient. - -`prologue' - This pattern, if defined, emits RTL for entry to a function. The - function entry is responsible for setting up the stack frame, - initializing the frame pointer register, saving callee saved - registers, etc. - - Using a prologue pattern is generally preferred over defining - `TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the - prologue. - - The `prologue' pattern is particularly useful for targets which - perform instruction scheduling. - -`epilogue' - This pattern emits RTL for exit from a function. The function - exit is responsible for deallocating the stack frame, restoring - callee saved registers and emitting the return instruction. - - Using an epilogue pattern is generally preferred over defining - `TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the - epilogue. - - The `epilogue' pattern is particularly useful for targets which - perform instruction scheduling or which have delay slots for their - return instruction. - -`sibcall_epilogue' - This pattern, if defined, emits RTL for exit from a function - without the final branch back to the calling function. This - pattern will be emitted before any sibling call (aka tail call) - sites. - - The `sibcall_epilogue' pattern must not clobber any arguments used - for parameter passing or any stack slots for arguments passed to - the current function. - -`trap' - This pattern, if defined, signals an error, typically by causing - some kind of signal to be raised. Among other places, it is used - by the Java front end to signal `invalid array index' exceptions. - -`conditional_trap' - Conditional trap instruction. Operand 0 is a piece of RTL which - performs a comparison. Operand 1 is the trap code, an integer. - - A typical `conditional_trap' pattern looks like - - (define_insn "conditional_trap" - [(trap_if (match_operator 0 "trap_operator" - [(cc0) (const_int 0)]) - (match_operand 1 "const_int_operand" "i"))] - "" - "...") - -`prefetch' - This pattern, if defined, emits code for a non-faulting data - prefetch instruction. Operand 0 is the address of the memory to - prefetch. Operand 1 is a constant 1 if the prefetch is preparing - for a write to the memory address, or a constant 0 otherwise. - Operand 2 is the expected degree of temporal locality of the data - and is a value between 0 and 3, inclusive; 0 means that the data - has no temporal locality, so it need not be left in the cache - after the access; 3 means that the data has a high degree of - temporal locality and should be left in all levels of cache - possible; 1 and 2 mean, respectively, a low or moderate degree of - temporal locality. - - Targets that do not support write prefetches or locality hints can - ignore the values of operands 1 and 2. - -`cycle_display' - This pattern, if present, will be emitted by the instruction - scheduler at the beginning of each new clock cycle. This can be - used for annotating the assembler output with cycle counts. - Operand 0 is a `const_int' that holds the clock cycle. - - - -File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc - -When the Order of Patterns Matters -================================== - - Sometimes an insn can match more than one instruction pattern. Then -the pattern that appears first in the machine description is the one -used. Therefore, more specific patterns (patterns that will match -fewer things) and faster instructions (those that will produce better -code when they do match) should usually go first in the description. - - In some cases the effect of ordering the patterns can be used to hide -a pattern when it is not valid. For example, the 68000 has an -instruction for converting a fullword to floating point and another for -converting a byte to floating point. An instruction converting an -integer to floating point could match either one. We put the pattern -to convert the fullword first to make sure that one will be used rather -than the other. (Otherwise a large integer might be generated as a -single-byte immediate quantity, which would not work.) Instead of -using this pattern ordering it would be possible to make the pattern -for convert-a-byte smart enough to deal properly with any constant -value. - - -File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc - -Interdependence of Patterns -=========================== - - Every machine description must have a named pattern for each of the -conditional branch names `bCOND'. The recognition template must always -have the form - - (set (pc) - (if_then_else (COND (cc0) (const_int 0)) - (label_ref (match_operand 0 "" "")) - (pc))) - -In addition, every machine description must have an anonymous pattern -for each of the possible reverse-conditional branches. Their templates -look like - - (set (pc) - (if_then_else (COND (cc0) (const_int 0)) - (pc) - (label_ref (match_operand 0 "" "")))) - -They are necessary because jump optimization can turn direct-conditional -branches into reverse-conditional branches. - - It is often convenient to use the `match_operator' construct to -reduce the number of patterns that must be specified for branches. For -example, - - (define_insn "" - [(set (pc) - (if_then_else (match_operator 0 "comparison_operator" - [(cc0) (const_int 0)]) - (pc) - (label_ref (match_operand 1 "" ""))))] - "CONDITION" - "...") - - In some cases machines support instructions identical except for the -machine mode of one or more operands. For example, there may be -"sign-extend halfword" and "sign-extend byte" instructions whose -patterns are - - (set (match_operand:SI 0 ...) - (extend:SI (match_operand:HI 1 ...))) - - (set (match_operand:SI 0 ...) - (extend:SI (match_operand:QI 1 ...))) - -Constant integers do not specify a machine mode, so an instruction to -extend a constant value could match either pattern. The pattern it -actually will match is the one that appears first in the file. For -correct results, this must be the one for the widest possible mode -(`HImode', here). If the pattern matches the `QImode' instruction, the -results will be incorrect if the constant value does not actually fit -that mode. - - Such instructions to extend constants are rarely generated because -they are optimized away, but they do occasionally happen in nonoptimized -compilations. - - If a constraint in a pattern allows a constant, the reload pass may -replace a register with a constant permitted by the constraint in some -cases. Similarly for memory references. Because of this substitution, -you should not provide separate patterns for increment and decrement -instructions. Instead, they should be generated from the same pattern -that supports register-register add insns by examining the operands and -generating the appropriate machine instruction. -