![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-20 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-20 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.3 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.55 from the input 1.1 root 2: file gcc.texi. 3: 4: This file documents the use and the internals of the GNU compiler. 5: 6: Published by the Free Software Foundation 675 Massachusetts Avenue 7: Cambridge, MA 02139 USA 8: 1.1.1.3 ! root 9: Copyright (C) 1988, 1989, 1992, 1993, 1994 Free Software Foundation, ! 10: Inc. 1.1 root 11: 12: Permission is granted to make and distribute verbatim copies of this 13: manual provided the copyright notice and this permission notice are 14: preserved on all copies. 15: 16: Permission is granted to copy and distribute modified versions of 17: this manual under the conditions for verbatim copying, provided also 1.1.1.3 ! root 18: that the sections entitled "GNU General Public License," "Funding for ! 19: Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are ! 20: included exactly as in the original, and provided that the entire ! 21: resulting derived work is distributed under the terms of a permission ! 22: notice identical to this one. 1.1 root 23: 24: Permission is granted to copy and distribute translations of this 25: manual into another language, under the above conditions for modified 26: versions, except that the sections entitled "GNU General Public 1.1.1.3 ! root 27: License," "Funding for Free Software," and "Protect Your Freedom--Fight ! 28: `Look And Feel'", and this permission notice, may be included in ! 29: translations approved by the Free Software Foundation instead of in the ! 30: original English. 1.1 root 31: 32: 1.1.1.3 ! root 33: File: gcc.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 1.1 root 34: 1.1.1.3 ! root 35: How Scalar Function Values Are Returned ! 36: --------------------------------------- 1.1 root 37: 1.1.1.3 ! root 38: This section discusses the macros that control returning scalars as ! 39: values--values that can fit in registers. 1.1.1.2 root 40: 1.1.1.3 ! root 41: `TRADITIONAL_RETURN_FLOAT' ! 42: Define this macro if `-traditional' should not cause functions ! 43: declared to return `float' to convert the value to `double'. ! 44: ! 45: `FUNCTION_VALUE (VALTYPE, FUNC)' ! 46: A C expression to create an RTX representing the place where a ! 47: function returns a value of data type VALTYPE. VALTYPE is a tree ! 48: node representing a data type. Write `TYPE_MODE (VALTYPE)' to get ! 49: the machine mode used to represent that type. On many machines, ! 50: only the mode is relevant. (Actually, on most machines, scalar ! 51: values are returned in the same place regardless of mode). ! 52: ! 53: If `PROMOTE_FUNCTION_RETURN' is defined, you must apply the same ! 54: promotion rules specified in `PROMOTE_MODE' if VALTYPE is a scalar ! 55: type. ! 56: ! 57: If the precise function being called is known, FUNC is a tree node ! 58: (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This ! 59: makes it possible to use a different value-returning convention ! 60: for specific functions when all their calls are known. ! 61: ! 62: `FUNCTION_VALUE' is not used for return vales with aggregate data ! 63: types, because these are returned in another way. See ! 64: `STRUCT_VALUE_REGNUM' and related macros, below. ! 65: ! 66: `FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)' ! 67: Define this macro if the target machine has "register windows" so ! 68: that the register in which a function returns its value is not the ! 69: same as the one in which the caller sees the value. ! 70: ! 71: For such machines, `FUNCTION_VALUE' computes the register in which ! 72: the caller will see the value. `FUNCTION_OUTGOING_VALUE' should be ! 73: defined in a similar fashion to tell the function where to put the ! 74: value. ! 75: ! 76: If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE' ! 77: serves both purposes. ! 78: ! 79: `FUNCTION_OUTGOING_VALUE' is not used for return vales with ! 80: aggregate data types, because these are returned in another way. ! 81: See `STRUCT_VALUE_REGNUM' and related macros, below. ! 82: ! 83: `LIBCALL_VALUE (MODE)' ! 84: A C expression to create an RTX representing the place where a ! 85: library function returns a value of mode MODE. If the precise ! 86: function being called is known, FUNC is a tree node ! 87: (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This ! 88: makes it possible to use a different value-returning convention ! 89: for specific functions when all their calls are known. ! 90: ! 91: Note that "library function" in this context means a compiler ! 92: support routine, used to perform arithmetic, whose name is known ! 93: specially by the compiler and was not mentioned in the C code being ! 94: compiled. ! 95: ! 96: The definition of `LIBRARY_VALUE' need not be concerned aggregate ! 97: data types, because none of the library functions returns such ! 98: types. ! 99: ! 100: `FUNCTION_VALUE_REGNO_P (REGNO)' ! 101: A C expression that is nonzero if REGNO is the number of a hard ! 102: register in which the values of called function may come back. ! 103: ! 104: A register whose use for returning values is limited to serving as ! 105: the second of a pair (for a value of type `double', say) need not ! 106: be recognized by this macro. So for most machines, this definition ! 107: suffices: ! 108: ! 109: #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) ! 110: ! 111: If the machine has register windows, so that the caller and the ! 112: called function use different registers for the return value, this ! 113: macro should recognize only the caller's register numbers. ! 114: ! 115: `APPLY_RESULT_SIZE' ! 116: Define this macro if `untyped_call' and `untyped_return' need more ! 117: space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and ! 118: restoring an arbitrary return value. 1.1 root 119: 120: 1.1.1.3 ! root 121: File: gcc.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 1.1 root 122: 1.1.1.3 ! root 123: How Large Values Are Returned ! 124: ----------------------------- 1.1 root 125: 1.1.1.3 ! root 126: When a function value's mode is `BLKmode' (and in some other cases), ! 127: the value is not returned according to `FUNCTION_VALUE' (*note Scalar ! 128: Return::.). Instead, the caller passes the address of a block of ! 129: memory in which the value should be stored. This address is called the ! 130: "structure value address". ! 131: ! 132: This section describes how to control returning structure values in ! 133: memory. ! 134: ! 135: `RETURN_IN_MEMORY (TYPE)' ! 136: A C expression which can inhibit the returning of certain function ! 137: values in registers, based on the type of value. A nonzero value ! 138: says to return the function value in memory, just as large ! 139: structures are always returned. Here TYPE will be a C expression ! 140: of type `tree', representing the data type of the value. ! 141: ! 142: Note that values of mode `BLKmode' must be explicitly handled by ! 143: this macro. Also, the option `-fpcc-struct-return' takes effect ! 144: regardless of this macro. On most systems, it is possible to ! 145: leave the macro undefined; this causes a default definition to be ! 146: used, whose value is the constant 1 for `BLKmode' values, and 0 ! 147: otherwise. ! 148: ! 149: Do not use this macro to indicate that structures and unions ! 150: should always be returned in memory. You should instead use ! 151: `DEFAULT_PCC_STRUCT_RETURN' to indicate this. ! 152: ! 153: `DEFAULT_PCC_STRUCT_RETURN' ! 154: Define this macro to be 1 if all structure and union return values ! 155: must be in memory. Since this results in slower code, this should ! 156: be defined only if needed for compatibility with other compilers ! 157: or with an ABI. If you define this macro to be 0, then the ! 158: conventions used for structure and union return values are decided ! 159: by the `RETURN_IN_MEMORY' macro. ! 160: ! 161: If not defined, this defaults to the value 1. ! 162: ! 163: `STRUCT_VALUE_REGNUM' ! 164: If the structure value address is passed in a register, then ! 165: `STRUCT_VALUE_REGNUM' should be the number of that register. ! 166: ! 167: `STRUCT_VALUE' ! 168: If the structure value address is not passed in a register, define ! 169: `STRUCT_VALUE' as an expression returning an RTX for the place ! 170: where the address is passed. If it returns 0, the address is ! 171: passed as an "invisible" first argument. ! 172: ! 173: `STRUCT_VALUE_INCOMING_REGNUM' ! 174: On some architectures the place where the structure value address ! 175: is found by the called function is not the same place that the ! 176: caller put it. This can be due to register windows, or it could ! 177: be because the function prologue moves it to a different place. ! 178: ! 179: If the incoming location of the structure value address is in a ! 180: register, define this macro as the register number. ! 181: ! 182: `STRUCT_VALUE_INCOMING' ! 183: If the incoming location is not a register, then you should define ! 184: `STRUCT_VALUE_INCOMING' as an expression for an RTX for where the ! 185: called function should find the value. If it should find the ! 186: value on the stack, define this to create a `mem' which refers to ! 187: the frame pointer. A definition of 0 means that the address is ! 188: passed as an "invisible" first argument. ! 189: ! 190: `PCC_STATIC_STRUCT_RETURN' ! 191: Define this macro if the usual system convention on the target ! 192: machine for returning structures and unions is for the called ! 193: function to return the address of a static variable containing the ! 194: value. 1.1 root 195: 1.1.1.3 ! root 196: Do not define this if the usual system convention is for the ! 197: caller to pass an address to the subroutine. ! 198: ! 199: This macro has effect in `-fpcc-struct-return' mode, but it does ! 200: nothing when you use `-freg-struct-return' mode. 1.1 root 201: 202: 1.1.1.3 ! root 203: File: gcc.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling ! 204: ! 205: Caller-Saves Register Allocation ! 206: -------------------------------- 1.1 root 207: 1.1.1.3 ! root 208: If you enable it, GNU CC can save registers around function calls. ! 209: This makes it possible to use call-clobbered registers to hold ! 210: variables that must live across calls. ! 211: ! 212: `DEFAULT_CALLER_SAVES' ! 213: Define this macro if function calls on the target machine do not ! 214: preserve any registers; in other words, if `CALL_USED_REGISTERS' ! 215: has 1 for all registers. This macro enables `-fcaller-saves' by ! 216: default. Eventually that option will be enabled by default on all ! 217: machines and both the option and this macro will be eliminated. ! 218: ! 219: `CALLER_SAVE_PROFITABLE (REFS, CALLS)' ! 220: A C expression to determine whether it is worthwhile to consider ! 221: placing a pseudo-register in a call-clobbered hard register and ! 222: saving and restoring it around each function call. The expression ! 223: should be 1 when this is worth doing, and 0 otherwise. 1.1 root 224: 1.1.1.3 ! root 225: If you don't define this macro, a default is used which is good on ! 226: most machines: `4 * CALLS < REFS'. 1.1 root 227: 1.1.1.2 root 228: 1.1.1.3 ! root 229: File: gcc.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling 1.1 root 230: 1.1.1.3 ! root 231: Function Entry and Exit ! 232: ----------------------- 1.1 root 233: 1.1.1.3 ! root 234: This section describes the macros that output function entry ! 235: ("prologue") and exit ("epilogue") code. 1.1 root 236: 1.1.1.3 ! root 237: `FUNCTION_PROLOGUE (FILE, SIZE)' ! 238: A C compound statement that outputs the assembler code for entry ! 239: to a function. The prologue is responsible for setting up the ! 240: stack frame, initializing the frame pointer register, saving ! 241: registers that must be saved, and allocating SIZE additional bytes ! 242: of storage for the local variables. SIZE is an integer. FILE is ! 243: a stdio stream to which the assembler code should be output. ! 244: ! 245: The label for the beginning of the function need not be output by ! 246: this macro. That has already been done when the macro is run. ! 247: ! 248: To determine which registers to save, the macro can refer to the ! 249: array `regs_ever_live': element R is nonzero if hard register R is ! 250: used anywhere within the function. This implies the function ! 251: prologue should save register R, provided it is not one of the ! 252: call-used registers. (`FUNCTION_EPILOGUE' must likewise use ! 253: `regs_ever_live'.) ! 254: ! 255: On machines that have "register windows", the function entry code ! 256: does not save on the stack the registers that are in the windows, ! 257: even if they are supposed to be preserved by function calls; ! 258: instead it takes appropriate steps to "push" the register stack, ! 259: if any non-call-used registers are used in the function. ! 260: ! 261: On machines where functions may or may not have frame-pointers, the ! 262: function entry code must vary accordingly; it must set up the frame ! 263: pointer if one is wanted, and not otherwise. To determine whether ! 264: a frame pointer is in wanted, the macro can refer to the variable ! 265: `frame_pointer_needed'. The variable's value will be 1 at run ! 266: time in a function that needs a frame pointer. *Note ! 267: Elimination::. ! 268: ! 269: The function entry code is responsible for allocating any stack ! 270: space required for the function. This stack space consists of the ! 271: regions listed below. In most cases, these regions are allocated ! 272: in the order listed, with the last listed region closest to the ! 273: top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is ! 274: defined, and the highest address if it is not defined). You can ! 275: use a different order for a machine if doing so is more convenient ! 276: or required for compatibility reasons. Except in cases where ! 277: required by standard or by a debugger, there is no reason why the ! 278: stack layout used by GCC need agree with that used by other ! 279: compilers for a machine. ! 280: ! 281: * A region of `current_function_pretend_args_size' bytes of ! 282: uninitialized space just underneath the first argument ! 283: arriving on the stack. (This may not be at the very start of ! 284: the allocated stack region if the calling sequence has pushed ! 285: anything else since pushing the stack arguments. But ! 286: usually, on such machines, nothing else has been pushed yet, ! 287: because the function prologue itself does all the pushing.) ! 288: This region is used on machines where an argument may be ! 289: passed partly in registers and partly in memory, and, in some ! 290: cases to support the features in `varargs.h' and `stdargs.h'. ! 291: ! 292: * An area of memory used to save certain registers used by the ! 293: function. The size of this area, which may also include ! 294: space for such things as the return address and pointers to ! 295: previous stack frames, is machine-specific and usually ! 296: depends on which registers have been used in the function. ! 297: Machines with register windows often do not require a save ! 298: area. ! 299: ! 300: * A region of at least SIZE bytes, possibly rounded up to an ! 301: allocation boundary, to contain the local variables of the ! 302: function. On some machines, this region and the save area ! 303: may occur in the opposite order, with the save area closer to ! 304: the top of the stack. ! 305: ! 306: * Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a ! 307: region of `current_function_outgoing_args_size' bytes to be ! 308: used for outgoing argument lists of the function. *Note ! 309: Stack Arguments::. ! 310: ! 311: Normally, it is necessary for the macros `FUNCTION_PROLOGUE' and ! 312: `FUNCTION_EPILOGUE' to treat leaf functions specially. The C ! 313: variable `leaf_function' is nonzero for such a function. ! 314: ! 315: `EXIT_IGNORE_STACK' ! 316: Define this macro as a C expression that is nonzero if the return ! 317: instruction or the function epilogue ignores the value of the stack ! 318: pointer; in other words, if it is safe to delete an instruction to ! 319: adjust the stack pointer before a return from the function. ! 320: ! 321: Note that this macro's value is relevant only for functions for ! 322: which frame pointers are maintained. It is never safe to delete a ! 323: final stack adjustment in a function that has no frame pointer, ! 324: and the compiler knows this regardless of `EXIT_IGNORE_STACK'. ! 325: ! 326: `FUNCTION_EPILOGUE (FILE, SIZE)' ! 327: A C compound statement that outputs the assembler code for exit ! 328: from a function. The epilogue is responsible for restoring the ! 329: saved registers and stack pointer to their values when the ! 330: function was called, and returning control to the caller. This ! 331: macro takes the same arguments as the macro `FUNCTION_PROLOGUE', ! 332: and the registers to restore are determined from `regs_ever_live' ! 333: and `CALL_USED_REGISTERS' in the same way. ! 334: ! 335: On some machines, there is a single instruction that does all the ! 336: work of returning from the function. On these machines, give that ! 337: instruction the name `return' and do not define the macro ! 338: `FUNCTION_EPILOGUE' at all. ! 339: ! 340: Do not define a pattern named `return' if you want the ! 341: `FUNCTION_EPILOGUE' to be used. If you want the target switches ! 342: to control whether return instructions or epilogues are used, ! 343: define a `return' pattern with a validity condition that tests the ! 344: target switches appropriately. If the `return' pattern's validity ! 345: condition is false, epilogues will be used. ! 346: ! 347: On machines where functions may or may not have frame-pointers, the ! 348: function exit code must vary accordingly. Sometimes the code for ! 349: these two cases is completely different. To determine whether a ! 350: frame pointer is wanted, the macro can refer to the variable ! 351: `frame_pointer_needed'. The variable's value will be 1 when ! 352: compiling a function that needs a frame pointer. ! 353: ! 354: Normally, `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE' must treat ! 355: leaf functions specially. The C variable `leaf_function' is ! 356: nonzero for such a function. *Note Leaf Functions::. ! 357: ! 358: On some machines, some functions pop their arguments on exit while ! 359: others leave that for the caller to do. For example, the 68020 ! 360: when given `-mrtd' pops arguments in functions that take a fixed ! 361: number of arguments. ! 362: ! 363: Your definition of the macro `RETURN_POPS_ARGS' decides which ! 364: functions pop their own arguments. `FUNCTION_EPILOGUE' needs to ! 365: know what was decided. The variable that is called ! 366: `current_function_pops_args' is the number of bytes of its ! 367: arguments that a function should pop. *Note Scalar Return::. ! 368: ! 369: `DELAY_SLOTS_FOR_EPILOGUE' ! 370: Define this macro if the function epilogue contains delay slots to ! 371: which instructions from the rest of the function can be "moved". ! 372: The definition should be a C expression whose value is an integer ! 373: representing the number of delay slots there. ! 374: ! 375: `ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)' ! 376: A C expression that returns 1 if INSN can be placed in delay slot ! 377: number N of the epilogue. ! 378: ! 379: The argument N is an integer which identifies the delay slot now ! 380: being considered (since different slots may have different rules of ! 381: eligibility). It is never negative and is always less than the ! 382: number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE' ! 383: returns). If you reject a particular insn for a given delay slot, ! 384: in principle, it may be reconsidered for a subsequent delay slot. ! 385: Also, other insns may (at least in principle) be considered for ! 386: the so far unfilled delay slot. ! 387: ! 388: The insns accepted to fill the epilogue delay slots are put in an ! 389: RTL list made with `insn_list' objects, stored in the variable ! 390: `current_function_epilogue_delay_list'. The insn for the first ! 391: delay slot comes first in the list. Your definition of the macro ! 392: `FUNCTION_EPILOGUE' should fill the delay slots by outputting the ! 393: insns in this list, usually by calling `final_scan_insn'. 1.1 root 394: 1.1.1.3 ! root 395: You need not define this macro if you did not define ! 396: `DELAY_SLOTS_FOR_EPILOGUE'. 1.1 root 397: 398: 1.1.1.3 ! root 399: File: gcc.info, Node: Profiling, Prev: Function Entry, Up: Stack and Calling 1.1 root 400: 1.1.1.3 ! root 401: Generating Code for Profiling ! 402: ----------------------------- 1.1 root 403: 1.1.1.3 ! root 404: These macros will help you generate code for profiling. 1.1 root 405: 1.1.1.3 ! root 406: `FUNCTION_PROFILER (FILE, LABELNO)' ! 407: A C statement or compound statement to output to FILE some ! 408: assembler code to call the profiling subroutine `mcount'. Before ! 409: calling, the assembler code must load the address of a counter ! 410: variable into a register where `mcount' expects to find the ! 411: address. The name of this variable is `LP' followed by the number ! 412: LABELNO, so you would generate the name using `LP%d' in a ! 413: `fprintf'. ! 414: ! 415: The details of how the address should be passed to `mcount' are ! 416: determined by your operating system environment, not by GNU CC. To ! 417: figure them out, compile a small program for profiling using the ! 418: system's installed C compiler and look at the assembler code that ! 419: results. ! 420: ! 421: `PROFILE_BEFORE_PROLOGUE' ! 422: Define this macro if the code for function profiling should come ! 423: before the function prologue. Normally, the profiling code comes ! 424: after. ! 425: ! 426: `FUNCTION_BLOCK_PROFILER (FILE, LABELNO)' ! 427: A C statement or compound statement to output to FILE some ! 428: assembler code to initialize basic-block profiling for the current ! 429: object module. This code should call the subroutine ! 430: `__bb_init_func' once per object module, passing it as its sole ! 431: argument the address of a block allocated in the object module. ! 432: ! 433: The name of the block is a local symbol made with this statement: ! 434: ! 435: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0); ! 436: ! 437: Of course, since you are writing the definition of ! 438: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you ! 439: can take a short cut in the definition of this macro and use the ! 440: name that you know will result. ! 441: ! 442: The first word of this block is a flag which will be nonzero if the ! 443: object module has already been initialized. So test this word ! 444: first, and do not call `__bb_init_func' if the flag is nonzero. ! 445: ! 446: `BLOCK_PROFILER (FILE, BLOCKNO)' ! 447: A C statement or compound statement to increment the count ! 448: associated with the basic block number BLOCKNO. Basic blocks are ! 449: numbered separately from zero within each compilation. The count ! 450: associated with block number BLOCKNO is at index BLOCKNO in a ! 451: vector of words; the name of this array is a local symbol made ! 452: with this statement: ! 453: ! 454: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2); ! 455: ! 456: Of course, since you are writing the definition of ! 457: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you ! 458: can take a short cut in the definition of this macro and use the ! 459: name that you know will result. ! 460: ! 461: `BLOCK_PROFILER_CODE' ! 462: A C function or functions which are needed in the library to ! 463: support block profiling. 1.1 root 464: 1.1.1.3 ! root 465: ! 466: File: gcc.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros 1.1 root 467: 1.1.1.3 ! root 468: Implementing the Varargs Macros ! 469: =============================== 1.1 root 470: 1.1.1.3 ! root 471: GNU CC comes with an implementation of `varargs.h' and `stdarg.h' ! 472: that work without change on machines that pass arguments on the stack. ! 473: Other machines require their own implementations of varargs, and the ! 474: two machine independent header files must have conditionals to include ! 475: it. ! 476: ! 477: ANSI `stdarg.h' differs from traditional `varargs.h' mainly in the ! 478: calling convention for `va_start'. The traditional implementation ! 479: takes just one argument, which is the variable in which to store the ! 480: argument pointer. The ANSI implementation of `va_start' takes an ! 481: additional second argument. The user is supposed to write the last ! 482: named argument of the function here. ! 483: ! 484: However, `va_start' should not use this argument. The way to find ! 485: the end of the named arguments is with the built-in functions described ! 486: below. ! 487: ! 488: `__builtin_saveregs ()' ! 489: Use this built-in function to save the argument registers in ! 490: memory so that the varargs mechanism can access them. Both ANSI ! 491: and traditional versions of `va_start' must use ! 492: `__builtin_saveregs', unless you use `SETUP_INCOMING_VARARGS' (see ! 493: below) instead. ! 494: ! 495: On some machines, `__builtin_saveregs' is open-coded under the ! 496: control of the macro `EXPAND_BUILTIN_SAVEREGS'. On other machines, ! 497: it calls a routine written in assembler language, found in ! 498: `libgcc2.c'. ! 499: ! 500: Code generated for the call to `__builtin_saveregs' appears at the ! 501: beginning of the function, as opposed to where the call to ! 502: `__builtin_saveregs' is written, regardless of what the code is. ! 503: This is because the registers must be saved before the function ! 504: starts to use them for its own purposes. ! 505: ! 506: `__builtin_args_info (CATEGORY)' ! 507: Use this built-in function to find the first anonymous arguments in ! 508: registers. ! 509: ! 510: In general, a machine may have several categories of registers ! 511: used for arguments, each for a particular category of data types. ! 512: (For example, on some machines, floating-point registers are used ! 513: for floating-point arguments while other arguments are passed in ! 514: the general registers.) To make non-varargs functions use the ! 515: proper calling convention, you have defined the `CUMULATIVE_ARGS' ! 516: data type to record how many registers in each category have been ! 517: used so far ! 518: ! 519: `__builtin_args_info' accesses the same data structure of type ! 520: `CUMULATIVE_ARGS' after the ordinary argument layout is finished ! 521: with it, with CATEGORY specifying which word to access. Thus, the ! 522: value indicates the first unused register in a given category. ! 523: ! 524: Normally, you would use `__builtin_args_info' in the implementation ! 525: of `va_start', accessing each category just once and storing the ! 526: value in the `va_list' object. This is because `va_list' will ! 527: have to update the values, and there is no way to alter the values ! 528: accessed by `__builtin_args_info'. ! 529: ! 530: `__builtin_next_arg (LASTARG)' ! 531: This is the equivalent of `__builtin_args_info', for stack ! 532: arguments. It returns the address of the first anonymous stack ! 533: argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns ! 534: the address of the location above the first anonymous stack ! 535: argument. Use it in `va_start' to initialize the pointer for ! 536: fetching arguments from the stack. Also use it in `va_start' to ! 537: verify that the second parameter LASTARG is the last named argument ! 538: of the current function. ! 539: ! 540: `__builtin_classify_type (OBJECT)' ! 541: Since each machine has its own conventions for which data types are ! 542: passed in which kind of register, your implementation of `va_arg' ! 543: has to embody these conventions. The easiest way to categorize the ! 544: specified data type is to use `__builtin_classify_type' together ! 545: with `sizeof' and `__alignof__'. ! 546: ! 547: `__builtin_classify_type' ignores the value of OBJECT, considering ! 548: only its data type. It returns an integer describing what kind of ! 549: type that is--integer, floating, pointer, structure, and so on. ! 550: ! 551: The file `typeclass.h' defines an enumeration that you can use to ! 552: interpret the values of `__builtin_classify_type'. ! 553: ! 554: These machine description macros help implement varargs: ! 555: ! 556: `EXPAND_BUILTIN_SAVEREGS (ARGS)' ! 557: If defined, is a C expression that produces the machine-specific ! 558: code for a call to `__builtin_saveregs'. This code will be moved ! 559: to the very beginning of the function, before any parameter access ! 560: are made. The return value of this function should be an RTX that ! 561: contains the value to use as the return of `__builtin_saveregs'. ! 562: ! 563: The argument ARGS is a `tree_list' containing the arguments that ! 564: were passed to `__builtin_saveregs'. ! 565: ! 566: If this macro is not defined, the compiler will output an ordinary ! 567: call to the library function `__builtin_saveregs'. ! 568: ! 569: `SETUP_INCOMING_VARARGS (ARGS_SO_FAR, MODE, TYPE,' ! 570: PRETEND_ARGS_SIZE, SECOND_TIME) This macro offers an alternative ! 571: to using `__builtin_saveregs' and defining the macro ! 572: `EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous register ! 573: arguments into the stack so that all the arguments appear to have ! 574: been passed consecutively on the stack. Once this is done, you ! 575: can use the standard implementation of varargs that works for ! 576: machines that pass all their arguments on the stack. ! 577: ! 578: The argument ARGS_SO_FAR is the `CUMULATIVE_ARGS' data structure, ! 579: containing the values that obtain after processing of the named ! 580: arguments. The arguments MODE and TYPE describe the last named ! 581: argument--its machine mode and its data type as a tree node. ! 582: ! 583: The macro implementation should do two things: first, push onto the ! 584: stack all the argument registers *not* used for the named ! 585: arguments, and second, store the size of the data thus pushed into ! 586: the `int'-valued variable whose name is supplied as the argument ! 587: PRETEND_ARGS_SIZE. The value that you store here will serve as ! 588: additional offset for setting up the stack frame. ! 589: ! 590: Because you must generate code to push the anonymous arguments at ! 591: compile time without knowing their data types, ! 592: `SETUP_INCOMING_VARARGS' is only useful on machines that have just ! 593: a single category of argument register and use it uniformly for ! 594: all data types. ! 595: ! 596: If the argument SECOND_TIME is nonzero, it means that the ! 597: arguments of the function are being analyzed for the second time. ! 598: This happens for an inline function, which is not actually ! 599: compiled until the end of the source file. The macro ! 600: `SETUP_INCOMING_VARARGS' should not generate any instructions in ! 601: this case. 1.1 root 602: 1.1.1.2 root 603: 1.1.1.3 ! root 604: File: gcc.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 1.1 root 605: 1.1.1.3 ! root 606: Trampolines for Nested Functions ! 607: ================================ 1.1 root 608: 1.1.1.3 ! root 609: A "trampoline" is a small piece of code that is created at run time ! 610: when the address of a nested function is taken. It normally resides on ! 611: the stack, in the stack frame of the containing function. These macros ! 612: tell GNU CC how to generate code to allocate and initialize a ! 613: trampoline. ! 614: ! 615: The instructions in the trampoline must do two things: load a ! 616: constant address into the static chain register, and jump to the real ! 617: address of the nested function. On CISC machines such as the m68k, ! 618: this requires two instructions, a move immediate and a jump. Then the ! 619: two addresses exist in the trampoline as word-long immediate operands. ! 620: On RISC machines, it is often necessary to load each address into a ! 621: register in two parts. Then pieces of each address form separate ! 622: immediate operands. ! 623: ! 624: The code generated to initialize the trampoline must store the ! 625: variable parts--the static chain value and the function address--into ! 626: the immediate operands of the instructions. On a CISC machine, this is ! 627: simply a matter of copying each address to a memory reference at the ! 628: proper offset from the start of the trampoline. On a RISC machine, it ! 629: may be necessary to take out pieces of the address and store them ! 630: separately. ! 631: ! 632: `TRAMPOLINE_TEMPLATE (FILE)' ! 633: A C statement to output, on the stream FILE, assembler code for a ! 634: block of data that contains the constant parts of a trampoline. ! 635: This code should not include a label--the label is taken care of ! 636: automatically. ! 637: ! 638: `TRAMPOLINE_SECTION' ! 639: The name of a subroutine to switch to the section in which the ! 640: trampoline template is to be placed (*note Sections::.). The ! 641: default is a value of `readonly_data_section', which places the ! 642: trampoline in the section containing read-only data. ! 643: ! 644: `TRAMPOLINE_SIZE' ! 645: A C expression for the size in bytes of the trampoline, as an ! 646: integer. ! 647: ! 648: `TRAMPOLINE_ALIGNMENT' ! 649: Alignment required for trampolines, in bits. ! 650: ! 651: If you don't define this macro, the value of `BIGGEST_ALIGNMENT' ! 652: is used for aligning trampolines. ! 653: ! 654: `INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)' ! 655: A C statement to initialize the variable parts of a trampoline. ! 656: aDDR is an RTX for the address of the trampoline; FNADDR is an RTX ! 657: for the address of the nested function; STATIC_CHAIN is an RTX for ! 658: the static chain value that should be passed to the function when ! 659: it is called. ! 660: ! 661: `ALLOCATE_TRAMPOLINE (FP)' ! 662: A C expression to allocate run-time space for a trampoline. The ! 663: expression value should be an RTX representing a memory reference ! 664: to the space for the trampoline. ! 665: ! 666: If this macro is not defined, by default the trampoline is ! 667: allocated as a stack slot. This default is right for most ! 668: machines. The exceptions are machines where it is impossible to ! 669: execute instructions in the stack area. On such machines, you may ! 670: have to implement a separate stack, using this macro in ! 671: conjunction with `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE'. ! 672: ! 673: FP points to a data structure, a `struct function', which ! 674: describes the compilation status of the immediate containing ! 675: function of the function which the trampoline is for. Normally ! 676: (when `ALLOCATE_TRAMPOLINE' is not defined), the stack slot for the ! 677: trampoline is in the stack frame of this containing function. ! 678: Other allocation strategies probably must do something analogous ! 679: with this information. ! 680: ! 681: Implementing trampolines is difficult on many machines because they ! 682: have separate instruction and data caches. Writing into a stack ! 683: location fails to clear the memory in the instruction cache, so when ! 684: the program jumps to that location, it executes the old contents. ! 685: ! 686: Here are two possible solutions. One is to clear the relevant parts ! 687: of the instruction cache whenever a trampoline is set up. The other is ! 688: to make all trampolines identical, by having them jump to a standard ! 689: subroutine. The former technique makes trampoline execution faster; the ! 690: latter makes initialization faster. ! 691: ! 692: To clear the instruction cache when a trampoline is initialized, ! 693: define the following macros which describe the shape of the cache. ! 694: ! 695: `INSN_CACHE_SIZE' ! 696: The total size in bytes of the cache. ! 697: ! 698: `INSN_CACHE_LINE_WIDTH' ! 699: The length in bytes of each cache line. The cache is divided into ! 700: cache lines which are disjoint slots, each holding a contiguous ! 701: chunk of data fetched from memory. Each time data is brought into ! 702: the cache, an entire line is read at once. The data loaded into a ! 703: cache line is always aligned on a boundary equal to the line size. ! 704: ! 705: `INSN_CACHE_DEPTH' ! 706: The number of alternative cache lines that can hold any particular ! 707: memory location. ! 708: ! 709: Alternatively, if the machine has system calls or instructions to ! 710: clear the instruction cache directly, you can define the following ! 711: macro. ! 712: ! 713: `CLEAR_INSN_CACHE (BEG, END)' ! 714: If defined, expands to a C expression clearing the *instruction ! 715: cache* in the specified interval. If it is not defined, and the ! 716: macro INSN_CACHE_SIZE is defined, some generic code is generated ! 717: to clear the cache. The definition of this macro would typically ! 718: be a series of `asm' statements. Both BEG and END are both pointer ! 719: expressions. ! 720: ! 721: To use a standard subroutine, define the following macro. In ! 722: addition, you must make sure that the instructions in a trampoline fill ! 723: an entire cache line with identical instructions, or else ensure that ! 724: the beginning of the trampoline code is always aligned at the same ! 725: point in its cache line. Look in `m68k.h' as a guide. ! 726: ! 727: `TRANSFER_FROM_TRAMPOLINE' ! 728: Define this macro if trampolines need a special subroutine to do ! 729: their work. The macro should expand to a series of `asm' ! 730: statements which will be compiled with GNU CC. They go in a ! 731: library function named `__transfer_from_trampoline'. ! 732: ! 733: If you need to avoid executing the ordinary prologue code of a ! 734: compiled C function when you jump to the subroutine, you can do so ! 735: by placing a special label of your own in the assembler code. Use ! 736: one `asm' statement to generate an assembler label, and another to ! 737: make the label global. Then trampolines can use that label to ! 738: jump directly to your special assembler code. 1.1 root 739: 740: 1.1.1.3 ! root 741: File: gcc.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 1.1 root 742: 1.1.1.3 ! root 743: Implicit Calls to Library Routines ! 744: ================================== 1.1 root 745: 1.1.1.3 ! root 746: Here is an explanation of implicit calls to library routines. 1.1 root 747: 1.1.1.3 ! root 748: `MULSI3_LIBCALL' ! 749: A C string constant giving the name of the function to call for ! 750: multiplication of one signed full-word by another. If you do not ! 751: define this macro, the default name is used, which is `__mulsi3', ! 752: a function defined in `libgcc.a'. ! 753: ! 754: `DIVSI3_LIBCALL' ! 755: A C string constant giving the name of the function to call for ! 756: division of one signed full-word by another. If you do not define ! 757: this macro, the default name is used, which is `__divsi3', a ! 758: function defined in `libgcc.a'. ! 759: ! 760: `UDIVSI3_LIBCALL' ! 761: A C string constant giving the name of the function to call for ! 762: division of one unsigned full-word by another. If you do not ! 763: define this macro, the default name is used, which is `__udivsi3', ! 764: a function defined in `libgcc.a'. ! 765: ! 766: `MODSI3_LIBCALL' ! 767: A C string constant giving the name of the function to call for the ! 768: remainder in division of one signed full-word by another. If you ! 769: do not define this macro, the default name is used, which is ! 770: `__modsi3', a function defined in `libgcc.a'. ! 771: ! 772: `UMODSI3_LIBCALL' ! 773: A C string constant giving the name of the function to call for the ! 774: remainder in division of one unsigned full-word by another. If ! 775: you do not define this macro, the default name is used, which is ! 776: `__umodsi3', a function defined in `libgcc.a'. ! 777: ! 778: `MULDI3_LIBCALL' ! 779: A C string constant giving the name of the function to call for ! 780: multiplication of one signed double-word by another. If you do not ! 781: define this macro, the default name is used, which is `__muldi3', ! 782: a function defined in `libgcc.a'. ! 783: ! 784: `DIVDI3_LIBCALL' ! 785: A C string constant giving the name of the function to call for ! 786: division of one signed double-word by another. If you do not ! 787: define this macro, the default name is used, which is `__divdi3', a ! 788: function defined in `libgcc.a'. ! 789: ! 790: `UDIVDI3_LIBCALL' ! 791: A C string constant giving the name of the function to call for ! 792: division of one unsigned full-word by another. If you do not ! 793: define this macro, the default name is used, which is `__udivdi3', ! 794: a function defined in `libgcc.a'. ! 795: ! 796: `MODDI3_LIBCALL' ! 797: A C string constant giving the name of the function to call for the ! 798: remainder in division of one signed double-word by another. If ! 799: you do not define this macro, the default name is used, which is ! 800: `__moddi3', a function defined in `libgcc.a'. ! 801: ! 802: `UMODDI3_LIBCALL' ! 803: A C string constant giving the name of the function to call for the ! 804: remainder in division of one unsigned full-word by another. If ! 805: you do not define this macro, the default name is used, which is ! 806: `__umoddi3', a function defined in `libgcc.a'. ! 807: ! 808: `INIT_TARGET_OPTABS' ! 809: Define this macro as a C statement that declares additional library ! 810: routines renames existing ones. `init_optabs' calls this macro ! 811: after initializing all the normal library routines. ! 812: ! 813: `TARGET_EDOM' ! 814: The value of `EDOM' on the target machine, as a C integer constant ! 815: expression. If you don't define this macro, GNU CC does not ! 816: attempt to deposit the value of `EDOM' into `errno' directly. ! 817: Look in `/usr/include/errno.h' to find the value of `EDOM' on your ! 818: system. ! 819: ! 820: If you do not define `TARGET_EDOM', then compiled code reports ! 821: domain errors by calling the library function and letting it ! 822: report the error. If mathematical functions on your system use ! 823: `matherr' when there is an error, then you should leave ! 824: `TARGET_EDOM' undefined so that `matherr' is used normally. ! 825: ! 826: `GEN_ERRNO_RTX' ! 827: Define this macro as a C expression to create an rtl expression ! 828: that refers to the global "variable" `errno'. (On certain systems, ! 829: `errno' may not actually be a variable.) If you don't define this ! 830: macro, a reasonable default is used. ! 831: ! 832: `TARGET_MEM_FUNCTIONS' ! 833: Define this macro if GNU CC should generate calls to the System V ! 834: (and ANSI C) library functions `memcpy' and `memset' rather than ! 835: the BSD functions `bcopy' and `bzero'. ! 836: ! 837: `LIBGCC_NEEDS_DOUBLE' ! 838: Define this macro if only `float' arguments cannot be passed to ! 839: library routines (so they must be converted to `double'). This ! 840: macro affects both how library calls are generated and how the ! 841: library routines in `libgcc1.c' accept their arguments. It is ! 842: useful on machines where floating and fixed point arguments are ! 843: passed differently, such as the i860. ! 844: ! 845: `FLOAT_ARG_TYPE' ! 846: Define this macro to override the type used by the library ! 847: routines to pick up arguments of type `float'. (By default, they ! 848: use a union of `float' and `int'.) ! 849: ! 850: The obvious choice would be `float'--but that won't work with ! 851: traditional C compilers that expect all arguments declared as ! 852: `float' to arrive as `double'. To avoid this conversion, the ! 853: library routines ask for the value as some other type and then ! 854: treat it as a `float'. ! 855: ! 856: On some systems, no other type will work for this. For these ! 857: systems, you must use `LIBGCC_NEEDS_DOUBLE' instead, to force ! 858: conversion of the values `double' before they are passed. ! 859: ! 860: `FLOATIFY (PASSED-VALUE)' ! 861: Define this macro to override the way library routines redesignate ! 862: a `float' argument as a `float' instead of the type it was passed ! 863: as. The default is an expression which takes the `float' field of ! 864: the union. ! 865: ! 866: `FLOAT_VALUE_TYPE' ! 867: Define this macro to override the type used by the library ! 868: routines to return values that ought to have type `float'. (By ! 869: default, they use `int'.) ! 870: ! 871: The obvious choice would be `float'--but that won't work with ! 872: traditional C compilers gratuitously convert values declared as ! 873: `float' into `double'. ! 874: ! 875: `INTIFY (FLOAT-VALUE)' ! 876: Define this macro to override the way the value of a ! 877: `float'-returning library routine should be packaged in order to ! 878: return it. These functions are actually declared to return type ! 879: `FLOAT_VALUE_TYPE' (normally `int'). ! 880: ! 881: These values can't be returned as type `float' because traditional ! 882: C compilers would gratuitously convert the value to a `double'. ! 883: ! 884: A local variable named `intify' is always available when the macro ! 885: `INTIFY' is used. It is a union of a `float' field named `f' and ! 886: a field named `i' whose type is `FLOAT_VALUE_TYPE' or `int'. ! 887: ! 888: If you don't define this macro, the default definition works by ! 889: copying the value through that union. ! 890: ! 891: `nongcc_SI_type' ! 892: Define this macro as the name of the data type corresponding to ! 893: `SImode' in the system's own C compiler. ! 894: ! 895: You need not define this macro if that type is `long int', as it ! 896: usually is. ! 897: ! 898: `nongcc_word_type' ! 899: Define this macro as the name of the data type corresponding to the ! 900: word_mode in the system's own C compiler. ! 901: ! 902: You need not define this macro if that type is `long int', as it ! 903: usually is. ! 904: ! 905: `perform_...' ! 906: Define these macros to supply explicit C statements to carry out ! 907: various arithmetic operations on types `float' and `double' in the ! 908: library routines in `libgcc1.c'. See that file for a full list of ! 909: these macros and their arguments. ! 910: ! 911: On most machines, you don't need to define any of these macros, ! 912: because the C compiler that comes with the system takes care of ! 913: doing them. ! 914: ! 915: `NEXT_OBJC_RUNTIME' ! 916: Define this macro to generate code for Objective C message sending ! 917: using the calling convention of the NeXT system. This calling ! 918: convention involves passing the object, the selector and the ! 919: method arguments all at once to the method-lookup library function. ! 920: ! 921: The default calling convention passes just the object and the ! 922: selector to the lookup function, which returns a pointer to the ! 923: method. 1.1 root 924: 925: 1.1.1.3 ! root 926: File: gcc.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros 1.1 root 927: 1.1.1.3 ! root 928: Addressing Modes ! 929: ================ 1.1 root 930: 1.1.1.3 ! root 931: This is about addressing modes. 1.1 root 932: 1.1.1.3 ! root 933: `HAVE_POST_INCREMENT' ! 934: Define this macro if the machine supports post-increment ! 935: addressing. ! 936: ! 937: `HAVE_PRE_INCREMENT' ! 938: `HAVE_POST_DECREMENT' ! 939: `HAVE_PRE_DECREMENT' ! 940: Similar for other kinds of addressing. ! 941: ! 942: `CONSTANT_ADDRESS_P (X)' ! 943: A C expression that is 1 if the RTX X is a constant which is a ! 944: valid address. On most machines, this can be defined as ! 945: `CONSTANT_P (X)', but a few machines are more restrictive in which ! 946: constant addresses are supported. ! 947: ! 948: `CONSTANT_P' accepts integer-values expressions whose values are ! 949: not explicitly known, such as `symbol_ref', `label_ref', and ! 950: `high' expressions and `const' arithmetic expressions, in addition ! 951: to `const_int' and `const_double' expressions. ! 952: ! 953: `MAX_REGS_PER_ADDRESS' ! 954: A number, the maximum number of registers that can appear in a ! 955: valid memory address. Note that it is up to you to specify a ! 956: value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS' ! 957: would ever accept. ! 958: ! 959: `GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)' ! 960: A C compound statement with a conditional `goto LABEL;' executed ! 961: if X (an RTX) is a legitimate memory address on the target machine ! 962: for a memory operand of mode MODE. ! 963: ! 964: It usually pays to define several simpler macros to serve as ! 965: subroutines for this one. Otherwise it may be too complicated to ! 966: understand. ! 967: ! 968: This macro must exist in two variants: a strict variant and a ! 969: non-strict one. The strict variant is used in the reload pass. It ! 970: must be defined so that any pseudo-register that has not been ! 971: allocated a hard register is considered a memory reference. In ! 972: contexts where some kind of register is required, a pseudo-register ! 973: with no hard register must be rejected. ! 974: ! 975: The non-strict variant is used in other passes. It must be ! 976: defined to accept all pseudo-registers in every context where some ! 977: kind of register is required. ! 978: ! 979: Compiler source files that want to use the strict variant of this ! 980: macro define the macro `REG_OK_STRICT'. You should use an `#ifdef ! 981: REG_OK_STRICT' conditional to define the strict variant in that ! 982: case and the non-strict variant otherwise. ! 983: ! 984: Subroutines to check for acceptable registers for various purposes ! 985: (one for base registers, one for index registers, and so on) are ! 986: typically among the subroutines used to define ! 987: `GO_IF_LEGITIMATE_ADDRESS'. Then only these subroutine macros ! 988: need have two variants; the higher levels of macros may be the ! 989: same whether strict or not. ! 990: ! 991: Normally, constant addresses which are the sum of a `symbol_ref' ! 992: and an integer are stored inside a `const' RTX to mark them as ! 993: constant. Therefore, there is no need to recognize such sums ! 994: specifically as legitimate addresses. Normally you would simply ! 995: recognize any `const' as legitimate. ! 996: ! 997: Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant ! 998: sums that are not marked with `const'. It assumes that a naked ! 999: `plus' indicates indexing. If so, then you *must* reject such ! 1000: naked constant sums as illegitimate addresses, so that none of ! 1001: them will be given to `PRINT_OPERAND_ADDRESS'. ! 1002: ! 1003: On some machines, whether a symbolic address is legitimate depends ! 1004: on the section that the address refers to. On these machines, ! 1005: define the macro `ENCODE_SECTION_INFO' to store the information ! 1006: into the `symbol_ref', and then check for it here. When you see a ! 1007: `const', you will have to look inside it to find the `symbol_ref' ! 1008: in order to determine the section. *Note Assembler Format::. ! 1009: ! 1010: The best way to modify the name string is by adding text to the ! 1011: beginning, with suitable punctuation to prevent any ambiguity. ! 1012: Allocate the new name in `saveable_obstack'. You will have to ! 1013: modify `ASM_OUTPUT_LABELREF' to remove and decode the added text ! 1014: and output the name accordingly, and define `STRIP_NAME_ENCODING' ! 1015: to access the original name string. ! 1016: ! 1017: You can check the information stored here into the `symbol_ref' in ! 1018: the definitions of the macros `GO_IF_LEGITIMATE_ADDRESS' and ! 1019: `PRINT_OPERAND_ADDRESS'. ! 1020: ! 1021: `REG_OK_FOR_BASE_P (X)' ! 1022: A C expression that is nonzero if X (assumed to be a `reg' RTX) is ! 1023: valid for use as a base register. For hard registers, it should ! 1024: always accept those which the hardware permits and reject the ! 1025: others. Whether the macro accepts or rejects pseudo registers ! 1026: must be controlled by `REG_OK_STRICT' as described above. This ! 1027: usually requires two variant definitions, of which `REG_OK_STRICT' ! 1028: controls the one actually used. ! 1029: ! 1030: `REG_OK_FOR_INDEX_P (X)' ! 1031: A C expression that is nonzero if X (assumed to be a `reg' RTX) is ! 1032: valid for use as an index register. ! 1033: ! 1034: The difference between an index register and a base register is ! 1035: that the index register may be scaled. If an address involves the ! 1036: sum of two registers, neither one of them scaled, then either one ! 1037: may be labeled the "base" and the other the "index"; but whichever ! 1038: labeling is used must fit the machine's constraints of which ! 1039: registers may serve in each capacity. The compiler will try both ! 1040: labelings, looking for one that is valid, and will reload one or ! 1041: both registers only if neither labeling works. ! 1042: ! 1043: `LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)' ! 1044: A C compound statement that attempts to replace X with a valid ! 1045: memory address for an operand of mode MODE. WIN will be a C ! 1046: statement label elsewhere in the code; the macro definition may use ! 1047: ! 1048: GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN); ! 1049: ! 1050: to avoid further processing if the address has become legitimate. ! 1051: ! 1052: X will always be the result of a call to `break_out_memory_refs', ! 1053: and OLDX will be the operand that was given to that function to ! 1054: produce X. ! 1055: ! 1056: The code generated by this macro should not alter the substructure ! 1057: of X. If it transforms X into a more legitimate form, it should ! 1058: assign X (which will always be a C variable) a new value. ! 1059: ! 1060: It is not necessary for this macro to come up with a legitimate ! 1061: address. The compiler has standard ways of doing so in all cases. ! 1062: In fact, it is safe for this macro to do nothing. But often a ! 1063: machine-dependent strategy can generate better code. ! 1064: ! 1065: `GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)' ! 1066: A C statement or compound statement with a conditional `goto ! 1067: LABEL;' executed if memory address X (an RTX) can have different ! 1068: meanings depending on the machine mode of the memory reference it ! 1069: is used for or if the address is valid for some modes but not ! 1070: others. ! 1071: ! 1072: Autoincrement and autodecrement addresses typically have ! 1073: mode-dependent effects because the amount of the increment or ! 1074: decrement is the size of the operand being addressed. Some ! 1075: machines have other mode-dependent addresses. Many RISC machines ! 1076: have no mode-dependent addresses. ! 1077: ! 1078: You may assume that ADDR is a valid address for the machine. ! 1079: ! 1080: `LEGITIMATE_CONSTANT_P (X)' ! 1081: A C expression that is nonzero if X is a legitimate constant for ! 1082: an immediate operand on the target machine. You can assume that X ! 1083: satisfies `CONSTANT_P', so you need not check this. In fact, `1' ! 1084: is a suitable definition for this macro on machines where anything ! 1085: `CONSTANT_P' is valid. 1.1 root 1086:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.