--- gcc/gcc.info-12 2018/04/24 17:51:24 1.1.1.1 +++ gcc/gcc.info-12 2018/04/24 18:11:43 1.1.1.6 @@ -1,1150 +1,1004 @@ -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. - - -File: gcc.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Machine Macros - -Layout of Source Language Data Types -==================================== - - 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'. - - -File: gcc.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Machine Macros - -Register Usage -============== - - This section explains how to describe what registers the target -machine has, and how (in general) they can be used. - - The description of which registers a specific instruction can use is -done with register classes; see *Note Register Classes::. For -information on using registers to access a stack frame, see *Note -Frame Registers::. For passing values in registers, see *Note -Register Arguments::. For returning values in registers, see *Note -Scalar Return::. - -* Menu: - -* Register Basics:: Number and kinds of registers. -* Allocation Order:: Order in which registers are allocated. -* Values in Registers:: What kinds of values each reg can hold. -* Leaf Functions:: Renumbering registers for leaf functions. -* Stack Registers:: Handling a register stack such as 80387. -* Obsolete Register Macros:: Macros formerly used for the 80387. - - -File: gcc.info, Node: Register Basics, Next: Allocation Order, Up: Registers - -Basic Characteristics of Registers ----------------------------------- - -`FIRST_PSEUDO_REGISTER' - Number of hardware registers known to the compiler. They receive - numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first - pseudo register's number really is assigned the number - `FIRST_PSEUDO_REGISTER'. - -`FIXED_REGISTERS' - An initializer that says which registers are used for fixed - purposes all throughout the compiled code and are therefore not - available for general allocation. These would include the stack - pointer, the frame pointer (except on machines where that can be - used as a general register when no frame pointer is needed), the - program counter on machines where that is considered one of the - addressable registers, and any other numbered register with a - standard use. - - This information is expressed as a sequence of numbers, separated - by commas and surrounded by braces. The Nth number is 1 if - register N is fixed, 0 otherwise. - - The table initialized from this macro, and the table initialized - by the following one, may be overridden at run time either - automatically, by the actions of the macro - `CONDITIONAL_REGISTER_USAGE', or by the user with the command - options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'. - -`CALL_USED_REGISTERS' - Like `FIXED_REGISTERS' but has 1 for each register that is - clobbered (in general) by function calls as well as for fixed - registers. This macro therefore identifies the registers that - are not available for general allocation of values that must live - across function calls. - - If a register has 0 in `CALL_USED_REGISTERS', the compiler - automatically saves it on function entry and restores it on - function exit, if the register is used within the function. - -`CONDITIONAL_REGISTER_USAGE' - Zero or more C statements that may conditionally modify two - variables `fixed_regs' and `call_used_regs' (both of type `char - []') after they have been initialized from the two preceding - macros. - - This is necessary in case the fixed or call-clobbered registers - depend on target flags. - - You need not define this macro if it has no work to do. - - If the usage of an entire class of registers depends on the target - flags, you may indicate this to GCC by using this macro to modify - `fixed_regs' and `call_used_regs' to 1 for each of the registers - in the classes which should not be used by GCC. Also define the - macro `REG_CLASS_FROM_LETTER' to return `NO_REGS' if it is called - with a letter for a class that shouldn't be used. - - (However, if this class is not included in `GENERAL_REGS' and all - of the insn patterns whose constraints permit this class are - controlled by target switches, then GCC will automatically avoid - using these registers when the target switches are opposed to - them.) - -`NON_SAVING_SETJMP' - If this macro is defined and has a nonzero value, it means that - `setjmp' and related functions fail to save the registers, or that - `longjmp' fails to restore them. To compensate, the compiler - avoids putting variables in registers in functions that use - `setjmp'. - - -File: gcc.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers - -Order of Allocation of Registers --------------------------------- - -`REG_ALLOC_ORDER' - If defined, an initializer for a vector of integers, containing - the numbers of hard registers in the order in which GNU CC should - prefer to use them (from most preferred to least). - - If this macro is not defined, registers are used lowest numbered - first (all else being equal). - - One use of this macro is on machines where the highest numbered - registers must always be saved and the save-multiple-registers - instruction supports only sequences of consecutive registers. On - such machines, define `REG_ALLOC_ORDER' to be an initializer that - lists the highest numbered allocatable register first. - -`ORDER_REGS_FOR_LOCAL_ALLOC' - A C statement (sans semicolon) to choose the order in which to - allocate hard registers for pseudo-registers local to a basic - block. - - Store the desired order of registers in the array - `reg_alloc_order'. Element 0 should be the register to allocate - first; element 1, the next register; and so on. - - The macro body should not assume anything about the contents of - `reg_alloc_order' before execution of the macro. - - On most machines, it is not necessary to define this macro. - - -File: gcc.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers - -How Values Fit in Registers ---------------------------- - - 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. - - -File: gcc.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers - -Handling Leaf Functions ------------------------ - - 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. - - -File: gcc.info, Node: Stack Registers, Next: Obsolete Register Macros, Prev: Leaf Functions, Up: Registers - -Registers That Form a Stack ---------------------------- - - There are special features to handle computers where some of the -"registers" form a stack, as in the 80387 coprocessor for the 80386. -Stack registers are normally written by pushing onto the stack, and are -numbered relative to the top of the stack. - - Currently, GNU CC can only handle one group of stack-like -registers, and they must be consecutively numbered. - -`STACK_REGS' - Define this if the machine has any stack-like registers. - -`FIRST_STACK_REG' - The number of the first stack-like register. This one is the top - of the stack. - -`LAST_STACK_REG' - The number of the last stack-like register. This one is the - bottom of the stack. - - -File: gcc.info, Node: Obsolete Register Macros, Prev: Stack Registers, Up: Registers - -Obsolete Macros for Controlling Register Usage ----------------------------------------------- - - These features do not work very well. They exist because they used -to be required to generate correct code for the 80387 coprocessor of -the 80386. They are no longer used by that machine description and -may be removed in a later version of the compiler. Don't use them! - -`OVERLAPPING_REGNO_P (REGNO)' - If defined, this is a C expression whose value is nonzero if hard - register number REGNO is an overlapping register. This means a - hard register which overlaps a hard register with a different - number. (Such overlap is undesirable, but occasionally it allows - a machine to be supported which otherwise could not be.) This - macro must return nonzero for *all* the registers which overlap - each other. GNU CC can use an overlapping register only in - certain limited ways. It can be used for allocation within a - basic block, and may be spilled for reloading; that is all. - - If this macro is not defined, it means that none of the hard - registers overlap each other. This is the usual situation. - -`INSN_CLOBBERS_REGNO_P (INSN, REGNO)' - If defined, this is a C expression whose value should be nonzero - if the insn INSN has the effect of mysteriously clobbering the - contents of hard register number REGNO. By "mysterious" we mean - that the insn's RTL expression doesn't describe such an effect. - - If this macro is not defined, it means that no insn clobbers - registers mysteriously. This is the usual situation; all else - being equal, it is best for the RTL expression to show all the - activity. - -`PRESERVE_DEATH_INFO_REGNO_P (REGNO)' - If defined, this is a C expression whose value is nonzero if - accurate `REG_DEAD' notes are needed for hard register number - REGNO at the time of outputting the assembler code. When this is - so, a few optimizations that take place after register allocation - and could invalidate the death notes are not done when this - register is involved. - - You would arrange to preserve death info for a register when some - of the code in the machine description which is executed to write - the assembler code looks at the death notes. This is necessary - only when the actual hardware feature which GNU CC thinks of as a - register is not actually a register of the usual sort. (It - might, for example, be a hardware stack.) - - If this macro is not defined, it means that no death notes need - to be preserved. This is the usual situation. - - -File: gcc.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Machine Macros - -Register Classes -================ - - On many machines, the numbered registers are not all equivalent. -For example, certain registers may not be allowed for indexed -addressing; certain registers may not be allowed in some instructions. - These machine restrictions are described to the compiler using -"register classes". - - You define a number of register classes, giving each one a name and -saying which of the registers belong to it. Then you can specify -register classes that are allowed as operands to particular -instruction patterns. - - In general, each register will belong to several classes. In fact, -one class must be named `ALL_REGS' and contain all the registers. -Another class must be named `NO_REGS' and contain no registers. Often -the union of two classes will be another class; however, this is not -required. - - One of the classes must be named `GENERAL_REGS'. There is nothing -terribly special about the name, but the operand constraint letters -`r' and `g' specify this class. If `GENERAL_REGS' is the same as -`ALL_REGS', just define it as a macro which expands to `ALL_REGS'. - - Order the classes so that if class X is contained in class Y then X -has a lower class number than Y. - - The way classes other than `GENERAL_REGS' are specified in operand -constraints is through machine-dependent operand constraint letters. -You can define such letters to correspond to various classes, then use -them in operand constraints. - - You should define a class for the union of two classes whenever some -instruction allows both classes. For example, if an instruction allows -either a floating point (coprocessor) register or a general register -for a certain operand, you should define a class -`FLOAT_OR_GENERAL_REGS' which includes both of them. Otherwise you -will get suboptimal code. - - You must also specify certain redundant information about the -register classes: for each class, which classes contain it and which -ones are contained in it; for each pair of classes, the largest class -contained in their union. - - When a value occupying several consecutive registers is expected in -a certain class, all the registers used must belong to that class. -Therefore, register classes cannot be used to enforce a requirement for -a register pair to start with an even-numbered register. The way to -specify this requirement is with `HARD_REGNO_MODE_OK'. - - Register classes used for input-operands of bitwise-and or shift -instructions have a special requirement: each such class must have, for -each fixed-point machine mode, a subclass whose registers can transfer -that mode to or from memory. For example, on some machines, the -operations for single-byte values (`QImode') are limited to certain -registers. When this is so, each register class that is used in a -bitwise-and or shift instruction must have a subclass consisting of -registers from which single-byte values can be loaded or stored. This -is so that `PREFERRED_RELOAD_CLASS' can always have a possible value -to return. - -`enum reg_class' - An enumeral type that must be defined with all the register class - names as enumeral values. `NO_REGS' must be first. `ALL_REGS' - must be the last register class, followed by one more enumeral - value, `LIM_REG_CLASSES', which is not a register class but rather - tells how many classes there are. - - Each register class has a number, which is the value of casting - the class name to type `int'. The number serves as an index in - many of the tables described below. - -`N_REG_CLASSES' - The number of distinct register classes, defined as follows: - - #define N_REG_CLASSES (int) LIM_REG_CLASSES - -`REG_CLASS_NAMES' - An initializer containing the names of the register classes as C - string constants. These names are used in writing some of the - debugging dumps. - -`REG_CLASS_CONTENTS' - An initializer containing the contents of the register classes, - as integers which are bit masks. The Nth integer specifies the - contents of class N. The way the integer MASK is interpreted is - that register R is in the class if `MASK & (1 << R)' is 1. - - When the machine has more than 32 registers, an integer does not - suffice. Then the integers are replaced by sub-initializers, - braced groupings containing several integers. Each - sub-initializer must be suitable as an initializer for the type - `HARD_REG_SET' which is defined in `hard-reg-set.h'. - -`REGNO_REG_CLASS (REGNO)' - A C expression whose value is a register class containing hard - register REGNO. In general there is more that one such class; - choose a class which is "minimal", meaning that no smaller class - also contains the register. - -`BASE_REG_CLASS' - A macro whose definition is the name of the class to which a valid - base register must belong. A base register is one used in an - address which is the register value plus a displacement. - -`INDEX_REG_CLASS' - A macro whose definition is the name of the class to which a valid - index register must belong. An index register is one used in an - address where its value is either multiplied by a scale factor or - added to another register (as well as added to a displacement). - -`REG_CLASS_FROM_LETTER (CHAR)' - A C expression which defines the machine-dependent operand - constraint letters for register classes. If CHAR is such a - letter, the value should be the register class corresponding to - it. Otherwise, the value should be `NO_REGS'. - -`REGNO_OK_FOR_BASE_P (NUM)' - A C expression which is nonzero if register number NUM is - suitable for use as a base register in operand addresses. It may - be either a suitable hard register or a pseudo register that has - been allocated such a hard register. - -`REGNO_OK_FOR_INDEX_P (NUM)' - A C expression which is nonzero if register number NUM is - suitable for use as an index register in operand addresses. It - may be either a suitable hard register or a pseudo register that - has been allocated such a hard register. - - The difference between an index register and a base register is - that the index register may be scaled. If an address involves - the sum of two registers, neither one of them scaled, then either - one may be labeled the "base" and the other the "index"; but - whichever labeling is used must fit the machine's constraints of - which registers may serve in each capacity. The compiler will - try both labelings, looking for one that is valid, and will - reload one or both registers only if neither labeling works. - -`PREFERRED_RELOAD_CLASS (X, CLASS)' - A C expression that places additional restrictions on the - register class to use when it is necessary to copy value X into a - register in class CLASS. The value is a register class; perhaps - CLASS, or perhaps another, smaller class. On many machines, the - definition - - #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS - - is safe. - - Sometimes returning a more restrictive class makes better code. - For example, on the 68000, when X is an integer constant that is - in range for a `moveq' instruction, the value of this macro is - always `DATA_REGS' as long as CLASS includes the data registers. - Requiring a data register guarantees that a `moveq' will be used. - - If X is a `const_double', by returning `NO_REGS' you can force X - into a memory constant. This is useful on certain machines where - immediate floating values cannot be loaded into certain kinds of +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: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL + +Registers and Memory +==================== + + Here are the RTL expression types for describing access to machine +registers and to main memory. + +`(reg:M N)' + For small values of the integer N (those that are less than + `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine + register number N: a "hard register". For larger values of N, it + stands for a temporary value or "pseudo register". The compiler's + strategy is to generate code assuming an unlimited number of such + pseudo registers, and later convert them into hard registers or + into memory references. + + M is the machine mode of the reference. It is necessary because + machines can generally refer to each register in more than one + mode. For example, a register may contain a full word but there + may be instructions to refer to it as a half word or as a single + byte, as well as instructions to refer to it as a floating point + number of various precisions. + + Even for a register that the machine can access in only one mode, + the mode must always be specified. + + The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine + description, since the number of hard registers on the machine is + an invariant characteristic of the machine. Note, however, that + not all of the machine registers must be general registers. All + the machine registers that can be used for storage of data are + given hard register numbers, even those that can be used only in + certain instructions or can hold only certain types of data. + + A hard register may be accessed in various modes throughout one + function, but each pseudo register is given a natural mode and is + accessed only in that mode. When it is necessary to describe an + access to a pseudo register using a nonnatural mode, a `subreg' + expression is used. + + A `reg' expression with a machine mode that specifies more than + one word of data may actually stand for several consecutive + registers. If in addition the register number specifies a + hardware register, then it actually represents several consecutive + hardware registers starting with the specified one. + + Each pseudo register number used in a function's RTL code is + represented by a unique `reg' expression. + + Some pseudo register numbers, those within the range of + `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear + during the RTL generation phase and are eliminated before the + optimization phases. These represent locations in the stack frame + that cannot be determined until RTL generation for the function + has been completed. The following virtual register numbers are + defined: + + `VIRTUAL_INCOMING_ARGS_REGNUM' + This points to the first word of the incoming arguments + passed on the stack. Normally these arguments are placed + there by the caller, but the callee may have pushed some + arguments that were previously passed in registers. + + When RTL generation is complete, this virtual register is + replaced by the sum of the register given by + `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'. + + `VIRTUAL_STACK_VARS_REGNUM' + If `FRAME_GROWS_DOWNWARD' is defined, this points to + immediately above the first variable on the stack. + Otherwise, it points to the first variable on the stack. + + `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the + register given by `FRAME_POINTER_REGNUM' and the value + `STARTING_FRAME_OFFSET'. + + `VIRTUAL_STACK_DYNAMIC_REGNUM' + This points to the location of dynamically allocated memory + on the stack immediately after the stack pointer has been + adjusted by the amount of memory desired. + + This virtual register is replaced by the sum of the register + given by `STACK_POINTER_REGNUM' and the value + `STACK_DYNAMIC_OFFSET'. + + `VIRTUAL_OUTGOING_ARGS_REGNUM' + This points to the location in the stack at which outgoing + arguments should be written when the stack is pre-pushed + (arguments pushed using push insns should always use + `STACK_POINTER_REGNUM'). + + This virtual register is replaced by the sum of the register + given by `STACK_POINTER_REGNUM' and the value + `STACK_POINTER_OFFSET'. + +`(subreg:M REG WORDNUM)' + `subreg' expressions are used to refer to a register in a machine + mode other than its natural one, or to refer to one register of a + multi-word `reg' that actually refers to several registers. + + Each pseudo-register has a natural mode. If it is necessary to + operate on it in a different mode--for example, to perform a + fullword move instruction on a pseudo-register that contains a + single byte--the pseudo-register must be enclosed in a `subreg'. + In such a case, WORDNUM is zero. + + Usually M is at least as narrow as the mode of REG, in which case + it is restricting consideration to only the bits of REG that are + in M. + + Sometimes M is wider than the mode of REG. These `subreg' + expressions are often called "paradoxical". They are used in + cases where we want to refer to an object in a wider mode but do + not care what value the additional bits have. The reload pass + ensures that paradoxical references are only made to hard 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 other use of `subreg' is to extract the individual registers of + a multi-register value. Machine modes such as `DImode' and + `TImode' can indicate values longer than a word, values which + usually require two or more consecutive registers. To access one + of the registers, use a `subreg' with mode `SImode' and a WORDNUM + that says which register. + + Storing in a non-paradoxical `subreg' has undefined results for + bits belonging to the same word as the `subreg'. This laxity makes + it easier to generate efficient code for such instructions. To + represent an instruction that preserves all the bits outside of + those in the `subreg', use `strict_low_part' around the `subreg'. + + The compilation parameter `WORDS_BIG_ENDIAN', if set to 1, says + that word number zero is the most significant part; otherwise, it + is the least significant part. + + Between the combiner pass and the reload pass, it is possible to + have a paradoxical `subreg' which contains a `mem' instead of a + `reg' as its first operand. After the reload pass, it is also + possible to have a non-paradoxical `subreg' which contains a + `mem'; this usually occurs when the `mem' is a stack slot which + replaced a pseudo register. + + Note that it is not valid to access a `DFmode' value in `SFmode' + using a `subreg'. On some machines the most significant part of a + `DFmode' value does not have the same format as a single-precision + floating value. + + It is also not valid to access a single word of a multi-word value + in a hard register when less registers can hold the value than + would be expected from its size. For example, some 32-bit + machines have floating-point registers that can hold an entire + `DFmode' value. If register 10 were such a register `(subreg:SI + (reg:DF 10) 1)' would be invalid because there is no way to + convert that reference to a single machine register. The reload + pass prevents `subreg' expressions such as these from being formed. + + The first operand of a `subreg' expression is customarily accessed + with the `SUBREG_REG' macro and the second operand is customarily + accessed with the `SUBREG_WORD' macro. + +`(scratch:M)' + This represents a scratch register that will be required for the + execution of a single instruction and not used subsequently. It is + converted into a `reg' by either the local register allocator or the reload pass. - Three other special macros describe which operands fit which -constraint letters. - -`CONST_OK_FOR_LETTER_P (VALUE, C)' - A C expression that defines the machine-dependent operand - constraint letters that specify particular ranges of integer - values. If C is one of those letters, the expression should - check that VALUE, an integer, is in the appropriate range and - return 1 if so, 0 otherwise. If C is not one of those letters, - the value should be 0 regardless of VALUE. - -`CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)' - A C expression that defines the machine-dependent operand - constraint letters that specify particular ranges of - `const_double' values. - - If C is one of those letters, the expression should check that - VALUE, an RTX of code `const_double', is in the appropriate range - and return 1 if so, 0 otherwise. If C is not one of those - letters, the value should be 0 regardless of VALUE. - - `const_double' is used for all floating-point constants and for - `DImode' fixed-point constants. A given letter can accept either - or both kinds of values. It can use `GET_MODE' to distinguish - between these kinds. - -`EXTRA_CONSTRAINT (VALUE, C)' - A C expression that defines the optional machine-dependent - constraint letters that can be used to segregate specific types - of operands, usually memory references, for the target machine. - Normally this macro will not be defined. If it is required for a - particular target machine, it should return 1 if VALUE - corresponds to the operand type represented by the constraint - letter C. If C is not defined as an extra constraint, the value - returned should be 0 regardless of VALUE. - - For example, on the ROMP, load instructions cannot have their - output in r0 if the memory reference contains a symbolic address. - Constraint letter `Q' is defined as representing a memory - address that does *not* contain a symbolic address. An - alternative is specified with a `Q' constraint on the input and - `r' on the output. The next alternative specifies `m' on the - input and a register class that does not include r0 on the output. - - -File: gcc.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Machine Macros - -Describing Stack Layout and Calling Conventions -=============================================== - -* Menu: - -* Frame Layout:: -* Frame Registers:: -* Elimination:: -* Stack Arguments:: -* Register Arguments:: -* Scalar Return:: -* Aggregate Return:: -* Caller Saves:: -* Function Entry:: -* Profiling:: - - -File: gcc.info, Node: Frame Layout, Next: Frame Registers, Up: Stack and Calling - -Basic Stack Layout ------------------- + `scratch' is usually present inside a `clobber' operation (*note + Side Effects::.). -`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. +`(cc0)' + This refers to the machine's condition code register. It has no + operands and may not have a machine mode. There are two ways to + use it: + + * To stand for a complete set of condition code flags. This is + best on most machines, where each comparison sets the entire + series of flags. + + With this technique, `(cc0)' may be validly used in only two + contexts: as the destination of an assignment (in test and + compare instructions) and in comparison operators comparing + against zero (`const_int' with value zero; that is to say, + `const0_rtx'). + + * To stand for a single flag that is the result of a single + condition. This is useful on machines that have only a + single flag bit, and in which comparison instructions must + specify the condition to test. + + With this technique, `(cc0)' may be validly used in only two + contexts: as the destination of an assignment (in test and + compare instructions) where the source is a comparison + operator, and as the first operand of `if_then_else' (in a + conditional branch). + + There is only one expression object of code `cc0'; it is the value + of the variable `cc0_rtx'. Any attempt to create an expression of + code `cc0' will return `cc0_rtx'. + + Instructions can set the condition code implicitly. On many + machines, nearly all instructions set the condition code based on + the value that they compute or store. It is not necessary to + record these actions explicitly in the RTL because the machine + description includes a prescription for recognizing the + instructions that do so (by means of the macro + `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions + whose sole purpose is to set the condition code, and instructions + that use the condition code, need mention `(cc0)'. + + On some machines, the condition code register is given a register + number and a `reg' is used instead of `(cc0)'. This is usually the + preferable approach if only a small subset of instructions modify + the condition code. Other machines store condition codes in + general registers; in such cases a pseudo register should be used. + + Some machines, such as the Sparc and RS/6000, have two sets of + arithmetic instructions, one that sets and one that does not set + the condition code. This is best handled by normally generating + the instruction that does not set the condition code, and making a + pattern that both performs the arithmetic and sets the condition + code register (which would not be `(cc0)' in this case). For + examples, search for `addcc' and `andcc' in `sparc.md'. + +`(pc)' + This represents the machine's program counter. It has no operands + and may not have a machine mode. `(pc)' may be validly used only + in certain specific contexts in jump instructions. + + There is only one expression object of code `pc'; it is the value + of the variable `pc_rtx'. Any attempt to create an expression of + code `pc' will return `pc_rtx'. + + All instructions that do not jump alter the program counter + implicitly by incrementing it, but there is no need to mention + this in the RTL. + +`(mem:M ADDR)' + This RTX represents a reference to main memory at an address + represented by the expression ADDR. M specifies how large a unit + of memory is accessed. + + +File: gcc.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL + +RTL Expressions for Arithmetic +============================== + + Unless otherwise specified, all the operands of arithmetic +expressions must be valid for mode M. An operand is valid for mode M +if it has mode M, or if it is a `const_int' or `const_double' and M is +a mode of class `MODE_INT'. + + For commutative binary operations, constants should be placed in the +second operand. + +`(plus:M X Y)' + Represents the sum of the values represented by X and Y carried + out in machine mode M. + +`(lo_sum:M X Y)' + Like `plus', except that it represents that sum of X and the + low-order bits of Y. The number of low order bits is + machine-dependent but is normally the number of bits in a `Pmode' + item minus the number of bits set by the `high' code (*note + Constants::.). + + M should be `Pmode'. + +`(minus:M X Y)' + Like `plus' but represents subtraction. + +`(compare:M X Y)' + Represents the result of subtracting Y from X for purposes of + comparison. The result is computed without overflow, as if with + infinite precision. + + Of course, machines can't really subtract with infinite precision. + However, they can pretend to do so when only the sign of the + result will be used, which is the case when the result is stored + in the condition code. And that is the only way this kind of + expression may validly be used: as a value to be stored in the + condition codes. + + The mode M is not related to the modes of X and Y, but instead is + the mode of the condition code value. If `(cc0)' is used, it is + `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often + `CCmode'. *Note Condition Code::. + + Normally, X and Y must have the same mode. Otherwise, `compare' + is valid only if the mode of X is in class `MODE_INT' and Y is a + `const_int' or `const_double' with mode `VOIDmode'. The mode of X + determines what mode the comparison is to be done in; thus it must + not be `VOIDmode'. + + If one of the operands is a constant, it should be placed in the + second operand and the comparison code adjusted as appropriate. + + A `compare' specifying two `VOIDmode' constants is not valid since + there is no way to know in what mode the comparison is to be + performed; the comparison must either be folded during the + compilation or the first operand must be loaded into a register + while its mode is still known. + +`(neg:M X)' + Represents the negation (subtraction from zero) of the value + represented by X, carried out in mode M. + +`(mult:M X Y)' + Represents the signed product of the values represented by X and Y + carried out in machine mode M. + + Some machines support a multiplication that generates a product + wider than the operands. Write the pattern for this as + + (mult:M (sign_extend:M X) (sign_extend:M Y)) + + where M is wider than the modes of X and Y, which need not be the + same. + + Write patterns for unsigned widening multiplication similarly using + `zero_extend'. + +`(div:M X Y)' + Represents the quotient in signed division of X by Y, carried out + in machine mode M. If M is a floating point mode, it represents + the exact quotient; otherwise, the integerized quotient. + + Some machines have division instructions in which the operands and + quotient widths are not all the same; you should represent such + instructions using `truncate' and `sign_extend' as in, + + (truncate:M1 (div:M2 X (sign_extend:M2 Y))) + +`(udiv:M X Y)' + Like `div' but represents unsigned division. + +`(mod:M X Y)' +`(umod:M X Y)' + Like `div' and `udiv' but represent the remainder instead of the + quotient. + +`(smin:M X Y)' +`(smax:M X Y)' + Represents the smaller (for `smin') or larger (for `smax') of X + and Y, interpreted as signed integers in mode M. + +`(umin:M X Y)' +`(umax:M X Y)' + Like `smin' and `smax', but the values are interpreted as unsigned + integers. + +`(not:M X)' + Represents the bitwise complement of the value represented by X, + carried out in mode M, which must be a fixed-point machine mode. + +`(and:M X Y)' + Represents the bitwise logical-and of the values represented by X + and Y, carried out in machine mode M, which must be a fixed-point + machine mode. + +`(ior:M X Y)' + Represents the bitwise inclusive-or of the values represented by X + and Y, carried out in machine mode M, which must be a fixed-point + mode. + +`(xor:M X Y)' + Represents the bitwise exclusive-or of the values represented by X + and Y, carried out in machine mode M, which must be a fixed-point + mode. + +`(ashift:M X C)' + Represents the result of arithmetically shifting X left by C + places. X have mode M, a fixed-point machine mode. C be a + fixed-point mode or be a constant with mode `VOIDmode'; which mode + is determined by the mode called for in the machine description + entry for the left-shift instruction. For example, on the Vax, + the mode of C is `QImode' regardless of M. + +`(lshift:M X C)' + Like `ashift' but for logical left shift. `ashift' and `lshift' + are identical operations; we customarily use `ashift' for both. + +`(lshiftrt:M X C)' +`(ashiftrt:M X C)' + Like `lshift' and `ashift' but for right shift. Unlike the case + for left shift, these two operations are distinct. + +`(rotate:M X C)' +`(rotatert:M X C)' + Similar but represent left and right rotate. If C is a constant, + use `rotate'. + +`(abs:M X)' + Represents the absolute value of X, computed in mode M. + +`(sqrt:M X)' + Represents the square root of X, computed in mode M. Most often M + will be a floating point mode. + +`(ffs:M X)' + Represents one plus the index of the least significant 1-bit in X, + represented as an integer of mode M. (The value is zero if X is + zero.) The mode of X need not be M; depending on the target + machine, various mode combinations may be valid. + + +File: gcc.info, Node: Comparisons, Next: Bit Fields, Prev: Arithmetic, Up: RTL + +Comparison Operations +===================== + + Comparison operators test a relation on two operands and are +considered to represent a machine-dependent nonzero value described by, +but not necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::.) if the +relation holds, or zero if it does not. The mode of the comparison +operation is independent of the mode of the data being compared. If +the comparison operation is being tested (e.g., the first operand of an +`if_then_else'), the mode must be `VOIDmode'. If the comparison +operation is producing data to be stored in some variable, the mode +must be in class `MODE_INT'. All comparison operations producing data +must use the same mode, which is machine-specific. + + There are two ways that comparison operations may be used. The +comparison operators may be used to compare the condition codes `(cc0)' +against zero, as in `(eq (cc0) (const_int 0))'. Such a construct +actually refers to the result of the preceding instruction in which the +condition codes were set. The instructing setting the condition code +must be adjacent to the instruction using the condition code; only +`note' insns may separate them. + + Alternatively, a comparison operation may directly compare two data +objects. The mode of the comparison is determined by the operands; they +must both be valid for a common machine mode. A comparison with both +operands constant would be invalid as the machine mode could not be +deduced from it, but such a comparison should never exist in RTL due to +constant folding. + + In the example above, if `(cc0)' were last set to `(compare X Y)', +the comparison operation is identical to `(eq X Y)'. Usually only one +style of comparisons is supported on a particular machine, but the +combine pass will try to merge the operations to produce the `eq' shown +in case it exists in the context of the particular insn involved. + + Inequality comparisons come in two flavors, signed and unsigned. +Thus, there are distinct expression codes `gt' and `gtu' for signed and +unsigned greater-than. These can produce different results for the same +pair of integer values: for example, 1 is signed greater-than -1 but not +unsigned greater-than, because -1 when regarded as unsigned is actually +`0xffffffff' which is greater than 1. + + The signed comparisons are also used for floating point values. +Floating point comparisons are distinguished by the machine modes of +the operands. + +`(eq:M X Y)' + 1 if the values represented by X and Y are equal, otherwise 0. + +`(ne:M X Y)' + 1 if the values represented by X and Y are not equal, otherwise 0. + +`(gt:M X Y)' + 1 if the X is greater than Y. If they are fixed-point, the + comparison is done in a signed sense. + +`(gtu:M X Y)' + Like `gt' but does unsigned comparison, on fixed-point numbers + only. + +`(lt:M X Y)' +`(ltu:M X Y)' + Like `gt' and `gtu' but test for "less than". + +`(ge:M X Y)' +`(geu:M X Y)' + Like `gt' and `gtu' but test for "greater than or equal". + +`(le:M X Y)' +`(leu:M X Y)' + Like `gt' and `gtu' but test for "less than or equal". + +`(if_then_else COND THEN ELSE)' + This is not a comparison operation but is listed here because it is + always used in conjunction with a comparison operation. To be + precise, COND is a comparison expression. This expression + represents a choice, according to COND, between the value + represented by THEN and the one represented by ELSE. + + On most machines, `if_then_else' expressions are valid only to + express conditional jumps. + +`(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' + Similar to `if_then_else', but more general. Each of TEST1, + TEST2, ... is performed in turn. The result of this expression is + the VALUE corresponding to the first non-zero test, or DEFAULT if + none of the tests are non-zero expressions. + + This is currently not valid for instruction patterns and is + supported only for insn attributes. *Note Insn Attributes::. + + +File: gcc.info, Node: Bit Fields, Next: Conversions, Prev: Comparisons, Up: RTL + +Bit Fields +========== + + Special expression codes exist to represent bitfield instructions. +These types of expressions are lvalues in RTL; they may appear on the +left side of an assignment, indicating insertion of a value into the +specified bit field. + +`(sign_extract:M LOC SIZE POS)' + This represents a reference to a sign-extended bit field contained + or starting in LOC (a memory or register reference). The bit field + is SIZE bits wide and starts at bit POS. The compilation option + `BITS_BIG_ENDIAN' says which end of the memory unit POS counts + from. + + If LOC is in memory, its mode must be a single-byte integer mode. + If LOC is in a register, the mode to use is specified by the + operand of the `insv' or `extv' pattern (*note Standard Names::.) + and is usually a full-word integer mode. + + The mode of POS is machine-specific and is also specified in the + `insv' or `extv' pattern. + + The mode M is the same as the mode that would be used for LOC if + it were a register. + +`(zero_extract:M LOC SIZE POS)' + Like `sign_extract' but refers to an unsigned or zero-extended bit + field. The same sequence of bits are extracted, but they are + filled to an entire word with zeros instead of by sign-extension. + + +File: gcc.info, Node: Conversions, Next: RTL Declarations, Prev: Bit Fields, Up: RTL + +Conversions +=========== + + All conversions between machine modes must be represented by +explicit conversion operations. For example, an expression which is +the sum of a byte and a full word cannot be written as `(plus:SI +(reg:QI 34) (reg:SI 80))' because the `plus' operation requires two +operands of the same machine mode. Therefore, the byte-sized operand +is enclosed in a conversion operation, as in + + (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) + + The conversion operation is not a mere placeholder, because there +may be more than one way of converting from a given starting mode to +the desired final mode. The conversion operation code says how to do +it. + + For all conversion operations, X must not be `VOIDmode' because the +mode in which to do the conversion would not be known. The conversion +must either be done at compile-time or X must be placed into a register. + +`(sign_extend:M X)' + Represents the result of sign-extending the value X to machine + mode M. M must be a fixed-point mode and X a fixed-point value of + a mode narrower than M. + +`(zero_extend:M X)' + Represents the result of zero-extending the value X to machine + mode M. M must be a fixed-point mode and X a fixed-point value of + a mode narrower than M. + +`(float_extend:M X)' + Represents the result of extending the value X to machine mode M. + m must be a floating point mode and X a floating point value of a + mode narrower than M. + +`(truncate:M X)' + Represents the result of truncating the value X to machine mode M. + M must be a fixed-point mode and X a fixed-point value of a mode + wider than M. + +`(float_truncate:M X)' + Represents the result of truncating the value X to machine mode M. + M must be a floating point mode and X a floating point value of a + mode wider than M. + +`(float:M X)' + Represents the result of converting fixed point value X, regarded + as signed, to floating point mode M. + +`(unsigned_float:M X)' + Represents the result of converting fixed point value X, regarded + as unsigned, to floating point mode M. + +`(fix:M X)' + When M is a fixed point mode, represents the result of converting + floating point value X to mode M, regarded as signed. How + rounding is done is not specified, so this operation may be used + validly in compiling C code only for integer-valued operands. + +`(unsigned_fix:M X)' + Represents the result of converting floating point value X to + fixed point mode M, regarded as unsigned. How rounding is done is + not specified. + +`(fix:M X)' + When M is a floating point mode, represents the result of + converting floating point value X (valid for mode M) to an + integer, still represented in floating point mode M, by rounding + towards zero. + + +File: gcc.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL + +Declarations +============ + + Declaration expression codes do not represent arithmetic operations +but rather state assertions about their operands. + +`(strict_low_part (subreg:M (reg:N R) 0))' + This expression code is used in only one context: as the + destination operand of a `set' expression. In addition, the + operand of this expression must be a non-paradoxical `subreg' + expression. + + The presence of `strict_low_part' says that the part of the + register which is meaningful in mode N, but is not part of mode M, + is not to be altered. Normally, an assignment to such a subreg is + allowed to have undefined effects on the rest of the register when + M is less than a word. + + +File: gcc.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL + +Side Effect Expressions +======================= + + 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: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL + +Embedded Side-Effects on Addresses +================================== + + Four special side-effect expression codes appear as memory addresses. + +`(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: Assembler, Next: Insns, Prev: Incdec, Up: RTL + +Assembler Instructions as Expressions +===================================== + + 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. - \ No newline at end of file