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: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros |
---|
34 | |
---|
35 | Register Usage |
---|
36 | ============== |
---|
37 | |
---|
38 | This section explains how to describe what registers the target |
---|
39 | machine has, and how (in general) they can be used. |
---|
40 | |
---|
41 | The description of which registers a specific instruction can use is |
---|
42 | done with register classes; see *Note Register Classes::. For |
---|
43 | information on using registers to access a stack frame, see *Note Frame |
---|
44 | Registers::. For passing values in registers, see *Note Register |
---|
45 | Arguments::. For returning values in registers, see *Note Scalar |
---|
46 | Return::. |
---|
47 | |
---|
48 | * Menu: |
---|
49 | |
---|
50 | * Register Basics:: Number and kinds of registers. |
---|
51 | * Allocation Order:: Order in which registers are allocated. |
---|
52 | * Values in Registers:: What kinds of values each reg can hold. |
---|
53 | * Leaf Functions:: Renumbering registers for leaf functions. |
---|
54 | * Stack Registers:: Handling a register stack such as 80387. |
---|
55 | * Obsolete Register Macros:: Macros formerly used for the 80387. |
---|
56 | |
---|
57 | |
---|
58 | File: gcc.info, Node: Register Basics, Next: Allocation Order, Up: Registers |
---|
59 | |
---|
60 | Basic Characteristics of Registers |
---|
61 | ---------------------------------- |
---|
62 | |
---|
63 | Registers have various characteristics. |
---|
64 | |
---|
65 | `FIRST_PSEUDO_REGISTER' |
---|
66 | Number of hardware registers known to the compiler. They receive |
---|
67 | numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first |
---|
68 | pseudo register's number really is assigned the number |
---|
69 | `FIRST_PSEUDO_REGISTER'. |
---|
70 | |
---|
71 | `FIXED_REGISTERS' |
---|
72 | An initializer that says which registers are used for fixed |
---|
73 | purposes all throughout the compiled code and are therefore not |
---|
74 | available for general allocation. These would include the stack |
---|
75 | pointer, the frame pointer (except on machines where that can be |
---|
76 | used as a general register when no frame pointer is needed), the |
---|
77 | program counter on machines where that is considered one of the |
---|
78 | addressable registers, and any other numbered register with a |
---|
79 | standard use. |
---|
80 | |
---|
81 | This information is expressed as a sequence of numbers, separated |
---|
82 | by commas and surrounded by braces. The Nth number is 1 if |
---|
83 | register N is fixed, 0 otherwise. |
---|
84 | |
---|
85 | The table initialized from this macro, and the table initialized by |
---|
86 | the following one, may be overridden at run time either |
---|
87 | automatically, by the actions of the macro |
---|
88 | `CONDITIONAL_REGISTER_USAGE', or by the user with the command |
---|
89 | options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'. |
---|
90 | |
---|
91 | `CALL_USED_REGISTERS' |
---|
92 | Like `FIXED_REGISTERS' but has 1 for each register that is |
---|
93 | clobbered (in general) by function calls as well as for fixed |
---|
94 | registers. This macro therefore identifies the registers that are |
---|
95 | not available for general allocation of values that must live |
---|
96 | across function calls. |
---|
97 | |
---|
98 | If a register has 0 in `CALL_USED_REGISTERS', the compiler |
---|
99 | automatically saves it on function entry and restores it on |
---|
100 | function exit, if the register is used within the function. |
---|
101 | |
---|
102 | `CONDITIONAL_REGISTER_USAGE' |
---|
103 | Zero or more C statements that may conditionally modify two |
---|
104 | variables `fixed_regs' and `call_used_regs' (both of type `char |
---|
105 | []') after they have been initialized from the two preceding |
---|
106 | macros. |
---|
107 | |
---|
108 | This is necessary in case the fixed or call-clobbered registers |
---|
109 | depend on target flags. |
---|
110 | |
---|
111 | You need not define this macro if it has no work to do. |
---|
112 | |
---|
113 | If the usage of an entire class of registers depends on the target |
---|
114 | flags, you may indicate this to GCC by using this macro to modify |
---|
115 | `fixed_regs' and `call_used_regs' to 1 for each of the registers |
---|
116 | in the classes which should not be used by GCC. Also define the |
---|
117 | macro `REG_CLASS_FROM_LETTER' to return `NO_REGS' if it is called |
---|
118 | with a letter for a class that shouldn't be used. |
---|
119 | |
---|
120 | (However, if this class is not included in `GENERAL_REGS' and all |
---|
121 | of the insn patterns whose constraints permit this class are |
---|
122 | controlled by target switches, then GCC will automatically avoid |
---|
123 | using these registers when the target switches are opposed to |
---|
124 | them.) |
---|
125 | |
---|
126 | `NON_SAVING_SETJMP' |
---|
127 | If this macro is defined and has a nonzero value, it means that |
---|
128 | `setjmp' and related functions fail to save the registers, or that |
---|
129 | `longjmp' fails to restore them. To compensate, the compiler |
---|
130 | avoids putting variables in registers in functions that use |
---|
131 | `setjmp'. |
---|
132 | |
---|
133 | `INCOMING_REGNO (OUT)' |
---|
134 | Define this macro if the target machine has register windows. |
---|
135 | This C expression returns the register number as seen by the |
---|
136 | called function corresponding to the register number OUT as seen |
---|
137 | by the calling function. Return OUT if register number OUT is not |
---|
138 | an outbound register. |
---|
139 | |
---|
140 | `OUTGOING_REGNO (IN)' |
---|
141 | Define this macro if the target machine has register windows. |
---|
142 | This C expression returns the register number as seen by the |
---|
143 | calling function corresponding to the register number IN as seen |
---|
144 | by the called function. Return IN if register number IN is not an |
---|
145 | inbound register. |
---|
146 | |
---|
147 | |
---|
148 | File: gcc.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers |
---|
149 | |
---|
150 | Order of Allocation of Registers |
---|
151 | -------------------------------- |
---|
152 | |
---|
153 | Registers are allocated in order. |
---|
154 | |
---|
155 | `REG_ALLOC_ORDER' |
---|
156 | If defined, an initializer for a vector of integers, containing the |
---|
157 | numbers of hard registers in the order in which GNU CC should |
---|
158 | prefer to use them (from most preferred to least). |
---|
159 | |
---|
160 | If this macro is not defined, registers are used lowest numbered |
---|
161 | first (all else being equal). |
---|
162 | |
---|
163 | One use of this macro is on machines where the highest numbered |
---|
164 | registers must always be saved and the save-multiple-registers |
---|
165 | instruction supports only sequences of consecutive registers. On |
---|
166 | such machines, define `REG_ALLOC_ORDER' to be an initializer that |
---|
167 | lists the highest numbered allocable register first. |
---|
168 | |
---|
169 | `ORDER_REGS_FOR_LOCAL_ALLOC' |
---|
170 | A C statement (sans semicolon) to choose the order in which to |
---|
171 | allocate hard registers for pseudo-registers local to a basic |
---|
172 | block. |
---|
173 | |
---|
174 | Store the desired register order in the array `reg_alloc_order'. |
---|
175 | Element 0 should be the register to allocate first; element 1, the |
---|
176 | next register; and so on. |
---|
177 | |
---|
178 | The macro body should not assume anything about the contents of |
---|
179 | `reg_alloc_order' before execution of the macro. |
---|
180 | |
---|
181 | On most machines, it is not necessary to define this macro. |
---|
182 | |
---|
183 | |
---|
184 | File: gcc.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers |
---|
185 | |
---|
186 | How Values Fit in Registers |
---|
187 | --------------------------- |
---|
188 | |
---|
189 | This section discusses the macros that describe which kinds of values |
---|
190 | (specifically, which machine modes) each register can hold, and how many |
---|
191 | consecutive registers are needed for a given mode. |
---|
192 | |
---|
193 | `HARD_REGNO_NREGS (REGNO, MODE)' |
---|
194 | A C expression for the number of consecutive hard registers, |
---|
195 | starting at register number REGNO, required to hold a value of mode |
---|
196 | MODE. |
---|
197 | |
---|
198 | On a machine where all registers are exactly one word, a suitable |
---|
199 | definition of this macro is |
---|
200 | |
---|
201 | #define HARD_REGNO_NREGS(REGNO, MODE) \ |
---|
202 | ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \ |
---|
203 | / UNITS_PER_WORD)) |
---|
204 | |
---|
205 | `HARD_REGNO_MODE_OK (REGNO, MODE)' |
---|
206 | A C expression that is nonzero if it is permissible to store a |
---|
207 | value of mode MODE in hard register number REGNO (or in several |
---|
208 | registers starting with that one). For a machine where all |
---|
209 | registers are equivalent, a suitable definition is |
---|
210 | |
---|
211 | #define HARD_REGNO_MODE_OK(REGNO, MODE) 1 |
---|
212 | |
---|
213 | You need not include code to check for the numbers of fixed |
---|
214 | registers, because the allocation mechanism considers them to be |
---|
215 | always occupied. |
---|
216 | |
---|
217 | On some machines, double-precision values must be kept in even/odd |
---|
218 | register pairs. You can implement that by defining this macro to |
---|
219 | reject odd register numbers for such modes. |
---|
220 | |
---|
221 | The minimum requirement for a mode to be OK in a register is that |
---|
222 | the `movMODE' instruction pattern support moves between the |
---|
223 | register and other hard register in the same class and that moving |
---|
224 | a value into the register and back out not alter it. |
---|
225 | |
---|
226 | Since the same instruction used to move `word_mode' will work for |
---|
227 | all narrower integer modes, it is not necessary on any machine for |
---|
228 | `HARD_REGNO_MODE_OK' to distinguish between these modes, provided |
---|
229 | you define patterns `movhi', etc., to take advantage of this. This |
---|
230 | is useful because of the interaction between `HARD_REGNO_MODE_OK' |
---|
231 | and `MODES_TIEABLE_P'; it is very desirable for all integer modes |
---|
232 | to be tieable. |
---|
233 | |
---|
234 | Many machines have special registers for floating point arithmetic. |
---|
235 | Often people assume that floating point machine modes are allowed |
---|
236 | only in floating point registers. This is not true. Any |
---|
237 | registers that can hold integers can safely *hold* a floating |
---|
238 | point machine mode, whether or not floating arithmetic can be done |
---|
239 | on it in those registers. Integer move instructions can be used |
---|
240 | to move the values. |
---|
241 | |
---|
242 | On some machines, though, the converse is true: fixed-point machine |
---|
243 | modes may not go in floating registers. This is true if the |
---|
244 | floating registers normalize any value stored in them, because |
---|
245 | storing a non-floating value there would garble it. In this case, |
---|
246 | `HARD_REGNO_MODE_OK' should reject fixed-point machine modes in |
---|
247 | floating registers. But if the floating registers do not |
---|
248 | automatically normalize, if you can store any bit pattern in one |
---|
249 | and retrieve it unchanged without a trap, then any machine mode |
---|
250 | may go in a floating register, so you can define this macro to say |
---|
251 | so. |
---|
252 | |
---|
253 | The primary significance of special floating registers is rather |
---|
254 | that they are the registers acceptable in floating point arithmetic |
---|
255 | instructions. However, this is of no concern to |
---|
256 | `HARD_REGNO_MODE_OK'. You handle it by writing the proper |
---|
257 | constraints for those instructions. |
---|
258 | |
---|
259 | On some machines, the floating registers are especially slow to |
---|
260 | access, so that it is better to store a value in a stack frame |
---|
261 | than in such a register if floating point arithmetic is not being |
---|
262 | done. As long as the floating registers are not in class |
---|
263 | `GENERAL_REGS', they will not be used unless some pattern's |
---|
264 | constraint asks for one. |
---|
265 | |
---|
266 | `MODES_TIEABLE_P (MODE1, MODE2)' |
---|
267 | A C expression that is nonzero if a value of mode MODE1 is |
---|
268 | accessible in mode MODE2 without copying. |
---|
269 | |
---|
270 | If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R, |
---|
271 | MODE2)' are always the same for any R, then `MODES_TIEABLE_P |
---|
272 | (MODE1, MODE2)' should be nonzero. If they differ for any R, you |
---|
273 | should define this macro to return zero unless some other |
---|
274 | mechanism ensures the accessibility of the value in a narrower |
---|
275 | mode. |
---|
276 | |
---|
277 | You should define this macro to return nonzero in as many cases as |
---|
278 | possible since doing so will allow GNU CC to perform better |
---|
279 | register allocation. |
---|
280 | |
---|
281 | |
---|
282 | File: gcc.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers |
---|
283 | |
---|
284 | Handling Leaf Functions |
---|
285 | ----------------------- |
---|
286 | |
---|
287 | On some machines, a leaf function (i.e., one which makes no calls) |
---|
288 | can run more efficiently if it does not make its own register window. |
---|
289 | Often this means it is required to receive its arguments in the |
---|
290 | registers where they are passed by the caller, instead of the registers |
---|
291 | where they would normally arrive. |
---|
292 | |
---|
293 | The special treatment for leaf functions generally applies only when |
---|
294 | other conditions are met; for example, often they may use only those |
---|
295 | registers for its own variables and temporaries. We use the term "leaf |
---|
296 | function" to mean a function that is suitable for this special |
---|
297 | handling, so that functions with no calls are not necessarily "leaf |
---|
298 | functions". |
---|
299 | |
---|
300 | GNU CC assigns register numbers before it knows whether the function |
---|
301 | is suitable for leaf function treatment. So it needs to renumber the |
---|
302 | registers in order to output a leaf function. The following macros |
---|
303 | accomplish this. |
---|
304 | |
---|
305 | `LEAF_REGISTERS' |
---|
306 | A C initializer for a vector, indexed by hard register number, |
---|
307 | which contains 1 for a register that is allowable in a candidate |
---|
308 | for leaf function treatment. |
---|
309 | |
---|
310 | If leaf function treatment involves renumbering the registers, |
---|
311 | then the registers marked here should be the ones before |
---|
312 | renumbering--those that GNU CC would ordinarily allocate. The |
---|
313 | registers which will actually be used in the assembler code, after |
---|
314 | renumbering, should not be marked with 1 in this vector. |
---|
315 | |
---|
316 | Define this macro only if the target machine offers a way to |
---|
317 | optimize the treatment of leaf functions. |
---|
318 | |
---|
319 | `LEAF_REG_REMAP (REGNO)' |
---|
320 | A C expression whose value is the register number to which REGNO |
---|
321 | should be renumbered, when a function is treated as a leaf |
---|
322 | function. |
---|
323 | |
---|
324 | If REGNO is a register number which should not appear in a leaf |
---|
325 | function before renumbering, then the expression should yield -1, |
---|
326 | which will cause the compiler to abort. |
---|
327 | |
---|
328 | Define this macro only if the target machine offers a way to |
---|
329 | optimize the treatment of leaf functions, and registers need to be |
---|
330 | renumbered to do this. |
---|
331 | |
---|
332 | Normally, `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE' must treat |
---|
333 | leaf functions specially. It can test the C variable `leaf_function' |
---|
334 | which is nonzero for leaf functions. (The variable `leaf_function' is |
---|
335 | defined only if `LEAF_REGISTERS' is defined.) |
---|
336 | |
---|
337 | |
---|
338 | File: gcc.info, Node: Stack Registers, Next: Obsolete Register Macros, Prev: Leaf Functions, Up: Registers |
---|
339 | |
---|
340 | Registers That Form a Stack |
---|
341 | --------------------------- |
---|
342 | |
---|
343 | There are special features to handle computers where some of the |
---|
344 | "registers" form a stack, as in the 80387 coprocessor for the 80386. |
---|
345 | Stack registers are normally written by pushing onto the stack, and are |
---|
346 | numbered relative to the top of the stack. |
---|
347 | |
---|
348 | Currently, GNU CC can only handle one group of stack-like registers, |
---|
349 | and they must be consecutively numbered. |
---|
350 | |
---|
351 | `STACK_REGS' |
---|
352 | Define this if the machine has any stack-like registers. |
---|
353 | |
---|
354 | `FIRST_STACK_REG' |
---|
355 | The number of the first stack-like register. This one is the top |
---|
356 | of the stack. |
---|
357 | |
---|
358 | `LAST_STACK_REG' |
---|
359 | The number of the last stack-like register. This one is the |
---|
360 | bottom of the stack. |
---|
361 | |
---|
362 | |
---|
363 | File: gcc.info, Node: Obsolete Register Macros, Prev: Stack Registers, Up: Registers |
---|
364 | |
---|
365 | Obsolete Macros for Controlling Register Usage |
---|
366 | ---------------------------------------------- |
---|
367 | |
---|
368 | These features do not work very well. They exist because they used |
---|
369 | to be required to generate correct code for the 80387 coprocessor of the |
---|
370 | 80386. They are no longer used by that machine description and may be |
---|
371 | removed in a later version of the compiler. Don't use them! |
---|
372 | |
---|
373 | `OVERLAPPING_REGNO_P (REGNO)' |
---|
374 | If defined, this is a C expression whose value is nonzero if hard |
---|
375 | register number REGNO is an overlapping register. This means a |
---|
376 | hard register which overlaps a hard register with a different |
---|
377 | number. (Such overlap is undesirable, but occasionally it allows |
---|
378 | a machine to be supported which otherwise could not be.) This |
---|
379 | macro must return nonzero for *all* the registers which overlap |
---|
380 | each other. GNU CC can use an overlapping register only in |
---|
381 | certain limited ways. It can be used for allocation within a |
---|
382 | basic block, and may be spilled for reloading; that is all. |
---|
383 | |
---|
384 | If this macro is not defined, it means that none of the hard |
---|
385 | registers overlap each other. This is the usual situation. |
---|
386 | |
---|
387 | `INSN_CLOBBERS_REGNO_P (INSN, REGNO)' |
---|
388 | If defined, this is a C expression whose value should be nonzero if |
---|
389 | the insn INSN has the effect of mysteriously clobbering the |
---|
390 | contents of hard register number REGNO. By "mysterious" we mean |
---|
391 | that the insn's RTL expression doesn't describe such an effect. |
---|
392 | |
---|
393 | If this macro is not defined, it means that no insn clobbers |
---|
394 | registers mysteriously. This is the usual situation; all else |
---|
395 | being equal, it is best for the RTL expression to show all the |
---|
396 | activity. |
---|
397 | |
---|
398 | `PRESERVE_DEATH_INFO_REGNO_P (REGNO)' |
---|
399 | If defined, this is a C expression whose value is nonzero if |
---|
400 | correct `REG_DEAD' notes are needed for hard register number REGNO |
---|
401 | after reload. |
---|
402 | |
---|
403 | You would arrange to preserve death info for a register when some |
---|
404 | of the code in the machine description which is executed to write |
---|
405 | the assembler code looks at the death notes. This is necessary |
---|
406 | only when the actual hardware feature which GNU CC thinks of as a |
---|
407 | register is not actually a register of the usual sort. (It might, |
---|
408 | for example, be a hardware stack.) |
---|
409 | |
---|
410 | It is also useful for peepholes and linker relaxation. |
---|
411 | |
---|
412 | If this macro is not defined, it means that no death notes need to |
---|
413 | be preserved, and some may even be incorrect. This is the usual |
---|
414 | situation. |
---|
415 | |
---|
416 | |
---|
417 | File: gcc.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros |
---|
418 | |
---|
419 | Register Classes |
---|
420 | ================ |
---|
421 | |
---|
422 | On many machines, the numbered registers are not all equivalent. |
---|
423 | For example, certain registers may not be allowed for indexed |
---|
424 | addressing; certain registers may not be allowed in some instructions. |
---|
425 | These machine restrictions are described to the compiler using |
---|
426 | "register classes". |
---|
427 | |
---|
428 | You define a number of register classes, giving each one a name and |
---|
429 | saying which of the registers belong to it. Then you can specify |
---|
430 | register classes that are allowed as operands to particular instruction |
---|
431 | patterns. |
---|
432 | |
---|
433 | In general, each register will belong to several classes. In fact, |
---|
434 | one class must be named `ALL_REGS' and contain all the registers. |
---|
435 | Another class must be named `NO_REGS' and contain no registers. Often |
---|
436 | the union of two classes will be another class; however, this is not |
---|
437 | required. |
---|
438 | |
---|
439 | One of the classes must be named `GENERAL_REGS'. There is nothing |
---|
440 | terribly special about the name, but the operand constraint letters `r' |
---|
441 | and `g' specify this class. If `GENERAL_REGS' is the same as |
---|
442 | `ALL_REGS', just define it as a macro which expands to `ALL_REGS'. |
---|
443 | |
---|
444 | Order the classes so that if class X is contained in class Y then X |
---|
445 | has a lower class number than Y. |
---|
446 | |
---|
447 | The way classes other than `GENERAL_REGS' are specified in operand |
---|
448 | constraints is through machine-dependent operand constraint letters. |
---|
449 | You can define such letters to correspond to various classes, then use |
---|
450 | them in operand constraints. |
---|
451 | |
---|
452 | You should define a class for the union of two classes whenever some |
---|
453 | instruction allows both classes. For example, if an instruction allows |
---|
454 | either a floating point (coprocessor) register or a general register |
---|
455 | for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS' |
---|
456 | which includes both of them. Otherwise you will get suboptimal code. |
---|
457 | |
---|
458 | You must also specify certain redundant information about the |
---|
459 | register classes: for each class, which classes contain it and which |
---|
460 | ones are contained in it; for each pair of classes, the largest class |
---|
461 | contained in their union. |
---|
462 | |
---|
463 | When a value occupying several consecutive registers is expected in a |
---|
464 | certain class, all the registers used must belong to that class. |
---|
465 | Therefore, register classes cannot be used to enforce a requirement for |
---|
466 | a register pair to start with an even-numbered register. The way to |
---|
467 | specify this requirement is with `HARD_REGNO_MODE_OK'. |
---|
468 | |
---|
469 | Register classes used for input-operands of bitwise-and or shift |
---|
470 | instructions have a special requirement: each such class must have, for |
---|
471 | each fixed-point machine mode, a subclass whose registers can transfer |
---|
472 | that mode to or from memory. For example, on some machines, the |
---|
473 | operations for single-byte values (`QImode') are limited to certain |
---|
474 | registers. When this is so, each register class that is used in a |
---|
475 | bitwise-and or shift instruction must have a subclass consisting of |
---|
476 | registers from which single-byte values can be loaded or stored. This |
---|
477 | is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to |
---|
478 | return. |
---|
479 | |
---|
480 | `enum reg_class' |
---|
481 | An enumeral type that must be defined with all the register class |
---|
482 | names as enumeral values. `NO_REGS' must be first. `ALL_REGS' |
---|
483 | must be the last register class, followed by one more enumeral |
---|
484 | value, `LIM_REG_CLASSES', which is not a register class but rather |
---|
485 | tells how many classes there are. |
---|
486 | |
---|
487 | Each register class has a number, which is the value of casting |
---|
488 | the class name to type `int'. The number serves as an index in |
---|
489 | many of the tables described below. |
---|
490 | |
---|
491 | `N_REG_CLASSES' |
---|
492 | The number of distinct register classes, defined as follows: |
---|
493 | |
---|
494 | #define N_REG_CLASSES (int) LIM_REG_CLASSES |
---|
495 | |
---|
496 | `REG_CLASS_NAMES' |
---|
497 | An initializer containing the names of the register classes as C |
---|
498 | string constants. These names are used in writing some of the |
---|
499 | debugging dumps. |
---|
500 | |
---|
501 | `REG_CLASS_CONTENTS' |
---|
502 | An initializer containing the contents of the register classes, as |
---|
503 | integers which are bit masks. The Nth integer specifies the |
---|
504 | contents of class N. The way the integer MASK is interpreted is |
---|
505 | that register R is in the class if `MASK & (1 << R)' is 1. |
---|
506 | |
---|
507 | When the machine has more than 32 registers, an integer does not |
---|
508 | suffice. Then the integers are replaced by sub-initializers, |
---|
509 | braced groupings containing several integers. Each |
---|
510 | sub-initializer must be suitable as an initializer for the type |
---|
511 | `HARD_REG_SET' which is defined in `hard-reg-set.h'. |
---|
512 | |
---|
513 | `REGNO_REG_CLASS (REGNO)' |
---|
514 | A C expression whose value is a register class containing hard |
---|
515 | register REGNO. In general there is more than one such class; |
---|
516 | choose a class which is "minimal", meaning that no smaller class |
---|
517 | also contains the register. |
---|
518 | |
---|
519 | `BASE_REG_CLASS' |
---|
520 | A macro whose definition is the name of the class to which a valid |
---|
521 | base register must belong. A base register is one used in an |
---|
522 | address which is the register value plus a displacement. |
---|
523 | |
---|
524 | `INDEX_REG_CLASS' |
---|
525 | A macro whose definition is the name of the class to which a valid |
---|
526 | index register must belong. An index register is one used in an |
---|
527 | address where its value is either multiplied by a scale factor or |
---|
528 | added to another register (as well as added to a displacement). |
---|
529 | |
---|
530 | `REG_CLASS_FROM_LETTER (CHAR)' |
---|
531 | A C expression which defines the machine-dependent operand |
---|
532 | constraint letters for register classes. If CHAR is such a |
---|
533 | letter, the value should be the register class corresponding to |
---|
534 | it. Otherwise, the value should be `NO_REGS'. The register |
---|
535 | letter `r', corresponding to class `GENERAL_REGS', will not be |
---|
536 | passed to this macro; you do not need to handle it. |
---|
537 | |
---|
538 | `REGNO_OK_FOR_BASE_P (NUM)' |
---|
539 | A C expression which is nonzero if register number NUM is suitable |
---|
540 | for use as a base register in operand addresses. It may be either |
---|
541 | a suitable hard register or a pseudo register that has been |
---|
542 | allocated such a hard register. |
---|
543 | |
---|
544 | `REGNO_MODE_OK_FOR_BASE_P (NUM, MODE)' |
---|
545 | A C expression that is just like `REGNO_OK_FOR_BASE_P', except that |
---|
546 | that expression may examine the mode of the memory reference in |
---|
547 | MODE. You should define this macro if the mode of the memory |
---|
548 | reference affects whether a register may be used as a base |
---|
549 | register. If you define this macro, the compiler will use it |
---|
550 | instead of `REGNO_OK_FOR_BASE_P'. |
---|
551 | |
---|
552 | `REGNO_OK_FOR_INDEX_P (NUM)' |
---|
553 | A C expression which is nonzero if register number NUM is suitable |
---|
554 | for use as an index register in operand addresses. It may be |
---|
555 | either a suitable hard register or a pseudo register that has been |
---|
556 | allocated such a hard register. |
---|
557 | |
---|
558 | The difference between an index register and a base register is |
---|
559 | that the index register may be scaled. If an address involves the |
---|
560 | sum of two registers, neither one of them scaled, then either one |
---|
561 | may be labeled the "base" and the other the "index"; but whichever |
---|
562 | labeling is used must fit the machine's constraints of which |
---|
563 | registers may serve in each capacity. The compiler will try both |
---|
564 | labelings, looking for one that is valid, and will reload one or |
---|
565 | both registers only if neither labeling works. |
---|
566 | |
---|
567 | `PREFERRED_RELOAD_CLASS (X, CLASS)' |
---|
568 | A C expression that places additional restrictions on the register |
---|
569 | class to use when it is necessary to copy value X into a register |
---|
570 | in class CLASS. The value is a register class; perhaps CLASS, or |
---|
571 | perhaps another, smaller class. On many machines, the following |
---|
572 | definition is safe: |
---|
573 | |
---|
574 | #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS |
---|
575 | |
---|
576 | Sometimes returning a more restrictive class makes better code. |
---|
577 | For example, on the 68000, when X is an integer constant that is |
---|
578 | in range for a `moveq' instruction, the value of this macro is |
---|
579 | always `DATA_REGS' as long as CLASS includes the data registers. |
---|
580 | Requiring a data register guarantees that a `moveq' will be used. |
---|
581 | |
---|
582 | If X is a `const_double', by returning `NO_REGS' you can force X |
---|
583 | into a memory constant. This is useful on certain machines where |
---|
584 | immediate floating values cannot be loaded into certain kinds of |
---|
585 | registers. |
---|
586 | |
---|
587 | `PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS)' |
---|
588 | Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of |
---|
589 | input reloads. If you don't define this macro, the default is to |
---|
590 | use CLASS, unchanged. |
---|
591 | |
---|
592 | `LIMIT_RELOAD_CLASS (MODE, CLASS)' |
---|
593 | A C expression that places additional restrictions on the register |
---|
594 | class to use when it is necessary to be able to hold a value of |
---|
595 | mode MODE in a reload register for which class CLASS would |
---|
596 | ordinarily be used. |
---|
597 | |
---|
598 | Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when |
---|
599 | there are certain modes that simply can't go in certain reload |
---|
600 | classes. |
---|
601 | |
---|
602 | The value is a register class; perhaps CLASS, or perhaps another, |
---|
603 | smaller class. |
---|
604 | |
---|
605 | Don't define this macro unless the target machine has limitations |
---|
606 | which require the macro to do something nontrivial. |
---|
607 | |
---|
608 | `SECONDARY_RELOAD_CLASS (CLASS, MODE, X)' |
---|
609 | `SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)' |
---|
610 | `SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)' |
---|
611 | Many machines have some registers that cannot be copied directly |
---|
612 | to or from memory or even from other types of registers. An |
---|
613 | example is the `MQ' register, which on most machines, can only be |
---|
614 | copied to or from general registers, but not memory. Some |
---|
615 | machines allow copying all registers to and from memory, but |
---|
616 | require a scratch register for stores to some memory locations |
---|
617 | (e.g., those with symbolic address on the RT, and those with |
---|
618 | certain symbolic address on the Sparc when compiling PIC). In |
---|
619 | some cases, both an intermediate and a scratch register are |
---|
620 | required. |
---|
621 | |
---|
622 | You should define these macros to indicate to the reload phase |
---|
623 | that it may need to allocate at least one register for a reload in |
---|
624 | addition to the register to contain the data. Specifically, if |
---|
625 | copying X to a register CLASS in MODE requires an intermediate |
---|
626 | register, you should define `SECONDARY_INPUT_RELOAD_CLASS' to |
---|
627 | return the largest register class all of whose registers can be |
---|
628 | used as intermediate registers or scratch registers. |
---|
629 | |
---|
630 | If copying a register CLASS in MODE to X requires an intermediate |
---|
631 | or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' should be |
---|
632 | defined to return the largest register class required. If the |
---|
633 | requirements for input and output reloads are the same, the macro |
---|
634 | `SECONDARY_RELOAD_CLASS' should be used instead of defining both |
---|
635 | macros identically. |
---|
636 | |
---|
637 | The values returned by these macros are often `GENERAL_REGS'. |
---|
638 | Return `NO_REGS' if no spare register is needed; i.e., if X can be |
---|
639 | directly copied to or from a register of CLASS in MODE without |
---|
640 | requiring a scratch register. Do not define this macro if it |
---|
641 | would always return `NO_REGS'. |
---|
642 | |
---|
643 | If a scratch register is required (either with or without an |
---|
644 | intermediate register), you should define patterns for |
---|
645 | `reload_inM' or `reload_outM', as required (*note Standard |
---|
646 | Names::.. These patterns, which will normally be implemented with |
---|
647 | a `define_expand', should be similar to the `movM' patterns, |
---|
648 | except that operand 2 is the scratch register. |
---|
649 | |
---|
650 | Define constraints for the reload register and scratch register |
---|
651 | that contain a single register class. If the original reload |
---|
652 | register (whose class is CLASS) can meet the constraint given in |
---|
653 | the pattern, the value returned by these macros is used for the |
---|
654 | class of the scratch register. Otherwise, two additional reload |
---|
655 | registers are required. Their classes are obtained from the |
---|
656 | constraints in the insn pattern. |
---|
657 | |
---|
658 | X might be a pseudo-register or a `subreg' of a pseudo-register, |
---|
659 | which could either be in a hard register or in memory. Use |
---|
660 | `true_regnum' to find out; it will return -1 if the pseudo is in |
---|
661 | memory and the hard register number if it is in a register. |
---|
662 | |
---|
663 | These macros should not be used in the case where a particular |
---|
664 | class of registers can only be copied to memory and not to another |
---|
665 | class of registers. In that case, secondary reload registers are |
---|
666 | not needed and would not be helpful. Instead, a stack location |
---|
667 | must be used to perform the copy and the `movM' pattern should use |
---|
668 | memory as a intermediate storage. This case often occurs between |
---|
669 | floating-point and general registers. |
---|
670 | |
---|
671 | `SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M)' |
---|
672 | Certain machines have the property that some registers cannot be |
---|
673 | copied to some other registers without using memory. Define this |
---|
674 | macro on those machines to be a C expression that is non-zero if |
---|
675 | objects of mode M in registers of CLASS1 can only be copied to |
---|
676 | registers of class CLASS2 by storing a register of CLASS1 into |
---|
677 | memory and loading that memory location into a register of CLASS2. |
---|
678 | |
---|
679 | Do not define this macro if its value would always be zero. |
---|
680 | |
---|
681 | `SECONDARY_MEMORY_NEEDED_RTX (MODE)' |
---|
682 | Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler |
---|
683 | allocates a stack slot for a memory location needed for register |
---|
684 | copies. If this macro is defined, the compiler instead uses the |
---|
685 | memory location defined by this macro. |
---|
686 | |
---|
687 | Do not define this macro if you do not define |
---|
688 | `SECONDARY_MEMORY_NEEDED'. |
---|
689 | |
---|
690 | `SECONDARY_MEMORY_NEEDED_MODE (MODE)' |
---|
691 | When the compiler needs a secondary memory location to copy |
---|
692 | between two registers of mode MODE, it normally allocates |
---|
693 | sufficient memory to hold a quantity of `BITS_PER_WORD' bits and |
---|
694 | performs the store and load operations in a mode that many bits |
---|
695 | wide and whose class is the same as that of MODE. |
---|
696 | |
---|
697 | This is right thing to do on most machines because it ensures that |
---|
698 | all bits of the register are copied and prevents accesses to the |
---|
699 | registers in a narrower mode, which some machines prohibit for |
---|
700 | floating-point registers. |
---|
701 | |
---|
702 | However, this default behavior is not correct on some machines, |
---|
703 | such as the DEC Alpha, that store short integers in floating-point |
---|
704 | registers differently than in integer registers. On those |
---|
705 | machines, the default widening will not work correctly and you |
---|
706 | must define this macro to suppress that widening in some cases. |
---|
707 | See the file `alpha.h' for details. |
---|
708 | |
---|
709 | Do not define this macro if you do not define |
---|
710 | `SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is |
---|
711 | `BITS_PER_WORD' bits wide is correct for your machine. |
---|
712 | |
---|
713 | `SMALL_REGISTER_CLASSES' |
---|
714 | Normally the compiler avoids choosing registers that have been |
---|
715 | explicitly mentioned in the rtl as spill registers (these |
---|
716 | registers are normally those used to pass parameters and return |
---|
717 | values). However, some machines have so few registers of certain |
---|
718 | classes that there would not be enough registers to use as spill |
---|
719 | registers if this were done. |
---|
720 | |
---|
721 | Define `SMALL_REGISTER_CLASSES' to be an expression with a non-zero |
---|
722 | value on these machines. When this macro has a non-zero value, the |
---|
723 | compiler allows registers explicitly used in the rtl to be used as |
---|
724 | spill registers but avoids extending the lifetime of these |
---|
725 | registers. |
---|
726 | |
---|
727 | It is always safe to define this macro with a non-zero value, but |
---|
728 | if you unnecessarily define it, you will reduce the amount of |
---|
729 | optimizations that can be performed in some cases. If you do not |
---|
730 | define this macro with a non-zero value when it is required, the |
---|
731 | compiler will run out of spill registers and print a fatal error |
---|
732 | message. For most machines, you should not define this macro at |
---|
733 | all. |
---|
734 | |
---|
735 | `CLASS_LIKELY_SPILLED_P (CLASS)' |
---|
736 | A C expression whose value is nonzero if pseudos that have been |
---|
737 | assigned to registers of class CLASS would likely be spilled |
---|
738 | because registers of CLASS are needed for spill registers. |
---|
739 | |
---|
740 | The default value of this macro returns 1 if CLASS has exactly one |
---|
741 | register and zero otherwise. On most machines, this default |
---|
742 | should be used. Only define this macro to some other expression |
---|
743 | if pseudo allocated by `local-alloc.c' end up in memory because |
---|
744 | their hard registers were needed for spill registers. If this |
---|
745 | macro returns nonzero for those classes, those pseudos will only |
---|
746 | be allocated by `global.c', which knows how to reallocate the |
---|
747 | pseudo to another register. If there would not be another |
---|
748 | register available for reallocation, you should not change the |
---|
749 | definition of this macro since the only effect of such a |
---|
750 | definition would be to slow down register allocation. |
---|
751 | |
---|
752 | `CLASS_MAX_NREGS (CLASS, MODE)' |
---|
753 | A C expression for the maximum number of consecutive registers of |
---|
754 | class CLASS needed to hold a value of mode MODE. |
---|
755 | |
---|
756 | This is closely related to the macro `HARD_REGNO_NREGS'. In fact, |
---|
757 | the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be |
---|
758 | the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all |
---|
759 | REGNO values in the class CLASS. |
---|
760 | |
---|
761 | This macro helps control the handling of multiple-word values in |
---|
762 | the reload pass. |
---|
763 | |
---|
764 | `CLASS_CANNOT_CHANGE_SIZE' |
---|
765 | If defined, a C expression for a class that contains registers |
---|
766 | which the compiler must always access in a mode that is the same |
---|
767 | size as the mode in which it loaded the register. |
---|
768 | |
---|
769 | For the example, loading 32-bit integer or floating-point objects |
---|
770 | into floating-point registers on the Alpha extends them to 64-bits. |
---|
771 | Therefore loading a 64-bit object and then storing it as a 32-bit |
---|
772 | object does not store the low-order 32-bits, as would be the case |
---|
773 | for a normal register. Therefore, `alpha.h' defines this macro as |
---|
774 | `FLOAT_REGS'. |
---|
775 | |
---|
776 | Three other special macros describe which operands fit which |
---|
777 | constraint letters. |
---|
778 | |
---|
779 | `CONST_OK_FOR_LETTER_P (VALUE, C)' |
---|
780 | A C expression that defines the machine-dependent operand |
---|
781 | constraint letters (`I', `J', `K', ... `P') that specify |
---|
782 | particular ranges of integer values. If C is one of those |
---|
783 | letters, the expression should check that VALUE, an integer, is in |
---|
784 | the appropriate range and return 1 if so, 0 otherwise. If C is |
---|
785 | not one of those letters, the value should be 0 regardless of |
---|
786 | VALUE. |
---|
787 | |
---|
788 | `CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)' |
---|
789 | A C expression that defines the machine-dependent operand |
---|
790 | constraint letters that specify particular ranges of |
---|
791 | `const_double' values (`G' or `H'). |
---|
792 | |
---|
793 | If C is one of those letters, the expression should check that |
---|
794 | VALUE, an RTX of code `const_double', is in the appropriate range |
---|
795 | and return 1 if so, 0 otherwise. If C is not one of those |
---|
796 | letters, the value should be 0 regardless of VALUE. |
---|
797 | |
---|
798 | `const_double' is used for all floating-point constants and for |
---|
799 | `DImode' fixed-point constants. A given letter can accept either |
---|
800 | or both kinds of values. It can use `GET_MODE' to distinguish |
---|
801 | between these kinds. |
---|
802 | |
---|
803 | `EXTRA_CONSTRAINT (VALUE, C)' |
---|
804 | A C expression that defines the optional machine-dependent |
---|
805 | constraint letters (`Q', `R', `S', `T', `U') that can be used to |
---|
806 | segregate specific types of operands, usually memory references, |
---|
807 | for the target machine. Normally this macro will not be defined. |
---|
808 | If it is required for a particular target machine, it should |
---|
809 | return 1 if VALUE corresponds to the operand type represented by |
---|
810 | the constraint letter C. If C is not defined as an extra |
---|
811 | constraint, the value returned should be 0 regardless of VALUE. |
---|
812 | |
---|
813 | For example, on the ROMP, load instructions cannot have their |
---|
814 | output in r0 if the memory reference contains a symbolic address. |
---|
815 | Constraint letter `Q' is defined as representing a memory address |
---|
816 | that does *not* contain a symbolic address. An alternative is |
---|
817 | specified with a `Q' constraint on the input and `r' on the |
---|
818 | output. The next alternative specifies `m' on the input and a |
---|
819 | register class that does not include r0 on the output. |
---|
820 | |
---|
821 | |
---|
822 | File: gcc.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros |
---|
823 | |
---|
824 | Stack Layout and Calling Conventions |
---|
825 | ==================================== |
---|
826 | |
---|
827 | This describes the stack layout and calling conventions. |
---|
828 | |
---|
829 | * Menu: |
---|
830 | |
---|
831 | * Frame Layout:: |
---|
832 | * Stack Checking:: |
---|
833 | * Frame Registers:: |
---|
834 | * Elimination:: |
---|
835 | * Stack Arguments:: |
---|
836 | * Register Arguments:: |
---|
837 | * Scalar Return:: |
---|
838 | * Aggregate Return:: |
---|
839 | * Caller Saves:: |
---|
840 | * Function Entry:: |
---|
841 | * Profiling:: |
---|
842 | |
---|
843 | |
---|
844 | File: gcc.info, Node: Frame Layout, Next: Stack Checking, Up: Stack and Calling |
---|
845 | |
---|
846 | Basic Stack Layout |
---|
847 | ------------------ |
---|
848 | |
---|
849 | Here is the basic stack layout. |
---|
850 | |
---|
851 | `STACK_GROWS_DOWNWARD' |
---|
852 | Define this macro if pushing a word onto the stack moves the stack |
---|
853 | pointer to a smaller address. |
---|
854 | |
---|
855 | When we say, "define this macro if ...," it means that the |
---|
856 | compiler checks this macro only with `#ifdef' so the precise |
---|
857 | definition used does not matter. |
---|
858 | |
---|
859 | `FRAME_GROWS_DOWNWARD' |
---|
860 | Define this macro if the addresses of local variable slots are at |
---|
861 | negative offsets from the frame pointer. |
---|
862 | |
---|
863 | `ARGS_GROW_DOWNWARD' |
---|
864 | Define this macro if successive arguments to a function occupy |
---|
865 | decreasing addresses on the stack. |
---|
866 | |
---|
867 | `STARTING_FRAME_OFFSET' |
---|
868 | Offset from the frame pointer to the first local variable slot to |
---|
869 | be allocated. |
---|
870 | |
---|
871 | If `FRAME_GROWS_DOWNWARD', find the next slot's offset by |
---|
872 | subtracting the first slot's length from `STARTING_FRAME_OFFSET'. |
---|
873 | Otherwise, it is found by adding the length of the first slot to |
---|
874 | the value `STARTING_FRAME_OFFSET'. |
---|
875 | |
---|
876 | `STACK_POINTER_OFFSET' |
---|
877 | Offset from the stack pointer register to the first location at |
---|
878 | which outgoing arguments are placed. If not specified, the |
---|
879 | default value of zero is used. This is the proper value for most |
---|
880 | machines. |
---|
881 | |
---|
882 | If `ARGS_GROW_DOWNWARD', this is the offset to the location above |
---|
883 | the first location at which outgoing arguments are placed. |
---|
884 | |
---|
885 | `FIRST_PARM_OFFSET (FUNDECL)' |
---|
886 | Offset from the argument pointer register to the first argument's |
---|
887 | address. On some machines it may depend on the data type of the |
---|
888 | function. |
---|
889 | |
---|
890 | If `ARGS_GROW_DOWNWARD', this is the offset to the location above |
---|
891 | the first argument's address. |
---|
892 | |
---|
893 | `STACK_DYNAMIC_OFFSET (FUNDECL)' |
---|
894 | Offset from the stack pointer register to an item dynamically |
---|
895 | allocated on the stack, e.g., by `alloca'. |
---|
896 | |
---|
897 | The default value for this macro is `STACK_POINTER_OFFSET' plus the |
---|
898 | length of the outgoing arguments. The default is correct for most |
---|
899 | machines. See `function.c' for details. |
---|
900 | |
---|
901 | `DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)' |
---|
902 | A C expression whose value is RTL representing the address in a |
---|
903 | stack frame where the pointer to the caller's frame is stored. |
---|
904 | Assume that FRAMEADDR is an RTL expression for the address of the |
---|
905 | stack frame itself. |
---|
906 | |
---|
907 | If you don't define this macro, the default is to return the value |
---|
908 | of FRAMEADDR--that is, the stack frame address is also the address |
---|
909 | of the stack word that points to the previous frame. |
---|
910 | |
---|
911 | `SETUP_FRAME_ADDRESSES ()' |
---|
912 | If defined, a C expression that produces the machine-specific code |
---|
913 | to setup the stack so that arbitrary frames can be accessed. For |
---|
914 | example, on the Sparc, we must flush all of the register windows |
---|
915 | to the stack before we can access arbitrary stack frames. This |
---|
916 | macro will seldom need to be defined. |
---|
917 | |
---|
918 | `RETURN_ADDR_RTX (COUNT, FRAMEADDR)' |
---|
919 | A C expression whose value is RTL representing the value of the |
---|
920 | return address for the frame COUNT steps up from the current |
---|
921 | frame, after the prologue. FRAMEADDR is the frame pointer of the |
---|
922 | COUNT frame, or the frame pointer of the COUNT - 1 frame if |
---|
923 | `RETURN_ADDR_IN_PREVIOUS_FRAME' is defined. |
---|
924 | |
---|
925 | The value of the expression must always be the correct address when |
---|
926 | COUNT is zero, but may be `NULL_RTX' if there is not way to |
---|
927 | determine the return address of other frames. |
---|
928 | |
---|
929 | `RETURN_ADDR_IN_PREVIOUS_FRAME' |
---|
930 | Define this if the return address of a particular stack frame is |
---|
931 | accessed from the frame pointer of the previous stack frame. |
---|
932 | |
---|
933 | `INCOMING_RETURN_ADDR_RTX' |
---|
934 | A C expression whose value is RTL representing the location of the |
---|
935 | incoming return address at the beginning of any function, before |
---|
936 | the prologue. This RTL is either a `REG', indicating that the |
---|
937 | return value is saved in `REG', or a `MEM' representing a location |
---|
938 | in the stack. |
---|
939 | |
---|
940 | You only need to define this macro if you want to support call |
---|
941 | frame debugging information like that provided by DWARF 2. |
---|
942 | |
---|
943 | `INCOMING_FRAME_SP_OFFSET' |
---|
944 | A C expression whose value is an integer giving the offset, in |
---|
945 | bytes, from the value of the stack pointer register to the top of |
---|
946 | the stack frame at the beginning of any function, before the |
---|
947 | prologue. The top of the frame is defined to be the value of the |
---|
948 | stack pointer in the previous frame, just before the call |
---|
949 | instruction. |
---|
950 | |
---|
951 | You only need to define this macro if you want to support call |
---|
952 | frame debugging information like that provided by DWARF 2. |
---|
953 | |
---|
954 | |
---|
955 | File: gcc.info, Node: Stack Checking, Next: Frame Registers, Prev: Frame Layout, Up: Stack and Calling |
---|
956 | |
---|
957 | Specifying How Stack Checking is Done |
---|
958 | ------------------------------------- |
---|
959 | |
---|
960 | GNU CC will check that stack references are within the boundaries of |
---|
961 | the stack, if the `-fstack-check' is specified, in one of three ways: |
---|
962 | |
---|
963 | 1. If the value of the `STACK_CHECK_BUILTIN' macro is nonzero, GNU CC |
---|
964 | will assume that you have arranged for stack checking to be done at |
---|
965 | appropriate places in the configuration files, e.g., in |
---|
966 | `FUNCTION_PROLOGUE'. GNU CC will do not other special processing. |
---|
967 | |
---|
968 | 2. If `STACK_CHECK_BUILTIN' is zero and you defined a named pattern |
---|
969 | called `check_stack' in your `md' file, GNU CC will call that |
---|
970 | pattern with one argument which is the address to compare the stack |
---|
971 | value against. You must arrange for this pattern to report an |
---|
972 | error if the stack pointer is out of range. |
---|
973 | |
---|
974 | 3. If neither of the above are true, GNU CC will generate code to |
---|
975 | periodically "probe" the stack pointer using the values of the |
---|
976 | macros defined below. |
---|
977 | |
---|
978 | Normally, you will use the default values of these macros, so GNU CC |
---|
979 | will use the third approach. |
---|
980 | |
---|
981 | `STACK_CHECK_BUILTIN' |
---|
982 | A nonzero value if stack checking is done by the configuration |
---|
983 | files in a machine-dependent manner. You should define this macro |
---|
984 | if stack checking is require by the ABI of your machine or if you |
---|
985 | would like to have to stack checking in some more efficient way |
---|
986 | than GNU CC's portable approach. The default value of this macro |
---|
987 | is zero. |
---|
988 | |
---|
989 | `STACK_CHECK_PROBE_INTERVAL' |
---|
990 | An integer representing the interval at which GNU CC must generate |
---|
991 | stack probe instructions. You will normally define this macro to |
---|
992 | be no larger than the size of the "guard pages" at the end of a |
---|
993 | stack area. The default value of 4096 is suitable for most |
---|
994 | systems. |
---|
995 | |
---|
996 | `STACK_CHECK_PROBE_LOAD' |
---|
997 | A integer which is nonzero if GNU CC should perform the stack probe |
---|
998 | as a load instruction and zero if GNU CC should use a store |
---|
999 | instruction. The default is zero, which is the most efficient |
---|
1000 | choice on most systems. |
---|
1001 | |
---|
1002 | `STACK_CHECK_PROTECT' |
---|
1003 | The number of bytes of stack needed to recover from a stack |
---|
1004 | overflow, for languages where such a recovery is supported. The |
---|
1005 | default value of 75 words should be adequate for most machines. |
---|
1006 | |
---|
1007 | `STACK_CHECK_MAX_FRAME_SIZE' |
---|
1008 | The maximum size of a stack frame, in bytes. GNU CC will generate |
---|
1009 | probe instructions in non-leaf functions to ensure at least this |
---|
1010 | many bytes of stack are available. If a stack frame is larger |
---|
1011 | than this size, stack checking will not be reliable and GNU CC |
---|
1012 | will issue a warning. The default is chosen so that GNU CC only |
---|
1013 | generates one instruction on most systems. You should normally |
---|
1014 | not change the default value of this macro. |
---|
1015 | |
---|
1016 | `STACK_CHECK_FIXED_FRAME_SIZE' |
---|
1017 | GNU CC uses this value to generate the above warning message. It |
---|
1018 | represents the amount of fixed frame used by a function, not |
---|
1019 | including space for any callee-saved registers, temporaries and |
---|
1020 | user variables. You need only specify an upper bound for this |
---|
1021 | amount and will normally use the default of four words. |
---|
1022 | |
---|
1023 | `STACK_CHECK_MAX_VAR_SIZE' |
---|
1024 | The maximum size, in bytes, of an object that GNU CC will place in |
---|
1025 | the fixed area of the stack frame when the user specifies |
---|
1026 | `-fstack-check'. GNU CC computed the default from the values of |
---|
1027 | the above macros and you will normally not need to override that |
---|
1028 | default. |
---|
1029 | |
---|