--- gcc/gcc.info-10 2018/04/24 17:51:58 1.1.1.2 +++ gcc/gcc.info-10 2018/04/24 18:06:57 1.1.1.5 @@ -1,1156 +1,1055 @@ -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. +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: Simple Constraints, Next: Multi-Alternative, Prev: Constraints, Up: Constraints +File: gcc.info, Node: VMS Misc, Prev: Global Declarations, Up: VMS -Simple Constraints ------------------- +Other VMS Issues +================ - The simplest kind of constraint is a string full of letters, each of -which describes one kind of operand that is permitted. Here are the -letters that are allowed: - -`m' - A memory operand is allowed, with any kind of address that the - machine supports in general. - -`o' - A memory operand is allowed, but only if the address is - "offsettable". This means that adding a small integer (actually, - the width in bytes of the operand, as determined by its machine - mode) may be added to the address and the result is also a valid - memory address. - - For example, an address which is constant is offsettable; so is an - address that is the sum of a register and a constant (as long as a - slightly larger constant is also within the range of - address-offsets supported by the machine); but an autoincrement - or autodecrement address is not offsettable. More complicated - indirect/indexed addresses may or may not be offsettable - depending on the other addressing modes that the machine supports. - - Note that in an output operand which can be matched by another - operand, the constraint letter `o' is valid only when accompanied - by both `<' (if the target machine has predecrement addressing) - and `>' (if the target machine has preincrement addressing). + GNU CC automatically arranges for `main' to return 1 by default if +you fail to specify an explicit return value. This will be interpreted +by VMS as a status code indicating a normal successful completion. +Version 1 of GNU CC did not provide this default. + + GNU CC on VMS works only with the GNU assembler, GAS. You need +version 1.37 or later of GAS in order to produce value debugging +information for the VMS debugger. Use the ordinary VMS linker with the +object files produced by GAS. + + Under previous versions of GNU CC, the generated code would +occasionally give strange results when linked to the sharable `VAXCRTL' +library. Now this should work. + + A caveat for use of `const' global variables: the `const' modifier +must be specified in every external declaration of the variable in all +of the source files that use that variable. Otherwise the linker will +issue warnings about conflicting attributes for the variable. Your +program will still work despite the warnings, but the variable will be +placed in writable storage. + + Although the VMS linker does distinguish between upper and lower case +letters in global symbols, most VMS compilers convert all such symbols +into upper case and most run-time library routines also have upper case +names. To be able to reliably call such routines, GNU CC (by means of +the assembler GAS) converts global symbols into upper case like other +VMS compilers. However, since the usual practice in C is to distinguish +case, GNU CC (via GAS) tries to preserve usual C behavior by augmenting +each name that is not all lower case. This means truncating the name +to at most 23 characters and then adding more characters at the end +which encode the case pattern of those 23. Names which contain at +least one dollar sign are an exception; they are converted directly into +upper case without augmentation. + + Name augmentation yields bad results for programs that use +precompiled libraries (such as Xlib) which were generated by another +compiler. You can use the compiler option `/NOCASE_HACK' to inhibit +augmentation; it makes external C functions and variables +case-independent as is usual on VMS. Alternatively, you could write +all references to the functions and variables in such libraries using +lower case; this will work on VMS, but is not portable to other +systems. The compiler option `/NAMES' also provides control over +global name handling. + + Function and variable names are handled somewhat differently with GNU +C++. The GNU C++ compiler performs "name mangling" on function names, +which means that it adds information to the function name to describe +the data types of the arguments that the function takes. One result of +this is that the name of a function can become very long. Since the +VMS linker only recognizes the first 31 characters in a name, special +action is taken to ensure that each function and variable has a unique +name that can be represented in 31 characters. + + If the name (plus a name augmentation, if required) is less than 32 +characters in length, then no special action is performed. If the name +is longer than 31 characters, the assembler (GAS) will generate a hash +string based upon the function name, truncate the function name to 23 +characters, and append the hash string to the truncated name. If the +`/VERBOSE' compiler option is used, the assembler will print both the +full and truncated names of each symbol that is truncated. + + The `/NOCASE_HACK' compiler option should not be used when you are +compiling programs that use libg++. libg++ has several instances of +objects (i.e. `Filebuf' and `filebuf') which become indistinguishable +in a case-insensitive environment. This leads to cases where you need +to inhibit augmentation selectively (if you were using libg++ and Xlib +in the same program, for example). There is no special feature for +doing this, but you can get the result by defining a macro for each +mixed case symbol for which you wish to inhibit augmentation. The +macro should expand into the lower case equivalent of itself. For +example: -`V' - A memory operand that is not offsettable. In other words, - anything that would fit the `m' constraint but not the `o' - constraint. - -`<' - A memory operand with autodecrement addressing (either - predecrement or postdecrement) is allowed. - -`>' - A memory operand with autoincrement addressing (either - preincrement or postincrement) is allowed. - -`r' - A register operand is allowed provided that it is in a general - register. - -`d', `a', `f', ... - Other letters can be defined in machine-dependent fashion to - stand for particular classes of registers. `d', `a' and `f' are - defined on the 68000/68020 to stand for data, address and floating - point registers. - -`i' - An immediate integer operand (one with constant value) is allowed. - This includes symbolic constants whose values will be known only - at assembly time. + #define StuDlyCapS studlycaps -`n' - An immediate integer operand with a known numeric value is - allowed. Many systems cannot support assembly-time constants for - operands less than a word wide. Constraints for these operands - should use `n' rather than `i'. - -`I', `J', `K', ... `P' - Other letters in the range `I' through `P' may be defined in a - machine-dependent fashion to permit immediate integer operands - with explicit integer values in specified ranges. For example, - on the 68000, `I' is defined to stand for the range of values 1 - to 8. This is the range permitted as a shift count in the shift - instructions. - -`E' - An immediate floating operand (expression code `const_double') is - allowed, but only if the target floating point format is the same - as that of the host machine (on which the compiler is running). - -`F' - An immediate floating operand (expression code `const_double') is - allowed. - -`G', `H' - `G' and `H' may be defined in a machine-dependent fashion to - permit immediate floating operands in particular ranges of values. - -`s' - An immediate integer operand whose value is not an explicit - integer is allowed. - - This might appear strange; if an insn allows a constant operand - with a value not known at compile time, it certainly must allow - any known value. So why use `s' instead of `i'? Sometimes it - allows better code to be generated. - - For example, on the 68000 in a fullword instruction it is - possible to use an immediate operand; but if the immediate value - is between -128 and 127, better code results from loading the - value into a register and using the register. This is because - the load into the register can be done with a `moveq' - instruction. We arrange for this to happen by defining the - letter `K' to mean "any integer outside the range -128 to 127", - and then specifying `Ks' in the operand constraints. - -`g' - Any register, memory or immediate integer operand is allowed, - except for registers that are not general registers. - -`X' - Any operand whatsoever is allowed, even if it does not satisfy - `general_operand'. This is normally used in the constraint of a - `match_scratch' when certain alternatives will not actually - require a scratch register. - -`0', `1', `2', ... `9' - An operand that matches the specified operand number is allowed. - If a digit is used together with letters within the same - alternative, the digit should come last. - - This is called a "matching constraint" and what it really means is - that the assembler has only a single operand that fills two roles - considered separate in the RTL insn. For example, an add insn - has two input operands and one output operand in the RTL, but on - most machines an add instruction really has only two operands, - one of them an input-output operand. - - Matching constraints work only in circumstances like that add - insn. More precisely, the two operands that match must include - one input-only operand and one output-only operand. Moreover, - the digit must be a smaller number than the number of the operand - that uses it in the constraint. - - For operands to match in a particular case usually means that they - are identical-looking RTL expressions. But in a few special cases - specific kinds of dissimilarity are allowed. For example, `*x' - as an input operand will match `*x++' as an output operand. For - proper results in such cases, the output template should always - use the output-operand's number when printing the operand. - -`p' - An operand that is a valid memory address is allowed. This is - for "load address" and "push address" instructions. - - `p' in the constraint must be accompanied by `address_operand' as - the predicate in the `match_operand'. This predicate interprets - the mode specified in the `match_operand' as the mode of the - memory reference for which the address would be valid. - -`Q', `R', `S', ... `U' - Letters in the range `Q' through `U' may be defined in a - machine-dependent fashion to stand for arbitrary operand types. - The machine description macro `EXTRA_CONSTRAINT' is passed the - operand as its first argument and the constraint letter as its - second operand. - - A typical use for this would be to distinguish certain types of - memory references that affect other insn operands. - - Do not define these constraint letters to accept register - references (`reg'); the reload pass does not expect this and - would not handle it properly. - - In order to have valid assembler code, each operand must satisfy -its constraint. But a failure to do so does not prevent the pattern -from applying to an insn. Instead, it directs the compiler to modify -the code so that the constraint will be satisfied. Usually this is -done by copying an operand into a register. - - Contrast, therefore, the two instruction patterns that follow: - - (define_insn "" - [(set (match_operand:SI 0 "general_operand" "r") - (plus:SI (match_dup 0) - (match_operand:SI 1 "general_operand" "r")))] - "" - "...") - -which has two operands, one of which must appear in two places, and - - (define_insn "" - [(set (match_operand:SI 0 "general_operand" "r") - (plus:SI (match_operand:SI 1 "general_operand" "0") - (match_operand:SI 2 "general_operand" "r")))] - "" - "...") - -which has three operands, two of which are required by a constraint to -be identical. If we are considering an insn of the form - - (insn N PREV NEXT - (set (reg:SI 3) - (plus:SI (reg:SI 6) (reg:SI 109))) - ...) - -the first pattern would not apply at all, because this insn does not -contain two identical subexpressions in the right place. The pattern -would say, "That does not look like an add instruction; try other -patterns." The second pattern would say, "Yes, that's an add -instruction, but there is something wrong with it." It would direct -the reload pass of the compiler to generate additional insns to make -the constraint true. The results might look like this: - - (insn N2 PREV N - (set (reg:SI 3) (reg:SI 6)) - ...) - - (insn N N2 NEXT - (set (reg:SI 3) - (plus:SI (reg:SI 3) (reg:SI 109))) - ...) - - It is up to you to make sure that each operand, in each pattern, has -constraints that can handle any RTL expression that could be present -for that operand. (When multiple alternatives are in use, each -pattern must, for each possible combination of operand expressions, -have at least one alternative which can handle that combination of -operands.) The constraints don't need to *allow* any possible -operand--when this is the case, they do not constrain--but they must -at least point the way to reloading any possible operand so that it -will fit. - - * If the constraint accepts whatever operands the predicate permits, - there is no problem: reloading is never necessary for this - operand. - - For example, an operand whose constraints permit everything except - registers is safe provided its predicate rejects registers. - - An operand whose predicate accepts only constant values is safe - provided its constraints include the letter `i'. If any possible - constant value is accepted, then nothing less than `i' will do; - if the predicate is more selective, then the constraints may also - be more selective. - - * Any operand expression can be reloaded by copying it into a - register. So if an operand's constraints allow some kind of - register, it is certain to be safe. It need not permit all - classes of registers; the compiler knows how to copy a register - into another register of the proper class in order to make an - instruction valid. - - * A nonoffsettable memory reference can be reloaded by copying the - address into a register. So if the constraint uses the letter - `o', all memory references are taken care of. - - * A constant operand can be reloaded by allocating space in memory - to hold it as preinitialized data. Then the memory reference can - be used in place of the constant. So if the constraint uses the - letters `o' or `m', constant operands are not a problem. - - * If the constraint permits a constant and a pseudo register used - in an insn was not allocated to a hard register and is equivalent - to a constant, the register will be replaced with the constant. - If the predicate does not permit a constant and the insn is - re-recognized for some reason, the compiler will crash. Thus the - predicate must always recognize any objects allowed by the - constraint. - - If the operand's predicate can recognize registers, but the -constraint does not permit them, it can make the compiler crash. When -this operand happens to be a register, the reload pass will be -stymied, because it does not know how to copy a register temporarily -into memory. + These macro definitions can be placed in a header file to minimize +the number of changes to your source code.  -File: gcc.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints +File: gcc.info, Node: Portability, Next: Interface, Prev: VMS, Up: Top -Multiple Alternative Constraints --------------------------------- +GNU CC and Portability +********************** - Sometimes a single instruction has multiple alternative sets of -possible operands. For example, on the 68000, a logical-or -instruction can combine register or an immediate value into memory, or -it can combine any kind of operand into a register; but it cannot -combine one memory location into another. - - These constraints are represented as multiple alternatives. An -alternative can be described by a series of letters for each operand. -The overall constraint for an operand is made from the letters for -this operand from the first alternative, a comma, the letters for this -operand from the second alternative, a comma, and so on until the last -alternative. Here is how it is done for fullword logical-or on the -68000: - - (define_insn "iorsi3" - [(set (match_operand:SI 0 "general_operand" "=m,d") - (ior:SI (match_operand:SI 1 "general_operand" "%0,0") - (match_operand:SI 2 "general_operand" "dKs,dmKs")))] - ...) - - The first alternative has `m' (memory) for operand 0, `0' for -operand 1 (meaning it must match operand 0), and `dKs' for operand 2. -The second alternative has `d' (data register) for operand 0, `0' for -operand 1, and `dmKs' for operand 2. The `=' and `%' in the -constraints apply to all the alternatives; their meaning is explained -in the next section (*note Class Preferences::.). - - If all the operands fit any one alternative, the instruction is -valid. Otherwise, for each alternative, the compiler counts how many -instructions must be added to copy the operands so that that -alternative applies. The alternative requiring the least copying is -chosen. If two alternatives need the same amount of copying, the one -that comes first is chosen. These choices can be altered with the `?' -and `!' characters: - -`?' - Disparage slightly the alternative that the `?' appears in, as a - choice when no alternative applies exactly. The compiler regards - this alternative as one unit more costly for each `?' that appears - in it. - -`!' - Disparage severely the alternative that the `!' appears in. This - alternative can still be used if it fits without reloading, but - if reloading is needed, some other alternative will be used. - - When an insn pattern has multiple alternatives in its constraints, -often the appearance of the assembler code is determined mostly by -which alternative was matched. When this is so, the C code for -writing the assembler code can use the variable `which_alternative', -which is the ordinal number of the alternative that was actually -satisfied (0 for the first, 1 for the second alternative, etc.). -*Note Output Statement::. + The main goal of GNU CC was to make a good, fast compiler for +machines in the class that the GNU system aims to run on: 32-bit +machines that address 8-bit bytes and have several general registers. +Elegance, theoretical power and simplicity are only secondary. + + GNU CC gets most of the information about the target machine from a +machine description which gives an algebraic formula for each of the +machine's instructions. This is a very clean way to describe the +target. But when the compiler needs information that is difficult to +express in this fashion, I have not hesitated to define an ad-hoc +parameter to the machine description. The purpose of portability is to +reduce the total work needed on the compiler; it was not of interest +for its own sake. + + GNU CC does not contain machine dependent code, but it does contain +code that depends on machine parameters such as endianness (whether the +most significant byte has the highest or lowest address of the bytes in +a word) and the availability of autoincrement addressing. In the +RTL-generation pass, it is often necessary to have multiple strategies +for generating code for a particular kind of syntax tree, strategies +that are usable for different combinations of parameters. Often I have +not tried to address all possible cases, but only the common ones or +only the ones that I have encountered. As a result, a new target may +require additional strategies. You will know if this happens because +the compiler will call `abort'. Fortunately, the new strategies can be +added in a machine-independent fashion, and will affect only the target +machines that need them.  -File: gcc.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints +File: gcc.info, Node: Interface, Next: Passes, Prev: Portability, Up: Top -Register Class Preferences --------------------------- +Interfacing to GNU CC Output +**************************** - The operand constraints have another function: they enable the -compiler to decide which kind of hardware register a pseudo register -is best allocated to. The compiler examines the constraints that -apply to the insns that use the pseudo register, looking for the -machine-dependent letters such as `d' and `a' that specify classes of -registers. The pseudo register is put in whichever class gets the -most "votes". The constraint letters `g' and `r' also vote: they vote -in favor of a general register. The machine description says which -registers are considered general. - - Of course, on some machines all registers are equivalent, and no -register classes are defined. Then none of this complexity is -relevant. + GNU CC is normally configured to use the same function calling +convention normally in use on the target system. This is done with the +machine-description macros described (*note Target Macros::.). + + However, returning of structure and union values is done differently +on some target machines. As a result, functions compiled with PCC +returning such types cannot be called from code compiled with GNU CC, +and vice versa. This does not cause trouble often because few Unix +library routines return structures or unions. + + GNU CC code returns structures and unions that are 1, 2, 4 or 8 bytes +long in the same registers used for `int' or `double' return values. +(GNU CC typically allocates variables of such types in registers also.) +Structures and unions of other sizes are returned by storing them into +an address passed by the caller (usually in a register). The +machine-description macros `STRUCT_VALUE' and `STRUCT_INCOMING_VALUE' +tell GNU CC where to pass this address. + + By contrast, PCC on most target machines returns structures and +unions of any size by copying the data into an area of static storage, +and then returning the address of that storage as if it were a pointer +value. The caller must copy the data from that memory area to the +place where the value is wanted. This is slower than the method used +by GNU CC, and fails to be reentrant. + + On some target machines, such as RISC machines and the 80386, the +standard system convention is to pass to the subroutine the address of +where to return the value. On these machines, GNU CC has been +configured to be compatible with the standard compiler, when this method +is used. It may not be compatible for structures of 1, 2, 4 or 8 bytes. + + GNU CC uses the system's standard convention for passing arguments. +On some machines, the first few arguments are passed in registers; in +others, all are passed on the stack. It would be possible to use +registers for argument passing on any machine, and this would probably +result in a significant speedup. But the result would be complete +incompatibility with code that follows the standard convention. So this +change is practical only if you are switching to GNU CC as the sole C +compiler for the system. We may implement register argument passing on +certain machines once we have a complete GNU system so that we can +compile the libraries with GNU CC. + + On some machines (particularly the Sparc), certain types of arguments +are passed "by invisible reference". This means that the value is +stored in memory, and the address of the memory location is passed to +the subroutine. + + If you use `longjmp', beware of automatic variables. ANSI C says +that automatic variables that are not declared `volatile' have undefined +values after a `longjmp'. And this is all GNU CC promises to do, +because it is very difficult to restore register variables correctly, +and one of GNU CC's features is that it can put variables in registers +without your asking it to. + + If you want a variable to be unaltered by `longjmp', and you don't +want to write `volatile' because old C compilers don't accept it, just +take the address of the variable. If a variable's address is ever +taken, even if just to compute it and ignore it, then the variable +cannot go in a register: + + { + int careful; + &careful; + ... + } + + Code compiled with GNU CC may call certain library routines. Most of +them handle arithmetic for which there are no instructions. This +includes multiply and divide on some machines, and floating point +operations on any machine for which floating point support is disabled +with `-msoft-float'. Some standard parts of the C library, such as +`bcopy' or `memcpy', are also called automatically. The usual function +call interface is used for calling the library routines. + + These library routines should be defined in the library `libgcc.a', +which GNU CC automatically searches whenever it links a program. On +machines that have multiply and divide instructions, if hardware +floating point is in use, normally `libgcc.a' is not needed, but it is +searched just in case. + + Each arithmetic function is defined in `libgcc1.c' to use the +corresponding C arithmetic operator. As long as the file is compiled +with another C compiler, which supports all the C arithmetic operators, +this file will work portably. However, `libgcc1.c' does not work if +compiled with GNU CC, because each arithmetic function would compile +into a call to itself!  -File: gcc.info, Node: Modifiers, Next: No Constraints, Prev: Class Preferences, Up: Constraints +File: gcc.info, Node: Passes, Next: RTL, Prev: Interface, Up: Top -Constraint Modifier Characters ------------------------------- +Passes and Files of the Compiler +******************************** -`=' - Means that this operand is write-only for this instruction: the - previous value is discarded and replaced by output data. - -`+' - Means that this operand is both read and written by the - instruction. - - When the compiler fixes up the operands to satisfy the - constraints, it needs to know which operands are inputs to the - instruction and which are outputs from it. `=' identifies an - output; `+' identifies an operand that is both input and output; - all other operands are assumed to be input only. - -`&' - Means (in a particular alternative) that this operand is written - before the instruction is finished using the input operands. - Therefore, this operand may not lie in a register that is used as - an input operand or as part of any memory address. - - `&' applies only to the alternative in which it is written. In - constraints with multiple alternatives, sometimes one alternative - requires `&' while others do not. See, for example, the `movdf' - insn of the 68000. - - `&' does not obviate the need to write `='. - -`%' - Declares the instruction to be commutative for this operand and - the following operand. This means that the compiler may - interchange the two operands if that is the cheapest way to make - all operands fit the constraints. This is often used in patterns - for addition instructions that really have only two operands: the - result must go in one of the arguments. Here for example, is how - the 68000 halfword-add instruction is defined: - - (define_insn "addhi3" - [(set (match_operand:HI 0 "general_operand" "=m,r") - (plus:HI (match_operand:HI 1 "general_operand" "%0,0") - (match_operand:HI 2 "general_operand" "di,g")))] - ...) - -`#' - Says that all following characters, up to the next comma, are to - be ignored as a constraint. They are significant only for - choosing register preferences. - -`*' - Says that the following character should be ignored when choosing - register preferences. `*' has no effect on the meaning of the - constraint as a constraint, and no effect on reloading. - - Here is an example: the 68000 has an instruction to sign-extend a - halfword in a data register, and can also sign-extend a value by - copying it into an address register. While either kind of - register is acceptable, the constraints on an address-register - destination are less strict, so it is best if register allocation - makes an address register its goal. Therefore, `*' is used so - that the `d' constraint letter (for data register) is ignored - when computing register preferences. - - (define_insn "extendhisi2" - [(set (match_operand:SI 0 "general_operand" "=*d,a") - (sign_extend:SI - (match_operand:HI 1 "general_operand" "0,g")))] - ...) + The overall control structure of the compiler is in `toplev.c'. This +file is responsible for initialization, decoding arguments, opening and +closing files, and sequencing the passes. + + The parsing pass is invoked only once, to parse the entire input. +The RTL intermediate code for a function is generated as the function +is parsed, a statement at a time. Each statement is read in as a +syntax tree and then converted to RTL; then the storage for the tree +for the statement is reclaimed. Storage for types (and the expressions +for their sizes), declarations, and a representation of the binding +contours and how they nest, remain until the function is finished being +compiled; these are all needed to output the debugging information. + + Each time the parsing pass reads a complete function definition or +top-level declaration, it calls either the function +`rest_of_compilation', or the function `rest_of_decl_compilation' in +`toplev.c', which are responsible for all further processing necessary, +ending with output of the assembler language. All other compiler +passes run, in sequence, within `rest_of_compilation'. When that +function returns from compiling a function definition, the storage used +for that function definition's compilation is entirely freed, unless it +is an inline function (*note An Inline Function is As Fast As a Macro: +Inline.). + + Here is a list of all the passes of the compiler and their source +files. Also included is a description of where debugging dumps can be +requested with `-d' options. + + * Parsing. This pass reads the entire text of a function definition, + constructing partial syntax trees. This and RTL generation are no + longer truly separate passes (formerly they were), but it is + easier to think of them as separate. + + The tree representation does not entirely follow C syntax, because + it is intended to support other languages as well. + + Language-specific data type analysis is also done in this pass, + and every tree node that represents an expression has a data type + attached. Variables are represented as declaration nodes. + + Constant folding and some arithmetic simplifications are also done + during this pass. + + The language-independent source files for parsing are + `stor-layout.c', `fold-const.c', and `tree.c'. There are also + header files `tree.h' and `tree.def' which define the format of + the tree representation. + + The source files to parse C are `c-parse.in', `c-decl.c', + `c-typeck.c', `c-aux-info.c', `c-convert.c', and `c-lang.c' along + with header files `c-lex.h', and `c-tree.h'. + + The source files for parsing C++ are `cp-parse.y', `cp-class.c', + `cp-cvt.c', `cp-decl.c', `cp-decl2.c', `cp-dem.c', `cp-except.c', + `cp-expr.c', `cp-init.c', `cp-lex.c', `cp-method.c', `cp-ptree.c', + `cp-search.c', `cp-tree.c', `cp-type2.c', and `cp-typeck.c', along + with header files `cp-tree.def', `cp-tree.h', and `cp-decl.h'. + + The special source files for parsing Objective C are + `objc-parse.y', `objc-actions.c', `objc-tree.def', and + `objc-actions.h'. Certain C-specific files are used for this as + well. + + The file `c-common.c' is also used for all of the above languages. + + * RTL generation. This is the conversion of syntax tree into RTL + code. It is actually done statement-by-statement during parsing, + but for most purposes it can be thought of as a separate pass. + + This is where the bulk of target-parameter-dependent code is found, + since often it is necessary for strategies to apply only when + certain standard kinds of instructions are available. The purpose + of named instruction patterns is to provide this information to + the RTL generation pass. + + Optimization is done in this pass for `if'-conditions that are + comparisons, boolean operations or conditional expressions. Tail + recursion is detected at this time also. Decisions are made about + how best to arrange loops and how to output `switch' statements. + + The source files for RTL generation include `stmt.c', `calls.c', + `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and + `emit-rtl.c'. Also, the file `insn-emit.c', generated from the + machine description by the program `genemit', is used in this + pass. The header file `expr.h' is used for communication within + this pass. + + The header files `insn-flags.h' and `insn-codes.h', generated from + the machine description by the programs `genflags' and `gencodes', + tell this pass which standard names are available for use and + which patterns correspond to them. + + Aside from debugging information output, none of the following + passes refers to the tree structure representation of the function + (only part of which is saved). + + The decision of whether the function can and should be expanded + inline in its subsequent callers is made at the end of rtl + generation. The function must meet certain criteria, currently + related to the size of the function and the types and number of + parameters it has. Note that this function may contain loops, + recursive calls to itself (tail-recursive functions can be + inlined!), gotos, in short, all constructs supported by GNU CC. + The file `integrate.c' contains the code to save a function's rtl + for later inlining and to inline that rtl when the function is + called. The header file `integrate.h' is also used for this + purpose. + + The option `-dr' causes a debugging dump of the RTL code after + this pass. This dump file's name is made by appending `.rtl' to + the input file name. + + * Jump optimization. This pass simplifies jumps to the following + instruction, jumps across jumps, and jumps to jumps. It deletes + unreferenced labels and unreachable code, except that unreachable + code that contains a loop is not recognized as unreachable in this + pass. (Such loops are deleted later in the basic block analysis.) + It also converts some code originally written with jumps into + sequences of instructions that directly set values from the + results of comparisons, if the machine has such instructions. + + Jump optimization is performed two or three times. The first time + is immediately following RTL generation. The second time is after + CSE, but only if CSE says repeated jump optimization is needed. + The last time is right before the final pass. That time, + cross-jumping and deletion of no-op move instructions are done + together with the optimizations described above. + + The source file of this pass is `jump.c'. + + The option `-dj' causes a debugging dump of the RTL code after + this pass is run for the first time. This dump file's name is + made by appending `.jump' to the input file name. + + * Register scan. This pass finds the first and last use of each + register, as a guide for common subexpression elimination. Its + source is in `regclass.c'. + + * Jump threading. This pass detects a condition jump that branches + to an identical or inverse test. Such jumps can be `threaded' + through the second conditional test. The source code for this + pass is in `jump.c'. This optimization is only performed if + `-fthread-jumps' is enabled. + + * Common subexpression elimination. This pass also does constant + propagation. Its source file is `cse.c'. If constant propagation + causes conditional jumps to become unconditional or to become + no-ops, jump optimization is run again when CSE is finished. + + The option `-ds' causes a debugging dump of the RTL code after + this pass. This dump file's name is made by appending `.cse' to + the input file name. + + * Loop optimization. This pass moves constant expressions out of + loops, and optionally does strength-reduction and loop unrolling + as well. Its source files are `loop.c' and `unroll.c', plus the + header `loop.h' used for communication between them. Loop + unrolling uses some functions in `integrate.c' and the header + `integrate.h'. + + The option `-dL' causes a debugging dump of the RTL code after + this pass. This dump file's name is made by appending `.loop' to + the input file name. + + * If `-frerun-cse-after-loop' was enabled, a second common + subexpression elimination pass is performed after the loop + optimization pass. Jump threading is also done again at this time + if it was specified. + + The option `-dt' causes a debugging dump of the RTL code after + this pass. This dump file's name is made by appending `.cse2' to + the input file name. + + * Stupid register allocation is performed at this point in a + nonoptimizing compilation. It does a little data flow analysis as + well. When stupid register allocation is in use, the next pass + executed is the reloading pass; the others in between are skipped. + The source file is `stupid.c'. + + * Data flow analysis (`flow.c'). This pass divides the program into + basic blocks (and in the process deletes unreachable loops); then + it computes which pseudo-registers are live at each point in the + program, and makes the first instruction that uses a value point at + the instruction that computed the value. + + This pass also deletes computations whose results are never used, + and combines memory references with add or subtract instructions + to make autoincrement or autodecrement addressing. + + The option `-df' causes a debugging dump of the RTL code after + this pass. This dump file's name is made by appending `.flow' to + the input file name. If stupid register allocation is in use, this + dump file reflects the full results of such allocation. + + * Instruction combination (`combine.c'). This pass attempts to + combine groups of two or three instructions that are related by + data flow into single instructions. It combines the RTL + expressions for the instructions by substitution, simplifies the + result using algebra, and then attempts to match the result + against the machine description. + + The option `-dc' causes a debugging dump of the RTL code after + this pass. This dump file's name is made by appending `.combine' + to the input file name. + + * Instruction scheduling (`sched.c'). This pass looks for + instructions whose output will not be available by the time that + it is used in subsequent instructions. (Memory loads and floating + point instructions often have this behavior on RISC machines). It + re-orders instructions within a basic block to try to separate the + definition and use of items that otherwise would cause pipeline + stalls. + + Instruction scheduling is performed twice. The first time is + immediately after instruction combination and the second is + immediately after reload. + + The option `-dS' causes a debugging dump of the RTL code after this + pass is run for the first time. The dump file's name is made by + appending `.sched' to the input file name. + + * Register class preferencing. The RTL code is scanned to find out + which register class is best for each pseudo register. The source + file is `regclass.c'. + + * Local register allocation (`local-alloc.c'). This pass allocates + hard registers to pseudo registers that are used only within one + basic block. Because the basic block is linear, it can use fast + and powerful techniques to do a very good job. + + The option `-dl' causes a debugging dump of the RTL code after + this pass. This dump file's name is made by appending `.lreg' to + the input file name. + + * Global register allocation (`global.c'). This pass allocates hard + registers for the remaining pseudo registers (those whose life + spans are not contained in one basic block). + + * Reloading. This pass renumbers pseudo registers with the hardware + registers numbers they were allocated. Pseudo registers that did + not get hard registers are replaced with stack slots. Then it + finds instructions that are invalid because a value has failed to + end up in a register, or has ended up in a register of the wrong + kind. It fixes up these instructions by reloading the + problematical values temporarily into registers. Additional + instructions are generated to do the copying. + + The reload pass also optionally eliminates the frame pointer and + inserts instructions to save and restore call-clobbered registers + around calls. + + Source files are `reload.c' and `reload1.c', plus the header + `reload.h' used for communication between them. + + The option `-dg' causes a debugging dump of the RTL code after + this pass. This dump file's name is made by appending `.greg' to + the input file name. + + * Instruction scheduling is repeated here to try to avoid pipeline + stalls due to memory loads generated for spilled pseudo registers. + + The option `-dR' causes a debugging dump of the RTL code after + this pass. This dump file's name is made by appending `.sched2' + to the input file name. + + * Jump optimization is repeated, this time including cross-jumping + and deletion of no-op move instructions. + + The option `-dJ' causes a debugging dump of the RTL code after + this pass. This dump file's name is made by appending `.jump2' to + the input file name. + + * Delayed branch scheduling. This optional pass attempts to find + instructions that can go into the delay slots of other + instructions, usually jumps and calls. The source file name is + `reorg.c'. + + The option `-dd' causes a debugging dump of the RTL code after + this pass. This dump file's name is made by appending `.dbr' to + the input file name. + + * Conversion from usage of some hard registers to usage of a register + stack may be done at this point. Currently, this is supported only + for the floating-point registers of the Intel 80387 coprocessor. + The source file name is `reg-stack.c'. + + The options `-dk' causes a debugging dump of the RTL code after + this pass. This dump file's name is made by appending `.stack' to + the input file name. + + * Final. This pass outputs the assembler code for the function. It + is also responsible for identifying spurious test and compare + instructions. Machine-specific peephole optimizations are + performed at the same time. The function entry and exit sequences + are generated directly as assembler code in this pass; they never + exist as RTL. + + The source files are `final.c' plus `insn-output.c'; the latter is + generated automatically from the machine description by the tool + `genoutput'. The header file `conditions.h' is used for + communication between these files. + + * Debugging information output. This is run after final because it + must output the stack slot offsets for pseudo registers that did + not get hard registers. Source files are `dbxout.c' for DBX + symbol table format, `sdbout.c' for SDB symbol table format, and + `dwarfout.c' for DWARF symbol table format. + + Some additional files are used by all or many passes: + + * Every pass uses `machmode.def' and `machmode.h' which define the + machine modes. + + * Several passes use `real.h', which defines the default + representation of floating point constants and how to operate on + them. + + * All the passes that work with RTL use the header files `rtl.h' and + `rtl.def', and subroutines in file `rtl.c'. The tools `gen*' also + use these files to read and work with the machine description RTL. + + * Several passes refer to the header file `insn-config.h' which + contains a few parameters (C macro definitions) generated + automatically from the machine description RTL by the tool + `genconfig'. + + * Several passes use the instruction recognizer, which consists of + `recog.c' and `recog.h', plus the files `insn-recog.c' and + `insn-extract.c' that are generated automatically from the machine + description by the tools `genrecog' and `genextract'. + + * Several passes use the header files `regs.h' which defines the + information recorded about pseudo register usage, and + `basic-block.h' which defines the information recorded about basic + blocks. + + * `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector + with a bit for each hard register, and some macros to manipulate + it. This type is just `int' if the machine has few enough hard + registers; otherwise it is an array of `int' and some of the + macros expand into loops. + + * Several passes use instruction attributes. A definition of the + attributes defined for a particular machine is in file + `insn-attr.h', which is generated from the machine description by + the program `genattr'. The file `insn-attrtab.c' contains + subroutines to obtain the attribute values for insns. It is + generated from the machine description by the program `genattrtab'.  -File: gcc.info, Node: No Constraints, Prev: Modifiers, Up: Constraints +File: gcc.info, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top -Not Using Constraints ---------------------- +RTL Representation +****************** - Some machines are so clean that operand constraints are not -required. For example, on the Vax, an operand valid in one context is -valid in any other context. On such a machine, every operand -constraint would be `g', excepting only operands of "load address" -instructions which are written as if they referred to a memory -location's contents but actual refer to its address. They would have -constraint `p'. - - For such machines, instead of writing `g' and `p' for all the -constraints, you can choose to write a description with empty -constraints. Then you write `""' for the constraint in every -`match_operand'. Address operands are identified by writing an -`address' expression around the `match_operand', not by their -constraints. - - When the machine description has just empty constraints, certain -parts of compilation are skipped, making the compiler faster. However, -few machines actually do not need constraints; all machine descriptions -now in existence use constraints. + Most of the work of the compiler is done on an intermediate +representation called register transfer language. In this language, +the instructions to be output are described, pretty much one by one, in +an algebraic form that describes what the instruction does. + + RTL is inspired by Lisp lists. It has both an internal form, made +up of structures that point at other structures, and a textual form +that is used in the machine description and in printed debugging dumps. +The textual form uses nested parentheses to indicate the pointers in +the internal form. + +* Menu: + +* RTL Objects:: Expressions vs vectors vs strings vs integers. +* Accessors:: Macros to access expression operands or vector elts. +* Flags:: Other flags in an RTL expression. +* Machine Modes:: Describing the size and format of a datum. +* Constants:: Expressions with constant values. +* Regs and Memory:: Expressions representing register contents or memory. +* Arithmetic:: Expressions representing arithmetic on other expressions. +* Comparisons:: Expressions representing comparison of expressions. +* Bit Fields:: Expressions representing bitfields in memory or reg. +* Conversions:: Extending, truncating, floating or fixing. +* RTL Declarations:: Declaring volatility, constancy, etc. +* Side Effects:: Expressions for storing in registers, etc. +* Incdec:: Embedded side-effects for autoincrement addressing. +* Assembler:: Representing `asm' with operands. +* Insns:: Expression types for entire insns. +* Calls:: RTL representation of function call insns. +* Sharing:: Some expressions are unique; others *must* be copied. +* Reading RTL:: Reading textual RTL from a file.  -File: gcc.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc +File: gcc.info, Node: RTL Objects, Next: Accessors, Prev: RTL, Up: RTL -Standard Names for Patterns Used in Generation -============================================== +RTL Object Types +================ - Here is a table of the instruction names that are meaningful in the -RTL generation pass of the compiler. Giving one of these names to an -instruction pattern tells the RTL generation pass that it can use the -pattern in to accomplish a certain task. - -`movM' - Here M stands for a two-letter machine mode name, in lower case. - This instruction pattern moves data with that machine mode from - operand 1 to operand 0. For example, `movsi' moves full-word - data. - - If operand 0 is a `subreg' with mode M of a register whose own - mode is wider than M, the effect of this instruction is to store - the specified value in the part of the register that corresponds - to mode M. The effect on the rest of the register is undefined. - - This class of patterns is special in several ways. First of all, - each of these names *must* be defined, because there is no other - way to copy a datum from one place to another. - - Second, these patterns are not used solely in the RTL generation - pass. Even the reload pass can generate move insns to copy - values from stack slots into temporary registers. When it does - so, one of the operands is a hard register and the other is an - operand that can need to be reloaded into a register. - - Therefore, when given such a pair of operands, the pattern must - generate RTL which needs no reloading and needs no temporary - registers--no registers other than the operands. For example, if - you support the pattern with a `define_expand', then in such a - case the `define_expand' mustn't call `force_reg' or any other - such function which might generate new pseudo registers. - - This requirement exists even for subword modes on a RISC machine - where fetching those modes from memory normally requires several - insns and some temporary registers. Look in `spur.md' to see how - the requirement can be satisfied. - - During reload a memory reference with an invalid address may be - passed as an operand. Such an address will be replaced with a - valid address later in the reload pass. In this case, nothing - may be done with the address except to use it as it stands. If - it is copied, it will not be replaced with a valid address. No - attempt should be made to make such an address into a valid - address and no routine (such as `change_address') that will do so - may be called. Note that `general_operand' will fail when - applied to such an address. - - The global variable `reload_in_progress' (which must be explicitly - declared if required) can be used to determine whether such - special handling is required. - - The variety of operands that have reloads depends on the rest of - the machine description, but typically on a RISC machine these - can only be pseudo registers that did not get hard registers, - while on other machines explicit memory references will get - optional reloads. - - If a scratch register is required to move an object to or from - memory, it can be allocated using `gen_reg_rtx' prior to reload. - But this is impossible during and after reload. If there are - cases needing scratch registers after reload, you must define - `SECONDARY_INPUT_RELOAD_CLASS' and/or - `SECONDARY_OUTPUT_RELOAD_CLASS' to detect them, and provide - patterns `reload_inM' or `reload_outM' to handle them. *Note - Register Classes::. - - The constraints on a `moveM' must permit moving any hard register - to any other hard register provided that `HARD_REGNO_MODE_OK' - permits mode M in both registers and `REGISTER_MOVE_COST' applied - to their classes returns a value of 2. - - It is obligatory to support floating point `moveM' instructions - into and out of any registers that can hold fixed point values, - because unions and structures (which have modes `SImode' or - `DImode') can be in those registers and they may have floating - point members. - - There may also be a need to support fixed point `moveM' - instructions in and out of floating point registers. - Unfortunately, I have forgotten why this was so, and I don't know - whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed - point values in floating point registers, then the constraints of - the fixed point `moveM' instructions must be designed to avoid - ever trying to reload into a floating point register. - -`reload_inM' -`reload_outM' - Like `movM', but used when a scratch register is required to move - between operand 0 and operand 1. Operand 2 describes the scratch - register. See the discussion of the `SECONDARY_RELOAD_CLASS' - macro in *note Register Classes::.. - -`movstrictM' - Like `movM' except that if operand 0 is a `subreg' with mode M of - a register whose natural mode is wider, the `movstrictM' - instruction is guaranteed not to alter any of the register except - the part which belongs to mode M. - -`addM3' - Add operand 2 and operand 1, storing the result in operand 0. - All operands must have mode M. This can be used even on - two-address machines, by means of constraints requiring operands - 1 and 0 to be the same location. - -`subM3', `mulM3' -`divM3', `udivM3', `modM3', `umodM3' -`sminM3', `smaxM3', `uminM3', `umaxM3' -`andM3', `iorM3', `xorM3' - Similar, for other arithmetic operations. - -`mulhisi3' - Multiply operands 1 and 2, which have mode `HImode', and store a - `SImode' product in operand 0. - -`mulqihi3', `mulsidi3' - Similar widening-multiplication instructions of other widths. - -`umulqihi3', `umulhisi3', `umulsidi3' - Similar widening-multiplication instructions that do unsigned - multiplication. - -`divmodM4' - Signed division that produces both a quotient and a remainder. - Operand 1 is divided by operand 2 to produce a quotient stored in - operand 0 and a remainder stored in operand 3. - - For machines with an instruction that produces both a quotient - and a remainder, provide a pattern for `divmodM4' but do not - provide patterns for `divM3' and `modM3'. This allows - optimization in the relatively common case when both the quotient - and remainder are computed. - - If an instruction that just produces a quotient or just a - remainder exists and is more efficient than the instruction that - produces both, write the output routine of `divmodM4' to call - `find_reg_note' and look for a `REG_UNUSED' note on the quotient - or remainder and generate the appropriate instruction. - -`udivmodM4' - Similar, but does unsigned division. - -`ashlM3' - Arithmetic-shift operand 1 left by a number of bits specified by - operand 2, and store the result in operand 0. Operand 2 has mode - `SImode', not mode M. - -`ashrM3', `lshlM3', `lshrM3', `rotlM3', `rotrM3' - Other shift and rotate instructions. - - Logical and arithmetic left shift are the same. Machines that do - not allow negative shift counts often have only one instruction - for shifting left. On such machines, you should define a pattern - named `ashlM3' and leave `lshlM3' undefined. - -`negM2' - Negate operand 1 and store the result in operand 0. - -`absM2' - Store the absolute value of operand 1 into operand 0. - -`sqrtM2' - Store the square root of operand 1 into operand 0. - -`ffsM2' - Store into operand 0 one plus the index of the least significant - 1-bit of operand 1. If operand 1 is zero, store zero. M is the - mode of operand 0; operand 1's mode is specified by the - instruction pattern, and the compiler will convert the operand to - that mode before generating the instruction. - -`one_cmplM2' - Store the bitwise-complement of operand 1 into operand 0. - -`cmpM' - Compare operand 0 and operand 1, and set the condition codes. - The RTL pattern should look like this: - - (set (cc0) (compare (match_operand:M 0 ...) - (match_operand:M 1 ...))) - -`tstM' - Compare operand 0 against zero, and set the condition codes. The - RTL pattern should look like this: - - (set (cc0) (match_operand:M 0 ...)) - - `tstM' patterns should not be defined for machines that do not - use `(cc0)'. Doing so would confuse the optimizer since it would - no longer be clear which `set' operations were comparisons. The - `cmpM' patterns should be used instead. - -`movstrM' - Block move instruction. The addresses of the destination and - source strings are the first two operands, and both are in mode - `Pmode'. The number of bytes to move is the third operand, in - mode M. - - The fourth operand is the known shared alignment of the source and - destination, in the form of a `const_int' rtx. Thus, if the - compiler knows that both source and destination are word-aligned, - it may provide the value 4 for this operand. - - These patterns need not give special consideration to the - possibility that the source and destination strings might overlap. - -`cmpstrM' - Block compare instruction, with five operands. Operand 0 is the - output; it has mode M. The remaining four operands are like the - operands of `movstrM'. The two memory blocks specified are - compared byte by byte in lexicographic order. The effect of the - instruction is to store a value in operand 0 whose sign indicates - the result of the comparison. - -`floatMN2' - Convert signed integer operand 1 (valid for fixed point mode M) to - floating point mode N and store in operand 0 (which has mode N). - -`floatunsMN2' - Convert unsigned integer operand 1 (valid for fixed point mode M) - to floating point mode N and store in operand 0 (which has mode - N). - -`fixMN2' - Convert operand 1 (valid for floating point mode M) to fixed - point mode N as a signed number and store in operand 0 (which has - mode N). This instruction's result is defined only when the - value of operand 1 is an integer. - -`fixunsMN2' - Convert operand 1 (valid for floating point mode M) to fixed - point mode N as an unsigned number and store in operand 0 (which - has mode N). This instruction's result is defined only when the - value of operand 1 is an integer. - -`ftruncM2' - Convert operand 1 (valid for floating point mode M) to an integer - value, still represented in floating point mode M, and store it - in operand 0 (valid for floating point mode M). - -`fix_truncMN2' - Like `fixMN2' but works for any floating point value of mode M by - converting the value to an integer. - -`fixuns_truncMN2' - Like `fixunsMN2' but works for any floating point value of mode M - by converting the value to an integer. - -`truncMN' - Truncate operand 1 (valid for mode M) to mode N and store in - operand 0 (which has mode N). Both modes must be fixed point or - both floating point. - -`extendMN' - Sign-extend operand 1 (valid for mode M) to mode N and store in - operand 0 (which has mode N). Both modes must be fixed point or - both floating point. - -`zero_extendMN' - Zero-extend operand 1 (valid for mode M) to mode N and store in - operand 0 (which has mode N). Both modes must be fixed point. - -`extv' - Extract a bit field from operand 1 (a register or memory - operand), where operand 2 specifies the width in bits and operand - 3 the starting bit, and store it in operand 0. Operand 0 must - have mode `word_mode'. Operand 1 may have mode `byte_mode' or - `word_mode'; often `word_mode' is allowed only for registers. - Operands 2 and 3 must be valid for `word_mode'. - - The RTL generation pass generates this instruction only with - constants for operands 2 and 3. - - The bit-field value is sign-extended to a full word integer - before it is stored in operand 0. - -`extzv' - Like `extv' except that the bit-field value is zero-extended. - -`insv' - Store operand 3 (which must be valid for `word_mode') into a bit - field in operand 0, where operand 1 specifies the width in bits - and operand 2 the starting bit. Operand 0 may have mode - `byte_mode' or `word_mode'; often `word_mode' is allowed only for - registers. Operands 1 and 2 must be valid for `word_mode'. - - The RTL generation pass generates this instruction only with - constants for operands 1 and 2. - -`sCOND' - Store zero or nonzero in the operand according to the condition - codes. Value stored is nonzero iff the condition COND is true. - COND is the name of a comparison operation expression code, such - as `eq', `lt' or `leu'. - - You specify the mode that the operand must have when you write the - `match_operand' expression. The compiler automatically sees - which mode you have used and supplies an operand of that mode. - - The value stored for a true condition must have 1 as its low bit, - or else must be negative. Otherwise the instruction is not - suitable and you should omit it from the machine description. - You describe to the compiler exactly which value is stored by - defining the macro `STORE_FLAG_VALUE' (*note Misc::.). If a - description cannot be found that can be used for all the `sCOND' - patterns, you should omit those operations from the machine - description. - - These operations may fail, but should do so only in relatively - uncommon cases; if they would fail for common cases involving - integer comparisons, it is best to omit these patterns. - - If these operations are omitted, the compiler will usually - generate code that copies the constant one to the target and - branches around an assignment of zero to the target. If this - code is more efficient than the potential instructions used for - the `sCOND' pattern followed by those required to convert the - result into a 1 or a zero in `SImode', you should omit the - `sCOND' operations from the machine description. - -`bCOND' - Conditional branch instruction. Operand 0 is a `label_ref' that - refers to the label to jump to. Jump if the condition codes meet - condition COND. - - Some machines do not follow the model assumed here where a - comparison instruction is followed by a conditional branch - instruction. In that case, the `cmpM' (and `tstM') patterns - should simply store the operands away and generate all the - required insns in a `define_expand' (*note Expander - Definitions::.) for the conditional branch operations. All calls - to expand `vCOND' patterns are immediately preceded by calls to - expand either a `cmpM' pattern or a `tstM' pattern. - - Machines that use a pseudo register for the condition code value, - or where the mode used for the comparison depends on the - condition being tested, should also use the above mechanism. - *Note Jump Patterns:: - - The above discussion also applies to `sCOND' patterns. - -`call' - Subroutine call instruction returning no value. Operand 0 is the - function to call; operand 1 is the number of bytes of arguments - pushed (in mode `SImode', except it is normally a `const_int'); - operand 2 is the number of registers used as operands. - - On most machines, operand 2 is not actually stored into the RTL - pattern. It is supplied for the sake of some RISC machines which - need to put this information into the assembler code; they can - put it in the RTL instead of operand 1. - - Operand 0 should be a `mem' RTX whose address is the address of - the function. Note, however, that this address can be a - `symbol_ref' expression even if it would not be a legitimate - memory address on the target machine. If it is also not a valid - argument for a call instruction, the pattern for this operation - should be a `define_expand' (*note Expander Definitions::.) that - places the address into a register and uses that register in the - call instruction. - -`call_value' - Subroutine call instruction returning a value. Operand 0 is the - hard register in which the value is returned. There are three - more operands, the same as the three operands of the `call' - instruction (but with numbers increased by one). - - Subroutines that return `BLKmode' objects use the `call' insn. - -`call_pop', `call_value_pop' - Similar to `call' and `call_value', except used if defined and if - `RETURN_POPS_ARGS' is non-zero. They should emit a `parallel' - that contains both the function call and a `set' to indicate the - adjustment made to the frame pointer. - - For machines where `RETURN_POPS_ARGS' can be non-zero, the use of - these patterns increases the number of functions for which the - frame pointer can be eliminated, if desired. - -`return' - Subroutine return instruction. This instruction pattern name - should be defined only if a single instruction can do all the - work of returning from a function. - - Like the `movM' patterns, this pattern is also used after the RTL - generation phase. In this case it is to support machines where - multiple instructions are usually needed to return from a - function, but some class of functions only requires one - instruction to implement a return. Normally, the applicable - functions are those which do not need to save any registers or - allocate stack space. - - For such machines, the condition specified in this pattern should - only be true when `reload_completed' is non-zero and the - function's epilogue would only be a single instruction. For - machines with register windows, the routine `leaf_function_p' may - be used to determine if a register window push is required. - - Machines that have conditional return instructions should define - patterns such as - - (define_insn "" - [(set (pc) - (if_then_else (match_operator 0 "comparison_operator" - [(cc0) (const_int 0)]) - (return) - (pc)))] - "CONDITION" - "...") - - where CONDITION would normally be the same condition specified on - the named `return' pattern. - -`nop' - No-op instruction. This instruction pattern name should always - be defined to output a no-op in assembler code. `(const_int 0)' - will do as an RTL pattern. - -`indirect_jump' - An instruction to jump to an address which is operand zero. This - pattern name is mandatory on all machines. - -`casesi' - Instruction to jump through a dispatch table, including bounds - checking. This instruction takes five operands: - - 1. The index to dispatch on, which has mode `SImode'. - - 2. The lower bound for indices in the table, an integer - constant. - - 3. The total range of indices in the table--the largest index - minus the smallest one (both inclusive). - - 4. A label that precedes the table itself. - - 5. A label to jump to if the index has a value outside the - bounds. (If the machine-description macro - `CASE_DROPS_THROUGH' is defined, then an out-of-bounds index - drops through to the code following the jump table instead - of jumping to this label. In that case, this label is not - actually used by the `casesi' instruction, but it is always - provided as an operand.) - - The table is a `addr_vec' or `addr_diff_vec' inside of a - `jump_insn'. The number of elements in the table is one plus the - difference between the upper bound and the lower bound. - -`tablejump' - Instruction to jump to a variable address. This is a low-level - capability which can be used to implement a dispatch table when - there is no `casesi' pattern. - - This pattern requires two operands: the address or offset, and a - label which should immediately precede the jump table. If the - macro `CASE_VECTOR_PC_RELATIVE' is defined then the first operand - is an offset which counts from the address of the table; - otherwise, it is an absolute address to jump to. - - The `tablejump' insn is always the last insn before the jump - table it uses. Its assembler code normally has no need to use the - second operand, but you should incorporate it in the RTL pattern - so that the jump optimizer will not delete the table as - unreachable code. + RTL uses five kinds of objects: expressions, integers, wide integers, +strings and vectors. Expressions are the most important ones. An RTL +expression ("RTX", for short) is a C structure, but it is usually +referred to with a pointer; a type that is given the typedef name `rtx'. + + An integer is simply an `int'; their written form uses decimal +digits. A wide integer is an integral object whose type is +`HOST_WIDE_INT' (*note Config::.); their written form uses decimal +digits. + + A string is a sequence of characters. In core it is represented as a +`char *' in usual C fashion, and it is written in C syntax as well. +However, strings in RTL may never be null. If you write an empty +string in a machine description, it is represented in core as a null +pointer rather than as a pointer to a null character. In certain +contexts, these null pointers instead of strings are valid. Within RTL +code, strings are most commonly found inside `symbol_ref' expressions, +but they appear in other contexts in the RTL expressions that make up +machine descriptions. + + A vector contains an arbitrary number of pointers to expressions. +The number of elements in the vector is explicitly present in the +vector. The written form of a vector consists of square brackets +(`[...]') surrounding the elements, in sequence and with whitespace +separating them. Vectors of length zero are not created; null pointers +are used instead. + + Expressions are classified by "expression codes" (also called RTX +codes). The expression code is a name defined in `rtl.def', which is +also (in upper case) a C enumeration constant. The possible expression +codes and their meanings are machine-independent. The code of an RTX +can be extracted with the macro `GET_CODE (X)' and altered with +`PUT_CODE (X, NEWCODE)'. + + The expression code determines how many operands the expression +contains, and what kinds of objects they are. In RTL, unlike Lisp, you +cannot tell by looking at an operand what kind of object it is. +Instead, you must know from its context--from the expression code of +the containing expression. For example, in an expression of code +`subreg', the first operand is to be regarded as an expression and the +second operand as an integer. In an expression of code `plus', there +are two operands, both of which are to be regarded as expressions. In +a `symbol_ref' expression, there is one operand, which is to be +regarded as a string. + + Expressions are written as parentheses containing the name of the +expression type, its flags and machine mode if any, and then the +operands of the expression (separated by spaces). + + Expression code names in the `md' file are written in lower case, +but when they appear in C code they are written in upper case. In this +manual, they are shown as follows: `const_int'. + + In a few contexts a null pointer is valid where an expression is +normally wanted. The written form of this is `(nil)'.  -File: gcc.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc +File: gcc.info, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL -When the Order of Patterns Matters -================================== +Access to Operands +================== - Sometimes an insn can match more than one instruction pattern. -Then the pattern that appears first in the machine description is the -one used. Therefore, more specific patterns (patterns that will match -fewer things) and faster instructions (those that will produce better -code when they do match) should usually go first in the description. - - In some cases the effect of ordering the patterns can be used to -hide a pattern when it is not valid. For example, the 68000 has an -instruction for converting a fullword to floating point and another -for converting a byte to floating point. An instruction converting an -integer to floating point could match either one. We put the pattern -to convert the fullword first to make sure that one will be used -rather than the other. (Otherwise a large integer might be generated -as a single-byte immediate quantity, which would not work.) Instead of -using this pattern ordering it would be possible to make the pattern -for convert-a-byte smart enough to deal properly with any constant -value. + For each expression type `rtl.def' specifies the number of contained +objects and their kinds, with four possibilities: `e' for expression +(actually a pointer to an expression), `i' for integer, `w' for wide +integer, `s' for string, and `E' for vector of expressions. The +sequence of letters for an expression code is called its "format". +Thus, the format of `subreg' is `ei'. + + A few other format characters are used occasionally: + +`u' + `u' is equivalent to `e' except that it is printed differently in + debugging dumps. It is used for pointers to insns. - -File: gcc.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc - -Interdependence of Patterns -=========================== +`n' + `n' is equivalent to `i' except that it is printed differently in + debugging dumps. It is used for the line number or code number of + a `note' insn. + +`S' + `S' indicates a string which is optional. In the RTL objects in + core, `S' is equivalent to `s', but when the object is read, from + an `md' file, the string value of this operand may be omitted. An + omitted string is taken to be the null string. - Every machine description must have a named pattern for each of the -conditional branch names `bCOND'. The recognition template must -always have the form - - (set (pc) - (if_then_else (COND (cc0) (const_int 0)) - (label_ref (match_operand 0 "" "")) - (pc))) - -In addition, every machine description must have an anonymous pattern -for each of the possible reverse-conditional branches. Their templates -look like - - (set (pc) - (if_then_else (COND (cc0) (const_int 0)) - (pc) - (label_ref (match_operand 0 "" "")))) - -They are necessary because jump optimization can turn -direct-conditional branches into reverse-conditional branches. - - It is often convenient to use the `match_operator' construct to -reduce the number of patterns that must be specified for branches. For -example, - - (define_insn "" - [(set (pc) - (if_then_else (match_operator 0 "comparison_operator" - [(cc0) (const_int 0)]) - (pc) - (label_ref (match_operand 1 "" ""))))] - "CONDITION" - "...") - - In some cases machines support instructions identical except for the -machine mode of one or more operands. For example, there may be -"sign-extend halfword" and "sign-extend byte" instructions whose -patterns are - - (set (match_operand:SI 0 ...) - (extend:SI (match_operand:HI 1 ...))) - - (set (match_operand:SI 0 ...) - (extend:SI (match_operand:QI 1 ...))) - -Constant integers do not specify a machine mode, so an instruction to -extend a constant value could match either pattern. The pattern it -actually will match is the one that appears first in the file. For -correct results, this must be the one for the widest possible mode -(`HImode', here). If the pattern matches the `QImode' instruction, -the results will be incorrect if the constant value does not actually -fit that mode. - - Such instructions to extend constants are rarely generated because -they are optimized away, but they do occasionally happen in -nonoptimized compilations. - - If a constraint in a pattern allows a constant, the reload pass may -replace a register with a constant permitted by the constraint in some -cases. Similarly for memory references. You must ensure that the -predicate permits all objects allowed by the constraints to prevent the -compiler from crashing. - - Because of this substitution, you should not provide separate -patterns for increment and decrement instructions. Instead, they -should be generated from the same pattern that supports -register-register add insns by examining the operands and generating -the appropriate machine instruction. +`V' + `V' indicates a vector which is optional. In the RTL objects in + core, `V' is equivalent to `E', but when the object is read from + an `md' file, the vector value of this operand may be omitted. An + omitted vector is effectively the same as a vector of no elements. + +`0' + `0' means a slot whose contents do not fit any normal category. + `0' slots are not printed at all in dumps, and are often used in + special ways by small parts of the compiler. + + There are macros to get the number of operands, the format, and the +class of an expression code: + +`GET_RTX_LENGTH (CODE)' + Number of operands of an RTX of code CODE. + +`GET_RTX_FORMAT (CODE)' + The format of an RTX of code CODE, as a C string. + +`GET_RTX_CLASS (CODE)' + A single character representing the type of RTX operation that code + CODE performs. + + The following classes are defined: + + `o' + An RTX code that represents an actual object, such as `reg' or + `mem'. `subreg' is not in this class. + + `<' + An RTX code for a comparison. The codes in this class are + `NE', `EQ', `LE', `LT', `GE', `GT', `LEU', `LTU', `GEU', + `GTU'. + + `1' + An RTX code for a unary arithmetic operation, such as `neg'. + + `c' + An RTX code for a commutative binary operation, other than + `NE' and `EQ' (which have class `<'). + + `2' + An RTX code for a noncommutative binary operation, such as + `MINUS'. + + `b' + An RTX code for a bitfield operation, either `ZERO_EXTRACT' or + `SIGN_EXTRACT'. + + `3' + An RTX code for other three input operations, such as + `IF_THEN_ELSE'. + + `i' + An RTX code for a machine insn (`INSN', `JUMP_INSN', and + `CALL_INSN'). + + `m' + An RTX code for something that matches in insns, such as + `MATCH_DUP'. + + `x' + All other RTX codes. + + Operands of expressions are accessed using the macros `XEXP', +`XINT', `XWINT' and `XSTR'. Each of these macros takes two arguments: +an expression-pointer (RTX) and an operand number (counting from zero). +Thus, + + XEXP (X, 2) + +accesses operand 2 of expression X, as an expression. + + XINT (X, 2) + +accesses the same operand as an integer. `XSTR', used in the same +fashion, would access it as a string. + + Any operand can be accessed as an integer, as an expression or as a +string. You must choose the correct method of access for the kind of +value actually stored in the operand. You would do this based on the +expression code of the containing expression. That is also how you +would know how many operands there are. + + For example, if X is a `subreg' expression, you know that it has two +operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X, +1)'. If you did `XINT (X, 0)', you would get the address of the +expression operand but cast as an integer; that might occasionally be +useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP +(X, 1)' would also compile without error, and would return the second, +integer operand cast as an expression pointer, which would probably +result in a crash when accessed. Nothing stops you from writing `XEXP +(X, 28)' either, but this will access memory past the end of the +expression with unpredictable results. + + Access to operands which are vectors is more complicated. You can +use the macro `XVEC' to get the vector-pointer itself, or the macros +`XVECEXP' and `XVECLEN' to access the elements and length of a vector. + +`XVEC (EXP, IDX)' + Access the vector-pointer which is operand number IDX in EXP. + +`XVECLEN (EXP, IDX)' + Access the length (number of elements) in the vector which is in + operand number IDX in EXP. This value is an `int'. + +`XVECEXP (EXP, IDX, ELTNUM)' + Access element number ELTNUM in the vector which is in operand + number IDX in EXP. This value is an RTX. + + It is up to you to make sure that ELTNUM is not negative and is + less than `XVECLEN (EXP, IDX)'. + + All the macros defined in this section expand into lvalues and +therefore can be used to assign the operands, lengths and vector +elements as well as to access them.  -File: gcc.info, Node: Jump Patterns, Next: Insn Canonicalizations, Prev: Dependent Patterns, Up: Machine Desc - -Defining Jump Instruction Patterns -================================== +File: gcc.info, Node: Flags, Next: Machine Modes, Prev: Accessors, Up: RTL - For most machines, GNU CC assumes that the machine has a condition -code. A comparison insn sets the condition code, recording the -results of both signed and unsigned comparison of the given operands. -A separate branch insn tests the condition code and branches or not -according its value. The branch insns come in distinct signed and -unsigned flavors. Many common machines, such as the Vax, the 68000 -and the 32000, work this way. - - Some machines have distinct signed and unsigned compare -instructions, and only one set of conditional branch instructions. -The easiest way to handle these machines is to treat them just like -the others until the final stage where assembly code is written. At -this time, when outputting code for the compare instruction, peek -ahead at the following branch using `next_cc0_user (insn)'. (The -variable `insn' refers to the insn being output, in the output-writing -code in an instruction pattern.) If the RTL says that is an unsigned -branch, output an unsigned compare; otherwise output a signed compare. - When the branch itself is output, you can treat signed and unsigned -branches identically. - - The reason you can do this is that GNU CC always generates a pair of -consecutive RTL insns, possibly separated by `note' insns, one to set -the condition code and one to test it, and keeps the pair inviolate -until the end. - - To go with this technique, you must define the machine-description -macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no -compare instruction is superfluous. - - Some machines have compare-and-branch instructions and no condition -code. A similar technique works for them. When it is time to -"output" a compare instruction, record its operands in two static -variables. When outputting the branch-on-condition-code instruction -that follows, actually output a compare-and-branch instruction that -uses the remembered operands. - - It also works to define patterns for compare-and-branch -instructions. In optimizing compilation, the pair of compare and -branch instructions will be combined according to these patterns. But -this does not happen if optimization is not requested. So you must -use one of the solutions above in addition to any special patterns you -define. - - In many RISC machines, most instructions do not affect the condition -code and there may not even be a separate condition code register. On -these machines, the restriction that the definition and use of the -condition code be adjacent insns is not necessary and can prevent -important optimizations. For example, on the IBM RS/6000, there is a -delay for taken branches unless the condition code register is set -three instructions earlier than the conditional branch. The -instruction scheduler cannot perform this optimization if it is not -permitted to separate the definition and use of the condition code -register. - - On these machines, do not use `(cc0)', but instead use a register -to represent the condition code. If there is a specific condition code -register in the machine, use a hard register. If the condition code or -comparison result can be placed in any general register, or if there -are multiple condition registers, use a pseudo register. - - On some machines, the type of branch instruction generated may -depend on the way the condition code was produced; for example, on the -68k and Sparc, setting the condition code directly from an add or -subtract instruction does not clear the overflow bit the way that a -test instruction does, so a different branch instruction must be used -for some conditional branches. For machines that use `(cc0)', the set -and use of the condition code must be adjacent (separated only by -`note' insns) allowing flags in `cc_status' to be used. (*Note -Condition Code::.) Also, the comparison and branch insns can be -located from each other by using the functions `prev_cc0_setter' and -`next_cc0_user'. - - However, this is not true on machines that do not use `(cc0)'. On -those machines, no assumptions can be made about the adjacency of the -compare and branch insns and the above methods cannot be used. -Instead, we use the machine mode of the condition code register to -record different formats of the condition code register. - - Registers used to store the condition code value should have a mode -that is in class `MODE_CC'. Normally, it will be `CCmode'. If -additional modes are required (as for the add example mentioned above -in the Sparc), define the macro `EXTRA_CC_MODES' to list the -additional modes required (*note Condition Code::.). Also define -`EXTRA_CC_NAMES' to list the names of those modes and `SELECT_CC_MODE' -to choose a mode given an operand of a compare. - - If it is known during RTL generation that a different mode will be -required (for example, if the machine has separate compare instructions -for signed and unsigned quantities, like most IBM processors), they can -be specified at that time. - - If the cases that require different modes would be made by -instruction combination, the macro `SELECT_CC_MODE' determines which -machine mode should be used for the comparison result. The patterns -should be written using that mode. To support the case of the add on -the Sparc discussed above, we have the pattern - - (define_insn "" - [(set (reg:CC_NOOV 0) - (compare:CC_NOOV (plus:SI (match_operand:SI 0 "register_operand" "%r") - (match_operand:SI 1 "arith_operand" "rI")) - (const_int 0)))] - "" - "...") +Flags in an RTL Expression +========================== - The `SELECT_CC_MODE' macro on the Sparc returns `CC_NOOVmode' for -comparisons whose argument is a `plus'. + RTL expressions contain several flags (one-bit bitfields) that are +used in certain types of expression. Most often they are accessed with +the following macros: + +`MEM_VOLATILE_P (X)' + In `mem' expressions, nonzero for volatile memory references. + Stored in the `volatil' field and printed as `/v'. + +`MEM_IN_STRUCT_P (X)' + In `mem' expressions, nonzero for reference to an entire + structure, union or array, or to a component of one. Zero for + references to a scalar variable or through a pointer to a scalar. + Stored in the `in_struct' field and printed as `/s'. + +`REG_LOOP_TEST_P' + In `reg' expressions, nonzero if this register's entire life is + contained in the exit test code for some loop. Stored in the + `in_struct' field and printed as `/s'. + +`REG_USERVAR_P (X)' + In a `reg', nonzero if it corresponds to a variable present in the + user's source code. Zero for temporaries generated internally by + the compiler. Stored in the `volatil' field and printed as `/v'. + +`REG_FUNCTION_VALUE_P (X)' + Nonzero in a `reg' if it is the place in which this function's + value is going to be returned. (This happens only in a hard + register.) Stored in the `integrated' field and printed as `/i'. + + The same hard register may be used also for collecting the values + of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero + in this kind of use. + +`SUBREG_PROMOTED_VAR_P' + Nonzero in a `subreg' if it was made when accessing an object that + was promoted to a wider mode in accord with the `PROMOTED_MODE' + machine description macro (*note Storage Layout::.). In this + case, the mode of the `subreg' is the declared mode of the object + and the mode of `SUBREG_REG' is the mode of the register that + holds the object. Promoted variables are always either sign- or + zero-extended to the wider mode on every assignment. Stored in + the `in_struct' field and printed as `/s'. + +`SUBREG_PROMOTED_UNSIGNED_P' + Nonzero in a `subreg' that has `SUBREG_PROMOTED_VAR_P' nonzero if + the object being referenced is kept zero-extended and zero if it + is kept sign-extended. Stored in the `unchanging' field and + printed as `/u'. + +`RTX_UNCHANGING_P (X)' + Nonzero in a `reg' or `mem' if the value is not changed. (This + flag is not set for memory references via pointers to constants. + Such pointers only guarantee that the object will not be changed + explicitly by the current function. The object might be changed by + other functions or by aliasing.) Stored in the `unchanging' field + and printed as `/u'. + +`RTX_INTEGRATED_P (INSN)' + Nonzero in an insn if it resulted from an in-line function call. + Stored in the `integrated' field and printed as `/i'. This may be + deleted; nothing currently depends on it. + +`SYMBOL_REF_USED (X)' + In a `symbol_ref', indicates that X has been used. This is + normally only used to ensure that X is only declared external + once. Stored in the `used' field. + +`SYMBOL_REF_FLAG (X)' + In a `symbol_ref', this is used as a flag for machine-specific + purposes. Stored in the `volatil' field and printed as `/v'. + +`LABEL_OUTSIDE_LOOP_P' + In `label_ref' expressions, nonzero if this is a reference to a + label that is outside the innermost loop containing the reference + to the label. Stored in the `in_struct' field and printed as `/s'. + +`INSN_DELETED_P (INSN)' + In an insn, nonzero if the insn has been deleted. Stored in the + `volatil' field and printed as `/v'. + +`INSN_ANNULLED_BRANCH_P (INSN)' + In an `insn' in the delay slot of a branch insn, indicates that an + annulling branch should be used. See the discussion under + `sequence' below. Stored in the `unchanging' field and printed as + `/u'. + +`INSN_FROM_TARGET_P (INSN)' + In an `insn' in a delay slot of a branch, indicates that the insn + is from the target of the branch. If the branch insn has + `INSN_ANNULLED_BRANCH_P' set, this insn should only be executed if + the branch is taken. For annulled branches with this bit clear, + the insn should be executed only if the branch is not taken. + Stored in the `in_struct' field and printed as `/s'. + +`CONSTANT_POOL_ADDRESS_P (X)' + Nonzero in a `symbol_ref' if it refers to part of the current + function's "constants pool". These are addresses close to the + beginning of the function, and GNU CC assumes they can be addressed + directly (perhaps with the help of base registers). Stored in the + `unchanging' field and printed as `/u'. + +`CONST_CALL_P (X)' + In a `call_insn', indicates that the insn represents a call to a + const function. Stored in the `unchanging' field and printed as + `/u'. + +`LABEL_PRESERVE_P (X)' + In a `code_label', indicates that the label can never be deleted. + Labels referenced by a non-local goto will have this bit set. + Stored in the `in_struct' field and printed as `/s'. + +`SCHED_GROUP_P (INSN)' + During instruction scheduling, in an insn, indicates that the + previous insn must be scheduled together with this insn. This is + used to ensure that certain groups of instructions will not be + split up by the instruction scheduling pass, for example, `use' + insns before a `call_insn' may not be separated from the + `call_insn'. Stored in the `in_struct' field and printed as `/s'. + + These are the fields which the above macros refer to: + +`used' + Normally, this flag is used only momentarily, at the end of RTL + generation for a function, to count the number of times an + expression appears in insns. Expressions that appear more than + once are copied, according to the rules for shared structure + (*note Sharing::.). + + In a `symbol_ref', it indicates that an external declaration for + the symbol has already been written. + + In a `reg', it is used by the leaf register renumbering code to + ensure that each register is only renumbered once. + +`volatil' + This flag is used in `mem', `symbol_ref' and `reg' expressions and + in insns. In RTL dump files, it is printed as `/v'. + + In a `mem' expression, it is 1 if the memory reference is volatile. + Volatile memory references may not be deleted, reordered or + combined. + + In a `symbol_ref' expression, it is used for machine-specific + purposes. + + In a `reg' expression, it is 1 if the value is a user-level + variable. 0 indicates an internal compiler temporary. + + In an insn, 1 means the insn has been deleted. + +`in_struct' + In `mem' expressions, it is 1 if the memory datum referred to is + all or part of a structure or array; 0 if it is (or might be) a + scalar variable. A reference through a C pointer has 0 because + the pointer might point to a scalar variable. This information + allows the compiler to determine something about possible cases of + aliasing. + + In an insn in the delay slot of a branch, 1 means that this insn + is from the target of the branch. + + During instruction scheduling, in an insn, 1 means that this insn + must be scheduled as part of a group together with the previous + insn. + + In `reg' expressions, it is 1 if the register has its entire life + contained within the test expression of some loop. + + In `subreg' expressions, 1 means that the `subreg' is accessing an + object that has had its mode promoted from a wider mode. + + In `label_ref' expressions, 1 means that the referenced label is + outside the innermost loop containing the insn in which the + `label_ref' was found. + + In `code_label' expressions, it is 1 if the label may never be + deleted. This is used for labels which are the target of + non-local gotos. + + In an RTL dump, this flag is represented as `/s'. + +`unchanging' + In `reg' and `mem' expressions, 1 means that the value of the + expression never changes. + + In `subreg' expressions, it is 1 if the `subreg' references an + unsigned object whose mode has been promoted to a wider mode. + + In an insn, 1 means that this is an annulling branch. + + In a `symbol_ref' expression, 1 means that this symbol addresses + something in the per-function constants pool. + + In a `call_insn', 1 means that this instruction is a call to a + const function. + + In an RTL dump, this flag is represented as `/u'. + +`integrated' + In some kinds of expressions, including insns, this flag means the + rtl was produced by procedure integration. + + In a `reg' expression, this flag indicates the register containing + the value to be returned by the current function. On machines + that pass parameters in registers, the same register number may be + used for parameters as well, but this flag is not set on such uses. - \ No newline at end of file