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