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