--- gcc/gcc.info-14 2018/04/24 17:51:49 1.1.1.2 +++ gcc/gcc.info-14 2018/04/24 18:17:47 1.1.1.7 @@ -1,940 +1,1100 @@ -This is Info file gcc.info, produced by Makeinfo-1.44 from the input +This is Info file gcc.info, produced by Makeinfo-1.55 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, 1994 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," "Funding for +Free Software," 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," "Funding for Free Software," 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: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling +File: gcc.info, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL + +Insns +===== -Function Entry and Exit ------------------------ + 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 (after delayed branch scheduling, copies of an insn with the +same id-number may be present in multiple places in a function, but +these copies will always be identical and will only appear inside a +`sequence'), 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 first insn in the chain is obtained by calling `get_insns'; the +last insn is the result of calling `get_last_insn'. Within the chain +delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must +always correspond: if INSN is not the first insn, + + NEXT_INSN (PREV_INSN (INSN)) == INSN + +is always true and if INSN is not the last insn, + + PREV_INSN (NEXT_INSN (INSN)) == INSN + +is always true. + + After delay slot scheduling, some of the insns in the chain might be +`sequence' expressions, which contain a vector of insns. The value of +`NEXT_INSN' in all but the last of these insns is the next insn in the +vector; the value of `NEXT_INSN' of the last insn in the vector is the +same as the value of `NEXT_INSN' for the `sequence' in which it is +contained. Similar rules apply for `PREV_INSN'. + + This means that the above invariants are not necessarily true for +insns inside `sequence' expressions. Specifically, if INSN is the +first insn in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn +containing the `sequence' expression, as is the value of `PREV_INSN +(NEXT_INSN (INSN))' is INSN is the last insn in the `sequence' +expression. You can use these expressions to find the containing +`sequence' expression. + + 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. `sequence' expressions are + always contained in insns with code `insn' even if one of those + insns should jump or 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). If + there is an instruction to return from the current function, it is + recorded as a `jump_insn'. + + `jump_insn' insns have the same extra fields as `insn' insns, + accessed in the same way and in addition contain a field + `JUMP_LABEL' which is defined once jump optimization has completed. + + For simple conditional and unconditional jumps, this field + contains the `code_label' to which this insn will (possibly + conditionally) branch. In a more complex jump, `JUMP_LABEL' + records one of the labels that the insn refers to; the only way to + find the others is to scan the entire body of the insn. + + Return insns count as jumps, but since they do not refer to any + labels, they have zero in the `JUMP_LABEL' field. + +`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 and in addition contain a field + `CALL_INSN_FUNCTION_USAGE', which contains a list (chain of + `expr_list' expressions) containing `use' and `clobber' + expressions that denote hard registers used or clobbered by the + called function. A register specified in a `clobber' in this list + is modified *after* the execution of the `call_insn', while a + register in a `clobber' in the body of the `call_insn' is + clobbered before the insn completes execution. `clobber' + expressions in this list augment registers specified in + `CALL_USED_REGISTERS' (*note Register Basics::.). + +`code_label' + A `code_label' insn represents a label that a jump insn can jump + to. It contains two special fields of data in addition to the + three standard ones. `CODE_LABEL_NUMBER' 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, usually of the form `LN' where N is + the label number. + + When a `code_label' appears in an RTL expression, it normally + appears within a `label_ref' which represents the address of the + label, as a number. + + The field `LABEL_NUSES' is only defined once the jump optimization + phase is completed and contains the number of times this label is + referenced in the current function. + +`barrier' + Barriers are placed in the instruction stream when control cannot + flow past them. They are placed after unconditional jump + instructions to indicate that the jumps are unconditional and + after calls to `volatile' functions, which do not return (e.g., + `exit'). 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. + + `NOTE_INSN_LOOP_CONT' + Appears at the place in a loop that `continue' statements + jump to. + + `NOTE_INSN_LOOP_VTOP' + This note indicates the place in a loop where the exit test + begins for those loops in which the exit test has been + duplicated. This position becomes another virtual start of + the loop when considering loop invariants. + + `NOTE_INSN_FUNCTION_END' + Appears near the end of the function body, just before the + label that `return' statements jump to (on machine where a + single instruction does not suffice for returning). This + note may be deleted by jump optimization. + + `NOTE_INSN_SETJMP' + Appears following each call to `setjmp' or a related function. + + These codes are printed symbolically when they appear in debugging + dumps. + + The machine mode of an insn is normally `VOIDmode', but some phases +use the mode for various purposes; for example, the reload pass sets it +to `HImode' if the insn needs reloading but not register elimination +and `QImode' if both are required. The common subexpression +elimination pass sets the mode of an insn to `QImode' when it is the +first insn in a block that has already been processed. + + 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. This + must be one of the following codes: `set', `call', `use', + `clobber', `return', `asm_input', `asm_output', `addr_vec', + `addr_diff_vec', `trap_if', `unspec', `unspec_volatile', + `parallel', or `sequence'. If it is a `parallel', each element of + the `parallel' must be one these codes, except that `parallel' + expressions cannot be nested and `addr_vec' and `addr_diff_vec' + are not permitted inside a `parallel' expression. + +`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 remains -1 on an + insn whose pattern consists of a single `use', `clobber', + `asm_input', `addr_vec' or `addr_diff_vec' expression. + + Matching is also never attempted on insns that result from an `asm' + statement. These contain at least one `asm_operands' expression. + The function `asm_noperands' returns a non-negative value for such + insns. + + In the debugging output, this field is printed as a number + followed by a symbolic representation that locates the pattern in + the `md' file as some small positive or negative offset from a + named pattern. + +`LOG_LINKS (I)' + A list (chain of `insn_list' expressions) giving information about + dependencies between instructions within a basic block. Neither a + jump nor a label may come between the related insns. + +`REG_NOTES (I)' + A list (chain of `expr_list' and `insn_list' expressions) giving + miscellaneous information about the insn. It is often information + pertaining to the registers used in this insn. + + 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. + + This list is originally set up by the flow analysis pass; it is a +null pointer until then. Flow only adds links for those data +dependencies which can be used for instruction combination. For each +insn, the flow analysis pass adds a link to insns which store into +registers values that are used for the first time in this insn. The +instruction scheduling pass adds extra links so that every dependence +will be represented. Links represent data dependencies, +antidependencies and output dependencies; the machine mode of the link +distinguishes these three types: antidependencies have mode +`REG_DEP_ANTI', output dependencies have mode `REG_DEP_OUTPUT', and +data dependencies have mode `VOIDmode'. + + The `REG_NOTES' field of an insn is a chain similar to the +`LOG_LINKS' field but it includes `expr_list' expressions in addition +to `insn_list' expressions. There are several kinds of register notes, +which are distinguished by the machine mode, which in a register note +is really understood as being an `enum reg_note'. The first operand OP +of the note is data whose meaning depends on the kind of note. + + The macro `REG_NOTE_KIND (X)' returns the kind of register note. +Its counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' sets the +register note type of X to be NEWKIND. + + Register notes are of three classes: They may say something about an +input to an insn, they may say something about an output of an insn, or +they may create a linkage between two insns. There are also a set of +values that are only used in `LOG_LINKS'. + + These register notes annotate inputs to an insn: + +`REG_DEAD' + The value in 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. + + This does not necessarily mean that the register OP has no useful + value after this insn since it may also be an output of the insn. + In such a case, however, a `REG_DEAD' note would be redundant and + is usually not present until after the reload pass, but no code + relies on this fact. + +`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' expression. + +`REG_NONNEG' + The register OP is known to have a nonnegative value when this + insn is reached. This is used so that decrement and branch until + zero instructions, such as the m68k dbra, can be matched. + + The `REG_NONNEG' note is added to insns only if the machine + description has a `decrement_and_branch_until_zero' pattern. + +`REG_NO_CONFLICT' + This insn does not cause a conflict between OP and the item being + set by this insn even though it might appear that it does. In + other words, if the destination register and OP could otherwise be + assigned the same register, this insn does not prevent that + assignment. + + Insns with this note are usually part of a block that begins with a + `clobber' insn specifying a multi-word pseudo register (which will + be the output of the block), a group of insns that each set one + word of the value and have the `REG_NO_CONFLICT' note attached, + and a final insn that copies the output to itself with an attached + `REG_EQUAL' note giving the expression being computed. This block + is encapsulated with `REG_LIBCALL' and `REG_RETVAL' notes on the + first and last insns, respectively. + +`REG_LABEL' + This insn uses OP, a `code_label', but is not a `jump_insn'. The + presence of this note allows jump optimization to be aware that OP + is, in fact, being used. + + The following notes describe attributes of outputs of an insn: + +`REG_EQUIV' +`REG_EQUAL' + This note is only valid on an insn that sets only one register and + indicates that that register will be equal to OP at run time; the + scope of this equivalence differs between the two types of notes. + The value which the insn explicitly copies into the register may + look different from OP, but they will be equal at run time. If the + output of the single `set' is a `strict_low_part' expression, the + note refers to the register that is contained in `SUBREG_REG' of + the `subreg' expression. + + For `REG_EQUIV', the register is equivalent to OP throughout the + entire function, 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.) 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. + + In the case of `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. In this case, 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. + + These two notes are used in different ways by the compiler passes. + `REG_EQUAL' is used by passes prior to register allocation (such as + common subexpression elimination and loop optimization) to tell + them how to think of that value. `REG_EQUIV' notes are used by + register allocation to indicate that there is an available + substitute expression (either a constant or a `mem' expression for + the location of a parameter on the stack) that may be used in + place of a register if insufficient registers are available. + + Except for stack homes for parameters, which are indicated by a + `REG_EQUIV' note and are not useful to the early optimization + passes and pseudo registers that are equivalent to a memory + location throughout there entire life, which is not detected until + later in the compilation, all equivalences are initially indicated + by an attached `REG_EQUAL' note. In the early stages of register + allocation, a `REG_EQUAL' note is changed into a `REG_EQUIV' note + if OP is a constant and the insn represents the only set of its + destination register. + + Thus, compiler passes prior to register allocation need only check + for `REG_EQUAL' notes and passes subsequent to register allocation + need only check for `REG_EQUIV' notes. + +`REG_UNUSED' + The register OP being set by this insn will not be used in a + subsequent insn. This differs from a `REG_DEAD' note, which + indicates that the value in an input will not be used subsequently. + These two notes are independent; both may be present for the same + register. + +`REG_WAS_0' + The single output of this insn contained zero before this insn. + OP is the insn that set it to zero. You can rely on this note if + it is present and OP has not been deleted or turned into a `note'; + its absence implies nothing. + + These notes describe linkages between insns. They occur in pairs: +one insn has one of a pair of notes that points to a second insn, which +has the inverse note pointing back to the first insn. + +`REG_RETVAL' + This insn copies the value of a multi-insn sequence (for example, a + library call), and OP is the first insn of the sequence (for a + library call, the first insn that was generated to set up the + arguments for the library call). + + Loop optimization uses this note to treat such a sequence as a + single operation for code motion purposes and flow analysis uses + this note to delete such sequences whose results are dead. + + A `REG_EQUAL' note will also usually be attached to this insn to + provide the expression being computed by the sequence. + +`REG_LIBCALL' + This is the inverse of `REG_RETVAL': it is placed on the first + insn of a multi-insn sequence, and it points to the last one. + +`REG_CC_SETTER' +`REG_CC_USER' + On machines that use `cc0', the insns which set and use `cc0' set + and use `cc0' are adjacent. However, when branch delay slot + filling is done, this may no longer be true. In this case a + `REG_CC_USER' note will be placed on the insn setting `cc0' to + point to the insn using `cc0' and a `REG_CC_SETTER' note will be + placed on the insn using `cc0' to point to the insn setting `cc0'. + + These values are only used in the `LOG_LINKS' field, and indicate +the type of dependency that each link represents. Links which indicate +a data dependence (a read after write dependence) do not use any code, +they simply have mode `VOIDmode', and are printed without any +descriptive text. + +`REG_DEP_ANTI' + This indicates an anti dependence (a write after read dependence). + +`REG_DEP_OUTPUT' + This indicates an output dependence (a write after write + dependence). + + For convenience, the machine mode in an `insn_list' or `expr_list' +is printed using these symbolic codes in debugging dumps. + + 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. - This section describes the macros that output function entry -("prologue") and exit ("epilogue") code. + +File: gcc.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL -`FUNCTION_PROLOGUE (FILE, SIZE)' - A C compound statement that outputs the assembler code for entry - to a function. The prologue is responsible for setting up the - stack frame, initializing the frame pointer register, saving - registers that must be saved, and allocating SIZE additional - bytes of storage for the local variables. SIZE is an integer. - FILE is a stdio stream to which the assembler code should be - output. - - The label for the beginning of the function need not be output by - this macro. That has already been done when the macro is run. - - To determine which registers to save, the macro can refer to the - array `regs_ever_live': element R is nonzero if hard register R - is used anywhere within the function. This implies the function - prologue should save register R, provided it is not one of the - call-used registers. (`FUNCTION_EPILOGUE' must likewise use - `regs_ever_live'.) - - On machines that have "register windows", the function entry code - does not save on the stack the registers that are in the windows, - even if they are supposed to be preserved by function calls; - instead it takes appropriate steps to "push" the register stack, - if any non-call-used registers are used in the function. - - On machines where functions may or may not have frame-pointers, - the function entry code must vary accordingly; it must set up the - frame pointer if one is wanted, and not otherwise. To determine - whether a frame pointer is in wanted, the macro can refer to the - variable `frame_pointer_needed'. The variable's value will be 1 - at run time in a function that needs a frame pointer. *Note - Elimination::. - - The function entry code is responsible for allocating any stack - space required for the function. This stack space consists of - the regions listed below. In most cases, these regions are - allocated in the order listed, with the last listed region - closest to the top of the stack (the lowest address if - `STACK_GROWS_DOWNWARD' is defined, and the highest address if it - is not defined). You can use a different order for a machine if - doing so is more convenient or required for compatibility - reasons. Except in cases where required by standard or by a - debugger, there is no reason why the stack layout used by GCC - need agree with that used by other compilers for a machine. - - * A region of `current_function_pretend_args_size' bytes of - uninitialized space just underneath the first argument - arriving on the stack. (This may not be at the very start - of the allocated stack region if the calling sequence has - pushed anything else since pushing the stack arguments. But - usually, on such machines, nothing else has been pushed yet, - because the function prologue itself does all the pushing.) - This region is used on machines where an argument may be - passed partly in registers and partly in memory, and, in - some cases to support the features in `varargs.h' and - `stdargs.h'. - - * An area of memory used to save certain registers used by the - function. The size of this area, which may also include - space for such things as the return address and pointers to - previous stack frames, is machine-specific and usually - depends on which registers have been used in the function. - Machines with register windows often do not require a save - area. - - * A region of at least SIZE bytes, possibly rounded up to an - allocation boundary, to contain the local variables of the - function. On some machines, this region and the save area - may occur in the opposite order, with the save area closer - to the top of the stack. - - * Optionally, in the case that `ACCUMULATE_OUTGOING_ARGS' is - defined, a region of `current_function_outgoing_args_size' - bytes to be used for outgoing argument lists of the - function. *Note Stack Arguments::. - - Normally, it is necessary for `FUNCTION_PROLOGUE' and - `FUNCTION_EPILOGUE' to treat leaf functions specially. The C - variable `leaf_function' is nonzero for such a function. - -`EXIT_IGNORE_STACK' - Define this macro as a C expression that is nonzero if the return - instruction or the function epilogue ignores the value of the - stack pointer; in other words, if it is safe to delete an - instruction to adjust the stack pointer before a return from the - function. - - Note that this macro's value is relevant only for functions for - which frame pointers are maintained. It is never safe to delete - a final stack adjustment in a function that has no frame pointer, - and the compiler knows this regardless of `EXIT_IGNORE_STACK'. - -`FUNCTION_EPILOGUE (FILE, SIZE)' - A C compound statement that outputs the assembler code for exit - from a function. The epilogue is responsible for restoring the - saved registers and stack pointer to their values when the - function was called, and returning control to the caller. This - macro takes the same arguments as the macro `FUNCTION_PROLOGUE', - and the registers to restore are determined from `regs_ever_live' - and `CALL_USED_REGISTERS' in the same way. - - On some machines, there is a single instruction that does all the - work of returning from the function. On these machines, give that - instruction the name `return' and do not define the macro - `FUNCTION_EPILOGUE' at all. - - Do not define a pattern named `return' if you want the - `FUNCTION_EPILOGUE' to be used. If you want the target switches - to control whether return instructions or epilogues are used, - define a `return' pattern with a validity condition that tests - the target switches appropriately. If the `return' pattern's - validity condition is false, epilogues will be used. - - On machines where functions may or may not have frame-pointers, - the function exit code must vary accordingly. Sometimes the code - for these two cases is completely different. To determine - whether a frame pointer is in wanted, the macro can refer to the - variable `frame_pointer_needed'. The variable's value will be 1 - at run time in a function that needs a frame pointer. - - Normally, it is necessary for `FUNCTION_PROLOGUE' and - `FUNCTION_EPILOGUE' to treat leaf functions specially. The C - variable `leaf_function' is nonzero for such a function. *Note - Leaf Functions::. - - On some machines, some functions pop their arguments on exit while - others leave that for the caller to do. For example, the 68020 - when given `-mrtd' pops arguments in functions that take a fixed - number of arguments. - - Your definition of the macro `RETURN_POPS_ARGS' decides which - functions pop their own arguments. `FUNCTION_EPILOGUE' needs to - know what was decided. The variable `current_function_pops_args' - is the number of bytes of its arguments that a function should - pop. *Note Scalar Return::. - -`DELAY_SLOTS_FOR_EPILOGUE' - Define this macro if the function epilogue contains delay slots - to which instructions from the rest of the function can be - "moved". The definition should be a C expression whose value is - an integer representing the number of delay slots there. - -`ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)' - A C expression that returns 1 if INSN can be placed in delay slot - number N of the epilogue. - - The argument N is an integer which identifies the delay slot now - being considered (since different slots may have different rules - of eligibility). It is never negative and is always less than - the number of epilogue delay slots (what - `DELAY_SLOTS_FOR_EPILOGUE' returns). If you reject a particular - insn for a given delay slot, in principle, it may be reconsidered - for a subsequent delay slot. Also, other insns may (at least in - principle) be considered for the so far unfilled delay slot. - - The insns accepted to fill the epilogue delay slots are put in an - RTL list made with `insn_list' objects, stored in the variable - `current_function_epilogue_delay_list'. The insn for the first - delay slot comes first in the list. Your definition of the macro - `FUNCTION_EPILOGUE' should fill the delay slots by outputting the - insns in this list, usually by calling `final_scan_insn'. +RTL Representation of Function-Call Insns +========================================= - You need not define this macro if you did not define - `DELAY_SLOTS_FOR_EPILOGUE'. + 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 (mem:FM ADDR) NBYTES) + +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' expression as +shown above is the entire body of the insn, except that the insn might +also contain `use' or `clobber' expressions. + + 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 (mem:FM ADDR) NBYTES)) + +This RTL expression makes it clear (to the optimizer passes) that the +appropriate register receives a useful value in this insn. + + 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. + + On some machines, the call instruction itself clobbers some register, +for example to contain the return address. `call_insn' insns on these +machines should have a body which is a `parallel' that contains both +the `call' expression and `clobber' expressions that indicate which +registers are destroyed. Similarly, if the call instruction requires +some register other than the stack pointer that is not explicitly +mentioned it its RTL, a `use' subexpression should mention that +register. + + Functions that are called are assumed to modify all registers listed +in the configuration macro `CALL_USED_REGISTERS' (*note Register +Basics::.) and, with the exception of `const' functions and library +calls, to modify all of memory. + + Insns containing just `use' expressions directly precede the +`call_insn' insn to indicate which registers contain inputs to the +function. Similarly, if registers other than those in +`CALL_USED_REGISTERS' are clobbered by the called function, insns +containing a single `clobber' follow immediately after the call to +indicate which registers.  -File: gcc.info, Node: Profiling, Prev: Function Entry, Up: Stack and Calling +File: gcc.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL -Generating Code for Profiling ------------------------------ +Structure Sharing Assumptions +============================= -`FUNCTION_PROFILER (FILE, LABELNO)' - A C statement or compound statement to output to FILE some - assembler code to call the profiling subroutine `mcount'. Before - calling, the assembler code must load the address of a counter - variable into a register where `mcount' expects to find the - address. The name of this variable is `LP' followed by the - number LABELNO, so you would generate the name using `LP%d' in a - `fprintf'. - - The details of how the address should be passed to `mcount' are - determined by your operating system environment, not by GNU CC. - To figure them out, compile a small program for profiling using - the system's installed C compiler and look at the assembler code - that results. - -`PROFILE_BEFORE_PROLOGUE' - Define this macro if the code for function profiling should come - before the function prologue. Normally, the profiling code comes - after. - -`FUNCTION_BLOCK_PROFILER (FILE, LABELNO)' - A C statement or compound statement to output to FILE some - assembler code to initialize basic-block profiling for the current - object module. This code should call the subroutine - `__bb_init_func' once per object module, passing it as its sole - argument the address of a block allocated in the object module. - - The name of the block is a local symbol made with this statement: - - ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0); - - Of course, since you are writing the definition of - `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you - can take a short cut in the definition of this macro and use the - name that you know will result. - - The first word of this block is a flag which will be nonzero if - the object module has already been initialized. So test this - word first, and do not call `__bb_init_func' if the flag is - nonzero. - -`BLOCK_PROFILER (FILE, BLOCKNO)' - A C statement or compound statement to increment the count - associated with the basic block number BLOCKNO. Basic blocks are - numbered separately from zero within each compilation. The count - associated with block number BLOCKNO is at index BLOCKNO in a - vector of words; the name of this array is a local symbol made - with this statement: - - ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2); - - Of course, since you are writing the definition of - `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you - can take a short cut in the definition of this macro and use the - name that you know will result. + The compiler assumes that certain kinds of RTL expressions are +unique; there do not exist two distinct objects representing the same +value. In other cases, it makes an opposite assumption: that no RTL +expression object of a certain kind appears in more than one place in +the containing structure. + + These assumptions refer to a single function; except for the RTL +objects that describe global variables and external functions, and a +few standard objects such as small integer constants, no RTL objects +are common to two functions. + + * Each pseudo-register has only a single `reg' object to represent + it, and therefore only a single machine mode. + + * For any symbolic label, there is only one `symbol_ref' object + referring to it. + + * There is only one `const_int' expression with value 0, only one + with value 1, and only one with value -1. Some other integer + values are also stored uniquely. + + * There is only one `pc' expression. + + * There is only one `cc0' expression. + + * There is only one `const_double' expression with value 0 for each + floating point mode. Likewise for values 1 and 2. + + * No `label_ref' or `scratch' appears in more than one place in the + RTL structure; in other words, it is safe to do a tree-walk of all + the insns in the function and assume that each time a `label_ref' + or `scratch' is seen it is distinct from all others that are seen. + + * Only one `mem' object is normally created for each static variable + or stack slot, so these objects are frequently shared in all the + places they appear. However, separate but equal objects for these + variables are occasionally made. + + * When a single `asm' statement has multiple output operands, a + distinct `asm_operands' expression is made for each output operand. + However, these all share the vector which contains the sequence of + input operands. This sharing is used later on to test whether two + `asm_operands' expressions come from the same statement, so all + optimizations must carefully preserve the sharing if they copy the + vector at all. + + * No RTL object appears in more than one place in the RTL structure + except as described above. Many passes of the compiler rely on + this by assuming that they can modify RTL objects in place without + unwanted side-effects on other insns. + + * During initial RTL generation, shared structure is freely + introduced. After all the RTL for a function has been generated, + all shared structure is copied by `unshare_all_rtl' in + `emit-rtl.c', after which the above rules are guaranteed to be + followed. + + * During the combiner pass, shared structure within an insn can exist + temporarily. However, the shared structure is copied before the + combiner is finished with the insn. This is done by calling + `copy_rtx_if_shared', which is a subroutine of `unshare_all_rtl'.  -File: gcc.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros +File: gcc.info, Node: Reading RTL, Prev: Sharing, Up: RTL + +Reading RTL +=========== -Implementing the Varargs Macros -=============================== + To read an RTL object from a file, call `read_rtx'. It takes one +argument, a stdio stream, and returns a single RTL object. - GNU CC comes with an implementation of `varargs.h' and `stdarg.h' -that work without change on machines that pass arguments on the stack. - Other machines require their own implementations of varargs, and the -two machine independent header files must have conditionals to include -it. - - ANSI `stdarg.h' differs from traditional `varargs.h' mainly in the -calling convention for `va_start'. The traditional implementation -takes just one argument, which is the variable in which to store the -argument pointer. The ANSI implementation takes an additional first -argument, which is the last named argument of the function. However, -it should not use this argument. The way to find the end of the named -arguments is with the built-in functions described below. - -`__builtin_saveregs ()' - Use this built-in function to save the argument registers in - memory so that the varargs mechanism can access them. Both ANSI - and traditional versions of `va_start' must use - `__builtin_saveregs', unless you use `SETUP_INCOMING_VARARGS' - (see below) instead. - - On some machines, `__builtin_saveregs' is open-coded under the - control of the macro `EXPAND_BUILTIN_SAVEREGS'. On other - machines, it calls a routine written in assembler language, found - in `libgcc2.c'. - - Regardless of what code is generated for the call to - `__builtin_saveregs', it appears at the beginning of the function, - not where the call to `__builtin_saveregs' is written. This is - because the registers must be saved before the function starts to - use them for its own purposes. - -`__builtin_args_info (CATEGORY)' - Use this built-in function to find the first anonymous arguments - in registers. - - In general, a machine may have several categories of registers - used for arguments, each for a particular category of data types. - (For example, on some machines, floating-point registers are - used for floating-point arguments while other arguments are - passed in the general registers.) To make non-varargs functions - use the proper calling convention, you have defined the - `CUMULATIVE_ARGS' data type to record how many registers in each - category have been used so far - - `__builtin_args_info' accesses the same data structure of type - `CUMULATIVE_ARGS' after the ordinary argument layout is finished - with it, with CATEGORY specifying which word to access. Thus, the - value indicates the first unused register in a given category. - - Normally, you would use `__builtin_args_info' in the - implementation of `va_start', accessing each category just once - and storing the value in the `va_list' object. This is because - `va_list' will have to update the values, and there is no way to - alter the values accessed by `__builtin_args_info'. - -`__builtin_next_arg ()' - This is the equivalent of `__builtin_args_info', for stack - arguments. It returns the address of the first anonymous stack - argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns - the address of the location above the first anonymous stack - argument. Use it in `va_start' to initialize the pointer for - fetching arguments from the stack. - -`__builtin_classify_type (OBJECT)' - Since each machine has its own conventions for which data types - are passed in which kind of register, your implementation of - `va_arg' has to embody these conventions. The easiest way to - categorize the specified data type is to use - `__builtin_classify_type' together with `sizeof' and - `__alignof__'. - - `__builtin_classify_type' ignores the value of OBJECT, - considering only its data type. It returns an integer describing - what kind of type that is--integer, floating, pointer, structure, - and so on. - - The file `typeclass.h' defines an enumeration that you can use to - interpret the values of `__builtin_classify_type'. - - These machine description macros help implement varargs: - -`EXPAND_BUILTIN_SAVEREGS (ARGS)' - If defined, is a C expression that produces the machine-specific - code for a call to `__builtin_saveregs'. This code will be moved - to the very beginning of the function, before any parameter - access are made. The return value of this function should be an - RTX that contains the value to use as the return of - `__builtin_saveregs'. - - The argument ARGS is a `tree_list' containing the arguments that - were passed to `__builtin_saveregs'. - - If this macro is not defined, the compiler will output an ordinary - call to the library function `__builtin_saveregs'. - -`SETUP_INCOMING_VARARGS (ARGS_SO_FAR, MODE, TYPE, PRETEND_ARGS_SIZE, SECOND_TIME)' - This macro offers an alternative to using `__builtin_saveregs' and - defining the macro `EXPAND_BUILTIN_SAVEREGS'. Use it to store the - anonymous register arguments into the stack so that all the - arguments appear to have been passed consecutively on the stack. - Once this is done, you can use the standard implementation of - varargs that works for machines that pass all their arguments on - the stack. - - The argument ARGS_SO_FAR is the `CUMULATIVE_ARGS' data structure, - containing the values that obtain after processing of the named - arguments. The arguments MODE and TYPE describe the last named - argument--its machine mode and its data type as a tree node. - - The macro implementation should do two things: first, push onto - the stack all the argument registers *not* used for the named - arguments, and second, store the size of the data thus pushed - into the `int'-valued variable whose name is supplied as the - argument PRETEND_ARGS_SIZE. The value that you store here will - serve as additional offset for setting up the stack frame. - - Because you must generate code to push the anonymous arguments at - compile time without knowing their data types, - `SETUP_INCOMING_VARARGS' is only useful on machines that have just - a single category of argument register and use it uniformly for - all data types. - - If the argument SECOND_TIME is nonzero, it means that the - arguments of the function are being analyzed for the second time. - This happens for an inline function, which is not actually - compiled until the end of the source file. The macro - `SETUP_INCOMING_VARARGS' should not generate any instructions in - this case. + Reading RTL from a file is very slow. This is no currently not a +problem because reading RTL occurs only as part of building the +compiler. + + People frequently have the idea of using RTL stored as text in a +file as an interface between a language front end and the bulk of GNU +CC. This idea is not feasible. + + GNU CC was designed to use RTL internally only. Correct RTL for a +given program is very dependent on the particular target machine. And +the RTL does not contain all the information about the program. + + The proper way to interface GNU CC to a new language front end is +with the "tree" data structure. There is no manual for this data +structure, but it is described in the files `tree.h' and `tree.def'.  -File: gcc.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros +File: gcc.info, Node: Machine Desc, Next: Target Macros, Prev: RTL, Up: Top + +Machine Descriptions +******************** -Trampolines for Nested Functions -================================ + A machine description has two parts: a file of instruction patterns +(`.md' file) and a C header file of macro definitions. - A "trampoline" is a small piece of code that is created at run time -when the address of a nested function is taken. It normally resides on -the stack, in the stack frame of the containing function. These macros -tell GNU CC how to generate code to allocate and initialize a -trampoline. - - The instructions in the trampoline must do two things: load a -constant address into the static chain register, and jump to the real -address of the nested function. On CISC machines such as the m68k, -this requires two instructions, a move immediate and a jump. Then the -two addresses exist in the trampoline as word-long immediate operands. - On RISC machines, it is often necessary to load each address into a -register in two parts. Then pieces of each address form separate -immediate operands. - - The code generated to initialize the trampoline must store the -variable parts--the static chain value and the function address--into -the immediate operands of the instructions. On a CISC machine, this is -simply a matter of copying each address to a memory reference at the -proper offset from the start of the trampoline. On a RISC machine, it -may be necessary to take out pieces of the address and store them -separately. - -`TRAMPOLINE_TEMPLATE (FILE)' - A C statement to output, on the stream FILE, assembler code for a - block of data that contains the constant parts of a trampoline. - This code should not include a label--the label is taken care of - automatically. - -`TRAMPOLINE_SIZE' - A C expression for the size in bytes of the trampoline, as an - integer. - -`TRAMPOLINE_ALIGNMENT' - Alignment required for trampolines, in bits. - - If you don't define this macro, the value of `BIGGEST_ALIGNMENT' - is used for aligning trampolines. - -`INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)' - A C statement to initialize the variable parts of a trampoline. - ADDR is an RTX for the address of the trampoline; FNADDR is an - RTX for the address of the nested function; STATIC_CHAIN is an - RTX for the static chain value that should be passed to the - function when it is called. - -`ALLOCATE_TRAMPOLINE (FP)' - A C expression to allocate run-time space for a trampoline. The - expression value should be an RTX representing a memory reference - to the space for the trampoline. - - If this macro is not defined, by default the trampoline is - allocated as a stack slot. This default is right for most - machines. The exceptions are machines where it is impossible to - execute instructions in the stack area. On such machines, you - may have to implement a separate stack, using this macro in - conjunction with `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE'. - - FP points to a data structure, a `struct function', which - describes the compilation status of the immediate containing - function of the function which the trampoline is for. Normally - (when `ALLOCATE_TRAMPOLINE' is not defined), the stack slot for - the trampoline is in the stack frame of this containing function. - Other allocation strategies probably must do something analogous - with this information. - - Implementing trampolines is difficult on many machines because they -have separate instruction and data caches. Writing into a stack -location fails to clear the memory in the instruction cache, so when -the program jumps to that location, it executes the old contents. - - Here are two possible solutions. One is to clear the relevant -parts of the instruction cache whenever a trampoline is set up. The -other is to make all trampolines identical, by having them jump to a -standard subroutine. The former technique makes trampoline execution -faster; the latter makes initialization faster. - - To clear the instruction cache when a trampoline is initialized, -define the following macros which describe the shape of the cache. - -`INSN_CACHE_SIZE' - The total size in bytes of the cache. - -`INSN_CACHE_LINE_WIDTH' - The length in bytes of each cache line. The cache is divided - into cache lines which are disjoint slots, each holding a - contiguous chunk of data fetched from memory. Each time data is - brought into the cache, an entire line is read at once. The data - loaded into a cache line is always aligned on a boundary equal to - the line size. - -`INSN_CACHE_DEPTH' - The number of alternative cache lines that can hold any - particular memory location. - - To use a standard subroutine, define the following macro. In -addition, you must make sure that the instructions in a trampoline -fill an entire cache line with identical instructions, or else ensure -that the beginning of the trampoline code is always aligned at the -same point in its cache line. Look in `m68k.h' as a guide. - -`TRANSFER_FROM_TRAMPOLINE' - Define this macro if trampolines need a special subroutine to do - their work. The macro should expand to a series of `asm' - statements which will be compiled with GNU CC. They go in a - library function named `__transfer_from_trampoline'. - - If you need to avoid executing the ordinary prologue code of a - compiled C function when you jump to the subroutine, you can do - so by placing a special label of your own in the assembler code. - Use one `asm' statement to generate an assembler label, and - another to make the label global. Then trampolines can use that - label to jump directly to your special assembler code. + The `.md' file for a target machine contains a pattern for each +instruction that the target machine supports (or at least each +instruction that is worth telling the compiler about). It may also +contain comments. A semicolon causes the rest of the line to be a +comment, unless the semicolon is inside a quoted string. + + See the next chapter for information on the C header file. + +* Menu: + +* Patterns:: How to write instruction patterns. +* Example:: An explained example of a `define_insn' pattern. +* RTL Template:: The RTL template defines what insns match a pattern. +* Output Template:: The output template says how to make assembler code + from such an insn. +* Output Statement:: For more generality, write C code to output + the assembler code. +* Constraints:: When not all operands are general operands. +* Standard Names:: Names mark patterns to use for code generation. +* Pattern Ordering:: When the order of patterns makes a difference. +* Dependent Patterns:: Having one pattern may make you need another. +* Jump Patterns:: Special considerations for patterns for jump insns. +* Insn Canonicalizations::Canonicalization of Instructions +* Peephole Definitions::Defining machine-specific peephole optimizations. +* Expander Definitions::Generating a sequence of several RTL insns + for a standard operation. +* Insn Splitting:: Splitting Instructions into Multiple Instructions +* Insn Attributes:: Specifying the value of attributes for generated insns.  -File: gcc.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros +File: gcc.info, Node: Patterns, Next: Example, Up: Machine Desc -Implicit Calls to Library Routines -================================== +Everything about Instruction Patterns +===================================== -`MULSI3_LIBCALL' - A C string constant giving the name of the function to call for - multiplication of one signed full-word by another. If you do not - define this macro, the default name is used, which is `__mulsi3', - a function defined in `libgcc.a'. - -`DIVSI3_LIBCALL' - A C string constant giving the name of the function to call for - division of one signed full-word by another. If you do not define - this macro, the default name is used, which is `__divsi3', a - function defined in `libgcc.a'. - -`UDIVSI3_LIBCALL' - A C string constant giving the name of the function to call for - division of one unsigned full-word by another. If you do not - define this macro, the default name is used, which is - `__udivsi3', a function defined in `libgcc.a'. - -`MODSI3_LIBCALL' - A C string constant giving the name of the function to call for - the remainder in division of one signed full-word by another. If - you do not define this macro, the default name is used, which is - `__modsi3', a function defined in `libgcc.a'. - -`UMODSI3_LIBCALL' - A C string constant giving the name of the function to call for - the remainder in division of one unsigned full-word by another. - If you do not define this macro, the default name is used, which - is `__umodsi3', a function defined in `libgcc.a'. - -`MULDI3_LIBCALL' - A C string constant giving the name of the function to call for - multiplication of one signed double-word by another. If you do - not define this macro, the default name is used, which is - `__muldi3', a function defined in `libgcc.a'. - -`DIVDI3_LIBCALL' - A C string constant giving the name of the function to call for - division of one signed double-word by another. If you do not - define this macro, the default name is used, which is `__divdi3', - a function defined in `libgcc.a'. - -`UDIVDI3_LIBCALL' - A C string constant giving the name of the function to call for - division of one unsigned full-word by another. If you do not - define this macro, the default name is used, which is - `__udivdi3', a function defined in `libgcc.a'. - -`MODDI3_LIBCALL' - A C string constant giving the name of the function to call for - the remainder in division of one signed double-word by another. - If you do not define this macro, the default name is used, which - is `__moddi3', a function defined in `libgcc.a'. - -`UMODDI3_LIBCALL' - A C string constant giving the name of the function to call for - the remainder in division of one unsigned full-word by another. - If you do not define this macro, the default name is used, which - is `__umoddi3', a function defined in `libgcc.a'. - -`TARGET_MEM_FUNCTIONS' - Define this macro if GNU CC should generate calls to the System V - (and ANSI C) library functions `memcpy' and `memset' rather than - the BSD functions `bcopy' and `bzero'. - -`LIBGCC_NEEDS_DOUBLE' - Define this macro if only `float' arguments cannot be passed to - library routines (so they must be converted to `double'). This - macro affects both how library calls are generated and how the - library routines in `libgcc1.c' accept their arguments. It is - useful on machines where floating and fixed point arguments are - passed differently, such as the i860. - -`FLOAT_ARG_TYPE' - Define this macro to override the type used by the library - routines to pick up arguments of type `float'. (By default, they - use a union of `float' and `int'.) - - The obvious choice would be `float'--but that won't work with - traditional C compilers that expect all arguments declared as - `float' to arrive as `double'. To avoid this conversion, the - library routines ask for the value as some other type and then - treat it as a `float'. - - On some systems, no other type will work for this. For these - systems, you must use `LIBGCC_NEEDS_DOUBLE' instead, to force - conversion of the values `double' before they are passed. - -`FLOATIFY (PASSED-VALUE)' - Define this macro to override the way library routines - redesignate a `float' argument as a `float' instead of the type - it was passed as. The default is an expression which takes the - `float' field of the union. - -`FLOAT_VALUE_TYPE' - Define this macro to override the type used by the library - routines to return values that ought to have type `float'. (By - default, they use `int'.) - - The obvious choice would be `float'--but that won't work with - traditional C compilers gratuitously convert values declared as - `float' into `double'. - -`INTIFY (FLOAT-VALUE)' - Define this macro to override the way the value of a - `float'-returning library routine should be packaged in order to - return it. These functions are actually declared to return type - `FLOAT_VALUE_TYPE' (normally `int'). - - These values can't be returned as type `float' because traditional - C compilers would gratuitously convert the value to a `double'. - - A local variable named `intify' is always available when the macro - `INTIFY' is used. It is a union of a `float' field named `f' and - a field named `i' whose type is `FLOAT_VALUE_TYPE' or `int'. - - If you don't define this macro, the default definition works by - copying the value through that union. - -`SItype' - Define this macro as the name of the data type corresponding to - `SImode' in the system's own C compiler. - - You need not define this macro if that type is `int', as it - usually is. - -`perform_...' - Define these macros to supply explicit C statements to carry out - various arithmetic operations on types `float' and `double' in the - library routines in `libgcc1.c'. See that file for a full list - of these macros and their arguments. - - On most machines, you don't need to define any of these macros, - because the C compiler that comes with the system takes care of - doing them. - -`NEXT_OBJC_RUNTIME' - Define this macro to generate code for Objective C message - sending using the calling convention of the NeXT system. This - calling convention involves passing the object, the selector and - the method arguments all at once to the method-lookup library - function. - - The default calling convention passes just the object and the - selector to the lookup function, which returns a pointer to the - method. + Each instruction pattern contains an incomplete RTL expression, with +pieces to be filled in later, operand constraints that restrict how the +pieces can be filled in, and an output pattern or C code to generate +the assembler output, all wrapped up in a `define_insn' expression. + + A `define_insn' is an RTL expression containing four or five +operands: + + 1. An optional name. The presence of a name indicate that this + instruction pattern can perform a certain standard job for the + RTL-generation pass of the compiler. This pass knows certain + names and will use the instruction patterns with those names, if + the names are defined in the machine description. + + The absence of a name is indicated by writing an empty string + where the name should go. Nameless instruction patterns are never + used for generating RTL code, but they may permit several simpler + insns to be combined later on. + + Names that are not thus known and used in RTL-generation have no + effect; they are equivalent to no name at all. + + 2. The "RTL template" (*note RTL Template::.) is a vector of + incomplete RTL expressions which show what the instruction should + look like. It is incomplete because it may contain + `match_operand', `match_operator', and `match_dup' expressions + that stand for operands of the instruction. + + If the vector has only one element, that element is the template + for the instruction pattern. If the vector has multiple elements, + then the instruction pattern is a `parallel' expression containing + the elements described. + + 3. A condition. This is a string which contains a C expression that + is the final test to decide whether an insn body matches this + pattern. + + For a named pattern, the condition (if present) may not depend on + the data in the insn being matched, but only the + target-machine-type flags. The compiler needs to test these + conditions during initialization in order to learn exactly which + named instructions are available in a particular run. + + For nameless patterns, the condition is applied only when matching + an individual insn, and only after the insn has matched the + pattern's recognition template. The insn's operands may be found + in the vector `operands'. + + 4. The "output template": a string that says how to output matching + insns as assembler code. `%' in this string specifies where to + substitute the value of an operand. *Note Output Template::. + + When simple substitution isn't general enough, you can specify a + piece of C code to compute the output. *Note Output Statement::. + + 5. Optionally, a vector containing the values of attributes for insns + matching this pattern. *Note Insn Attributes::.  -File: gcc.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros +File: gcc.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc + +Example of `define_insn' +======================== + + Here is an actual example of an instruction pattern, for the +68000/68020. -Addressing Modes -================ + (define_insn "tstsi" + [(set (cc0) + (match_operand:SI 0 "general_operand" "rm"))] + "" + "* + { if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) + return \"tstl %0\"; + return \"cmpl #0,%0\"; }") + + This is an instruction that sets the condition codes based on the +value of a general operand. It has no condition, so any insn whose RTL +description has the form shown may be handled according to this +pattern. The name `tstsi' means "test a `SImode' value" and tells the +RTL generation pass that, when it is necessary to test such a value, an +insn to do so can be constructed using this pattern. + + The output control string is a piece of C code which chooses which +output template to return based on the kind of operand and the specific +type of CPU for which code is being generated. -`HAVE_POST_INCREMENT' - Define this macro if the machine supports post-increment - addressing. - -`HAVE_PRE_INCREMENT' -`HAVE_POST_DECREMENT' -`HAVE_PRE_DECREMENT' - Similar for other kinds of addressing. - -`CONSTANT_ADDRESS_P (X)' - A C expression that is 1 if the RTX X is a constant which is a - valid address. On most machines, this can be defined as - `CONSTANT_P (X)', but a few machines are more restrictive in - which constant addresses are supported. - - `CONSTANT_P' accepts integer-values expressions whose values are - not explicitly known, such as `symbol_ref', `label_ref', and - `high' expressions and `const' arithmetic expressions, in - addition to `const_int' and `const_double' expressions. - -`MAX_REGS_PER_ADDRESS' - A number, the maximum number of registers that can appear in a - valid memory address. Note that it is up to you to specify a - value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS' - would ever accept. - -`GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)' - A C compound statement with a conditional `goto LABEL;' executed - if X (an RTX) is a legitimate memory address on the target - machine for a memory operand of mode MODE. - - It usually pays to define several simpler macros to serve as - subroutines for this one. Otherwise it may be too complicated to - understand. - - This macro must exist in two variants: a strict variant and a - non-strict one. The strict variant is used in the reload pass. - It must be defined so that any pseudo-register that has not been - allocated a hard register is considered a memory reference. In - contexts where some kind of register is required, a - pseudo-register with no hard register must be rejected. - - The non-strict variant is used in other passes. It must be - defined to accept all pseudo-registers in every context where - some kind of register is required. - - Compiler source files that want to use the strict variant of this - macro define the macro `REG_OK_STRICT'. You should use an - `#ifdef REG_OK_STRICT' conditional to define the strict variant - in that case and the non-strict variant otherwise. - - Typically among the subroutines used to define - `GO_IF_LEGITIMATE_ADDRESS' are subroutines to check for - acceptable registers for various purposes (one for base - registers, one for index registers, and so on). Then only these - subroutine macros need have two variants; the higher levels of - macros may be the same whether strict or not. - - Normally, constant addresses which are the sum of a `symbol_ref' - and an integer are stored inside a `const' RTX to mark them as - constant. Therefore, there is no need to recognize such sums - specifically as legitimate addresses. Normally you would simply - recognize any `const' as legitimate. - - Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant - sums that are not marked with `const'. It assumes that a naked - `plus' indicates indexing. If so, then you *must* reject such - naked constant sums as illegitimate addresses, so that none of - them will be given to `PRINT_OPERAND_ADDRESS'. - - On some machines, whether a symbolic address is legitimate - depends on the section that the address refers to. On these - machines, define the macro `ENCODE_SECTION_INFO' to store the - information into the `symbol_ref', and then check for it here. - When you see a `const', you will have to look inside it to find - the `symbol_ref' in order to determine the section. *Note - Assembler Format::. - - The best way to modify the name string is by adding text to the - beginning, with suitable punctuation to prevent any ambiguity. - Allocate the new name in `saveable_obstack'. You will have to - modify `ASM_OUTPUT_LABELREF' to remove and decode the added text - and output the name accordingly. - - You can check the information stored here into the `symbol_ref' in - the definitions of `GO_IF_LEGITIMATE_ADDRESS' and - `PRINT_OPERAND_ADDRESS'. - -`REG_OK_FOR_BASE_P (X)' - A C expression that is nonzero if X (assumed to be a `reg' RTX) - is valid for use as a base register. For hard registers, it - should always accept those which the hardware permits and reject - the others. Whether the macro accepts or rejects pseudo - registers must be controlled by `REG_OK_STRICT' as described - above. This usually requires two variant definitions, of which - `REG_OK_STRICT' controls the one actually used. - -`REG_OK_FOR_INDEX_P (X)' - A C expression that is nonzero if X (assumed to be a `reg' RTX) - is valid for use as an index register. - - The difference between an index register and a base register is - that the index register may be scaled. If an address involves - the sum of two registers, neither one of them scaled, then either - one may be labeled the "base" and the other the "index"; but - whichever labeling is used must fit the machine's constraints of - which registers may serve in each capacity. The compiler will - try both labelings, looking for one that is valid, and will - reload one or both registers only if neither labeling works. - -`LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)' - A C compound statement that attempts to replace X with a valid - memory address for an operand of mode MODE. WIN will be a C - statement label elsewhere in the code; the macro definition may - use - - GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN); - - to avoid further processing if the address has become legitimate. - - X will always be the result of a call to `break_out_memory_refs', - and OLDX will be the operand that was given to that function to - produce X. - - The code generated by this macro should not alter the - substructure of X. If it transforms X into a more legitimate - form, it should assign X (which will always be a C variable) a - new value. - - It is not necessary for this macro to come up with a legitimate - address. The compiler has standard ways of doing so in all - cases. In fact, it is safe for this macro to do nothing. But - often a machine-dependent strategy can generate better code. - -`GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)' - A C statement or compound statement with a conditional `goto - LABEL;' executed if memory address X (an RTX) can have different - meanings depending on the machine mode of the memory reference it - is used for. - - Autoincrement and autodecrement addresses typically have - mode-dependent effects because the amount of the increment or - decrement is the size of the operand being addressed. Some - machines have other mode-dependent addresses. Many RISC machines - have no mode-dependent addresses. - - You may assume that ADDR is a valid address for the machine. - -`LEGITIMATE_CONSTANT_P (X)' - A C expression that is nonzero if X is a legitimate constant for - an immediate operand on the target machine. You can assume that - X satisfies `CONSTANT_P', so you need not check this. In fact, - `1' is a suitable definition for this macro on machines where - anything `CONSTANT_P' is valid. - -`LEGITIMATE_PIC_OPERAND_P (X)' - A C expression that is nonzero if X is a legitimate immediate - operand on the target machine when generating position - independent code. You can assume that X satisfies `CONSTANT_P', - so you need not check this. You can also assume FLAG_PIC is - true, so you need not check it either. You need not define this - macro if all constants (including `SYMBOL_REF') can be immediate - operands when generating position independent code. + `"rm"' is an operand constraint. Its meaning is explained below.  -File: gcc.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Target Macros +File: gcc.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc -Condition Code Status -===================== +RTL Template +============ + + The RTL template is used to define which insns match the particular +pattern and how to find their operands. For named patterns, the RTL +template also says how to construct an insn from specified operands. + + Construction involves substituting specified operands into a copy of +the template. Matching involves determining the values that serve as +the operands in the insn being matched. Both of these activities are +controlled by special expression types that direct matching and +substitution of the operands. + +`(match_operand:M N PREDICATE CONSTRAINT)' + This expression is a placeholder for operand number N of the insn. + When constructing an insn, operand number N will be substituted + at this point. When matching an insn, whatever appears at this + position in the insn will be taken as operand number N; but it + must satisfy PREDICATE or this instruction pattern will not match + at all. + + Operand numbers must be chosen consecutively counting from zero in + each instruction pattern. There may be only one `match_operand' + expression in the pattern for each operand number. Usually + operands are numbered in the order of appearance in `match_operand' + expressions. + + PREDICATE is a string that is the name of a C function that + accepts two arguments, an expression and a machine mode. During + matching, the function will be called with the putative operand as + the expression and M as the mode argument (if M is not specified, + `VOIDmode' will be used, which normally causes PREDICATE to accept + any mode). If it returns zero, this instruction pattern fails to + match. PREDICATE may be an empty string; then it means no test is + to be done on the operand, so anything which occurs in this + position is valid. + + Most of the time, PREDICATE will reject modes other than M--but + not always. For example, the predicate `address_operand' uses M + as the mode of memory ref that the address should be valid for. + Many predicates accept `const_int' nodes even though their mode is + `VOIDmode'. + + CONSTRAINT controls reloading and the choice of the best register + class to use for a value, as explained later (*note + Constraints::.). + + People are often unclear on the difference between the constraint + and the predicate. The predicate helps decide whether a given + insn matches the pattern. The constraint plays no role in this + decision; instead, it controls various decisions in the case of an + insn which does match. + + On CISC machines, the most common PREDICATE is + `"general_operand"'. This function checks that the putative + operand is either a constant, a register or a memory reference, + and that it is valid for mode M. + + For an operand that must be a register, PREDICATE should be + `"register_operand"'. Using `"general_operand"' would be valid, + since the reload pass would copy any non-register operands through + registers, but this would make GNU CC do extra work, it would + prevent invariant operands (such as constant) from being removed + from loops, and it would prevent the register allocator from doing + the best possible job. On RISC machines, it is usually most + efficient to allow PREDICATE to accept only objects that the + constraints allow. + + For an operand that must be a constant, you must be sure to either + use `"immediate_operand"' for PREDICATE, or make the instruction + pattern's extra condition require a constant, or both. You cannot + expect the constraints to do this work! If the constraints allow + only constants, but the predicate allows something else, the + compiler will crash when that case arises. + +`(match_scratch:M N CONSTRAINT)' + This expression is also a placeholder for operand number N and + indicates that operand must be a `scratch' or `reg' expression. + + When matching patterns, this is equivalent to + + (match_operand:M N "scratch_operand" PRED) + + but, when generating RTL, it produces a (`scratch':M) expression. + + If the last few expressions in a `parallel' are `clobber' + expressions whose operands are either a hard register or + `match_scratch', the combiner can add or delete them when + necessary. *Note Side Effects::. + +`(match_dup N)' + This expression is also a placeholder for operand number N. It is + used when the operand needs to appear more than once in the insn. + + In construction, `match_dup' acts just like `match_operand': the + operand is substituted into the insn being constructed. But in + matching, `match_dup' behaves differently. It assumes that operand + number N has already been determined by a `match_operand' + appearing earlier in the recognition template, and it matches only + an identical-looking expression. + +`(match_operator:M N PREDICATE [OPERANDS...])' + This pattern is a kind of placeholder for a variable RTL expression + code. + + When constructing an insn, it stands for an RTL expression whose + expression code is taken from that of operand N, and whose + operands are constructed from the patterns OPERANDS. + + When matching an expression, it matches an expression if the + function PREDICATE returns nonzero on that expression *and* the + patterns OPERANDS match the operands of the expression. + + Suppose that the function `commutative_operator' is defined as + follows, to match any expression whose operator is one of the + commutative arithmetic operators of RTL and whose mode is MODE: + + int + commutative_operator (x, mode) + rtx x; + enum machine_mode mode; + { + enum rtx_code code = GET_CODE (x); + if (GET_MODE (x) != mode) + return 0; + return (GET_RTX_CLASS (code) == 'c' + || code == EQ || code == NE); + } + + Then the following pattern will match any RTL expression consisting + of a commutative operator applied to two general operands: + + (match_operator:SI 3 "commutative_operator" + [(match_operand:SI 1 "general_operand" "g") + (match_operand:SI 2 "general_operand" "g")]) + + Here the vector `[OPERANDS...]' contains two patterns because the + expressions to be matched all contain two operands. + + When this pattern does match, the two operands of the commutative + operator are recorded as operands 1 and 2 of the insn. (This is + done by the two instances of `match_operand'.) Operand 3 of the + insn will be the entire commutative expression: use `GET_CODE + (operands[3])' to see which commutative operator was used. + + The machine mode M of `match_operator' works like that of + `match_operand': it is passed as the second argument to the + predicate function, and that function is solely responsible for + deciding whether the expression to be matched "has" that mode. + + When constructing an insn, argument 3 of the gen-function will + specify the operation (i.e. the expression code) for the + expression to be made. It should be an RTL expression, whose + expression code is copied into a new expression whose operands are + arguments 1 and 2 of the gen-function. The subexpressions of + argument 3 are not used; only its expression code matters. + + When `match_operator' is used in a pattern for matching an insn, + it usually best if the operand number of the `match_operator' is + higher than that of the actual operands of the insn. This improves + register allocation because the register allocator often looks at + operands 1 and 2 of insns to see if it can do register tying. + + There is no way to specify constraints in `match_operator'. The + operand of the insn which corresponds to the `match_operator' + never has any constraints because it is never reloaded as a whole. + However, if parts of its OPERANDS are matched by `match_operand' + patterns, those parts may have constraints of their own. + +`(match_op_dup:M N[OPERANDS...])' + Like `match_dup', except that it applies to operators instead of + operands. When constructing an insn, operand number N will be + substituted at this point. But in matching, `match_op_dup' behaves + differently. It assumes that operand number N has already been + determined by a `match_operator' appearing earlier in the + recognition template, and it matches only an identical-looking + expression. + +`(match_parallel N PREDICATE [SUBPAT...])' + This pattern is a placeholder for an insn that consists of a + `parallel' expression with a variable number of elements. This + expression should only appear at the top level of an insn pattern. + + When constructing an insn, operand number N will be substituted at + this point. When matching an insn, it matches if the body of the + insn is a `parallel' expression with at least as many elements as + the vector of SUBPAT expressions in the `match_parallel', if each + SUBPAT matches the corresponding element of the `parallel', *and* + the function PREDICATE returns nonzero on the `parallel' that is + the body of the insn. It is the responsibility of the predicate + to validate elements of the `parallel' beyond those listed in the + `match_parallel'. + + A typical use of `match_parallel' is to match load and store + multiple expressions, which can contain a variable number of + elements in a `parallel'. For example, + + (define_insn "" + [(match_parallel 0 "load_multiple_operation" + [(set (match_operand:SI 1 "gpc_reg_operand" "=r") + (match_operand:SI 2 "memory_operand" "m")) + (use (reg:SI 179)) + (clobber (reg:SI 179))])] + "" + "loadm 0,0,%1,%2") + + This example comes from `a29k.md'. The function + `load_multiple_operations' is defined in `a29k.c' and checks that + subsequent elements in the `parallel' are the same as the `set' in + the pattern, except that they are referencing subsequent registers + and memory locations. + + An insn that matches this pattern might look like: + + (parallel + [(set (reg:SI 20) (mem:SI (reg:SI 100))) + (use (reg:SI 179)) + (clobber (reg:SI 179)) + (set (reg:SI 21) + (mem:SI (plus:SI (reg:SI 100) + (const_int 4)))) + (set (reg:SI 22) + (mem:SI (plus:SI (reg:SI 100) + (const_int 8))))]) + +`(match_par_dup N [SUBPAT...])' + Like `match_op_dup', but for `match_parallel' instead of + `match_operator'. + +`(address (match_operand:M N "address_operand" ""))' + This complex of expressions is a placeholder for an operand number + N in a "load address" instruction: an operand which specifies a + memory location in the usual way, but for which the actual operand + value used is the address of the location, not the contents of the + location. + + `address' expressions never appear in RTL code, only in machine + descriptions. And they are used only in machine descriptions that + do not use the operand constraint feature. When operand + constraints are in use, the letter `p' in the constraint serves + this purpose. + + M is the machine mode of the *memory location being addressed*, + not the machine mode of the address itself. That mode is always + the same on a given target machine (it is `Pmode', which normally + is `SImode'), so there is no point in mentioning it; thus, no + machine mode is written in the `address' expression. If some day + support is added for machines in which addresses of different + kinds of objects appear differently or are used differently (such + as the PDP-10), different formats would perhaps need different + machine modes and these modes might be written in the `address' + expression. + + +File: gcc.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc - The file `conditions.h' defines a variable `cc_status' to describe -how the condition code was computed (in case the interpretation of the -condition code depends on the instruction that it was set by). This -variable contains the RTL expressions on which the condition code is -currently based, and several standard flags. - - Sometimes additional machine-specific flags must be defined in the -machine description header file. It can also add additional -machine-specific information by defining `CC_STATUS_MDEP'. - -`CC_STATUS_MDEP' - C code for a data type which is used for declaring the `mdep' - component of `cc_status'. It defaults to `int'. - - This macro is not used on machines that do not use `cc0'. - -`CC_STATUS_MDEP_INIT' - A C expression to initialize the `mdep' field to "empty". The - default definition does nothing, since most machines don't use - the field anyway. If you want to use the field, you should - probably define this macro to initialize it. - - This macro is not used on machines that do not use `cc0'. - -`NOTICE_UPDATE_CC (EXP, INSN)' - A C compound statement to set the components of `cc_status' - appropriately for an insn INSN whose body is EXP. It is this - macro's responsibility to recognize insns that set the condition - code as a byproduct of other activity as well as those that - explicitly set `(cc0)'. - - This macro is not used on machines that do not use `cc0'. - - If there are insns that do not set the condition code but do alter - other machine registers, this macro must check to see whether they - invalidate the expressions that the condition code is recorded as - reflecting. For example, on the 68000, insns that store in - address registers do not set the condition code, which means that - usually `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for - such insns. But suppose that the previous insn set the condition - code based on location `a4@(102)' and the current insn stores a - new value in `a4'. Although the condition code is not changed by - this, it will no longer be true that it reflects the contents of - `a4@(102)'. Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' - in this case to say that nothing is known about the condition - code value. - - The definition of `NOTICE_UPDATE_CC' must be prepared to deal - with the results of peephole optimization: insns whose patterns - are `parallel' RTXs containing various `reg', `mem' or constants - which are just the operands. The RTL structure of these insns is - not sufficient to indicate what the insns actually do. What - `NOTICE_UPDATE_CC' should do when it sees one is just to run - `CC_STATUS_INIT'. - - A possible definition of `NOTICE_UPDATE_CC' is to call a function - that looks at an attribute (*note Insn Attributes::.) named, for - example, `cc'. This avoids having detailed information about - patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'. - -`EXTRA_CC_MODES' - A list of names to be used for additional modes for condition code - values in registers (*note Jump Patterns::.). These names are - added to `enum machine_mode' and all have class `MODE_CC'. By - convention, they should start with `CC' and end with `mode'. - - You should only define this macro if your machine does not use - `cc0' and only if additional modes are required. - -`EXTRA_CC_NAMES' - A list of C strings giving the names for the modes listed in - `EXTRA_CC_MODES'. For example, the Sparc defines this macro and - `EXTRA_CC_MODES' as - - #define EXTRA_CC_MODES CC_NOOVmode, CCFPmode - #define EXTRA_CC_NAMES "CC_NOOV", "CCFP" - - This macro is not required if `EXTRA_CC_MODES' is not defined. - -`SELECT_CC_MODE (OP, X)' - Returns a mode from class `MODE_CC' to be used when comparison - operation code OP is applied to rtx X. For example, on the Sparc, - `SELECT_CC_MODE' is defined as (see *note Jump Patterns::. for a - description of the reason for this definition) - - #define SELECT_CC_MODE(OP,X) \ - (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT ? CCFPmode \ - : (GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ - || GET_CODE (X) == NEG) \ - ? CC_NOOVmode : CCmode) +Output Templates and Operand Substitution +========================================= - This macro is not required if `EXTRA_CC_MODES' is not defined. + The "output template" is a string which specifies how to output the +assembler code for an instruction pattern. Most of the template is a +fixed string which is output literally. The character `%' is used to +specify where to substitute an operand; it can also be used to identify +places where different variants of the assembler require different +syntax. + + In the simplest case, a `%' followed by a digit N says to output +operand N at that point in the string. + + `%' followed by a letter and a digit says to output an operand in an +alternate fashion. Four letters have standard, built-in meanings +described below. The machine description macro `PRINT_OPERAND' can +define additional letters with nonstandard meanings. + + `%cDIGIT' can be used to substitute an operand that is a constant +value without the syntax that normally indicates an immediate operand. + + `%nDIGIT' is like `%cDIGIT' except that the value of the constant is +negated before printing. + + `%aDIGIT' can be used to substitute an operand as if it were a +memory reference, with the actual operand treated as the address. This +may be useful when outputting a "load address" instruction, because +often the assembler syntax for such an instruction requires you to +write the operand as if it were a memory reference. + + `%lDIGIT' is used to substitute a `label_ref' into a jump +instruction. + + `%=' outputs a number which is unique to each instruction in the +entire compilation. This is useful for making local labels to be +referred to more than once in a single template that generates multiple +assembler instructions. + + `%' followed by a punctuation character specifies a substitution that +does not use an operand. Only one case is standard: `%%' outputs a `%' +into the assembler code. Other nonstandard cases can be defined in the +`PRINT_OPERAND' macro. You must also define which punctuation +characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro. + + The template may generate multiple assembler instructions. Write +the text for the instructions, with `\;' between them. + + When the RTL contains two operands which are required by constraint +to match each other, the output template must refer only to the +lower-numbered operand. Matching operands are not always identical, +and the rest of the compiler arranges to put the proper RTL expression +for printing into the lower-numbered operand. + + One use of nonstandard letters or punctuation following `%' is to +distinguish between different assembler languages for the same machine; +for example, Motorola syntax versus MIT syntax for the 68000. Motorola +syntax requires periods in most opcode names, while MIT syntax does +not. For example, the opcode `movel' in MIT syntax is `move.l' in +Motorola syntax. The same file of patterns is used for both kinds of +output syntax, but the character sequence `%.' is used in each place +where Motorola syntax wants a period. The `PRINT_OPERAND' macro for +Motorola syntax defines the sequence to output a period; the macro for +MIT syntax defines it to do nothing. + + As a special case, a template consisting of the single character `#' +instructs the compiler to first split the insn, and then output the +resulting instructions separately. This helps eliminate redundancy in +the output templates. If you have a `define_insn' that needs to emit +multiple assembler instructions, and there is an matching `define_split' +already defined, then you can simply use `#' as the output template +instead of writing an output template that emits the multiple assembler +instructions. + + If `ASSEMBLER_DIALECT' is defined, you can use +`{option0|option1|option2}' constructs in the templates. These +describe multiple variants of assembler language syntax. *Note +Instruction Output::. - \ No newline at end of file