--- gcc/gcc.info-16 2018/04/24 17:52:22 1.1.1.2 +++ gcc/gcc.info-16 2018/04/24 18:11:35 1.1.1.6 @@ -1,771 +1,1051 @@ -This is Info file gcc.info, produced by Makeinfo-1.44 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: Debugging Info, Next: Cross-compilation, Prev: Assembler Format, Up: Target Macros - -Controlling Debugging Information Format -======================================== - -`DBX_REGISTER_NUMBER (REGNO)' - A C expression that returns the DBX register number for the - compiler register number REGNO. In simple cases, the value of - this expression may be REGNO itself. But sometimes there are some - registers that the compiler knows about and DBX does not, or vice - versa. In such cases, some register may need to have one number - in the compiler and another for DBX. - - If two registers have consecutive numbers inside GNU CC, and they - can be used as a pair to hold a multiword value, then they *must* - have consecutive numbers after renumbering with - `DBX_REGISTER_NUMBER'. Otherwise, debuggers will be unable to - access such a pair, because they expect register pairs to be - consecutive in their own numbering scheme. - - If you find yourself defining `DBX_REGISTER_NUMBER' in way that - does not preserve register pairs, then what you must do instead is - redefine the actual register numbering scheme. - -`DBX_DEBUGGING_INFO' - Define this macro if GNU CC should produce debugging output for - DBX in response to the `-g' option. - -`SDB_DEBUGGING_INFO' - Define this macro if GNU CC should produce COFF-style debugging - output for SDB in response to the `-g' option. - -`DWARF_DEBUGGING_INFO' - Define this macro if GNU CC should produce dwarf format debugging - output in response to the `-g' option. - -`XCOFF_DEBUGGING_INFO' - Define this macro if GNU CC should produce XCOFF format debugging - output in response to the `-g' option. - -`DEFAULT_GDB_EXTENSIONS' - Define this macro to control whether GNU CC should by default - generate GDB's extended version of DBX debugging information - (assuming DBX-format debugging information is enabled at all). - If you don't define the macro, the default is 1: always generate - the extended information. - -`DEBUG_SYMS_TEXT' - Define this macro if all `.stabs' commands should be output while - in the text section. - -`DEBUGGER_AUTO_OFFSET (X)' - A C expression that returns the integer offset value for an - automatic variable having address X (an RTL expression). The - default computation assumes that X is based on the frame-pointer - and gives the offset from the frame-pointer. This is required - for targets that produce debugging output for DBX or COFF-style - debugging output for SDB and allow the frame-pointer to be - eliminated when the `-g' options is used. - -`DEBUGGER_ARG_OFFSET (OFFSET, X)' - A C expression that returns the integer offset value for an - argument having address X (an RTL expression). The nominal - offset is OFFSET. - -`ASM_STABS_OP' - A C string constant naming the assembler pseudo op to use instead - of `.stabs' to define an ordinary debugging symbol. If you don't - define this macro, `.stabs' is used. This macro applies only to - DBX debugging information format. - -`ASM_STABD_OP' - A C string constant naming the assembler pseudo op to use instead - of `.stabd' to define a debugging symbol whose value is the - current location. If you don't define this macro, `.stabd' is - used. This macro applies only to DBX debugging information - format. - -`ASM_STABN_OP' - A C string constant naming the assembler pseudo op to use instead - of `.stabn' to define a debugging symbol with no name. If you - don't define this macro, `.stabn' is used. This macro applies - only to DBX debugging information format. - -`PUT_SDB_...' - Define these macros to override the assembler syntax for the - special SDB assembler directives. See `sdbout.c' for a list of - these macros and their arguments. If the standard syntax is - used, you need not define them yourself. - -`SDB_DELIM' - Some assemblers do not support a semicolon as a delimiter, even - between SDB assembler directives. In that case, define this - macro to be the delimiter to use (usually `\n'). It is not - necessary to define a new set of `PUT_SDB_OP' macros if this is - the only change required. - -`SDB_GENERATE_FAKE' - Define this macro to override the usual method of constructing a - dummy name for anonymous structure and union types. See - `sdbout.c' for more information. - -`SDB_ALLOW_UNKNOWN_REFERENCES' - Define this macro to allow references to unknown structure, - union, or enumeration tags to be emitted. Standard COFF does not - allow handling of unknown references, MIPS ECOFF has support for - it. - -`SDB_ALLOW_FORWARD_REFERENCES' - Define this macro to allow references to structure, union, or - enumeration tags that have not yet been seen to be handled. Some - assemblers choke if forward tags are used, while some require it. - -`DBX_NO_XREFS' - Define this macro if DBX on your system does not support the - construct `xsTAGNAME'. On some systems, this construct is used to - describe a forward reference to a structure named TAGNAME. On - other systems, this construct is not supported at all. - -`DBX_CONTIN_LENGTH' - A symbol name in DBX-format debugging information is normally - continued (split into two separate `.stabs' directives) when it - exceeds a certain length (by default, 80 characters). On some - operating systems, DBX requires this splitting; on others, - splitting must not be done. You can inhibit splitting by - defining this macro with the value zero. You can override the - default splitting-length by defining this macro as an expression - for the length you desire. - -`DBX_CONTIN_CHAR' - Normally continuation is indicated by adding a `\' character to - the end of a `.stabs' string when a continuation follows. To use - a different character instead, define this macro as a character - constant for the character you want to use. Do not define this - macro if backslash is correct for your system. - -`DBX_WORKING_DIRECTORY' - Define this if DBX wants to have the current directory recorded - in each object file. - - Note that the working directory is always recorded if GDB - extensions are enabled. - -`DBX_STATIC_STAB_DATA_SECTION' - Define this macro if it is necessary to go to the data section - before outputting the `.stabs' pseudo-op for a non-global static - variable. - -`DBX_LBRAC_FIRST' - Define this macro if the `N_LBRAC' symbol for a block should - precede the debugging information for variables and functions - defined in that block. Normally, in DBX format, the `N_LBRAC' - symbol comes first. - -`DBX_FUNCTION_FIRST' - Define this macro if the DBX information for a function and its - arguments should precede the assembler code for the function. - Normally, in DBX format, the debugging information entirely - follows the assembler code. - -`DBX_OUTPUT_FUNCTION_END (STREAM, FUNCTION)' - Define this macro if the target machine requires special output - at the end of the debugging information for a function. The - definition should be a C statement (sans semicolon) to output the - appropriate information to STREAM. FUNCTION is the - `FUNCTION_DECL' node for the function. - -`DBX_OUTPUT_STANDARD_TYPES (SYMS)' - Define this macro if you need to control the order of output of - the standard data types at the beginning of compilation. The - argument SYMS is a `tree' which is a chain of all the predefined - global symbols, including names of data types. - - Normally, DBX output starts with definitions of the types for - integers and characters, followed by all the other predefined - types of the particular language in no particular order. - - On some machines, it is necessary to output different particular - types first. To do this, define `DBX_OUTPUT_STANDARD_TYPES' to - output those symbols in the necessary order. Any predefined - types that you don't explicitly output will be output afterward - in no particular order. - - Be careful not to define this macro so that it works only for C. - There are no global variables to access most of the built-in - types, because another language may have another set of types. - The way to output a particular type is to look through SYMS to - see if you can find it. Here is an example: - - { - tree decl; - for (decl = syms; decl; decl = TREE_CHAIN (decl)) - if (!strcmp (IDENTIFIER_POINTER (DECL_NAME (decl)), "long int")) - dbxout_symbol (decl); - ... - } - - This does nothing if the expected type does not exist. - - See the function `init_decl_processing' in source file `c-decl.c' - to find the names to use for all the built-in C types. - -`DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME)' - A C statement to output DBX debugging information to the stdio - stream STREAM which indicates that file NAME is the main source - file--the file specified as the input file for compilation. This - macro is called only once, at the beginning of compilation. - - This macro need not be defined if the standard form of output for - DBX debugging information is appropriate. - -`DBX_OUTPUT_MAIN_SOURCE_DIRECTORY (STREAM, NAME)' - A C statement to output DBX debugging information to the stdio - stream STREAM which indicates that the current directory during - compilation is named NAME. - - This macro need not be defined if the standard form of output for - DBX debugging information is appropriate. - -`DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME)' - A C statement to output DBX debugging information at the end of - compilation of the main source file NAME. - - If you don't define this macro, nothing special is output at the - end of compilation, which is correct for most machines. - -`DBX_OUTPUT_SOURCE_FILENAME (STREAM, NAME)' - A C statement to output DBX debugging information to the stdio - stream STREAM which indicates that file NAME is the current source - file. This output is generated each time input shifts to a - different source file as a result of `#include', the end of an - included file, or a `#line' command. - - This macro need not be defined if the standard form of output for - DBX debugging information is appropriate. - - -File: gcc.info, Node: Cross-compilation, Next: Misc, Prev: Debugging Info, Up: Target Macros - -Cross Compilation and Floating Point Format -=========================================== - - While all modern machines use 2's complement representation for -integers, there are a variety of representations for floating point -numbers. This means that in a cross-compiler the representation of -floating point numbers in the compiled program may be different from -that used in the machine doing the compilation. - - Because different representation systems may offer different -amounts of range and precision, the cross compiler cannot safely use -the host machine's floating point arithmetic. Therefore, floating -point constants must be represented in the target machine's format. -This means that the cross compiler cannot use `atof' to parse a -floating point constant; it must have its own special routine to use -instead. Also, constant folding must emulate the target machine's -arithmetic (or must not be done at all). - - The macros in the following table should be defined only if you are -cross compiling between different floating point formats. - - Otherwise, don't define them. Then default definitions will be set -up which use `double' as the data type, `==' to test for equality, etc. - - You don't need to worry about how many times you use an operand of -any of these macros. The compiler never uses operands which have side -effects. - -`REAL_VALUE_TYPE' - A macro for the C data type to be used to hold a floating point - value in the target machine's format. Typically this would be a - `struct' containing an array of `int'. - -`REAL_VALUES_EQUAL (X, Y)' - A macro for a C expression which compares for equality the two - values, X and Y, both of type `REAL_VALUE_TYPE'. - -`REAL_VALUES_LESS (X, Y)' - A macro for a C expression which tests whether X is less than Y, - both values being of type `REAL_VALUE_TYPE' and interpreted as - floating point numbers in the target machine's representation. - -`REAL_VALUE_LDEXP (X, SCALE)' - A macro for a C expression which performs the standard library - function `ldexp', but using the target machine's floating point - representation. Both X and the value of the expression have type - `REAL_VALUE_TYPE'. The second argument, SCALE, is an integer. - -`REAL_VALUE_FIX (X)' - A macro whose definition is a C expression to convert the - target-machine floating point value X to a signed integer. X has - type `REAL_VALUE_TYPE'. - -`REAL_VALUE_UNSIGNED_FIX (X)' - A macro whose definition is a C expression to convert the - target-machine floating point value X to an unsigned integer. X - has type `REAL_VALUE_TYPE'. - -`REAL_VALUE_FIX_TRUNCATE (X)' - A macro whose definition is a C expression to convert the - target-machine floating point value X to a signed integer, - rounding toward 0. X has type `REAL_VALUE_TYPE'. - -`REAL_VALUE_UNSIGNED_FIX_TRUNCATE (X)' - A macro whose definition is a C expression to convert the - target-machine floating point value X to an unsigned integer, - rounding toward 0. X has type `REAL_VALUE_TYPE'. - -`REAL_VALUE_ATOF (STRING)' - A macro for a C expression which converts STRING, an expression - of type `char *', into a floating point number in the target - machine's representation. The value has type `REAL_VALUE_TYPE'. - -`REAL_INFINITY' - Define this macro if infinity is a possible floating point value, - and therefore division by 0 is legitimate. - -`REAL_VALUE_ISINF (X)' - A macro for a C expression which determines whether X, a floating - point value, is infinity. The value has type `int'. By default, - this is defined to call `isinf'. - -`REAL_VALUE_ISNAN (X)' - A macro for a C expression which determines whether X, a floating - point value, is a "nan" (not-a-number). The value has type - `int'. By default, this is defined to call `isnan'. - - Define the following additional macros if you want to make floating -point constant folding work while cross compiling. If you don't -define them, cross compilation is still possible, but constant folding -will not happen for floating point values. - -`REAL_ARITHMETIC (OUTPUT, CODE, X, Y)' - A macro for a C statement which calculates an arithmetic - operation of the two floating point values X and Y, both of type - `REAL_VALUE_TYPE' in the target machine's representation, to - produce a result of the same type and representation which is - stored in OUTPUT (which will be a variable). - - The operation to be performed is specified by CODE, a tree code - which will always be one of the following: `PLUS_EXPR', - `MINUS_EXPR', `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'. - - The expansion of this macro is responsible for checking for - overflow. If overflow happens, the macro expansion should - execute the statement `return 0;', which indicates the inability - to perform the arithmetic operation requested. - -`REAL_VALUE_NEGATE (X)' - A macro for a C expression which returns the negative of the - floating point value X. Both X and the value of the expression - have type `REAL_VALUE_TYPE' and are in the target machine's - floating point representation. - - There is no way for this macro to report overflow, since overflow - can't happen in the negation operation. - -`REAL_VALUE_TRUNCATE (X)' - A macro for a C expression which converts the double-precision - floating point value X to single-precision. - - Both X and the value of the expression have type - `REAL_VALUE_TYPE' and are in the target machine's floating point - representation. However, the value should have an appropriate bit - pattern to be output properly as a single-precision floating - constant. - - There is no way for this macro to report overflow. - -`REAL_VALUE_TO_INT (LOW, HIGH, X)' - A macro for a C expression which converts a floating point value - X into a double-precision integer which is then stored into LOW - and HIGH, two variables of type INT. - -`REAL_VALUE_FROM_INT (X, LOW, HIGH)' - A macro for a C expression which converts a double-precision - integer found in LOW and HIGH, two variables of type INT, into a - floating point value which is then stored into X. - - -File: gcc.info, Node: Misc, Prev: Cross-compilation, Up: Target Macros - -Miscellaneous Parameters -======================== - -`PREDICATE_CODES' - Optionally define this if you have added predicates to - `MACHINE.c'. This macro is called within an initializer of an - array of structures. The first field in the structure is the - name of a predicate and the second field is an array of rtl - codes. For each predicate, list all rtl codes that can be in - expressions matched by the predicate. The list should have a - trailing comma. Here is an example of two entries in the list - for a typical RISC machine: - - #define PREDICATE_CODES \ - {"gen_reg_rtx_operand", {SUBREG, REG}}, \ - {"reg_or_short_cint_operand", {SUBREG, REG, CONST_INT}}, - - Defining this macro does not affect the generated code (however, - incorrect definitions that omit an rtl code that may be matched - by the predicate can cause the compiler to malfunction). - Instead, it allows the table built by `genrecog' to be more - compact and efficient, thus speeding up the compiler. The most - important predicates to include in the list specified by this - macro are thoses used in the most insn patterns. - -`CASE_VECTOR_MODE' - An alias for a machine mode name. This is the machine mode that - elements of a jump-table should have. - -`CASE_VECTOR_PC_RELATIVE' - Define this macro if jump-tables should contain relative - addresses. - -`CASE_DROPS_THROUGH' - Define this if control falls through a `case' insn when the index - value is out of range. This means the specified default-label is - actually ignored by the `case' insn proper. - -`BYTE_LOADS_ZERO_EXTEND' - Define this macro if an instruction to load a value narrower than - a word from memory into a register also zero-extends the value to - the whole register. - -`IMPLICIT_FIX_EXPR' - An alias for a tree code that should be used by default for - conversion of floating point values to fixed point. Normally, - `FIX_ROUND_EXPR' is used. - -`FIXUNS_TRUNC_LIKE_FIX_TRUNC' - Define this macro if the same instructions that convert a floating - point number to a signed fixed point number also convert validly - to an unsigned one. - -`EASY_DIV_EXPR' - An alias for a tree code that is the easiest kind of division to - compile code for in the general case. It may be - `TRUNC_DIV_EXPR', `FLOOR_DIV_EXPR', `CEIL_DIV_EXPR' or - `ROUND_DIV_EXPR'. These four division operators differ in how - they round the result to an integer. `EASY_DIV_EXPR' is used - when it is permissible to use any of those kinds of division and - the choice should be made on the basis of efficiency. - -`MOVE_MAX' - The maximum number of bytes that a single instruction can move - quickly from memory to memory. - -`SHIFT_COUNT_TRUNCATED' - Defining this macro causes the compiler to omit a sign-extend, - zero-extend, or bitwise `and' instruction that truncates the - count of a shift operation to a width equal to the number of bits - needed to represent the size of the object being shifted. On - machines that have instructions that act on bitfields at variable - positions, including `bit test' instructions, defining - `SHIFT_COUNT_TRUNCATED' also causes truncation not to be applied - to these instructions. - - If both types of instructions truncate the count (for shifts) and - position (for bitfield operations), or if no variable-position - bitfield instructions exist, you should define this macro. - - However, on some machines, such as the 80386 and the 680x0, - truncation only applies to shift operations and not the (real or - pretended) bitfield operations. Do not define - `SHIFT_COUNT_TRUNCATED' on such machines. Instead, add patterns - to the `md' file that include the implied truncation of the shift - instructions. - -`TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)' - A C expression which is nonzero if on this machine it is safe to - "convert" an integer of INPREC bits to one of OUTPREC bits (where - OUTPREC is smaller than INPREC) by merely operating on it as if - it had only OUTPREC bits. - - On many machines, this expression can be 1. - - It is reported that suboptimal code can result when - `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for modes - for which `MODES_TIEABLE_P' is 0. If this is the case, making - `TRULY_NOOP_TRUNCATION' return 0 in such cases may improve things. - -`STORE_FLAG_VALUE' - A C expression describing the value returned by a comparison - operator and stored by a store-flag instruction (`sCOND') when the - condition is true. This description must apply to *all* the - `sCOND' patterns and all the comparison operators. - - A value of 1 or -1 means that the instruction implementing the - comparison operator returns exactly 1 or -1 when the comparison - is true and 0 when the comparison is false. Otherwise, the value - indicates which bits of the result are guaranteed to be 1 when - the comparison is true. This value is interpreted in the mode of - the comparison operation, which is given by the mode of the first - operand in the `sCOND' pattern. Either the low bit or the sign - bit of `STORE_FLAG_VALUE' be on. Presently, only those bits are - used by the compiler. - - If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will - generate code that depends only on the specified bits. It can - also replace comparison operators with equivalent operations if - they cause the required bits to be set, even if the remaining - bits are undefined. For example, on a machine whose comparison - operators return an `SImode' value and where `STORE_FLAG_VALUE' - is defined as `0x80000000', saying that just the sign bit is - relevant, the expression - - (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) - - can be converted to - - (ashift:SI X (const_int N)) - - where N is the appropriate shift count to move the bit being - tested into the sign bit. - - There is no way to describe a machine that always sets the - low-order bit for a true value, but does not guarantee the value - of any other bits, but we do not know of any machine that has - such an instruction. If you are trying to port GNU CC to such a - machine, include an instruction to perform a logical-and of the - result with 1 in the pattern for the comparison operators and let - us know (*note Bug Reporting::.). - - Often, a machine will have multiple instructions that obtain a - value from a comparison (or the condition codes). Here are rules - to guide the choice of value for `STORE_FLAG_VALUE', and hence - the instructions to be used: - - * Use the shortest sequence that yields a valid definition for - `STORE_FLAG_VALUE'. It is more efficent for the compiler to - "normalize" the value (convert it to, e.g., 1 or 0) than for - the comparison operators to do so because there may be - opportunities to combine the normalization with other - operations. - - * For equal-length sequences, use a value of 1 or -1, with -1 - being slightly preferred on machines with expensive jumps - and 1 preferred on other machines. - - * As a second choice, choose a value of `0x80000001' if - instructions exist that set both the sign and low-order bits - but do not define the others. - - * Otherwise, use a value of `0x80000000'. - - You need not define `STORE_FLAG_VALUE' if the machine has no - store-flag instructions. - -`Pmode' - An alias for the machine mode for pointers. Normally the - definition can be - - #define Pmode SImode - -`FUNCTION_MODE' - An alias for the machine mode used for memory references to - functions being called, in `call' RTL expressions. On most - machines this should be `QImode'. - -`INTEGRATE_THRESHOLD (DECL)' - A C expression for the maximum number of instructions above which - the function DECL should not be inlined. DECL is a - `FUNCTION_DECL' node. - - The default definition of this macro is 64 plus 8 times the - number of arguments that the function accepts. Some people think - a larger threshold should be used on RISC machines. - -`SCCS_DIRECTIVE' - Define this if the preprocessor should ignore `#sccs' directives - and print no error message. - -`HANDLE_PRAGMA (STREAM)' - Define this macro if you want to implement any pragmas. If - defined, it should be a C statement to be executed when `#pragma' - is seen. The argument STREAM is the stdio input stream from - which the source text can be read. - - It is generally a bad idea to implement new uses of `#pragma'. - The only reason to define this macro is for compatibility with - other compilers that do support `#pragma' for the sake of any user - programs which already use it. - -`DOLLARS_IN_IDENTIFIERS' - Define this macro to control use of the character `$' in - identifier names. The value should be 0, 1, or 2. 0 means `$' - is not allowed by default; 1 means it is allowed by default if - `-traditional' is used; 2 means it is allowed by default provided - `-ansi' is not used. 1 is the default; there is no need to - define this macro in that case. - -`NO_DOLLAR_IN_LABEL' - Define this macro if the assembler does not accept the character - `$' in label names. By default constructors and destructors in - G++ have `$' in the identifiers. If this macro is defined, `.' - is used instead. - -`DEFAULT_MAIN_RETURN' - Define this macro if the target system expects every program's - `main' function to return a standard "success" value by default - (if no other value is explicitly returned). - - The definition should be a C statement (sans semicolon) to - generate the appropriate rtl instructions. It is used only when - compiling the end of `main'. - -`HAVE_ATEXIT' - Define this if the target system supports the function `atexit' - from the ANSI C standard. If this is not defined, and - `INIT_SECTION_ASM_OP' is not defined, a default `exit' function - will be provided to support C++. - -`EXIT_BODY' - Define this if your `exit' function needs to do something besides - calling an external function `_cleanup' before terminating with - `_exit'. The `EXIT_BODY' macro is only needed if netiher - `HAVE_ATEXIT' nor `INIT_SECTION_ASM_OP' are defined. - - -File: gcc.info, Node: Config, Next: Index, Prev: Target Macros, Up: Top - -The Configuration File -********************** - - The configuration file `xm-MACHINE.h' contains macro definitions -that describe the machine and system on which the compiler is running, -unlike the definitions in `MACHINE.h', which describe the machine for -which the compiler is producing output. Most of the values in -`xm-MACHINE.h' are actually the same on all machines that GNU CC runs -on, so large parts of all configuration files are identical. But -there are some macros that vary: - -`USG' - Define this macro if the host system is System V. - -`VMS' - Define this macro if the host system is VMS. - -`FAILURE_EXIT_CODE' - A C expression for the status code to be returned when the - compiler exits after serious errors. - -`SUCCESS_EXIT_CODE' - A C expression for the status code to be returned when the - compiler exits without serious errors. - -`HOST_WORDS_BIG_ENDIAN' - Defined if the host machine stores words of multi-word values in - big-endian order. (GNU CC does not depend on the host byte - ordering within a word.) - -`HOST_FLOAT_FORMAT' - A numeric code distinguishing the floating point format for the - host machine. See `TARGET_FLOAT_FORMAT' in *Note Storage - Layout:: for the alternatives and default. - -`HOST_BITS_PER_CHAR' - A C expression for the number of bits in `char' on the host - machine. - -`HOST_BITS_PER_SHORT' - A C expression for the number of bits in `short' on the host - machine. - -`HOST_BITS_PER_INT' - A C expression for the number of bits in `int' on the host - machine. - -`HOST_BITS_PER_LONG' - A C expression for the number of bits in `long' on the host - machine. - -`ONLY_INT_FIELDS' - Define this macro to indicate that the host compiler only supports - `int' bit fields, rather than other integral types, including - `enum', as do most C compilers. - -`EXECUTABLE_SUFFIX' - Define this macro if the host system uses a naming convention for - executable files that involves a common suffix (such as, in some - systems, `.exe') that must be mentioned explicitly when you run - the program. - -`OBSTACK_CHUNK_SIZE' - A C expression for the size of ordinary obstack chunks. If you - don't define this, a usually-reasonable default is used. - -`OBSTACK_CHUNK_ALLOC' - The function used to allocate obstack chunks. If you don't - define this, `xmalloc' is used. - -`OBSTACK_CHUNK_FREE' - The function used to free obstack chunks. If you don't define - this, `free' is used. - -`USE_C_ALLOCA' - Define this macro to indicate that the compiler is running with - the `alloca' implemented in C. This version of `alloca' can be - found in the file `alloca.c'; to use it, you must also alter the - `Makefile' variable `ALLOCA'. (This is done automatically for - the systems on which we know it is needed.) - - If you do define this macro, you should probably do it as follows: - - #ifndef __GNUC__ - #define USE_C_ALLOCA - #else - #define alloca __builtin_alloca - #endif - - so that when the compiler is compiled with GNU CC it uses the more - efficient built-in `alloca' function. - -`FUNCTION_CONVERSION_BUG' - Define this macro to indicate that the host compiler does not - properly handle converting a function value to a - pointer-to-function when it is used in an expression. - -`HAVE_VPRINTF' - Define this if the library function `vprintf' is available on your - system. - -`HAVE_PUTENV' - Define this if the library function `putenv' is available on your - system. - -`NO_SYS_SIGLIST' - Define this if your system *does not* provide the variable - `sys_siglist'. - - Some systems do provide this variable, but with a different name - such as `_sys_siglist'. On these systems, you can define - `sys_siglist' as a macro which expands into the name actually - provided. - -`NO_STAB_H' - Define this if your system does not have the include file - `stab.h'. If `USG' is defined, `NO_STAB_H' is assumed. - - In addition, configuration files for system V define `bcopy', -`bzero' and `bcmp' as aliases. Some files define `alloca' as a macro -when compiled with GNU CC, in order to take advantage of the benefit -of GNU CC's built-in `alloca'. +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: Expander Definitions, Next: Insn Splitting, Prev: Peephole Definitions, Up: Machine Desc + +Defining RTL Sequences for Code Generation +========================================== + + On some target machines, some standard pattern names for RTL +generation cannot be handled with single insn, but a sequence of RTL +insns can represent them. For these target machines, you can write a +`define_expand' to specify how to generate the sequence of RTL. + + A `define_expand' is an RTL expression that looks almost like a +`define_insn'; but, unlike the latter, a `define_expand' is used only +for RTL generation and it can produce more than one RTL insn. + + A `define_expand' RTX has four operands: + + * The name. Each `define_expand' must have a name, since the only + use for it is to refer to it by name. + + * The RTL template. This is just like the RTL template for a + `define_peephole' in that it is a vector of RTL expressions each + being one insn. + + * The condition, a string containing a C expression. This + expression is used to express how the availability of this pattern + depends on subclasses of target machine, selected by command-line + options when GNU CC is run. This is just like the condition of a + `define_insn' that has a standard name. + + * The preparation statements, a string containing zero or more C + statements which are to be executed before RTL code is generated + from the RTL template. + + Usually these statements prepare temporary registers for use as + internal operands in the RTL template, but they can also generate + RTL insns directly by calling routines such as `emit_insn', etc. + Any such insns precede the ones that come from the RTL template. + + Every RTL insn emitted by a `define_expand' must match some +`define_insn' in the machine description. Otherwise, the compiler will +crash when trying to generate code for the insn or trying to optimize +it. + + The RTL template, in addition to controlling generation of RTL insns, +also describes the operands that need to be specified when this pattern +is used. In particular, it gives a predicate for each operand. + + A true operand, which needs to be specified in order to generate RTL +from the pattern, should be described with a `match_operand' in its +first occurrence in the RTL template. This enters information on the +operand's predicate into the tables that record such things. GNU CC +uses the information to preload the operand into a register if that is +required for valid RTL code. If the operand is referred to more than +once, subsequent references should use `match_dup'. + + The RTL template may also refer to internal "operands" which are +temporary registers or labels used only within the sequence made by the +`define_expand'. Internal operands are substituted into the RTL +template with `match_dup', never with `match_operand'. The values of +the internal operands are not passed in as arguments by the compiler +when it requests use of this pattern. Instead, they are computed +within the pattern, in the preparation statements. These statements +compute the values and store them into the appropriate elements of +`operands' so that `match_dup' can find them. + + There are two special macros defined for use in the preparation +statements: `DONE' and `FAIL'. Use them with a following semicolon, as +a statement. + +`DONE' + Use the `DONE' macro to end RTL generation for the pattern. The + only RTL insns resulting from the pattern on this occasion will be + those already emitted by explicit calls to `emit_insn' within the + preparation statements; the RTL template will not be generated. + +`FAIL' + Make the pattern fail on this occasion. When a pattern fails, it + means that the pattern was not truly available. The calling + routines in the compiler will try other strategies for code + generation using other patterns. + + Failure is currently supported only for binary (addition, + multiplication, shifting, etc.) and bitfield (`extv', `extzv', and + `insv') operations. + + Here is an example, the definition of left-shift for the SPUR chip: + + (define_expand "ashlsi3" + [(set (match_operand:SI 0 "register_operand" "") + (ashift:SI + + (match_operand:SI 1 "register_operand" "") + (match_operand:SI 2 "nonmemory_operand" "")))] + "" + " + + { + if (GET_CODE (operands[2]) != CONST_INT + || (unsigned) INTVAL (operands[2]) > 3) + FAIL; + }") + +This example uses `define_expand' so that it can generate an RTL insn +for shifting when the shift-count is in the supported range of 0 to 3 +but fail in other cases where machine insns aren't available. When it +fails, the compiler tries another strategy using different patterns +(such as, a library call). + + If the compiler were able to handle nontrivial condition-strings in +patterns with names, then it would be possible to use a `define_insn' +in that case. Here is another case (zero-extension on the 68000) which +makes more use of the power of `define_expand': + + (define_expand "zero_extendhisi2" + [(set (match_operand:SI 0 "general_operand" "") + (const_int 0)) + (set (strict_low_part + (subreg:HI + (match_dup 0) + 0)) + (match_operand:HI 1 "general_operand" ""))] + "" + "operands[1] = make_safe_from (operands[1], operands[0]);") + +Here two RTL insns are generated, one to clear the entire output operand +and the other to copy the input operand into its low half. This +sequence is incorrect if the input operand refers to [the old value of] +the output operand, so the preparation statement makes sure this isn't +so. The function `make_safe_from' copies the `operands[1]' into a +temporary register if it refers to `operands[0]'. It does this by +emitting another RTL insn. + + Finally, a third example shows the use of an internal operand. +Zero-extension on the SPUR chip is done by `and'-ing the result against +a halfword mask. But this mask cannot be represented by a `const_int' +because the constant value is too large to be legitimate on this +machine. So it must be copied into a register with `force_reg' and +then the register used in the `and'. + + (define_expand "zero_extendhisi2" + [(set (match_operand:SI 0 "register_operand" "") + (and:SI (subreg:SI + (match_operand:HI 1 "register_operand" "") + 0) + (match_dup 2)))] + "" + "operands[2] + = force_reg (SImode, gen_rtx (CONST_INT, + VOIDmode, 65535)); ") + + *Note:* If the `define_expand' is used to serve a standard binary or +unary arithmetic operation or a bitfield operation, then the last insn +it generates must not be a `code_label', `barrier' or `note'. It must +be an `insn', `jump_insn' or `call_insn'. If you don't need a real insn +at the end, emit an insn to copy the result of the operation into +itself. Such an insn will generate no code, but it can avoid problems +in the compiler. + + +File: gcc.info, Node: Insn Splitting, Next: Insn Attributes, Prev: Expander Definitions, Up: Machine Desc + +Defining How to Split Instructions +================================== + + There are two cases where you should specify how to split a pattern +into multiple insns. 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-instruction delay slots. However, some insns may generate +more than one machine instruction. These insns cannot be placed into a +delay slot. + + Often you can rewrite 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 compiler splits the insn if there is a +reason to believe that it might improve instruction or delay slot +scheduling. + + The insn combiner phase also splits putative insns. If three insns +are merged into one insn with a complex expression that cannot be +matched by some `define_insn' pattern, the combiner phase attempts to +split the complex pattern into two insns that are recognized. Usually +it can break the complex pattern into two patterns by splitting out some +subexpression. However, in some other cases, such as performing an +addition of a large constant in two insns on a RISC machine, the way to +split the addition into two insns is machine-dependent. + + The `define_split' definition tells the compiler how to split a +complex insn into several simpler insns. It 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'. 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 statements that are +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. Unlike those in +`define_expand', however, these statements must not generate any new +pseudo-registers. Once reload has completed, they also must not +allocate any space in the stack frame. + + Patterns are matched against INSN-PATTERN in two different +circumstances. If an insn needs to be split for delay slot scheduling +or insn scheduling, the insn is already known to be valid, which means +that it must have been matched by some `define_insn' and, if +`reload_completed' is non-zero, is known to satisfy the constraints of +that `define_insn'. In that case, the new insn patterns must also be +insns that are matched by some `define_insn' and, if `reload_completed' +is non-zero, must also satisfy the constraints of those definitions. + + As an example of this usage of `define_split', consider the following +example from `a29k.md', 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]); }") + + When the combiner phase tries to split an insn pattern, it is always +the case that the pattern is *not* matched by any `define_insn'. The +combiner pass first tries to split a single `set' expression and then +the same `set' expression inside a `parallel', but followed by a +`clobber' of a pseudo-reg to use as a scratch register. In these +cases, the combiner expects exactly two new insn patterns to be +generated. It will verify that these patterns match some `define_insn' +definitions, so you need not do this test in the `define_split' (of +course, there is no point in writing a `define_split' that will never +produce insns that match). + + Here is an example of this use of `define_split', taken from +`rs6000.md': + + (define_split + [(set (match_operand:SI 0 "gen_reg_operand" "") + (plus:SI (match_operand:SI 1 "gen_reg_operand" "") + (match_operand:SI 2 "non_add_cint_operand" "")))] + "" + [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) + (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] + " + { + int low = INTVAL (operands[2]) & 0xffff; + int high = (unsigned) INTVAL (operands[2]) >> 16; + + if (low & 0x8000) + high++, low |= 0xffff0000; + + operands[3] = gen_rtx (CONST_INT, VOIDmode, high << 16); + operands[4] = gen_rtx (CONST_INT, VOIDmode, low); + }") + + Here the predicate `non_add_cint_operand' matches any `const_int' +that is *not* a valid operand of a single add insn. The add with the +smaller displacement is written so that it can be substituted into the +address of a subsequent operation. + + An example that uses a scratch register, from the same file, +generates an equality comparison of a register and a large constant: + + (define_split + [(set (match_operand:CC 0 "cc_reg_operand" "") + (compare:CC (match_operand:SI 1 "gen_reg_operand" "") + (match_operand:SI 2 "non_short_cint_operand" ""))) + (clobber (match_operand:SI 3 "gen_reg_operand" ""))] + "find_single_use (operands[0], insn, 0) + && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ + || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" + [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) + (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] + " + { + /* Get the constant we are comparing against, C, and see what it + looks like sign-extended to 16 bits. Then see what constant + could be XOR'ed with C to get the sign-extended value. */ + + int c = INTVAL (operands[2]); + int sextc = (c << 16) >> 16; + int xorv = c ^ sextc; + + operands[4] = gen_rtx (CONST_INT, VOIDmode, xorv); + operands[5] = gen_rtx (CONST_INT, VOIDmode, sextc); + }") + + To avoid confusion, don't write a single `define_split' that accepts +some insns that match some `define_insn' as well as some insns that +don't. Instead, write two separate `define_split' definitions, one for +the insns that are valid and one for the insns that are not valid. + + +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. +* Constant Attributes:: Defining attributes that are constant. +* Delay Slots:: Defining delay slots required for a machine. +* Function Units:: Specifying information for insn scheduling. + + +File: gcc.info, Node: Defining Attributes, Next: Expressions, 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. *Note Constant +Attributes::, for information on attributes that do not depend on any +particular insn. + + 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: + + * A `#define' is written for the symbol `HAVE_ATTR_NAME'. + + * 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: + +`(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. + +`(attr_flag NAME)' + The value of an `attr_flag' expression is true if the flag + specified by NAME is true for the `insn' currently being scheduled. + + NAME is a string specifying one of a fixed set of flags to test. + Test the flags `forward' and `backward' to determine the direction + of a conditional branch. Test the flags `very_likely', `likely', + `very_unlikely', and `unlikely' to determine if a conditional + branch is expected to be taken. + + If the `very_likely' flag is true, then the `likely' flag is also + true. Likewise for the `very_unlikely' and `unlikely' flags. + + This example describes a conditional branch delay slot which can + be nullified for forward branches that are taken (annul-true) or + for backward branches which are not taken (annul-false). + + (define_delay (eq_attr "type" "cbranch") + [(eq_attr "in_branch_delay" "true") + (and (eq_attr "in_branch_delay" "true") + (attr_flag "forward")) + (and (eq_attr "in_branch_delay" "true") + (attr_flag "backward"))]) + + The `forward' and `backward' flags are false if the current `insn' + being scheduled is not a conditional branch. + + The `very_likely' and `likely' flags are true if the `insn' being + scheduled is not a conditional branch. The The `very_unlikely' + and `unlikely' flags are false if the `insn' being scheduled is + not a conditional branch. + + `attr_flag' is only used during delay slot scheduling and has no + meaning to other passes of the compiler. + + +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 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 both the `define_insn' and +the `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. The +way to compute the length of an `asm' insn is to multiply the length +specified in the expression `define_asm_attributes' 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: Constant Attributes, 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'. + +`(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 is computed as the number of vectors multiplied by +the size of each vector. + + Lengths are measured in addressable storage units (bytes). + + 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 `get_attr_length' (the value of the +`length' attribute) 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: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes + +Constant Attributes +------------------- + + A special form of `define_attr', where the expression for the +default value is a `const' expression, indicates an attribute that is +constant for a given run of the compiler. Constant attributes may be +used to specify which variety of processor is used. For example, + + (define_attr "cpu" "m88100,m88110,m88000" + (const + (cond [(symbol_ref "TARGET_88100") (const_string "m88100") + (symbol_ref "TARGET_88110") (const_string "m88110")] + (const_string "m88000")))) + + (define_attr "memory" "fast,slow" + (const + (if_then_else (symbol_ref "TARGET_FAST_MEM") + (const_string "fast") + (const_string "slow")))) + + The routine generated for constant attributes has no parameters as it +does not depend on any particular insn. RTL expressions used to define +the value of a constant attribute may use the `symbol_ref' form, but +may not use either the `match_operand' form or `eq_attr' forms +involving insn attributes. + + +File: gcc.info, Node: Delay Slots, Next: Function Units, Prev: Constant Attributes, 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 in first-in-first-out order. 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 ISSUE-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. + + ISSUE-DELAY is an integer that specifies the number of cycles after +the instruction matching the TEST expression begins using this unit +until a subsequent instruction can begin. A cost of N indicates an N-1 +cycle delay. A subsequent instruction may also be delayed if an +earlier instruction has a longer READY-DELAY value. This blocking +effect is computed using the SIMULTANEITY, READY-DELAY, ISSUE-DELAY, +and CONFLICT-LIST terms. For a normal non-pipelined function unit, +SIMULTANEITY is one, the unit is taken to block for the READY-DELAY +cycles of the executing insn, and smaller values of ISSUE-DELAY are +ignored. + + CONFLICT-LIST is an optional list giving detailed conflict costs for +this unit. If specified, it is a list of condition test expressions to +be applied to insns chosen to execute in NAME following the particular +insn matching TEST that is already executing in NAME. For each insn in +the list, ISSUE-DELAY specifies the conflict cost; for insns not in the +list, the cost is zero. If not specified, CONFLICT-LIST defaults to +all instructions that use the function unit. + + 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 0) + + 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 0 (eq_attr "type" "sp_fp") 4 4 [(eq_attr "type" "dp_fp")]) + (define_function_unit + "fp" 1 0 (eq_attr "type" "dp_fp") 4 4 [(eq_attr "type" "sp_fp")]) + + *Note:* The scheduler attempts to avoid function unit conflicts and +uses all the specifications in the `define_function_unit' expression. +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: Target Macros, Next: Config, Prev: Machine Desc, Up: Top + +Target 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. - \ No newline at end of file