diff options
Diffstat (limited to 'gcc-1.40/gcc.info-7')
| -rw-r--r-- | gcc-1.40/gcc.info-7 | 970 |
1 files changed, 970 insertions, 0 deletions
diff --git a/gcc-1.40/gcc.info-7 b/gcc-1.40/gcc.info-7 new file mode 100644 index 0000000..ed72551 --- /dev/null +++ b/gcc-1.40/gcc.info-7 @@ -0,0 +1,970 @@ +Info file gcc.info, produced by Makeinfo, -*- Text -*- from input +file gcc.texinfo. + + This file documents the use and the internals of the GNU compiler. + + Copyright (C) 1988, 1989, 1990 Free Software Foundation, Inc. + + Permission is granted to make and distribute verbatim copies of +this manual provided the copyright notice and this permission notice +are preserved on all copies. + + Permission is granted to copy and distribute modified versions of +this manual under the conditions for verbatim copying, provided also +that the 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 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: Sharing, Prev: Calls, Up: RTL + +Structure Sharing Assumptions +============================= + + The compiler assumes that certain kinds of RTL expressions are +unique; there do not exist two distinct objects representing the same +value. In other cases, it makes an opposite assumption: that no RTL +expression object of a certain kind appears in more than one place in +the containing structure. + + These assumptions refer to a single function; except for the RTL +objects that describe global variables and external functions, no RTL +objects are common to two functions. + + * Each pseudo-register has only a single `reg' object to represent + it, and therefore only a single machine mode. + + * For any symbolic label, there is only one `symbol_ref' object + referring to it. + + * There is only one `const_int' expression with value zero, and + only one with value one. + + * There is only one `pc' expression. + + * There is only one `cc0' expression. + + * There is only one `const_double' expression with mode `SFmode' + and value zero, and only one with mode `DFmode' and value zero. + + * No `label_ref' appears in more than one place in the RTL + structure; in other words, it is safe to do a tree-walk of all + the insns in the function and assume that each time a + `label_ref' is seen it is distinct from all others that are seen. + + * Only one `mem' object is normally created for each static + variable or stack slot, so these objects are frequently shared + in all the places they appear. However, separate but equal + objects for these variables are occasionally made. + + * When a single `asm' statement has multiple output operands, a + distinct `asm_operands' RTX is made for each output operand. + However, these all share the vector which contains the sequence + of input operands. Because this sharing is used later on to + test whether two `asm_operands' RTX's come from the same + statement, the sharing must be guaranteed to be preserved. + + * No RTL object appears in more than one place in the RTL + structure except as described above. Many passes of the + compiler rely on this by assuming that they can modify RTL + objects in place without unwanted side-effects on other insns. + + * During initial RTL generation, shared structure is freely + introduced. After all the RTL for a function has been + generated, all shared structure is copied by `unshare_all_rtl' + in `emit-rtl.c', after which the above rules are guaranteed to + be followed. + + * During the combiner pass, shared structure with an insn can + exist temporarily. However, the shared structure is copied + before the combiner is finished with the insn. This is done by + `copy_substitutions' in `combine.c'. + + +File: gcc.info, Node: Machine Desc, Next: Machine Macros, Prev: RTL, Up: Top + +Machine Descriptions +******************** + + A machine description has two parts: a file of instruction +patterns (`.md' file) and a C header file of macro definitions. + + The `.md' file for a target machine contains a pattern for each +instruction that the target machine supports (or at least each +instruction that is worth telling the compiler about). It may also +contain comments. A semicolon causes the rest of the line to be a +comment, unless the semicolon is inside a quoted string. + + See the next chapter for information on the C header file. + +* Menu: + +* Patterns:: How to write instruction patterns. +* Example:: An explained example of a `define_insn' pattern. +* RTL Template:: The RTL template defines what insns match a pattern. +* Output Template:: The output template says how to make assembler code + from such an insn. +* Output Statement:: For more generality, write C code to output + the assembler code. +* Constraints:: When not all operands are general operands. +* Standard Names:: Names mark patterns to use for code generation. +* Pattern Ordering:: When the order of patterns makes a difference. +* Dependent Patterns:: Having one pattern may make you need another. +* Jump Patterns:: Special considerations for patterns for jump insns. +* Peephole Definitions::Defining machine-specific peephole optimizations. +* Expander Definitions::Generating a sequence of several RTL insns + for a standard operation. + + +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' and `match_dup' expressions that stand for + operands of the instruction. + + If the vector has only one element, that element is the + template for the instruction pattern. If the vector has + multiple elements, then the instruction pattern is a `parallel' + expression containing the elements described. + + 3. A condition. This is a string which contains a C expression + that is the final test to decide whether an insn body matches + this pattern. + + For a named pattern, the condition (if present) may not + depend on the data in the insn being matched, but only the + target-machine-type flags. The compiler needs to test these + conditions during initialization in order to learn exactly which + named instructions are available in a particular run. + + For nameless patterns, the condition is applied only when + matching an individual insn, and only after the insn has matched + the pattern's recognition template. The insn's operands may be + found in the vector `operands'. + + 4. The "output template": a string that says how to output matching + insns as assembler code. `%' in this string specifies where to + substitute the value of an operand. *Note Output Template::. + + When simple substitution isn't general enough, you can + specify a piece of C code to compute the output. *Note Output + Statement::. + + 5. Optionally, some "machine-specific information". The meaning of + this information is defined only by an individual machine + description; typically it might say whether this insn alters the + condition codes, or how many bytes of output it generates. + + This operand is written as a string containing a C + initializer (complete with braces) for the structure type + `INSN_MACHINE_INFO', whose definition is up to you (*note + Misc::.). + + +File: gcc.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc + +Example of `define_insn' +======================== + + Here is an actual example of an instruction pattern, for the +68000/68020. + + (define_insn "tstsi" + [(set (cc0) + (match_operand:SI 0 "general_operand" "rm"))] + "" + "* + { if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) + return \"tstl %0\"; + return \"cmpl #0,%0\"; }") + + This is an instruction that sets the condition codes based on the +value of a general operand. It has no condition, so any insn whose +RTL description has the form shown may be handled according to this +pattern. The name `tstsi' means "test a `SImode' value" and tells +the RTL generation pass that, when it is necessary to test such a +value, an insn to do so can be constructed using this pattern. + + The output control string is a piece of C code which chooses which +output template to return based on the kind of operand and the +specific type of CPU for which code is being generated. + + `"rm"' is an operand constraint. Its meaning is explained below. + + +File: gcc.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc + +RTL Template for Generating and Recognizing 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 PRED 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 PRED 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. + + PRED 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 it returns + zero, this instruction pattern fails to match. PRED 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. + + 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. + + Most often, PRED is `"general_operand"'. This function checks + that the putative operand is either a constant, a register or a + memory reference, and that it is valid for mode M. + + For an operand that must be a register, PRED 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, and it would prevent the register allocator + from doing the best possible job. + + For an operand that must be a constant, either PRED should be + `"immediate_operand"', or the instruction pattern's extra + condition should check for constants, 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_dup N)' + This expression is also a placeholder for operand number N. It + is used when the operand needs to appear more than once in the + insn. + + In construction, `match_dup' 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 + six 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 (code == PLUS || code == MULT || code == UMULT + || code == AND || code == IOR || code == XOR); + } + + Then the following pattern will match any RTL expression + consisting of a commutative operator applied to two general + operands: + + (match_operator:SI 2 "commutative_operator" + [(match_operand:SI 3 "general_operand" "g") + (match_operand:SI 4 "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 3 and 4 of the + insn. (This is done by the two instances of `match_operand'.) + Operand 2 of the insn will be the entire commutative expression: + use `GET_CODE (operands[2])' 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 2 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 3 and 4 of the gen-function. The subexpressions + of argument 2 are not used; only its expression code matters. + + 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. + +`(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. + + `%lDIGIT' is used to substitute a `label_ref' into a jump +instruction. + + `%' 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 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 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: + + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "r,m") + (const_int 0))] + "" + "* + return (which_alternative == 0 + ? \"clrreg %0\" : \"clrmem %0\"); + ") + + +File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc + +Operand Constraints +=================== + + 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: + +* 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). + + When the constraint letter `o' is used, the reload pass may + generate instructions which copy a nonoffsettable address into + an index register. The idea is that the register can be used as + a replacement offsettable address. But this method requires + that there be patterns to copy any kind of address into a + register. Auto-increment and auto-decrement addresses are an + exception; there need not be an instruction that can copy such + an address into a register, because reload handles these cases + specially. + + Most older machine designs have "load address" instructions + which do just what is needed here. Some RISC machines do not + advertise such instructions, but the possible addresses on these + machines are very limited, so it is easy to fake them. + +`<' + 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', ... + Other letters in the range `I' through `M' 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. + +`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. + +`N' (a digit) + An operand that matches operand number N is allowed. If a digit + is used together with letters, the digit should come last. + + This is called a "matching constraint" and what it really means + is that the assembler has only a single operand that fills two + roles considered separate in the RTL insn. For example, an add + insn has two input operands and one output operand in the RTL, + but on most machines an add instruction really has only two + operands, one of them an input-output operand. + + Matching constraints work only in circumstances like that add + insn. More precisely, the matching constraint must appear in an + input-only operand and the operand that it matches must be an + output-only operand with a lower number. Thus, operand N must + have `=' in its 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 accompanies by `address_operand' + as the predicate in the `match_operand'. + + In order to have valid assembler code, each operand must satisfy +its constraint. But a failure to do so does not prevent the pattern +from applying to an insn. Instead, it directs the compiler to modify +the code so that the constraint will be satisfied. Usually this is +done by copying an operand into a register. + + Contrast, therefore, the two instruction patterns that follow: + + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "r") + (plus:SI (match_dup 0) + (match_operand:SI 1 "general_operand" "r")))] + "" + "...") + +which has two operands, one of which must appear in two places, and + + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "r") + (plus:SI (match_operand:SI 1 "general_operand" "0") + (match_operand:SI 2 "general_operand" "r")))] + "" + "...") + +which has three operands, two of which are required by a constraint +to be identical. If we are considering an insn of the form + + (insn N PREV NEXT + (set (reg:SI 3) + (plus:SI (reg:SI 6) (reg:SI 109))) + ...) + +the first pattern would not apply at all, because this insn does not +contain two identical subexpressions in the right place. The pattern +would say, "That does not look like an add instruction; try other +patterns." The second pattern would say, "Yes, that's an add +instruction, but there is something wrong with it." It would direct +the reload pass of the compiler to generate additional insns to make +the constraint true. The results might look like this: + + (insn N2 PREV N + (set (reg:SI 3) (reg:SI 6)) + ...) + + (insn N N2 NEXT + (set (reg:SI 3) + (plus:SI (reg:SI 3) (reg:SI 109))) + ...) + + It is up to you to make sure that each operand, in each pattern, +has constraints that can handle any RTL expression that could be +present for that operand. (When multiple alternatives are in use, +each pattern must, for each possible combination of operand +expressions, have at least one alternative which can handle that +combination of operands.) The constraints don't need to *allow* any +possible operand--when this is the case, they do not constrain--but +they must at least point the way to reloading any possible operand so +that it will fit. + + * If the constraint accepts whatever operands the predicate + permits, there is no problem: reloading is never necessary for + this operand. + + For example, an operand whose constraints permit everything + except registers is safe provided its predicate rejects registers. + + An operand whose predicate accepts only constant values is safe + provided its constraints include the letter `i'. If any + possible constant value is accepted, then nothing less than `i' + will do; if the predicate is more selective, then the + constraints may also be more selective. + + * Any operand expression can be reloaded by copying it into a + register. So if an operand's constraints allow some kind of + register, it is certain to be safe. It need not permit all + classes of registers; the compiler knows how to copy a register + into another register of the proper class in order to make an + instruction valid. + + * A nonoffsettable memory reference can be reloaded by copying the + address into a register. So if the constraint uses the letter + `o', all memory references are taken care of. + + * A constant operand can be reloaded by allocating space in memory + to hold it as preinitialized data. Then the memory reference + can be used in place of the constant. So if the constraint uses + the letters `o' or `m', constant operands are not a problem. + + If the 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. + + 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. + When operands must be copied into registers, the compiler will + never choose this alternative as the one to strive for. + + 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.). For +example: + + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "r,m") + (const_int 0))] + "" + "* + return (which_alternative == 0 + ? \"clrreg %0\" : \"clrmem %0\"); + ") + + +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")))] + ...) + + Note that in previous versions of GNU CC the `%' constraint + modifier always applied to operands 1 and 2 regardless of which + operand it was written in. The usual custom was to write it in + operand 0. Now it must be in operand 1 if the operands to be + exchanged are 1 and 2. + +`#' + 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. + + 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: No Constraints, Prev: Modifiers, Up: Constraints + +Not Using Constraints +--------------------- + + 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 |