![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-7 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to gcc.info-7 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1: Info file gcc.info, produced by Makeinfo, -*- Text -*- from input
2: file gcc.texinfo.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
1.1.1.2 ! root 6: Copyright (C) 1988, 1989 Free Software Foundation, Inc.
1.1 root 7:
8: Permission is granted to make and distribute verbatim copies of this
9: manual provided the copyright notice and this permission notice are
10: preserved on all copies.
11:
12: Permission is granted to copy and distribute modified versions of
13: this manual under the conditions for verbatim copying, provided also
1.1.1.2 ! root 14: that the section entitled ``GNU General Public License'' is included
! 15: exactly as in the original, and provided that the entire resulting
! 16: derived work is distributed under the terms of a permission notice
! 17: identical to this one.
1.1 root 18:
19: Permission is granted to copy and distribute translations of this
20: manual into another language, under the above conditions for modified
1.1.1.2 ! root 21: versions, except that the section entitled ``GNU General Public
1.1 root 22: License'' and this permission notice may be included in translations
23: approved by the Free Software Foundation instead of in the original
24: English.
25:
26:
27:
1.1.1.2 ! root 28: File: gcc.info, Node: Registers, Next: Register Classes, Prev: Storage Layout, Up: Machine Macros
! 29:
! 30: Register Usage
! 31: ==============
! 32:
! 33: `FIRST_PSEUDO_REGISTER'
! 34: Number of hardware registers known to the compiler. They
! 35: receive numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the
! 36: first pseudo register's number really is assigned the number
! 37: `FIRST_PSEUDO_REGISTER'.
! 38:
! 39: `FIXED_REGISTERS'
! 40: An initializer that says which registers are used for fixed
! 41: purposes all throughout the compiled code and are therefore not
! 42: available for general allocation. These would include the stack
! 43: pointer, the frame pointer (except on machines where that can be
! 44: used as a general register when no frame pointer is needed), the
! 45: program counter on machines where that is considered one of the
! 46: addressable registers, and any other numbered register with a
! 47: standard use.
! 48:
! 49: This information is expressed as a sequence of numbers,
! 50: separated by commas and surrounded by braces. The Nth number is
! 51: 1 if register N is fixed, 0 otherwise.
! 52:
! 53: The table initialized from this macro, and the table initialized
! 54: by the following one, may be overridden at run time either
! 55: automatically, by the actions of the macro
! 56: `CONDITIONAL_REGISTER_USAGE', or by the user with the command
! 57: options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'.
! 58:
! 59: `CALL_USED_REGISTERS'
! 60: Like `FIXED_REGISTERS' but has 1 for each register that is
! 61: clobbered (in general) by function calls as well as for fixed
! 62: registers. This macro therefore identifies the registers that
! 63: are not available for general allocation of values that must
! 64: live across function calls.
! 65:
! 66: If a register has 0 in `CALL_USED_REGISTERS', the compiler
! 67: automatically saves it on function entry and restores it on
! 68: function exit, if the register is used within the function.
! 69:
! 70: `DEFAULT_CALLER_SAVES'
! 71: Define this macro if the target machine if function calls do not
! 72: preserve any registers; in other words, if `CALL_USED_REGISTERS'
! 73: has 1 for all registers. This macro enables `-fcaller-saves' by
! 74: default. Eventually that option will be enabled by default on
! 75: all machines and both the option and this macro will be
! 76: eliminated.
! 77:
! 78: `CONDITIONAL_REGISTER_USAGE'
! 79: Zero or more C statements that may conditionally modify two
! 80: variables `fixed_regs' and `call_used_regs' (both of type `char
! 81: []') after they have been initialized from the two preceding
! 82: macros.
! 83:
! 84: This is necessary in case the fixed or call-clobbered registers
! 85: depend on target flags.
! 86:
! 87: You need not define this macro if it has no work to do.
! 88:
! 89: If the usage of an entire class of registers depends on the
! 90: target flags, you may indicate this to GCC by using this macro
! 91: to modify `fixed_regs' and `call_used_regs' to 1 for each of the
! 92: registers in the classes which should not be used by GCC. Also
! 93: define the macro `REG_CLASS_FROM_LETTER' to return `NO_REGS' if
! 94: it is called with a letter for a class that shouldn't be used.
! 95:
! 96: (However, if this class is not included in `GENERAL_REGS' and
! 97: all of the insn patterns whose constraints permit this class are
! 98: controlled by target switches, then GCC will automatically avoid
! 99: using these registers when the target switches are opposed to
! 100: them.)
! 101:
! 102: `OVERLAPPING_REGNO_P (REGNO)'
! 103: If defined, this is a C expression whose value is nonzero if
! 104: hard register number REGNO is an overlapping register. This
! 105: means a hard register which overlaps a hard register with a
! 106: different number. (Such overlap is undesirable, but
! 107: occasionally it allows a machine to be supported which otherwise
! 108: could not be.) This macro must return nonzero for *all* the
! 109: registers which overlap each other. GNU CC can use an
! 110: overlapping register only in certain limited ways. It can be
! 111: used for allocation within a basic block, and may be spilled for
! 112: reloading; that is all.
! 113:
! 114: If this macro is not defined, it means that none of the hard
! 115: registers overlap each other. This is the usual situation.
! 116:
! 117: `INSN_CLOBBERS_REGNO_P (INSN, REGNO)'
! 118: If defined, this is a C expression whose value should be nonzero
! 119: if the insn INSN has the effect of mysteriously clobbering the
! 120: contents of hard register number REGNO. By ``mysterious'' we
! 121: mean that the insn's RTL expression doesn't describe such an
! 122: effect.
! 123:
! 124: If this macro is not defined, it means that no insn clobbers
! 125: registers mysteriously. This is the usual situation; all else
! 126: being equal, it is best for the RTL expression to show all the
! 127: activity.
! 128:
! 129: `PRESERVE_DEATH_INFO_REGNO_P (REGNO)'
! 130: If defined, this is a C expression whose value is nonzero if
! 131: accurate `REG_DEAD' notes are needed for hard register number
! 132: REGNO at the time of outputting the assembler code. When this
! 133: is so, a few optimizations that take place after register
! 134: allocation and could invalidate the death notes are not done
! 135: when this register is involved.
! 136:
! 137: You would arrange to preserve death info for a register when
! 138: some of the code in the machine description which is executed to
! 139: write the assembler code looks at the the death notes. This is
! 140: necessary only when the actual hardware feature which GNU CC
! 141: thinks of as a register is not actually a register of the usual
! 142: sort. (It might, for example, be a hardware stack.)
! 143:
! 144: If this macro is not defined, it means that no death notes need
! 145: to be preserved. This is the usual situation.
! 146:
! 147: `HARD_REGNO_REGS (REGNO, MODE)'
! 148: A C expression for the number of consecutive hard registers,
! 149: starting at register number REGNO, required to hold a value of
! 150: mode MODE.
! 151:
! 152: On a machine where all registers are exactly one word, a
! 153: suitable definition of this macro is
! 154:
! 155: #define HARD_REGNO_NREGS(REGNO, MODE) \
! 156: ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
! 157: / UNITS_PER_WORD))
! 158:
! 159: `HARD_REGNO_MODE_OK (REGNO, MODE)'
! 160: A C expression that is nonzero if it is permissible to store a
! 161: value of mode MODE in hard register number REGNO (or in several
! 162: registers starting with that one). For a machine where all
! 163: registers are equivalent, a suitable definition is
! 164:
! 165: #define HARD_REGNO_MODE_OK(REGNO, MODE) 1
! 166:
! 167: It is not necessary for this macro to check for fixed register
! 168: numbers because the allocation mechanism considers them to be
! 169: always occupied.
! 170:
! 171: Many machines have special registers for floating point
! 172: arithmetic. Often people assume that floating point machine
! 173: modes are allowed only in floating point registers. This is not
! 174: true. Any registers that can hold integers can safely *hold* a
! 175: floating point machine mode, whether or not floating arithmetic
! 176: can be done on it in those registers.
! 177:
! 178: The true significance of special floating registers is rather
! 179: than non-floating-point machine modes *may not* go in those
! 180: registers. This is true if the floating registers normalize any
! 181: value stored in them, because storing a non-floating value there
! 182: would garble it. If the floating registers do not automatically
! 183: normalize, if you can store any bit pattern in one and retrieve
! 184: it unchanged without a trap, then any machine mode may go in a
! 185: floating register and this macro should say so.
! 186:
! 187: Sometimes there are floating registers that are especially slow
! 188: to access, so that it is better to store a value in a stack
! 189: frame than in such a register if floating point arithmetic is
! 190: not being done. As long as the floating registers are not in
! 191: class `GENERAL_REGS', they will not be used unless some insn's
! 192: constraint asks for one.
! 193:
! 194: It is obligatory to support floating point `move' instructions
! 195: into and out of any registers that can hold fixed point values,
! 196: because unions and structures (which have modes `SImode' or
! 197: `DImode') can be in those registers and they may have floating
! 198: point members.
! 199:
! 200: There may also be a need to support fixed point `move'
! 201: instructions in and out of floating point registers.
! 202: Unfortunately, I have forgotten why this was so, and I don't
! 203: know whether it is still true. If `HARD_REGNO_MODE_OK' rejects
! 204: fixed point values in floating point registers, then the
! 205: constraints of the fixed point `move' instructions must be
! 206: designed to avoid ever trying to reload into a floating point
! 207: register.
! 208:
! 209: `MODES_TIEABLE_P (MODE1, MODE2)'
! 210: A C expression that is nonzero if it is desirable to choose
! 211: register allocation so as to avoid move instructions between a
! 212: value of mode MODE1 and a value of mode MODE2.
! 213:
! 214: If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R,
! 215: MODE2)' are ever different for any R, then `MODES_TIEABLE_P
! 216: (MODE1, MODE2)' must be zero.
! 217:
! 218: `PC_REGNUM'
! 219: If the program counter has a register number, define this as
! 220: that register number. Otherwise, do not define it.
! 221:
! 222: `STACK_POINTER_REGNUM'
! 223: The register number of the stack pointer register, which must
! 224: also be a fixed register according to `FIXED_REGISTERS'. On
! 225: many machines, the hardware determines which register this is.
! 226:
! 227: `FRAME_POINTER_REGNUM'
! 228: The register number of the frame pointer register, which is used
! 229: to access automatic variables in the stack frame. On some
! 230: machines, the hardware determines which register this is. On
! 231: other machines, you can choose any register you wish for this
! 232: purpose.
! 233:
! 234: `FRAME_POINTER_REQUIRED'
! 235: A C expression which is nonzero if a function must have and use
! 236: a frame pointer. This expression is evaluated in the reload
! 237: pass, in the function `reload', and it can in principle examine
! 238: the current function and decide according to the facts, but on
! 239: most machines the constant 0 or the constant 1 suffices. Use 0
! 240: when the machine allows code to be generated with no frame
! 241: pointer, and doing so saves some time or space. Use 1 when
! 242: there is no possible advantage to avoiding a frame pointer.
! 243:
! 244: In certain cases, the compiler does not know how to produce
! 245: valid code without a frame pointer. The compiler recognizes
! 246: those cases and automatically gives the function a frame pointer
! 247: regardless of what `FRAME_POINTER_REQUIRED' says. You don't
! 248: need to worry about them.
! 249:
! 250: In a function that does not require a frame pointer, the frame
! 251: pointer register can be allocated for ordinary usage, unless you
! 252: mark it as a fixed register. See `FIXED_REGISTERS' for more
! 253: information.
! 254:
! 255: `ARG_POINTER_REGNUM'
! 256: The register number of the arg pointer register, which is used
! 257: to access the function's argument list. On some machines, this
! 258: is the same as the frame pointer register. On some machines,
! 259: the hardware determines which register this is. On other
! 260: machines, you can choose any register you wish for this purpose.
! 261: If this is not the same register as the frame pointer register,
! 262: then you must mark it as a fixed register according to
! 263: `FIXED_REGISTERS'.
! 264:
! 265: `STATIC_CHAIN_REGNUM'
! 266: The register number used for passing a function's static chain
! 267: pointer. This is needed for languages such as Pascal and Algol
! 268: where functions defined within other functions can access the
! 269: local variables of the outer functions; it is not currently used
! 270: because C does not provide this feature, but you must define the
! 271: macro.
! 272:
! 273: The static chain register need not be a fixed register.
! 274:
! 275: `STRUCT_VALUE_REGNUM'
! 276: When a function's value's mode is `BLKmode', the value is not
! 277: returned according to `FUNCTION_VALUE'. Instead, the caller
! 278: passes the address of a block of memory in which the value
! 279: should be stored.
! 280:
! 281: If this value is passed in a register, then
! 282: `STRUCT_VALUE_REGNUM' should be the number of that register.
! 283:
! 284: `STRUCT_VALUE'
! 285: If the structure value address is not passed in a register,
! 286: define `STRUCT_VALUE' as an expression returning an RTX for the
! 287: place where the address is passed. If it returns a `mem' RTX,
! 288: the address is passed as an ``invisible'' first argument.
! 289:
! 290: `STRUCT_VALUE_INCOMING_REGNUM'
! 291: On some architectures the place where the structure value
! 292: address is found by the called function is not the same place
! 293: that the caller put it. This can be due to register windows, or
! 294: it could be because the function prologue moves it to a
! 295: different place.
! 296:
! 297: If the incoming location of the structure value address is in a
! 298: register, define this macro as the register number.
! 299:
! 300: `STRUCT_VALUE_INCOMING'
! 301: If the incoming location is not a register, define
! 302: `STRUCT_VALUE_INCOMING' as an expression for an RTX for where
! 303: the called function should find the value. If it should find
! 304: the value on the stack, define this to create a `mem' which
! 305: refers to the frame pointer. If the value is a `mem', the
! 306: compiler assumes it is for an invisible first argument, and
! 307: leaves space for it when finding the first real argument.
! 308:
! 309: `REG_ALLOC_ORDER'
! 310: If defined, an initializer for a vector of integers, containing
! 311: the numbers of hard registers in the order in which the GNU CC
! 312: should prefer to use them (from most preferred to least).
! 313:
! 314: If this macro is not defined, registers are used lowest numbered
! 315: first (all else being equal).
! 316:
! 317: One use of this macro is on the 360, where the highest numbered
! 318: registers must always be saved and the save-multiple-registers
! 319: instruction supports only sequences of consecutive registers.
! 320: This macro is defined to cause the highest numbered allocatable
! 321: registers to be used first.
! 322:
! 323:
! 324:
! 325: File: gcc.info, Node: Register Classes, Next: Stack Layout, Prev: Registers, Up: Machine Macros
! 326:
! 327: Register Classes
! 328: ================
! 329:
! 330: On many machines, the numbered registers are not all equivalent. For
! 331: example, certain registers may not be allowed for indexed addressing;
! 332: certain registers may not be allowed in some instructions. These
! 333: machine restrictions are described to the compiler using "register
! 334: classes".
! 335:
! 336: You define a number of register classes, giving each one a name and
! 337: saying which of the registers belong to it. Then you can specify
! 338: register classes that are allowed as operands to particular
! 339: instruction patterns.
! 340:
! 341: In general, each register will belong to several classes. In fact,
! 342: one class must be named `ALL_REGS' and contain all the registers.
! 343: Another class must be named `NO_REGS' and contain no registers.
! 344: Often the union of two classes will be another class; however, this
! 345: is not required.
! 346:
! 347: One of the classes must be named `GENERAL_REGS'. There is nothing
! 348: terribly special about the name, but the operand constraint letters
! 349: `r' and `g' specify this class. If `GENERAL_REGS' is the same as
! 350: `ALL_REGS', just define it as a macro which expands to `ALL_REGS'.
! 351:
! 352: The way classes other than `GENERAL_REGS' are specified in operand
! 353: constraints is through machine-dependent operand constraint letters.
! 354: You can define such letters to correspond to various classes, then
! 355: use them in operand constraints.
! 356:
! 357: You should define a class for the union of two classes whenever some
! 358: instruction allows both classes. For example, if an instruction
! 359: allows either a floating-point (coprocessor) register or a general
! 360: register for a certain operand, you should define a class
! 361: `FLOAT_OR_GENERAL_REGS' which includes both of them. Otherwise you
! 362: will get suboptimal code.
! 363:
! 364: You must also specify certain redundant information about the
! 365: register classes: for each class, which classes contain it and which
! 366: ones are contained in it; for each pair of classes, the largest class
! 367: contained in their union.
! 368:
! 369: Register classes used for input-operands of bitwise-and or shift
! 370: instructions have a special requirement: each such class must have,
! 371: for each fixed-point machine mode, a subclass whose registers can
! 372: transfer that mode to or from memory. For example, on some machines,
! 373: the operations for single-byte values (`QImode') are limited to
! 374: certain registers. When this is so, each register class that is used
! 375: in a bitwise-and or shift instruction must have a subclass consisting
! 376: of registers from which single-byte values can be loaded or stored.
! 377: This is so that `PREFERRED_RELOAD_CLASS' can always have a possible
! 378: value to return.
! 379:
! 380: `enum reg_class'
! 381: An enumeral type that must be defined with all the register
! 382: class names as enumeral values. `NO_REGS' must be first.
! 383: `ALL_REGS' must be the last register class, followed by one more
! 384: enumeral value, `LIM_REG_CLASSES', which is not a register class
! 385: but rather tells how many classes there are.
! 386:
! 387: Each register class has a number, which is the value of casting
! 388: the class name to type `int'. The number serves as an index in
! 389: many of the tables described below.
! 390:
! 391: `N_REG_CLASSES'
! 392: The number of distinct register classes, defined as follows:
! 393:
! 394: #define N_REG_CLASSES (int) LIM_REG_CLASSES
! 395:
! 396: `REG_CLASS_NAMES'
! 397: An initializer containing the names of the register classes as C
! 398: string constants. These names are used in writing some of the
! 399: debugging dumps.
! 400:
! 401: `REG_CLASS_CONTENTS'
! 402: An initializer containing the contents of the register classes,
! 403: as integers which are bit masks. The Nth integer specifies the
! 404: contents of class N. The way the integer MASK is interpreted is
! 405: that register R is in the class if `MASK & (1 << R)' is 1.
! 406:
! 407: When the machine has more than 32 registers, an integer does not
! 408: suffice. Then the integers are replaced by sub-initializers,
! 409: braced groupings containing several integers. Each
! 410: sub-initializer must be suitable as an initializer for the type
! 411: `HARD_REG_SET' which is defined in `hard-reg-set.h'.
! 412:
! 413: `REGNO_REG_CLASS (REGNO)'
! 414: A C expression whose value is a register class containing hard
! 415: register REGNO. In general there is more that one such class;
! 416: choose a class which is "minimal", meaning that no smaller class
! 417: also contains the register.
! 418:
! 419: `BASE_REG_CLASS'
! 420: A macro whose definition is the name of the class to which a
! 421: valid base register must belong. A base register is one used in
! 422: an address which is the register value plus a displacement.
! 423:
! 424: `INDEX_REG_CLASS'
! 425: A macro whose definition is the name of the class to which a
! 426: valid index register must belong. An index register is one used
! 427: in an address where its value is either multiplied by a scale
! 428: factor or added to another register (as well as added to a
! 429: displacement).
! 430:
! 431: `REG_CLASS_FROM_LETTER (CHAR)'
! 432: A C expression which defines the machine-dependent operand
! 433: constraint letters for register classes. If CHAR is such a
! 434: letter, the value should be the register class corresponding to
! 435: it. Otherwise, the value should be `NO_REGS'.
! 436:
! 437: `REGNO_OK_FOR_BASE_P (NUM)'
! 438: A C expression which is nonzero if register number NUM is
! 439: suitable for use as a base register in operand addresses. It
! 440: may be either a suitable hard register or a pseudo register that
! 441: has been allocated such a hard register.
! 442:
! 443: `REGNO_OK_FOR_INDEX_P (NUM)'
! 444: A C expression which is nonzero if register number NUM is
! 445: suitable for use as an index register in operand addresses. It
! 446: may be either a suitable hard register or a pseudo register that
! 447: has been allocated such a hard register.
! 448:
! 449: The difference between an index register and a base register is
! 450: that the index register may be scaled. If an address involves
! 451: the sum of two registers, neither one of them scaled, then
! 452: either one may be labeled the ``base'' and the other the
! 453: ``index''; but whichever labeling is used must fit the machine's
! 454: constraints of which registers may serve in each capacity. The
! 455: compiler will try both labelings, looking for one that is valid,
! 456: and will reload one or both registers only if neither labeling
! 457: works.
! 458:
! 459: `PREFERRED_RELOAD_CLASS (X, CLASS)'
! 460: A C expression that places additional restrictions on the
! 461: register class to use when it is necessary to copy value X into
! 462: a register in class CLASS. The value is a register class;
! 463: perhaps CLASS, or perhaps another, smaller class. On many
! 464: machines, the definition
! 465:
! 466: #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
! 467:
! 468: is safe.
! 469:
! 470: Sometimes returning a more restrictive class makes better code.
! 471: For example, on the 68000, when X is an integer constant that is
! 472: in range for a `moveq' instruction, the value of this macro is
! 473: always `DATA_REGS' as long as CLASS includes the data registers.
! 474: Requiring a data register guarantees that a `moveq' will be used.
! 475:
! 476: If X is a `const_double', by returning `NO_REGS' you can force X
! 477: into a memory constant. This is useful on certain machines
! 478: where immediate floating values cannot be loaded into certain
! 479: kinds of registers.
! 480:
! 481: In a shift instruction or a bitwise-and instruction, the mode of
! 482: X, the value being reloaded, may not be the same as the mode of
! 483: the instruction's operand. (They will both be fixed-point
! 484: modes, however.) In such a case, CLASS may not be a safe value
! 485: to return. CLASS is certainly valid for the instruction, but it
! 486: may not be valid for reloading X. This problem can occur on
! 487: machines such as the 68000 and 80386 where some registers can
! 488: handle full-word values but cannot handle single-byte values.
! 489:
! 490: On such machines, this macro must examine the mode of X and
! 491: return a subclass of CLASS which can handle loads and stores of
! 492: that mode. On the 68000, where address registers cannot handle
! 493: `QImode', if X has `QImode' then you must return `DATA_REGS'.
! 494: If CLASS is `ADDR_REGS', then there is no correct value to
! 495: return; but the shift and bitwise-and instructions don't use
! 496: `ADDR_REGS', so this fatal case never arises.
! 497:
! 498: `CLASS_MAX_NREGS (CLASS, MODE)'
! 499: A C expression for the maximum number of consecutive registers
! 500: of class CLASS needed to hold a value of mode MODE.
! 501:
! 502: This is closely related to the macro `HARD_REGNO_NREGS'. In
! 503: fact, the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)'
! 504: should be the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)'
! 505: for all REGNO values in the class CLASS.
! 506:
! 507: This macro helps control the handling of multiple-word values in
! 508: the reload pass.
! 509:
! 510: Two other special macros describe which constants fit which
! 511: constraint letters.
! 512:
! 513: `CONST_OK_FOR_LETTER_P (VALUE, C)'
! 514: A C expression that defines the machine-dependent operand
! 515: constraint letters that specify particular ranges of integer
! 516: values. If C is one of those letters, the expression should
! 517: check that VALUE, an integer, is in the appropriate range and
! 518: return 1 if so, 0 otherwise. If C is not one of those letters,
! 519: the value should be 0 regardless of VALUE.
! 520:
! 521: `CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)'
! 522: A C expression that defines the machine-dependent operand
! 523: constraint letters that specify particular ranges of floating
! 524: values. If C is one of those letters, the expression should
! 525: check that VALUE, an RTX of code `const_double', is in the
! 526: appropriate range and return 1 if so, 0 otherwise. If C is not
! 527: one of those letters, the value should be 0 regardless of VALUE.
! 528:
! 529:
! 530:
1.1 root 531: File: gcc.info, Node: Stack Layout, Next: Library Names, Prev: Register Classes, Up: Machine Macros
532:
533: Describing Stack Layout
534: =======================
535:
536: `STACK_GROWS_DOWNWARD'
537: Define this macro if pushing a word onto the stack moves the
538: stack pointer to a smaller address.
539:
540: When we say, ``define this macro if ...,'' it means that the
541: compiler checks this macro only with `#ifdef' so the precise
542: definition used does not matter.
543:
544: `FRAME_GROWS_DOWNWARD'
545: Define this macro if the addresses of local variable slots are
546: at negative offsets from the frame pointer.
547:
548: `STARTING_FRAME_OFFSET'
549: Offset from the frame pointer to the first local variable slot
550: to be allocated.
551:
552: If `FRAME_GROWS_DOWNWARD', the next slot's offset is found by
553: subtracting the length of the first slot from
554: `STARTING_FRAME_OFFSET'. Otherwise, it is found by adding the
555: length of the first slot to the value `STARTING_FRAME_OFFSET'.
556:
557: `PUSH_ROUNDING (NPUSHED)'
558: A C expression that is the number of bytes actually pushed onto
559: the stack when an instruction attempts to push NPUSHED bytes.
560:
561: If the target machine does not have a push instruction, do not
562: define this macro. That directs GNU CC to use an alternate
563: strategy: to allocate the entire argument block and then store
564: the arguments into it.
565:
566: On some machines, the definition
567:
568: #define PUSH_ROUNDING(BYTES) (BYTES)
569:
570: will suffice. But on other machines, instructions that appear
571: to push one byte actually push two bytes in an attempt to
572: maintain alignment. Then the definition should be
573:
574: #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
575:
576: `FIRST_PARM_OFFSET (FUNDECL)'
577: Offset from the argument pointer register to the first
578: argument's address. On some machines it may depend on the data
579: type of the function. (In the next version of GNU CC, the
580: argument will be changed to the function data type rather than
581: its declaration.)
582:
583: `FIRST_PARM_CALLER_OFFSET (FUNDECL)'
584: Define this macro on machines where register parameters have
585: shadow locations on the stack, at addresses below the nominal
586: parameter. This matters because certain arguments cannot be
587: passed on the stack. On these machines, such arguments must be
588: stored into the shadow locations.
589:
590: This macro should expand into a C expression whose value is the
591: offset of the first parameter's shadow location from the nominal
592: stack pointer value. (That value is itself computed by adding
593: the value of `STACK_POINTER_OFFSET' to the stack pointer
594: register.)
595:
1.1.1.2 ! root 596: `STACK_ARGS_ADJUST (SIZE)'
! 597: Define this macro if the machine requires padding on the stack
! 598: for certain function calls. This is padding on a
! 599: per-function-call basis, not padding for individual arguments.
! 600:
! 601: The argument SIZE will be a C variable of type `struct arg_data'
! 602: which contains two fields, an integer named `constant' and an
! 603: RTX named `var'. These together represent a size measured in
! 604: bytes which is the sum of the integer and the RTX. Most of the
! 605: time `var' is 0, which means that the size is simply the integer.
! 606:
! 607: The definition should be a C statement or compound statement
! 608: which alters the variable supplied in whatever way you wish.
! 609:
! 610: Note that the value you leave in the variable `size' will
! 611: ultimately be rounded up to a multiple of `STACK_BOUNDARY' bits.
! 612:
! 613: This macro is not fully implemented for machines which have push
! 614: instructions (i.e., on which `PUSH_ROUNDING' is defined).
! 615:
1.1 root 616: `RETURN_POPS_ARGS (FUNTYPE)'
617: A C expression that should be 1 if a function pops its own
618: arguments on returning, or 0 if the function pops no arguments
619: and the caller must therefore pop them all after the function
620: returns.
621:
622: FUNTYPE is a C variable whose value is a tree node that
623: describes the function in question. Normally it is a node of
624: type `FUNCTION_TYPE' that describes the data type of the function.
625: From this it is possible to obtain the data types of the value
626: and arguments (if known).
627:
628: When a call to a library function is being considered, FUNTYPE
629: will contain an identifier node for the library function. Thus,
630: if you need to distinguish among various library functions, you
631: can do so by their names. Note that ``library function'' in
632: this context means a function used to perform arithmetic, whose
633: name is known specially in the compiler and was not mentioned in
634: the C code being compiled.
635:
636: On the Vax, all functions always pop their arguments, so the
637: definition of this macro is 1. On the 68000, using the standard
638: calling convention, no functions pop their arguments, so the
639: value of the macro is always 0 in this case. But an alternative
640: calling convention is available in which functions that take a
641: fixed number of arguments pop them but other functions (such as
642: `printf') pop nothing (the caller pops all). When this
643: convention is in use, FUNTYPE is examined to determine whether a
644: function takes a fixed number of arguments.
645:
646: `FUNCTION_VALUE (VALTYPE, FUNC)'
647: A C expression to create an RTX representing the place where a
648: function returns a value of data type VALTYPE. VALTYPE is a
649: tree node representing a data type. Write `TYPE_MODE (VALTYPE)'
650: to get the machine mode used to represent that type. On many
651: machines, only the mode is relevant. (Actually, on most
652: machines, scalar values are returned in the same place
653: regardless of mode).
654:
655: If the precise function being called is known, FUNC is a tree
656: node (`FUNCTION_DECL') for it; otherwise, FUNC is a null
657: pointer. This makes it possible to use a different
658: value-returning convention for specific functions when all their
659: calls are known.
660:
661: `FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)'
662: Define this macro if the target machine has ``register windows''
663: so that the register in which a function returns its value is
664: not the same as the one in which the caller sees the value.
665:
666: For such machines, `FUNCTION_VALUE' computes the register in
667: which the caller will see the value, and
668: `FUNCTION_OUTGOING_VALUE' should be defined in a similar fashion
669: to tell the function where to put the value.
670:
671: If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE'
672: serves both purposes.
673:
1.1.1.2 ! root 674: `RETURN_IN_MEMORY (TYPE)'
! 675: A C expression which can inhibit the returning of certain
! 676: function values in registers, based on the type of value. A
! 677: nonzero value says to return the function value in memory, just
! 678: as large structures are always returned. Here TYPE will be a C
! 679: expression of type `tree', representing the data type of the
! 680: value.
! 681:
! 682: Note that values of mode `BLKmode' are returned in memory
! 683: regardless of this macro. Also, the option
! 684: `-fpcc-struct-return' takes effect regardless of this macro. On
! 685: most systems, it is possible to leave the macro undefined; this
! 686: causes a default definition to be used, whose value is the
! 687: constant 0.
! 688:
1.1 root 689: `LIBCALL_VALUE (MODE)'
690: A C expression to create an RTX representing the place where a
691: library function returns a value of mode MODE. If the precise
692: function being called is known, FUNC is a tree node
693: (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer.
694: This makes it possible to use a different value-returning
695: convention for specific functions when all their calls are known.
696:
697: Note that ``library function'' in this context means a compiler
698: support routine, used to perform arithmetic, whose name is known
699: specially by the compiler and was not mentioned in the C code
700: being compiled.
701:
702: `FUNCTION_VALUE_REGNO_P (REGNO)'
703: A C expression that is nonzero if REGNO is the number of a hard
704: register in which the values of called function may come back.
705:
706: A register whose use for returning values is limited to serving
707: as the second of a pair (for a value of type `double', say) need
708: not be recognized by this macro. So for most machines, this
709: definition suffices:
710:
711: #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
712:
713: If the machine has register windows, so that the caller and the
714: called function use different registers for the return value,
715: this macro should recognize only the caller's register numbers.
716:
717: `FUNCTION_ARG (CUM, MODE, TYPE, NAMED)'
718: A C expression that controls whether a function argument is
719: passed in a register, and which register.
720:
721: The arguments are CUM, which summarizes all the previous
722: arguments; MODE, the machine mode of the argument; TYPE, the
723: data type of the argument as a tree node or 0 if that is not
724: known (which happens for C support library functions); and
725: NAMED, which is 1 for an ordinary argument and 0 for nameless
726: arguments that correspond to `...' in the called function's
727: prototype.
728:
729: The value of the expression should either be a `reg' RTX for the
730: hard register in which to pass the argument, or zero to pass the
731: argument on the stack.
732:
733: For the Vax and 68000, where normally all arguments are pushed,
734: zero suffices as a definition.
735:
736: `FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)'
737: Define this macro if the target machine has ``register
738: windows'', so that the register in which a function sees an
739: arguments is not necessarily the same as the one in which the
740: caller passed the argument.
741:
742: For such machines, `FUNCTION_ARG' computes the register in which
743: the caller passes the value, and `FUNCTION_INCOMING_ARG' should
744: be defined in a similar fashion to tell the function being
745: called where the arguments will arrive.
746:
747: If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
748: both purposes.
749:
750: `FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)'
751: A C expression for the number of words, at the beginning of an
752: argument, must be put in registers. The value must be zero for
753: arguments that are passed entirely in registers or that are
754: entirely pushed on the stack.
755:
756: On some machines, certain arguments must be passed partially in
757: registers and partially in memory. On these machines, typically
758: the first N words of arguments are passed in registers, and the
759: rest on the stack. If a multi-word argument (a `double' or a
760: structure) crosses that boundary, its first few words must be
761: passed in registers and the rest must be pushed. This macro
762: tells the compiler when this occurs, and how many of the words
763: should go in registers.
764:
765: `FUNCTION_ARG' for these arguments should return the first
766: register to be used by the caller for this argument; likewise
767: `FUNCTION_INCOMING_ARG', for the called function.
768:
769: `CUMULATIVE_ARGS'
770: A C type for declaring a variable that is used as the first
771: argument of `FUNCTION_ARG' and other related values. For some
772: target machines, the type `int' suffices and can hold the number
773: of bytes of argument so far.
774:
775: `INIT_CUMULATIVE_ARGS (CUM, FNTYPE)'
776: A C statement (sans semicolon) for initializing the variable CUM
777: for the state at the beginning of the argument list. The
778: variable has type `CUMULATIVE_ARGS'. The value of FNTYPE is the
779: tree node for the data type of the function which will receive
780: the args, or 0 if the args are to a compiler support library
781: function.
782:
783: `FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)'
1.1.1.2 ! root 784: A C statement (sans semicolon) to update the summarizer variable
! 785: CUM to advance past an argument in the argument list. The
! 786: values MODE, TYPE and NAMED describe that argument. Once this
! 787: is done, the variable CUM is suitable for analyzing the
! 788: *following* argument with `FUNCTION_ARG', etc.
1.1 root 789:
790: `FUNCTION_ARG_REGNO_P (REGNO)'
791: A C expression that is nonzero if REGNO is the number of a hard
792: register in which function arguments are sometimes passed. This
793: does *not* include implicit arguments such as the static chain
794: and the structure-value address. On many machines, no registers
795: can be used for this purpose since all function arguments are
796: pushed on the stack.
797:
798: `FUNCTION_ARG_PADDING (MODE, SIZE)'
799: If defined, a C expression which determines whether, and in
800: which direction, to pad out an argument with extra space. The
801: value should be of type `enum direction': either `upward' to pad
802: above the argument, `downward' to pad below, or `none' to
803: inhibit padding.
804:
805: The argument SIZE is an RTX which describes the size of the
806: argument, in bytes. It should be used only if MODE is
807: `BLKmode'. Otherwise, SIZE is 0.
808:
809: This macro does not control the *amount* of padding; that is
810: always just enough to reach the next multiple of `PARM_BOUNDARY'.
811:
812: This macro has a default definition which is right for most
813: systems. For little-endian machines, the default is to pad
814: upward. For big-endian machines, the default is to pad downward
815: for an argument of constant size shorter than an `int', and
816: upward otherwise.
817:
818: `FUNCTION_PROLOGUE (FILE, SIZE)'
819: A C compound statement that outputs the assembler code for entry
820: to a function. The prologue is responsible for setting up the
821: stack frame, initializing the frame pointer register, saving
822: registers that must be saved, and allocating SIZE additional
823: bytes of storage for the local variables. SIZE is an integer.
824: FILE is a stdio stream to which the assembler code should be
825: output.
826:
827: The label for the beginning of the function need not be output
828: by this macro. That has already been done when the macro is run.
829:
830: To determine which registers to save, the macro can refer to the
831: array `regs_ever_live': element R is nonzero if hard register R
832: is used anywhere within the function. This implies the function
833: prologue should save register R, but not if it is one of the
834: call-used registers.
835:
836: On machines where functions may or may not have frame-pointers,
837: the function entry code must vary accordingly; it must set up
838: the frame pointer if one is wanted, and not otherwise. To
839: determine whether a frame pointer is in wanted, the macro can
840: refer to the variable `frame_pointer_needed'. The variable's
841: value will be 1 at run time in a function that needs a frame
842: pointer.
843:
844: `FUNCTION_PROFILER (FILE, LABELNO)'
845: A C statement or compound statement to output to FILE some
846: assembler code to call the profiling subroutine `mcount'.
847: Before calling, the assembler code must load the address of a
848: counter variable into a register where `mcount' expects to find
849: the address. The name of this variable is `LP' followed by the
850: number LABELNO, so you would generate the name using `LP%d' in a
851: `fprintf'.
852:
853: The details of how the address should be passed to `mcount' are
854: determined by your operating system environment, not by GNU CC.
855: To figure them out, compile a small program for profiling using
856: the system's installed C compiler and look at the assembler code
857: that results.
858:
1.1.1.2 ! root 859: `FUNCTION_BLOCK_PROFILER (FILE, LABELNO)'
! 860: A C statement or compound statement to output to FILE some
! 861: assembler code to initialize basic-block profiling for the
! 862: current object module. This code should call the subroutine
! 863: `__bb_init_func' once per object module, passing it as its sole
! 864: argument the address of a block allocated in the object module.
! 865:
! 866: The name of the block is a local symbol made with this statement:
! 867:
! 868: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0);
! 869:
! 870: Of course, since you are writing the definition of
! 871: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you
! 872: can take a short cut in the definition of this macro and use the
! 873: name that you know will result.
! 874:
! 875: The first word of this block is a flag which will be nonzero if
! 876: the object module has already been initialized. So test this
! 877: word first, and do not call `__bb_init_func' if the flag is
! 878: nonzero.
! 879:
! 880: `BLOCK_PROFILER (FILE, BLOCKNO)'
! 881: A C statement or compound statement to increment the count
! 882: associated with the basic block number BLOCKNO. Basic blocks
! 883: are numbered separately from zero within each compilation. The
! 884: count associated with block number BLOCKNO is at index BLOCKNO
! 885: in a vector of words; the name of this array is a local symbol
! 886: made with this statement:
! 887:
! 888: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2);
! 889:
! 890: Of course, since you are writing the definition of
! 891: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you
! 892: can take a short cut in the definition of this macro and use the
! 893: name that you know will result.
! 894:
1.1 root 895: `EXIT_IGNORES_STACK'
896: Define this macro as a C expression that is nonzero if the
897: return instruction or the function epilogue ignores the value of
898: the stack pointer; in other words, if it is safe to delete an
899: instruction to adjust the stack pointer before a return from the
900: function.
901:
902: Note that this macro's value is relevant only for for which
903: frame pointers are maintained. It is never possible to delete a
904: final stack adjustment in a function that has no frame pointer,
905: and the compiler knows this regardless of `EXIT_IGNORES_STACK'.
906:
907: `FUNCTION_EPILOGUE (FILE, SIZE)'
908: A C compound statement that outputs the assembler code for exit
909: from a function. The epilogue is responsible for restoring the
910: saved registers and stack pointer to their values when the
911: function was called, and returning control to the caller. This
912: macro takes the same arguments as the macro `FUNCTION_PROLOGUE',
913: and the registers to restore are determined from
914: `regs_ever_live' and `CALL_USED_REGISTERS' in the same way.
915:
916: On some machines, there is a single instruction that does all
917: the work of returning from the function. On these machines,
918: give that instruction the name `return' and do not define the
919: macro `FUNCTION_EPILOGUE' at all.
920:
921: Do not define a pattern named `return' if you want the
922: `FUNCTION_EPILOGUE' to be used. If you want the target switches
923: to control whether return instructions or epilogues are used,
924: define a `return' pattern with a validity condition that tests
925: the target switches appropriately. If the `return' pattern's
926: validity condition is false, epilogues will be used.
927:
928: On machines where functions may or may not have frame-pointers,
929: the function exit code must vary accordingly. Sometimes the
930: code for these two cases is completely different. To determine
931: whether a frame pointer is in wanted, the macro can refer to the
932: variable `frame_pointer_needed'. The variable's value will be 1
933: at run time in a function that needs a frame pointer.
934:
935: On some machines, some functions pop their arguments on exit
936: while others leave that for the caller to do. For example, the
937: 68020 when given `-mrtd' pops arguments in functions that take a
938: fixed number of arguments.
939:
940: Your definition of the macro `RETURN_POPS_ARGS' decides which
941: functions pop their own arguments. `FUNCTION_EPILOGUE' needs to
942: know what was decided. The variable
943: `current_function_pops_args' is nonzero if the function should
944: pop its own arguments. If so, use the variable
945: `current_function_args_size' as the number of bytes to pop.
946:
947: `FIX_FRAME_POINTER_ADDRESS (ADDR, DEPTH)'
948: A C compound statement to alter a memory address that uses the
949: frame pointer register so that it uses the stack pointer
950: register instead. This must be done in the instructions that
951: load parameter values into registers, when the reload pass
952: determines that a frame pointer is not necessary for the
953: function. ADDR will be a C variable name, and the updated
954: address should be stored in that variable. DEPTH will be the
955: current depth of stack temporaries (number of bytes of arguments
956: currently pushed). The change in offset between a
957: frame-pointer-relative address and a stack-pointer-relative
958: address must include DEPTH.
959:
960: Even if your machine description specifies there will always be
961: a frame pointer in the frame pointer register, you must still
962: define `FIX_FRAME_POINTER_ADDRESS', but the definition will
963: never be executed at run time, so it may be empty.
964:
965:
966:
967: File: gcc.info, Node: Library Names, Next: Addressing Modes, Prev: Stack Layout, Up: Machine Macros
968:
969: Library Subroutine Names
970: ========================
971:
1.1.1.2 ! root 972: `MULSI3_LIBCALL'
! 973: A C string constant giving the name of the function to call for
! 974: multiplication of one signed full-word by another. If you do
! 975: not define this macro, the default name is used, which is
! 976: `__mulsi3', a function defined in `gnulib'.
! 977:
! 978: `UMULSI3_LIBCALL'
! 979: A C string constant giving the name of the function to call for
! 980: multiplication of one unsigned full-word by another. If you do
! 981: not define this macro, the default name is used, which is
! 982: `__umulsi3', a function defined in `gnulib'.
! 983:
! 984: `DIVSI3_LIBCALL'
! 985: A C string constant giving the name of the function to call for
! 986: division of one signed full-word by another. If you do not
! 987: define this macro, the default name is used, which is
! 988: `__divsi3', a function defined in `gnulib'.
! 989:
1.1 root 990: `UDIVSI3_LIBCALL'
991: A C string constant giving the name of the function to call for
1.1.1.2 ! root 992: division of one unsigned full-word by another. If you do not
! 993: define this macro, the default name is used, which is
! 994: `__udivsi3', a function defined in `gnulib'.
! 995:
! 996: `MODSI3_LIBCALL'
! 997: A C string constant giving the name of the function to call for
! 998: the remainder in division of one signed full-word by another.
! 999: If you do not define this macro, the default name is used, which
! 1000: is `__modsi3', a function defined in `gnulib'.
1.1 root 1001:
1002: `UMODSI3_LIBCALL'
1003: A C string constant giving the name of the function to call for
1.1.1.2 ! root 1004: the remainder in division of one unsigned full-word by another.
! 1005: If you do not define this macro, the default name is used, which
! 1006: is `__umodsi3', a function defined in `gnulib'.
1.1 root 1007:
1008: `TARGET_MEM_FUNCTIONS'
1009: Define this macro if GNU CC should generate calls to the System
1010: V (and ANSI C) library functions `memcpy' and `memset' rather
1011: than the BSD functions `bcopy' and `bzero'.
1012:
1013:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.