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