![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-13 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-13 CVS log | Up to [GCC 2.x] / gcc |
1.1 root 1: This is Info file gcc.info, produced by Makeinfo-1.43 from the input
2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
6: Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc.
7:
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.
11:
12: Permission is granted to copy and distribute modified versions of
13: this manual under the conditions for verbatim copying, provided also
14: that the section entitled "GNU General Public License" is included
15: exactly as in the original, and provided that the entire resulting
16: derived work is distributed under the terms of a permission notice
17: identical to this one.
18:
19: Permission is granted to copy and distribute translations of this
20: manual into another language, under the above conditions for modified
21: versions, except that the section entitled "GNU General Public
22: License" and this permission notice may be included in translations
23: approved by the Free Software Foundation instead of in the original
24: English.
25:
26:
27: File: gcc.info, Node: Frame Registers, Next: Elimination, Prev: Frame Layout, Up: Stack and Calling
28:
29: Registers That Address the Stack Frame
30: --------------------------------------
31:
32: `STACK_POINTER_REGNUM'
33: The register number of the stack pointer register, which must
34: also be a fixed register according to `FIXED_REGISTERS'. On most
35: machines, the hardware determines which register this is.
36:
37: `FRAME_POINTER_REGNUM'
38: The register number of the frame pointer register, which is used
39: to access automatic variables in the stack frame. On some
40: machines, the hardware determines which register this is. On
41: other machines, you can choose any register you wish for this
42: purpose.
43:
44: `ARG_POINTER_REGNUM'
45: The register number of the arg pointer register, which is used to
46: access the function's argument list. On some machines, this is
47: the same as the frame pointer register. On some machines, the
48: hardware determines which register this is. On other machines,
49: you can choose any register you wish for this purpose. If this
50: is not the same register as the frame pointer register, then you
51: must mark it as a fixed register according to `FIXED_REGISTERS',
52: or arrange to be able to eliminate it (*note Elimination::.).
53:
54: `STATIC_CHAIN_REGNUM'
55: `STATIC_CHAIN_INCOMING_REGNUM'
56: Register numbers used for passing a function's static chain
57: pointer. If register windows are used,
58: `STATIC_CHAIN_INCOMING_REGNUM' is the register number as seen by
59: the called function, while `STATIC_CHAIN_REGNUM' is the register
60: number as seen by the calling function. If these registers are
61: the same, `STATIC_CHAIN_INCOMING_REGNUM' need not be defined.
62:
63: The static chain register need not be a fixed register.
64:
65: If the static chain is passed in memory, these macros should not
66: be defined; instead, the next two macros should be defined.
67:
68: `STATIC_CHAIN'
69: `STATIC_CHAIN_INCOMING'
70: If the static chain is passed in memory, these macros provide rtx
71: giving `mem' expressions that denote where they are stored.
72: `STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as
73: seen by the calling and called functions, respectively. Often
74: the former will be at an offset from the stack pointer and the
75: latter at an offset from the frame pointer.
76:
77: The variables `stack_pointer_rtx', `frame_pointer_rtx', and
78: `arg_pointer_rtx' will have been initialized prior to the use of
79: these macros and should be used to refer to those items.
80:
81: If the static chain is passed in a register, the two previous
82: macros should be defined instead.
83:
84:
85: File: gcc.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling
86:
87: Eliminating Frame Pointer and Arg Pointer
88: -----------------------------------------
89:
90: `FRAME_POINTER_REQUIRED'
91: A C expression which is nonzero if a function must have and use a
92: frame pointer. This expression is evaluated in the reload pass.
93: If its value is nonzero the function will have a frame pointer.
94:
95: The expression can in principle examine the current function and
96: decide according to the facts, but on most machines the constant
97: 0 or the constant 1 suffices. Use 0 when the machine allows code
98: to be generated with no frame pointer, and doing so saves some
99: time or space. Use 1 when there is no possible advantage to
100: avoiding a frame pointer.
101:
102: In certain cases, the compiler does not know how to produce valid
103: code without a frame pointer. The compiler recognizes those
104: cases and automatically gives the function a frame pointer
105: regardless of what `FRAME_POINTER_REQUIRED' says. You don't need
106: to worry about them.
107:
108: In a function that does not require a frame pointer, the frame
109: pointer register can be allocated for ordinary usage, unless you
110: mark it as a fixed register. See `FIXED_REGISTERS' for more
111: information.
112:
113: This macro is ignored and need not be defined if `ELIMINABLE_REGS'
114: is defined.
115:
116: `INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)'
117: A C statement to store in the variable DEPTH-VAR the difference
118: between the frame pointer and the stack pointer values
119: immediately after the function prologue. The value would be
120: computed from information such as the result of `get_frame_size
121: ()' and the tables of registers `regs_ever_live' and
122: `call_used_regs'.
123:
124: If `ELIMINABLE_REGS' is defined, this macro will be not be used
125: and need not be defined. Otherwise, it must be defined even if
126: `FRAME_POINTER_REQUIRED' is defined to always be true; in that
127: case, you may set DEPTH-VAR to anything.
128:
129: `ELIMINABLE_REGS'
130: If defined, this macro specifies a table of register pairs used to
131: eliminate unneeded registers that point into the stack frame. If
132: it is not defined, the only elimination attempted by the compiler
133: is to replace references to the frame pointer with references to
134: the stack pointer.
135:
136: The definition of this macro is a list of structure
137: initializations, each of which specifies an original and
138: replacement register.
139:
140: On some machines, the position of the argument pointer is not
141: known until the compilation is completed. In such a case, a
142: separate hard register must be used for the argument pointer.
143: This register can be eliminated by replacing it with either the
144: frame pointer or the argument pointer, depending on whether or
145: not the frame pointer has been eliminated.
146:
147: In this case, you might specify:
148: #define ELIMINABLE_REGS \
149: {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
150: {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
151: {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
152:
153: Note that the elimination of the argument pointer with the stack
154: pointer is specified first since that is the preferred
155: elimination.
156:
157: `CAN_ELIMINATE (FROM-REG, TO-REG)'
158: A C expression that returns non-zero if the compiler is allowed
159: to try to replace register number FROM-REG with register number
160: TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is
161: defined, and will usually be the constant 1, since most of the
162: cases preventing register elimination are things that the
163: compiler already knows about.
164:
165: `INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)'
166: This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It
167: specifies the initial difference between the specified pair of
168: registers. This macro must be defined if `ELIMINABLE_REGS' is
169: defined.
170:
171: `LONGJMP_RESTORE_FROM_STACK'
172: Define this macro if the `longjmp' function restores registers
173: from the stack frames, rather than from those saved specifically
174: by `setjmp'. Certain quantities must not be kept in registers
175: across a call to `setjmp' on such machines.
176:
177:
178: File: gcc.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling
179:
180: Passing Function Arguments on the Stack
181: ---------------------------------------
182:
183: The macros in this section control how arguments are passed on the
184: stack. See the following section for other macros that control
185: passing certain arguments in registers.
186:
187: `PROMOTE_PROTOTYPES'
188: Define this macro if an argument declared as `char' or `short' in
189: a prototype should actually be passed as an `int'. In addition
190: to avoiding errors in certain cases of mismatch, it also makes
191: for better code on certain machines.
192:
193: `PUSH_ROUNDING (NPUSHED)'
194: A C expression that is the number of bytes actually pushed onto
195: the stack when an instruction attempts to push NPUSHED bytes.
196:
197: If the target machine does not have a push instruction, do not
198: define this macro. That directs GNU CC to use an alternate
199: strategy: to allocate the entire argument block and then store
200: the arguments into it.
201:
202: On some machines, the definition
203:
204: #define PUSH_ROUNDING(BYTES) (BYTES)
205:
206: will suffice. But on other machines, instructions that appear to
207: push one byte actually push two bytes in an attempt to maintain
208: alignment. Then the definition should be
209:
210: #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
211:
212: `ACCUMULATE_OUTGOING_ARGS'
213: If defined, the maximum amount of space required for outgoing
214: arguments will be computed and placed into the variable
215: `current_function_outgoing_args_size'. No space will be pushed
216: onto the stack for each call; instead, the function prologue
217: should increase the stack frame size by this amount.
218:
219: It is not proper to define both `PUSH_ROUNDING' and
220: `ACCUMULATE_OUTGOING_ARGS'.
221:
222: `REG_PARM_STACK_SPACE'
223: Define this macro if functions should assume that stack space has
224: been allocated for arguments even when their values are passed in
225: registers.
226:
227: The value of this macro is the size, in bytes, of the area
228: reserved for arguments passed in registers.
229:
230: This space can either be allocated by the caller or be a part of
231: the machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE'
232: says which.
233:
234: `OUTGOING_REG_PARM_STACK_SPACE'
235: Define this if it is the responsibility of the caller to allocate
236: the area reserved for arguments passed in registers.
237:
238: If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls
239: whether the space for these arguments counts in the value of
240: `current_function_outgoing_args_size'.
241:
242: `STACK_PARMS_IN_REG_PARM_AREA'
243: Define this macro if `REG_PARM_STACK_SPACE' is defined but stack
244: parameters don't skip the area specified by
245: `REG_PARM_STACK_SPACE'.
246:
247: Normally, when a parameter is not passed in registers, it is
248: placed on the stack beyond the `REG_PARM_STACK_SPACE' area.
249: Defining this macro suppresses this behavior and causes the
250: parameter to be passed on the stack in its natural location.
251:
252: `RETURN_POPS_ARGS (FUNTYPE, STACK-SIZE)'
253: A C expression that should indicate the number of bytes of its own
254: arguments that a function pops on returning, or 0 if the function
255: pops no arguments and the caller must therefore pop them all
256: after the function returns.
257:
258: FUNTYPE is a C variable whose value is a tree node that describes
259: the function in question. Normally it is a node of type
260: `FUNCTION_TYPE' that describes the data type of the function.
261: From this it is possible to obtain the data types of the value and
262: arguments (if known).
263:
264: When a call to a library function is being considered, FUNTYPE
265: will contain an identifier node for the library function. Thus,
266: if you need to distinguish among various library functions, you
267: can do so by their names. Note that "library function" in this
268: context means a function used to perform arithmetic, whose name
269: is known specially in the compiler and was not mentioned in the C
270: code being compiled.
271:
272: STACK-SIZE is the number of bytes of arguments passed on the
273: stack. If a variable number of bytes is passed, it is zero, and
274: argument popping will always be the responsibility of the calling
275: function.
276:
277: On the Vax, all functions always pop their arguments, so the
278: definition of this macro is STACK-SIZE. On the 68000, using the
279: standard calling convention, no functions pop their arguments, so
280: the value of the macro is always 0 in this case. But an
281: alternative calling convention is available in which functions
282: that take a fixed number of arguments pop them but other
283: functions (such as `printf') pop nothing (the caller pops all).
284: When this convention is in use, FUNTYPE is examined to determine
285: whether a function takes a fixed number of arguments.
286:
287:
288: File: gcc.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling
289:
290: Passing Arguments in Registers
291: ------------------------------
292:
293: This section describes the macros which let you control how various
294: types of arguments are passed in registers or how they are arranged in
295: the stack.
296:
297: `FUNCTION_ARG (CUM, MODE, TYPE, NAMED)'
298: A C expression that controls whether a function argument is passed
299: in a register, and which register.
300:
301: The arguments are CUM, which summarizes all the previous
302: arguments; MODE, the machine mode of the argument; TYPE, the data
303: type of the argument as a tree node or 0 if that is not known
304: (which happens for C support library functions); and NAMED, which
305: is 1 for an ordinary argument and 0 for nameless arguments that
306: correspond to `...' in the called function's prototype.
307:
308: The value of the expression should either be a `reg' RTX for the
309: hard register in which to pass the argument, or zero to pass the
310: argument on the stack.
311:
312: For machines like the Vax and 68000, where normally all arguments
313: are pushed, zero suffices as a definition.
314:
315: The usual way to make the ANSI library `stdarg.h' work on a
316: machine where some arguments are usually passed in registers, is
317: to cause nameless arguments to be passed on the stack instead.
318: This is done by making `FUNCTION_ARG' return 0 whenever NAMED is
319: 0.
320:
321: You may use the macro `MUST_PASS_IN_STACK (MODE, TYPE)' in the
322: definition of this macro to determine if this argument is of a
323: type that must be passed in the stack. If `REG_PARM_STACK_SPACE'
324: is not defined and `FUNCTION_ARG' returns non-zero for such an
325: argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is
326: defined, the argument will be computed in the stack and then
327: loaded into a register.
328:
329: `FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)'
330: Define this macro if the target machine has "register windows", so
331: that the register in which a function sees an arguments is not
332: necessarily the same as the one in which the caller passed the
333: argument.
334:
335: For such machines, `FUNCTION_ARG' computes the register in which
336: the caller passes the value, and `FUNCTION_INCOMING_ARG' should
337: be defined in a similar fashion to tell the function being called
338: where the arguments will arrive.
339:
340: If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
341: both purposes.
342:
343: `FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)'
344: A C expression for the number of words, at the beginning of an
345: argument, must be put in registers. The value must be zero for
346: arguments that are passed entirely in registers or that are
347: entirely pushed on the stack.
348:
349: On some machines, certain arguments must be passed partially in
350: registers and partially in memory. On these machines, typically
351: the first N words of arguments are passed in registers, and the
352: rest on the stack. If a multi-word argument (a `double' or a
353: structure) crosses that boundary, its first few words must be
354: passed in registers and the rest must be pushed. This macro
355: tells the compiler when this occurs, and how many of the words
356: should go in registers.
357:
358: `FUNCTION_ARG' for these arguments should return the first
359: register to be used by the caller for this argument; likewise
360: `FUNCTION_INCOMING_ARG', for the called function.
361:
362: `FUNCTION_ARG_PASS_BY_REFERENCE (CUM, MODE, TYPE, NAMED)'
363: A C expression that indicates when an argument must be passed by
364: reference. If nonzero for an argument, a copy of that argument
365: is made in memory and a pointer to the argument is passed instead
366: of the argument itself. The pointer is passed in whatever way is
367: appropriate for passing a pointer to that type.
368:
369: On machines where `REG_PARM_STACK_SPACE' is not defined, a
370: suitable definition of this macro might be
371: #define FUNCTION_ARG_PASS_BY_REFERENCE(CUM, MODE, TYPE, NAMED) \
372: MUST_PASS_IN_STACK (MODE, TYPE)
373:
374: `CUMULATIVE_ARGS'
375: A C type for declaring a variable that is used as the first
376: argument of `FUNCTION_ARG' and other related values. For some
377: target machines, the type `int' suffices and can hold the number
378: of bytes of argument so far.
379:
380: There is no need to record in `CUMULATIVE_ARGS' anything about the
381: arguments that have been passed on the stack. The compiler has
382: other variables to keep track of that. For target machines on
383: which all arguments are passed on the stack, there is no need to
384: store anything in `CUMULATIVE_ARGS'; however, the data structure
385: must exist and should not be empty, so use `int'.
386:
387: `INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME)'
388: A C statement (sans semicolon) for initializing the variable CUM
389: for the state at the beginning of the argument list. The
390: variable has type `CUMULATIVE_ARGS'. The value of FNTYPE is the
391: tree node for the data type of the function which will receive
392: the args, or 0 if the args are to a compiler support library
393: function.
394:
395: When processing a call to a compiler support library function,
396: LIBNAME identifies which one. It is a `symbol_ref' rtx which
397: contains the name of the function, as a string. LIBNAME is 0 when
398: an ordinary C function call is being processed. Thus, each time
399: this macro is called, either LIBNAME or FNTYPE is nonzero, but
400: never both of them at once.
401:
402: `INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)'
403: Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of
404: finding the arguments for the function being compiled. If this
405: macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead.
406:
407: The argument LIBNAME exists for symmetry with
408: `INIT_CUMULATIVE_ARGS'. The value passed for LIBNAME is always
409: 0, since library routines with special calling conventions are
410: never compiled with GNU CC.
411:
412: `FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)'
413: A C statement (sans semicolon) to update the summarizer variable
414: CUM to advance past an argument in the argument list. The values
415: MODE, TYPE and NAMED describe that argument. Once this is done,
416: the variable CUM is suitable for analyzing the *following*
417: argument with `FUNCTION_ARG', etc.
418:
419: This macro need not do anything if the argument in question was
420: passed on the stack. The compiler knows how to track the amount
421: of stack space used for arguments without any special help.
422:
423: `FUNCTION_ARG_PADDING (MODE, TYPE)'
424: If defined, a C expression which determines whether, and in which
425: direction, to pad out an argument with extra space. The value
426: should be of type `enum direction': either `upward' to pad above
427: the argument, `downward' to pad below, or `none' to inhibit
428: padding.
429:
430: This macro does not control the *amount* of padding; that is
431: always just enough to reach the next multiple of
432: `FUNCTION_ARG_BOUNDARY'.
433:
434: This macro has a default definition which is right for most
435: systems. For little-endian machines, the default is to pad
436: upward. For big-endian machines, the default is to pad downward
437: for an argument of constant size shorter than an `int', and
438: upward otherwise.
439:
440: `FUNCTION_ARG_BOUNDARY (MODE, TYPE)'
441: If defined, a C expression that gives the alignment boundary, in
442: bits, of an argument with the specified mode and type. If it is
443: not defined, `PARM_BOUNDARY' is used for all arguments.
444:
445: `FUNCTION_ARG_REGNO_P (REGNO)'
446: A C expression that is nonzero if REGNO is the number of a hard
447: register in which function arguments are sometimes passed. This
448: does *not* include implicit arguments such as the static chain and
449: the structure-value address. On many machines, no registers can
450: be used for this purpose since all function arguments are pushed
451: on the stack.
452:
453:
454: File: gcc.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling
455:
456: How Scalar Function Values Are Returned
457: ---------------------------------------
458:
459: This section discusses the macros that control returning scalars as
460: values--values that can fit in registers.
461:
462: `TRADITIONAL_RETURN_FLOAT'
463: Define this macro if `-traditional' should not cause functions
464: declared to return `float' to convert the value to `double'.
465:
466: `FUNCTION_VALUE (VALTYPE, FUNC)'
467: A C expression to create an RTX representing the place where a
468: function returns a value of data type VALTYPE. VALTYPE is a tree
469: node representing a data type. Write `TYPE_MODE (VALTYPE)' to
470: get the machine mode used to represent that type. On many
471: machines, only the mode is relevant. (Actually, on most
472: machines, scalar values are returned in the same place regardless
473: of mode).
474:
475: If the precise function being called is known, FUNC is a tree
476: node (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer.
477: This makes it possible to use a different value-returning
478: convention for specific functions when all their calls are known.
479:
480: `FUNCTION_VALUE' is not used for return vales with aggregate data
481: types, because these are returned in another way. See
482: `STRUCT_VALUE_REGNUM' and related macros, below.
483:
484: `FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)'
485: Define this macro if the target machine has "register windows" so
486: that the register in which a function returns its value is not
487: the same as the one in which the caller sees the value.
488:
489: For such machines, `FUNCTION_VALUE' computes the register in
490: which the caller will see the value, and
491: `FUNCTION_OUTGOING_VALUE' should be defined in a similar fashion
492: to tell the function where to put the value.
493:
494: If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE'
495: serves both purposes.
496:
497: `FUNCTION_OUTGOING_VALUE' is not used for return vales with
498: aggregate data types, because these are returned in another way.
499: See `STRUCT_VALUE_REGNUM' and related macros, below.
500:
501: `LIBCALL_VALUE (MODE)'
502: A C expression to create an RTX representing the place where a
503: library function returns a value of mode MODE. If the precise
504: function being called is known, FUNC is a tree node
505: (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer.
506: This makes it possible to use a different value-returning
507: convention for specific functions when all their calls are known.
508:
509: Note that "library function" in this context means a compiler
510: support routine, used to perform arithmetic, whose name is known
511: specially by the compiler and was not mentioned in the C code
512: being compiled.
513:
514: The definition of `LIBRARY_VALUE' need not be concerned aggregate
515: data types, because none of the library functions returns such
516: types.
517:
518: `FUNCTION_VALUE_REGNO_P (REGNO)'
519: A C expression that is nonzero if REGNO is the number of a hard
520: register in which the values of called function may come back.
521:
522: A register whose use for returning values is limited to serving
523: as the second of a pair (for a value of type `double', say) need
524: not be recognized by this macro. So for most machines, this
525: definition suffices:
526:
527: #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
528:
529: If the machine has register windows, so that the caller and the
530: called function use different registers for the return value,
531: this macro should recognize only the caller's register numbers.
532:
533:
534: File: gcc.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling
535:
536: How Large Values Are Returnd
537: ----------------------------
538:
539: When a function value's mode is `BLKmode' (and in some other
540: cases), the value is not returned according to `FUNCTION_VALUE' (*note
541: Scalar Return::.). Instead, the caller passes the address of a block
542: of memory in which the value should be stored. This address is called
543: the "structure value address".
544:
545: This section describes how to control returning structure values in
546: memory.
547:
548: `RETURN_IN_MEMORY (TYPE)'
549: A C expression which can inhibit the returning of certain function
550: values in registers, based on the type of value. A nonzero value
551: says to return the function value in memory, just as large
552: structures are always returned. Here TYPE will be a C expression
553: of type `tree', representing the data type of the value.
554:
555: Note that values of mode `BLKmode' are returned in memory
556: regardless of this macro. Also, the option `-fpcc-struct-return'
557: takes effect regardless of this macro. On most systems, it is
558: possible to leave the macro undefined; this causes a default
559: definition to be used, whose value is the constant 0.
560:
561: `STRUCT_VALUE_REGNUM'
562: If the structure value address is passed in a register, then
563: `STRUCT_VALUE_REGNUM' should be the number of that register.
564:
565: `STRUCT_VALUE'
566: If the structure value address is not passed in a register, define
567: `STRUCT_VALUE' as an expression returning an RTX for the place
568: where the address is passed. If it returns 0, the address is
569: passed as an "invisible" first argument.
570:
571: `STRUCT_VALUE_INCOMING_REGNUM'
572: On some architectures the place where the structure value address
573: is found by the called function is not the same place that the
574: caller put it. This can be due to register windows, or it could
575: be because the function prologue moves it to a different place.
576:
577: If the incoming location of the structure value address is in a
578: register, define this macro as the register number.
579:
580: `STRUCT_VALUE_INCOMING'
581: If the incoming location is not a register, define
582: `STRUCT_VALUE_INCOMING' as an expression for an RTX for where the
583: called function should find the value. If it should find the
584: value on the stack, define this to create a `mem' which refers to
585: the frame pointer. A definition of 0 means that the address is
586: passed as an "invisible" first argument.
587:
588: `PCC_STATIC_STRUCT_RETURN'
589: Define this macro if the usual system convention on the target
590: machine for returning structures and unions is for the called
591: function to return the address of a static variable containing
592: the value. GNU CC does not normally use this convention, even if
593: it is the usual one, but does use it if `-fpcc-struct-value' is
594: specified.
595:
596: Do not define this if the usual system convention is for the
597: caller to pass an address to the subroutine.
598:
599:
600: File: gcc.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling
601:
602: Caller-Saves Register Allocation
603: --------------------------------
604:
605: If you enable it, GNU CC can save registers around function calls.
606: This makes it possible to use call-clobbered registers to hold
607: variables that must live across calls.
608:
609: `DEFAULT_CALLER_SAVES'
610: Define this macro if function calls on the target machine do not
611: preserve any registers; in other words, if `CALL_USED_REGISTERS'
612: has 1 for all registers. This macro enables `-fcaller-saves' by
613: default. Eventually that option will be enabled by default on
614: all machines and both the option and this macro will be
615: eliminated.
616:
617: `CALLER_SAVE_PROFITABLE (REFS, CALLS)'
618: A C expression to determine whether it is worthwhile to consider
619: placing a pseudo-register in a call-clobbered hard register and
620: saving and restoring it around each function call. The
621: expression should be 1 when this is worth doing, and 0 otherwise.
622:
623: If you don't define this macro, a default is used which is good
624: on most machines: `4 * CALLS < REFS'.
625:
626:
627: File: gcc.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling
628:
629: Function Entry and Exit
630: -----------------------
631:
632: This section describes the macros that output function entry
633: ("prologue") and exit ("epilogue") code.
634:
635: `FUNCTION_PROLOGUE (FILE, SIZE)'
636: A C compound statement that outputs the assembler code for entry
637: to a function. The prologue is responsible for setting up the
638: stack frame, initializing the frame pointer register, saving
639: registers that must be saved, and allocating SIZE additional
640: bytes of storage for the local variables. SIZE is an integer.
641: FILE is a stdio stream to which the assembler code should be
642: output.
643:
644: The label for the beginning of the function need not be output by
645: this macro. That has already been done when the macro is run.
646:
647: To determine which registers to save, the macro can refer to the
648: array `regs_ever_live': element R is nonzero if hard register R
649: is used anywhere within the function. This implies the function
650: prologue should save register R, provided it is not one of the
651: call-used registers. (`FUNCTION_EPILOGUE' must likewise use
652: `regs_ever_live'.)
653:
654: On machines that have "register windows", the function entry code
655: does not save on the stack the registers that are in the windows,
656: even if they are supposed to be preserved by function calls;
657: instead it takes appropriate steps to "push" the register stack,
658: if any non-call-used registers are used in the function.
659:
660: On machines where functions may or may not have frame-pointers,
661: the function entry code must vary accordingly; it must set up the
662: frame pointer if one is wanted, and not otherwise. To determine
663: whether a frame pointer is in wanted, the macro can refer to the
664: variable `frame_pointer_needed'. The variable's value will be 1
665: at run time in a function that needs a frame pointer. *Note
666: Elimination::.
667:
668: The function entry code is responsible for allocating any stack
669: space required for the function. This stack space consists of
670: the regions listed below. In most cases, these regions are
671: allocated in the order listed, with the last listed region
672: closest to the top of the stack (the lowest address if
673: `STACK_GROWS_DOWNWARD' is defined, and the highest address if it
674: is not defined). You can use a different order for a machine if
675: doing so is more convenient or required for compatibility
676: reasons. Except in cases where required by standard or by a
677: debugger, there is no reason why the stack layout used by GCC
678: need agree with that used by other compilers for a machine.
679:
680: * A region of `current_function_pretend_args_size' bytes of
681: uninitialized space just underneath the first argument
682: arriving on the stack. (This may not be at the very start
683: of the allocated stack region if the calling sequence has
684: pushed anything else since pushing the stack arguments. But
685: usually, on such machines, nothing else has been pushed yet,
686: because the function prologue itself does all the pushing.)
687: This region is used on machines where an argument may be
688: passed partly in registers and partly in memory, and, in
689: some cases to support the features in `varargs.h' and
690: `stdargs.h'.
691:
692: * An area of memory used to save certain registers used by the
693: function. The size of this area, which may also include
694: space for such things as the return address and pointers to
695: previous stack frames, is machine-specific and usually
696: depends on which registers have been used in the function.
697: Machines with register windows often do not require a save
698: area.
699:
700: * A region of at least SIZE bytes, possibly rounded up to an
701: allocation boundary, to contain the local variables of the
702: function. On some machines, this region and the save area
703: may occur in the opposite order, with the save area closer
704: to the top of the stack.
705:
706: * Optionally, in the case that `ACCUMULATE_OUTGOING_ARGS' is
707: defined, a region of `current_function_outgoing_args_size'
708: bytes to be used for outgoing argument lists of the
709: function. *Note Stack Arguments::.
710:
711: Normally, it is necessary for `FUNCTION_PROLOGUE' and
712: `FUNCTION_EPILOGUE' to treat leaf functions specially. The C
713: variable `leaf_function' is nonzero for such a function.
714:
715: `EXIT_IGNORE_STACK'
716: Define this macro as a C expression that is nonzero if the return
717: instruction or the function epilogue ignores the value of the
718: stack pointer; in other words, if it is safe to delete an
719: instruction to adjust the stack pointer before a return from the
720: function.
721:
722: Note that this macro's value is relevant only for functions for
723: which frame pointers are maintained. It is never safe to delete
724: a final stack adjustment in a function that has no frame pointer,
725: and the compiler knows this regardless of `EXIT_IGNORE_STACK'.
726:
727: `FUNCTION_EPILOGUE (FILE, SIZE)'
728: A C compound statement that outputs the assembler code for exit
729: from a function. The epilogue is responsible for restoring the
730: saved registers and stack pointer to their values when the
731: function was called, and returning control to the caller. This
732: macro takes the same arguments as the macro `FUNCTION_PROLOGUE',
733: and the registers to restore are determined from `regs_ever_live'
734: and `CALL_USED_REGISTERS' in the same way.
735:
736: On some machines, there is a single instruction that does all the
737: work of returning from the function. On these machines, give that
738: instruction the name `return' and do not define the macro
739: `FUNCTION_EPILOGUE' at all.
740:
741: Do not define a pattern named `return' if you want the
742: `FUNCTION_EPILOGUE' to be used. If you want the target switches
743: to control whether return instructions or epilogues are used,
744: define a `return' pattern with a validity condition that tests
745: the target switches appropriately. If the `return' pattern's
746: validity condition is false, epilogues will be used.
747:
748: On machines where functions may or may not have frame-pointers,
749: the function exit code must vary accordingly. Sometimes the code
750: for these two cases is completely different. To determine
751: whether a frame pointer is in wanted, the macro can refer to the
752: variable `frame_pointer_needed'. The variable's value will be 1
753: at run time in a function that needs a frame pointer.
754:
755: Normally, it is necessary for `FUNCTION_PROLOGUE' and
756: `FUNCTION_EPILOGUE' to treat leaf functions specially. The C
757: variable `leaf_function' is nonzero for such a function. *Note
758: Leaf Functions::.
759:
760: On some machines, some functions pop their arguments on exit while
761: others leave that for the caller to do. For example, the 68020
762: when given `-mrtd' pops arguments in functions that take a fixed
763: number of arguments.
764:
765: Your definition of the macro `RETURN_POPS_ARGS' decides which
766: functions pop their own arguments. `FUNCTION_EPILOGUE' needs to
767: know what was decided. The variable `current_function_pops_args'
768: is the number of bytes of its arguments that a function should
769: pop. *Note Scalar Return::.
770:
771: `DELAY_SLOTS_FOR_EPILOGUE'
772: Define this macro if the function epilogue contains delay slots
773: to which instructions from the rest of the function can be
774: "moved". The definition should be a C expression whose value is
775: an integer representing the number of delay slots there.
776:
777: `ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)'
778: A C expression that returns 1 if INSN can be placed in delay slot
779: number N of the epilogue.
780:
781: The argument N is an integer which identifies the delay slot now
782: being considered (since different slots may have different rules
783: of eligibility). It is never negative and is always less than
784: the number of epilogue delay slots (what
785: `DELAY_SLOTS_FOR_EPILOGUE' returns). If you reject a particular
786: insn for a given delay slot, in principle, it may be reconsidered
787: for a subsequent delay slot. Also, other insns may (at least in
788: principle) be considered for the so far unfilled delay slot.
789:
790: The insns accepted to fill the epilogue delay slots are put in an
791: RTL list made with `insn_list' objects, stored in the variable
792: `current_function_epilogue_delay_list'. The insn for the first
793: delay slot comes first in the list. Your definition of the macro
794: `FUNCTION_EPILOGUE' should fill the delay slots by outputting the
795: insns in this list, usually by calling `final_scan_insn'.
796:
797: You need not define this macro if you did not define
798: `DELAY_SLOTS_FOR_EPILOGUE'.
799:
800:
801: File: gcc.info, Node: Profiling, Prev: Function Entry, Up: Stack and Calling
802:
803: Generating Code for Profiling
804: -----------------------------
805:
806: `FUNCTION_PROFILER (FILE, LABELNO)'
807: A C statement or compound statement to output to FILE some
808: assembler code to call the profiling subroutine `mcount'. Before
809: calling, the assembler code must load the address of a counter
810: variable into a register where `mcount' expects to find the
811: address. The name of this variable is `LP' followed by the
812: number LABELNO, so you would generate the name using `LP%d' in a
813: `fprintf'.
814:
815: The details of how the address should be passed to `mcount' are
816: determined by your operating system environment, not by GNU CC.
817: To figure them out, compile a small program for profiling using
818: the system's installed C compiler and look at the assembler code
819: that results.
820:
821: `PROFILE_BEFORE_PROLOGUE'
822: Define this macro if the code for function profiling should come
823: before the function prologue. Normally, the profiling code comes
824: after.
825:
826: `FUNCTION_BLOCK_PROFILER (FILE, LABELNO)'
827: A C statement or compound statement to output to FILE some
828: assembler code to initialize basic-block profiling for the current
829: object module. This code should call the subroutine
830: `__bb_init_func' once per object module, passing it as its sole
831: argument the address of a block allocated in the object module.
832:
833: The name of the block is a local symbol made with this statement:
834:
835: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0);
836:
837: Of course, since you are writing the definition of
838: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you
839: can take a short cut in the definition of this macro and use the
840: name that you know will result.
841:
842: The first word of this block is a flag which will be nonzero if
843: the object module has already been initialized. So test this
844: word first, and do not call `__bb_init_func' if the flag is
845: nonzero.
846:
847: `BLOCK_PROFILER (FILE, BLOCKNO)'
848: A C statement or compound statement to increment the count
849: associated with the basic block number BLOCKNO. Basic blocks are
850: numbered separately from zero within each compilation. The count
851: associated with block number BLOCKNO is at index BLOCKNO in a
852: vector of words; the name of this array is a local symbol made
853: with this statement:
854:
855: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2);
856:
857: Of course, since you are writing the definition of
858: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you
859: can take a short cut in the definition of this macro and use the
860: name that you know will result.
861:
862:
863: File: gcc.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Machine Macros
864:
865: Implementing the Varargs Macros
866: ===============================
867:
868: GNU CC comes with an implementation of `varargs.h' and `stdarg.h'
869: that work without change on machines that pass arguments on the stack.
870: Other machines require their own implementations of varargs, and the
871: two machine independent header files must have conditionals to include
872: it.
873:
874: ANSI `stdarg.h' differs from traditional `varargs.h' mainly in the
875: calling convention for `va_start'. The traditional implementation
876: takes just one argument, which is the variable in which to store the
877: argument pointer. The ANSI implementation takes an additional first
878: argument, which is the last named argument of the function. However,
879: it should not use this argument. The way to find the end of the named
880: arguments is with the built-in functions described below.
881:
882: `__builtin_saveregs ()'
883: Use this built-in function to save the argument registers in
884: memory so that the varargs mechanism can access them. Both ANSI
885: and traditional versions of `va_start' must use
886: `__builtin_saveregs', unless you use `SETUP_INCOMING_VARARGS'
887: (see below) instead.
888:
889: On some machines, `__builtin_saveregs' is open-coded under the
890: control of the macro `EXPAND_BUILTIN_SAVEREGS'. On other
891: machines, it calls a routine written in assembler language, found
892: in `libgcc2.c'.
893:
894: Regardless of what code is generated for the call to
895: `__builtin_saveregs', it appears at the beginning of the function,
896: not where the call to `__builtin_saveregs' is written. This is
897: because the registers must be saved before the function starts to
898: use them for its own purposes.
899:
900: `__builtin_args_info (CATEGORY)'
901: Use this built-in function to find the first anonymous arguments
902: in registers.
903:
904: In general, a machine may have several categories of registers
905: used for arguments, each for a particular category of data types.
906: (For example, on some machines, floating-point registers are
907: used for floating-point arguments while other arguments are
908: passed in the general registers.) To make non-varargs functions
909: use the proper calling convention, you have defined the
910: `CUMULATIVE_ARGS' data type to record how many registers in each
911: category have been used so far
912:
913: `__builtin_args_info' accesses the same data structure of type
914: `CUMULATIVE_ARGS' after the ordinary argument layout is finished
915: with it, with CATEGORY specifying which word to access. Thus, the
916: value indicates the first unused register in a given category.
917:
918: Normally, you would use `__builtin_args_info' in the
919: implementation of `va_start', accessing each category just once
920: and storing the value in the `va_list' object. This is because
921: `va_list' will have to update the values, and there is no way to
922: alter the values accessed by `__builtin_args_info'.
923:
924: `__builtin_next_arg ()'
925: This is the equivalent of `__builtin_args_info', for stack
926: arguments. It returns the address of the first anonymous stack
927: argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns
928: the address of the location above the first anonymous stack
929: argument. Use it in `va_start' to initialize the pointer for
930: fetching arguments from the stack.
931:
932: `__builtin_classify_type (OBJECT)'
933: Since each machine has its own conventions for which data types
934: are passed in which kind of register, your implementation of
935: `va_arg' has to embody these conventions. The easiest way to
936: categorize the specified data type is to use
937: `__builtin_classify_type' together with `sizeof' and
938: `__alignof__'.
939:
940: `__builtin_classify_type' ignores the value of OBJECT,
941: considering only its data type. It returns an integer describing
942: what kind of type that is--integer, floating, pointer, structure,
943: and so on.
944:
945: The file `typeclass.h' defines an enumeration that you can use to
946: interpret the values of `__builtin_classify_type'.
947:
948: These machine description macros help implement varargs:
949:
950: `EXPAND_BUILTIN_SAVEREGS (ARGS)'
951: If defined, is a C expression that produces the machine-specific
952: code for a call to `__builtin_saveregs'. This code will be moved
953: to the very beginning of the function, before any parameter
954: access are made. The return value of this function should be an
955: RTX that contains the value to use as the return of
956: `__builtin_saveregs'.
957:
958: The argument ARGS is a `tree_list' containing the arguments that
959: were passed to `__builtin_saveregs'.
960:
961: If this macro is not defined, the compiler will output an ordinary
962: call to the library function `__builtin_saveregs'.
963:
964: `SETUP_INCOMING_VARARGS (ARGS_SO_FAR, MODE, TYPE, PRETEND_ARGS_SIZE, SECOND_TIME)'
965: This macro offers an alternative to using `__builtin_saveregs' and
966: defining the macro `EXPAND_BUILTIN_SAVEREGS'. Use it to store the
967: anonymous register arguments into the stack so that all the
968: arguments appear to have been passed consecutively on the stack.
969: Once this is done, you can use the standard implementation of
970: varargs that works for machines that pass all their arguments on
971: the stack.
972:
973: The argument ARGS_SO_FAR is the `CUMULATIVE_ARGS' data structure,
974: containing the values that obtain after processing of the named
975: arguments. The arguments MODE and TYPE describe the last named
976: argument--its machine mode and its data type as a tree node.
977:
978: The macro implementation should do two things: first, push onto
979: the stack all the argument registers *not* used for the named
980: arguments, and second, store the size of the data thus pushed
981: into the `int'-valued variable whose name is supplied as the
982: argument PRETEND_ARGS_SIZE. The value that you store here will
983: serve as additional offset for setting up the stack frame.
984:
985: Because you must generate code to push the anonymous arguments at
986: compile time without knowing their data types,
987: `SETUP_INCOMING_VARARGS' is only useful on machines that have just
988: a single category of argument register and use it uniformly for
989: all data types.
990:
991: If the argument SECOND_TIME is nonzero, it means that the
992: arguments of the function are being analyzed for the second time.
993: This happens for an inline function, which is not actually
994: compiled until the end of the source file. The macro
995: `SETUP_INCOMING_VARARGS' should not generate any instructions in
996: this case.
997:
998:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.