--- gcc/gcc.info-16 2018/04/24 18:18:25 1.1.1.7 +++ gcc/gcc.info-16 2018/04/24 18:24:43 1.1.1.8 @@ -3,11 +3,11 @@ file gcc.texi. This file documents the use and the internals of the GNU compiler. - Published by the Free Software Foundation 675 Massachusetts Avenue -Cambridge, MA 02139 USA + Published by the Free Software Foundation 59 Temple Place - Suite 330 +Boston, MA 02111-1307 USA - Copyright (C) 1988, 1989, 1992, 1993, 1994 Free Software Foundation, -Inc. + Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 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 @@ -30,1060 +30,1298 @@ translations approved by the Free Softwa original English.  -File: gcc.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc +File: gcc.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc -Standard Pattern Names For Generation -===================================== +RTL Template +============ - Here is a table of the instruction names that are meaningful in the -RTL generation pass of the compiler. Giving one of these names to an -instruction pattern tells the RTL generation pass that it can use the -pattern in to accomplish a certain task. - -`movM' - Here M stands for a two-letter machine mode name, in lower case. - This instruction pattern moves data with that machine mode from - operand 1 to operand 0. For example, `movsi' moves full-word data. - - If operand 0 is a `subreg' with mode M of a register whose own - mode is wider than M, the effect of this instruction is to store - the specified value in the part of the register that corresponds - to mode M. The effect on the rest of the register is undefined. - - This class of patterns is special in several ways. First of all, - each of these names *must* be defined, because there is no other - way to copy a datum from one place to another. - - Second, these patterns are not used solely in the RTL generation - pass. Even the reload pass can generate move insns to copy values - from stack slots into temporary registers. When it does so, one - of the operands is a hard register and the other is an operand - that can need to be reloaded into a register. - - Therefore, when given such a pair of operands, the pattern must - generate RTL which needs no reloading and needs no temporary - registers--no registers other than the operands. For example, if - you support the pattern with a `define_expand', then in such a - case the `define_expand' mustn't call `force_reg' or any other such - function which might generate new pseudo registers. - - This requirement exists even for subword modes on a RISC machine - where fetching those modes from memory normally requires several - insns and some temporary registers. Look in `spur.md' to see how - the requirement can be satisfied. - - During reload a memory reference with an invalid address may be - passed as an operand. Such an address will be replaced with a - valid address later in the reload pass. In this case, nothing may - be done with the address except to use it as it stands. If it is - copied, it will not be replaced with a valid address. No attempt - should be made to make such an address into a valid address and no - routine (such as `change_address') that will do so may be called. - Note that `general_operand' will fail when applied to such an - address. - - The global variable `reload_in_progress' (which must be explicitly - declared if required) can be used to determine whether such special - handling is required. - - The variety of operands that have reloads depends on the rest of - the machine description, but typically on a RISC machine these can - only be pseudo registers that did not get hard registers, while on - other machines explicit memory references will get optional - reloads. - - If a scratch register is required to move an object to or from - memory, it can be allocated using `gen_reg_rtx' prior to reload. - But this is impossible during and after reload. If there are - cases needing scratch registers after reload, you must define - `SECONDARY_INPUT_RELOAD_CLASS' and perhaps also - `SECONDARY_OUTPUT_RELOAD_CLASS' to detect them, and provide - patterns `reload_inM' or `reload_outM' to handle them. *Note - Register Classes::. - - The constraints on a `moveM' must permit moving any hard register - to any other hard register provided that `HARD_REGNO_MODE_OK' - permits mode M in both registers and `REGISTER_MOVE_COST' applied - to their classes returns a value of 2. - - It is obligatory to support floating point `moveM' instructions - into and out of any registers that can hold fixed point values, - because unions and structures (which have modes `SImode' or - `DImode') can be in those registers and they may have floating - point members. - - There may also be a need to support fixed point `moveM' - instructions in and out of floating point registers. - Unfortunately, I have forgotten why this was so, and I don't know - whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed - point values in floating point registers, then the constraints of - the fixed point `moveM' instructions must be designed to avoid - ever trying to reload into a floating point register. - -`reload_inM' -`reload_outM' - Like `movM', but used when a scratch register is required to move - between operand 0 and operand 1. Operand 2 describes the scratch - register. See the discussion of the `SECONDARY_RELOAD_CLASS' - macro in *note Register Classes::.. - -`movstrictM' - Like `movM' except that if operand 0 is a `subreg' with mode M of - a register whose natural mode is wider, the `movstrictM' - instruction is guaranteed not to alter any of the register except - the part which belongs to mode M. - -`load_multiple' - Load several consecutive memory locations into consecutive - registers. Operand 0 is the first of the consecutive registers, - operand 1 is the first memory location, and operand 2 is a - constant: the number of consecutive registers. - - Define this only if the target machine really has such an - instruction; do not define this if the most efficient way of - loading consecutive registers from memory is to do them one at a - time. - - On some machines, there are restrictions as to which consecutive - registers can be stored into memory, such as particular starting or - ending register numbers or only a range of valid counts. For those - machines, use a `define_expand' (*note Expander Definitions::.) - and make the pattern fail if the restrictions are not met. - - Write the generated insn as a `parallel' with elements being a - `set' of one register from the appropriate memory location (you may - also need `use' or `clobber' elements). Use a `match_parallel' - (*note RTL Template::.) to recognize the insn. See `a29k.md' and - `rs6000.md' for examples of the use of this insn pattern. - -`store_multiple' - Similar to `load_multiple', but store several consecutive registers - into consecutive memory locations. Operand 0 is the first of the - consecutive memory locations, operand 1 is the first register, and - operand 2 is a constant: the number of consecutive registers. - -`addM3' - Add operand 2 and operand 1, storing the result in operand 0. All - operands must have mode M. This can be used even on two-address - machines, by means of constraints requiring operands 1 and 0 to be - the same location. - -`subM3', `mulM3' -`divM3', `udivM3', `modM3', `umodM3' -`sminM3', `smaxM3', `uminM3', `umaxM3' -`andM3', `iorM3', `xorM3' - Similar, for other arithmetic operations. - -`mulhisi3' - Multiply operands 1 and 2, which have mode `HImode', and store a - `SImode' product in operand 0. - -`mulqihi3', `mulsidi3' - Similar widening-multiplication instructions of other widths. - -`umulqihi3', `umulhisi3', `umulsidi3' - Similar widening-multiplication instructions that do unsigned - multiplication. - -`divmodM4' - Signed division that produces both a quotient and a remainder. - Operand 1 is divided by operand 2 to produce a quotient stored in - operand 0 and a remainder stored in operand 3. - - For machines with an instruction that produces both a quotient and - a remainder, provide a pattern for `divmodM4' but do not provide - patterns for `divM3' and `modM3'. This allows optimization in the - relatively common case when both the quotient and remainder are - computed. - - If an instruction that just produces a quotient or just a remainder - exists and is more efficient than the instruction that produces - both, write the output routine of `divmodM4' to call - `find_reg_note' and look for a `REG_UNUSED' note on the quotient - or remainder and generate the appropriate instruction. - -`udivmodM4' - Similar, but does unsigned division. - -`ashlM3' - Arithmetic-shift operand 1 left by a number of bits specified by - operand 2, and store the result in operand 0. Here M is the mode - of operand 0 and operand 1; operand 2's mode is specified by the - instruction pattern, and the compiler will convert the operand to - that mode before generating the instruction. + The RTL template is used to define which insns match the particular +pattern and how to find their operands. For named patterns, the RTL +template also says how to construct an insn from specified operands. + + Construction involves substituting specified operands into a copy of +the template. Matching involves determining the values that serve as +the operands in the insn being matched. Both of these activities are +controlled by special expression types that direct matching and +substitution of the operands. + +`(match_operand:M N PREDICATE CONSTRAINT)' + This expression is a placeholder for operand number N of the insn. + When constructing an insn, operand number N will be substituted + at this point. When matching an insn, whatever appears at this + position in the insn will be taken as operand number N; but it + must satisfy PREDICATE or this instruction pattern will not match + at all. + + Operand numbers must be chosen consecutively counting from zero in + each instruction pattern. There may be only one `match_operand' + expression in the pattern for each operand number. Usually + operands are numbered in the order of appearance in `match_operand' + expressions. + + PREDICATE is a string that is the name of a C function that + accepts two arguments, an expression and a machine mode. During + matching, the function will be called with the putative operand as + the expression and M as the mode argument (if M is not specified, + `VOIDmode' will be used, which normally causes PREDICATE to accept + any mode). If it returns zero, this instruction pattern fails to + match. PREDICATE may be an empty string; then it means no test is + to be done on the operand, so anything which occurs in this + position is valid. + + Most of the time, PREDICATE will reject modes other than M--but + not always. For example, the predicate `address_operand' uses M + as the mode of memory ref that the address should be valid for. + Many predicates accept `const_int' nodes even though their mode is + `VOIDmode'. + + CONSTRAINT controls reloading and the choice of the best register + class to use for a value, as explained later (*note + Constraints::.). + + People are often unclear on the difference between the constraint + and the predicate. The predicate helps decide whether a given + insn matches the pattern. The constraint plays no role in this + decision; instead, it controls various decisions in the case of an + insn which does match. + + On CISC machines, the most common PREDICATE is + `"general_operand"'. This function checks that the putative + operand is either a constant, a register or a memory reference, + and that it is valid for mode M. + + For an operand that must be a register, PREDICATE should be + `"register_operand"'. Using `"general_operand"' would be valid, + since the reload pass would copy any non-register operands through + registers, but this would make GNU CC do extra work, it would + prevent invariant operands (such as constant) from being removed + from loops, and it would prevent the register allocator from doing + the best possible job. On RISC machines, it is usually most + efficient to allow PREDICATE to accept only objects that the + constraints allow. + + For an operand that must be a constant, you must be sure to either + use `"immediate_operand"' for PREDICATE, or make the instruction + pattern's extra condition require a constant, or both. You cannot + expect the constraints to do this work! If the constraints allow + only constants, but the predicate allows something else, the + compiler will crash when that case arises. + +`(match_scratch:M N CONSTRAINT)' + This expression is also a placeholder for operand number N and + indicates that operand must be a `scratch' or `reg' expression. + + When matching patterns, this is equivalent to + + (match_operand:M N "scratch_operand" PRED) + + but, when generating RTL, it produces a (`scratch':M) expression. + + If the last few expressions in a `parallel' are `clobber' + expressions whose operands are either a hard register or + `match_scratch', the combiner can add or delete them when + necessary. *Note Side Effects::. + +`(match_dup N)' + This expression is also a placeholder for operand number N. It is + used when the operand needs to appear more than once in the insn. + + In construction, `match_dup' acts just like `match_operand': the + operand is substituted into the insn being constructed. But in + matching, `match_dup' behaves differently. It assumes that operand + number N has already been determined by a `match_operand' + appearing earlier in the recognition template, and it matches only + an identical-looking expression. -`ashrM3', `lshrM3', `rotlM3', `rotrM3' - Other shift and rotate instructions, analogous to the `ashlM3' - instructions. +`(match_operator:M N PREDICATE [OPERANDS...])' + This pattern is a kind of placeholder for a variable RTL expression + code. -`negM2' - Negate operand 1 and store the result in operand 0. + When constructing an insn, it stands for an RTL expression whose + expression code is taken from that of operand N, and whose + operands are constructed from the patterns OPERANDS. + + When matching an expression, it matches an expression if the + function PREDICATE returns nonzero on that expression *and* the + patterns OPERANDS match the operands of the expression. + + Suppose that the function `commutative_operator' is defined as + follows, to match any expression whose operator is one of the + commutative arithmetic operators of RTL and whose mode is MODE: + + int + commutative_operator (x, mode) + rtx x; + enum machine_mode mode; + { + enum rtx_code code = GET_CODE (x); + if (GET_MODE (x) != mode) + return 0; + return (GET_RTX_CLASS (code) == 'c' + || code == EQ || code == NE); + } + + Then the following pattern will match any RTL expression consisting + of a commutative operator applied to two general operands: + + (match_operator:SI 3 "commutative_operator" + [(match_operand:SI 1 "general_operand" "g") + (match_operand:SI 2 "general_operand" "g")]) + + Here the vector `[OPERANDS...]' contains two patterns because the + expressions to be matched all contain two operands. + + When this pattern does match, the two operands of the commutative + operator are recorded as operands 1 and 2 of the insn. (This is + done by the two instances of `match_operand'.) Operand 3 of the + insn will be the entire commutative expression: use `GET_CODE + (operands[3])' to see which commutative operator was used. + + The machine mode M of `match_operator' works like that of + `match_operand': it is passed as the second argument to the + predicate function, and that function is solely responsible for + deciding whether the expression to be matched "has" that mode. + + When constructing an insn, argument 3 of the gen-function will + specify the operation (i.e. the expression code) for the + expression to be made. It should be an RTL expression, whose + expression code is copied into a new expression whose operands are + arguments 1 and 2 of the gen-function. The subexpressions of + argument 3 are not used; only its expression code matters. + + When `match_operator' is used in a pattern for matching an insn, + it usually best if the operand number of the `match_operator' is + higher than that of the actual operands of the insn. This improves + register allocation because the register allocator often looks at + operands 1 and 2 of insns to see if it can do register tying. + + There is no way to specify constraints in `match_operator'. The + operand of the insn which corresponds to the `match_operator' + never has any constraints because it is never reloaded as a whole. + However, if parts of its OPERANDS are matched by `match_operand' + patterns, those parts may have constraints of their own. + +`(match_op_dup:M N[OPERANDS...])' + Like `match_dup', except that it applies to operators instead of + operands. When constructing an insn, operand number N will be + substituted at this point. But in matching, `match_op_dup' behaves + differently. It assumes that operand number N has already been + determined by a `match_operator' appearing earlier in the + recognition template, and it matches only an identical-looking + expression. + +`(match_parallel N PREDICATE [SUBPAT...])' + This pattern is a placeholder for an insn that consists of a + `parallel' expression with a variable number of elements. This + expression should only appear at the top level of an insn pattern. + + When constructing an insn, operand number N will be substituted at + this point. When matching an insn, it matches if the body of the + insn is a `parallel' expression with at least as many elements as + the vector of SUBPAT expressions in the `match_parallel', if each + SUBPAT matches the corresponding element of the `parallel', *and* + the function PREDICATE returns nonzero on the `parallel' that is + the body of the insn. It is the responsibility of the predicate + to validate elements of the `parallel' beyond those listed in the + `match_parallel'. + + A typical use of `match_parallel' is to match load and store + multiple expressions, which can contain a variable number of + elements in a `parallel'. For example, -`absM2' - Store the absolute value of operand 1 into operand 0. + (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. -`sqrtM2' - Store the square root of operand 1 into operand 0. + +File: gcc.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc - The `sqrt' built-in function of C always uses the mode which - corresponds to the C data type `double'. - -`ffsM2' - Store into operand 0 one plus the index of the least significant - 1-bit of operand 1. If operand 1 is zero, store zero. M is the - mode of operand 0; operand 1's mode is specified by the instruction - pattern, and the compiler will convert the operand to that mode - before generating the instruction. - - The `ffs' built-in function of C always uses the mode which - corresponds to the C data type `int'. - -`one_cmplM2' - Store the bitwise-complement of operand 1 into operand 0. - -`cmpM' - Compare operand 0 and operand 1, and set the condition codes. The - RTL pattern should look like this: - - (set (cc0) (compare (match_operand:M 0 ...) - (match_operand:M 1 ...))) - -`tstM' - Compare operand 0 against zero, and set the condition codes. The - RTL pattern should look like this: - - (set (cc0) (match_operand:M 0 ...)) - - `tstM' patterns should not be defined for machines that do not use - `(cc0)'. Doing so would confuse the optimizer since it would no - longer be clear which `set' operations were comparisons. The - `cmpM' patterns should be used instead. - -`movstrM' - Block move instruction. The addresses of the destination and - source strings are the first two operands, and both are in mode - `Pmode'. The number of bytes to move is the third operand, in - mode M. - - The fourth operand is the known shared alignment of the source and - destination, in the form of a `const_int' rtx. Thus, if the - compiler knows that both source and destination are word-aligned, - it may provide the value 4 for this operand. - - These patterns need not give special consideration to the - possibility that the source and destination strings might overlap. - -`cmpstrM' - Block compare instruction, with five operands. Operand 0 is the - output; it has mode M. The remaining four operands are like the - operands of `movstrM'. The two memory blocks specified are - compared byte by byte in lexicographic order. The effect of the - instruction is to store a value in operand 0 whose sign indicates - the result of the comparison. - - Compute the length of a string, with three operands. Operand 0 is - the result (of mode M), operand 1 is a `mem' referring to the - first character of the string, operand 2 is the character to - search for (normally zero), and operand 3 is a constant describing - the known alignment of the beginning of the string. - -`floatMN2' - Convert signed integer operand 1 (valid for fixed point mode M) to - floating point mode N and store in operand 0 (which has mode N). - -`floatunsMN2' - Convert unsigned integer operand 1 (valid for fixed point mode M) - to floating point mode N and store in operand 0 (which has mode N). - -`fixMN2' - Convert operand 1 (valid for floating point mode M) to fixed point - mode N as a signed number and store in operand 0 (which has mode - N). This instruction's result is defined only when the value of - operand 1 is an integer. - -`fixunsMN2' - Convert operand 1 (valid for floating point mode M) to fixed point - mode N as an unsigned number and store in operand 0 (which has - mode N). This instruction's result is defined only when the value - of operand 1 is an integer. - -`ftruncM2' - Convert operand 1 (valid for floating point mode M) to an integer - value, still represented in floating point mode M, and store it in - operand 0 (valid for floating point mode M). - -`fix_truncMN2' - Like `fixMN2' but works for any floating point value of mode M by - converting the value to an integer. - -`fixuns_truncMN2' - Like `fixunsMN2' but works for any floating point value of mode M - by converting the value to an integer. - -`truncMN' - Truncate operand 1 (valid for mode M) to mode N and store in - operand 0 (which has mode N). Both modes must be fixed point or - both floating point. - -`extendMN' - Sign-extend operand 1 (valid for mode M) to mode N and store in - operand 0 (which has mode N). Both modes must be fixed point or - both floating point. - -`zero_extendMN' - Zero-extend operand 1 (valid for mode M) to mode N and store in - operand 0 (which has mode N). Both modes must be fixed point. - -`extv' - Extract a bit field from operand 1 (a register or memory operand), - where operand 2 specifies the width in bits and operand 3 the - starting bit, and store it in operand 0. Operand 0 must have mode - `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode'; - often `word_mode' is allowed only for registers. Operands 2 and 3 - must be valid for `word_mode'. - - The RTL generation pass generates this instruction only with - constants for operands 2 and 3. - - The bit-field value is sign-extended to a full word integer before - it is stored in operand 0. - -`extzv' - Like `extv' except that the bit-field value is zero-extended. - -`insv' - Store operand 3 (which must be valid for `word_mode') into a bit - field in operand 0, where operand 1 specifies the width in bits and - operand 2 the starting bit. Operand 0 may have mode `byte_mode' or - `word_mode'; often `word_mode' is allowed only for registers. - Operands 1 and 2 must be valid for `word_mode'. - - The RTL generation pass generates this instruction only with - constants for operands 1 and 2. - -`sCOND' - Store zero or nonzero in the operand according to the condition - codes. Value stored is nonzero iff the condition COND is true. - cOND is the name of a comparison operation expression code, such - as `eq', `lt' or `leu'. - - You specify the mode that the operand must have when you write the - `match_operand' expression. The compiler automatically sees which - mode you have used and supplies an operand of that mode. - - The value stored for a true condition must have 1 as its low bit, - or else must be negative. Otherwise the instruction is not - suitable and you should omit it from the machine description. You - describe to the compiler exactly which value is stored by defining - the macro `STORE_FLAG_VALUE' (*note Misc::.). If a description - cannot be found that can be used for all the `sCOND' patterns, you - should omit those operations from the machine description. - - These operations may fail, but should do so only in relatively - uncommon cases; if they would fail for common cases involving - integer comparisons, it is best to omit these patterns. - - If these operations are omitted, the compiler will usually - generate code that copies the constant one to the target and - branches around an assignment of zero to the target. If this code - is more efficient than the potential instructions used for the - `sCOND' pattern followed by those required to convert the result - into a 1 or a zero in `SImode', you should omit the `sCOND' - operations from the machine description. - -`bCOND' - Conditional branch instruction. Operand 0 is a `label_ref' that - refers to the label to jump to. Jump if the condition codes meet - condition COND. - - Some machines do not follow the model assumed here where a - comparison instruction is followed by a conditional branch - instruction. In that case, the `cmpM' (and `tstM') patterns should - simply store the operands away and generate all the required insns - in a `define_expand' (*note Expander Definitions::.) for the - conditional branch operations. All calls to expand `bCOND' - patterns are immediately preceded by calls to expand either a - `cmpM' pattern or a `tstM' pattern. - - Machines that use a pseudo register for the condition code value, - or where the mode used for the comparison depends on the condition - being tested, should also use the above mechanism. *Note Jump - Patterns:: - - The above discussion also applies to `sCOND' patterns. - -`call' - Subroutine call instruction returning no value. Operand 0 is the - function to call; operand 1 is the number of bytes of arguments - pushed (in mode `SImode', except it is normally a `const_int'); - operand 2 is the number of registers used as operands. - - On most machines, operand 2 is not actually stored into the RTL - pattern. It is supplied for the sake of some RISC machines which - need to put this information into the assembler code; they can put - it in the RTL instead of operand 1. - - Operand 0 should be a `mem' RTX whose address is the address of the - function. Note, however, that this address can be a `symbol_ref' - expression even if it would not be a legitimate memory address on - the target machine. If it is also not a valid argument for a call - instruction, the pattern for this operation should be a - `define_expand' (*note Expander Definitions::.) that places the - address into a register and uses that register in the call - instruction. +Output Templates and Operand Substitution +========================================= -`call_value' - Subroutine call instruction returning a value. Operand 0 is the - hard register in which the value is returned. There are three more - operands, the same as the three operands of the `call' instruction - (but with numbers increased by one). - - Subroutines that return `BLKmode' objects use the `call' insn. - -`call_pop', `call_value_pop' - Similar to `call' and `call_value', except used if defined and if - `RETURN_POPS_ARGS' is non-zero. They should emit a `parallel' - that contains both the function call and a `set' to indicate the - adjustment made to the frame pointer. - - For machines where `RETURN_POPS_ARGS' can be non-zero, the use of - these patterns increases the number of functions for which the - frame pointer can be eliminated, if desired. - -`untyped_call' - Subroutine call instruction returning a value of any type. - Operand 0 is the function to call; operand 1 is a memory location - where the result of calling the function is to be stored; operand - 2 is a `parallel' expression where each element is a `set' - expression that indicates the saving of a function return value - into the result block. - - This instruction pattern should be defined to support - `__builtin_apply' on machines where special instructions are needed - to call a subroutine with arbitrary arguments or to save the value - returned. This instruction pattern is required on machines that - have multiple registers that can hold a return value (i.e. - `FUNCTION_VALUE_REGNO_P' is true for more than one register). - -`return' - Subroutine return instruction. This instruction pattern name - should be defined only if a single instruction can do all the work - of returning from a function. - - Like the `movM' patterns, this pattern is also used after the RTL - generation phase. In this case it is to support machines where - multiple instructions are usually needed to return from a - function, but some class of functions only requires one - instruction to implement a return. Normally, the applicable - functions are those which do not need to save any registers or - allocate stack space. - - For such machines, the condition specified in this pattern should - only be true when `reload_completed' is non-zero and the function's - epilogue would only be a single instruction. For machines with - register windows, the routine `leaf_function_p' may be used to - determine if a register window push is required. + The "output template" is a string which specifies how to output the +assembler code for an instruction pattern. Most of the template is a +fixed string which is output literally. The character `%' is used to +specify where to substitute an operand; it can also be used to identify +places where different variants of the assembler require different +syntax. + + In the simplest case, a `%' followed by a digit N says to output +operand N at that point in the string. + + `%' followed by a letter and a digit says to output an operand in an +alternate fashion. Four letters have standard, built-in meanings +described below. The machine description macro `PRINT_OPERAND' can +define additional letters with nonstandard meanings. + + `%cDIGIT' can be used to substitute an operand that is a constant +value without the syntax that normally indicates an immediate operand. + + `%nDIGIT' is like `%cDIGIT' except that the value of the constant is +negated before printing. + + `%aDIGIT' can be used to substitute an operand as if it were a +memory reference, with the actual operand treated as the address. This +may be useful when outputting a "load address" instruction, because +often the assembler syntax for such an instruction requires you to +write the operand as if it were a memory reference. + + `%lDIGIT' is used to substitute a `label_ref' into a jump +instruction. + + `%=' outputs a number which is unique to each instruction in the +entire compilation. This is useful for making local labels to be +referred to more than once in a single template that generates multiple +assembler instructions. + + `%' followed by a punctuation character specifies a substitution that +does not use an operand. Only one case is standard: `%%' outputs a `%' +into the assembler code. Other nonstandard cases can be defined in the +`PRINT_OPERAND' macro. You must also define which punctuation +characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro. + + The template may generate multiple assembler instructions. Write +the text for the instructions, with `\;' between them. + + When the RTL contains two operands which are required by constraint +to match each other, the output template must refer only to the +lower-numbered operand. Matching operands are not always identical, +and the rest of the compiler arranges to put the proper RTL expression +for printing into the lower-numbered operand. + + One use of nonstandard letters or punctuation following `%' is to +distinguish between different assembler languages for the same machine; +for example, Motorola syntax versus MIT syntax for the 68000. Motorola +syntax requires periods in most opcode names, while MIT syntax does +not. For example, the opcode `movel' in MIT syntax is `move.l' in +Motorola syntax. The same file of patterns is used for both kinds of +output syntax, but the character sequence `%.' is used in each place +where Motorola syntax wants a period. The `PRINT_OPERAND' macro for +Motorola syntax defines the sequence to output a period; the macro for +MIT syntax defines it to do nothing. + + As a special case, a template consisting of the single character `#' +instructs the compiler to first split the insn, and then output the +resulting instructions separately. This helps eliminate redundancy in +the output templates. If you have a `define_insn' that needs to emit +multiple assembler instructions, and there is an matching `define_split' +already defined, then you can simply use `#' as the output template +instead of writing an output template that emits the multiple assembler +instructions. + + If `ASSEMBLER_DIALECT' is defined, you can use +`{option0|option1|option2}' constructs in the templates. These +describe multiple variants of assembler language syntax. *Note +Instruction Output::. - Machines that have conditional return instructions should define - patterns such as + +File: gcc.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc - (define_insn "" - [(set (pc) - (if_then_else (match_operator - 0 "comparison_operator" - [(cc0) (const_int 0)]) - (return) - (pc)))] - "CONDITION" - "...") - - where CONDITION would normally be the same condition specified on - the named `return' pattern. - -`untyped_return' - Untyped subroutine return instruction. This instruction pattern - should be defined to support `__builtin_return' on machines where - special instructions are needed to return a value of any type. - - Operand 0 is a memory location where the result of calling a - function with `__builtin_apply' is stored; operand 1 is a - `parallel' expression where each element is a `set' expression - that indicates the restoring of a function return value from the - result block. - -`nop' - No-op instruction. This instruction pattern name should always be - defined to output a no-op in assembler code. `(const_int 0)' will - do as an RTL pattern. - -`indirect_jump' - An instruction to jump to an address which is operand zero. This - pattern name is mandatory on all machines. - -`casesi' - Instruction to jump through a dispatch table, including bounds - checking. This instruction takes five operands: - - 1. The index to dispatch on, which has mode `SImode'. - - 2. The lower bound for indices in the table, an integer constant. - - 3. The total range of indices in the table--the largest index - minus the smallest one (both inclusive). - - 4. A label that precedes the table itself. - - 5. A label to jump to if the index has a value outside the - bounds. (If the machine-description macro - `CASE_DROPS_THROUGH' is defined, then an out-of-bounds index - drops through to the code following the jump table instead of - jumping to this label. In that case, this label is not - actually used by the `casesi' instruction, but it is always - provided as an operand.) - - The table is a `addr_vec' or `addr_diff_vec' inside of a - `jump_insn'. The number of elements in the table is one plus the - difference between the upper bound and the lower bound. - -`tablejump' - Instruction to jump to a variable address. This is a low-level - capability which can be used to implement a dispatch table when - there is no `casesi' pattern. - - This pattern requires two operands: the address or offset, and a - label which should immediately precede the jump table. If the - macro `CASE_VECTOR_PC_RELATIVE' is defined then the first operand - is an offset which counts from the address of the table; - otherwise, it is an absolute address to jump to. In either case, - the first operand has mode `Pmode'. - - The `tablejump' insn is always the last insn before the jump table - it uses. Its assembler code normally has no need to use the - second operand, but you should incorporate it in the RTL pattern so - that the jump optimizer will not delete the table as unreachable - code. +C Statements for Assembler Output +================================= -`save_stack_block' -`save_stack_function' -`save_stack_nonlocal' -`restore_stack_block' -`restore_stack_function' -`restore_stack_nonlocal' - Most machines save and restore the stack pointer by copying it to - or from an object of mode `Pmode'. Do not define these patterns on - such machines. - - Some machines require special handling for stack pointer saves and - restores. On those machines, define the patterns corresponding to - the non-standard cases by using a `define_expand' (*note Expander - Definitions::.) that produces the required insns. The three types - of saves and restores are: - - 1. `save_stack_block' saves the stack pointer at the start of a - block that allocates a variable-sized object, and - `restore_stack_block' restores the stack pointer when the - block is exited. - - 2. `save_stack_function' and `restore_stack_function' do a - similar job for the outermost block of a function and are - used when the function allocates variable-sized objects or - calls `alloca'. Only the epilogue uses the restored stack - pointer, allowing a simpler save or restore sequence on some - machines. - - 3. `save_stack_nonlocal' is used in functions that contain labels - branched to by nested functions. It saves the stack pointer - in such a way that the inner function can use - `restore_stack_nonlocal' to restore the stack pointer. The - compiler generates code to restore the frame and argument - pointer registers, but some machines require saving and - restoring additional data such as register window information - or stack backchains. Place insns in these patterns to save - and restore any such required data. - - When saving the stack pointer, operand 0 is the save area and - operand 1 is the stack pointer. The mode used to allocate the - save area is the mode of operand 0. You must specify an integral - mode, or `VOIDmode' if no save area is needed for a particular - type of save (either because no save is needed or because a - machine-specific save area can be used). Operand 0 is the stack - pointer and operand 1 is the save area for restore operations. If - `save_stack_block' is defined, operand 0 must not be `VOIDmode' - since these saves can be arbitrarily nested. - - A save area is a `mem' that is at a constant offset from - `virtual_stack_vars_rtx' when the stack pointer is saved for use by - nonlocal gotos and a `reg' in the other two cases. - -`allocate_stack' - Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 0 - from the stack pointer to create space for dynamically allocated - data. - - Do not define this pattern if all that must be done is the - subtraction. Some machines require other operations such as stack - probes or maintaining the back chain. Define this pattern to emit - those operations in addition to updating the stack pointer. + Often a single fixed template string cannot produce correct and +efficient assembler code for all the cases that are recognized by a +single instruction pattern. For example, the opcodes may depend on the +kinds of operands; or some unfortunate combinations of operands may +require extra machine instructions. + + If the output control string starts with a `@', then it is actually +a series of templates, each on a separate line. (Blank lines and +leading spaces and tabs are ignored.) The templates correspond to the +pattern's constraint alternatives (*note Multi-Alternative::.). For +example, if a target machine has a two-address add instruction `addr' +to add into a register and another `addm' to add a register to memory, +you might write this pattern: + + (define_insn "addsi3" + [(set (match_operand:SI 0 "general_operand" "=r,m") + (plus:SI (match_operand:SI 1 "general_operand" "0,0") + (match_operand:SI 2 "general_operand" "g,r")))] + "" + "@ + addr %2,%0 + addm %2,%0") + + 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: + + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "=r,m") + (const_int 0))] + "" + "* + return (which_alternative == 0 + ? \"clrreg %0\" : \"clrmem %0\"); + ") + + The example above, where the assembler code to generate was *solely* +determined by the alternative, could also have been specified as +follows, having the output control string start with a `@': + + (define_insn "" + [(set (match_operand:SI 0 "general_operand" "=r,m") + (const_int 0))] + "" + "@ + clrreg %0 + clrmem %0")  -File: gcc.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc +File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc -When the Order of Patterns Matters -================================== +Operand Constraints +=================== - Sometimes an insn can match more than one instruction pattern. Then -the pattern that appears first in the machine description is the one -used. Therefore, more specific patterns (patterns that will match -fewer things) and faster instructions (those that will produce better -code when they do match) should usually go first in the description. - - In some cases the effect of ordering the patterns can be used to hide -a pattern when it is not valid. For example, the 68000 has an -instruction for converting a fullword to floating point and another for -converting a byte to floating point. An instruction converting an -integer to floating point could match either one. We put the pattern -to convert the fullword first to make sure that one will be used rather -than the other. (Otherwise a large integer might be generated as a -single-byte immediate quantity, which would not work.) Instead of using -this pattern ordering it would be possible to make the pattern for -convert-a-byte smart enough to deal properly with any constant value. + 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. +* Machine Constraints:: Existing constraints for some particular machines. +* No Constraints:: Describing a clean machine without constraints.  -File: gcc.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc +File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints -Interdependence of Patterns -=========================== +Simple Constraints +------------------ - Every machine description must have a named pattern for each of the -conditional branch names `bCOND'. The recognition template must always -have the form - - (set (pc) - (if_then_else (COND (cc0) (const_int 0)) - (label_ref (match_operand 0 "" "")) - (pc))) - -In addition, every machine description must have an anonymous pattern -for each of the possible reverse-conditional branches. Their templates -look like - - (set (pc) - (if_then_else (COND (cc0) (const_int 0)) - (pc) - (label_ref (match_operand 0 "" "")))) - -They are necessary because jump optimization can turn direct-conditional -branches into reverse-conditional branches. - - It is often convenient to use the `match_operator' construct to -reduce the number of patterns that must be specified for branches. For -example, + 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. + + Contrast, therefore, the two instruction patterns that follow: (define_insn "" - [(set (pc) - (if_then_else (match_operator 0 "comparison_operator" - [(cc0) (const_int 0)]) - (pc) - (label_ref (match_operand 1 "" ""))))] - "CONDITION" + [(set (match_operand:SI 0 "general_operand" "=r") + (plus:SI (match_dup 0) + (match_operand:SI 1 "general_operand" "r")))] + "" "...") - In some cases machines support instructions identical except for the -machine mode of one or more operands. For example, there may be -"sign-extend halfword" and "sign-extend byte" instructions whose -patterns are +which has two operands, one of which must appear in two places, and - (set (match_operand:SI 0 ...) - (extend:SI (match_operand:HI 1 ...))) + (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)) + ...) - (set (match_operand:SI 0 ...) - (extend:SI (match_operand:QI 1 ...))) + (insn N N2 NEXT + (set (reg:SI 3) + (plus:SI (reg:SI 3) (reg:SI 109))) + ...) -Constant integers do not specify a machine mode, so an instruction to -extend a constant value could match either pattern. The pattern it -actually will match is the one that appears first in the file. For -correct results, this must be the one for the widest possible mode -(`HImode', here). If the pattern matches the `QImode' instruction, the -results will be incorrect if the constant value does not actually fit -that mode. - - Such instructions to extend constants are rarely generated because -they are optimized away, but they do occasionally happen in nonoptimized -compilations. - - If a constraint in a pattern allows a constant, the reload pass may -replace a register with a constant permitted by the constraint in some -cases. Similarly for memory references. You must ensure that the -predicate permits all objects allowed by the constraints to prevent the -compiler from crashing. - - Because of this substitution, you should not provide separate -patterns for increment and decrement instructions. Instead, they -should be generated from the same pattern that supports -register-register add insns by examining the operands and generating -the appropriate machine instruction. + It is up to you to make sure that each operand, in each pattern, has +constraints that can handle any RTL expression that could be present for +that operand. (When multiple alternatives are in use, each pattern +must, for each possible combination of operand expressions, have at +least one alternative which can handle that combination of operands.) +The constraints don't need to *allow* any possible operand--when this is +the case, they do not constrain--but they must at least point the way to +reloading any possible operand so that it will fit. + + * If the constraint accepts whatever operands the predicate permits, + there is no problem: reloading is never necessary for this operand. + + For example, an operand whose constraints permit everything except + registers is safe provided its predicate rejects registers. + + An operand whose predicate accepts only constant values is safe + provided its constraints include the letter `i'. If any possible + constant value is accepted, then nothing less than `i' will do; if + the predicate is more selective, then the constraints may also be + more selective. + + * Any operand expression can be reloaded by copying it into a + register. So if an operand's constraints allow some kind of + register, it is certain to be safe. It need not permit all + classes of registers; the compiler knows how to copy a register + into another register of the proper class in order to make an + instruction valid. + + * A nonoffsettable memory reference can be reloaded by copying the + address into a register. So if the constraint uses the letter + `o', all memory references are taken care of. + + * A constant operand can be reloaded by allocating space in memory to + hold it as preinitialized data. Then the memory reference can be + used in place of the constant. So if the constraint uses the + letters `o' or `m', constant operands are not a problem. + + * If the constraint permits a constant and a pseudo register used in + an insn was not allocated to a hard register and is equivalent to + a constant, the register will be replaced with the constant. If + the predicate does not permit a constant and the insn is + re-recognized for some reason, the compiler will crash. Thus the + predicate must always recognize any objects allowed by the + constraint. + + If the operand's predicate can recognize registers, but the +constraint does not permit them, it can make the compiler crash. When +this operand happens to be a register, the reload pass will be stymied, +because it does not know how to copy a register temporarily into memory.  -File: gcc.info, Node: Jump Patterns, Next: Insn Canonicalizations, Prev: Dependent Patterns, Up: Machine Desc +File: gcc.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints + +Multiple Alternative Constraints +-------------------------------- -Defining Jump Instruction Patterns -================================== + 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")))] + ...) - For most machines, GNU CC assumes that the machine has a condition -code. A comparison insn sets the condition code, recording the results -of both signed and unsigned comparison of the given operands. A -separate branch insn tests the condition code and branches or not -according its value. The branch insns come in distinct signed and -unsigned flavors. Many common machines, such as the Vax, the 68000 and -the 32000, work this way. - - Some machines have distinct signed and unsigned compare -instructions, and only one set of conditional branch instructions. The -easiest way to handle these machines is to treat them just like the -others until the final stage where assembly code is written. At this -time, when outputting code for the compare instruction, peek ahead at -the following branch using `next_cc0_user (insn)'. (The variable -`insn' refers to the insn being output, in the output-writing code in -an instruction pattern.) If the RTL says that is an unsigned branch, -output an unsigned compare; otherwise output a signed compare. When -the branch itself is output, you can treat signed and unsigned branches -identically. - - The reason you can do this is that GNU CC always generates a pair of -consecutive RTL insns, possibly separated by `note' insns, one to set -the condition code and one to test it, and keeps the pair inviolate -until the end. - - To go with this technique, you must define the machine-description -macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no -compare instruction is superfluous. - - Some machines have compare-and-branch instructions and no condition -code. A similar technique works for them. When it is time to "output" -a compare instruction, record its operands in two static variables. -When outputting the branch-on-condition-code instruction that follows, -actually output a compare-and-branch instruction that uses the -remembered operands. - - It also works to define patterns for compare-and-branch instructions. -In optimizing compilation, the pair of compare and branch instructions -will be combined according to these patterns. But this does not happen -if optimization is not requested. So you must use one of the solutions -above in addition to any special patterns you define. - - In many RISC machines, most instructions do not affect the condition -code and there may not even be a separate condition code register. On -these machines, the restriction that the definition and use of the -condition code be adjacent insns is not necessary and can prevent -important optimizations. For example, on the IBM RS/6000, there is a -delay for taken branches unless the condition code register is set three -instructions earlier than the conditional branch. The instruction -scheduler cannot perform this optimization if it is not permitted to -separate the definition and use of the condition code register. - - On these machines, do not use `(cc0)', but instead use a register to -represent the condition code. If there is a specific condition code -register in the machine, use a hard register. If the condition code or -comparison result can be placed in any general register, or if there are -multiple condition registers, use a pseudo register. - - On some machines, the type of branch instruction generated may -depend on the way the condition code was produced; for example, on the -68k and Sparc, setting the condition code directly from an add or -subtract instruction does not clear the overflow bit the way that a test -instruction does, so a different branch instruction must be used for -some conditional branches. For machines that use `(cc0)', the set and -use of the condition code must be adjacent (separated only by `note' -insns) allowing flags in `cc_status' to be used. (*Note Condition -Code::.) Also, the comparison and branch insns can be located from -each other by using the functions `prev_cc0_setter' and `next_cc0_user'. - - However, this is not true on machines that do not use `(cc0)'. On -those machines, no assumptions can be made about the adjacency of the -compare and branch insns and the above methods cannot be used. Instead, -we use the machine mode of the condition code register to record -different formats of the condition code register. - - Registers used to store the condition code value should have a mode -that is in class `MODE_CC'. Normally, it will be `CCmode'. If -additional modes are required (as for the add example mentioned above in -the Sparc), define the macro `EXTRA_CC_MODES' to list the additional -modes required (*note Condition Code::.). Also define `EXTRA_CC_NAMES' -to list the names of those modes and `SELECT_CC_MODE' to choose a mode -given an operand of a compare. - - If it is known during RTL generation that a different mode will be -required (for example, if the machine has separate compare instructions -for signed and unsigned quantities, like most IBM processors), they can -be specified at that time. - - If the cases that require different modes would be made by -instruction combination, the macro `SELECT_CC_MODE' determines which -machine mode should be used for the comparison result. The patterns -should be written using that mode. To support the case of the add on -the Sparc discussed above, we have the pattern + 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::. - (define_insn "" - [(set (reg:CC_NOOV 0) - (compare:CC_NOOV - (plus:SI (match_operand:SI 0 "register_operand" "%r") - (match_operand:SI 1 "arith_operand" "rI")) - (const_int 0)))] - "" - "...") + +File: gcc.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints - The `SELECT_CC_MODE' macro on the Sparc returns `CC_NOOVmode' for -comparisons whose argument is a `plus'. +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: Insn Canonicalizations, Next: Peephole Definitions, Prev: Jump Patterns, Up: Machine Desc +File: gcc.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints -Canonicalization of Instructions -================================ +Constraint Modifier Characters +------------------------------ - There are often cases where multiple RTL expressions could represent -an operation performed by a single machine instruction. This situation -is most commonly encountered with logical, branch, and -multiply-accumulate instructions. In such cases, the compiler attempts -to convert these multiple RTL expressions into a single canonical form -to reduce the number of insn patterns required. - - In addition to algebraic simplifications, following canonicalizations -are performed: - - * For commutative and comparison operators, a constant is always - made the second operand. If a machine only supports a constant as - the second operand, only patterns that match a constant in the - second operand need be supplied. - - For these operators, if only one operand is a `neg', `not', - `mult', `plus', or `minus' expression, it will be the first - operand. - - * For the `compare' operator, a constant is always the second operand - on machines where `cc0' is used (*note Jump Patterns::.). On other - machines, there are rare cases where the compiler might want to - construct a `compare' with a constant as the first operand. - However, these cases are not common enough for it to be worthwhile - to provide a pattern matching a constant as the first operand - unless the machine actually has such an instruction. - - An operand of `neg', `not', `mult', `plus', or `minus' is made the - first operand under the same conditions as above. - - * `(minus X (const_int N))' is converted to `(plus X (const_int - -N))'. - - * Within address computations (i.e., inside `mem'), a left shift is - converted into the appropriate multiplication by a power of two. - - De`Morgan's Law is used to move bitwise negation inside a bitwise - logical-and or logical-or operation. If this results in only one - operand being a `not' expression, it will be the first one. - - A machine that has an instruction that performs a bitwise - logical-and of one operand with the bitwise negation of the other - should specify the pattern for that instruction as + Here are constraint modifier characters. - (define_insn "" - [(set (match_operand:M 0 ...) - (and:M (not:M (match_operand:M 1 ...)) - (match_operand:M 2 ...)))] - "..." - "...") +`=' + Means that this operand is write-only for this instruction: the + previous value is discarded and replaced by output data. - Similarly, a pattern for a "NAND" instruction should be written +`+' + Means that this operand is both read and written by the + instruction. - (define_insn "" - [(set (match_operand:M 0 ...) - (ior:M (not:M (match_operand:M 1 ...)) - (not:M (match_operand:M 2 ...))))] - "..." - "...") - - In both cases, it is not necessary to include patterns for the many - logically equivalent RTL expressions. - - * The only possible RTL expressions involving both bitwise - exclusive-or and bitwise negation are `(xor:M X Y)' and `(not:M - (xor:M X Y))'. - - * The sum of three items, one of which is a constant, will only - appear in the form - - (plus:M (plus:M X Y) CONSTANT) - - * On machines that do not use `cc0', `(compare X (const_int 0))' - will be converted to X. - - * Equality comparisons of a group of bits (usually a single bit) - with zero will be written using `zero_extract' rather than the - equivalent `and' or `sign_extract' operations. + 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: Peephole Definitions, Next: Expander Definitions, Prev: Insn Canonicalizations, Up: Machine Desc +File: gcc.info, Node: Machine Constraints, Next: No Constraints, Prev: Modifiers, Up: Constraints -Machine-Specific Peephole Optimizers -==================================== +Constraints for Particular Machines +----------------------------------- - In addition to instruction patterns the `md' file may contain -definitions of machine-specific peephole optimizations. + Whenever possible, you should use the general-purpose constraint +letters in `asm' arguments, since they will convey meaning more readily +to people reading your code. Failing that, use the constraint letters +that usually have very similar meanings across architectures. The most +commonly used constraints are `m' and `r' (for memory and +general-purpose registers respectively; *note Simple Constraints::.), +and `I', usually the letter indicating the most common +immediate-constant format. - The combiner does not notice certain peephole optimizations when the -data flow in the program does not suggest that it should try them. For -example, sometimes two consecutive insns related in purpose can be -combined even though the second one does not appear to use a register -computed in the first one. A machine-specific peephole optimizer can -detect such opportunities. - - A definition looks like this: - - (define_peephole - [INSN-PATTERN-1 - INSN-PATTERN-2 - ...] - "CONDITION" - "TEMPLATE" - "OPTIONAL INSN-ATTRIBUTES") - -The last string operand may be omitted if you are not using any -machine-specific information in this machine description. If present, -it must obey the same rules as in a `define_insn'. - - In this skeleton, INSN-PATTERN-1 and so on are patterns to match -consecutive insns. The optimization applies to a sequence of insns when -INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, -and so on. - - Each of the insns matched by a peephole must also match a -`define_insn'. Peepholes are checked only at the last stage just -before code generation, and only optionally. Therefore, any insn which -would match a peephole but no `define_insn' will cause a crash in code -generation in an unoptimized compilation, or at various optimization -stages. - - The operands of the insns are matched with `match_operands', -`match_operator', and `match_dup', as usual. What is not usual is that -the operand numbers apply to all the insn patterns in the definition. -So, you can check for identical operands in two insns by using -`match_operand' in one insn and `match_dup' in the other. - - The operand constraints used in `match_operand' patterns do not have -any direct effect on the applicability of the peephole, but they will -be validated afterward, so make sure your constraints are general enough -to apply whenever the peephole matches. If the peephole matches but -the constraints are not satisfied, the compiler will crash. - - It is safe to omit constraints in all the operands of the peephole; -or you can write constraints which serve as a double-check on the -criteria previously tested. - - Once a sequence of insns matches the patterns, the CONDITION is -checked. This is a C expression which makes the final decision whether -to perform the optimization (we do so if the expression is nonzero). If -CONDITION is omitted (in other words, the string is empty) then the -optimization is applied to every sequence of insns that matches the -patterns. - - The defined peephole optimizations are applied after register -allocation is complete. Therefore, the peephole definition can check -which operands have ended up in which kinds of registers, just by -looking at the operands. - - The way to refer to the operands in CONDITION is to write -`operands[I]' for operand number I (as matched by `(match_operand I -...)'). Use the variable `insn' to refer to the last of the insns -being matched; use `prev_nonnote_insn' to find the preceding insns. - - When optimizing computations with intermediate results, you can use -CONDITION to match only when the intermediate results are not used -elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where INSN -is the insn in which you expect the value to be used for the last time -(from the value of `insn', together with use of `prev_nonnote_insn'), -and OP is the intermediate value (from `operands[I]'). - - Applying the optimization means replacing the sequence of insns with -one new insn. The TEMPLATE controls ultimate output of assembler code -for this combined insn. It works exactly like the template of a -`define_insn'. Operand numbers in this template are the same ones used -in matching the original sequence of insns. - - The result of a defined peephole optimizer does not need to match -any of the insn patterns in the machine description; it does not even -have an opportunity to match them. The peephole optimizer definition -itself serves as the insn pattern to control how the insn is output. - - Defined peephole optimizers are run as assembler code is being -output, so the insns they produce are never combined or rearranged in -any way. - - Here is an example, taken from the 68000 machine description: - - (define_peephole - [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) - (set (match_operand:DF 0 "register_operand" "=f") - (match_operand:DF 1 "register_operand" "ad"))] - "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" - "* - { - rtx xoperands[2]; - xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1); - #ifdef MOTOROLA - output_asm_insn (\"move.l %1,(sp)\", xoperands); - output_asm_insn (\"move.l %1,-(sp)\", operands); - return \"fmove.d (sp)+,%0\"; - #else - output_asm_insn (\"movel %1,sp@\", xoperands); - output_asm_insn (\"movel %1,sp@-\", operands); - return \"fmoved sp@+,%0\"; - #endif - } - ") - - The effect of this optimization is to change - - jbsr _foobar - addql #4,sp - movel d1,sp@- - movel d0,sp@- - fmoved sp@+,fp0 - -into - - jbsr _foobar - movel d1,sp@ - movel d0,sp@- - fmoved sp@+,fp0 - - INSN-PATTERN-1 and so on look *almost* like the second operand of -`define_insn'. There is one important difference: the second operand -of `define_insn' consists of one or more RTX's enclosed in square -brackets. Usually, there is only one: then the same action can be -written as an element of a `define_peephole'. But when there are -multiple actions in a `define_insn', they are implicitly enclosed in a -`parallel'. Then you must explicitly write the `parallel', and the -square brackets within it, in the `define_peephole'. Thus, if an insn -pattern looks like this, - - (define_insn "divmodsi4" - [(set (match_operand:SI 0 "general_operand" "=d") - (div:SI (match_operand:SI 1 "general_operand" "0") - (match_operand:SI 2 "general_operand" "dmsK"))) - (set (match_operand:SI 3 "general_operand" "=d") - (mod:SI (match_dup 1) (match_dup 2)))] - "TARGET_68020" - "divsl%.l %2,%3:%0") - -then the way to mention this insn in a peephole is as follows: - - (define_peephole - [... - (parallel - [(set (match_operand:SI 0 "general_operand" "=d") - (div:SI (match_operand:SI 1 "general_operand" "0") - (match_operand:SI 2 "general_operand" "dmsK"))) - (set (match_operand:SI 3 "general_operand" "=d") - (mod:SI (match_dup 1) (match_dup 2)))]) - ...] - ...) + For each machine architecture, the `config/MACHINE.h' file defines +additional constraints. These constraints are used by the compiler +itself for instruction generation, as well as for `asm' statements; +therefore, some of the constraints are not particularly interesting for +`asm'. The constraints are defined through these macros: + +`REG_CLASS_FROM_LETTER' + Register class constraints (usually lower case). + +`CONST_OK_FOR_LETTER_P' + Immediate constant constraints, for non-floating point constants of + word size or smaller precision (usually upper case). + +`CONST_DOUBLE_OK_FOR_LETTER_P' + Immediate constant constraints, for all floating point constants + and for constants of greater than word size precision (usually + upper case). + +`EXTRA_CONSTRAINT' + Special cases of registers or memory. This macro is not required, + and is only defined for some machines. + + Inspecting these macro definitions in the compiler source for your +machine is the best way to be certain you have the right constraints. +However, here is a summary of the machine-dependent constraints +available on some particular machines. + +*ARM family--`arm.h'* + `f' + Floating-point register + + `F' + One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0, + 4.0, 5.0 or 10.0 + + `G' + Floating-point constant that would satisfy the constraint `F' + if it were negated + + `I' + Integer that is valid as an immediate operand in a data + processing instruction. That is, an integer in the range 0 + to 255 rotated by a multiple of 2 + + `J' + Integer in the range -4095 to 4095 + + `K' + Integer that satisfies constraint `I' when inverted (ones + complement) + + `L' + Integer that satisfies constraint `I' when negated (twos + complement) + + `M' + Integer in the range 0 to 32 + + `Q' + A memory reference where the exact address is in a single + register (``m'' is preferable for `asm' statements) + + `R' + An item in the constant pool + + `S' + A symbol in the text segment of the current file + +*AMD 29000 family--`a29k.h'* + `l' + Local register 0 + + `b' + Byte Pointer (`BP') register + + `q' + `Q' register + + `h' + Special purpose register + + `A' + First accumulator register + + `a' + Other accumulator register + + `f' + Floating point register + + `I' + Constant greater than 0, less than 0x100 + + `J' + Constant greater than 0, less than 0x10000 + + `K' + Constant whose high 24 bits are on (1) + + `L' + 16 bit constant whose high 8 bits are on (1) + + `M' + 32 bit constant whose high 16 bits are on (1) + + `N' + 32 bit negative constant that fits in 8 bits + + `O' + The constant 0x80000000 or, on the 29050, any 32 bit constant + whose low 16 bits are 0. + + `P' + 16 bit negative constant that fits in 8 bits + + `G' + `H' + A floating point constant (in `asm' statements, use the + machine independent `E' or `F' instead) + +*IBM RS6000--`rs6000.h'* + `b' + Address base register + + `f' + Floating point register + + `h' + `MQ', `CTR', or `LINK' register + + `q' + `MQ' register + + `c' + `CTR' register + + `l' + `LINK' register + + `x' + `CR' register (condition register) number 0 + + `y' + `CR' register (condition register) + + `I' + Signed 16 bit constant + + `J' + Constant whose low 16 bits are 0 + + `K' + Constant whose high 16 bits are 0 + + `L' + Constant suitable as a mask operand + + `M' + Constant larger than 31 + + `N' + Exact power of 2 + + `O' + Zero + + `P' + Constant whose negation is a signed 16 bit constant + + `G' + Floating point constant that can be loaded into a register + with one instruction per word + + `Q' + Memory operand that is an offset from a register (`m' is + preferable for `asm' statements) + +*Intel 386--`i386.h'* + `q' + `a', `b', `c', or `d' register + + `A' + `a', or `d' register (for 64-bit ints) + + `f' + Floating point register + + `t' + First (top of stack) floating point register + + `u' + Second floating point register + + `a' + `a' register + + `b' + `b' register + + `c' + `c' register + + `d' + `d' register + + `D' + `di' register + + `S' + `si' register + + `I' + Constant in range 0 to 31 (for 32 bit shifts) + + `J' + Constant in range 0 to 63 (for 64 bit shifts) + + `K' + `0xff' + + `L' + `0xffff' + + `M' + 0, 1, 2, or 3 (shifts for `lea' instruction) + + `N' + Constant in range 0 to 255 (for `out' instruction) + + `G' + Standard 80387 floating point constant + +*Intel 960--`i960.h'* + `f' + Floating point register (`fp0' to `fp3') + + `l' + Local register (`r0' to `r15') + + `b' + Global register (`g0' to `g15') + + `d' + Any local or global register + + `I' + Integers from 0 to 31 + + `J' + 0 + + `K' + Integers from -31 to 0 + + `G' + Floating point 0 + + `H' + Floating point 1 + +*MIPS--`mips.h'* + `d' + General-purpose integer register + + `f' + Floating-point register (if available) + + `h' + `Hi' register + + `l' + `Lo' register + + `x' + `Hi' or `Lo' register + + `y' + General-purpose integer register + + `z' + Floating-point status register + + `I' + Signed 16 bit constant (for arithmetic instructions) + + `J' + Zero + + `K' + Zero-extended 16-bit constant (for logic instructions) + + `L' + Constant with low 16 bits zero (can be loaded with `lui') + + `M' + 32 bit constant which requires two instructions to load (a + constant which is not `I', `K', or `L') + + `N' + Negative 16 bit constant + + `O' + Exact power of two + + `P' + Positive 16 bit constant + + `G' + Floating point zero + + `Q' + Memory reference that can be loaded with more than one + instruction (`m' is preferable for `asm' statements) + + `R' + Memory reference that can be loaded with one instruction (`m' + is preferable for `asm' statements) + + `S' + Memory reference in external OSF/rose PIC format (`m' is + preferable for `asm' statements) + +*Motorola 680x0--`m68k.h'* + `a' + Address register + + `d' + Data register + + `f' + 68881 floating-point register, if available + + `x' + Sun FPA (floating-point) register, if available + + `y' + First 16 Sun FPA registers, if available + + `I' + Integer in the range 1 to 8 + + `J' + 16 bit signed number + + `K' + Signed number whose magnitude is greater than 0x80 + + `L' + Integer in the range -8 to -1 + + `G' + Floating point constant that is not a 68881 constant + + `H' + Floating point constant that can be used by Sun FPA + +*SPARC--`sparc.h'* + `f' + Floating-point register + + `I' + Signed 13 bit constant + + `J' + Zero + + `K' + 32 bit constant with the low 12 bits clear (a constant that + can be loaded with the `sethi' instruction) + + `G' + Floating-point zero + + `H' + Signed 13 bit constant, sign-extended to 32 or 64 bits + + `Q' + Memory reference that can be loaded with one instruction + (`m' is more appropriate for `asm' statements) + + `S' + Constant, or memory address + + `T' + Memory address aligned to an 8-byte boundary + + `U' + Even register + + +File: gcc.info, Node: No Constraints, Prev: Machine Constraints, 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.