![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-9 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to gcc.info-9 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1: Info file gcc.info, produced by Makeinfo, -*- Text -*- from input
2: file gcc.texinfo.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
6: Copyright (C) 1988, 1989 Free Software Foundation, Inc.
7:
8: Permission is granted to make and distribute verbatim copies of this
9: manual provided the copyright notice and this permission notice are
10: preserved on all copies.
11:
12: Permission is granted to copy and distribute modified versions of
13: this manual under the conditions for verbatim copying, provided also
14: that the sections entitled ``GNU General Public License'' and
15: ``Protect Your Freedom--Fight `Look And Feel''' are included exactly
16: as in the original, and provided that the entire resulting derived
17: work is distributed under the terms of a permission notice identical
18: to this one.
19:
20: Permission is granted to copy and distribute translations of this
21: manual into another language, under the above conditions for modified
22: versions, except that the sections entitled ``GNU General Public
23: License'' and ``Protect Your Freedom--Fight `Look And Feel''' and
24: this permission notice may be included in translations approved by
25: the Free Software Foundation instead of in the original English.
26:
27:
28:
29: File: gcc.info, Node: Stack Layout, Next: Library Names, Prev: Register Classes, Up: Machine Macros
30:
31: Describing Stack Layout
32: =======================
33:
34: `STACK_GROWS_DOWNWARD'
35: Define this macro if pushing a word onto the stack moves the
36: stack pointer to a smaller address.
37:
38: When we say, ``define this macro if ...,'' it means that the
39: compiler checks this macro only with `#ifdef' so the precise
40: definition used does not matter.
41:
42: `FRAME_GROWS_DOWNWARD'
43: Define this macro if the addresses of local variable slots are
44: at negative offsets from the frame pointer.
45:
46: `STARTING_FRAME_OFFSET'
47: Offset from the frame pointer to the first local variable slot
48: to be allocated.
49:
50: If `FRAME_GROWS_DOWNWARD', the next slot's offset is found by
51: subtracting the length of the first slot from
52: `STARTING_FRAME_OFFSET'. Otherwise, it is found by adding the
53: length of the first slot to the value `STARTING_FRAME_OFFSET'.
54:
55: `PUSH_ROUNDING (NPUSHED)'
56: A C expression that is the number of bytes actually pushed onto
57: the stack when an instruction attempts to push NPUSHED bytes.
58:
59: If the target machine does not have a push instruction, do not
60: define this macro. That directs GNU CC to use an alternate
61: strategy: to allocate the entire argument block and then store
62: the arguments into it.
63:
64: On some machines, the definition
65:
66: #define PUSH_ROUNDING(BYTES) (BYTES)
67:
68: will suffice. But on other machines, instructions that appear
69: to push one byte actually push two bytes in an attempt to
70: maintain alignment. Then the definition should be
71:
72: #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
73:
74: `FIRST_PARM_OFFSET (FUNDECL)'
75: Offset from the argument pointer register to the first
76: argument's address. On some machines it may depend on the data
77: type of the function. (In the next version of GNU CC, the
78: argument will be changed to the function data type rather than
79: its declaration.)
80:
81: `FIRST_PARM_CALLER_OFFSET (FUNDECL)'
82: Define this macro on machines where register parameters have
83: shadow locations on the stack, at addresses below the nominal
84: parameter. This matters because certain arguments cannot be
85: passed on the stack. On these machines, such arguments must be
86: stored into the shadow locations.
87:
88: This macro should expand into a C expression whose value is the
89: offset of the first parameter's shadow location from the nominal
90: stack pointer value. (That value is itself computed by adding
91: the value of `STACK_POINTER_OFFSET' to the stack pointer
92: register.)
93:
94: `REG_PARM_STACK_SPACE'
95: Define this macro if functions should assume that stack space
96: has been allocated for arguments even when their values are
97: passed in registers.
98:
99: The actual allocation of such space would be done either by the
100: call instruction or by the function prologue, or by defining
101: FIRST_PARM_CALLER_OFFSET.
102:
103: `STACK_ARGS_ADJUST (SIZE)'
104: Define this macro if the machine requires padding on the stack
105: for certain function calls. This is padding on a
106: per-function-call basis, not padding for individual arguments.
107:
108: The argument SIZE will be a C variable of type `struct arg_data'
109: which contains two fields, an integer named `constant' and an
110: RTX named `var'. These together represent a size measured in
111: bytes which is the sum of the integer and the RTX. Most of the
112: time `var' is 0, which means that the size is simply the integer.
113:
114: The definition should be a C statement or compound statement
115: which alters the variable supplied in whatever way you wish.
116:
117: Note that the value you leave in the variable `size' will
118: ultimately be rounded up to a multiple of `STACK_BOUNDARY' bits.
119:
120: This macro is not fully implemented for machines which have push
121: instructions (i.e., on which `PUSH_ROUNDING' is defined).
122:
123: `RETURN_POPS_ARGS (FUNTYPE)'
124: A C expression that should be 1 if a function pops its own
125: arguments on returning, or 0 if the function pops no arguments
126: and the caller must therefore pop them all after the function
127: returns.
128:
129: FUNTYPE is a C variable whose value is a tree node that
130: describes the function in question. Normally it is a node of
131: type `FUNCTION_TYPE' that describes the data type of the function.
132: From this it is possible to obtain the data types of the value
133: and arguments (if known).
134:
135: When a call to a library function is being considered, FUNTYPE
136: will contain an identifier node for the library function. Thus,
137: if you need to distinguish among various library functions, you
138: can do so by their names. Note that ``library function'' in
139: this context means a function used to perform arithmetic, whose
140: name is known specially in the compiler and was not mentioned in
141: the C code being compiled.
142:
143: On the Vax, all functions always pop their arguments, so the
144: definition of this macro is 1. On the 68000, using the standard
145: calling convention, no functions pop their arguments, so the
146: value of the macro is always 0 in this case. But an alternative
147: calling convention is available in which functions that take a
148: fixed number of arguments pop them but other functions (such as
149: `printf') pop nothing (the caller pops all). When this
150: convention is in use, FUNTYPE is examined to determine whether a
151: function takes a fixed number of arguments.
152:
153: `FUNCTION_VALUE (VALTYPE, FUNC)'
154: A C expression to create an RTX representing the place where a
155: function returns a value of data type VALTYPE. VALTYPE is a
156: tree node representing a data type. Write `TYPE_MODE (VALTYPE)'
157: to get the machine mode used to represent that type. On many
158: machines, only the mode is relevant. (Actually, on most
159: machines, scalar values are returned in the same place
160: regardless of mode).
161:
162: If the precise function being called is known, FUNC is a tree
163: node (`FUNCTION_DECL') for it; otherwise, FUNC is a null
164: pointer. This makes it possible to use a different
165: value-returning convention for specific functions when all their
166: calls are known.
167:
168: `FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)'
169: Define this macro if the target machine has ``register windows''
170: so that the register in which a function returns its value is
171: not the same as the one in which the caller sees the value.
172:
173: For such machines, `FUNCTION_VALUE' computes the register in
174: which the caller will see the value, and
175: `FUNCTION_OUTGOING_VALUE' should be defined in a similar fashion
176: to tell the function where to put the value.
177:
178: If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE'
179: serves both purposes.
180:
181: `RETURN_IN_MEMORY (TYPE)'
182: A C expression which can inhibit the returning of certain
183: function values in registers, based on the type of value. A
184: nonzero value says to return the function value in memory, just
185: as large structures are always returned. Here TYPE will be a C
186: expression of type `tree', representing the data type of the
187: value.
188:
189: Note that values of mode `BLKmode' are returned in memory
190: regardless of this macro. Also, the option
191: `-fpcc-struct-return' takes effect regardless of this macro. On
192: most systems, it is possible to leave the macro undefined; this
193: causes a default definition to be used, whose value is the
194: constant 0.
195:
196: `LIBCALL_VALUE (MODE)'
197: A C expression to create an RTX representing the place where a
198: library function returns a value of mode MODE. If the precise
199: function being called is known, FUNC is a tree node
200: (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer.
201: This makes it possible to use a different value-returning
202: convention for specific functions when all their calls are known.
203:
204: Note that ``library function'' in this context means a compiler
205: support routine, used to perform arithmetic, whose name is known
206: specially by the compiler and was not mentioned in the C code
207: being compiled.
208:
209: `FUNCTION_VALUE_REGNO_P (REGNO)'
210: A C expression that is nonzero if REGNO is the number of a hard
211: register in which the values of called function may come back.
212:
213: A register whose use for returning values is limited to serving
214: as the second of a pair (for a value of type `double', say) need
215: not be recognized by this macro. So for most machines, this
216: definition suffices:
217:
218: #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
219:
220: If the machine has register windows, so that the caller and the
221: called function use different registers for the return value,
222: this macro should recognize only the caller's register numbers.
223:
224: `FUNCTION_ARG (CUM, MODE, TYPE, NAMED)'
225: A C expression that controls whether a function argument is
226: passed in a register, and which register.
227:
228: The arguments are CUM, which summarizes all the previous
229: arguments; MODE, the machine mode of the argument; TYPE, the
230: data type of the argument as a tree node or 0 if that is not
231: known (which happens for C support library functions); and
232: NAMED, which is 1 for an ordinary argument and 0 for nameless
233: arguments that correspond to `...' in the called function's
234: prototype.
235:
236: The value of the expression should either be a `reg' RTX for the
237: hard register in which to pass the argument, or zero to pass the
238: argument on the stack.
239:
240: For the Vax and 68000, where normally all arguments are pushed,
241: zero suffices as a definition.
242:
243: The usual way to make the ANSI library `stdarg.h' work on a
244: machine where some arguments are usually passed in registers, is
245: to cause nameless arguments to be passed on the stack instead.
246: This is done by making `FUNCTION_ARG' return 0 whenever NAMED is
247: 0.
248:
249: `FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)'
250: Define this macro if the target machine has ``register
251: windows'', so that the register in which a function sees an
252: arguments is not necessarily the same as the one in which the
253: caller passed the argument.
254:
255: For such machines, `FUNCTION_ARG' computes the register in which
256: the caller passes the value, and `FUNCTION_INCOMING_ARG' should
257: be defined in a similar fashion to tell the function being
258: called where the arguments will arrive.
259:
260: If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
261: both purposes.
262:
263: `FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)'
264: A C expression for the number of words, at the beginning of an
265: argument, must be put in registers. The value must be zero for
266: arguments that are passed entirely in registers or that are
267: entirely pushed on the stack.
268:
269: On some machines, certain arguments must be passed partially in
270: registers and partially in memory. On these machines, typically
271: the first N words of arguments are passed in registers, and the
272: rest on the stack. If a multi-word argument (a `double' or a
273: structure) crosses that boundary, its first few words must be
274: passed in registers and the rest must be pushed. This macro
275: tells the compiler when this occurs, and how many of the words
276: should go in registers.
277:
278: `FUNCTION_ARG' for these arguments should return the first
279: register to be used by the caller for this argument; likewise
280: `FUNCTION_INCOMING_ARG', for the called function.
281:
282: `CUMULATIVE_ARGS'
283: A C type for declaring a variable that is used as the first
284: argument of `FUNCTION_ARG' and other related values. For some
285: target machines, the type `int' suffices and can hold the number
286: of bytes of argument so far.
287:
288: `INIT_CUMULATIVE_ARGS (CUM, FNTYPE)'
289: A C statement (sans semicolon) for initializing the variable CUM
290: for the state at the beginning of the argument list. The
291: variable has type `CUMULATIVE_ARGS'. The value of FNTYPE is the
292: tree node for the data type of the function which will receive
293: the args, or 0 if the args are to a compiler support library
294: function.
295:
296: `FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)'
297: A C statement (sans semicolon) to update the summarizer variable
298: CUM to advance past an argument in the argument list. The
299: values MODE, TYPE and NAMED describe that argument. Once this
300: is done, the variable CUM is suitable for analyzing the
301: *following* argument with `FUNCTION_ARG', etc.
302:
303: `FUNCTION_ARG_REGNO_P (REGNO)'
304: A C expression that is nonzero if REGNO is the number of a hard
305: register in which function arguments are sometimes passed. This
306: does *not* include implicit arguments such as the static chain
307: and the structure-value address. On many machines, no registers
308: can be used for this purpose since all function arguments are
309: pushed on the stack.
310:
311: `FUNCTION_ARG_PADDING (MODE, SIZE)'
312: If defined, a C expression which determines whether, and in
313: which direction, to pad out an argument with extra space. The
314: value should be of type `enum direction': either `upward' to pad
315: above the argument, `downward' to pad below, or `none' to
316: inhibit padding.
317:
318: The argument SIZE is an RTX which describes the size of the
319: argument, in bytes. It should be used only if MODE is
320: `BLKmode'. Otherwise, SIZE is 0.
321:
322: This macro does not control the *amount* of padding; that is
323: always just enough to reach the next multiple of `PARM_BOUNDARY'.
324:
325: This macro has a default definition which is right for most
326: systems. For little-endian machines, the default is to pad
327: upward. For big-endian machines, the default is to pad downward
328: for an argument of constant size shorter than an `int', and
329: upward otherwise.
330:
331: `FUNCTION_PROLOGUE (FILE, SIZE)'
332: A C compound statement that outputs the assembler code for entry
333: to a function. The prologue is responsible for setting up the
334: stack frame, initializing the frame pointer register, saving
335: registers that must be saved, and allocating SIZE additional
336: bytes of storage for the local variables. SIZE is an integer.
337: FILE is a stdio stream to which the assembler code should be
338: output.
339:
340: The label for the beginning of the function need not be output
341: by this macro. That has already been done when the macro is run.
342:
343: To determine which registers to save, the macro can refer to the
344: array `regs_ever_live': element R is nonzero if hard register R
345: is used anywhere within the function. This implies the function
346: prologue should save register R, but not if it is one of the
347: call-used registers.
348:
349: On machines where functions may or may not have frame-pointers,
350: the function entry code must vary accordingly; it must set up
351: the frame pointer if one is wanted, and not otherwise. To
352: determine whether a frame pointer is in wanted, the macro can
353: refer to the variable `frame_pointer_needed'. The variable's
354: value will be 1 at run time in a function that needs a frame
355: pointer.
356:
357: On machines where arguments may be passed in registers, and not
358: have stack space allocated, this macro must examine the variable
359: `current_function_pretend_args_size', and allocate that many
360: bytes of uninitialized space on the stack just underneath the
361: first argument arriving on the stack. (This may not be at the
362: very end of the stack, if the calling sequence has pushed
363: anything else since pushing the stack arguments. But usually,
364: on such machines, nothing else has been pushed yet, because the
365: function prologue itself does all the pushing.)
366:
367: This ``pretend argument'' space is allocated in functions that
368: use the ANSI library `stdarg.h' to accept anonymous arguments of
369: unspecified types; the last named argument is copied into the
370: space, so that the anonymous arguments follow it consecutively.
371:
372: `FUNCTION_PROFILER (FILE, LABELNO)'
373: A C statement or compound statement to output to FILE some
374: assembler code to call the profiling subroutine `mcount'.
375: Before calling, the assembler code must load the address of a
376: counter variable into a register where `mcount' expects to find
377: the address. The name of this variable is `LP' followed by the
378: number LABELNO, so you would generate the name using `LP%d' in a
379: `fprintf'.
380:
381: The details of how the address should be passed to `mcount' are
382: determined by your operating system environment, not by GNU CC.
383: To figure them out, compile a small program for profiling using
384: the system's installed C compiler and look at the assembler code
385: that results.
386:
387: `FUNCTION_BLOCK_PROFILER (FILE, LABELNO)'
388: A C statement or compound statement to output to FILE some
389: assembler code to initialize basic-block profiling for the
390: current object module. This code should call the subroutine
391: `__bb_init_func' once per object module, passing it as its sole
392: argument the address of a block allocated in the object module.
393:
394: The name of the block is a local symbol made with this statement:
395:
396: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0);
397:
398: Of course, since you are writing the definition of
399: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you
400: can take a short cut in the definition of this macro and use the
401: name that you know will result.
402:
403: The first word of this block is a flag which will be nonzero if
404: the object module has already been initialized. So test this
405: word first, and do not call `__bb_init_func' if the flag is
406: nonzero.
407:
408: `BLOCK_PROFILER (FILE, BLOCKNO)'
409: A C statement or compound statement to increment the count
410: associated with the basic block number BLOCKNO. Basic blocks
411: are numbered separately from zero within each compilation. The
412: count associated with block number BLOCKNO is at index BLOCKNO
413: in a vector of words; the name of this array is a local symbol
414: made with this statement:
415:
416: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2);
417:
418: Of course, since you are writing the definition of
419: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you
420: can take a short cut in the definition of this macro and use the
421: name that you know will result.
422:
423: `EXIT_IGNORES_STACK'
424: Define this macro as a C expression that is nonzero if the
425: return instruction or the function epilogue ignores the value of
426: the stack pointer; in other words, if it is safe to delete an
427: instruction to adjust the stack pointer before a return from the
428: function.
429:
430: Note that this macro's value is relevant only for functions for
431: which frame pointers are maintained. It is never safe to delete
432: a final stack adjustment in a function that has no frame
433: pointer, and the compiler knows this regardless of
434: `EXIT_IGNORES_STACK'.
435:
436: `FUNCTION_EPILOGUE (FILE, SIZE)'
437: A C compound statement that outputs the assembler code for exit
438: from a function. The epilogue is responsible for restoring the
439: saved registers and stack pointer to their values when the
440: function was called, and returning control to the caller. This
441: macro takes the same arguments as the macro `FUNCTION_PROLOGUE',
442: and the registers to restore are determined from
443: `regs_ever_live' and `CALL_USED_REGISTERS' in the same way.
444:
445: On some machines, there is a single instruction that does all
446: the work of returning from the function. On these machines,
447: give that instruction the name `return' and do not define the
448: macro `FUNCTION_EPILOGUE' at all.
449:
450: Do not define a pattern named `return' if you want the
451: `FUNCTION_EPILOGUE' to be used. If you want the target switches
452: to control whether return instructions or epilogues are used,
453: define a `return' pattern with a validity condition that tests
454: the target switches appropriately. If the `return' pattern's
455: validity condition is false, epilogues will be used.
456:
457: On machines where functions may or may not have frame-pointers,
458: the function exit code must vary accordingly. Sometimes the
459: code for these two cases is completely different. To determine
460: whether a frame pointer is in wanted, the macro can refer to the
461: variable `frame_pointer_needed'. The variable's value will be 1
462: at run time in a function that needs a frame pointer.
463:
464: On some machines, some functions pop their arguments on exit
465: while others leave that for the caller to do. For example, the
466: 68020 when given `-mrtd' pops arguments in functions that take a
467: fixed number of arguments.
468:
469: Your definition of the macro `RETURN_POPS_ARGS' decides which
470: functions pop their own arguments. `FUNCTION_EPILOGUE' needs to
471: know what was decided. The variable
472: `current_function_pops_args' is nonzero if the function should
473: pop its own arguments. If so, use the variable
474: `current_function_args_size' as the number of bytes to pop.
475:
476: `FIX_FRAME_POINTER_ADDRESS (ADDR, DEPTH)'
477: A C compound statement to alter a memory address that uses the
478: frame pointer register so that it uses the stack pointer
479: register instead. This must be done in the instructions that
480: load parameter values into registers, when the reload pass
481: determines that a frame pointer is not necessary for the
482: function. ADDR will be a C variable name, and the updated
483: address should be stored in that variable. DEPTH will be the
484: current depth of stack temporaries (number of bytes of arguments
485: currently pushed). The change in offset between a
486: frame-pointer-relative address and a stack-pointer-relative
487: address must include DEPTH.
488:
489: Even if your machine description specifies there will always be
490: a frame pointer in the frame pointer register, you must still
491: define `FIX_FRAME_POINTER_ADDRESS', but the definition will
492: never be executed at run time, so it may be empty.
493:
494: `LONGJMP_RESTORE_FROM_STACK'
495: Define this macro if the `longjmp' function restores registers
496: from the stack frames, rather than from those saved specifically
497: by `setjmp'. Certain quantities must not be kept in registers
498: across a call to `setjmp' on such machines.
499:
500:
501:
502: File: gcc.info, Node: Library Names, Next: Addressing Modes, Prev: Stack Layout, Up: Machine Macros
503:
504: Library Subroutine Names
505: ========================
506:
507: `MULSI3_LIBCALL'
508: A C string constant giving the name of the function to call for
509: multiplication of one signed full-word by another. If you do
510: not define this macro, the default name is used, which is
511: `__mulsi3', a function defined in `gnulib'.
512:
513: `UMULSI3_LIBCALL'
514: A C string constant giving the name of the function to call for
515: multiplication of one unsigned full-word by another. If you do
516: not define this macro, the default name is used, which is
517: `__umulsi3', a function defined in `gnulib'.
518:
519: `DIVSI3_LIBCALL'
520: A C string constant giving the name of the function to call for
521: division of one signed full-word by another. If you do not
522: define this macro, the default name is used, which is
523: `__divsi3', a function defined in `gnulib'.
524:
525: `UDIVSI3_LIBCALL'
526: A C string constant giving the name of the function to call for
527: division of one unsigned full-word by another. If you do not
528: define this macro, the default name is used, which is
529: `__udivsi3', a function defined in `gnulib'.
530:
531: `MODSI3_LIBCALL'
532: A C string constant giving the name of the function to call for
533: the remainder in division of one signed full-word by another.
534: If you do not define this macro, the default name is used, which
535: is `__modsi3', a function defined in `gnulib'.
536:
537: `UMODSI3_LIBCALL'
538: A C string constant giving the name of the function to call for
539: the remainder in division of one unsigned full-word by another.
540: If you do not define this macro, the default name is used, which
541: is `__umodsi3', a function defined in `gnulib'.
542:
543: `TARGET_MEM_FUNCTIONS'
544: Define this macro if GNU CC should generate calls to the System
545: V (and ANSI C) library functions `memcpy' and `memset' rather
546: than the BSD functions `bcopy' and `bzero'.
547:
548:
549:
550: File: gcc.info, Node: Addressing Modes, Next: Delayed Branch, Prev: Library Names, Up: Machine Macros
551:
552: Addressing Modes
553: ================
554:
555: `HAVE_POST_INCREMENT'
556: Define this macro if the machine supports post-increment
557: addressing.
558:
559: `HAVE_PRE_INCREMENT'
560: `HAVE_POST_DECREMENT'
561: `HAVE_PRE_DECREMENT'
562: Similar for other kinds of addressing.
563:
564: `CONSTANT_ADDRESS_P (X)'
565: A C expression that is 1 if the RTX X is a constant whose value
566: is an integer. This includes integers whose values are not
567: explicitly known, such as `symbol_ref' and `label_ref'
568: expressions and `const' arithmetic expressions.
569:
570: On most machines, this can be defined as `CONSTANT_P (X)', but a
571: few machines are more restrictive in which constant addresses
572: are supported.
573:
574: `MAX_REGS_PER_ADDRESS'
575: A number, the maximum number of registers that can appear in a
576: valid memory address.
577:
578: `GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)'
579: A C compound statement with a conditional `goto LABEL;' executed
580: if X (an RTX) is a legitimate memory address on the target
581: machine for a memory operand of mode MODE.
582:
583: It usually pays to define several simpler macros to serve as
584: subroutines for this one. Otherwise it may be too complicated
585: to understand.
586:
587: This macro must exist in two variants: a strict variant and a
588: non-strict one. The strict variant is used in the reload pass.
589: It must be defined so that any pseudo-register that has not been
590: allocated a hard register is considered a memory reference. In
591: contexts where some kind of register is required, a
592: pseudo-register with no hard register must be rejected.
593:
594: The non-strict variant is used in other passes. It must be
595: defined to accept all pseudo-registers in every context where
596: some kind of register is required.
597:
598: Compiler source files that want to use the strict variant of
599: this macro define the macro `REG_OK_STRICT'. You should use an
600: `#ifdef REG_OK_STRICT' conditional to define the strict variant
601: in that case and the non-strict variant otherwise.
602:
603: Typically among the subroutines used to define
604: `GO_IF_LEGITIMATE_ADDRESS' are subroutines to check for
605: acceptable registers for various purposes (one for base
606: registers, one for index registers, and so on). Then only these
607: subroutine macros need have two variants; the higher levels of
608: macros may be the same whether strict or not.
609:
610: Normally, constant addresses which are the sum of a `symbol_ref'
611: and an integer are stored inside a `const' RTX to mark them as
612: constant. Therefore, there is no need to recognize such sums as
613: legitimate addresses.
614:
615: Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle
616: constant sums that are not marked with `const'. It assumes
617: that a naked `plus' indicates indexing. If so, then you *must*
618: reject such naked constant sums as illegitimate addresses, so
619: that none of them will be given to `PRINT_OPERAND_ADDRESS'.
620:
621: `REG_OK_FOR_BASE_P (X)'
622: A C expression that is nonzero if X (assumed to be a `reg' RTX)
623: is valid for use as a base register. For hard registers, it
624: should always accept those which the hardware permits and reject
625: the others. Whether the macro accepts or rejects pseudo
626: registers must be controlled by `REG_OK_STRICT' as described
627: above. This usually requires two variant definitions, of which
628: `REG_OK_STRICT' controls the one actually used.
629:
630: `REG_OK_FOR_INDEX_P (X)'
631: A C expression that is nonzero if X (assumed to be a `reg' RTX)
632: is valid for use as an index register.
633:
634: The difference between an index register and a base register is
635: that the index register may be scaled. If an address involves
636: the sum of two registers, neither one of them scaled, then
637: either one may be labeled the ``base'' and the other the
638: ``index''; but whichever labeling is used must fit the machine's
639: constraints of which registers may serve in each capacity. The
640: compiler will try both labelings, looking for one that is valid,
641: and will reload one or both registers only if neither labeling
642: works.
643:
644: `LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)'
645: A C compound statement that attempts to replace X with a valid
646: memory address for an operand of mode MODE. WIN will be a C
647: statement label elsewhere in the code; the macro definition may
648: use
649:
650: GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
651:
652: to avoid further processing if the address has become legitimate.
653:
654: X will always be the result of a call to
655: `break_out_memory_refs', and OLDX will be the operand that was
656: given to that function to produce X.
657:
658: The code generated by this macro should not alter the
659: substructure of X. If it transforms X into a more legitimate
660: form, it should assign X (which will always be a C variable) a
661: new value.
662:
663: It is not necessary for this macro to come up with a legitimate
664: address. The compiler has standard ways of doing so in all
665: cases. In fact, it is safe for this macro to do nothing. But
666: often a machine-dependent strategy can generate better code.
667:
668: `GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)'
669: A C statement or compound statement with a conditional `goto
670: LABEL;' executed if memory address X (an RTX) can have different
671: meanings depending on the machine mode of the memory reference
672: it is used for.
673:
674: Autoincrement and autodecrement addresses typically have
675: mode-dependent effects because the amount of the increment or
676: decrement is the size of the operand being addressed. Some
677: machines have other mode-dependent addresses. Many RISC
678: machines have no mode-dependent addresses.
679:
680: You may assume that ADDR is a valid address for the machine.
681:
682: `LEGITIMATE_CONSTANT_P (X)'
683: A C expression that is nonzero if X is a legitimate constant for
684: an immediate operand on the target machine. You can assume that
685: either X is a `const_double' or it satisfies `CONSTANT_P', so
686: you need not check these things. In fact, `1' is a suitable
687: definition for this macro on machines where any `const_double'
688: is valid and anything `CONSTANT_P' is valid.
689:
690:
691:
692: File: gcc.info, Node: Delayed Branch, Next: Condition Code, Prev: Addressing Modes, Up: Machine Macros
693:
694: Parameters for Delayed Branch Optimization
695: ==========================================
696:
697: `HAVE_DELAYED_BRANCH'
698: Define this macro if the target machine has delayed branches,
699: that is, a branch does not take effect immediately, and the
700: actual branch instruction may be followed by one or more
701: instructions that will be issued before the PC is actually
702: changed.
703:
704: If defined, this allows a special scheduling pass to be run
705: after the second jump optimization to attempt to reorder
706: instructions to exploit this. Defining this macro also requires
707: the definition of certain other macros described below.
708:
709: `DBR_SLOTS_AFTER (INSN)'
710: This macro must be defined if `HAVE_DELAYED_BRANCH' is defined.
711: Its definition should be a C expression returning the number of
712: available delay slots following the instruction(s) output by the
713: pattern for INSN. The definition of ``slot'' is
714: machine-dependent, and may denote instructions, bytes, or
715: whatever.
716:
717: `DBR_INSN_SLOTS (INSN)'
718: This macro must be defined if `HAVE_DELAYED_BRANCH' is defined.
719: It should be a C expression returning the number of slots
720: (typically the number of machine instructions) consumed by INSN.
721:
722: You may assume that INSN is truly an insn, not a note, label,
723: barrier, dispatch table, `use', or `clobber'.
724:
725: `DBR_INSN_ELIGIBLE_P (INSN, DINSN)'
726: A C expression whose value is non-zero if it is legitimate to
727: put INSN in the delay slot following DINSN.
728:
729: You do not need to take account of data flow considerations in
730: the definition of this macro, because the delayed branch
731: optimizer always does that. This macro is needed only when
732: certain insns may not be placed in certain delay slots for
733: reasons not evident from the RTL expressions themselves. If
734: there are no such problems, you don't need to define this macro.
735:
736: You may assume that INSN is truly an insn, not a note, label,
737: barrier, dispatch table, `use', or `clobber'. You may assume
738: that DINSN is a jump insn with a delay slot.
739:
740: `DBR_OUTPUT_SEQEND(FILE)'
741: A C statement, to be executed after all slot-filler instructions
742: have been output. If necessary, call `dbr_sequence_length' to
743: determine the number of slots filled in a sequence (zero if not
744: currently outputting a sequence), to decide how many no-ops to
745: output, or whatever.
746:
747: Don't define this macro if it has nothing to do, but it is
748: helpful in reading assembly output if the extent of the delay
749: sequence is made explicit (e.g. with white space).
750:
751: Note that output routines for instructions with delay slots must
752: be prepared to deal with not being output as part of a sequence
753: (i.e. when the scheduling pass is not run, or when no slot
754: fillers could be found.) The variable `final_sequence' is null
755: when not processing a sequence, otherwise it contains the
756: `sequence' rtx being output.
757:
758:
759:
760: File: gcc.info, Node: Condition Code, Next: Cross-compilation, Prev: Delayed Branch, Up: Machine Macros
761:
762: Condition Code Information
763: ==========================
764:
765: The file `conditions.h' defines a variable `cc_status' to describe
766: how the condition code was computed (in case the interpretation of
767: the condition code depends on the instruction that it was set by).
768: This variable contains the RTL expressions on which the condition
769: code is currently based, and several standard flags.
770:
771: Sometimes additional machine-specific flags must be defined in the
772: machine description header file. It can also add additional
773: machine-specific information by defining `CC_STATUS_MDEP'.
774:
775: `CC_STATUS_MDEP'
776: C code for a data type which is used for declaring the `mdep'
777: component of `cc_status'. It defaults to `int'.
778:
779: `CC_STATUS_MDEP_INIT'
780: A C expression to initialize the `mdep' field to ``empty''. The
781: default definition does nothing, since most machines don't use
782: the field anyway. If you want to use the field, you should
783: probably define this macro to initialize it.
784:
785: `NOTICE_UPDATE_CC (EXP, INSN)'
786: A C compound statement to set the components of `cc_status'
787: appropriately for an insn INSN whose body is EXP. It is this
788: macro's responsibility to recognize insns that set the condition
789: code as a byproduct of other activity as well as those that
790: explicitly set `(cc0)'.
791:
792: If there are insn that do not set the condition code but do
793: alter other machine registers, this macro must check to see
794: whether they invalidate the expressions that the condition code
795: is recorded as reflecting. For example, on the 68000, insns
796: that store in address registers do not set the condition code,
797: which means that usually `NOTICE_UPDATE_CC' can leave
798: `cc_status' unaltered for such insns. But suppose that the
799: previous insn set the condition code based on location
800: `a4@(102)' and the current insn stores a new value in `a4'.
801: Although the condition code is not changed by this, it will no
802: longer be true that it reflects the contents of `a4@(102)'.
803: Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this
804: case to say that nothing is known about the condition code value.
805:
806: The definition of `NOTICE_UPDATE_CC' must be prepared to deal
807: with the results of peephole optimization: insns whose patterns
808: are `parallel' RTXs containing various `reg', `mem' or constants
809: which are just the operands. The RTL structure of these insns
810: is not sufficient to indicate what the insns actually do. What
811: `NOTICE_UPDATE_CC' should do when it sees one is just to run
812: `CC_STATUS_INIT'.
813:
814:
815:
816: File: gcc.info, Node: Cross-compilation, Next: Misc, Prev: Condition Code, Up: Machine Macros
817:
818: Cross Compilation and Floating-Point Format
819: ===========================================
820:
821: While all modern machines use 2's complement representation for
822: integers, there are a variety of representations for floating point
823: numbers. This means that in a cross-compiler the representation of
824: floating point numbers in the compiled program may be different from
825: that used in the machine doing the compilation.
826:
827: Because different representation systems may offer different amounts
828: of range and precision, the cross compiler cannot safely use the host
829: machine's floating point arithmetic. Therefore, floating point
830: constants must be represented in the target machine's format. This
831: means that the cross compiler cannot use `atof' to parse a floating
832: point constant; it must have its own special routine to use instead.
833: Also, constant folding must emulate the target machine's arithmetic
834: (or must not be done at all).
835:
836: The macros in the following table should be defined only if you are
837: cross compiling between different floating point formats.
838:
839: Otherwise, don't define them. Then default definitions will be set up
840: which use `double' as the data type, `==' to test for equality, etc.
841:
842: You don't need to worry about how many times you use an operand of
843: any of these macros. The compiler never uses operands which have
844: side effects.
845:
846: `REAL_VALUE_TYPE'
847: A macro for the C data type to be used to hold a floating point
848: value in the target machine's format. Typically this would be a
849: `struct' containing an array of `int'.
850:
851: `REAL_VALUES_EQUAL (X, Y)'
852: A macro for a C expression which compares for equality the two
853: values, X and Y, both of type `REAL_VALUE_TYPE'.
854:
855: `REAL_VALUES_LESS (X, Y)'
856: A macro for a C expression which tests whether X is less than Y,
857: both values being of type `REAL_VALUE_TYPE' and interpreted as
858: floating point numbers in the target machine's representation.
859:
860: `REAL_VALUE_LDEXP (X, SCALE)'
861: A macro for a C expression which performs the standard library
862: function `ldexp', but using the target machine's floating point
863: representation. Both X and the value of the expression have
864: type `REAL_VALUE_TYPE'. The second argument, SCALE, is an
865: integer.
866:
867: `REAL_VALUE_ATOF (STRING)'
868: A macro for a C expression which converts STRING, an expression
869: of type `char *', into a floating point number in the target
870: machine's representation. The value has type `REAL_VALUE_TYPE'.
871:
872: Define the following additional macros if you want to make floating
873: point constant folding work while cross compiling. If you don't
874: define them, cross compilation is still possible, but constant
875: folding will not happen for floating point values.
876:
877: `REAL_ARITHMETIC (OUTPUT, CODE, X, Y)'
878: A macro for a C statement which calculates an arithmetic
879: operation of the two floating point values X and Y, both of type
880: `REAL_VALUE_TYPE' in the target machine's representation, to
881: produce a result of the same type and representation which is
882: stored in OUTPUT (which will be a variable).
883:
884: The operation to be performed is specified by CODE, a tree code
885: which will always be one of the following: `PLUS_EXPR',
886: `MINUS_EXPR', `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'.
887:
888: The expansion of this macro is responsible for checking for
889: overflow. If overflow happens, the macro expansion should
890: execute the statement `return 0;', which indicates the inability
891: to perform the arithmetic operation requested.
892:
893: `REAL_VALUE_NEGATE (X)'
894: A macro for a C expression which returns the negative of the
895: floating point value X. Both X and the value of the expression
896: have type `REAL_VALUE_TYPE' and are in the target machine's
897: floating point representation.
898:
899: There is no way for this macro to report overflow, since
900: overflow can't happen in the negation operation.
901:
902: `REAL_VALUE_TO_INT (LOW, HIGH, X)'
903: A macro for a C expression which converts a floating point value
904: X into a double-precision integer which is then stored into LOW
905: and HIGH, two variables of type INT.
906:
907: `REAL_VALUE_FROM_INT (X, LOW, HIGH)'
908: A macro for a C expression which converts a double-precision
909: integer found in LOW and HIGH, two variables of type INT, into a
910: floating point value which is then stored into X.
911:
912:
913:
914: File: gcc.info, Node: Misc, Next: Assembler Format, Prev: Cross-compilation, Up: Machine Macros
915:
916: Miscellaneous Parameters
917: ========================
918:
919: `CASE_VECTOR_MODE'
920: An alias for a machine mode name. This is the machine mode that
921: elements of a jump-table should have.
922:
923: `CASE_VECTOR_PC_RELATIVE'
924: Define this macro if jump-tables should contain relative
925: addresses.
926:
927: `CASE_DROPS_THROUGH'
928: Define this if control falls through a `case' insn when the
929: index value is out of range. This means the specified
930: default-label is actually ignored by the `case' insn proper.
931:
932: `IMPLICIT_FIX_EXPR'
933: An alias for a tree code that should be used by default for
934: conversion of floating point values to fixed point. Normally,
935: `FIX_ROUND_EXPR' is used.
936:
937: `FIXUNS_TRUNC_LIKE_FIX_TRUNC'
938: Define this macro if the same instructions that convert a
939: floating point number to a signed fixed point number also
940: convert validly to an unsigned one.
941:
942: `EASY_DIV_EXPR'
943: An alias for a tree code that is the easiest kind of division to
944: compile code for in the general case. It may be
945: `TRUNC_DIV_EXPR', `FLOOR_DIV_EXPR', `CEIL_DIV_EXPR' or
946: `ROUND_DIV_EXPR'. These four division operators differ in how
947: they round the result to an integer. `EASY_DIV_EXPR' is used
948: when it is permissible to use any of those kinds of division and
949: the choice should be made on the basis of efficiency.
950:
951: `DEFAULT_SIGNED_CHAR'
952: An expression whose value is 1 or 0, according to whether the
953: type `char' should be signed or unsigned by default. The user
954: can always override this default with the options
955: `-fsigned-char' and `-funsigned-char'.
956:
957: `SCCS_DIRECTIVE'
958: Define this if the preprocessor should ignore `#sccs' directives
959: and print no error message.
960:
961: `HAVE_VPRINTF'
962: Define this if the library function `vprintf' is available on
963: your system.
964:
965: `MOVE_MAX'
966: The maximum number of bytes that a single instruction can move
967: quickly from memory to memory.
968:
969: `INT_TYPE_SIZE'
970: A C expression for the size in bits of the type `int' on the
971: target machine. If you don't define this, the default is one
972: word.
973:
974: `SHORT_TYPE_SIZE'
975: A C expression for the size in bits of the type `short' on the
976: target machine. If you don't define this, the default is half a
977: word. (If this would be less than one storage unit, it is
978: rounded up to one unit.)
979:
980: `LONG_TYPE_SIZE'
981: A C expression for the size in bits of the type `long' on the
982: target machine. If you don't define this, the default is one
983: word.
984:
985: `LONG_LONG_TYPE_SIZE'
986: A C expression for the size in bits of the type `long long' on
987: the target machine. If you don't define this, the default is
988: two words.
989:
990: `CHAR_TYPE_SIZE'
991: A C expression for the size in bits of the type `char' on the
992: target machine. If you don't define this, the default is one
993: quarter of a word. (If this would be less than one storage
994: unit, it is rounded up to one unit.)
995:
996: `FLOAT_TYPE_SIZE'
997: A C expression for the size in bits of the type `float' on the
998: target machine. If you don't define this, the default is one
999: word.
1000:
1001: `DOUBLE_TYPE_SIZE'
1002: A C expression for the size in bits of the type `double' on the
1003: target machine. If you don't define this, the default is two
1004: words.
1005:
1006: `LONG_DOUBLE_TYPE_SIZE'
1007: A C expression for the size in bits of the type `long double' on
1008: the target machine. If you don't define this, the default is
1009: two words.
1010:
1011: `SLOW_BYTE_ACCESS'
1012: Define this macro as a C expression which is nonzero if
1013: accessing less than a word of memory (i.e. a `char' or a
1014: `short') is slow (requires more than one instruction).
1015:
1016: `SLOW_ZERO_EXTEND'
1017: Define this macro if zero-extension (of a `char' or `short' to
1018: an `int') can be done faster if the destination is a register
1019: that is known to be zero.
1020:
1021: If you define this macro, you must have instruction patterns
1022: that recognize RTL structures like this:
1023:
1024: (set (strict-low-part (subreg:QI (reg:SI ...) 0)) ...)
1025:
1026: and likewise for `HImode'.
1027:
1028: `SHIFT_COUNT_TRUNCATED'
1029: Define this macro if shift instructions ignore all but the
1030: lowest few bits of the shift count. It implies that a
1031: sign-extend or zero-extend instruction for the shift count can
1032: be omitted.
1033:
1034: `TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)'
1035: A C expression which is nonzero if on this machine it is safe to
1036: ``convert'' an integer of INPREC bits to one of OUTPREC bits
1037: (where OUTPREC is smaller than INPREC) by merely operating on it
1038: as if it had only OUTPREC bits.
1039:
1040: On many machines, this expression can be 1.
1041:
1042: `NO_FUNCTION_CSE'
1043: Define this macro if it is as good or better to call a constant
1044: function address than to call an address kept in a register.
1045:
1046: `PROMOTE_PROTOTYPES'
1047: Define this macro if an argument declared as `char' or `short'
1048: in a prototype should actually be passed as an `int'. In
1049: addition to avoiding errors in certain cases of mismatch, it
1050: also makes for better code on certain machines.
1051:
1052: `STORE_FLAG_VALUE'
1053: A C expression for the value stored by a store-flag instruction
1054: (`sCOND') when the condition is true. This is usually 1 or -1;
1055: it is required to be an odd number or a negative number.
1056:
1057: Do not define `STORE_FLAG_VALUE' if the machine has no
1058: store-flag instructions.
1059:
1060: `Pmode'
1061: An alias for the machine mode for pointers. Normally the
1062: definition can be
1063:
1064: #define Pmode SImode
1065:
1066: `FUNCTION_MODE'
1067: An alias for the machine mode used for memory references to
1068: functions being called, in `call' RTL expressions. On most
1069: machines this should be `QImode'.
1070:
1071: `INSN_MACHINE_INFO'
1072: This macro should expand into a C structure type to use for the
1073: machine-dependent info field specified with the optional last
1074: argument in `define_insn' and `define_peephole' patterns. For
1075: example, it might expand into `struct machine_info'; then it
1076: would be up to you to define this structure in the `tm.h' file.
1077:
1078: You do not need to define this macro if you do not write the
1079: optional last argument in any of the patterns in the machine
1080: description.
1081:
1082: `DEFAULT_MACHINE_INFO'
1083: This macro should expand into a C initializer to use to
1084: initialize the machine-dependent info for one insn pattern. It
1085: is used for patterns that do not specify the machine-dependent
1086: info.
1087:
1088: If you do not define this macro, zero is used.
1089:
1090: `CONST_COSTS (X, CODE)'
1091: A part of a C `switch' statement that describes the relative
1092: costs of constant RTL expressions. It must contain `case'
1093: labels for expression codes `const_int', `const', `symbol_ref',
1094: `label_ref' and `const_double'. Each case must ultimately reach
1095: a `return' statement to return the relative cost of the use of
1096: that kind of constant value in an expression. The cost may
1097: depend on the precise value of the constant, which is available
1098: for examination in X.
1099:
1100: CODE is the expression code--redundant, since it can be obtained
1101: with `GET_CODE (X)'.
1102:
1103: `DOLLARS_IN_IDENTIFIERS'
1104: Define this to be nonzero if the character `$' should be allowed
1105: by default in identifier names.
1106:
1107: `USE_C_ALLOCA'
1108: Define this macro to indicate that the compiler is running with
1109: the `alloca' implemented in C. This version of `alloca' can be
1110: found in the file `alloca.c'; to use it, you must also alter the
1111: `Makefile' variable `ALLOCA'.
1112:
1113: This macro, unlike most, describes the machine that the compiler
1114: is running on, rather than the one the compiler is compiling for.
1115: Therefore, it should be set in the `xm-MACHINE.h' file rather
1116: than in the `tm-MACHINE.h' file.
1117:
1118: If you do define this macro, you should probably do it as follows:
1119:
1120: #ifndef __GNUC__
1121: #define USE_C_ALLOCA
1122: #else
1123: #define alloca __builtin_alloca
1124: #endif
1125:
1126: so that when the compiler is compiled with GNU CC it uses the
1127: more efficient built-in `alloca' function.
1128:
1129:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.