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