![[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:
1.1.1.6 ! root 4: This file documents the use and the internals of the GNU compiler.
1.1 root 5:
1.1.1.6 ! root 6: Copyright (C) 1988, 1989, 1990 Free Software Foundation, Inc.
1.1 root 7:
1.1.1.6 ! root 8: Permission is granted to make and distribute verbatim copies of
! 9: this manual provided the copyright notice and this permission notice
! 10: are preserved on all copies.
1.1 root 11:
1.1.1.6 ! root 12: Permission is granted to copy and distribute modified versions of
1.1 root 13: this manual under the conditions for verbatim copying, provided also
1.1.1.4 root 14: that the sections entitled "GNU General Public License" and "Protect
15: Your Freedom--Fight `Look And Feel'" are included exactly as in the
16: original, and provided that the entire resulting derived work is
17: distributed under the terms of a permission notice identical to this
18: one.
1.1 root 19:
1.1.1.6 ! root 20: Permission is granted to copy and distribute translations of this
1.1 root 21: manual into another language, under the above conditions for modified
1.1.1.4 root 22: versions, except that the sections entitled "GNU General Public
23: License" and "Protect Your Freedom--Fight `Look And Feel'" and this
24: permission notice may be included in translations approved by the
25: Free Software Foundation instead of in the original English.
1.1 root 26:
1.1.1.6 ! root 27:
! 28: File: gcc.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc
! 29:
! 30: Standard Names for Patterns Used in Generation
! 31: ==============================================
! 32:
! 33: Here is a table of the instruction names that are meaningful in
! 34: the RTL generation pass of the compiler. Giving one of these names
! 35: to an instruction pattern tells the RTL generation pass that it can
! 36: use the pattern in to accomplish a certain task.
! 37:
! 38: `movM'
! 39: Here M stands for a two-letter machine mode name, in lower case.
! 40: This instruction pattern moves data with that machine mode from
! 41: operand 1 to operand 0. For example, `movsi' moves full-word
! 42: data.
! 43:
! 44: If operand 0 is a `subreg' with mode M of a register whose own
! 45: mode is wider than M, the effect of this instruction is to store
! 46: the specified value in the part of the register that corresponds
! 47: to mode M. The effect on the rest of the register is undefined.
! 48:
! 49: This class of patterns is special in several ways. First of
! 50: all, each of these names *must* be defined, because there is no
! 51: other way to copy a datum from one place to another.
! 52:
! 53: Second, these patterns are not used solely in the RTL generation
! 54: pass. Even the reload pass can generate move insns to copy
! 55: values from stack slots into temporary registers. When it does
! 56: so, one of the operands is a hard register and the other is an
! 57: operand that can need to be reloaded into a register.
! 58:
! 59: Therefore, when given such a pair of operands, the pattern must
! 60: generate RTL which needs no reloading and needs no temporary
! 61: registers--no registers other than the operands. For example,
! 62: if you support the pattern with a `define_expand', then in such
! 63: a case the `define_expand' mustn't call `force_reg' or any other
! 64: such function which might generate new pseudo registers.
! 65:
! 66: This requirement exists even for subword modes on a RISC machine
! 67: where fetching those modes from memory normally requires several
! 68: insns and some temporary registers. Look in `spur.md' to see
! 69: how the requirement can be satisfied.
! 70:
! 71: The variety of operands that have reloads depends on the rest of
! 72: the machine description, but typically on a RISC machine these
! 73: can only be pseudo registers that did not get hard registers,
! 74: while on other machines explicit memory references will get
! 75: optional reloads.
! 76:
! 77: The constraints on a `moveM' must allow any hard register to be
! 78: moved to any other hard register (provided that
! 79: `HARD_REGNO_MODE_OK' permits mode M in both registers).
! 80:
! 81: It is obligatory to support floating point `moveM' instructions
! 82: into and out of any registers that can hold fixed point values,
! 83: because unions and structures (which have modes `SImode' or
! 84: `DImode') can be in those registers and they may have floating
! 85: point members.
! 86:
! 87: There may also be a need to support fixed point `moveM'
! 88: instructions in and out of floating point registers.
! 89: Unfortunately, I have forgotten why this was so, and I don't
! 90: know whether it is still true. If `HARD_REGNO_MODE_OK' rejects
! 91: fixed point values in floating point registers, then the
! 92: constraints of the fixed point `moveM' instructions must be
! 93: designed to avoid ever trying to reload into a floating point
! 94: register.
! 95:
! 96: `movstrictM'
! 97: Like `movM' except that if operand 0 is a `subreg' with mode M
! 98: of a register whose natural mode is wider, the `movstrictM'
! 99: instruction is guaranteed not to alter any of the register
! 100: except the part which belongs to mode M.
! 101:
! 102: `addM3'
! 103: Add operand 2 and operand 1, storing the result in operand 0.
! 104: All operands must have mode M. This can be used even on
! 105: two-address machines, by means of constraints requiring operands
! 106: 1 and 0 to be the same location.
! 107:
! 108: `subM3', `mulM3', `umulM3', `divM3', `udivM3', `modM3', `umodM3', `andM3', `iorM3', `xorM3'
! 109: Similar, for other arithmetic operations.
! 110:
! 111: There are special considerations for register classes for
! 112: logical-and instructions, affecting also the macro
! 113: `PREFERRED_RELOAD_CLASS'. They apply not only to the patterns
! 114: with these standard names, but to any patterns that will match
! 115: such an instruction. *Note Register Classes::.
! 116:
! 117: `mulhisi3'
! 118: Multiply operands 1 and 2, which have mode `HImode', and store a
! 119: `SImode' product in operand 0.
! 120:
! 121: `mulqihi3', `mulsidi3'
! 122: Similar widening-multiplication instructions of other widths.
! 123:
! 124: `umulqihi3', `umulhisi3', `umulsidi3'
! 125: Similar widening-multiplication instructions that do unsigned
! 126: multiplication.
! 127:
! 128: `divmodM4'
! 129: Signed division that produces both a quotient and a remainder.
! 130: Operand 1 is divided by operand 2 to produce a quotient stored
! 131: in operand 0 and a remainder stored in operand 3.
! 132:
! 133: `udivmodM4'
! 134: Similar, but does unsigned division.
! 135:
! 136: `ashlM3'
! 137: Arithmetic-shift operand 1 left by a number of bits specified by
! 138: operand 2, and store the result in operand 0. Operand 2 has
! 139: mode `SImode', not mode M.
! 140:
! 141: `ashrM3', `lshlM3', `lshrM3', `rotlM3', `rotrM3'
! 142: Other shift and rotate instructions.
! 143:
! 144: Logical and arithmetic left shift are the same. Machines that
! 145: do not allow negative shift counts often have only one
! 146: instruction for shifting left. On such machines, you should
! 147: define a pattern named `ashlM3' and leave `lshlM3' undefined.
! 148:
! 149: There are special considerations for register classes for shift
! 150: instructions, affecting also the macro `PREFERRED_RELOAD_CLASS'.
! 151: They apply not only to the patterns with these standard names,
! 152: but to any patterns that will match such an instruction. *Note
! 153: Register Classes::.
! 154:
! 155: `negM2'
! 156: Negate operand 1 and store the result in operand 0.
! 157:
! 158: `absM2'
! 159: Store the absolute value of operand 1 into operand 0.
! 160:
! 161: `sqrtM2'
! 162: Store the square root of operand 1 into operand 0.
! 163:
! 164: `ffsM2'
! 165: Store into operand 0 one plus the index of the least significant
! 166: 1-bit of operand 1. If operand 1 is zero, store zero. M is the
! 167: mode of operand 0; operand 1's mode is specified by the
! 168: instruction pattern, and the compiler will convert the operand
! 169: to that mode before generating the instruction.
! 170:
! 171: `one_cmplM2'
! 172: Store the bitwise-complement of operand 1 into operand 0.
! 173:
! 174: `cmpM'
! 175: Compare operand 0 and operand 1, and set the condition codes.
! 176: The RTL pattern should look like this:
! 177:
! 178: (set (cc0) (compare (match_operand:M 0 ...)
! 179: (match_operand:M 1 ...)))
! 180:
! 181: Each such definition in the machine description, for integer
! 182: mode M, must have a corresponding `tstM' pattern, because
! 183: optimization can simplify the compare into a test when operand 1
! 184: is zero.
! 185:
! 186: `tstM'
! 187: Compare operand 0 against zero, and set the condition codes.
! 188: The RTL pattern should look like this:
! 189:
! 190: (set (cc0) (match_operand:M 0 ...))
! 191:
! 192: `movstrM'
! 193: Block move instruction. The addresses of the destination and
! 194: source strings are the first two operands, and both are in mode
! 195: `Pmode'. The number of bytes to move is the third operand, in
! 196: mode M. The fourth operand is the known shared alignment of the
! 197: source and destination, in the form of a `const_int' rtx.
! 198:
! 199: `cmpstrM'
! 200: Block compare instruction, with operands like `movstrM' except
! 201: that the two memory blocks are compared byte by byte in
! 202: lexicographic order. The effect of the instruction is to set
! 203: the condition codes.
! 204:
! 205: `floatMN2'
! 206: Convert signed integer operand 1 (valid for fixed point mode M)
! 207: to floating point mode N and store in operand 0 (which has mode
! 208: N).
! 209:
! 210: `floatunsMN2'
! 211: Convert unsigned integer operand 1 (valid for fixed point mode
! 212: M) to floating point mode N and store in operand 0 (which has
! 213: mode N).
! 214:
! 215: `fixMN2'
! 216: Convert operand 1 (valid for floating point mode M) to fixed
! 217: point mode N as a signed number and store in operand 0 (which
! 218: has mode N). This instruction's result is defined only when the
! 219: value of operand 1 is an integer.
! 220:
! 221: `fixunsMN2'
! 222: Convert operand 1 (valid for floating point mode M) to fixed
! 223: point mode N as an unsigned number and store in operand 0 (which
! 224: has mode N). This instruction's result is defined only when the
! 225: value of operand 1 is an integer.
! 226:
! 227: `ftruncM2'
! 228: Convert operand 1 (valid for floating point mode M) to an
! 229: integer value, still represented in floating point mode M, and
! 230: store it in operand 0 (valid for floating point mode M).
! 231:
! 232: `fix_truncMN2'
! 233: Like `fixMN2' but works for any floating point value of mode M
! 234: by converting the value to an integer.
! 235:
! 236: `fixuns_truncMN2'
! 237: Like `fixunsMN2' but works for any floating point value of mode
! 238: M by converting the value to an integer.
! 239:
! 240: `truncMN'
! 241: Truncate operand 1 (valid for mode M) to mode N and store in
! 242: operand 0 (which has mode N). Both modes must be fixed point or
! 243: both floating point.
! 244:
! 245: `extendMN'
! 246: Sign-extend operand 1 (valid for mode M) to mode N and store in
! 247: operand 0 (which has mode N). Both modes must be fixed point or
! 248: both floating point.
! 249:
! 250: `zero_extendMN'
! 251: Zero-extend operand 1 (valid for mode M) to mode N and store in
! 252: operand 0 (which has mode N). Both modes must be fixed point.
! 253:
! 254: `extv'
! 255: Extract a bit-field from operand 1 (a register or memory
! 256: operand), where operand 2 specifies the width in bits and
! 257: operand 3 the starting bit, and store it in operand 0. Operand
! 258: 0 must have `SImode'. Operand 1 may have mode `QImode' or
! 259: `SImode'; often `SImode' is allowed only for registers.
! 260: Operands 2 and 3 must be valid for `SImode'.
! 261:
! 262: The RTL generation pass generates this instruction only with
! 263: constants for operands 2 and 3.
! 264:
! 265: The bit-field value is sign-extended to a full word integer
! 266: before it is stored in operand 0.
! 267:
! 268: `extzv'
! 269: Like `extv' except that the bit-field value is zero-extended.
! 270:
! 271: `insv'
! 272: Store operand 3 (which must be valid for `SImode') into a
! 273: bit-field in operand 0, where operand 1 specifies the width in
! 274: bits and operand 2 the starting bit. Operand 0 may have mode
! 275: `QImode' or `SImode'; often `SImode' is allowed only for
! 276: registers. Operands 1 and 2 must be valid for `SImode'.
! 277:
! 278: The RTL generation pass generates this instruction only with
! 279: constants for operands 1 and 2.
! 280:
! 281: `sCOND'
! 282: Store zero or nonzero in the operand according to the condition
! 283: codes. Value stored is nonzero iff the condition COND is true.
! 284: COND is the name of a comparison operation expression code, such
! 285: as `eq', `lt' or `leu'.
! 286:
! 287: You specify the mode that the operand must have when you write
! 288: the `match_operand' expression. The compiler automatically sees
! 289: which mode you have used and supplies an operand of that mode.
! 290:
! 291: The value stored for a true condition must have 1 as its low
! 292: bit, or else must be negative. Otherwise the instruction is not
! 293: suitable and must be omitted from the machine description. You
! 294: must tell the compiler exactly which value is stored by defining
! 295: the macro `STORE_FLAG_VALUE'.
! 296:
! 297: `bCOND'
! 298: Conditional branch instruction. Operand 0 is a `label_ref' that
! 299: refers to the label to jump to. Jump if the condition codes
! 300: meet condition COND.
! 301:
! 302: `call'
! 303: Subroutine call instruction returning no value. Operand 0 is
! 304: the function to call; operand 1 is the number of bytes of
! 305: arguments pushed (in mode `SImode', except it is normally a
! 306: `const_int'); operand 2 is the number of registers used as
! 307: operands.
! 308:
! 309: On most machines, operand 2 is not actually stored into the RTL
! 310: pattern. It is supplied for the sake of some RISC machines
! 311: which need to put this information into the assembler code; they
! 312: can put it in the RTL instead of operand 1.
! 313:
! 314: Operand 0 should be a `mem' RTX whose address is the address of
! 315: the function.
! 316:
! 317: `call_value'
! 318: Subroutine call instruction returning a value. Operand 0 is the
! 319: hard register in which the value is returned. There are three
! 320: more operands, the same as the three operands of the `call'
! 321: instruction (but with numbers increased by one).
! 322:
! 323: Subroutines that return `BLKmode' objects use the `call' insn.
! 324:
! 325: `return'
! 326: Subroutine return instruction. This instruction pattern name
! 327: should be defined only if a single instruction can do all the
! 328: work of returning from a function.
! 329:
! 330: `nop'
! 331: No-op instruction. This instruction pattern name should always
! 332: be defined to output a no-op in assembler code. `(const_int 0)'
! 333: will do as an RTL pattern.
! 334:
! 335: `casesi'
! 336: Instruction to jump through a dispatch table, including bounds
! 337: checking. This instruction takes five operands:
! 338:
! 339: 1. The index to dispatch on, which has mode `SImode'.
! 340:
! 341: 2. The lower bound for indices in the table, an integer
! 342: constant.
! 343:
! 344: 3. The total range of indices in the table--the largest index
! 345: minus the smallest one (both inclusive).
! 346:
! 347: 4. A label to jump to if the index has a value outside the
! 348: bounds. (If the machine-description macro
! 349: `CASE_DROPS_THROUGH' is defined, then an out-of-bounds
! 350: index drops through to the code following the jump table
! 351: instead of jumping to this label. In that case, this label
! 352: is not actually used by the `casesi' instruction, but it is
! 353: always provided as an operand.)
! 354:
! 355: 5. A label that precedes the table itself.
! 356:
! 357: The table is a `addr_vec' or `addr_diff_vec' inside of a
! 358: `jump_insn'. The number of elements in the table is one plus
! 359: the difference between the upper bound and the lower bound.
! 360:
! 361: `tablejump'
! 362: Instruction to jump to a variable address. This is a low-level
! 363: capability which can be used to implement a dispatch table when
! 364: there is no `casesi' pattern.
! 365:
! 366: This pattern requires two operands: the address or offset, and a
! 367: label which should immediately precede the jump table. If the
! 368: macro `CASE_VECTOR_PC_RELATIVE' is defined then the first
! 369: operand is an offset that counts from the address of the table;
! 370: otherwise, it is an absolute address to jump to.
! 371:
! 372: The `tablejump' insn is always the last insn before the jump
! 373: table it uses. Its assembler code normally has no need to use
! 374: the second operand, but you should incorporate it in the RTL
! 375: pattern so that the jump optimizer will not delete the table as
! 376: unreachable code.
! 377:
! 378:
! 379: File: gcc.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc
! 380:
! 381: When the Order of Patterns Matters
! 382: ==================================
! 383:
! 384: Sometimes an insn can match more than one instruction pattern.
! 385: Then the pattern that appears first in the machine description is the
! 386: one used. Therefore, more specific patterns (patterns that will
! 387: match fewer things) and faster instructions (those that will produce
! 388: better code when they do match) should usually go first in the
! 389: description.
! 390:
! 391: In some cases the effect of ordering the patterns can be used to
! 392: hide a pattern when it is not valid. For example, the 68000 has an
! 393: instruction for converting a fullword to floating point and another
! 394: for converting a byte to floating point. An instruction converting
! 395: an integer to floating point could match either one. We put the
! 396: pattern to convert the fullword first to make sure that one will be
! 397: used rather than the other. (Otherwise a large integer might be
! 398: generated as a single-byte immediate quantity, which would not work.)
! 399: Instead of using this pattern ordering it would be possible to make
! 400: the pattern for convert-a-byte smart enough to deal properly with any
! 401: constant value.
1.1 root 402:
403:
1.1.1.5 root 404: File: gcc.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc
405:
406: Interdependence of Patterns
407: ===========================
408:
1.1.1.6 ! root 409: Every machine description must have a named pattern for each of
! 410: the conditional branch names `bCOND'. The recognition template must
1.1.1.5 root 411: always have the form
412:
413: (set (pc)
414: (if_then_else (COND (cc0) (const_int 0))
415: (label_ref (match_operand 0 "" ""))
416: (pc)))
417:
418: In addition, every machine description must have an anonymous pattern
419: for each of the possible reverse-conditional branches. These
420: patterns look like
421:
422: (set (pc)
423: (if_then_else (COND (cc0) (const_int 0))
424: (pc)
425: (label_ref (match_operand 0 "" ""))))
426:
427: They are necessary because jump optimization can turn
428: direct-conditional branches into reverse-conditional branches.
429:
1.1.1.6 ! root 430: The compiler does more with RTL than just create it from patterns
! 431: and recognize the patterns: it can perform arithmetic expression
! 432: codes when constant values for their operands can be determined. As
! 433: a result, sometimes having one pattern can require other patterns.
! 434: For example, the Vax has no `and' instruction, but it has `and not'
1.1.1.5 root 435: instructions. Here is the definition of one of them:
436:
437: (define_insn "andcbsi2"
438: [(set (match_operand:SI 0 "general_operand" "")
439: (and:SI (match_dup 0)
440: (not:SI (match_operand:SI
441: 1 "general_operand" ""))))]
442: ""
443: "bicl2 %1,%0")
444:
445: If operand 1 is an explicit integer constant, an instruction
446: constructed using that pattern can be simplified into an `and' like
447: this:
448:
449: (set (reg:SI 41)
450: (and:SI (reg:SI 41)
451: (const_int 0xffff7fff)))
452:
453: (where the integer constant is the one's complement of what appeared
454: in the original instruction).
455:
1.1.1.6 ! root 456: To avoid a fatal error, the compiler must have a pattern that
1.1.1.5 root 457: recognizes such an instruction. Here is what is used:
458:
459: (define_insn ""
460: [(set (match_operand:SI 0 "general_operand" "")
461: (and:SI (match_dup 0)
462: (match_operand:SI 1 "general_operand" "")))]
463: "GET_CODE (operands[1]) == CONST_INT"
464: "*
465: { operands[1]
466: = gen_rtx (CONST_INT, VOIDmode, ~INTVAL (operands[1]));
467: return \"bicl2 %1,%0\";
468: }")
469:
470: Whereas a pattern to match a general `and' instruction is impossible
471: to support on the Vax, this pattern is possible because it matches
472: only a constant second argument: a special case that can be output as
473: an `and not' instruction.
474:
1.1.1.6 ! root 475: A "compare" instruction whose RTL looks like this:
1.1.1.5 root 476:
477: (set (cc0) (compare OPERAND (const_int 0)))
478:
479: may be simplified by optimization into a "test" like this:
480:
481: (set (cc0) OPERAND)
482:
483: So in the machine description, each "compare" pattern for an integer
484: mode must have a corresponding "test" pattern that will match the
485: result of such simplification.
486:
1.1.1.6 ! root 487: In some cases machines support instructions identical except for
! 488: the machine mode of one or more operands. For example, there may be
1.1.1.5 root 489: "sign-extend halfword" and "sign-extend byte" instructions whose
490: patterns are
491:
492: (set (match_operand:SI 0 ...)
493: (extend:SI (match_operand:HI 1 ...)))
494:
495: (set (match_operand:SI 0 ...)
496: (extend:SI (match_operand:QI 1 ...)))
497:
498: Constant integers do not specify a machine mode, so an instruction to
499: extend a constant value could match either pattern. The pattern it
500: actually will match is the one that appears first in the file. For
501: correct results, this must be the one for the widest possible mode
502: (`HImode', here). If the pattern matches the `QImode' instruction,
503: the results will be incorrect if the constant value does not actually
504: fit that mode.
505:
1.1.1.6 ! root 506: Such instructions to extend constants are rarely generated because
1.1.1.5 root 507: they are optimized away, but they do occasionally happen in
508: nonoptimized compilations.
509:
1.1.1.6 ! root 510: When an instruction has the constraint letter `o', the reload pass
1.1.1.5 root 511: may generate instructions which copy a nonoffsettable address into an
512: index register. The idea is that the register can be used as a
513: replacement offsettable address. In order for these generated
514: instructions to work, there must be patterns to copy any kind of
515: valid address into a register.
516:
1.1.1.6 ! root 517: Most older machine designs have "load address" instructions which
! 518: do just what is needed here. Some RISC machines do not advertise
! 519: such instructions, but the possible addresses on these machines are
! 520: very limited, so it is easy to fake them.
1.1.1.5 root 521:
1.1.1.6 ! root 522: Auto-increment and auto-decrement addresses are an exception;
! 523: there need not be an instruction that can copy such an address into a
1.1.1.5 root 524: register, because reload handles these cases in a different manner.
525:
526:
527: File: gcc.info, Node: Jump Patterns, Next: Peephole Definitions, Prev: Dependent Patterns, Up: Machine Desc
528:
529: Defining Jump Instruction Patterns
530: ==================================
531:
1.1.1.6 ! root 532: GNU CC assumes that the machine has a condition code. A
! 533: comparison insn sets the condition code, recording the results of
! 534: both signed and unsigned comparison of the given operands. A
! 535: separate branch insn tests the condition code and branches or not
! 536: according its value. The branch insns come in distinct signed and
! 537: unsigned flavors. Many common machines, such as the Vax, the 68000
! 538: and the 32000, work this way.
! 539:
! 540: Some machines have distinct signed and unsigned compare
! 541: instructions, and only one set of conditional branch instructions.
! 542: The easiest way to handle these machines is to treat them just like
! 543: the others until the final stage where assembly code is written. At
! 544: this time, when outputting code for the compare instruction, peek
! 545: ahead at the following branch using `NEXT_INSN (insn)'. (The
! 546: variable `insn' refers to the insn being output, in the
! 547: output-writing code in an instruction pattern.) If the RTL says that
! 548: is an unsigned branch, output an unsigned compare; otherwise output a
! 549: signed compare. When the branch itself is output, you can treat
! 550: signed and unsigned branches identically.
! 551:
! 552: The reason you can do this is that GNU CC always generates a pair
! 553: of consecutive RTL insns, one to set the condition code and one to
! 554: test it, and keeps the pair inviolate until the end.
1.1.1.5 root 555:
1.1.1.6 ! root 556: To go with this technique, you must define the machine-description
1.1.1.5 root 557: macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no
558: compare instruction is superfluous.
559:
1.1.1.6 ! root 560: Some machines have compare-and-branch instructions and no
! 561: condition code. A similar technique works for them. When it is time
! 562: to "output" a compare instruction, record its operands in two static
1.1.1.5 root 563: variables. When outputting the branch-on-condition-code instruction
564: that follows, actually output a compare-and-branch instruction that
565: uses the remembered operands.
566:
1.1.1.6 ! root 567: It also works to define patterns for compare-and-branch
! 568: instructions. In optimizing compilation, the pair of compare and
! 569: branch instructions will be combined according to these patterns.
! 570: But this does not happen if optimization is not requested. So you
! 571: must use one of the solutions above in addition to any special
! 572: patterns you define.
1.1.1.5 root 573:
574:
1.1.1.3 root 575: File: gcc.info, Node: Peephole Definitions, Next: Expander Definitions, Prev: Jump Patterns, Up: Machine Desc
1.1.1.2 root 576:
1.1.1.3 root 577: Defining Machine-Specific Peephole Optimizers
578: =============================================
1.1.1.2 root 579:
1.1.1.6 ! root 580: In addition to instruction patterns the `md' file may contain
1.1.1.3 root 581: definitions of machine-specific peephole optimizations.
1.1.1.2 root 582:
1.1.1.6 ! root 583: The combiner does not notice certain peephole optimizations when
! 584: the data flow in the program does not suggest that it should try
! 585: them. For example, sometimes two consecutive insns related in
! 586: purpose can be combined even though the second one does not appear to
! 587: use a register computed in the first one. A machine-specific
! 588: peephole optimizer can detect such opportunities.
1.1.1.3 root 589:
1.1.1.6 ! root 590: A definition looks like this:
1.1.1.3 root 591:
592: (define_peephole
593: [INSN-PATTERN-1
594: INSN-PATTERN-2
595: ...]
596: "CONDITION"
597: "TEMPLATE"
598: "MACHINE-SPECIFIC INFO")
599:
600: The last string operand may be omitted if you are not using any
601: machine-specific information in this machine description. If
602: present, it must obey the same rules as in a `define_insn'.
603:
1.1.1.6 ! root 604: In this skeleton, INSN-PATTERN-1 and so on are patterns to match
1.1.1.3 root 605: consecutive insns. The optimization applies to a sequence of insns
606: when INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the
607: next, and so on.
608:
1.1.1.6 ! root 609: Each of the insns matched by a peephole must also match a
1.1.1.3 root 610: `define_insn'. Peepholes are checked only at the last stage just
611: before code generation, and only optionally. Therefore, any insn
612: which would match a peephole but no `define_insn' will cause a crash
613: in code generation in an unoptimized compilation, or at various
614: optimization stages.
615:
1.1.1.6 ! root 616: The operands of the insns are matched with `match_operands' and
1.1.1.3 root 617: `match_dup', as usual. What is not usual is that the operand numbers
618: apply to all the insn patterns in the definition. So, you can check
619: for identical operands in two insns by using `match_operand' in one
620: insn and `match_dup' in the other.
621:
1.1.1.6 ! root 622: The operand constraints used in `match_operand' patterns do not
! 623: have any direct effect on the applicability of the peephole, but they
! 624: will be validated afterward, so make sure your constraints are
! 625: general enough to apply whenever the peephole matches. If the
! 626: peephole matches but the constraints are not satisfied, the compiler
! 627: will crash.
! 628:
! 629: It is safe to omit constraints in all the operands of the
! 630: peephole; or you can write constraints which serve as a double-check
! 631: on the criteria previously tested.
1.1.1.3 root 632:
1.1.1.6 ! root 633: Once a sequence of insns matches the patterns, the CONDITION is
1.1.1.3 root 634: checked. This is a C expression which makes the final decision
635: whether to perform the optimization (we do so if the expression is
636: nonzero). If CONDITION is omitted (in other words, the string is
637: empty) then the optimization is applied to every sequence of insns
638: that matches the patterns.
639:
1.1.1.6 ! root 640: The defined peephole optimizations are applied after register
1.1.1.3 root 641: allocation is complete. Therefore, the peephole definition can check
642: which operands have ended up in which kinds of registers, just by
643: looking at the operands.
644:
1.1.1.6 ! root 645: The way to refer to the operands in CONDITION is to write
1.1.1.3 root 646: `operands[I]' for operand number I (as matched by `(match_operand I
647: ...)'). Use the variable `insn' to refer to the last of the insns
648: being matched; use `PREV_INSN' to find the preceding insns (but be
649: careful to skip over any `note' insns that intervene).
650:
1.1.1.6 ! root 651: When optimizing computations with intermediate results, you can
! 652: use CONDITION to match only when the intermediate results are not
! 653: used elsewhere. Use the C expression `dead_or_set_p (INSN, OP)',
! 654: where INSN is the insn in which you expect the value to be used for
! 655: the last time (from the value of `insn', together with use of
1.1.1.3 root 656: `PREV_INSN'), and OP is the intermediate value (from `operands[I]').
657:
1.1.1.6 ! root 658: Applying the optimization means replacing the sequence of insns
! 659: with one new insn. The TEMPLATE controls ultimate output of
! 660: assembler code for this combined insn. It works exactly like the
! 661: template of a `define_insn'. Operand numbers in this template are
! 662: the same ones used in matching the original sequence of insns.
1.1.1.3 root 663:
1.1.1.6 ! root 664: The result of a defined peephole optimizer does not need to match
! 665: any of the insn patterns in the machine description; it does not even
1.1.1.3 root 666: have an opportunity to match them. The peephole optimizer definition
667: itself serves as the insn pattern to control how the insn is output.
668:
1.1.1.6 ! root 669: Defined peephole optimizers are run as assembler code is being
1.1.1.3 root 670: output, so the insns they produce are never combined or rearranged in
671: any way.
672:
1.1.1.6 ! root 673: Here is an example, taken from the 68000 machine description:
1.1.1.3 root 674:
675: (define_peephole
676: [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4)))
677: (set (match_operand:DF 0 "register_operand" "f")
678: (match_operand:DF 1 "register_operand" "ad"))]
679: "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
680: "*
681: {
682: rtx xoperands[2];
683: xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1);
684: #ifdef MOTOROLA
685: output_asm_insn (\"move.l %1,(sp)\", xoperands);
686: output_asm_insn (\"move.l %1,-(sp)\", operands);
687: return \"fmove.d (sp)+,%0\";
688: #else
689: output_asm_insn (\"movel %1,sp@\", xoperands);
690: output_asm_insn (\"movel %1,sp@-\", operands);
691: return \"fmoved sp@+,%0\";
692: #endif
693: }
694: ")
695:
1.1.1.6 ! root 696: The effect of this optimization is to change
1.1.1.3 root 697:
698: jbsr _foobar
699: addql #4,sp
700: movel d1,sp@-
701: movel d0,sp@-
702: fmoved sp@+,fp0
703:
704: into
705:
706: jbsr _foobar
707: movel d1,sp@
708: movel d0,sp@-
709: fmoved sp@+,fp0
710:
1.1.1.6 ! root 711: INSN-PATTERN-1 and so on look *almost* like the second operand of
1.1.1.3 root 712: `define_insn'. There is one important difference: the second operand
713: of `define_insn' consists of one or more RTX's enclosed in square
714: brackets. Usually, there is only one: then the same action can be
715: written as an element of a `define_peephole'. But when there are
716: multiple actions in a `define_insn', they are implicitly enclosed in
717: a `parallel'. Then you must explicitly write the `parallel', and the
718: square brackets within it, in the `define_peephole'. Thus, if an
719: insn pattern looks like this,
720:
721: (define_insn "divmodsi4"
722: [(set (match_operand:SI 0 "general_operand" "=d")
723: (div:SI (match_operand:SI 1 "general_operand" "0")
724: (match_operand:SI 2 "general_operand" "dmsK")))
725: (set (match_operand:SI 3 "general_operand" "=d")
726: (mod:SI (match_dup 1) (match_dup 2)))]
727: "TARGET_68020"
728: "divsl%.l %2,%3:%0")
729:
730: then the way to mention this insn in a peephole is as follows:
731:
732: (define_peephole
733: [...
734: (parallel
735: [(set (match_operand:SI 0 "general_operand" "=d")
736: (div:SI (match_operand:SI 1 "general_operand" "0")
737: (match_operand:SI 2 "general_operand" "dmsK")))
738: (set (match_operand:SI 3 "general_operand" "=d")
739: (mod:SI (match_dup 1) (match_dup 2)))])
740: ...]
741: ...)
1.1.1.2 root 742:
743:
1.1.1.3 root 744: File: gcc.info, Node: Expander Definitions, Prev: Peephole Definitions, Up: Machine Desc
1.1.1.2 root 745:
1.1.1.3 root 746: Defining RTL Sequences for Code Generation
747: ==========================================
1.1.1.2 root 748:
1.1.1.6 ! root 749: On some target machines, some standard pattern names for RTL
1.1.1.3 root 750: generation cannot be handled with single insn, but a sequence of RTL
751: insns can represent them. For these target machines, you can write a
752: `define_expand' to specify how to generate the sequence of RTL.
753:
1.1.1.6 ! root 754: A `define_expand' is an RTL expression that looks almost like a
1.1.1.3 root 755: `define_insn'; but, unlike the latter, a `define_expand' is used only
756: for RTL generation and it can produce more than one RTL insn.
757:
1.1.1.6 ! root 758: A `define_expand' RTX has four operands:
1.1.1.3 root 759:
760: * The name. Each `define_expand' must have a name, since the only
761: use for it is to refer to it by name.
762:
763: * The RTL template. This is just like the RTL template for a
764: `define_peephole' in that it is a vector of RTL expressions each
765: being one insn.
766:
767: * The condition, a string containing a C expression. This
768: expression is used to express how the availability of this
769: pattern depends on subclasses of target machine, selected by
770: command-line options when GNU CC is run. This is just like the
771: condition of a `define_insn' that has a standard name.
772:
773: * The preparation statements, a string containing zero or more C
774: statements which are to be executed before RTL code is generated
775: from the RTL template.
776:
777: Usually these statements prepare temporary registers for use as
778: internal operands in the RTL template, but they can also
779: generate RTL insns directly by calling routines such as
780: `emit_insn', etc. Any such insns precede the ones that come
781: from the RTL template.
782:
1.1.1.6 ! root 783: Every RTL insn emitted by a `define_expand' must match some
1.1.1.3 root 784: `define_insn' in the machine description. Otherwise, the compiler
785: will crash when trying to generate code for the insn or trying to
786: optimize it.
787:
1.1.1.6 ! root 788: The RTL template, in addition to controlling generation of RTL
! 789: insns, also describes the operands that need to be specified when
! 790: this pattern is used. In particular, it gives a predicate for each
! 791: operand.
! 792:
! 793: A true operand, which need to be specified in order to generate
! 794: RTL from the pattern, should be described with a `match_operand' in
! 795: its first occurrence in the RTL template. This enters information on
! 796: the operand's predicate into the tables that record such things. GNU
! 797: CC uses the information to preload the operand into a register if
! 798: that is required for valid RTL code. If the operand is referred to
! 799: more than once, subsequent references should use `match_dup'.
1.1.1.3 root 800:
1.1.1.6 ! root 801: The RTL template may also refer to internal "operands" which are
1.1.1.3 root 802: temporary registers or labels used only within the sequence made by
803: the `define_expand'. Internal operands are substituted into the RTL
804: template with `match_dup', never with `match_operand'. The values of
805: the internal operands are not passed in as arguments by the compiler
806: when it requests use of this pattern. Instead, they are computed
807: within the pattern, in the preparation statements. These statements
808: compute the values and store them into the appropriate elements of
809: `operands' so that `match_dup' can find them.
810:
1.1.1.6 ! root 811: There are two special macros defined for use in the preparation
1.1.1.3 root 812: statements: `DONE' and `FAIL'. Use them with a following semicolon,
813: as a statement.
814:
815: `DONE'
816: Use the `DONE' macro to end RTL generation for the pattern. The
817: only RTL insns resulting from the pattern on this occasion will
818: be those already emitted by explicit calls to `emit_insn' within
819: the preparation statements; the RTL template will not be
820: generated.
821:
822: `FAIL'
823: Make the pattern fail on this occasion. When a pattern fails,
824: it means that the pattern was not truly available. The calling
825: routines in the compiler will try other strategies for code
826: generation using other patterns.
827:
828: Failure is currently supported only for binary operations
829: (addition, multiplication, shifting, etc.).
830:
831: Do not emit any insns explicitly with `emit_insn' before failing.
832:
1.1.1.6 ! root 833: Here is an example, the definition of left-shift for the SPUR chip:
1.1.1.3 root 834:
835: (define_expand "ashlsi3"
836: [(set (match_operand:SI 0 "register_operand" "")
837: (ashift:SI
838: (match_operand:SI 1 "register_operand" "")
839: (match_operand:SI 2 "nonmemory_operand" "")))]
840: ""
841: "
842: {
843: if (GET_CODE (operands[2]) != CONST_INT
844: || (unsigned) INTVAL (operands[2]) > 3)
845: FAIL;
846: }")
847:
848: This example uses `define_expand' so that it can generate an RTL insn
849: for shifting when the shift-count is in the supported range of 0 to 3
850: but fail in other cases where machine insns aren't available. When
851: it fails, the compiler tries another strategy using different
852: patterns (such as, a library call).
853:
1.1.1.6 ! root 854: If the compiler were able to handle nontrivial condition-strings
! 855: in patterns with names, then it would be possible to use a
! 856: `define_insn' in that case. Here is another case (zero-extension on
! 857: the 68000) which makes more use of the power of `define_expand':
1.1.1.3 root 858:
859: (define_expand "zero_extendhisi2"
860: [(set (match_operand:SI 0 "general_operand" "")
861: (const_int 0))
862: (set (strict_low_part
863: (subreg:HI
864: (match_dup 0)
865: 0))
866: (match_operand:HI 1 "general_operand" ""))]
867: ""
868: "operands[1] = make_safe_from (operands[1], operands[0]);")
869:
870: Here two RTL insns are generated, one to clear the entire output
871: operand and the other to copy the input operand into its low half.
872: This sequence is incorrect if the input operand refers to [the old
873: value of] the output operand, so the preparation statement makes sure
874: this isn't so. The function `make_safe_from' copies the
875: `operands[1]' into a temporary register if it refers to
876: `operands[0]'. It does this by emitting another RTL insn.
877:
1.1.1.6 ! root 878: Finally, a third example shows the use of an internal operand.
1.1.1.3 root 879: Zero-extension on the SPUR chip is done by `and'-ing the result
880: against a halfword mask. But this mask cannot be represented by a
881: `const_int' because the constant value is too large to be legitimate
882: on this machine. So it must be copied into a register with
883: `force_reg' and then the register used in the `and'.
884:
885: (define_expand "zero_extendhisi2"
886: [(set (match_operand:SI 0 "register_operand" "")
887: (and:SI (subreg:SI
888: (match_operand:HI 1 "register_operand" "")
889: 0)
890: (match_dup 2)))]
891: ""
892: "operands[2]
893: = force_reg (SImode, gen_rtx (CONST_INT,
894: VOIDmode, 65535)); ")
895:
1.1.1.6 ! root 896: *Note:* If the `define_expand' is used to serve a standard binary
! 897: or unary arithmetic operation, then the last insn it generates must
! 898: not be a `code_label', `barrier' or `note'. It must be an `insn',
1.1.1.3 root 899: `jump_insn' or `call_insn'.
1.1.1.2 root 900:
901:
1.1.1.3 root 902: File: gcc.info, Node: Machine Macros, Next: Config, Prev: Machine Desc, Up: Top
1.1.1.2 root 903:
1.1.1.3 root 904: Machine Description Macros
905: **************************
1.1.1.2 root 906:
1.1.1.6 ! root 907: The other half of the machine description is a C header file
1.1.1.3 root 908: conventionally given the name `tm-MACHINE.h'. The file `tm.h' should
909: be a link to it. The header file `config.h' includes `tm.h' and most
910: compiler source files include `config.h'.
911:
912: * Menu:
913:
914: * Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'.
915: * Storage Layout:: Defining sizes and alignments of data types.
916: * Registers:: Naming and describing the hardware registers.
917: * Register Classes:: Defining the classes of hardware registers.
918: * Stack Layout:: Defining which way the stack grows and by how much.
1.1.1.6 ! root 919: * Library Calls:: Specifying how to call certain library routines.
1.1.1.3 root 920: * Addressing Modes:: Defining addressing modes valid for memory operands.
921: * Delayed Branch:: Do branches execute the following instruction?
922: * Condition Code:: Defining how insns update the condition code.
923: * Cross-compilation:: Handling floating point for cross-compilers.
924: * Misc:: Everything else.
1.1.1.5 root 925: * Assembler Format:: Defining how to write insns and pseudo-ops to output.
1.1.1.2 root 926:
927:
1.1.1.3 root 928: File: gcc.info, Node: Run-time Target, Next: Storage Layout, Prev: Machine Macros, Up: Machine Macros
1.1.1.2 root 929:
1.1.1.3 root 930: Run-time Target Specification
931: =============================
1.1.1.2 root 932:
1.1.1.3 root 933: `CPP_PREDEFINES'
934: Define this to be a string constant containing `-D' options to
935: define the predefined macros that identify this machine and
936: system. These macros will be predefined unless the `-ansi'
937: option is specified.
1.1.1.2 root 938:
1.1.1.3 root 939: In addition, a parallel set of macros are predefined, whose
940: names are made by appending `__' at the beginning and at the
941: end. These `__' macros are permitted by the ANSI standard, so
942: they are predefined regardless of whether `-ansi' is specified.
1.1.1.2 root 943:
1.1.1.3 root 944: For example, on the Sun, one can use the following value:
945:
946: "-Dmc68000 -Dsun -Dunix"
1.1 root 947:
1.1.1.3 root 948: The result is to define the macros `__mc68000__', `__sun__' and
949: `__unix__' unconditionally, and the macros `mc68000', `sun' and
950: `unix' provided `-ansi' is not specified.
1.1 root 951:
1.1.1.3 root 952: `CPP_SPEC'
1.1 root 953: A C string constant that tells the GNU CC driver program options
1.1.1.3 root 954: to pass to CPP. It can also specify how to translate options
955: you give to GNU CC into options for GNU CC to pass to the CPP.
1.1 root 956:
957: Do not define this macro if it does not need to do anything.
958:
1.1.1.3 root 959: `CC1_SPEC'
1.1 root 960: A C string constant that tells the GNU CC driver program options
1.1.1.3 root 961: to pass to CC1. It can also specify how to translate options
962: you give to GNU CC into options for GNU CC to pass to the CC1.
1.1 root 963:
964: Do not define this macro if it does not need to do anything.
965:
1.1.1.3 root 966: `extern int target_flags;'
967: This declaration should be present.
1.1 root 968:
1.1.1.3 root 969: `TARGET_...'
970: This series of macros is to allow compiler command arguments to
971: enable or disable the use of optional features of the target
972: machine. For example, one machine description serves both the
973: 68000 and the 68020; a command argument tells the compiler
974: whether it should use 68020-only instructions or not. This
975: command argument works by means of a macro `TARGET_68020' that
976: tests a bit in `target_flags'.
977:
978: Define a macro `TARGET_FEATURENAME' for each such option. Its
979: definition should test a bit in `target_flags'; for example:
980:
981: #define TARGET_68020 (target_flags & 1)
982:
983: One place where these macros are used is in the
984: condition-expressions of instruction patterns. Note how
985: `TARGET_68020' appears frequently in the 68000 machine
986: description file, `m68k.md'. Another place they are used is in
987: the definitions of the other macros in the `tm-MACHINE.h' file.
988:
989: `TARGET_SWITCHES'
990: This macro defines names of command options to set and clear
991: bits in `target_flags'. Its definition is an initializer with a
992: subgrouping for each command option.
993:
994: Each subgrouping contains a string constant, that defines the
995: option name, and a number, which contains the bits to set in
996: `target_flags'. A negative number says to clear bits instead;
997: the negative of the number is which bits to clear. The actual
998: option name is made by appending `-m' to the specified name.
999:
1000: One of the subgroupings should have a null string. The number
1001: in this grouping is the default value for `target_flags'. Any
1002: target options act starting with that value.
1003:
1004: Here is an example which defines `-m68000' and `-m68020' with
1005: opposite meanings, and picks the latter as the default:
1006:
1007: #define TARGET_SWITCHES \
1008: { { "68020", 1}, \
1009: { "68000", -1}, \
1010: { "", 1}}
1011:
1012: `OVERRIDE_OPTIONS'
1013: Sometimes certain combinations of command options do not make
1014: sense on a particular target machine. You can define a macro
1015: `OVERRIDE_OPTIONS' to take account of this. This macro, if
1016: defined, is executed once just after all the command options
1017: have been parsed.
1.1 root 1018:
1019:
1.1.1.3 root 1020: File: gcc.info, Node: Storage Layout, Next: Registers, Prev: Run-time Target, Up: Machine Macros
1021:
1022: Storage Layout
1023: ==============
1024:
1.1.1.6 ! root 1025: Note that the definitions of the macros in this table which are
! 1026: sizes or alignments measured in bits do not need to be constant.
! 1027: They can be C expressions that refer to static variables, such as the
1.1.1.3 root 1028: `target_flags'. *Note Run-time Target::.
1029:
1030: `BITS_BIG_ENDIAN'
1031: Define this macro if the most significant bit in a byte has the
1032: lowest number. This means that bit-field instructions count
1033: from the most significant bit. If the machine has no bit-field
1034: instructions, this macro is irrelevant.
1035:
1036: This macro does not affect the way structure fields are packed
1037: into bytes or words; that is controlled by `BYTES_BIG_ENDIAN'.
1038:
1039: `BYTES_BIG_ENDIAN'
1040: Define this macro if the most significant byte in a word has the
1041: lowest number.
1042:
1043: `WORDS_BIG_ENDIAN'
1044: Define this macro if, in a multiword object, the most
1045: significant word has the lowest number.
1046:
1047: `BITS_PER_UNIT'
1048: Number of bits in an addressable storage unit (byte); normally 8.
1049:
1050: `BITS_PER_WORD'
1051: Number of bits in a word; normally 32.
1052:
1053: `UNITS_PER_WORD'
1054: Number of storage units in a word; normally 4.
1055:
1056: `POINTER_SIZE'
1057: Width of a pointer, in bits.
1058:
1059: `POINTER_BOUNDARY'
1060: Alignment required for pointers stored in memory, in bits.
1061:
1062: `PARM_BOUNDARY'
1063: Normal alignment required for function parameters on the stack,
1064: in bits. All stack parameters receive least this much alignment
1065: regardless of data type. On most machines, this is the same as
1066: the size of an integer.
1067:
1068: `MAX_PARM_BOUNDARY'
1069: Largest alignment required for any stack parameters, in bits.
1070: If the data type of the parameter calls for more alignment than
1071: `PARM_BOUNDARY', then it is given extra padding up to this limit.
1072:
1073: Don't define this macro if it would be equal to `PARM_BOUNDARY';
1074: in other words, if the alignment of a stack parameter should not
1075: depend on its data type (as is the case on most machines).
1076:
1077: `STACK_BOUNDARY'
1078: Define this macro if you wish to preserve a certain alignment
1079: for the stack pointer at all times. The definition is a C
1080: expression for the desired alignment (measured in bits).
1081:
1082: `FUNCTION_BOUNDARY'
1083: Alignment required for a function entry point, in bits.
1084:
1085: `BIGGEST_ALIGNMENT'
1086: Biggest alignment that any data type can require on this
1087: machine, in bits.
1088:
1089: `CONSTANT_ALIGNMENT (CODE, TYPEALIGN)'
1090: A C expression to compute the alignment for a constant. The
1091: argument TYPEALIGN is the alignment required for the constant's
1092: data type. CODE is the tree code of the constant itself.
1093:
1094: If this macro is not defined, the default is to use TYPEALIGN.
1095: If you do define this macro, the value must be a multiple of
1096: TYPEALIGN.
1097:
1098: The purpose of defining this macro is usually to cause string
1099: constants to be word aligned so that `dhrystone' can be made to
1100: run faster.
1101:
1102: `EMPTY_FIELD_BOUNDARY'
1103: Alignment in bits to be given to a structure bit field that
1104: follows an empty field such as `int : 0;'.
1105:
1106: `STRUCTURE_SIZE_BOUNDARY'
1107: Number of bits which any structure or union's size must be a
1108: multiple of. Each structure or union's size is rounded up to a
1109: multiple of this.
1110:
1111: If you do not define this macro, the default is the same as
1112: `BITS_PER_UNIT'.
1113:
1114: `STRICT_ALIGNMENT'
1115: Define this if instructions will fail to work if given data not
1116: on the nominal alignment. If instructions will merely go slower
1117: in that case, do not define this macro.
1118:
1119: `PCC_BITFIELD_TYPE_MATTERS'
1120: Define this if you wish to imitate a certain bizarre behavior
1121: pattern of some instances of PCC: a bit field whose declared
1122: type is `int' has the same effect on the size and alignment of a
1123: structure as an actual `int' would have.
1124:
1.1.1.4 root 1125: If the macro is defined, then its definition should be a C
1126: expression; a nonzero value for the expression enables
1127: PCC-compatible behavior.
1128:
1.1.1.3 root 1129: Just what effect that is in GNU CC depends on other parameters,
1130: but on most machines it would force the structure's alignment
1131: and size to a multiple of 32 or `BIGGEST_ALIGNMENT' bits.
1132:
1133: `MAX_FIXED_MODE_SIZE'
1134: An integer expression for the largest integer machine mode that
1135: should actually be used. All integer machine modes of this size
1136: or smaller can be used for structures and unions with the
1137: appropriate sizes.
1138:
1139: `CHECK_FLOAT_VALUE (MODE, VALUE)'
1140: A C statement to validate the value VALUE (or type `double') for
1141: mode MODE. This means that you check whether VALUE fits within
1142: the possible range of values for mode MODE on this target
1143: machine. The mode MODE is always `SFmode' or `DFmode'.
1144:
1145: If VALUE is not valid, you should call `error' to print an error
1146: message and then assign some valid value to VALUE. Allowing an
1147: invalid value to go through the compiler can produce incorrect
1148: assembler code which may even cause Unix assemblers to crash.
1149:
1150: This macro need not be defined if there is no work for it to do.
1151:
1.1.1.6 ! root 1152:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.