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