![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-18 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-18 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.7 ! root 1: This is Info file gcc.info, produced by Makeinfo version 1.67 from the ! 2: input file gcc.texi. 1.1 root 3: 4: This file documents the use and the internals of the GNU compiler. 5: 1.1.1.6 root 6: Published by the Free Software Foundation 59 Temple Place - Suite 330 7: Boston, MA 02111-1307 USA 1.1.1.3 root 8: 1.1.1.6 root 9: Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 Free Software 10: Foundation, Inc. 1.1 root 11: 12: Permission is granted to make and distribute verbatim copies of this 13: manual provided the copyright notice and this permission notice are 14: preserved on all copies. 15: 16: Permission is granted to copy and distribute modified versions of 17: this manual under the conditions for verbatim copying, provided also 1.1.1.5 root 18: that the sections entitled "GNU General Public License," "Funding for 19: Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are 20: included exactly as in the original, and provided that the entire 21: resulting derived work is distributed under the terms of a permission 22: notice identical to this one. 1.1 root 23: 24: Permission is granted to copy and distribute translations of this 25: manual into another language, under the above conditions for modified 26: versions, except that the sections entitled "GNU General Public 1.1.1.5 root 27: License," "Funding for Free Software," and "Protect Your Freedom--Fight 28: `Look And Feel'", and this permission notice, may be included in 29: translations approved by the Free Software Foundation instead of in the 30: original English. 1.1 root 31: 32: 1.1.1.6 root 33: File: gcc.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Peephole Definitions, Up: Machine Desc 1.1 root 34: 1.1.1.6 root 35: Defining RTL Sequences for Code Generation 36: ========================================== 1.1.1.2 root 37: 1.1.1.6 root 38: On some target machines, some standard pattern names for RTL 39: generation cannot be handled with single insn, but a sequence of RTL 40: insns can represent them. For these target machines, you can write a 41: `define_expand' to specify how to generate the sequence of RTL. 42: 43: A `define_expand' is an RTL expression that looks almost like a 44: `define_insn'; but, unlike the latter, a `define_expand' is used only 45: for RTL generation and it can produce more than one RTL insn. 46: 47: A `define_expand' RTX has four operands: 48: 49: * The name. Each `define_expand' must have a name, since the only 50: use for it is to refer to it by name. 51: 52: * The RTL template. This is just like the RTL template for a 53: `define_peephole' in that it is a vector of RTL expressions each 54: being one insn. 55: 56: * The condition, a string containing a C expression. This 57: expression is used to express how the availability of this pattern 58: depends on subclasses of target machine, selected by command-line 59: options when GNU CC is run. This is just like the condition of a 60: `define_insn' that has a standard name. Therefore, the condition 61: (if present) may not depend on the data in the insn being matched, 62: but only the target-machine-type flags. The compiler needs to 63: test these conditions during initialization in order to learn 64: exactly which named instructions are available in a particular run. 65: 66: * The preparation statements, a string containing zero or more C 67: statements which are to be executed before RTL code is generated 68: from the RTL template. 69: 70: Usually these statements prepare temporary registers for use as 71: internal operands in the RTL template, but they can also generate 72: RTL insns directly by calling routines such as `emit_insn', etc. 73: Any such insns precede the ones that come from the RTL template. 74: 75: Every RTL insn emitted by a `define_expand' must match some 76: `define_insn' in the machine description. Otherwise, the compiler will 77: crash when trying to generate code for the insn or trying to optimize 78: it. 79: 80: The RTL template, in addition to controlling generation of RTL insns, 81: also describes the operands that need to be specified when this pattern 82: is used. In particular, it gives a predicate for each operand. 83: 84: A true operand, which needs to be specified in order to generate RTL 85: from the pattern, should be described with a `match_operand' in its 86: first occurrence in the RTL template. This enters information on the 87: operand's predicate into the tables that record such things. GNU CC 88: uses the information to preload the operand into a register if that is 89: required for valid RTL code. If the operand is referred to more than 90: once, subsequent references should use `match_dup'. 91: 92: The RTL template may also refer to internal "operands" which are 93: temporary registers or labels used only within the sequence made by the 94: `define_expand'. Internal operands are substituted into the RTL 95: template with `match_dup', never with `match_operand'. The values of 96: the internal operands are not passed in as arguments by the compiler 97: when it requests use of this pattern. Instead, they are computed 98: within the pattern, in the preparation statements. These statements 99: compute the values and store them into the appropriate elements of 100: `operands' so that `match_dup' can find them. 101: 102: There are two special macros defined for use in the preparation 103: statements: `DONE' and `FAIL'. Use them with a following semicolon, as 104: a statement. 105: 106: `DONE' 107: Use the `DONE' macro to end RTL generation for the pattern. The 108: only RTL insns resulting from the pattern on this occasion will be 109: those already emitted by explicit calls to `emit_insn' within the 110: preparation statements; the RTL template will not be generated. 111: 112: `FAIL' 113: Make the pattern fail on this occasion. When a pattern fails, it 114: means that the pattern was not truly available. The calling 115: routines in the compiler will try other strategies for code 116: generation using other patterns. 117: 118: Failure is currently supported only for binary (addition, 119: multiplication, shifting, etc.) and bitfield (`extv', `extzv', and 120: `insv') operations. 121: 122: Here is an example, the definition of left-shift for the SPUR chip: 123: 124: (define_expand "ashlsi3" 125: [(set (match_operand:SI 0 "register_operand" "") 126: (ashift:SI 127: 128: (match_operand:SI 1 "register_operand" "") 129: (match_operand:SI 2 "nonmemory_operand" "")))] 130: "" 131: " 132: 133: { 134: if (GET_CODE (operands[2]) != CONST_INT 135: || (unsigned) INTVAL (operands[2]) > 3) 136: FAIL; 137: }") 138: 139: This example uses `define_expand' so that it can generate an RTL insn 140: for shifting when the shift-count is in the supported range of 0 to 3 141: but fail in other cases where machine insns aren't available. When it 142: fails, the compiler tries another strategy using different patterns 143: (such as, a library call). 144: 145: If the compiler were able to handle nontrivial condition-strings in 146: patterns with names, then it would be possible to use a `define_insn' 147: in that case. Here is another case (zero-extension on the 68000) which 148: makes more use of the power of `define_expand': 149: 150: (define_expand "zero_extendhisi2" 151: [(set (match_operand:SI 0 "general_operand" "") 152: (const_int 0)) 153: (set (strict_low_part 154: (subreg:HI 155: (match_dup 0) 156: 0)) 157: (match_operand:HI 1 "general_operand" ""))] 158: "" 159: "operands[1] = make_safe_from (operands[1], operands[0]);") 160: 161: Here two RTL insns are generated, one to clear the entire output operand 162: and the other to copy the input operand into its low half. This 163: sequence is incorrect if the input operand refers to [the old value of] 164: the output operand, so the preparation statement makes sure this isn't 165: so. The function `make_safe_from' copies the `operands[1]' into a 166: temporary register if it refers to `operands[0]'. It does this by 167: emitting another RTL insn. 168: 169: Finally, a third example shows the use of an internal operand. 170: Zero-extension on the SPUR chip is done by `and'-ing the result against 171: a halfword mask. But this mask cannot be represented by a `const_int' 172: because the constant value is too large to be legitimate on this 173: machine. So it must be copied into a register with `force_reg' and 174: then the register used in the `and'. 175: 176: (define_expand "zero_extendhisi2" 177: [(set (match_operand:SI 0 "register_operand" "") 178: (and:SI (subreg:SI 179: (match_operand:HI 1 "register_operand" "") 180: 0) 181: (match_dup 2)))] 182: "" 183: "operands[2] 184: = force_reg (SImode, gen_rtx (CONST_INT, 185: VOIDmode, 65535)); ") 186: 187: *Note:* If the `define_expand' is used to serve a standard binary or 188: unary arithmetic operation or a bitfield operation, then the last insn 189: it generates must not be a `code_label', `barrier' or `note'. It must 190: be an `insn', `jump_insn' or `call_insn'. If you don't need a real insn 191: at the end, emit an insn to copy the result of the operation into 192: itself. Such an insn will generate no code, but it can avoid problems 193: in the compiler. 1.1.1.3 root 194: 1.1.1.6 root 195: 196: File: gcc.info, Node: Insn Splitting, Next: Insn Attributes, Prev: Expander Definitions, Up: Machine Desc 1.1.1.5 root 197: 1.1.1.6 root 198: Defining How to Split Instructions 199: ================================== 1.1.1.5 root 200: 1.1.1.6 root 201: There are two cases where you should specify how to split a pattern 202: into multiple insns. On machines that have instructions requiring delay 203: slots (*note Delay Slots::.) or that have instructions whose output is 204: not available for multiple cycles (*note Function Units::.), the 205: compiler phases that optimize these cases need to be able to move insns 206: into one-instruction delay slots. However, some insns may generate 207: more than one machine instruction. These insns cannot be placed into a 208: delay slot. 209: 210: Often you can rewrite the single insn as a list of individual insns, 211: each corresponding to one machine instruction. The disadvantage of 212: doing so is that it will cause the compilation to be slower and require 213: more space. If the resulting insns are too complex, it may also 214: suppress some optimizations. The compiler splits the insn if there is a 215: reason to believe that it might improve instruction or delay slot 216: scheduling. 217: 218: The insn combiner phase also splits putative insns. If three insns 219: are merged into one insn with a complex expression that cannot be 220: matched by some `define_insn' pattern, the combiner phase attempts to 221: split the complex pattern into two insns that are recognized. Usually 222: it can break the complex pattern into two patterns by splitting out some 223: subexpression. However, in some other cases, such as performing an 224: addition of a large constant in two insns on a RISC machine, the way to 225: split the addition into two insns is machine-dependent. 226: 227: The `define_split' definition tells the compiler how to split a 228: complex insn into several simpler insns. It looks like this: 229: 230: (define_split 231: [INSN-PATTERN] 232: "CONDITION" 233: [NEW-INSN-PATTERN-1 234: NEW-INSN-PATTERN-2 235: ...] 236: "PREPARATION STATEMENTS") 237: 238: INSN-PATTERN is a pattern that needs to be split and CONDITION is 239: the final condition to be tested, as in a `define_insn'. When an insn 240: matching INSN-PATTERN and satisfying CONDITION is found, it is replaced 241: in the insn list with the insns given by NEW-INSN-PATTERN-1, 242: NEW-INSN-PATTERN-2, etc. 243: 244: The PREPARATION STATEMENTS are similar to those statements that are 245: specified for `define_expand' (*note Expander Definitions::.) and are 246: executed before the new RTL is generated to prepare for the generated 247: code or emit some insns whose pattern is not fixed. Unlike those in 248: `define_expand', however, these statements must not generate any new 249: pseudo-registers. Once reload has completed, they also must not 250: allocate any space in the stack frame. 251: 252: Patterns are matched against INSN-PATTERN in two different 253: circumstances. If an insn needs to be split for delay slot scheduling 254: or insn scheduling, the insn is already known to be valid, which means 255: that it must have been matched by some `define_insn' and, if 256: `reload_completed' is non-zero, is known to satisfy the constraints of 257: that `define_insn'. In that case, the new insn patterns must also be 258: insns that are matched by some `define_insn' and, if `reload_completed' 259: is non-zero, must also satisfy the constraints of those definitions. 260: 261: As an example of this usage of `define_split', consider the following 262: example from `a29k.md', which splits a `sign_extend' from `HImode' to 263: `SImode' into a pair of shift insns: 264: 265: (define_split 266: [(set (match_operand:SI 0 "gen_reg_operand" "") 267: (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 268: "" 269: [(set (match_dup 0) 270: (ashift:SI (match_dup 1) 271: (const_int 16))) 272: (set (match_dup 0) 273: (ashiftrt:SI (match_dup 0) 274: (const_int 16)))] 275: " 276: { operands[1] = gen_lowpart (SImode, operands[1]); }") 277: 278: When the combiner phase tries to split an insn pattern, it is always 279: the case that the pattern is *not* matched by any `define_insn'. The 280: combiner pass first tries to split a single `set' expression and then 281: the same `set' expression inside a `parallel', but followed by a 282: `clobber' of a pseudo-reg to use as a scratch register. In these 283: cases, the combiner expects exactly two new insn patterns to be 284: generated. It will verify that these patterns match some `define_insn' 285: definitions, so you need not do this test in the `define_split' (of 286: course, there is no point in writing a `define_split' that will never 287: produce insns that match). 288: 289: Here is an example of this use of `define_split', taken from 290: `rs6000.md': 291: 292: (define_split 293: [(set (match_operand:SI 0 "gen_reg_operand" "") 294: (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 295: (match_operand:SI 2 "non_add_cint_operand" "")))] 296: "" 297: [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 298: (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 299: " 300: { 301: int low = INTVAL (operands[2]) & 0xffff; 302: int high = (unsigned) INTVAL (operands[2]) >> 16; 303: 304: if (low & 0x8000) 305: high++, low |= 0xffff0000; 306: 307: operands[3] = gen_rtx (CONST_INT, VOIDmode, high << 16); 308: operands[4] = gen_rtx (CONST_INT, VOIDmode, low); 309: }") 310: 311: Here the predicate `non_add_cint_operand' matches any `const_int' 312: that is *not* a valid operand of a single add insn. The add with the 313: smaller displacement is written so that it can be substituted into the 314: address of a subsequent operation. 315: 316: An example that uses a scratch register, from the same file, 317: generates an equality comparison of a register and a large constant: 318: 319: (define_split 320: [(set (match_operand:CC 0 "cc_reg_operand" "") 321: (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 322: (match_operand:SI 2 "non_short_cint_operand" ""))) 323: (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 324: "find_single_use (operands[0], insn, 0) 325: && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 326: || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 327: [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 328: (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 329: " 330: { 331: /* Get the constant we are comparing against, C, and see what it 332: looks like sign-extended to 16 bits. Then see what constant 333: could be XOR'ed with C to get the sign-extended value. */ 334: 335: int c = INTVAL (operands[2]); 336: int sextc = (c << 16) >> 16; 337: int xorv = c ^ sextc; 338: 339: operands[4] = gen_rtx (CONST_INT, VOIDmode, xorv); 340: operands[5] = gen_rtx (CONST_INT, VOIDmode, sextc); 341: }") 342: 343: To avoid confusion, don't write a single `define_split' that accepts 344: some insns that match some `define_insn' as well as some insns that 345: don't. Instead, write two separate `define_split' definitions, one for 346: the insns that are valid and one for the insns that are not valid. 1.1.1.5 root 347: 1.1.1.6 root 348: 349: File: gcc.info, Node: Insn Attributes, Prev: Insn Splitting, Up: Machine Desc 1.1.1.5 root 350: 1.1.1.6 root 351: Instruction Attributes 352: ====================== 1.1.1.5 root 353: 1.1.1.6 root 354: In addition to describing the instruction supported by the target 355: machine, the `md' file also defines a group of "attributes" and a set of 356: values for each. Every generated insn is assigned a value for each 357: attribute. One possible attribute would be the effect that the insn 358: has on the machine's condition code. This attribute can then be used 359: by `NOTICE_UPDATE_CC' to track the condition codes. 1.1.1.5 root 360: 1.1.1.6 root 361: * Menu: 1.1.1.5 root 362: 1.1.1.6 root 363: * Defining Attributes:: Specifying attributes and their values. 364: * Expressions:: Valid expressions for attribute values. 365: * Tagging Insns:: Assigning attribute values to insns. 366: * Attr Example:: An example of assigning attributes. 367: * Insn Lengths:: Computing the length of insns. 368: * Constant Attributes:: Defining attributes that are constant. 369: * Delay Slots:: Defining delay slots required for a machine. 370: * Function Units:: Specifying information for insn scheduling. 1.1.1.5 root 371: 1.1.1.6 root 372: 373: File: gcc.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes 1.1.1.5 root 374: 1.1.1.6 root 375: Defining Attributes and their Values 376: ------------------------------------ 1.1.1.5 root 377: 1.1.1.6 root 378: The `define_attr' expression is used to define each attribute 379: required by the target machine. It looks like: 1.1.1.5 root 380: 1.1.1.6 root 381: (define_attr NAME LIST-OF-VALUES DEFAULT) 1.1.1.5 root 382: 1.1.1.6 root 383: NAME is a string specifying the name of the attribute being defined. 1.1.1.5 root 384: 1.1.1.6 root 385: LIST-OF-VALUES is either a string that specifies a comma-separated 386: list of values that can be assigned to the attribute, or a null string 387: to indicate that the attribute takes numeric values. 1.1.1.5 root 388: 1.1.1.6 root 389: DEFAULT is an attribute expression that gives the value of this 390: attribute for insns that match patterns whose definition does not 391: include an explicit value for this attribute. *Note Attr Example::, 392: for more information on the handling of defaults. *Note Constant 393: Attributes::, for information on attributes that do not depend on any 394: particular insn. 1.1.1.5 root 395: 1.1.1.6 root 396: For each defined attribute, a number of definitions are written to 397: the `insn-attr.h' file. For cases where an explicit set of values is 398: specified for an attribute, the following are defined: 1.1.1.5 root 399: 1.1.1.6 root 400: * A `#define' is written for the symbol `HAVE_ATTR_NAME'. 1.1.1.5 root 401: 1.1.1.6 root 402: * An enumeral class is defined for `attr_NAME' with elements of the 403: form `UPPER-NAME_UPPER-VALUE' where the attribute name and value 404: are first converted to upper case. 1.1.1.5 root 405: 1.1.1.6 root 406: * A function `get_attr_NAME' is defined that is passed an insn and 407: returns the attribute value for that insn. 1.1.1.5 root 408: 1.1.1.6 root 409: For example, if the following is present in the `md' file: 1.1.1.5 root 410: 1.1.1.6 root 411: (define_attr "type" "branch,fp,load,store,arith" ...) 1.1.1.5 root 412: 1.1.1.6 root 413: the following lines will be written to the file `insn-attr.h'. 1.1.1.5 root 414: 1.1.1.6 root 415: #define HAVE_ATTR_type 416: enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 417: TYPE_STORE, TYPE_ARITH}; 418: extern enum attr_type get_attr_type (); 1.1.1.5 root 419: 1.1.1.6 root 420: If the attribute takes numeric values, no `enum' type will be 421: defined and the function to obtain the attribute's value will return 422: `int'. 1.1.1.5 root 423: 424: 1.1.1.6 root 425: File: gcc.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes 1.1.1.2 root 426: 1.1.1.6 root 427: Attribute Expressions 428: --------------------- 1.1.1.2 root 429: 1.1.1.6 root 430: RTL expressions used to define attributes use the codes described 431: above plus a few specific to attribute definitions, to be discussed 432: below. Attribute value expressions must have one of the following 433: forms: 434: 435: `(const_int I)' 436: The integer I specifies the value of a numeric attribute. I must 437: be non-negative. 438: 439: The value of a numeric attribute can be specified either with a 440: `const_int' or as an integer represented as a string in 441: `const_string', `eq_attr' (see below), and `set_attr' (*note 442: Tagging Insns::.) expressions. 443: 444: `(const_string VALUE)' 445: The string VALUE specifies a constant attribute value. If VALUE 446: is specified as `"*"', it means that the default value of the 447: attribute is to be used for the insn containing this expression. 448: `"*"' obviously cannot be used in the DEFAULT expression of a 449: `define_attr'. 450: 451: If the attribute whose value is being specified is numeric, VALUE 452: must be a string containing a non-negative integer (normally 453: `const_int' would be used in this case). Otherwise, it must 454: contain one of the valid values for the attribute. 455: 456: `(if_then_else TEST TRUE-VALUE FALSE-VALUE)' 457: TEST specifies an attribute test, whose format is defined below. 458: The value of this expression is TRUE-VALUE if TEST is true, 459: otherwise it is FALSE-VALUE. 460: 461: `(cond [TEST1 VALUE1 ...] DEFAULT)' 462: The first operand of this expression is a vector containing an even 463: number of expressions and consisting of pairs of TEST and VALUE 464: expressions. The value of the `cond' expression is that of the 465: VALUE corresponding to the first true TEST expression. If none of 466: the TEST expressions are true, the value of the `cond' expression 467: is that of the DEFAULT expression. 468: 469: TEST expressions can have one of the following forms: 470: 471: `(const_int I)' 472: This test is true if I is non-zero and false otherwise. 473: 474: `(not TEST)' 475: `(ior TEST1 TEST2)' 476: `(and TEST1 TEST2)' 477: These tests are true if the indicated logical function is true. 478: 479: `(match_operand:M N PRED CONSTRAINTS)' 480: This test is true if operand N of the insn whose attribute value 481: is being determined has mode M (this part of the test is ignored 482: if M is `VOIDmode') and the function specified by the string PRED 483: returns a non-zero value when passed operand N and mode M (this 484: part of the test is ignored if PRED is the null string). 485: 486: The CONSTRAINTS operand is ignored and should be the null string. 487: 488: `(le ARITH1 ARITH2)' 489: `(leu ARITH1 ARITH2)' 490: `(lt ARITH1 ARITH2)' 491: `(ltu ARITH1 ARITH2)' 492: `(gt ARITH1 ARITH2)' 493: `(gtu ARITH1 ARITH2)' 494: `(ge ARITH1 ARITH2)' 495: `(geu ARITH1 ARITH2)' 496: `(ne ARITH1 ARITH2)' 497: `(eq ARITH1 ARITH2)' 498: These tests are true if the indicated comparison of the two 499: arithmetic expressions is true. Arithmetic expressions are formed 500: with `plus', `minus', `mult', `div', `mod', `abs', `neg', `and', 501: `ior', `xor', `not', `ashift', `lshiftrt', and `ashiftrt' 502: expressions. 503: 504: `const_int' and `symbol_ref' are always valid terms (*note Insn 505: Lengths::.,for additional forms). `symbol_ref' is a string 506: denoting a C expression that yields an `int' when evaluated by the 507: `get_attr_...' routine. It should normally be a global variable. 508: 509: `(eq_attr NAME VALUE)' 510: NAME is a string specifying the name of an attribute. 511: 512: VALUE is a string that is either a valid value for attribute NAME, 513: a comma-separated list of values, or `!' followed by a value or 514: list. If VALUE does not begin with a `!', this test is true if 515: the value of the NAME attribute of the current insn is in the list 516: specified by VALUE. If VALUE begins with a `!', this test is true 517: if the attribute's value is *not* in the specified list. 518: 519: For example, 520: 521: (eq_attr "type" "load,store") 522: 523: is equivalent to 524: 525: (ior (eq_attr "type" "load") (eq_attr "type" "store")) 526: 527: If NAME specifies an attribute of `alternative', it refers to the 528: value of the compiler variable `which_alternative' (*note Output 529: Statement::.) and the values must be small integers. For example, 530: 531: (eq_attr "alternative" "2,3") 532: 533: is equivalent to 534: 535: (ior (eq (symbol_ref "which_alternative") (const_int 2)) 536: (eq (symbol_ref "which_alternative") (const_int 3))) 537: 538: Note that, for most attributes, an `eq_attr' test is simplified in 539: cases where the value of the attribute being tested is known for 540: all insns matching a particular pattern. This is by far the most 541: common case. 542: 543: `(attr_flag NAME)' 544: The value of an `attr_flag' expression is true if the flag 545: specified by NAME is true for the `insn' currently being scheduled. 546: 547: NAME is a string specifying one of a fixed set of flags to test. 548: Test the flags `forward' and `backward' to determine the direction 549: of a conditional branch. Test the flags `very_likely', `likely', 550: `very_unlikely', and `unlikely' to determine if a conditional 551: branch is expected to be taken. 552: 553: If the `very_likely' flag is true, then the `likely' flag is also 554: true. Likewise for the `very_unlikely' and `unlikely' flags. 555: 556: This example describes a conditional branch delay slot which can 557: be nullified for forward branches that are taken (annul-true) or 558: for backward branches which are not taken (annul-false). 559: 560: (define_delay (eq_attr "type" "cbranch") 561: [(eq_attr "in_branch_delay" "true") 562: (and (eq_attr "in_branch_delay" "true") 563: (attr_flag "forward")) 564: (and (eq_attr "in_branch_delay" "true") 565: (attr_flag "backward"))]) 566: 567: The `forward' and `backward' flags are false if the current `insn' 568: being scheduled is not a conditional branch. 569: 570: The `very_likely' and `likely' flags are true if the `insn' being 571: scheduled is not a conditional branch. The The `very_unlikely' 572: and `unlikely' flags are false if the `insn' being scheduled is 573: not a conditional branch. 1.1.1.2 root 574: 1.1.1.6 root 575: `attr_flag' is only used during delay slot scheduling and has no 576: meaning to other passes of the compiler. 1.1.1.2 root 577: 578: 1.1.1.6 root 579: File: gcc.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes 1.1.1.2 root 580: 1.1.1.6 root 581: Assigning Attribute Values to Insns 582: ----------------------------------- 1.1.1.2 root 583: 1.1.1.6 root 584: The value assigned to an attribute of an insn is primarily 585: determined by which pattern is matched by that insn (or which 586: `define_peephole' generated it). Every `define_insn' and 587: `define_peephole' can have an optional last argument to specify the 588: values of attributes for matching insns. The value of any attribute 589: not specified in a particular insn is set to the default value for that 590: attribute, as specified in its `define_attr'. Extensive use of default 591: values for attributes permits the specification of the values for only 592: one or two attributes in the definition of most insn patterns, as seen 593: in the example in the next section. 594: 595: The optional last argument of `define_insn' and `define_peephole' is 596: a vector of expressions, each of which defines the value for a single 597: attribute. The most general way of assigning an attribute's value is 598: to use a `set' expression whose first operand is an `attr' expression 599: giving the name of the attribute being set. The second operand of the 600: `set' is an attribute expression (*note Expressions::.) giving the 601: value of the attribute. 602: 603: When the attribute value depends on the `alternative' attribute 604: (i.e., which is the applicable alternative in the constraint of the 605: insn), the `set_attr_alternative' expression can be used. It allows 606: the specification of a vector of attribute expressions, one for each 607: alternative. 608: 609: When the generality of arbitrary attribute expressions is not 610: required, the simpler `set_attr' expression can be used, which allows 611: specifying a string giving either a single attribute value or a list of 612: attribute values, one for each alternative. 613: 614: The form of each of the above specifications is shown below. In 615: each case, NAME is a string specifying the attribute to be set. 616: 617: `(set_attr NAME VALUE-STRING)' 618: VALUE-STRING is either a string giving the desired attribute value, 619: or a string containing a comma-separated list giving the values for 620: succeeding alternatives. The number of elements must match the 621: number of alternatives in the constraint of the insn pattern. 622: 623: Note that it may be useful to specify `*' for some alternative, in 624: which case the attribute will assume its default value for insns 625: matching that alternative. 626: 627: `(set_attr_alternative NAME [VALUE1 VALUE2 ...])' 628: Depending on the alternative of the insn, the value will be one of 629: the specified values. This is a shorthand for using a `cond' with 630: tests on the `alternative' attribute. 631: 632: `(set (attr NAME) VALUE)' 633: The first operand of this `set' must be the special RTL expression 634: `attr', whose sole operand is a string giving the name of the 635: attribute being set. VALUE is the value of the attribute. 636: 637: The following shows three different ways of representing the same 638: attribute value specification: 639: 640: (set_attr "type" "load,store,arith") 641: 642: (set_attr_alternative "type" 643: [(const_string "load") (const_string "store") 644: (const_string "arith")]) 645: 646: (set (attr "type") 647: (cond [(eq_attr "alternative" "1") (const_string "load") 648: (eq_attr "alternative" "2") (const_string "store")] 649: (const_string "arith"))) 650: 651: The `define_asm_attributes' expression provides a mechanism to 652: specify the attributes assigned to insns produced from an `asm' 653: statement. It has the form: 654: 655: (define_asm_attributes [ATTR-SETS]) 656: 657: where ATTR-SETS is specified the same as for both the `define_insn' and 658: the `define_peephole' expressions. 659: 660: These values will typically be the "worst case" attribute values. 661: For example, they might indicate that the condition code will be 662: clobbered. 663: 664: A specification for a `length' attribute is handled specially. The 665: way to compute the length of an `asm' insn is to multiply the length 666: specified in the expression `define_asm_attributes' by the number of 667: machine instructions specified in the `asm' statement, determined by 668: counting the number of semicolons and newlines in the string. 669: Therefore, the value of the `length' attribute specified in a 670: `define_asm_attributes' should be the maximum possible length of a 671: single machine instruction. 1.1.1.2 root 672: 673: 1.1.1.6 root 674: File: gcc.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes 1.1.1.4 root 675: 1.1.1.6 root 676: Example of Attribute Specifications 677: ----------------------------------- 1.1.1.5 root 678: 1.1.1.6 root 679: The judicious use of defaulting is important in the efficient use of 680: insn attributes. Typically, insns are divided into "types" and an 681: attribute, customarily called `type', is used to represent this value. 682: This attribute is normally used only to define the default value for 683: other attributes. An example will clarify this usage. 684: 685: Assume we have a RISC machine with a condition code and in which only 686: full-word operations are performed in registers. Let us assume that we 687: can divide all insns into loads, stores, (integer) arithmetic 688: operations, floating point operations, and branches. 689: 690: Here we will concern ourselves with determining the effect of an 691: insn on the condition code and will limit ourselves to the following 692: possible effects: The condition code can be set unpredictably 693: (clobbered), not be changed, be set to agree with the results of the 694: operation, or only changed if the item previously set into the 695: condition code has been modified. 696: 697: Here is part of a sample `md' file for such a machine: 698: 699: (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 700: 701: (define_attr "cc" "clobber,unchanged,set,change0" 702: (cond [(eq_attr "type" "load") 703: (const_string "change0") 704: (eq_attr "type" "store,branch") 705: (const_string "unchanged") 706: (eq_attr "type" "arith") 707: (if_then_else (match_operand:SI 0 "" "") 708: (const_string "set") 709: (const_string "clobber"))] 710: (const_string "clobber"))) 711: 712: (define_insn "" 713: [(set (match_operand:SI 0 "general_operand" "=r,r,m") 714: (match_operand:SI 1 "general_operand" "r,m,r"))] 715: "" 716: "@ 717: move %0,%1 718: load %0,%1 719: store %0,%1" 720: [(set_attr "type" "arith,load,store")]) 721: 722: Note that we assume in the above example that arithmetic operations 723: performed on quantities smaller than a machine word clobber the 724: condition code since they will set the condition code to a value 725: corresponding to the full-word result. 1.1.1.2 root 726: 727: 1.1.1.6 root 728: File: gcc.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes 1.1.1.2 root 729: 1.1.1.6 root 730: Computing the Length of an Insn 731: ------------------------------- 1.1.1.3 root 732: 1.1.1.6 root 733: For many machines, multiple types of branch instructions are 734: provided, each for different length branch displacements. In most 735: cases, the assembler will choose the correct instruction to use. 736: However, when the assembler cannot do so, GCC can when a special 737: attribute, the `length' attribute, is defined. This attribute must be 738: defined to have numeric values by specifying a null string in its 739: `define_attr'. 740: 741: In the case of the `length' attribute, two additional forms of 742: arithmetic terms are allowed in test expressions: 743: 744: `(match_dup N)' 745: This refers to the address of operand N of the current insn, which 746: must be a `label_ref'. 747: 748: `(pc)' 749: This refers to the address of the *current* insn. It might have 750: been more consistent with other usage to make this the address of 751: the *next* insn but this would be confusing because the length of 752: the current insn is to be computed. 753: 754: For normal insns, the length will be determined by value of the 755: `length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn 756: patterns, the length is computed as the number of vectors multiplied by 757: the size of each vector. 758: 759: Lengths are measured in addressable storage units (bytes). 760: 761: The following macros can be used to refine the length computation: 762: 763: `FIRST_INSN_ADDRESS' 764: When the `length' insn attribute is used, this macro specifies the 765: value to be assigned to the address of the first insn in a 766: function. If not specified, 0 is used. 767: 768: `ADJUST_INSN_LENGTH (INSN, LENGTH)' 769: If defined, modifies the length assigned to instruction INSN as a 770: function of the context in which it is used. LENGTH is an lvalue 771: that contains the initially computed length of the insn and should 772: be updated with the correct length of the insn. If updating is 773: required, INSN must not be a varying-length insn. 774: 775: This macro will normally not be required. A case in which it is 776: required is the ROMP. On this machine, the size of an `addr_vec' 777: insn must be increased by two to compensate for the fact that 778: alignment may be required. 779: 780: The routine that returns `get_attr_length' (the value of the 781: `length' attribute) can be used by the output routine to determine the 782: form of the branch instruction to be written, as the example below 783: illustrates. 784: 785: As an example of the specification of variable-length branches, 786: consider the IBM 360. If we adopt the convention that a register will 787: be set to the starting address of a function, we can jump to labels 788: within 4k of the start using a four-byte instruction. Otherwise, we 789: need a six-byte sequence to load the address from memory and then 790: branch to it. 791: 792: On such a machine, a pattern for a branch instruction might be 793: specified as follows: 794: 795: (define_insn "jump" 796: [(set (pc) 797: (label_ref (match_operand 0 "" "")))] 798: "" 799: "* 800: { 801: return (get_attr_length (insn) == 4 802: ? \"b %l0\" : \"l r15,=a(%l0); br r15\"); 803: }" 804: [(set (attr "length") (if_then_else (lt (match_dup 0) (const_int 4096)) 805: (const_int 4) 806: (const_int 6)))]) 1.1.1.2 root 807: 808: 1.1.1.6 root 809: File: gcc.info, Node: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes 1.1.1.5 root 810: 1.1.1.6 root 811: Constant Attributes 812: ------------------- 1.1.1.5 root 813: 1.1.1.6 root 814: A special form of `define_attr', where the expression for the 815: default value is a `const' expression, indicates an attribute that is 816: constant for a given run of the compiler. Constant attributes may be 817: used to specify which variety of processor is used. For example, 818: 819: (define_attr "cpu" "m88100,m88110,m88000" 820: (const 821: (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 822: (symbol_ref "TARGET_88110") (const_string "m88110")] 823: (const_string "m88000")))) 824: 825: (define_attr "memory" "fast,slow" 826: (const 827: (if_then_else (symbol_ref "TARGET_FAST_MEM") 828: (const_string "fast") 829: (const_string "slow")))) 830: 831: The routine generated for constant attributes has no parameters as it 832: does not depend on any particular insn. RTL expressions used to define 833: the value of a constant attribute may use the `symbol_ref' form, but 834: may not use either the `match_operand' form or `eq_attr' forms 835: involving insn attributes. 1.1.1.2 root 836: 837: 1.1.1.6 root 838: File: gcc.info, Node: Delay Slots, Next: Function Units, Prev: Constant Attributes, Up: Insn Attributes 1.1.1.2 root 839: 1.1.1.6 root 840: Delay Slot Scheduling 841: --------------------- 1.1.1.5 root 842: 1.1.1.6 root 843: The insn attribute mechanism can be used to specify the requirements 844: for delay slots, if any, on a target machine. An instruction is said to 845: require a "delay slot" if some instructions that are physically after 846: the instruction are executed as if they were located before it. 847: Classic examples are branch and call instructions, which often execute 848: the following instruction before the branch or call is performed. 849: 850: On some machines, conditional branch instructions can optionally 851: "annul" instructions in the delay slot. This means that the 852: instruction will not be executed for certain branch outcomes. Both 853: instructions that annul if the branch is true and instructions that 854: annul if the branch is false are supported. 855: 856: Delay slot scheduling differs from instruction scheduling in that 857: determining whether an instruction needs a delay slot is dependent only 858: on the type of instruction being generated, not on data flow between the 859: instructions. See the next section for a discussion of data-dependent 860: instruction scheduling. 861: 862: The requirement of an insn needing one or more delay slots is 863: indicated via the `define_delay' expression. It has the following form: 864: 865: (define_delay TEST 866: [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 867: DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 868: ...]) 869: 870: TEST is an attribute test that indicates whether this `define_delay' 871: applies to a particular insn. If so, the number of required delay 872: slots is determined by the length of the vector specified as the second 873: argument. An insn placed in delay slot N must satisfy attribute test 874: DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns 875: may be annulled if the branch is true. Similarly, ANNUL-FALSE-N 876: specifies which insns in the delay slot may be annulled if the branch 877: is false. If annulling is not supported for that delay slot, `(nil)' 878: should be coded. 879: 880: For example, in the common case where branch and call insns require 881: a single delay slot, which may contain any insn other than a branch or 882: call, the following would be placed in the `md' file: 883: 884: (define_delay (eq_attr "type" "branch,call") 885: [(eq_attr "type" "!branch,call") (nil) (nil)]) 886: 887: Multiple `define_delay' expressions may be specified. In this case, 888: each such expression specifies different delay slot requirements and 889: there must be no insn for which tests in two `define_delay' expressions 890: are both true. 891: 892: For example, if we have a machine that requires one delay slot for 893: branches but two for calls, no delay slot can contain a branch or call 894: insn, and any valid insn in the delay slot for the branch can be 895: annulled if the branch is true, we might represent this as follows: 896: 897: (define_delay (eq_attr "type" "branch") 898: [(eq_attr "type" "!branch,call") 899: (eq_attr "type" "!branch,call") 900: (nil)]) 901: 902: (define_delay (eq_attr "type" "call") 903: [(eq_attr "type" "!branch,call") (nil) (nil) 904: (eq_attr "type" "!branch,call") (nil) (nil)]) 1.1.1.5 root 905: 906: 1.1.1.6 root 907: File: gcc.info, Node: Function Units, Prev: Delay Slots, Up: Insn Attributes 1.1.1.2 root 908: 1.1.1.6 root 909: Specifying Function Units 910: ------------------------- 1.1.1.5 root 911: 1.1.1.6 root 912: On most RISC machines, there are instructions whose results are not 913: available for a specific number of cycles. Common cases are 914: instructions that load data from memory. On many machines, a pipeline 915: stall will result if the data is referenced too soon after the load 916: instruction. 917: 918: In addition, many newer microprocessors have multiple function 919: units, usually one for integer and one for floating point, and often 920: will incur pipeline stalls when a result that is needed is not yet 921: ready. 922: 923: The descriptions in this section allow the specification of how much 924: time must elapse between the execution of an instruction and the time 925: when its result is used. It also allows specification of when the 926: execution of an instruction will delay execution of similar instructions 927: due to function unit conflicts. 928: 929: For the purposes of the specifications in this section, a machine is 930: divided into "function units", each of which execute a specific class 931: of instructions in first-in-first-out order. Function units that 932: accept one instruction each cycle and allow a result to be used in the 933: succeeding instruction (usually via forwarding) need not be specified. 934: Classic RISC microprocessors will normally have a single function unit, 935: which we can call `memory'. The newer "superscalar" processors will 936: often have function units for floating point operations, usually at 937: least a floating point adder and multiplier. 938: 939: Each usage of a function units by a class of insns is specified with 940: a `define_function_unit' expression, which looks like this: 941: 942: (define_function_unit NAME MULTIPLICITY SIMULTANEITY 943: TEST READY-DELAY ISSUE-DELAY 944: [CONFLICT-LIST]) 945: 946: NAME is a string giving the name of the function unit. 947: 948: MULTIPLICITY is an integer specifying the number of identical units 949: in the processor. If more than one unit is specified, they will be 950: scheduled independently. Only truly independent units should be 951: counted; a pipelined unit should be specified as a single unit. (The 952: only common example of a machine that has multiple function units for a 953: single instruction class that are truly independent and not pipelined 954: are the two multiply and two increment units of the CDC 6600.) 955: 956: SIMULTANEITY specifies the maximum number of insns that can be 957: executing in each instance of the function unit simultaneously or zero 958: if the unit is pipelined and has no limit. 959: 960: All `define_function_unit' definitions referring to function unit 961: NAME must have the same name and values for MULTIPLICITY and 962: SIMULTANEITY. 963: 964: TEST is an attribute test that selects the insns we are describing 965: in this definition. Note that an insn may use more than one function 966: unit and a function unit may be specified in more than one 967: `define_function_unit'. 968: 969: READY-DELAY is an integer that specifies the number of cycles after 970: which the result of the instruction can be used without introducing any 971: stalls. 972: 973: ISSUE-DELAY is an integer that specifies the number of cycles after 974: the instruction matching the TEST expression begins using this unit 975: until a subsequent instruction can begin. A cost of N indicates an N-1 976: cycle delay. A subsequent instruction may also be delayed if an 977: earlier instruction has a longer READY-DELAY value. This blocking 978: effect is computed using the SIMULTANEITY, READY-DELAY, ISSUE-DELAY, 979: and CONFLICT-LIST terms. For a normal non-pipelined function unit, 980: SIMULTANEITY is one, the unit is taken to block for the READY-DELAY 981: cycles of the executing insn, and smaller values of ISSUE-DELAY are 982: ignored. 983: 984: CONFLICT-LIST is an optional list giving detailed conflict costs for 985: this unit. If specified, it is a list of condition test expressions to 986: be applied to insns chosen to execute in NAME following the particular 987: insn matching TEST that is already executing in NAME. For each insn in 988: the list, ISSUE-DELAY specifies the conflict cost; for insns not in the 989: list, the cost is zero. If not specified, CONFLICT-LIST defaults to 990: all instructions that use the function unit. 991: 992: Typical uses of this vector are where a floating point function unit 993: can pipeline either single- or double-precision operations, but not 994: both, or where a memory unit can pipeline loads, but not stores, etc. 995: 996: As an example, consider a classic RISC machine where the result of a 997: load instruction is not available for two cycles (a single "delay" 998: instruction is required) and where only one load instruction can be 999: executed simultaneously. This would be specified as: 1000: 1001: (define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 0) 1002: 1003: For the case of a floating point function unit that can pipeline 1004: either single or double precision, but not both, the following could be 1005: specified: 1006: 1007: (define_function_unit 1008: "fp" 1 0 (eq_attr "type" "sp_fp") 4 4 [(eq_attr "type" "dp_fp")]) 1009: (define_function_unit 1010: "fp" 1 0 (eq_attr "type" "dp_fp") 4 4 [(eq_attr "type" "sp_fp")]) 1011: 1012: *Note:* The scheduler attempts to avoid function unit conflicts and 1013: uses all the specifications in the `define_function_unit' expression. 1014: It has recently come to our attention that these specifications may not 1015: allow modeling of some of the newer "superscalar" processors that have 1016: insns using multiple pipelined units. These insns will cause a 1017: potential conflict for the second unit used during their execution and 1018: there is no way of representing that conflict. We welcome any examples 1019: of how function unit conflicts work in such processors and suggestions 1020: for their representation. 1.1.1.2 root 1021: 1.1.1.3 root 1022: 1.1.1.6 root 1023: File: gcc.info, Node: Target Macros, Next: Config, Prev: Machine Desc, Up: Top 1.1.1.5 root 1024: 1.1.1.6 root 1025: Target Description Macros 1026: ************************* 1.1.1.5 root 1027: 1.1.1.6 root 1028: In addition to the file `MACHINE.md', a machine description includes 1029: a C header file conventionally given the name `MACHINE.h'. This header 1030: file defines numerous macros that convey the information about the 1031: target machine that does not fit into the scheme of the `.md' file. 1032: The file `tm.h' should be a link to `MACHINE.h'. The header file 1033: `config.h' includes `tm.h' and most compiler source files include 1034: `config.h'. 1.1.1.5 root 1035: 1.1.1.6 root 1036: * Menu: 1.1.1.2 root 1037: 1.1.1.6 root 1038: * Driver:: Controlling how the driver runs the compilation passes. 1039: * Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'. 1040: * Storage Layout:: Defining sizes and alignments of data. 1041: * Type Layout:: Defining sizes and properties of basic user data types. 1042: * Registers:: Naming and describing the hardware registers. 1043: * Register Classes:: Defining the classes of hardware registers. 1044: * Stack and Calling:: Defining which way the stack grows and by how much. 1045: * Varargs:: Defining the varargs macros. 1046: * Trampolines:: Code set up at run time to enter a nested function. 1047: * Library Calls:: Controlling how library routines are implicitly called. 1048: * Addressing Modes:: Defining addressing modes valid for memory operands. 1049: * Condition Code:: Defining how insns update the condition code. 1050: * Costs:: Defining relative costs of different operations. 1051: * Sections:: Dividing storage into text, data, and other sections. 1052: * PIC:: Macros for position independent code. 1053: * Assembler Format:: Defining how to write insns and pseudo-ops to output. 1054: * Debugging Info:: Defining the format of debugging output. 1055: * Cross-compilation:: Handling floating point for cross-compilers. 1056: * Misc:: Everything else. 1.1 root 1057:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.