--- gcc/gcc.info-11 2018/04/24 17:51:24 1.1.1.1 +++ gcc/gcc.info-11 2018/04/24 18:08:10 1.1.1.5 @@ -1,1091 +1,960 @@ -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: Insn Splitting, Next: Insn Attributes, Prev: Expander Definitions, Up: Machine Desc - -Splitting Instructions into Multiple Instructions -================================================= - - On machines that have instructions requiring delay slots (*note -Delay Slots::.) or that have instructions whose output is not -available for multiple cycles (*note Function Units::.), the compiler -phases that optimize these cases need to be able to move insns into -one-cycle delay slots. However, some insns may generate more than one -machine instruction. These insns would be unable to be placed into a -delay slot. - - It is often possible to write the single insn as a list of -individual insns, each corresponding to one machine instruction. The -disadvantage of doing so is that it will cause the compilation to be -slower and require more space. If the resulting insns are too -complex, it may also suppress some optimizations. - - The `define_split' definition tells the compiler how to split a -complex insn into several simpler insns. This spilling will be -performed if there is a reason to believe that it might improve -instruction or delay slot scheduling. The definition looks like this: - - (define_split - [INSN-PATTERN] - "CONDITION" - [NEW-INSN-PATTERN-1 - NEW-INSN-PATTERN-2 - ...] - "PREPARATION STATEMENTS") - - INSN-PATTERN is a pattern that needs to be split and CONDITION is -the final condition to be tested, as in a `define_insn'. Any insn -matched by a `define_split' must also be matched by a `define_insn' in -case it does not need to be split. - - When an insn matching INSN-PATTERN and satisfying CONDITION is -found, it is replaced in the insn list with the insns given by -NEW-INSN-PATTERN-1, NEW-INSN-PATTERN-2, etc. - - The PREPARATION STATEMENTS are similar to those specified for -`define_expand' (*note Expander Definitions::.) and are executed -before the new RTL is generated to prepare for the generated code or -emit some insns whose pattern is not fixed. - - As a simple case, consider the following example from the AMD 29000 -machine description, which splits a `sign_extend' from `HImode' to -`SImode' into a pair of shift insns: - - (define_split - [(set (match_operand:SI 0 "gen_reg_operand" "") - (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] - "" - [(set (match_dup 0) - (ashift:SI (match_dup 1) - (const_int 16))) - (set (match_dup 0) - (ashiftrt:SI (match_dup 0) - (const_int 16)))] - " - { operands[1] = gen_lowpart (SImode, operands[1]); }") - - -File: gcc.info, Node: Insn Attributes, Prev: Insn Splitting, Up: Machine Desc - -Instruction Attributes -====================== - - In addition to describing the instruction supported by the target -machine, the `md' file also defines a group of "attributes" and a set -of values for each. Every generated insn is assigned a value for each -attribute. One possible attribute would be the effect that the insn -has on the machine's condition code. This attribute can then be used -by `NOTICE_UPDATE_CC' to track the condition codes. - -* Menu: - -* Defining Attributes:: Specifying attributes and their values. -* Expressions:: Valid expressions for attribute values. -* Tagging Insns:: Assigning attribute values to insns. -* Attr Example:: An example of assigning attributes. -* Insn Lengths:: Computing the length of insns. -* Delay Slots:: Defining delay slots required for a machine. -* Function Units:: Specifying information for insn scheduling. +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: Machine Modes, Next: Constants, Prev: Flags, Up: RTL + +Machine Modes +============= + + A machine mode describes a size of data object and the +representation used for it. In the C code, machine modes are +represented by an enumeration type, `enum machine_mode', defined in +`machmode.def'. Each RTL expression has room for a machine mode and so +do certain kinds of tree expressions (declarations and types, to be +precise). + + In debugging dumps and machine descriptions, the machine mode of an +RTL expression is written after the expression code with a colon to +separate them. The letters `mode' which appear at the end of each +machine mode name are omitted. For example, `(reg:SI 38)' is a `reg' +expression with machine mode `SImode'. If the mode is `VOIDmode', it +is not written at all. + + Here is a table of machine modes. The term "byte" below refers to an +object of `BITS_PER_UNIT' bits (*note Storage Layout::.). + +`QImode' + "Quarter-Integer" mode represents a single byte treated as an + integer. + +`HImode' + "Half-Integer" mode represents a two-byte integer. + +`PSImode' + "Partial Single Integer" mode represents an integer which occupies + four bytes but which doesn't really use all four. On some + machines, this is the right mode to use for pointers. + +`SImode' + "Single Integer" mode represents a four-byte integer. + +`PDImode' + "Partial Double Integer" mode represents an integer which occupies + eight bytes but which doesn't really use all eight. On some + machines, this is the right mode to use for certain pointers. + +`DImode' + "Double Integer" mode represents an eight-byte integer. + +`TImode' + "Tetra Integer" (?) mode represents a sixteen-byte integer. + +`SFmode' + "Single Floating" mode represents a single-precision (four byte) + floating point number. + +`DFmode' + "Double Floating" mode represents a double-precision (eight byte) + floating point number. + +`XFmode' + "Extended Floating" mode represents a triple-precision (twelve + byte) floating point number. This mode is used for IEEE extended + floating point. + +`TFmode' + "Tetra Floating" mode represents a quadruple-precision (sixteen + byte) floating point number. + +`CCmode' + "Condition Code" mode represents the value of a condition code, + which is a machine-specific set of bits used to represent the + result of a comparison operation. Other machine-specific modes + may also be used for the condition code. These modes are not used + on machines that use `cc0' (see *note Condition Code::.). + +`BLKmode' + "Block" mode represents values that are aggregates to which none of + the other modes apply. In RTL, only memory references can have + this mode, and only if they appear in string-move or vector + instructions. On machines which have no such instructions, + `BLKmode' will not appear in RTL. + +`VOIDmode' + Void mode means the absence of a mode or an unspecified mode. For + example, RTL expressions of code `const_int' have mode `VOIDmode' + because they can be taken to have whatever mode the context + requires. In debugging dumps of RTL, `VOIDmode' is expressed by + the absence of any mode. + +`SCmode, DCmode, XCmode, TCmode' + These modes stand for a complex number represented as a pair of + floating point values. The values are in `SFmode', `DFmode', + `XFmode', and `TFmode', respectively. Since C does not support + complex numbers, these machine modes are only partially + implemented. + + The machine description defines `Pmode' as a C macro which expands +into the machine mode used for addresses. Normally this is the mode +whose size is `BITS_PER_WORD', `SImode' on 32-bit machines. + + The only modes which a machine description must support are +`QImode', and the modes corresponding to `BITS_PER_WORD', +`FLOAT_TYPE_SIZE' and `DOUBLE_TYPE_SIZE'. The compiler will attempt to +use `DImode' for 8-byte structures and unions, but this can be +prevented by overriding the definition of `MAX_FIXED_MODE_SIZE'. +Alternatively, you can have the compiler use `TImode' for 16-byte +structures and unions. Likewise, you can arrange for the C type `short +int' to avoid using `HImode'. + + Very few explicit references to machine modes remain in the compiler +and these few references will soon be removed. Instead, the machine +modes are divided into mode classes. These are represented by the +enumeration type `enum mode_class' defined in `machmode.h'. The +possible mode classes are: + +`MODE_INT' + Integer modes. By default these are `QImode', `HImode', `SImode', + `DImode', and `TImode'. + +`MODE_PARTIAL_INT' + The "partial integer" modes, `PSImode' and `PDImode'. + +`MODE_FLOAT' + floating point modes. By default these are `SFmode', `DFmode', + `XFmode' and `TFmode'. + +`MODE_COMPLEX_INT' + Complex integer modes. (These are not currently implemented). + +`MODE_COMPLEX_FLOAT' + Complex floating point modes. By default these are `SCmode', + `DCmode', `XCmode', and `TCmode'. + +`MODE_FUNCTION' + Algol or Pascal function variables including a static chain. + (These are not currently implemented). + +`MODE_CC' + Modes representing condition code values. These are `CCmode' plus + any modes listed in the `EXTRA_CC_MODES' macro. *Note Jump + Patterns::, also see *Note Condition Code::. + +`MODE_RANDOM' + This is a catchall mode class for modes which don't fit into the + above classes. Currently `VOIDmode' and `BLKmode' are in + `MODE_RANDOM'. + + Here are some C macros that relate to machine modes: + +`GET_MODE (X)' + Returns the machine mode of the RTX X. + +`PUT_MODE (X, NEWMODE)' + Alters the machine mode of the RTX X to be NEWMODE. + +`NUM_MACHINE_MODES' + Stands for the number of machine modes available on the target + machine. This is one greater than the largest numeric value of any + machine mode. + +`GET_MODE_NAME (M)' + Returns the name of mode M as a string. + +`GET_MODE_CLASS (M)' + Returns the mode class of mode M. + +`GET_MODE_WIDER_MODE (M)' + Returns the next wider natural mode. For example, the expression + `GET_MODE_WIDER_MODE (QImode)' returns `HImode'. + +`GET_MODE_SIZE (M)' + Returns the size in bytes of a datum of mode M. + +`GET_MODE_BITSIZE (M)' + Returns the size in bits of a datum of mode M. + +`GET_MODE_MASK (M)' + Returns a bitmask containing 1 for all bits in a word that fit + within mode M. This macro can only be used for modes whose + bitsize is less than or equal to `HOST_BITS_PER_INT'. + +`GET_MODE_ALIGNMENT (M))' + Return the required alignment, in bits, for an object of mode M. + +`GET_MODE_UNIT_SIZE (M)' + Returns the size in bytes of the subunits of a datum of mode M. + This is the same as `GET_MODE_SIZE' except in the case of complex + modes. For them, the unit size is the size of the real or + imaginary part. + +`GET_MODE_NUNITS (M)' + Returns the number of units contained in a mode, i.e., + `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'. + +`GET_CLASS_NARROWEST_MODE (C)' + Returns the narrowest mode in mode class C. + + The global variables `byte_mode' and `word_mode' contain modes whose +classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or +`BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode' +and `SImode', respectively.  -File: gcc.info, Node: Defining Attributes, Next: Expressions, Prev: Insn Attributes, Up: Insn Attributes - -Defining Attributes and their Values ------------------------------------- - - The `define_attr' expression is used to define each attribute -required by the target machine. It looks like: - - (define_attr NAME LIST-OF-VALUES DEFAULT) - - NAME is a string specifying the name of the attribute being defined. - - LIST-OF-VALUES is either a string that specifies a comma-separated -list of values that can be assigned to the attribute, or a null string -to indicate that the attribute takes numeric values. - - DEFAULT is an attribute expression that gives the value of this -attribute for insns that match patterns whose definition does not -include an explicit value for this attribute. *Note Attr Example::, -for more information on the handling of defaults. - - For each defined attribute, a number of definitions are written to -the `insn-attr.h' file. For cases where an explicit set of values is -specified for an attribute, the following are defined: +File: gcc.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL - * A `#define' is written for the symbol `HAVE_ATTR_NAME'. +Constant Expression Types +========================= - * An enumeral class is defined for `attr_NAME' with elements of the - form `UPPER-NAME_UPPER-VALUE' where the attribute name and value - are first converted to upper case. - - * A function `get_attr_NAME' is defined that is passed an insn and - returns the attribute value for that insn. - - For example, if the following is present in the `md' file: - - (define_attr "type" "branch,fp,load,store,arith" ...) - -the following lines will be written to the file `insn-attr.h'. - - #define HAVE_ATTR_type - enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, - TYPE_STORE, TYPE_ARITH}; - extern enum attr_type get_attr_type (); - - If the attribute takes numeric values, no `enum' type will be -defined and the function to obtain the attribute's value will return -`int'. - - -File: gcc.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes - -Attribute Expressions ---------------------- - - RTL expressions used to define attributes use the codes described -above plus a few specific to attribute definitions, to be discussed -below. Attribute value expressions must have one of the following -forms: + The simplest RTL expressions are those that represent constant +values. `(const_int I)' - The integer I specifies the value of a numeric attribute. I must - be non-negative. - - The value of a numeric attribute can be specified either with a - `const_int' or as an integer represented as a string in - `const_string', `eq_attr' (see below), and `set_attr' (*note - Tagging Insns::.) expressions. - -`(const_string VALUE)' - The string VALUE specifies a constant attribute value. If VALUE - is specified as `"*"', it means that the default value of the - attribute is to be used for the insn containing this expression. - `"*"' obviously cannot be used in the DEFAULT expression of a - `define_attr'. - - If the attribute whose value is being specified is numeric, VALUE - must be a string containing a non-negative integer (normally - `const_int' would be used in this case). Otherwise, it must - contain one of the valid values for the attribute. - -`(if_then_else TEST TRUE-VALUE FALSE-VALUE)' - TEST specifies an attribute test, whose format is defined below. - The value of this expression is TRUE-VALUE if TEST is true, - otherwise it is FALSE-VALUE. - -`(cond [TEST1 VALUE1 ...] DEFAULT)' - The first operand of this expression is a vector containing an - even number of expressions and consisting of pairs of TEST and - VALUE expressions. The value of the `cond' expression is that of - the VALUE corresponding to the first true TEST expression. If - none of the TEST expressions are true, the value of the `cond' - expression is that of the DEFAULT expression. - - TEST expressions can have one of the following forms: - -`(const_int I)' - This test is true if I is non-zero and false otherwise. - -`(not TEST)' -`(ior TEST1 TEST2)' -`(and TEST1 TEST2)' - These tests are true if the indicated logical function is true. - -`(match_operand:M N PRED CONSTRAINTS)' - This test is true if operand N of the insn whose attribute value - is being determined has mode M (this part of the test is ignored - if M is `VOIDmode') and the function specified by the string PRED - returns a non-zero value when passed operand N and mode M (this - part of the test is ignored if PRED is the null string). - - The CONSTRAINTS operand is ignored and should be the null string. - -`(le ARITH1 ARITH2)' -`(leu ARITH1 ARITH2)' -`(lt ARITH1 ARITH2)' -`(ltu ARITH1 ARITH2)' -`(gt ARITH1 ARITH2)' -`(gtu ARITH1 ARITH2)' -`(ge ARITH1 ARITH2)' -`(geu ARITH1 ARITH2)' -`(ne ARITH1 ARITH2)' -`(eq ARITH1 ARITH2)' - These tests are true if the indicated comparison of the two - arithmetic expressions is true. Arithmetic expressions are - formed with `plus', `minus', `mult', `div', `mod', `abs', `neg', - `and', `ior', `xor', `not', `lshift', `ashift', `lshiftrt', and - `ashiftrt' expressions. - - `const_int' and `symbol_ref' are always valid terms (*note Insn - Lengths::.,for additional forms). `symbol_ref' is a string - denoting a C expression that yields an `int' when evaluated by the - `get_attr_...' routine. It should normally be a global variable. - -`(eq_attr NAME VALUE)' - NAME is a string specifying the name of an attribute. - - VALUE is a string that is either a valid value for attribute - NAME, a comma-separated list of values, or `!' followed by a - value or list. If VALUE does not begin with a `!', this test is - true if the value of the NAME attribute of the current insn is in - the list specified by VALUE. If VALUE begins with a `!', this - test is true if the attribute's value is *not* in the specified - list. - - For example, - - (eq_attr "type" "load,store") - - is equivalent to - - (ior (eq_attr "type" "load") (eq_attr "type" "store")) - - If NAME specifies an attribute of `alternative', it refers to the - value of the compiler variable `which_alternative' (*note Output - Statement::.) and the values must be small integers. For example, - - (eq_attr "alternative" "2,3") - - is equivalent to - - (ior (eq (symbol_ref "which_alternative") (const_int 2)) - (eq (symbol_ref "which_alternative") (const_int 3))) - - Note that, for most attributes, an `eq_attr' test is simplified - in cases where the value of the attribute being tested is known - for all insns matching a particular pattern. This is by far the - most common case. - - -File: gcc.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes - -Assigning Attribute Values to Insns ------------------------------------ - - The value assigned to an attribute of an insn is primarily -determined by which pattern is matched by that insn (or which -`define_peephole' generated it). Every `define_insn' and -`define_peephole' can have an optional last argument to specify the -values of attributes for matching insns. The value of any attribute -not specified in a particular insn is set to the default value for -that attribute, as specified in its `define_attr'. Extensive use of -default values for attributes permits the specification of the values -for only one or two attributes in the definition of most insn -patterns, as seen in the example in the next section. - - The optional last argument of `define_insn' and `define_peephole' -is a vector of expressions, each of which defines the value for a -single attribute. The most general way of assigning an attribute's -value is to use a `set' expression whose first operand is an `attr' -expression giving the name of the attribute being set. The second -operand of the `set' is an attribute expression (*note Expressions::.) -giving the value of the attribute. - - When the attribute value depends on the `alternative' attribute -(i.e., which is the applicable alternative in the constraint of the -insn), the `set_attr_alternative' expression can can be used. It -allows the specification of a vector of attribute expressions, one for -each alternative. - - When the generality of arbitrary attribute expressions is not -required, the simpler `set_attr' expression can be used, which allows -specifying a string giving either a single attribute value or a list -of attribute values, one for each alternative. - - The form of each of the above specifications is shown below. In -each case, NAME is a string specifying the attribute to be set. - -`(set_attr NAME VALUE-STRING)' - VALUE-STRING is either a string giving the desired attribute - value, or a string containing a comma-separated list giving the - values for succeeding alternatives. The number of elements must - match the number of alternatives in the constraint of the insn - pattern. - - Note that it may be useful to specify `*' for some alternative, in - which case the attribute will assume its default value for insns - matching that alternative. - -`(set_attr_alternative NAME [VALUE1 VALUE2 ...])' - Depending on the alternative of the insn, the value will be one - of the specified values. This is a shorthand for using a `cond' - with tests on the `alternative' attribute. - -`(set (attr NAME) VALUE)' - The first operand of this `set' must be the special RTL expression - `attr', whose sole operand is a string giving the name of the - attribute being set. VALUE is the value of the attribute. - - The following shows three different ways of representing the same -attribute value specification: - - (set_attr "type" "load,store,arith") - - (set_attr_alternative "type" - [(const_string "load") (const_string "store") - (const_string "arith")]) - - (set (attr "type") - (cond [(eq_attr "alternative" "1") (const_string "load") - (eq_attr "alternative" "2") (const_string "store")] - (const_string "arith"))) - - The `define_asm_attributes' expression provides a mechanism to -specify the attributes assigned to insns produced from an `asm' -statement. It has the form: - - (define_asm_attributes [ATTR-SETS]) - -where ATTR-SETS is specified the same as for `define_insn' and -`define_peephole' expressions. - - These values will typically be the "worst case" attribute values. -For example, they might indicate that the condition code will be -clobbered. - - A specification for a `length' attribute is handled specially. To -compute the length of an `asm' insn, the length specified in the -`define_asm_attributes' expression is multiplied by the number of -machine instructions specified in the `asm' statement, determined by -counting the number of semicolons and newlines in the string. -Therefore, the value of the `length' attribute specified in a -`define_asm_attributes' should be the maximum possible length of a -single machine instruction. - - -File: gcc.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes - -Example of Attribute Specifications ------------------------------------ - - The judicious use of defaulting is important in the efficient use of -insn attributes. Typically, insns are divided into "types" and an -attribute, customarily called `type', is used to represent this value. - This attribute is normally used only to define the default value for -other attributes. An example will clarify this usage. - - Assume we have a RISC machine with a condition code and in which -only full-word operations are performed in registers. Let us assume -that we can divide all insns into loads, stores, (integer) arithmetic -operations, floating point operations, and branches. - - Here we will concern ourselves with determining the effect of an -insn on the condition code and will limit ourselves to the following -possible effects: The condition code can be set unpredictably -(clobbered), not be changed, be set to agree with the results of the -operation, or only changed if the item previously set into the -condition code has been modified. - - Here is part of a sample `md' file for such a machine: - - (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) - - (define_attr "cc" "clobber,unchanged,set,change0" - (cond [(eq_attr "type" "load") - (const_string "change0") - (eq_attr "type" "store,branch") - (const_string "unchanged") - (eq_attr "type" "arith") - (if_then_else (match_operand:SI 0 "" "") - (const_string "set") - (const_string "clobber"))] - (const_string "clobber"))) - - (define_insn "" - [(set (match_operand:SI 0 "general_operand" "=r,r,m") - (match_operand:SI 1 "general_operand" "r,m,r"))] - "" - "@ - move %0,%1 - load %0,%1 - store %0,%1" - [(set_attr "type" "arith,load,store")]) - - Note that we assume in the above example that arithmetic operations -performed on quantities smaller than a machine word clobber the -condition code since they will set the condition code to a value -corresponding to the full-word result. - - -File: gcc.info, Node: Insn Lengths, Next: Delay Slots, Prev: Attr Example, Up: Insn Attributes - -Computing the Length of an Insn -------------------------------- - - For many machines, multiple types of branch instructions are -provided, each for different length branch displacements. In most -cases, the assembler will choose the correct instruction to use. -However, when the assembler cannot do so, GCC can when a special -attribute, the `length' attribute, is defined. This attribute must be -defined to have numeric values by specifying a null string in its -`define_attr'. - - In the case of the `length' attribute, two additional forms of -arithmetic terms are allowed in test expressions: - -`(match_dup N)' - This refers to the address of operand N of the current insn, which - must be a `label_ref'. + This type of expression represents the integer value I. I is + customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)', + which is equivalent to `XWINT (EXP, 0)'. + + There is only one expression object for the integer value zero; it + is the value of the variable `const0_rtx'. Likewise, the only + expression for integer value one is found in `const1_rtx', the only + expression for integer value two is found in `const2_rtx', and the + only expression for integer value negative one is found in + `constm1_rtx'. Any attempt to create an expression of code + `const_int' and value zero, one, two or negative one will return + `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as + appropriate. + + Similarly, there is only one object for the integer whose value is + `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If + `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will + point to the same object. If `STORE_FLAG_VALUE' is -1, + `const_true_rtx' and `constm1_rtx' will point to the same object. + +`(const_double:M ADDR I0 I1 ...)' + Represents either a floating-point constant of mode M or an + integer constant too large to fit into `HOST_BITS_PER_WIDE_INT' + bits but small enough to fit within twice that number of bits (GNU + CC does not provide a mechanism to represent even larger + constants). In the latter case, M will be `VOIDmode'. + + ADDR is used to contain the `mem' expression that corresponds to + the location in memory that at which the constant can be found. If + it has not been allocated a memory location, but is on the chain + of all `const_double' expressions in this compilation (maintained + using an undisplayed field), ADDR contains `const0_rtx'. If it is + not on the chain, ADDR contains `cc0_rtx'. ADDR is customarily + accessed with the macro `CONST_DOUBLE_MEM' and the chain field via + `CONST_DOUBLE_CHAIN'. + + If M is `VOIDmode', the bits of the value are stored in I0 and I1. + I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and + I1 with `CONST_DOUBLE_HIGH'. + + If the constant is floating point (regardless of its precision), + then the number of integers used to store the value depends on the + size of `REAL_VALUE_TYPE' (*note Cross-compilation::.). The + integers represent a floating point number, but not precisely in + the target machine's or host machine's floating point format. To + convert them to the precise bit pattern used by the target + machine, use the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends + (*note Data Output::.). + + The macro `CONST0_RTX (MODE)' refers to an expression with value 0 + in mode MODE. If mode MODE is of mode class `MODE_INT', it + returns `const0_rtx'. Otherwise, it returns a `CONST_DOUBLE' + expression in mode MODE. Similarly, the macro `CONST1_RTX (MODE)' + refers to an expression with value 1 in mode MODE and similarly + for `CONST2_RTX'. + +`(const_string STR)' + Represents a constant string with value STR. Currently this is + used only for insn attributes (*note Insn Attributes::.) since + constant strings in C are placed in memory. + +`(symbol_ref:MODE SYMBOL)' + Represents the value of an assembler label for data. SYMBOL is a + string that describes the name of the assembler label. If it + starts with a `*', the label is the rest of SYMBOL not including + the `*'. Otherwise, the label is SYMBOL, usually prefixed with + `_'. + + The `symbol_ref' contains a mode, which is usually `Pmode'. + Usually that is the only mode for which a symbol is directly valid. + +`(label_ref LABEL)' + Represents the value of an assembler label for code. It contains + one operand, an expression, which must be a `code_label' that + appears in the instruction sequence to identify the place where + the label should go. + + The reason for using a distinct expression type for code label + references is so that jump optimization can distinguish them. + +`(const:M EXP)' + Represents a constant that is the result of an assembly-time + arithmetic computation. The operand, EXP, is an expression that + contains only constants (`const_int', `symbol_ref' and `label_ref' + expressions) combined with `plus' and `minus'. However, not all + combinations are valid, since the assembler cannot do arbitrary + arithmetic on relocatable symbols. + + M should be `Pmode'. + +`(high:M EXP)' + Represents the high-order bits of EXP, usually a `symbol_ref'. + The number of bits is machine-dependent and is normally the number + of bits specified in an instruction that initializes the high + order bits of a register. It is used with `lo_sum' to represent + the typical two-instruction sequence used in RISC machines to + reference a global memory location. + + M should be `Pmode'. + + +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_DOWNWARDS' 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. However, 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. + + 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. + + 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. + + `scratch' is usually present inside a `clobber' operation (*note + Side Effects::.). + +`(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 refers to the address of the *current* insn. It might have - been more consistent with other usage to make this the address of - the *next* insn but this would be confusing because the length of - the current insn is to be computed. - - For normal insns, the length will be determined by value of the -`length' attribute. In the case of `addr_vec' and `addr_diff_vec' -insn patterns, the length will be computed as the number of vectors -multiplied by the size of each vector. - - The following macros can be used to refine the length computation: - -`FIRST_INSN_ADDRESS' - When the `length' insn attribute is used, this macro specifies the - value to be assigned to the address of the first insn in a - function. If not specified, 0 is used. - -`ADJUST_INSN_LENGTH (INSN, LENGTH)' - If defined, modifies the length assigned to instruction INSN as a - function of the context in which it is used. LENGTH is an lvalue - that contains the initially computed length of the insn and - should be updated with the correct length of the insn. If - updating is required, INSN must not be a varying-length insn. - - This macro will normally not be required. A case in which it is - required is the ROMP. On this machine, the size of an `addr_vec' - insn must be increased by two to compensate for the fact that - alignment may be required. - - The routine that returns the value of the `length' attribute, -`get_attr_value', can be used by the output routine to determine the -form of the branch instruction to be written, as the example below -illustrates. - - As an example of the specification of variable-length branches, -consider the IBM 360. If we adopt the convention that a register will -be set to the starting address of a function, we can jump to labels -within 4K of the start using a four-byte instruction. Otherwise, we -need a six-byte sequence to load the address from memory and then -branch to it. - - On such a machine, a pattern for a branch instruction might be -specified as follows: - - (define_insn "jump" - [(set (pc) - (label_ref (match_operand 0 "" "")))] - "" - "* - { - return (get_attr_length (insn) == 4 - ? \"b %l0\" : \"l r15,=a(%l0); br r15\"); - }" - [(set (attr "length") (if_then_else (lt (match_dup 0) (const_int 4096)) - (const_int 4) - (const_int 6)))]) - - -File: gcc.info, Node: Delay Slots, Next: Function Units, Prev: Insn Lengths, Up: Insn Attributes - -Delay Slot Scheduling ---------------------- - - The insn attribute mechanism can be used to specify the -requirements for delay slots, if any, on a target machine. An -instruction is said to require a "delay slot" if some instructions -that are physically after the instruction are executed as if they were -located before it. Classic examples are branch and call instructions, -which often execute the following instruction before the branch or -call is performed. - - On some machines, conditional branch instructions can optionally -"annul" instructions in the delay slot. This means that the -instruction will not be executed for certain branch outcomes. Both -instructions that annul if the branch is true and instructions that -annul if the branch is false are supported. - - Delay slot scheduling differs from instruction scheduling in that -determining whether an instruction needs a delay slot is dependent only -on the type of instruction being generated, not on data flow between -the instructions. See the next section for a discussion of -data-dependent instruction scheduling. - - The requirement of an insn needing one or more delay slots is -indicated via the `define_delay' expression. It has the following -form: - - (define_delay TEST - [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 - DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 - ...]) - - TEST is an attribute test that indicates whether this -`define_delay' applies to a particular insn. If so, the number of -required delay slots is determined by the length of the vector -specified as the second argument. An insn placed in delay slot N must -satisfy attribute test DELAY-N. ANNUL-TRUE-N is an attribute test -that specifies which insns may be annulled if the branch is true. -Similarly, ANNUL-FALSE-N specifies which insns in the delay slot may -be annulled if the branch is false. If annulling is not supported for -that delay slot, `(nil)' should be coded. - - For example, in the common case where branch and call insns require -a single delay slot, which may contain any insn other than a branch or -call, the following would be placed in the `md' file: - - (define_delay (eq_attr "type" "branch,call") - [(eq_attr "type" "!branch,call") (nil) (nil)]) - - Multiple `define_delay' expressions may be specified. In this -case, each such expression specifies different delay slot requirements -and there must be no insn for which tests in two `define_delay' -expressions are both true. - - For example, if we have a machine that requires one delay slot for -branches but two for calls, no delay slot can contain a branch or -call insn, and any valid insn in the delay slot for the branch can be -annulled if the branch is true, we might represent this as follows: - - (define_delay (eq_attr "type" "branch") - [(eq_attr "type" "!branch,call") (eq_attr "type" "!branch,call") (nil)]) - - (define_delay (eq_attr "type" "call") - [(eq_attr "type" "!branch,call") (nil) (nil) - (eq_attr "type" "!branch,call") (nil) (nil)]) - - -File: gcc.info, Node: Function Units, Prev: Delay Slots, Up: Insn Attributes - -Specifying Function Units -------------------------- - - On most RISC machines, there are instructions whose results are not -available for a specific number of cycles. Common cases are -instructions that load data from memory. On many machines, a pipeline -stall will result if the data is referenced too soon after the load -instruction. - - In addition, many newer microprocessors have multiple function -units, usually one for integer and one for floating point, and often -will incur pipeline stalls when a result that is needed is not yet -ready. - - The descriptions in this section allow the specification of how much -time must elapse between the execution of an instruction and the time -when its result is used. It also allows specification of when the -execution of an instruction will delay execution of similar -instructions due to function unit conflicts. - - For the purposes of the specifications in this section, a machine is -divided into "function units", each of which execute a specific class -of instructions. Function units that accept one instruction each -cycle and allow a result to be used in the succeeding instruction -(usually via forwarding) need not be specified. Classic RISC -microprocessors will normally have a single function unit, which we can -call `memory'. The newer "superscalar" processors will often have -function units for floating point operations, usually at least a -floating point adder and multiplier. - - Each usage of a function units by a class of insns is specified -with a `define_function_unit' expression, which looks like this: - - (define_function_unit NAME MULTIPLICITY SIMULTANEITY - TEST READY-DELAY BUSY-DELAY - [CONFLICT-LIST]) - - NAME is a string giving the name of the function unit. - - MULTIPLICITY is an integer specifying the number of identical units -in the processor. If more than one unit is specified, they will be -scheduled independently. Only truly independent units should be -counted; a pipelined unit should be specified as a single unit. (The -only common example of a machine that has multiple function units for a -single instruction class that are truly independent and not pipelined -are the two multiply and two increment units of the CDC 6600.) - - SIMULTANEITY specifies the maximum number of insns that can be -executing in each instance of the function unit simultaneously or zero -if the unit is pipelined and has no limit. - - All `define_function_unit' definitions referring to function unit -NAME must have the same name and values for MULTIPLICITY and -SIMULTANEITY. - - TEST is an attribute test that selects the insns we are describing -in this definition. Note that an insn may use more than one function -unit and a function unit may be specified in more than one -`define_function_unit'. - - READY-DELAY is an integer that specifies the number of cycles after -which the result of the instruction can be used without introducing -any stalls. - - BUSY-DELAY is an integer that represents the default cost if an -insn is scheduled for this unit while the unit is active with another -insn. If SIMULTANEITY is zero, this specification is ignored. -Otherwise, a zero value indicates that these insns execute on NAME in -a fully pipelined fashion, even if SIMULTANEITY is non-zero. A -non-zero value indicates that scheduling a new insn on this unit while -another is active will incur a cost. A cost of two indicates a single -cycle delay. For a normal non-pipelined function unit, BUSY-DELAY -will be twice READY-DELAY. - - CONFLICT-LIST is an optional list giving detailed conflict costs -for this unit. If specified, it is a list of condition test -expressions which are applied to insns already executing in NAME. For -each insn that is in the list, BUSY-DELAY will be used for the conflict -cost, while a value of zero will be used for insns not in the list. - - Typical uses of this vector are where a floating point function -unit can pipeline either single- or double-precision operations, but -not both, or where a memory unit can pipeline loads, but not stores, -etc. - - As an example, consider a classic RISC machine where the result of a -load instruction is not available for two cycles (a single "delay" -instruction is required) and where only one load instruction can be -executed simultaneously. This would be specified as: - - (define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 4) - - For the case of a floating point function unit that can pipeline -either single or double precision, but not both, the following could -be specified: - - (define_function_unit - "fp" 1 1 (eq_attr "type" "sp_fp") 4 8 (eq_attr "type" "dp_fp")] - (define_function_unit - "fp" 1 1 (eq_attr "type" "dp_fp") 4 8 (eq_attr "type" "sp_fp")] - - *Note:* No code currently exists to avoid function unit conflicts, -only data conflicts. Hence MULTIPLICITY, SIMULTANEITY, BUSY-COST, and -CONFLICT-LIST are currently ignored. When such code is written, it is -possible that the specifications for these values may be changed. It -has recently come to our attention that these specifications may not -allow modeling of some of the newer "superscalar" processors that have -insns using multiple pipelined units. These insns will cause a -potential conflict for the second unit used during their execution and -there is no way of representing that conflict. We welcome any -examples of how function unit conflicts work in such processors and -suggestions for their representation. - - -File: gcc.info, Node: Machine Macros, Next: Config, Prev: Machine Desc, Up: Top - -Machine Description Macros -************************** - - In addition to the file `MACHINE.md', a machine description -includes a C header file conventionally given the name `MACHINE.h'. -This header file defines numerous macros that convey the information -about the target machine that does not fit into the scheme of the -`.md' file. The file `tm.h' should be a link to `MACHINE.h'. The -header file `config.h' includes `tm.h' and most compiler source files -include `config.h'. - -* Menu: - -* Driver:: Controlling how the driver runs the compilation passes. -* Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'. -* Storage Layout:: Defining sizes and alignments of data. -* Type Layout:: Defining sizes and properties of basic user data types. -* Registers:: Naming and describing the hardware registers. -* Register Classes:: Defining the classes of hardware registers. -* Stack and Calling:: Defining which way the stack grows and by how much. -* Varargs:: Defining the varargs macros. -* Trampolines:: Code set up at run time to enter a nested function. -* Library Calls:: Controlling how library routines are implicitly called. -* Addressing Modes:: Defining addressing modes valid for memory operands. -* Condition Code:: Defining how insns update the condition code. -* Costs:: Defining relative costs of different operations. -* Sections:: Dividing storage into text, data, and other sections. -* PIC:: Macros for position independent code. -* Assembler Format:: Defining how to write insns and pseudo-ops to output. -* Debugging Info:: Defining the format of debugging output. -* Cross-compilation:: Handling floating point for cross-compilers. -* Misc:: Everything else. - - -File: gcc.info, Node: Driver, Next: Run-time Target, Prev: Machine Macros, Up: Machine Macros - -Controlling the Compilation Driver, `gcc' -========================================= - -`SWITCH_TAKES_ARG (CHAR)' - A C expression which determines whether the option `-CHAR' takes - arguments. The value should be the number of arguments that - option takes--zero, for many options. - - By default, this macro is defined to handle the standard options - properly. You need not define it unless you wish to add - additional options which take arguments. - -`WORD_SWITCH_TAKES_ARG (NAME)' - A C expression which determines whether the option `-NAME' takes - arguments. The value should be the number of arguments that - option takes--zero, for many options. This macro rather than - `SWITCH_TAKES_ARG' is used for multi-character option names. - - By default, this macro is defined to handle the standard options - properly. You need not define it unless you wish to add - additional options which take arguments. - -`SWITCHES_NEED_SPACES' - A string-valued C expression which is nonempty if the linker - needs a space between the `-L' or `-o' option and its argument. - - If this macro is not defined, the default value is 0. - -`CPP_SPEC' - A C string constant that tells the GNU CC driver program options - to pass to CPP. It can also specify how to translate options you - give to GNU CC into options for GNU CC to pass to the CPP. - - Do not define this macro if it does not need to do anything. - -`SIGNED_CHAR_SPEC' - A C string constant that tells the GNU CC driver program options - to pass to CPP. By default, this macro is defined to pass the - option `-D__CHAR_UNSIGNED__' to CPP if `char' will be treated as - `unsigned char' by `cc1'. - - Do not define this macro unless you need to override the default - definition. - -`CC1_SPEC' - A C string constant that tells the GNU CC driver program options - to pass to `cc1'. It can also specify how to translate options - you give to GNU CC into options for GNU CC to pass to the `cc1'. - - Do not define this macro if it does not need to do anything. - -`CC1PLUS_SPEC' - A C string constant that tells the GNU CC driver program options - to pass to `cc1plus'. It can also specify how to translate - options you give to GNU CC into options for GNU CC to pass to the - `cc1plus'. - - Do not define this macro if it does not need to do anything. - -`ASM_SPEC' - A C string constant that tells the GNU CC driver program options - to pass to the assembler. It can also specify how to translate - options you give to GNU CC into options for GNU CC to pass to the - assembler. See the file `sun3.h' for an example of this. - - Do not define this macro if it does not need to do anything. - -`ASM_FINAL_SPEC' - A C string constant that tells the GNU CC driver program how to - run any programs which cleanup after the normal assembler. - Normally, this is not needed. See the file `mips.h' for an - example of this. - - Do not define this macro if it does not need to do anything. - -`LINK_SPEC' - A C string constant that tells the GNU CC driver program options - to pass to the linker. It can also specify how to translate - options you give to GNU CC into options for GNU CC to pass to the - linker. - - Do not define this macro if it does not need to do anything. - -`LIB_SPEC' - Another C string constant used much like `LINK_SPEC'. The - difference between the two is that `LIB_SPEC' is used at the end - of the command given to the linker. - - If this macro is not defined, a default is provided that loads - the standard C library from the usual place. See `gcc.c'. - -`STARTFILE_SPEC' - Another C string constant used much like `LINK_SPEC'. The - difference between the two is that `STARTFILE_SPEC' is used at - the very beginning of the command given to the linker. - - If this macro is not defined, a default is provided that loads the - standard C startup file from the usual place. See `gcc.c'. - -`ENDFILE_SPEC' - Another C string constant used much like `LINK_SPEC'. The - difference between the two is that `ENDFILE_SPEC' is used at the - very end of the command given to the linker. - - Do not define this macro if it does not need to do anything. - -`LINK_LIBGCC_SPECIAL' - Define this macro meaning that `gcc' should find the library - `libgcc.a' by hand, rather than passing the argument `-lgcc' to - tell the linker to do the search. - -`RELATIVE_PREFIX_NOT_LINKDIR' - Define this macro to tell `gcc' that it should only translate a - `-B' prefix into a `-L' linker option if the prefix indicates an - absolute file name. - -`STANDARD_EXEC_PREFIX' - Define this macro as a C string constant if you wish to override - the standard choice of `/usr/local/lib/gcc/' as the default - prefix to try when searching for the executable files of the - compiler. - -`MD_EXEC_PREFIX' - If defined, this macro is an additional prefix to try after - `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when - the `-b' option is used, or the compiler is built as a cross - compiler. - -`STANDARD_STARTFILE_PREFIX' - Define this macro as a C string constant if you wish to override - the standard choice of `/usr/local/lib/gcc/' as the default - prefix to try when searching for startup files such as `crt0.o'. - -`MD_STARTFILE_PREFIX' - If defined, this macro supplies an additional prefix to try after - the standard prefixes. `MD_EXEC_PREFIX' is not searched when the - `-b' option is used, or the compiler is built as a cross compiler. - -`LOCAL_INCLUDE_DIR' - Define this macro as a C string constant if you wish to override - the standard choice of `/usr/local/include' as the default prefix - to try when searching for local header files. `LOCAL_INCLUDE_DIR' - comes before `SYSTEM_INCLUDE_DIR' in the search order. - - Cross compilers do not use this macro and do not search either - `/usr/local/include' or its replacement. - -`SYSTEM_INCLUDE_DIR' - Define this macro as a C string constant if you wish to specify a - system-specific directory to search for header files before the - standard directory. `SYSTEM_INCLUDE_DIR' comes before - `STANDARD_INCLUDE_DIR' in the search order. - - Cross compilers do not use this macro and do not search the - directory specified. - -`STANDARD_INCLUDE_DIR' - Define this macro as a C string constant if you wish to override - the standard choice of `/usr/include' as the default prefix to - try when searching for header files. - - Cross compilers do not use this macro and do not search either - `/usr/include' or its replacement. - -`INCLUDE_DEFAULTS' - Define this macro if you wish to override the entire default - search path for include files. The default search path includes - `GPLUSPLUS_INCLUDE_DIR', `GCC_INCLUDE_DIR', `LOCAL_INCLUDE_DIR', - `SYSTEM_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition, - the macros `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are - defined automatically by `Makefile', and specify private search - areas for GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used - only for C++ programs. - - The definition should be an initializer for an array of - structures. Each array element should have two elements: the - directory name (a string constant) and a flag for C++-only - directories. Mark the end of the array with a null element. For - example, here is the definition used for VMS: - - #define INCLUDE_DEFAULTS \ - { \ - { "GNU_GXX_INCLUDE:", 1}, \ - { "GNU_CC_INCLUDE:", 0}, \ - { "SYS$SYSROOT:[SYSLIB.]", 0}, \ - { ".", 0}, \ - { 0, 0} \ - } - - Here is the order of prefixes tried for exec files: - - 1. Any prefixes specified by the user with `-B'. - - 2. The environment variable `GCC_EXEC_PREFIX', if any. - - 3. The directories specified by the environment variable - `COMPILER_PATH'. - - 4. The macro `STANDARD_EXEC_PREFIX'. - - 5. `/usr/lib/gcc/'. - - 6. The macro `MD_EXEC_PREFIX', if any. - - Here is the order of prefixes tried for startfiles: - - 1. Any prefixes specified by the user with `-B'. - - 2. The environment variable `GCC_EXEC_PREFIX', if any. - - 3. The directories specified by the environment variable - `LIBRARY_PATH'. - - 4. The macro `STANDARD_EXEC_PREFIX'. - - 5. `/usr/lib/gcc/'. - - 6. The macro `MD_EXEC_PREFIX', if any. - - 7. The macro `MD_STARTFILE_PREFIX', if any. - - 8. The macro `STANDARD_STARTFILE_PREFIX'. - - 9. `/lib/'. - - 10. `/usr/lib/'. - - -File: gcc.info, Node: Run-time Target, Next: Storage Layout, Prev: Driver, Up: Machine Macros - -Run-time Target Specification -============================= - -`CPP_PREDEFINES' - Define this to be a string constant containing `-D' options to - define the predefined macros that identify this machine and - system. These macros will be predefined unless the `-ansi' - option is specified. - - In addition, a parallel set of macros are predefined, whose names - are made by appending `__' at the beginning and at the end. These - `__' macros are permitted by the ANSI standard, so they are - predefined regardless of whether `-ansi' is specified. - - For example, on the Sun, one can use the following value: - - "-Dmc68000 -Dsun -Dunix" - - The result is to define the macros `__mc68000__', `__sun__' and - `__unix__' unconditionally, and the macros `mc68000', `sun' and - `unix' provided `-ansi' is not specified. - -`STDC_VALUE' - Define the value to be assigned to the built-in macro `__STDC__'. - The default is the value `1'. - -`extern int target_flags;' - This declaration should be present. - -`TARGET_...' - This series of macros is to allow compiler command arguments to - enable or disable the use of optional features of the target - machine. For example, one machine description serves both the - 68000 and the 68020; a command argument tells the compiler - whether it should use 68020-only instructions or not. This - command argument works by means of a macro `TARGET_68020' that - tests a bit in `target_flags'. - - Define a macro `TARGET_FEATURENAME' for each such option. Its - definition should test a bit in `target_flags'; for example: - - #define TARGET_68020 (target_flags & 1) - - One place where these macros are used is in the - condition-expressions of instruction patterns. Note how - `TARGET_68020' appears frequently in the 68000 machine - description file, `m68k.md'. Another place they are used is in - the definitions of the other macros in the `MACHINE.h' file. - -`TARGET_SWITCHES' - This macro defines names of command options to set and clear bits - in `target_flags'. Its definition is an initializer with a - subgrouping for each command option. - - Each subgrouping contains a string constant, that defines the - option name, and a number, which contains the bits to set in - `target_flags'. A negative number says to clear bits instead; - the negative of the number is which bits to clear. The actual - option name is made by appending `-m' to the specified name. - - One of the subgroupings should have a null string. The number in - this grouping is the default value for `target_flags'. Any - target options act starting with that value. - - Here is an example which defines `-m68000' and `-m68020' with - opposite meanings, and picks the latter as the default: - - #define TARGET_SWITCHES \ - { { "68020", 1}, \ - { "68000", -1}, \ - { "", 1}} - -`TARGET_OPTIONS' - This macro is similar to `TARGET_SWITCHES' but defines names of - command options that have values. Its definition is an - initializer with a subgrouping for each command option. - - Each subgrouping contains a string constant, that defines the - fixed part of the option name, and the address of a variable. - The variable, type `char *', is set to the variable part of the - given option if the fixed part matches. The actual option name - is made by appending `-m' to the specified name. - - Here is an example which defines `-mshort-data-NUMBER'. If the - given option is `-mshort-data-512', the variable `m88k_short_data' - will be set to the string `"512"'. - - extern char *m88k_short_data; - #define TARGET_OPTIONS { { "short-data-", &m88k_short_data } } - -`TARGET_VERSION' - This macro is a C statement to print on `stderr' a string - describing the particular machine description choice. Every - machine description should define `TARGET_VERSION'. For example: - - #ifdef MOTOROLA - #define TARGET_VERSION fprintf (stderr, " (68k, Motorola syntax)"); - #else - #define TARGET_VERSION fprintf (stderr, " (68k, MIT syntax)"); - #endif - -`OVERRIDE_OPTIONS' - Sometimes certain combinations of command options do not make - sense on a particular target machine. You can define a macro - `OVERRIDE_OPTIONS' to take account of this. This macro, if - defined, is executed once just after all the command options have - been parsed. - - Don't use this macro to turn on various extra optimizations for - `-O'. That is what `OPTIMIZATION_OPTIONS' is for. - -`OPTIMIZATION_OPTIONS (LEVEL)' - Some machines may desire to change what optimizations are - performed for various optimization levels. This macro, if - defined, is executed once just after the optimization level is - determined and before the remainder of the command options have - been parsed. Values set in this macro are used as the default - values for the other command line options. - - LEVEL is the optimization level specified; 2 if -O2 is specified, - 1 if -O is specified, and 0 if neither is specified. - - *Do not examine `write_symbols' in this macro!* The debugging - options are not supposed to alter the generated code. + 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. - \ No newline at end of file