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