![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-12 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-12 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: Storage Layout, Next: Type Layout, Prev: Run-time Target, Up: Machine Macros
28:
29: Storage Layout
30: ==============
31:
32: Note that the definitions of the macros in this table which are
33: sizes or alignments measured in bits do not need to be constant. They
34: can be C expressions that refer to static variables, such as the
35: `target_flags'. *Note Run-time Target::.
36:
37: `BITS_BIG_ENDIAN'
38: Define this macro to be the value 1 if the most significant bit
39: in a byte has the lowest number; otherwise define it to be the
40: value zero. This means that bit-field instructions count from
41: the most significant bit. If the machine has no bit-field
42: instructions, this macro is irrelevant.
43:
44: This macro does not affect the way structure fields are packed
45: into bytes or words; that is controlled by `BYTES_BIG_ENDIAN'.
46:
47: `BYTES_BIG_ENDIAN'
48: Define this macro to be 1 if the most significant byte in a word
49: has the lowest number.
50:
51: `WORDS_BIG_ENDIAN'
52: Define this macro to be 1 if, in a multiword object, the most
53: significant word has the lowest number.
54:
55: `BITS_PER_UNIT'
56: Number of bits in an addressable storage unit (byte); normally 8.
57:
58: `BITS_PER_WORD'
59: Number of bits in a word; normally 32.
60:
61: `MAX_BITS_PER_WORD'
62: Maximum number of bits in a word. If this is undefined, the
63: default is `BITS_PER_WORD'. Otherwise, it is the constant value
64: that is the largest value that `BITS_PER_WORD' can have at
65: run-time.
66:
67: `UNITS_PER_WORD'
68: Number of storage units in a word; normally 4.
69:
70: `POINTER_SIZE'
71: Width of a pointer, in bits.
72:
73: `PARM_BOUNDARY'
74: Normal alignment required for function parameters on the stack, in
75: bits. All stack parameters receive least this much alignment
76: regardless of data type. On most machines, this is the same as
77: the size of an integer.
78:
79: `STACK_BOUNDARY'
80: Define this macro if you wish to preserve a certain alignment for
81: the stack pointer. The definition is a C expression for the
82: desired alignment (measured in bits).
83:
84: If `PUSH_ROUNDING' is not defined, the stack will always be
85: aligned to the specified boundary. If `PUSH_ROUNDING' is defined
86: and specifies a less strict alignment than `STACK_BOUNDARY', the
87: stack may be momentarily unaligned while pushing arguments.
88:
89: `FUNCTION_BOUNDARY'
90: Alignment required for a function entry point, in bits.
91:
92: `BIGGEST_ALIGNMENT'
93: Biggest alignment that any data type can require on this machine,
94: in bits.
95:
96: `BIGGEST_FIELD_ALIGNMENT'
97: Biggest alignment that any structure field can require on this
98: machine, in bits.
99:
100: `MAX_OFILE_ALIGNMENT'
101: Biggest alignment supported by the object file format of this
102: machine. Use this macro to limit the alignment which can be
103: specified using the `__attribute__ ((aligned (N)))' construct.
104: If not defined, the default value is `BIGGEST_ALIGNMENT'.
105:
106: `DATA_ALIGNMENT (TYPE, BASIC-ALIGN)'
107: If defined, a C expression to compute the alignment for a static
108: variable. TYPE is the data type, and BASIC-ALIGN is the
109: alignment that the object would ordinarily have. The value of
110: this macro is used instead of that alignment to align the object.
111:
112: If this macro is not defined, then BASIC-ALIGN is used.
113:
114: One use of this macro is to increase alignment of medium-size
115: data to make it all fit in fewer cache lines. Another is to
116: cause character arrays to be word-aligned so that `strcpy' calls
117: that copy constants to character arrays can be done inline.
118:
119: `CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN)'
120: If defined, a C expression to compute the alignment given to a
121: constant that is being placed in memory. CONSTANT is the
122: constant and BASIC-ALIGN is the alignment that the object would
123: ordinarily have. The value of this macro is used instead of that
124: alignment to align the object.
125:
126: If this macro is not defined, then BASIC-ALIGN is used.
127:
128: The typical use of this macro is to increase alignment for string
129: constants to be word aligned so that `strcpy' calls that copy
130: constants can be done inline.
131:
132: `EMPTY_FIELD_BOUNDARY'
133: Alignment in bits to be given to a structure bit field that
134: follows an empty field such as `int : 0;'.
135:
136: `STRUCTURE_SIZE_BOUNDARY'
137: Number of bits which any structure or union's size must be a
138: multiple of. Each structure or union's size is rounded up to a
139: multiple of this.
140:
141: If you do not define this macro, the default is the same as
142: `BITS_PER_UNIT'.
143:
144: `STRICT_ALIGNMENT'
145: Define this if instructions will fail to work if given data not
146: on the nominal alignment. If instructions will merely go slower
147: in that case, do not define this macro.
148:
149: `PCC_BITFIELD_TYPE_MATTERS'
150: Define this if you wish to imitate the way many other C compilers
151: handle alignment of bitfields and the structures that contain
152: them.
153:
154: The behavior is that the type written for a bitfield (`int',
155: `short', or other integer type) imposes an alignment for the
156: entire structure, as if the structure really did contain an
157: ordinary field of that type. In addition, the bitfield is placed
158: within the structure so that it would fit within such a field,
159: not crossing a boundary for it.
160:
161: Thus, on most machines, a bitfield whose type is written as `int'
162: would not cross a four-byte boundary, and would force four-byte
163: alignment for the whole structure. (The alignment used may not
164: be four bytes; it is controlled by the other alignment
165: parameters.)
166:
167: If the macro is defined, its definition should be a C expression;
168: a nonzero value for the expression enables this behavior.
169:
170: Note that if this macro is not defined, or its value is zero, some
171: bitfields may cross more than one alignment boundary. The
172: compiler can support such references if there are `insv', `extv',
173: and `extzv' insns that can directly reference memory.
174:
175: The other known way of making bitfields work is to define
176: `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then
177: every structure can be accessed with fullwords.
178:
179: Unless the machine has bitfield instructions or you define
180: `STRUCTURE_SIZE_BOUNDARY' that way, you must define
181: `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value.
182:
183: `BITFIELD_NBYTES_LIMITED'
184: Like PCC_BITFIELD_TYPE_MATTERS except that its effect is limited
185: to aligning a bitfield within the structure.
186:
187: `ROUND_TYPE_SIZE (STRUCT, SIZE, ALIGN)'
188: Define this macro as an expression for the overall size of a
189: structure (given by STRUCT as a tree node) when the size computed
190: from the fields is SIZE and the alignment is ALIGN.
191:
192: The default is to round SIZE up to a multiple of ALIGN.
193:
194: `ROUND_TYPE_ALIGN (STRUCT, COMPUTED, SPECIFIED)'
195: Define this macro as an expression for the alignment of a
196: structure (given by STRUCT as a tree node) if the alignment
197: computed in the usual way is COMPUTED and the alignment
198: explicitly specified was SPECIFIED.
199:
200: The default is to use SPECIFIED if it is larger; otherwise, use
201: the smaller of COMPUTED and `BIGGEST_ALIGNMENT'
202:
203: `MAX_FIXED_MODE_SIZE'
204: An integer expression for the size in bits of the largest integer
205: machine mode that should actually be used. All integer machine
206: modes of this size or smaller can be used for structures and
207: unions with the appropriate sizes. If this macro is undefined,
208: `GET_MODE_BITSIZE (DImode)' is assumed.
209:
210: `CHECK_FLOAT_VALUE (MODE, VALUE)'
211: A C statement to validate the value VALUE (of type `double') for
212: mode MODE. This means that you check whether VALUE fits within
213: the possible range of values for mode MODE on this target
214: machine. The mode MODE is always `SFmode' or `DFmode'.
215:
216: If VALUE is not valid, you should call `error' to print an error
217: message and then assign some valid value to VALUE. Allowing an
218: invalid value to go through the compiler can produce incorrect
219: assembler code which may even cause Unix assemblers to crash.
220:
221: This macro need not be defined if there is no work for it to do.
222:
223: `TARGET_FLOAT_FORMAT'
224: A code distinguishing the floating point format of the target
225: machine. There are three defined values:
226:
227: `IEEE_FLOAT_FORMAT'
228: This code indicates IEEE floating point. It is the default;
229: there is no need to define this macro when the format is
230: IEEE.
231:
232: `VAX_FLOAT_FORMAT'
233: This code indicates the peculiar format used on the Vax.
234:
235: `UNKNOWN_FLOAT_FORMAT'
236: This code indicates any other format.
237:
238: The value of this macro is compared with `HOST_FLOAT_FORMAT'
239: (*note Config::.) to determine whether the target machine has the
240: same format as the host machine. If any other formats are
241: actually in use on supported machines, new codes should be
242: defined for them.
243:
244:
245: File: gcc.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Machine Macros
246:
247: Layout of Source Language Data Types
248: ====================================
249:
250: These macros define the sizes and other characteristics of the
251: standard basic data types used in programs being compiled. Unlike the
252: macros in the previous section, these apply to specific features of C
253: and related languages, rather than to fundamental aspects of storage
254: layout.
255:
256: `INT_TYPE_SIZE'
257: A C expression for the size in bits of the type `int' on the
258: target machine. If you don't define this, the default is one
259: word.
260:
261: `SHORT_TYPE_SIZE'
262: A C expression for the size in bits of the type `short' on the
263: target machine. If you don't define this, the default is half a
264: word. (If this would be less than one storage unit, it is
265: rounded up to one unit.)
266:
267: `LONG_TYPE_SIZE'
268: A C expression for the size in bits of the type `long' on the
269: target machine. If you don't define this, the default is one
270: word.
271:
272: `LONG_LONG_TYPE_SIZE'
273: A C expression for the size in bits of the type `long long' on the
274: target machine. If you don't define this, the default is two
275: words.
276:
277: `CHAR_TYPE_SIZE'
278: A C expression for the size in bits of the type `char' on the
279: target machine. If you don't define this, the default is one
280: quarter of a word. (If this would be less than one storage unit,
281: it is rounded up to one unit.)
282:
283: `FLOAT_TYPE_SIZE'
284: A C expression for the size in bits of the type `float' on the
285: target machine. If you don't define this, the default is one
286: word.
287:
288: `DOUBLE_TYPE_SIZE'
289: A C expression for the size in bits of the type `double' on the
290: target machine. If you don't define this, the default is two
291: words.
292:
293: `LONG_DOUBLE_TYPE_SIZE'
294: A C expression for the size in bits of the type `long double' on
295: the target machine. If you don't define this, the default is two
296: words.
297:
298: `DEFAULT_SIGNED_CHAR'
299: An expression whose value is 1 or 0, according to whether the type
300: `char' should be signed or unsigned by default. The user can
301: always override this default with the options `-fsigned-char' and
302: `-funsigned-char'.
303:
304: `DEFAULT_SHORT_ENUMS'
305: A C expression to determine whether to give an `enum' type only
306: as many bytes as it takes to represent the range of possible
307: values of that type. A nonzero value means to do that; a zero
308: value means all `enum' types should be allocated like `int'.
309:
310: If you don't define the macro, the default is 0.
311:
312: `SIZE_TYPE'
313: A C expression for a string describing the name of the data type
314: to use for size values. The typedef name `size_t' is defined
315: using the contents of the string.
316:
317: The string can contain more than one keyword. If so, separate
318: them with spaces, and write first any length keyword, then
319: `unsigned' if appropriate, and finally `int'. The string must
320: exactly match one of the data type names defined in the function
321: `init_decl_processing' in the file `c-decl.c'. You may not omit
322: `int' or change the order--that would cause the compiler to crash
323: on startup.
324:
325: If you don't define this macro, the default is `"long unsigned
326: int"'.
327:
328: `PTRDIFF_TYPE'
329: A C expression for a string describing the name of the data type
330: to use for the result of subtracting two pointers. The typedef
331: name `ptrdiff_t' is defined using the contents of the string. See
332: `SIZE_TYPE' above for more information.
333:
334: If you don't define this macro, the default is `"long int"'.
335:
336: `WCHAR_TYPE'
337: A C expression for a string describing the name of the data type
338: to use for wide characters. The typedef name `wchar_t' is
339: defined using the contents of the string. See `SIZE_TYPE' above
340: for more information.
341:
342: If you don't define this macro, the default is `"int"'.
343:
344: `WCHAR_TYPE_SIZE'
345: A C expression for the size in bits of the data type for wide
346: characters. This is used in `cpp', which cannot make use of
347: `WCHAR_TYPE'.
348:
349: `OBJC_INT_SELECTORS'
350: Define this macro if the type of Objective C selectors should be
351: `int'.
352:
353: If this macro is not defined, then selectors should have the type
354: `struct objc_selector *'.
355:
356: `OBJC_NONUNIQUE_SELECTORS'
357: Define this macro if Objective C selector-references will be made
358: unique by the linker (this is the default). In this case, each
359: selector-reference will be given a separate assembler label.
360: Otherwise, the selector-references will be gathered into an array
361: with a single assembler label.
362:
363: `MULTIBYTE_CHARS'
364: Define this macro to enable support for multibyte characters in
365: the input to GNU CC. This requires that the host system support
366: the ANSI C library functions for converting multibyte characters
367: to wide characters.
368:
369: `TARGET_BELL'
370: A C constant expression for the integer value for escape sequence
371: `\a'.
372:
373: `TARGET_BS'
374: `TARGET_TAB'
375: `TARGET_NEWLINE'
376: C constant expressions for the integer values for escape sequences
377: `\b', `\t' and `\n'.
378:
379: `TARGET_VT'
380: `TARGET_FF'
381: `TARGET_CR'
382: C constant expressions for the integer values for escape sequences
383: `\v', `\f' and `\r'.
384:
385:
386: File: gcc.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Machine Macros
387:
388: Register Usage
389: ==============
390:
391: This section explains how to describe what registers the target
392: machine has, and how (in general) they can be used.
393:
394: The description of which registers a specific instruction can use is
395: done with register classes; see *Note Register Classes::. For
396: information on using registers to access a stack frame, see *Note
397: Frame Registers::. For passing values in registers, see *Note
398: Register Arguments::. For returning values in registers, see *Note
399: Scalar Return::.
400:
401: * Menu:
402:
403: * Register Basics:: Number and kinds of registers.
404: * Allocation Order:: Order in which registers are allocated.
405: * Values in Registers:: What kinds of values each reg can hold.
406: * Leaf Functions:: Renumbering registers for leaf functions.
407: * Stack Registers:: Handling a register stack such as 80387.
408: * Obsolete Register Macros:: Macros formerly used for the 80387.
409:
410:
411: File: gcc.info, Node: Register Basics, Next: Allocation Order, Up: Registers
412:
413: Basic Characteristics of Registers
414: ----------------------------------
415:
416: `FIRST_PSEUDO_REGISTER'
417: Number of hardware registers known to the compiler. They receive
418: numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first
419: pseudo register's number really is assigned the number
420: `FIRST_PSEUDO_REGISTER'.
421:
422: `FIXED_REGISTERS'
423: An initializer that says which registers are used for fixed
424: purposes all throughout the compiled code and are therefore not
425: available for general allocation. These would include the stack
426: pointer, the frame pointer (except on machines where that can be
427: used as a general register when no frame pointer is needed), the
428: program counter on machines where that is considered one of the
429: addressable registers, and any other numbered register with a
430: standard use.
431:
432: This information is expressed as a sequence of numbers, separated
433: by commas and surrounded by braces. The Nth number is 1 if
434: register N is fixed, 0 otherwise.
435:
436: The table initialized from this macro, and the table initialized
437: by the following one, may be overridden at run time either
438: automatically, by the actions of the macro
439: `CONDITIONAL_REGISTER_USAGE', or by the user with the command
440: options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'.
441:
442: `CALL_USED_REGISTERS'
443: Like `FIXED_REGISTERS' but has 1 for each register that is
444: clobbered (in general) by function calls as well as for fixed
445: registers. This macro therefore identifies the registers that
446: are not available for general allocation of values that must live
447: across function calls.
448:
449: If a register has 0 in `CALL_USED_REGISTERS', the compiler
450: automatically saves it on function entry and restores it on
451: function exit, if the register is used within the function.
452:
453: `CONDITIONAL_REGISTER_USAGE'
454: Zero or more C statements that may conditionally modify two
455: variables `fixed_regs' and `call_used_regs' (both of type `char
456: []') after they have been initialized from the two preceding
457: macros.
458:
459: This is necessary in case the fixed or call-clobbered registers
460: depend on target flags.
461:
462: You need not define this macro if it has no work to do.
463:
464: If the usage of an entire class of registers depends on the target
465: flags, you may indicate this to GCC by using this macro to modify
466: `fixed_regs' and `call_used_regs' to 1 for each of the registers
467: in the classes which should not be used by GCC. Also define the
468: macro `REG_CLASS_FROM_LETTER' to return `NO_REGS' if it is called
469: with a letter for a class that shouldn't be used.
470:
471: (However, if this class is not included in `GENERAL_REGS' and all
472: of the insn patterns whose constraints permit this class are
473: controlled by target switches, then GCC will automatically avoid
474: using these registers when the target switches are opposed to
475: them.)
476:
477: `NON_SAVING_SETJMP'
478: If this macro is defined and has a nonzero value, it means that
479: `setjmp' and related functions fail to save the registers, or that
480: `longjmp' fails to restore them. To compensate, the compiler
481: avoids putting variables in registers in functions that use
482: `setjmp'.
483:
484:
485: File: gcc.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers
486:
487: Order of Allocation of Registers
488: --------------------------------
489:
490: `REG_ALLOC_ORDER'
491: If defined, an initializer for a vector of integers, containing
492: the numbers of hard registers in the order in which GNU CC should
493: prefer to use them (from most preferred to least).
494:
495: If this macro is not defined, registers are used lowest numbered
496: first (all else being equal).
497:
498: One use of this macro is on machines where the highest numbered
499: registers must always be saved and the save-multiple-registers
500: instruction supports only sequences of consecutive registers. On
501: such machines, define `REG_ALLOC_ORDER' to be an initializer that
502: lists the highest numbered allocatable register first.
503:
504: `ORDER_REGS_FOR_LOCAL_ALLOC'
505: A C statement (sans semicolon) to choose the order in which to
506: allocate hard registers for pseudo-registers local to a basic
507: block.
508:
509: Store the desired order of registers in the array
510: `reg_alloc_order'. Element 0 should be the register to allocate
511: first; element 1, the next register; and so on.
512:
513: The macro body should not assume anything about the contents of
514: `reg_alloc_order' before execution of the macro.
515:
516: On most machines, it is not necessary to define this macro.
517:
518:
519: File: gcc.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers
520:
521: How Values Fit in Registers
522: ---------------------------
523:
524: This section discusses the macros that describe which kinds of
525: values (specifically, which machine modes) each register can hold, and
526: how many consecutive registers are needed for a given mode.
527:
528: `HARD_REGNO_NREGS (REGNO, MODE)'
529: A C expression for the number of consecutive hard registers,
530: starting at register number REGNO, required to hold a value of
531: mode MODE.
532:
533: On a machine where all registers are exactly one word, a suitable
534: definition of this macro is
535:
536: #define HARD_REGNO_NREGS(REGNO, MODE) \
537: ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
538: / UNITS_PER_WORD))
539:
540: `HARD_REGNO_MODE_OK (REGNO, MODE)'
541: A C expression that is nonzero if it is permissible to store a
542: value of mode MODE in hard register number REGNO (or in several
543: registers starting with that one). For a machine where all
544: registers are equivalent, a suitable definition is
545:
546: #define HARD_REGNO_MODE_OK(REGNO, MODE) 1
547:
548: It is not necessary for this macro to check for the numbers of
549: fixed registers, because the allocation mechanism considers them
550: to be always occupied.
551:
552: On some machines, double-precision values must be kept in even/odd
553: register pairs. The way to implement that is to define this macro
554: to reject odd register numbers for such modes.
555:
556: The minimum requirement for a mode to be OK in a register is that
557: the `movMODE' instruction pattern support moves between the
558: register and any other hard register for which the mode is OK;
559: and that moving a value into the register and back out not alter
560: it.
561:
562: Since the same instruction used to move `SImode' will work for all
563: narrower integer modes, it is not necessary on any machine for
564: `HARD_REGNO_MODE_OK' to distinguish between these modes, provided
565: you define patterns `movhi', etc., to take advantage of this.
566: This is useful because of the interaction between
567: `HARD_REGNO_MODE_OK' and `MODES_TIEABLE_P'; it is very desirable
568: for all integer modes to be tieable.
569:
570: Many machines have special registers for floating point
571: arithmetic. Often people assume that floating point machine
572: modes are allowed only in floating point registers. This is not
573: true. Any registers that can hold integers can safely *hold* a
574: floating point machine mode, whether or not floating arithmetic
575: can be done on it in those registers. Integer move instructions
576: can be used to move the values.
577:
578: On some machines, though, the converse is true: fixed-point
579: machine modes may not go in floating registers. This is true if
580: the floating registers normalize any value stored in them,
581: because storing a non-floating value there would garble it. In
582: this case, `HARD_REGNO_MODE_OK' should reject fixed-point machine
583: modes in floating registers. But if the floating registers do
584: not automatically normalize, if you can store any bit pattern in
585: one and retrieve it unchanged without a trap, then any machine
586: mode may go in a floating register and this macro should say so.
587:
588: The primary significance of special floating registers is rather
589: that they are the registers acceptable in floating point
590: arithmetic instructions. However, this is of no concern to
591: `HARD_REGNO_MODE_OK'. You handle it by writing the proper
592: constraints for those instructions.
593:
594: On some machines, the floating registers are especially slow to
595: access, so that it is better to store a value in a stack frame
596: than in such a register if floating point arithmetic is not being
597: done. As long as the floating registers are not in class
598: `GENERAL_REGS', they will not be used unless some pattern's
599: constraint asks for one.
600:
601: `MODES_TIEABLE_P (MODE1, MODE2)'
602: A C expression that is nonzero if it is desirable to choose
603: register allocation so as to avoid move instructions between a
604: value of mode MODE1 and a value of mode MODE2.
605:
606: If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R,
607: MODE2)' are ever different for any R, then `MODES_TIEABLE_P
608: (MODE1, MODE2)' must be zero.
609:
610:
611: File: gcc.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers
612:
613: Handling Leaf Functions
614: -----------------------
615:
616: On some machines, a leaf function (i.e., one which make no calls)
617: can run more efficiently if it does not make its own register window.
618: Often this means it is required to receive its arguments in the
619: registers where they are passed by the caller, instead of the
620: registers where they would normally arrive. Also, the leaf function
621: may use only those registers for its own variables and temporaries.
622:
623: GNU CC assigns register numbers before it knows whether the
624: function is suitable for leaf function treatment. So it needs to
625: renumber the registers in order to output a leaf function. The
626: following macros accomplish this.
627:
628: `LEAF_REGISTERS'
629: A C initializer for a vector, indexed by hard register number,
630: which contains 1 for a register that is allowable in a candidate
631: for leaf function treatment.
632:
633: If leaf function treatment involves renumbering the registers,
634: then the registers marked here should be the ones before
635: renumbering--those that GNU CC would ordinarily allocate. The
636: registers which will actually be used in the assembler code,
637: after renumbering, should not be marked with 1 in this vector.
638:
639: Define this macro only if the target machine offers a way to
640: optimize the treatment of leaf functions.
641:
642: `LEAF_REG_REMAP (REGNO)'
643: A C expression whose value is the register number to which REGNO
644: should be renumbered, when a function is treated as a leaf
645: function.
646:
647: If REGNO is a register number which should not appear in a leaf
648: function before renumbering, then the expression should yield -1,
649: which will cause the compiler to abort.
650:
651: Define this macro only if the target machine offers a way to
652: optimize the treatment of leaf functions, and registers need to
653: be renumbered to do this.
654:
655: `REG_LEAF_ALLOC_ORDER'
656: If defined, an initializer for a vector of integers, containing
657: the numbers of hard registers in the order in which the GNU CC
658: should prefer to use them (from most preferred to least) in a
659: leaf function. If this macro is not defined, REG_ALLOC_ORDER is
660: used for both non-leaf and leaf-functions.
661:
662: Normally, it is necessary for `FUNCTION_PROLOGUE' and
663: `FUNCTION_EPILOGUE' to treat leaf functions specially. The C variable
664: `leaf_function' is nonzero for such a function.
665:
666:
667: File: gcc.info, Node: Stack Registers, Next: Obsolete Register Macros, Prev: Leaf Functions, Up: Registers
668:
669: Registers That Form a Stack
670: ---------------------------
671:
672: There are special features to handle computers where some of the
673: "registers" form a stack, as in the 80387 coprocessor for the 80386.
674: Stack registers are normally written by pushing onto the stack, and are
675: numbered relative to the top of the stack.
676:
677: Currently, GNU CC can only handle one group of stack-like
678: registers, and they must be consecutively numbered.
679:
680: `STACK_REGS'
681: Define this if the machine has any stack-like registers.
682:
683: `FIRST_STACK_REG'
684: The number of the first stack-like register. This one is the top
685: of the stack.
686:
687: `LAST_STACK_REG'
688: The number of the last stack-like register. This one is the
689: bottom of the stack.
690:
691:
692: File: gcc.info, Node: Obsolete Register Macros, Prev: Stack Registers, Up: Registers
693:
694: Obsolete Macros for Controlling Register Usage
695: ----------------------------------------------
696:
697: These features do not work very well. They exist because they used
698: to be required to generate correct code for the 80387 coprocessor of
699: the 80386. They are no longer used by that machine description and
700: may be removed in a later version of the compiler. Don't use them!
701:
702: `OVERLAPPING_REGNO_P (REGNO)'
703: If defined, this is a C expression whose value is nonzero if hard
704: register number REGNO is an overlapping register. This means a
705: hard register which overlaps a hard register with a different
706: number. (Such overlap is undesirable, but occasionally it allows
707: a machine to be supported which otherwise could not be.) This
708: macro must return nonzero for *all* the registers which overlap
709: each other. GNU CC can use an overlapping register only in
710: certain limited ways. It can be used for allocation within a
711: basic block, and may be spilled for reloading; that is all.
712:
713: If this macro is not defined, it means that none of the hard
714: registers overlap each other. This is the usual situation.
715:
716: `INSN_CLOBBERS_REGNO_P (INSN, REGNO)'
717: If defined, this is a C expression whose value should be nonzero
718: if the insn INSN has the effect of mysteriously clobbering the
719: contents of hard register number REGNO. By "mysterious" we mean
720: that the insn's RTL expression doesn't describe such an effect.
721:
722: If this macro is not defined, it means that no insn clobbers
723: registers mysteriously. This is the usual situation; all else
724: being equal, it is best for the RTL expression to show all the
725: activity.
726:
727: `PRESERVE_DEATH_INFO_REGNO_P (REGNO)'
728: If defined, this is a C expression whose value is nonzero if
729: accurate `REG_DEAD' notes are needed for hard register number
730: REGNO at the time of outputting the assembler code. When this is
731: so, a few optimizations that take place after register allocation
732: and could invalidate the death notes are not done when this
733: register is involved.
734:
735: You would arrange to preserve death info for a register when some
736: of the code in the machine description which is executed to write
737: the assembler code looks at the death notes. This is necessary
738: only when the actual hardware feature which GNU CC thinks of as a
739: register is not actually a register of the usual sort. (It
740: might, for example, be a hardware stack.)
741:
742: If this macro is not defined, it means that no death notes need
743: to be preserved. This is the usual situation.
744:
745:
746: File: gcc.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Machine Macros
747:
748: Register Classes
749: ================
750:
751: On many machines, the numbered registers are not all equivalent.
752: For example, certain registers may not be allowed for indexed
753: addressing; certain registers may not be allowed in some instructions.
754: These machine restrictions are described to the compiler using
755: "register classes".
756:
757: You define a number of register classes, giving each one a name and
758: saying which of the registers belong to it. Then you can specify
759: register classes that are allowed as operands to particular
760: instruction patterns.
761:
762: In general, each register will belong to several classes. In fact,
763: one class must be named `ALL_REGS' and contain all the registers.
764: Another class must be named `NO_REGS' and contain no registers. Often
765: the union of two classes will be another class; however, this is not
766: required.
767:
768: One of the classes must be named `GENERAL_REGS'. There is nothing
769: terribly special about the name, but the operand constraint letters
770: `r' and `g' specify this class. If `GENERAL_REGS' is the same as
771: `ALL_REGS', just define it as a macro which expands to `ALL_REGS'.
772:
773: Order the classes so that if class X is contained in class Y then X
774: has a lower class number than Y.
775:
776: The way classes other than `GENERAL_REGS' are specified in operand
777: constraints is through machine-dependent operand constraint letters.
778: You can define such letters to correspond to various classes, then use
779: them in operand constraints.
780:
781: You should define a class for the union of two classes whenever some
782: instruction allows both classes. For example, if an instruction allows
783: either a floating point (coprocessor) register or a general register
784: for a certain operand, you should define a class
785: `FLOAT_OR_GENERAL_REGS' which includes both of them. Otherwise you
786: will get suboptimal code.
787:
788: You must also specify certain redundant information about the
789: register classes: for each class, which classes contain it and which
790: ones are contained in it; for each pair of classes, the largest class
791: contained in their union.
792:
793: When a value occupying several consecutive registers is expected in
794: a certain class, all the registers used must belong to that class.
795: Therefore, register classes cannot be used to enforce a requirement for
796: a register pair to start with an even-numbered register. The way to
797: specify this requirement is with `HARD_REGNO_MODE_OK'.
798:
799: Register classes used for input-operands of bitwise-and or shift
800: instructions have a special requirement: each such class must have, for
801: each fixed-point machine mode, a subclass whose registers can transfer
802: that mode to or from memory. For example, on some machines, the
803: operations for single-byte values (`QImode') are limited to certain
804: registers. When this is so, each register class that is used in a
805: bitwise-and or shift instruction must have a subclass consisting of
806: registers from which single-byte values can be loaded or stored. This
807: is so that `PREFERRED_RELOAD_CLASS' can always have a possible value
808: to return.
809:
810: `enum reg_class'
811: An enumeral type that must be defined with all the register class
812: names as enumeral values. `NO_REGS' must be first. `ALL_REGS'
813: must be the last register class, followed by one more enumeral
814: value, `LIM_REG_CLASSES', which is not a register class but rather
815: tells how many classes there are.
816:
817: Each register class has a number, which is the value of casting
818: the class name to type `int'. The number serves as an index in
819: many of the tables described below.
820:
821: `N_REG_CLASSES'
822: The number of distinct register classes, defined as follows:
823:
824: #define N_REG_CLASSES (int) LIM_REG_CLASSES
825:
826: `REG_CLASS_NAMES'
827: An initializer containing the names of the register classes as C
828: string constants. These names are used in writing some of the
829: debugging dumps.
830:
831: `REG_CLASS_CONTENTS'
832: An initializer containing the contents of the register classes,
833: as integers which are bit masks. The Nth integer specifies the
834: contents of class N. The way the integer MASK is interpreted is
835: that register R is in the class if `MASK & (1 << R)' is 1.
836:
837: When the machine has more than 32 registers, an integer does not
838: suffice. Then the integers are replaced by sub-initializers,
839: braced groupings containing several integers. Each
840: sub-initializer must be suitable as an initializer for the type
841: `HARD_REG_SET' which is defined in `hard-reg-set.h'.
842:
843: `REGNO_REG_CLASS (REGNO)'
844: A C expression whose value is a register class containing hard
845: register REGNO. In general there is more that one such class;
846: choose a class which is "minimal", meaning that no smaller class
847: also contains the register.
848:
849: `BASE_REG_CLASS'
850: A macro whose definition is the name of the class to which a valid
851: base register must belong. A base register is one used in an
852: address which is the register value plus a displacement.
853:
854: `INDEX_REG_CLASS'
855: A macro whose definition is the name of the class to which a valid
856: index register must belong. An index register is one used in an
857: address where its value is either multiplied by a scale factor or
858: added to another register (as well as added to a displacement).
859:
860: `REG_CLASS_FROM_LETTER (CHAR)'
861: A C expression which defines the machine-dependent operand
862: constraint letters for register classes. If CHAR is such a
863: letter, the value should be the register class corresponding to
864: it. Otherwise, the value should be `NO_REGS'.
865:
866: `REGNO_OK_FOR_BASE_P (NUM)'
867: A C expression which is nonzero if register number NUM is
868: suitable for use as a base register in operand addresses. It may
869: be either a suitable hard register or a pseudo register that has
870: been allocated such a hard register.
871:
872: `REGNO_OK_FOR_INDEX_P (NUM)'
873: A C expression which is nonzero if register number NUM is
874: suitable for use as an index register in operand addresses. It
875: may be either a suitable hard register or a pseudo register that
876: has been allocated such a hard register.
877:
878: The difference between an index register and a base register is
879: that the index register may be scaled. If an address involves
880: the sum of two registers, neither one of them scaled, then either
881: one may be labeled the "base" and the other the "index"; but
882: whichever labeling is used must fit the machine's constraints of
883: which registers may serve in each capacity. The compiler will
884: try both labelings, looking for one that is valid, and will
885: reload one or both registers only if neither labeling works.
886:
887: `PREFERRED_RELOAD_CLASS (X, CLASS)'
888: A C expression that places additional restrictions on the
889: register class to use when it is necessary to copy value X into a
890: register in class CLASS. The value is a register class; perhaps
891: CLASS, or perhaps another, smaller class. On many machines, the
892: definition
893:
894: #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
895:
896: is safe.
897:
898: Sometimes returning a more restrictive class makes better code.
899: For example, on the 68000, when X is an integer constant that is
900: in range for a `moveq' instruction, the value of this macro is
901: always `DATA_REGS' as long as CLASS includes the data registers.
902: Requiring a data register guarantees that a `moveq' will be used.
903:
904: If X is a `const_double', by returning `NO_REGS' you can force X
905: into a memory constant. This is useful on certain machines where
906: immediate floating values cannot be loaded into certain kinds of
907: registers.
908:
909: `LIMIT_RELOAD_CLASS (MODE, CLASS)'
910: A C expression that places additional restrictions on the
911: register class to use when it is necessary to be able to hold a
912: value of mode MODE in a reload register for which class CLASS
913: would ordinarily be used.
914:
915: Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when
916: there are certain modes that simply can't go in certain reload
917: classes.
918:
919: The value is a register class; perhaps CLASS, or perhaps another,
920: smaller class.
921:
922: Don't define this macro unless the target machine has limitations
923: which require the macro to do something nontrivial.
924:
925: `SECONDARY_RELOAD_CLASS (CLASS, MODE, X)'
926: `SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)'
927: `SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)'
928: Many machines have some registers that cannot be copied directly
929: to or from memory or even from other types of registers. An
930: example is the `MQ' register, which on most machines, can only be
931: copied to or from general registers, but not memory. Some
932: machines allow copying all registers to and from memory, but
933: require a scratch register for stores to some memory locations
934: (e.g., those with symbolic address on the RT, and those with
935: certain symbolic address on the Sparc when compiling PIC). In
936: some cases, both an intermediate and a scratch register are
937: required.
938:
939: You should define these macros to indicate to the reload phase
940: that it may need to allocate at least one register for a reload
941: in addition to the register to contain the data. Specifically,
942: if copying X to a register CLASS in MODE requires an intermediate
943: register, you should define `SECONDARY_INPUT_RELOAD_CLASS' to
944: return the largest register class all of whose registers can be
945: used as intermediate registers or scratch registers.
946:
947: If copying a register CLASS in MODE to X requires an intermediate
948: or scratch register, you should define
949: `SECONDARY_OUTPUT_RELOAD_CLASS' to return the largest register
950: class required. If the requirements for input and output reloads
951: are the same, the macro `SECONDARY_RELOAD_CLASS' should be used
952: instead of defining both macros identically.
953:
954: The values returned by these macros are often `GENERAL_REGS'.
955: Return `NO_REGS' if no spare register is needed; i.e., if X can
956: be directly copied to or from a register of CLASS in MODE without
957: requiring a scratch register. Do not define this macro if it
958: would always return `NO_REGS'.
959:
960: If a scratch register is required (either with or without an
961: intermediate register), you should define patterns for
962: `reload_inM' or `reload_outM', as required (*note Standard
963: Names::.. These patterns, which will normally be implemented
964: with a `define_expand', should be similar to the `movM' patterns,
965: except that operand 2 is the scratch register.
966:
967: Define constraints for the reload register and scratch register
968: that contain a single register class. If the original reload
969: register (whose class is CLASS) can meet the constraint given in
970: the pattern, the value returned by these macros is used for the
971: class of the scratch register. Otherwise, two additional reload
972: registers are required. Their classes are obtained from the
973: constraints in the insn pattern.
974:
975: X might be a pseudo-register or a `subreg' of a pseudo-register,
976: which could either be in a hard register or in memory. Use
977: `true_regnum' to find out; it will return -1 if the pseudo is in
978: memory and the hard register number if it is in a register.
979:
980: These macros should not be used in the case where a particular
981: class of registers can only be copied to memory and not to
982: another class of registers. In that case, secondary reload
983: registers are not needed and would not be helpful. Instead, a
984: stack location must be used to perform the copy and the `movM'
985: pattern should use memory as a intermediate storage. This case
986: often occurs between floating-point and general registers.
987:
988: `SMALL_REGISTER_CLASSES'
989: Normally the compiler will avoid choosing spill registers from
990: registers that have been explicitly mentioned in the rtl (these
991: registers are normally those used to pass parameters and return
992: values). However, some machines have so few registers of certain
993: classes that there would not be enough registers to use as spill
994: registers if this were done.
995:
996: On those machines, you should define `SMALL_REGISTER_CLASSES'.
997: When it is defined, the compiler allows registers explicitly used
998: in the rtl to be used as spill registers but prevents the
999: compiler from extending the lifetime of these registers.
1000:
1001: Defining this macro is always safe, but unnecessarily defining
1002: this macro will reduce the amount of optimizations that can be
1003: performed in some cases. If this macro is not defined but needs
1004: to be, the compiler will run out of reload registers and print a
1005: fatal error message.
1006:
1007: For most machines, this macro should not be defined.
1008:
1009: `CLASS_MAX_NREGS (CLASS, MODE)'
1010: A C expression for the maximum number of consecutive registers of
1011: class CLASS needed to hold a value of mode MODE.
1012:
1013: This is closely related to the macro `HARD_REGNO_NREGS'. In
1014: fact, the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)'
1015: should be the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)'
1016: for all REGNO values in the class CLASS.
1017:
1018: This macro helps control the handling of multiple-word values in
1019: the reload pass.
1020:
1021: Three other special macros describe which operands fit which
1022: constraint letters.
1023:
1024: `CONST_OK_FOR_LETTER_P (VALUE, C)'
1025: A C expression that defines the machine-dependent operand
1026: constraint letters that specify particular ranges of integer
1027: values. If C is one of those letters, the expression should
1028: check that VALUE, an integer, is in the appropriate range and
1029: return 1 if so, 0 otherwise. If C is not one of those letters,
1030: the value should be 0 regardless of VALUE.
1031:
1032: `CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)'
1033: A C expression that defines the machine-dependent operand
1034: constraint letters that specify particular ranges of
1035: `const_double' values.
1036:
1037: If C is one of those letters, the expression should check that
1038: VALUE, an RTX of code `const_double', is in the appropriate range
1039: and return 1 if so, 0 otherwise. If C is not one of those
1040: letters, the value should be 0 regardless of VALUE.
1041:
1042: `const_double' is used for all floating-point constants and for
1043: `DImode' fixed-point constants. A given letter can accept either
1044: or both kinds of values. It can use `GET_MODE' to distinguish
1045: between these kinds.
1046:
1047: `EXTRA_CONSTRAINT (VALUE, C)'
1048: A C expression that defines the optional machine-dependent
1049: constraint letters that can be used to segregate specific types
1050: of operands, usually memory references, for the target machine.
1051: Normally this macro will not be defined. If it is required for a
1052: particular target machine, it should return 1 if VALUE
1053: corresponds to the operand type represented by the constraint
1054: letter C. If C is not defined as an extra constraint, the value
1055: returned should be 0 regardless of VALUE.
1056:
1057: For example, on the ROMP, load instructions cannot have their
1058: output in r0 if the memory reference contains a symbolic address.
1059: Constraint letter `Q' is defined as representing a memory
1060: address that does *not* contain a symbolic address. An
1061: alternative is specified with a `Q' constraint on the input and
1062: `r' on the output. The next alternative specifies `m' on the
1063: input and a register class that does not include r0 on the output.
1064:
1065:
1066: File: gcc.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Machine Macros
1067:
1068: Describing Stack Layout and Calling Conventions
1069: ===============================================
1070:
1071: * Menu:
1072:
1073: * Frame Layout::
1074: * Frame Registers::
1075: * Elimination::
1076: * Stack Arguments::
1077: * Register Arguments::
1078: * Scalar Return::
1079: * Aggregate Return::
1080: * Caller Saves::
1081: * Function Entry::
1082: * Profiling::
1083:
1084:
1085: File: gcc.info, Node: Frame Layout, Next: Frame Registers, Up: Stack and Calling
1086:
1087: Basic Stack Layout
1088: ------------------
1089:
1090: `STACK_GROWS_DOWNWARD'
1091: Define this macro if pushing a word onto the stack moves the stack
1092: pointer to a smaller address.
1093:
1094: When we say, "define this macro if ...," it means that the
1095: compiler checks this macro only with `#ifdef' so the precise
1096: definition used does not matter.
1097:
1098: `FRAME_GROWS_DOWNWARD'
1099: Define this macro if the addresses of local variable slots are at
1100: negative offsets from the frame pointer.
1101:
1102: `ARGS_GROW_DOWNWARD'
1103: Define this macro if successive arguments to a function occupy
1104: decreasing addresses on the stack.
1105:
1106: `STARTING_FRAME_OFFSET'
1107: Offset from the frame pointer to the first local variable slot to
1108: be allocated.
1109:
1110: If `FRAME_GROWS_DOWNWARD', the next slot's offset is found by
1111: subtracting the length of the first slot from
1112: `STARTING_FRAME_OFFSET'. Otherwise, it is found by adding the
1113: length of the first slot to the value `STARTING_FRAME_OFFSET'.
1114:
1115: `STACK_POINTER_OFFSET'
1116: Offset from the stack pointer register to the first location at
1117: which outgoing arguments are placed. If not specified, the
1118: default value of zero is used. This is the proper value for most
1119: machines.
1120:
1121: If `ARGS_GROW_DOWNWARD', this is the offset to the location above
1122: the first location at which outgoing arguments are placed.
1123:
1124: `FIRST_PARM_OFFSET (FUNDECL)'
1125: Offset from the argument pointer register to the first argument's
1126: address. On some machines it may depend on the data type of the
1127: function.
1128:
1129: If `ARGS_GROW_DOWNWARD', this is the offset to the location above
1130: the first argument's address.
1131:
1132: `STACK_DYNAMIC_OFFSET (FUNDECL)'
1133: Offset from the stack pointer register to an item dynamically
1134: allocated on the stack, e.g., by `alloca'.
1135:
1136: The default value for this macro is `STACK_POINTER_OFFSET' plus
1137: the length of the outgoing arguments. The default is correct for
1138: most machines. See `function.c' for details.
1139:
1140: `DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)'
1141: A C expression whose value is RTL representing the address in a
1142: stack frame where the pointer to the caller's frame is stored.
1143: Assume that FRAMEADDR is an RTL expression for the address of the
1144: stack frame itself.
1145:
1146: If you don't define this macro, the default is to return the value
1147: of FRAMEADDR--that is, the stack frame address is also the
1148: address of the stack word that points to the previous frame.
1149:
1150:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.