--- gcc/internals-3 2018/04/24 16:38:32 1.1.1.2 +++ gcc/internals-3 2018/04/24 16:39:27 1.1.1.3 @@ -1,31 +1,345 @@ -Info file internals, produced by Makeinfo, -*- Text -*- -from input file internals.texinfo. + +File: internals, Node: Passes, Next: RTL, Prev: Interface, Up: Top + +Passes and Files of the Compiler +******************************** +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, remains 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 the function `rest_of_compilation' or +`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 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. + + C 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 associative-law simplifications are also done + during this pass. + + The source files for parsing are `parse.y', `decl.c', `typecheck.c', + `stor-layout.c', `fold-const.c', and `tree.c'. The last three are + intended to be language-independent. There are also header files + `parse.h', `c-tree.h', `tree.h' and `tree.def'. The last two define + the format of the tree representation. + + * 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 are `stmt.c', `expr.c', + `explow.c', `expmed.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 files `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 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.) + + 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'. + + * 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. + Its source file is `loop.c'. + + 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. + + * 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. + + * 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-alloc.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. + + 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. + + * Jump optimization is repeated, this time including cross-jumping and + deletion of no-op move instructions. Machine-specific peephole + optimizations are performed at the same time. + + 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. + + * Final. This pass outputs the assembler code for the function. It is + also responsible for identifying spurious test and compare + instructions. 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 and `symout.c' for GDB's own symbol table format. + +Some additional files are used by all or many passes: + + * Every pass uses `machmode.def', which defines the machine modes. + + * 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. -This file documents the internals of the GNU compiler. + +File: internals, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top -Copyright (C) 1988 Free Software Foundation, Inc. +RTL Representation +****************** -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. +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 bit-fields 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. -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 CC 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. -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 CC General Public License'' and -this permission notice may be included in translations approved by the -Free Software Foundation instead of in the original English. + +File: internals, Node: RTL Objects, Next: Accessors, Prev: RTL, Up: RTL +RTL Object Types +================ +RTL uses four kinds of objects: expressions, 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', and a string is a `char *'. Within RTL +code, strings appear only inside `symbol_ref' expressions, but they appear +in other contexts in the RTL expressions that make up machine descriptions. + 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. + +A vector contains an arbitrary, specified 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: internals, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL @@ -60,12 +374,10 @@ Operands of expressions are accessed usi 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. @@ -295,7 +607,6 @@ The simplest RTL expressions are those t u.i[0] = XINT (x, 0); u.i[1] = XINT (x, 1); - and then refer to `u.d'. The value of the constant is represented as a double in this fashion even if the value represented is single-precision. @@ -682,7 +993,6 @@ conversion operation, as in (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) - The conversion operation is not a mere placeholder, because there may be more than one way of converting from a given starting mode to the desired final mode. The conversion operation code says how to do it. @@ -756,491 +1066,4 @@ rather state assertions about their oper undefined effects on the rest of the register when M is less than a word. - -File: internals, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL - -Side Effect Expressions -======================= - -The expression codes described so far represent values, not actions. But -machine instructions never produce values; they are meaningful only for -their side effects on the state of the machine. Special expression codes -are used to represent side effects. - -The body of an instruction is always one of these side effect codes; the -codes described above, which represent values, appear only as the operands -of these. - -`(set LVAL X)' - Represents the action of storing the value of X into the place - represented by LVAL. LVAL must be an expression representing a place - that can be stored in: `reg' (or `subreg' or `strict_low_part'), - `mem', `pc' or `cc0'. - - If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then X - must be valid for that mode. - - If LVAL is a `reg' whose machine mode is less than the full width of - the register, then it means that the part of the register specified by - the machine mode is given the specified value and the rest of the - register receives an undefined value. Likewise, if LVAL is a `subreg' - whose machine mode is narrower than `SImode', the rest of the register - can be changed in an undefined way. - - If LVAL is a `strict_low_part' of a `subreg', then the part of the - register specified by the machine mode of the `subreg' is given the - value X and the rest of the register is not changed. - - If LVAL is `(cc0)', it has no machine mode, and X may have any mode. - This represents a ``test'' or ``compare'' instruction. - - If LVAL is `(pc)', we have a jump instruction, and the possibilities - for X are very limited. It may be a `label_ref' expression - (unconditional jump). It may be an `if_then_else' (conditional jump), - in which case either the second or the third operand must be `(pc)' - (for the case which does not jump) and the other of the two must be a - `label_ref' (for the case which does jump). X may also be a `mem' or - `(plus:SI (pc) Y)', where Y may be a `reg' or a `mem'; these unusual - patterns are used to represent jumps through branch tables. - -`(return)' - Represents a return from the current function, on machines where this - can be done with one instruction, such as Vaxes. On machines where a - multi-instruction ``epilogue'' must be executed in order to return - from the function, returning is done by jumping to a label which - precedes the epilogue, and the `return' expression code is never used. - -`(call FUNCTION NARGS)' - Represents a function call. FUNCTION is a `mem' expression whose - address is the address of the function to be called. NARGS is an - expression representing the number of words of argument. - - Each machine has a standard machine mode which FUNCTION must have. - The machine description defines macro `FUNCTION_MODE' to expand into - the requisite mode name. The purpose of this mode is to specify what - kind of addressing is allowed, on machines where the allowed kinds of - addressing depend on the machine mode being addressed. - -`(clobber X)' - Represents the storing or possible storing of an unpredictable, - undescribed value into X, which must be a `reg' or `mem' expression. - - One place this is used is in string instructions that store standard - values into particular hard registers. It may not be worth the - trouble to describe the values that are stored, but it is essential to - inform the compiler that the registers will be altered, lest it - attempt to keep data in them across the string instruction. - - X may also be null---a null C pointer, no expression at all. Such a - `(clobber (null))' expression means that all memory locations must be - presumed clobbered. - - Note that the machine description classifies certain hard registers as - ``call-clobbered''. All function call instructions are assumed by - default to clobber these registers, so there is no need to use - `clobber' expressions to indicate this fact. Also, each function call - is assumed to have the potential to alter any memory location. - -`(use X)' - Represents the use of the value of X. It indicates that the value in - X at this point in the program is needed, even though it may not be - apparent why this is so. Therefore, the compiler will not attempt to - delete instructions whose only effect is to store a value in X. X - must be a `reg' expression. - -`(parallel [X0 X1 ...])' - Represents several side effects performed in parallel. The square - brackets stand for a vector; the operand of `parallel' is a vector of - expressions. X0, X1 and so on are individual side - effects---expressions of code `set', `call', `return', `clobber' or - `use'. - - ``In parallel'' means that first all the values used in the individual - side-effects are computed, and second all the actual side-effects are - performed. For example, - - (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) - (set (mem:SI (reg:SI 1)) (reg:SI 1))]) - - - says unambiguously that the values of hard register 1 and the memory - location addressed by it are interchanged. In both places where - `(reg:SI 1)' appears as a memory address it refers to the value in - register 1 *before* the execution of the instruction. - -`(sequence [INSNS ...])' - Represents a sequence of insns. Each of the INSNS that appears in the - vector is suitable for appearing in the chain of insns, so it must be - an `insn', `jump_insn', `call_insn', `code_label', `barrier' or `note'. - - A `sequence' RTX never appears in an actual insn. It represents the - sequence of insns that result from a `define_expand' *before* those - insns are passed to `emit_insn' to insert them in the chain of insns. - When actually inserted, the individual sub-insns are separated out and - the `sequence' is forgotten. - -Three expression codes appear in place of a side effect, as the body of an -insn, though strictly speaking they do not describe side effects as such: - -`(asm_input S)' - Represents literal assembler code as described by the string S. - -`(addr_vec:M [LR0 LR1 ...])' - Represents a table of jump addresses. The vector elements LR0, etc., - are `label_ref' expressions. The mode M specifies how much space is - given to each address; normally M would be `Pmode'. - -`(addr_diff_vec:M BASE [LR0 LR1 ...])' - Represents a table of jump addresses expressed as offsets from BASE. - The vector elements LR0, etc., are `label_ref' expressions and so is - BASE. The mode M specifies how much space is given to each - address-difference. - - -File: internals, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL - -Embedded Side-Effects on Addresses -================================== - -Four special side-effect expression codes appear as memory addresses. - -`(pre_dec:M X)' - Represents the side effect of decrementing X by a standard amount and - represents also the value that X has after being decremented. X must - be a `reg' or `mem', but most machines allow only a `reg'. M must be - the machine mode for pointers on the machine in use. The amount X is - decremented by is the length in bytes of the machine mode of the - containing memory reference of which this expression serves as the - address. Here is an example of its use: - - (mem:DF (pre_dec:SI (reg:SI 39))) - - - This says to decrement pseudo register 39 by the length of a `DFmode' - value and use the result to address a `DFmode' value. - -`(pre_inc:M X)' - Similar, but specifies incrementing X instead of decrementing it. - -`(post_dec:M X)' - Represents the same side effect as `pre_decrement' but a different - value. The value represented here is the value X has before being - decremented. - -`(post_inc:M X)' - Similar, but specifies incrementing X instead of decrementing it. - -These embedded side effect expressions must be used with care. Instruction -patterns may not use them. Until the `flow' pass of the compiler, they may -occur only to represent pushes onto the stack. The `flow' pass finds cases -where registers are incremented or decremented in one instruction and used -as an address shortly before or after; these cases are then transformed to -use pre- or post-increment or -decrement. - -Explicit popping of the stack could be represented with these embedded side -effect operators, but that would not be safe; the instruction combination -pass could move the popping past pushes, thus changing the meaning of the -code. - -An instruction that can be represented with an embedded side effect could -also be represented using `parallel' containing an additional `set' to -describe how the address register is altered. This is not done because -machines that allow these operations at all typically allow them wherever a -memory address is called for. Describing them as additional parallel -stores would require doubling the number of entries in the machine -description. - - -File: internals, Node: Assembler, Next: Insns, Prev: IncDec, Up: RTL - -Assembler Instructions as Expressions -===================================== - -The RTX code `asm_operands' represents a value produced by a user-specified -assembler instruction. It is used to represent an `asm' statement with -arguments. An `asm' statement with a single output operand, like this: - - asm ("foo %1,%2,%0" : "a" (outputvar) : "g" (x + y), "di" (*z)); - - -is represented using a single `asm_operands' RTX which represents the value -that is stored in `outputvar': - - (set RTX-FOR-OUTPUTVAR - (asm_operands "foo %1,%2,%0" "a" 0 - [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] - [(asm_input:M1 "g") - (asm_input:M2 "di")])) - - -Here the operands of the `asm_operands' RTX are the assembler template -string, the output-operand's constraint, the index-number of the output -operand among the output operands specified, a vector of input operand -RTX's, and a vector of input-operand modes and constraints. The mode M1 is -the mode of the sum `x+y'; M2 is that of `*z'. - -When an `asm' statement has multiple output values, its insn has several -such `set' RTX's inside of a `parallel'. Each `set' contains a -`asm_operands'; all of these share the same assembler template and vectors, -but each contains the constraint for the respective output operand. They -are also distinguished by the output-operand index number, which is 0, 1, -... for successive output operands. - - -File: internals, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL - -Insns -===== - -The RTL representation of the code for a function is a doubly-linked chain -of objects called "insns". Insns are expressions with special codes that -are used for no other purpose. Some insns are actual instructions; others -represent dispatch tables for `switch' statements; others represent labels -to jump to or various sorts of declarative information. - -In addition to its own specific data, each insn must have a unique -id-number that distinguishes it from all other insns in the current -function, and chain pointers to the preceding and following insns. These -three fields occupy the same position in every insn, independent of the -expression code of the insn. They could be accessed with `XEXP' and -`XINT', but instead three special macros are always used: - -`INSN_UID (I)' - Accesses the unique id of insn I. - -`PREV_INSN (I)' - Accesses the chain pointer to the insn preceding I. If I is the first - insn, this is a null pointer. - -`NEXT_INSN (I)' - Accesses the chain pointer to the insn following I. If I is the last - insn, this is a null pointer. - -The `NEXT_INSN' and `PREV_INSN' pointers must always correspond: if I is -not the first insn, - - NEXT_INSN (PREV_INSN (INSN)) == INSN - - -is always true. - -Every insn has one of the following six expression codes: - -`insn' - The expression code `insn' is used for instructions that do not jump - and do not do function calls. Insns with code `insn' have four - additional fields beyond the three mandatory ones listed above. These - four are described in a table below. - -`jump_insn' - The expression code `jump_insn' is used for instructions that may jump - (or, more generally, may contain `label_ref' expressions). - `jump_insn' insns have the same extra fields as `insn' insns, accessed - in the same way. - -`call_insn' - The expression code `call_insn' is used for instructions that may do - function calls. It is important to distinguish these instructions - because they imply that certain registers and memory locations may be - altered unpredictably. - - `call_insn' insns have the same extra fields as `insn' insns, accessed - in the same way. - -`code_label' - A `code_label' insn represents a label that a jump insn can jump to. - It contains one special field of data in addition to the three - standard ones. It is used to hold the "label number", a number that - identifies this label uniquely among all the labels in the compilation - (not just in the current function). Ultimately, the label is - represented in the assembler output as an assembler label `LN' where N - is the label number. - -`barrier' - Barriers are placed in the instruction stream after unconditional jump - instructions to indicate that the jumps are unconditional. They - contain no information beyond the three standard fields. - -`note' - `note' insns are used to represent additional debugging and - declarative information. They contain two nonstandard fields, an - integer which is accessed with the macro `NOTE_LINE_NUMBER' and a - string accessed with `NOTE_SOURCE_FILE'. - - If `NOTE_LINE_NUMBER' is positive, the note represents the position of - a source line and `NOTE_SOURCE_FILE' is the source file name that the - line came from. These notes control generation of line number data in - the assembler output. - - Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a code - with one of the following values (and `NOTE_SOURCE_FILE' must contain - a null pointer): - - `NOTE_INSN_DELETED' - Such a note is completely ignorable. Some passes of the compiler - delete insns by altering them into notes of this kind. - - `NOTE_INSN_BLOCK_BEG' - `NOTE_INSN_BLOCK_END' - These types of notes indicate the position of the beginning and - end of a level of scoping of variable names. They control the - output of debugging information. - - `NOTE_INSN_LOOP_BEG' - `NOTE_INSN_LOOP_END' - These types of notes indicate the position of the beginning and - end of a `while' or `for' loop. They enable the loop optimizer - to find loops quickly. - -Here is a table of the extra fields of `insn', `jump_insn' and `call_insn' -insns: - -`PATTERN (I)' - An expression for the side effect performed by this insn. - -`REG_NOTES (I)' - A list (chain of `expr_list' expressions) giving information about the - usage of registers in this insn. This list is set up by the flow - analysis pass; it is a null pointer until then. - -`LOG_LINKS (I)' - A list (chain of `insn_list' expressions) of previous ``related'' - insns: insns which store into registers values that are used for the - first time in this insn. (An additional constraint is that neither a - jump nor a label may come between the related insns). This list is - set up by the flow analysis pass; it is a null pointer until then. - -`INSN_CODE (I)' - An integer that says which pattern in the machine description matches - this insn, or -1 if the matching has not yet been attempted. - - Such matching is never attempted and this field is not used on an insn - whose pattern consists of a single `use', `clobber', `asm', `addr_vec' - or `addr_diff_vec' expression. - -The `LOG_LINKS' field of an insn is a chain of `insn_list' expressions. -Each of these has two operands: the first is an insn, and the second is -another `insn_list' expression (the next one in the chain). The last -`insn_list' in the chain has a null pointer as second operand. The -significant thing about the chain is which insns appear in it (as first -operands of `insn_list' expressions). Their order is not significant. - -The `REG_NOTES' field of an insn is a similar chain but of `expr_list' -expressions instead of `insn_list'. There are four kinds of register -notes, which are distinguished by the machine mode of the `expr_list', -which a register note is really understood as being an `enum reg_note'. -The first operand OP of the `expr_list' is data whose meaning depends on -the kind of note. Here are the four kinds: - -`REG_DEAD' - The register OP dies in this insn; that is to say, altering the value - immediately after this insn would not affect the future behavior of - the program. - -`REG_INC' - The register OP is incremented (or decremented; at this level there is - no distinction) by an embedded side effect inside this insn. This - means it appears in a `POST_INC', `PRE_INC', `POST_DEC' or `PRE_DEC' - RTX. - -`REG_EQUIV' - The register that is set by this insn will be equal to OP at run time, - and could validly be replaced in all its occurrences by OP. - (``Validly'' here refers to the data flow of the program; simple - replacement may make some insns invalid.) - - The value which the insn explicitly copies into the register may look - different from OP, but they will be equal at run time. - - For example, when a constant is loaded into a register that is never - assigned any other value, this kind of note is used. - - When a parameter is copied into a pseudo-register at entry to a - function, a note of this kind records that the register is equivalent - to the stack slot where the parameter was passed. Although in this - case the register may be set by other insns, it is still valid to - replace the register by the stack slot throughout the function. - -`REG_EQUAL' - The register that is set by this insn will be equal to OP at run time - at the end of this insn (but not necessarily elsewhere in the function). - - The RTX OP is typically an arithmetic expression. For example, when a - sequence of insns such as a library call is used to perform an - arithmetic operation, this kind of note is attached to the insn that - produces or copies the final value. It tells the CSE pass how to - think of that value. - -`REG_RETVAL' - This insn copies the value of a library call, and OP is the first insn - that was generated to set up the arguments for the library call. - - Flow analysis uses this note to delete all of a library call whose - result is dead. - -`REG_WAS_0' - The register OP contained zero before this insn. You can rely on this - note if it is present; its absence implies nothing. - -(The only difference between the expression codes `insn_list' and -`expr_list' is that the first operand of an `insn_list' is assumed to be an -insn and is printed in debugging dumps as the insn's unique id; the first -operand of an `expr_list' is printed in the ordinary way as an expression.) - - -File: internals, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL - -RTL Representation of Function-Call Insns -========================================= - -Insns that call subroutines have the RTL expression code `call_insn'. -These insns must satisfy special rules, and their bodies must use a special -RTL expression code, `call'. - -A `call' expression has two operands, as follows: - - (call NBYTES (mem:FM ADDR)) - - -Here NBYTES is an operand that represents the number of bytes of argument -data being passed to the subroutine, FM is a machine mode (which must equal -as the definition of the `FUNCTION_MODE' macro in the machine description) -and ADDR represents the address of the subroutine. - -For a subroutine that returns no value, the `call' RTX as shown above is -the entire body of the insn. - -For a subroutine that returns a value whose mode is not `BLKmode', the -value is returned in a hard register. If this register's number is R, then -the body of the call insn looks like this: - - (set (reg:M R) - (call NBYTES (mem:FM ADDR))) - - -This RTL expression makes it clear (to the optimizer passes) that the -appropriate register receives a useful value in this insn. - -Immediately after RTL generation, if the value of the subroutine is -actually used, this call insn is always followed closely by an insn which -refers to the register R. The following insn has one of two forms. Either -it copies the value into a pseudo-register, like this: - - (set (reg:M P) (reg:M R)) - - -or (in the case where the calling function will simply return whatever -value the call produced, and no operation is needed to do this): - - (use (reg:M R)) - - -Between the call insn and this insn there may intervene only a -stack-adjustment insn (and perhaps some `note' insns). - -When a subroutine returns a `BLKmode' value, it is handled by passing to -the subroutine the address of a place to store the value. So the call insn -itself does not ``return'' any value, and it has the same RTL form as a -call that returns nothing. - - + \ No newline at end of file