![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to internals-6 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / cmd / gcc|
Return to internals-6 CVS log | Up to [Research Unix] / researchv10dc / cmd / gcc |
1.1 root 1:
2:
3: File: internals, Node: Registers, Next: Register Classes, Prev: Storage Layout, Up: Machine Macros
4:
5: Register Usage
6: ==============
7:
8: `FIRST_PSEUDO_REGISTER'
9: Number of hardware registers known to the compiler. They receive
10: numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first pseudo
11: register's number really is assigned the number `FIRST_PSEUDO_REGISTER'.
12:
13: `FIXED_REGISTERS'
14: An initializer that says which registers are used for fixed purposes
15: all throughout the compiled code and are therefore not available for
16: general allocation. These would include the stack pointer, the frame
17: pointer, the program counter on machines where that is considered one
18: of the addressable registers, and any other numbered register with a
19: standard use.
20:
21: This information is expressed as a sequence of numbers, separated by
22: commas and surrounded by braces. The Nth number is 1 if register N is
23: fixed, 0 otherwise.
24:
25: The table initialized from this macro, and the table initialized by
26: the following one, may be overridden at run time either automatically,
27: by the actions of the macro `CONDITIONAL_REGISTER_USAGE', or by the
28: user with the command options `-ffixed-REG', `-fcall-used-REG' and
29: `-fcall-saved-REG'.
30:
31: `CALL_USED_REGISTERS'
32: Like `FIXED_REGISTERS' but has 1 for each register that is clobbered
33: (in general) by function calls as well as for fixed registers. This
34: macro therefore identifies the registers that are not available for
35: general allocation of values that must live across function calls.
36:
37: If a register has 0 in `CALL_USED_REGISTERS', the compiler
38: automatically saves it on function entry and restores it on function
39: exit, if the register is used within the function.
40:
41: `CONDITIONAL_REGISTER_USAGE'
42: Zero or more C statements that may conditionally modify two variables
43: `fixed_regs' and `call_used_regs' (both of type `char []') after they
44: have been initialized from the two preceding macros.
45:
46: This is necessary in case the fixed or call-clobbered registers depend
47: on target flags.
48:
49: You need not define this macro if it has no work to do.
50:
51: `HARD_REGNO_REGS (REGNO, MODE)'
52: A C expression for the number of consecutive hard registers, starting
53: at register number REGNO, required to hold a value of mode MODE.
54:
55: On a machine where all registers are exactly one word, a suitable
56: definition of this macro is
57:
58: #define HARD_REGNO_NREGS(REGNO, MODE) \
59: ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
60: / UNITS_PER_WORD))
61:
62: `HARD_REGNO_MODE_OK (REGNO, MODE)'
63: A C expression that is nonzero if it is permissible to store a value
64: of mode MODE in hard register number REGNO (or in several registers
65: starting with that one). For a machine where all registers are
66: equivalent, a suitable definition is
67:
68: #define HARD_REGNO_MODE_OK(REGNO, MODE) 1
69:
70: It is not necessary for this macro to check for fixed register numbers
71: because the allocation mechanism considers them to be always occupied.
72:
73: Many machines have special registers for floating point arithmetic.
74: Often people assume that floating point machine modes are allowed only
75: in floating point registers. This is not true. Any registers that
76: can hold integers can safely *hold* a floating point machine mode,
77: whether or not floating arithmetic can be done on it in those registers.
78:
79: The true significance of special floating registers is rather than
80: non-floating-point machine modes *may not* go in those registers.
81: This is true if the floating registers normalize any value stored in
82: them, because storing a non-floating value there would garble it. If
83: the floating registers do not automatically normalize, if you can
84: store any bit pattern in one and retrieve it unchanged without a trap,
85: then any machine mode may go in a floating register and this macro
86: should say so.
87:
88: Sometimes there are floating registers that are especially slow to
89: access, so that it is better to store a value in a stack frame than in
90: such a register if floating point arithmetic is not being done. As
91: long as the floating registers are not in class `GENERAL_REGS', they
92: will not be used unless some insn's constraint asks for one.
93:
94: It is obligatory to support floating point `move' instructions into
95: and out of general registers, because unions and structures (which
96: have modes `SImode' or `DImode') can be in those registers and they
97: may have floating point members.
98:
99: `MODES_TIEABLE_P (MODE1, MODE2)'
100: A C expression that is nonzero if it is desirable to choose register
101: allocation so as to avoid move instructions between a value of mode
102: MODE1 and a value of mode MODE2.
103:
104: If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R, MODE2)'
105: are ever different for any R, then `MODES_TIEABLE_P (MODE1, MODE2)'
106: must be zero.
107:
108: `PC_REGNUM'
109: If the program counter has a register number, define this as that
110: register number. Otherwise, do not define it.
111:
112: `STACK_POINTER_REGNUM'
113: The register number of the stack pointer register, which must also be
114: a fixed register according to `FIXED_REGISTERS'. On many machines,
115: the hardware determines which register this is.
116:
117: `FRAME_POINTER_REGNUM'
118: The register number of the frame pointer register, which is used to
119: access automatic variables in the stack frame. On some machines, the
120: hardware determines which register this is. On other machines, you
121: can choose any register you wish for this purpose.
122:
123: `FRAME_POINTER_REQUIRED'
124: A C expression which is nonzero if a function must have and use a
125: frame pointer. This expression is evaluated in the reload pass, in
126: the function `reload', and it can in principle examine the current
127: function and decide according to the facts, but on most machines the
128: constant 0 or the constant 1 suffices. Use 0 when the machine allows
129: code to be generated with no frame pointer, and doing so saves some
130: time or space. Use 1 when there is no possible advantage to avoiding
131: a frame pointer.
132:
133: In certain cases, the compiler does not know how to do without a frame
134: pointer. The compiler recognizes those cases and automatically gives
135: the function a frame pointer regardless of what
136: `FRAME_POINTER_REQUIRED' says. You don't need to worry about them.
137:
138: In a function that does not require a frame pointer, the frame pointer
139: register can be allocated for ordinary usage, provided it is not
140: marked as a fixed register. See `FIXED_REGISTERS' for more information.
141:
142: `ARG_POINTER_REGNUM'
143: The register number of the arg pointer register, which is used to
144: access the function's argument list. On some machines, this is the
145: same as the frame pointer register. On some machines, the hardware
146: determines which register this is. On other machines, you can choose
147: any register you wish for this purpose. It must in any case be a
148: fixed register according to `FIXED_REGISTERS'.
149:
150: `STATIC_CHAIN_REGNUM'
151: The register number used for passing a function's static chain
152: pointer. This is needed for languages such as Pascal and Algol where
153: functions defined within other functions can access the local
154: variables of the outer functions; it is not currently used because C
155: does not provide this feature.
156:
157: The static chain register need not be a fixed register.
158:
159: `STRUCT_VALUE_REGNUM'
160: When a function's value's mode is `BLKmode', the value is not returned
161: according to `FUNCTION_VALUE'. Instead, the caller passes the address
162: of a block of memory in which the value should be stored.
163: `STRUCT_VALUE_REGNUM' is the register in which this address is passed.
164:
165:
166: File: internals, Node: Register Classes, Next: Stack Layout, Prev: Registers, Up: Machine Macros
167:
168: Register Classes
169: ================
170:
171: On many machines, the numbered registers are not all equivalent. For
172: example, certain registers may not be allowed for indexed addressing;
173: certain registers may not be allowed in some instructions. These machine
174: restrictions are described to the compiler using "register classes".
175:
176: You define a number of register classes, giving each one a name and saying
177: which of the registers belong to it. Then you can specify register classes
178: that are allowed as operands to particular instruction patterns.
179:
180: In general, each register will belong to several classes. In fact, one
181: class must be named `ALL_REGS' and contain all the registers. Another
182: class must be named `NO_REGS' and contain no registers. Often the union of
183: two classes will be another class; however, this is not required.
184:
185: One of the classes must be named `GENERAL_REGS'. There is nothing terribly
186: special about the name, but the operand constraint letters `r' and `g'
187: specify this class. If `GENERAL_REGS' is the same as `ALL_REGS', just
188: define it as a macro which expands to `ALL_REGS'.
189:
190: The way classes other than `GENERAL_REGS' are specified in operand
191: constraints is through machine-dependent operand constraint letters. You
192: can define such letters to correspond to various classes, then use them in
193: operand constraints.
194:
195: You should define a class for the union of two classes whenever some
196: instruction allows both classes. For example, if an instruction allows
197: either a floating-point (coprocessor) register or a general register for a
198: certain operand, you should define a class `FLOAT_OR_GENERAL_REGS' which
199: includes both of them. Otherwise you will get suboptimal code.
200:
201: You must also specify certain redundant information about the register
202: classes: for each class, which classes contain it and which ones are
203: contained in it; for each pair of classes, the largest class contained in
204: their union.
205:
206: `enum reg_class'
207: An enumeral type that must be defined with all the register class
208: names as enumeral values. `NO_REGS' must be first. `ALL_REGS' must
209: be the last register class, followed by one more enumeral value,
210: `LIM_REG_CLASSES', which is not a register class but rather tells how
211: many classes there are.
212:
213: Each register class has a number, which is the value of casting the
214: class name to type `int'. The number serves as an index in many of
215: the tables described below.
216:
217: `REG_CLASS_NAMES'
218: An initializer containing the names of the register classes as C
219: string constants. These names are used in writing some of the
220: debugging dumps.
221:
222: `REG_CLASS_CONTENTS'
223: An initializer containing the contents of the register classes, as
224: integers which are bit masks. The Nth integer specifies the contents
225: of class N. The way the integer MASK is interpreted is that register
226: R is in the class if `MASK & (1 << R)' is 1.
227:
228: When the machine has more than 32 registers, an integer does not
229: suffice. Then the integers are replaced by sub-initializers, braced
230: groupings containing several integers. Each sub-initializer must be
231: suitable as an initializer for the type `HARD_REG_SET' which is
232: defined in `hard-reg-set.h'.
233:
234: `REGNO_REG_CLASS (REGNO)'
235: A C expression whose value is a register class containing hard
236: regiSTER REGNO. In general there is more that one such class; choose
237: a class which is "minimal", meaning that no smaller class also
238: contains the register.
239:
240: `INDEX_REG_CLASS'
241: A macro whose definition is the name of the class to which a valid
242: index register must belong.
243:
244: `REG_CLASS_FROM_LETTER (CHAR)'
245: A C expression which defines the machine-dependent operand constraint
246: letters for register classes. If CHAR is such a letter, the value
247: should be the register class corresponding to it. Otherwise, the
248: value should be `NO_REGS'.
249:
250: `REGNO_OK_FOR_BASE_P (NUM)'
251: A C expression which is nonzero if register number NUM is suitable for
252: use as a base register in operand addresses. It may be either a
253: suitable hard register or a pseudo register that has been allocated
254: such a hard register.
255:
256: `REGNO_OK_FOR_INDEX_P (NUM)'
257: A C expression which is nonzero if register number NUM is suitable for
258: use as an index register in operand addresses. It may be either a
259: suitable hard register or a pseudo register that has been allocated
260: such a hard register.
261:
262: The difference between an index register and a base register is that
263: the index register may be scaled. If an address involves the sum of
264: two registers, neither one of them scaled, then either one may be
265: labeled the ``base'' and the other the ``index''; but whichever
266: labeling is used must fit the machine's constraints of which registers
267: may serve in each capacity. The compiler will try both labelings,
268: looking for one that is valid, and reload one or both registers only
269: if neither labeling works.
270:
271: `PREFERRED_RELOAD_CLASS (X, CLASS)'
272: A C expression that places additional restrictions on the register
273: class to use when it is necessary to copy value X into a register in
274: class CLASS. The value is a register class; perhaps CLASS, or perhaps
275: another, smaller class. CLASS is always safe as a value. In fact,
276: the definition
277:
278: #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
279:
280: is always safe. However, sometimes returning a more restrictive class
281: makes better code. For example, on the 68000, when X is an integer
282: constant that is in range for a `moveq' instruction, the value of this
283: macro is always `DATA_REGS' as long as CLASS includes the data
284: registers. Requiring a data register guarantees that a `moveq' will
285: be used.
286:
287: `CLASS_MAX_NREGS (CLASS, MODE)'
288: A C expression for the maximum number of consecutive registers of
289: cLASS CLASS needed to hold a value of mode MODE.
290:
291: This is closely related to the macro `HARD_REGNO_NREGS'. In fact, the
292: value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be the
293: maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all REGNO values
294: in the class CLASS.
295:
296: This macro helps control the handling of multiple-word values in the
297: reload pass.
298:
299: Two other special macros describe which constants fit which constraint
300: letters.
301:
302: `CONST_OK_FOR_LETTER_P (VALUE, C)'
303: A C expression that defines the machine-dependent operand constraint
304: letters that specify particular ranges of integer values. If C is one
305: of those letters, the expression should check that VALUE, an integer,
306: is in the appropriate range and return 1 if so, 0 otherwise. If C is
307: not one of those letters, the value should be 0 regardless of VALUE.
308:
309: `CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)'
310: A C expression that defines the machine-dependent operand constraint
311: letters that specify particular ranges of floating values. If C is
312: one of those letters, the expression should check that VALUE, an RTX
313: of code `const_double', is in the appropriate range and return 1 if
314: so, 0 otherwise. If C is not one of those letters, the value should
315: be 0 regardless of VALUE.
316:
317:
318: File: internals, Node: Stack Layout, Next: Library Names, Prev: Register Classes, Up: Machine Macros
319:
320: Describing Stack Layout
321: =======================
322:
323: `STACK_GROWS_DOWNWARD'
324: Define this macro if pushing a word onto the stack moves the stack
325: pointer to a smaller address.
326:
327: When we say, ``define this macro if ...,'' it means that the compiler
328: checks this macro only with `#ifdef' so the precise definition used
329: does not matter.
330:
331: `FRAME_GROWS_DOWNWARD'
332: Define this macro if the addresses of local variable slots are at
333: negative offsets from the frame pointer.
334:
335: `STARTING_FRAME_OFFSET'
336: Offset from the frame pointer to the first local variable slot to be
337: allocated.
338:
339: If `FRAME_GROWS_DOWNWARD', the next slot's offset is found by
340: subtracting the length of the first slot from `STARTING_FRAME_OFFSET'.
341: Otherwise, it is found by adding the length of the first slot to the
342: value `STARTING_FRAME_OFFSET'.
343:
344: `PUSH_ROUNDING (NPUSHED)'
345: A C expression that is the number of bytes actually pushed onto the
346: stack when an instruction attempts to push NPUSHED bytes.
347:
348: If the target machine does not have a push instruction, do not define
349: this macro. That directs GNU CC to use an alternate strategy: to
350: allocate the entire argument block and then store the arguments into it.
351:
352: On some machines, the definition
353:
354: #define PUSH_ROUNDING(BYTES) (BYTES)
355:
356: will suffice. But on other machines, instructions that appear to push
357: one byte actually push two bytes in an attempt to maintain alignment.
358: Then the definition should be
359:
360: #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
361:
362: `FIRST_PARM_OFFSET'
363: Offset from the argument pointer register to the first argument's
364: address.
365:
366: `RETURN_POPS_ARGS (FUNTYPE)'
367: A C expression that should be 1 if a function pops its own arguments
368: on returning, or 0 if the function pops no arguments and the caller
369: must therefore pop them all after the function returns.
370:
371: FUNTYPE is a C variable whose value is a tree node that describes the
372: function in question. Normally it is a node of type `FUNCTION_TYPE'
373: that describes the data type of the function. From this it is
374: possible to obtain the data types of the value and arguments (if known).
375:
376: When a call to a library function is being considered, FUNTYPE will
377: contain an identifier node for the library function. Thus, if you
378: need to distinguish among various library functions, you can do so by
379: their names. Note that ``library function'' in this context means a
380: function used to perform arithmetic, whose name is known specially in
381: the compiler and was not mentioned in the C code being compiled.
382:
383: On the Vax, all functions always pop their arguments, so the
384: definition of this macro is 1. On the 68000, using the standard
385: calling convention, no functions pop their arguments, so the value of
386: the macro is always 0 in this case. But an alternative calling
387: convention is available in which functions that take a fixed number of
388: arguments pop them but other functions (such as `printf') pop nothing
389: (the caller pops all). When this convention is in use, FUNTYPE is
390: examined to determine whether a function takes a fixed number of
391: arguments.
392:
393: `FUNCTION_VALUE (VALTYPE, FUNC)'
394: A C expression to create an RTX representing the place where a
395: function returns a value of data type VALTYPE. VALTYPE is a tree node
396: representing a data type. Write `TYPE_MODE (VALTYPE)' to get the
397: machine mode used to represent that type. On many machines, only the
398: mode is relevant. (Actually, on most machines, scalar values are
399: returned in the same place regardless of mode).
400:
401: If the precise function being called is known, FUNC is a tree node
402: (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
403: makes it possible to use a different value-returning convention for
404: specific functions when all their calls are known.
405:
406: `FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)'
407: Define this macro if the target machine has ``register windows'' so
408: that the register in which a function returns its value is not the
409: same as the one in which the caller sees the value.
410:
411: For such machines, `FUNCTION_VALUE' computes the register in which the
412: caller will see the value, and `FUNCTION_OUTGOING_VALUE' should be
413: defined in a similar fashion to tell the function where to put the
414: value.
415:
416: If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE' serves
417: both purposes.
418:
419: `LIBCALL_VALUE (MODE)'
420: A C expression to create an RTX representing the place where a library
421: function returns a value of mode MODE. If the precise function being
422: called is known, FUNC is a tree node (`FUNCTION_DECL') for it;
423: otherwise, FUNC is a null pointer. This makes it possible to use a
424: different value-returning convention for specific functions when all
425: their calls are known.
426:
427: Note that ``library function'' in this context means a compiler
428: support routine, used to perform arithmetic, whose name is known
429: specially by the compiler and was not mentioned in the C code being
430: compiled.
431:
432: `FUNCTION_VALUE_REGNO_P (REGNO)'
433: A C expression that is nonzero if REGNO is the number of a hard
434: register in which function values are sometimes returned.
435:
436: A register whose use for returning values is limited to serving as the
437: second of a pair (for a value of type `double', say) need not be
438: recognized by this macro. So for most machines, this definition
439: suffices:
440:
441: #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
442:
443: `FUNCTION_ARG (CUM, MODE, TYPE, NAMED)'
444: A C expression that controls whether a function argument is passed in
445: a register, and which register.
446:
447: The arguments are CUM, which summarizes all the previous arguments;
448: MODE, the machine mode of the argument; TYPE, the data type of the
449: argument as a tree node or 0 if that is not known (which happens for C
450: support library functions); and NAMED, which is 1 for an ordinary
451: argument and 0 for nameless arguments that correspond to `...' in the
452: called function's prototype.
453:
454: The value of the expression should either be a `reg' RTX for the hard
455: register in which to pass the argument, or zero to pass the argument
456: on the stack.
457:
458: For the Vax and 68000, where normally all arguments are pushed, zero
459: suffices as a definition.
460:
461: `FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)'
462: Define this macro if the target machine has ``register windows'', so
463: that the register in which a function sees an arguments is not
464: necessarily the same as the one in which the caller passed the argument.
465:
466: For such machines, `FUNCTION_ARG' computes the register in which the
467: caller passes the value, and `FUNCTION_INCOMING_ARG' should be defined
468: in a similar fashion to tell the function being called where the
469: arguments will arrive.
470:
471: If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves both
472: purposes.
473:
474: `FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)'
475: A C expression for the number of words, at the beginning of an
476: argument, must be put in registers. The value must be zero for
477: arguments that are passed entirely in registers or that are entirely
478: pushed on the stack.
479:
480: On some machines, certain arguments must be passed partially in
481: registers and partially in memory. On these machines, typically the
482: first N words of arguments are passed in registers, and the rest on
483: the stack. If a multi-word argument (a `double' or a structure)
484: crosses that boundary, its first few words must be passed in registers
485: and the rest must be pushed. This macro tells the compiler when this
486: occurs, and how many of the words should go in registers.
487:
488: `FUNCTION_ARG' for these arguments should return the first register to
489: be used by the caller for this argument; likewise
490: `FUNCTION_INCOMING_ARG', for the called function.
491:
492: `CUMULATIVE_ARGS'
493: A C type for declaring a variable that is used as the first argument
494: of `FUNCTION_ARG' and other related values. For some target machines,
495: the type `int' suffices and can hold the number of bytes of argument
496: so far.
497:
498: `INIT_CUMULATIVE_ARGS (CUM)'
499: A C statement (sans semicolon) for initializing the variable CUM for
500: the state at the beginning of the argument list. The variable has
501: type `CUMULATIVE_ARGS'.
502:
503: `FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)'
504: Update the summarizer variable CUM to advance past an argument in the
505: argument list. The values MODE, TYPE and NAMED describe that
506: argument. Once this is done, the variable CUM is suitable for
507: analyzing the *following* argument with `FUNCTION_ARG', etc.
508:
509: `FUNCTION_ARG_REGNO_P (REGNO)'
510: A C expression that is nonzero if REGNO is the number of a hard
511: register in which function arguments are sometimes passed. This does
512: *not* include implicit arguments such as the static chain and the
513: structure-value address. On many machines, no registers can be used
514: for this purpose since all function arguments are pushed on the stack.
515:
516: `FUNCTION_PROLOGUE (FILE, SIZE)'
517: A C compound statement that outputs the assembler code for entry to a
518: function. The prologue is responsible for setting up the stack frame,
519: initializing the frame pointer register, saving registers that must be
520: saved, and allocating SIZE additional bytes of storage for the local
521: variables. SIZE is an integer. FILE is a stdio stream to which the
522: assembler code should be output.
523:
524: The label for the beginning of the function need not be output by this
525: macro. That has already been done when the macro is run.
526:
527: To determine which registers to save, the macro can refer to the array
528: `regs_ever_live': element R is nonzero if hard register R is used
529: anywhere within the function. This implies the function prologue
530: should save register R, but not if it is one of the call-used registers.
531:
532: On machines where functions may or may not have frame-pointers, the
533: function entry code must vary accordingly; it must set up the frame
534: pointer if one is wanted, and not otherwise. To determine whether a
535: frame pointer is in wanted, the macro can refer to the variable
536: `frame_pointer_needed'. The variable's value will be 1 at run time in
537: a function that needs a frame pointer.
538:
539: `FUNCTION_PROFILER (FILE, LABELNO)'
540: A C statement or compound statement to output to FILE some assembler
541: code to call the profiling subroutine `mcount'. Before calling, the
542: assembler code must load the address of a counter variable into a
543: register where `mcount' expects to find the address. The name of this
544: variable is `LP' followed by the number LABELNO, so you would generate
545: the name using `LP%d' in a `fprintf'.
546:
547: The details of how the address should be passed to `mcount' are
548: determined by your operating system environment, not by GNU CC. To
549: figure them out, compile a small program for profiling using the
550: system's installed C compiler and look at the assembler code that
551: results.
552:
553: `EXIT_IGNORES_STACK'
554: Define this macro as a C expression that is nonzero if the return
555: instruction or the function epilogue ignores the value of the stack
556: pointer; in other words, if it is safe to delete an instruction to
557: adjust the stack pointer before a return from the function.
558:
559: Note that this macro's value is relevant only for for which frame
560: pointers are maintained. It is never possible to delete a final stack
561: adjustment in a function that has no frame pointer, and the compiler
562: knows this regardless of `EXIT_IGNORES_STACK'.
563:
564: `FUNCTION_EPILOGUE (FILE, SIZE)'
565: A C compound statement that outputs the assembler code for exit from a
566: function. The epilogue is responsible for restoring the saved
567: registers and stack pointer to their values when the function was
568: called, and returning control to the caller. This macro takes the
569: same arguments as the macro `FUNCTION_PROLOGUE', and the registers to
570: restore are determined from `regs_ever_live' and `CALL_USED_REGISTERS'
571: in the same way.
572:
573: On some machines, there is a single instruction that does all the work
574: of returning from the function. On these machines, give that
575: instruction the name `return' and do not define the macro
576: `FUNCTION_EPILOGUE' at all.
577:
578: On machines where functions may or may not have frame-pointers, the
579: function exit code must vary accordingly. Sometimes the code for
580: these two cases is completely different. To determine whether a frame
581: pointer is in wanted, the macro can refer to the variable
582: `frame_pointer_needed'. The variable's value will be 1 at run time in
583: a function that needs a frame pointer.
584:
585: On some machines, some functions pop their arguments on exit while
586: others leave that for the caller to do. For example, the 68020 when
587: given `-mrtd' pops arguments in functions that take a fixed number of
588: arguments.
589:
590: Your definition of the macro `RETURN_POPS_ARGS' decides which
591: functions pop their own arguments. `FUNCTION_EPILOGUE' needs to know
592: what was decided. The variable `current_function_pops_args' is
593: nonzero if the function should pop its own arguments. If so, use the
594: variable `current_function_args_size' as the number of bytes to pop.
595:
596: `FIX_FRAME_POINTER_ADDRESS (ADDR, DEPTH)'
597: A C compound statement to alter a memory address that uses the frame
598: pointer register so that it uses the stack pointer register instead.
599: This must be done in the instructions that load parameter values into
600: registers, when the reload pass determines that a frame pointer is not
601: necessary for the function. ADDR will be a C variable name, and the
602: updated address should be stored in that variable. DEPTH will be the
603: current depth of stack temporaries (number of bytes of arguments
604: currently pushed). The change in offset between a
605: frame-pointer-relative address and a stack-pointer-relative address
606: must include DEPTH.
607:
608: Even if your machine description specifies there will always be a
609: frame pointer in the frame pointer register, you must still define
610: `FIX_FRAME_POINTER_ADDRESS', but the definition will never be executed
611: at run time, so it may be empty.
612:
613:
614: File: internals, Node: Library Names, Next: Addressing Modes, Prev: Stack Layout, Up: Machine Macros
615:
616: Library Subroutine Names
617: ========================
618:
619: `UDIVSI3_LIBCALL'
620: A C string constant giving the name of the function to call for
621: division of a full-word by a full-word. If you do not define this
622: macro, the default name is used, which is `_udivsi3', a function
623: defined in `gnulib'.
624:
625: `UMODSI3_LIBCALL'
626: A C string constant giving the name of the function to call for the
627: remainder in division of a full-word by a full-word. If you do not
628: define this macro, the default name is used, which is `_umodsi3', a
629: function defined in `gnulib'.
630:
631: `TARGET_MEM_FUNCTIONS'
632: Define this macro if GNU CC should generate calls to the System V (and
633: ANSI C) library functions `memcpy' and `memset' rather than the BSD
634: functions `bcopy' and `bzero'.
635:
636:
637: File: internals, Node: Addressing Modes, Next: Misc, Prev: Library Names, Up: Machine Macros
638:
639: Addressing Modes
640: ================
641:
642: `HAVE_POST_INCREMENT'
643: Define this macro if the machine supports post-increment addressing.
644:
645: `HAVE_PRE_INCREMENT'
646: `HAVE_POST_DECREMENT'
647: `HAVE_PRE_DECREMENT'
648: Similar for other kinds of addressing.
649:
650: `CONSTANT_ADDRESS_P (X)'
651: A C expression that is 1 if the RTX X is a constant whose value is an
652: integer. This includes integers whose values are not explicitly
653: known, such as `symbol_ref' and `label_ref' expressions and `const'
654: arithmetic expressions.
655:
656: On most machines, this can be defined as `CONSTANT_P (X)', but a few
657: machines are more restrictive in which constant addresses are supported.
658:
659: `MAX_REGS_PER_ADDRESS'
660: A number, the maximum number of registers that can appear in a valid
661: memory address.
662:
663: `GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)'
664: A C compound statement with a conditional `goto LABEL;' executed if X
665: (an RTX) is a legitimate memory address on the target machine for a
666: memory operand of mode MODE.
667:
668: It usually pays to define several simpler macros to serve as
669: subroutines for this one. Otherwise it may be too complicated to
670: understand.
671:
672: This macro must exist in two variants: a strict variant and a
673: non-strict one. The strict variant is used in the reload pass. It
674: must be defined so that any pseudo-register that has not been
675: allocated a hard register is considered a memory reference. In
676: contexts where some kind of register is required, a pseudo-register
677: with no hard register must be rejected.
678:
679: The non-strict variant is used in other passes. It must be defined to
680: accept all pseudo-registers in every context where some kind of
681: register is required.
682:
683: Compiler source files that want to use the strict variant of this
684: macro define the macro `REG_OK_STRICT'. You should use an `#ifdef
685: REG_OK_STRICT' conditional to define the strict variant in that case
686: and the non-strict variant otherwise.
687:
688: Typically among the subroutines used to define
689: `GO_IF_LEGITIMATE_ADDRESS' are subroutines to check for acceptable
690: registers for various purposes (one for base registers, one for index
691: registers, and so on). Then only these subroutine macros need have
692: two variants; the higher levels of macros may be the same whether
693: strict or not.
694:
695: `LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)'
696: A C compound statement that attempts to replace X with a valid memory
697: address for an operand of mode MODE. WIN will be a C statement label
698: elsewhere in the code; the macro definition may use
699:
700: GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
701:
702: to avoid further processing if the address has become legitimate.
703:
704: X will always be the result of a call to `break_out_memory_refs', and
705: OLDX will be the operand that was given to that function to produce X.
706:
707: The code generated by this macro should not alter the substructure of
708: X. If it transforms X into a more legitimate form, it should assign X
709: (which will always be a C variable) a new value.
710:
711: It is not necessary for this macro to come up with a legitimate
712: address. The compiler has standard ways of doing so in all cases. In
713: fact, it is safe for this macro to do nothing. But often a
714: machine-dependent strategy can generate better code.
715:
716: `GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)'
717: A C statement or compound statement with a conditional `goto LABEL;'
718: executed if memory address X (an RTX) can have different meanings
719: depending on the machine mode of the memory reference it is used for.
720:
721: Autoincrement and autodecrement addresses typically have
722: mode-dependent effects because the amount of the increment or
723: decrement is the size of the operand being addressed. Some machines
724: have other mode-dependent addresses. Many RISC machines have no
725: mode-dependent addresses.
726:
727: You may assume that ADDR is a valid address for the machine.
728:
729: `LEGITIMATE_CONSTANT_P (X)'
730: A C expression that is nonzero if X is a legitimate constant for an
731: immediate operand on the target machine. You can assume that either X
732: is a `const_double' or it satisfies `CONSTANT_P', so you need not
733: check these things. In fact, `1' is a suitable definition for this
734: macro on machines where any `const_double' is valid and anything
735: `CONSTANT_P' is valid.
736:
737:
738: File: internals, Node: Misc, Next: Condition Code, Prev: Addressing Modes, Up: Machine Macros
739:
740: Miscellaneous Parameters
741: ========================
742:
743: `CASE_VECTOR_MODE'
744: An alias for a machine mode name. This is the machine mode that
745: elements of a jump-table should have.
746:
747: `CASE_VECTOR_PC_RELATIVE'
748: Define this macro if jump-tables should contain relative addresses.
749:
750: `CASE_DROPS_THROUGH'
751: Define this if control falls through a `case' insn when the index
752: value is out of range. This means the specified default-label is
753: actually ignored by the `case' insn proper.
754:
755: `IMPLICIT_FIX_EXPR'
756: An alias for a tree code that should be used by default for conversion
757: of floating point values to fixed point. Normally, `FIX_ROUND_EXPR'
758: is used.
759:
760: `FIXUNS_TRUNC_LIKE_FIX_TRUNC'
761: Define this macro if the same instructions that convert a floating
762: point number to a signed fixed point number also convert validly to an
763: unsigned one.
764:
765: `EASY_DIV_EXPR'
766: An alias for a tree code that is the easiest kind of division to
767: compile code for in the general case. It may be `TRUNC_DIV_EXPR',
768: `FLOOR_DIV_EXPR', `CEIL_DIV_EXPR' or `ROUND_DIV_EXPR'. These four
769: division operators differ in how they round the result to an integer.
770: `EASY_DIV_EXPR' is used when it is permissible to use any of those
771: kinds of division and the choice should be made on the basis of
772: efficiency.
773:
774: `DEFAULT_SIGNED_CHAR'
775: An expression whose value is 1 or 0, according to whether the type
776: `char' should be signed or unsigned by default. The user can always
777: override this default with the options `-fsigned-char' and
778: `-funsigned-char'.
779:
780: `SCCS_DIRECTIVE'
781: Define this if the preprocessor should ignore `#sccs' directives with
782: no error message.
783:
784: `MOVE_MAX'
785: The maximum number of bytes that a single instruction can move quickly
786: from memory to memory.
787:
788: `INT_TYPE_SIZE'
789: A C expression for the size in bits of the type `int' on the target
790: machine.
791:
792: `SLOW_BYTE_ACCESS'
793: Define this macro as a C expression which is nonzero if accessing less
794: than a word of memory (i.e. a `char' or a `short') is slow (requires
795: more than one instruction).
796:
797: `SLOW_ZERO_EXTEND'
798: Define this macro if zero-extension (of a `char' or `short' to an
799: `int') can be done faster if the destination is a register that is
800: known to be zero.
801:
802: If you define this macro, you must have instruction patterns that
803: recognize RTL structures like this:
804:
805: (set (strict-low-part (subreg:QI (reg:SI ...) 0)) ...)
806:
807: and likewise for `HImode'.
808:
809: `SHIFT_COUNT_TRUNCATED'
810: Define this macro if shift instructions ignore all but the lowest few
811: bits of the shift count. It implies that a sign-extend or zero-extend
812: instruction for the shift count can be omitted.
813:
814: `TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)'
815: A C expression which is nonzero if on this machine it is safe to
816: ``convert'' an integer of INPREC bits to one of OUTPREC bits (where
817: OUTPREC is smaller than INPREC) by merely operating on it as if it had
818: only OUTPREC bits.
819:
820: On many machines, this expression can be 1.
821:
822: `NO_FUNCTION_CSE'
823: Define this macro if it is as good or better to call a constant
824: function address than to call an address kept in a register.
825:
826: `STORE_FLAG_VALUE'
827: A C expression for the value stored by a store-flag instruction
828: (`sCOND') when the condition is true. This is usually 1 or -1; it is
829: required to be an odd number.
830:
831: Do not define `STORE_FLAG_VALUE' if the machine has no store-flag
832: instructions.
833:
834: `Pmode'
835: An alias for the machine mode for pointers. Normally the definition
836: can be
837:
838: #define Pmode SImode
839:
840: `FUNCTION_MODE'
841: An alias for the machine mode used for memory references to functions
842: being called, in `call' RTL expressions. On most machines this should
843: be `QImode'.
844:
845: `CONST_COST (X, CODE)'
846: A part of a C `switch' statement that describes the relative costs of
847: constant RTL expressions. It must contain `case' labels for
848: expression codes `const_int', `const', `symbol_ref', `label_ref' and
849: `const_double'. Each case must ultimately reach a `return' statement
850: to return the relative cost of the use of that kind of constant value
851: in an expression. The cost may depend on the precise value of the
852: constant, which is available for examination in X.
853:
854: CODE is the expression code---redundant, since it can be obtained with
855: `GET_CODE (X)'.
856:
857: `DOLLARS_IN_IDENTIFIERS'
858: Define this if the character `$' should be allowed in identifier names.
859:
860:
861: File: internals, Node: Condition Code, Next: Assembler Format, Prev: Misc, Up: Machine Macros
862:
863: Condition Code Information
864: ==========================
865:
866: The file `conditions.h' defines a variable `cc_status' to describe how the
867: condition code was computed (in case the interpretation of the condition
868: code depends on the instruction that it was set by). This variable
869: contains the RTL expressions on which the condition code is currently
870: based, and several standard flags.
871:
872: Sometimes additional machine-specific flags must be defined in the machine
873: description header file. It can also add additional machine-specific
874: information by defining `CC_STATUS_MDEP'.
875:
876: `CC_STATUS_MDEP'
877: C code for a data type which is used for declaring the `mdep'
878: component of `cc_status'. It defaults to `int'.
879:
880: `CC_STATUS_MDEP_INIT'
881: A C expression for the initial value of the `mdep' field. It defaults
882: to 0.
883:
884: `NOTICE_UPDATE_CC (EXP)'
885: A C compound statement to set the components of `cc_status'
886: appropriately for an insn whose body is EXP. It is this macro's
887: responsibility to recognize insns that set the condition code as a
888: byproduct of other activity as well as those that explicitly set
889: `(cc0)'.
890:
891: If there are insn that do not set the condition code but do alter
892: other machine registers, this macro must check to see whether they
893: invalidate the expressions that the condition code is recorded as
894: reflecting. For example, on the 68000, insns that store in address
895: registers do not set the condition code, which means that usually
896: `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns.
897: But suppose that the previous insn set the condition code based on
898: location `a4@(102)' and the current insn stores a new value in `a4'.
899: Although the condition code is not changed by this, it will no longer
900: be true that it reflects the contents of `a4@(102)'. Therefore,
901: `NOTICE_UPDATE_CC' must alter `cc_status' in this case to say that
902: nothing is known about the condition code value.
903:
904:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.