![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-13 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-13 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.2 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.44 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: 6: Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc. 7: 8: Permission is granted to make and distribute verbatim copies of 9: this manual provided the copyright notice and this permission notice 10: are preserved on all copies. 11: 12: Permission is granted to copy and distribute modified versions of 13: this manual under the conditions for verbatim copying, provided also 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. 18: 19: Permission is granted to copy and distribute translations of this 20: manual into another language, under the above conditions for modified 21: versions, except that the section entitled "GNU General Public 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: 1.1.1.2 ! root 27: File: gcc.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros ! 28: ! 29: Register Classes ! 30: ================ ! 31: ! 32: On many machines, the numbered registers are not all equivalent. ! 33: For example, certain registers may not be allowed for indexed ! 34: addressing; certain registers may not be allowed in some instructions. ! 35: These machine restrictions are described to the compiler using ! 36: "register classes". ! 37: ! 38: You define a number of register classes, giving each one a name and ! 39: saying which of the registers belong to it. Then you can specify ! 40: register classes that are allowed as operands to particular ! 41: instruction patterns. ! 42: ! 43: In general, each register will belong to several classes. In fact, ! 44: one class must be named `ALL_REGS' and contain all the registers. ! 45: Another class must be named `NO_REGS' and contain no registers. Often ! 46: the union of two classes will be another class; however, this is not ! 47: required. ! 48: ! 49: One of the classes must be named `GENERAL_REGS'. There is nothing ! 50: terribly special about the name, but the operand constraint letters ! 51: `r' and `g' specify this class. If `GENERAL_REGS' is the same as ! 52: `ALL_REGS', just define it as a macro which expands to `ALL_REGS'. ! 53: ! 54: Order the classes so that if class X is contained in class Y then X ! 55: has a lower class number than Y. ! 56: ! 57: The way classes other than `GENERAL_REGS' are specified in operand ! 58: constraints is through machine-dependent operand constraint letters. ! 59: You can define such letters to correspond to various classes, then use ! 60: them in operand constraints. ! 61: ! 62: You should define a class for the union of two classes whenever some ! 63: instruction allows both classes. For example, if an instruction allows ! 64: either a floating point (coprocessor) register or a general register ! 65: for a certain operand, you should define a class ! 66: `FLOAT_OR_GENERAL_REGS' which includes both of them. Otherwise you ! 67: will get suboptimal code. ! 68: ! 69: You must also specify certain redundant information about the ! 70: register classes: for each class, which classes contain it and which ! 71: ones are contained in it; for each pair of classes, the largest class ! 72: contained in their union. ! 73: ! 74: When a value occupying several consecutive registers is expected in ! 75: a certain class, all the registers used must belong to that class. ! 76: Therefore, register classes cannot be used to enforce a requirement for ! 77: a register pair to start with an even-numbered register. The way to ! 78: specify this requirement is with `HARD_REGNO_MODE_OK'. ! 79: ! 80: Register classes used for input-operands of bitwise-and or shift ! 81: instructions have a special requirement: each such class must have, for ! 82: each fixed-point machine mode, a subclass whose registers can transfer ! 83: that mode to or from memory. For example, on some machines, the ! 84: operations for single-byte values (`QImode') are limited to certain ! 85: registers. When this is so, each register class that is used in a ! 86: bitwise-and or shift instruction must have a subclass consisting of ! 87: registers from which single-byte values can be loaded or stored. This ! 88: is so that `PREFERRED_RELOAD_CLASS' can always have a possible value ! 89: to return. ! 90: ! 91: `enum reg_class' ! 92: An enumeral type that must be defined with all the register class ! 93: names as enumeral values. `NO_REGS' must be first. `ALL_REGS' ! 94: must be the last register class, followed by one more enumeral ! 95: value, `LIM_REG_CLASSES', which is not a register class but rather ! 96: tells how many classes there are. ! 97: ! 98: Each register class has a number, which is the value of casting ! 99: the class name to type `int'. The number serves as an index in ! 100: many of the tables described below. ! 101: ! 102: `N_REG_CLASSES' ! 103: The number of distinct register classes, defined as follows: ! 104: ! 105: #define N_REG_CLASSES (int) LIM_REG_CLASSES ! 106: ! 107: `REG_CLASS_NAMES' ! 108: An initializer containing the names of the register classes as C ! 109: string constants. These names are used in writing some of the ! 110: debugging dumps. ! 111: ! 112: `REG_CLASS_CONTENTS' ! 113: An initializer containing the contents of the register classes, ! 114: as integers which are bit masks. The Nth integer specifies the ! 115: contents of class N. The way the integer MASK is interpreted is ! 116: that register R is in the class if `MASK & (1 << R)' is 1. ! 117: ! 118: When the machine has more than 32 registers, an integer does not ! 119: suffice. Then the integers are replaced by sub-initializers, ! 120: braced groupings containing several integers. Each ! 121: sub-initializer must be suitable as an initializer for the type ! 122: `HARD_REG_SET' which is defined in `hard-reg-set.h'. ! 123: ! 124: `REGNO_REG_CLASS (REGNO)' ! 125: A C expression whose value is a register class containing hard ! 126: register REGNO. In general there is more that one such class; ! 127: choose a class which is "minimal", meaning that no smaller class ! 128: also contains the register. ! 129: ! 130: `BASE_REG_CLASS' ! 131: A macro whose definition is the name of the class to which a valid ! 132: base register must belong. A base register is one used in an ! 133: address which is the register value plus a displacement. ! 134: ! 135: `INDEX_REG_CLASS' ! 136: A macro whose definition is the name of the class to which a valid ! 137: index register must belong. An index register is one used in an ! 138: address where its value is either multiplied by a scale factor or ! 139: added to another register (as well as added to a displacement). ! 140: ! 141: `REG_CLASS_FROM_LETTER (CHAR)' ! 142: A C expression which defines the machine-dependent operand ! 143: constraint letters for register classes. If CHAR is such a ! 144: letter, the value should be the register class corresponding to ! 145: it. Otherwise, the value should be `NO_REGS'. The register ! 146: letter `r', corresponding to class `GENERAL_REGS', will not be ! 147: passed to this macro; you do not need to handle it. ! 148: ! 149: `REGNO_OK_FOR_BASE_P (NUM)' ! 150: A C expression which is nonzero if register number NUM is ! 151: suitable for use as a base register in operand addresses. It may ! 152: be either a suitable hard register or a pseudo register that has ! 153: been allocated such a hard register. ! 154: ! 155: `REGNO_OK_FOR_INDEX_P (NUM)' ! 156: A C expression which is nonzero if register number NUM is ! 157: suitable for use as an index register in operand addresses. It ! 158: may be either a suitable hard register or a pseudo register that ! 159: has been allocated such a hard register. ! 160: ! 161: The difference between an index register and a base register is ! 162: that the index register may be scaled. If an address involves ! 163: the sum of two registers, neither one of them scaled, then either ! 164: one may be labeled the "base" and the other the "index"; but ! 165: whichever labeling is used must fit the machine's constraints of ! 166: which registers may serve in each capacity. The compiler will ! 167: try both labelings, looking for one that is valid, and will ! 168: reload one or both registers only if neither labeling works. ! 169: ! 170: `PREFERRED_RELOAD_CLASS (X, CLASS)' ! 171: A C expression that places additional restrictions on the ! 172: register class to use when it is necessary to copy value X into a ! 173: register in class CLASS. The value is a register class; perhaps ! 174: CLASS, or perhaps another, smaller class. On many machines, the ! 175: definition ! 176: ! 177: #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS ! 178: ! 179: is safe. ! 180: ! 181: Sometimes returning a more restrictive class makes better code. ! 182: For example, on the 68000, when X is an integer constant that is ! 183: in range for a `moveq' instruction, the value of this macro is ! 184: always `DATA_REGS' as long as CLASS includes the data registers. ! 185: Requiring a data register guarantees that a `moveq' will be used. ! 186: ! 187: If X is a `const_double', by returning `NO_REGS' you can force X ! 188: into a memory constant. This is useful on certain machines where ! 189: immediate floating values cannot be loaded into certain kinds of ! 190: registers. ! 191: ! 192: `LIMIT_RELOAD_CLASS (MODE, CLASS)' ! 193: A C expression that places additional restrictions on the ! 194: register class to use when it is necessary to be able to hold a ! 195: value of mode MODE in a reload register for which class CLASS ! 196: would ordinarily be used. ! 197: ! 198: Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when ! 199: there are certain modes that simply can't go in certain reload ! 200: classes. ! 201: ! 202: The value is a register class; perhaps CLASS, or perhaps another, ! 203: smaller class. ! 204: ! 205: Don't define this macro unless the target machine has limitations ! 206: which require the macro to do something nontrivial. ! 207: ! 208: `SECONDARY_RELOAD_CLASS (CLASS, MODE, X)' ! 209: `SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)' ! 210: `SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)' ! 211: Many machines have some registers that cannot be copied directly ! 212: to or from memory or even from other types of registers. An ! 213: example is the `MQ' register, which on most machines, can only be ! 214: copied to or from general registers, but not memory. Some ! 215: machines allow copying all registers to and from memory, but ! 216: require a scratch register for stores to some memory locations ! 217: (e.g., those with symbolic address on the RT, and those with ! 218: certain symbolic address on the Sparc when compiling PIC). In ! 219: some cases, both an intermediate and a scratch register are ! 220: required. ! 221: ! 222: You should define these macros to indicate to the reload phase ! 223: that it may need to allocate at least one register for a reload ! 224: in addition to the register to contain the data. Specifically, ! 225: if copying X to a register CLASS in MODE requires an intermediate ! 226: register, you should define `SECONDARY_INPUT_RELOAD_CLASS' to ! 227: return the largest register class all of whose registers can be ! 228: used as intermediate registers or scratch registers. ! 229: ! 230: If copying a register CLASS in MODE to X requires an intermediate ! 231: or scratch register, you should define ! 232: `SECONDARY_OUTPUT_RELOAD_CLASS' to return the largest register ! 233: class required. If the requirements for input and output reloads ! 234: are the same, the macro `SECONDARY_RELOAD_CLASS' should be used ! 235: instead of defining both macros identically. ! 236: ! 237: The values returned by these macros are often `GENERAL_REGS'. ! 238: Return `NO_REGS' if no spare register is needed; i.e., if X can ! 239: be directly copied to or from a register of CLASS in MODE without ! 240: requiring a scratch register. Do not define this macro if it ! 241: would always return `NO_REGS'. ! 242: ! 243: If a scratch register is required (either with or without an ! 244: intermediate register), you should define patterns for ! 245: `reload_inM' or `reload_outM', as required (*note Standard ! 246: Names::.. These patterns, which will normally be implemented ! 247: with a `define_expand', should be similar to the `movM' patterns, ! 248: except that operand 2 is the scratch register. ! 249: ! 250: Define constraints for the reload register and scratch register ! 251: that contain a single register class. If the original reload ! 252: register (whose class is CLASS) can meet the constraint given in ! 253: the pattern, the value returned by these macros is used for the ! 254: class of the scratch register. Otherwise, two additional reload ! 255: registers are required. Their classes are obtained from the ! 256: constraints in the insn pattern. ! 257: ! 258: X might be a pseudo-register or a `subreg' of a pseudo-register, ! 259: which could either be in a hard register or in memory. Use ! 260: `true_regnum' to find out; it will return -1 if the pseudo is in ! 261: memory and the hard register number if it is in a register. ! 262: ! 263: These macros should not be used in the case where a particular ! 264: class of registers can only be copied to memory and not to ! 265: another class of registers. In that case, secondary reload ! 266: registers are not needed and would not be helpful. Instead, a ! 267: stack location must be used to perform the copy and the `movM' ! 268: pattern should use memory as a intermediate storage. This case ! 269: often occurs between floating-point and general registers. ! 270: ! 271: `SMALL_REGISTER_CLASSES' ! 272: Normally the compiler will avoid choosing spill registers from ! 273: registers that have been explicitly mentioned in the rtl (these ! 274: registers are normally those used to pass parameters and return ! 275: values). However, some machines have so few registers of certain ! 276: classes that there would not be enough registers to use as spill ! 277: registers if this were done. ! 278: ! 279: On those machines, you should define `SMALL_REGISTER_CLASSES'. ! 280: When it is defined, the compiler allows registers explicitly used ! 281: in the rtl to be used as spill registers but prevents the ! 282: compiler from extending the lifetime of these registers. ! 283: ! 284: Defining this macro is always safe, but unnecessarily defining ! 285: this macro will reduce the amount of optimizations that can be ! 286: performed in some cases. If this macro is not defined but needs ! 287: to be, the compiler will run out of reload registers and print a ! 288: fatal error message. ! 289: ! 290: For most machines, this macro should not be defined. ! 291: ! 292: `CLASS_MAX_NREGS (CLASS, MODE)' ! 293: A C expression for the maximum number of consecutive registers of ! 294: class CLASS needed to hold a value of mode MODE. ! 295: ! 296: This is closely related to the macro `HARD_REGNO_NREGS'. In ! 297: fact, the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' ! 298: should be the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' ! 299: for all REGNO values in the class CLASS. ! 300: ! 301: This macro helps control the handling of multiple-word values in ! 302: the reload pass. ! 303: ! 304: Three other special macros describe which operands fit which ! 305: constraint letters. ! 306: ! 307: `CONST_OK_FOR_LETTER_P (VALUE, C)' ! 308: A C expression that defines the machine-dependent operand ! 309: constraint letters that specify particular ranges of integer ! 310: values. If C is one of those letters, the expression should ! 311: check that VALUE, an integer, is in the appropriate range and ! 312: return 1 if so, 0 otherwise. If C is not one of those letters, ! 313: the value should be 0 regardless of VALUE. ! 314: ! 315: `CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)' ! 316: A C expression that defines the machine-dependent operand ! 317: constraint letters that specify particular ranges of ! 318: `const_double' values. ! 319: ! 320: If C is one of those letters, the expression should check that ! 321: VALUE, an RTX of code `const_double', is in the appropriate range ! 322: and return 1 if so, 0 otherwise. If C is not one of those ! 323: letters, the value should be 0 regardless of VALUE. ! 324: ! 325: `const_double' is used for all floating-point constants and for ! 326: `DImode' fixed-point constants. A given letter can accept either ! 327: or both kinds of values. It can use `GET_MODE' to distinguish ! 328: between these kinds. ! 329: ! 330: `EXTRA_CONSTRAINT (VALUE, C)' ! 331: A C expression that defines the optional machine-dependent ! 332: constraint letters that can be used to segregate specific types ! 333: of operands, usually memory references, for the target machine. ! 334: Normally this macro will not be defined. If it is required for a ! 335: particular target machine, it should return 1 if VALUE ! 336: corresponds to the operand type represented by the constraint ! 337: letter C. If C is not defined as an extra constraint, the value ! 338: returned should be 0 regardless of VALUE. ! 339: ! 340: For example, on the ROMP, load instructions cannot have their ! 341: output in r0 if the memory reference contains a symbolic address. ! 342: Constraint letter `Q' is defined as representing a memory ! 343: address that does *not* contain a symbolic address. An ! 344: alternative is specified with a `Q' constraint on the input and ! 345: `r' on the output. The next alternative specifies `m' on the ! 346: input and a register class that does not include r0 on the output. ! 347: ! 348: ! 349: File: gcc.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros ! 350: ! 351: Describing Stack Layout and Calling Conventions ! 352: =============================================== ! 353: ! 354: * Menu: ! 355: ! 356: * Frame Layout:: ! 357: * Frame Registers:: ! 358: * Elimination:: ! 359: * Stack Arguments:: ! 360: * Register Arguments:: ! 361: * Scalar Return:: ! 362: * Aggregate Return:: ! 363: * Caller Saves:: ! 364: * Function Entry:: ! 365: * Profiling:: ! 366: ! 367: ! 368: File: gcc.info, Node: Frame Layout, Next: Frame Registers, Up: Stack and Calling ! 369: ! 370: Basic Stack Layout ! 371: ------------------ ! 372: ! 373: `STACK_GROWS_DOWNWARD' ! 374: Define this macro if pushing a word onto the stack moves the stack ! 375: pointer to a smaller address. ! 376: ! 377: When we say, "define this macro if ...," it means that the ! 378: compiler checks this macro only with `#ifdef' so the precise ! 379: definition used does not matter. ! 380: ! 381: `FRAME_GROWS_DOWNWARD' ! 382: Define this macro if the addresses of local variable slots are at ! 383: negative offsets from the frame pointer. ! 384: ! 385: `ARGS_GROW_DOWNWARD' ! 386: Define this macro if successive arguments to a function occupy ! 387: decreasing addresses on the stack. ! 388: ! 389: `STARTING_FRAME_OFFSET' ! 390: Offset from the frame pointer to the first local variable slot to ! 391: be allocated. ! 392: ! 393: If `FRAME_GROWS_DOWNWARD', the next slot's offset is found by ! 394: subtracting the length of the first slot from ! 395: `STARTING_FRAME_OFFSET'. Otherwise, it is found by adding the ! 396: length of the first slot to the value `STARTING_FRAME_OFFSET'. ! 397: ! 398: `STACK_POINTER_OFFSET' ! 399: Offset from the stack pointer register to the first location at ! 400: which outgoing arguments are placed. If not specified, the ! 401: default value of zero is used. This is the proper value for most ! 402: machines. ! 403: ! 404: If `ARGS_GROW_DOWNWARD', this is the offset to the location above ! 405: the first location at which outgoing arguments are placed. ! 406: ! 407: `FIRST_PARM_OFFSET (FUNDECL)' ! 408: Offset from the argument pointer register to the first argument's ! 409: address. On some machines it may depend on the data type of the ! 410: function. ! 411: ! 412: If `ARGS_GROW_DOWNWARD', this is the offset to the location above ! 413: the first argument's address. ! 414: ! 415: `STACK_DYNAMIC_OFFSET (FUNDECL)' ! 416: Offset from the stack pointer register to an item dynamically ! 417: allocated on the stack, e.g., by `alloca'. ! 418: ! 419: The default value for this macro is `STACK_POINTER_OFFSET' plus ! 420: the length of the outgoing arguments. The default is correct for ! 421: most machines. See `function.c' for details. ! 422: ! 423: `DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)' ! 424: A C expression whose value is RTL representing the address in a ! 425: stack frame where the pointer to the caller's frame is stored. ! 426: Assume that FRAMEADDR is an RTL expression for the address of the ! 427: stack frame itself. ! 428: ! 429: If you don't define this macro, the default is to return the value ! 430: of FRAMEADDR--that is, the stack frame address is also the ! 431: address of the stack word that points to the previous frame. ! 432: ! 433: 1.1 root 434: File: gcc.info, Node: Frame Registers, Next: Elimination, Prev: Frame Layout, Up: Stack and Calling 435: 436: Registers That Address the Stack Frame 437: -------------------------------------- 438: 439: `STACK_POINTER_REGNUM' 440: The register number of the stack pointer register, which must 441: also be a fixed register according to `FIXED_REGISTERS'. On most 442: machines, the hardware determines which register this is. 443: 444: `FRAME_POINTER_REGNUM' 445: The register number of the frame pointer register, which is used 446: to access automatic variables in the stack frame. On some 447: machines, the hardware determines which register this is. On 448: other machines, you can choose any register you wish for this 449: purpose. 450: 451: `ARG_POINTER_REGNUM' 452: The register number of the arg pointer register, which is used to 453: access the function's argument list. On some machines, this is 454: the same as the frame pointer register. On some machines, the 455: hardware determines which register this is. On other machines, 456: you can choose any register you wish for this purpose. If this 457: is not the same register as the frame pointer register, then you 458: must mark it as a fixed register according to `FIXED_REGISTERS', 459: or arrange to be able to eliminate it (*note Elimination::.). 460: 461: `STATIC_CHAIN_REGNUM' 462: `STATIC_CHAIN_INCOMING_REGNUM' 463: Register numbers used for passing a function's static chain 464: pointer. If register windows are used, 465: `STATIC_CHAIN_INCOMING_REGNUM' is the register number as seen by 466: the called function, while `STATIC_CHAIN_REGNUM' is the register 467: number as seen by the calling function. If these registers are 468: the same, `STATIC_CHAIN_INCOMING_REGNUM' need not be defined. 469: 470: The static chain register need not be a fixed register. 471: 472: If the static chain is passed in memory, these macros should not 473: be defined; instead, the next two macros should be defined. 474: 475: `STATIC_CHAIN' 476: `STATIC_CHAIN_INCOMING' 477: If the static chain is passed in memory, these macros provide rtx 478: giving `mem' expressions that denote where they are stored. 479: `STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as 480: seen by the calling and called functions, respectively. Often 481: the former will be at an offset from the stack pointer and the 482: latter at an offset from the frame pointer. 483: 484: The variables `stack_pointer_rtx', `frame_pointer_rtx', and 485: `arg_pointer_rtx' will have been initialized prior to the use of 486: these macros and should be used to refer to those items. 487: 488: If the static chain is passed in a register, the two previous 489: macros should be defined instead. 490: 491: 492: File: gcc.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling 493: 494: Eliminating Frame Pointer and Arg Pointer 495: ----------------------------------------- 496: 497: `FRAME_POINTER_REQUIRED' 498: A C expression which is nonzero if a function must have and use a 499: frame pointer. This expression is evaluated in the reload pass. 500: If its value is nonzero the function will have a frame pointer. 501: 502: The expression can in principle examine the current function and 503: decide according to the facts, but on most machines the constant 504: 0 or the constant 1 suffices. Use 0 when the machine allows code 505: to be generated with no frame pointer, and doing so saves some 506: time or space. Use 1 when there is no possible advantage to 507: avoiding a frame pointer. 508: 509: In certain cases, the compiler does not know how to produce valid 510: code without a frame pointer. The compiler recognizes those 511: cases and automatically gives the function a frame pointer 512: regardless of what `FRAME_POINTER_REQUIRED' says. You don't need 513: to worry about them. 514: 515: In a function that does not require a frame pointer, the frame 516: pointer register can be allocated for ordinary usage, unless you 517: mark it as a fixed register. See `FIXED_REGISTERS' for more 518: information. 519: 520: This macro is ignored and need not be defined if `ELIMINABLE_REGS' 521: is defined. 522: 523: `INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)' 524: A C statement to store in the variable DEPTH-VAR the difference 525: between the frame pointer and the stack pointer values 526: immediately after the function prologue. The value would be 527: computed from information such as the result of `get_frame_size 528: ()' and the tables of registers `regs_ever_live' and 529: `call_used_regs'. 530: 531: If `ELIMINABLE_REGS' is defined, this macro will be not be used 532: and need not be defined. Otherwise, it must be defined even if 533: `FRAME_POINTER_REQUIRED' is defined to always be true; in that 534: case, you may set DEPTH-VAR to anything. 535: 536: `ELIMINABLE_REGS' 537: If defined, this macro specifies a table of register pairs used to 538: eliminate unneeded registers that point into the stack frame. If 539: it is not defined, the only elimination attempted by the compiler 540: is to replace references to the frame pointer with references to 541: the stack pointer. 542: 543: The definition of this macro is a list of structure 544: initializations, each of which specifies an original and 545: replacement register. 546: 547: On some machines, the position of the argument pointer is not 548: known until the compilation is completed. In such a case, a 549: separate hard register must be used for the argument pointer. 550: This register can be eliminated by replacing it with either the 551: frame pointer or the argument pointer, depending on whether or 552: not the frame pointer has been eliminated. 553: 554: In this case, you might specify: 555: #define ELIMINABLE_REGS \ 556: {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ 557: {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ 558: {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} 559: 560: Note that the elimination of the argument pointer with the stack 561: pointer is specified first since that is the preferred 562: elimination. 563: 564: `CAN_ELIMINATE (FROM-REG, TO-REG)' 565: A C expression that returns non-zero if the compiler is allowed 566: to try to replace register number FROM-REG with register number 567: TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is 568: defined, and will usually be the constant 1, since most of the 569: cases preventing register elimination are things that the 570: compiler already knows about. 571: 572: `INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)' 573: This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It 574: specifies the initial difference between the specified pair of 575: registers. This macro must be defined if `ELIMINABLE_REGS' is 576: defined. 577: 578: `LONGJMP_RESTORE_FROM_STACK' 579: Define this macro if the `longjmp' function restores registers 580: from the stack frames, rather than from those saved specifically 581: by `setjmp'. Certain quantities must not be kept in registers 582: across a call to `setjmp' on such machines. 583: 584: 585: File: gcc.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling 586: 587: Passing Function Arguments on the Stack 588: --------------------------------------- 589: 590: The macros in this section control how arguments are passed on the 591: stack. See the following section for other macros that control 592: passing certain arguments in registers. 593: 594: `PROMOTE_PROTOTYPES' 595: Define this macro if an argument declared as `char' or `short' in 596: a prototype should actually be passed as an `int'. In addition 597: to avoiding errors in certain cases of mismatch, it also makes 598: for better code on certain machines. 599: 600: `PUSH_ROUNDING (NPUSHED)' 601: A C expression that is the number of bytes actually pushed onto 602: the stack when an instruction attempts to push NPUSHED bytes. 603: 604: If the target machine does not have a push instruction, do not 605: define this macro. That directs GNU CC to use an alternate 606: strategy: to allocate the entire argument block and then store 607: the arguments into it. 608: 609: On some machines, the definition 610: 611: #define PUSH_ROUNDING(BYTES) (BYTES) 612: 613: will suffice. But on other machines, instructions that appear to 614: push one byte actually push two bytes in an attempt to maintain 615: alignment. Then the definition should be 616: 617: #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) 618: 619: `ACCUMULATE_OUTGOING_ARGS' 620: If defined, the maximum amount of space required for outgoing 621: arguments will be computed and placed into the variable 622: `current_function_outgoing_args_size'. No space will be pushed 623: onto the stack for each call; instead, the function prologue 624: should increase the stack frame size by this amount. 625: 626: It is not proper to define both `PUSH_ROUNDING' and 627: `ACCUMULATE_OUTGOING_ARGS'. 628: 629: `REG_PARM_STACK_SPACE' 630: Define this macro if functions should assume that stack space has 631: been allocated for arguments even when their values are passed in 632: registers. 633: 634: The value of this macro is the size, in bytes, of the area 635: reserved for arguments passed in registers. 636: 637: This space can either be allocated by the caller or be a part of 638: the machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' 639: says which. 640: 641: `OUTGOING_REG_PARM_STACK_SPACE' 642: Define this if it is the responsibility of the caller to allocate 643: the area reserved for arguments passed in registers. 644: 645: If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls 646: whether the space for these arguments counts in the value of 647: `current_function_outgoing_args_size'. 648: 649: `STACK_PARMS_IN_REG_PARM_AREA' 650: Define this macro if `REG_PARM_STACK_SPACE' is defined but stack 651: parameters don't skip the area specified by 652: `REG_PARM_STACK_SPACE'. 653: 654: Normally, when a parameter is not passed in registers, it is 655: placed on the stack beyond the `REG_PARM_STACK_SPACE' area. 656: Defining this macro suppresses this behavior and causes the 657: parameter to be passed on the stack in its natural location. 658: 659: `RETURN_POPS_ARGS (FUNTYPE, STACK-SIZE)' 660: A C expression that should indicate the number of bytes of its own 661: arguments that a function pops on returning, or 0 if the function 662: pops no arguments and the caller must therefore pop them all 663: after the function returns. 664: 665: FUNTYPE is a C variable whose value is a tree node that describes 666: the function in question. Normally it is a node of type 667: `FUNCTION_TYPE' that describes the data type of the function. 668: From this it is possible to obtain the data types of the value and 669: arguments (if known). 670: 671: When a call to a library function is being considered, FUNTYPE 672: will contain an identifier node for the library function. Thus, 673: if you need to distinguish among various library functions, you 674: can do so by their names. Note that "library function" in this 675: context means a function used to perform arithmetic, whose name 676: is known specially in the compiler and was not mentioned in the C 677: code being compiled. 678: 679: STACK-SIZE is the number of bytes of arguments passed on the 680: stack. If a variable number of bytes is passed, it is zero, and 681: argument popping will always be the responsibility of the calling 682: function. 683: 684: On the Vax, all functions always pop their arguments, so the 685: definition of this macro is STACK-SIZE. On the 68000, using the 686: standard calling convention, no functions pop their arguments, so 687: the value of the macro is always 0 in this case. But an 688: alternative calling convention is available in which functions 689: that take a fixed number of arguments pop them but other 690: functions (such as `printf') pop nothing (the caller pops all). 691: When this convention is in use, FUNTYPE is examined to determine 692: whether a function takes a fixed number of arguments. 693: 694: 695: File: gcc.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling 696: 697: Passing Arguments in Registers 698: ------------------------------ 699: 700: This section describes the macros which let you control how various 701: types of arguments are passed in registers or how they are arranged in 702: the stack. 703: 704: `FUNCTION_ARG (CUM, MODE, TYPE, NAMED)' 705: A C expression that controls whether a function argument is passed 706: in a register, and which register. 707: 708: The arguments are CUM, which summarizes all the previous 709: arguments; MODE, the machine mode of the argument; TYPE, the data 710: type of the argument as a tree node or 0 if that is not known 711: (which happens for C support library functions); and NAMED, which 712: is 1 for an ordinary argument and 0 for nameless arguments that 713: correspond to `...' in the called function's prototype. 714: 715: The value of the expression should either be a `reg' RTX for the 716: hard register in which to pass the argument, or zero to pass the 717: argument on the stack. 718: 719: For machines like the Vax and 68000, where normally all arguments 720: are pushed, zero suffices as a definition. 721: 722: The usual way to make the ANSI library `stdarg.h' work on a 723: machine where some arguments are usually passed in registers, is 724: to cause nameless arguments to be passed on the stack instead. 725: This is done by making `FUNCTION_ARG' return 0 whenever NAMED is 726: 0. 727: 728: You may use the macro `MUST_PASS_IN_STACK (MODE, TYPE)' in the 729: definition of this macro to determine if this argument is of a 730: type that must be passed in the stack. If `REG_PARM_STACK_SPACE' 731: is not defined and `FUNCTION_ARG' returns non-zero for such an 732: argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is 733: defined, the argument will be computed in the stack and then 734: loaded into a register. 735: 736: `FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)' 737: Define this macro if the target machine has "register windows", so 738: that the register in which a function sees an arguments is not 739: necessarily the same as the one in which the caller passed the 740: 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 called 745: 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: `FUNCTION_ARG_PASS_BY_REFERENCE (CUM, MODE, TYPE, NAMED)' 770: A C expression that indicates when an argument must be passed by 771: reference. If nonzero for an argument, a copy of that argument 772: is made in memory and a pointer to the argument is passed instead 773: of the argument itself. The pointer is passed in whatever way is 774: appropriate for passing a pointer to that type. 775: 776: On machines where `REG_PARM_STACK_SPACE' is not defined, a 777: suitable definition of this macro might be 778: #define FUNCTION_ARG_PASS_BY_REFERENCE(CUM, MODE, TYPE, NAMED) \ 779: MUST_PASS_IN_STACK (MODE, TYPE) 780: 781: `CUMULATIVE_ARGS' 782: A C type for declaring a variable that is used as the first 783: argument of `FUNCTION_ARG' and other related values. For some 784: target machines, the type `int' suffices and can hold the number 785: of bytes of argument so far. 786: 787: There is no need to record in `CUMULATIVE_ARGS' anything about the 788: arguments that have been passed on the stack. The compiler has 789: other variables to keep track of that. For target machines on 790: which all arguments are passed on the stack, there is no need to 791: store anything in `CUMULATIVE_ARGS'; however, the data structure 792: must exist and should not be empty, so use `int'. 793: 794: `INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME)' 795: A C statement (sans semicolon) for initializing the variable CUM 796: for the state at the beginning of the argument list. The 797: variable has type `CUMULATIVE_ARGS'. The value of FNTYPE is the 798: tree node for the data type of the function which will receive 799: the args, or 0 if the args are to a compiler support library 800: function. 801: 802: When processing a call to a compiler support library function, 803: LIBNAME identifies which one. It is a `symbol_ref' rtx which 804: contains the name of the function, as a string. LIBNAME is 0 when 805: an ordinary C function call is being processed. Thus, each time 806: this macro is called, either LIBNAME or FNTYPE is nonzero, but 807: never both of them at once. 808: 809: `INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)' 810: Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of 811: finding the arguments for the function being compiled. If this 812: macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead. 813: 814: The argument LIBNAME exists for symmetry with 815: `INIT_CUMULATIVE_ARGS'. The value passed for LIBNAME is always 816: 0, since library routines with special calling conventions are 817: never compiled with GNU CC. 818: 819: `FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)' 820: A C statement (sans semicolon) to update the summarizer variable 821: CUM to advance past an argument in the argument list. The values 822: MODE, TYPE and NAMED describe that argument. Once this is done, 823: the variable CUM is suitable for analyzing the *following* 824: argument with `FUNCTION_ARG', etc. 825: 826: This macro need not do anything if the argument in question was 827: passed on the stack. The compiler knows how to track the amount 828: of stack space used for arguments without any special help. 829: 830: `FUNCTION_ARG_PADDING (MODE, TYPE)' 831: If defined, a C expression which determines whether, and in which 832: direction, to pad out an argument with extra space. The value 833: should be of type `enum direction': either `upward' to pad above 834: the argument, `downward' to pad below, or `none' to inhibit 835: padding. 836: 837: This macro does not control the *amount* of padding; that is 838: always just enough to reach the next multiple of 839: `FUNCTION_ARG_BOUNDARY'. 840: 841: This macro has a default definition which is right for most 842: systems. For little-endian machines, the default is to pad 843: upward. For big-endian machines, the default is to pad downward 844: for an argument of constant size shorter than an `int', and 845: upward otherwise. 846: 847: `FUNCTION_ARG_BOUNDARY (MODE, TYPE)' 848: If defined, a C expression that gives the alignment boundary, in 849: bits, of an argument with the specified mode and type. If it is 850: not defined, `PARM_BOUNDARY' is used for all arguments. 851: 852: `FUNCTION_ARG_REGNO_P (REGNO)' 853: A C expression that is nonzero if REGNO is the number of a hard 854: register in which function arguments are sometimes passed. This 855: does *not* include implicit arguments such as the static chain and 856: the structure-value address. On many machines, no registers can 857: be used for this purpose since all function arguments are pushed 858: on the stack. 859: 860: 861: File: gcc.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 862: 863: How Scalar Function Values Are Returned 864: --------------------------------------- 865: 866: This section discusses the macros that control returning scalars as 867: values--values that can fit in registers. 868: 869: `TRADITIONAL_RETURN_FLOAT' 870: Define this macro if `-traditional' should not cause functions 871: declared to return `float' to convert the value to `double'. 872: 873: `FUNCTION_VALUE (VALTYPE, FUNC)' 874: A C expression to create an RTX representing the place where a 875: function returns a value of data type VALTYPE. VALTYPE is a tree 876: node representing a data type. Write `TYPE_MODE (VALTYPE)' to 877: get the machine mode used to represent that type. On many 878: machines, only the mode is relevant. (Actually, on most 879: machines, scalar values are returned in the same place regardless 880: of mode). 881: 882: If the precise function being called is known, FUNC is a tree 883: node (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. 884: This makes it possible to use a different value-returning 885: convention for specific functions when all their calls are known. 886: 887: `FUNCTION_VALUE' is not used for return vales with aggregate data 888: types, because these are returned in another way. See 889: `STRUCT_VALUE_REGNUM' and related macros, below. 890: 891: `FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)' 892: Define this macro if the target machine has "register windows" so 893: that the register in which a function returns its value is not 894: the same as the one in which the caller sees the value. 895: 896: For such machines, `FUNCTION_VALUE' computes the register in 897: which the caller will see the value, and 898: `FUNCTION_OUTGOING_VALUE' should be defined in a similar fashion 899: to tell the function where to put the value. 900: 901: If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE' 902: serves both purposes. 903: 904: `FUNCTION_OUTGOING_VALUE' is not used for return vales with 905: aggregate data types, because these are returned in another way. 906: See `STRUCT_VALUE_REGNUM' and related macros, below. 907: 908: `LIBCALL_VALUE (MODE)' 909: A C expression to create an RTX representing the place where a 910: library function returns a value of mode MODE. If the precise 911: function being called is known, FUNC is a tree node 912: (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. 913: This makes it possible to use a different value-returning 914: convention for specific functions when all their calls are known. 915: 916: Note that "library function" in this context means a compiler 917: support routine, used to perform arithmetic, whose name is known 918: specially by the compiler and was not mentioned in the C code 919: being compiled. 920: 921: The definition of `LIBRARY_VALUE' need not be concerned aggregate 922: data types, because none of the library functions returns such 923: types. 924: 925: `FUNCTION_VALUE_REGNO_P (REGNO)' 926: A C expression that is nonzero if REGNO is the number of a hard 927: register in which the values of called function may come back. 928: 929: A register whose use for returning values is limited to serving 930: as the second of a pair (for a value of type `double', say) need 931: not be recognized by this macro. So for most machines, this 932: definition suffices: 933: 934: #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) 935: 936: If the machine has register windows, so that the caller and the 937: called function use different registers for the return value, 938: this macro should recognize only the caller's register numbers. 939: 940: 941: File: gcc.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 942: 1.1.1.2 ! root 943: How Large Values Are Returned ! 944: ----------------------------- 1.1 root 945: 946: When a function value's mode is `BLKmode' (and in some other 947: cases), the value is not returned according to `FUNCTION_VALUE' (*note 948: Scalar Return::.). Instead, the caller passes the address of a block 949: of memory in which the value should be stored. This address is called 950: the "structure value address". 951: 952: This section describes how to control returning structure values in 953: memory. 954: 955: `RETURN_IN_MEMORY (TYPE)' 956: A C expression which can inhibit the returning of certain function 957: values in registers, based on the type of value. A nonzero value 958: says to return the function value in memory, just as large 959: structures are always returned. Here TYPE will be a C expression 960: of type `tree', representing the data type of the value. 961: 962: Note that values of mode `BLKmode' are returned in memory 963: regardless of this macro. Also, the option `-fpcc-struct-return' 964: takes effect regardless of this macro. On most systems, it is 965: possible to leave the macro undefined; this causes a default 966: definition to be used, whose value is the constant 0. 967: 968: `STRUCT_VALUE_REGNUM' 969: If the structure value address is passed in a register, then 970: `STRUCT_VALUE_REGNUM' should be the number of that register. 971: 972: `STRUCT_VALUE' 973: If the structure value address is not passed in a register, define 974: `STRUCT_VALUE' as an expression returning an RTX for the place 975: where the address is passed. If it returns 0, the address is 976: passed as an "invisible" first argument. 977: 978: `STRUCT_VALUE_INCOMING_REGNUM' 979: On some architectures the place where the structure value address 980: is found by the called function is not the same place that the 981: caller put it. This can be due to register windows, or it could 982: be because the function prologue moves it to a different place. 983: 984: If the incoming location of the structure value address is in a 985: register, define this macro as the register number. 986: 987: `STRUCT_VALUE_INCOMING' 988: If the incoming location is not a register, define 989: `STRUCT_VALUE_INCOMING' as an expression for an RTX for where the 990: called function should find the value. If it should find the 991: value on the stack, define this to create a `mem' which refers to 992: the frame pointer. A definition of 0 means that the address is 993: passed as an "invisible" first argument. 994: 995: `PCC_STATIC_STRUCT_RETURN' 996: Define this macro if the usual system convention on the target 997: machine for returning structures and unions is for the called 998: function to return the address of a static variable containing 999: the value. GNU CC does not normally use this convention, even if 1000: it is the usual one, but does use it if `-fpcc-struct-value' is 1001: specified. 1002: 1003: Do not define this if the usual system convention is for the 1004: caller to pass an address to the subroutine. 1005: 1006: 1007: File: gcc.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling 1008: 1009: Caller-Saves Register Allocation 1010: -------------------------------- 1011: 1012: If you enable it, GNU CC can save registers around function calls. 1013: This makes it possible to use call-clobbered registers to hold 1014: variables that must live across calls. 1015: 1016: `DEFAULT_CALLER_SAVES' 1017: Define this macro if function calls on the target machine do not 1018: preserve any registers; in other words, if `CALL_USED_REGISTERS' 1019: has 1 for all registers. This macro enables `-fcaller-saves' by 1020: default. Eventually that option will be enabled by default on 1021: all machines and both the option and this macro will be 1022: eliminated. 1023: 1024: `CALLER_SAVE_PROFITABLE (REFS, CALLS)' 1025: A C expression to determine whether it is worthwhile to consider 1026: placing a pseudo-register in a call-clobbered hard register and 1027: saving and restoring it around each function call. The 1028: expression should be 1 when this is worth doing, and 0 otherwise. 1029: 1030: If you don't define this macro, a default is used which is good 1031: on most machines: `4 * CALLS < REFS'. 1032: 1033:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.