![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-8 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-8 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 root 26:
27:
28:
1.1.1.3 ! root 29: File: gcc.info, Node: Peephole Definitions, Next: Expander Definitions, Prev: Jump Patterns, Up: Machine Desc
1.1.1.2 root 30:
1.1.1.3 ! root 31: Defining Machine-Specific Peephole Optimizers
! 32: =============================================
1.1.1.2 root 33:
1.1.1.3 ! root 34: In addition to instruction patterns the `md' file may contain
! 35: definitions of machine-specific peephole optimizations.
1.1.1.2 root 36:
1.1.1.3 ! root 37: The combiner does not notice certain peephole optimizations when the
! 38: data flow in the program does not suggest that it should try them.
! 39: For example, sometimes two consecutive insns related in purpose can
! 40: be combined even though the second one does not appear to use a
! 41: register computed in the first one. A machine-specific peephole
! 42: optimizer can detect such opportunities.
! 43:
! 44: A definition looks like this:
! 45:
! 46: (define_peephole
! 47: [INSN-PATTERN-1
! 48: INSN-PATTERN-2
! 49: ...]
! 50: "CONDITION"
! 51: "TEMPLATE"
! 52: "MACHINE-SPECIFIC INFO")
! 53:
! 54: The last string operand may be omitted if you are not using any
! 55: machine-specific information in this machine description. If
! 56: present, it must obey the same rules as in a `define_insn'.
! 57:
! 58: In this skeleton, INSN-PATTERN-1 and so on are patterns to match
! 59: consecutive insns. The optimization applies to a sequence of insns
! 60: when INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the
! 61: next, and so on.
! 62:
! 63: Each of the insns matched by a peephole must also match a
! 64: `define_insn'. Peepholes are checked only at the last stage just
! 65: before code generation, and only optionally. Therefore, any insn
! 66: which would match a peephole but no `define_insn' will cause a crash
! 67: in code generation in an unoptimized compilation, or at various
! 68: optimization stages.
! 69:
! 70: The operands of the insns are matched with `match_operands' and
! 71: `match_dup', as usual. What is not usual is that the operand numbers
! 72: apply to all the insn patterns in the definition. So, you can check
! 73: for identical operands in two insns by using `match_operand' in one
! 74: insn and `match_dup' in the other.
! 75:
! 76: The operand constraints used in `match_operand' patterns do not have
! 77: any direct effect on the applicability of the peephole, but they will
! 78: be validated afterward, so make sure your constraints are general
! 79: enough to apply whenever the peephole matches. If the peephole
! 80: matches but the constraints are not satisfied, the compiler will crash.
! 81:
! 82: It is safe to omit constraints in all the operands of the peephole;
! 83: or you can write constraints which serve as a double-check on the
! 84: criteria previously tested.
! 85:
! 86: Once a sequence of insns matches the patterns, the CONDITION is
! 87: checked. This is a C expression which makes the final decision
! 88: whether to perform the optimization (we do so if the expression is
! 89: nonzero). If CONDITION is omitted (in other words, the string is
! 90: empty) then the optimization is applied to every sequence of insns
! 91: that matches the patterns.
! 92:
! 93: The defined peephole optimizations are applied after register
! 94: allocation is complete. Therefore, the peephole definition can check
! 95: which operands have ended up in which kinds of registers, just by
! 96: looking at the operands.
! 97:
! 98: The way to refer to the operands in CONDITION is to write
! 99: `operands[I]' for operand number I (as matched by `(match_operand I
! 100: ...)'). Use the variable `insn' to refer to the last of the insns
! 101: being matched; use `PREV_INSN' to find the preceding insns (but be
! 102: careful to skip over any `note' insns that intervene).
! 103:
! 104: When optimizing computations with intermediate results, you can use
! 105: CONDITION to match only when the intermediate results are not used
! 106: elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where
! 107: INSN is the insn in which you expect the value to be used for the
! 108: last time (from the value of `insn', together with use of
! 109: `PREV_INSN'), and OP is the intermediate value (from `operands[I]').
! 110:
! 111: Applying the optimization means replacing the sequence of insns with
! 112: one new insn. The TEMPLATE controls ultimate output of assembler
! 113: code for this combined insn. It works exactly like the template of a
! 114: `define_insn'. Operand numbers in this template are the same ones
! 115: used in matching the original sequence of insns.
! 116:
! 117: The result of a defined peephole optimizer does not need to match any
! 118: of the insn patterns in the machine description; it does not even
! 119: have an opportunity to match them. The peephole optimizer definition
! 120: itself serves as the insn pattern to control how the insn is output.
! 121:
! 122: Defined peephole optimizers are run as assembler code is being
! 123: output, so the insns they produce are never combined or rearranged in
! 124: any way.
! 125:
! 126: Here is an example, taken from the 68000 machine description:
! 127:
! 128: (define_peephole
! 129: [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4)))
! 130: (set (match_operand:DF 0 "register_operand" "f")
! 131: (match_operand:DF 1 "register_operand" "ad"))]
! 132: "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
! 133: "*
! 134: {
! 135: rtx xoperands[2];
! 136: xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1);
! 137: #ifdef MOTOROLA
! 138: output_asm_insn (\"move.l %1,(sp)\", xoperands);
! 139: output_asm_insn (\"move.l %1,-(sp)\", operands);
! 140: return \"fmove.d (sp)+,%0\";
! 141: #else
! 142: output_asm_insn (\"movel %1,sp@\", xoperands);
! 143: output_asm_insn (\"movel %1,sp@-\", operands);
! 144: return \"fmoved sp@+,%0\";
! 145: #endif
! 146: }
! 147: ")
! 148:
! 149: The effect of this optimization is to change
! 150:
! 151: jbsr _foobar
! 152: addql #4,sp
! 153: movel d1,sp@-
! 154: movel d0,sp@-
! 155: fmoved sp@+,fp0
! 156:
! 157: into
! 158:
! 159: jbsr _foobar
! 160: movel d1,sp@
! 161: movel d0,sp@-
! 162: fmoved sp@+,fp0
! 163:
! 164: INSN-PATTERN-1 and so on look *almost* like the second operand of
! 165: `define_insn'. There is one important difference: the second operand
! 166: of `define_insn' consists of one or more RTX's enclosed in square
! 167: brackets. Usually, there is only one: then the same action can be
! 168: written as an element of a `define_peephole'. But when there are
! 169: multiple actions in a `define_insn', they are implicitly enclosed in
! 170: a `parallel'. Then you must explicitly write the `parallel', and the
! 171: square brackets within it, in the `define_peephole'. Thus, if an
! 172: insn pattern looks like this,
! 173:
! 174: (define_insn "divmodsi4"
! 175: [(set (match_operand:SI 0 "general_operand" "=d")
! 176: (div:SI (match_operand:SI 1 "general_operand" "0")
! 177: (match_operand:SI 2 "general_operand" "dmsK")))
! 178: (set (match_operand:SI 3 "general_operand" "=d")
! 179: (mod:SI (match_dup 1) (match_dup 2)))]
! 180: "TARGET_68020"
! 181: "divsl%.l %2,%3:%0")
! 182:
! 183: then the way to mention this insn in a peephole is as follows:
! 184:
! 185: (define_peephole
! 186: [...
! 187: (parallel
! 188: [(set (match_operand:SI 0 "general_operand" "=d")
! 189: (div:SI (match_operand:SI 1 "general_operand" "0")
! 190: (match_operand:SI 2 "general_operand" "dmsK")))
! 191: (set (match_operand:SI 3 "general_operand" "=d")
! 192: (mod:SI (match_dup 1) (match_dup 2)))])
! 193: ...]
! 194: ...)
1.1.1.2 root 195:
196:
197:
1.1.1.3 ! root 198: File: gcc.info, Node: Expander Definitions, Prev: Peephole Definitions, Up: Machine Desc
1.1.1.2 root 199:
1.1.1.3 ! root 200: Defining RTL Sequences for Code Generation
! 201: ==========================================
1.1.1.2 root 202:
1.1.1.3 ! root 203: On some target machines, some standard pattern names for RTL
! 204: generation cannot be handled with single insn, but a sequence of RTL
! 205: insns can represent them. For these target machines, you can write a
! 206: `define_expand' to specify how to generate the sequence of RTL.
! 207:
! 208: A `define_expand' is an RTL expression that looks almost like a
! 209: `define_insn'; but, unlike the latter, a `define_expand' is used only
! 210: for RTL generation and it can produce more than one RTL insn.
! 211:
! 212: A `define_expand' RTX has four operands:
! 213:
! 214: * The name. Each `define_expand' must have a name, since the only
! 215: use for it is to refer to it by name.
! 216:
! 217: * The RTL template. This is just like the RTL template for a
! 218: `define_peephole' in that it is a vector of RTL expressions each
! 219: being one insn.
! 220:
! 221: * The condition, a string containing a C expression. This
! 222: expression is used to express how the availability of this
! 223: pattern depends on subclasses of target machine, selected by
! 224: command-line options when GNU CC is run. This is just like the
! 225: condition of a `define_insn' that has a standard name.
! 226:
! 227: * The preparation statements, a string containing zero or more C
! 228: statements which are to be executed before RTL code is generated
! 229: from the RTL template.
! 230:
! 231: Usually these statements prepare temporary registers for use as
! 232: internal operands in the RTL template, but they can also
! 233: generate RTL insns directly by calling routines such as
! 234: `emit_insn', etc. Any such insns precede the ones that come
! 235: from the RTL template.
! 236:
! 237: Every RTL insn emitted by a `define_expand' must match some
! 238: `define_insn' in the machine description. Otherwise, the compiler
! 239: will crash when trying to generate code for the insn or trying to
! 240: optimize it.
! 241:
! 242: The RTL template, in addition to controlling generation of RTL insns,
! 243: also describes the operands that need to be specified when this
! 244: pattern is used. In particular, it gives a predicate for each operand.
! 245:
! 246: A true operand, which need to be specified in order to generate RTL
! 247: from the pattern, should be described with a `match_operand' in its
! 248: first occurrence in the RTL template. This enters information on the
! 249: operand's predicate into the tables that record such things. GNU CC
! 250: uses the information to preload the operand into a register if that
! 251: is required for valid RTL code. If the operand is referred to more
! 252: than once, subsequent references should use `match_dup'.
! 253:
! 254: The RTL template may also refer to internal ``operands'' which are
! 255: temporary registers or labels used only within the sequence made by
! 256: the `define_expand'. Internal operands are substituted into the RTL
! 257: template with `match_dup', never with `match_operand'. The values of
! 258: the internal operands are not passed in as arguments by the compiler
! 259: when it requests use of this pattern. Instead, they are computed
! 260: within the pattern, in the preparation statements. These statements
! 261: compute the values and store them into the appropriate elements of
! 262: `operands' so that `match_dup' can find them.
! 263:
! 264: There are two special macros defined for use in the preparation
! 265: statements: `DONE' and `FAIL'. Use them with a following semicolon,
! 266: as a statement.
! 267:
! 268: `DONE'
! 269: Use the `DONE' macro to end RTL generation for the pattern. The
! 270: only RTL insns resulting from the pattern on this occasion will
! 271: be those already emitted by explicit calls to `emit_insn' within
! 272: the preparation statements; the RTL template will not be
! 273: generated.
! 274:
! 275: `FAIL'
! 276: Make the pattern fail on this occasion. When a pattern fails,
! 277: it means that the pattern was not truly available. The calling
! 278: routines in the compiler will try other strategies for code
! 279: generation using other patterns.
! 280:
! 281: Failure is currently supported only for binary operations
! 282: (addition, multiplication, shifting, etc.).
! 283:
! 284: Do not emit any insns explicitly with `emit_insn' before failing.
! 285:
! 286: Here is an example, the definition of left-shift for the SPUR chip:
! 287:
! 288: (define_expand "ashlsi3"
! 289: [(set (match_operand:SI 0 "register_operand" "")
! 290: (ashift:SI
! 291: (match_operand:SI 1 "register_operand" "")
! 292: (match_operand:SI 2 "nonmemory_operand" "")))]
! 293: ""
! 294: "
! 295: {
! 296: if (GET_CODE (operands[2]) != CONST_INT
! 297: || (unsigned) INTVAL (operands[2]) > 3)
! 298: FAIL;
! 299: }")
! 300:
! 301: This example uses `define_expand' so that it can generate an RTL insn
! 302: for shifting when the shift-count is in the supported range of 0 to 3
! 303: but fail in other cases where machine insns aren't available. When
! 304: it fails, the compiler tries another strategy using different
! 305: patterns (such as, a library call).
! 306:
! 307: If the compiler were able to handle nontrivial condition-strings in
! 308: patterns with names, then it would be possible to use a `define_insn'
! 309: in that case. Here is another case (zero-extension on the 68000)
! 310: which makes more use of the power of `define_expand':
! 311:
! 312: (define_expand "zero_extendhisi2"
! 313: [(set (match_operand:SI 0 "general_operand" "")
! 314: (const_int 0))
! 315: (set (strict_low_part
! 316: (subreg:HI
! 317: (match_dup 0)
! 318: 0))
! 319: (match_operand:HI 1 "general_operand" ""))]
! 320: ""
! 321: "operands[1] = make_safe_from (operands[1], operands[0]);")
! 322:
! 323: Here two RTL insns are generated, one to clear the entire output
! 324: operand and the other to copy the input operand into its low half.
! 325: This sequence is incorrect if the input operand refers to [the old
! 326: value of] the output operand, so the preparation statement makes sure
! 327: this isn't so. The function `make_safe_from' copies the
! 328: `operands[1]' into a temporary register if it refers to
! 329: `operands[0]'. It does this by emitting another RTL insn.
! 330:
! 331: Finally, a third example shows the use of an internal operand.
! 332: Zero-extension on the SPUR chip is done by `and'-ing the result
! 333: against a halfword mask. But this mask cannot be represented by a
! 334: `const_int' because the constant value is too large to be legitimate
! 335: on this machine. So it must be copied into a register with
! 336: `force_reg' and then the register used in the `and'.
! 337:
! 338: (define_expand "zero_extendhisi2"
! 339: [(set (match_operand:SI 0 "register_operand" "")
! 340: (and:SI (subreg:SI
! 341: (match_operand:HI 1 "register_operand" "")
! 342: 0)
! 343: (match_dup 2)))]
! 344: ""
! 345: "operands[2]
! 346: = force_reg (SImode, gen_rtx (CONST_INT,
! 347: VOIDmode, 65535)); ")
! 348:
! 349: *Note:* If the `define_expand' is used to serve a standard binary or
! 350: unary arithmetic operation, then the last insn it generates must not
! 351: be a `code_label', `barrier' or `note'. It must be an `insn',
! 352: `jump_insn' or `call_insn'.
1.1.1.2 root 353:
354:
355:
1.1.1.3 ! root 356: File: gcc.info, Node: Machine Macros, Next: Config, Prev: Machine Desc, Up: Top
1.1.1.2 root 357:
1.1.1.3 ! root 358: Machine Description Macros
! 359: **************************
1.1.1.2 root 360:
1.1.1.3 ! root 361: The other half of the machine description is a C header file
! 362: conventionally given the name `tm-MACHINE.h'. The file `tm.h' should
! 363: be a link to it. The header file `config.h' includes `tm.h' and most
! 364: compiler source files include `config.h'.
! 365:
! 366: * Menu:
! 367:
! 368: * Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'.
! 369: * Storage Layout:: Defining sizes and alignments of data types.
! 370: * Registers:: Naming and describing the hardware registers.
! 371: * Register Classes:: Defining the classes of hardware registers.
! 372: * Stack Layout:: Defining which way the stack grows and by how much.
! 373: * Library Names:: Specifying names of subroutines to call automatically.
! 374: * Addressing Modes:: Defining addressing modes valid for memory operands.
! 375: * Delayed Branch:: Do branches execute the following instruction?
! 376: * Condition Code:: Defining how insns update the condition code.
! 377: * Assembler Format:: Defining how to write insns and pseudo-ops to output.
! 378: * Cross-compilation:: Handling floating point for cross-compilers.
! 379: * Misc:: Everything else.
1.1.1.2 root 380:
1.1.1.3 ! root 381:
1.1.1.2 root 382:
1.1.1.3 ! root 383: File: gcc.info, Node: Run-time Target, Next: Storage Layout, Prev: Machine Macros, Up: Machine Macros
1.1.1.2 root 384:
1.1.1.3 ! root 385: Run-time Target Specification
! 386: =============================
1.1.1.2 root 387:
1.1.1.3 ! root 388: `CPP_PREDEFINES'
! 389: Define this to be a string constant containing `-D' options to
! 390: define the predefined macros that identify this machine and
! 391: system. These macros will be predefined unless the `-ansi'
! 392: option is specified.
1.1.1.2 root 393:
1.1.1.3 ! root 394: In addition, a parallel set of macros are predefined, whose
! 395: names are made by appending `__' at the beginning and at the
! 396: end. These `__' macros are permitted by the ANSI standard, so
! 397: they are predefined regardless of whether `-ansi' is specified.
1.1.1.2 root 398:
1.1.1.3 ! root 399: For example, on the Sun, one can use the following value:
! 400:
! 401: "-Dmc68000 -Dsun -Dunix"
1.1 root 402:
1.1.1.3 ! root 403: The result is to define the macros `__mc68000__', `__sun__' and
! 404: `__unix__' unconditionally, and the macros `mc68000', `sun' and
! 405: `unix' provided `-ansi' is not specified.
1.1 root 406:
1.1.1.3 ! root 407: `CPP_SPEC'
1.1 root 408: A C string constant that tells the GNU CC driver program options
1.1.1.3 ! root 409: to pass to CPP. It can also specify how to translate options
! 410: you give to GNU CC into options for GNU CC to pass to the CPP.
1.1 root 411:
412: Do not define this macro if it does not need to do anything.
413:
1.1.1.3 ! root 414: `CC1_SPEC'
1.1 root 415: A C string constant that tells the GNU CC driver program options
1.1.1.3 ! root 416: to pass to CC1. It can also specify how to translate options
! 417: you give to GNU CC into options for GNU CC to pass to the CC1.
1.1 root 418:
419: Do not define this macro if it does not need to do anything.
420:
1.1.1.3 ! root 421: `extern int target_flags;'
! 422: This declaration should be present.
1.1 root 423:
1.1.1.3 ! root 424: `TARGET_...'
! 425: This series of macros is to allow compiler command arguments to
! 426: enable or disable the use of optional features of the target
! 427: machine. For example, one machine description serves both the
! 428: 68000 and the 68020; a command argument tells the compiler
! 429: whether it should use 68020-only instructions or not. This
! 430: command argument works by means of a macro `TARGET_68020' that
! 431: tests a bit in `target_flags'.
! 432:
! 433: Define a macro `TARGET_FEATURENAME' for each such option. Its
! 434: definition should test a bit in `target_flags'; for example:
! 435:
! 436: #define TARGET_68020 (target_flags & 1)
! 437:
! 438: One place where these macros are used is in the
! 439: condition-expressions of instruction patterns. Note how
! 440: `TARGET_68020' appears frequently in the 68000 machine
! 441: description file, `m68k.md'. Another place they are used is in
! 442: the definitions of the other macros in the `tm-MACHINE.h' file.
! 443:
! 444: `TARGET_SWITCHES'
! 445: This macro defines names of command options to set and clear
! 446: bits in `target_flags'. Its definition is an initializer with a
! 447: subgrouping for each command option.
! 448:
! 449: Each subgrouping contains a string constant, that defines the
! 450: option name, and a number, which contains the bits to set in
! 451: `target_flags'. A negative number says to clear bits instead;
! 452: the negative of the number is which bits to clear. The actual
! 453: option name is made by appending `-m' to the specified name.
! 454:
! 455: One of the subgroupings should have a null string. The number
! 456: in this grouping is the default value for `target_flags'. Any
! 457: target options act starting with that value.
! 458:
! 459: Here is an example which defines `-m68000' and `-m68020' with
! 460: opposite meanings, and picks the latter as the default:
! 461:
! 462: #define TARGET_SWITCHES \
! 463: { { "68020", 1}, \
! 464: { "68000", -1}, \
! 465: { "", 1}}
! 466:
! 467: `OVERRIDE_OPTIONS'
! 468: Sometimes certain combinations of command options do not make
! 469: sense on a particular target machine. You can define a macro
! 470: `OVERRIDE_OPTIONS' to take account of this. This macro, if
! 471: defined, is executed once just after all the command options
! 472: have been parsed.
1.1 root 473:
474:
475:
1.1.1.3 ! root 476: File: gcc.info, Node: Storage Layout, Next: Registers, Prev: Run-time Target, Up: Machine Macros
! 477:
! 478: Storage Layout
! 479: ==============
! 480:
! 481: Note that the definitions of the macros in this table which are sizes
! 482: or alignments measured in bits do not need to be constant. They can
! 483: be C expressions that refer to static variables, such as the
! 484: `target_flags'. *Note Run-time Target::.
! 485:
! 486: `BITS_BIG_ENDIAN'
! 487: Define this macro if the most significant bit in a byte has the
! 488: lowest number. This means that bit-field instructions count
! 489: from the most significant bit. If the machine has no bit-field
! 490: instructions, this macro is irrelevant.
! 491:
! 492: This macro does not affect the way structure fields are packed
! 493: into bytes or words; that is controlled by `BYTES_BIG_ENDIAN'.
! 494:
! 495: `BYTES_BIG_ENDIAN'
! 496: Define this macro if the most significant byte in a word has the
! 497: lowest number.
! 498:
! 499: `WORDS_BIG_ENDIAN'
! 500: Define this macro if, in a multiword object, the most
! 501: significant word has the lowest number.
! 502:
! 503: `BITS_PER_UNIT'
! 504: Number of bits in an addressable storage unit (byte); normally 8.
! 505:
! 506: `BITS_PER_WORD'
! 507: Number of bits in a word; normally 32.
! 508:
! 509: `UNITS_PER_WORD'
! 510: Number of storage units in a word; normally 4.
! 511:
! 512: `POINTER_SIZE'
! 513: Width of a pointer, in bits.
! 514:
! 515: `POINTER_BOUNDARY'
! 516: Alignment required for pointers stored in memory, in bits.
! 517:
! 518: `PARM_BOUNDARY'
! 519: Normal alignment required for function parameters on the stack,
! 520: in bits. All stack parameters receive least this much alignment
! 521: regardless of data type. On most machines, this is the same as
! 522: the size of an integer.
! 523:
! 524: `MAX_PARM_BOUNDARY'
! 525: Largest alignment required for any stack parameters, in bits.
! 526: If the data type of the parameter calls for more alignment than
! 527: `PARM_BOUNDARY', then it is given extra padding up to this limit.
! 528:
! 529: Don't define this macro if it would be equal to `PARM_BOUNDARY';
! 530: in other words, if the alignment of a stack parameter should not
! 531: depend on its data type (as is the case on most machines).
! 532:
! 533: `STACK_BOUNDARY'
! 534: Define this macro if you wish to preserve a certain alignment
! 535: for the stack pointer at all times. The definition is a C
! 536: expression for the desired alignment (measured in bits).
! 537:
! 538: `FUNCTION_BOUNDARY'
! 539: Alignment required for a function entry point, in bits.
! 540:
! 541: `BIGGEST_ALIGNMENT'
! 542: Biggest alignment that any data type can require on this
! 543: machine, in bits.
! 544:
! 545: `CONSTANT_ALIGNMENT (CODE, TYPEALIGN)'
! 546: A C expression to compute the alignment for a constant. The
! 547: argument TYPEALIGN is the alignment required for the constant's
! 548: data type. CODE is the tree code of the constant itself.
! 549:
! 550: If this macro is not defined, the default is to use TYPEALIGN.
! 551: If you do define this macro, the value must be a multiple of
! 552: TYPEALIGN.
! 553:
! 554: The purpose of defining this macro is usually to cause string
! 555: constants to be word aligned so that `dhrystone' can be made to
! 556: run faster.
! 557:
! 558: `EMPTY_FIELD_BOUNDARY'
! 559: Alignment in bits to be given to a structure bit field that
! 560: follows an empty field such as `int : 0;'.
! 561:
! 562: `STRUCTURE_SIZE_BOUNDARY'
! 563: Number of bits which any structure or union's size must be a
! 564: multiple of. Each structure or union's size is rounded up to a
! 565: multiple of this.
! 566:
! 567: If you do not define this macro, the default is the same as
! 568: `BITS_PER_UNIT'.
! 569:
! 570: `STRICT_ALIGNMENT'
! 571: Define this if instructions will fail to work if given data not
! 572: on the nominal alignment. If instructions will merely go slower
! 573: in that case, do not define this macro.
! 574:
! 575: `PCC_BITFIELD_TYPE_MATTERS'
! 576: Define this if you wish to imitate a certain bizarre behavior
! 577: pattern of some instances of PCC: a bit field whose declared
! 578: type is `int' has the same effect on the size and alignment of a
! 579: structure as an actual `int' would have.
! 580:
! 581: Just what effect that is in GNU CC depends on other parameters,
! 582: but on most machines it would force the structure's alignment
! 583: and size to a multiple of 32 or `BIGGEST_ALIGNMENT' bits.
! 584:
! 585: `MAX_FIXED_MODE_SIZE'
! 586: An integer expression for the largest integer machine mode that
! 587: should actually be used. All integer machine modes of this size
! 588: or smaller can be used for structures and unions with the
! 589: appropriate sizes.
! 590:
! 591: `CHECK_FLOAT_VALUE (MODE, VALUE)'
! 592: A C statement to validate the value VALUE (or type `double') for
! 593: mode MODE. This means that you check whether VALUE fits within
! 594: the possible range of values for mode MODE on this target
! 595: machine. The mode MODE is always `SFmode' or `DFmode'.
! 596:
! 597: If VALUE is not valid, you should call `error' to print an error
! 598: message and then assign some valid value to VALUE. Allowing an
! 599: invalid value to go through the compiler can produce incorrect
! 600: assembler code which may even cause Unix assemblers to crash.
! 601:
! 602: This macro need not be defined if there is no work for it to do.
! 603:
! 604:
! 605:
! 606: File: gcc.info, Node: Registers, Next: Register Classes, Prev: Storage Layout, Up: Machine Macros
! 607:
! 608: Register Usage
! 609: ==============
! 610:
! 611: `FIRST_PSEUDO_REGISTER'
! 612: Number of hardware registers known to the compiler. They
! 613: receive numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the
! 614: first pseudo register's number really is assigned the number
! 615: `FIRST_PSEUDO_REGISTER'.
! 616:
! 617: `FIXED_REGISTERS'
! 618: An initializer that says which registers are used for fixed
! 619: purposes all throughout the compiled code and are therefore not
! 620: available for general allocation. These would include the stack
! 621: pointer, the frame pointer (except on machines where that can be
! 622: used as a general register when no frame pointer is needed), the
! 623: program counter on machines where that is considered one of the
! 624: addressable registers, and any other numbered register with a
! 625: standard use.
! 626:
! 627: This information is expressed as a sequence of numbers,
! 628: separated by commas and surrounded by braces. The Nth number is
! 629: 1 if register N is fixed, 0 otherwise.
! 630:
! 631: The table initialized from this macro, and the table initialized
! 632: by the following one, may be overridden at run time either
! 633: automatically, by the actions of the macro
! 634: `CONDITIONAL_REGISTER_USAGE', or by the user with the command
! 635: options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'.
! 636:
! 637: `CALL_USED_REGISTERS'
! 638: Like `FIXED_REGISTERS' but has 1 for each register that is
! 639: clobbered (in general) by function calls as well as for fixed
! 640: registers. This macro therefore identifies the registers that
! 641: are not available for general allocation of values that must
! 642: live across function calls.
! 643:
! 644: If a register has 0 in `CALL_USED_REGISTERS', the compiler
! 645: automatically saves it on function entry and restores it on
! 646: function exit, if the register is used within the function.
! 647:
! 648: `DEFAULT_CALLER_SAVES'
! 649: Define this macro if function calls on the target machine do not
! 650: preserve any registers; in other words, if `CALL_USED_REGISTERS'
! 651: has 1 for all registers. This macro enables `-fcaller-saves' by
! 652: default. Eventually that option will be enabled by default on
! 653: all machines and both the option and this macro will be
! 654: eliminated.
! 655:
! 656: `CONDITIONAL_REGISTER_USAGE'
! 657: Zero or more C statements that may conditionally modify two
! 658: variables `fixed_regs' and `call_used_regs' (both of type `char
! 659: []') after they have been initialized from the two preceding
! 660: macros.
! 661:
! 662: This is necessary in case the fixed or call-clobbered registers
! 663: depend on target flags.
! 664:
! 665: You need not define this macro if it has no work to do.
! 666:
! 667: If the usage of an entire class of registers depends on the
! 668: target flags, you may indicate this to GCC by using this macro
! 669: to modify `fixed_regs' and `call_used_regs' to 1 for each of the
! 670: registers in the classes which should not be used by GCC. Also
! 671: define the macro `REG_CLASS_FROM_LETTER' to return `NO_REGS' if
! 672: it is called with a letter for a class that shouldn't be used.
! 673:
! 674: (However, if this class is not included in `GENERAL_REGS' and
! 675: all of the insn patterns whose constraints permit this class are
! 676: controlled by target switches, then GCC will automatically avoid
! 677: using these registers when the target switches are opposed to
! 678: them.)
! 679:
! 680: `OVERLAPPING_REGNO_P (REGNO)'
! 681: If defined, this is a C expression whose value is nonzero if
! 682: hard register number REGNO is an overlapping register. This
! 683: means a hard register which overlaps a hard register with a
! 684: different number. (Such overlap is undesirable, but
! 685: occasionally it allows a machine to be supported which otherwise
! 686: could not be.) This macro must return nonzero for *all* the
! 687: registers which overlap each other. GNU CC can use an
! 688: overlapping register only in certain limited ways. It can be
! 689: used for allocation within a basic block, and may be spilled for
! 690: reloading; that is all.
! 691:
! 692: If this macro is not defined, it means that none of the hard
! 693: registers overlap each other. This is the usual situation.
! 694:
! 695: `INSN_CLOBBERS_REGNO_P (INSN, REGNO)'
! 696: If defined, this is a C expression whose value should be nonzero
! 697: if the insn INSN has the effect of mysteriously clobbering the
! 698: contents of hard register number REGNO. By ``mysterious'' we
! 699: mean that the insn's RTL expression doesn't describe such an
! 700: effect.
! 701:
! 702: If this macro is not defined, it means that no insn clobbers
! 703: registers mysteriously. This is the usual situation; all else
! 704: being equal, it is best for the RTL expression to show all the
! 705: activity.
! 706:
! 707: `PRESERVE_DEATH_INFO_REGNO_P (REGNO)'
! 708: If defined, this is a C expression whose value is nonzero if
! 709: accurate `REG_DEAD' notes are needed for hard register number
! 710: REGNO at the time of outputting the assembler code. When this
! 711: is so, a few optimizations that take place after register
! 712: allocation and could invalidate the death notes are not done
! 713: when this register is involved.
! 714:
! 715: You would arrange to preserve death info for a register when
! 716: some of the code in the machine description which is executed to
! 717: write the assembler code looks at the death notes. This is
! 718: necessary only when the actual hardware feature which GNU CC
! 719: thinks of as a register is not actually a register of the usual
! 720: sort. (It might, for example, be a hardware stack.)
! 721:
! 722: If this macro is not defined, it means that no death notes need
! 723: to be preserved. This is the usual situation.
! 724:
! 725: `HARD_REGNO_REGS (REGNO, MODE)'
! 726: A C expression for the number of consecutive hard registers,
! 727: starting at register number REGNO, required to hold a value of
! 728: mode MODE.
! 729:
! 730: On a machine where all registers are exactly one word, a
! 731: suitable definition of this macro is
! 732:
! 733: #define HARD_REGNO_NREGS(REGNO, MODE) \
! 734: ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
! 735: / UNITS_PER_WORD))
! 736:
! 737: `HARD_REGNO_MODE_OK (REGNO, MODE)'
! 738: A C expression that is nonzero if it is permissible to store a
! 739: value of mode MODE in hard register number REGNO (or in several
! 740: registers starting with that one). For a machine where all
! 741: registers are equivalent, a suitable definition is
! 742:
! 743: #define HARD_REGNO_MODE_OK(REGNO, MODE) 1
! 744:
! 745: It is not necessary for this macro to check for the numbers of
! 746: fixed registers, because the allocation mechanism considers them
! 747: to be always occupied.
! 748:
! 749: On some machines, double-precision values must be kept in
! 750: even/odd register pairs. The way to implement that is to define
! 751: this macro to reject odd register numbers for such modes.
! 752:
! 753: GNU CC assumes that it can always move values between registers
! 754: and (suitably addressed) memory locations. If it is impossible
! 755: to move a value of a certain mode between memory and certain
! 756: registers, then `HARD_REGNO_MODE_OK' must not allow this mode in
! 757: those registers.
! 758:
! 759: Many machines have special registers for floating point
! 760: arithmetic. Often people assume that floating point machine
! 761: modes are allowed only in floating point registers. This is not
! 762: true. Any registers that can hold integers can safely *hold* a
! 763: floating point machine mode, whether or not floating arithmetic
! 764: can be done on it in those registers.
! 765:
! 766: On some machines, though, the converse is true: fixed-point
! 767: machine modes may not go in floating registers. This is true if
! 768: the floating registers normalize any value stored in them,
! 769: because storing a non-floating value there would garble it. In
! 770: this case, `HARD_REGNO_MODE_OK' should reject fixed-point
! 771: machine modes in floating registers. But if the floating
! 772: registers do not automatically normalize, if you can store any
! 773: bit pattern in one and retrieve it unchanged without a trap,
! 774: then any machine mode may go in a floating register and this
! 775: macro should say so.
! 776:
! 777: The primary significance of special floating registers is rather
! 778: that they are the registers acceptable in floating point
! 779: arithmetic instructions. However, this is of no concern to
! 780: `HARD_REGNO_MODE_OK'. You handle it by writing the proper
! 781: constraints for those instructions.
! 782:
! 783: On some machines, the floating registers are especially slow to
! 784: access, so that it is better to store a value in a stack frame
! 785: than in such a register if floating point arithmetic is not
! 786: being done. As long as the floating registers are not in class
! 787: `GENERAL_REGS', they will not be used unless some insn's
! 788: constraint asks for one.
! 789:
! 790: `MODES_TIEABLE_P (MODE1, MODE2)'
! 791: A C expression that is nonzero if it is desirable to choose
! 792: register allocation so as to avoid move instructions between a
! 793: value of mode MODE1 and a value of mode MODE2.
! 794:
! 795: If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R,
! 796: MODE2)' are ever different for any R, then `MODES_TIEABLE_P
! 797: (MODE1, MODE2)' must be zero.
! 798:
! 799: `PC_REGNUM'
! 800: If the program counter has a register number, define this as
! 801: that register number. Otherwise, do not define it.
! 802:
! 803: `STACK_POINTER_REGNUM'
! 804: The register number of the stack pointer register, which must
! 805: also be a fixed register according to `FIXED_REGISTERS'. On
! 806: many machines, the hardware determines which register this is.
! 807:
! 808: `FRAME_POINTER_REGNUM'
! 809: The register number of the frame pointer register, which is used
! 810: to access automatic variables in the stack frame. On some
! 811: machines, the hardware determines which register this is. On
! 812: other machines, you can choose any register you wish for this
! 813: purpose.
! 814:
! 815: `FRAME_POINTER_REQUIRED'
! 816: A C expression which is nonzero if a function must have and use
! 817: a frame pointer. This expression is evaluated twice: at the
! 818: beginning of generating RTL, and in the reload pass. If its
! 819: value is nonzero at either time, then the function will have a
! 820: frame pointer.
! 821:
! 822: The expression can in principle examine the current function and
! 823: decide according to the facts, but on most machines the constant
! 824: 0 or the constant 1 suffices. Use 0 when the machine allows
! 825: code to be generated with no frame pointer, and doing so saves
! 826: some time or space. Use 1 when there is no possible advantage
! 827: to avoiding a frame pointer.
! 828:
! 829: In certain cases, the compiler does not know how to produce
! 830: valid code without a frame pointer. The compiler recognizes
! 831: those cases and automatically gives the function a frame pointer
! 832: regardless of what `FRAME_POINTER_REQUIRED' says. You don't
! 833: need to worry about them.
! 834:
! 835: In a function that does not require a frame pointer, the frame
! 836: pointer register can be allocated for ordinary usage, unless you
! 837: mark it as a fixed register. See `FIXED_REGISTERS' for more
! 838: information.
! 839:
! 840: `ARG_POINTER_REGNUM'
! 841: The register number of the arg pointer register, which is used
! 842: to access the function's argument list. On some machines, this
! 843: is the same as the frame pointer register. On some machines,
! 844: the hardware determines which register this is. On other
! 845: machines, you can choose any register you wish for this purpose.
! 846: If this is not the same register as the frame pointer register,
! 847: then you must mark it as a fixed register according to
! 848: `FIXED_REGISTERS'.
! 849:
! 850: `STATIC_CHAIN_REGNUM'
! 851: The register number used for passing a function's static chain
! 852: pointer. This is needed for languages such as Pascal and Algol
! 853: where functions defined within other functions can access the
! 854: local variables of the outer functions; it is not currently used
! 855: because C does not provide this feature, but you must define the
! 856: macro.
! 857:
! 858: The static chain register need not be a fixed register.
! 859:
! 860: `STRUCT_VALUE_REGNUM'
! 861: When a function's value's mode is `BLKmode', the value is not
! 862: returned according to `FUNCTION_VALUE'. Instead, the caller
! 863: passes the address of a block of memory in which the value
! 864: should be stored.
! 865:
! 866: If this value is passed in a register, then
! 867: `STRUCT_VALUE_REGNUM' should be the number of that register.
! 868:
! 869: `STRUCT_VALUE'
! 870: If the structure value address is not passed in a register,
! 871: define `STRUCT_VALUE' as an expression returning an RTX for the
! 872: place where the address is passed. If it returns a `mem' RTX,
! 873: the address is passed as an ``invisible'' first argument.
! 874:
! 875: `STRUCT_VALUE_INCOMING_REGNUM'
! 876: On some architectures the place where the structure value
! 877: address is found by the called function is not the same place
! 878: that the caller put it. This can be due to register windows, or
! 879: it could be because the function prologue moves it to a
! 880: different place.
! 881:
! 882: If the incoming location of the structure value address is in a
! 883: register, define this macro as the register number.
! 884:
! 885: `STRUCT_VALUE_INCOMING'
! 886: If the incoming location is not a register, define
! 887: `STRUCT_VALUE_INCOMING' as an expression for an RTX for where
! 888: the called function should find the value. If it should find
! 889: the value on the stack, define this to create a `mem' which
! 890: refers to the frame pointer. If the value is a `mem', the
! 891: compiler assumes it is for an invisible first argument, and
! 892: leaves space for it when finding the first real argument.
! 893:
! 894: `REG_ALLOC_ORDER'
! 895: If defined, an initializer for a vector of integers, containing
! 896: the numbers of hard registers in the order in which the GNU CC
! 897: should prefer to use them (from most preferred to least).
! 898:
! 899: If this macro is not defined, registers are used lowest numbered
! 900: first (all else being equal).
! 901:
! 902: One use of this macro is on the 360, where the highest numbered
! 903: registers must always be saved and the save-multiple-registers
! 904: instruction supports only sequences of consecutive registers.
! 905: This macro is defined to cause the highest numbered allocatable
! 906: registers to be used first.
! 907:
! 908:
! 909:
! 910: File: gcc.info, Node: Register Classes, Next: Stack Layout, Prev: Registers, Up: Machine Macros
! 911:
! 912: Register Classes
! 913: ================
! 914:
! 915: On many machines, the numbered registers are not all equivalent. For
! 916: example, certain registers may not be allowed for indexed addressing;
! 917: certain registers may not be allowed in some instructions. These
! 918: machine restrictions are described to the compiler using "register
! 919: classes".
! 920:
! 921: You define a number of register classes, giving each one a name and
! 922: saying which of the registers belong to it. Then you can specify
! 923: register classes that are allowed as operands to particular
! 924: instruction patterns.
! 925:
! 926: In general, each register will belong to several classes. In fact,
! 927: one class must be named `ALL_REGS' and contain all the registers.
! 928: Another class must be named `NO_REGS' and contain no registers.
! 929: Often the union of two classes will be another class; however, this
! 930: is not required.
! 931:
! 932: One of the classes must be named `GENERAL_REGS'. There is nothing
! 933: terribly special about the name, but the operand constraint letters
! 934: `r' and `g' specify this class. If `GENERAL_REGS' is the same as
! 935: `ALL_REGS', just define it as a macro which expands to `ALL_REGS'.
! 936:
! 937: The way classes other than `GENERAL_REGS' are specified in operand
! 938: constraints is through machine-dependent operand constraint letters.
! 939: You can define such letters to correspond to various classes, then
! 940: use them in operand constraints.
! 941:
! 942: You should define a class for the union of two classes whenever some
! 943: instruction allows both classes. For example, if an instruction
! 944: allows either a floating-point (coprocessor) register or a general
! 945: register for a certain operand, you should define a class
! 946: `FLOAT_OR_GENERAL_REGS' which includes both of them. Otherwise you
! 947: will get suboptimal code.
! 948:
! 949: You must also specify certain redundant information about the
! 950: register classes: for each class, which classes contain it and which
! 951: ones are contained in it; for each pair of classes, the largest class
! 952: contained in their union.
! 953:
! 954: When a value occupying several consecutive registers is expected in a
! 955: certain class, all the registers used must belong to that class.
! 956: Therefore, register classes cannot be used to enforce a requirement
! 957: for a register pair to start with an even-numbered register. The way
! 958: to specify this requirement is with `HARD_REGNO_MODE_OK'.
! 959:
! 960: Register classes used for input-operands of bitwise-and or shift
! 961: instructions have a special requirement: each such class must have,
! 962: for each fixed-point machine mode, a subclass whose registers can
! 963: transfer that mode to or from memory. For example, on some machines,
! 964: the operations for single-byte values (`QImode') are limited to
! 965: certain registers. When this is so, each register class that is used
! 966: in a bitwise-and or shift instruction must have a subclass consisting
! 967: of registers from which single-byte values can be loaded or stored.
! 968: This is so that `PREFERRED_RELOAD_CLASS' can always have a possible
! 969: value to return.
! 970:
! 971: `enum reg_class'
! 972: An enumeral type that must be defined with all the register
! 973: class names as enumeral values. `NO_REGS' must be first.
! 974: `ALL_REGS' must be the last register class, followed by one more
! 975: enumeral value, `LIM_REG_CLASSES', which is not a register class
! 976: but rather tells how many classes there are.
! 977:
! 978: Each register class has a number, which is the value of casting
! 979: the class name to type `int'. The number serves as an index in
! 980: many of the tables described below.
! 981:
! 982: `N_REG_CLASSES'
! 983: The number of distinct register classes, defined as follows:
! 984:
! 985: #define N_REG_CLASSES (int) LIM_REG_CLASSES
! 986:
! 987: `REG_CLASS_NAMES'
! 988: An initializer containing the names of the register classes as C
! 989: string constants. These names are used in writing some of the
! 990: debugging dumps.
! 991:
! 992: `REG_CLASS_CONTENTS'
! 993: An initializer containing the contents of the register classes,
! 994: as integers which are bit masks. The Nth integer specifies the
! 995: contents of class N. The way the integer MASK is interpreted is
! 996: that register R is in the class if `MASK & (1 << R)' is 1.
! 997:
! 998: When the machine has more than 32 registers, an integer does not
! 999: suffice. Then the integers are replaced by sub-initializers,
! 1000: braced groupings containing several integers. Each
! 1001: sub-initializer must be suitable as an initializer for the type
! 1002: `HARD_REG_SET' which is defined in `hard-reg-set.h'.
! 1003:
! 1004: `REGNO_REG_CLASS (REGNO)'
! 1005: A C expression whose value is a register class containing hard
! 1006: register REGNO. In general there is more that one such class;
! 1007: choose a class which is "minimal", meaning that no smaller class
! 1008: also contains the register.
! 1009:
! 1010: `BASE_REG_CLASS'
! 1011: A macro whose definition is the name of the class to which a
! 1012: valid base register must belong. A base register is one used in
! 1013: an address which is the register value plus a displacement.
! 1014:
! 1015: `INDEX_REG_CLASS'
! 1016: A macro whose definition is the name of the class to which a
! 1017: valid index register must belong. An index register is one used
! 1018: in an address where its value is either multiplied by a scale
! 1019: factor or added to another register (as well as added to a
! 1020: displacement).
! 1021:
! 1022: `REG_CLASS_FROM_LETTER (CHAR)'
! 1023: A C expression which defines the machine-dependent operand
! 1024: constraint letters for register classes. If CHAR is such a
! 1025: letter, the value should be the register class corresponding to
! 1026: it. Otherwise, the value should be `NO_REGS'.
! 1027:
! 1028: `REGNO_OK_FOR_BASE_P (NUM)'
! 1029: A C expression which is nonzero if register number NUM is
! 1030: suitable for use as a base register in operand addresses. It
! 1031: may be either a suitable hard register or a pseudo register that
! 1032: has been allocated such a hard register.
! 1033:
! 1034: `REGNO_OK_FOR_INDEX_P (NUM)'
! 1035: A C expression which is nonzero if register number NUM is
! 1036: suitable for use as an index register in operand addresses. It
! 1037: may be either a suitable hard register or a pseudo register that
! 1038: has been allocated such a hard register.
! 1039:
! 1040: The difference between an index register and a base register is
! 1041: that the index register may be scaled. If an address involves
! 1042: the sum of two registers, neither one of them scaled, then
! 1043: either one may be labeled the ``base'' and the other the
! 1044: ``index''; but whichever labeling is used must fit the machine's
! 1045: constraints of which registers may serve in each capacity. The
! 1046: compiler will try both labelings, looking for one that is valid,
! 1047: and will reload one or both registers only if neither labeling
! 1048: works.
1.1 root 1049:
1.1.1.3 ! root 1050: `PREFERRED_RELOAD_CLASS (X, CLASS)'
! 1051: A C expression that places additional restrictions on the
! 1052: register class to use when it is necessary to copy value X into
! 1053: a register in class CLASS. The value is a register class;
! 1054: perhaps CLASS, or perhaps another, smaller class. On many
! 1055: machines, the definition
! 1056:
! 1057: #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
! 1058:
! 1059: is safe.
! 1060:
! 1061: Sometimes returning a more restrictive class makes better code.
! 1062: For example, on the 68000, when X is an integer constant that is
! 1063: in range for a `moveq' instruction, the value of this macro is
! 1064: always `DATA_REGS' as long as CLASS includes the data registers.
! 1065: Requiring a data register guarantees that a `moveq' will be used.
! 1066:
! 1067: If X is a `const_double', by returning `NO_REGS' you can force X
! 1068: into a memory constant. This is useful on certain machines
! 1069: where immediate floating values cannot be loaded into certain
! 1070: kinds of registers.
! 1071:
! 1072: In a shift instruction or a bitwise-and instruction, the mode of
! 1073: X, the value being reloaded, may not be the same as the mode of
! 1074: the instruction's operand. (They will both be fixed-point
! 1075: modes, however.) In such a case, CLASS may not be a safe value
! 1076: to return. CLASS is certainly valid for the instruction, but it
! 1077: may not be valid for reloading X. This problem can occur on
! 1078: machines such as the 68000 and 80386 where some registers can
! 1079: handle full-word values but cannot handle single-byte values.
! 1080:
! 1081: On such machines, this macro must examine the mode of X and
! 1082: return a subclass of CLASS which can handle loads and stores of
! 1083: that mode. On the 68000, where address registers cannot handle
! 1084: `QImode', if X has `QImode' then you must return `DATA_REGS'.
! 1085: If CLASS is `ADDR_REGS', then there is no correct value to
! 1086: return; but the shift and bitwise-and instructions don't use
! 1087: `ADDR_REGS', so this fatal case never arises.
! 1088:
! 1089: `CLASS_MAX_NREGS (CLASS, MODE)'
! 1090: A C expression for the maximum number of consecutive registers
! 1091: of class CLASS needed to hold a value of mode MODE.
! 1092:
! 1093: This is closely related to the macro `HARD_REGNO_NREGS'. In
! 1094: fact, the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)'
! 1095: should be the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)'
! 1096: for all REGNO values in the class CLASS.
! 1097:
! 1098: This macro helps control the handling of multiple-word values in
! 1099: the reload pass.
! 1100:
! 1101: Two other special macros describe which constants fit which
! 1102: constraint letters.
! 1103:
! 1104: `CONST_OK_FOR_LETTER_P (VALUE, C)'
! 1105: A C expression that defines the machine-dependent operand
! 1106: constraint letters that specify particular ranges of integer
! 1107: values. If C is one of those letters, the expression should
! 1108: check that VALUE, an integer, is in the appropriate range and
! 1109: return 1 if so, 0 otherwise. If C is not one of those letters,
! 1110: the value should be 0 regardless of VALUE.
! 1111:
! 1112: `CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)'
! 1113: A C expression that defines the machine-dependent operand
! 1114: constraint letters that specify particular ranges of floating
! 1115: values. If C is one of those letters, the expression should
! 1116: check that VALUE, an RTX of code `const_double', is in the
! 1117: appropriate range and return 1 if so, 0 otherwise. If C is not
! 1118: one of those letters, the value should be 0 regardless of VALUE.
1.1 root 1119:
1120:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.