![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-18 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Apple XNU] / GNUtools / cc|
Return to gcc.info-18 CVS log | Up to [Apple XNU] / GNUtools / cc |
1.1 root 1: This is Info file gcc.info, produced by Makeinfo-1.54 from the input
2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
6: Published by the Free Software Foundation 675 Massachusetts Avenue
7: Cambridge, MA 02139 USA
8:
9: Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
10:
11: Permission is granted to make and distribute verbatim copies of this
12: manual provided the copyright notice and this permission notice are
13: preserved on all copies.
14:
15: Permission is granted to copy and distribute modified versions of
16: this manual under the conditions for verbatim copying, provided also
17: that the sections entitled "GNU General Public License" and "Protect
18: Your Freedom--Fight `Look And Feel'" are included exactly as in the
19: original, and provided that the entire resulting derived work is
20: distributed under the terms of a permission notice identical to this
21: one.
22:
23: Permission is granted to copy and distribute translations of this
24: manual into another language, under the above conditions for modified
25: versions, except that the sections entitled "GNU General Public
26: License" and "Protect Your Freedom--Fight `Look And Feel'", and this
27: permission notice, may be included in translations approved by the Free
28: Software Foundation instead of in the original English.
29:
30:
31: File: gcc.info, Node: Obsolete Register Macros, Prev: Stack Registers, Up: Registers
32:
33: Obsolete Macros for Controlling Register Usage
34: ----------------------------------------------
35:
36: These features do not work very well. They exist because they used
37: to be required to generate correct code for the 80387 coprocessor of the
38: 80386. They are no longer used by that machine description and may be
39: removed in a later version of the compiler. Don't use them!
40:
41: `OVERLAPPING_REGNO_P (REGNO)'
42: If defined, this is a C expression whose value is nonzero if hard
43: register number REGNO is an overlapping register. This means a
44: hard register which overlaps a hard register with a different
45: number. (Such overlap is undesirable, but occasionally it allows
46: a machine to be supported which otherwise could not be.) This
47: macro must return nonzero for *all* the registers which overlap
48: each other. GNU CC can use an overlapping register only in
49: certain limited ways. It can be used for allocation within a
50: basic block, and may be spilled for reloading; that is all.
51:
52: If this macro is not defined, it means that none of the hard
53: registers overlap each other. This is the usual situation.
54:
55: `INSN_CLOBBERS_REGNO_P (INSN, REGNO)'
56: If defined, this is a C expression whose value should be nonzero if
57: the insn INSN has the effect of mysteriously clobbering the
58: contents of hard register number REGNO. By "mysterious" we mean
59: that the insn's RTL expression doesn't describe such an effect.
60:
61: If this macro is not defined, it means that no insn clobbers
62: registers mysteriously. This is the usual situation; all else
63: being equal, it is best for the RTL expression to show all the
64: activity.
65:
66: `PRESERVE_DEATH_INFO_REGNO_P (REGNO)'
67: If defined, this is a C expression whose value is nonzero if
68: accurate `REG_DEAD' notes are needed for hard register number REGNO
69: at the time of outputting the assembler code. When this is so, a
70: few optimizations that take place after register allocation and
71: could invalidate the death notes are not done when this register is
72: involved.
73:
74: You would arrange to preserve death info for a register when some
75: of the code in the machine description which is executed to write
76: the assembler code looks at the death notes. This is necessary
77: only when the actual hardware feature which GNU CC thinks of as a
78: register is not actually a register of the usual sort. (It might,
79: for example, be a hardware stack.)
80:
81: If this macro is not defined, it means that no death notes need to
82: be preserved. This is the usual situation.
83:
84:
85: File: gcc.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros
86:
87: Register Classes
88: ================
89:
90: On many machines, the numbered registers are not all equivalent.
91: For example, certain registers may not be allowed for indexed
92: addressing; certain registers may not be allowed in some instructions.
93: These machine restrictions are described to the compiler using
94: "register classes".
95:
96: You define a number of register classes, giving each one a name and
97: saying which of the registers belong to it. Then you can specify
98: register classes that are allowed as operands to particular instruction
99: patterns.
100:
101: In general, each register will belong to several classes. In fact,
102: one class must be named `ALL_REGS' and contain all the registers.
103: Another class must be named `NO_REGS' and contain no registers. Often
104: the union of two classes will be another class; however, this is not
105: required.
106:
107: One of the classes must be named `GENERAL_REGS'. There is nothing
108: terribly special about the name, but the operand constraint letters `r'
109: and `g' specify this class. If `GENERAL_REGS' is the same as
110: `ALL_REGS', just define it as a macro which expands to `ALL_REGS'.
111:
112: Order the classes so that if class X is contained in class Y then X
113: has a lower class number than Y.
114:
115: The way classes other than `GENERAL_REGS' are specified in operand
116: constraints is through machine-dependent operand constraint letters.
117: You can define such letters to correspond to various classes, then use
118: them in operand constraints.
119:
120: You should define a class for the union of two classes whenever some
121: instruction allows both classes. For example, if an instruction allows
122: either a floating point (coprocessor) register or a general register
123: for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS'
124: which includes both of them. Otherwise you will get suboptimal code.
125:
126: You must also specify certain redundant information about the
127: register classes: for each class, which classes contain it and which
128: ones are contained in it; for each pair of classes, the largest class
129: contained in their union.
130:
131: When a value occupying several consecutive registers is expected in a
132: certain class, all the registers used must belong to that class.
133: Therefore, register classes cannot be used to enforce a requirement for
134: a register pair to start with an even-numbered register. The way to
135: specify this requirement is with `HARD_REGNO_MODE_OK'.
136:
137: Register classes used for input-operands of bitwise-and or shift
138: instructions have a special requirement: each such class must have, for
139: each fixed-point machine mode, a subclass whose registers can transfer
140: that mode to or from memory. For example, on some machines, the
141: operations for single-byte values (`QImode') are limited to certain
142: registers. When this is so, each register class that is used in a
143: bitwise-and or shift instruction must have a subclass consisting of
144: registers from which single-byte values can be loaded or stored. This
145: is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to
146: return.
147:
148: `enum reg_class'
149: An enumeral type that must be defined with all the register class
150: names as enumeral values. `NO_REGS' must be first. `ALL_REGS'
151: must be the last register class, followed by one more enumeral
152: value, `LIM_REG_CLASSES', which is not a register class but rather
153: tells how many classes there are.
154:
155: Each register class has a number, which is the value of casting
156: the class name to type `int'. The number serves as an index in
157: many of the tables described below.
158:
159: `N_REG_CLASSES'
160: The number of distinct register classes, defined as follows:
161:
162: #define N_REG_CLASSES (int) LIM_REG_CLASSES
163:
164: `REG_CLASS_NAMES'
165: An initializer containing the names of the register classes as C
166: string constants. These names are used in writing some of the
167: debugging dumps.
168:
169: `REG_CLASS_CONTENTS'
170: An initializer containing the contents of the register classes, as
171: integers which are bit masks. The Nth integer specifies the
172: contents of class N. The way the integer MASK is interpreted is
173: that register R is in the class if `MASK & (1 << R)' is 1.
174:
175: When the machine has more than 32 registers, an integer does not
176: suffice. Then the integers are replaced by sub-initializers,
177: braced groupings containing several integers. Each
178: sub-initializer must be suitable as an initializer for the type
179: `HARD_REG_SET' which is defined in `hard-reg-set.h'.
180:
181: `REGNO_REG_CLASS (REGNO)'
182: A C expression whose value is a register class containing hard
183: register REGNO. In general there is more than one such class;
184: choose a class which is "minimal", meaning that no smaller class
185: also contains the register.
186:
187: `BASE_REG_CLASS'
188: A macro whose definition is the name of the class to which a valid
189: base register must belong. A base register is one used in an
190: address which is the register value plus a displacement.
191:
192: `INDEX_REG_CLASS'
193: A macro whose definition is the name of the class to which a valid
194: index register must belong. An index register is one used in an
195: address where its value is either multiplied by a scale factor or
196: added to another register (as well as added to a displacement).
197:
198: `REG_CLASS_FROM_LETTER (CHAR)'
199: A C expression which defines the machine-dependent operand
200: constraint letters for register classes. If CHAR is such a
201: letter, the value should be the register class corresponding to
202: it. Otherwise, the value should be `NO_REGS'. The register
203: letter `r', corresponding to class `GENERAL_REGS', will not be
204: passed to this macro; you do not need to handle it.
205:
206: `REGNO_OK_FOR_BASE_P (NUM)'
207: A C expression which is nonzero if register number NUM is suitable
208: for use as a base register in operand addresses. It may be either
209: a suitable hard register or a pseudo register that has been
210: allocated such a hard register.
211:
212: `REGNO_OK_FOR_INDEX_P (NUM)'
213: A C expression which is nonzero if register number NUM is suitable
214: for use as an index register in operand addresses. It may be
215: either a suitable hard register or a pseudo register that has been
216: allocated such a hard register.
217:
218: The difference between an index register and a base register is
219: that the index register may be scaled. If an address involves the
220: sum of two registers, neither one of them scaled, then either one
221: may be labeled the "base" and the other the "index"; but whichever
222: labeling is used must fit the machine's constraints of which
223: registers may serve in each capacity. The compiler will try both
224: labelings, looking for one that is valid, and will reload one or
225: both registers only if neither labeling works.
226:
227: `PREFERRED_RELOAD_CLASS (X, CLASS)'
228: A C expression that places additional restrictions on the register
229: class to use when it is necessary to copy value X into a register
230: in class CLASS. The value is a register class; perhaps CLASS, or
231: perhaps another, smaller class. On many machines, the following
232: definition is safe:
233:
234: #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
235:
236: Sometimes returning a more restrictive class makes better code.
237: For example, on the 68000, when X is an integer constant that is
238: in range for a `moveq' instruction, the value of this macro is
239: always `DATA_REGS' as long as CLASS includes the data registers.
240: Requiring a data register guarantees that a `moveq' will be used.
241:
242: If X is a `const_double', by returning `NO_REGS' you can force X
243: into a memory constant. This is useful on certain machines where
244: immediate floating values cannot be loaded into certain kinds of
245: registers.
246:
247: `PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS)'
248: Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of
249: input reloads. If you don't define this macro, the default is to
250: use CLASS, unchanged.
251:
252: `LIMIT_RELOAD_CLASS (MODE, CLASS)'
253: A C expression that places additional restrictions on the register
254: class to use when it is necessary to be able to hold a value of
255: mode MODE in a reload register for which class CLASS would
256: ordinarily be used.
257:
258: Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when
259: there are certain modes that simply can't go in certain reload
260: classes.
261:
262: The value is a register class; perhaps CLASS, or perhaps another,
263: smaller class.
264:
265: Don't define this macro unless the target machine has limitations
266: which require the macro to do something nontrivial.
267:
268: `SECONDARY_RELOAD_CLASS (CLASS, MODE, X)'
269: `SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)'
270: `SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)'
271: Many machines have some registers that cannot be copied directly
272: to or from memory or even from other types of registers. An
273: example is the `MQ' register, which on most machines, can only be
274: copied to or from general registers, but not memory. Some
275: machines allow copying all registers to and from memory, but
276: require a scratch register for stores to some memory locations
277: (e.g., those with symbolic address on the RT, and those with
278: certain symbolic address on the Sparc when compiling PIC). In
279: some cases, both an intermediate and a scratch register are
280: required.
281:
282: You should define these macros to indicate to the reload phase
283: that it may need to allocate at least one register for a reload in
284: addition to the register to contain the data. Specifically, if
285: copying X to a register CLASS in MODE requires an intermediate
286: register, you should define `SECONDARY_INPUT_RELOAD_CLASS' to
287: return the largest register class all of whose registers can be
288: used as intermediate registers or scratch registers.
289:
290: If copying a register CLASS in MODE to X requires an intermediate
291: or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' should be
292: defined to return the largest register class required. If the
293: requirements for input and output reloads are the same, the macro
294: `SECONDARY_RELOAD_CLASS' should be used instead of defining both
295: macros identically.
296:
297: The values returned by these macros are often `GENERAL_REGS'.
298: Return `NO_REGS' if no spare register is needed; i.e., if X can be
299: directly copied to or from a register of CLASS in MODE without
300: requiring a scratch register. Do not define this macro if it
301: would always return `NO_REGS'.
302:
303: If a scratch register is required (either with or without an
304: intermediate register), you should define patterns for
305: `reload_inM' or `reload_outM', as required (*note Standard
306: Names::.. These patterns, which will normally be implemented with
307: a `define_expand', should be similar to the `movM' patterns,
308: except that operand 2 is the scratch register.
309:
310: Define constraints for the reload register and scratch register
311: that contain a single register class. If the original reload
312: register (whose class is CLASS) can meet the constraint given in
313: the pattern, the value returned by these macros is used for the
314: class of the scratch register. Otherwise, two additional reload
315: registers are required. Their classes are obtained from the
316: constraints in the insn pattern.
317:
318: X might be a pseudo-register or a `subreg' of a pseudo-register,
319: which could either be in a hard register or in memory. Use
320: `true_regnum' to find out; it will return -1 if the pseudo is in
321: memory and the hard register number if it is in a register.
322:
323: These macros should not be used in the case where a particular
324: class of registers can only be copied to memory and not to another
325: class of registers. In that case, secondary reload registers are
326: not needed and would not be helpful. Instead, a stack location
327: must be used to perform the copy and the `movM' pattern should use
328: memory as a intermediate storage. This case often occurs between
329: floating-point and general registers.
330:
331: `SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M)'
332: Certain machines have the property that some registers cannot be
333: copied to some other registers without using memory. Define this
334: macro on those machines to be a C expression that is non-zero if
335: objects of mode M in registers of CLASS1 can only be copied to
336: registers of class CLASS2 by storing a register of CLASS1 into
337: memory and loading that memory location into a register of CLASS2.
338:
339: Do not define this macro if its value would always be zero.
340:
341: `SECONDARY_MEMORY_NEEDED_RTX (MODE)'
342: Normally, when `SECONDARY_MEMORY_NEEDED' is defined, the compiler
343: will allocate a stack slot when a memory location for a register
344: copy is needed. If this macro is defined, the compiler instead
345: uses the memory location defined by this macro.
346:
347: `SMALL_REGISTER_CLASSES'
348: Normally the compiler will avoid choosing spill registers from
349: registers that have been explicitly mentioned in the rtl (these
350: registers are normally those used to pass parameters and return
351: values). However, some machines have so few registers of certain
352: classes that there would not be enough registers to use as spill
353: registers if this were done.
354:
355: You should define `SMALL_REGISTER_CLASSES' on those machines. When
356: it is defined, the compiler allows registers explicitly used in
357: the rtl to be used as spill registers but prevents the compiler
358: from extending the lifetime of these registers.
359:
360: Defining this macro is always safe, but unnecessarily defining
361: this macro will reduce the amount of optimizations that can be
362: performed in some cases. If this macro is not defined but needs
363: to be, the compiler will run out of reload registers and print a
364: fatal error message.
365:
366: For most machines, this macro should not be defined.
367:
368: `CLASS_LIKELY_SPILLED_P (CLASS)'
369: A C expression whose value is nonzero if pseudos that have been
370: assigned to registers of class CLASS would likely be spilled
371: because registers of CLASS are needed for spill registers.
372:
373: The default value of this macro returns 1 if CLASS has exactly one
374: register and zero otherwise. On most machines, this default
375: should be used. Only define this macro to some other expression
376: if pseudo allocated by `local-alloc.c' end up in memory because
377: their hard registers were needed for spill regisers. If this
378: macro returns nonzero for those classes, those pseudos will only
379: be allocated by `global.c', which knows how to reallocate the
380: pseudo to another register. If there would not be another
381: register available for reallocation, you should not change the
382: definition of this macro since the only effect of such a
383: definition would be to slow down register allocation.
384:
385: `CLASS_MAX_NREGS (CLASS, MODE)'
386: A C expression for the maximum number of consecutive registers of
387: class CLASS needed to hold a value of mode MODE.
388:
389: This is closely related to the macro `HARD_REGNO_NREGS'. In fact,
390: the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be
391: the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all
392: REGNO values in the class CLASS.
393:
394: This macro helps control the handling of multiple-word values in
395: the reload pass.
396:
397: Three other special macros describe which operands fit which
398: constraint letters.
399:
400: `CONST_OK_FOR_LETTER_P (VALUE, C)'
401: A C expression that defines the machine-dependent operand
402: constraint letters that specify particular ranges of integer
403: values. If C is one of those letters, the expression should check
404: that VALUE, an integer, is in the appropriate range and return 1
405: if so, 0 otherwise. If C is not one of those letters, the value
406: should be 0 regardless of VALUE.
407:
408: `CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)'
409: A C expression that defines the machine-dependent operand
410: constraint letters that specify particular ranges of
411: `const_double' values.
412:
413: If C is one of those letters, the expression should check that
414: VALUE, an RTX of code `const_double', is in the appropriate range
415: and return 1 if so, 0 otherwise. If C is not one of those
416: letters, the value should be 0 regardless of VALUE.
417:
418: `const_double' is used for all floating-point constants and for
419: `DImode' fixed-point constants. A given letter can accept either
420: or both kinds of values. It can use `GET_MODE' to distinguish
421: between these kinds.
422:
423: `EXTRA_CONSTRAINT (VALUE, C)'
424: A C expression that defines the optional machine-dependent
425: constraint letters that can be used to segregate specific types of
426: operands, usually memory references, for the target machine.
427: Normally this macro will not be defined. If it is required for a
428: particular target machine, it should return 1 if VALUE corresponds
429: to the operand type represented by the constraint letter C. If C
430: is not defined as an extra constraint, the value returned should
431: be 0 regardless of VALUE.
432:
433: For example, on the ROMP, load instructions cannot have their
434: output in r0 if the memory reference contains a symbolic address.
435: Constraint letter `Q' is defined as representing a memory address
436: that does *not* contain a symbolic address. An alternative is
437: specified with a `Q' constraint on the input and `r' on the
438: output. The next alternative specifies `m' on the input and a
439: register class that does not include r0 on the output.
440:
441:
442: File: gcc.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros
443:
444: Stack Layout and Calling Conventions
445: ====================================
446:
447: * Menu:
448:
449: * Frame Layout::
450: * Frame Registers::
451: * Elimination::
452: * Stack Arguments::
453: * Register Arguments::
454: * Scalar Return::
455: * Aggregate Return::
456: * Caller Saves::
457: * Function Entry::
458: * Profiling::
459:
460:
461: File: gcc.info, Node: Frame Layout, Next: Frame Registers, Up: Stack and Calling
462:
463: Basic Stack Layout
464: ------------------
465:
466: `STACK_GROWS_DOWNWARD'
467: Define this macro if pushing a word onto the stack moves the stack
468: pointer to a smaller address.
469:
470: When we say, "define this macro if ...," it means that the
471: compiler checks this macro only with `#ifdef' so the precise
472: definition used does not matter.
473:
474: `FRAME_GROWS_DOWNWARD'
475: Define this macro if the addresses of local variable slots are at
476: negative offsets from the frame pointer.
477:
478: `ARGS_GROW_DOWNWARD'
479: Define this macro if successive arguments to a function occupy
480: decreasing addresses on the stack.
481:
482: `STARTING_FRAME_OFFSET'
483: Offset from the frame pointer to the first local variable slot to
484: be allocated.
485:
486: If `FRAME_GROWS_DOWNWARD', find the next slot's offset by
487: subtracting the first slot's length from `STARTING_FRAME_OFFSET'.
488: Otherwise, it is found by adding the length of the first slot to
489: the value `STARTING_FRAME_OFFSET'.
490:
491: `STACK_POINTER_OFFSET'
492: Offset from the stack pointer register to the first location at
493: which outgoing arguments are placed. If not specified, the
494: default value of zero is used. This is the proper value for most
495: machines.
496:
497: If `ARGS_GROW_DOWNWARD', this is the offset to the location above
498: the first location at which outgoing arguments are placed.
499:
500: `FIRST_PARM_OFFSET (FUNDECL)'
501: Offset from the argument pointer register to the first argument's
502: address. On some machines it may depend on the data type of the
503: function.
504:
505: If `ARGS_GROW_DOWNWARD', this is the offset to the location above
506: the first argument's address.
507:
508: `STACK_DYNAMIC_OFFSET (FUNDECL)'
509: Offset from the stack pointer register to an item dynamically
510: allocated on the stack, e.g., by `alloca'.
511:
512: The default value for this macro is `STACK_POINTER_OFFSET' plus the
513: length of the outgoing arguments. The default is correct for most
514: machines. See `function.c' for details.
515:
516: `DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)'
517: A C expression whose value is RTL representing the address in a
518: stack frame where the pointer to the caller's frame is stored.
519: Assume that FRAMEADDR is an RTL expression for the address of the
520: stack frame itself.
521:
522: If you don't define this macro, the default is to return the value
523: of FRAMEADDR--that is, the stack frame address is also the address
524: of the stack word that points to the previous frame.
525:
526: `SERTUP_FRAME_ADDRESSES ()'
527: If defined, a C expression that produces the machine-specific code
528: to setup the stack so that arbitrary frames can be accessed. For
529: example, on the Sparc, we must flush all of the register windows
530: to the stack before we can access arbitrary stack frames. This
531: macro will seldom need to be defined.
532:
533: `RETURN_ADDR_RTX (COUNT, FRAMEADDR)'
534: A C expression whose value is RTL representing the value of the
535: return address for the frame COUNT steps up from the current frame.
536: fRAMEADDR is the frame pointer of the COUNT frame, or the frame
537: pointer of the COUNT - 1 frame if `RETURN_ADDR_IN_PREVIOUS_FRAME'
538: is defined.
539:
540: `RETURN_ADDR_IN_PREVIOUS_FRAME'
541: Define this if the return address of a particular stack frame is
542: accessed from the frame pointer of the previous stack frame.
543:
544:
545: File: gcc.info, Node: Frame Registers, Next: Elimination, Prev: Frame Layout, Up: Stack and Calling
546:
547: Registers That Address the Stack Frame
548: --------------------------------------
549:
550: `STACK_POINTER_REGNUM'
551: The register number of the stack pointer register, which must also
552: be a fixed register according to `FIXED_REGISTERS'. On most
553: machines, the hardware determines which register this is.
554:
555: `FRAME_POINTER_REGNUM'
556: The register number of the frame pointer register, which is used to
557: access automatic variables in the stack frame. On some machines,
558: the hardware determines which register this is. On other
559: machines, you can choose any register you wish for this purpose.
560:
561: `HARD_FRAME_POINTER_REGNUM'
562: On some machines the offset between the frame pointer and starting
563: offset of the automatic variables is not known until after register
564: allocation has been done (for example, because the saved registers
565: are between these two locations). On those machines,
566: `FRAME_POINTER_REGNUM' as a special, fixed register to be used
567: internally until the offset is known, and define
568: `HARD_FRAME_POINTER_REGNUM' to be the hard register used for the
569: frame pointer.
570:
571: You should define this macro only in the very rare circumstances
572: when it is not possible to calculate the offset between the frame
573: pointer and the automatic variables until after register
574: allocation has been completed. When this macro is defined, you
575: must also indicate in your definition of `ELIMINABLE_REGS' how to
576: eliminate `FRAME_POINTER_REGNUM' into either
577: `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'.
578:
579: Do not define this macro if it would be the same as
580: `FRAME_POINTER_REGNUM'.
581:
582: `ARG_POINTER_REGNUM'
583: The register number of the arg pointer register, which is used to
584: access the function's argument list. On some machines, this is
585: the same as the frame pointer register. On some machines, the
586: hardware determines which register this is. On other machines,
587: you can choose any register you wish for this purpose. If this is
588: not the same register as the frame pointer register, then you must
589: mark it as a fixed register according to `FIXED_REGISTERS', or
590: arrange to be able to eliminate it (*note Elimination::.).
591:
592: `STATIC_CHAIN_REGNUM'
593: `STATIC_CHAIN_INCOMING_REGNUM'
594: Register numbers used for passing a function's static chain
595: pointer. If register windows are used, the register number as
596: seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM',
597: while the register number as seen by the calling function is
598: `STATIC_CHAIN_REGNUM'. If these registers are the same,
599: `STATIC_CHAIN_INCOMING_REGNUM' need not be defined.
600:
601: The static chain register need not be a fixed register.
602:
603: If the static chain is passed in memory, these macros should not be
604: defined; instead, the next two macros should be defined.
605:
606: `STATIC_CHAIN'
607: `STATIC_CHAIN_INCOMING'
608: If the static chain is passed in memory, these macros provide rtx
609: giving `mem' expressions that denote where they are stored.
610: `STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as
611: seen by the calling and called functions, respectively. Often the
612: former will be at an offset from the stack pointer and the latter
613: at an offset from the frame pointer.
614:
615: The variables `stack_pointer_rtx', `frame_pointer_rtx', and
616: `arg_pointer_rtx' will have been initialized prior to the use of
617: these macros and should be used to refer to those items.
618:
619: If the static chain is passed in a register, the two previous
620: macros should be defined instead.
621:
622:
623: File: gcc.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling
624:
625: Eliminating Frame Pointer and Arg Pointer
626: -----------------------------------------
627:
628: `FRAME_POINTER_REQUIRED'
629: A C expression which is nonzero if a function must have and use a
630: frame pointer. This expression is evaluated in the reload pass.
631: If its value is nonzero the function will have a frame pointer.
632:
633: The expression can in principle examine the current function and
634: decide according to the facts, but on most machines the constant 0
635: or the constant 1 suffices. Use 0 when the machine allows code to
636: be generated with no frame pointer, and doing so saves some time
637: or space. Use 1 when there is no possible advantage to avoiding a
638: frame pointer.
639:
640: In certain cases, the compiler does not know how to produce valid
641: code without a frame pointer. The compiler recognizes those cases
642: and automatically gives the function a frame pointer regardless of
643: what `FRAME_POINTER_REQUIRED' says. You don't need to worry about
644: them.
645:
646: In a function that does not require a frame pointer, the frame
647: pointer register can be allocated for ordinary usage, unless you
648: mark it as a fixed register. See `FIXED_REGISTERS' for more
649: information.
650:
651: This macro is ignored and you do not need to define it if the
652: function `ELIMINABLE_REGS' is defined.
653:
654: `INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)'
655: A C statement to store in the variable DEPTH-VAR the difference
656: between the frame pointer and the stack pointer values immediately
657: after the function prologue. The value would be computed from
658: information such as the result of `get_frame_size ()' and the
659: tables of registers `regs_ever_live' and `call_used_regs'.
660:
661: If `ELIMINABLE_REGS' is defined, this macro will be not be used and
662: need not be defined. Otherwise, it must be defined even if
663: `FRAME_POINTER_REQUIRED' is defined to always be true; in that
664: case, you may set DEPTH-VAR to anything.
665:
666: `ELIMINABLE_REGS'
667: If defined, this macro specifies a table of register pairs used to
668: eliminate unneeded registers that point into the stack frame. If
669: it is not defined, the only elimination attempted by the compiler
670: is to replace references to the frame pointer with references to
671: the stack pointer.
672:
673: The definition of this macro is a list of structure
674: initializations, each of which specifies an original and
675: replacement register.
676:
677: On some machines, the position of the argument pointer is not
678: known until the compilation is completed. In such a case, a
679: separate hard register must be used for the argument pointer.
680: This register can be eliminated by replacing it with either the
681: frame pointer or the argument pointer, depending on whether or not
682: the frame pointer has been eliminated.
683:
684: In this case, you might specify:
685: #define ELIMINABLE_REGS \
686: {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
687: {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
688: {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
689:
690: Note that the elimination of the argument pointer with the stack
691: pointer is specified first since that is the preferred elimination.
692:
693: `CAN_ELIMINATE (FROM-REG, TO-REG)'
694: A C expression that returns non-zero if the compiler is allowed to
695: try to replace register number FROM-REG with register number
696: TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is
697: defined, and will usually be the constant 1, since most of the
698: cases preventing register elimination are things that the compiler
699: already knows about.
700:
701: `INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)'
702: This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It
703: specifies the initial difference between the specified pair of
704: registers. This macro must be defined if `ELIMINABLE_REGS' is
705: defined.
706:
707: `LONGJMP_RESTORE_FROM_STACK'
708: Define this macro if the `longjmp' function restores registers from
709: the stack frames, rather than from those saved specifically by
710: `setjmp'. Certain quantities must not be kept in registers across
711: a call to `setjmp' on such machines.
712:
713:
714: File: gcc.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling
715:
716: Passing Function Arguments on the Stack
717: ---------------------------------------
718:
719: The macros in this section control how arguments are passed on the
720: stack. See the following section for other macros that control passing
721: certain arguments in registers.
722:
723: `PROMOTE_PROTOTYPES'
724: Define this macro if an argument declared in a prototype as an
725: integral type smaller than `int' should actually be passed as an
726: `int'. In addition to avoiding errors in certain cases of
727: mismatch, it also makes for better code on certain machines.
728:
729: `PUSH_ROUNDING (NPUSHED)'
730: A C expression that is the number of bytes actually pushed onto the
731: stack when an instruction attempts to push NPUSHED bytes.
732:
733: If the target machine does not have a push instruction, do not
734: define this macro. That directs GNU CC to use an alternate
735: strategy: to allocate the entire argument block and then store the
736: arguments into it.
737:
738: On some machines, the definition
739:
740: #define PUSH_ROUNDING(BYTES) (BYTES)
741:
742: will suffice. But on other machines, instructions that appear to
743: push one byte actually push two bytes in an attempt to maintain
744: alignment. Then the definition should be
745:
746: #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
747:
748: `ACCUMULATE_OUTGOING_ARGS'
749: If defined, the maximum amount of space required for outgoing
750: arguments will be computed and placed into the variable
751: `current_function_outgoing_args_size'. No space will be pushed
752: onto the stack for each call; instead, the function prologue should
753: increase the stack frame size by this amount.
754:
755: Defining both `PUSH_ROUNDING' and `ACCUMULATE_OUTGOING_ARGS' is
756: not proper.
757:
758: `REG_PARM_STACK_SPACE (FNDECL)'
759: Define this macro if functions should assume that stack space has
760: been allocated for arguments even when their values are passed in
761: registers.
762:
763: The value of this macro is the size, in bytes, of the area
764: reserved for arguments passed in registers for the function
765: represented by FNDECL.
766:
767: This space can be allocated by the caller, or be a part of the
768: machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says
769: which.
770:
771: `MAYBE_REG_PARM_STACK_SPACE'
772: `FINAL_REG_PARM_STACK_SPACE (CONST_SIZE, VAR_SIZE)'
773: Define these macros in addition to the one above if functions might
774: allocate stack space for arguments even when their values are
775: passed in registers. These should be used when the stack space
776: allocated for arguments in registers is not a simple constant
777: independent of the function declaration.
778:
779: The value of the first macro is the size, in bytes, of the area
780: that we should initially assume would be reserved for arguments
781: passed in registers.
782:
783: The value of the second macro is the actual size, in bytes, of the
784: area that will be reserved for arguments passed in registers.
785: This takes two arguments: an integer representing the number of
786: bytes of fixed sized arguments on the stack, and a tree
787: representing the number of bytes of variable sized arguments on
788: the stack.
789:
790: When these macros are defined, `REG_PARM_STACK_SPACE' will only be
791: called for libcall functions, the current function, or for a
792: function being called when it is known that such stack space must
793: be allocated. In each case this value can be easily computed.
794:
795: When deciding whether a called function needs such stack space,
796: and how much space to reserve, GNU CC uses these two macros
797: instead of `REG_PARM_STACK_SPACE'.
798:
799: `OUTGOING_REG_PARM_STACK_SPACE'
800: Define this if it is the responsibility of the caller to allocate
801: the area reserved for arguments passed in registers.
802:
803: If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls
804: whether the space for these arguments counts in the value of
805: `current_function_outgoing_args_size'.
806:
807: `STACK_PARMS_IN_REG_PARM_AREA'
808: Define this macro if `REG_PARM_STACK_SPACE' is defined, but the
809: stack parameters don't skip the area specified by it.
810:
811: Normally, when a parameter is not passed in registers, it is
812: placed on the stack beyond the `REG_PARM_STACK_SPACE' area.
813: Defining this macro suppresses this behavior and causes the
814: parameter to be passed on the stack in its natural location.
815:
816: `RETURN_POPS_ARGS (FUNTYPE, STACK-SIZE)'
817: A C expression that should indicate the number of bytes of its own
818: arguments that a function pops on returning, or 0 if the function
819: pops no arguments and the caller must therefore pop them all after
820: the function returns.
821:
822: FUNTYPE is a C variable whose value is a tree node that describes
823: the function in question. Normally it is a node of type
824: `FUNCTION_TYPE' that describes the data type of the function.
825: From this it is possible to obtain the data types of the value and
826: arguments (if known).
827:
828: When a call to a library function is being considered, FUNTYPE
829: will contain an identifier node for the library function. Thus, if
830: you need to distinguish among various library functions, you can
831: do so by their names. Note that "library function" in this
832: context means a function used to perform arithmetic, whose name is
833: known specially in the compiler and was not mentioned in the C
834: code being compiled.
835:
836: STACK-SIZE is the number of bytes of arguments passed on the
837: stack. If a variable number of bytes is passed, it is zero, and
838: argument popping will always be the responsibility of the calling
839: function.
840:
841: On the Vax, all functions always pop their arguments, so the
842: definition of this macro is STACK-SIZE. On the 68000, using the
843: standard calling convention, no functions pop their arguments, so
844: the value of the macro is always 0 in this case. But an
845: alternative calling convention is available in which functions
846: that take a fixed number of arguments pop them but other functions
847: (such as `printf') pop nothing (the caller pops all). When this
848: convention is in use, FUNTYPE is examined to determine whether a
849: function takes a fixed number of arguments.
850:
851:
852: File: gcc.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling
853:
854: Passing Arguments in Registers
855: ------------------------------
856:
857: This section describes the macros which let you control how various
858: types of arguments are passed in registers or how they are arranged in
859: the stack.
860:
861: `FUNCTION_ARG (CUM, MODE, TYPE, NAMED)'
862: A C expression that controls whether a function argument is passed
863: in a register, and which register.
864:
865: The arguments are CUM, which summarizes all the previous
866: arguments; MODE, the machine mode of the argument; TYPE, the data
867: type of the argument as a tree node or 0 if that is not known
868: (which happens for C support library functions); and NAMED, which
869: is 1 for an ordinary argument and 0 for nameless arguments that
870: correspond to `...' in the called function's prototype.
871:
872: The value of the expression should either be a `reg' RTX for the
873: hard register in which to pass the argument, or zero to pass the
874: argument on the stack.
875:
876: For machines like the Vax and 68000, where normally all arguments
877: are pushed, zero suffices as a definition.
878:
879: The usual way to make the ANSI library `stdarg.h' work on a machine
880: where some arguments are usually passed in registers, is to cause
881: nameless arguments to be passed on the stack instead. This is done
882: by making `FUNCTION_ARG' return 0 whenever NAMED is 0.
883:
884: You may use the macro `MUST_PASS_IN_STACK (MODE, TYPE)' in the
885: definition of this macro to determine if this argument is of a
886: type that must be passed in the stack. If `REG_PARM_STACK_SPACE'
887: is not defined and `FUNCTION_ARG' returns non-zero for such an
888: argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is
889: defined, the argument will be computed in the stack and then
890: loaded into a register.
891:
892: `FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)'
893: Define this macro if the target machine has "register windows", so
894: that the register in which a function sees an arguments is not
895: necessarily the same as the one in which the caller passed the
896: argument.
897:
898: For such machines, `FUNCTION_ARG' computes the register in which
899: the caller passes the value, and `FUNCTION_INCOMING_ARG' should be
900: defined in a similar fashion to tell the function being called
901: where the arguments will arrive.
902:
903: If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
904: both purposes.
905:
906: `FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)'
907: A C expression for the number of words, at the beginning of an
908: argument, must be put in registers. The value must be zero for
909: arguments that are passed entirely in registers or that are
910: entirely pushed on the stack.
911:
912: On some machines, certain arguments must be passed partially in
913: registers and partially in memory. On these machines, typically
914: the first N words of arguments are passed in registers, and the
915: rest on the stack. If a multi-word argument (a `double' or a
916: structure) crosses that boundary, its first few words must be
917: passed in registers and the rest must be pushed. This macro tells
918: the compiler when this occurs, and how many of the words should go
919: in registers.
920:
921: `FUNCTION_ARG' for these arguments should return the first
922: register to be used by the caller for this argument; likewise
923: `FUNCTION_INCOMING_ARG', for the called function.
924:
925: `FUNCTION_ARG_PASS_BY_REFERENCE (CUM, MODE, TYPE, NAMED)'
926: A C expression that indicates when an argument must be passed by
927: reference. If nonzero for an argument, a copy of that argument is
928: made in memory and a pointer to the argument is passed instead of
929: the argument itself. The pointer is passed in whatever way is
930: appropriate for passing a pointer to that type.
931:
932: On machines where `REG_PARM_STACK_SPACE' is not defined, a suitable
933: definition of this macro might be
934: #define FUNCTION_ARG_PASS_BY_REFERENCE\
935: (CUM, MODE, TYPE, NAMED) \
936: MUST_PASS_IN_STACK (MODE, TYPE)
937:
938: `FUNCTION_ARG_CALLEE_COPIES (CUM, MODE, TYPE, NAMED)'
939: If defined, a C expression that indicates when it is the called
940: function's responsibility to make a copy of arguments passed by
941: invisible reference. Normally, the caller makes a copy and passes
942: the address of the copy to the routine being called. When
943: FUNCTION_ARG_CALLEE_COPIES is defined and is nonzero, the caller
944: does not make a copy. Instead, it passes a pointer to the "live"
945: value. The called function must not modify this value. If it can
946: be determined that the value won't be modified, it need not make a
947: copy; otherwise a copy must be made.
948:
949: `CUMULATIVE_ARGS'
950: A C type for declaring a variable that is used as the first
951: argument of `FUNCTION_ARG' and other related values. For some
952: target machines, the type `int' suffices and can hold the number
953: of bytes of argument so far.
954:
955: There is no need to record in `CUMULATIVE_ARGS' anything about the
956: arguments that have been passed on the stack. The compiler has
957: other variables to keep track of that. For target machines on
958: which all arguments are passed on the stack, there is no need to
959: store anything in `CUMULATIVE_ARGS'; however, the data structure
960: must exist and should not be empty, so use `int'.
961:
962: `INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME)'
963: A C statement (sans semicolon) for initializing the variable CUM
964: for the state at the beginning of the argument list. The variable
965: has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node
966: for the data type of the function which will receive the args, or 0
967: if the args are to a compiler support library function.
968:
969: When processing a call to a compiler support library function,
970: LIBNAME identifies which one. It is a `symbol_ref' rtx which
971: contains the name of the function, as a string. LIBNAME is 0 when
972: an ordinary C function call is being processed. Thus, each time
973: this macro is called, either LIBNAME or FNTYPE is nonzero, but
974: never both of them at once.
975:
976: `INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)'
977: Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of
978: finding the arguments for the function being compiled. If this
979: macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead.
980:
981: The value passed for LIBNAME is always 0, since library routines
982: with special calling conventions are never compiled with GNU CC.
983: The argument LIBNAME exists for symmetry with
984: `INIT_CUMULATIVE_ARGS'.
985:
986: `FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)'
987: A C statement (sans semicolon) to update the summarizer variable
988: CUM to advance past an argument in the argument list. The values
989: MODE, TYPE and NAMED describe that argument. Once this is done,
990: the variable CUM is suitable for analyzing the *following*
991: argument with `FUNCTION_ARG', etc.
992:
993: This macro need not do anything if the argument in question was
994: passed on the stack. The compiler knows how to track the amount
995: of stack space used for arguments without any special help.
996:
997: `FUNCTION_ARG_PADDING (MODE, TYPE)'
998: If defined, a C expression which determines whether, and in which
999: direction, to pad out an argument with extra space. The value
1000: should be of type `enum direction': either `upward' to pad above
1001: the argument, `downward' to pad below, or `none' to inhibit
1002: padding.
1003:
1004: The *amount* of padding is always just enough to reach the next
1005: multiple of `FUNCTION_ARG_BOUNDARY'; this macro does not control
1006: it.
1007:
1008: This macro has a default definition which is right for most
1009: systems. For little-endian machines, the default is to pad
1010: upward. For big-endian machines, the default is to pad downward
1011: for an argument of constant size shorter than an `int', and upward
1012: otherwise.
1013:
1014: `FUNCTION_ARG_BOUNDARY (MODE, TYPE)'
1015: If defined, a C expression that gives the alignment boundary, in
1016: bits, of an argument with the specified mode and type. If it is
1017: not defined, `PARM_BOUNDARY' is used for all arguments.
1018:
1019: `FUNCTION_ARG_REGNO_P (REGNO)'
1020: A C expression that is nonzero if REGNO is the number of a hard
1021: register in which function arguments are sometimes passed. This
1022: does *not* include implicit arguments such as the static chain and
1023: the structure-value address. On many machines, no registers can be
1024: used for this purpose since all function arguments are pushed on
1025: the stack.
1026:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.