--- gcc/gcc.info-11 2018/04/24 17:52:34 1.1.1.2 +++ gcc/gcc.info-11 2018/04/24 18:02:01 1.1.1.4 @@ -1,1175 +1,991 @@ -This is Info file gcc.info, produced by Makeinfo-1.44 from the input +This is Info file gcc.info, produced by Makeinfo-1.49 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. - 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 make and distribute verbatim copies of this +manual provided the copyright notice and this permission notice are +preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also -that the section entitled "GNU General Public License" is included -exactly as in the original, and provided that the entire resulting -derived work is distributed under the terms of a permission notice -identical to this one. +that the sections entitled "GNU General Public License" and "Protect +Your Freedom--Fight `Look And Feel'" are included exactly as in the +original, and provided that the entire resulting derived work is +distributed under the terms of a permission notice identical to this +one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified -versions, except that the section entitled "GNU General Public -License" and this permission notice may be included in translations -approved by the Free Software Foundation instead of in the original -English. +versions, except that the sections entitled "GNU General Public +License" and "Protect Your Freedom--Fight `Look And Feel'", and this +permission notice, may be included in translations approved by the Free +Software Foundation instead of in the original English. + + +File: gcc.info, Node: Patterns, Next: Example, Prev: Machine Desc, Up: Machine Desc + +Everything about Instruction Patterns +===================================== + + 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. - -File: gcc.info, Node: Insn Canonicalizations, Next: Peephole Definitions, Prev: Jump Patterns, Up: Machine Desc + 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. -Canonicalization of Instructions -================================ + 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. - There are often cases where multiple RTL expressions could -represent an operation performed by a single machine instruction. -This situation is most commonly encountered with logical, branch, and -multiply-accumulate instructions. In such cases, the compiler -attempts to convert these multiple RTL expressions into a single -canonical form to reduce the number of insn patterns required. - - In addition to algebraic simplifications, following -canonicalizations are performed: - - * For commutative and comparison operators, a constant is always - made the second operand. If a machine only supports a constant - as the second operand, only patterns that match a constant in the - second operand need be supplied. - - For these operators, if only one operand is a `neg', `not', - `mult', `plus', or `minus' expression, it will be the first - operand. - - * For the `compare' operator, a constant is always the second - operand on machines where `cc0' is used (*note Jump Patterns::.). - On other machines, there are rare cases where the compiler might - want to construct a `compare' with a constant as the first - operand. However, these cases are not common enough for it to be - worthwhile to provide a pattern matching a constant as the first - operand unless the machine actually has such an instruction. - - An operand of `neg', `not', `mult', `plus', or `minus' is made - the first operand under the same conditions as above. - - * `(minus X (const_int N))' is converted to `(plus X (const_int - -N))'. - - * Within address computations (i.e., inside `mem'), a left shift is - converted into the appropriate multiplication by a power of two. - - De`Morgan's Law is used to move bitwise negation inside a bitwise - logical-and or logical-or operation. If this results in only one - operand being a `not' expression, it will be the first one. - - A machine that has an instruction that performs a bitwise - logical-and of one operand with the bitwise negation of the other - should specify the pattern for that instruction as + 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'. - (define_insn "" - [(set (match_operand:M 0 ...) - (and:M (not:M (match_operand:M 1 ...)) - (match_operand:M 2 ...)))] - "..." - "...") + 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::. - Similarly, a pattern for a "NAND" instruction should be written + When simple substitution isn't general enough, you can specify a + piece of C code to compute the output. *Note Output Statement::. - (define_insn "" - [(set (match_operand:M 0 ...) - (ior:M (not:M (match_operand:M 1 ...)) - (not:M (match_operand:M 2 ...))))] - "..." - "...") - - In both cases, it is not necessary to include patterns for the - many logically equivalent RTL expressions. - - * The only possible RTL expressions involving both bitwise - exclusive-or and bitwise negation are `(xor:M X) Y)' and `(not:M - (xor:M X Y))'. - - * The sum of three items, one of which is a constant, will only - appear in the form - - (plus:M (plus:M X Y) CONSTANT) - - * On machines that do not use `cc0', `(compare X (const_int 0))' - will be converted to X. - - * Equality comparisons of a group of bits (usually a single bit) - with zero will be written using `zero_extract' rather than the - equivalent `and' or `sign_extract' operations. + 5. Optionally, a vector containing the values of attributes for insns + matching this pattern. *Note Insn Attributes::.  -File: gcc.info, Node: Peephole Definitions, Next: Expander Definitions, Prev: Insn Canonicalizations, Up: Machine Desc +File: gcc.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc -Defining Machine-Specific Peephole Optimizers -============================================= +Example of `define_insn' +======================== - In addition to instruction patterns the `md' file may contain -definitions of machine-specific peephole optimizations. + Here is an actual example of an instruction pattern, for the +68000/68020. - The combiner does not notice certain peephole optimizations when -the data flow in the program does not suggest that it should try them. - For example, sometimes two consecutive insns related in purpose can -be combined even though the second one does not appear to use a -register computed in the first one. A machine-specific peephole -optimizer can detect such opportunities. - - A definition looks like this: - - (define_peephole - [INSN-PATTERN-1 - INSN-PATTERN-2 - ...] - "CONDITION" - "TEMPLATE" - "OPTIONAL INSN-ATTRIBUTES") - -The last string operand may be omitted if you are not using any -machine-specific information in this machine description. If present, -it must obey the same rules as in a `define_insn'. - - In this skeleton, INSN-PATTERN-1 and so on are patterns to match -consecutive insns. The optimization applies to a sequence of insns -when INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the -next, and so on. - - Each of the insns matched by a peephole must also match a -`define_insn'. Peepholes are checked only at the last stage just -before code generation, and only optionally. Therefore, any insn which -would match a peephole but no `define_insn' will cause a crash in code -generation in an unoptimized compilation, or at various optimization -stages. - - The operands of the insns are matched with `match_operands', -`match_operator', and `match_dup', as usual. What is not usual is -that the operand numbers apply to all the insn patterns in the -definition. So, you can check for identical operands in two insns by -using `match_operand' in one insn and `match_dup' in the other. - - The operand constraints used in `match_operand' patterns do not have -any direct effect on the applicability of the peephole, but they will -be validated afterward, so make sure your constraints are general -enough to apply whenever the peephole matches. If the peephole matches -but the constraints are not satisfied, the compiler will crash. - - It is safe to omit constraints in all the operands of the peephole; -or you can write constraints which serve as a double-check on the -criteria previously tested. - - Once a sequence of insns matches the patterns, the CONDITION is -checked. This is a C expression which makes the final decision -whether to perform the optimization (we do so if the expression is -nonzero). If CONDITION is omitted (in other words, the string is -empty) then the optimization is applied to every sequence of insns -that matches the patterns. - - The defined peephole optimizations are applied after register -allocation is complete. Therefore, the peephole definition can check -which operands have ended up in which kinds of registers, just by -looking at the operands. - - The way to refer to the operands in CONDITION is to write -`operands[I]' for operand number I (as matched by `(match_operand I -...)'). Use the variable `insn' to refer to the last of the insns -being matched; use `prev_nonnote_insn' to find the preceding insns. - - When optimizing computations with intermediate results, you can use -CONDITION to match only when the intermediate results are not used -elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where -INSN is the insn in which you expect the value to be used for the last -time (from the value of `insn', together with use of -`prev_nonnote_insn'), and OP is the intermediate value (from -`operands[I]'). - - Applying the optimization means replacing the sequence of insns -with one new insn. The TEMPLATE controls ultimate output of assembler -code for this combined insn. It works exactly like the template of a -`define_insn'. Operand numbers in this template are the same ones -used in matching the original sequence of insns. - - The result of a defined peephole optimizer does not need to match -any of the insn patterns in the machine description; it does not even -have an opportunity to match them. The peephole optimizer definition -itself serves as the insn pattern to control how the insn is output. - - Defined peephole optimizers are run as assembler code is being -output, so the insns they produce are never combined or rearranged in -any way. - - Here is an example, taken from the 68000 machine description: - - (define_peephole - [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) - (set (match_operand:DF 0 "register_operand" "f") - (match_operand:DF 1 "register_operand" "ad"))] - "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" + (define_insn "tstsi" + [(set (cc0) + (match_operand:SI 0 "general_operand" "rm"))] + "" "* - { - rtx xoperands[2]; - xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1); - #ifdef MOTOROLA - output_asm_insn (\"move.l %1,(sp)\", xoperands); - output_asm_insn (\"move.l %1,-(sp)\", operands); - return \"fmove.d (sp)+,%0\"; - #else - output_asm_insn (\"movel %1,sp@\", xoperands); - output_asm_insn (\"movel %1,sp@-\", operands); - return \"fmoved sp@+,%0\"; - #endif - } - ") - - The effect of this optimization is to change - - jbsr _foobar - addql #4,sp - movel d1,sp@- - movel d0,sp@- - fmoved sp@+,fp0 - -into - - jbsr _foobar - movel d1,sp@ - movel d0,sp@- - fmoved sp@+,fp0 - - INSN-PATTERN-1 and so on look *almost* like the second operand of -`define_insn'. There is one important difference: the second operand -of `define_insn' consists of one or more RTX's enclosed in square -brackets. Usually, there is only one: then the same action can be -written as an element of a `define_peephole'. But when there are -multiple actions in a `define_insn', they are implicitly enclosed in a -`parallel'. Then you must explicitly write the `parallel', and the -square brackets within it, in the `define_peephole'. Thus, if an insn -pattern looks like this, - - (define_insn "divmodsi4" - [(set (match_operand:SI 0 "general_operand" "=d") - (div:SI (match_operand:SI 1 "general_operand" "0") - (match_operand:SI 2 "general_operand" "dmsK"))) - (set (match_operand:SI 3 "general_operand" "=d") - (mod:SI (match_dup 1) (match_dup 2)))] - "TARGET_68020" - "divsl%.l %2,%3:%0") - -then the way to mention this insn in a peephole is as follows: - - (define_peephole - [... - (parallel - [(set (match_operand:SI 0 "general_operand" "=d") - (div:SI (match_operand:SI 1 "general_operand" "0") - (match_operand:SI 2 "general_operand" "dmsK"))) - (set (match_operand:SI 3 "general_operand" "=d") - (mod:SI (match_dup 1) (match_dup 2)))]) - ...] - ...) + { if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) + return \"tstl %0\"; + return \"cmpl #0,%0\"; }") - -File: gcc.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Peephole Definitions, Up: Machine Desc + 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. -Defining RTL Sequences for Code Generation -========================================== + 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. - On some target machines, some standard pattern names for RTL -generation cannot be handled with single insn, but a sequence of RTL -insns can represent them. For these target machines, you can write a -`define_expand' to specify how to generate the sequence of RTL. - - A `define_expand' is an RTL expression that looks almost like a -`define_insn'; but, unlike the latter, a `define_expand' is used only -for RTL generation and it can produce more than one RTL insn. - - A `define_expand' RTX has four operands: - - * The name. Each `define_expand' must have a name, since the only - use for it is to refer to it by name. - - * The RTL template. This is just like the RTL template for a - `define_peephole' in that it is a vector of RTL expressions each - being one insn. - - * The condition, a string containing a C expression. This - expression is used to express how the availability of this - pattern depends on subclasses of target machine, selected by - command-line options when GNU CC is run. This is just like the - condition of a `define_insn' that has a standard name. - - * The preparation statements, a string containing zero or more C - statements which are to be executed before RTL code is generated - from the RTL template. - - Usually these statements prepare temporary registers for use as - internal operands in the RTL template, but they can also generate - RTL insns directly by calling routines such as `emit_insn', etc. - Any such insns precede the ones that come from the RTL template. - - Every RTL insn emitted by a `define_expand' must match some -`define_insn' in the machine description. Otherwise, the compiler -will crash when trying to generate code for the insn or trying to -optimize it. - - The RTL template, in addition to controlling generation of RTL -insns, also describes the operands that need to be specified when this -pattern is used. In particular, it gives a predicate for each operand. - - A true operand, which needs to be specified in order to generate -RTL from the pattern, should be described with a `match_operand' in -its first occurrence in the RTL template. This enters information on -the operand's predicate into the tables that record such things. GNU -CC uses the information to preload the operand into a register if that -is required for valid RTL code. If the operand is referred to more -than once, subsequent references should use `match_dup'. - - The RTL template may also refer to internal "operands" which are -temporary registers or labels used only within the sequence made by the -`define_expand'. Internal operands are substituted into the RTL -template with `match_dup', never with `match_operand'. The values of -the internal operands are not passed in as arguments by the compiler -when it requests use of this pattern. Instead, they are computed -within the pattern, in the preparation statements. These statements -compute the values and store them into the appropriate elements of -`operands' so that `match_dup' can find them. - - There are two special macros defined for use in the preparation -statements: `DONE' and `FAIL'. Use them with a following semicolon, -as a statement. - -`DONE' - Use the `DONE' macro to end RTL generation for the pattern. The - only RTL insns resulting from the pattern on this occasion will be - those already emitted by explicit calls to `emit_insn' within the - preparation statements; the RTL template will not be generated. - -`FAIL' - Make the pattern fail on this occasion. When a pattern fails, it - means that the pattern was not truly available. The calling - routines in the compiler will try other strategies for code - generation using other patterns. - - Failure is currently supported only for binary (addition, - multiplication, shifting, etc.) and bitfield (`extv', `extzv', - and `insv') operations. - - Here is an example, the definition of left-shift for the SPUR chip: - - (define_expand "ashlsi3" - [(set (match_operand:SI 0 "register_operand" "") - (ashift:SI - (match_operand:SI 1 "register_operand" "") - (match_operand:SI 2 "nonmemory_operand" "")))] - "" - " - { - if (GET_CODE (operands[2]) != CONST_INT - || (unsigned) INTVAL (operands[2]) > 3) - FAIL; - }") - -This example uses `define_expand' so that it can generate an RTL insn -for shifting when the shift-count is in the supported range of 0 to 3 -but fail in other cases where machine insns aren't available. When it -fails, the compiler tries another strategy using different patterns -(such as, a library call). - - If the compiler were able to handle nontrivial condition-strings in -patterns with names, then it would be possible to use a `define_insn' -in that case. Here is another case (zero-extension on the 68000) -which makes more use of the power of `define_expand': - - (define_expand "zero_extendhisi2" - [(set (match_operand:SI 0 "general_operand" "") - (const_int 0)) - (set (strict_low_part - (subreg:HI - (match_dup 0) - 0)) - (match_operand:HI 1 "general_operand" ""))] - "" - "operands[1] = make_safe_from (operands[1], operands[0]);") - -Here two RTL insns are generated, one to clear the entire output -operand and the other to copy the input operand into its low half. -This sequence is incorrect if the input operand refers to [the old -value of] the output operand, so the preparation statement makes sure -this isn't so. The function `make_safe_from' copies the `operands[1]' -into a temporary register if it refers to `operands[0]'. It does this -by emitting another RTL insn. - - Finally, a third example shows the use of an internal operand. -Zero-extension on the SPUR chip is done by `and'-ing the result -against a halfword mask. But this mask cannot be represented by a -`const_int' because the constant value is too large to be legitimate -on this machine. So it must be copied into a register with -`force_reg' and then the register used in the `and'. - - (define_expand "zero_extendhisi2" - [(set (match_operand:SI 0 "register_operand" "") - (and:SI (subreg:SI - (match_operand:HI 1 "register_operand" "") - 0) - (match_dup 2)))] - "" - "operands[2] - = force_reg (SImode, gen_rtx (CONST_INT, - VOIDmode, 65535)); ") - - *Note:* If the `define_expand' is used to serve a standard binary -or unary arithmetic operation or a bitfield operation, then the last -insn it generates must not be a `code_label', `barrier' or `note'. It -must be an `insn', `jump_insn' or `call_insn'. If you don't need a -real insn at the end, emit an insn to copy the result of the operation -into itself. Such an insn will generate no code, but it can avoid -problems in the compiler. + `"rm"' is an operand constraint. Its meaning is explained below.  -File: gcc.info, Node: Insn Splitting, Next: Insn Attributes, Prev: Expander Definitions, Up: Machine Desc +File: gcc.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc -Splitting Instructions into Multiple Instructions +RTL Template for Generating and Recognizing Insns ================================================= - On machines that have instructions requiring delay slots (*note -Delay Slots::.) or that have instructions whose output is not -available for multiple cycles (*note Function Units::.), the compiler -phases that optimize these cases need to be able to move insns into -one-cycle delay slots. However, some insns may generate more than one -machine instruction. These insns would be unable to be placed into a -delay slot. - - It is often possible to write the single insn as a list of -individual insns, each corresponding to one machine instruction. The -disadvantage of doing so is that it will cause the compilation to be -slower and require more space. If the resulting insns are too -complex, it may also suppress some optimizations. - - The `define_split' definition tells the compiler how to split a -complex insn into several simpler insns. This spilling will be -performed if there is a reason to believe that it might improve -instruction or delay slot scheduling. The definition looks like this: - - (define_split - [INSN-PATTERN] - "CONDITION" - [NEW-INSN-PATTERN-1 - NEW-INSN-PATTERN-2 - ...] - "PREPARATION STATEMENTS") - - INSN-PATTERN is a pattern that needs to be split and CONDITION is -the final condition to be tested, as in a `define_insn'. Any insn -matched by a `define_split' must also be matched by a `define_insn' in -case it does not need to be split. - - When an insn matching INSN-PATTERN and satisfying CONDITION is -found, it is replaced in the insn list with the insns given by -NEW-INSN-PATTERN-1, NEW-INSN-PATTERN-2, etc. - - The PREPARATION STATEMENTS are similar to those specified for -`define_expand' (*note Expander Definitions::.) and are executed -before the new RTL is generated to prepare for the generated code or -emit some insns whose pattern is not fixed. - - As a simple case, consider the following example from the AMD 29000 -machine description, which splits a `sign_extend' from `HImode' to -`SImode' into a pair of shift insns: - - (define_split - [(set (match_operand:SI 0 "gen_reg_operand" "") - (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] - "" - [(set (match_dup 0) - (ashift:SI (match_dup 1) - (const_int 16))) - (set (match_dup 0) - (ashiftrt:SI (match_dup 0) - (const_int 16)))] - " - { operands[1] = gen_lowpart (SImode, operands[1]); }") - - -File: gcc.info, Node: Insn Attributes, Prev: Insn Splitting, Up: Machine Desc - -Instruction Attributes -====================== - - In addition to describing the instruction supported by the target -machine, the `md' file also defines a group of "attributes" and a set -of values for each. Every generated insn is assigned a value for each -attribute. One possible attribute would be the effect that the insn -has on the machine's condition code. This attribute can then be used -by `NOTICE_UPDATE_CC' to track the condition codes. - -* Menu: - -* Defining Attributes:: Specifying attributes and their values. -* Expressions:: Valid expressions for attribute values. -* Tagging Insns:: Assigning attribute values to insns. -* Attr Example:: An example of assigning attributes. -* Insn Lengths:: Computing the length of insns. -* Constant Attributes:: Defining attributes that are constant. -* Delay Slots:: Defining delay slots required for a machine. -* Function Units:: Specifying information for insn scheduling. - - -File: gcc.info, Node: Defining Attributes, Next: Expressions, Prev: Insn Attributes, Up: Insn Attributes - -Defining Attributes and their Values ------------------------------------- - - The `define_attr' expression is used to define each attribute -required by the target machine. It looks like: - - (define_attr NAME LIST-OF-VALUES DEFAULT) - - NAME is a string specifying the name of the attribute being defined. - - LIST-OF-VALUES is either a string that specifies a comma-separated -list of values that can be assigned to the attribute, or a null string -to indicate that the attribute takes numeric values. - - DEFAULT is an attribute expression that gives the value of this -attribute for insns that match patterns whose definition does not -include an explicit value for this attribute. *Note Attr Example::, -for more information on the handling of defaults. *Note Constant -Attributes::, for information on attributes that do not depend on any -particular insn. - - For each defined attribute, a number of definitions are written to -the `insn-attr.h' file. For cases where an explicit set of values is -specified for an attribute, the following are defined: - - * A `#define' is written for the symbol `HAVE_ATTR_NAME'. - - * An enumeral class is defined for `attr_NAME' with elements of the - form `UPPER-NAME_UPPER-VALUE' where the attribute name and value - are first converted to upper case. - - * A function `get_attr_NAME' is defined that is passed an insn and - returns the attribute value for that insn. - - For example, if the following is present in the `md' file: + 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, PREDICATE is most often `"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"'. It would be valid to use + `"general_operand"', 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, 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 completely 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 them when necessary. *Note + Side Effects::. - (define_attr "type" "branch,fp,load,store,arith" ...) - -the following lines will be written to the file `insn-attr.h'. - - #define HAVE_ATTR_type - enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, - TYPE_STORE, TYPE_ARITH}; - extern enum attr_type get_attr_type (); - - If the attribute takes numeric values, no `enum' type will be -defined and the function to obtain the attribute's value will return -`int'. - - -File: gcc.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes - -Attribute Expressions ---------------------- - - RTL expressions used to define attributes use the codes described -above plus a few specific to attribute definitions, to be discussed -below. Attribute value expressions must have one of the following -forms: - -`(const_int I)' - The integer I specifies the value of a numeric attribute. I must - be non-negative. - - The value of a numeric attribute can be specified either with a - `const_int' or as an integer represented as a string in - `const_string', `eq_attr' (see below), and `set_attr' (*note - Tagging Insns::.) expressions. - -`(const_string VALUE)' - The string VALUE specifies a constant attribute value. If VALUE - is specified as `"*"', it means that the default value of the - attribute is to be used for the insn containing this expression. - `"*"' obviously cannot be used in the DEFAULT expression of a - `define_attr'. - - If the attribute whose value is being specified is numeric, VALUE - must be a string containing a non-negative integer (normally - `const_int' would be used in this case). Otherwise, it must - contain one of the valid values for the attribute. - -`(if_then_else TEST TRUE-VALUE FALSE-VALUE)' - TEST specifies an attribute test, whose format is defined below. - The value of this expression is TRUE-VALUE if TEST is true, - otherwise it is FALSE-VALUE. - -`(cond [TEST1 VALUE1 ...] DEFAULT)' - The first operand of this expression is a vector containing an - even number of expressions and consisting of pairs of TEST and - VALUE expressions. The value of the `cond' expression is that of - the VALUE corresponding to the first true TEST expression. If - none of the TEST expressions are true, the value of the `cond' - expression is that of the DEFAULT expression. - - TEST expressions can have one of the following forms: - -`(const_int I)' - This test is true if I is non-zero and false otherwise. - -`(not TEST)' -`(ior TEST1 TEST2)' -`(and TEST1 TEST2)' - These tests are true if the indicated logical function is true. - -`(match_operand:M N PRED CONSTRAINTS)' - This test is true if operand N of the insn whose attribute value - is being determined has mode M (this part of the test is ignored - if M is `VOIDmode') and the function specified by the string PRED - returns a non-zero value when passed operand N and mode M (this - part of the test is ignored if PRED is the null string). - - The CONSTRAINTS operand is ignored and should be the null string. - -`(le ARITH1 ARITH2)' -`(leu ARITH1 ARITH2)' -`(lt ARITH1 ARITH2)' -`(ltu ARITH1 ARITH2)' -`(gt ARITH1 ARITH2)' -`(gtu ARITH1 ARITH2)' -`(ge ARITH1 ARITH2)' -`(geu ARITH1 ARITH2)' -`(ne ARITH1 ARITH2)' -`(eq ARITH1 ARITH2)' - These tests are true if the indicated comparison of the two - arithmetic expressions is true. Arithmetic expressions are - formed with `plus', `minus', `mult', `div', `mod', `abs', `neg', - `and', `ior', `xor', `not', `lshift', `ashift', `lshiftrt', and - `ashiftrt' expressions. - - `const_int' and `symbol_ref' are always valid terms (*note Insn - Lengths::.,for additional forms). `symbol_ref' is a string - denoting a C expression that yields an `int' when evaluated by the - `get_attr_...' routine. It should normally be a global variable. - -`(eq_attr NAME VALUE)' - NAME is a string specifying the name of an attribute. - - VALUE is a string that is either a valid value for attribute - NAME, a comma-separated list of values, or `!' followed by a - value or list. If VALUE does not begin with a `!', this test is - true if the value of the NAME attribute of the current insn is in - the list specified by VALUE. If VALUE begins with a `!', this - test is true if the attribute's value is *not* in the specified - list. - - For example, - - (eq_attr "type" "load,store") - - is equivalent to - - (ior (eq_attr "type" "load") (eq_attr "type" "store")) - - If NAME specifies an attribute of `alternative', it refers to the - value of the compiler variable `which_alternative' (*note Output - Statement::.) and the values must be small integers. For example, - - (eq_attr "alternative" "2,3") - - is equivalent to - - (ior (eq (symbol_ref "which_alternative") (const_int 2)) - (eq (symbol_ref "which_alternative") (const_int 3))) - - Note that, for most attributes, an `eq_attr' test is simplified - in cases where the value of the attribute being tested is known - for all insns matching a particular pattern. This is by far the - most common case. - - -File: gcc.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes - -Assigning Attribute Values to Insns ------------------------------------ - - The value assigned to an attribute of an insn is primarily -determined by which pattern is matched by that insn (or which -`define_peephole' generated it). Every `define_insn' and -`define_peephole' can have an optional last argument to specify the -values of attributes for matching insns. The value of any attribute -not specified in a particular insn is set to the default value for -that attribute, as specified in its `define_attr'. Extensive use of -default values for attributes permits the specification of the values -for only one or two attributes in the definition of most insn -patterns, as seen in the example in the next section. - - The optional last argument of `define_insn' and `define_peephole' -is a vector of expressions, each of which defines the value for a -single attribute. The most general way of assigning an attribute's -value is to use a `set' expression whose first operand is an `attr' -expression giving the name of the attribute being set. The second -operand of the `set' is an attribute expression (*note Expressions::.) -giving the value of the attribute. - - When the attribute value depends on the `alternative' attribute -(i.e., which is the applicable alternative in the constraint of the -insn), the `set_attr_alternative' expression can can be used. It -allows the specification of a vector of attribute expressions, one for -each alternative. - - When the generality of arbitrary attribute expressions is not -required, the simpler `set_attr' expression can be used, which allows -specifying a string giving either a single attribute value or a list -of attribute values, one for each alternative. - - The form of each of the above specifications is shown below. In -each case, NAME is a string specifying the attribute to be set. - -`(set_attr NAME VALUE-STRING)' - VALUE-STRING is either a string giving the desired attribute - value, or a string containing a comma-separated list giving the - values for succeeding alternatives. The number of elements must - match the number of alternatives in the constraint of the insn - pattern. - - Note that it may be useful to specify `*' for some alternative, in - which case the attribute will assume its default value for insns - matching that alternative. - -`(set_attr_alternative NAME [VALUE1 VALUE2 ...])' - Depending on the alternative of the insn, the value will be one - of the specified values. This is a shorthand for using a `cond' - with tests on the `alternative' attribute. - -`(set (attr NAME) VALUE)' - The first operand of this `set' must be the special RTL expression - `attr', whose sole operand is a string giving the name of the - attribute being set. VALUE is the value of the attribute. +`(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. - The following shows three different ways of representing the same -attribute value specification: + In construction, `match_dup' behaves exactly 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 contains a variable number of + elements in a `parallel'. For example, - (set_attr "type" "load,store,arith") - - (set_attr_alternative "type" - [(const_string "load") (const_string "store") - (const_string "arith")]) - - (set (attr "type") - (cond [(eq_attr "alternative" "1") (const_string "load") - (eq_attr "alternative" "2") (const_string "store")] - (const_string "arith"))) - - The `define_asm_attributes' expression provides a mechanism to -specify the attributes assigned to insns produced from an `asm' -statement. It has the form: - - (define_asm_attributes [ATTR-SETS]) - -where ATTR-SETS is specified the same as for `define_insn' and -`define_peephole' expressions. - - These values will typically be the "worst case" attribute values. -For example, they might indicate that the condition code will be -clobbered. - - A specification for a `length' attribute is handled specially. To -compute the length of an `asm' insn, the length specified in the -`define_asm_attributes' expression is multiplied by the number of -machine instructions specified in the `asm' statement, determined by -counting the number of semicolons and newlines in the string. -Therefore, the value of the `length' attribute specified in a -`define_asm_attributes' should be the maximum possible length of a -single machine instruction. + (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 + +Output Templates and Operand Substitution +========================================= + + 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. - -File: gcc.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes + `%lDIGIT' is used to substitute a `label_ref' into a jump +instruction. -Example of Attribute Specifications ------------------------------------ + `%=' 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. + + +File: gcc.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc + +C Statements for Generating Assembler Output +============================================ + + Often a single fixed template string cannot produce correct and +efficient assembler code for all the cases that are recognized by a +single instruction pattern. For example, the opcodes may depend on the +kinds of operands; or some unfortunate combinations of operands may +require extra machine instructions. + + If the output control string starts with a `@', then it is actually +a series of templates, each on a separate line. (Blank lines and +leading spaces and tabs are ignored.) The templates correspond to the +pattern's constraint alternatives (*note Multi-Alternative::.). For +example, if a target machine has a two-address add instruction `addr' +to add into a register and another `addm' to add a register to memory, +you might write this pattern: + + (define_insn "addsi3" + [(set (match_operand:SI 0 "general_operand" "=r,m") + (plus:SI (match_operand:SI 1 "general_operand" "0,0") + (match_operand:SI 2 "general_operand" "g,r")))] + "" + "@ + addr %2,%0 + addm %2,%0") - The judicious use of defaulting is important in the efficient use of -insn attributes. Typically, insns are divided into "types" and an -attribute, customarily called `type', is used to represent this value. - This attribute is normally used only to define the default value for -other attributes. An example will clarify this usage. - - Assume we have a RISC machine with a condition code and in which -only full-word operations are performed in registers. Let us assume -that we can divide all insns into loads, stores, (integer) arithmetic -operations, floating point operations, and branches. - - Here we will concern ourselves with determining the effect of an -insn on the condition code and will limit ourselves to the following -possible effects: The condition code can be set unpredictably -(clobbered), not be changed, be set to agree with the results of the -operation, or only changed if the item previously set into the -condition code has been modified. + If the output control string starts with a `*', then it is not an +output template but rather a piece of C program that should compute a +template. It should execute a `return' statement to return the +template-string you want. Most such templates use C string literals, +which require doublequote characters to delimit them. To include these +doublequote characters in the string, prefix each one with `\'. + + The operands may be found in the array `operands', whose C data type +is `rtx []'. + + It is very common to select different ways of generating assembler +code based on whether an immediate operand is within a certain range. +Be careful when doing this, because the result of `INTVAL' is an +integer on the host machine. If the host machine has more bits in an +`int' than the target machine has in the mode in which the constant +will be used, then some of the bits you get from `INTVAL' will be +superfluous. For proper results, you must carefully disregard the +values of those bits. + + It is possible to output an assembler instruction and then go on to +output or compute more of them, using the subroutine `output_asm_insn'. + This receives two arguments: a template-string and a vector of +operands. The vector may be `operands', or it may be another array of +`rtx' that you declare locally and initialize yourself. + + When an insn pattern has multiple alternatives in its constraints, +often the appearance of the assembler code is determined mostly by +which alternative was matched. When this is so, the C code can test +the variable `which_alternative', which is the ordinal number of the +alternative that was actually satisfied (0 for the first, 1 for the +second alternative, etc.). + + For example, suppose there are two opcodes for storing zero, `clrreg' +for registers and `clrmem' for memory locations. Here is how a pattern +could use `which_alternative' to choose between them: - Here is part of a sample `md' file for such a machine: + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "=r,m") + (const_int 0))] + "" + "* + return (which_alternative == 0 + ? \"clrreg %0\" : \"clrmem %0\"); + ") + + The example above, where the assembler code to generate was *solely* +determined by the alternative, could also have been specified as +follows, having the output control string start with a `@': - (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) - - (define_attr "cc" "clobber,unchanged,set,change0" - (cond [(eq_attr "type" "load") - (const_string "change0") - (eq_attr "type" "store,branch") - (const_string "unchanged") - (eq_attr "type" "arith") - (if_then_else (match_operand:SI 0 "" "") - (const_string "set") - (const_string "clobber"))] - (const_string "clobber"))) - (define_insn "" - [(set (match_operand:SI 0 "general_operand" "=r,r,m") - (match_operand:SI 1 "general_operand" "r,m,r"))] + [(set (match_operand:SI 0 "general_operand" "=r,m") + (const_int 0))] "" "@ - move %0,%1 - load %0,%1 - store %0,%1" - [(set_attr "type" "arith,load,store")]) - - Note that we assume in the above example that arithmetic operations -performed on quantities smaller than a machine word clobber the -condition code since they will set the condition code to a value -corresponding to the full-word result. + clrreg %0 + clrmem %0")  -File: gcc.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes +File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc -Computing the Length of an Insn -------------------------------- +Operand Constraints +=================== - For many machines, multiple types of branch instructions are -provided, each for different length branch displacements. In most -cases, the assembler will choose the correct instruction to use. -However, when the assembler cannot do so, GCC can when a special -attribute, the `length' attribute, is defined. This attribute must be -defined to have numeric values by specifying a null string in its -`define_attr'. + Each `match_operand' in an instruction pattern can specify a +constraint for the type of operands allowed. Constraints can say +whether an operand may be in a register, and which kinds of register; +whether the operand can be a memory reference, and which kinds of +address; whether the operand may be an immediate constant, and which +possible values it may have. Constraints can also require two operands +to match. - In the case of the `length' attribute, two additional forms of -arithmetic terms are allowed in test expressions: +* Menu: -`(match_dup N)' - This refers to the address of operand N of the current insn, which - must be a `label_ref'. +* Simple Constraints:: Basic use of constraints. +* Multi-Alternative:: When an insn has two alternative constraint-patterns. +* Class Preferences:: Constraints guide which hard register to put things in. +* Modifiers:: More precise control over effects of constraints. +* No Constraints:: Describing a clean machine without constraints. + + +File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Prev: Constraints, Up: Constraints + +Simple Constraints +------------------ + + The simplest kind of constraint is a string full of letters, each of +which describes one kind of operand that is permitted. Here are the +letters that are allowed: + +`m' + A memory operand is allowed, with any kind of address that the + machine supports in general. + +`o' + A memory operand is allowed, but only if the address is + "offsettable". This means that adding a small integer (actually, + the width in bytes of the operand, as determined by its machine + mode) may be added to the address and the result is also a valid + memory address. + + For example, an address which is constant is offsettable; so is an + address that is the sum of a register and a constant (as long as a + slightly larger constant is also within the range of + address-offsets supported by the machine); but an autoincrement or + autodecrement address is not offsettable. More complicated + indirect/indexed addresses may or may not be offsettable depending + on the other addressing modes that the machine supports. + + Note that in an output operand which can be matched by another + operand, the constraint letter `o' is valid only when accompanied + by both `<' (if the target machine has predecrement addressing) + and `>' (if the target machine has preincrement addressing). + +`V' + A memory operand that is not offsettable. In other words, + anything that would fit the `m' constraint but not the `o' + constraint. + +`<' + A memory operand with autodecrement addressing (either + predecrement or postdecrement) is allowed. + +`>' + A memory operand with autoincrement addressing (either + preincrement or postincrement) is allowed. + +`r' + A register operand is allowed provided that it is in a general + register. + +`d', `a', `f', ... + Other letters can be defined in machine-dependent fashion to stand + for particular classes of registers. `d', `a' and `f' are defined + on the 68000/68020 to stand for data, address and floating point + registers. + +`i' + An immediate integer operand (one with constant value) is allowed. + This includes symbolic constants whose values will be known only at + assembly time. + +`n' + An immediate integer operand with a known numeric value is allowed. + Many systems cannot support assembly-time constants for operands + less than a word wide. Constraints for these operands should use + `n' rather than `i'. + +`I', `J', `K', ... `P' + Other letters in the range `I' through `P' may be defined in a + machine-dependent fashion to permit immediate integer operands with + explicit integer values in specified ranges. For example, on the + 68000, `I' is defined to stand for the range of values 1 to 8. + This is the range permitted as a shift count in the shift + instructions. + +`E' + An immediate floating operand (expression code `const_double') is + allowed, but only if the target floating point format is the same + as that of the host machine (on which the compiler is running). + +`F' + An immediate floating operand (expression code `const_double') is + allowed. + +`G', `H' + `G' and `H' may be defined in a machine-dependent fashion to + permit immediate floating operands in particular ranges of values. + +`s' + An immediate integer operand whose value is not an explicit + integer is allowed. + + This might appear strange; if an insn allows a constant operand + with a value not known at compile time, it certainly must allow + any known value. So why use `s' instead of `i'? Sometimes it + allows better code to be generated. + + For example, on the 68000 in a fullword instruction it is possible + to use an immediate operand; but if the immediate value is between + -128 and 127, better code results from loading the value into a + register and using the register. This is because the load into + the register can be done with a `moveq' instruction. We arrange + for this to happen by defining the letter `K' to mean "any integer + outside the range -128 to 127", and then specifying `Ks' in the + operand constraints. + +`g' + Any register, memory or immediate integer operand is allowed, + except for registers that are not general registers. + +`X' + Any operand whatsoever is allowed, even if it does not satisfy + `general_operand'. This is normally used in the constraint of a + `match_scratch' when certain alternatives will not actually + require a scratch register. + +`0', `1', `2', ... `9' + An operand that matches the specified operand number is allowed. + If a digit is used together with letters within the same + alternative, the digit should come last. + + This is called a "matching constraint" and what it really means is + that the assembler has only a single operand that fills two roles + considered separate in the RTL insn. For example, an add insn has + two input operands and one output operand in the RTL, but on most + CISC machines an add instruction really has only two operands, one + of them an input-output operand: + + addl #35,r12 + + Matching constraints are used in these circumstances. More + precisely, the two operands that match must include one input-only + operand and one output-only operand. Moreover, the digit must be a + smaller number than the number of the operand that uses it in the + constraint. + + For operands to match in a particular case usually means that they + are identical-looking RTL expressions. But in a few special cases + specific kinds of dissimilarity are allowed. For example, `*x' as + an input operand will match `*x++' as an output operand. For + proper results in such cases, the output template should always + use the output-operand's number when printing the operand. + +`p' + An operand that is a valid memory address is allowed. This is for + "load address" and "push address" instructions. + + `p' in the constraint must be accompanied by `address_operand' as + the predicate in the `match_operand'. This predicate interprets + the mode specified in the `match_operand' as the mode of the memory + reference for which the address would be valid. + +`Q', `R', `S', ... `U' + Letters in the range `Q' through `U' may be defined in a + machine-dependent fashion to stand for arbitrary operand types. + The machine description macro `EXTRA_CONSTRAINT' is passed the + operand as its first argument and the constraint letter as its + second operand. + + A typical use for this would be to distinguish certain types of + memory references that affect other insn operands. + + Do not define these constraint letters to accept register + references (`reg'); the reload pass does not expect this and would + not handle it properly. + + In order to have valid assembler code, each operand must satisfy its +constraint. But a failure to do so does not prevent the pattern from +applying to an insn. Instead, it directs the compiler to modify the +code so that the constraint will be satisfied. Usually this is done by +copying an operand into a register. -`(pc)' - This refers to the address of the *current* insn. It might have - been more consistent with other usage to make this the address of - the *next* insn but this would be confusing because the length of - the current insn is to be computed. - - For normal insns, the length will be determined by value of the -`length' attribute. In the case of `addr_vec' and `addr_diff_vec' -insn patterns, the length will be computed as the number of vectors -multiplied by the size of each vector. - - The following macros can be used to refine the length computation: - -`FIRST_INSN_ADDRESS' - When the `length' insn attribute is used, this macro specifies the - value to be assigned to the address of the first insn in a - function. If not specified, 0 is used. - -`ADJUST_INSN_LENGTH (INSN, LENGTH)' - If defined, modifies the length assigned to instruction INSN as a - function of the context in which it is used. LENGTH is an lvalue - that contains the initially computed length of the insn and - should be updated with the correct length of the insn. If - updating is required, INSN must not be a varying-length insn. - - This macro will normally not be required. A case in which it is - required is the ROMP. On this machine, the size of an `addr_vec' - insn must be increased by two to compensate for the fact that - alignment may be required. - - The routine that returns the value of the `length' attribute, -`get_attr_length', can be used by the output routine to determine the -form of the branch instruction to be written, as the example below -illustrates. - - As an example of the specification of variable-length branches, -consider the IBM 360. If we adopt the convention that a register will -be set to the starting address of a function, we can jump to labels -within 4K of the start using a four-byte instruction. Otherwise, we -need a six-byte sequence to load the address from memory and then -branch to it. - - On such a machine, a pattern for a branch instruction might be -specified as follows: - - (define_insn "jump" - [(set (pc) - (label_ref (match_operand 0 "" "")))] - "" - "* - { - return (get_attr_length (insn) == 4 - ? \"b %l0\" : \"l r15,=a(%l0); br r15\"); - }" - [(set (attr "length") (if_then_else (lt (match_dup 0) (const_int 4096)) - (const_int 4) - (const_int 6)))]) + Contrast, therefore, the two instruction patterns that follow: - -File: gcc.info, Node: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "=r") + (plus:SI (match_dup 0) + (match_operand:SI 1 "general_operand" "r")))] + "" + "...") -Constant Attributes -------------------- +which has two operands, one of which must appear in two places, and - A special form of DEFINE_ATTR, where the expression for the default -value is a CONST expression, indicates an attribute that is constant -for a given run of the compiler. Constant attributes may be used to -specify which variety of processor is used. For example, - - (define_attr "cpu" "m88100,m88110,m88000" - (const - (cond [(symbol_ref "TARGET_88100") (const_string "m88100") - (symbol_ref "TARGET_88110") (const_string "m88110")] - (const_string "m88000")))) - - (define_attr "memory" "fast,slow" - (const - (if_then_else (symbol_ref "TARGET_FAST_MEM") - (const_string "fast") - (const_string "slow")))) - - The routine generated for constant attributes has no parameters as -it does not depend on any particular insn. RTL expressions used to -define the value of a constant attribute may use the SYMBOL_REF form, -but may not use either the MATCH_OPERAND form or EQ_ATTR forms -involving insn attributes. + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "=r") + (plus:SI (match_operand:SI 1 "general_operand" "0") + (match_operand:SI 2 "general_operand" "r")))] + "" + "...") - -File: gcc.info, Node: Delay Slots, Next: Function Units, Prev: Constant Attributes, Up: Insn Attributes +which has three operands, two of which are required by a constraint to +be identical. If we are considering an insn of the form -Delay Slot Scheduling ---------------------- + (insn N PREV NEXT + (set (reg:SI 3) + (plus:SI (reg:SI 6) (reg:SI 109))) + ...) - The insn attribute mechanism can be used to specify the -requirements for delay slots, if any, on a target machine. An -instruction is said to require a "delay slot" if some instructions -that are physically after the instruction are executed as if they were -located before it. Classic examples are branch and call instructions, -which often execute the following instruction before the branch or -call is performed. - - On some machines, conditional branch instructions can optionally -"annul" instructions in the delay slot. This means that the -instruction will not be executed for certain branch outcomes. Both -instructions that annul if the branch is true and instructions that -annul if the branch is false are supported. - - Delay slot scheduling differs from instruction scheduling in that -determining whether an instruction needs a delay slot is dependent only -on the type of instruction being generated, not on data flow between -the instructions. See the next section for a discussion of -data-dependent instruction scheduling. - - The requirement of an insn needing one or more delay slots is -indicated via the `define_delay' expression. It has the following -form: - - (define_delay TEST - [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 - DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 - ...]) - - TEST is an attribute test that indicates whether this -`define_delay' applies to a particular insn. If so, the number of -required delay slots is determined by the length of the vector -specified as the second argument. An insn placed in delay slot N must -satisfy attribute test DELAY-N. ANNUL-TRUE-N is an attribute test -that specifies which insns may be annulled if the branch is true. -Similarly, ANNUL-FALSE-N specifies which insns in the delay slot may -be annulled if the branch is false. If annulling is not supported for -that delay slot, `(nil)' should be coded. - - For example, in the common case where branch and call insns require -a single delay slot, which may contain any insn other than a branch or -call, the following would be placed in the `md' file: - - (define_delay (eq_attr "type" "branch,call") - [(eq_attr "type" "!branch,call") (nil) (nil)]) - - Multiple `define_delay' expressions may be specified. In this -case, each such expression specifies different delay slot requirements -and there must be no insn for which tests in two `define_delay' -expressions are both true. - - For example, if we have a machine that requires one delay slot for -branches but two for calls, no delay slot can contain a branch or -call insn, and any valid insn in the delay slot for the branch can be -annulled if the branch is true, we might represent this as follows: +the first pattern would not apply at all, because this insn does not +contain two identical subexpressions in the right place. The pattern +would say, "That does not look like an add instruction; try other +patterns." The second pattern would say, "Yes, that's an add +instruction, but there is something wrong with it." It would direct +the reload pass of the compiler to generate additional insns to make +the constraint true. The results might look like this: - (define_delay (eq_attr "type" "branch") - [(eq_attr "type" "!branch,call") (eq_attr "type" "!branch,call") (nil)]) + (insn N2 PREV N + (set (reg:SI 3) (reg:SI 6)) + ...) - (define_delay (eq_attr "type" "call") - [(eq_attr "type" "!branch,call") (nil) (nil) - (eq_attr "type" "!branch,call") (nil) (nil)]) - - -File: gcc.info, Node: Function Units, Prev: Delay Slots, Up: Insn Attributes - -Specifying Function Units -------------------------- + (insn N N2 NEXT + (set (reg:SI 3) + (plus:SI (reg:SI 3) (reg:SI 109))) + ...) - On most RISC machines, there are instructions whose results are not -available for a specific number of cycles. Common cases are -instructions that load data from memory. On many machines, a pipeline -stall will result if the data is referenced too soon after the load -instruction. + It is up to you to make sure that each operand, in each pattern, has +constraints that can handle any RTL expression that could be present for +that operand. (When multiple alternatives are in use, each pattern +must, for each possible combination of operand expressions, have at +least one alternative which can handle that combination of operands.) +The constraints don't need to *allow* any possible operand--when this is +the case, they do not constrain--but they must at least point the way to +reloading any possible operand so that it will fit. + + * If the constraint accepts whatever operands the predicate permits, + there is no problem: reloading is never necessary for this operand. + + For example, an operand whose constraints permit everything except + registers is safe provided its predicate rejects registers. + + An operand whose predicate accepts only constant values is safe + provided its constraints include the letter `i'. If any possible + constant value is accepted, then nothing less than `i' will do; if + the predicate is more selective, then the constraints may also be + more selective. + + * Any operand expression can be reloaded by copying it into a + register. So if an operand's constraints allow some kind of + register, it is certain to be safe. It need not permit all + classes of registers; the compiler knows how to copy a register + into another register of the proper class in order to make an + instruction valid. + + * A nonoffsettable memory reference can be reloaded by copying the + address into a register. So if the constraint uses the letter + `o', all memory references are taken care of. + + * A constant operand can be reloaded by allocating space in memory to + hold it as preinitialized data. Then the memory reference can be + used in place of the constant. So if the constraint uses the + letters `o' or `m', constant operands are not a problem. + + * If the constraint permits a constant and a pseudo register used in + an insn was not allocated to a hard register and is equivalent to + a constant, the register will be replaced with the constant. If + the predicate does not permit a constant and the insn is + re-recognized for some reason, the compiler will crash. Thus the + predicate must always recognize any objects allowed by the + constraint. + + If the operand's predicate can recognize registers, but the +constraint does not permit them, it can make the compiler crash. When +this operand happens to be a register, the reload pass will be stymied, +because it does not know how to copy a register temporarily into memory. + + +File: gcc.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints + +Multiple Alternative Constraints +-------------------------------- + + Sometimes a single instruction has multiple alternative sets of +possible operands. For example, on the 68000, a logical-or instruction +can combine register or an immediate value into memory, or it can +combine any kind of operand into a register; but it cannot combine one +memory location into another. + + These constraints are represented as multiple alternatives. An +alternative can be described by a series of letters for each operand. +The overall constraint for an operand is made from the letters for this +operand from the first alternative, a comma, the letters for this +operand from the second alternative, a comma, and so on until the last +alternative. Here is how it is done for fullword logical-or on the +68000: + + (define_insn "iorsi3" + [(set (match_operand:SI 0 "general_operand" "=m,d") + (ior:SI (match_operand:SI 1 "general_operand" "%0,0") + (match_operand:SI 2 "general_operand" "dKs,dmKs")))] + ...) - In addition, many newer microprocessors have multiple function -units, usually one for integer and one for floating point, and often -will incur pipeline stalls when a result that is needed is not yet -ready. - - The descriptions in this section allow the specification of how much -time must elapse between the execution of an instruction and the time -when its result is used. It also allows specification of when the -execution of an instruction will delay execution of similar -instructions due to function unit conflicts. - - For the purposes of the specifications in this section, a machine is -divided into "function units", each of which execute a specific class -of instructions. Function units that accept one instruction each -cycle and allow a result to be used in the succeeding instruction -(usually via forwarding) need not be specified. Classic RISC -microprocessors will normally have a single function unit, which we can -call `memory'. The newer "superscalar" processors will often have -function units for floating point operations, usually at least a -floating point adder and multiplier. - - Each usage of a function units by a class of insns is specified -with a `define_function_unit' expression, which looks like this: - - (define_function_unit NAME MULTIPLICITY SIMULTANEITY - TEST READY-DELAY BUSY-DELAY - [CONFLICT-LIST]) - - NAME is a string giving the name of the function unit. - - MULTIPLICITY is an integer specifying the number of identical units -in the processor. If more than one unit is specified, they will be -scheduled independently. Only truly independent units should be -counted; a pipelined unit should be specified as a single unit. (The -only common example of a machine that has multiple function units for a -single instruction class that are truly independent and not pipelined -are the two multiply and two increment units of the CDC 6600.) - - SIMULTANEITY specifies the maximum number of insns that can be -executing in each instance of the function unit simultaneously or zero -if the unit is pipelined and has no limit. - - All `define_function_unit' definitions referring to function unit -NAME must have the same name and values for MULTIPLICITY and -SIMULTANEITY. - - TEST is an attribute test that selects the insns we are describing -in this definition. Note that an insn may use more than one function -unit and a function unit may be specified in more than one -`define_function_unit'. - - READY-DELAY is an integer that specifies the number of cycles after -which the result of the instruction can be used without introducing -any stalls. - - BUSY-DELAY is an integer that represents the default cost if an -insn is scheduled for this unit while the unit is active with another -insn. If SIMULTANEITY is zero, this specification is ignored. -Otherwise, a zero value indicates that these insns execute on NAME in -a fully pipelined fashion, even if SIMULTANEITY is non-zero. A -non-zero value indicates that scheduling a new insn on this unit while -another is active will incur a cost. A cost of two indicates a single -cycle delay. For a normal non-pipelined function unit, BUSY-DELAY -will be twice READY-DELAY. - - CONFLICT-LIST is an optional list giving detailed conflict costs -for this unit. If specified, it is a list of condition test -expressions which are applied to insns already executing in NAME. For -each insn that is in the list, BUSY-DELAY will be used for the conflict -cost, while a value of zero will be used for insns not in the list. - - Typical uses of this vector are where a floating point function -unit can pipeline either single- or double-precision operations, but -not both, or where a memory unit can pipeline loads, but not stores, -etc. - - As an example, consider a classic RISC machine where the result of a -load instruction is not available for two cycles (a single "delay" -instruction is required) and where only one load instruction can be -executed simultaneously. This would be specified as: - - (define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 4) - - For the case of a floating point function unit that can pipeline -either single or double precision, but not both, the following could -be specified: - - (define_function_unit - "fp" 1 1 (eq_attr "type" "sp_fp") 4 8 (eq_attr "type" "dp_fp")] - (define_function_unit - "fp" 1 1 (eq_attr "type" "dp_fp") 4 8 (eq_attr "type" "sp_fp")] - - *Note:* No code currently exists to avoid function unit conflicts, -only data conflicts. Hence MULTIPLICITY, SIMULTANEITY, BUSY-COST, and -CONFLICT-LIST are currently ignored. When such code is written, it is -possible that the specifications for these values may be changed. It -has recently come to our attention that these specifications may not -allow modeling of some of the newer "superscalar" processors that have -insns using multiple pipelined units. These insns will cause a -potential conflict for the second unit used during their execution and -there is no way of representing that conflict. We welcome any -examples of how function unit conflicts work in such processors and -suggestions for their representation. + The first alternative has `m' (memory) for operand 0, `0' for +operand 1 (meaning it must match operand 0), and `dKs' for operand 2. +The second alternative has `d' (data register) for operand 0, `0' for +operand 1, and `dmKs' for operand 2. The `=' and `%' in the +constraints apply to all the alternatives; their meaning is explained +in the next section (*note Class Preferences::.). + + If all the operands fit any one alternative, the instruction is +valid. Otherwise, for each alternative, the compiler counts how many +instructions must be added to copy the operands so that that +alternative applies. The alternative requiring the least copying is +chosen. If two alternatives need the same amount of copying, the one +that comes first is chosen. These choices can be altered with the `?' +and `!' characters: + +`?' + Disparage slightly the alternative that the `?' appears in, as a + choice when no alternative applies exactly. The compiler regards + this alternative as one unit more costly for each `?' that appears + in it. + +`!' + Disparage severely the alternative that the `!' appears in. This + alternative can still be used if it fits without reloading, but if + reloading is needed, some other alternative will be used. + + When an insn pattern has multiple alternatives in its constraints, +often the appearance of the assembler code is determined mostly by which +alternative was matched. When this is so, the C code for writing the +assembler code can use the variable `which_alternative', which is the +ordinal number of the alternative that was actually satisfied (0 for +the first, 1 for the second alternative, etc.). *Note Output +Statement::. + + +File: gcc.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints + +Register Class Preferences +-------------------------- + + The operand constraints have another function: they enable the +compiler to decide which kind of hardware register a pseudo register is +best allocated to. The compiler examines the constraints that apply to +the insns that use the pseudo register, looking for the +machine-dependent letters such as `d' and `a' that specify classes of +registers. The pseudo register is put in whichever class gets the most +"votes". The constraint letters `g' and `r' also vote: they vote in +favor of a general register. The machine description says which +registers are considered general. + + Of course, on some machines all registers are equivalent, and no +register classes are defined. Then none of this complexity is relevant. + + +File: gcc.info, Node: Modifiers, Next: No Constraints, Prev: Class Preferences, Up: Constraints + +Constraint Modifier Characters +------------------------------ + +`=' + Means that this operand is write-only for this instruction: the + previous value is discarded and replaced by output data. + +`+' + Means that this operand is both read and written by the + instruction. + + When the compiler fixes up the operands to satisfy the constraints, + it needs to know which operands are inputs to the instruction and + which are outputs from it. `=' identifies an output; `+' + identifies an operand that is both input and output; all other + operands are assumed to be input only. + +`&' + Means (in a particular alternative) that this operand is written + before the instruction is finished using the input operands. + Therefore, this operand may not lie in a register that is used as + an input operand or as part of any memory address. + + `&' applies only to the alternative in which it is written. In + constraints with multiple alternatives, sometimes one alternative + requires `&' while others do not. See, for example, the `movdf' + insn of the 68000. + + `&' does not obviate the need to write `='. + +`%' + Declares the instruction to be commutative for this operand and the + following operand. This means that the compiler may interchange + the two operands if that is the cheapest way to make all operands + fit the constraints. This is often used in patterns for addition + instructions that really have only two operands: the result must + go in one of the arguments. Here for example, is how the 68000 + halfword-add instruction is defined: + + (define_insn "addhi3" + [(set (match_operand:HI 0 "general_operand" "=m,r") + (plus:HI (match_operand:HI 1 "general_operand" "%0,0") + (match_operand:HI 2 "general_operand" "di,g")))] + ...) + +`#' + Says that all following characters, up to the next comma, are to be + ignored as a constraint. They are significant only for choosing + register preferences. + +`*' + Says that the following character should be ignored when choosing + register preferences. `*' has no effect on the meaning of the + constraint as a constraint, and no effect on reloading. + + Here is an example: the 68000 has an instruction to sign-extend a + halfword in a data register, and can also sign-extend a value by + copying it into an address register. While either kind of + register is acceptable, the constraints on an address-register + destination are less strict, so it is best if register allocation + makes an address register its goal. Therefore, `*' is used so + that the `d' constraint letter (for data register) is ignored when + computing register preferences. + + (define_insn "extendhisi2" + [(set (match_operand:SI 0 "general_operand" "=*d,a") + (sign_extend:SI + (match_operand:HI 1 "general_operand" "0,g")))] + ...)  -File: gcc.info, Node: Target Macros, Next: Config, Prev: Machine Desc, Up: Top - -Target Description Macros -************************* - - In addition to the file `MACHINE.md', a machine description -includes a C header file conventionally given the name `MACHINE.h'. -This header file defines numerous macros that convey the information -about the target machine that does not fit into the scheme of the -`.md' file. The file `tm.h' should be a link to `MACHINE.h'. The -header file `config.h' includes `tm.h' and most compiler source files -include `config.h'. +File: gcc.info, Node: No Constraints, Prev: Modifiers, Up: Constraints -* Menu: +Not Using Constraints +--------------------- -* Driver:: Controlling how the driver runs the compilation passes. -* Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'. -* Storage Layout:: Defining sizes and alignments of data. -* Type Layout:: Defining sizes and properties of basic user data types. -* Registers:: Naming and describing the hardware registers. -* Register Classes:: Defining the classes of hardware registers. -* Stack and Calling:: Defining which way the stack grows and by how much. -* Varargs:: Defining the varargs macros. -* Trampolines:: Code set up at run time to enter a nested function. -* Library Calls:: Controlling how library routines are implicitly called. -* Addressing Modes:: Defining addressing modes valid for memory operands. -* Condition Code:: Defining how insns update the condition code. -* Costs:: Defining relative costs of different operations. -* Sections:: Dividing storage into text, data, and other sections. -* PIC:: Macros for position independent code. -* Assembler Format:: Defining how to write insns and pseudo-ops to output. -* Debugging Info:: Defining the format of debugging output. -* Cross-compilation:: Handling floating point for cross-compilers. -* Misc:: Everything else. + Some machines are so clean that operand constraints are not +required. For example, on the Vax, an operand valid in one context is +valid in any other context. On such a machine, every operand +constraint would be `g', excepting only operands of "load address" +instructions which are written as if they referred to a memory +location's contents but actual refer to its address. They would have +constraint `p'. + + For such machines, instead of writing `g' and `p' for all the +constraints, you can choose to write a description with empty +constraints. Then you write `""' for the constraint in every +`match_operand'. Address operands are identified by writing an +`address' expression around the `match_operand', not by their +constraints. + + When the machine description has just empty constraints, certain +parts of compilation are skipped, making the compiler faster. However, +few machines actually do not need constraints; all machine descriptions +now in existence use constraints.  \ No newline at end of file