![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-7 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to gcc.info-7 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1: Info file gcc.info, produced by Makeinfo, -*- Text -*- from input
2: file gcc.texinfo.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
1.1.1.2 root 6: Copyright (C) 1988, 1989 Free Software Foundation, Inc.
1.1 root 7:
8: Permission is granted to make and distribute verbatim copies of this
9: manual provided the copyright notice and this permission notice are
10: preserved on all copies.
11:
12: Permission is granted to copy and distribute modified versions of
13: this manual under the conditions for verbatim copying, provided also
1.1.1.3 ! root 14: that the sections entitled ``GNU General Public License'' and
! 15: ``Protect Your Freedom--Fight `Look And Feel''' are included exactly
! 16: as in the original, and provided that the entire resulting derived
! 17: work is distributed under the terms of a permission notice identical
! 18: to this one.
1.1 root 19:
20: Permission is granted to copy and distribute translations of this
21: manual into another language, under the above conditions for modified
1.1.1.3 ! root 22: versions, except that the sections entitled ``GNU General Public
! 23: License'' and ``Protect Your Freedom--Fight `Look And Feel''' and
! 24: this permission notice may be included in translations approved by
! 25: the Free Software Foundation instead of in the original English.
1.1.1.2 root 26:
1.1.1.3 ! root 27:
! 28:
! 29: File: gcc.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc
! 30:
! 31: C Statements for Generating Assembler Output
! 32: ============================================
! 33:
! 34: Often a single fixed template string cannot produce correct and
! 35: efficient assembler code for all the cases that are recognized by a
! 36: single instruction pattern. For example, the opcodes may depend on
! 37: the kinds of operands; or some unfortunate combinations of operands
! 38: may require extra machine instructions.
! 39:
! 40: If the output control string starts with a `*', then it is not an
! 41: output template but rather a piece of C program that should compute a
! 42: template. It should execute a `return' statement to return the
! 43: template-string you want. Most such templates use C string literals,
! 44: which require doublequote characters to delimit them. To include
! 45: these doublequote characters in the string, prefix each one with `\'.
! 46:
! 47: The operands may be found in the array `operands', whose C data type
! 48: is `rtx []'.
! 49:
! 50: It is possible to output an assembler instruction and then go on to
! 51: output or compute more of them, using the subroutine
! 52: `output_asm_insn'. This receives two arguments: a template-string
! 53: and a vector of operands. The vector may be `operands', or it may be
! 54: another array of `rtx' that you declare locally and initialize
! 55: yourself.
! 56:
! 57: When an insn pattern has multiple alternatives in its constraints,
! 58: often the appearance of the assembler code is determined mostly by
! 59: which alternative was matched. When this is so, the C code can test
! 60: the variable `which_alternative', which is the ordinal number of the
! 61: alternative that was actually satisfied (0 for the first, 1 for the
! 62: second alternative, etc.).
! 63:
! 64: For example, suppose there are two opcodes for storing zero, `clrreg'
! 65: for registers and `clrmem' for memory locations. Here is how a
! 66: pattern could use `which_alternative' to choose between them:
! 67:
! 68: (define_insn ""
! 69: [(set (match_operand:SI 0 "general_operand" "r,m")
! 70: (const_int 0))]
! 71: ""
! 72: "*
! 73: return (which_alternative == 0
! 74: ? \"clrreg %0\" : \"clrmem %0\");
! 75: ")
! 76:
! 77:
! 78:
! 79: File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc
! 80:
! 81: Operand Constraints
! 82: ===================
! 83:
! 84: Each `match_operand' in an instruction pattern can specify a
! 85: constraint for the type of operands allowed. Constraints can say
! 86: whether an operand may be in a register, and which kinds of register;
! 87: whether the operand can be a memory reference, and which kinds of
! 88: address; whether the operand may be an immediate constant, and which
! 89: possible values it may have. Constraints can also require two
! 90: operands to match.
! 91:
! 92: * Menu:
! 93:
! 94: * Simple Constraints:: Basic use of constraints.
! 95: * Multi-Alternative:: When an insn has two alternative constraint-patterns.
! 96: * Class Preferences:: Constraints guide which hard register to put things in.
! 97: * Modifiers:: More precise control over effects of constraints.
! 98: * No Constraints:: Describing a clean machine without constraints.
! 99:
! 100:
! 101:
! 102: File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Prev: Constraints, Up: Constraints
! 103:
! 104: Simple Constraints
! 105: ------------------
! 106:
! 107: The simplest kind of constraint is a string full of letters, each of
! 108: which describes one kind of operand that is permitted. Here are the
! 109: letters that are allowed:
! 110:
! 111: `m'
! 112: A memory operand is allowed, with any kind of address that the
! 113: machine supports in general.
! 114:
! 115: `o'
! 116: A memory operand is allowed, but only if the address is
! 117: "offsettable". This means that adding a small integer
! 118: (actually, the width in bytes of the operand, as determined by
! 119: its machine mode) may be added to the address and the result is
! 120: also a valid memory address.
! 121:
! 122: For example, an address which is constant is offsettable; so is
! 123: an address that is the sum of a register and a constant (as long
! 124: as a slightly larger constant is also within the range of
! 125: address-offsets supported by the machine); but an autoincrement
! 126: or autodecrement address is not offsettable. More complicated
! 127: indirect/indexed addresses may or may not be offsettable
! 128: depending on the other addressing modes that the machine supports.
! 129:
! 130: Note that in an output operand which can be matched by another
! 131: operand, the constraint letter `o' is valid only when
! 132: accompanied by both `<' (if the target machine has predecrement
! 133: addressing) and `>' (if the target machine has preincrement
! 134: addressing).
! 135:
! 136: When the constraint letter `o' is used, the reload pass may
! 137: generate instructions which copy a nonoffsettable address into
! 138: an index register. The idea is that the register can be used as
! 139: a replacement offsettable address. But this method requires
! 140: that there be patterns to copy any kind of address into a
! 141: register. Auto-increment and auto-decrement addresses are an
! 142: exception; there need not be an instruction that can copy such
! 143: an address into a register, because reload handles these cases
! 144: specially.
! 145:
! 146: Most older machine designs have ``load address'' instructions
! 147: which do just what is needed here. Some RISC machines do not
! 148: advertise such instructions, but the possible addresses on these
! 149: machines are very limited, so it is easy to fake them.
! 150:
! 151: `<'
! 152: A memory operand with autodecrement addressing (either
! 153: predecrement or postdecrement) is allowed.
! 154:
! 155: `>'
! 156: A memory operand with autoincrement addressing (either
! 157: preincrement or postincrement) is allowed.
! 158:
! 159: `r'
! 160: A register operand is allowed provided that it is in a general
! 161: register.
! 162:
! 163: `d', `a', `f', ...
! 164: Other letters can be defined in machine-dependent fashion to
! 165: stand for particular classes of registers. `d', `a' and `f' are
! 166: defined on the 68000/68020 to stand for data, address and
! 167: floating point registers.
! 168:
! 169: `i'
! 170: An immediate integer operand (one with constant value) is allowed.
! 171: This includes symbolic constants whose values will be known only
! 172: at assembly time.
! 173:
! 174: `n'
! 175: An immediate integer operand with a known numeric value is
! 176: allowed. Many systems cannot support assembly-time constants
! 177: for operands less than a word wide. Constraints for these
! 178: operands should use `n' rather than `i'.
! 179:
! 180: `I', `J', `K', ...
! 181: Other letters in the range `I' through `M' may be defined in a
! 182: machine-dependent fashion to permit immediate integer operands
! 183: with explicit integer values in specified ranges. For example,
! 184: on the 68000, `I' is defined to stand for the range of values 1
! 185: to 8. This is the range permitted as a shift count in the shift
! 186: instructions.
! 187:
! 188: `F'
! 189: An immediate floating operand (expression code `const_double')
! 190: is allowed.
! 191:
! 192: `G', `H'
! 193: `G' and `H' may be defined in a machine-dependent fashion to
! 194: permit immediate floating operands in particular ranges of values.
! 195:
! 196: `s'
! 197: An immediate integer operand whose value is not an explicit
! 198: integer is allowed.
! 199:
! 200: This might appear strange; if an insn allows a constant operand
! 201: with a value not known at compile time, it certainly must allow
! 202: any known value. So why use `s' instead of `i'? Sometimes it
! 203: allows better code to be generated.
! 204:
! 205: For example, on the 68000 in a fullword instruction it is
! 206: possible to use an immediate operand; but if the immediate value
! 207: is between -128 and 127, better code results from loading the
! 208: value into a register and using the register. This is because
! 209: the load into the register can be done with a `moveq'
! 210: instruction. We arrange for this to happen by defining the
! 211: letter `K' to mean ``any integer outside the range -128 to
! 212: 127'', and then specifying `Ks' in the operand constraints.
! 213:
! 214: `g'
! 215: Any register, memory or immediate integer operand is allowed,
! 216: except for registers that are not general registers.
! 217:
! 218: `N' (a digit)
! 219: An operand that matches operand number N is allowed. If a digit
! 220: is used together with letters, the digit should come last.
! 221:
! 222: This is called a "matching constraint" and what it really means
! 223: is that the assembler has only a single operand that fills two
! 224: roles considered separate in the RTL insn. For example, an add
! 225: insn has two input operands and one output operand in the RTL,
! 226: but on most machines an add instruction really has only two
! 227: operands, one of them an input-output operand.
! 228:
! 229: Matching constraints work only in circumstances like that add
! 230: insn. More precisely, the matching constraint must appear in an
! 231: input-only operand and the operand that it matches must be an
! 232: output-only operand with a lower number. Thus, operand N must
! 233: have `=' in its constraint.
! 234:
! 235: For operands to match in a particular case usually means that
! 236: they are identical-looking RTL expressions. But in a few
! 237: special cases specific kinds of dissimilarity are allowed. For
! 238: example, `*x' as an input operand will match `*x++' as an output
! 239: operand. For proper results in such cases, the output template
! 240: should always use the output-operand's number when printing the
! 241: operand.
! 242:
! 243: `p'
! 244: An operand that is a valid memory address is allowed. This is
! 245: for ``load address'' and ``push address'' instructions.
! 246:
! 247: `p' in the constraint must be accompanies by `address_operand'
! 248: as the predicate in the `match_operand'.
! 249:
! 250: In order to have valid assembler code, each operand must satisfy its
! 251: constraint. But a failure to do so does not prevent the pattern from
! 252: applying to an insn. Instead, it directs the compiler to modify the
! 253: code so that the constraint will be satisfied. Usually this is done
! 254: by copying an operand into a register.
! 255:
! 256: Contrast, therefore, the two instruction patterns that follow:
! 257:
! 258: (define_insn ""
! 259: [(set (match_operand:SI 0 "general_operand" "r")
! 260: (plus:SI (match_dup 0)
! 261: (match_operand:SI 1 "general_operand" "r")))]
! 262: ""
! 263: "...")
! 264:
! 265: which has two operands, one of which must appear in two places, and
! 266:
! 267: (define_insn ""
! 268: [(set (match_operand:SI 0 "general_operand" "r")
! 269: (plus:SI (match_operand:SI 1 "general_operand" "0")
! 270: (match_operand:SI 2 "general_operand" "r")))]
! 271: ""
! 272: "...")
! 273:
! 274: which has three operands, two of which are required by a constraint
! 275: to be identical. If we are considering an insn of the form
! 276:
! 277: (insn N PREV NEXT
! 278: (set (reg:SI 3)
! 279: (plus:SI (reg:SI 6) (reg:SI 109)))
! 280: ...)
! 281:
! 282: the first pattern would not apply at all, because this insn does not
! 283: contain two identical subexpressions in the right place. The pattern
! 284: would say, ``That does not look like an add instruction; try other
! 285: patterns.'' The second pattern would say, ``Yes, that's an add
! 286: instruction, but there is something wrong with it.'' It would direct
! 287: the reload pass of the compiler to generate additional insns to make
! 288: the constraint true. The results might look like this:
! 289:
! 290: (insn N2 PREV N
! 291: (set (reg:SI 3) (reg:SI 6))
! 292: ...)
! 293:
! 294: (insn N N2 NEXT
! 295: (set (reg:SI 3)
! 296: (plus:SI (reg:SI 3) (reg:SI 109)))
! 297: ...)
! 298:
! 299: It is up to you to make sure that each operand, in each pattern, has
! 300: constraints that can handle any RTL expression that could be present
! 301: for that operand. (When multiple alternatives are in use, each
! 302: pattern must, for each possible combination of operand expressions,
! 303: have at least one alternative which can handle that combination of
! 304: operands.) The constraints don't need to *allow* any possible
! 305: operand--when this is the case, they do not constrain--but they must
! 306: at least point the way to reloading any possible operand so that it
! 307: will fit.
! 308:
! 309: * If the constraint accepts whatever operands the predicate
! 310: permits, there is no problem: reloading is never necessary for
! 311: this operand.
! 312:
! 313: For example, an operand whose constraints permit everything
! 314: except registers is safe provided its predicate rejects registers.
! 315:
! 316: An operand whose predicate accepts only constant values is safe
! 317: provided its constraints include the letter `i'. If any
! 318: possible constant value is accepted, then nothing less than `i'
! 319: will do; if the predicate is more selective, then the
! 320: constraints may also be more selective.
! 321:
! 322: * Any operand expression can be reloaded by copying it into a
! 323: register. So if an operand's constraints allow some kind of
! 324: register, it is certain to be safe. It need not permit all
! 325: classes of registers; the compiler knows how to copy a register
! 326: into another register of the proper class in order to make an
! 327: instruction valid.
! 328:
! 329: * A nonoffsettable memory reference can be reloaded by copying the
! 330: address into a register. So if the constraint uses the letter
! 331: `o', all memory references are taken care of.
! 332:
! 333: * A constant operand can be reloaded by allocating space in memory
! 334: to hold it as preinitialized data. Then the memory reference
! 335: can be used in place of the constant. So if the constraint uses
! 336: the letters `o' or `m', constant operands are not a problem.
! 337:
! 338: If the operand's predicate can recognize registers, but the
! 339: constraint does not permit them, it can make the compiler crash.
! 340: When this operand happens to be a register, the reload pass will be
! 341: stymied, because it does not know how to copy a register temporarily
! 342: into memory.
! 343:
! 344:
! 345:
! 346: File: gcc.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints
! 347:
! 348: Multiple Alternative Constraints
! 349: --------------------------------
! 350:
! 351: Sometimes a single instruction has multiple alternative sets of
! 352: possible operands. For example, on the 68000, a logical-or
! 353: instruction can combine register or an immediate value into memory,
! 354: or it can combine any kind of operand into a register; but it cannot
! 355: combine one memory location into another.
! 356:
! 357: These constraints are represented as multiple alternatives. An
! 358: alternative can be described by a series of letters for each operand.
! 359: The overall constraint for an operand is made from the letters for
! 360: this operand from the first alternative, a comma, the letters for
! 361: this operand from the second alternative, a comma, and so on until
! 362: the last alternative. Here is how it is done for fullword logical-or
! 363: on the 68000:
! 364:
! 365: (define_insn "iorsi3"
! 366: [(set (match_operand:SI 0 "general_operand" "=m,d")
! 367: (ior:SI (match_operand:SI 1 "general_operand" "%0,0")
! 368: (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
! 369: ...)
! 370:
! 371: The first alternative has `m' (memory) for operand 0, `0' for operand
! 372: 1 (meaning it must match operand 0), and `dKs' for operand 2. The
! 373: second alternative has `d' (data register) for operand 0, `0' for
! 374: operand 1, and `dmKs' for operand 2. The `=' and `%' in the
! 375: constraints apply to all the alternatives; their meaning is explained
! 376: in the next section.
! 377:
! 378: If all the operands fit any one alternative, the instruction is valid.
! 379: Otherwise, for each alternative, the compiler counts how many
! 380: instructions must be added to copy the operands so that that
! 381: alternative applies. The alternative requiring the least copying is
! 382: chosen. If two alternatives need the same amount of copying, the one
! 383: that comes first is chosen. These choices can be altered with the
! 384: `?' and `!' characters:
! 385:
! 386: `?'
! 387: Disparage slightly the alternative that the `?' appears in, as a
! 388: choice when no alternative applies exactly. The compiler
! 389: regards this alternative as one unit more costly for each `?'
! 390: that appears in it.
! 391:
! 392: `!'
! 393: Disparage severely the alternative that the `!' appears in.
! 394: When operands must be copied into registers, the compiler will
! 395: never choose this alternative as the one to strive for.
! 396:
! 397: When an insn pattern has multiple alternatives in its constraints,
! 398: often the appearance of the assembler code is determined mostly by
! 399: which alternative was matched. When this is so, the C code for
! 400: writing the assembler code can use the variable `which_alternative',
! 401: which is the ordinal number of the alternative that was actually
! 402: satisfied (0 for the first, 1 for the second alternative, etc.). For
! 403: example:
! 404:
! 405: (define_insn ""
! 406: [(set (match_operand:SI 0 "general_operand" "r,m")
! 407: (const_int 0))]
! 408: ""
! 409: "*
! 410: return (which_alternative == 0
! 411: ? \"clrreg %0\" : \"clrmem %0\");
! 412: ")
! 413:
! 414:
! 415:
! 416: File: gcc.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints
! 417:
! 418: Register Class Preferences
! 419: --------------------------
! 420:
! 421: The operand constraints have another function: they enable the
! 422: compiler to decide which kind of hardware register a pseudo register
! 423: is best allocated to. The compiler examines the constraints that
! 424: apply to the insns that use the pseudo register, looking for the
! 425: machine-dependent letters such as `d' and `a' that specify classes of
! 426: registers. The pseudo register is put in whichever class gets the
! 427: most ``votes''. The constraint letters `g' and `r' also vote: they
! 428: vote in favor of a general register. The machine description says
! 429: which registers are considered general.
! 430:
! 431: Of course, on some machines all registers are equivalent, and no
! 432: register classes are defined. Then none of this complexity is
! 433: relevant.
! 434:
! 435:
! 436:
! 437: File: gcc.info, Node: Modifiers, Next: No Constraints, Prev: Class Preferences, Up: Constraints
! 438:
! 439: Constraint Modifier Characters
! 440: ------------------------------
! 441:
! 442: `='
! 443: Means that this operand is write-only for this instruction: the
! 444: previous value is discarded and replaced by output data.
! 445:
! 446: `+'
! 447: Means that this operand is both read and written by the
! 448: instruction.
! 449:
! 450: When the compiler fixes up the operands to satisfy the
! 451: constraints, it needs to know which operands are inputs to the
! 452: instruction and which are outputs from it. `=' identifies an
! 453: output; `+' identifies an operand that is both input and output;
! 454: all other operands are assumed to be input only.
! 455:
! 456: `&'
! 457: Means (in a particular alternative) that this operand is written
! 458: before the instruction is finished using the input operands.
! 459: Therefore, this operand may not lie in a register that is used
! 460: as an input operand or as part of any memory address.
! 461:
! 462: `&' applies only to the alternative in which it is written. In
! 463: constraints with multiple alternatives, sometimes one
! 464: alternative requires `&' while others do not. See, for example,
! 465: the `movdf' insn of the 68000.
! 466:
! 467: `&' does not obviate the need to write `='.
! 468:
! 469: `%'
! 470: Declares the instruction to be commutative for this operand and
! 471: the following operand. This means that the compiler may
! 472: interchange the two operands if that is the cheapest way to make
! 473: all operands fit the constraints. This is often used in
! 474: patterns for addition instructions that really have only two
! 475: operands: the result must go in one of the arguments. Here for
! 476: example, is how the 68000 halfword-add instruction is defined:
! 477:
! 478: (define_insn "addhi3"
! 479: [(set (match_operand:HI 0 "general_operand" "=m,r")
! 480: (plus:HI (match_operand:HI 1 "general_operand" "%0,0")
! 481: (match_operand:HI 2 "general_operand" "di,g")))]
! 482: ...)
! 483:
! 484: Note that in previous versions of GNU CC the `%' constraint
! 485: modifier always applied to operands 1 and 2 regardless of which
! 486: operand it was written in. The usual custom was to write it in
! 487: operand 0. Now it must be in operand 1 if the operands to be
! 488: exchanged are 1 and 2.
! 489:
! 490: `#'
! 491: Says that all following characters, up to the next comma, are to
! 492: be ignored as a constraint. They are significant only for
! 493: choosing register preferences.
! 494:
! 495: `*'
! 496: Says that the following character should be ignored when
! 497: choosing register preferences. `*' has no effect on the meaning
! 498: of the constraint as a constraint.
! 499:
! 500: Here is an example: the 68000 has an instruction to sign-extend
! 501: a halfword in a data register, and can also sign-extend a value
! 502: by copying it into an address register. While either kind of
! 503: register is acceptable, the constraints on an address-register
! 504: destination are less strict, so it is best if register
! 505: allocation makes an address register its goal. Therefore, `*'
! 506: is used so that the `d' constraint letter (for data register) is
! 507: ignored when computing register preferences.
! 508:
! 509: (define_insn "extendhisi2"
! 510: [(set (match_operand:SI 0 "general_operand" "=*d,a")
! 511: (sign_extend:SI
! 512: (match_operand:HI 1 "general_operand" "0,g")))]
! 513: ...)
! 514:
! 515:
! 516:
! 517: File: gcc.info, Node: No Constraints, Prev: Modifiers, Up: Constraints
! 518:
! 519: Not Using Constraints
! 520: ---------------------
! 521:
! 522: Some machines are so clean that operand constraints are not required.
! 523: For example, on the Vax, an operand valid in one context is valid in
! 524: any other context. On such a machine, every operand constraint would
! 525: be `g', excepting only operands of ``load address'' instructions
! 526: which are written as if they referred to a memory location's contents
! 527: but actual refer to its address. They would have constraint `p'.
! 528:
! 529: For such machines, instead of writing `g' and `p' for all the
! 530: constraints, you can choose to write a description with empty
! 531: constraints. Then you write `""' for the constraint in every
! 532: `match_operand'. Address operands are identified by writing an
! 533: `address' expression around the `match_operand', not by their
! 534: constraints.
! 535:
! 536: When the machine description has just empty constraints, certain
! 537: parts of compilation are skipped, making the compiler faster.
! 538: However, few machines actually do not need constraints; all machine
! 539: descriptions now in existence use constraints.
! 540:
! 541:
! 542:
! 543: File: gcc.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc
! 544:
! 545: Standard Names for Patterns Used in Generation
! 546: ==============================================
! 547:
! 548: Here is a table of the instruction names that are meaningful in the
! 549: RTL generation pass of the compiler. Giving one of these names to an
! 550: instruction pattern tells the RTL generation pass that it can use the
! 551: pattern in to accomplish a certain task.
! 552:
! 553: `movM'
! 554: Here M stands for a two-letter machine mode name, in lower case.
! 555: This instruction pattern moves data with that machine mode from
! 556: operand 1 to operand 0. For example, `movsi' moves full-word
! 557: data.
! 558:
! 559: If operand 0 is a `subreg' with mode M of a register whose own
! 560: mode is wider than M, the effect of this instruction is to store
! 561: the specified value in the part of the register that corresponds
! 562: to mode M. The effect on the rest of the register is undefined.
! 563:
! 564: This class of patterns is special in several ways. First of
! 565: all, each of these names *must* be defined, because there is no
! 566: other way to copy a datum from one place to another.
! 567:
! 568: Second, these patterns are not used solely in the RTL generation
! 569: pass. Even the reload pass can generate move insns to copy
! 570: values from stack slots into temporary registers. When it does
! 571: so, one of the operands is a hard register and the other is an
! 572: operand that can need to be reloaded into a register.
! 573:
! 574: Therefore, when given such a pair of operands, the pattern must
! 575: generate RTL which needs no reloading and needs no temporary
! 576: registers--no registers other than the operands. For example,
! 577: if you support the pattern with a `define_expand', then in such
! 578: a case the `define_expand' mustn't call `force_reg' or any other
! 579: such function which might generate new pseudo registers.
! 580:
! 581: This requirement exists even for subword modes on a RISC machine
! 582: where fetching those modes from memory normally requires several
! 583: insns and some temporary registers. Look in `spur.md' to see
! 584: how the requirement can be satisfied.
! 585:
! 586: The variety of operands that have reloads depends on the rest of
! 587: the machine description, but typically on a RISC machine these
! 588: can only be pseudo registers that did not get hard registers,
! 589: while on other machines explicit memory references will get
! 590: optional reloads.
! 591:
! 592: The constraints on a `moveM' must allow any hard register to be
! 593: moved to any other hard register (provided that
! 594: `HARD_REGNO_MODE_OK' permits mode M in both registers).
! 595:
! 596: It is obligatory to support floating point `moveM' instructions
1.1.1.2 root 597: into and out of any registers that can hold fixed point values,
598: because unions and structures (which have modes `SImode' or
599: `DImode') can be in those registers and they may have floating
600: point members.
601:
1.1.1.3 ! root 602: There may also be a need to support fixed point `moveM'
1.1.1.2 root 603: instructions in and out of floating point registers.
604: Unfortunately, I have forgotten why this was so, and I don't
605: know whether it is still true. If `HARD_REGNO_MODE_OK' rejects
606: fixed point values in floating point registers, then the
1.1.1.3 ! root 607: constraints of the fixed point `moveM' instructions must be
1.1.1.2 root 608: designed to avoid ever trying to reload into a floating point
609: register.
610:
1.1.1.3 ! root 611: `movstrictM'
! 612: Like `movM' except that if operand 0 is a `subreg' with mode M
! 613: of a register whose natural mode is wider, the `movstrictM'
! 614: instruction is guaranteed not to alter any of the register
! 615: except the part which belongs to mode M.
! 616:
! 617: `addM3'
! 618: Add operand 2 and operand 1, storing the result in operand 0.
! 619: All operands must have mode M. This can be used even on
! 620: two-address machines, by means of constraints requiring operands
! 621: 1 and 0 to be the same location.
! 622:
! 623: `subM3', `mulM3', `umulM3', `divM3', `udivM3', `modM3', `umodM3', `andM3', `iorM3', `xorM3'
! 624: Similar, for other arithmetic operations.
! 625:
! 626: There are special considerations for register classes for
! 627: logical-and instructions, affecting also the macro
! 628: `PREFERRED_RELOAD_CLASS'. They apply not only to the patterns
! 629: with these standard names, but to any patterns that will match
! 630: such an instruction. *Note Register Classes::.
! 631:
! 632: `mulhisi3'
! 633: Multiply operands 1 and 2, which have mode `HImode', and store a
! 634: `SImode' product in operand 0.
! 635:
! 636: `mulqihi3', `mulsidi3'
! 637: Similar widening-multiplication instructions of other widths.
! 638:
! 639: `umulqihi3', `umulhisi3', `umulsidi3'
! 640: Similar widening-multiplication instructions that do unsigned
! 641: multiplication.
! 642:
! 643: `divmodM4'
! 644: Signed division that produces both a quotient and a remainder.
! 645: Operand 1 is divided by operand 2 to produce a quotient stored
! 646: in operand 0 and a remainder stored in operand 3.
! 647:
! 648: `udivmodM4'
! 649: Similar, but does unsigned division.
! 650:
! 651: `ashlM3'
! 652: Arithmetic-shift operand 1 left by a number of bits specified by
! 653: operand 2, and store the result in operand 0. Operand 2 has
! 654: mode `SImode', not mode M.
! 655:
! 656: `ashrM3', `lshlM3', `lshrM3', `rotlM3', `rotrM3'
! 657: Other shift and rotate instructions.
! 658:
! 659: Logical and arithmetic left shift are the same. Machines that
! 660: do not allow negative shift counts often have only one
! 661: instruction for shifting left. On such machines, you should
! 662: define a pattern named `ashlM3' and leave `lshlM3' undefined.
! 663:
! 664: There are special considerations for register classes for shift
! 665: instructions, affecting also the macro `PREFERRED_RELOAD_CLASS'.
! 666: They apply not only to the patterns with these standard names,
! 667: but to any patterns that will match such an instruction. *Note
! 668: Register Classes::.
! 669:
! 670: `negM2'
! 671: Negate operand 1 and store the result in operand 0.
! 672:
! 673: `absM2'
! 674: Store the absolute value of operand 1 into operand 0.
! 675:
! 676: `sqrtM2'
! 677: Store the square root of operand 1 into operand 0.
! 678:
! 679: `ffsM2'
! 680: Store into operand 0 one plus the index of the least significant
! 681: 1-bit of operand 1. If operand 1 is zero, store zero. M is the
! 682: mode of operand 0; operand 1's mode is specified by the
! 683: instruction pattern, and the compiler will convert the operand
! 684: to that mode before generating the instruction.
! 685:
! 686: `one_cmplM2'
! 687: Store the bitwise-complement of operand 1 into operand 0.
! 688:
! 689: `cmpM'
! 690: Compare operand 0 and operand 1, and set the condition codes.
! 691: The RTL pattern should look like this:
! 692:
! 693: (set (cc0) (compare (match_operand:M 0 ...)
! 694: (match_operand:M 1 ...)))
! 695:
! 696: Each such definition in the machine description, for integer
! 697: mode M, must have a corresponding `tstM' pattern, because
! 698: optimization can simplify the compare into a test when operand 1
! 699: is zero.
! 700:
! 701: `tstM'
! 702: Compare operand 0 against zero, and set the condition codes.
! 703: The RTL pattern should look like this:
! 704:
! 705: (set (cc0) (match_operand:M 0 ...))
! 706:
! 707: `movstrM'
! 708: Block move instruction. The addresses of the destination and
! 709: source strings are the first two operands, and both are in mode
! 710: `Pmode'. The number of bytes to move is the third operand, in
! 711: mode M. The fourth operand is the known shared alignment of the
! 712: source and destination, in the form of a `const_int' rtx.
! 713:
! 714: `cmpstrM'
! 715: Block compare instruction, with operands like `movstrM' except
! 716: that the two memory blocks are compared byte by byte in
! 717: lexicographic order. The effect of the instruction is to set
! 718: the condition codes.
! 719:
! 720: `floatMN2'
! 721: Convert signed integer operand 1 (valid for fixed point mode M)
! 722: to floating point mode N and store in operand 0 (which has mode
! 723: N).
! 724:
! 725: `floatunsMN2'
! 726: Convert unsigned integer operand 1 (valid for fixed point mode
! 727: M) to floating point mode N and store in operand 0 (which has
! 728: mode N).
! 729:
! 730: `fixMN2'
! 731: Convert operand 1 (valid for floating point mode M) to fixed
! 732: point mode N as a signed number and store in operand 0 (which
! 733: has mode N). This instruction's result is defined only when the
! 734: value of operand 1 is an integer.
! 735:
! 736: `fixunsMN2'
! 737: Convert operand 1 (valid for floating point mode M) to fixed
! 738: point mode N as an unsigned number and store in operand 0 (which
! 739: has mode N). This instruction's result is defined only when the
! 740: value of operand 1 is an integer.
! 741:
! 742: `ftruncM2'
! 743: Convert operand 1 (valid for floating point mode M) to an
! 744: integer value, still represented in floating point mode M, and
! 745: store it in operand 0 (valid for floating point mode M).
! 746:
! 747: `fix_truncMN2'
! 748: Like `fixMN2' but works for any floating point value of mode M
! 749: by converting the value to an integer.
! 750:
! 751: `fixuns_truncMN2'
! 752: Like `fixunsMN2' but works for any floating point value of mode
! 753: M by converting the value to an integer.
! 754:
! 755: `truncMN'
! 756: Truncate operand 1 (valid for mode M) to mode N and store in
! 757: operand 0 (which has mode N). Both modes must be fixed point or
! 758: both floating point.
! 759:
! 760: `extendMN'
! 761: Sign-extend operand 1 (valid for mode M) to mode N and store in
! 762: operand 0 (which has mode N). Both modes must be fixed point or
! 763: both floating point.
! 764:
! 765: `zero_extendMN'
! 766: Zero-extend operand 1 (valid for mode M) to mode N and store in
! 767: operand 0 (which has mode N). Both modes must be fixed point.
! 768:
! 769: `extv'
! 770: Extract a bit-field from operand 1 (a register or memory
! 771: operand), where operand 2 specifies the width in bits and
! 772: operand 3 the starting bit, and store it in operand 0. Operand
! 773: 0 must have `Simode'. Operand 1 may have mode `QImode' or
! 774: `SImode'; often `SImode' is allowed only for registers.
! 775: Operands 2 and 3 must be valid for `SImode'.
! 776:
! 777: The RTL generation pass generates this instruction only with
! 778: constants for operands 2 and 3.
! 779:
! 780: The bit-field value is sign-extended to a full word integer
! 781: before it is stored in operand 0.
! 782:
! 783: `extzv'
! 784: Like `extv' except that the bit-field value is zero-extended.
! 785:
! 786: `insv'
! 787: Store operand 3 (which must be valid for `SImode') into a
! 788: bit-field in operand 0, where operand 1 specifies the width in
! 789: bits and operand 2 the starting bit. Operand 0 may have mode
! 790: `QImode' or `SImode'; often `SImode' is allowed only for
! 791: registers. Operands 1 and 2 must be valid for `SImode'.
! 792:
! 793: The RTL generation pass generates this instruction only with
! 794: constants for operands 1 and 2.
! 795:
! 796: `sCOND'
! 797: Store zero or nonzero in the operand according to the condition
! 798: codes. Value stored is nonzero iff the condition COND is true.
! 799: COND is the name of a comparison operation expression code, such
! 800: as `eq', `lt' or `leu'.
! 801:
! 802: You specify the mode that the operand must have when you write
! 803: the `match_operand' expression. The compiler automatically sees
! 804: which mode you have used and supplies an operand of that mode.
! 805:
! 806: The value stored for a true condition must have 1 as its low
! 807: bit, or else must be negative. Otherwise the instruction is not
! 808: suitable and must be omitted from the machine description. You
! 809: must tell the compiler exactly which value is stored by defining
! 810: the macro `STORE_FLAG_VALUE'.
! 811:
! 812: `bCOND'
! 813: Conditional branch instruction. Operand 0 is a `label_ref' that
! 814: refers to the label to jump to. Jump if the condition codes
! 815: meet condition COND.
! 816:
! 817: `call'
! 818: Subroutine call instruction returning no value. Operand 0 is
! 819: the function to call; operand 1 is the number of bytes of
! 820: arguments pushed (in mode `SImode', except it is normally a
! 821: `const_int'); operand 2 is the number of registers used as
! 822: operands.
! 823:
! 824: On most machines, operand 2 is not actually stored into the RTL
! 825: pattern. It is supplied for the sake of some RISC machines
! 826: which need to put this information into the assembler code; they
! 827: can put it in the RTL instead of operand 1.
! 828:
! 829: Operand 0 should be a `mem' RTX whose address is the address of
! 830: the function.
! 831:
! 832: `call_value'
! 833: Subroutine call instruction returning a value. Operand 0 is the
! 834: hard register in which the value is returned. There are three
! 835: more operands, the same as the three operands of the `call'
! 836: instruction (but with numbers increased by one).
! 837:
! 838: Subroutines that return `BLKmode' objects use the `call' insn.
! 839:
! 840: `return'
! 841: Subroutine return instruction. This instruction pattern name
! 842: should be defined only if a single instruction can do all the
! 843: work of returning from a function.
! 844:
! 845: `nop'
! 846: No-op instruction. This instruction pattern name should always
! 847: be defined to output a no-op in assembler code. `(const_int 0)'
! 848: will do as an RTL pattern.
! 849:
! 850: `casesi'
! 851: Instruction to jump through a dispatch table, including bounds
! 852: checking. This instruction takes five operands:
! 853:
! 854: 1. The index to dispatch on, which has mode `SImode'.
! 855:
! 856: 2. The lower bound for indices in the table, an integer
! 857: constant.
! 858:
! 859: 3. The total range of indices in the table--the largest index
! 860: minus the smallest one (both inclusive).
! 861:
! 862: 4. A label to jump to if the index has a value outside the
! 863: bounds. (If the machine-description macro
! 864: `CASE_DROPS_THROUGH' is defined, then an out-of-bounds
! 865: index drops through to the code following the jump table
! 866: instead of jumping to this label. In that case, this label
! 867: is not actually used by the `casesi' instruction, but it is
! 868: always provided as an operand.)
! 869:
! 870: 5. A label that precedes the table itself.
! 871:
! 872: The table is a `addr_vec' or `addr_diff_vec' inside of a
! 873: `jump_insn'. The number of elements in the table is one plus
! 874: the difference between the upper bound and the lower bound.
! 875:
! 876: `tablejump'
! 877: Instruction to jump to a variable address. This is a low-level
! 878: capability which can be used to implement a dispatch table when
! 879: there is no `casesi' pattern.
! 880:
! 881: This pattern requires two operands: the address or offset, and a
! 882: label which should immediately precede the jump table. If the
! 883: macro `CASE_VECTOR_PC_RELATIVE' is defined then the first
! 884: operand is an absolute address to jump to; otherwise, it is an
! 885: offset which counts from the address of the table.
! 886:
! 887: The `tablejump' insn is always the last insn before the jump
! 888: table it uses. Its assembler code normally has no need to use
! 889: the second operand, but you should incorporate it in the RTL
! 890: pattern so that the jump optimizer will not delete the table as
! 891: unreachable code.
! 892:
! 893:
! 894:
! 895: File: gcc.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc
! 896:
! 897: When the Order of Patterns Matters
! 898: ==================================
! 899:
! 900: Sometimes an insn can match more than one instruction pattern. Then
! 901: the pattern that appears first in the machine description is the one
! 902: used. Therefore, more specific patterns (patterns that will match
! 903: fewer things) and faster instructions (those that will produce better
! 904: code when they do match) should usually go first in the description.
! 905:
! 906: In some cases the effect of ordering the patterns can be used to hide
! 907: a pattern when it is not valid. For example, the 68000 has an
! 908: instruction for converting a fullword to floating point and another
! 909: for converting a byte to floating point. An instruction converting
! 910: an integer to floating point could match either one. We put the
! 911: pattern to convert the fullword first to make sure that one will be
! 912: used rather than the other. (Otherwise a large integer might be
! 913: generated as a single-byte immediate quantity, which would not work.)
! 914: Instead of using this pattern ordering it would be possible to make
! 915: the pattern for convert-a-byte smart enough to deal properly with any
! 916: constant value.
! 917:
! 918:
! 919:
! 920: File: gcc.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc
! 921:
! 922: Interdependence of Patterns
! 923: ===========================
! 924:
! 925: Every machine description must have a named pattern for each of the
! 926: conditional branch names `bCOND'. The recognition template must
! 927: always have the form
! 928:
! 929: (set (pc)
! 930: (if_then_else (COND (cc0) (const_int 0))
! 931: (label_ref (match_operand 0 "" ""))
! 932: (pc)))
! 933:
! 934: In addition, every machine description must have an anonymous pattern
! 935: for each of the possible reverse-conditional branches. These
! 936: patterns look like
! 937:
! 938: (set (pc)
! 939: (if_then_else (COND (cc0) (const_int 0))
! 940: (pc)
! 941: (label_ref (match_operand 0 "" ""))))
! 942:
! 943: They are necessary because jump optimization can turn
! 944: direct-conditional branches into reverse-conditional branches.
! 945:
! 946: The compiler does more with RTL than just create it from patterns and
! 947: recognize the patterns: it can perform arithmetic expression codes
! 948: when constant values for their operands can be determined. As a
! 949: result, sometimes having one pattern can require other patterns. For
! 950: example, the Vax has no `and' instruction, but it has `and not'
! 951: instructions. Here is the definition of one of them:
! 952:
! 953: (define_insn "andcbsi2"
! 954: [(set (match_operand:SI 0 "general_operand" "")
! 955: (and:SI (match_dup 0)
! 956: (not:SI (match_operand:SI
! 957: 1 "general_operand" ""))))]
! 958: ""
! 959: "bicl2 %1,%0")
! 960:
! 961: If operand 1 is an explicit integer constant, an instruction
! 962: constructed using that pattern can be simplified into an `and' like
! 963: this:
! 964:
! 965: (set (reg:SI 41)
! 966: (and:SI (reg:SI 41)
! 967: (const_int 0xffff7fff)))
! 968:
! 969: (where the integer constant is the one's complement of what appeared
! 970: in the original instruction).
! 971:
! 972: To avoid a fatal error, the compiler must have a pattern that
! 973: recognizes such an instruction. Here is what is used:
! 974:
! 975: (define_insn ""
! 976: [(set (match_operand:SI 0 "general_operand" "")
! 977: (and:SI (match_dup 0)
! 978: (match_operand:SI 1 "general_operand" "")))]
! 979: "GET_CODE (operands[1]) == CONST_INT"
! 980: "*
! 981: { operands[1]
! 982: = gen_rtx (CONST_INT, VOIDmode, ~INTVAL (operands[1]));
! 983: return \"bicl2 %1,%0\";
! 984: }")
! 985:
! 986: Whereas a pattern to match a general `and' instruction is impossible
! 987: to support on the Vax, this pattern is possible because it matches
! 988: only a constant second argument: a special case that can be output as
! 989: an `and not' instruction.
! 990:
! 991: A ``compare'' instruction whose RTL looks like this:
! 992:
! 993: (set (cc0) (compare OPERAND (const_int 0)))
! 994:
! 995: may be simplified by optimization into a ``test'' like this:
! 996:
! 997: (set (cc0) OPERAND)
! 998:
! 999: So in the machine description, each ``compare'' pattern for an
! 1000: integer mode must have a corresponding ``test'' pattern that will
! 1001: match the result of such simplification.
! 1002:
! 1003: In some cases machines support instructions identical except for the
! 1004: machine mode of one or more operands. For example, there may be
! 1005: ``sign-extend halfword'' and ``sign-extend byte'' instructions whose
! 1006: patterns are
! 1007:
! 1008: (set (match_operand:SI 0 ...)
! 1009: (extend:SI (match_operand:HI 1 ...)))
! 1010:
! 1011: (set (match_operand:SI 0 ...)
! 1012: (extend:SI (match_operand:QI 1 ...)))
! 1013:
! 1014: Constant integers do not specify a machine mode, so an instruction to
! 1015: extend a constant value could match either pattern. The pattern it
! 1016: actually will match is the one that appears first in the file. For
! 1017: correct results, this must be the one for the widest possible mode
! 1018: (`HImode', here). If the pattern matches the `QImode' instruction,
! 1019: the results will be incorrect if the constant value does not actually
! 1020: fit that mode.
! 1021:
! 1022: Such instructions to extend constants are rarely generated because
! 1023: they are optimized away, but they do occasionally happen in
! 1024: nonoptimized compilations.
! 1025:
! 1026: When an instruction has the constraint letter `o', the reload pass
! 1027: may generate instructions which copy a nonoffsettable address into an
! 1028: index register. The idea is that the register can be used as a
! 1029: replacement offsettable address. In order for these generated
! 1030: instructions to work, there must be patterns to copy any kind of
! 1031: valid address into a register.
! 1032:
! 1033: Most older machine designs have ``load address'' instructions which
! 1034: do just what is needed here. Some RISC machines do not advertise
! 1035: such instructions, but the possible addresses on these machines are
! 1036: very limited, so it is easy to fake them.
! 1037:
! 1038: Auto-increment and auto-decrement addresses are an exception; there
! 1039: need not be an instruction that can copy such an address into a
! 1040: register, because reload handles these cases in a different manner.
! 1041:
! 1042:
! 1043:
! 1044: File: gcc.info, Node: Jump Patterns, Next: Peephole Definitions, Prev: Dependent Patterns, Up: Machine Desc
! 1045:
! 1046: Defining Jump Instruction Patterns
! 1047: ==================================
! 1048:
! 1049: GNU CC assumes that the machine has a condition code. A comparison
! 1050: insn sets the condition code, recording the results of both signed
! 1051: and unsigned comparison of the given operands. A separate branch
! 1052: insn tests the condition code and branches or not according its
! 1053: value. The branch insns come in distinct signed and unsigned
! 1054: flavors. Many common machines, such as the Vax, the 68000 and the
! 1055: 32000, work this way.
! 1056:
! 1057: Some machines have distinct signed and unsigned compare instructions,
! 1058: and only one set of conditional branch instructions. The easiest way
! 1059: to handle these machines is to treat them just like the others until
! 1060: the final stage where assembly code is written. At this time, when
! 1061: outputting code for the compare instruction, peek ahead at the
! 1062: following branch using `NEXT_INSN (insn)'. (The variable `insn'
! 1063: refers to the insn being output, in the output-writing code in an
! 1064: instruction pattern.) If the RTL says that is an unsigned branch,
! 1065: output an unsigned compare; otherwise output a signed compare. When
! 1066: the branch itself is output, you can treat signed and unsigned
! 1067: branches identically.
! 1068:
! 1069: The reason you can do this is that GNU CC always generates a pair of
! 1070: consecutive RTL insns, one to set the condition code and one to test
! 1071: it, and keeps the pair inviolate until the end.
! 1072:
! 1073: To go with this technique, you must define the machine-description
! 1074: macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no
! 1075: compare instruction is superfluous.
! 1076:
! 1077: Some machines have compare-and-branch instructions and no condition
! 1078: code. A similar technique works for them. When it is time to
! 1079: ``output'' a compare instruction, record its operands in two static
! 1080: variables. When outputting the branch-on-condition-code instruction
! 1081: that follows, actually output a compare-and-branch instruction that
! 1082: uses the remembered operands.
! 1083:
! 1084: It also works to define patterns for compare-and-branch instructions.
! 1085: In optimizing compilation, the pair of compare and branch
! 1086: instructions will be combined according to these patterns. But this
! 1087: does not happen if optimization is not requested. So you must use
! 1088: one of the solutions above in addition to any special patterns you
! 1089: define.
1.1 root 1090:
1091:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.