![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-9 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to gcc.info-9 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1: Info file gcc.info, produced by Makeinfo, -*- Text -*- from input
2: file gcc.texinfo.
3:
1.1.1.4 ! root 4: This file documents the use and the internals of the GNU compiler.
1.1 root 5:
1.1.1.4 ! root 6: Copyright (C) 1988, 1989, 1990 Free Software Foundation, Inc.
1.1 root 7:
1.1.1.4 ! root 8: Permission is granted to make and distribute verbatim copies of
! 9: this manual provided the copyright notice and this permission notice
! 10: are preserved on all copies.
1.1 root 11:
1.1.1.4 ! root 12: Permission is granted to copy and distribute modified versions of
1.1 root 13: this manual under the conditions for verbatim copying, provided also
1.1.1.2 root 14: that the sections entitled "GNU General Public License" and "Protect
15: Your Freedom--Fight `Look And Feel'" are included exactly as in the
16: original, and provided that the entire resulting derived work is
17: distributed under the terms of a permission notice identical to this
18: one.
1.1 root 19:
1.1.1.4 ! root 20: Permission is granted to copy and distribute translations of this
1.1 root 21: manual into another language, under the above conditions for modified
1.1.1.2 root 22: versions, except that the sections entitled "GNU General Public
23: License" and "Protect Your Freedom--Fight `Look And Feel'" and this
24: permission notice may be included in translations approved by the
25: Free Software Foundation instead of in the original English.
1.1 root 26:
1.1.1.4 ! root 27:
! 28: File: gcc.info, Node: Registers, Next: Register Classes, Prev: Storage Layout, Up: Machine Macros
! 29:
! 30: Register Usage
! 31: ==============
! 32:
! 33: `FIRST_PSEUDO_REGISTER'
! 34: Number of hardware registers known to the compiler. They
! 35: receive numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the
! 36: first pseudo register's number really is assigned the number
! 37: `FIRST_PSEUDO_REGISTER'.
! 38:
! 39: `FIXED_REGISTERS'
! 40: An initializer that says which registers are used for fixed
! 41: purposes all throughout the compiled code and are therefore not
! 42: available for general allocation. These would include the stack
! 43: pointer, the frame pointer (except on machines where that can be
! 44: used as a general register when no frame pointer is needed), the
! 45: program counter on machines where that is considered one of the
! 46: addressable registers, and any other numbered register with a
! 47: standard use.
! 48:
! 49: This information is expressed as a sequence of numbers,
! 50: separated by commas and surrounded by braces. The Nth number is
! 51: 1 if register N is fixed, 0 otherwise.
! 52:
! 53: The table initialized from this macro, and the table initialized
! 54: by the following one, may be overridden at run time either
! 55: automatically, by the actions of the macro
! 56: `CONDITIONAL_REGISTER_USAGE', or by the user with the command
! 57: options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'.
! 58:
! 59: `CALL_USED_REGISTERS'
! 60: Like `FIXED_REGISTERS' but has 1 for each register that is
! 61: clobbered (in general) by function calls as well as for fixed
! 62: registers. This macro therefore identifies the registers that
! 63: are not available for general allocation of values that must
! 64: live across function calls.
! 65:
! 66: If a register has 0 in `CALL_USED_REGISTERS', the compiler
! 67: automatically saves it on function entry and restores it on
! 68: function exit, if the register is used within the function.
! 69:
! 70: `DEFAULT_CALLER_SAVES'
! 71: Define this macro if function calls on the target machine do not
! 72: preserve any registers; in other words, if `CALL_USED_REGISTERS'
! 73: has 1 for all registers. This macro enables `-fcaller-saves' by
! 74: default. Eventually that option will be enabled by default on
! 75: all machines and both the option and this macro will be
! 76: eliminated.
! 77:
! 78: `CONDITIONAL_REGISTER_USAGE'
! 79: Zero or more C statements that may conditionally modify two
! 80: variables `fixed_regs' and `call_used_regs' (both of type `char
! 81: []') after they have been initialized from the two preceding
! 82: macros.
! 83:
! 84: This is necessary in case the fixed or call-clobbered registers
! 85: depend on target flags.
! 86:
! 87: You need not define this macro if it has no work to do.
! 88:
! 89: If the usage of an entire class of registers depends on the
! 90: target flags, you may indicate this to GCC by using this macro
! 91: to modify `fixed_regs' and `call_used_regs' to 1 for each of the
! 92: registers in the classes which should not be used by GCC. Also
! 93: define the macro `REG_CLASS_FROM_LETTER' to return `NO_REGS' if
! 94: it is called with a letter for a class that shouldn't be used.
! 95:
! 96: (However, if this class is not included in `GENERAL_REGS' and
! 97: all of the insn patterns whose constraints permit this class are
! 98: controlled by target switches, then GCC will automatically avoid
! 99: using these registers when the target switches are opposed to
! 100: them.)
! 101:
! 102: `OVERLAPPING_REGNO_P (REGNO)'
! 103: If defined, this is a C expression whose value is nonzero if
! 104: hard register number REGNO is an overlapping register. This
! 105: means a hard register which overlaps a hard register with a
! 106: different number. (Such overlap is undesirable, but
! 107: occasionally it allows a machine to be supported which otherwise
! 108: could not be.) This macro must return nonzero for *all* the
! 109: registers which overlap each other. GNU CC can use an
! 110: overlapping register only in certain limited ways. It can be
! 111: used for allocation within a basic block, and may be spilled for
! 112: reloading; that is all.
! 113:
! 114: If this macro is not defined, it means that none of the hard
! 115: registers overlap each other. This is the usual situation.
! 116:
! 117: `INSN_CLOBBERS_REGNO_P (INSN, REGNO)'
! 118: If defined, this is a C expression whose value should be nonzero
! 119: if the insn INSN has the effect of mysteriously clobbering the
! 120: contents of hard register number REGNO. By "mysterious" we mean
! 121: that the insn's RTL expression doesn't describe such an effect.
! 122:
! 123: If this macro is not defined, it means that no insn clobbers
! 124: registers mysteriously. This is the usual situation; all else
! 125: being equal, it is best for the RTL expression to show all the
! 126: activity.
! 127:
! 128: `PRESERVE_DEATH_INFO_REGNO_P (REGNO)'
! 129: If defined, this is a C expression whose value is nonzero if
! 130: accurate `REG_DEAD' notes are needed for hard register number
! 131: REGNO at the time of outputting the assembler code. When this
! 132: is so, a few optimizations that take place after register
! 133: allocation and could invalidate the death notes are not done
! 134: when this register is involved.
! 135:
! 136: You would arrange to preserve death info for a register when
! 137: some of the code in the machine description which is executed to
! 138: write the assembler code looks at the death notes. This is
! 139: necessary only when the actual hardware feature which GNU CC
! 140: thinks of as a register is not actually a register of the usual
! 141: sort. (It might, for example, be a hardware stack.)
! 142:
! 143: If this macro is not defined, it means that no death notes need
! 144: to be preserved. This is the usual situation.
! 145:
! 146: `HARD_REGNO_NREGS (REGNO, MODE)'
! 147: A C expression for the number of consecutive hard registers,
! 148: starting at register number REGNO, required to hold a value of
! 149: mode MODE.
! 150:
! 151: On a machine where all registers are exactly one word, a
! 152: suitable definition of this macro is
! 153:
! 154: #define HARD_REGNO_NREGS(REGNO, MODE) \
! 155: ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
! 156: / UNITS_PER_WORD))
! 157:
! 158: `HARD_REGNO_MODE_OK (REGNO, MODE)'
! 159: A C expression that is nonzero if it is permissible to store a
! 160: value of mode MODE in hard register number REGNO (or in several
! 161: registers starting with that one). For a machine where all
! 162: registers are equivalent, a suitable definition is
! 163:
! 164: #define HARD_REGNO_MODE_OK(REGNO, MODE) 1
! 165:
! 166: It is not necessary for this macro to check for the numbers of
! 167: fixed registers, because the allocation mechanism considers them
! 168: to be always occupied.
! 169:
! 170: On some machines, double-precision values must be kept in
! 171: even/odd register pairs. The way to implement that is to define
! 172: this macro to reject odd register numbers for such modes.
! 173:
! 174: GNU CC assumes that it can always move values between registers
! 175: and (suitably addressed) memory locations. If it is impossible
! 176: to move a value of a certain mode between memory and certain
! 177: registers, then `HARD_REGNO_MODE_OK' must not allow this mode in
! 178: those registers.
! 179:
! 180: Many machines have special registers for floating point
! 181: arithmetic. Often people assume that floating point machine
! 182: modes are allowed only in floating point registers. This is not
! 183: true. Any registers that can hold integers can safely *hold* a
! 184: floating point machine mode, whether or not floating arithmetic
! 185: can be done on it in those registers.
! 186:
! 187: On some machines, though, the converse is true: fixed-point
! 188: machine modes may not go in floating registers. This is true if
! 189: the floating registers normalize any value stored in them,
! 190: because storing a non-floating value there would garble it. In
! 191: this case, `HARD_REGNO_MODE_OK' should reject fixed-point
! 192: machine modes in floating registers. But if the floating
! 193: registers do not automatically normalize, if you can store any
! 194: bit pattern in one and retrieve it unchanged without a trap,
! 195: then any machine mode may go in a floating register and this
! 196: macro should say so.
! 197:
! 198: The primary significance of special floating registers is rather
! 199: that they are the registers acceptable in floating point
! 200: arithmetic instructions. However, this is of no concern to
! 201: `HARD_REGNO_MODE_OK'. You handle it by writing the proper
! 202: constraints for those instructions.
! 203:
! 204: On some machines, the floating registers are especially slow to
! 205: access, so that it is better to store a value in a stack frame
! 206: than in such a register if floating point arithmetic is not
! 207: being done. As long as the floating registers are not in class
! 208: `GENERAL_REGS', they will not be used unless some insn's
! 209: constraint asks for one.
! 210:
! 211: `MODES_TIEABLE_P (MODE1, MODE2)'
! 212: A C expression that is nonzero if it is desirable to choose
! 213: register allocation so as to avoid move instructions between a
! 214: value of mode MODE1 and a value of mode MODE2.
! 215:
! 216: If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R,
! 217: MODE2)' are ever different for any R, then `MODES_TIEABLE_P
! 218: (MODE1, MODE2)' must be zero.
! 219:
! 220: `PC_REGNUM'
! 221: If the program counter has a register number, define this as
! 222: that register number. Otherwise, do not define it.
! 223:
! 224: `STACK_POINTER_REGNUM'
! 225: The register number of the stack pointer register, which must
! 226: also be a fixed register according to `FIXED_REGISTERS'. On
! 227: many machines, the hardware determines which register this is.
! 228:
! 229: `FRAME_POINTER_REGNUM'
! 230: The register number of the frame pointer register, which is used
! 231: to access automatic variables in the stack frame. On some
! 232: machines, the hardware determines which register this is. On
! 233: other machines, you can choose any register you wish for this
! 234: purpose.
! 235:
! 236: `FRAME_POINTER_REQUIRED'
! 237: A C expression which is nonzero if a function must have and use
! 238: a frame pointer. This expression is evaluated twice: at the
! 239: beginning of generating RTL, and in the reload pass. If its
! 240: value is nonzero at either time, then the function will have a
! 241: frame pointer.
! 242:
! 243: The expression can in principle examine the current function and
! 244: decide according to the facts, but on most machines the constant
! 245: 0 or the constant 1 suffices. Use 0 when the machine allows
! 246: code to be generated with no frame pointer, and doing so saves
! 247: some time or space. Use 1 when there is no possible advantage
! 248: to avoiding a frame pointer.
! 249:
! 250: In certain cases, the compiler does not know how to produce
! 251: valid code without a frame pointer. The compiler recognizes
! 252: those cases and automatically gives the function a frame pointer
! 253: regardless of what `FRAME_POINTER_REQUIRED' says. You don't
! 254: need to worry about them.
! 255:
! 256: In a function that does not require a frame pointer, the frame
! 257: pointer register can be allocated for ordinary usage, unless you
! 258: mark it as a fixed register. See `FIXED_REGISTERS' for more
! 259: information.
! 260:
! 261: `ARG_POINTER_REGNUM'
! 262: The register number of the arg pointer register, which is used
! 263: to access the function's argument list. On some machines, this
! 264: is the same as the frame pointer register. On some machines,
! 265: the hardware determines which register this is. On other
! 266: machines, you can choose any register you wish for this purpose.
! 267: If this is not the same register as the frame pointer register,
! 268: then you must mark it as a fixed register according to
! 269: `FIXED_REGISTERS'.
! 270:
! 271: `STATIC_CHAIN_REGNUM'
! 272: The register number used for passing a function's static chain
! 273: pointer. This is needed for languages such as Pascal and Algol
! 274: where functions defined within other functions can access the
! 275: local variables of the outer functions; it is not currently used
! 276: because C does not provide this feature, but you must define the
! 277: macro.
! 278:
! 279: The static chain register need not be a fixed register.
! 280:
! 281: `STRUCT_VALUE_REGNUM'
! 282: When a function's value's mode is `BLKmode', the value is not
! 283: returned according to `FUNCTION_VALUE'. Instead, the caller
! 284: passes the address of a block of memory in which the value
! 285: should be stored.
! 286:
! 287: If this value is passed in a register, then
! 288: `STRUCT_VALUE_REGNUM' should be the number of that register.
! 289:
! 290: `STRUCT_VALUE'
! 291: If the structure value address is not passed in a register,
! 292: define `STRUCT_VALUE' as an expression returning an RTX for the
! 293: place where the address is passed. If it returns a `mem' RTX,
! 294: the address is passed as an "invisible" first argument.
! 295:
! 296: `STRUCT_VALUE_INCOMING_REGNUM'
! 297: On some architectures the place where the structure value
! 298: address is found by the called function is not the same place
! 299: that the caller put it. This can be due to register windows, or
! 300: it could be because the function prologue moves it to a
! 301: different place.
! 302:
! 303: If the incoming location of the structure value address is in a
! 304: register, define this macro as the register number.
! 305:
! 306: `STRUCT_VALUE_INCOMING'
! 307: If the incoming location is not a register, define
! 308: `STRUCT_VALUE_INCOMING' as an expression for an RTX for where
! 309: the called function should find the value. If it should find
! 310: the value on the stack, define this to create a `mem' which
! 311: refers to the frame pointer. If the value is a `mem', the
! 312: compiler assumes it is for an invisible first argument, and
! 313: leaves space for it when finding the first real argument.
! 314:
! 315: `REG_ALLOC_ORDER'
! 316: If defined, an initializer for a vector of integers, containing
! 317: the numbers of hard registers in the order in which the GNU CC
! 318: should prefer to use them (from most preferred to least).
! 319:
! 320: If this macro is not defined, registers are used lowest numbered
! 321: first (all else being equal).
! 322:
! 323: One use of this macro is on the 360, where the highest numbered
! 324: registers must always be saved and the save-multiple-registers
! 325: instruction supports only sequences of consecutive registers.
! 326: This macro is defined to cause the highest numbered allocatable
! 327: registers to be used first.
1.1 root 328:
329:
1.1.1.3 root 330: File: gcc.info, Node: Register Classes, Next: Stack Layout, Prev: Registers, Up: Machine Macros
331:
332: Register Classes
333: ================
334:
1.1.1.4 ! root 335: On many machines, the numbered registers are not all equivalent.
! 336: For example, certain registers may not be allowed for indexed
! 337: addressing; certain registers may not be allowed in some
! 338: instructions. These machine restrictions are described to the
! 339: compiler using "register classes".
1.1.1.3 root 340:
1.1.1.4 ! root 341: You define a number of register classes, giving each one a name
! 342: and saying which of the registers belong to it. Then you can specify
1.1.1.3 root 343: register classes that are allowed as operands to particular
344: instruction patterns.
345:
1.1.1.4 ! root 346: In general, each register will belong to several classes. In
! 347: fact, one class must be named `ALL_REGS' and contain all the
! 348: registers. Another class must be named `NO_REGS' and contain no
! 349: registers. Often the union of two classes will be another class;
! 350: however, this is not required.
1.1.1.3 root 351:
1.1.1.4 ! root 352: One of the classes must be named `GENERAL_REGS'. There is nothing
1.1.1.3 root 353: terribly special about the name, but the operand constraint letters
354: `r' and `g' specify this class. If `GENERAL_REGS' is the same as
355: `ALL_REGS', just define it as a macro which expands to `ALL_REGS'.
356:
1.1.1.4 ! root 357: The way classes other than `GENERAL_REGS' are specified in operand
1.1.1.3 root 358: constraints is through machine-dependent operand constraint letters.
359: You can define such letters to correspond to various classes, then
360: use them in operand constraints.
361:
1.1.1.4 ! root 362: You should define a class for the union of two classes whenever
! 363: some instruction allows both classes. For example, if an instruction
1.1.1.3 root 364: allows either a floating-point (coprocessor) register or a general
365: register for a certain operand, you should define a class
366: `FLOAT_OR_GENERAL_REGS' which includes both of them. Otherwise you
367: will get suboptimal code.
368:
1.1.1.4 ! root 369: You must also specify certain redundant information about the
1.1.1.3 root 370: register classes: for each class, which classes contain it and which
371: ones are contained in it; for each pair of classes, the largest class
372: contained in their union.
373:
1.1.1.4 ! root 374: When a value occupying several consecutive registers is expected
! 375: in a certain class, all the registers used must belong to that class.
1.1.1.3 root 376: Therefore, register classes cannot be used to enforce a requirement
377: for a register pair to start with an even-numbered register. The way
378: to specify this requirement is with `HARD_REGNO_MODE_OK'.
379:
1.1.1.4 ! root 380: Register classes used for input-operands of bitwise-and or shift
1.1.1.3 root 381: instructions have a special requirement: each such class must have,
382: for each fixed-point machine mode, a subclass whose registers can
383: transfer that mode to or from memory. For example, on some machines,
384: the operations for single-byte values (`QImode') are limited to
385: certain registers. When this is so, each register class that is used
386: in a bitwise-and or shift instruction must have a subclass consisting
387: of registers from which single-byte values can be loaded or stored.
388: This is so that `PREFERRED_RELOAD_CLASS' can always have a possible
389: value to return.
390:
391: `enum reg_class'
392: An enumeral type that must be defined with all the register
393: class names as enumeral values. `NO_REGS' must be first.
394: `ALL_REGS' must be the last register class, followed by one more
395: enumeral value, `LIM_REG_CLASSES', which is not a register class
396: but rather tells how many classes there are.
397:
398: Each register class has a number, which is the value of casting
399: the class name to type `int'. The number serves as an index in
400: many of the tables described below.
401:
402: `N_REG_CLASSES'
403: The number of distinct register classes, defined as follows:
404:
405: #define N_REG_CLASSES (int) LIM_REG_CLASSES
406:
407: `REG_CLASS_NAMES'
408: An initializer containing the names of the register classes as C
409: string constants. These names are used in writing some of the
410: debugging dumps.
411:
412: `REG_CLASS_CONTENTS'
413: An initializer containing the contents of the register classes,
414: as integers which are bit masks. The Nth integer specifies the
415: contents of class N. The way the integer MASK is interpreted is
416: that register R is in the class if `MASK & (1 << R)' is 1.
417:
418: When the machine has more than 32 registers, an integer does not
419: suffice. Then the integers are replaced by sub-initializers,
420: braced groupings containing several integers. Each
421: sub-initializer must be suitable as an initializer for the type
422: `HARD_REG_SET' which is defined in `hard-reg-set.h'.
423:
424: `REGNO_REG_CLASS (REGNO)'
425: A C expression whose value is a register class containing hard
426: register REGNO. In general there is more that one such class;
427: choose a class which is "minimal", meaning that no smaller class
428: also contains the register.
429:
430: `BASE_REG_CLASS'
431: A macro whose definition is the name of the class to which a
432: valid base register must belong. A base register is one used in
433: an address which is the register value plus a displacement.
434:
435: `INDEX_REG_CLASS'
436: A macro whose definition is the name of the class to which a
437: valid index register must belong. An index register is one used
438: in an address where its value is either multiplied by a scale
439: factor or added to another register (as well as added to a
440: displacement).
441:
442: `REG_CLASS_FROM_LETTER (CHAR)'
443: A C expression which defines the machine-dependent operand
444: constraint letters for register classes. If CHAR is such a
445: letter, the value should be the register class corresponding to
446: it. Otherwise, the value should be `NO_REGS'.
447:
448: `REGNO_OK_FOR_BASE_P (NUM)'
449: A C expression which is nonzero if register number NUM is
450: suitable for use as a base register in operand addresses. It
451: may be either a suitable hard register or a pseudo register that
452: has been allocated such a hard register.
453:
454: `REGNO_OK_FOR_INDEX_P (NUM)'
455: A C expression which is nonzero if register number NUM is
456: suitable for use as an index register in operand addresses. It
457: may be either a suitable hard register or a pseudo register that
458: has been allocated such a hard register.
459:
460: The difference between an index register and a base register is
461: that the index register may be scaled. If an address involves
462: the sum of two registers, neither one of them scaled, then
463: either one may be labeled the "base" and the other the "index";
464: but whichever labeling is used must fit the machine's
465: constraints of which registers may serve in each capacity. The
466: compiler will try both labelings, looking for one that is valid,
467: and will reload one or both registers only if neither labeling
468: works.
469:
470: `PREFERRED_RELOAD_CLASS (X, CLASS)'
471: A C expression that places additional restrictions on the
472: register class to use when it is necessary to copy value X into
473: a register in class CLASS. The value is a register class;
474: perhaps CLASS, or perhaps another, smaller class. On many
475: machines, the definition
476:
477: #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
478:
479: is safe.
480:
481: Sometimes returning a more restrictive class makes better code.
482: For example, on the 68000, when X is an integer constant that is
483: in range for a `moveq' instruction, the value of this macro is
484: always `DATA_REGS' as long as CLASS includes the data registers.
485: Requiring a data register guarantees that a `moveq' will be used.
486:
487: If X is a `const_double', by returning `NO_REGS' you can force X
488: into a memory constant. This is useful on certain machines
489: where immediate floating values cannot be loaded into certain
490: kinds of registers.
491:
492: In a shift instruction or a bitwise-and instruction, the mode of
493: X, the value being reloaded, may not be the same as the mode of
494: the instruction's operand. (They will both be fixed-point
495: modes, however.) In such a case, CLASS may not be a safe value
496: to return. CLASS is certainly valid for the instruction, but it
497: may not be valid for reloading X. This problem can occur on
498: machines such as the 68000 and 80386 where some registers can
499: handle full-word values but cannot handle single-byte values.
500:
501: On such machines, this macro must examine the mode of X and
502: return a subclass of CLASS which can handle loads and stores of
503: that mode. On the 68000, where address registers cannot handle
504: `QImode', if X has `QImode' then you must return `DATA_REGS'.
505: If CLASS is `ADDR_REGS', then there is no correct value to
506: return; but the shift and bitwise-and instructions don't use
507: `ADDR_REGS', so this fatal case never arises.
508:
509: `CLASS_MAX_NREGS (CLASS, MODE)'
510: A C expression for the maximum number of consecutive registers
511: of class CLASS needed to hold a value of mode MODE.
512:
513: This is closely related to the macro `HARD_REGNO_NREGS'. In
514: fact, the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)'
515: should be the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)'
516: for all REGNO values in the class CLASS.
517:
518: This macro helps control the handling of multiple-word values in
519: the reload pass.
520:
1.1.1.4 ! root 521: Two other special macros describe which constants fit which
1.1.1.3 root 522: constraint letters.
523:
524: `CONST_OK_FOR_LETTER_P (VALUE, C)'
525: A C expression that defines the machine-dependent operand
526: constraint letters that specify particular ranges of integer
527: values. If C is one of those letters, the expression should
528: check that VALUE, an integer, is in the appropriate range and
529: return 1 if so, 0 otherwise. If C is not one of those letters,
530: the value should be 0 regardless of VALUE.
531:
532: `CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)'
533: A C expression that defines the machine-dependent operand
534: constraint letters that specify particular ranges of floating
535: values. If C is one of those letters, the expression should
536: check that VALUE, an RTX of code `const_double', is in the
537: appropriate range and return 1 if so, 0 otherwise. If C is not
538: one of those letters, the value should be 0 regardless of VALUE.
539:
540:
1.1.1.4 ! root 541: File: gcc.info, Node: Stack Layout, Next: Library Calls, Prev: Register Classes, Up: Machine Macros
1.1 root 542:
543: Describing Stack Layout
544: =======================
545:
546: `STACK_GROWS_DOWNWARD'
547: Define this macro if pushing a word onto the stack moves the
548: stack pointer to a smaller address.
549:
1.1.1.2 root 550: When we say, "define this macro if ...," it means that the
1.1 root 551: compiler checks this macro only with `#ifdef' so the precise
552: definition used does not matter.
553:
554: `FRAME_GROWS_DOWNWARD'
555: Define this macro if the addresses of local variable slots are
556: at negative offsets from the frame pointer.
557:
558: `STARTING_FRAME_OFFSET'
559: Offset from the frame pointer to the first local variable slot
560: to be allocated.
561:
562: If `FRAME_GROWS_DOWNWARD', the next slot's offset is found by
563: subtracting the length of the first slot from
564: `STARTING_FRAME_OFFSET'. Otherwise, it is found by adding the
565: length of the first slot to the value `STARTING_FRAME_OFFSET'.
566:
567: `PUSH_ROUNDING (NPUSHED)'
568: A C expression that is the number of bytes actually pushed onto
569: the stack when an instruction attempts to push NPUSHED bytes.
570:
571: If the target machine does not have a push instruction, do not
572: define this macro. That directs GNU CC to use an alternate
573: strategy: to allocate the entire argument block and then store
574: the arguments into it.
575:
576: On some machines, the definition
577:
578: #define PUSH_ROUNDING(BYTES) (BYTES)
579:
580: will suffice. But on other machines, instructions that appear
581: to push one byte actually push two bytes in an attempt to
582: maintain alignment. Then the definition should be
583:
584: #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
585:
586: `FIRST_PARM_OFFSET (FUNDECL)'
587: Offset from the argument pointer register to the first
588: argument's address. On some machines it may depend on the data
589: type of the function. (In the next version of GNU CC, the
590: argument will be changed to the function data type rather than
591: its declaration.)
592:
593: `FIRST_PARM_CALLER_OFFSET (FUNDECL)'
594: Define this macro on machines where register parameters have
595: shadow locations on the stack, at addresses below the nominal
596: parameter. This matters because certain arguments cannot be
597: passed on the stack. On these machines, such arguments must be
598: stored into the shadow locations.
599:
600: This macro should expand into a C expression whose value is the
601: offset of the first parameter's shadow location from the nominal
602: stack pointer value. (That value is itself computed by adding
603: the value of `STACK_POINTER_OFFSET' to the stack pointer
604: register.)
605:
606: `REG_PARM_STACK_SPACE'
607: Define this macro if functions should assume that stack space
608: has been allocated for arguments even when their values are
609: passed in registers.
610:
611: The actual allocation of such space would be done either by the
612: call instruction or by the function prologue, or by defining
1.1.1.2 root 613: `FIRST_PARM_CALLER_OFFSET'.
1.1 root 614:
615: `STACK_ARGS_ADJUST (SIZE)'
616: Define this macro if the machine requires padding on the stack
617: for certain function calls. This is padding on a
618: per-function-call basis, not padding for individual arguments.
619:
620: The argument SIZE will be a C variable of type `struct arg_data'
621: which contains two fields, an integer named `constant' and an
622: RTX named `var'. These together represent a size measured in
623: bytes which is the sum of the integer and the RTX. Most of the
624: time `var' is 0, which means that the size is simply the integer.
625:
626: The definition should be a C statement or compound statement
627: which alters the variable supplied in whatever way you wish.
628:
629: Note that the value you leave in the variable `size' will
630: ultimately be rounded up to a multiple of `STACK_BOUNDARY' bits.
631:
632: This macro is not fully implemented for machines which have push
633: instructions (i.e., on which `PUSH_ROUNDING' is defined).
634:
635: `RETURN_POPS_ARGS (FUNTYPE)'
636: A C expression that should be 1 if a function pops its own
637: arguments on returning, or 0 if the function pops no arguments
638: and the caller must therefore pop them all after the function
639: returns.
640:
641: FUNTYPE is a C variable whose value is a tree node that
642: describes the function in question. Normally it is a node of
643: type `FUNCTION_TYPE' that describes the data type of the function.
644: From this it is possible to obtain the data types of the value
645: and arguments (if known).
646:
647: When a call to a library function is being considered, FUNTYPE
648: will contain an identifier node for the library function. Thus,
649: if you need to distinguish among various library functions, you
1.1.1.2 root 650: can do so by their names. Note that "library function" in this
651: context means a function used to perform arithmetic, whose name
652: is known specially in the compiler and was not mentioned in the
653: C code being compiled.
1.1 root 654:
655: On the Vax, all functions always pop their arguments, so the
656: definition of this macro is 1. On the 68000, using the standard
657: calling convention, no functions pop their arguments, so the
658: value of the macro is always 0 in this case. But an alternative
659: calling convention is available in which functions that take a
660: fixed number of arguments pop them but other functions (such as
661: `printf') pop nothing (the caller pops all). When this
662: convention is in use, FUNTYPE is examined to determine whether a
663: function takes a fixed number of arguments.
664:
1.1.1.2 root 665: When this macro returns nonzero, the macro
666: `FRAME_POINTER_REQUIRED' must also return nonzero for proper
667: operation.
668:
1.1 root 669: `FUNCTION_VALUE (VALTYPE, FUNC)'
670: A C expression to create an RTX representing the place where a
671: function returns a value of data type VALTYPE. VALTYPE is a
672: tree node representing a data type. Write `TYPE_MODE (VALTYPE)'
673: to get the machine mode used to represent that type. On many
674: machines, only the mode is relevant. (Actually, on most
675: machines, scalar values are returned in the same place
676: regardless of mode).
677:
678: If the precise function being called is known, FUNC is a tree
679: node (`FUNCTION_DECL') for it; otherwise, FUNC is a null
680: pointer. This makes it possible to use a different
681: value-returning convention for specific functions when all their
682: calls are known.
683:
684: `FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)'
1.1.1.2 root 685: Define this macro if the target machine has "register windows"
1.1 root 686: so that the register in which a function returns its value is
687: not the same as the one in which the caller sees the value.
688:
689: For such machines, `FUNCTION_VALUE' computes the register in
690: which the caller will see the value, and
691: `FUNCTION_OUTGOING_VALUE' should be defined in a similar fashion
692: to tell the function where to put the value.
693:
694: If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE'
695: serves both purposes.
696:
697: `RETURN_IN_MEMORY (TYPE)'
698: A C expression which can inhibit the returning of certain
699: function values in registers, based on the type of value. A
700: nonzero value says to return the function value in memory, just
701: as large structures are always returned. Here TYPE will be a C
702: expression of type `tree', representing the data type of the
703: value.
704:
705: Note that values of mode `BLKmode' are returned in memory
706: regardless of this macro. Also, the option
707: `-fpcc-struct-return' takes effect regardless of this macro. On
708: most systems, it is possible to leave the macro undefined; this
709: causes a default definition to be used, whose value is the
710: constant 0.
711:
712: `LIBCALL_VALUE (MODE)'
713: A C expression to create an RTX representing the place where a
714: library function returns a value of mode MODE. If the precise
715: function being called is known, FUNC is a tree node
716: (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer.
717: This makes it possible to use a different value-returning
718: convention for specific functions when all their calls are known.
719:
1.1.1.2 root 720: Note that "library function" in this context means a compiler
1.1 root 721: support routine, used to perform arithmetic, whose name is known
722: specially by the compiler and was not mentioned in the C code
723: being compiled.
724:
725: `FUNCTION_VALUE_REGNO_P (REGNO)'
726: A C expression that is nonzero if REGNO is the number of a hard
727: register in which the values of called function may come back.
728:
729: A register whose use for returning values is limited to serving
730: as the second of a pair (for a value of type `double', say) need
731: not be recognized by this macro. So for most machines, this
732: definition suffices:
733:
734: #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
735:
736: If the machine has register windows, so that the caller and the
737: called function use different registers for the return value,
738: this macro should recognize only the caller's register numbers.
739:
740: `FUNCTION_ARG (CUM, MODE, TYPE, NAMED)'
741: A C expression that controls whether a function argument is
742: passed in a register, and which register.
743:
744: The arguments are CUM, which summarizes all the previous
745: arguments; MODE, the machine mode of the argument; TYPE, the
746: data type of the argument as a tree node or 0 if that is not
747: known (which happens for C support library functions); and
748: NAMED, which is 1 for an ordinary argument and 0 for nameless
749: arguments that correspond to `...' in the called function's
750: prototype.
751:
752: The value of the expression should either be a `reg' RTX for the
753: hard register in which to pass the argument, or zero to pass the
754: argument on the stack.
755:
756: For the Vax and 68000, where normally all arguments are pushed,
757: zero suffices as a definition.
758:
759: The usual way to make the ANSI library `stdarg.h' work on a
760: machine where some arguments are usually passed in registers, is
761: to cause nameless arguments to be passed on the stack instead.
762: This is done by making `FUNCTION_ARG' return 0 whenever NAMED is
763: 0.
764:
765: `FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)'
1.1.1.2 root 766: Define this macro if the target machine has "register windows",
767: so that the register in which a function sees an arguments is
768: not necessarily the same as the one in which the caller passed
769: the argument.
1.1 root 770:
771: For such machines, `FUNCTION_ARG' computes the register in which
772: the caller passes the value, and `FUNCTION_INCOMING_ARG' should
773: be defined in a similar fashion to tell the function being
774: called where the arguments will arrive.
775:
776: If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
777: both purposes.
778:
779: `FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)'
780: A C expression for the number of words, at the beginning of an
781: argument, must be put in registers. The value must be zero for
782: arguments that are passed entirely in registers or that are
783: entirely pushed on the stack.
784:
785: On some machines, certain arguments must be passed partially in
786: registers and partially in memory. On these machines, typically
787: the first N words of arguments are passed in registers, and the
788: rest on the stack. If a multi-word argument (a `double' or a
789: structure) crosses that boundary, its first few words must be
790: passed in registers and the rest must be pushed. This macro
791: tells the compiler when this occurs, and how many of the words
792: should go in registers.
793:
794: `FUNCTION_ARG' for these arguments should return the first
795: register to be used by the caller for this argument; likewise
796: `FUNCTION_INCOMING_ARG', for the called function.
797:
798: `CUMULATIVE_ARGS'
799: A C type for declaring a variable that is used as the first
800: argument of `FUNCTION_ARG' and other related values. For some
801: target machines, the type `int' suffices and can hold the number
802: of bytes of argument so far.
803:
804: `INIT_CUMULATIVE_ARGS (CUM, FNTYPE)'
805: A C statement (sans semicolon) for initializing the variable CUM
806: for the state at the beginning of the argument list. The
807: variable has type `CUMULATIVE_ARGS'. The value of FNTYPE is the
808: tree node for the data type of the function which will receive
809: the args, or 0 if the args are to a compiler support library
810: function.
811:
812: `FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)'
813: A C statement (sans semicolon) to update the summarizer variable
814: CUM to advance past an argument in the argument list. The
815: values MODE, TYPE and NAMED describe that argument. Once this
816: is done, the variable CUM is suitable for analyzing the
817: *following* argument with `FUNCTION_ARG', etc.
818:
819: `FUNCTION_ARG_REGNO_P (REGNO)'
820: A C expression that is nonzero if REGNO is the number of a hard
821: register in which function arguments are sometimes passed. This
822: does *not* include implicit arguments such as the static chain
823: and the structure-value address. On many machines, no registers
824: can be used for this purpose since all function arguments are
825: pushed on the stack.
826:
827: `FUNCTION_ARG_PADDING (MODE, SIZE)'
828: If defined, a C expression which determines whether, and in
829: which direction, to pad out an argument with extra space. The
830: value should be of type `enum direction': either `upward' to pad
831: above the argument, `downward' to pad below, or `none' to
832: inhibit padding.
833:
834: The argument SIZE is an RTX which describes the size of the
835: argument, in bytes. It should be used only if MODE is
836: `BLKmode'. Otherwise, SIZE is 0.
837:
838: This macro does not control the *amount* of padding; that is
839: always just enough to reach the next multiple of `PARM_BOUNDARY'.
840:
841: This macro has a default definition which is right for most
842: systems. For little-endian machines, the default is to pad
843: upward. For big-endian machines, the default is to pad downward
844: for an argument of constant size shorter than an `int', and
845: upward otherwise.
846:
847: `FUNCTION_PROLOGUE (FILE, SIZE)'
848: A C compound statement that outputs the assembler code for entry
849: to a function. The prologue is responsible for setting up the
850: stack frame, initializing the frame pointer register, saving
851: registers that must be saved, and allocating SIZE additional
852: bytes of storage for the local variables. SIZE is an integer.
853: FILE is a stdio stream to which the assembler code should be
854: output.
855:
856: The label for the beginning of the function need not be output
857: by this macro. That has already been done when the macro is run.
858:
859: To determine which registers to save, the macro can refer to the
860: array `regs_ever_live': element R is nonzero if hard register R
861: is used anywhere within the function. This implies the function
862: prologue should save register R, but not if it is one of the
863: call-used registers.
864:
865: On machines where functions may or may not have frame-pointers,
866: the function entry code must vary accordingly; it must set up
867: the frame pointer if one is wanted, and not otherwise. To
868: determine whether a frame pointer is in wanted, the macro can
869: refer to the variable `frame_pointer_needed'. The variable's
870: value will be 1 at run time in a function that needs a frame
871: pointer.
872:
1.1.1.2 root 873: On machines where an argument may be passed partly in registers
874: and partly in memory, this macro must examine the variable
1.1 root 875: `current_function_pretend_args_size', and allocate that many
876: bytes of uninitialized space on the stack just underneath the
877: first argument arriving on the stack. (This may not be at the
878: very end of the stack, if the calling sequence has pushed
879: anything else since pushing the stack arguments. But usually,
880: on such machines, nothing else has been pushed yet, because the
881: function prologue itself does all the pushing.)
882:
883: `FUNCTION_PROFILER (FILE, LABELNO)'
884: A C statement or compound statement to output to FILE some
885: assembler code to call the profiling subroutine `mcount'.
886: Before calling, the assembler code must load the address of a
887: counter variable into a register where `mcount' expects to find
888: the address. The name of this variable is `LP' followed by the
889: number LABELNO, so you would generate the name using `LP%d' in a
890: `fprintf'.
891:
892: The details of how the address should be passed to `mcount' are
893: determined by your operating system environment, not by GNU CC.
894: To figure them out, compile a small program for profiling using
895: the system's installed C compiler and look at the assembler code
896: that results.
897:
898: `FUNCTION_BLOCK_PROFILER (FILE, LABELNO)'
899: A C statement or compound statement to output to FILE some
900: assembler code to initialize basic-block profiling for the
901: current object module. This code should call the subroutine
902: `__bb_init_func' once per object module, passing it as its sole
903: argument the address of a block allocated in the object module.
904:
905: The name of the block is a local symbol made with this statement:
906:
907: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0);
908:
909: Of course, since you are writing the definition of
910: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you
911: can take a short cut in the definition of this macro and use the
912: name that you know will result.
913:
914: The first word of this block is a flag which will be nonzero if
915: the object module has already been initialized. So test this
916: word first, and do not call `__bb_init_func' if the flag is
917: nonzero.
918:
919: `BLOCK_PROFILER (FILE, BLOCKNO)'
920: A C statement or compound statement to increment the count
921: associated with the basic block number BLOCKNO. Basic blocks
922: are numbered separately from zero within each compilation. The
923: count associated with block number BLOCKNO is at index BLOCKNO
924: in a vector of words; the name of this array is a local symbol
925: made with this statement:
926:
927: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2);
928:
929: Of course, since you are writing the definition of
930: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you
931: can take a short cut in the definition of this macro and use the
932: name that you know will result.
933:
1.1.1.2 root 934: `EXIT_IGNORE_STACK'
1.1 root 935: Define this macro as a C expression that is nonzero if the
936: return instruction or the function epilogue ignores the value of
937: the stack pointer; in other words, if it is safe to delete an
938: instruction to adjust the stack pointer before a return from the
939: function.
940:
941: Note that this macro's value is relevant only for functions for
942: which frame pointers are maintained. It is never safe to delete
943: a final stack adjustment in a function that has no frame
944: pointer, and the compiler knows this regardless of
1.1.1.2 root 945: `EXIT_IGNORE_STACK'.
1.1 root 946:
947: `FUNCTION_EPILOGUE (FILE, SIZE)'
948: A C compound statement that outputs the assembler code for exit
949: from a function. The epilogue is responsible for restoring the
950: saved registers and stack pointer to their values when the
951: function was called, and returning control to the caller. This
952: macro takes the same arguments as the macro `FUNCTION_PROLOGUE',
953: and the registers to restore are determined from
954: `regs_ever_live' and `CALL_USED_REGISTERS' in the same way.
955:
956: On some machines, there is a single instruction that does all
957: the work of returning from the function. On these machines,
958: give that instruction the name `return' and do not define the
959: macro `FUNCTION_EPILOGUE' at all.
960:
961: Do not define a pattern named `return' if you want the
962: `FUNCTION_EPILOGUE' to be used. If you want the target switches
963: to control whether return instructions or epilogues are used,
964: define a `return' pattern with a validity condition that tests
965: the target switches appropriately. If the `return' pattern's
966: validity condition is false, epilogues will be used.
967:
968: On machines where functions may or may not have frame-pointers,
969: the function exit code must vary accordingly. Sometimes the
970: code for these two cases is completely different. To determine
971: whether a frame pointer is in wanted, the macro can refer to the
972: variable `frame_pointer_needed'. The variable's value will be 1
973: at run time in a function that needs a frame pointer.
974:
975: On some machines, some functions pop their arguments on exit
976: while others leave that for the caller to do. For example, the
977: 68020 when given `-mrtd' pops arguments in functions that take a
978: fixed number of arguments.
979:
980: Your definition of the macro `RETURN_POPS_ARGS' decides which
981: functions pop their own arguments. `FUNCTION_EPILOGUE' needs to
982: know what was decided. The variable
983: `current_function_pops_args' is nonzero if the function should
984: pop its own arguments. If so, use the variable
985: `current_function_args_size' as the number of bytes to pop.
986:
987: `FIX_FRAME_POINTER_ADDRESS (ADDR, DEPTH)'
988: A C compound statement to alter a memory address that uses the
989: frame pointer register so that it uses the stack pointer
990: register instead. This must be done in the instructions that
991: load parameter values into registers, when the reload pass
992: determines that a frame pointer is not necessary for the
993: function. ADDR will be a C variable name, and the updated
994: address should be stored in that variable. DEPTH will be the
995: current depth of stack temporaries (number of bytes of arguments
996: currently pushed). The change in offset between a
997: frame-pointer-relative address and a stack-pointer-relative
998: address must include DEPTH.
999:
1000: Even if your machine description specifies there will always be
1001: a frame pointer in the frame pointer register, you must still
1002: define `FIX_FRAME_POINTER_ADDRESS', but the definition will
1003: never be executed at run time, so it may be empty.
1004:
1005: `LONGJMP_RESTORE_FROM_STACK'
1006: Define this macro if the `longjmp' function restores registers
1007: from the stack frames, rather than from those saved specifically
1008: by `setjmp'. Certain quantities must not be kept in registers
1009: across a call to `setjmp' on such machines.
1010:
1011:
1.1.1.4 ! root 1012: File: gcc.info, Node: Library Calls, Next: Addressing Modes, Prev: Stack Layout, Up: Machine Macros
1.1 root 1013:
1.1.1.4 ! root 1014: Implicit Use of Library Routines
! 1015: ================================
1.1 root 1016:
1017: `MULSI3_LIBCALL'
1018: A C string constant giving the name of the function to call for
1019: multiplication of one signed full-word by another. If you do
1020: not define this macro, the default name is used, which is
1021: `__mulsi3', a function defined in `gnulib'.
1022:
1023: `UMULSI3_LIBCALL'
1024: A C string constant giving the name of the function to call for
1025: multiplication of one unsigned full-word by another. If you do
1026: not define this macro, the default name is used, which is
1027: `__umulsi3', a function defined in `gnulib'.
1028:
1029: `DIVSI3_LIBCALL'
1030: A C string constant giving the name of the function to call for
1031: division of one signed full-word by another. If you do not
1032: define this macro, the default name is used, which is
1033: `__divsi3', a function defined in `gnulib'.
1034:
1035: `UDIVSI3_LIBCALL'
1036: A C string constant giving the name of the function to call for
1037: division of one unsigned full-word by another. If you do not
1038: define this macro, the default name is used, which is
1039: `__udivsi3', a function defined in `gnulib'.
1040:
1041: `MODSI3_LIBCALL'
1042: A C string constant giving the name of the function to call for
1043: the remainder in division of one signed full-word by another.
1044: If you do not define this macro, the default name is used, which
1045: is `__modsi3', a function defined in `gnulib'.
1046:
1047: `UMODSI3_LIBCALL'
1048: A C string constant giving the name of the function to call for
1049: the remainder in division of one unsigned full-word by another.
1050: If you do not define this macro, the default name is used, which
1051: is `__umodsi3', a function defined in `gnulib'.
1052:
1053: `TARGET_MEM_FUNCTIONS'
1054: Define this macro if GNU CC should generate calls to the System
1055: V (and ANSI C) library functions `memcpy' and `memset' rather
1056: than the BSD functions `bcopy' and `bzero'.
1057:
1.1.1.4 ! root 1058: `GNULIB_NEEDS_DOUBLE'
! 1059: Define this macro if only `float' arguments cannot be passed to
! 1060: library routines (so they must be converted to `double'). This
! 1061: macro affects both how library calls are generated and how the
! 1062: library routines in `gnulib.c' accept their arguments. It is
! 1063: useful on machines where floating and fixed point arguments are
! 1064: passed differently, such as the i860.
1.1 root 1065:
1.1.1.4 ! root 1066:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.