![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to md.texi CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to md.texi CVS log | Up to [GCC 2.x] / gcc |
1.1.1.5 ! root 1: @c Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc. 1.1 root 2: @c This is part of the GCC manual. 3: @c For copying conditions, see the file gcc.texi. 4: 5: @ifset INTERNALS 1.1.1.3 root 6: @node Machine Desc 1.1 root 7: @chapter Machine Descriptions 8: @cindex machine descriptions 9: 10: A machine description has two parts: a file of instruction patterns 11: (@file{.md} file) and a C header file of macro definitions. 12: 13: The @file{.md} file for a target machine contains a pattern for each 14: instruction that the target machine supports (or at least each instruction 15: that is worth telling the compiler about). It may also contain comments. 16: A semicolon causes the rest of the line to be a comment, unless the semicolon 17: is inside a quoted string. 18: 19: See the next chapter for information on the C header file. 20: 21: @menu 22: * Patterns:: How to write instruction patterns. 23: * Example:: An explained example of a @code{define_insn} pattern. 24: * RTL Template:: The RTL template defines what insns match a pattern. 25: * Output Template:: The output template says how to make assembler code 26: from such an insn. 27: * Output Statement:: For more generality, write C code to output 28: the assembler code. 29: * Constraints:: When not all operands are general operands. 30: * Standard Names:: Names mark patterns to use for code generation. 31: * Pattern Ordering:: When the order of patterns makes a difference. 32: * Dependent Patterns:: Having one pattern may make you need another. 33: * Jump Patterns:: Special considerations for patterns for jump insns. 34: * Insn Canonicalizations::Canonicalization of Instructions 35: * Peephole Definitions::Defining machine-specific peephole optimizations. 36: * Expander Definitions::Generating a sequence of several RTL insns 37: for a standard operation. 38: * Insn Splitting:: Splitting Instructions into Multiple Instructions 39: * Insn Attributes:: Specifying the value of attributes for generated insns. 40: @end menu 41: 1.1.1.5 ! root 42: @node Patterns 1.1 root 43: @section Everything about Instruction Patterns 44: @cindex patterns 45: @cindex instruction patterns 46: 47: @findex define_insn 48: Each instruction pattern contains an incomplete RTL expression, with pieces 49: to be filled in later, operand constraints that restrict how the pieces can 50: be filled in, and an output pattern or C code to generate the assembler 51: output, all wrapped up in a @code{define_insn} expression. 52: 53: A @code{define_insn} is an RTL expression containing four or five operands: 54: 55: @enumerate 56: @item 57: An optional name. The presence of a name indicate that this instruction 58: pattern can perform a certain standard job for the RTL-generation 59: pass of the compiler. This pass knows certain names and will use 60: the instruction patterns with those names, if the names are defined 61: in the machine description. 62: 63: The absence of a name is indicated by writing an empty string 64: where the name should go. Nameless instruction patterns are never 65: used for generating RTL code, but they may permit several simpler insns 66: to be combined later on. 67: 68: Names that are not thus known and used in RTL-generation have no 69: effect; they are equivalent to no name at all. 70: 71: @item 72: The @dfn{RTL template} (@pxref{RTL Template}) is a vector of incomplete 73: RTL expressions which show what the instruction should look like. It is 74: incomplete because it may contain @code{match_operand}, 75: @code{match_operator}, and @code{match_dup} expressions that stand for 76: operands of the instruction. 77: 78: If the vector has only one element, that element is the template for the 79: instruction pattern. If the vector has multiple elements, then the 80: instruction pattern is a @code{parallel} expression containing the 81: elements described. 82: 83: @item 84: @cindex pattern conditions 85: @cindex conditions, in patterns 86: A condition. This is a string which contains a C expression that is 87: the final test to decide whether an insn body matches this pattern. 88: 89: @cindex named patterns and conditions 90: For a named pattern, the condition (if present) may not depend on 91: the data in the insn being matched, but only the target-machine-type 92: flags. The compiler needs to test these conditions during 93: initialization in order to learn exactly which named instructions are 94: available in a particular run. 95: 96: @findex operands 97: For nameless patterns, the condition is applied only when matching an 98: individual insn, and only after the insn has matched the pattern's 99: recognition template. The insn's operands may be found in the vector 100: @code{operands}. 101: 102: @item 103: The @dfn{output template}: a string that says how to output matching 104: insns as assembler code. @samp{%} in this string specifies where 105: to substitute the value of an operand. @xref{Output Template}. 106: 107: When simple substitution isn't general enough, you can specify a piece 108: of C code to compute the output. @xref{Output Statement}. 109: 110: @item 111: Optionally, a vector containing the values of attributes for insns matching 112: this pattern. @xref{Insn Attributes}. 113: @end enumerate 114: 1.1.1.5 ! root 115: @node Example 1.1 root 116: @section Example of @code{define_insn} 117: @cindex @code{define_insn} example 118: 119: Here is an actual example of an instruction pattern, for the 68000/68020. 120: 121: @example 122: (define_insn "tstsi" 123: [(set (cc0) 124: (match_operand:SI 0 "general_operand" "rm"))] 125: "" 126: "* 127: @{ if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 128: return \"tstl %0\"; 129: return \"cmpl #0,%0\"; @}") 130: @end example 131: 132: This is an instruction that sets the condition codes based on the value of 133: a general operand. It has no condition, so any insn whose RTL description 134: has the form shown may be handled according to this pattern. The name 135: @samp{tstsi} means ``test a @code{SImode} value'' and tells the RTL generation 136: pass that, when it is necessary to test such a value, an insn to do so 137: can be constructed using this pattern. 138: 139: The output control string is a piece of C code which chooses which 140: output template to return based on the kind of operand and the specific 141: type of CPU for which code is being generated. 142: 143: @samp{"rm"} is an operand constraint. Its meaning is explained below. 144: 1.1.1.5 ! root 145: @node RTL Template ! 146: @section RTL Template 1.1 root 147: @cindex RTL insn template 148: @cindex generating insns 149: @cindex insns, generating 150: @cindex recognizing insns 151: @cindex insns, recognizing 152: 153: The RTL template is used to define which insns match the particular pattern 154: and how to find their operands. For named patterns, the RTL template also 155: says how to construct an insn from specified operands. 156: 157: Construction involves substituting specified operands into a copy of the 158: template. Matching involves determining the values that serve as the 159: operands in the insn being matched. Both of these activities are 160: controlled by special expression types that direct matching and 161: substitution of the operands. 162: 163: @table @code 164: @findex match_operand 165: @item (match_operand:@var{m} @var{n} @var{predicate} @var{constraint}) 166: This expression is a placeholder for operand number @var{n} of 167: the insn. When constructing an insn, operand number @var{n} 168: will be substituted at this point. When matching an insn, whatever 169: appears at this position in the insn will be taken as operand 170: number @var{n}; but it must satisfy @var{predicate} or this instruction 171: pattern will not match at all. 172: 173: Operand numbers must be chosen consecutively counting from zero in 174: each instruction pattern. There may be only one @code{match_operand} 175: expression in the pattern for each operand number. Usually operands 176: are numbered in the order of appearance in @code{match_operand} 177: expressions. 178: 179: @var{predicate} is a string that is the name of a C function that accepts two 180: arguments, an expression and a machine mode. During matching, the 181: function will be called with the putative operand as the expression and 182: @var{m} as the mode argument (if @var{m} is not specified, 183: @code{VOIDmode} will be used, which normally causes @var{predicate} to accept 184: any mode). If it returns zero, this instruction pattern fails to match. 185: @var{predicate} may be an empty string; then it means no test is to be done 186: on the operand, so anything which occurs in this position is valid. 187: 188: Most of the time, @var{predicate} will reject modes other than @var{m}---but 189: not always. For example, the predicate @code{address_operand} uses 190: @var{m} as the mode of memory ref that the address should be valid for. 191: Many predicates accept @code{const_int} nodes even though their mode is 192: @code{VOIDmode}. 193: 194: @var{constraint} controls reloading and the choice of the best register 195: class to use for a value, as explained later (@pxref{Constraints}). 196: 197: People are often unclear on the difference between the constraint and the 198: predicate. The predicate helps decide whether a given insn matches the 199: pattern. The constraint plays no role in this decision; instead, it 200: controls various decisions in the case of an insn which does match. 201: 202: @findex general_operand 1.1.1.5 ! root 203: On CISC machines, the most common @var{predicate} is ! 204: @code{"general_operand"}. This function checks that the putative ! 205: operand is either a constant, a register or a memory reference, and that ! 206: it is valid for mode @var{m}. 1.1 root 207: 208: @findex register_operand 209: For an operand that must be a register, @var{predicate} should be 1.1.1.5 ! root 210: @code{"register_operand"}. Using @code{"general_operand"} would be ! 211: valid, since the reload pass would copy any non-register operands ! 212: through registers, but this would make GNU CC do extra work, it would ! 213: prevent invariant operands (such as constant) from being removed from ! 214: loops, and it would prevent the register allocator from doing the best ! 215: possible job. On RISC machines, it is usually most efficient to allow ! 216: @var{predicate} to accept only objects that the constraints allow. 1.1 root 217: 218: @findex immediate_operand 1.1.1.5 ! root 219: For an operand that must be a constant, you must be sure to either use 1.1 root 220: @code{"immediate_operand"} for @var{predicate}, or make the instruction 221: pattern's extra condition require a constant, or both. You cannot 222: expect the constraints to do this work! If the constraints allow only 223: constants, but the predicate allows something else, the compiler will 224: crash when that case arises. 225: 226: @findex match_scratch 227: @item (match_scratch:@var{m} @var{n} @var{constraint}) 228: This expression is also a placeholder for operand number @var{n} 229: and indicates that operand must be a @code{scratch} or @code{reg} 230: expression. 231: 232: When matching patterns, this is completely equivalent to 233: 1.1.1.5 ! root 234: @smallexample 1.1 root 235: (match_operand:@var{m} @var{n} "scratch_operand" @var{pred}) 1.1.1.5 ! root 236: @end smallexample 1.1 root 237: 238: but, when generating RTL, it produces a (@code{scratch}:@var{m}) 239: expression. 240: 241: If the last few expressions in a @code{parallel} are @code{clobber} 242: expressions whose operands are either a hard register or 243: @code{match_scratch}, the combiner can add them when necessary. 244: @xref{Side Effects}. 245: 246: @findex match_dup 247: @item (match_dup @var{n}) 248: This expression is also a placeholder for operand number @var{n}. 249: It is used when the operand needs to appear more than once in the 250: insn. 251: 1.1.1.5 ! root 252: In construction, @code{match_dup} acts just like @code{match_operand}: ! 253: the operand is substituted into the insn being constructed. But in ! 254: matching, @code{match_dup} behaves differently. It assumes that operand ! 255: number @var{n} has already been determined by a @code{match_operand} ! 256: appearing earlier in the recognition template, and it matches only an ! 257: identical-looking expression. 1.1 root 258: 259: @findex match_operator 260: @item (match_operator:@var{m} @var{n} @var{predicate} [@var{operands}@dots{}]) 261: This pattern is a kind of placeholder for a variable RTL expression 262: code. 263: 264: When constructing an insn, it stands for an RTL expression whose 265: expression code is taken from that of operand @var{n}, and whose 266: operands are constructed from the patterns @var{operands}. 267: 268: When matching an expression, it matches an expression if the function 269: @var{predicate} returns nonzero on that expression @emph{and} the 270: patterns @var{operands} match the operands of the expression. 271: 272: Suppose that the function @code{commutative_operator} is defined as 273: follows, to match any expression whose operator is one of the 274: commutative arithmetic operators of RTL and whose mode is @var{mode}: 275: 1.1.1.5 ! root 276: @smallexample 1.1 root 277: int 278: commutative_operator (x, mode) 279: rtx x; 280: enum machine_mode mode; 281: @{ 282: enum rtx_code code = GET_CODE (x); 283: if (GET_MODE (x) != mode) 284: return 0; 1.1.1.5 ! root 285: return (GET_RTX_CLASS (code) == 'c' ! 286: || code == EQ || code == NE); 1.1 root 287: @} 1.1.1.5 ! root 288: @end smallexample 1.1 root 289: 290: Then the following pattern will match any RTL expression consisting 291: of a commutative operator applied to two general operands: 292: 1.1.1.5 ! root 293: @smallexample 1.1 root 294: (match_operator:SI 3 "commutative_operator" 295: [(match_operand:SI 1 "general_operand" "g") 296: (match_operand:SI 2 "general_operand" "g")]) 1.1.1.5 ! root 297: @end smallexample 1.1 root 298: 299: Here the vector @code{[@var{operands}@dots{}]} contains two patterns 300: because the expressions to be matched all contain two operands. 301: 302: When this pattern does match, the two operands of the commutative 303: operator are recorded as operands 1 and 2 of the insn. (This is done 304: by the two instances of @code{match_operand}.) Operand 3 of the insn 305: will be the entire commutative expression: use @code{GET_CODE 306: (operands[3])} to see which commutative operator was used. 307: 308: The machine mode @var{m} of @code{match_operator} works like that of 309: @code{match_operand}: it is passed as the second argument to the 310: predicate function, and that function is solely responsible for 311: deciding whether the expression to be matched ``has'' that mode. 312: 313: When constructing an insn, argument 3 of the gen-function will specify 314: the operation (i.e. the expression code) for the expression to be 315: made. It should be an RTL expression, whose expression code is copied 316: into a new expression whose operands are arguments 1 and 2 of the 317: gen-function. The subexpressions of argument 3 are not used; 318: only its expression code matters. 319: 320: When @code{match_operator} is used in a pattern for matching an insn, 321: it usually best if the operand number of the @code{match_operator} 322: is higher than that of the actual operands of the insn. This improves 323: register allocation because the register allocator often looks at 324: operands 1 and 2 of insns to see if it can do register tying. 325: 326: There is no way to specify constraints in @code{match_operator}. The 327: operand of the insn which corresponds to the @code{match_operator} 328: never has any constraints because it is never reloaded as a whole. 329: However, if parts of its @var{operands} are matched by 330: @code{match_operand} patterns, those parts may have constraints of 331: their own. 332: 1.1.1.4 root 333: @findex match_op_dup 334: @item (match_op_dup:@var{m} @var{n}[@var{operands}@dots{}]) 335: Like @code{match_dup}, except that it applies to operators instead of 336: operands. When constructing an insn, operand number @var{n} will be 337: substituted at this point. But in matching, @code{match_op_dup} behaves 338: differently. It assumes that operand number @var{n} has already been 339: determined by a @code{match_operator} appearing earlier in the 340: recognition template, and it matches only an identical-looking 341: expression. 342: 1.1.1.3 root 343: @findex match_parallel 344: @item (match_parallel @var{n} @var{predicate} [@var{subpat}@dots{}]) 345: This pattern is a placeholder for an insn that consists of a 346: @code{parallel} expression with a variable number of elements. This 347: expression should only appear at the top level of an insn pattern. 348: 349: When constructing an insn, operand number @var{n} will be substituted at 350: this point. When matching an insn, it matches if the body of the insn 351: is a @code{parallel} expression with at least as many elements as the 352: vector of @var{subpat} expressions in the @code{match_parallel}, if each 353: @var{subpat} matches the corresponding element of the @code{parallel}, 354: @emph{and} the function @var{predicate} returns nonzero on the 355: @code{parallel} that is the body of the insn. It is the responsibility 356: of the predicate to validate elements of the @code{parallel} beyond 357: those listed in the @code{match_parallel}.@refill 358: 359: A typical use of @code{match_parallel} is to match load and store 360: multiple expressions, which can contains a variable number of elements 361: in a @code{parallel}. For example, 1.1.1.5 ! root 362: @c the following is *still* going over. need to change the code. ! 363: @c also need to work on grouping of this example. --mew 1feb93 1.1.1.3 root 364: 1.1.1.5 ! root 365: @smallexample 1.1.1.3 root 366: (define_insn "" 367: [(match_parallel 0 "load_multiple_operation" 1.1.1.5 ! root 368: [(set (match_operand:SI 1 "gpc_reg_operand" "=r") ! 369: (match_operand:SI 2 "memory_operand" "m")) ! 370: (use (reg:SI 179)) ! 371: (clobber (reg:SI 179))])] 1.1.1.3 root 372: "" 373: "loadm 0,0,%1,%2") 1.1.1.5 ! root 374: @end smallexample 1.1.1.3 root 375: 376: This example comes from @file{a29k.md}. The function 377: @code{load_multiple_operations} is defined in @file{a29k.c} and checks 378: that subsequent elements in the @code{parallel} are the same as the 379: @code{set} in the pattern, except that they are referencing subsequent 380: registers and memory locations. 381: 382: An insn that matches this pattern might look like: 383: 1.1.1.5 ! root 384: @smallexample ! 385: (parallel ! 386: [(set (reg:SI 20) (mem:SI (reg:SI 100))) ! 387: (use (reg:SI 179)) ! 388: (clobber (reg:SI 179)) ! 389: (set (reg:SI 21) ! 390: (mem:SI (plus:SI (reg:SI 100) ! 391: (const_int 4)))) ! 392: (set (reg:SI 22) ! 393: (mem:SI (plus:SI (reg:SI 100) ! 394: (const_int 8))))]) ! 395: @end smallexample 1.1.1.3 root 396: 1.1.1.4 root 397: @findex match_par_dup 398: @item (match_par_dup @var{n} [@var{subpat}@dots{}]) 399: Like @code{match_op_dup}, but for @code{match_parallel} instead of 400: @code{match_operator}. 401: 1.1 root 402: @findex address 403: @item (address (match_operand:@var{m} @var{n} "address_operand" "")) 404: This complex of expressions is a placeholder for an operand number 405: @var{n} in a ``load address'' instruction: an operand which specifies 406: a memory location in the usual way, but for which the actual operand 407: value used is the address of the location, not the contents of the 408: location. 409: 410: @code{address} expressions never appear in RTL code, only in machine 411: descriptions. And they are used only in machine descriptions that do 412: not use the operand constraint feature. When operand constraints are 413: in use, the letter @samp{p} in the constraint serves this purpose. 414: 415: @var{m} is the machine mode of the @emph{memory location being 416: addressed}, not the machine mode of the address itself. That mode is 417: always the same on a given target machine (it is @code{Pmode}, which 418: normally is @code{SImode}), so there is no point in mentioning it; 419: thus, no machine mode is written in the @code{address} expression. If 420: some day support is added for machines in which addresses of different 421: kinds of objects appear differently or are used differently (such as 422: the PDP-10), different formats would perhaps need different machine 423: modes and these modes might be written in the @code{address} 424: expression. 425: @end table 426: 1.1.1.5 ! root 427: @node Output Template 1.1 root 428: @section Output Templates and Operand Substitution 429: @cindex output templates 430: @cindex operand substitution 431: 432: @cindex @samp{%} in template 433: @cindex percent sign 434: The @dfn{output template} is a string which specifies how to output the 435: assembler code for an instruction pattern. Most of the template is a 436: fixed string which is output literally. The character @samp{%} is used 437: to specify where to substitute an operand; it can also be used to 438: identify places where different variants of the assembler require 439: different syntax. 440: 441: In the simplest case, a @samp{%} followed by a digit @var{n} says to output 442: operand @var{n} at that point in the string. 443: 444: @samp{%} followed by a letter and a digit says to output an operand in an 445: alternate fashion. Four letters have standard, built-in meanings described 446: below. The machine description macro @code{PRINT_OPERAND} can define 447: additional letters with nonstandard meanings. 448: 449: @samp{%c@var{digit}} can be used to substitute an operand that is a 450: constant value without the syntax that normally indicates an immediate 451: operand. 452: 453: @samp{%n@var{digit}} is like @samp{%c@var{digit}} except that the value of 454: the constant is negated before printing. 455: 456: @samp{%a@var{digit}} can be used to substitute an operand as if it were a 457: memory reference, with the actual operand treated as the address. This may 458: be useful when outputting a ``load address'' instruction, because often the 459: assembler syntax for such an instruction requires you to write the operand 460: as if it were a memory reference. 461: 462: @samp{%l@var{digit}} is used to substitute a @code{label_ref} into a jump 463: instruction. 464: 1.1.1.4 root 465: @samp{%=} outputs a number which is unique to each instruction in the 466: entire compilation. This is useful for making local labels to be 467: referred to more than once in a single template that generates multiple 468: assembler instructions. 469: 1.1 root 470: @samp{%} followed by a punctuation character specifies a substitution that 471: does not use an operand. Only one case is standard: @samp{%%} outputs a 472: @samp{%} into the assembler code. Other nonstandard cases can be 473: defined in the @code{PRINT_OPERAND} macro. You must also define 474: which punctuation characters are valid with the 475: @code{PRINT_OPERAND_PUNCT_VALID_P} macro. 476: 477: @cindex \ 478: @cindex backslash 479: The template may generate multiple assembler instructions. Write the text 480: for the instructions, with @samp{\;} between them. 481: 482: @cindex matching operands 483: When the RTL contains two operands which are required by constraint to match 484: each other, the output template must refer only to the lower-numbered operand. 485: Matching operands are not always identical, and the rest of the compiler 486: arranges to put the proper RTL expression for printing into the lower-numbered 487: operand. 488: 489: One use of nonstandard letters or punctuation following @samp{%} is to 490: distinguish between different assembler languages for the same machine; for 491: example, Motorola syntax versus MIT syntax for the 68000. Motorola syntax 492: requires periods in most opcode names, while MIT syntax does not. For 493: example, the opcode @samp{movel} in MIT syntax is @samp{move.l} in Motorola 494: syntax. The same file of patterns is used for both kinds of output syntax, 495: but the character sequence @samp{%.} is used in each place where Motorola 496: syntax wants a period. The @code{PRINT_OPERAND} macro for Motorola syntax 497: defines the sequence to output a period; the macro for MIT syntax defines 498: it to do nothing. 499: 1.1.1.5 ! root 500: @cindex @code{#} in template ! 501: As a special case, a template consisting of the single character @code{#} ! 502: instructs the compiler to first split the insn, and then output the ! 503: resulting instructions separately. This helps eliminate redundancy in the ! 504: output templates. If you have a @code{define_insn} that needs to emit ! 505: multiple assembler instructions, and there is an matching @code{define_split} ! 506: already defined, then you can simply use @code{#} as the output template ! 507: instead of writing an output template that emits the multiple assembler ! 508: instructions. ! 509: ! 510: @node Output Statement ! 511: @section C Statements for Assembler Output 1.1 root 512: @cindex output statements 513: @cindex C statements for assembler output 514: @cindex generating assembler output 515: 516: Often a single fixed template string cannot produce correct and efficient 517: assembler code for all the cases that are recognized by a single 518: instruction pattern. For example, the opcodes may depend on the kinds of 519: operands; or some unfortunate combinations of operands may require extra 520: machine instructions. 521: 522: If the output control string starts with a @samp{@@}, then it is actually 523: a series of templates, each on a separate line. (Blank lines and 524: leading spaces and tabs are ignored.) The templates correspond to the 525: pattern's constraint alternatives (@pxref{Multi-Alternative}). For example, 526: if a target machine has a two-address add instruction @samp{addr} to add 527: into a register and another @samp{addm} to add a register to memory, you 528: might write this pattern: 529: 1.1.1.5 ! root 530: @smallexample 1.1 root 531: (define_insn "addsi3" 1.1.1.3 root 532: [(set (match_operand:SI 0 "general_operand" "=r,m") 1.1 root 533: (plus:SI (match_operand:SI 1 "general_operand" "0,0") 534: (match_operand:SI 2 "general_operand" "g,r")))] 535: "" 536: "@@ 1.1.1.4 root 537: addr %2,%0 538: addm %2,%0") 1.1.1.5 ! root 539: @end smallexample 1.1 root 540: 541: @cindex @code{*} in template 542: @cindex asterisk in template 543: If the output control string starts with a @samp{*}, then it is not an 544: output template but rather a piece of C program that should compute a 545: template. It should execute a @code{return} statement to return the 546: template-string you want. Most such templates use C string literals, which 547: require doublequote characters to delimit them. To include these 548: doublequote characters in the string, prefix each one with @samp{\}. 549: 550: The operands may be found in the array @code{operands}, whose C data type 551: is @code{rtx []}. 552: 553: It is very common to select different ways of generating assembler code 554: based on whether an immediate operand is within a certain range. Be 555: careful when doing this, because the result of @code{INTVAL} is an 556: integer on the host machine. If the host machine has more bits in an 557: @code{int} than the target machine has in the mode in which the constant 558: will be used, then some of the bits you get from @code{INTVAL} will be 559: superfluous. For proper results, you must carefully disregard the 560: values of those bits. 561: 562: @findex output_asm_insn 563: It is possible to output an assembler instruction and then go on to output 564: or compute more of them, using the subroutine @code{output_asm_insn}. This 565: receives two arguments: a template-string and a vector of operands. The 566: vector may be @code{operands}, or it may be another array of @code{rtx} 567: that you declare locally and initialize yourself. 568: 569: @findex which_alternative 570: When an insn pattern has multiple alternatives in its constraints, often 571: the appearance of the assembler code is determined mostly by which alternative 572: was matched. When this is so, the C code can test the variable 573: @code{which_alternative}, which is the ordinal number of the alternative 574: that was actually satisfied (0 for the first, 1 for the second alternative, 575: etc.). 576: 577: For example, suppose there are two opcodes for storing zero, @samp{clrreg} 578: for registers and @samp{clrmem} for memory locations. Here is how 579: a pattern could use @code{which_alternative} to choose between them: 580: 1.1.1.5 ! root 581: @smallexample 1.1 root 582: (define_insn "" 1.1.1.3 root 583: [(set (match_operand:SI 0 "general_operand" "=r,m") 1.1 root 584: (const_int 0))] 585: "" 586: "* 587: return (which_alternative == 0 588: ? \"clrreg %0\" : \"clrmem %0\"); 589: ") 1.1.1.5 ! root 590: @end smallexample 1.1 root 591: 592: The example above, where the assembler code to generate was 593: @emph{solely} determined by the alternative, could also have been specified 594: as follows, having the output control string start with a @samp{@@}: 595: 1.1.1.5 ! root 596: @smallexample ! 597: @group 1.1 root 598: (define_insn "" 1.1.1.3 root 599: [(set (match_operand:SI 0 "general_operand" "=r,m") 1.1 root 600: (const_int 0))] 601: "" 602: "@@ 603: clrreg %0 604: clrmem %0") 1.1.1.5 ! root 605: @end group ! 606: @end smallexample ! 607: @end ifset 1.1 root 608: 1.1.1.5 ! root 609: @c Most of this node appears by itself (in a different place) even ! 610: @c when the INTERNALS flag is clear. Passages that require the full ! 611: @c manual's context are conditionalized to appear only in the full manual. ! 612: @ifset INTERNALS ! 613: @node Constraints 1.1 root 614: @section Operand Constraints 615: @cindex operand constraints 616: @cindex constraints 617: 618: Each @code{match_operand} in an instruction pattern can specify a 1.1.1.5 ! root 619: constraint for the type of operands allowed. ! 620: @end ifset ! 621: @ifclear INTERNALS ! 622: @node Constraints ! 623: @section Constraints for @code{asm} Operands ! 624: @cindex operand constraints, @code{asm} ! 625: @cindex constraints, @code{asm} ! 626: @cindex @code{asm} constraints ! 627: Here are specific details on what constraint letters you can use with ! 628: @code{asm} operands. ! 629: @end ifclear ! 630: Constraints can say whether 1.1 root 631: an operand may be in a register, and which kinds of register; whether the 632: operand can be a memory reference, and which kinds of address; whether the 633: operand may be an immediate constant, and which possible values it may 634: have. Constraints can also require two operands to match. 635: 1.1.1.5 ! root 636: @ifset INTERNALS 1.1 root 637: @menu 638: * Simple Constraints:: Basic use of constraints. 639: * Multi-Alternative:: When an insn has two alternative constraint-patterns. 640: * Class Preferences:: Constraints guide which hard register to put things in. 641: * Modifiers:: More precise control over effects of constraints. 1.1.1.5 ! root 642: * Machine Constraints:: Existing constraints for some particular machines. 1.1 root 643: * No Constraints:: Describing a clean machine without constraints. 644: @end menu 1.1.1.5 ! root 645: @end ifset 1.1 root 646: 1.1.1.5 ! root 647: @ifclear INTERNALS ! 648: @menu ! 649: * Simple Constraints:: Basic use of constraints. ! 650: * Multi-Alternative:: When an insn has two alternative constraint-patterns. ! 651: * Modifiers:: More precise control over effects of constraints. ! 652: * Machine Constraints:: Special constraints for some particular machines. ! 653: @end menu ! 654: @end ifclear ! 655: ! 656: @node Simple Constraints 1.1 root 657: @subsection Simple Constraints 658: @cindex simple constraints 659: 660: The simplest kind of constraint is a string full of letters, each of 661: which describes one kind of operand that is permitted. Here are 662: the letters that are allowed: 663: 664: @table @asis 665: @cindex @samp{m} in constraint 666: @cindex memory references in constraints 667: @item @samp{m} 668: A memory operand is allowed, with any kind of address that the machine 669: supports in general. 670: 671: @cindex offsettable address 672: @cindex @samp{o} in constraint 673: @item @samp{o} 674: A memory operand is allowed, but only if the address is 675: @dfn{offsettable}. This means that adding a small integer (actually, 676: the width in bytes of the operand, as determined by its machine mode) 677: may be added to the address and the result is also a valid memory 678: address. 679: 680: @cindex autoincrement/decrement addressing 681: For example, an address which is constant is offsettable; so is an 682: address that is the sum of a register and a constant (as long as a 683: slightly larger constant is also within the range of address-offsets 684: supported by the machine); but an autoincrement or autodecrement 685: address is not offsettable. More complicated indirect/indexed 686: addresses may or may not be offsettable depending on the other 687: addressing modes that the machine supports. 688: 689: Note that in an output operand which can be matched by another 690: operand, the constraint letter @samp{o} is valid only when accompanied 691: by both @samp{<} (if the target machine has predecrement addressing) 692: and @samp{>} (if the target machine has preincrement addressing). 693: 694: @cindex @samp{V} in constraint 695: @item @samp{V} 696: A memory operand that is not offsettable. In other words, anything that 697: would fit the @samp{m} constraint but not the @samp{o} constraint. 698: 699: @cindex @samp{<} in constraint 700: @item @samp{<} 701: A memory operand with autodecrement addressing (either predecrement or 702: postdecrement) is allowed. 703: 704: @cindex @samp{>} in constraint 705: @item @samp{>} 706: A memory operand with autoincrement addressing (either preincrement or 707: postincrement) is allowed. 708: 709: @cindex @samp{r} in constraint 710: @cindex registers in constraints 711: @item @samp{r} 712: A register operand is allowed provided that it is in a general 713: register. 714: 715: @cindex @samp{d} in constraint 716: @item @samp{d}, @samp{a}, @samp{f}, @dots{} 717: Other letters can be defined in machine-dependent fashion to stand for 718: particular classes of registers. @samp{d}, @samp{a} and @samp{f} are 719: defined on the 68000/68020 to stand for data, address and floating 720: point registers. 721: 722: @cindex constants in constraints 723: @cindex @samp{i} in constraint 724: @item @samp{i} 725: An immediate integer operand (one with constant value) is allowed. 726: This includes symbolic constants whose values will be known only at 727: assembly time. 728: 729: @cindex @samp{n} in constraint 730: @item @samp{n} 731: An immediate integer operand with a known numeric value is allowed. 732: Many systems cannot support assembly-time constants for operands less 733: than a word wide. Constraints for these operands should use @samp{n} 734: rather than @samp{i}. 735: 736: @cindex @samp{I} in constraint 737: @item @samp{I}, @samp{J}, @samp{K}, @dots{} @samp{P} 738: Other letters in the range @samp{I} through @samp{P} may be defined in 739: a machine-dependent fashion to permit immediate integer operands with 740: explicit integer values in specified ranges. For example, on the 741: 68000, @samp{I} is defined to stand for the range of values 1 to 8. 742: This is the range permitted as a shift count in the shift 743: instructions. 744: 745: @cindex @samp{E} in constraint 746: @item @samp{E} 747: An immediate floating operand (expression code @code{const_double}) is 748: allowed, but only if the target floating point format is the same as 749: that of the host machine (on which the compiler is running). 750: 751: @cindex @samp{F} in constraint 752: @item @samp{F} 753: An immediate floating operand (expression code @code{const_double}) is 754: allowed. 755: 756: @cindex @samp{G} in constraint 757: @cindex @samp{H} in constraint 758: @item @samp{G}, @samp{H} 759: @samp{G} and @samp{H} may be defined in a machine-dependent fashion to 760: permit immediate floating operands in particular ranges of values. 761: 762: @cindex @samp{s} in constraint 763: @item @samp{s} 764: An immediate integer operand whose value is not an explicit integer is 765: allowed. 766: 767: This might appear strange; if an insn allows a constant operand with a 768: value not known at compile time, it certainly must allow any known 769: value. So why use @samp{s} instead of @samp{i}? Sometimes it allows 770: better code to be generated. 771: 772: For example, on the 68000 in a fullword instruction it is possible to 773: use an immediate operand; but if the immediate value is between -128 774: and 127, better code results from loading the value into a register and 775: using the register. This is because the load into the register can be 776: done with a @samp{moveq} instruction. We arrange for this to happen 777: by defining the letter @samp{K} to mean ``any integer outside the 778: range -128 to 127'', and then specifying @samp{Ks} in the operand 779: constraints. 780: 781: @cindex @samp{g} in constraint 782: @item @samp{g} 783: Any register, memory or immediate integer operand is allowed, except for 784: registers that are not general registers. 785: 786: @cindex @samp{X} in constraint 787: @item @samp{X} 1.1.1.5 ! root 788: @ifset INTERNALS 1.1 root 789: Any operand whatsoever is allowed, even if it does not satisfy 790: @code{general_operand}. This is normally used in the constraint of 791: a @code{match_scratch} when certain alternatives will not actually 792: require a scratch register. 1.1.1.5 ! root 793: @end ifset ! 794: @ifclear INTERNALS ! 795: Any operand whatsoever is allowed. ! 796: @end ifclear 1.1 root 797: 798: @cindex @samp{0} in constraint 799: @cindex digits in constraint 800: @item @samp{0}, @samp{1}, @samp{2}, @dots{} @samp{9} 801: An operand that matches the specified operand number is allowed. If a 802: digit is used together with letters within the same alternative, the 803: digit should come last. 804: 805: @cindex matching constraint 806: @cindex constraint, matching 807: This is called a @dfn{matching constraint} and what it really means is 808: that the assembler has only a single operand that fills two roles 1.1.1.5 ! root 809: @ifset INTERNALS 1.1 root 810: considered separate in the RTL insn. For example, an add insn has two 1.1.1.3 root 811: input operands and one output operand in the RTL, but on most CISC 1.1.1.5 ! root 812: @end ifset ! 813: @ifclear INTERNALS ! 814: which @code{asm} distinguishes. For example, an add instruction uses ! 815: two input operands and an output operand, but on most CISC ! 816: @end ifclear 1.1.1.3 root 817: machines an add instruction really has only two operands, one of them an 818: input-output operand: 819: 1.1.1.5 ! root 820: @smallexample 1.1.1.3 root 821: addl #35,r12 1.1.1.5 ! root 822: @end smallexample 1.1 root 823: 1.1.1.3 root 824: Matching constraints are used in these circumstances. 1.1 root 825: More precisely, the two operands that match must include one input-only 826: operand and one output-only operand. Moreover, the digit must be a 827: smaller number than the number of the operand that uses it in the 828: constraint. 829: 1.1.1.5 ! root 830: @ifset INTERNALS 1.1 root 831: For operands to match in a particular case usually means that they 832: are identical-looking RTL expressions. But in a few special cases 833: specific kinds of dissimilarity are allowed. For example, @code{*x} 834: as an input operand will match @code{*x++} as an output operand. 835: For proper results in such cases, the output template should always 836: use the output-operand's number when printing the operand. 1.1.1.5 ! root 837: @end ifset 1.1 root 838: 839: @cindex load address instruction 840: @cindex push address instruction 841: @cindex address constraints 842: @cindex @samp{p} in constraint 843: @item @samp{p} 844: An operand that is a valid memory address is allowed. This is 845: for ``load address'' and ``push address'' instructions. 846: 847: @findex address_operand 848: @samp{p} in the constraint must be accompanied by @code{address_operand} 849: as the predicate in the @code{match_operand}. This predicate interprets 850: the mode specified in the @code{match_operand} as the mode of the memory 851: reference for which the address would be valid. 852: 853: @cindex extensible constraints 854: @cindex @samp{Q}, in constraint 855: @item @samp{Q}, @samp{R}, @samp{S}, @dots{} @samp{U} 856: Letters in the range @samp{Q} through @samp{U} may be defined in a 857: machine-dependent fashion to stand for arbitrary operand types. 1.1.1.5 ! root 858: @ifset INTERNALS 1.1 root 859: The machine description macro @code{EXTRA_CONSTRAINT} is passed the 860: operand as its first argument and the constraint letter as its 861: second operand. 862: 863: A typical use for this would be to distinguish certain types of 864: memory references that affect other insn operands. 865: 866: Do not define these constraint letters to accept register references 867: (@code{reg}); the reload pass does not expect this and would not handle 868: it properly. 1.1.1.5 ! root 869: @end ifset 1.1 root 870: @end table 871: 1.1.1.5 ! root 872: @ifset INTERNALS 1.1 root 873: In order to have valid assembler code, each operand must satisfy 874: its constraint. But a failure to do so does not prevent the pattern 875: from applying to an insn. Instead, it directs the compiler to modify 876: the code so that the constraint will be satisfied. Usually this is 877: done by copying an operand into a register. 878: 879: Contrast, therefore, the two instruction patterns that follow: 880: 1.1.1.5 ! root 881: @smallexample 1.1 root 882: (define_insn "" 1.1.1.3 root 883: [(set (match_operand:SI 0 "general_operand" "=r") 1.1 root 884: (plus:SI (match_dup 0) 885: (match_operand:SI 1 "general_operand" "r")))] 886: "" 887: "@dots{}") 1.1.1.5 ! root 888: @end smallexample 1.1 root 889: 890: @noindent 891: which has two operands, one of which must appear in two places, and 892: 1.1.1.5 ! root 893: @smallexample 1.1 root 894: (define_insn "" 1.1.1.3 root 895: [(set (match_operand:SI 0 "general_operand" "=r") 1.1 root 896: (plus:SI (match_operand:SI 1 "general_operand" "0") 897: (match_operand:SI 2 "general_operand" "r")))] 898: "" 899: "@dots{}") 1.1.1.5 ! root 900: @end smallexample 1.1 root 901: 902: @noindent 903: which has three operands, two of which are required by a constraint to be 904: identical. If we are considering an insn of the form 905: 1.1.1.5 ! root 906: @smallexample 1.1 root 907: (insn @var{n} @var{prev} @var{next} 908: (set (reg:SI 3) 909: (plus:SI (reg:SI 6) (reg:SI 109))) 910: @dots{}) 1.1.1.5 ! root 911: @end smallexample 1.1 root 912: 913: @noindent 914: the first pattern would not apply at all, because this insn does not 915: contain two identical subexpressions in the right place. The pattern would 916: say, ``That does not look like an add instruction; try other patterns.'' 917: The second pattern would say, ``Yes, that's an add instruction, but there 918: is something wrong with it.'' It would direct the reload pass of the 919: compiler to generate additional insns to make the constraint true. The 920: results might look like this: 921: 1.1.1.5 ! root 922: @smallexample 1.1 root 923: (insn @var{n2} @var{prev} @var{n} 924: (set (reg:SI 3) (reg:SI 6)) 925: @dots{}) 926: 927: (insn @var{n} @var{n2} @var{next} 928: (set (reg:SI 3) 929: (plus:SI (reg:SI 3) (reg:SI 109))) 930: @dots{}) 1.1.1.5 ! root 931: @end smallexample 1.1 root 932: 933: It is up to you to make sure that each operand, in each pattern, has 934: constraints that can handle any RTL expression that could be present for 935: that operand. (When multiple alternatives are in use, each pattern must, 936: for each possible combination of operand expressions, have at least one 937: alternative which can handle that combination of operands.) The 938: constraints don't need to @emph{allow} any possible operand---when this is 939: the case, they do not constrain---but they must at least point the way to 940: reloading any possible operand so that it will fit. 941: 942: @itemize @bullet 943: @item 944: If the constraint accepts whatever operands the predicate permits, 945: there is no problem: reloading is never necessary for this operand. 946: 947: For example, an operand whose constraints permit everything except 948: registers is safe provided its predicate rejects registers. 949: 950: An operand whose predicate accepts only constant values is safe 951: provided its constraints include the letter @samp{i}. If any possible 952: constant value is accepted, then nothing less than @samp{i} will do; 953: if the predicate is more selective, then the constraints may also be 954: more selective. 955: 956: @item 957: Any operand expression can be reloaded by copying it into a register. 958: So if an operand's constraints allow some kind of register, it is 959: certain to be safe. It need not permit all classes of registers; the 960: compiler knows how to copy a register into another register of the 961: proper class in order to make an instruction valid. 962: 963: @cindex nonoffsettable memory reference 964: @cindex memory reference, nonoffsettable 965: @item 966: A nonoffsettable memory reference can be reloaded by copying the 967: address into a register. So if the constraint uses the letter 968: @samp{o}, all memory references are taken care of. 969: 970: @item 971: A constant operand can be reloaded by allocating space in memory to 972: hold it as preinitialized data. Then the memory reference can be used 973: in place of the constant. So if the constraint uses the letters 974: @samp{o} or @samp{m}, constant operands are not a problem. 975: 976: @item 977: If the constraint permits a constant and a pseudo register used in an insn 978: was not allocated to a hard register and is equivalent to a constant, 979: the register will be replaced with the constant. If the predicate does 980: not permit a constant and the insn is re-recognized for some reason, the 981: compiler will crash. Thus the predicate must always recognize any 982: objects allowed by the constraint. 983: @end itemize 984: 985: If the operand's predicate can recognize registers, but the constraint does 986: not permit them, it can make the compiler crash. When this operand happens 987: to be a register, the reload pass will be stymied, because it does not know 988: how to copy a register temporarily into memory. 1.1.1.5 ! root 989: @end ifset 1.1 root 990: 1.1.1.5 ! root 991: @node Multi-Alternative 1.1 root 992: @subsection Multiple Alternative Constraints 993: @cindex multiple alternative constraints 994: 995: Sometimes a single instruction has multiple alternative sets of possible 996: operands. For example, on the 68000, a logical-or instruction can combine 997: register or an immediate value into memory, or it can combine any kind of 998: operand into a register; but it cannot combine one memory location into 999: another. 1000: 1001: These constraints are represented as multiple alternatives. An alternative 1002: can be described by a series of letters for each operand. The overall 1003: constraint for an operand is made from the letters for this operand 1004: from the first alternative, a comma, the letters for this operand from 1005: the second alternative, a comma, and so on until the last alternative. 1.1.1.5 ! root 1006: @ifset INTERNALS 1.1 root 1007: Here is how it is done for fullword logical-or on the 68000: 1008: 1.1.1.5 ! root 1009: @smallexample 1.1 root 1010: (define_insn "iorsi3" 1011: [(set (match_operand:SI 0 "general_operand" "=m,d") 1012: (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 1013: (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 1014: @dots{}) 1.1.1.5 ! root 1015: @end smallexample 1.1 root 1016: 1017: The first alternative has @samp{m} (memory) for operand 0, @samp{0} for 1018: operand 1 (meaning it must match operand 0), and @samp{dKs} for operand 1019: 2. The second alternative has @samp{d} (data register) for operand 0, 1020: @samp{0} for operand 1, and @samp{dmKs} for operand 2. The @samp{=} and 1021: @samp{%} in the constraints apply to all the alternatives; their 1022: meaning is explained in the next section (@pxref{Class Preferences}). 1.1.1.5 ! root 1023: @end ifset 1.1 root 1024: 1.1.1.5 ! root 1025: @c FIXME Is this ? and ! stuff of use in asm()? If not, hide unless INTERNAL 1.1 root 1026: If all the operands fit any one alternative, the instruction is valid. 1027: Otherwise, for each alternative, the compiler counts how many instructions 1028: must be added to copy the operands so that that alternative applies. 1029: The alternative requiring the least copying is chosen. If two alternatives 1030: need the same amount of copying, the one that comes first is chosen. 1031: These choices can be altered with the @samp{?} and @samp{!} characters: 1032: 1033: @table @code 1034: @cindex @samp{?} in constraint 1035: @cindex question mark 1036: @item ? 1037: Disparage slightly the alternative that the @samp{?} appears in, 1038: as a choice when no alternative applies exactly. The compiler regards 1039: this alternative as one unit more costly for each @samp{?} that appears 1040: in it. 1041: 1042: @cindex @samp{!} in constraint 1043: @cindex exclamation point 1044: @item ! 1045: Disparage severely the alternative that the @samp{!} appears in. 1046: This alternative can still be used if it fits without reloading, 1047: but if reloading is needed, some other alternative will be used. 1048: @end table 1049: 1.1.1.5 ! root 1050: @ifset INTERNALS 1.1 root 1051: When an insn pattern has multiple alternatives in its constraints, often 1052: the appearance of the assembler code is determined mostly by which 1053: alternative was matched. When this is so, the C code for writing the 1054: assembler code can use the variable @code{which_alternative}, which is 1055: the ordinal number of the alternative that was actually satisfied (0 for 1056: the first, 1 for the second alternative, etc.). @xref{Output Statement}. 1.1.1.5 ! root 1057: @end ifset 1.1 root 1058: 1.1.1.5 ! root 1059: @ifset INTERNALS ! 1060: @node Class Preferences 1.1 root 1061: @subsection Register Class Preferences 1062: @cindex class preference constraints 1063: @cindex register class preference constraints 1064: 1065: @cindex voting between constraint alternatives 1066: The operand constraints have another function: they enable the compiler 1067: to decide which kind of hardware register a pseudo register is best 1068: allocated to. The compiler examines the constraints that apply to the 1069: insns that use the pseudo register, looking for the machine-dependent 1070: letters such as @samp{d} and @samp{a} that specify classes of registers. 1071: The pseudo register is put in whichever class gets the most ``votes''. 1072: The constraint letters @samp{g} and @samp{r} also vote: they vote in 1073: favor of a general register. The machine description says which registers 1074: are considered general. 1075: 1076: Of course, on some machines all registers are equivalent, and no register 1077: classes are defined. Then none of this complexity is relevant. 1.1.1.5 ! root 1078: @end ifset 1.1 root 1079: 1.1.1.5 ! root 1080: @node Modifiers 1.1 root 1081: @subsection Constraint Modifier Characters 1082: @cindex modifiers in constraints 1083: @cindex constraint modifier characters 1084: 1085: @table @samp 1086: @cindex @samp{=} in constraint 1087: @item = 1088: Means that this operand is write-only for this instruction: the previous 1089: value is discarded and replaced by output data. 1090: 1091: @cindex @samp{+} in constraint 1092: @item + 1093: Means that this operand is both read and written by the instruction. 1094: 1095: When the compiler fixes up the operands to satisfy the constraints, 1096: it needs to know which operands are inputs to the instruction and 1097: which are outputs from it. @samp{=} identifies an output; @samp{+} 1098: identifies an operand that is both input and output; all other operands 1099: are assumed to be input only. 1100: 1101: @cindex @samp{&} in constraint 1102: @item & 1103: Means (in a particular alternative) that this operand is written 1104: before the instruction is finished using the input operands. 1105: Therefore, this operand may not lie in a register that is used as an 1106: input operand or as part of any memory address. 1107: 1108: @samp{&} applies only to the alternative in which it is written. In 1109: constraints with multiple alternatives, sometimes one alternative 1110: requires @samp{&} while others do not. See, for example, the 1111: @samp{movdf} insn of the 68000. 1112: 1113: @samp{&} does not obviate the need to write @samp{=}. 1114: 1115: @cindex @samp{%} in constraint 1116: @item % 1117: Declares the instruction to be commutative for this operand and the 1118: following operand. This means that the compiler may interchange the 1119: two operands if that is the cheapest way to make all operands fit the 1.1.1.5 ! root 1120: constraints. ! 1121: @ifset INTERNALS ! 1122: This is often used in patterns for addition instructions 1.1 root 1123: that really have only two operands: the result must go in one of the 1124: arguments. Here for example, is how the 68000 halfword-add 1125: instruction is defined: 1126: 1.1.1.5 ! root 1127: @smallexample 1.1 root 1128: (define_insn "addhi3" 1129: [(set (match_operand:HI 0 "general_operand" "=m,r") 1130: (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 1131: (match_operand:HI 2 "general_operand" "di,g")))] 1132: @dots{}) 1.1.1.5 ! root 1133: @end smallexample ! 1134: @end ifset 1.1 root 1135: 1136: @cindex @samp{#} in constraint 1137: @item # 1138: Says that all following characters, up to the next comma, are to be 1139: ignored as a constraint. They are significant only for choosing 1140: register preferences. 1141: 1.1.1.5 ! root 1142: @ifset INTERNALS 1.1 root 1143: @cindex @samp{*} in constraint 1144: @item * 1145: Says that the following character should be ignored when choosing 1146: register preferences. @samp{*} has no effect on the meaning of the 1147: constraint as a constraint, and no effect on reloading. 1148: 1149: Here is an example: the 68000 has an instruction to sign-extend a 1150: halfword in a data register, and can also sign-extend a value by 1151: copying it into an address register. While either kind of register is 1152: acceptable, the constraints on an address-register destination are 1153: less strict, so it is best if register allocation makes an address 1154: register its goal. Therefore, @samp{*} is used so that the @samp{d} 1155: constraint letter (for data register) is ignored when computing 1156: register preferences. 1157: 1.1.1.5 ! root 1158: @smallexample 1.1 root 1159: (define_insn "extendhisi2" 1160: [(set (match_operand:SI 0 "general_operand" "=*d,a") 1161: (sign_extend:SI 1162: (match_operand:HI 1 "general_operand" "0,g")))] 1163: @dots{}) 1.1.1.5 ! root 1164: @end smallexample ! 1165: @end ifset ! 1166: @end table ! 1167: ! 1168: @node Machine Constraints ! 1169: @subsection Constraints for Particular Machines ! 1170: @cindex machine specific constraints ! 1171: @cindex constraints, machine specific ! 1172: ! 1173: Whenever possible, you should use the general-purpose constraint letters ! 1174: in @code{asm} arguments, since they will convey meaning more readily to ! 1175: people reading your code. Failing that, use the constraint letters ! 1176: that usually have very similar meanings across architectures. The most ! 1177: commonly used constraints are @samp{m} and @samp{r} (for memory and ! 1178: general-purpose registers respectively; @pxref{Simple Constraints}), and ! 1179: @samp{I}, usually the letter indicating the most common ! 1180: immediate-constant format. ! 1181: ! 1182: For each machine architecture, the @file{config/@var{machine}.h} file ! 1183: defines additional constraints. These constraints are used by the ! 1184: compiler itself for instruction generation, as well as for @code{asm} ! 1185: statements; therefore, some of the constraints are not particularly ! 1186: interesting for @code{asm}. The constraints are defined through these ! 1187: macros: ! 1188: ! 1189: @table @code ! 1190: @item REG_CLASS_FROM_LETTER ! 1191: Register class constraints (usually lower case). ! 1192: ! 1193: @item CONST_OK_FOR_LETTER_P ! 1194: Immediate constant constraints, for non-floating point constants of ! 1195: word size or smaller precision (usually upper case). ! 1196: ! 1197: @item CONST_DOUBLE_OK_FOR_LETTER_P ! 1198: Immediate constant constraints, for all floating point constants and for ! 1199: constants of greater than word size precision (usually upper case). ! 1200: ! 1201: @item EXTRA_CONSTRAINT ! 1202: Special cases of registers or memory. This macro is not required, and ! 1203: is only defined for some machines. ! 1204: @end table ! 1205: ! 1206: Inspecting these macro definitions in the compiler source for your ! 1207: machine is the best way to be certain you have the right constraints. ! 1208: However, here is a summary of the machine-dependent constraints ! 1209: available on some particular machines. ! 1210: ! 1211: @table @emph ! 1212: @item AMD 29000 family---@file{a29k.h} ! 1213: @table @code ! 1214: @item l ! 1215: Local register 0 ! 1216: ! 1217: @item b ! 1218: Byte Pointer (@samp{BP}) register ! 1219: ! 1220: @item q ! 1221: @samp{Q} register ! 1222: ! 1223: @item h ! 1224: Special purpose register ! 1225: ! 1226: @item A ! 1227: First accumulator register ! 1228: ! 1229: @item a ! 1230: Other accumulator register ! 1231: ! 1232: @item f ! 1233: Floating point register ! 1234: ! 1235: @item I ! 1236: Constant greater than 0, less than 0x100 ! 1237: ! 1238: @item J ! 1239: Constant greater than 0, less than 0x10000 ! 1240: ! 1241: @item K ! 1242: Constant whose high 24 bits are on (1) ! 1243: ! 1244: @item L ! 1245: 16 bit constant whose high 8 bits are on (1) ! 1246: ! 1247: @item M ! 1248: 32 bit constant whose high 16 bits are on (1) ! 1249: ! 1250: @item N ! 1251: 32 bit negative constant that fits in 8 bits ! 1252: ! 1253: @item O ! 1254: The constant 0x80000000 or, on the 29050, any 32 bit constant ! 1255: whose low 16 bits are 0. ! 1256: ! 1257: @item P ! 1258: 16 bit negative constant that fits in 8 bits ! 1259: ! 1260: @item G ! 1261: @itemx H ! 1262: A floating point constant (in @code{asm} statements, use the machine ! 1263: independent @samp{E} or @samp{F} instead) ! 1264: @end table ! 1265: ! 1266: @item IBM RS6000---@file{rs6000.h} ! 1267: @table @code ! 1268: @item b ! 1269: Address base register ! 1270: ! 1271: @item f ! 1272: Floating point register ! 1273: ! 1274: @item h ! 1275: @samp{MQ}, @samp{CTR}, or @samp{LINK} register ! 1276: ! 1277: @item q ! 1278: @samp{MQ} register ! 1279: ! 1280: @item c ! 1281: @samp{CTR} register ! 1282: ! 1283: @item l ! 1284: @samp{LINK} register ! 1285: ! 1286: @item x ! 1287: @samp{CR} register (condition register) number 0 ! 1288: ! 1289: @item y ! 1290: @samp{CR} register (condition register) ! 1291: ! 1292: @item I ! 1293: Signed 16 bit constant ! 1294: ! 1295: @item J ! 1296: Constant whose low 16 bits are 0 ! 1297: ! 1298: @item K ! 1299: Constant whose high 16 bits are 0 ! 1300: ! 1301: @item L ! 1302: Constant suitable as a mask operand ! 1303: ! 1304: @item M ! 1305: Constant larger than 31 ! 1306: ! 1307: @item N ! 1308: Exact power of 2 ! 1309: ! 1310: @item O ! 1311: Zero ! 1312: ! 1313: @item P ! 1314: Constant whose negation is a signed 16 bit constant ! 1315: ! 1316: @item G ! 1317: Floating point constant that can be loaded into a register with one ! 1318: instruction per word ! 1319: ! 1320: @item Q ! 1321: Memory operand that is an offset from a register (@samp{m} is preferable ! 1322: for @code{asm} statements) ! 1323: @end table ! 1324: ! 1325: @item Intel 386---@file{i386.h} ! 1326: @table @code ! 1327: @item q ! 1328: @samp{a}, @code{b}, @code{c}, or @code{d} register ! 1329: ! 1330: @item f ! 1331: Floating point register ! 1332: ! 1333: @item t ! 1334: First (top of stack) floating point register ! 1335: ! 1336: @item u ! 1337: Second floating point register ! 1338: ! 1339: @item a ! 1340: @samp{a} register ! 1341: ! 1342: @item b ! 1343: @samp{b} register ! 1344: ! 1345: @item c ! 1346: @samp{c} register ! 1347: ! 1348: @item d ! 1349: @samp{d} register ! 1350: ! 1351: @item D ! 1352: @samp{di} register ! 1353: ! 1354: @item S ! 1355: @samp{si} register ! 1356: ! 1357: @item I ! 1358: Constant in range 0 to 31 (for 32 bit shifts) ! 1359: ! 1360: @item J ! 1361: Constant in range 0 to 63 (for 64 bit shifts) ! 1362: ! 1363: @item K ! 1364: @samp{0xff} ! 1365: ! 1366: @item L ! 1367: @samp{0xffff} ! 1368: ! 1369: @item M ! 1370: 0, 1, 2, or 3 (shifts for @code{lea} instruction) ! 1371: ! 1372: @item G ! 1373: Standard 80387 floating point constant ! 1374: @end table ! 1375: ! 1376: @item Intel 960---@file{i960.h} ! 1377: @table @code ! 1378: @item f ! 1379: Floating point register (@code{fp0} to @code{fp3}) ! 1380: ! 1381: @item l ! 1382: Local register (@code{r0} to @code{r15}) ! 1383: ! 1384: @item b ! 1385: Global register (@code{g0} to @code{g15}) ! 1386: ! 1387: @item d ! 1388: Any local or global register ! 1389: ! 1390: @item I ! 1391: Integers from 0 to 31 ! 1392: ! 1393: @item J ! 1394: 0 ! 1395: ! 1396: @item K ! 1397: Integers from -31 to 0 ! 1398: ! 1399: @item G ! 1400: Floating point 0 ! 1401: ! 1402: @item H ! 1403: Floating point 1 ! 1404: @end table ! 1405: ! 1406: @item MIPS---@file{mips.h} ! 1407: @table @code ! 1408: @item d ! 1409: General-purpose integer register ! 1410: ! 1411: @item f ! 1412: Floating-point register (if available) ! 1413: ! 1414: @item h ! 1415: @samp{Hi} register ! 1416: ! 1417: @item l ! 1418: @samp{Lo} register ! 1419: ! 1420: @item x ! 1421: @samp{Hi} or @samp{Lo} register ! 1422: ! 1423: @item y ! 1424: General-purpose integer register ! 1425: ! 1426: @item z ! 1427: Floating-point status register ! 1428: ! 1429: @item I ! 1430: Signed 16 bit constant (for arithmetic instructions) ! 1431: ! 1432: @item J ! 1433: Zero ! 1434: ! 1435: @item K ! 1436: Zero-extended 16-bit constant (for logic instructions) ! 1437: ! 1438: @item L ! 1439: Constant with low 16 bits zero (can be loaded with @code{lui}) ! 1440: ! 1441: @item M ! 1442: 32 bit constant which requires two instructions to load (a constant ! 1443: which is not @samp{I}, @samp{K}, or @samp{L}) ! 1444: ! 1445: @item N ! 1446: Negative 16 bit constant ! 1447: ! 1448: @item O ! 1449: Exact power of two ! 1450: ! 1451: @item P ! 1452: Positive 16 bit constant ! 1453: ! 1454: @item G ! 1455: Floating point zero ! 1456: ! 1457: @item Q ! 1458: Memory reference that can be loaded with more than one instruction ! 1459: (@samp{m} is preferable for @code{asm} statements) ! 1460: ! 1461: @item R ! 1462: Memory reference that can be loaded with one instruction ! 1463: (@samp{m} is preferable for @code{asm} statements) ! 1464: ! 1465: @item S ! 1466: Memory reference in external OSF/rose PIC format ! 1467: (@samp{m} is preferable for @code{asm} statements) 1.1 root 1468: @end table 1469: 1.1.1.5 ! root 1470: @item Motorola 680x0---@file{m68k.h} ! 1471: @table @code ! 1472: @item a ! 1473: Address register ! 1474: ! 1475: @item d ! 1476: Data register ! 1477: ! 1478: @item f ! 1479: 68881 floating-point register, if available ! 1480: ! 1481: @item x ! 1482: Sun FPA (floating-point) register, if available ! 1483: ! 1484: @item y ! 1485: First 16 Sun FPA registers, if available ! 1486: ! 1487: @item I ! 1488: Integer in the range 1 to 8 ! 1489: ! 1490: @item J ! 1491: 16 bit signed number ! 1492: ! 1493: @item K ! 1494: Signed number whose magnitude is greater than 0x80 ! 1495: ! 1496: @item L ! 1497: Integer in the range -8 to -1 ! 1498: ! 1499: @item G ! 1500: Floating point constant that is not a 68881 constant ! 1501: ! 1502: @item H ! 1503: Floating point constant that can be used by Sun FPA ! 1504: @end table ! 1505: ! 1506: @need 1000 ! 1507: @item SPARC---@file{sparc.h} ! 1508: @table @code ! 1509: @item f ! 1510: Floating-point register ! 1511: ! 1512: @item I ! 1513: Signed 13 bit constant ! 1514: ! 1515: @item J ! 1516: Zero ! 1517: ! 1518: @item K ! 1519: 32 bit constant with the low 12 bits clear (a constant that can be ! 1520: loaded with the @code{sethi} instruction) ! 1521: ! 1522: @item G ! 1523: Floating-point zero ! 1524: ! 1525: @item H ! 1526: Signed 13 bit constant, sign-extended to 32 or 64 bits ! 1527: ! 1528: @item Q ! 1529: Memory reference that can be loaded with one instruction (@samp{m} is ! 1530: more appropriate for @code{asm} statements) ! 1531: ! 1532: @item S ! 1533: Constant, or memory address ! 1534: ! 1535: @item T ! 1536: Memory address aligned to an 8-byte boundary ! 1537: ! 1538: @item U ! 1539: Even register ! 1540: @end table ! 1541: @end table ! 1542: ! 1543: @ifset INTERNALS ! 1544: @node No Constraints 1.1 root 1545: @subsection Not Using Constraints 1546: @cindex no constraints 1547: @cindex not using constraints 1548: 1549: Some machines are so clean that operand constraints are not required. For 1550: example, on the Vax, an operand valid in one context is valid in any other 1551: context. On such a machine, every operand constraint would be @samp{g}, 1552: excepting only operands of ``load address'' instructions which are 1553: written as if they referred to a memory location's contents but actual 1554: refer to its address. They would have constraint @samp{p}. 1555: 1556: @cindex empty constraints 1557: For such machines, instead of writing @samp{g} and @samp{p} for all 1558: the constraints, you can choose to write a description with empty constraints. 1559: Then you write @samp{""} for the constraint in every @code{match_operand}. 1560: Address operands are identified by writing an @code{address} expression 1561: around the @code{match_operand}, not by their constraints. 1562: 1563: When the machine description has just empty constraints, certain parts 1564: of compilation are skipped, making the compiler faster. However, 1565: few machines actually do not need constraints; all machine descriptions 1566: now in existence use constraints. 1.1.1.5 ! root 1567: @end ifset 1.1 root 1568: 1.1.1.5 ! root 1569: @ifset INTERNALS ! 1570: @node Standard Names ! 1571: @section Standard Pattern Names For Generation 1.1 root 1572: @cindex standard pattern names 1573: @cindex pattern names 1574: @cindex names, pattern 1575: 1576: Here is a table of the instruction names that are meaningful in the RTL 1577: generation pass of the compiler. Giving one of these names to an 1578: instruction pattern tells the RTL generation pass that it can use the 1579: pattern in to accomplish a certain task. 1580: 1581: @table @asis 1582: @cindex @code{mov@var{m}} instruction pattern 1583: @item @samp{mov@var{m}} 1584: Here @var{m} stands for a two-letter machine mode name, in lower case. 1585: This instruction pattern moves data with that machine mode from operand 1586: 1 to operand 0. For example, @samp{movsi} moves full-word data. 1587: 1588: If operand 0 is a @code{subreg} with mode @var{m} of a register whose 1589: own mode is wider than @var{m}, the effect of this instruction is 1590: to store the specified value in the part of the register that corresponds 1591: to mode @var{m}. The effect on the rest of the register is undefined. 1592: 1593: This class of patterns is special in several ways. First of all, each 1594: of these names @emph{must} be defined, because there is no other way 1595: to copy a datum from one place to another. 1596: 1597: Second, these patterns are not used solely in the RTL generation pass. 1598: Even the reload pass can generate move insns to copy values from stack 1599: slots into temporary registers. When it does so, one of the operands is 1600: a hard register and the other is an operand that can need to be reloaded 1601: into a register. 1602: 1603: @findex force_reg 1604: Therefore, when given such a pair of operands, the pattern must generate 1605: RTL which needs no reloading and needs no temporary registers---no 1606: registers other than the operands. For example, if you support the 1607: pattern with a @code{define_expand}, then in such a case the 1608: @code{define_expand} mustn't call @code{force_reg} or any other such 1609: function which might generate new pseudo registers. 1610: 1611: This requirement exists even for subword modes on a RISC machine where 1612: fetching those modes from memory normally requires several insns and 1613: some temporary registers. Look in @file{spur.md} to see how the 1614: requirement can be satisfied. 1615: 1616: @findex change_address 1617: During reload a memory reference with an invalid address may be passed 1618: as an operand. Such an address will be replaced with a valid address 1619: later in the reload pass. In this case, nothing may be done with the 1620: address except to use it as it stands. If it is copied, it will not be 1621: replaced with a valid address. No attempt should be made to make such 1622: an address into a valid address and no routine (such as 1623: @code{change_address}) that will do so may be called. Note that 1624: @code{general_operand} will fail when applied to such an address. 1625: 1626: @findex reload_in_progress 1627: The global variable @code{reload_in_progress} (which must be explicitly 1628: declared if required) can be used to determine whether such special 1629: handling is required. 1630: 1631: The variety of operands that have reloads depends on the rest of the 1632: machine description, but typically on a RISC machine these can only be 1633: pseudo registers that did not get hard registers, while on other 1634: machines explicit memory references will get optional reloads. 1635: 1636: If a scratch register is required to move an object to or from memory, 1637: it can be allocated using @code{gen_reg_rtx} prior to reload. But this 1638: is impossible during and after reload. If there are cases needing 1639: scratch registers after reload, you must define 1.1.1.5 ! root 1640: @code{SECONDARY_INPUT_RELOAD_CLASS} and perhaps also 1.1 root 1641: @code{SECONDARY_OUTPUT_RELOAD_CLASS} to detect them, and provide 1642: patterns @samp{reload_in@var{m}} or @samp{reload_out@var{m}} to handle 1643: them. @xref{Register Classes}. 1644: 1645: The constraints on a @samp{move@var{m}} must permit moving any hard 1646: register to any other hard register provided that 1647: @code{HARD_REGNO_MODE_OK} permits mode @var{m} in both registers and 1648: @code{REGISTER_MOVE_COST} applied to their classes returns a value of 2. 1649: 1650: It is obligatory to support floating point @samp{move@var{m}} 1651: instructions into and out of any registers that can hold fixed point 1652: values, because unions and structures (which have modes @code{SImode} or 1653: @code{DImode}) can be in those registers and they may have floating 1654: point members. 1655: 1656: There may also be a need to support fixed point @samp{move@var{m}} 1657: instructions in and out of floating point registers. Unfortunately, I 1658: have forgotten why this was so, and I don't know whether it is still 1659: true. If @code{HARD_REGNO_MODE_OK} rejects fixed point values in 1660: floating point registers, then the constraints of the fixed point 1661: @samp{move@var{m}} instructions must be designed to avoid ever trying to 1662: reload into a floating point register. 1663: 1.1.1.3 root 1664: @cindex @code{reload_in} instruction pattern 1665: @cindex @code{reload_out} instruction pattern 1.1 root 1666: @item @samp{reload_in@var{m}} 1667: @itemx @samp{reload_out@var{m}} 1668: Like @samp{mov@var{m}}, but used when a scratch register is required to 1669: move between operand 0 and operand 1. Operand 2 describes the scratch 1670: register. See the discussion of the @code{SECONDARY_RELOAD_CLASS} 1671: macro in @pxref{Register Classes}. 1672: 1673: @cindex @code{movstrict@var{m}} instruction pattern 1674: @item @samp{movstrict@var{m}} 1675: Like @samp{mov@var{m}} except that if operand 0 is a @code{subreg} 1676: with mode @var{m} of a register whose natural mode is wider, 1677: the @samp{movstrict@var{m}} instruction is guaranteed not to alter 1678: any of the register except the part which belongs to mode @var{m}. 1679: 1.1.1.3 root 1680: @cindex @code{load_multiple} instruction pattern 1681: @item @code{load_multiple} 1682: Load several consecutive memory locations into consecutive registers. 1683: Operand 0 is the first of the consecutive registers, operand 1 1684: is the first memory location, and operand 2 is a constant: the 1685: number of consecutive registers. 1686: 1687: Define this only if the target machine really has such an instruction; 1688: do not define this if the most efficient way of loading consecutive 1689: registers from memory is to do them one at a time. 1690: 1691: On some machines, there are restrictions as to which consecutive 1692: registers can be stored into memory, such as particular starting or 1693: ending register numbers or only a range of valid counts. For those 1694: machines, use a @code{define_expand} (@pxref{Expander Definitions}) 1695: and make the pattern fail if the restrictions are not met. 1696: 1697: Write the generated insn as a @code{parallel} with elements being a 1698: @code{set} of one register from the appropriate memory location (you may 1699: also need @code{use} or @code{clobber} elements). Use a 1700: @code{match_parallel} (@pxref{RTL Template}) to recognize the insn. See 1701: @file{a29k.md} and @file{rs6000.md} for examples of the use of this insn 1702: pattern. 1703: 1704: @cindex @samp{store_multiple} instruction pattern 1705: @item @code{store_multiple} 1706: Similar to @samp{load_multiple}, but store several consecutive registers 1707: into consecutive memory locations. Operand 0 is the first of the 1708: consecutive memory locations, operand 1 is the first register, and 1709: operand 2 is a constant: the number of consecutive registers. 1710: 1.1 root 1711: @cindex @code{add@var{m}3} instruction pattern 1712: @item @samp{add@var{m}3} 1713: Add operand 2 and operand 1, storing the result in operand 0. All operands 1714: must have mode @var{m}. This can be used even on two-address machines, by 1715: means of constraints requiring operands 1 and 0 to be the same location. 1716: 1717: @cindex @code{sub@var{m}3} instruction pattern 1718: @cindex @code{mul@var{m}3} instruction pattern 1719: @cindex @code{div@var{m}3} instruction pattern 1720: @cindex @code{udiv@var{m}3} instruction pattern 1721: @cindex @code{mod@var{m}3} instruction pattern 1722: @cindex @code{umod@var{m}3} instruction pattern 1723: @cindex @code{min@var{m}3} instruction pattern 1724: @cindex @code{max@var{m}3} instruction pattern 1725: @cindex @code{umin@var{m}3} instruction pattern 1726: @cindex @code{umax@var{m}3} instruction pattern 1727: @cindex @code{and@var{m}3} instruction pattern 1728: @cindex @code{ior@var{m}3} instruction pattern 1729: @cindex @code{xor@var{m}3} instruction pattern 1730: @item @samp{sub@var{m}3}, @samp{mul@var{m}3} 1731: @itemx @samp{div@var{m}3}, @samp{udiv@var{m}3}, @samp{mod@var{m}3}, @samp{umod@var{m}3} 1732: @itemx @samp{smin@var{m}3}, @samp{smax@var{m}3}, @samp{umin@var{m}3}, @samp{umax@var{m}3} 1733: @itemx @samp{and@var{m}3}, @samp{ior@var{m}3}, @samp{xor@var{m}3} 1734: Similar, for other arithmetic operations. 1735: 1736: @cindex @code{mulhisi3} instruction pattern 1737: @item @samp{mulhisi3} 1738: Multiply operands 1 and 2, which have mode @code{HImode}, and store 1739: a @code{SImode} product in operand 0. 1740: 1741: @cindex @code{mulqihi3} instruction pattern 1742: @cindex @code{mulsidi3} instruction pattern 1743: @item @samp{mulqihi3}, @samp{mulsidi3} 1744: Similar widening-multiplication instructions of other widths. 1745: 1746: @cindex @code{umulqihi3} instruction pattern 1747: @cindex @code{umulhisi3} instruction pattern 1748: @cindex @code{umulsidi3} instruction pattern 1749: @item @samp{umulqihi3}, @samp{umulhisi3}, @samp{umulsidi3} 1750: Similar widening-multiplication instructions that do unsigned 1751: multiplication. 1752: 1753: @cindex @code{divmod@var{m}4} instruction pattern 1754: @item @samp{divmod@var{m}4} 1755: Signed division that produces both a quotient and a remainder. 1756: Operand 1 is divided by operand 2 to produce a quotient stored 1757: in operand 0 and a remainder stored in operand 3. 1758: 1759: For machines with an instruction that produces both a quotient and a 1760: remainder, provide a pattern for @samp{divmod@var{m}4} but do not 1761: provide patterns for @samp{div@var{m}3} and @samp{mod@var{m}3}. This 1762: allows optimization in the relatively common case when both the quotient 1763: and remainder are computed. 1764: 1765: If an instruction that just produces a quotient or just a remainder 1766: exists and is more efficient than the instruction that produces both, 1767: write the output routine of @samp{divmod@var{m}4} to call 1768: @code{find_reg_note} and look for a @code{REG_UNUSED} note on the 1769: quotient or remainder and generate the appropriate instruction. 1770: 1771: @cindex @code{udivmod@var{m}4} instruction pattern 1772: @item @samp{udivmod@var{m}4} 1773: Similar, but does unsigned division. 1774: 1775: @cindex @code{ashl@var{m}3} instruction pattern 1776: @item @samp{ashl@var{m}3} 1.1.1.3 root 1777: Arithmetic-shift operand 1 left by a number of bits specified by operand 1778: 2, and store the result in operand 0. Here @var{m} is the mode of 1779: operand 0 and operand 1; operand 2's mode is specified by the 1780: instruction pattern, and the compiler will convert the operand to that 1781: mode before generating the instruction. 1.1 root 1782: 1783: @cindex @code{ashr@var{m}3} instruction pattern 1784: @cindex @code{lshl@var{m}3} instruction pattern 1785: @cindex @code{lshr@var{m}3} instruction pattern 1786: @cindex @code{rotl@var{m}3} instruction pattern 1787: @cindex @code{rotr@var{m}3} instruction pattern 1788: @item @samp{ashr@var{m}3}, @samp{lshl@var{m}3}, @samp{lshr@var{m}3}, @samp{rotl@var{m}3}, @samp{rotr@var{m}3} 1.1.1.3 root 1789: Other shift and rotate instructions, analogous to the 1790: @code{ashl@var{m}3} instructions. 1.1 root 1791: 1792: Logical and arithmetic left shift are the same. Machines that do not 1793: allow negative shift counts often have only one instruction for 1794: shifting left. On such machines, you should define a pattern named 1795: @samp{ashl@var{m}3} and leave @samp{lshl@var{m}3} undefined. 1796: 1797: @cindex @code{neg@var{m}2} instruction pattern 1798: @item @samp{neg@var{m}2} 1799: Negate operand 1 and store the result in operand 0. 1800: 1801: @cindex @code{abs@var{m}2} instruction pattern 1802: @item @samp{abs@var{m}2} 1803: Store the absolute value of operand 1 into operand 0. 1804: 1805: @cindex @code{sqrt@var{m}2} instruction pattern 1806: @item @samp{sqrt@var{m}2} 1807: Store the square root of operand 1 into operand 0. 1808: 1.1.1.3 root 1809: The @code{sqrt} built-in function of C always uses the mode which 1810: corresponds to the C data type @code{double}. 1811: 1.1 root 1812: @cindex @code{ffs@var{m}2} instruction pattern 1813: @item @samp{ffs@var{m}2} 1814: Store into operand 0 one plus the index of the least significant 1-bit 1815: of operand 1. If operand 1 is zero, store zero. @var{m} is the mode 1816: of operand 0; operand 1's mode is specified by the instruction 1817: pattern, and the compiler will convert the operand to that mode before 1818: generating the instruction. 1819: 1.1.1.3 root 1820: The @code{ffs} built-in function of C always uses the mode which 1821: corresponds to the C data type @code{int}. 1822: 1.1 root 1823: @cindex @code{one_cmpl@var{m}2} instruction pattern 1824: @item @samp{one_cmpl@var{m}2} 1825: Store the bitwise-complement of operand 1 into operand 0. 1826: 1827: @cindex @code{cmp@var{m}} instruction pattern 1828: @item @samp{cmp@var{m}} 1829: Compare operand 0 and operand 1, and set the condition codes. 1830: The RTL pattern should look like this: 1831: 1.1.1.5 ! root 1832: @smallexample 1.1 root 1833: (set (cc0) (compare (match_operand:@var{m} 0 @dots{}) 1834: (match_operand:@var{m} 1 @dots{}))) 1.1.1.5 ! root 1835: @end smallexample 1.1 root 1836: 1837: @cindex @code{tst@var{m}} instruction pattern 1838: @item @samp{tst@var{m}} 1839: Compare operand 0 against zero, and set the condition codes. 1840: The RTL pattern should look like this: 1841: 1.1.1.5 ! root 1842: @smallexample 1.1 root 1843: (set (cc0) (match_operand:@var{m} 0 @dots{})) 1.1.1.5 ! root 1844: @end smallexample 1.1 root 1845: 1846: @samp{tst@var{m}} patterns should not be defined for machines that do 1847: not use @code{(cc0)}. Doing so would confuse the optimizer since it 1848: would no longer be clear which @code{set} operations were comparisons. 1849: The @samp{cmp@var{m}} patterns should be used instead. 1850: 1851: @cindex @code{movstr@var{m}} instruction pattern 1852: @item @samp{movstr@var{m}} 1853: Block move instruction. The addresses of the destination and source 1854: strings are the first two operands, and both are in mode @code{Pmode}. 1855: The number of bytes to move is the third operand, in mode @var{m}. 1856: 1857: The fourth operand is the known shared alignment of the source and 1858: destination, in the form of a @code{const_int} rtx. Thus, if the 1859: compiler knows that both source and destination are word-aligned, 1860: it may provide the value 4 for this operand. 1861: 1862: These patterns need not give special consideration to the possibility 1863: that the source and destination strings might overlap. 1864: 1865: @cindex @code{cmpstr@var{m}} instruction pattern 1866: @item @samp{cmpstr@var{m}} 1867: Block compare instruction, with five operands. Operand 0 is the output; 1868: it has mode @var{m}. The remaining four operands are like the operands 1869: of @samp{movstr@var{m}}. The two memory blocks specified are compared 1870: byte by byte in lexicographic order. The effect of the instruction is 1871: to store a value in operand 0 whose sign indicates the result of the 1872: comparison. 1873: 1.1.1.5 ! root 1874: @cindex @code{strlen@var{m}} instruction pattern ! 1875: Compute the length of a string, with three operands. ! 1876: Operand 0 is the result (of mode @var{m}), operand 1 is ! 1877: a @code{mem} referring to the first character of the string, ! 1878: operand 2 is the character to search for (normally zero), ! 1879: and operand 3 is a constant describing the known alignment ! 1880: of the beginning of the string. ! 1881: 1.1 root 1882: @cindex @code{float@var{mn}2} instruction pattern 1883: @item @samp{float@var{m}@var{n}2} 1884: Convert signed integer operand 1 (valid for fixed point mode @var{m}) to 1885: floating point mode @var{n} and store in operand 0 (which has mode 1886: @var{n}). 1887: 1888: @cindex @code{floatuns@var{mn}2} instruction pattern 1889: @item @samp{floatuns@var{m}@var{n}2} 1890: Convert unsigned integer operand 1 (valid for fixed point mode @var{m}) 1891: to floating point mode @var{n} and store in operand 0 (which has mode 1892: @var{n}). 1893: 1894: @cindex @code{fix@var{mn}2} instruction pattern 1895: @item @samp{fix@var{m}@var{n}2} 1896: Convert operand 1 (valid for floating point mode @var{m}) to fixed 1897: point mode @var{n} as a signed number and store in operand 0 (which 1898: has mode @var{n}). This instruction's result is defined only when 1899: the value of operand 1 is an integer. 1900: 1901: @cindex @code{fixuns@var{mn}2} instruction pattern 1902: @item @samp{fixuns@var{m}@var{n}2} 1903: Convert operand 1 (valid for floating point mode @var{m}) to fixed 1904: point mode @var{n} as an unsigned number and store in operand 0 (which 1905: has mode @var{n}). This instruction's result is defined only when the 1906: value of operand 1 is an integer. 1907: 1908: @cindex @code{ftrunc@var{m}2} instruction pattern 1909: @item @samp{ftrunc@var{m}2} 1910: Convert operand 1 (valid for floating point mode @var{m}) to an 1911: integer value, still represented in floating point mode @var{m}, and 1912: store it in operand 0 (valid for floating point mode @var{m}). 1913: 1914: @cindex @code{fix_trunc@var{mn}2} instruction pattern 1915: @item @samp{fix_trunc@var{m}@var{n}2} 1916: Like @samp{fix@var{m}@var{n}2} but works for any floating point value 1917: of mode @var{m} by converting the value to an integer. 1918: 1919: @cindex @code{fixuns_trunc@var{mn}2} instruction pattern 1920: @item @samp{fixuns_trunc@var{m}@var{n}2} 1921: Like @samp{fixuns@var{m}@var{n}2} but works for any floating point 1922: value of mode @var{m} by converting the value to an integer. 1923: 1924: @cindex @code{trunc@var{mn}} instruction pattern 1925: @item @samp{trunc@var{m}@var{n}} 1926: Truncate operand 1 (valid for mode @var{m}) to mode @var{n} and 1927: store in operand 0 (which has mode @var{n}). Both modes must be fixed 1928: point or both floating point. 1929: 1930: @cindex @code{extend@var{mn}} instruction pattern 1931: @item @samp{extend@var{m}@var{n}} 1932: Sign-extend operand 1 (valid for mode @var{m}) to mode @var{n} and 1933: store in operand 0 (which has mode @var{n}). Both modes must be fixed 1934: point or both floating point. 1935: 1936: @cindex @code{zero_extend@var{mn}} instruction pattern 1937: @item @samp{zero_extend@var{m}@var{n}} 1938: Zero-extend operand 1 (valid for mode @var{m}) to mode @var{n} and 1939: store in operand 0 (which has mode @var{n}). Both modes must be fixed 1940: point. 1941: 1942: @cindex @code{extv} instruction pattern 1943: @item @samp{extv} 1944: Extract a bit field from operand 1 (a register or memory operand), where 1945: operand 2 specifies the width in bits and operand 3 the starting bit, 1946: and store it in operand 0. Operand 0 must have mode @code{word_mode}. 1947: Operand 1 may have mode @code{byte_mode} or @code{word_mode}; often 1948: @code{word_mode} is allowed only for registers. Operands 2 and 3 must 1949: be valid for @code{word_mode}. 1950: 1951: The RTL generation pass generates this instruction only with constants 1952: for operands 2 and 3. 1953: 1954: The bit-field value is sign-extended to a full word integer 1955: before it is stored in operand 0. 1956: 1957: @cindex @code{extzv} instruction pattern 1958: @item @samp{extzv} 1959: Like @samp{extv} except that the bit-field value is zero-extended. 1960: 1961: @cindex @code{insv} instruction pattern 1962: @item @samp{insv} 1963: Store operand 3 (which must be valid for @code{word_mode}) into a bit 1964: field in operand 0, where operand 1 specifies the width in bits and 1965: operand 2 the starting bit. Operand 0 may have mode @code{byte_mode} or 1966: @code{word_mode}; often @code{word_mode} is allowed only for registers. 1967: Operands 1 and 2 must be valid for @code{word_mode}. 1968: 1969: The RTL generation pass generates this instruction only with constants 1970: for operands 1 and 2. 1971: 1972: @cindex @code{s@var{cond}} instruction pattern 1973: @item @samp{s@var{cond}} 1974: Store zero or nonzero in the operand according to the condition codes. 1975: Value stored is nonzero iff the condition @var{cond} is true. 1976: @var{cond} is the name of a comparison operation expression code, such 1977: as @code{eq}, @code{lt} or @code{leu}. 1978: 1979: You specify the mode that the operand must have when you write the 1980: @code{match_operand} expression. The compiler automatically sees 1981: which mode you have used and supplies an operand of that mode. 1982: 1983: The value stored for a true condition must have 1 as its low bit, or 1984: else must be negative. Otherwise the instruction is not suitable and 1985: you should omit it from the machine description. You describe to the 1986: compiler exactly which value is stored by defining the macro 1987: @code{STORE_FLAG_VALUE} (@pxref{Misc}). If a description cannot be 1988: found that can be used for all the @samp{s@var{cond}} patterns, you 1989: should omit those operations from the machine description. 1990: 1991: These operations may fail, but should do so only in relatively 1992: uncommon cases; if they would fail for common cases involving 1993: integer comparisons, it is best to omit these patterns. 1994: 1995: If these operations are omitted, the compiler will usually generate code 1996: that copies the constant one to the target and branches around an 1997: assignment of zero to the target. If this code is more efficient than 1998: the potential instructions used for the @samp{s@var{cond}} pattern 1999: followed by those required to convert the result into a 1 or a zero in 2000: @code{SImode}, you should omit the @samp{s@var{cond}} operations from 2001: the machine description. 2002: 2003: @cindex @code{b@var{cond}} instruction pattern 2004: @item @samp{b@var{cond}} 2005: Conditional branch instruction. Operand 0 is a @code{label_ref} that 2006: refers to the label to jump to. Jump if the condition codes meet 2007: condition @var{cond}. 2008: 2009: Some machines do not follow the model assumed here where a comparison 2010: instruction is followed by a conditional branch instruction. In that 2011: case, the @samp{cmp@var{m}} (and @samp{tst@var{m}}) patterns should 2012: simply store the operands away and generate all the required insns in a 2013: @code{define_expand} (@pxref{Expander Definitions}) for the conditional 1.1.1.4 root 2014: branch operations. All calls to expand @samp{b@var{cond}} patterns are 1.1 root 2015: immediately preceded by calls to expand either a @samp{cmp@var{m}} 2016: pattern or a @samp{tst@var{m}} pattern. 2017: 2018: Machines that use a pseudo register for the condition code value, or 2019: where the mode used for the comparison depends on the condition being 2020: tested, should also use the above mechanism. @xref{Jump Patterns} 2021: 2022: The above discussion also applies to @samp{s@var{cond}} patterns. 2023: 2024: @cindex @code{call} instruction pattern 2025: @item @samp{call} 2026: Subroutine call instruction returning no value. Operand 0 is the 2027: function to call; operand 1 is the number of bytes of arguments pushed 2028: (in mode @code{SImode}, except it is normally a @code{const_int}); 2029: operand 2 is the number of registers used as operands. 2030: 2031: On most machines, operand 2 is not actually stored into the RTL 2032: pattern. It is supplied for the sake of some RISC machines which need 2033: to put this information into the assembler code; they can put it in 2034: the RTL instead of operand 1. 2035: 2036: Operand 0 should be a @code{mem} RTX whose address is the address of the 2037: function. Note, however, that this address can be a @code{symbol_ref} 2038: expression even if it would not be a legitimate memory address on the 2039: target machine. If it is also not a valid argument for a call 2040: instruction, the pattern for this operation should be a 2041: @code{define_expand} (@pxref{Expander Definitions}) that places the 2042: address into a register and uses that register in the call instruction. 2043: 2044: @cindex @code{call_value} instruction pattern 2045: @item @samp{call_value} 2046: Subroutine call instruction returning a value. Operand 0 is the hard 2047: register in which the value is returned. There are three more 2048: operands, the same as the three operands of the @samp{call} 2049: instruction (but with numbers increased by one). 2050: 2051: Subroutines that return @code{BLKmode} objects use the @samp{call} 2052: insn. 2053: 2054: @cindex @code{call_pop} instruction pattern 2055: @cindex @code{call_value_pop} instruction pattern 2056: @item @samp{call_pop}, @samp{call_value_pop} 2057: Similar to @samp{call} and @samp{call_value}, except used if defined and 2058: if @code{RETURN_POPS_ARGS} is non-zero. They should emit a @code{parallel} 2059: that contains both the function call and a @code{set} to indicate the 2060: adjustment made to the frame pointer. 2061: 2062: For machines where @code{RETURN_POPS_ARGS} can be non-zero, the use of these 2063: patterns increases the number of functions for which the frame pointer 2064: can be eliminated, if desired. 2065: 1.1.1.5 ! root 2066: @cindex @code{untyped_call} instruction pattern ! 2067: @item @samp{untyped_call} ! 2068: Subroutine call instruction returning a value of any type. Operand 0 is ! 2069: the function to call; operand 1 is a memory location where the result of ! 2070: calling the function is to be stored; operand 2 is a @code{parallel} ! 2071: expression where each element is a @code{set} expression that indicates ! 2072: the saving of a function return value into the result block. ! 2073: ! 2074: This instruction pattern should be defined to support ! 2075: @code{__builtin_apply} on machines where special instructions are needed ! 2076: to call a subroutine with arbitrary arguments or to save the value ! 2077: returned. This instruction pattern is required on machines that have ! 2078: multiple registers that can hold a return value (i.e. ! 2079: @code{FUNCTION_VALUE_REGNO_P} is true for more than one register). ! 2080: 1.1 root 2081: @cindex @code{return} instruction pattern 2082: @item @samp{return} 2083: Subroutine return instruction. This instruction pattern name should be 2084: defined only if a single instruction can do all the work of returning 2085: from a function. 2086: 2087: Like the @samp{mov@var{m}} patterns, this pattern is also used after the 2088: RTL generation phase. In this case it is to support machines where 2089: multiple instructions are usually needed to return from a function, but 2090: some class of functions only requires one instruction to implement a 2091: return. Normally, the applicable functions are those which do not need 2092: to save any registers or allocate stack space. 2093: 2094: @findex reload_completed 2095: @findex leaf_function_p 2096: For such machines, the condition specified in this pattern should only 2097: be true when @code{reload_completed} is non-zero and the function's 2098: epilogue would only be a single instruction. For machines with register 2099: windows, the routine @code{leaf_function_p} may be used to determine if 2100: a register window push is required. 2101: 2102: Machines that have conditional return instructions should define patterns 2103: such as 2104: 1.1.1.5 ! root 2105: @smallexample 1.1 root 2106: (define_insn "" 2107: [(set (pc) 1.1.1.5 ! root 2108: (if_then_else (match_operator ! 2109: 0 "comparison_operator" ! 2110: [(cc0) (const_int 0)]) 1.1.1.4 root 2111: (return) 2112: (pc)))] 1.1 root 2113: "@var{condition}" 2114: "@dots{}") 1.1.1.5 ! root 2115: @end smallexample 1.1 root 2116: 2117: where @var{condition} would normally be the same condition specified on the 2118: named @samp{return} pattern. 2119: 1.1.1.5 ! root 2120: @cindex @code{untyped_return} instruction pattern ! 2121: @item @samp{untyped_return} ! 2122: Untyped subroutine return instruction. This instruction pattern should ! 2123: be defined to support @code{__builtin_return} on machines where special ! 2124: instructions are needed to return a value of any type. ! 2125: ! 2126: Operand 0 is a memory location where the result of calling a function ! 2127: with @code{__builtin_apply} is stored; operand 1 is a @code{parallel} ! 2128: expression where each element is a @code{set} expression that indicates ! 2129: the restoring of a function return value from the result block. ! 2130: 1.1 root 2131: @cindex @code{nop} instruction pattern 2132: @item @samp{nop} 2133: No-op instruction. This instruction pattern name should always be defined 2134: to output a no-op in assembler code. @code{(const_int 0)} will do as an 2135: RTL pattern. 2136: 2137: @cindex @code{indirect_jump} instruction pattern 2138: @item @samp{indirect_jump} 2139: An instruction to jump to an address which is operand zero. 2140: This pattern name is mandatory on all machines. 2141: 2142: @cindex @code{casesi} instruction pattern 2143: @item @samp{casesi} 2144: Instruction to jump through a dispatch table, including bounds checking. 2145: This instruction takes five operands: 2146: 2147: @enumerate 2148: @item 2149: The index to dispatch on, which has mode @code{SImode}. 2150: 2151: @item 2152: The lower bound for indices in the table, an integer constant. 2153: 2154: @item 2155: The total range of indices in the table---the largest index 2156: minus the smallest one (both inclusive). 2157: 2158: @item 2159: A label that precedes the table itself. 2160: 2161: @item 2162: A label to jump to if the index has a value outside the bounds. 2163: (If the machine-description macro @code{CASE_DROPS_THROUGH} is defined, 2164: then an out-of-bounds index drops through to the code following 2165: the jump table instead of jumping to this label. In that case, 2166: this label is not actually used by the @samp{casesi} instruction, 2167: but it is always provided as an operand.) 2168: @end enumerate 2169: 2170: The table is a @code{addr_vec} or @code{addr_diff_vec} inside of a 2171: @code{jump_insn}. The number of elements in the table is one plus the 2172: difference between the upper bound and the lower bound. 2173: 2174: @cindex @code{tablejump} instruction pattern 2175: @item @samp{tablejump} 2176: Instruction to jump to a variable address. This is a low-level 2177: capability which can be used to implement a dispatch table when there 2178: is no @samp{casesi} pattern. 2179: 2180: This pattern requires two operands: the address or offset, and a label 2181: which should immediately precede the jump table. If the macro 2182: @code{CASE_VECTOR_PC_RELATIVE} is defined then the first operand is an 2183: offset which counts from the address of the table; otherwise, it is an 1.1.1.3 root 2184: absolute address to jump to. In either case, the first operand has 2185: mode @code{Pmode}. 1.1 root 2186: 2187: The @samp{tablejump} insn is always the last insn before the jump 2188: table it uses. Its assembler code normally has no need to use the 2189: second operand, but you should incorporate it in the RTL pattern so 2190: that the jump optimizer will not delete the table as unreachable code. 1.1.1.3 root 2191: 2192: @cindex @code{save_stack_block} instruction pattern 2193: @cindex @code{save_stack_function} instruction pattern 2194: @cindex @code{save_stack_nonlocal} instruction pattern 2195: @cindex @code{restore_stack_block} instruction pattern 2196: @cindex @code{restore_stack_function} instruction pattern 2197: @cindex @code{restore_stack_nonlocal} instruction pattern 2198: @item @samp{save_stack_block} 2199: @itemx @samp{save_stack_function} 2200: @itemx @samp{save_stack_nonlocal} 2201: @itemx @samp{restore_stack_block} 2202: @itemx @samp{restore_stack_function} 2203: @itemx @samp{restore_stack_nonlocal} 2204: Most machines save and restore the stack pointer by copying it to or 2205: from an object of mode @code{Pmode}. Do not define these patterns on 2206: such machines. 2207: 2208: Some machines require special handling for stack pointer saves and 2209: restores. On those machines, define the patterns corresponding to the 2210: non-standard cases by using a @code{define_expand} (@pxref{Expander 2211: Definitions}) that produces the required insns. The three types of 2212: saves and restores are: 2213: 2214: @enumerate 2215: @item 2216: @samp{save_stack_block} saves the stack pointer at the start of a block 1.1.1.5 ! root 2217: that allocates a variable-sized object, and @samp{restore_stack_block} 1.1.1.3 root 2218: restores the stack pointer when the block is exited. 2219: 2220: @item 1.1.1.5 ! root 2221: @samp{save_stack_function} and @samp{restore_stack_function} do a ! 2222: similar job for the outermost block of a function and are used when the 1.1.1.3 root 2223: function allocates variable-sized objects or calls @code{alloca}. Only 2224: the epilogue uses the restored stack pointer, allowing a simpler save or 2225: restore sequence on some machines. 2226: 2227: @item 2228: @samp{save_stack_nonlocal} is used in functions that contain labels 2229: branched to by nested functions. It saves the stack pointer in such a 2230: way that the inner function can use @samp{restore_stack_nonlocal} to 2231: restore the stack pointer. The compiler generates code to restore the 2232: frame and argument pointer registers, but some machines require saving 2233: and restoring additional data such as register window information or 2234: stack backchains. Place insns in these patterns to save and restore any 2235: such required data. 2236: @end enumerate 2237: 2238: When saving the stack pointer, operand 0 is the save area and operand 1 2239: is the stack pointer. The mode used to allocate the save area is the 2240: mode of operand 0. You must specify an integral mode, or 2241: @code{VOIDmode} if no save area is needed for a particular type of save 2242: (either because no save is needed or because a machine-specific save 2243: area can be used). Operand 0 is the stack pointer and operand 1 is the 2244: save area for restore operations. If @samp{save_stack_block} is 2245: defined, operand 0 must not be @code{VOIDmode} since these saves can be 2246: arbitrarily nested. 2247: 2248: A save area is a @code{mem} that is at a constant offset from 2249: @code{virtual_stack_vars_rtx} when the stack pointer is saved for use by 2250: nonlocal gotos and a @code{reg} in the other two cases. 2251: 2252: @cindex @code{allocate_stack} instruction pattern 2253: @item @samp{allocate_stack} 2254: Subtract operand 0 from the stack pointer to create space for 2255: for dynamically allocated data. 2256: 2257: Do not define this pattern if all that must be done is the subtraction. 2258: On some machines require other operations such as stack probes or 2259: maintaining the back chain. Define this pattern to emit those 2260: operations in addition to updating the stack pointer. 1.1 root 2261: @end table 2262: 1.1.1.5 ! root 2263: @node Pattern Ordering 1.1 root 2264: @section When the Order of Patterns Matters 2265: @cindex Pattern Ordering 2266: @cindex Ordering of Patterns 2267: 2268: Sometimes an insn can match more than one instruction pattern. Then the 2269: pattern that appears first in the machine description is the one used. 2270: Therefore, more specific patterns (patterns that will match fewer things) 2271: and faster instructions (those that will produce better code when they 2272: do match) should usually go first in the description. 2273: 2274: In some cases the effect of ordering the patterns can be used to hide 2275: a pattern when it is not valid. For example, the 68000 has an 2276: instruction for converting a fullword to floating point and another 2277: for converting a byte to floating point. An instruction converting 2278: an integer to floating point could match either one. We put the 2279: pattern to convert the fullword first to make sure that one will 2280: be used rather than the other. (Otherwise a large integer might 2281: be generated as a single-byte immediate quantity, which would not work.) 2282: Instead of using this pattern ordering it would be possible to make the 2283: pattern for convert-a-byte smart enough to deal properly with any 2284: constant value. 2285: 1.1.1.5 ! root 2286: @node Dependent Patterns 1.1 root 2287: @section Interdependence of Patterns 2288: @cindex Dependent Patterns 2289: @cindex Interdependence of Patterns 2290: 2291: Every machine description must have a named pattern for each of the 2292: conditional branch names @samp{b@var{cond}}. The recognition template 2293: must always have the form 2294: 2295: @example 2296: (set (pc) 2297: (if_then_else (@var{cond} (cc0) (const_int 0)) 2298: (label_ref (match_operand 0 "" "")) 2299: (pc))) 2300: @end example 2301: 2302: @noindent 2303: In addition, every machine description must have an anonymous pattern 2304: for each of the possible reverse-conditional branches. Their templates 2305: look like 2306: 2307: @example 2308: (set (pc) 2309: (if_then_else (@var{cond} (cc0) (const_int 0)) 2310: (pc) 2311: (label_ref (match_operand 0 "" "")))) 2312: @end example 2313: 2314: @noindent 2315: They are necessary because jump optimization can turn direct-conditional 2316: branches into reverse-conditional branches. 2317: 2318: It is often convenient to use the @code{match_operator} construct to 2319: reduce the number of patterns that must be specified for branches. For 2320: example, 2321: 2322: @example 2323: (define_insn "" 2324: [(set (pc) 2325: (if_then_else (match_operator 0 "comparison_operator" 1.1.1.4 root 2326: [(cc0) (const_int 0)]) 2327: (pc) 2328: (label_ref (match_operand 1 "" ""))))] 1.1 root 2329: "@var{condition}" 2330: "@dots{}") 2331: @end example 2332: 2333: In some cases machines support instructions identical except for the 2334: machine mode of one or more operands. For example, there may be 2335: ``sign-extend halfword'' and ``sign-extend byte'' instructions whose 2336: patterns are 2337: 2338: @example 2339: (set (match_operand:SI 0 @dots{}) 2340: (extend:SI (match_operand:HI 1 @dots{}))) 2341: 2342: (set (match_operand:SI 0 @dots{}) 2343: (extend:SI (match_operand:QI 1 @dots{}))) 2344: @end example 2345: 2346: @noindent 2347: Constant integers do not specify a machine mode, so an instruction to 2348: extend a constant value could match either pattern. The pattern it 2349: actually will match is the one that appears first in the file. For correct 2350: results, this must be the one for the widest possible mode (@code{HImode}, 2351: here). If the pattern matches the @code{QImode} instruction, the results 2352: will be incorrect if the constant value does not actually fit that mode. 2353: 2354: Such instructions to extend constants are rarely generated because they are 2355: optimized away, but they do occasionally happen in nonoptimized 2356: compilations. 2357: 2358: If a constraint in a pattern allows a constant, the reload pass may 2359: replace a register with a constant permitted by the constraint in some 2360: cases. Similarly for memory references. You must ensure that the 2361: predicate permits all objects allowed by the constraints to prevent the 2362: compiler from crashing. 2363: 2364: Because of this substitution, you should not provide separate patterns 2365: for increment and decrement instructions. Instead, they should be 2366: generated from the same pattern that supports register-register add 2367: insns by examining the operands and generating the appropriate machine 2368: instruction. 2369: 1.1.1.5 ! root 2370: @node Jump Patterns 1.1 root 2371: @section Defining Jump Instruction Patterns 2372: @cindex jump instruction patterns 2373: @cindex defining jump instruction patterns 2374: 2375: For most machines, GNU CC assumes that the machine has a condition code. 2376: A comparison insn sets the condition code, recording the results of both 2377: signed and unsigned comparison of the given operands. A separate branch 2378: insn tests the condition code and branches or not according its value. 2379: The branch insns come in distinct signed and unsigned flavors. Many 2380: common machines, such as the Vax, the 68000 and the 32000, work this 2381: way. 2382: 2383: Some machines have distinct signed and unsigned compare instructions, and 2384: only one set of conditional branch instructions. The easiest way to handle 2385: these machines is to treat them just like the others until the final stage 2386: where assembly code is written. At this time, when outputting code for the 2387: compare instruction, peek ahead at the following branch using 2388: @code{next_cc0_user (insn)}. (The variable @code{insn} refers to the insn 2389: being output, in the output-writing code in an instruction pattern.) If 2390: the RTL says that is an unsigned branch, output an unsigned compare; 2391: otherwise output a signed compare. When the branch itself is output, you 2392: can treat signed and unsigned branches identically. 2393: 2394: The reason you can do this is that GNU CC always generates a pair of 2395: consecutive RTL insns, possibly separated by @code{note} insns, one to 2396: set the condition code and one to test it, and keeps the pair inviolate 2397: until the end. 2398: 2399: To go with this technique, you must define the machine-description macro 2400: @code{NOTICE_UPDATE_CC} to do @code{CC_STATUS_INIT}; in other words, no 2401: compare instruction is superfluous. 2402: 2403: Some machines have compare-and-branch instructions and no condition code. 2404: A similar technique works for them. When it is time to ``output'' a 2405: compare instruction, record its operands in two static variables. When 2406: outputting the branch-on-condition-code instruction that follows, actually 2407: output a compare-and-branch instruction that uses the remembered operands. 2408: 2409: It also works to define patterns for compare-and-branch instructions. 2410: In optimizing compilation, the pair of compare and branch instructions 2411: will be combined according to these patterns. But this does not happen 2412: if optimization is not requested. So you must use one of the solutions 2413: above in addition to any special patterns you define. 2414: 2415: In many RISC machines, most instructions do not affect the condition 2416: code and there may not even be a separate condition code register. On 2417: these machines, the restriction that the definition and use of the 2418: condition code be adjacent insns is not necessary and can prevent 2419: important optimizations. For example, on the IBM RS/6000, there is a 2420: delay for taken branches unless the condition code register is set three 2421: instructions earlier than the conditional branch. The instruction 2422: scheduler cannot perform this optimization if it is not permitted to 2423: separate the definition and use of the condition code register. 2424: 2425: On these machines, do not use @code{(cc0)}, but instead use a register 2426: to represent the condition code. If there is a specific condition code 2427: register in the machine, use a hard register. If the condition code or 2428: comparison result can be placed in any general register, or if there are 2429: multiple condition registers, use a pseudo register. 2430: 2431: @findex prev_cc0_setter 2432: @findex next_cc0_user 2433: On some machines, the type of branch instruction generated may depend on 2434: the way the condition code was produced; for example, on the 68k and 2435: Sparc, setting the condition code directly from an add or subtract 2436: instruction does not clear the overflow bit the way that a test 2437: instruction does, so a different branch instruction must be used for 2438: some conditional branches. For machines that use @code{(cc0)}, the set 2439: and use of the condition code must be adjacent (separated only by 2440: @code{note} insns) allowing flags in @code{cc_status} to be used. 2441: (@xref{Condition Code}.) Also, the comparison and branch insns can be 2442: located from each other by using the functions @code{prev_cc0_setter} 2443: and @code{next_cc0_user}. 2444: 2445: However, this is not true on machines that do not use @code{(cc0)}. On 2446: those machines, no assumptions can be made about the adjacency of the 2447: compare and branch insns and the above methods cannot be used. Instead, 2448: we use the machine mode of the condition code register to record 2449: different formats of the condition code register. 2450: 2451: Registers used to store the condition code value should have a mode that 2452: is in class @code{MODE_CC}. Normally, it will be @code{CCmode}. If 2453: additional modes are required (as for the add example mentioned above in 2454: the Sparc), define the macro @code{EXTRA_CC_MODES} to list the 2455: additional modes required (@pxref{Condition Code}). Also define 2456: @code{EXTRA_CC_NAMES} to list the names of those modes and 2457: @code{SELECT_CC_MODE} to choose a mode given an operand of a compare. 2458: 2459: If it is known during RTL generation that a different mode will be 2460: required (for example, if the machine has separate compare instructions 2461: for signed and unsigned quantities, like most IBM processors), they can 2462: be specified at that time. 2463: 2464: If the cases that require different modes would be made by instruction 2465: combination, the macro @code{SELECT_CC_MODE} determines which machine 2466: mode should be used for the comparison result. The patterns should be 2467: written using that mode. To support the case of the add on the Sparc 2468: discussed above, we have the pattern 2469: 1.1.1.5 ! root 2470: @smallexample 1.1 root 2471: (define_insn "" 2472: [(set (reg:CC_NOOV 0) 1.1.1.5 ! root 2473: (compare:CC_NOOV ! 2474: (plus:SI (match_operand:SI 0 "register_operand" "%r") ! 2475: (match_operand:SI 1 "arith_operand" "rI")) ! 2476: (const_int 0)))] 1.1 root 2477: "" 2478: "@dots{}") 1.1.1.5 ! root 2479: @end smallexample 1.1 root 2480: 2481: The @code{SELECT_CC_MODE} macro on the Sparc returns @code{CC_NOOVmode} 2482: for comparisons whose argument is a @code{plus}. 2483: 1.1.1.5 ! root 2484: @node Insn Canonicalizations 1.1 root 2485: @section Canonicalization of Instructions 2486: @cindex canonicalization of instructions 2487: @cindex insn canonicalization 2488: 2489: There are often cases where multiple RTL expressions could represent an 1.1.1.2 root 2490: operation performed by a single machine instruction. This situation is 1.1 root 2491: most commonly encountered with logical, branch, and multiply-accumulate 2492: instructions. In such cases, the compiler attempts to convert these 2493: multiple RTL expressions into a single canonical form to reduce the 2494: number of insn patterns required. 2495: 2496: In addition to algebraic simplifications, following canonicalizations 2497: are performed: 2498: 2499: @itemize @bullet 2500: @item 2501: For commutative and comparison operators, a constant is always made the 2502: second operand. If a machine only supports a constant as the second 2503: operand, only patterns that match a constant in the second operand need 2504: be supplied. 2505: 2506: @cindex @code{neg}, canonicalization of 2507: @cindex @code{not}, canonicalization of 2508: @cindex @code{mult}, canonicalization of 2509: @cindex @code{plus}, canonicalization of 2510: @cindex @code{minus}, canonicalization of 2511: For these operators, if only one operand is a @code{neg}, @code{not}, 2512: @code{mult}, @code{plus}, or @code{minus} expression, it will be the 2513: first operand. 2514: 2515: @cindex @code{compare}, canonicalization of 2516: @item 2517: For the @code{compare} operator, a constant is always the second operand 2518: on machines where @code{cc0} is used (@pxref{Jump Patterns}). On other 2519: machines, there are rare cases where the compiler might want to construct 2520: a @code{compare} with a constant as the first operand. However, these 2521: cases are not common enough for it to be worthwhile to provide a pattern 2522: matching a constant as the first operand unless the machine actually has 2523: such an instruction. 2524: 2525: An operand of @code{neg}, @code{not}, @code{mult}, @code{plus}, or 2526: @code{minus} is made the first operand under the same conditions as 2527: above. 2528: 2529: @item 2530: @code{(minus @var{x} (const_int @var{n}))} is converted to 2531: @code{(plus @var{x} (const_int @var{-n}))}. 2532: 2533: @item 2534: Within address computations (i.e., inside @code{mem}), a left shift is 2535: converted into the appropriate multiplication by a power of two. 2536: 2537: @cindex @code{ior}, canonicalization of 2538: @cindex @code{and}, canonicalization of 2539: @cindex De Morgan's law 2540: De`Morgan's Law is used to move bitwise negation inside a bitwise 2541: logical-and or logical-or operation. If this results in only one 2542: operand being a @code{not} expression, it will be the first one. 2543: 2544: A machine that has an instruction that performs a bitwise logical-and of one 2545: operand with the bitwise negation of the other should specify the pattern 2546: for that instruction as 2547: 2548: @example 2549: (define_insn "" 2550: [(set (match_operand:@var{m} 0 @dots{}) 1.1.1.4 root 2551: (and:@var{m} (not:@var{m} (match_operand:@var{m} 1 @dots{})) 2552: (match_operand:@var{m} 2 @dots{})))] 1.1 root 2553: "@dots{}" 2554: "@dots{}") 2555: @end example 2556: 2557: @noindent 2558: Similarly, a pattern for a ``NAND'' instruction should be written 2559: 2560: @example 2561: (define_insn "" 2562: [(set (match_operand:@var{m} 0 @dots{}) 1.1.1.4 root 2563: (ior:@var{m} (not:@var{m} (match_operand:@var{m} 1 @dots{})) 2564: (not:@var{m} (match_operand:@var{m} 2 @dots{}))))] 1.1 root 2565: "@dots{}" 2566: "@dots{}") 2567: @end example 2568: 2569: In both cases, it is not necessary to include patterns for the many 2570: logically equivalent RTL expressions. 2571: 2572: @cindex @code{xor}, canonicalization of 2573: @item 2574: The only possible RTL expressions involving both bitwise exclusive-or 2575: and bitwise negation are @code{(xor:@var{m} @var{x}) @var{y})} 2576: and @code{(not:@var{m} (xor:@var{m} @var{x} @var{y}))}.@refill 2577: 2578: @item 2579: The sum of three items, one of which is a constant, will only appear in 2580: the form 2581: 2582: @example 2583: (plus:@var{m} (plus:@var{m} @var{x} @var{y}) @var{constant}) 2584: @end example 2585: 2586: @item 2587: On machines that do not use @code{cc0}, 2588: @code{(compare @var{x} (const_int 0))} will be converted to 2589: @var{x}.@refill 2590: 2591: @cindex @code{zero_extract}, canonicalization of 2592: @cindex @code{sign_extract}, canonicalization of 2593: @item 2594: Equality comparisons of a group of bits (usually a single bit) with zero 2595: will be written using @code{zero_extract} rather than the equivalent 2596: @code{and} or @code{sign_extract} operations. 2597: 2598: @end itemize 2599: 1.1.1.5 ! root 2600: @node Peephole Definitions ! 2601: @section Machine-Specific Peephole Optimizers 1.1 root 2602: @cindex peephole optimizer definitions 2603: @cindex defining peephole optimizers 2604: 2605: In addition to instruction patterns the @file{md} file may contain 2606: definitions of machine-specific peephole optimizations. 2607: 2608: The combiner does not notice certain peephole optimizations when the data 2609: flow in the program does not suggest that it should try them. For example, 2610: sometimes two consecutive insns related in purpose can be combined even 2611: though the second one does not appear to use a register computed in the 2612: first one. A machine-specific peephole optimizer can detect such 2613: opportunities. 2614: 1.1.1.5 ! root 2615: @need 1000 1.1 root 2616: A definition looks like this: 2617: 1.1.1.5 ! root 2618: @smallexample 1.1 root 2619: (define_peephole 2620: [@var{insn-pattern-1} 2621: @var{insn-pattern-2} 2622: @dots{}] 2623: "@var{condition}" 2624: "@var{template}" 2625: "@var{optional insn-attributes}") 1.1.1.5 ! root 2626: @end smallexample 1.1 root 2627: 2628: @noindent 2629: The last string operand may be omitted if you are not using any 2630: machine-specific information in this machine description. If present, 2631: it must obey the same rules as in a @code{define_insn}. 2632: 2633: In this skeleton, @var{insn-pattern-1} and so on are patterns to match 2634: consecutive insns. The optimization applies to a sequence of insns when 2635: @var{insn-pattern-1} matches the first one, @var{insn-pattern-2} matches 2636: the next, and so on.@refill 2637: 2638: Each of the insns matched by a peephole must also match a 2639: @code{define_insn}. Peepholes are checked only at the last stage just 2640: before code generation, and only optionally. Therefore, any insn which 2641: would match a peephole but no @code{define_insn} will cause a crash in code 2642: generation in an unoptimized compilation, or at various optimization 2643: stages. 2644: 2645: The operands of the insns are matched with @code{match_operands}, 2646: @code{match_operator}, and @code{match_dup}, as usual. What is not 2647: usual is that the operand numbers apply to all the insn patterns in the 2648: definition. So, you can check for identical operands in two insns by 2649: using @code{match_operand} in one insn and @code{match_dup} in the 2650: other. 2651: 2652: The operand constraints used in @code{match_operand} patterns do not have 2653: any direct effect on the applicability of the peephole, but they will 2654: be validated afterward, so make sure your constraints are general enough 2655: to apply whenever the peephole matches. If the peephole matches 2656: but the constraints are not satisfied, the compiler will crash. 2657: 2658: It is safe to omit constraints in all the operands of the peephole; or 2659: you can write constraints which serve as a double-check on the criteria 2660: previously tested. 2661: 2662: Once a sequence of insns matches the patterns, the @var{condition} is 2663: checked. This is a C expression which makes the final decision whether to 2664: perform the optimization (we do so if the expression is nonzero). If 2665: @var{condition} is omitted (in other words, the string is empty) then the 2666: optimization is applied to every sequence of insns that matches the 2667: patterns. 2668: 2669: The defined peephole optimizations are applied after register allocation 2670: is complete. Therefore, the peephole definition can check which 2671: operands have ended up in which kinds of registers, just by looking at 2672: the operands. 2673: 2674: @findex prev_nonnote_insn 2675: The way to refer to the operands in @var{condition} is to write 2676: @code{operands[@var{i}]} for operand number @var{i} (as matched by 2677: @code{(match_operand @var{i} @dots{})}). Use the variable @code{insn} 2678: to refer to the last of the insns being matched; use 2679: @code{prev_nonnote_insn} to find the preceding insns. 2680: 2681: @findex dead_or_set_p 2682: When optimizing computations with intermediate results, you can use 2683: @var{condition} to match only when the intermediate results are not used 2684: elsewhere. Use the C expression @code{dead_or_set_p (@var{insn}, 2685: @var{op})}, where @var{insn} is the insn in which you expect the value 2686: to be used for the last time (from the value of @code{insn}, together 2687: with use of @code{prev_nonnote_insn}), and @var{op} is the intermediate 2688: value (from @code{operands[@var{i}]}).@refill 2689: 2690: Applying the optimization means replacing the sequence of insns with one 2691: new insn. The @var{template} controls ultimate output of assembler code 2692: for this combined insn. It works exactly like the template of a 2693: @code{define_insn}. Operand numbers in this template are the same ones 2694: used in matching the original sequence of insns. 2695: 2696: The result of a defined peephole optimizer does not need to match any of 2697: the insn patterns in the machine description; it does not even have an 2698: opportunity to match them. The peephole optimizer definition itself serves 2699: as the insn pattern to control how the insn is output. 2700: 2701: Defined peephole optimizers are run as assembler code is being output, 2702: so the insns they produce are never combined or rearranged in any way. 2703: 2704: Here is an example, taken from the 68000 machine description: 2705: 1.1.1.5 ! root 2706: @smallexample 1.1 root 2707: (define_peephole 2708: [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) 1.1.1.3 root 2709: (set (match_operand:DF 0 "register_operand" "=f") 1.1 root 2710: (match_operand:DF 1 "register_operand" "ad"))] 2711: "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" 2712: "* 2713: @{ 2714: rtx xoperands[2]; 2715: xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1); 2716: #ifdef MOTOROLA 2717: output_asm_insn (\"move.l %1,(sp)\", xoperands); 2718: output_asm_insn (\"move.l %1,-(sp)\", operands); 2719: return \"fmove.d (sp)+,%0\"; 2720: #else 2721: output_asm_insn (\"movel %1,sp@@\", xoperands); 2722: output_asm_insn (\"movel %1,sp@@-\", operands); 2723: return \"fmoved sp@@+,%0\"; 2724: #endif 2725: @} 2726: ") 1.1.1.5 ! root 2727: @end smallexample 1.1 root 2728: 1.1.1.5 ! root 2729: @need 1000 1.1 root 2730: The effect of this optimization is to change 2731: 1.1.1.5 ! root 2732: @smallexample ! 2733: @group 1.1 root 2734: jbsr _foobar 2735: addql #4,sp 2736: movel d1,sp@@- 2737: movel d0,sp@@- 2738: fmoved sp@@+,fp0 1.1.1.5 ! root 2739: @end group ! 2740: @end smallexample 1.1 root 2741: 2742: @noindent 2743: into 2744: 1.1.1.5 ! root 2745: @smallexample ! 2746: @group 1.1 root 2747: jbsr _foobar 2748: movel d1,sp@@ 2749: movel d0,sp@@- 2750: fmoved sp@@+,fp0 1.1.1.5 ! root 2751: @end group ! 2752: @end smallexample 1.1 root 2753: 2754: @ignore 2755: @findex CC_REVERSED 2756: If a peephole matches a sequence including one or more jump insns, you must 2757: take account of the flags such as @code{CC_REVERSED} which specify that the 2758: condition codes are represented in an unusual manner. The compiler 2759: automatically alters any ordinary conditional jumps which occur in such 2760: situations, but the compiler cannot alter jumps which have been replaced by 2761: peephole optimizations. So it is up to you to alter the assembler code 2762: that the peephole produces. Supply C code to write the assembler output, 2763: and in this C code check the condition code status flags and change the 2764: assembler code as appropriate. 2765: @end ignore 2766: 2767: @var{insn-pattern-1} and so on look @emph{almost} like the second 2768: operand of @code{define_insn}. There is one important difference: the 2769: second operand of @code{define_insn} consists of one or more RTX's 2770: enclosed in square brackets. Usually, there is only one: then the same 2771: action can be written as an element of a @code{define_peephole}. But 2772: when there are multiple actions in a @code{define_insn}, they are 2773: implicitly enclosed in a @code{parallel}. Then you must explicitly 2774: write the @code{parallel}, and the square brackets within it, in the 2775: @code{define_peephole}. Thus, if an insn pattern looks like this, 2776: 1.1.1.5 ! root 2777: @smallexample 1.1 root 2778: (define_insn "divmodsi4" 2779: [(set (match_operand:SI 0 "general_operand" "=d") 2780: (div:SI (match_operand:SI 1 "general_operand" "0") 2781: (match_operand:SI 2 "general_operand" "dmsK"))) 2782: (set (match_operand:SI 3 "general_operand" "=d") 2783: (mod:SI (match_dup 1) (match_dup 2)))] 2784: "TARGET_68020" 2785: "divsl%.l %2,%3:%0") 1.1.1.5 ! root 2786: @end smallexample 1.1 root 2787: 2788: @noindent 2789: then the way to mention this insn in a peephole is as follows: 2790: 1.1.1.5 ! root 2791: @smallexample 1.1 root 2792: (define_peephole 2793: [@dots{} 2794: (parallel 2795: [(set (match_operand:SI 0 "general_operand" "=d") 2796: (div:SI (match_operand:SI 1 "general_operand" "0") 2797: (match_operand:SI 2 "general_operand" "dmsK"))) 2798: (set (match_operand:SI 3 "general_operand" "=d") 2799: (mod:SI (match_dup 1) (match_dup 2)))]) 2800: @dots{}] 2801: @dots{}) 1.1.1.5 ! root 2802: @end smallexample 1.1 root 2803: 1.1.1.5 ! root 2804: @node Expander Definitions 1.1 root 2805: @section Defining RTL Sequences for Code Generation 2806: @cindex expander definitions 2807: @cindex code generation RTL sequences 2808: @cindex defining RTL sequences for code generation 2809: 2810: On some target machines, some standard pattern names for RTL generation 2811: cannot be handled with single insn, but a sequence of RTL insns can 2812: represent them. For these target machines, you can write a 2813: @code{define_expand} to specify how to generate the sequence of RTL. 2814: 2815: @findex define_expand 2816: A @code{define_expand} is an RTL expression that looks almost like a 2817: @code{define_insn}; but, unlike the latter, a @code{define_expand} is used 2818: only for RTL generation and it can produce more than one RTL insn. 2819: 2820: A @code{define_expand} RTX has four operands: 2821: 2822: @itemize @bullet 2823: @item 2824: The name. Each @code{define_expand} must have a name, since the only 2825: use for it is to refer to it by name. 2826: 2827: @findex define_peephole 2828: @item 2829: The RTL template. This is just like the RTL template for a 2830: @code{define_peephole} in that it is a vector of RTL expressions 2831: each being one insn. 2832: 2833: @item 2834: The condition, a string containing a C expression. This expression is 2835: used to express how the availability of this pattern depends on 2836: subclasses of target machine, selected by command-line options when 2837: GNU CC is run. This is just like the condition of a 2838: @code{define_insn} that has a standard name. 2839: 2840: @item 2841: The preparation statements, a string containing zero or more C 2842: statements which are to be executed before RTL code is generated from 2843: the RTL template. 2844: 2845: Usually these statements prepare temporary registers for use as 2846: internal operands in the RTL template, but they can also generate RTL 2847: insns directly by calling routines such as @code{emit_insn}, etc. 2848: Any such insns precede the ones that come from the RTL template. 2849: @end itemize 2850: 2851: Every RTL insn emitted by a @code{define_expand} must match some 2852: @code{define_insn} in the machine description. Otherwise, the compiler 2853: will crash when trying to generate code for the insn or trying to optimize 2854: it. 2855: 2856: The RTL template, in addition to controlling generation of RTL insns, 2857: also describes the operands that need to be specified when this pattern 2858: is used. In particular, it gives a predicate for each operand. 2859: 2860: A true operand, which needs to be specified in order to generate RTL from 2861: the pattern, should be described with a @code{match_operand} in its first 2862: occurrence in the RTL template. This enters information on the operand's 2863: predicate into the tables that record such things. GNU CC uses the 2864: information to preload the operand into a register if that is required for 2865: valid RTL code. If the operand is referred to more than once, subsequent 2866: references should use @code{match_dup}. 2867: 2868: The RTL template may also refer to internal ``operands'' which are 2869: temporary registers or labels used only within the sequence made by the 2870: @code{define_expand}. Internal operands are substituted into the RTL 2871: template with @code{match_dup}, never with @code{match_operand}. The 2872: values of the internal operands are not passed in as arguments by the 2873: compiler when it requests use of this pattern. Instead, they are computed 2874: within the pattern, in the preparation statements. These statements 2875: compute the values and store them into the appropriate elements of 2876: @code{operands} so that @code{match_dup} can find them. 2877: 2878: There are two special macros defined for use in the preparation statements: 2879: @code{DONE} and @code{FAIL}. Use them with a following semicolon, 2880: as a statement. 2881: 2882: @table @code 2883: 2884: @findex DONE 2885: @item DONE 2886: Use the @code{DONE} macro to end RTL generation for the pattern. The 2887: only RTL insns resulting from the pattern on this occasion will be 2888: those already emitted by explicit calls to @code{emit_insn} within the 2889: preparation statements; the RTL template will not be generated. 2890: 2891: @findex FAIL 2892: @item FAIL 2893: Make the pattern fail on this occasion. When a pattern fails, it means 2894: that the pattern was not truly available. The calling routines in the 2895: compiler will try other strategies for code generation using other patterns. 2896: 2897: Failure is currently supported only for binary (addition, multiplication, 2898: shifting, etc.) and bitfield (@code{extv}, @code{extzv}, and @code{insv}) 2899: operations. 2900: @end table 2901: 2902: Here is an example, the definition of left-shift for the SPUR chip: 2903: 1.1.1.5 ! root 2904: @smallexample ! 2905: @group 1.1 root 2906: (define_expand "ashlsi3" 2907: [(set (match_operand:SI 0 "register_operand" "") 2908: (ashift:SI 1.1.1.5 ! root 2909: @end group ! 2910: @group 1.1 root 2911: (match_operand:SI 1 "register_operand" "") 2912: (match_operand:SI 2 "nonmemory_operand" "")))] 2913: "" 2914: " 1.1.1.5 ! root 2915: @end group ! 2916: @end smallexample ! 2917: ! 2918: @smallexample ! 2919: @group 1.1 root 2920: @{ 2921: if (GET_CODE (operands[2]) != CONST_INT 2922: || (unsigned) INTVAL (operands[2]) > 3) 2923: FAIL; 2924: @}") 1.1.1.5 ! root 2925: @end group ! 2926: @end smallexample 1.1 root 2927: 2928: @noindent 2929: This example uses @code{define_expand} so that it can generate an RTL insn 2930: for shifting when the shift-count is in the supported range of 0 to 3 but 2931: fail in other cases where machine insns aren't available. When it fails, 2932: the compiler tries another strategy using different patterns (such as, a 2933: library call). 2934: 2935: If the compiler were able to handle nontrivial condition-strings in 2936: patterns with names, then it would be possible to use a 2937: @code{define_insn} in that case. Here is another case (zero-extension 2938: on the 68000) which makes more use of the power of @code{define_expand}: 2939: 1.1.1.5 ! root 2940: @smallexample 1.1 root 2941: (define_expand "zero_extendhisi2" 2942: [(set (match_operand:SI 0 "general_operand" "") 2943: (const_int 0)) 2944: (set (strict_low_part 2945: (subreg:HI 2946: (match_dup 0) 2947: 0)) 2948: (match_operand:HI 1 "general_operand" ""))] 2949: "" 2950: "operands[1] = make_safe_from (operands[1], operands[0]);") 1.1.1.5 ! root 2951: @end smallexample 1.1 root 2952: 2953: @noindent 2954: @findex make_safe_from 2955: Here two RTL insns are generated, one to clear the entire output operand 2956: and the other to copy the input operand into its low half. This sequence 2957: is incorrect if the input operand refers to [the old value of] the output 2958: operand, so the preparation statement makes sure this isn't so. The 2959: function @code{make_safe_from} copies the @code{operands[1]} into a 2960: temporary register if it refers to @code{operands[0]}. It does this 2961: by emitting another RTL insn. 2962: 2963: Finally, a third example shows the use of an internal operand. 2964: Zero-extension on the SPUR chip is done by @code{and}-ing the result 2965: against a halfword mask. But this mask cannot be represented by a 2966: @code{const_int} because the constant value is too large to be legitimate 2967: on this machine. So it must be copied into a register with 2968: @code{force_reg} and then the register used in the @code{and}. 2969: 1.1.1.5 ! root 2970: @smallexample 1.1 root 2971: (define_expand "zero_extendhisi2" 2972: [(set (match_operand:SI 0 "register_operand" "") 2973: (and:SI (subreg:SI 2974: (match_operand:HI 1 "register_operand" "") 2975: 0) 2976: (match_dup 2)))] 2977: "" 2978: "operands[2] 2979: = force_reg (SImode, gen_rtx (CONST_INT, 2980: VOIDmode, 65535)); ") 1.1.1.5 ! root 2981: @end smallexample 1.1 root 2982: 2983: @strong{Note:} If the @code{define_expand} is used to serve a 2984: standard binary or unary arithmetic operation or a bitfield operation, 2985: then the last insn it generates must not be a @code{code_label}, 2986: @code{barrier} or @code{note}. It must be an @code{insn}, 2987: @code{jump_insn} or @code{call_insn}. If you don't need a real insn 2988: at the end, emit an insn to copy the result of the operation into 2989: itself. Such an insn will generate no code, but it can avoid problems 2990: in the compiler.@refill 2991: 1.1.1.5 ! root 2992: @node Insn Splitting ! 2993: @section Defining How to Split Instructions 1.1 root 2994: @cindex insn splitting 2995: @cindex instruction splitting 2996: @cindex splitting instructions 2997: 1.1.1.3 root 2998: There are two cases where you should specify how to split a pattern into 2999: multiple insns. On machines that have instructions requiring delay 3000: slots (@pxref{Delay Slots}) or that have instructions whose output is 3001: not available for multiple cycles (@pxref{Function Units}), the compiler 3002: phases that optimize these cases need to be able to move insns into 3003: one-cycle delay slots. However, some insns may generate more than one 3004: machine instruction. These insns cannot be placed into a delay slot. 3005: 3006: Often you can rewrite the single insn as a list of individual insns, 3007: each corresponding to one machine instruction. The disadvantage of 3008: doing so is that it will cause the compilation to be slower and require 3009: more space. If the resulting insns are too complex, it may also 3010: suppress some optimizations. The compiler splits the insn if there is a 3011: reason to believe that it might improve instruction or delay slot 3012: scheduling. 3013: 3014: The insn combiner phase also splits putative insns. If three insns are 3015: merged into one insn with a complex expression that cannot be matched by 3016: some @code{define_insn} pattern, the combiner phase attempts to split 3017: the complex pattern into two insns that are recognized. Usually it can 3018: break the complex pattern into two patterns by splitting out some 3019: subexpression. However, in some other cases, such as performing an 3020: addition of a large constant in two insns on a RISC machine, the way to 3021: split the addition into two insns is machine-dependent. 1.1 root 3022: 1.1.1.3 root 3023: @cindex define_split 1.1 root 3024: The @code{define_split} definition tells the compiler how to split a 1.1.1.3 root 3025: complex insn into several simpler insns. It looks like this: 1.1 root 3026: 1.1.1.5 ! root 3027: @smallexample 1.1 root 3028: (define_split 3029: [@var{insn-pattern}] 3030: "@var{condition}" 3031: [@var{new-insn-pattern-1} 3032: @var{new-insn-pattern-2} 3033: @dots{}] 3034: "@var{preparation statements}") 1.1.1.5 ! root 3035: @end smallexample 1.1 root 3036: 3037: @var{insn-pattern} is a pattern that needs to be split and 3038: @var{condition} is the final condition to be tested, as in a 1.1.1.3 root 3039: @code{define_insn}. When an insn matching @var{insn-pattern} and 3040: satisfying @var{condition} is found, it is replaced in the insn list 3041: with the insns given by @var{new-insn-pattern-1}, 3042: @var{new-insn-pattern-2}, etc. 1.1 root 3043: 1.1.1.5 ! root 3044: The @var{preparation statements} are similar to those statements that ! 3045: are specified for @code{define_expand} (@pxref{Expander Definitions}) ! 3046: and are executed before the new RTL is generated to prepare for the ! 3047: generated code or emit some insns whose pattern is not fixed. Unlike ! 3048: those in @code{define_expand}, however, these statements must not ! 3049: generate any new pseudo-registers. Once reload has completed, they also 1.1.1.4 root 3050: must not allocate any space in the stack frame. 1.1 root 3051: 1.1.1.3 root 3052: Patterns are matched against @var{insn-pattern} in two different 3053: circumstances. If an insn needs to be split for delay slot scheduling 3054: or insn scheduling, the insn is already known to be valid, which means 3055: that it must have been matched by some @code{define_insn} and, if 3056: @code{reload_completed} is non-zero, is known to satisfy the constraints 3057: of that @code{define_insn}. In that case, the new insn patterns must 3058: also be insns that are matched by some @code{define_insn} and, if 3059: @code{reload_completed} is non-zero, must also satisfy the constraints 3060: of those definitions. 3061: 3062: As an example of this usage of @code{define_split}, consider the following 3063: example from @file{a29k.md}, which splits a @code{sign_extend} from 1.1 root 3064: @code{HImode} to @code{SImode} into a pair of shift insns: 3065: 1.1.1.5 ! root 3066: @smallexample 1.1 root 3067: (define_split 3068: [(set (match_operand:SI 0 "gen_reg_operand" "") 1.1.1.4 root 3069: (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 1.1 root 3070: "" 3071: [(set (match_dup 0) 1.1.1.4 root 3072: (ashift:SI (match_dup 1) 3073: (const_int 16))) 1.1 root 3074: (set (match_dup 0) 1.1.1.4 root 3075: (ashiftrt:SI (match_dup 0) 3076: (const_int 16)))] 1.1 root 3077: " 3078: @{ operands[1] = gen_lowpart (SImode, operands[1]); @}") 1.1.1.5 ! root 3079: @end smallexample 1.1 root 3080: 1.1.1.3 root 3081: When the combiner phase tries to split an insn pattern, it is always the 3082: case that the pattern is @emph{not} matched by any @code{define_insn}. 3083: The combiner pass first tries to split a single @code{set} expression 3084: and then the same @code{set} expression inside a @code{parallel}, but 3085: followed by a @code{clobber} of a pseudo-reg to use as a scratch 3086: register. In these cases, the combiner expects exactly two new insn 3087: patterns to be generated. It will verify that these patterns match some 3088: @code{define_insn} definitions, so you need not do this test in the 3089: @code{define_split} (of course, there is no point in writing a 3090: @code{define_split} that will never produce insns that match). 3091: 3092: Here is an example of this use of @code{define_split}, taken from 3093: @file{rs6000.md}: 3094: 1.1.1.5 ! root 3095: @smallexample 1.1.1.3 root 3096: (define_split 3097: [(set (match_operand:SI 0 "gen_reg_operand" "") 1.1.1.4 root 3098: (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 3099: (match_operand:SI 2 "non_add_cint_operand" "")))] 1.1.1.3 root 3100: "" 3101: [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 3102: (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 3103: " 3104: @{ 3105: int low = INTVAL (operands[2]) & 0xffff; 3106: int high = (unsigned) INTVAL (operands[2]) >> 16; 3107: 3108: if (low & 0x8000) 3109: high++, low |= 0xffff0000; 3110: 3111: operands[3] = gen_rtx (CONST_INT, VOIDmode, high << 16); 3112: operands[4] = gen_rtx (CONST_INT, VOIDmode, low); 3113: @}") 1.1.1.5 ! root 3114: @end smallexample 1.1.1.3 root 3115: 3116: Here the predicate @code{non_add_cint_operand} matches any 3117: @code{const_int} that is @emph{not} a valid operand of a single add 3118: insn. Write the add with the smaller displacement is written so that it 3119: can be substituted into the address of a subsequent operation. 3120: 3121: An example that uses a scratch register, from the same file, generates 3122: an equality comparison of a register and a large constant: 3123: 1.1.1.5 ! root 3124: @smallexample 1.1.1.3 root 3125: (define_split 3126: [(set (match_operand:CC 0 "cc_reg_operand" "") 1.1.1.4 root 3127: (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 3128: (match_operand:SI 2 "non_short_cint_operand" ""))) 1.1.1.3 root 3129: (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 3130: "find_single_use (operands[0], insn, 0) 3131: && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 3132: || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 3133: [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 3134: (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 3135: " 3136: @{ 1.1.1.5 ! root 3137: /* Get the constant we are comparing against, C, and see what it ! 3138: looks like sign-extended to 16 bits. Then see what constant ! 3139: could be XOR'ed with C to get the sign-extended value. */ 1.1.1.3 root 3140: 3141: int c = INTVAL (operands[2]); 3142: int sextc = (c << 16) >> 16; 3143: int xorv = c ^ sextc; 3144: 3145: operands[4] = gen_rtx (CONST_INT, VOIDmode, xorv); 3146: operands[5] = gen_rtx (CONST_INT, VOIDmode, sextc); 3147: @}") 1.1.1.5 ! root 3148: @end smallexample 1.1.1.3 root 3149: 3150: To avoid confusion, don't write a single @code{define_split} that 3151: accepts some insns that match some @code{define_insn} as well as some 3152: insns that don't. Instead, write two separate @code{define_split} 3153: definitions, one for the insns that are valid and one for the insns that 3154: are not valid. 3155: 1.1.1.5 ! root 3156: @node Insn Attributes 1.1 root 3157: @section Instruction Attributes 3158: @cindex insn attributes 3159: @cindex instruction attributes 3160: 3161: In addition to describing the instruction supported by the target machine, 3162: the @file{md} file also defines a group of @dfn{attributes} and a set of 3163: values for each. Every generated insn is assigned a value for each attribute. 3164: One possible attribute would be the effect that the insn has on the machine's 3165: condition code. This attribute can then be used by @code{NOTICE_UPDATE_CC} 3166: to track the condition codes. 3167: 3168: @menu 3169: * Defining Attributes:: Specifying attributes and their values. 3170: * Expressions:: Valid expressions for attribute values. 3171: * Tagging Insns:: Assigning attribute values to insns. 3172: * Attr Example:: An example of assigning attributes. 3173: * Insn Lengths:: Computing the length of insns. 1.1.1.2 root 3174: * Constant Attributes:: Defining attributes that are constant. 1.1 root 3175: * Delay Slots:: Defining delay slots required for a machine. 3176: * Function Units:: Specifying information for insn scheduling. 3177: @end menu 3178: 1.1.1.5 ! root 3179: @node Defining Attributes 1.1 root 3180: @subsection Defining Attributes and their Values 3181: @cindex defining attributes and their values 3182: @cindex attributes, defining 3183: 3184: @findex define_attr 3185: The @code{define_attr} expression is used to define each attribute required 3186: by the target machine. It looks like: 3187: 1.1.1.5 ! root 3188: @smallexample 1.1 root 3189: (define_attr @var{name} @var{list-of-values} @var{default}) 1.1.1.5 ! root 3190: @end smallexample 1.1 root 3191: 3192: @var{name} is a string specifying the name of the attribute being defined. 3193: 3194: @var{list-of-values} is either a string that specifies a comma-separated 3195: list of values that can be assigned to the attribute, or a null string to 3196: indicate that the attribute takes numeric values. 3197: 3198: @var{default} is an attribute expression that gives the value of this 3199: attribute for insns that match patterns whose definition does not include 3200: an explicit value for this attribute. @xref{Attr Example}, for more 1.1.1.2 root 3201: information on the handling of defaults. @xref{Constant Attributes}, 3202: for information on attributes that do not depend on any particular insn. 1.1 root 3203: 3204: @findex insn-attr.h 3205: For each defined attribute, a number of definitions are written to the 3206: @file{insn-attr.h} file. For cases where an explicit set of values is 3207: specified for an attribute, the following are defined: 3208: 3209: @itemize @bullet 3210: @item 3211: A @samp{#define} is written for the symbol @samp{HAVE_ATTR_@var{name}}. 3212: 3213: @item 3214: An enumeral class is defined for @samp{attr_@var{name}} with 3215: elements of the form @samp{@var{upper-name}_@var{upper-value}} where 3216: the attribute name and value are first converted to upper case. 3217: 3218: @item 3219: A function @samp{get_attr_@var{name}} is defined that is passed an insn and 3220: returns the attribute value for that insn. 3221: @end itemize 3222: 3223: For example, if the following is present in the @file{md} file: 3224: 1.1.1.5 ! root 3225: @smallexample 1.1 root 3226: (define_attr "type" "branch,fp,load,store,arith" @dots{}) 1.1.1.5 ! root 3227: @end smallexample 1.1 root 3228: 3229: @noindent 3230: the following lines will be written to the file @file{insn-attr.h}. 3231: 1.1.1.5 ! root 3232: @smallexample 1.1 root 3233: #define HAVE_ATTR_type 3234: enum attr_type @{TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 1.1.1.4 root 3235: TYPE_STORE, TYPE_ARITH@}; 1.1 root 3236: extern enum attr_type get_attr_type (); 1.1.1.5 ! root 3237: @end smallexample 1.1 root 3238: 3239: If the attribute takes numeric values, no @code{enum} type will be 3240: defined and the function to obtain the attribute's value will return 3241: @code{int}. 3242: 1.1.1.5 ! root 3243: @node Expressions 1.1 root 3244: @subsection Attribute Expressions 3245: @cindex attribute expressions 3246: 3247: RTL expressions used to define attributes use the codes described above 3248: plus a few specific to attribute definitions, to be discussed below. 3249: Attribute value expressions must have one of the following forms: 3250: 3251: @table @code 3252: @cindex @code{const_int} and attributes 3253: @item (const_int @var{i}) 3254: The integer @var{i} specifies the value of a numeric attribute. @var{i} 3255: must be non-negative. 3256: 3257: The value of a numeric attribute can be specified either with a 3258: @code{const_int} or as an integer represented as a string in 3259: @code{const_string}, @code{eq_attr} (see below), and @code{set_attr} 3260: (@pxref{Tagging Insns}) expressions. 3261: 3262: @cindex @code{const_string} and attributes 3263: @item (const_string @var{value}) 3264: The string @var{value} specifies a constant attribute value. 3265: If @var{value} is specified as @samp{"*"}, it means that the default value of 3266: the attribute is to be used for the insn containing this expression. 3267: @samp{"*"} obviously cannot be used in the @var{default} expression 3268: of a @code{define_attr}.@refill 3269: 3270: If the attribute whose value is being specified is numeric, @var{value} 3271: must be a string containing a non-negative integer (normally 3272: @code{const_int} would be used in this case). Otherwise, it must 3273: contain one of the valid values for the attribute. 3274: 3275: @cindex @code{if_then_else} and attributes 3276: @item (if_then_else @var{test} @var{true-value} @var{false-value}) 3277: @var{test} specifies an attribute test, whose format is defined below. 3278: The value of this expression is @var{true-value} if @var{test} is true, 3279: otherwise it is @var{false-value}. 3280: 3281: @cindex @code{cond} and attributes 3282: @item (cond [@var{test1} @var{value1} @dots{}] @var{default}) 3283: The first operand of this expression is a vector containing an even 3284: number of expressions and consisting of pairs of @var{test} and @var{value} 3285: expressions. The value of the @code{cond} expression is that of the 3286: @var{value} corresponding to the first true @var{test} expression. If 3287: none of the @var{test} expressions are true, the value of the @code{cond} 3288: expression is that of the @var{default} expression. 3289: @end table 3290: 3291: @var{test} expressions can have one of the following forms: 3292: 3293: @table @code 3294: @cindex @code{const_int} and attribute tests 3295: @item (const_int @var{i}) 3296: This test is true if @var{i} is non-zero and false otherwise. 3297: 3298: @cindex @code{not} and attributes 3299: @cindex @code{ior} and attributes 3300: @cindex @code{and} and attributes 3301: @item (not @var{test}) 3302: @itemx (ior @var{test1} @var{test2}) 3303: @itemx (and @var{test1} @var{test2}) 3304: These tests are true if the indicated logical function is true. 3305: 3306: @cindex @code{match_operand} and attributes 3307: @item (match_operand:@var{m} @var{n} @var{pred} @var{constraints}) 3308: This test is true if operand @var{n} of the insn whose attribute value 3309: is being determined has mode @var{m} (this part of the test is ignored 3310: if @var{m} is @code{VOIDmode}) and the function specified by the string 3311: @var{pred} returns a non-zero value when passed operand @var{n} and mode 3312: @var{m} (this part of the test is ignored if @var{pred} is the null 3313: string). 3314: 3315: The @var{constraints} operand is ignored and should be the null string. 3316: 3317: @cindex @code{le} and attributes 3318: @cindex @code{leu} and attributes 3319: @cindex @code{lt} and attributes 3320: @cindex @code{gt} and attributes 3321: @cindex @code{gtu} and attributes 3322: @cindex @code{ge} and attributes 3323: @cindex @code{geu} and attributes 3324: @cindex @code{ne} and attributes 3325: @cindex @code{eq} and attributes 3326: @cindex @code{plus} and attributes 3327: @cindex @code{minus} and attributes 3328: @cindex @code{mult} and attributes 3329: @cindex @code{div} and attributes 3330: @cindex @code{mod} and attributes 3331: @cindex @code{abs} and attributes 3332: @cindex @code{neg} and attributes 3333: @cindex @code{lshift} and attributes 3334: @cindex @code{ashift} and attributes 3335: @cindex @code{lshiftrt} and attributes 3336: @cindex @code{ashiftrt} and attributes 3337: @item (le @var{arith1} @var{arith2}) 3338: @itemx (leu @var{arith1} @var{arith2}) 3339: @itemx (lt @var{arith1} @var{arith2}) 3340: @itemx (ltu @var{arith1} @var{arith2}) 3341: @itemx (gt @var{arith1} @var{arith2}) 3342: @itemx (gtu @var{arith1} @var{arith2}) 3343: @itemx (ge @var{arith1} @var{arith2}) 3344: @itemx (geu @var{arith1} @var{arith2}) 3345: @itemx (ne @var{arith1} @var{arith2}) 3346: @itemx (eq @var{arith1} @var{arith2}) 3347: These tests are true if the indicated comparison of the two arithmetic 3348: expressions is true. Arithmetic expressions are formed with 3349: @code{plus}, @code{minus}, @code{mult}, @code{div}, @code{mod}, 3350: @code{abs}, @code{neg}, @code{and}, @code{ior}, @code{xor}, @code{not}, 3351: @code{lshift}, @code{ashift}, @code{lshiftrt}, and @code{ashiftrt} 3352: expressions.@refill 3353: 3354: @findex get_attr 3355: @code{const_int} and @code{symbol_ref} are always valid terms (@pxref{Insn 3356: Lengths},for additional forms). @code{symbol_ref} is a string 3357: denoting a C expression that yields an @code{int} when evaluated by the 3358: @samp{get_attr_@dots{}} routine. It should normally be a global 3359: variable.@refill 3360: 3361: @findex eq_attr 3362: @item (eq_attr @var{name} @var{value}) 3363: @var{name} is a string specifying the name of an attribute. 3364: 3365: @var{value} is a string that is either a valid value for attribute 3366: @var{name}, a comma-separated list of values, or @samp{!} followed by a 3367: value or list. If @var{value} does not begin with a @samp{!}, this 3368: test is true if the value of the @var{name} attribute of the current 3369: insn is in the list specified by @var{value}. If @var{value} begins 3370: with a @samp{!}, this test is true if the attribute's value is 3371: @emph{not} in the specified list. 3372: 3373: For example, 3374: 1.1.1.5 ! root 3375: @smallexample 1.1 root 3376: (eq_attr "type" "load,store") 1.1.1.5 ! root 3377: @end smallexample 1.1 root 3378: 3379: @noindent 3380: is equivalent to 3381: 1.1.1.5 ! root 3382: @smallexample 1.1 root 3383: (ior (eq_attr "type" "load") (eq_attr "type" "store")) 1.1.1.5 ! root 3384: @end smallexample 1.1 root 3385: 3386: If @var{name} specifies an attribute of @samp{alternative}, it refers to the 3387: value of the compiler variable @code{which_alternative} 3388: (@pxref{Output Statement}) and the values must be small integers. For 3389: example,@refill 3390: 1.1.1.5 ! root 3391: @smallexample 1.1 root 3392: (eq_attr "alternative" "2,3") 1.1.1.5 ! root 3393: @end smallexample 1.1 root 3394: 3395: @noindent 3396: is equivalent to 3397: 1.1.1.5 ! root 3398: @smallexample 1.1 root 3399: (ior (eq (symbol_ref "which_alternative") (const_int 2)) 3400: (eq (symbol_ref "which_alternative") (const_int 3))) 1.1.1.5 ! root 3401: @end smallexample 1.1 root 3402: 3403: Note that, for most attributes, an @code{eq_attr} test is simplified in cases 3404: where the value of the attribute being tested is known for all insns matching 3405: a particular pattern. This is by far the most common case.@refill 1.1.1.5 ! root 3406: ! 3407: @findex attr_flag ! 3408: @item (attr_flag @var{name}) ! 3409: The value of an @code{attr_flag} expression is true if the flag ! 3410: specified by @var{name} is true for the @code{insn} currently being ! 3411: scheduled. ! 3412: ! 3413: @var{name} is a string specifying one of a fixed set of flags to test. ! 3414: Test the flags @code{forward} and @code{backward} to determine the ! 3415: direction of a conditional branch. Test the flags @code{very_likely}, ! 3416: @code{likely}, @code{very_unlikely}, and @code{unlikely} to determine ! 3417: if a conditional branch is expected to be taken. ! 3418: ! 3419: If the @code{very_likely} flag is true, then the @code{likely} flag is also ! 3420: true. Likewise for the @code{very_unlikely} and @code{unlikely} flags. ! 3421: ! 3422: This example describes a conditional branch delay slot which ! 3423: can be nullified for forward branches that are taken (annul-true) or ! 3424: for backward branches which are not taken (annul-false). ! 3425: ! 3426: @smallexample ! 3427: (define_delay (eq_attr "type" "cbranch") ! 3428: [(eq_attr "in_branch_delay" "true") ! 3429: (and (eq_attr "in_branch_delay" "true") ! 3430: (attr_flag "forward")) ! 3431: (and (eq_attr "in_branch_delay" "true") ! 3432: (attr_flag "backward"))]) ! 3433: @end smallexample ! 3434: ! 3435: The @code{forward} and @code{backward} flags are false if the current ! 3436: @code{insn} being scheduled is not a conditional branch. ! 3437: ! 3438: The @code{very_likely} and @code{likely} flags are true if the ! 3439: @code{insn} being scheduled is not a conditional branch. The ! 3440: The @code{very_unlikely} and @code{unlikely} flags are false if the ! 3441: @code{insn} being scheduled is not a conditional branch. ! 3442: ! 3443: @code{attr_flag} is only used during delay slot scheduling and has no ! 3444: meaning to other passes of the compiler. 1.1 root 3445: @end table 3446: 1.1.1.5 ! root 3447: @node Tagging Insns 1.1 root 3448: @subsection Assigning Attribute Values to Insns 3449: @cindex tagging insns 3450: @cindex assigning attribute values to insns 3451: 3452: The value assigned to an attribute of an insn is primarily determined by 3453: which pattern is matched by that insn (or which @code{define_peephole} 3454: generated it). Every @code{define_insn} and @code{define_peephole} can 3455: have an optional last argument to specify the values of attributes for 3456: matching insns. The value of any attribute not specified in a particular 3457: insn is set to the default value for that attribute, as specified in its 3458: @code{define_attr}. Extensive use of default values for attributes 3459: permits the specification of the values for only one or two attributes 3460: in the definition of most insn patterns, as seen in the example in the 3461: next section.@refill 3462: 3463: The optional last argument of @code{define_insn} and 3464: @code{define_peephole} is a vector of expressions, each of which defines 3465: the value for a single attribute. The most general way of assigning an 3466: attribute's value is to use a @code{set} expression whose first operand is an 3467: @code{attr} expression giving the name of the attribute being set. The 3468: second operand of the @code{set} is an attribute expression 3469: (@pxref{Expressions}) giving the value of the attribute.@refill 3470: 3471: When the attribute value depends on the @samp{alternative} attribute 3472: (i.e., which is the applicable alternative in the constraint of the 1.1.1.4 root 3473: insn), the @code{set_attr_alternative} expression can be used. It 1.1 root 3474: allows the specification of a vector of attribute expressions, one for 3475: each alternative. 3476: 3477: @findex set_attr 3478: When the generality of arbitrary attribute expressions is not required, 3479: the simpler @code{set_attr} expression can be used, which allows 3480: specifying a string giving either a single attribute value or a list 3481: of attribute values, one for each alternative. 3482: 3483: The form of each of the above specifications is shown below. In each case, 3484: @var{name} is a string specifying the attribute to be set. 3485: 3486: @table @code 3487: @item (set_attr @var{name} @var{value-string}) 3488: @var{value-string} is either a string giving the desired attribute value, 3489: or a string containing a comma-separated list giving the values for 3490: succeeding alternatives. The number of elements must match the number 3491: of alternatives in the constraint of the insn pattern. 3492: 3493: Note that it may be useful to specify @samp{*} for some alternative, in 3494: which case the attribute will assume its default value for insns matching 3495: that alternative. 3496: 3497: @findex set_attr_alternative 3498: @item (set_attr_alternative @var{name} [@var{value1} @var{value2} @dots{}]) 3499: Depending on the alternative of the insn, the value will be one of the 3500: specified values. This is a shorthand for using a @code{cond} with 3501: tests on the @samp{alternative} attribute. 3502: 3503: @findex attr 3504: @item (set (attr @var{name}) @var{value}) 3505: The first operand of this @code{set} must be the special RTL expression 3506: @code{attr}, whose sole operand is a string giving the name of the 3507: attribute being set. @var{value} is the value of the attribute. 3508: @end table 3509: 3510: The following shows three different ways of representing the same 3511: attribute value specification: 3512: 1.1.1.5 ! root 3513: @smallexample 1.1 root 3514: (set_attr "type" "load,store,arith") 3515: 3516: (set_attr_alternative "type" 3517: [(const_string "load") (const_string "store") 3518: (const_string "arith")]) 3519: 3520: (set (attr "type") 3521: (cond [(eq_attr "alternative" "1") (const_string "load") 3522: (eq_attr "alternative" "2") (const_string "store")] 3523: (const_string "arith"))) 1.1.1.5 ! root 3524: @end smallexample 1.1 root 3525: 1.1.1.5 ! root 3526: @need 1000 1.1 root 3527: @findex define_asm_attributes 3528: The @code{define_asm_attributes} expression provides a mechanism to 3529: specify the attributes assigned to insns produced from an @code{asm} 1.1.1.5 ! root 3530: statement. It has the form: 1.1 root 3531: 1.1.1.5 ! root 3532: @smallexample 1.1 root 3533: (define_asm_attributes [@var{attr-sets}]) 1.1.1.5 ! root 3534: @end smallexample 1.1 root 3535: 3536: @noindent 1.1.1.5 ! root 3537: where @var{attr-sets} is specified the same as for both the ! 3538: @code{define_insn} and the @code{define_peephole} expressions. 1.1 root 3539: 3540: These values will typically be the ``worst case'' attribute values. For 3541: example, they might indicate that the condition code will be clobbered. 3542: 1.1.1.5 ! root 3543: A specification for a @code{length} attribute is handled specially. The ! 3544: way to compute the length of an @code{asm} insn is to multiply the ! 3545: length specified in the expression @code{define_asm_attributes} by the ! 3546: number of machine instructions specified in the @code{asm} statement, ! 3547: determined by counting the number of semicolons and newlines in the ! 3548: string. Therefore, the value of the @code{length} attribute specified ! 3549: in a @code{define_asm_attributes} should be the maximum possible length ! 3550: of a single machine instruction. 1.1 root 3551: 1.1.1.5 ! root 3552: @node Attr Example 1.1 root 3553: @subsection Example of Attribute Specifications 3554: @cindex attribute specifications example 3555: @cindex attribute specifications 3556: 3557: The judicious use of defaulting is important in the efficient use of 3558: insn attributes. Typically, insns are divided into @dfn{types} and an 3559: attribute, customarily called @code{type}, is used to represent this 3560: value. This attribute is normally used only to define the default value 3561: for other attributes. An example will clarify this usage. 3562: 3563: Assume we have a RISC machine with a condition code and in which only 3564: full-word operations are performed in registers. Let us assume that we 3565: can divide all insns into loads, stores, (integer) arithmetic 3566: operations, floating point operations, and branches. 3567: 3568: Here we will concern ourselves with determining the effect of an insn on 3569: the condition code and will limit ourselves to the following possible 3570: effects: The condition code can be set unpredictably (clobbered), not 3571: be changed, be set to agree with the results of the operation, or only 3572: changed if the item previously set into the condition code has been 3573: modified. 3574: 3575: Here is part of a sample @file{md} file for such a machine: 3576: 1.1.1.5 ! root 3577: @smallexample 1.1 root 3578: (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 3579: 3580: (define_attr "cc" "clobber,unchanged,set,change0" 3581: (cond [(eq_attr "type" "load") 3582: (const_string "change0") 3583: (eq_attr "type" "store,branch") 3584: (const_string "unchanged") 3585: (eq_attr "type" "arith") 3586: (if_then_else (match_operand:SI 0 "" "") 3587: (const_string "set") 3588: (const_string "clobber"))] 3589: (const_string "clobber"))) 3590: 3591: (define_insn "" 3592: [(set (match_operand:SI 0 "general_operand" "=r,r,m") 3593: (match_operand:SI 1 "general_operand" "r,m,r"))] 3594: "" 3595: "@@ 3596: move %0,%1 3597: load %0,%1 3598: store %0,%1" 3599: [(set_attr "type" "arith,load,store")]) 1.1.1.5 ! root 3600: @end smallexample 1.1 root 3601: 3602: Note that we assume in the above example that arithmetic operations 3603: performed on quantities smaller than a machine word clobber the condition 3604: code since they will set the condition code to a value corresponding to the 3605: full-word result. 3606: 1.1.1.5 ! root 3607: @node Insn Lengths 1.1 root 3608: @subsection Computing the Length of an Insn 3609: @cindex insn lengths, computing 3610: @cindex computing the length of an insn 3611: 3612: For many machines, multiple types of branch instructions are provided, each 3613: for different length branch displacements. In most cases, the assembler 3614: will choose the correct instruction to use. However, when the assembler 3615: cannot do so, GCC can when a special attribute, the @samp{length} 3616: attribute, is defined. This attribute must be defined to have numeric 3617: values by specifying a null string in its @code{define_attr}. 3618: 3619: In the case of the @samp{length} attribute, two additional forms of 3620: arithmetic terms are allowed in test expressions: 3621: 3622: @table @code 3623: @cindex @code{match_dup} and attributes 3624: @item (match_dup @var{n}) 3625: This refers to the address of operand @var{n} of the current insn, which 3626: must be a @code{label_ref}. 3627: 3628: @cindex @code{pc} and attributes 3629: @item (pc) 3630: This refers to the address of the @emph{current} insn. It might have 3631: been more consistent with other usage to make this the address of the 3632: @emph{next} insn but this would be confusing because the length of the 3633: current insn is to be computed. 3634: @end table 3635: 3636: @cindex @code{addr_vec}, length of 3637: @cindex @code{addr_diff_vec}, length of 3638: For normal insns, the length will be determined by value of the 3639: @samp{length} attribute. In the case of @code{addr_vec} and 1.1.1.5 ! root 3640: @code{addr_diff_vec} insn patterns, the length is computed as ! 3641: the number of vectors multiplied by the size of each vector. ! 3642: ! 3643: Lengths are measured in addressable storage units (bytes). 1.1 root 3644: 3645: The following macros can be used to refine the length computation: 3646: 3647: @table @code 3648: @findex FIRST_INSN_ADDRESS 3649: @item FIRST_INSN_ADDRESS 3650: When the @code{length} insn attribute is used, this macro specifies the 3651: value to be assigned to the address of the first insn in a function. If 3652: not specified, 0 is used. 3653: 3654: @findex ADJUST_INSN_LENGTH 3655: @item ADJUST_INSN_LENGTH (@var{insn}, @var{length}) 3656: If defined, modifies the length assigned to instruction @var{insn} as a 3657: function of the context in which it is used. @var{length} is an lvalue 3658: that contains the initially computed length of the insn and should be 3659: updated with the correct length of the insn. If updating is required, 3660: @var{insn} must not be a varying-length insn. 3661: 3662: This macro will normally not be required. A case in which it is 3663: required is the ROMP. On this machine, the size of an @code{addr_vec} 3664: insn must be increased by two to compensate for the fact that alignment 3665: may be required. 3666: @end table 3667: 1.1.1.2 root 3668: @findex get_attr_length 1.1.1.5 ! root 3669: The routine that returns @code{get_attr_length} (the value of the ! 3670: @code{length} attribute) can be used by the output routine to ! 3671: determine the form of the branch instruction to be written, as the ! 3672: example below illustrates. 1.1 root 3673: 3674: As an example of the specification of variable-length branches, consider 3675: the IBM 360. If we adopt the convention that a register will be set to 1.1.1.5 ! root 3676: the starting address of a function, we can jump to labels within 4k of 1.1 root 3677: the start using a four-byte instruction. Otherwise, we need a six-byte 3678: sequence to load the address from memory and then branch to it. 3679: 3680: On such a machine, a pattern for a branch instruction might be specified 3681: as follows: 3682: 1.1.1.5 ! root 3683: @smallexample 1.1 root 3684: (define_insn "jump" 3685: [(set (pc) 3686: (label_ref (match_operand 0 "" "")))] 3687: "" 3688: "* 3689: @{ 3690: return (get_attr_length (insn) == 4 3691: ? \"b %l0\" : \"l r15,=a(%l0); br r15\"); 3692: @}" 3693: [(set (attr "length") (if_then_else (lt (match_dup 0) (const_int 4096)) 3694: (const_int 4) 3695: (const_int 6)))]) 1.1.1.5 ! root 3696: @end smallexample 1.1 root 3697: 1.1.1.5 ! root 3698: @node Constant Attributes 1.1.1.2 root 3699: @subsection Constant Attributes 3700: @cindex constant attributes 3701: 1.1.1.3 root 3702: A special form of @code{define_attr}, where the expression for the 3703: default value is a @code{const} expression, indicates an attribute that 3704: is constant for a given run of the compiler. Constant attributes may be 3705: used to specify which variety of processor is used. For example, 1.1.1.2 root 3706: 1.1.1.5 ! root 3707: @smallexample 1.1.1.2 root 3708: (define_attr "cpu" "m88100,m88110,m88000" 3709: (const 3710: (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 1.1.1.4 root 3711: (symbol_ref "TARGET_88110") (const_string "m88110")] 3712: (const_string "m88000")))) 1.1.1.2 root 3713: 3714: (define_attr "memory" "fast,slow" 3715: (const 3716: (if_then_else (symbol_ref "TARGET_FAST_MEM") 1.1.1.4 root 3717: (const_string "fast") 3718: (const_string "slow")))) 1.1.1.5 ! root 3719: @end smallexample 1.1.1.2 root 3720: 3721: The routine generated for constant attributes has no parameters as it 1.1.1.3 root 3722: does not depend on any particular insn. RTL expressions used to define 3723: the value of a constant attribute may use the @code{symbol_ref} form, 3724: but may not use either the @code{match_operand} form or @code{eq_attr} 3725: forms involving insn attributes. 1.1.1.2 root 3726: 1.1.1.5 ! root 3727: @node Delay Slots 1.1 root 3728: @subsection Delay Slot Scheduling 3729: @cindex delay slots, defining 3730: 3731: The insn attribute mechanism can be used to specify the requirements for 3732: delay slots, if any, on a target machine. An instruction is said to 3733: require a @dfn{delay slot} if some instructions that are physically 3734: after the instruction are executed as if they were located before it. 3735: Classic examples are branch and call instructions, which often execute 3736: the following instruction before the branch or call is performed. 3737: 3738: On some machines, conditional branch instructions can optionally 3739: @dfn{annul} instructions in the delay slot. This means that the 3740: instruction will not be executed for certain branch outcomes. Both 3741: instructions that annul if the branch is true and instructions that 3742: annul if the branch is false are supported. 3743: 3744: Delay slot scheduling differs from instruction scheduling in that 3745: determining whether an instruction needs a delay slot is dependent only 3746: on the type of instruction being generated, not on data flow between the 3747: instructions. See the next section for a discussion of data-dependent 3748: instruction scheduling. 3749: 3750: @findex define_delay 3751: The requirement of an insn needing one or more delay slots is indicated 3752: via the @code{define_delay} expression. It has the following form: 3753: 1.1.1.5 ! root 3754: @smallexample 1.1 root 3755: (define_delay @var{test} 3756: [@var{delay-1} @var{annul-true-1} @var{annul-false-1} 3757: @var{delay-2} @var{annul-true-2} @var{annul-false-2} 3758: @dots{}]) 1.1.1.5 ! root 3759: @end smallexample 1.1 root 3760: 3761: @var{test} is an attribute test that indicates whether this 3762: @code{define_delay} applies to a particular insn. If so, the number of 3763: required delay slots is determined by the length of the vector specified 3764: as the second argument. An insn placed in delay slot @var{n} must 3765: satisfy attribute test @var{delay-n}. @var{annul-true-n} is an 3766: attribute test that specifies which insns may be annulled if the branch 3767: is true. Similarly, @var{annul-false-n} specifies which insns in the 3768: delay slot may be annulled if the branch is false. If annulling is not 3769: supported for that delay slot, @code{(nil)} should be coded.@refill 3770: 3771: For example, in the common case where branch and call insns require 3772: a single delay slot, which may contain any insn other than a branch or 3773: call, the following would be placed in the @file{md} file: 3774: 1.1.1.5 ! root 3775: @smallexample 1.1 root 3776: (define_delay (eq_attr "type" "branch,call") 3777: [(eq_attr "type" "!branch,call") (nil) (nil)]) 1.1.1.5 ! root 3778: @end smallexample 1.1 root 3779: 3780: Multiple @code{define_delay} expressions may be specified. In this 3781: case, each such expression specifies different delay slot requirements 3782: and there must be no insn for which tests in two @code{define_delay} 3783: expressions are both true. 3784: 3785: For example, if we have a machine that requires one delay slot for branches 3786: but two for calls, no delay slot can contain a branch or call insn, 3787: and any valid insn in the delay slot for the branch can be annulled if the 3788: branch is true, we might represent this as follows: 3789: 1.1.1.5 ! root 3790: @smallexample 1.1 root 3791: (define_delay (eq_attr "type" "branch") 1.1.1.5 ! root 3792: [(eq_attr "type" "!branch,call") ! 3793: (eq_attr "type" "!branch,call") ! 3794: (nil)]) 1.1 root 3795: 3796: (define_delay (eq_attr "type" "call") 3797: [(eq_attr "type" "!branch,call") (nil) (nil) 3798: (eq_attr "type" "!branch,call") (nil) (nil)]) 1.1.1.5 ! root 3799: @end smallexample ! 3800: @c the above is *still* too long. --mew 4feb93 1.1 root 3801: 1.1.1.5 ! root 3802: @node Function Units 1.1 root 3803: @subsection Specifying Function Units 3804: @cindex function units, for scheduling 3805: 3806: On most RISC machines, there are instructions whose results are not 3807: available for a specific number of cycles. Common cases are instructions 3808: that load data from memory. On many machines, a pipeline stall will result 3809: if the data is referenced too soon after the load instruction. 3810: 3811: In addition, many newer microprocessors have multiple function units, usually 3812: one for integer and one for floating point, and often will incur pipeline 3813: stalls when a result that is needed is not yet ready. 3814: 3815: The descriptions in this section allow the specification of how much 3816: time must elapse between the execution of an instruction and the time 3817: when its result is used. It also allows specification of when the 3818: execution of an instruction will delay execution of similar instructions 3819: due to function unit conflicts. 3820: 3821: For the purposes of the specifications in this section, a machine is 3822: divided into @dfn{function units}, each of which execute a specific 1.1.1.4 root 3823: class of instructions in first-in-first-out order. Function units that 3824: accept one instruction each cycle and allow a result to be used in the 3825: succeeding instruction (usually via forwarding) need not be specified. 3826: Classic RISC microprocessors will normally have a single function unit, 3827: which we can call @samp{memory}. The newer ``superscalar'' processors 3828: will often have function units for floating point operations, usually at 3829: least a floating point adder and multiplier. 1.1 root 3830: 3831: @findex define_function_unit 3832: Each usage of a function units by a class of insns is specified with a 3833: @code{define_function_unit} expression, which looks like this: 3834: 1.1.1.5 ! root 3835: @smallexample 1.1 root 3836: (define_function_unit @var{name} @var{multiplicity} @var{simultaneity} 1.1.1.4 root 3837: @var{test} @var{ready-delay} @var{issue-delay} 3838: [@var{conflict-list}]) 1.1.1.5 ! root 3839: @end smallexample 1.1 root 3840: 3841: @var{name} is a string giving the name of the function unit. 3842: 3843: @var{multiplicity} is an integer specifying the number of identical 3844: units in the processor. If more than one unit is specified, they will 3845: be scheduled independently. Only truly independent units should be 3846: counted; a pipelined unit should be specified as a single unit. (The 3847: only common example of a machine that has multiple function units for a 3848: single instruction class that are truly independent and not pipelined 3849: are the two multiply and two increment units of the CDC 6600.) 3850: 3851: @var{simultaneity} specifies the maximum number of insns that can be 3852: executing in each instance of the function unit simultaneously or zero 3853: if the unit is pipelined and has no limit. 3854: 3855: All @code{define_function_unit} definitions referring to function unit 3856: @var{name} must have the same name and values for @var{multiplicity} and 3857: @var{simultaneity}. 3858: 3859: @var{test} is an attribute test that selects the insns we are describing 3860: in this definition. Note that an insn may use more than one function 3861: unit and a function unit may be specified in more than one 3862: @code{define_function_unit}. 3863: 3864: @var{ready-delay} is an integer that specifies the number of cycles 3865: after which the result of the instruction can be used without 3866: introducing any stalls. 3867: 1.1.1.4 root 3868: @var{issue-delay} is an integer that specifies the number of cycles 3869: after the instruction matching the @var{test} expression begins using 3870: this unit until a subsequent instruction can begin. A cost of @var{N} 3871: indicates an @var{N-1} cycle delay. A subsequent instruction may also 3872: be delayed if an earlier instruction has a longer @var{ready-delay} 3873: value. This blocking effect is computed using the @var{simultaneity}, 3874: @var{ready-delay}, @var{issue-delay}, and @var{conflict-list} terms. 3875: For a normal non-pipelined function unit, @var{simultaneity} is one, the 3876: unit is taken to block for the @var{ready-delay} cycles of the executing 3877: insn, and smaller values of @var{issue-delay} are ignored. 1.1 root 3878: 3879: @var{conflict-list} is an optional list giving detailed conflict costs 3880: for this unit. If specified, it is a list of condition test expressions 1.1.1.4 root 3881: to be applied to insns chosen to execute in @var{name} following the 3882: particular insn matching @var{test} that is already executing in 3883: @var{name}. For each insn in the list, @var{issue-delay} specifies the 3884: conflict cost; for insns not in the list, the cost is zero. If not 3885: specified, @var{conflict-list} defaults to all instructions that use the 3886: function unit. 1.1 root 3887: 3888: Typical uses of this vector are where a floating point function unit can 3889: pipeline either single- or double-precision operations, but not both, or 3890: where a memory unit can pipeline loads, but not stores, etc. 3891: 3892: As an example, consider a classic RISC machine where the result of a 3893: load instruction is not available for two cycles (a single ``delay'' 3894: instruction is required) and where only one load instruction can be executed 3895: simultaneously. This would be specified as: 3896: 1.1.1.5 ! root 3897: @smallexample 1.1.1.4 root 3898: (define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 0) 1.1.1.5 ! root 3899: @end smallexample 1.1 root 3900: 3901: For the case of a floating point function unit that can pipeline either 3902: single or double precision, but not both, the following could be specified: 3903: 1.1.1.5 ! root 3904: @smallexample 1.1 root 3905: (define_function_unit 1.1.1.4 root 3906: "fp" 1 0 (eq_attr "type" "sp_fp") 4 4 [(eq_attr "type" "dp_fp")]) 1.1 root 3907: (define_function_unit 1.1.1.4 root 3908: "fp" 1 0 (eq_attr "type" "dp_fp") 4 4 [(eq_attr "type" "sp_fp")]) 1.1.1.5 ! root 3909: @end smallexample 1.1 root 3910: 1.1.1.4 root 3911: @strong{Note:} The scheduler attempts to avoid function unit conflicts 3912: and uses all the specifications in the @code{define_function_unit} 3913: expression. It has recently come to our attention that these 3914: specifications may not allow modeling of some of the newer 3915: ``superscalar'' processors that have insns using multiple pipelined 3916: units. These insns will cause a potential conflict for the second unit 3917: used during their execution and there is no way of representing that 3918: conflict. We welcome any examples of how function unit conflicts work 3919: in such processors and suggestions for their representation. 1.1 root 3920: @end ifset
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.