--- gcc/gcc.info-12 2018/04/24 17:51:24 1.1.1.1 +++ gcc/gcc.info-12 2018/04/24 18:07:53 1.1.1.5 @@ -1,1150 +1,1107 @@ -This is Info file gcc.info, produced by Makeinfo-1.43 from the input +This is Info file gcc.info, produced by Makeinfo-1.54 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. + Published by the Free Software Foundation 675 Massachusetts Avenue +Cambridge, MA 02139 USA - 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. + Copyright (C) 1988, 1989, 1992, 1993 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 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. - - -File: gcc.info, Node: Storage Layout, Next: Type Layout, Prev: Run-time Target, Up: Machine Macros - -Storage Layout -============== - - 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. +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: Type Layout, Next: Registers, Prev: Storage Layout, Up: Machine Macros +File: gcc.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL -Layout of Source Language Data Types -==================================== +Side Effect Expressions +======================= - 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'. + The expression codes described so far represent values, not actions. +But machine instructions never produce values; they are meaningful only +for their side effects on the state of the machine. Special expression +codes are used to represent side effects. + + The body of an instruction is always one of these side effect codes; +the codes described above, which represent values, appear only as the +operands of these. + +`(set LVAL X)' + Represents the action of storing the value of X into the place + represented by LVAL. LVAL must be an expression representing a + place that can be stored in: `reg' (or `subreg' or + `strict_low_part'), `mem', `pc' or `cc0'. + + If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then + X must be valid for that mode. + + If LVAL is a `reg' whose machine mode is less than the full width + of the register, then it means that the part of the register + specified by the machine mode is given the specified value and the + rest of the register receives an undefined value. Likewise, if + LVAL is a `subreg' whose machine mode is narrower than the mode of + the register, the rest of the register can be changed in an + undefined way. + + If LVAL is a `strict_low_part' of a `subreg', then the part of the + register specified by the machine mode of the `subreg' is given + the value X and the rest of the register is not changed. + + If LVAL is `(cc0)', it has no machine mode, and X may be either a + `compare' expression or a value that may have any mode. The + latter case represents a "test" instruction. The expression `(set + (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N) + (const_int 0)))'. Use the former expression to save space during + the compilation. + + If LVAL is `(pc)', we have a jump instruction, and the + possibilities for X are very limited. It may be a `label_ref' + expression (unconditional jump). It may be an `if_then_else' + (conditional jump), in which case either the second or the third + operand must be `(pc)' (for the case which does not jump) and the + other of the two must be a `label_ref' (for the case which does + jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may + be a `reg' or a `mem'; these unusual patterns are used to + represent jumps through branch tables. + + If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not + be `VOIDmode' and the mode of X must be valid for the mode of LVAL. + + LVAL is customarily accessed with the `SET_DEST' macro and X with + the `SET_SRC' macro. + +`(return)' + As the sole expression in a pattern, represents a return from the + current function, on machines where this can be done with one + instruction, such as Vaxes. On machines where a multi-instruction + "epilogue" must be executed in order to return from the function, + returning is done by jumping to a label which precedes the + epilogue, and the `return' expression code is never used. + + Inside an `if_then_else' expression, represents the value to be + placed in `pc' to return to the caller. + + Note that an insn pattern of `(return)' is logically equivalent to + `(set (pc) (return))', but the latter form is never used. + +`(call FUNCTION NARGS)' + Represents a function call. FUNCTION is a `mem' expression whose + address is the address of the function to be called. NARGS is an + expression which can be used for two purposes: on some machines it + represents the number of bytes of stack argument; on others, it + represents the number of argument registers. + + Each machine has a standard machine mode which FUNCTION must have. + The machine description defines macro `FUNCTION_MODE' to expand + into the requisite mode name. The purpose of this mode is to + specify what kind of addressing is allowed, on machines where the + allowed kinds of addressing depend on the machine mode being + addressed. + +`(clobber X)' + Represents the storing or possible storing of an unpredictable, + undescribed value into X, which must be a `reg', `scratch' or + `mem' expression. + + One place this is used is in string instructions that store + standard values into particular hard registers. It may not be + worth the trouble to describe the values that are stored, but it + is essential to inform the compiler that the registers will be + altered, lest it attempt to keep data in them across the string + instruction. + + If X is `(mem:BLK (const_int 0))', it means that all memory + locations must be presumed clobbered. + + Note that the machine description classifies certain hard + registers as "call-clobbered". All function call instructions are + assumed by default to clobber these registers, so there is no need + to use `clobber' expressions to indicate this fact. Also, each + function call is assumed to have the potential to alter any memory + location, unless the function is declared `const'. + + If the last group of expressions in a `parallel' are each a + `clobber' expression whose arguments are `reg' or `match_scratch' + (*note RTL Template::.) expressions, the combiner phase can add + the appropriate `clobber' expressions to an insn it has + constructed when doing so will cause a pattern to be matched. + + This feature can be used, for example, on a machine that whose + multiply and add instructions don't use an MQ register but which + has an add-accumulate instruction that does clobber the MQ + register. Similarly, a combined instruction might require a + temporary register while the constituent instructions might not. + + When a `clobber' expression for a register appears inside a + `parallel' with other side effects, the register allocator + guarantees that the register is unoccupied both before and after + that insn. However, the reload phase may allocate a register used + for one of the inputs unless the `&' constraint is specified for + the selected alternative (*note Modifiers::.). You can clobber + either a specific hard register, a pseudo register, or a `scratch' + expression; in the latter two cases, GNU CC will allocate a hard + register that is available there for use as a temporary. + + For instructions that require a temporary register, you should use + `scratch' instead of a pseudo-register because this will allow the + combiner phase to add the `clobber' when required. You do this by + coding (`clobber' (`match_scratch' ...)). If you do clobber a + pseudo register, use one which appears nowhere else--generate a + new one each time. Otherwise, you may confuse CSE. + + There is one other known use for clobbering a pseudo register in a + `parallel': when one of the input operands of the insn is also + clobbered by the insn. In this case, using the same pseudo + register in the clobber and elsewhere in the insn produces the + expected results. + +`(use X)' + Represents the use of the value of X. It indicates that the value + in X at this point in the program is needed, even though it may + not be apparent why this is so. Therefore, the compiler will not + attempt to delete previous instructions whose only effect is to + store a value in X. X must be a `reg' expression. + + During the delayed branch scheduling phase, X may be an insn. + This indicates that X previously was located at this place in the + code and its data dependencies need to be taken into account. + These `use' insns will be deleted before the delayed branch + scheduling phase exits. + +`(parallel [X0 X1 ...])' + Represents several side effects performed in parallel. The square + brackets stand for a vector; the operand of `parallel' is a vector + of expressions. X0, X1 and so on are individual side effect + expressions--expressions of code `set', `call', `return', + `clobber' or `use'. + + "In parallel" means that first all the values used in the + individual side-effects are computed, and second all the actual + side-effects are performed. For example, + + (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) + (set (mem:SI (reg:SI 1)) (reg:SI 1))]) + + says unambiguously that the values of hard register 1 and the + memory location addressed by it are interchanged. In both places + where `(reg:SI 1)' appears as a memory address it refers to the + value in register 1 *before* the execution of the insn. + + It follows that it is *incorrect* to use `parallel' and expect the + result of one `set' to be available for the next one. For + example, people sometimes attempt to represent a jump-if-zero + instruction this way: + + (parallel [(set (cc0) (reg:SI 34)) + (set (pc) (if_then_else + (eq (cc0) (const_int 0)) + (label_ref ...) + (pc)))]) + + But this is incorrect, because it says that the jump condition + depends on the condition code value *before* this instruction, not + on the new value that is set by this instruction. + + Peephole optimization, which takes place together with final + assembly code output, can produce insns whose patterns consist of + a `parallel' whose elements are the operands needed to output the + resulting assembler code--often `reg', `mem' or constant + expressions. This would not be well-formed RTL at any other stage + in compilation, but it is ok then because no further optimization + remains to be done. However, the definition of the macro + `NOTICE_UPDATE_CC', if any, must deal with such insns if you + define any peephole optimizations. + +`(sequence [INSNS ...])' + Represents a sequence of insns. Each of the INSNS that appears in + the vector is suitable for appearing in the chain of insns, so it + must be an `insn', `jump_insn', `call_insn', `code_label', + `barrier' or `note'. + + A `sequence' RTX is never placed in an actual insn during RTL + generation. It represents the sequence of insns that result from a + `define_expand' *before* those insns are passed to `emit_insn' to + insert them in the chain of insns. When actually inserted, the + individual sub-insns are separated out and the `sequence' is + forgotten. + + After delay-slot scheduling is completed, an insn and all the + insns that reside in its delay slots are grouped together into a + `sequence'. The insn requiring the delay slot is the first insn + in the vector; subsequent insns are to be placed in the delay slot. + + `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to + indicate that a branch insn should be used that will conditionally + annul the effect of the insns in the delay slots. In such a case, + `INSN_FROM_TARGET_P' indicates that the insn is from the target of + the branch and should be executed only if the branch is taken; + otherwise the insn should be executed only if the branch is not + taken. *Note Delay Slots::. + + These expression codes appear in place of a side effect, as the body +of an insn, though strictly speaking they do not always describe side +effects as such: + +`(asm_input S)' + Represents literal assembler code as described by the string S. + +`(unspec [OPERANDS ...] INDEX)' +`(unspec_volatile [OPERANDS ...] INDEX)' + Represents a machine-specific operation on OPERANDS. INDEX + selects between multiple machine-specific operations. + `unspec_volatile' is used for volatile operations and operations + that may trap; `unspec' is used for other operations. + + These codes may appear inside a `pattern' of an insn, inside a + `parallel', or inside an expression. + +`(addr_vec:M [LR0 LR1 ...])' + Represents a table of jump addresses. The vector elements LR0, + etc., are `label_ref' expressions. The mode M specifies how much + space is given to each address; normally M would be `Pmode'. + +`(addr_diff_vec:M BASE [LR0 LR1 ...])' + Represents a table of jump addresses expressed as offsets from + BASE. The vector elements LR0, etc., are `label_ref' expressions + and so is BASE. The mode M specifies how much space is given to + each address-difference.  -File: gcc.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Machine Macros - -Register Usage -============== +File: gcc.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL - This section explains how to describe what registers the target -machine has, and how (in general) they can be used. +Embedded Side-Effects on Addresses +================================== - 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: + Four special side-effect expression codes appear as memory addresses. -* 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. +`(pre_dec:M X)' + Represents the side effect of decrementing X by a standard amount + and represents also the value that X has after being decremented. + x must be a `reg' or `mem', but most machines allow only a `reg'. + m must be the machine mode for pointers on the machine in use. + The amount X is decremented by is the length in bytes of the + machine mode of the containing memory reference of which this + expression serves as the address. Here is an example of its use: + + (mem:DF (pre_dec:SI (reg:SI 39))) + + This says to decrement pseudo register 39 by the length of a + `DFmode' value and use the result to address a `DFmode' value. + +`(pre_inc:M X)' + Similar, but specifies incrementing X instead of decrementing it. + +`(post_dec:M X)' + Represents the same side effect as `pre_dec' but a different + value. The value represented here is the value X has before being + decremented. + +`(post_inc:M X)' + Similar, but specifies incrementing X instead of decrementing it. + + These embedded side effect expressions must be used with care. +Instruction patterns may not use them. Until the `flow' pass of the +compiler, they may occur only to represent pushes onto the stack. The +`flow' pass finds cases where registers are incremented or decremented +in one instruction and used as an address shortly before or after; +these cases are then transformed to use pre- or post-increment or +-decrement. + + If a register used as the operand of these expressions is used in +another address in an insn, the original value of the register is used. +Uses of the register outside of an address are not permitted within the +same insn as a use in an embedded side effect expression because such +insns behave differently on different machines and hence must be treated +as ambiguous and disallowed. + + An instruction that can be represented with an embedded side effect +could also be represented using `parallel' containing an additional +`set' to describe how the address register is altered. This is not +done because machines that allow these operations at all typically +allow them wherever a memory address is called for. Describing them as +additional parallel stores would require doubling the number of entries +in the machine description.  -File: gcc.info, Node: Register Basics, Next: Allocation Order, Up: Registers +File: gcc.info, Node: Assembler, Next: Insns, Prev: Incdec, Up: RTL -Basic Characteristics of Registers ----------------------------------- +Assembler Instructions as Expressions +===================================== -`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'. + The RTX code `asm_operands' represents a value produced by a +user-specified assembler instruction. It is used to represent an `asm' +statement with arguments. An `asm' statement with a single output +operand, like this: + + asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); + +is represented using a single `asm_operands' RTX which represents the +value that is stored in `outputvar': + + (set RTX-FOR-OUTPUTVAR + (asm_operands "foo %1,%2,%0" "a" 0 + [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] + [(asm_input:M1 "g") + (asm_input:M2 "di")])) + +Here the operands of the `asm_operands' RTX are the assembler template +string, the output-operand's constraint, the index-number of the output +operand among the output operands specified, a vector of input operand +RTX's, and a vector of input-operand modes and constraints. The mode +M1 is the mode of the sum `x+y'; M2 is that of `*z'. + + When an `asm' statement has multiple output values, its insn has +several such `set' RTX's inside of a `parallel'. Each `set' contains a +`asm_operands'; all of these share the same assembler template and +vectors, but each contains the constraint for the respective output +operand. They are also distinguished by the output-operand index +number, which is 0, 1, ... for successive output operands.  -File: gcc.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers +File: gcc.info, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL -Order of Allocation of Registers --------------------------------- +Insns +===== -`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. - - On most machines, it is not necessary to define this macro. + The RTL representation of the code for a function is a doubly-linked +chain of objects called "insns". Insns are expressions with special +codes that are used for no other purpose. Some insns are actual +instructions; others represent dispatch tables for `switch' statements; +others represent labels to jump to or various sorts of declarative +information. + + In addition to its own specific data, each insn must have a unique +id-number that distinguishes it from all other insns in the current +function (after delayed branch scheduling, copies of an insn with the +same id-number may be present in multiple places in a function, but +these copies will always be identical and will only appear inside a +`sequence'), and chain pointers to the preceding and following insns. +These three fields occupy the same position in every insn, independent +of the expression code of the insn. They could be accessed with `XEXP' +and `XINT', but instead three special macros are always used: + +`INSN_UID (I)' + Accesses the unique id of insn I. + +`PREV_INSN (I)' + Accesses the chain pointer to the insn preceding I. If I is the + first insn, this is a null pointer. + +`NEXT_INSN (I)' + Accesses the chain pointer to the insn following I. If I is the + last insn, this is a null pointer. + + The first insn in the chain is obtained by calling `get_insns'; the +last insn is the result of calling `get_last_insn'. Within the chain +delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must +always correspond: if INSN is not the first insn, + + NEXT_INSN (PREV_INSN (INSN)) == INSN + +is always true and if INSN is not the last insn, + + PREV_INSN (NEXT_INSN (INSN)) == INSN + +is always true. + + After delay slot scheduling, some of the insns in the chain might be +`sequence' expressions, which contain a vector of insns. The value of +`NEXT_INSN' in all but the last of these insns is the next insn in the +vector; the value of `NEXT_INSN' of the last insn in the vector is the +same as the value of `NEXT_INSN' for the `sequence' in which it is +contained. Similar rules apply for `PREV_INSN'. + + This means that the above invariants are not necessarily true for +insns inside `sequence' expressions. Specifically, if INSN is the +first insn in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn +containing the `sequence' expression, as is the value of `PREV_INSN +(NEXT_INSN (INSN))' is INSN is the last insn in the `sequence' +expression. You can use these expressions to find the containing +`sequence' expression. + + Every insn has one of the following six expression codes: + +`insn' + The expression code `insn' is used for instructions that do not + jump and do not do function calls. `sequence' expressions are + always contained in insns with code `insn' even if one of those + insns should jump or do function calls. + + Insns with code `insn' have four additional fields beyond the three + mandatory ones listed above. These four are described in a table + below. + +`jump_insn' + The expression code `jump_insn' is used for instructions that may + jump (or, more generally, may contain `label_ref' expressions). If + there is an instruction to return from the current function, it is + recorded as a `jump_insn'. + + `jump_insn' insns have the same extra fields as `insn' insns, + accessed in the same way and in addition contains a field + `JUMP_LABEL' which is defined once jump optimization has completed. + + For simple conditional and unconditional jumps, this field + contains the `code_label' to which this insn will (possibly + conditionally) branch. In a more complex jump, `JUMP_LABEL' + records one of the labels that the insn refers to; the only way to + find the others is to scan the entire body of the insn. + + Return insns count as jumps, but since they do not refer to any + labels, they have zero in the `JUMP_LABEL' field. + +`call_insn' + The expression code `call_insn' is used for instructions that may + do function calls. It is important to distinguish these + instructions because they imply that certain registers and memory + locations may be altered unpredictably. + + A `call_insn' insn may be preceded by insns that contain a single + `use' expression and be followed by insns the contain a single + `clobber' expression. If so, these `use' and `clobber' + expressions are treated as being part of the function call. There + must not even be a `note' between the `call_insn' and the `use' or + `clobber' insns for this special treatment to take place. This is + somewhat of a kludge and will be removed in a later version of GNU + CC. + + `call_insn' insns have the same extra fields as `insn' insns, + accessed in the same way. + +`code_label' + A `code_label' insn represents a label that a jump insn can jump + to. It contains two special fields of data in addition to the + three standard ones. `CODE_LABEL_NUMBER' is used to hold the + "label number", a number that identifies this label uniquely among + all the labels in the compilation (not just in the current + function). Ultimately, the label is represented in the assembler + output as an assembler label, usually of the form `LN' where N is + the label number. + + When a `code_label' appears in an RTL expression, it normally + appears within a `label_ref' which represents the address of the + label, as a number. + + The field `LABEL_NUSES' is only defined once the jump optimization + phase is completed and contains the number of times this label is + referenced in the current function. + +`barrier' + Barriers are placed in the instruction stream when control cannot + flow past them. They are placed after unconditional jump + instructions to indicate that the jumps are unconditional and + after calls to `volatile' functions, which do not return (e.g., + `exit'). They contain no information beyond the three standard + fields. + +`note' + `note' insns are used to represent additional debugging and + declarative information. They contain two nonstandard fields, an + integer which is accessed with the macro `NOTE_LINE_NUMBER' and a + string accessed with `NOTE_SOURCE_FILE'. + + If `NOTE_LINE_NUMBER' is positive, the note represents the + position of a source line and `NOTE_SOURCE_FILE' is the source + file name that the line came from. These notes control generation + of line number data in the assembler output. + + Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a + code with one of the following values (and `NOTE_SOURCE_FILE' must + contain a null pointer): + + `NOTE_INSN_DELETED' + Such a note is completely ignorable. Some passes of the + compiler delete insns by altering them into notes of this + kind. + + `NOTE_INSN_BLOCK_BEG' + `NOTE_INSN_BLOCK_END' + These types of notes indicate the position of the beginning + and end of a level of scoping of variable names. They + control the output of debugging information. + + `NOTE_INSN_LOOP_BEG' + `NOTE_INSN_LOOP_END' + These types of notes indicate the position of the beginning + and end of a `while' or `for' loop. They enable the loop + optimizer to find loops quickly. + + `NOTE_INSN_LOOP_CONT' + Appears at the place in a loop that `continue' statements + jump to. + + `NOTE_INSN_LOOP_VTOP' + This note indicates the place in a loop where the exit test + begins for those loops in which the exit test has been + duplicated. This position becomes another virtual start of + the loop when considering loop invariants. + + `NOTE_INSN_FUNCTION_END' + Appears near the end of the function body, just before the + label that `return' statements jump to (on machine where a + single instruction does not suffice for returning). This + note may be deleted by jump optimization. + + `NOTE_INSN_SETJMP' + Appears following each call to `setjmp' or a related function. + + These codes are printed symbolically when they appear in debugging + dumps. + + The machine mode of an insn is normally `VOIDmode', but some phases +use the mode for various purposes; for example, the reload pass sets it +to `HImode' if the insn needs reloading but not register elimination +and `QImode' if both are required. The common subexpression +elimination pass sets the mode of an insn to `QImode' when it is the +first insn in a block that has already been processed. + + Here is a table of the extra fields of `insn', `jump_insn' and +`call_insn' insns: + +`PATTERN (I)' + An expression for the side effect performed by this insn. This + must be one of the following codes: `set', `call', `use', + `clobber', `return', `asm_input', `asm_output', `addr_vec', + `addr_diff_vec', `trap_if', `unspec', `unspec_volatile', + `parallel', or `sequence'. If it is a `parallel', each element of + the `parallel' must be one these codes, except that `parallel' + expressions cannot be nested and `addr_vec' and `addr_diff_vec' + are not permitted inside a `parallel' expression. + +`INSN_CODE (I)' + An integer that says which pattern in the machine description + matches this insn, or -1 if the matching has not yet been + attempted. + + Such matching is never attempted and this field remains -1 on an + insn whose pattern consists of a single `use', `clobber', + `asm_input', `addr_vec' or `addr_diff_vec' expression. + + Matching is also never attempted on insns that result from an `asm' + statement. These contain at least one `asm_operands' expression. + The function `asm_noperands' returns a non-negative value for such + insns. + + In the debugging output, this field is printed as a number + followed by a symbolic representation that locates the pattern in + the `md' file as some small positive or negative offset from a + named pattern. + +`LOG_LINKS (I)' + A list (chain of `insn_list' expressions) giving information about + dependencies between instructions within a basic block. Neither a + jump nor a label may come between the related insns. + +`REG_NOTES (I)' + A list (chain of `expr_list' and `insn_list' expressions) giving + miscellaneous information about the insn. It is often information + pertaining to the registers used in this insn. + + The `LOG_LINKS' field of an insn is a chain of `insn_list' +expressions. Each of these has two operands: the first is an insn, and +the second is another `insn_list' expression (the next one in the +chain). The last `insn_list' in the chain has a null pointer as second +operand. The significant thing about the chain is which insns appear +in it (as first operands of `insn_list' expressions). Their order is +not significant. + + This list is originally set up by the flow analysis pass; it is a +null pointer until then. Flow only adds links for those data +dependencies which can be used for instruction combination. For each +insn, the flow analysis pass adds a link to insns which store into +registers values that are used for the first time in this insn. The +instruction scheduling pass adds extra links so that every dependence +will be represented. Links represent data dependencies, +antidependencies and output dependencies; the machine mode of the link +distinguishes these three types: antidependencies have mode +`REG_DEP_ANTI', output dependencies have mode `REG_DEP_OUTPUT', and +data dependencies have mode `VOIDmode'. + + The `REG_NOTES' field of an insn is a chain similar to the +`LOG_LINKS' field but it includes `expr_list' expressions in addition +to `insn_list' expressions. There are several kinds of register notes, +which are distinguished by the machine mode, which in a register note +is really understood as being an `enum reg_note'. The first operand OP +of the note is data whose meaning depends on the kind of note. + + The macro `REG_NOTE_KIND (X)' returns the kind of register note. +Its counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' sets the +register note type of X to be NEWKIND. + + Register notes are of three classes: They may say something about an +input to an insn, they may say something about an output of an insn, or +they may create a linkage between two insns. There are also a set of +values that are only used in `LOG_LINKS'. + + These register notes annotate inputs to an insn: + +`REG_DEAD' + The value in OP dies in this insn; that is to say, altering the + value immediately after this insn would not affect the future + behavior of the program. + + This does not necessarily mean that the register OP has no useful + value after this insn since it may also be an output of the insn. + In such a case, however, a `REG_DEAD' note would be redundant and + is usually not present until after the reload pass, but no code + relies on this fact. + +`REG_INC' + The register OP is incremented (or decremented; at this level + there is no distinction) by an embedded side effect inside this + insn. This means it appears in a `post_inc', `pre_inc', + `post_dec' or `pre_dec' expression. + +`REG_NONNEG' + The register OP is known to have a nonnegative value when this + insn is reached. This is used so that decrement and branch until + zero instructions, such as the m68k dbra, can be matched. + + The `REG_NONNEG' note is added to insns only if the machine + description has a `decrement_and_branch_until_zero' pattern. + +`REG_NO_CONFLICT' + This insn does not cause a conflict between OP and the item being + set by this insn even though it might appear that it does. In + other words, if the destination register and OP could otherwise be + assigned the same register, this insn does not prevent that + assignment. + + Insns with this note are usually part of a block that begins with a + `clobber' insn specifying a multi-word pseudo register (which will + be the output of the block), a group of insns that each set one + word of the value and have the `REG_NO_CONFLICT' note attached, + and a final insn that copies the output to itself with an attached + `REG_EQUAL' note giving the expression being computed. This block + is encapsulated with `REG_LIBCALL' and `REG_RETVAL' notes on the + first and last insns, respectively. + +`REG_LABEL' + This insn uses OP, a `code_label', but is not a `jump_insn'. The + presence of this note allows jump optimization to be aware that OP + is, in fact, being used. + + The following notes describe attributes of outputs of an insn: + +`REG_EQUIV' +`REG_EQUAL' + This note is only valid on an insn that sets only one register and + indicates that that register will be equal to OP at run time; the + scope of this equivalence differs between the two types of notes. + The value which the insn explicitly copies into the register may + look different from OP, but they will be equal at run time. If the + output of the single `set' is a `strict_low_part' expression, the + note refers to the register that is contained in `SUBREG_REG' of + the `subreg' expression. + + For `REG_EQUIV', the register is equivalent to OP throughout the + entire function, and could validly be replaced in all its + occurrences by OP. ("Validly" here refers to the data flow of the + program; simple replacement may make some insns invalid.) For + example, when a constant is loaded into a register that is never + assigned any other value, this kind of note is used. + + When a parameter is copied into a pseudo-register at entry to a + function, a note of this kind records that the register is + equivalent to the stack slot where the parameter was passed. + Although in this case the register may be set by other insns, it + is still valid to replace the register by the stack slot + throughout the function. + + In the case of `REG_EQUAL', the register that is set by this insn + will be equal to OP at run time at the end of this insn but not + necessarily elsewhere in the function. In this case, OP is + typically an arithmetic expression. For example, when a sequence + of insns such as a library call is used to perform an arithmetic + operation, this kind of note is attached to the insn that produces + or copies the final value. + + These two notes are used in different ways by the compiler passes. + `REG_EQUAL' is used by passes prior to register allocation (such as + common subexpression elimination and loop optimization) to tell + them how to think of that value. `REG_EQUIV' notes are used by + register allocation to indicate that there is an available + substitute expression (either a constant or a `mem' expression for + the location of a parameter on the stack) that may be used in + place of a register if insufficient registers are available. + + Except for stack homes for parameters, which are indicated by a + `REG_EQUIV' note and are not useful to the early optimization + passes and pseudo registers that are equivalent to a memory + location throughout there entire life, which is not detected until + later in the compilation, all equivalences are initially indicated + by an attached `REG_EQUAL' note. In the early stages of register + allocation, a `REG_EQUAL' note is changed into a `REG_EQUIV' note + if OP is a constant and the insn represents the only set of its + destination register. + + Thus, compiler passes prior to register allocation need only check + for `REG_EQUAL' notes and passes subsequent to register allocation + need only check for `REG_EQUIV' notes. + +`REG_UNUSED' + The register OP being set by this insn will not be used in a + subsequent insn. This differs from a `REG_DEAD' note, which + indicates that the value in an input will not be used subsequently. + These two notes are independent; both may be present for the same + register. + +`REG_WAS_0' + The single output of this insn contained zero before this insn. + OP is the insn that set it to zero. You can rely on this note if + it is present and OP has not been deleted or turned into a `note'; + its absence implies nothing. + + These notes describe linkages between insns. They occur in pairs: +one insn has one of a pair of notes that points to a second insn, which +has the inverse note pointing back to the first insn. + +`REG_RETVAL' + This insn copies the value of a multi-insn sequence (for example, a + library call), and OP is the first insn of the sequence (for a + library call, the first insn that was generated to set up the + arguments for the library call). + + Loop optimization uses this note to treat such a sequence as a + single operation for code motion purposes and flow analysis uses + this note to delete such sequences whose results are dead. + + A `REG_EQUAL' note will also usually be attached to this insn to + provide the expression being computed by the sequence. + +`REG_LIBCALL' + This is the inverse of `REG_RETVAL': it is placed on the first + insn of a multi-insn sequence, and it points to the last one. + +`REG_CC_SETTER' +`REG_CC_USER' + On machines that use `cc0', the insns which set and use `cc0' set + and use `cc0' are adjacent. However, when branch delay slot + filling is done, this may no longer be true. In this case a + `REG_CC_USER' note will be placed on the insn setting `cc0' to + point to the insn using `cc0' and a `REG_CC_SETTER' note will be + placed on the insn using `cc0' to point to the insn setting `cc0'. + + These values are only used in the `LOG_LINKS' field, and indicate +the type of dependency that each link represents. Links which indicate +a data dependence (a read after write dependence) do not use any code, +they simply have mode `VOIDmode', and are printed without any +descriptive text. + +`REG_DEP_ANTI' + This indicates an anti dependence (a write after read dependence). + +`REG_DEP_OUTPUT' + This indicates an output dependence (a write after write + dependence). + + For convenience, the machine mode in an `insn_list' or `expr_list' +is printed using these symbolic codes in debugging dumps. + + The only difference between the expression codes `insn_list' and +`expr_list' is that the first operand of an `insn_list' is assumed to +be an insn and is printed in debugging dumps as the insn's unique id; +the first operand of an `expr_list' is printed in the ordinary way as +an expression.  -File: gcc.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers +File: gcc.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL -How Values Fit in Registers ---------------------------- +RTL Representation of Function-Call Insns +========================================= - 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. + Insns that call subroutines have the RTL expression code `call_insn'. +These insns must satisfy special rules, and their bodies must use a +special RTL expression code, `call'. + + A `call' expression has two operands, as follows: + + (call (mem:FM ADDR) NBYTES) + +Here NBYTES is an operand that represents the number of bytes of +argument data being passed to the subroutine, FM is a machine mode +(which must equal as the definition of the `FUNCTION_MODE' macro in the +machine description) and ADDR represents the address of the subroutine. + + For a subroutine that returns no value, the `call' expression as +shown above is the entire body of the insn, except that the insn might +also contain `use' or `clobber' expressions. + + For a subroutine that returns a value whose mode is not `BLKmode', +the value is returned in a hard register. If this register's number is +R, then the body of the call insn looks like this: + + (set (reg:M R) + (call (mem:FM ADDR) NBYTES)) + +This RTL expression makes it clear (to the optimizer passes) that the +appropriate register receives a useful value in this insn. + + When a subroutine returns a `BLKmode' value, it is handled by +passing to the subroutine the address of a place to store the value. +So the call insn itself does not "return" any value, and it has the +same RTL form as a call that returns nothing. + + On some machines, the call instruction itself clobbers some register, +for example to contain the return address. `call_insn' insns on these +machines should have a body which is a `parallel' that contains both +the `call' expression and `clobber' expressions that indicate which +registers are destroyed. Similarly, if the call instruction requires +some register other than the stack pointer that is not explicitly +mentioned it its RTL, a `use' subexpression should mention that +register. + + Functions that are called are assumed to modify all registers listed +in the configuration macro `CALL_USED_REGISTERS' (*note Register +Basics::.) and, with the exception of `const' functions and library +calls, to modify all of memory. + + Insns containing just `use' expressions directly precede the +`call_insn' insn to indicate which registers contain inputs to the +function. Similarly, if registers other than those in +`CALL_USED_REGISTERS' are clobbered by the called function, insns +containing a single `clobber' follow immediately after the call to +indicate which registers.  -File: gcc.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers +File: gcc.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL -Handling Leaf Functions ------------------------ +Structure Sharing Assumptions +============================= - 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. + The compiler assumes that certain kinds of RTL expressions are +unique; there do not exist two distinct objects representing the same +value. In other cases, it makes an opposite assumption: that no RTL +expression object of a certain kind appears in more than one place in +the containing structure. + + These assumptions refer to a single function; except for the RTL +objects that describe global variables and external functions, and a +few standard objects such as small integer constants, no RTL objects +are common to two functions. + + * Each pseudo-register has only a single `reg' object to represent + it, and therefore only a single machine mode. + + * For any symbolic label, there is only one `symbol_ref' object + referring to it. + + * There is only one `const_int' expression with value 0, only one + with value 1, and only one with value -1. Some other integer + values are also stored uniquely. + + * There is only one `pc' expression. + + * There is only one `cc0' expression. + + * There is only one `const_double' expression with value 0 for each + floating point mode. Likewise for values 1 and 2. + + * No `label_ref' or `scratch' appears in more than one place in the + RTL structure; in other words, it is safe to do a tree-walk of all + the insns in the function and assume that each time a `label_ref' + or `scratch' is seen it is distinct from all others that are seen. + + * Only one `mem' object is normally created for each static variable + or stack slot, so these objects are frequently shared in all the + places they appear. However, separate but equal objects for these + variables are occasionally made. + + * When a single `asm' statement has multiple output operands, a + distinct `asm_operands' expression is made for each output operand. + However, these all share the vector which contains the sequence of + input operands. This sharing is used later on to test whether two + `asm_operands' expressions come from the same statement, so all + optimizations must carefully preserve the sharing if they copy the + vector at all. + + * No RTL object appears in more than one place in the RTL structure + except as described above. Many passes of the compiler rely on + this by assuming that they can modify RTL objects in place without + unwanted side-effects on other insns. + + * During initial RTL generation, shared structure is freely + introduced. After all the RTL for a function has been generated, + all shared structure is copied by `unshare_all_rtl' in + `emit-rtl.c', after which the above rules are guaranteed to be + followed. + + * During the combiner pass, shared structure within an insn can exist + temporarily. However, the shared structure is copied before the + combiner is finished with the insn. This is done by calling + `copy_rtx_if_shared', which is a subroutine of `unshare_all_rtl'.  -File: gcc.info, Node: Stack Registers, Next: Obsolete Register Macros, Prev: Leaf Functions, Up: Registers +File: gcc.info, Node: Reading RTL, Prev: Sharing, Up: RTL -Registers That Form a Stack ---------------------------- +Reading RTL +=========== - 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. + To read an RTL object from a file, call `read_rtx'. It takes one +argument, a stdio stream, and returns a single RTL object. - Currently, GNU CC can only handle one group of stack-like -registers, and they must be consecutively numbered. + Reading RTL from a file is very slow. This is no currently not a +problem because reading RTL occurs only as part of building the +compiler. -`STACK_REGS' - Define this if the machine has any stack-like registers. + People frequently have the idea of using RTL stored as text in a +file as an interface between a language front end and the bulk of GNU +CC. This idea is not feasible. -`FIRST_STACK_REG' - The number of the first stack-like register. This one is the top - of the stack. + GNU CC was designed to use RTL internally only. Correct RTL for a +given program is very dependent on the particular target machine. And +the RTL does not contain all the information about the program. -`LAST_STACK_REG' - The number of the last stack-like register. This one is the - bottom of the stack. + The proper way to interface GNU CC to a new language front end is +with the "tree" data structure. There is no manual for this data +structure, but it is described in the files `tree.h' and `tree.def'.  -File: gcc.info, Node: Obsolete Register Macros, Prev: Stack Registers, Up: Registers +File: gcc.info, Node: Machine Desc, Next: Target Macros, Prev: RTL, Up: Top -Obsolete Macros for Controlling Register Usage ----------------------------------------------- +Machine Descriptions +******************** - 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.) + A machine description has two parts: a file of instruction patterns +(`.md' file) and a C header file of macro definitions. - If this macro is not defined, it means that no death notes need - to be preserved. This is the usual situation. + The `.md' file for a target machine contains a pattern for each +instruction that the target machine supports (or at least each +instruction that is worth telling the compiler about). It may also +contain comments. A semicolon causes the rest of the line to be a +comment, unless the semicolon is inside a quoted string. - -File: gcc.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Machine Macros + See the next chapter for information on the C header file. -Register Classes -================ +* Menu: - 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. +* Patterns:: How to write instruction patterns. +* Example:: An explained example of a `define_insn' pattern. +* RTL Template:: The RTL template defines what insns match a pattern. +* Output Template:: The output template says how to make assembler code + from such an insn. +* Output Statement:: For more generality, write C code to output + the assembler code. +* Constraints:: When not all operands are general operands. +* Standard Names:: Names mark patterns to use for code generation. +* Pattern Ordering:: When the order of patterns makes a difference. +* Dependent Patterns:: Having one pattern may make you need another. +* Jump Patterns:: Special considerations for patterns for jump insns. +* Insn Canonicalizations::Canonicalization of Instructions +* Peephole Definitions::Defining machine-specific peephole optimizations. +* Expander Definitions::Generating a sequence of several RTL insns + for a standard operation. +* Insn Splitting:: Splitting Instructions into Multiple Instructions +* Insn Attributes:: Specifying the value of attributes for generated insns.  -File: gcc.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Machine Macros +File: gcc.info, Node: Patterns, Next: Example, Up: Machine Desc -Describing Stack Layout and Calling Conventions -=============================================== +Everything about Instruction Patterns +===================================== -* Menu: + Each instruction pattern contains an incomplete RTL expression, with +pieces to be filled in later, operand constraints that restrict how the +pieces can be filled in, and an output pattern or C code to generate +the assembler output, all wrapped up in a `define_insn' expression. + + A `define_insn' is an RTL expression containing four or five +operands: + + 1. An optional name. The presence of a name indicate that this + instruction pattern can perform a certain standard job for the + RTL-generation pass of the compiler. This pass knows certain + names and will use the instruction patterns with those names, if + the names are defined in the machine description. + + The absence of a name is indicated by writing an empty string + where the name should go. Nameless instruction patterns are never + used for generating RTL code, but they may permit several simpler + insns to be combined later on. + + Names that are not thus known and used in RTL-generation have no + effect; they are equivalent to no name at all. + + 2. The "RTL template" (*note RTL Template::.) is a vector of + incomplete RTL expressions which show what the instruction should + look like. It is incomplete because it may contain + `match_operand', `match_operator', and `match_dup' expressions + that stand for operands of the instruction. + + If the vector has only one element, that element is the template + for the instruction pattern. If the vector has multiple elements, + then the instruction pattern is a `parallel' expression containing + the elements described. + + 3. A condition. This is a string which contains a C expression that + is the final test to decide whether an insn body matches this + pattern. + + For a named pattern, the condition (if present) may not depend on + the data in the insn being matched, but only the + target-machine-type flags. The compiler needs to test these + conditions during initialization in order to learn exactly which + named instructions are available in a particular run. + + For nameless patterns, the condition is applied only when matching + an individual insn, and only after the insn has matched the + pattern's recognition template. The insn's operands may be found + in the vector `operands'. + + 4. The "output template": a string that says how to output matching + insns as assembler code. `%' in this string specifies where to + substitute the value of an operand. *Note Output Template::. + + When simple substitution isn't general enough, you can specify a + piece of C code to compute the output. *Note Output Statement::. -* Frame Layout:: -* Frame Registers:: -* Elimination:: -* Stack Arguments:: -* Register Arguments:: -* Scalar Return:: -* Aggregate Return:: -* Caller Saves:: -* Function Entry:: -* Profiling:: + 5. Optionally, a vector containing the values of attributes for insns + matching this pattern. *Note Insn Attributes::.  -File: gcc.info, Node: Frame Layout, Next: Frame Registers, Up: Stack and Calling +File: gcc.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc + +Example of `define_insn' +======================== + + Here is an actual example of an instruction pattern, for the +68000/68020. -Basic Stack Layout ------------------- + (define_insn "tstsi" + [(set (cc0) + (match_operand:SI 0 "general_operand" "rm"))] + "" + "* + { if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) + return \"tstl %0\"; + return \"cmpl #0,%0\"; }") + + This is an instruction that sets the condition codes based on the +value of a general operand. It has no condition, so any insn whose RTL +description has the form shown may be handled according to this +pattern. The name `tstsi' means "test a `SImode' value" and tells the +RTL generation pass that, when it is necessary to test such a value, an +insn to do so can be constructed using this pattern. + + The output control string is a piece of C code which chooses which +output template to return based on the kind of operand and the specific +type of CPU for which code is being generated. -`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. + `"rm"' is an operand constraint. Its meaning is explained below. - \ No newline at end of file