![[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 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.43 from the input ! 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: ! 27: File: gcc.info, Node: Frame Registers, Next: Elimination, Prev: Frame Layout, Up: Stack and Calling ! 28: ! 29: Registers That Address the Stack Frame ! 30: -------------------------------------- ! 31: ! 32: `STACK_POINTER_REGNUM' ! 33: The register number of the stack pointer register, which must ! 34: also be a fixed register according to `FIXED_REGISTERS'. On most ! 35: machines, the hardware determines which register this is. ! 36: ! 37: `FRAME_POINTER_REGNUM' ! 38: The register number of the frame pointer register, which is used ! 39: to access automatic variables in the stack frame. On some ! 40: machines, the hardware determines which register this is. On ! 41: other machines, you can choose any register you wish for this ! 42: purpose. ! 43: ! 44: `ARG_POINTER_REGNUM' ! 45: The register number of the arg pointer register, which is used to ! 46: access the function's argument list. On some machines, this is ! 47: the same as the frame pointer register. On some machines, the ! 48: hardware determines which register this is. On other machines, ! 49: you can choose any register you wish for this purpose. If this ! 50: is not the same register as the frame pointer register, then you ! 51: must mark it as a fixed register according to `FIXED_REGISTERS', ! 52: or arrange to be able to eliminate it (*note Elimination::.). ! 53: ! 54: `STATIC_CHAIN_REGNUM' ! 55: `STATIC_CHAIN_INCOMING_REGNUM' ! 56: Register numbers used for passing a function's static chain ! 57: pointer. If register windows are used, ! 58: `STATIC_CHAIN_INCOMING_REGNUM' is the register number as seen by ! 59: the called function, while `STATIC_CHAIN_REGNUM' is the register ! 60: number as seen by the calling function. If these registers are ! 61: the same, `STATIC_CHAIN_INCOMING_REGNUM' need not be defined. ! 62: ! 63: The static chain register need not be a fixed register. ! 64: ! 65: If the static chain is passed in memory, these macros should not ! 66: be defined; instead, the next two macros should be defined. ! 67: ! 68: `STATIC_CHAIN' ! 69: `STATIC_CHAIN_INCOMING' ! 70: If the static chain is passed in memory, these macros provide rtx ! 71: giving `mem' expressions that denote where they are stored. ! 72: `STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as ! 73: seen by the calling and called functions, respectively. Often ! 74: the former will be at an offset from the stack pointer and the ! 75: latter at an offset from the frame pointer. ! 76: ! 77: The variables `stack_pointer_rtx', `frame_pointer_rtx', and ! 78: `arg_pointer_rtx' will have been initialized prior to the use of ! 79: these macros and should be used to refer to those items. ! 80: ! 81: If the static chain is passed in a register, the two previous ! 82: macros should be defined instead. ! 83: ! 84: ! 85: File: gcc.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling ! 86: ! 87: Eliminating Frame Pointer and Arg Pointer ! 88: ----------------------------------------- ! 89: ! 90: `FRAME_POINTER_REQUIRED' ! 91: A C expression which is nonzero if a function must have and use a ! 92: frame pointer. This expression is evaluated in the reload pass. ! 93: If its value is nonzero the function will have a frame pointer. ! 94: ! 95: The expression can in principle examine the current function and ! 96: decide according to the facts, but on most machines the constant ! 97: 0 or the constant 1 suffices. Use 0 when the machine allows code ! 98: to be generated with no frame pointer, and doing so saves some ! 99: time or space. Use 1 when there is no possible advantage to ! 100: avoiding a frame pointer. ! 101: ! 102: In certain cases, the compiler does not know how to produce valid ! 103: code without a frame pointer. The compiler recognizes those ! 104: cases and automatically gives the function a frame pointer ! 105: regardless of what `FRAME_POINTER_REQUIRED' says. You don't need ! 106: to worry about them. ! 107: ! 108: In a function that does not require a frame pointer, the frame ! 109: pointer register can be allocated for ordinary usage, unless you ! 110: mark it as a fixed register. See `FIXED_REGISTERS' for more ! 111: information. ! 112: ! 113: This macro is ignored and need not be defined if `ELIMINABLE_REGS' ! 114: is defined. ! 115: ! 116: `INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)' ! 117: A C statement to store in the variable DEPTH-VAR the difference ! 118: between the frame pointer and the stack pointer values ! 119: immediately after the function prologue. The value would be ! 120: computed from information such as the result of `get_frame_size ! 121: ()' and the tables of registers `regs_ever_live' and ! 122: `call_used_regs'. ! 123: ! 124: If `ELIMINABLE_REGS' is defined, this macro will be not be used ! 125: and need not be defined. Otherwise, it must be defined even if ! 126: `FRAME_POINTER_REQUIRED' is defined to always be true; in that ! 127: case, you may set DEPTH-VAR to anything. ! 128: ! 129: `ELIMINABLE_REGS' ! 130: If defined, this macro specifies a table of register pairs used to ! 131: eliminate unneeded registers that point into the stack frame. If ! 132: it is not defined, the only elimination attempted by the compiler ! 133: is to replace references to the frame pointer with references to ! 134: the stack pointer. ! 135: ! 136: The definition of this macro is a list of structure ! 137: initializations, each of which specifies an original and ! 138: replacement register. ! 139: ! 140: On some machines, the position of the argument pointer is not ! 141: known until the compilation is completed. In such a case, a ! 142: separate hard register must be used for the argument pointer. ! 143: This register can be eliminated by replacing it with either the ! 144: frame pointer or the argument pointer, depending on whether or ! 145: not the frame pointer has been eliminated. ! 146: ! 147: In this case, you might specify: ! 148: #define ELIMINABLE_REGS \ ! 149: {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ ! 150: {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ ! 151: {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} ! 152: ! 153: Note that the elimination of the argument pointer with the stack ! 154: pointer is specified first since that is the preferred ! 155: elimination. ! 156: ! 157: `CAN_ELIMINATE (FROM-REG, TO-REG)' ! 158: A C expression that returns non-zero if the compiler is allowed ! 159: to try to replace register number FROM-REG with register number ! 160: TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is ! 161: defined, and will usually be the constant 1, since most of the ! 162: cases preventing register elimination are things that the ! 163: compiler already knows about. ! 164: ! 165: `INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)' ! 166: This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It ! 167: specifies the initial difference between the specified pair of ! 168: registers. This macro must be defined if `ELIMINABLE_REGS' is ! 169: defined. ! 170: ! 171: `LONGJMP_RESTORE_FROM_STACK' ! 172: Define this macro if the `longjmp' function restores registers ! 173: from the stack frames, rather than from those saved specifically ! 174: by `setjmp'. Certain quantities must not be kept in registers ! 175: across a call to `setjmp' on such machines. ! 176: ! 177: ! 178: File: gcc.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling ! 179: ! 180: Passing Function Arguments on the Stack ! 181: --------------------------------------- ! 182: ! 183: The macros in this section control how arguments are passed on the ! 184: stack. See the following section for other macros that control ! 185: passing certain arguments in registers. ! 186: ! 187: `PROMOTE_PROTOTYPES' ! 188: Define this macro if an argument declared as `char' or `short' in ! 189: a prototype should actually be passed as an `int'. In addition ! 190: to avoiding errors in certain cases of mismatch, it also makes ! 191: for better code on certain machines. ! 192: ! 193: `PUSH_ROUNDING (NPUSHED)' ! 194: A C expression that is the number of bytes actually pushed onto ! 195: the stack when an instruction attempts to push NPUSHED bytes. ! 196: ! 197: If the target machine does not have a push instruction, do not ! 198: define this macro. That directs GNU CC to use an alternate ! 199: strategy: to allocate the entire argument block and then store ! 200: the arguments into it. ! 201: ! 202: On some machines, the definition ! 203: ! 204: #define PUSH_ROUNDING(BYTES) (BYTES) ! 205: ! 206: will suffice. But on other machines, instructions that appear to ! 207: push one byte actually push two bytes in an attempt to maintain ! 208: alignment. Then the definition should be ! 209: ! 210: #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) ! 211: ! 212: `ACCUMULATE_OUTGOING_ARGS' ! 213: If defined, the maximum amount of space required for outgoing ! 214: arguments will be computed and placed into the variable ! 215: `current_function_outgoing_args_size'. No space will be pushed ! 216: onto the stack for each call; instead, the function prologue ! 217: should increase the stack frame size by this amount. ! 218: ! 219: It is not proper to define both `PUSH_ROUNDING' and ! 220: `ACCUMULATE_OUTGOING_ARGS'. ! 221: ! 222: `REG_PARM_STACK_SPACE' ! 223: Define this macro if functions should assume that stack space has ! 224: been allocated for arguments even when their values are passed in ! 225: registers. ! 226: ! 227: The value of this macro is the size, in bytes, of the area ! 228: reserved for arguments passed in registers. ! 229: ! 230: This space can either be allocated by the caller or be a part of ! 231: the machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' ! 232: says which. ! 233: ! 234: `OUTGOING_REG_PARM_STACK_SPACE' ! 235: Define this if it is the responsibility of the caller to allocate ! 236: the area reserved for arguments passed in registers. ! 237: ! 238: If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls ! 239: whether the space for these arguments counts in the value of ! 240: `current_function_outgoing_args_size'. ! 241: ! 242: `STACK_PARMS_IN_REG_PARM_AREA' ! 243: Define this macro if `REG_PARM_STACK_SPACE' is defined but stack ! 244: parameters don't skip the area specified by ! 245: `REG_PARM_STACK_SPACE'. ! 246: ! 247: Normally, when a parameter is not passed in registers, it is ! 248: placed on the stack beyond the `REG_PARM_STACK_SPACE' area. ! 249: Defining this macro suppresses this behavior and causes the ! 250: parameter to be passed on the stack in its natural location. ! 251: ! 252: `RETURN_POPS_ARGS (FUNTYPE, STACK-SIZE)' ! 253: A C expression that should indicate the number of bytes of its own ! 254: arguments that a function pops on returning, or 0 if the function ! 255: pops no arguments and the caller must therefore pop them all ! 256: after the function returns. ! 257: ! 258: FUNTYPE is a C variable whose value is a tree node that describes ! 259: the function in question. Normally it is a node of type ! 260: `FUNCTION_TYPE' that describes the data type of the function. ! 261: From this it is possible to obtain the data types of the value and ! 262: arguments (if known). ! 263: ! 264: When a call to a library function is being considered, FUNTYPE ! 265: will contain an identifier node for the library function. Thus, ! 266: if you need to distinguish among various library functions, you ! 267: can do so by their names. Note that "library function" in this ! 268: context means a function used to perform arithmetic, whose name ! 269: is known specially in the compiler and was not mentioned in the C ! 270: code being compiled. ! 271: ! 272: STACK-SIZE is the number of bytes of arguments passed on the ! 273: stack. If a variable number of bytes is passed, it is zero, and ! 274: argument popping will always be the responsibility of the calling ! 275: function. ! 276: ! 277: On the Vax, all functions always pop their arguments, so the ! 278: definition of this macro is STACK-SIZE. On the 68000, using the ! 279: standard calling convention, no functions pop their arguments, so ! 280: the value of the macro is always 0 in this case. But an ! 281: alternative calling convention is available in which functions ! 282: that take a fixed number of arguments pop them but other ! 283: functions (such as `printf') pop nothing (the caller pops all). ! 284: When this convention is in use, FUNTYPE is examined to determine ! 285: whether a function takes a fixed number of arguments. ! 286: ! 287: ! 288: File: gcc.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling ! 289: ! 290: Passing Arguments in Registers ! 291: ------------------------------ ! 292: ! 293: This section describes the macros which let you control how various ! 294: types of arguments are passed in registers or how they are arranged in ! 295: the stack. ! 296: ! 297: `FUNCTION_ARG (CUM, MODE, TYPE, NAMED)' ! 298: A C expression that controls whether a function argument is passed ! 299: in a register, and which register. ! 300: ! 301: The arguments are CUM, which summarizes all the previous ! 302: arguments; MODE, the machine mode of the argument; TYPE, the data ! 303: type of the argument as a tree node or 0 if that is not known ! 304: (which happens for C support library functions); and NAMED, which ! 305: is 1 for an ordinary argument and 0 for nameless arguments that ! 306: correspond to `...' in the called function's prototype. ! 307: ! 308: The value of the expression should either be a `reg' RTX for the ! 309: hard register in which to pass the argument, or zero to pass the ! 310: argument on the stack. ! 311: ! 312: For machines like the Vax and 68000, where normally all arguments ! 313: are pushed, zero suffices as a definition. ! 314: ! 315: The usual way to make the ANSI library `stdarg.h' work on a ! 316: machine where some arguments are usually passed in registers, is ! 317: to cause nameless arguments to be passed on the stack instead. ! 318: This is done by making `FUNCTION_ARG' return 0 whenever NAMED is ! 319: 0. ! 320: ! 321: You may use the macro `MUST_PASS_IN_STACK (MODE, TYPE)' in the ! 322: definition of this macro to determine if this argument is of a ! 323: type that must be passed in the stack. If `REG_PARM_STACK_SPACE' ! 324: is not defined and `FUNCTION_ARG' returns non-zero for such an ! 325: argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is ! 326: defined, the argument will be computed in the stack and then ! 327: loaded into a register. ! 328: ! 329: `FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)' ! 330: Define this macro if the target machine has "register windows", so ! 331: that the register in which a function sees an arguments is not ! 332: necessarily the same as the one in which the caller passed the ! 333: argument. ! 334: ! 335: For such machines, `FUNCTION_ARG' computes the register in which ! 336: the caller passes the value, and `FUNCTION_INCOMING_ARG' should ! 337: be defined in a similar fashion to tell the function being called ! 338: where the arguments will arrive. ! 339: ! 340: If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves ! 341: both purposes. ! 342: ! 343: `FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)' ! 344: A C expression for the number of words, at the beginning of an ! 345: argument, must be put in registers. The value must be zero for ! 346: arguments that are passed entirely in registers or that are ! 347: entirely pushed on the stack. ! 348: ! 349: On some machines, certain arguments must be passed partially in ! 350: registers and partially in memory. On these machines, typically ! 351: the first N words of arguments are passed in registers, and the ! 352: rest on the stack. If a multi-word argument (a `double' or a ! 353: structure) crosses that boundary, its first few words must be ! 354: passed in registers and the rest must be pushed. This macro ! 355: tells the compiler when this occurs, and how many of the words ! 356: should go in registers. ! 357: ! 358: `FUNCTION_ARG' for these arguments should return the first ! 359: register to be used by the caller for this argument; likewise ! 360: `FUNCTION_INCOMING_ARG', for the called function. ! 361: ! 362: `FUNCTION_ARG_PASS_BY_REFERENCE (CUM, MODE, TYPE, NAMED)' ! 363: A C expression that indicates when an argument must be passed by ! 364: reference. If nonzero for an argument, a copy of that argument ! 365: is made in memory and a pointer to the argument is passed instead ! 366: of the argument itself. The pointer is passed in whatever way is ! 367: appropriate for passing a pointer to that type. ! 368: ! 369: On machines where `REG_PARM_STACK_SPACE' is not defined, a ! 370: suitable definition of this macro might be ! 371: #define FUNCTION_ARG_PASS_BY_REFERENCE(CUM, MODE, TYPE, NAMED) \ ! 372: MUST_PASS_IN_STACK (MODE, TYPE) ! 373: ! 374: `CUMULATIVE_ARGS' ! 375: A C type for declaring a variable that is used as the first ! 376: argument of `FUNCTION_ARG' and other related values. For some ! 377: target machines, the type `int' suffices and can hold the number ! 378: of bytes of argument so far. ! 379: ! 380: There is no need to record in `CUMULATIVE_ARGS' anything about the ! 381: arguments that have been passed on the stack. The compiler has ! 382: other variables to keep track of that. For target machines on ! 383: which all arguments are passed on the stack, there is no need to ! 384: store anything in `CUMULATIVE_ARGS'; however, the data structure ! 385: must exist and should not be empty, so use `int'. ! 386: ! 387: `INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME)' ! 388: A C statement (sans semicolon) for initializing the variable CUM ! 389: for the state at the beginning of the argument list. The ! 390: variable has type `CUMULATIVE_ARGS'. The value of FNTYPE is the ! 391: tree node for the data type of the function which will receive ! 392: the args, or 0 if the args are to a compiler support library ! 393: function. ! 394: ! 395: When processing a call to a compiler support library function, ! 396: LIBNAME identifies which one. It is a `symbol_ref' rtx which ! 397: contains the name of the function, as a string. LIBNAME is 0 when ! 398: an ordinary C function call is being processed. Thus, each time ! 399: this macro is called, either LIBNAME or FNTYPE is nonzero, but ! 400: never both of them at once. ! 401: ! 402: `INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)' ! 403: Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of ! 404: finding the arguments for the function being compiled. If this ! 405: macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead. ! 406: ! 407: The argument LIBNAME exists for symmetry with ! 408: `INIT_CUMULATIVE_ARGS'. The value passed for LIBNAME is always ! 409: 0, since library routines with special calling conventions are ! 410: never compiled with GNU CC. ! 411: ! 412: `FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)' ! 413: A C statement (sans semicolon) to update the summarizer variable ! 414: CUM to advance past an argument in the argument list. The values ! 415: MODE, TYPE and NAMED describe that argument. Once this is done, ! 416: the variable CUM is suitable for analyzing the *following* ! 417: argument with `FUNCTION_ARG', etc. ! 418: ! 419: This macro need not do anything if the argument in question was ! 420: passed on the stack. The compiler knows how to track the amount ! 421: of stack space used for arguments without any special help. ! 422: ! 423: `FUNCTION_ARG_PADDING (MODE, TYPE)' ! 424: If defined, a C expression which determines whether, and in which ! 425: direction, to pad out an argument with extra space. The value ! 426: should be of type `enum direction': either `upward' to pad above ! 427: the argument, `downward' to pad below, or `none' to inhibit ! 428: padding. ! 429: ! 430: This macro does not control the *amount* of padding; that is ! 431: always just enough to reach the next multiple of ! 432: `FUNCTION_ARG_BOUNDARY'. ! 433: ! 434: This macro has a default definition which is right for most ! 435: systems. For little-endian machines, the default is to pad ! 436: upward. For big-endian machines, the default is to pad downward ! 437: for an argument of constant size shorter than an `int', and ! 438: upward otherwise. ! 439: ! 440: `FUNCTION_ARG_BOUNDARY (MODE, TYPE)' ! 441: If defined, a C expression that gives the alignment boundary, in ! 442: bits, of an argument with the specified mode and type. If it is ! 443: not defined, `PARM_BOUNDARY' is used for all arguments. ! 444: ! 445: `FUNCTION_ARG_REGNO_P (REGNO)' ! 446: A C expression that is nonzero if REGNO is the number of a hard ! 447: register in which function arguments are sometimes passed. This ! 448: does *not* include implicit arguments such as the static chain and ! 449: the structure-value address. On many machines, no registers can ! 450: be used for this purpose since all function arguments are pushed ! 451: on the stack. ! 452: ! 453: ! 454: File: gcc.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling ! 455: ! 456: How Scalar Function Values Are Returned ! 457: --------------------------------------- ! 458: ! 459: This section discusses the macros that control returning scalars as ! 460: values--values that can fit in registers. ! 461: ! 462: `TRADITIONAL_RETURN_FLOAT' ! 463: Define this macro if `-traditional' should not cause functions ! 464: declared to return `float' to convert the value to `double'. ! 465: ! 466: `FUNCTION_VALUE (VALTYPE, FUNC)' ! 467: A C expression to create an RTX representing the place where a ! 468: function returns a value of data type VALTYPE. VALTYPE is a tree ! 469: node representing a data type. Write `TYPE_MODE (VALTYPE)' to ! 470: get the machine mode used to represent that type. On many ! 471: machines, only the mode is relevant. (Actually, on most ! 472: machines, scalar values are returned in the same place regardless ! 473: of mode). ! 474: ! 475: If the precise function being called is known, FUNC is a tree ! 476: node (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. ! 477: This makes it possible to use a different value-returning ! 478: convention for specific functions when all their calls are known. ! 479: ! 480: `FUNCTION_VALUE' is not used for return vales with aggregate data ! 481: types, because these are returned in another way. See ! 482: `STRUCT_VALUE_REGNUM' and related macros, below. ! 483: ! 484: `FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)' ! 485: Define this macro if the target machine has "register windows" so ! 486: that the register in which a function returns its value is not ! 487: the same as the one in which the caller sees the value. ! 488: ! 489: For such machines, `FUNCTION_VALUE' computes the register in ! 490: which the caller will see the value, and ! 491: `FUNCTION_OUTGOING_VALUE' should be defined in a similar fashion ! 492: to tell the function where to put the value. ! 493: ! 494: If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE' ! 495: serves both purposes. ! 496: ! 497: `FUNCTION_OUTGOING_VALUE' is not used for return vales with ! 498: aggregate data types, because these are returned in another way. ! 499: See `STRUCT_VALUE_REGNUM' and related macros, below. ! 500: ! 501: `LIBCALL_VALUE (MODE)' ! 502: A C expression to create an RTX representing the place where a ! 503: library function returns a value of mode MODE. If the precise ! 504: function being called is known, FUNC is a tree node ! 505: (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. ! 506: This makes it possible to use a different value-returning ! 507: convention for specific functions when all their calls are known. ! 508: ! 509: Note that "library function" in this context means a compiler ! 510: support routine, used to perform arithmetic, whose name is known ! 511: specially by the compiler and was not mentioned in the C code ! 512: being compiled. ! 513: ! 514: The definition of `LIBRARY_VALUE' need not be concerned aggregate ! 515: data types, because none of the library functions returns such ! 516: types. ! 517: ! 518: `FUNCTION_VALUE_REGNO_P (REGNO)' ! 519: A C expression that is nonzero if REGNO is the number of a hard ! 520: register in which the values of called function may come back. ! 521: ! 522: A register whose use for returning values is limited to serving ! 523: as the second of a pair (for a value of type `double', say) need ! 524: not be recognized by this macro. So for most machines, this ! 525: definition suffices: ! 526: ! 527: #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) ! 528: ! 529: If the machine has register windows, so that the caller and the ! 530: called function use different registers for the return value, ! 531: this macro should recognize only the caller's register numbers. ! 532: ! 533: ! 534: File: gcc.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling ! 535: ! 536: How Large Values Are Returnd ! 537: ---------------------------- ! 538: ! 539: When a function value's mode is `BLKmode' (and in some other ! 540: cases), the value is not returned according to `FUNCTION_VALUE' (*note ! 541: Scalar Return::.). Instead, the caller passes the address of a block ! 542: of memory in which the value should be stored. This address is called ! 543: the "structure value address". ! 544: ! 545: This section describes how to control returning structure values in ! 546: memory. ! 547: ! 548: `RETURN_IN_MEMORY (TYPE)' ! 549: A C expression which can inhibit the returning of certain function ! 550: values in registers, based on the type of value. A nonzero value ! 551: says to return the function value in memory, just as large ! 552: structures are always returned. Here TYPE will be a C expression ! 553: of type `tree', representing the data type of the value. ! 554: ! 555: Note that values of mode `BLKmode' are returned in memory ! 556: regardless of this macro. Also, the option `-fpcc-struct-return' ! 557: takes effect regardless of this macro. On most systems, it is ! 558: possible to leave the macro undefined; this causes a default ! 559: definition to be used, whose value is the constant 0. ! 560: ! 561: `STRUCT_VALUE_REGNUM' ! 562: If the structure value address is passed in a register, then ! 563: `STRUCT_VALUE_REGNUM' should be the number of that register. ! 564: ! 565: `STRUCT_VALUE' ! 566: If the structure value address is not passed in a register, define ! 567: `STRUCT_VALUE' as an expression returning an RTX for the place ! 568: where the address is passed. If it returns 0, the address is ! 569: passed as an "invisible" first argument. ! 570: ! 571: `STRUCT_VALUE_INCOMING_REGNUM' ! 572: On some architectures the place where the structure value address ! 573: is found by the called function is not the same place that the ! 574: caller put it. This can be due to register windows, or it could ! 575: be because the function prologue moves it to a different place. ! 576: ! 577: If the incoming location of the structure value address is in a ! 578: register, define this macro as the register number. ! 579: ! 580: `STRUCT_VALUE_INCOMING' ! 581: If the incoming location is not a register, define ! 582: `STRUCT_VALUE_INCOMING' as an expression for an RTX for where the ! 583: called function should find the value. If it should find the ! 584: value on the stack, define this to create a `mem' which refers to ! 585: the frame pointer. A definition of 0 means that the address is ! 586: passed as an "invisible" first argument. ! 587: ! 588: `PCC_STATIC_STRUCT_RETURN' ! 589: Define this macro if the usual system convention on the target ! 590: machine for returning structures and unions is for the called ! 591: function to return the address of a static variable containing ! 592: the value. GNU CC does not normally use this convention, even if ! 593: it is the usual one, but does use it if `-fpcc-struct-value' is ! 594: specified. ! 595: ! 596: Do not define this if the usual system convention is for the ! 597: caller to pass an address to the subroutine. ! 598: ! 599: ! 600: File: gcc.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling ! 601: ! 602: Caller-Saves Register Allocation ! 603: -------------------------------- ! 604: ! 605: If you enable it, GNU CC can save registers around function calls. ! 606: This makes it possible to use call-clobbered registers to hold ! 607: variables that must live across calls. ! 608: ! 609: `DEFAULT_CALLER_SAVES' ! 610: Define this macro if function calls on the target machine do not ! 611: preserve any registers; in other words, if `CALL_USED_REGISTERS' ! 612: has 1 for all registers. This macro enables `-fcaller-saves' by ! 613: default. Eventually that option will be enabled by default on ! 614: all machines and both the option and this macro will be ! 615: eliminated. ! 616: ! 617: `CALLER_SAVE_PROFITABLE (REFS, CALLS)' ! 618: A C expression to determine whether it is worthwhile to consider ! 619: placing a pseudo-register in a call-clobbered hard register and ! 620: saving and restoring it around each function call. The ! 621: expression should be 1 when this is worth doing, and 0 otherwise. ! 622: ! 623: If you don't define this macro, a default is used which is good ! 624: on most machines: `4 * CALLS < REFS'. ! 625: ! 626: ! 627: File: gcc.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling ! 628: ! 629: Function Entry and Exit ! 630: ----------------------- ! 631: ! 632: This section describes the macros that output function entry ! 633: ("prologue") and exit ("epilogue") code. ! 634: ! 635: `FUNCTION_PROLOGUE (FILE, SIZE)' ! 636: A C compound statement that outputs the assembler code for entry ! 637: to a function. The prologue is responsible for setting up the ! 638: stack frame, initializing the frame pointer register, saving ! 639: registers that must be saved, and allocating SIZE additional ! 640: bytes of storage for the local variables. SIZE is an integer. ! 641: FILE is a stdio stream to which the assembler code should be ! 642: output. ! 643: ! 644: The label for the beginning of the function need not be output by ! 645: this macro. That has already been done when the macro is run. ! 646: ! 647: To determine which registers to save, the macro can refer to the ! 648: array `regs_ever_live': element R is nonzero if hard register R ! 649: is used anywhere within the function. This implies the function ! 650: prologue should save register R, provided it is not one of the ! 651: call-used registers. (`FUNCTION_EPILOGUE' must likewise use ! 652: `regs_ever_live'.) ! 653: ! 654: On machines that have "register windows", the function entry code ! 655: does not save on the stack the registers that are in the windows, ! 656: even if they are supposed to be preserved by function calls; ! 657: instead it takes appropriate steps to "push" the register stack, ! 658: if any non-call-used registers are used in the function. ! 659: ! 660: On machines where functions may or may not have frame-pointers, ! 661: the function entry code must vary accordingly; it must set up the ! 662: frame pointer if one is wanted, and not otherwise. To determine ! 663: whether a frame pointer is in wanted, the macro can refer to the ! 664: variable `frame_pointer_needed'. The variable's value will be 1 ! 665: at run time in a function that needs a frame pointer. *Note ! 666: Elimination::. ! 667: ! 668: The function entry code is responsible for allocating any stack ! 669: space required for the function. This stack space consists of ! 670: the regions listed below. In most cases, these regions are ! 671: allocated in the order listed, with the last listed region ! 672: closest to the top of the stack (the lowest address if ! 673: `STACK_GROWS_DOWNWARD' is defined, and the highest address if it ! 674: is not defined). You can use a different order for a machine if ! 675: doing so is more convenient or required for compatibility ! 676: reasons. Except in cases where required by standard or by a ! 677: debugger, there is no reason why the stack layout used by GCC ! 678: need agree with that used by other compilers for a machine. ! 679: ! 680: * A region of `current_function_pretend_args_size' bytes of ! 681: uninitialized space just underneath the first argument ! 682: arriving on the stack. (This may not be at the very start ! 683: of the allocated stack region if the calling sequence has ! 684: pushed anything else since pushing the stack arguments. But ! 685: usually, on such machines, nothing else has been pushed yet, ! 686: because the function prologue itself does all the pushing.) ! 687: This region is used on machines where an argument may be ! 688: passed partly in registers and partly in memory, and, in ! 689: some cases to support the features in `varargs.h' and ! 690: `stdargs.h'. ! 691: ! 692: * An area of memory used to save certain registers used by the ! 693: function. The size of this area, which may also include ! 694: space for such things as the return address and pointers to ! 695: previous stack frames, is machine-specific and usually ! 696: depends on which registers have been used in the function. ! 697: Machines with register windows often do not require a save ! 698: area. ! 699: ! 700: * A region of at least SIZE bytes, possibly rounded up to an ! 701: allocation boundary, to contain the local variables of the ! 702: function. On some machines, this region and the save area ! 703: may occur in the opposite order, with the save area closer ! 704: to the top of the stack. ! 705: ! 706: * Optionally, in the case that `ACCUMULATE_OUTGOING_ARGS' is ! 707: defined, a region of `current_function_outgoing_args_size' ! 708: bytes to be used for outgoing argument lists of the ! 709: function. *Note Stack Arguments::. ! 710: ! 711: Normally, it is necessary for `FUNCTION_PROLOGUE' and ! 712: `FUNCTION_EPILOGUE' to treat leaf functions specially. The C ! 713: variable `leaf_function' is nonzero for such a function. ! 714: ! 715: `EXIT_IGNORE_STACK' ! 716: Define this macro as a C expression that is nonzero if the return ! 717: instruction or the function epilogue ignores the value of the ! 718: stack pointer; in other words, if it is safe to delete an ! 719: instruction to adjust the stack pointer before a return from the ! 720: function. ! 721: ! 722: Note that this macro's value is relevant only for functions for ! 723: which frame pointers are maintained. It is never safe to delete ! 724: a final stack adjustment in a function that has no frame pointer, ! 725: and the compiler knows this regardless of `EXIT_IGNORE_STACK'. ! 726: ! 727: `FUNCTION_EPILOGUE (FILE, SIZE)' ! 728: A C compound statement that outputs the assembler code for exit ! 729: from a function. The epilogue is responsible for restoring the ! 730: saved registers and stack pointer to their values when the ! 731: function was called, and returning control to the caller. This ! 732: macro takes the same arguments as the macro `FUNCTION_PROLOGUE', ! 733: and the registers to restore are determined from `regs_ever_live' ! 734: and `CALL_USED_REGISTERS' in the same way. ! 735: ! 736: On some machines, there is a single instruction that does all the ! 737: work of returning from the function. On these machines, give that ! 738: instruction the name `return' and do not define the macro ! 739: `FUNCTION_EPILOGUE' at all. ! 740: ! 741: Do not define a pattern named `return' if you want the ! 742: `FUNCTION_EPILOGUE' to be used. If you want the target switches ! 743: to control whether return instructions or epilogues are used, ! 744: define a `return' pattern with a validity condition that tests ! 745: the target switches appropriately. If the `return' pattern's ! 746: validity condition is false, epilogues will be used. ! 747: ! 748: On machines where functions may or may not have frame-pointers, ! 749: the function exit code must vary accordingly. Sometimes the code ! 750: for these two cases is completely different. To determine ! 751: whether a frame pointer is in wanted, the macro can refer to the ! 752: variable `frame_pointer_needed'. The variable's value will be 1 ! 753: at run time in a function that needs a frame pointer. ! 754: ! 755: Normally, it is necessary for `FUNCTION_PROLOGUE' and ! 756: `FUNCTION_EPILOGUE' to treat leaf functions specially. The C ! 757: variable `leaf_function' is nonzero for such a function. *Note ! 758: Leaf Functions::. ! 759: ! 760: On some machines, some functions pop their arguments on exit while ! 761: others leave that for the caller to do. For example, the 68020 ! 762: when given `-mrtd' pops arguments in functions that take a fixed ! 763: number of arguments. ! 764: ! 765: Your definition of the macro `RETURN_POPS_ARGS' decides which ! 766: functions pop their own arguments. `FUNCTION_EPILOGUE' needs to ! 767: know what was decided. The variable `current_function_pops_args' ! 768: is the number of bytes of its arguments that a function should ! 769: pop. *Note Scalar Return::. ! 770: ! 771: `DELAY_SLOTS_FOR_EPILOGUE' ! 772: Define this macro if the function epilogue contains delay slots ! 773: to which instructions from the rest of the function can be ! 774: "moved". The definition should be a C expression whose value is ! 775: an integer representing the number of delay slots there. ! 776: ! 777: `ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)' ! 778: A C expression that returns 1 if INSN can be placed in delay slot ! 779: number N of the epilogue. ! 780: ! 781: The argument N is an integer which identifies the delay slot now ! 782: being considered (since different slots may have different rules ! 783: of eligibility). It is never negative and is always less than ! 784: the number of epilogue delay slots (what ! 785: `DELAY_SLOTS_FOR_EPILOGUE' returns). If you reject a particular ! 786: insn for a given delay slot, in principle, it may be reconsidered ! 787: for a subsequent delay slot. Also, other insns may (at least in ! 788: principle) be considered for the so far unfilled delay slot. ! 789: ! 790: The insns accepted to fill the epilogue delay slots are put in an ! 791: RTL list made with `insn_list' objects, stored in the variable ! 792: `current_function_epilogue_delay_list'. The insn for the first ! 793: delay slot comes first in the list. Your definition of the macro ! 794: `FUNCTION_EPILOGUE' should fill the delay slots by outputting the ! 795: insns in this list, usually by calling `final_scan_insn'. ! 796: ! 797: You need not define this macro if you did not define ! 798: `DELAY_SLOTS_FOR_EPILOGUE'. ! 799: ! 800: ! 801: File: gcc.info, Node: Profiling, Prev: Function Entry, Up: Stack and Calling ! 802: ! 803: Generating Code for Profiling ! 804: ----------------------------- ! 805: ! 806: `FUNCTION_PROFILER (FILE, LABELNO)' ! 807: A C statement or compound statement to output to FILE some ! 808: assembler code to call the profiling subroutine `mcount'. Before ! 809: calling, the assembler code must load the address of a counter ! 810: variable into a register where `mcount' expects to find the ! 811: address. The name of this variable is `LP' followed by the ! 812: number LABELNO, so you would generate the name using `LP%d' in a ! 813: `fprintf'. ! 814: ! 815: The details of how the address should be passed to `mcount' are ! 816: determined by your operating system environment, not by GNU CC. ! 817: To figure them out, compile a small program for profiling using ! 818: the system's installed C compiler and look at the assembler code ! 819: that results. ! 820: ! 821: `PROFILE_BEFORE_PROLOGUE' ! 822: Define this macro if the code for function profiling should come ! 823: before the function prologue. Normally, the profiling code comes ! 824: after. ! 825: ! 826: `FUNCTION_BLOCK_PROFILER (FILE, LABELNO)' ! 827: A C statement or compound statement to output to FILE some ! 828: assembler code to initialize basic-block profiling for the current ! 829: object module. This code should call the subroutine ! 830: `__bb_init_func' once per object module, passing it as its sole ! 831: argument the address of a block allocated in the object module. ! 832: ! 833: The name of the block is a local symbol made with this statement: ! 834: ! 835: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0); ! 836: ! 837: Of course, since you are writing the definition of ! 838: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you ! 839: can take a short cut in the definition of this macro and use the ! 840: name that you know will result. ! 841: ! 842: The first word of this block is a flag which will be nonzero if ! 843: the object module has already been initialized. So test this ! 844: word first, and do not call `__bb_init_func' if the flag is ! 845: nonzero. ! 846: ! 847: `BLOCK_PROFILER (FILE, BLOCKNO)' ! 848: A C statement or compound statement to increment the count ! 849: associated with the basic block number BLOCKNO. Basic blocks are ! 850: numbered separately from zero within each compilation. The count ! 851: associated with block number BLOCKNO is at index BLOCKNO in a ! 852: vector of words; the name of this array is a local symbol made ! 853: with this statement: ! 854: ! 855: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2); ! 856: ! 857: Of course, since you are writing the definition of ! 858: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you ! 859: can take a short cut in the definition of this macro and use the ! 860: name that you know will result. ! 861: ! 862: ! 863: File: gcc.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Machine Macros ! 864: ! 865: Implementing the Varargs Macros ! 866: =============================== ! 867: ! 868: GNU CC comes with an implementation of `varargs.h' and `stdarg.h' ! 869: that work without change on machines that pass arguments on the stack. ! 870: Other machines require their own implementations of varargs, and the ! 871: two machine independent header files must have conditionals to include ! 872: it. ! 873: ! 874: ANSI `stdarg.h' differs from traditional `varargs.h' mainly in the ! 875: calling convention for `va_start'. The traditional implementation ! 876: takes just one argument, which is the variable in which to store the ! 877: argument pointer. The ANSI implementation takes an additional first ! 878: argument, which is the last named argument of the function. However, ! 879: it should not use this argument. The way to find the end of the named ! 880: arguments is with the built-in functions described below. ! 881: ! 882: `__builtin_saveregs ()' ! 883: Use this built-in function to save the argument registers in ! 884: memory so that the varargs mechanism can access them. Both ANSI ! 885: and traditional versions of `va_start' must use ! 886: `__builtin_saveregs', unless you use `SETUP_INCOMING_VARARGS' ! 887: (see below) instead. ! 888: ! 889: On some machines, `__builtin_saveregs' is open-coded under the ! 890: control of the macro `EXPAND_BUILTIN_SAVEREGS'. On other ! 891: machines, it calls a routine written in assembler language, found ! 892: in `libgcc2.c'. ! 893: ! 894: Regardless of what code is generated for the call to ! 895: `__builtin_saveregs', it appears at the beginning of the function, ! 896: not where the call to `__builtin_saveregs' is written. This is ! 897: because the registers must be saved before the function starts to ! 898: use them for its own purposes. ! 899: ! 900: `__builtin_args_info (CATEGORY)' ! 901: Use this built-in function to find the first anonymous arguments ! 902: in registers. ! 903: ! 904: In general, a machine may have several categories of registers ! 905: used for arguments, each for a particular category of data types. ! 906: (For example, on some machines, floating-point registers are ! 907: used for floating-point arguments while other arguments are ! 908: passed in the general registers.) To make non-varargs functions ! 909: use the proper calling convention, you have defined the ! 910: `CUMULATIVE_ARGS' data type to record how many registers in each ! 911: category have been used so far ! 912: ! 913: `__builtin_args_info' accesses the same data structure of type ! 914: `CUMULATIVE_ARGS' after the ordinary argument layout is finished ! 915: with it, with CATEGORY specifying which word to access. Thus, the ! 916: value indicates the first unused register in a given category. ! 917: ! 918: Normally, you would use `__builtin_args_info' in the ! 919: implementation of `va_start', accessing each category just once ! 920: and storing the value in the `va_list' object. This is because ! 921: `va_list' will have to update the values, and there is no way to ! 922: alter the values accessed by `__builtin_args_info'. ! 923: ! 924: `__builtin_next_arg ()' ! 925: This is the equivalent of `__builtin_args_info', for stack ! 926: arguments. It returns the address of the first anonymous stack ! 927: argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns ! 928: the address of the location above the first anonymous stack ! 929: argument. Use it in `va_start' to initialize the pointer for ! 930: fetching arguments from the stack. ! 931: ! 932: `__builtin_classify_type (OBJECT)' ! 933: Since each machine has its own conventions for which data types ! 934: are passed in which kind of register, your implementation of ! 935: `va_arg' has to embody these conventions. The easiest way to ! 936: categorize the specified data type is to use ! 937: `__builtin_classify_type' together with `sizeof' and ! 938: `__alignof__'. ! 939: ! 940: `__builtin_classify_type' ignores the value of OBJECT, ! 941: considering only its data type. It returns an integer describing ! 942: what kind of type that is--integer, floating, pointer, structure, ! 943: and so on. ! 944: ! 945: The file `typeclass.h' defines an enumeration that you can use to ! 946: interpret the values of `__builtin_classify_type'. ! 947: ! 948: These machine description macros help implement varargs: ! 949: ! 950: `EXPAND_BUILTIN_SAVEREGS (ARGS)' ! 951: If defined, is a C expression that produces the machine-specific ! 952: code for a call to `__builtin_saveregs'. This code will be moved ! 953: to the very beginning of the function, before any parameter ! 954: access are made. The return value of this function should be an ! 955: RTX that contains the value to use as the return of ! 956: `__builtin_saveregs'. ! 957: ! 958: The argument ARGS is a `tree_list' containing the arguments that ! 959: were passed to `__builtin_saveregs'. ! 960: ! 961: If this macro is not defined, the compiler will output an ordinary ! 962: call to the library function `__builtin_saveregs'. ! 963: ! 964: `SETUP_INCOMING_VARARGS (ARGS_SO_FAR, MODE, TYPE, PRETEND_ARGS_SIZE, SECOND_TIME)' ! 965: This macro offers an alternative to using `__builtin_saveregs' and ! 966: defining the macro `EXPAND_BUILTIN_SAVEREGS'. Use it to store the ! 967: anonymous register arguments into the stack so that all the ! 968: arguments appear to have been passed consecutively on the stack. ! 969: Once this is done, you can use the standard implementation of ! 970: varargs that works for machines that pass all their arguments on ! 971: the stack. ! 972: ! 973: The argument ARGS_SO_FAR is the `CUMULATIVE_ARGS' data structure, ! 974: containing the values that obtain after processing of the named ! 975: arguments. The arguments MODE and TYPE describe the last named ! 976: argument--its machine mode and its data type as a tree node. ! 977: ! 978: The macro implementation should do two things: first, push onto ! 979: the stack all the argument registers *not* used for the named ! 980: arguments, and second, store the size of the data thus pushed ! 981: into the `int'-valued variable whose name is supplied as the ! 982: argument PRETEND_ARGS_SIZE. The value that you store here will ! 983: serve as additional offset for setting up the stack frame. ! 984: ! 985: Because you must generate code to push the anonymous arguments at ! 986: compile time without knowing their data types, ! 987: `SETUP_INCOMING_VARARGS' is only useful on machines that have just ! 988: a single category of argument register and use it uniformly for ! 989: all data types. ! 990: ! 991: If the argument SECOND_TIME is nonzero, it means that the ! 992: arguments of the function are being analyzed for the second time. ! 993: This happens for an inline function, which is not actually ! 994: compiled until the end of the source file. The macro ! 995: `SETUP_INCOMING_VARARGS' should not generate any instructions in ! 996: this case. ! 997: ! 998:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.