![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-20 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-20 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.3 root 1: This is Info file gcc.info, produced by Makeinfo-1.55 from the input
1.1 root 2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
1.1.1.4 ! root 6: Published by the Free Software Foundation 59 Temple Place - Suite 330
! 7: Boston, MA 02111-1307 USA
1.1 root 8:
1.1.1.4 ! root 9: Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 Free Software
! 10: Foundation, Inc.
1.1 root 11:
12: Permission is granted to make and distribute verbatim copies of this
13: manual provided the copyright notice and this permission notice are
14: preserved on all copies.
15:
16: Permission is granted to copy and distribute modified versions of
17: this manual under the conditions for verbatim copying, provided also
1.1.1.3 root 18: that the sections entitled "GNU General Public License," "Funding for
19: Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
20: included exactly as in the original, and provided that the entire
21: resulting derived work is distributed under the terms of a permission
22: notice identical to this one.
1.1 root 23:
24: Permission is granted to copy and distribute translations of this
25: manual into another language, under the above conditions for modified
26: versions, except that the sections entitled "GNU General Public
1.1.1.3 root 27: License," "Funding for Free Software," and "Protect Your Freedom--Fight
28: `Look And Feel'", and this permission notice, may be included in
29: translations approved by the Free Software Foundation instead of in the
30: original English.
1.1 root 31:
32:
1.1.1.4 ! root 33: File: gcc.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers
1.1 root 34:
1.1.1.4 ! root 35: Handling Leaf Functions
! 36: -----------------------
1.1.1.2 root 37:
1.1.1.4 ! root 38: On some machines, a leaf function (i.e., one which makes no calls)
! 39: can run more efficiently if it does not make its own register window.
! 40: Often this means it is required to receive its arguments in the
! 41: registers where they are passed by the caller, instead of the registers
! 42: where they would normally arrive.
! 43:
! 44: The special treatment for leaf functions generally applies only when
! 45: other conditions are met; for example, often they may use only those
! 46: registers for its own variables and temporaries. We use the term "leaf
! 47: function" to mean a function that is suitable for this special
! 48: handling, so that functions with no calls are not necessarily "leaf
! 49: functions".
! 50:
! 51: GNU CC assigns register numbers before it knows whether the function
! 52: is suitable for leaf function treatment. So it needs to renumber the
! 53: registers in order to output a leaf function. The following macros
! 54: accomplish this.
! 55:
! 56: `LEAF_REGISTERS'
! 57: A C initializer for a vector, indexed by hard register number,
! 58: which contains 1 for a register that is allowable in a candidate
! 59: for leaf function treatment.
! 60:
! 61: If leaf function treatment involves renumbering the registers,
! 62: then the registers marked here should be the ones before
! 63: renumbering--those that GNU CC would ordinarily allocate. The
! 64: registers which will actually be used in the assembler code, after
! 65: renumbering, should not be marked with 1 in this vector.
! 66:
! 67: Define this macro only if the target machine offers a way to
! 68: optimize the treatment of leaf functions.
! 69:
! 70: `LEAF_REG_REMAP (REGNO)'
! 71: A C expression whose value is the register number to which REGNO
! 72: should be renumbered, when a function is treated as a leaf
! 73: function.
! 74:
! 75: If REGNO is a register number which should not appear in a leaf
! 76: function before renumbering, then the expression should yield -1,
! 77: which will cause the compiler to abort.
! 78:
! 79: Define this macro only if the target machine offers a way to
! 80: optimize the treatment of leaf functions, and registers need to be
! 81: renumbered to do this.
! 82:
! 83: Normally, `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE' must treat
! 84: leaf functions specially. It can test the C variable `leaf_function'
! 85: which is nonzero for leaf functions. (The variable `leaf_function' is
! 86: defined only if `LEAF_REGISTERS' is defined.)
1.1 root 87:
88:
1.1.1.4 ! root 89: File: gcc.info, Node: Stack Registers, Next: Obsolete Register Macros, Prev: Leaf Functions, Up: Registers
! 90:
! 91: Registers That Form a Stack
! 92: ---------------------------
! 93:
! 94: There are special features to handle computers where some of the
! 95: "registers" form a stack, as in the 80387 coprocessor for the 80386.
! 96: Stack registers are normally written by pushing onto the stack, and are
! 97: numbered relative to the top of the stack.
1.1 root 98:
1.1.1.4 ! root 99: Currently, GNU CC can only handle one group of stack-like registers,
! 100: and they must be consecutively numbered.
1.1 root 101:
1.1.1.4 ! root 102: `STACK_REGS'
! 103: Define this if the machine has any stack-like registers.
1.1 root 104:
1.1.1.4 ! root 105: `FIRST_STACK_REG'
! 106: The number of the first stack-like register. This one is the top
! 107: of the stack.
1.1.1.3 root 108:
1.1.1.4 ! root 109: `LAST_STACK_REG'
! 110: The number of the last stack-like register. This one is the
! 111: bottom of the stack.
1.1 root 112:
113:
1.1.1.4 ! root 114: File: gcc.info, Node: Obsolete Register Macros, Prev: Stack Registers, Up: Registers
1.1.1.3 root 115:
1.1.1.4 ! root 116: Obsolete Macros for Controlling Register Usage
! 117: ----------------------------------------------
1.1 root 118:
1.1.1.4 ! root 119: These features do not work very well. They exist because they used
! 120: to be required to generate correct code for the 80387 coprocessor of the
! 121: 80386. They are no longer used by that machine description and may be
! 122: removed in a later version of the compiler. Don't use them!
! 123:
! 124: `OVERLAPPING_REGNO_P (REGNO)'
! 125: If defined, this is a C expression whose value is nonzero if hard
! 126: register number REGNO is an overlapping register. This means a
! 127: hard register which overlaps a hard register with a different
! 128: number. (Such overlap is undesirable, but occasionally it allows
! 129: a machine to be supported which otherwise could not be.) This
! 130: macro must return nonzero for *all* the registers which overlap
! 131: each other. GNU CC can use an overlapping register only in
! 132: certain limited ways. It can be used for allocation within a
! 133: basic block, and may be spilled for reloading; that is all.
! 134:
! 135: If this macro is not defined, it means that none of the hard
! 136: registers overlap each other. This is the usual situation.
! 137:
! 138: `INSN_CLOBBERS_REGNO_P (INSN, REGNO)'
! 139: If defined, this is a C expression whose value should be nonzero if
! 140: the insn INSN has the effect of mysteriously clobbering the
! 141: contents of hard register number REGNO. By "mysterious" we mean
! 142: that the insn's RTL expression doesn't describe such an effect.
! 143:
! 144: If this macro is not defined, it means that no insn clobbers
! 145: registers mysteriously. This is the usual situation; all else
! 146: being equal, it is best for the RTL expression to show all the
! 147: activity.
! 148:
! 149: `PRESERVE_DEATH_INFO_REGNO_P (REGNO)'
! 150: If defined, this is a C expression whose value is nonzero if
! 151: accurate `REG_DEAD' notes are needed for hard register number REGNO
! 152: at the time of outputting the assembler code. When this is so, a
! 153: few optimizations that take place after register allocation and
! 154: could invalidate the death notes are not done when this register is
! 155: involved.
! 156:
! 157: You would arrange to preserve death info for a register when some
! 158: of the code in the machine description which is executed to write
! 159: the assembler code looks at the death notes. This is necessary
! 160: only when the actual hardware feature which GNU CC thinks of as a
! 161: register is not actually a register of the usual sort. (It might,
! 162: for example, be a hardware stack.)
1.1 root 163:
1.1.1.4 ! root 164: If this macro is not defined, it means that no death notes need to
! 165: be preserved. This is the usual situation.
1.1 root 166:
1.1.1.2 root 167:
1.1.1.4 ! root 168: File: gcc.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros
1.1 root 169:
1.1.1.4 ! root 170: Register Classes
! 171: ================
1.1 root 172:
1.1.1.4 ! root 173: On many machines, the numbered registers are not all equivalent.
! 174: For example, certain registers may not be allowed for indexed
! 175: addressing; certain registers may not be allowed in some instructions.
! 176: These machine restrictions are described to the compiler using
! 177: "register classes".
! 178:
! 179: You define a number of register classes, giving each one a name and
! 180: saying which of the registers belong to it. Then you can specify
! 181: register classes that are allowed as operands to particular instruction
! 182: patterns.
! 183:
! 184: In general, each register will belong to several classes. In fact,
! 185: one class must be named `ALL_REGS' and contain all the registers.
! 186: Another class must be named `NO_REGS' and contain no registers. Often
! 187: the union of two classes will be another class; however, this is not
! 188: required.
! 189:
! 190: One of the classes must be named `GENERAL_REGS'. There is nothing
! 191: terribly special about the name, but the operand constraint letters `r'
! 192: and `g' specify this class. If `GENERAL_REGS' is the same as
! 193: `ALL_REGS', just define it as a macro which expands to `ALL_REGS'.
! 194:
! 195: Order the classes so that if class X is contained in class Y then X
! 196: has a lower class number than Y.
! 197:
! 198: The way classes other than `GENERAL_REGS' are specified in operand
! 199: constraints is through machine-dependent operand constraint letters.
! 200: You can define such letters to correspond to various classes, then use
! 201: them in operand constraints.
! 202:
! 203: You should define a class for the union of two classes whenever some
! 204: instruction allows both classes. For example, if an instruction allows
! 205: either a floating point (coprocessor) register or a general register
! 206: for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS'
! 207: which includes both of them. Otherwise you will get suboptimal code.
! 208:
! 209: You must also specify certain redundant information about the
! 210: register classes: for each class, which classes contain it and which
! 211: ones are contained in it; for each pair of classes, the largest class
! 212: contained in their union.
! 213:
! 214: When a value occupying several consecutive registers is expected in a
! 215: certain class, all the registers used must belong to that class.
! 216: Therefore, register classes cannot be used to enforce a requirement for
! 217: a register pair to start with an even-numbered register. The way to
! 218: specify this requirement is with `HARD_REGNO_MODE_OK'.
! 219:
! 220: Register classes used for input-operands of bitwise-and or shift
! 221: instructions have a special requirement: each such class must have, for
! 222: each fixed-point machine mode, a subclass whose registers can transfer
! 223: that mode to or from memory. For example, on some machines, the
! 224: operations for single-byte values (`QImode') are limited to certain
! 225: registers. When this is so, each register class that is used in a
! 226: bitwise-and or shift instruction must have a subclass consisting of
! 227: registers from which single-byte values can be loaded or stored. This
! 228: is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to
! 229: return.
! 230:
! 231: `enum reg_class'
! 232: An enumeral type that must be defined with all the register class
! 233: names as enumeral values. `NO_REGS' must be first. `ALL_REGS'
! 234: must be the last register class, followed by one more enumeral
! 235: value, `LIM_REG_CLASSES', which is not a register class but rather
! 236: tells how many classes there are.
! 237:
! 238: Each register class has a number, which is the value of casting
! 239: the class name to type `int'. The number serves as an index in
! 240: many of the tables described below.
! 241:
! 242: `N_REG_CLASSES'
! 243: The number of distinct register classes, defined as follows:
! 244:
! 245: #define N_REG_CLASSES (int) LIM_REG_CLASSES
! 246:
! 247: `REG_CLASS_NAMES'
! 248: An initializer containing the names of the register classes as C
! 249: string constants. These names are used in writing some of the
! 250: debugging dumps.
! 251:
! 252: `REG_CLASS_CONTENTS'
! 253: An initializer containing the contents of the register classes, as
! 254: integers which are bit masks. The Nth integer specifies the
! 255: contents of class N. The way the integer MASK is interpreted is
! 256: that register R is in the class if `MASK & (1 << R)' is 1.
! 257:
! 258: When the machine has more than 32 registers, an integer does not
! 259: suffice. Then the integers are replaced by sub-initializers,
! 260: braced groupings containing several integers. Each
! 261: sub-initializer must be suitable as an initializer for the type
! 262: `HARD_REG_SET' which is defined in `hard-reg-set.h'.
! 263:
! 264: `REGNO_REG_CLASS (REGNO)'
! 265: A C expression whose value is a register class containing hard
! 266: register REGNO. In general there is more than one such class;
! 267: choose a class which is "minimal", meaning that no smaller class
! 268: also contains the register.
! 269:
! 270: `BASE_REG_CLASS'
! 271: A macro whose definition is the name of the class to which a valid
! 272: base register must belong. A base register is one used in an
! 273: address which is the register value plus a displacement.
! 274:
! 275: `INDEX_REG_CLASS'
! 276: A macro whose definition is the name of the class to which a valid
! 277: index register must belong. An index register is one used in an
! 278: address where its value is either multiplied by a scale factor or
! 279: added to another register (as well as added to a displacement).
! 280:
! 281: `REG_CLASS_FROM_LETTER (CHAR)'
! 282: A C expression which defines the machine-dependent operand
! 283: constraint letters for register classes. If CHAR is such a
! 284: letter, the value should be the register class corresponding to
! 285: it. Otherwise, the value should be `NO_REGS'. The register
! 286: letter `r', corresponding to class `GENERAL_REGS', will not be
! 287: passed to this macro; you do not need to handle it.
! 288:
! 289: `REGNO_OK_FOR_BASE_P (NUM)'
! 290: A C expression which is nonzero if register number NUM is suitable
! 291: for use as a base register in operand addresses. It may be either
! 292: a suitable hard register or a pseudo register that has been
! 293: allocated such a hard register.
! 294:
! 295: `REGNO_OK_FOR_INDEX_P (NUM)'
! 296: A C expression which is nonzero if register number NUM is suitable
! 297: for use as an index register in operand addresses. It may be
! 298: either a suitable hard register or a pseudo register that has been
! 299: allocated such a hard register.
! 300:
! 301: The difference between an index register and a base register is
! 302: that the index register may be scaled. If an address involves the
! 303: sum of two registers, neither one of them scaled, then either one
! 304: may be labeled the "base" and the other the "index"; but whichever
! 305: labeling is used must fit the machine's constraints of which
! 306: registers may serve in each capacity. The compiler will try both
! 307: labelings, looking for one that is valid, and will reload one or
! 308: both registers only if neither labeling works.
1.1 root 309:
1.1.1.4 ! root 310: `PREFERRED_RELOAD_CLASS (X, CLASS)'
! 311: A C expression that places additional restrictions on the register
! 312: class to use when it is necessary to copy value X into a register
! 313: in class CLASS. The value is a register class; perhaps CLASS, or
! 314: perhaps another, smaller class. On many machines, the following
! 315: definition is safe:
! 316:
! 317: #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
! 318:
! 319: Sometimes returning a more restrictive class makes better code.
! 320: For example, on the 68000, when X is an integer constant that is
! 321: in range for a `moveq' instruction, the value of this macro is
! 322: always `DATA_REGS' as long as CLASS includes the data registers.
! 323: Requiring a data register guarantees that a `moveq' will be used.
! 324:
! 325: If X is a `const_double', by returning `NO_REGS' you can force X
! 326: into a memory constant. This is useful on certain machines where
! 327: immediate floating values cannot be loaded into certain kinds of
! 328: registers.
1.1 root 329:
1.1.1.4 ! root 330: `PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS)'
! 331: Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of
! 332: input reloads. If you don't define this macro, the default is to
! 333: use CLASS, unchanged.
! 334:
! 335: `LIMIT_RELOAD_CLASS (MODE, CLASS)'
! 336: A C expression that places additional restrictions on the register
! 337: class to use when it is necessary to be able to hold a value of
! 338: mode MODE in a reload register for which class CLASS would
! 339: ordinarily be used.
! 340:
! 341: Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when
! 342: there are certain modes that simply can't go in certain reload
! 343: classes.
! 344:
! 345: The value is a register class; perhaps CLASS, or perhaps another,
! 346: smaller class.
! 347:
! 348: Don't define this macro unless the target machine has limitations
! 349: which require the macro to do something nontrivial.
! 350:
! 351: `SECONDARY_RELOAD_CLASS (CLASS, MODE, X)'
! 352: `SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)'
! 353: `SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)'
! 354: Many machines have some registers that cannot be copied directly
! 355: to or from memory or even from other types of registers. An
! 356: example is the `MQ' register, which on most machines, can only be
! 357: copied to or from general registers, but not memory. Some
! 358: machines allow copying all registers to and from memory, but
! 359: require a scratch register for stores to some memory locations
! 360: (e.g., those with symbolic address on the RT, and those with
! 361: certain symbolic address on the Sparc when compiling PIC). In
! 362: some cases, both an intermediate and a scratch register are
! 363: required.
! 364:
! 365: You should define these macros to indicate to the reload phase
! 366: that it may need to allocate at least one register for a reload in
! 367: addition to the register to contain the data. Specifically, if
! 368: copying X to a register CLASS in MODE requires an intermediate
! 369: register, you should define `SECONDARY_INPUT_RELOAD_CLASS' to
! 370: return the largest register class all of whose registers can be
! 371: used as intermediate registers or scratch registers.
! 372:
! 373: If copying a register CLASS in MODE to X requires an intermediate
! 374: or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' should be
! 375: defined to return the largest register class required. If the
! 376: requirements for input and output reloads are the same, the macro
! 377: `SECONDARY_RELOAD_CLASS' should be used instead of defining both
! 378: macros identically.
! 379:
! 380: The values returned by these macros are often `GENERAL_REGS'.
! 381: Return `NO_REGS' if no spare register is needed; i.e., if X can be
! 382: directly copied to or from a register of CLASS in MODE without
! 383: requiring a scratch register. Do not define this macro if it
! 384: would always return `NO_REGS'.
! 385:
! 386: If a scratch register is required (either with or without an
! 387: intermediate register), you should define patterns for
! 388: `reload_inM' or `reload_outM', as required (*note Standard
! 389: Names::.. These patterns, which will normally be implemented with
! 390: a `define_expand', should be similar to the `movM' patterns,
! 391: except that operand 2 is the scratch register.
! 392:
! 393: Define constraints for the reload register and scratch register
! 394: that contain a single register class. If the original reload
! 395: register (whose class is CLASS) can meet the constraint given in
! 396: the pattern, the value returned by these macros is used for the
! 397: class of the scratch register. Otherwise, two additional reload
! 398: registers are required. Their classes are obtained from the
! 399: constraints in the insn pattern.
! 400:
! 401: X might be a pseudo-register or a `subreg' of a pseudo-register,
! 402: which could either be in a hard register or in memory. Use
! 403: `true_regnum' to find out; it will return -1 if the pseudo is in
! 404: memory and the hard register number if it is in a register.
! 405:
! 406: These macros should not be used in the case where a particular
! 407: class of registers can only be copied to memory and not to another
! 408: class of registers. In that case, secondary reload registers are
! 409: not needed and would not be helpful. Instead, a stack location
! 410: must be used to perform the copy and the `movM' pattern should use
! 411: memory as a intermediate storage. This case often occurs between
! 412: floating-point and general registers.
! 413:
! 414: `SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M)'
! 415: Certain machines have the property that some registers cannot be
! 416: copied to some other registers without using memory. Define this
! 417: macro on those machines to be a C expression that is non-zero if
! 418: objects of mode M in registers of CLASS1 can only be copied to
! 419: registers of class CLASS2 by storing a register of CLASS1 into
! 420: memory and loading that memory location into a register of CLASS2.
! 421:
! 422: Do not define this macro if its value would always be zero.
! 423:
! 424: `SECONDARY_MEMORY_NEEDED_RTX (MODE)'
! 425: Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler
! 426: allocates a stack slot for a memory location needed for register
! 427: copies. If this macro is defined, the compiler instead uses the
! 428: memory location defined by this macro.
! 429:
! 430: Do not define this macro if you do not define
! 431: `SECONDARY_MEMORY_NEEDED'.
! 432:
! 433: `SECONDARY_MEMORY_NEEDED_MODE (MODE)'
! 434: When the compiler needs a secondary memory location to copy
! 435: between two registers of mode MODE, it normally allocates
! 436: sufficient memory to hold a quantity of `BITS_PER_WORD' bits and
! 437: performs the store and load operations in a mode that many bits
! 438: wide and whose class is the same as that of MODE.
! 439:
! 440: This is right thing to do on most machines because it ensures that
! 441: all bits of the register are copied and prevents accesses to the
! 442: registers in a narrower mode, which some machines prohibit for
! 443: floating-point registers.
! 444:
! 445: However, this default behavior is not correct on some machines,
! 446: such as the DEC Alpha, that store short integers in floating-point
! 447: registers differently than in integer registers. On those
! 448: machines, the default widening will not work correctly and you
! 449: must define this macro to suppress that widening in some cases.
! 450: See the file `alpha.h' for details.
! 451:
! 452: Do not define this macro if you do not define
! 453: `SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is
! 454: `BITS_PER_WORD' bits wide is correct for your machine.
! 455:
! 456: `SMALL_REGISTER_CLASSES'
! 457: Normally the compiler avoids choosing registers that have been
! 458: explicitly mentioned in the rtl as spill registers (these
! 459: registers are normally those used to pass parameters and return
! 460: values). However, some machines have so few registers of certain
! 461: classes that there would not be enough registers to use as spill
! 462: registers if this were done.
! 463:
! 464: Define `SMALL_REGISTER_CLASSES' on these machines. When it is
! 465: defined, the compiler allows registers explicitly used in the rtl
! 466: to be used as spill registers but avoids extending the lifetime of
! 467: these registers.
! 468:
! 469: It is always safe to define this macro, but if you unnecessarily
! 470: define it, you will reduce the amount of optimizations that can be
! 471: performed in some cases. If you do not define this macro when it
! 472: is required, the compiler will run out of spill registers and
! 473: print a fatal error message. For most machines, you should not
! 474: define this macro.
! 475:
! 476: `CLASS_LIKELY_SPILLED_P (CLASS)'
! 477: A C expression whose value is nonzero if pseudos that have been
! 478: assigned to registers of class CLASS would likely be spilled
! 479: because registers of CLASS are needed for spill registers.
! 480:
! 481: The default value of this macro returns 1 if CLASS has exactly one
! 482: register and zero otherwise. On most machines, this default
! 483: should be used. Only define this macro to some other expression
! 484: if pseudo allocated by `local-alloc.c' end up in memory because
! 485: their hard registers were needed for spill registers. If this
! 486: macro returns nonzero for those classes, those pseudos will only
! 487: be allocated by `global.c', which knows how to reallocate the
! 488: pseudo to another register. If there would not be another
! 489: register available for reallocation, you should not change the
! 490: definition of this macro since the only effect of such a
! 491: definition would be to slow down register allocation.
! 492:
! 493: `CLASS_MAX_NREGS (CLASS, MODE)'
! 494: A C expression for the maximum number of consecutive registers of
! 495: class CLASS needed to hold a value of mode MODE.
! 496:
! 497: This is closely related to the macro `HARD_REGNO_NREGS'. In fact,
! 498: the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be
! 499: the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all
! 500: REGNO values in the class CLASS.
! 501:
! 502: This macro helps control the handling of multiple-word values in
! 503: the reload pass.
! 504:
! 505: `CLASS_CANNOT_CHANGE_SIZE'
! 506: If defined, a C expression for a class that contains registers
! 507: which the compiler must always access in a mode that is the same
! 508: size as the mode in which it loaded the register.
! 509:
! 510: For the example, loading 32-bit integer or floating-point objects
! 511: into floating-point registers on the Alpha extends them to 64-bits.
! 512: Therefore loading a 64-bit object and then storing it as a 32-bit
! 513: object does not store the low-order 32-bits, as would be the case
! 514: for a normal register. Therefore, `alpha.h' defines this macro as
! 515: `FLOAT_REGS'.
! 516:
! 517: Three other special macros describe which operands fit which
! 518: constraint letters.
! 519:
! 520: `CONST_OK_FOR_LETTER_P (VALUE, C)'
! 521: A C expression that defines the machine-dependent operand
! 522: constraint letters that specify particular ranges of integer
! 523: values. If C is one of those letters, the expression should check
! 524: that VALUE, an integer, is in the appropriate range and return 1
! 525: if so, 0 otherwise. If C is not one of those letters, the value
! 526: should be 0 regardless of VALUE.
! 527:
! 528: `CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)'
! 529: A C expression that defines the machine-dependent operand
! 530: constraint letters that specify particular ranges of
! 531: `const_double' values.
! 532:
! 533: If C is one of those letters, the expression should check that
! 534: VALUE, an RTX of code `const_double', is in the appropriate range
! 535: and return 1 if so, 0 otherwise. If C is not one of those
! 536: letters, the value should be 0 regardless of VALUE.
! 537:
! 538: `const_double' is used for all floating-point constants and for
! 539: `DImode' fixed-point constants. A given letter can accept either
! 540: or both kinds of values. It can use `GET_MODE' to distinguish
! 541: between these kinds.
! 542:
! 543: `EXTRA_CONSTRAINT (VALUE, C)'
! 544: A C expression that defines the optional machine-dependent
! 545: constraint letters that can be used to segregate specific types of
! 546: operands, usually memory references, for the target machine.
! 547: Normally this macro will not be defined. If it is required for a
! 548: particular target machine, it should return 1 if VALUE corresponds
! 549: to the operand type represented by the constraint letter C. If C
! 550: is not defined as an extra constraint, the value returned should
! 551: be 0 regardless of VALUE.
! 552:
! 553: For example, on the ROMP, load instructions cannot have their
! 554: output in r0 if the memory reference contains a symbolic address.
! 555: Constraint letter `Q' is defined as representing a memory address
! 556: that does *not* contain a symbolic address. An alternative is
! 557: specified with a `Q' constraint on the input and `r' on the
! 558: output. The next alternative specifies `m' on the input and a
! 559: register class that does not include r0 on the output.
1.1 root 560:
561:
1.1.1.4 ! root 562: File: gcc.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros
1.1 root 563:
1.1.1.4 ! root 564: Stack Layout and Calling Conventions
! 565: ====================================
1.1 root 566:
1.1.1.4 ! root 567: This describes the stack layout and calling conventions.
1.1 root 568:
1.1.1.4 ! root 569: * Menu:
1.1 root 570:
1.1.1.4 ! root 571: * Frame Layout::
! 572: * Frame Registers::
! 573: * Elimination::
! 574: * Stack Arguments::
! 575: * Register Arguments::
! 576: * Scalar Return::
! 577: * Aggregate Return::
! 578: * Caller Saves::
! 579: * Function Entry::
! 580: * Profiling::
1.1 root 581:
1.1.1.4 ! root 582:
! 583: File: gcc.info, Node: Frame Layout, Next: Frame Registers, Up: Stack and Calling
1.1 root 584:
1.1.1.4 ! root 585: Basic Stack Layout
! 586: ------------------
1.1.1.3 root 587:
1.1.1.4 ! root 588: Here is the basic stack layout.
1.1.1.3 root 589:
1.1.1.4 ! root 590: `STACK_GROWS_DOWNWARD'
! 591: Define this macro if pushing a word onto the stack moves the stack
! 592: pointer to a smaller address.
! 593:
! 594: When we say, "define this macro if ...," it means that the
! 595: compiler checks this macro only with `#ifdef' so the precise
! 596: definition used does not matter.
! 597:
! 598: `FRAME_GROWS_DOWNWARD'
! 599: Define this macro if the addresses of local variable slots are at
! 600: negative offsets from the frame pointer.
! 601:
! 602: `ARGS_GROW_DOWNWARD'
! 603: Define this macro if successive arguments to a function occupy
! 604: decreasing addresses on the stack.
! 605:
! 606: `STARTING_FRAME_OFFSET'
! 607: Offset from the frame pointer to the first local variable slot to
! 608: be allocated.
! 609:
! 610: If `FRAME_GROWS_DOWNWARD', find the next slot's offset by
! 611: subtracting the first slot's length from `STARTING_FRAME_OFFSET'.
! 612: Otherwise, it is found by adding the length of the first slot to
! 613: the value `STARTING_FRAME_OFFSET'.
! 614:
! 615: `STACK_POINTER_OFFSET'
! 616: Offset from the stack pointer register to the first location at
! 617: which outgoing arguments are placed. If not specified, the
! 618: default value of zero is used. This is the proper value for most
! 619: machines.
! 620:
! 621: If `ARGS_GROW_DOWNWARD', this is the offset to the location above
! 622: the first location at which outgoing arguments are placed.
! 623:
! 624: `FIRST_PARM_OFFSET (FUNDECL)'
! 625: Offset from the argument pointer register to the first argument's
! 626: address. On some machines it may depend on the data type of the
! 627: function.
! 628:
! 629: If `ARGS_GROW_DOWNWARD', this is the offset to the location above
! 630: the first argument's address.
! 631:
! 632: `STACK_DYNAMIC_OFFSET (FUNDECL)'
! 633: Offset from the stack pointer register to an item dynamically
! 634: allocated on the stack, e.g., by `alloca'.
! 635:
! 636: The default value for this macro is `STACK_POINTER_OFFSET' plus the
! 637: length of the outgoing arguments. The default is correct for most
! 638: machines. See `function.c' for details.
! 639:
! 640: `DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)'
! 641: A C expression whose value is RTL representing the address in a
! 642: stack frame where the pointer to the caller's frame is stored.
! 643: Assume that FRAMEADDR is an RTL expression for the address of the
! 644: stack frame itself.
! 645:
! 646: If you don't define this macro, the default is to return the value
! 647: of FRAMEADDR--that is, the stack frame address is also the address
! 648: of the stack word that points to the previous frame.
! 649:
! 650: `SETUP_FRAME_ADDRESSES ()'
! 651: If defined, a C expression that produces the machine-specific code
! 652: to setup the stack so that arbitrary frames can be accessed. For
! 653: example, on the Sparc, we must flush all of the register windows
! 654: to the stack before we can access arbitrary stack frames. This
! 655: macro will seldom need to be defined.
! 656:
! 657: `RETURN_ADDR_RTX (COUNT, FRAMEADDR)'
! 658: A C expression whose value is RTL representing the value of the
! 659: return address for the frame COUNT steps up from the current frame.
! 660: fRAMEADDR is the frame pointer of the COUNT frame, or the frame
! 661: pointer of the COUNT - 1 frame if `RETURN_ADDR_IN_PREVIOUS_FRAME'
! 662: is defined.
! 663:
! 664: `RETURN_ADDR_IN_PREVIOUS_FRAME'
! 665: Define this if the return address of a particular stack frame is
! 666: accessed from the frame pointer of the previous stack frame.
1.1 root 667:
1.1.1.2 root 668:
1.1.1.4 ! root 669: File: gcc.info, Node: Frame Registers, Next: Elimination, Prev: Frame Layout, Up: Stack and Calling
1.1 root 670:
1.1.1.4 ! root 671: Registers That Address the Stack Frame
! 672: --------------------------------------
1.1 root 673:
1.1.1.4 ! root 674: This discusses registers that address the stack frame.
1.1 root 675:
1.1.1.4 ! root 676: `STACK_POINTER_REGNUM'
! 677: The register number of the stack pointer register, which must also
! 678: be a fixed register according to `FIXED_REGISTERS'. On most
! 679: machines, the hardware determines which register this is.
! 680:
! 681: `FRAME_POINTER_REGNUM'
! 682: The register number of the frame pointer register, which is used to
! 683: access automatic variables in the stack frame. On some machines,
! 684: the hardware determines which register this is. On other
! 685: machines, you can choose any register you wish for this purpose.
! 686:
! 687: `HARD_FRAME_POINTER_REGNUM'
! 688: On some machines the offset between the frame pointer and starting
! 689: offset of the automatic variables is not known until after register
! 690: allocation has been done (for example, because the saved registers
! 691: are between these two locations). On those machines, define
! 692: `FRAME_POINTER_REGNUM' the number of a special, fixed register to
! 693: be used internally until the offset is known, and define
! 694: `HARD_FRAME_POINTER_REGNUM' to be actual the hard register number
! 695: used for the frame pointer.
! 696:
! 697: You should define this macro only in the very rare circumstances
! 698: when it is not possible to calculate the offset between the frame
! 699: pointer and the automatic variables until after register
! 700: allocation has been completed. When this macro is defined, you
! 701: must also indicate in your definition of `ELIMINABLE_REGS' how to
! 702: eliminate `FRAME_POINTER_REGNUM' into either
! 703: `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'.
! 704:
! 705: Do not define this macro if it would be the same as
! 706: `FRAME_POINTER_REGNUM'.
! 707:
! 708: `ARG_POINTER_REGNUM'
! 709: The register number of the arg pointer register, which is used to
! 710: access the function's argument list. On some machines, this is
! 711: the same as the frame pointer register. On some machines, the
! 712: hardware determines which register this is. On other machines,
! 713: you can choose any register you wish for this purpose. If this is
! 714: not the same register as the frame pointer register, then you must
! 715: mark it as a fixed register according to `FIXED_REGISTERS', or
! 716: arrange to be able to eliminate it (*note Elimination::.).
! 717:
! 718: `STATIC_CHAIN_REGNUM'
! 719: `STATIC_CHAIN_INCOMING_REGNUM'
! 720: Register numbers used for passing a function's static chain
! 721: pointer. If register windows are used, the register number as
! 722: seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM',
! 723: while the register number as seen by the calling function is
! 724: `STATIC_CHAIN_REGNUM'. If these registers are the same,
! 725: `STATIC_CHAIN_INCOMING_REGNUM' need not be defined.
! 726:
! 727: The static chain register need not be a fixed register.
! 728:
! 729: If the static chain is passed in memory, these macros should not be
! 730: defined; instead, the next two macros should be defined.
! 731:
! 732: `STATIC_CHAIN'
! 733: `STATIC_CHAIN_INCOMING'
! 734: If the static chain is passed in memory, these macros provide rtx
! 735: giving `mem' expressions that denote where they are stored.
! 736: `STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as
! 737: seen by the calling and called functions, respectively. Often the
! 738: former will be at an offset from the stack pointer and the latter
! 739: at an offset from the frame pointer.
! 740:
! 741: The variables `stack_pointer_rtx', `frame_pointer_rtx', and
! 742: `arg_pointer_rtx' will have been initialized prior to the use of
! 743: these macros and should be used to refer to those items.
1.1 root 744:
1.1.1.4 ! root 745: If the static chain is passed in a register, the two previous
! 746: macros should be defined instead.
1.1 root 747:
1.1.1.4 ! root 748:
! 749: File: gcc.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling
1.1 root 750:
1.1.1.4 ! root 751: Eliminating Frame Pointer and Arg Pointer
! 752: -----------------------------------------
1.1 root 753:
1.1.1.4 ! root 754: This is about eliminating the frame pointer and arg pointer.
1.1 root 755:
1.1.1.4 ! root 756: `FRAME_POINTER_REQUIRED'
! 757: A C expression which is nonzero if a function must have and use a
! 758: frame pointer. This expression is evaluated in the reload pass.
! 759: If its value is nonzero the function will have a frame pointer.
! 760:
! 761: The expression can in principle examine the current function and
! 762: decide according to the facts, but on most machines the constant 0
! 763: or the constant 1 suffices. Use 0 when the machine allows code to
! 764: be generated with no frame pointer, and doing so saves some time
! 765: or space. Use 1 when there is no possible advantage to avoiding a
! 766: frame pointer.
! 767:
! 768: In certain cases, the compiler does not know how to produce valid
! 769: code without a frame pointer. The compiler recognizes those cases
! 770: and automatically gives the function a frame pointer regardless of
! 771: what `FRAME_POINTER_REQUIRED' says. You don't need to worry about
! 772: them.
! 773:
! 774: In a function that does not require a frame pointer, the frame
! 775: pointer register can be allocated for ordinary usage, unless you
! 776: mark it as a fixed register. See `FIXED_REGISTERS' for more
! 777: information.
! 778:
! 779: `INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)'
! 780: A C statement to store in the variable DEPTH-VAR the difference
! 781: between the frame pointer and the stack pointer values immediately
! 782: after the function prologue. The value would be computed from
! 783: information such as the result of `get_frame_size ()' and the
! 784: tables of registers `regs_ever_live' and `call_used_regs'.
! 785:
! 786: If `ELIMINABLE_REGS' is defined, this macro will be not be used and
! 787: need not be defined. Otherwise, it must be defined even if
! 788: `FRAME_POINTER_REQUIRED' is defined to always be true; in that
! 789: case, you may set DEPTH-VAR to anything.
! 790:
! 791: `ELIMINABLE_REGS'
! 792: If defined, this macro specifies a table of register pairs used to
! 793: eliminate unneeded registers that point into the stack frame. If
! 794: it is not defined, the only elimination attempted by the compiler
! 795: is to replace references to the frame pointer with references to
! 796: the stack pointer.
! 797:
! 798: The definition of this macro is a list of structure
! 799: initializations, each of which specifies an original and
! 800: replacement register.
! 801:
! 802: On some machines, the position of the argument pointer is not
! 803: known until the compilation is completed. In such a case, a
! 804: separate hard register must be used for the argument pointer.
! 805: This register can be eliminated by replacing it with either the
! 806: frame pointer or the argument pointer, depending on whether or not
! 807: the frame pointer has been eliminated.
! 808:
! 809: In this case, you might specify:
! 810: #define ELIMINABLE_REGS \
! 811: {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
! 812: {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
! 813: {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
! 814:
! 815: Note that the elimination of the argument pointer with the stack
! 816: pointer is specified first since that is the preferred elimination.
! 817:
! 818: `CAN_ELIMINATE (FROM-REG, TO-REG)'
! 819: A C expression that returns non-zero if the compiler is allowed to
! 820: try to replace register number FROM-REG with register number
! 821: TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is
! 822: defined, and will usually be the constant 1, since most of the
! 823: cases preventing register elimination are things that the compiler
! 824: already knows about.
! 825:
! 826: `INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)'
! 827: This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It
! 828: specifies the initial difference between the specified pair of
! 829: registers. This macro must be defined if `ELIMINABLE_REGS' is
! 830: defined.
! 831:
! 832: `LONGJMP_RESTORE_FROM_STACK'
! 833: Define this macro if the `longjmp' function restores registers from
! 834: the stack frames, rather than from those saved specifically by
! 835: `setjmp'. Certain quantities must not be kept in registers across
! 836: a call to `setjmp' on such machines.
1.1 root 837:
1.1.1.4 ! root 838:
! 839: File: gcc.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling
1.1 root 840:
1.1.1.4 ! root 841: Passing Function Arguments on the Stack
! 842: ---------------------------------------
1.1.1.3 root 843:
1.1.1.4 ! root 844: The macros in this section control how arguments are passed on the
! 845: stack. See the following section for other macros that control passing
! 846: certain arguments in registers.
! 847:
! 848: `PROMOTE_PROTOTYPES'
! 849: Define this macro if an argument declared in a prototype as an
! 850: integral type smaller than `int' should actually be passed as an
! 851: `int'. In addition to avoiding errors in certain cases of
! 852: mismatch, it also makes for better code on certain machines.
! 853:
! 854: `PUSH_ROUNDING (NPUSHED)'
! 855: A C expression that is the number of bytes actually pushed onto the
! 856: stack when an instruction attempts to push NPUSHED bytes.
! 857:
! 858: If the target machine does not have a push instruction, do not
! 859: define this macro. That directs GNU CC to use an alternate
! 860: strategy: to allocate the entire argument block and then store the
! 861: arguments into it.
! 862:
! 863: On some machines, the definition
! 864:
! 865: #define PUSH_ROUNDING(BYTES) (BYTES)
! 866:
! 867: will suffice. But on other machines, instructions that appear to
! 868: push one byte actually push two bytes in an attempt to maintain
! 869: alignment. Then the definition should be
! 870:
! 871: #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
! 872:
! 873: `ACCUMULATE_OUTGOING_ARGS'
! 874: If defined, the maximum amount of space required for outgoing
! 875: arguments will be computed and placed into the variable
! 876: `current_function_outgoing_args_size'. No space will be pushed
! 877: onto the stack for each call; instead, the function prologue should
! 878: increase the stack frame size by this amount.
! 879:
! 880: Defining both `PUSH_ROUNDING' and `ACCUMULATE_OUTGOING_ARGS' is
! 881: not proper.
! 882:
! 883: `REG_PARM_STACK_SPACE (FNDECL)'
! 884: Define this macro if functions should assume that stack space has
! 885: been allocated for arguments even when their values are passed in
! 886: registers.
1.1.1.3 root 887:
1.1.1.4 ! root 888: The value of this macro is the size, in bytes, of the area
! 889: reserved for arguments passed in registers for the function
! 890: represented by FNDECL.
! 891:
! 892: This space can be allocated by the caller, or be a part of the
! 893: machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says
! 894: which.
! 895:
! 896: `MAYBE_REG_PARM_STACK_SPACE'
! 897: `FINAL_REG_PARM_STACK_SPACE (CONST_SIZE, VAR_SIZE)'
! 898: Define these macros in addition to the one above if functions might
! 899: allocate stack space for arguments even when their values are
! 900: passed in registers. These should be used when the stack space
! 901: allocated for arguments in registers is not a simple constant
! 902: independent of the function declaration.
! 903:
! 904: The value of the first macro is the size, in bytes, of the area
! 905: that we should initially assume would be reserved for arguments
! 906: passed in registers.
! 907:
! 908: The value of the second macro is the actual size, in bytes, of the
! 909: area that will be reserved for arguments passed in registers.
! 910: This takes two arguments: an integer representing the number of
! 911: bytes of fixed sized arguments on the stack, and a tree
! 912: representing the number of bytes of variable sized arguments on
! 913: the stack.
! 914:
! 915: When these macros are defined, `REG_PARM_STACK_SPACE' will only be
! 916: called for libcall functions, the current function, or for a
! 917: function being called when it is known that such stack space must
! 918: be allocated. In each case this value can be easily computed.
! 919:
! 920: When deciding whether a called function needs such stack space,
! 921: and how much space to reserve, GNU CC uses these two macros
! 922: instead of `REG_PARM_STACK_SPACE'.
! 923:
! 924: `OUTGOING_REG_PARM_STACK_SPACE'
! 925: Define this if it is the responsibility of the caller to allocate
! 926: the area reserved for arguments passed in registers.
! 927:
! 928: If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls
! 929: whether the space for these arguments counts in the value of
! 930: `current_function_outgoing_args_size'.
! 931:
! 932: `STACK_PARMS_IN_REG_PARM_AREA'
! 933: Define this macro if `REG_PARM_STACK_SPACE' is defined, but the
! 934: stack parameters don't skip the area specified by it.
! 935:
! 936: Normally, when a parameter is not passed in registers, it is
! 937: placed on the stack beyond the `REG_PARM_STACK_SPACE' area.
! 938: Defining this macro suppresses this behavior and causes the
! 939: parameter to be passed on the stack in its natural location.
! 940:
! 941: `RETURN_POPS_ARGS (FUNDECL, FUNTYPE, STACK-SIZE)'
! 942: A C expression that should indicate the number of bytes of its own
! 943: arguments that a function pops on returning, or 0 if the function
! 944: pops no arguments and the caller must therefore pop them all after
! 945: the function returns.
! 946:
! 947: FUNDECL is a C variable whose value is a tree node that describes
! 948: the function in question. Normally it is a node of type
! 949: `FUNCTION_DECL' that describes the declaration of the function.
! 950: From this it is possible to obtain the DECL_MACHINE_ATTRIBUTES of
! 951: the function.
! 952:
! 953: FUNTYPE is a C variable whose value is a tree node that describes
! 954: the function in question. Normally it is a node of type
! 955: `FUNCTION_TYPE' that describes the data type of the function.
! 956: From this it is possible to obtain the data types of the value and
! 957: arguments (if known).
! 958:
! 959: When a call to a library function is being considered, FUNTYPE
! 960: will contain an identifier node for the library function. Thus, if
! 961: you need to distinguish among various library functions, you can
! 962: do so by their names. Note that "library function" in this
! 963: context means a function used to perform arithmetic, whose name is
! 964: known specially in the compiler and was not mentioned in the C
! 965: code being compiled.
! 966:
! 967: STACK-SIZE is the number of bytes of arguments passed on the
! 968: stack. If a variable number of bytes is passed, it is zero, and
! 969: argument popping will always be the responsibility of the calling
! 970: function.
! 971:
! 972: On the Vax, all functions always pop their arguments, so the
! 973: definition of this macro is STACK-SIZE. On the 68000, using the
! 974: standard calling convention, no functions pop their arguments, so
! 975: the value of the macro is always 0 in this case. But an
! 976: alternative calling convention is available in which functions
! 977: that take a fixed number of arguments pop them but other functions
! 978: (such as `printf') pop nothing (the caller pops all). When this
! 979: convention is in use, FUNTYPE is examined to determine whether a
! 980: function takes a fixed number of arguments.
1.1 root 981:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.