--- gcc/gcc.info-11 2018/04/24 17:51:24 1.1 +++ gcc/gcc.info-11 2018/04/24 18:02:01 1.1.1.4 @@ -1,1091 +1,991 @@ -This is Info file gcc.info, produced by Makeinfo-1.43 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 Splitting, Next: Insn Attributes, Prev: Expander Definitions, 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. -Splitting Instructions into Multiple 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. - 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]); }") + 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'. - -File: gcc.info, Node: Insn Attributes, Prev: Insn Splitting, Up: Machine Desc + 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::. -Instruction Attributes -====================== + When simple substitution isn't general enough, you can specify a + piece of C code to compute the output. *Note Output Statement::. - 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. -* Delay Slots:: Defining delay slots required for a machine. -* Function Units:: Specifying information for insn scheduling. + 5. Optionally, a vector containing the values of attributes for insns + matching this pattern. *Note Insn Attributes::.  -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) +File: gcc.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc - NAME is a string specifying the name of the attribute being defined. +Example of `define_insn' +======================== - 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. + Here is an actual example of an instruction pattern, for the +68000/68020. - 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. - - For each defined attribute, a number of definitions are written to -the `insn-attr.h' file. For cases where an explicit set of values is -specified for an attribute, the following are defined: - - * A `#define' is written for the symbol `HAVE_ATTR_NAME'. - - * An enumeral class is defined for `attr_NAME' with elements of the - form `UPPER-NAME_UPPER-VALUE' where the attribute name and value - are first converted to upper case. - - * A function `get_attr_NAME' is defined that is passed an insn and - returns the attribute value for that insn. - - For example, if the following is present in the `md' file: - - (define_attr "type" "branch,fp,load,store,arith" ...) + (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\"; }") -the following lines will be written to the file `insn-attr.h'. + 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. - #define HAVE_ATTR_type - enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, - TYPE_STORE, TYPE_ARITH}; - extern enum attr_type get_attr_type (); + 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. - If the attribute takes numeric values, no `enum' type will be -defined and the function to obtain the attribute's value will return -`int'. + `"rm"' is an operand constraint. Its meaning is explained below.  -File: gcc.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes - -Attribute Expressions ---------------------- +File: gcc.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc - 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 +RTL Template for Generating and Recognizing Insns +================================================= -Assigning Attribute Values to Insns ------------------------------------ + 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::. - 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. +`(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. - 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. + 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; + } - The following shows three different ways of representing the same -attribute value specification: + Then the following pattern will match any RTL expression consisting + of a commutative operator applied to two general operands: - (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. + (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, + + (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: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes +File: gcc.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc -Example of Attribute Specifications ------------------------------------ +Output Templates and Operand Substitution +========================================= - 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. + 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. - Here is part of a sample `md' file for such a machine: + `%lDIGIT' is used to substitute a `label_ref' into a jump +instruction. - (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"))] + `%=' 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")))] "" "@ - move %0,%1 - load %0,%1 - store %0,%1" - [(set_attr "type" "arith,load,store")]) - - Note that we assume in the above example that arithmetic operations -performed on quantities smaller than a machine word clobber the -condition code since they will set the condition code to a value -corresponding to the full-word result. - - -File: gcc.info, Node: Insn Lengths, Next: Delay Slots, Prev: Attr Example, Up: Insn Attributes + addr %2,%0 + addm %2,%0") -Computing the Length of an Insn -------------------------------- + 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: - For many machines, multiple types of branch instructions are -provided, each for different length branch displacements. In most -cases, the assembler will choose the correct instruction to use. -However, when the assembler cannot do so, GCC can when a special -attribute, the `length' attribute, is defined. This attribute must be -defined to have numeric values by specifying a null string in its -`define_attr'. - - In the case of the `length' attribute, two additional forms of -arithmetic terms are allowed in test expressions: - -`(match_dup N)' - This refers to the address of operand N of the current insn, which - must be a `label_ref'. - -`(pc)' - This refers to the address of the *current* insn. It might have - been more consistent with other usage to make this the address of - the *next* insn but this would be confusing because the length of - the current insn is to be computed. - - For normal insns, the length will be determined by value of the -`length' attribute. In the case of `addr_vec' and `addr_diff_vec' -insn patterns, the length 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_value', 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 "" "")))] + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "=r,m") + (const_int 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)))]) + 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 `@': - -File: gcc.info, Node: Delay Slots, Next: Function Units, Prev: Insn Lengths, Up: Insn Attributes - -Delay Slot Scheduling ---------------------- - - The insn attribute mechanism can be used to specify the -requirements for delay slots, if any, on a target machine. An -instruction is said to require a "delay slot" if some instructions -that are physically after the instruction are executed as if they were -located before it. Classic examples are branch and call instructions, -which often execute the following instruction before the branch or -call is performed. - - On some machines, conditional branch instructions can optionally -"annul" instructions in the delay slot. This means that the -instruction will not be executed for certain branch outcomes. Both -instructions that annul if the branch is true and instructions that -annul if the branch is false are supported. - - Delay slot scheduling differs from instruction scheduling in that -determining whether an instruction needs a delay slot is dependent only -on the type of instruction being generated, not on data flow between -the instructions. See the next section for a discussion of -data-dependent instruction scheduling. - - The requirement of an insn needing one or more delay slots is -indicated via the `define_delay' expression. It has the following -form: - - (define_delay TEST - [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 - DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 - ...]) - - TEST is an attribute test that indicates whether this -`define_delay' applies to a particular insn. If so, the number of -required delay slots is determined by the length of the vector -specified as the second argument. An insn placed in delay slot N must -satisfy attribute test DELAY-N. ANNUL-TRUE-N is an attribute test -that specifies which insns may be annulled if the branch is true. -Similarly, ANNUL-FALSE-N specifies which insns in the delay slot may -be annulled if the branch is false. If annulling is not supported for -that delay slot, `(nil)' should be coded. - - For example, in the common case where branch and call insns require -a single delay slot, which may contain any insn other than a branch or -call, the following would be placed in the `md' file: - - (define_delay (eq_attr "type" "branch,call") - [(eq_attr "type" "!branch,call") (nil) (nil)]) - - Multiple `define_delay' expressions may be specified. In this -case, each such expression specifies different delay slot requirements -and there must be no insn for which tests in two `define_delay' -expressions are both true. - - For example, if we have a machine that requires one delay slot for -branches but two for calls, no delay slot can contain a branch or -call insn, and any valid insn in the delay slot for the branch can be -annulled if the branch is true, we might represent this as follows: - - (define_delay (eq_attr "type" "branch") - [(eq_attr "type" "!branch,call") (eq_attr "type" "!branch,call") (nil)]) - - (define_delay (eq_attr "type" "call") - [(eq_attr "type" "!branch,call") (nil) (nil) - (eq_attr "type" "!branch,call") (nil) (nil)]) - - -File: gcc.info, Node: Function Units, Prev: Delay Slots, Up: Insn Attributes - -Specifying Function Units -------------------------- - - On most RISC machines, there are instructions whose results are not -available for a specific number of cycles. Common cases are -instructions that load data from memory. On many machines, a pipeline -stall will result if the data is referenced too soon after the load -instruction. - - In addition, many newer microprocessors have multiple function -units, usually one for integer and one for floating point, and often -will incur pipeline stalls when a result that is needed is not yet -ready. - - The descriptions in this section allow the specification of how much -time must elapse between the execution of an instruction and the time -when its result is used. It also allows specification of when the -execution of an instruction will delay execution of similar -instructions due to function unit conflicts. - - For the purposes of the specifications in this section, a machine is -divided into "function units", each of which execute a specific class -of instructions. 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. + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "=r,m") + (const_int 0))] + "" + "@ + clrreg %0 + clrmem %0")  -File: gcc.info, Node: Machine Macros, Next: Config, Prev: Machine Desc, Up: Top +File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc -Machine Description Macros -************************** +Operand Constraints +=================== - 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'. + 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. * Menu: -* Driver:: Controlling how the driver runs the compilation passes. -* Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'. -* Storage Layout:: Defining sizes and alignments of data. -* Type Layout:: Defining sizes and properties of basic user data types. -* Registers:: Naming and describing the hardware registers. -* Register Classes:: Defining the classes of hardware registers. -* Stack and Calling:: Defining which way the stack grows and by how much. -* Varargs:: Defining the varargs macros. -* Trampolines:: Code set up at run time to enter a nested function. -* Library Calls:: Controlling how library routines are implicitly called. -* Addressing Modes:: Defining addressing modes valid for memory operands. -* Condition Code:: Defining how insns update the condition code. -* Costs:: Defining relative costs of different operations. -* Sections:: Dividing storage into text, data, and other sections. -* PIC:: Macros for position independent code. -* Assembler Format:: Defining how to write insns and pseudo-ops to output. -* Debugging Info:: Defining the format of debugging output. -* Cross-compilation:: Handling floating point for cross-compilers. -* Misc:: Everything else. - - -File: gcc.info, Node: Driver, Next: Run-time Target, Prev: Machine Macros, Up: Machine Macros - -Controlling the Compilation Driver, `gcc' -========================================= - -`SWITCH_TAKES_ARG (CHAR)' - A C expression which determines whether the option `-CHAR' takes - arguments. The value should be the number of arguments that - option takes--zero, for many options. - - By default, this macro is defined to handle the standard options - properly. You need not define it unless you wish to add - additional options which take arguments. - -`WORD_SWITCH_TAKES_ARG (NAME)' - A C expression which determines whether the option `-NAME' takes - arguments. The value should be the number of arguments that - option takes--zero, for many options. This macro rather than - `SWITCH_TAKES_ARG' is used for multi-character option names. - - By default, this macro is defined to handle the standard options - properly. You need not define it unless you wish to add - additional options which take arguments. - -`SWITCHES_NEED_SPACES' - A string-valued C expression which is nonempty if the linker - needs a space between the `-L' or `-o' option and its argument. - - If this macro is not defined, the default value is 0. - -`CPP_SPEC' - A C string constant that tells the GNU CC driver program options - to pass to CPP. It can also specify how to translate options you - give to GNU CC into options for GNU CC to pass to the CPP. - - Do not define this macro if it does not need to do anything. - -`SIGNED_CHAR_SPEC' - A C string constant that tells the GNU CC driver program options - to pass to CPP. By default, this macro is defined to pass the - option `-D__CHAR_UNSIGNED__' to CPP if `char' will be treated as - `unsigned char' by `cc1'. - - Do not define this macro unless you need to override the default - definition. - -`CC1_SPEC' - A C string constant that tells the GNU CC driver program options - to pass to `cc1'. It can also specify how to translate options - you give to GNU CC into options for GNU CC to pass to the `cc1'. - - Do not define this macro if it does not need to do anything. - -`CC1PLUS_SPEC' - A C string constant that tells the GNU CC driver program options - to pass to `cc1plus'. It can also specify how to translate - options you give to GNU CC into options for GNU CC to pass to the - `cc1plus'. - - Do not define this macro if it does not need to do anything. - -`ASM_SPEC' - A C string constant that tells the GNU CC driver program options - to pass to the assembler. It can also specify how to translate - options you give to GNU CC into options for GNU CC to pass to the - assembler. See the file `sun3.h' for an example of this. - - Do not define this macro if it does not need to do anything. - -`ASM_FINAL_SPEC' - A C string constant that tells the GNU CC driver program how to - run any programs which cleanup after the normal assembler. - Normally, this is not needed. See the file `mips.h' for an - example of this. - - Do not define this macro if it does not need to do anything. - -`LINK_SPEC' - A C string constant that tells the GNU CC driver program options - to pass to the linker. It can also specify how to translate - options you give to GNU CC into options for GNU CC to pass to the - linker. - - Do not define this macro if it does not need to do anything. - -`LIB_SPEC' - Another C string constant used much like `LINK_SPEC'. The - difference between the two is that `LIB_SPEC' is used at the end - of the command given to the linker. - - If this macro is not defined, a default is provided that loads - the standard C library from the usual place. See `gcc.c'. - -`STARTFILE_SPEC' - Another C string constant used much like `LINK_SPEC'. The - difference between the two is that `STARTFILE_SPEC' is used at - the very beginning of the command given to the linker. - - If this macro is not defined, a default is provided that loads the - standard C startup file from the usual place. See `gcc.c'. - -`ENDFILE_SPEC' - Another C string constant used much like `LINK_SPEC'. The - difference between the two is that `ENDFILE_SPEC' is used at the - very end of the command given to the linker. - - Do not define this macro if it does not need to do anything. - -`LINK_LIBGCC_SPECIAL' - Define this macro meaning that `gcc' should find the library - `libgcc.a' by hand, rather than passing the argument `-lgcc' to - tell the linker to do the search. - -`RELATIVE_PREFIX_NOT_LINKDIR' - Define this macro to tell `gcc' that it should only translate a - `-B' prefix into a `-L' linker option if the prefix indicates an - absolute file name. - -`STANDARD_EXEC_PREFIX' - Define this macro as a C string constant if you wish to override - the standard choice of `/usr/local/lib/gcc/' as the default - prefix to try when searching for the executable files of the - compiler. - -`MD_EXEC_PREFIX' - If defined, this macro is an additional prefix to try after - `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when - the `-b' option is used, or the compiler is built as a cross - compiler. - -`STANDARD_STARTFILE_PREFIX' - Define this macro as a C string constant if you wish to override - the standard choice of `/usr/local/lib/gcc/' as the default - prefix to try when searching for startup files such as `crt0.o'. - -`MD_STARTFILE_PREFIX' - If defined, this macro supplies an additional prefix to try after - the standard prefixes. `MD_EXEC_PREFIX' is not searched when the - `-b' option is used, or the compiler is built as a cross compiler. - -`LOCAL_INCLUDE_DIR' - Define this macro as a C string constant if you wish to override - the standard choice of `/usr/local/include' as the default prefix - to try when searching for local header files. `LOCAL_INCLUDE_DIR' - comes before `SYSTEM_INCLUDE_DIR' in the search order. - - Cross compilers do not use this macro and do not search either - `/usr/local/include' or its replacement. - -`SYSTEM_INCLUDE_DIR' - Define this macro as a C string constant if you wish to specify a - system-specific directory to search for header files before the - standard directory. `SYSTEM_INCLUDE_DIR' comes before - `STANDARD_INCLUDE_DIR' in the search order. - - Cross compilers do not use this macro and do not search the - directory specified. - -`STANDARD_INCLUDE_DIR' - Define this macro as a C string constant if you wish to override - the standard choice of `/usr/include' as the default prefix to - try when searching for header files. - - Cross compilers do not use this macro and do not search either - `/usr/include' or its replacement. - -`INCLUDE_DEFAULTS' - Define this macro if you wish to override the entire default - search path for include files. The default search path includes - `GPLUSPLUS_INCLUDE_DIR', `GCC_INCLUDE_DIR', `LOCAL_INCLUDE_DIR', - `SYSTEM_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition, - the macros `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are - defined automatically by `Makefile', and specify private search - areas for GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used - only for C++ programs. - - The definition should be an initializer for an array of - structures. Each array element should have two elements: the - directory name (a string constant) and a flag for C++-only - directories. Mark the end of the array with a null element. For - example, here is the definition used for VMS: - - #define INCLUDE_DEFAULTS \ - { \ - { "GNU_GXX_INCLUDE:", 1}, \ - { "GNU_CC_INCLUDE:", 0}, \ - { "SYS$SYSROOT:[SYSLIB.]", 0}, \ - { ".", 0}, \ - { 0, 0} \ - } +* 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. - Here is the order of prefixes tried for exec files: + Contrast, therefore, the two instruction patterns that follow: - 1. Any prefixes specified by the user with `-B'. - - 2. The environment variable `GCC_EXEC_PREFIX', if any. - - 3. The directories specified by the environment variable - `COMPILER_PATH'. - - 4. The macro `STANDARD_EXEC_PREFIX'. - - 5. `/usr/lib/gcc/'. - - 6. The macro `MD_EXEC_PREFIX', if any. - - Here is the order of prefixes tried for startfiles: - - 1. Any prefixes specified by the user with `-B'. - - 2. The environment variable `GCC_EXEC_PREFIX', if any. - - 3. The directories specified by the environment variable - `LIBRARY_PATH'. - - 4. The macro `STANDARD_EXEC_PREFIX'. - - 5. `/usr/lib/gcc/'. - - 6. The macro `MD_EXEC_PREFIX', if any. + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "=r") + (plus:SI (match_dup 0) + (match_operand:SI 1 "general_operand" "r")))] + "" + "...") - 7. The macro `MD_STARTFILE_PREFIX', if any. +which has two operands, one of which must appear in two places, and - 8. The macro `STANDARD_STARTFILE_PREFIX'. + (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")))] + "" + "...") - 9. `/lib/'. +which has three operands, two of which are required by a constraint to +be identical. If we are considering an insn of the form - 10. `/usr/lib/'. + (insn N PREV NEXT + (set (reg:SI 3) + (plus:SI (reg:SI 6) (reg:SI 109))) + ...) + +the first pattern would not apply at all, because this insn does not +contain two identical subexpressions in the right place. The pattern +would say, "That does not look like an add instruction; try other +patterns." The second pattern would say, "Yes, that's an add +instruction, but there is something wrong with it." It would direct +the reload pass of the compiler to generate additional insns to make +the constraint true. The results might look like this: + + (insn N2 PREV N + (set (reg:SI 3) (reg:SI 6)) + ...) + + (insn N N2 NEXT + (set (reg:SI 3) + (plus:SI (reg:SI 3) (reg:SI 109))) + ...) + + It is up to you to make sure that each operand, in each pattern, has +constraints that can handle any RTL expression that could be present for +that operand. (When multiple alternatives are in use, each pattern +must, for each possible combination of operand expressions, have at +least one alternative which can handle that combination of operands.) +The constraints don't need to *allow* any possible operand--when this is +the case, they do not constrain--but they must at least point the way to +reloading any possible operand so that it will fit. + + * If the constraint accepts whatever operands the predicate permits, + there is no problem: reloading is never necessary for this operand. + + For example, an operand whose constraints permit everything except + registers is safe provided its predicate rejects registers. + + An operand whose predicate accepts only constant values is safe + provided its constraints include the letter `i'. If any possible + constant value is accepted, then nothing less than `i' will do; if + the predicate is more selective, then the constraints may also be + more selective. + + * Any operand expression can be reloaded by copying it into a + register. So if an operand's constraints allow some kind of + register, it is certain to be safe. It need not permit all + classes of registers; the compiler knows how to copy a register + into another register of the proper class in order to make an + instruction valid. + + * A nonoffsettable memory reference can be reloaded by copying the + address into a register. So if the constraint uses the letter + `o', all memory references are taken care of. + + * A constant operand can be reloaded by allocating space in memory to + hold it as preinitialized data. Then the memory reference can be + used in place of the constant. So if the constraint uses the + letters `o' or `m', constant operands are not a problem. + + * If the constraint permits a constant and a pseudo register used in + an insn was not allocated to a hard register and is equivalent to + a constant, the register will be replaced with the constant. If + the predicate does not permit a constant and the insn is + re-recognized for some reason, the compiler will crash. Thus the + predicate must always recognize any objects allowed by the + constraint. + + If the operand's predicate can recognize registers, but the +constraint does not permit them, it can make the compiler crash. When +this operand happens to be a register, the reload pass will be stymied, +because it does not know how to copy a register temporarily into memory. + + +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")))] + ...) + + 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: Run-time Target, Next: Storage Layout, Prev: Driver, Up: Machine Macros - -Run-time Target Specification -============================= +File: gcc.info, Node: No Constraints, Prev: Modifiers, Up: Constraints -`CPP_PREDEFINES' - Define this to be a string constant containing `-D' options to - define the predefined macros that identify this machine and - system. These macros will be predefined unless the `-ansi' - option is specified. - - In addition, a parallel set of macros are predefined, whose names - are made by appending `__' at the beginning and at the end. These - `__' macros are permitted by the ANSI standard, so they are - predefined regardless of whether `-ansi' is specified. - - For example, on the Sun, one can use the following value: - - "-Dmc68000 -Dsun -Dunix" - - The result is to define the macros `__mc68000__', `__sun__' and - `__unix__' unconditionally, and the macros `mc68000', `sun' and - `unix' provided `-ansi' is not specified. - -`STDC_VALUE' - Define the value to be assigned to the built-in macro `__STDC__'. - The default is the value `1'. - -`extern int target_flags;' - This declaration should be present. - -`TARGET_...' - This series of macros is to allow compiler command arguments to - enable or disable the use of optional features of the target - machine. For example, one machine description serves both the - 68000 and the 68020; a command argument tells the compiler - whether it should use 68020-only instructions or not. This - command argument works by means of a macro `TARGET_68020' that - tests a bit in `target_flags'. - - Define a macro `TARGET_FEATURENAME' for each such option. Its - definition should test a bit in `target_flags'; for example: - - #define TARGET_68020 (target_flags & 1) - - One place where these macros are used is in the - condition-expressions of instruction patterns. Note how - `TARGET_68020' appears frequently in the 68000 machine - description file, `m68k.md'. Another place they are used is in - the definitions of the other macros in the `MACHINE.h' file. - -`TARGET_SWITCHES' - This macro defines names of command options to set and clear bits - in `target_flags'. Its definition is an initializer with a - subgrouping for each command option. - - Each subgrouping contains a string constant, that defines the - option name, and a number, which contains the bits to set in - `target_flags'. A negative number says to clear bits instead; - the negative of the number is which bits to clear. The actual - option name is made by appending `-m' to the specified name. - - One of the subgroupings should have a null string. The number in - this grouping is the default value for `target_flags'. Any - target options act starting with that value. - - Here is an example which defines `-m68000' and `-m68020' with - opposite meanings, and picks the latter as the default: - - #define TARGET_SWITCHES \ - { { "68020", 1}, \ - { "68000", -1}, \ - { "", 1}} - -`TARGET_OPTIONS' - This macro is similar to `TARGET_SWITCHES' but defines names of - command options that have values. Its definition is an - initializer with a subgrouping for each command option. - - Each subgrouping contains a string constant, that defines the - fixed part of the option name, and the address of a variable. - The variable, type `char *', is set to the variable part of the - given option if the fixed part matches. The actual option name - is made by appending `-m' to the specified name. - - Here is an example which defines `-mshort-data-NUMBER'. If the - given option is `-mshort-data-512', the variable `m88k_short_data' - will be set to the string `"512"'. - - extern char *m88k_short_data; - #define TARGET_OPTIONS { { "short-data-", &m88k_short_data } } - -`TARGET_VERSION' - This macro is a C statement to print on `stderr' a string - describing the particular machine description choice. Every - machine description should define `TARGET_VERSION'. For example: - - #ifdef MOTOROLA - #define TARGET_VERSION fprintf (stderr, " (68k, Motorola syntax)"); - #else - #define TARGET_VERSION fprintf (stderr, " (68k, MIT syntax)"); - #endif - -`OVERRIDE_OPTIONS' - Sometimes certain combinations of command options do not make - sense on a particular target machine. You can define a macro - `OVERRIDE_OPTIONS' to take account of this. This macro, if - defined, is executed once just after all the command options have - been parsed. - - Don't use this macro to turn on various extra optimizations for - `-O'. That is what `OPTIMIZATION_OPTIONS' is for. - -`OPTIMIZATION_OPTIONS (LEVEL)' - Some machines may desire to change what optimizations are - performed for various optimization levels. This macro, if - defined, is executed once just after the optimization level is - determined and before the remainder of the command options have - been parsed. Values set in this macro are used as the default - values for the other command line options. - - LEVEL is the optimization level specified; 2 if -O2 is specified, - 1 if -O is specified, and 0 if neither is specified. +Not Using Constraints +--------------------- - *Do not examine `write_symbols' in this macro!* The debugging - options are not supposed to alter the generated code. + 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