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