1 This is doc/gccint.info, produced by makeinfo version 4.8 from
2 /scratch/mitchell/gcc-releases/gcc-4.1.2/gcc-4.1.2/gcc/doc/gccint.texi.
4 Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
5 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
7 Permission is granted to copy, distribute and/or modify this document
8 under the terms of the GNU Free Documentation License, Version 1.2 or
9 any later version published by the Free Software Foundation; with the
10 Invariant Sections being "GNU General Public License" and "Funding Free
11 Software", the Front-Cover texts being (a) (see below), and with the
12 Back-Cover Texts being (b) (see below). A copy of the license is
13 included in the section entitled "GNU Free Documentation License".
15 (a) The FSF's Front-Cover Text is:
19 (b) The FSF's Back-Cover Text is:
21 You have freedom to copy and modify this GNU Manual, like GNU
22 software. Copies published by the Free Software Foundation raise
23 funds for GNU development.
25 INFO-DIR-SECTION Programming
27 * gccint: (gccint). Internals of the GNU Compiler Collection.
29 This file documents the internals of the GNU compilers.
31 Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
32 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
34 Permission is granted to copy, distribute and/or modify this document
35 under the terms of the GNU Free Documentation License, Version 1.2 or
36 any later version published by the Free Software Foundation; with the
37 Invariant Sections being "GNU General Public License" and "Funding Free
38 Software", the Front-Cover texts being (a) (see below), and with the
39 Back-Cover Texts being (b) (see below). A copy of the license is
40 included in the section entitled "GNU Free Documentation License".
42 (a) The FSF's Front-Cover Text is:
46 (b) The FSF's Back-Cover Text is:
48 You have freedom to copy and modify this GNU Manual, like GNU
49 software. Copies published by the Free Software Foundation raise
50 funds for GNU development.
54 File: gccint.info, Node: Top, Next: Contributing, Up: (DIR)
59 This manual documents the internals of the GNU compilers, including how
60 to port them to new targets and some information about how to write
61 front ends for new languages. It corresponds to GCC version 4.1.2.
62 The use of the GNU compilers is documented in a separate manual. *Note
63 Introduction: (gcc)Top.
65 This manual is mainly a reference manual rather than a tutorial. It
66 discusses how to contribute to GCC (*note Contributing::), the
67 characteristics of the machines supported by GCC as hosts and targets
68 (*note Portability::), how GCC relates to the ABIs on such systems
69 (*note Interface::), and the characteristics of the languages for which
70 GCC front ends are written (*note Languages::). It then describes the
71 GCC source tree structure and build system, some of the interfaces to
72 GCC front ends, and how support for a target system is implemented in
75 Additional tutorial information is linked to from
76 `http://gcc.gnu.org/readings.html'.
80 * Contributing:: How to contribute to testing and developing GCC.
81 * Portability:: Goals of GCC's portability features.
82 * Interface:: Function-call interface of GCC output.
83 * Libgcc:: Low-level runtime library used by GCC.
84 * Languages:: Languages for which GCC front ends are written.
85 * Source Tree:: GCC source tree structure and build system.
86 * Options:: Option specification files.
87 * Passes:: Order of passes, what they do, and what each file is for.
88 * Trees:: The source representation used by the C and C++ front ends.
89 * RTL:: The intermediate representation that most passes work on.
90 * Control Flow:: Maintaining and manipulating the control flow graph.
91 * Tree SSA:: Analysis and optimization of the tree representation.
92 * Machine Desc:: How to write machine description instruction patterns.
93 * Target Macros:: How to write the machine description C macros and functions.
94 * Host Config:: Writing the `xm-MACHINE.h' file.
95 * Fragments:: Writing the `t-TARGET' and `x-HOST' files.
96 * Collect2:: How `collect2' works; how it finds `ld'.
97 * Header Dirs:: Understanding the standard header file directories.
98 * Type Information:: GCC's memory management; generating type information.
100 * Funding:: How to help assure funding for free software.
101 * GNU Project:: The GNU Project and GNU/Linux.
103 * Copying:: GNU General Public License says
104 how you can copy and share GCC.
105 * GNU Free Documentation License:: How you can copy and share this manual.
106 * Contributors:: People who have contributed to GCC.
108 * Option Index:: Index to command line options.
109 * Concept Index:: Index of concepts and symbol names.
112 File: gccint.info, Node: Contributing, Next: Portability, Prev: Top, Up: Top
114 1 Contributing to GCC Development
115 *********************************
117 If you would like to help pretest GCC releases to assure they work well,
118 current development sources are available by CVS (see
119 `http://gcc.gnu.org/cvs.html'). Source and binary snapshots are also
120 available for FTP; see `http://gcc.gnu.org/snapshots.html'.
122 If you would like to work on improvements to GCC, please read the
123 advice at these URLs:
125 `http://gcc.gnu.org/contribute.html'
126 `http://gcc.gnu.org/contributewhy.html'
128 for information on how to make useful contributions and avoid
129 duplication of effort. Suggested projects are listed at
130 `http://gcc.gnu.org/projects/'.
133 File: gccint.info, Node: Portability, Next: Interface, Prev: Contributing, Up: Top
135 2 GCC and Portability
136 *********************
138 GCC itself aims to be portable to any machine where `int' is at least a
139 32-bit type. It aims to target machines with a flat (non-segmented)
140 byte addressed data address space (the code address space can be
141 separate). Target ABIs may have 8, 16, 32 or 64-bit `int' type. `char'
142 can be wider than 8 bits.
144 GCC gets most of the information about the target machine from a
145 machine description which gives an algebraic formula for each of the
146 machine's instructions. This is a very clean way to describe the
147 target. But when the compiler needs information that is difficult to
148 express in this fashion, ad-hoc parameters have been defined for
149 machine descriptions. The purpose of portability is to reduce the
150 total work needed on the compiler; it was not of interest for its own
153 GCC does not contain machine dependent code, but it does contain code
154 that depends on machine parameters such as endianness (whether the most
155 significant byte has the highest or lowest address of the bytes in a
156 word) and the availability of autoincrement addressing. In the
157 RTL-generation pass, it is often necessary to have multiple strategies
158 for generating code for a particular kind of syntax tree, strategies
159 that are usable for different combinations of parameters. Often, not
160 all possible cases have been addressed, but only the common ones or
161 only the ones that have been encountered. As a result, a new target
162 may require additional strategies. You will know if this happens
163 because the compiler will call `abort'. Fortunately, the new
164 strategies can be added in a machine-independent fashion, and will
165 affect only the target machines that need them.
168 File: gccint.info, Node: Interface, Next: Libgcc, Prev: Portability, Up: Top
170 3 Interfacing to GCC Output
171 ***************************
173 GCC is normally configured to use the same function calling convention
174 normally in use on the target system. This is done with the
175 machine-description macros described (*note Target Macros::).
177 However, returning of structure and union values is done differently on
178 some target machines. As a result, functions compiled with PCC
179 returning such types cannot be called from code compiled with GCC, and
180 vice versa. This does not cause trouble often because few Unix library
181 routines return structures or unions.
183 GCC code returns structures and unions that are 1, 2, 4 or 8 bytes
184 long in the same registers used for `int' or `double' return values.
185 (GCC typically allocates variables of such types in registers also.)
186 Structures and unions of other sizes are returned by storing them into
187 an address passed by the caller (usually in a register). The target
188 hook `TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address.
190 By contrast, PCC on most target machines returns structures and unions
191 of any size by copying the data into an area of static storage, and then
192 returning the address of that storage as if it were a pointer value.
193 The caller must copy the data from that memory area to the place where
194 the value is wanted. This is slower than the method used by GCC, and
195 fails to be reentrant.
197 On some target machines, such as RISC machines and the 80386, the
198 standard system convention is to pass to the subroutine the address of
199 where to return the value. On these machines, GCC has been configured
200 to be compatible with the standard compiler, when this method is used.
201 It may not be compatible for structures of 1, 2, 4 or 8 bytes.
203 GCC uses the system's standard convention for passing arguments. On
204 some machines, the first few arguments are passed in registers; in
205 others, all are passed on the stack. It would be possible to use
206 registers for argument passing on any machine, and this would probably
207 result in a significant speedup. But the result would be complete
208 incompatibility with code that follows the standard convention. So this
209 change is practical only if you are switching to GCC as the sole C
210 compiler for the system. We may implement register argument passing on
211 certain machines once we have a complete GNU system so that we can
212 compile the libraries with GCC.
214 On some machines (particularly the SPARC), certain types of arguments
215 are passed "by invisible reference". This means that the value is
216 stored in memory, and the address of the memory location is passed to
219 If you use `longjmp', beware of automatic variables. ISO C says that
220 automatic variables that are not declared `volatile' have undefined
221 values after a `longjmp'. And this is all GCC promises to do, because
222 it is very difficult to restore register variables correctly, and one
223 of GCC's features is that it can put variables in registers without
227 File: gccint.info, Node: Libgcc, Next: Languages, Prev: Interface, Up: Top
229 4 The GCC low-level runtime library
230 ***********************************
232 GCC provides a low-level runtime library, `libgcc.a' or `libgcc_s.so.1'
233 on some platforms. GCC generates calls to routines in this library
234 automatically, whenever it needs to perform some operation that is too
235 complicated to emit inline code for.
237 Most of the routines in `libgcc' handle arithmetic operations that the
238 target processor cannot perform directly. This includes integer
239 multiply and divide on some machines, and all floating-point operations
240 on other machines. `libgcc' also includes routines for exception
241 handling, and a handful of miscellaneous operations.
243 Some of these routines can be defined in mostly machine-independent C.
244 Others must be hand-written in assembly language for each processor
247 GCC will also generate calls to C library routines, such as `memcpy'
248 and `memset', in some cases. The set of routines that GCC may possibly
249 use is documented in *Note Other Builtins: (gcc)Other Builtins.
251 These routines take arguments and return values of a specific machine
252 mode, not a specific C type. *Note Machine Modes::, for an explanation
253 of this concept. For illustrative purposes, in this chapter the
254 floating point type `float' is assumed to correspond to `SFmode';
255 `double' to `DFmode'; and `long double' to both `TFmode' and `XFmode'.
256 Similarly, the integer types `int' and `unsigned int' correspond to
257 `SImode'; `long' and `unsigned long' to `DImode'; and `long long' and
258 `unsigned long long' to `TImode'.
262 * Integer library routines::
263 * Soft float library routines::
264 * Exception handling routines::
265 * Miscellaneous routines::
268 File: gccint.info, Node: Integer library routines, Next: Soft float library routines, Up: Libgcc
270 4.1 Routines for integer arithmetic
271 ===================================
273 The integer arithmetic routines are used on platforms that don't provide
274 hardware support for arithmetic operations on some modes.
276 4.1.1 Arithmetic functions
277 --------------------------
279 -- Runtime Function: int __ashlsi3 (int A, int B)
280 -- Runtime Function: long __ashldi3 (long A, int B)
281 -- Runtime Function: long long __ashlti3 (long long A, int B)
282 These functions return the result of shifting A left by B bits.
284 -- Runtime Function: int __ashrsi3 (int A, int B)
285 -- Runtime Function: long __ashrdi3 (long A, int B)
286 -- Runtime Function: long long __ashrti3 (long long A, int B)
287 These functions return the result of arithmetically shifting A
290 -- Runtime Function: int __divsi3 (int A, int B)
291 -- Runtime Function: long __divdi3 (long A, long B)
292 -- Runtime Function: long long __divti3 (long long A, long long B)
293 These functions return the quotient of the signed division of A and
296 -- Runtime Function: int __lshrsi3 (int A, int B)
297 -- Runtime Function: long __lshrdi3 (long A, int B)
298 -- Runtime Function: long long __lshrti3 (long long A, int B)
299 These functions return the result of logically shifting A right by
302 -- Runtime Function: int __modsi3 (int A, int B)
303 -- Runtime Function: long __moddi3 (long A, long B)
304 -- Runtime Function: long long __modti3 (long long A, long long B)
305 These functions return the remainder of the signed division of A
308 -- Runtime Function: int __mulsi3 (int A, int B)
309 -- Runtime Function: long __muldi3 (long A, long B)
310 -- Runtime Function: long long __multi3 (long long A, long long B)
311 These functions return the product of A and B.
313 -- Runtime Function: long __negdi2 (long A)
314 -- Runtime Function: long long __negti2 (long long A)
315 These functions return the negation of A.
317 -- Runtime Function: unsigned int __udivsi3 (unsigned int A, unsigned
319 -- Runtime Function: unsigned long __udivdi3 (unsigned long A,
321 -- Runtime Function: unsigned long long __udivti3 (unsigned long long
322 A, unsigned long long B)
323 These functions return the quotient of the unsigned division of A
326 -- Runtime Function: unsigned long __udivmoddi3 (unsigned long A,
327 unsigned long B, unsigned long *C)
328 -- Runtime Function: unsigned long long __udivti3 (unsigned long long
329 A, unsigned long long B, unsigned long long *C)
330 These functions calculate both the quotient and remainder of the
331 unsigned division of A and B. The return value is the quotient,
332 and the remainder is placed in variable pointed to by C.
334 -- Runtime Function: unsigned int __umodsi3 (unsigned int A, unsigned
336 -- Runtime Function: unsigned long __umoddi3 (unsigned long A,
338 -- Runtime Function: unsigned long long __umodti3 (unsigned long long
339 A, unsigned long long B)
340 These functions return the remainder of the unsigned division of A
343 4.1.2 Comparison functions
344 --------------------------
346 The following functions implement integral comparisons. These functions
347 implement a low-level compare, upon which the higher level comparison
348 operators (such as less than and greater than or equal to) can be
349 constructed. The returned values lie in the range zero to two, to allow
350 the high-level operators to be implemented by testing the returned
351 result using either signed or unsigned comparison.
353 -- Runtime Function: int __cmpdi2 (long A, long B)
354 -- Runtime Function: int __cmpti2 (long long A, long long B)
355 These functions perform a signed comparison of A and B. If A is
356 less than B, they return 0; if A is greater than B, they return 2;
357 and if A and B are equal they return 1.
359 -- Runtime Function: int __ucmpdi2 (unsigned long A, unsigned long B)
360 -- Runtime Function: int __ucmpti2 (unsigned long long A, unsigned
362 These functions perform an unsigned comparison of A and B. If A
363 is less than B, they return 0; if A is greater than B, they return
364 2; and if A and B are equal they return 1.
366 4.1.3 Trapping arithmetic functions
367 -----------------------------------
369 The following functions implement trapping arithmetic. These functions
370 call the libc function `abort' upon signed arithmetic overflow.
372 -- Runtime Function: int __absvsi2 (int A)
373 -- Runtime Function: long __absvdi2 (long A)
374 These functions return the absolute value of A.
376 -- Runtime Function: int __addvsi3 (int A, int B)
377 -- Runtime Function: long __addvdi3 (long A, long B)
378 These functions return the sum of A and B; that is `A + B'.
380 -- Runtime Function: int __mulvsi3 (int A, int B)
381 -- Runtime Function: long __mulvdi3 (long A, long B)
382 The functions return the product of A and B; that is `A * B'.
384 -- Runtime Function: int __negvsi2 (int A)
385 -- Runtime Function: long __negvdi2 (long A)
386 These functions return the negation of A; that is `-A'.
388 -- Runtime Function: int __subvsi3 (int A, int B)
389 -- Runtime Function: long __subvdi3 (long A, long B)
390 These functions return the difference between B and A; that is `A
396 -- Runtime Function: int __clzsi2 (int A)
397 -- Runtime Function: int __clzdi2 (long A)
398 -- Runtime Function: int __clzti2 (long long A)
399 These functions return the number of leading 0-bits in A, starting
400 at the most significant bit position. If A is zero, the result is
403 -- Runtime Function: int __ctzsi2 (int A)
404 -- Runtime Function: int __ctzdi2 (long A)
405 -- Runtime Function: int __ctzti2 (long long A)
406 These functions return the number of trailing 0-bits in A, starting
407 at the least significant bit position. If A is zero, the result is
410 -- Runtime Function: int __ffsdi2 (long A)
411 -- Runtime Function: int __ffsti2 (long long A)
412 These functions return the index of the least significant 1-bit in
413 A, or the value zero if A is zero. The least significant bit is
416 -- Runtime Function: int __paritysi2 (int A)
417 -- Runtime Function: int __paritydi2 (long A)
418 -- Runtime Function: int __parityti2 (long long A)
419 These functions return the value zero if the number of bits set in
420 A is even, and the value one otherwise.
422 -- Runtime Function: int __popcountsi2 (int A)
423 -- Runtime Function: int __popcountdi2 (long A)
424 -- Runtime Function: int __popcountti2 (long long A)
425 These functions return the number of bits set in A.
428 File: gccint.info, Node: Soft float library routines, Next: Exception handling routines, Prev: Integer library routines, Up: Libgcc
430 4.2 Routines for floating point emulation
431 =========================================
433 The software floating point library is used on machines which do not
434 have hardware support for floating point. It is also used whenever
435 `-msoft-float' is used to disable generation of floating point
436 instructions. (Not all targets support this switch.)
438 For compatibility with other compilers, the floating point emulation
439 routines can be renamed with the `DECLARE_LIBRARY_RENAMES' macro (*note
440 Library Calls::). In this section, the default names are used.
442 Presently the library does not support `XFmode', which is used for
443 `long double' on some architectures.
445 4.2.1 Arithmetic functions
446 --------------------------
448 -- Runtime Function: float __addsf3 (float A, float B)
449 -- Runtime Function: double __adddf3 (double A, double B)
450 -- Runtime Function: long double __addtf3 (long double A, long double
452 -- Runtime Function: long double __addxf3 (long double A, long double
454 These functions return the sum of A and B.
456 -- Runtime Function: float __subsf3 (float A, float B)
457 -- Runtime Function: double __subdf3 (double A, double B)
458 -- Runtime Function: long double __subtf3 (long double A, long double
460 -- Runtime Function: long double __subxf3 (long double A, long double
462 These functions return the difference between B and A; that is,
465 -- Runtime Function: float __mulsf3 (float A, float B)
466 -- Runtime Function: double __muldf3 (double A, double B)
467 -- Runtime Function: long double __multf3 (long double A, long double
469 -- Runtime Function: long double __mulxf3 (long double A, long double
471 These functions return the product of A and B.
473 -- Runtime Function: float __divsf3 (float A, float B)
474 -- Runtime Function: double __divdf3 (double A, double B)
475 -- Runtime Function: long double __divtf3 (long double A, long double
477 -- Runtime Function: long double __divxf3 (long double A, long double
479 These functions return the quotient of A and B; that is, A / B.
481 -- Runtime Function: float __negsf2 (float A)
482 -- Runtime Function: double __negdf2 (double A)
483 -- Runtime Function: long double __negtf2 (long double A)
484 -- Runtime Function: long double __negxf2 (long double A)
485 These functions return the negation of A. They simply flip the
486 sign bit, so they can produce negative zero and negative NaN.
488 4.2.2 Conversion functions
489 --------------------------
491 -- Runtime Function: double __extendsfdf2 (float A)
492 -- Runtime Function: long double __extendsftf2 (float A)
493 -- Runtime Function: long double __extendsfxf2 (float A)
494 -- Runtime Function: long double __extenddftf2 (double A)
495 -- Runtime Function: long double __extenddfxf2 (double A)
496 These functions extend A to the wider mode of their return type.
498 -- Runtime Function: double __truncxfdf2 (long double A)
499 -- Runtime Function: double __trunctfdf2 (long double A)
500 -- Runtime Function: float __truncxfsf2 (long double A)
501 -- Runtime Function: float __trunctfsf2 (long double A)
502 -- Runtime Function: float __truncdfsf2 (double A)
503 These functions truncate A to the narrower mode of their return
504 type, rounding toward zero.
506 -- Runtime Function: int __fixsfsi (float A)
507 -- Runtime Function: int __fixdfsi (double A)
508 -- Runtime Function: int __fixtfsi (long double A)
509 -- Runtime Function: int __fixxfsi (long double A)
510 These functions convert A to a signed integer, rounding toward
513 -- Runtime Function: long __fixsfdi (float A)
514 -- Runtime Function: long __fixdfdi (double A)
515 -- Runtime Function: long __fixtfdi (long double A)
516 -- Runtime Function: long __fixxfdi (long double A)
517 These functions convert A to a signed long, rounding toward zero.
519 -- Runtime Function: long long __fixsfti (float A)
520 -- Runtime Function: long long __fixdfti (double A)
521 -- Runtime Function: long long __fixtfti (long double A)
522 -- Runtime Function: long long __fixxfti (long double A)
523 These functions convert A to a signed long long, rounding toward
526 -- Runtime Function: unsigned int __fixunssfsi (float A)
527 -- Runtime Function: unsigned int __fixunsdfsi (double A)
528 -- Runtime Function: unsigned int __fixunstfsi (long double A)
529 -- Runtime Function: unsigned int __fixunsxfsi (long double A)
530 These functions convert A to an unsigned integer, rounding toward
531 zero. Negative values all become zero.
533 -- Runtime Function: unsigned long __fixunssfdi (float A)
534 -- Runtime Function: unsigned long __fixunsdfdi (double A)
535 -- Runtime Function: unsigned long __fixunstfdi (long double A)
536 -- Runtime Function: unsigned long __fixunsxfdi (long double A)
537 These functions convert A to an unsigned long, rounding toward
538 zero. Negative values all become zero.
540 -- Runtime Function: unsigned long long __fixunssfti (float A)
541 -- Runtime Function: unsigned long long __fixunsdfti (double A)
542 -- Runtime Function: unsigned long long __fixunstfti (long double A)
543 -- Runtime Function: unsigned long long __fixunsxfti (long double A)
544 These functions convert A to an unsigned long long, rounding
545 toward zero. Negative values all become zero.
547 -- Runtime Function: float __floatsisf (int I)
548 -- Runtime Function: double __floatsidf (int I)
549 -- Runtime Function: long double __floatsitf (int I)
550 -- Runtime Function: long double __floatsixf (int I)
551 These functions convert I, a signed integer, to floating point.
553 -- Runtime Function: float __floatdisf (long I)
554 -- Runtime Function: double __floatdidf (long I)
555 -- Runtime Function: long double __floatditf (long I)
556 -- Runtime Function: long double __floatdixf (long I)
557 These functions convert I, a signed long, to floating point.
559 -- Runtime Function: float __floattisf (long long I)
560 -- Runtime Function: double __floattidf (long long I)
561 -- Runtime Function: long double __floattitf (long long I)
562 -- Runtime Function: long double __floattixf (long long I)
563 These functions convert I, a signed long long, to floating point.
565 4.2.3 Comparison functions
566 --------------------------
568 There are two sets of basic comparison functions.
570 -- Runtime Function: int __cmpsf2 (float A, float B)
571 -- Runtime Function: int __cmpdf2 (double A, double B)
572 -- Runtime Function: int __cmptf2 (long double A, long double B)
573 These functions calculate a <=> b. That is, if A is less than B,
574 they return -1; if A is greater than B, they return 1; and if A
575 and B are equal they return 0. If either argument is NaN they
576 return 1, but you should not rely on this; if NaN is a
577 possibility, use one of the higher-level comparison functions.
579 -- Runtime Function: int __unordsf2 (float A, float B)
580 -- Runtime Function: int __unorddf2 (double A, double B)
581 -- Runtime Function: int __unordtf2 (long double A, long double B)
582 These functions return a nonzero value if either argument is NaN,
585 There is also a complete group of higher level functions which
586 correspond directly to comparison operators. They implement the ISO C
587 semantics for floating-point comparisons, taking NaN into account. Pay
588 careful attention to the return values defined for each set. Under the
589 hood, all of these routines are implemented as
591 if (__unordXf2 (a, b))
593 return __cmpXf2 (a, b);
595 where E is a constant chosen to give the proper behavior for NaN.
596 Thus, the meaning of the return value is different for each set. Do
597 not rely on this implementation; only the semantics documented below
600 -- Runtime Function: int __eqsf2 (float A, float B)
601 -- Runtime Function: int __eqdf2 (double A, double B)
602 -- Runtime Function: int __eqtf2 (long double A, long double B)
603 These functions return zero if neither argument is NaN, and A and
606 -- Runtime Function: int __nesf2 (float A, float B)
607 -- Runtime Function: int __nedf2 (double A, double B)
608 -- Runtime Function: int __netf2 (long double A, long double B)
609 These functions return a nonzero value if either argument is NaN,
610 or if A and B are unequal.
612 -- Runtime Function: int __gesf2 (float A, float B)
613 -- Runtime Function: int __gedf2 (double A, double B)
614 -- Runtime Function: int __getf2 (long double A, long double B)
615 These functions return a value greater than or equal to zero if
616 neither argument is NaN, and A is greater than or equal to B.
618 -- Runtime Function: int __ltsf2 (float A, float B)
619 -- Runtime Function: int __ltdf2 (double A, double B)
620 -- Runtime Function: int __lttf2 (long double A, long double B)
621 These functions return a value less than zero if neither argument
622 is NaN, and A is strictly less than B.
624 -- Runtime Function: int __lesf2 (float A, float B)
625 -- Runtime Function: int __ledf2 (double A, double B)
626 -- Runtime Function: int __letf2 (long double A, long double B)
627 These functions return a value less than or equal to zero if
628 neither argument is NaN, and A is less than or equal to B.
630 -- Runtime Function: int __gtsf2 (float A, float B)
631 -- Runtime Function: int __gtdf2 (double A, double B)
632 -- Runtime Function: int __gttf2 (long double A, long double B)
633 These functions return a value greater than zero if neither
634 argument is NaN, and A is strictly greater than B.
637 File: gccint.info, Node: Exception handling routines, Next: Miscellaneous routines, Prev: Soft float library routines, Up: Libgcc
639 4.3 Language-independent routines for exception handling
640 ========================================================
644 _Unwind_DeleteException
649 _Unwind_GetLanguageSpecificData
650 _Unwind_GetRegionStart
651 _Unwind_GetTextRelBase
652 _Unwind_GetDataRelBase
653 _Unwind_RaiseException
657 _Unwind_FindEnclosingFunction
658 _Unwind_SjLj_Register
659 _Unwind_SjLj_Unregister
660 _Unwind_SjLj_RaiseException
661 _Unwind_SjLj_ForcedUnwind
664 __deregister_frame_info
665 __deregister_frame_info_bases
667 __register_frame_info
668 __register_frame_info_bases
669 __register_frame_info_table
670 __register_frame_info_table_bases
671 __register_frame_table
674 File: gccint.info, Node: Miscellaneous routines, Prev: Exception handling routines, Up: Libgcc
676 4.4 Miscellaneous runtime library routines
677 ==========================================
679 4.4.1 Cache control functions
680 -----------------------------
682 -- Runtime Function: void __clear_cache (char *BEG, char *END)
683 This function clears the instruction cache between BEG and END.
686 File: gccint.info, Node: Languages, Next: Source Tree, Prev: Libgcc, Up: Top
688 5 Language Front Ends in GCC
689 ****************************
691 The interface to front ends for languages in GCC, and in particular the
692 `tree' structure (*note Trees::), was initially designed for C, and
693 many aspects of it are still somewhat biased towards C and C-like
694 languages. It is, however, reasonably well suited to other procedural
695 languages, and front ends for many such languages have been written for
698 Writing a compiler as a front end for GCC, rather than compiling
699 directly to assembler or generating C code which is then compiled by
700 GCC, has several advantages:
702 * GCC front ends benefit from the support for many different target
703 machines already present in GCC.
705 * GCC front ends benefit from all the optimizations in GCC. Some of
706 these, such as alias analysis, may work better when GCC is
707 compiling directly from source code then when it is compiling from
710 * Better debugging information is generated when compiling directly
711 from source code than when going via intermediate generated C code.
713 Because of the advantages of writing a compiler as a GCC front end,
714 GCC front ends have also been created for languages very different from
715 those for which GCC was designed, such as the declarative
716 logic/functional language Mercury. For these reasons, it may also be
717 useful to implement compilers created for specialized purposes (for
718 example, as part of a research project) as GCC front ends.
721 File: gccint.info, Node: Source Tree, Next: Options, Prev: Languages, Up: Top
723 6 Source Tree Structure and Build System
724 ****************************************
726 This chapter describes the structure of the GCC source tree, and how
727 GCC is built. The user documentation for building and installing GCC
728 is in a separate manual (`http://gcc.gnu.org/install/'), with which it
729 is presumed that you are familiar.
733 * Configure Terms:: Configuration terminology and history.
734 * Top Level:: The top level source directory.
735 * gcc Directory:: The `gcc' subdirectory.
736 * Testsuites:: The GCC testsuites.
739 File: gccint.info, Node: Configure Terms, Next: Top Level, Up: Source Tree
741 6.1 Configure Terms and History
742 ===============================
744 The configure and build process has a long and colorful history, and can
745 be confusing to anyone who doesn't know why things are the way they are.
746 While there are other documents which describe the configuration process
747 in detail, here are a few things that everyone working on GCC should
750 There are three system names that the build knows about: the machine
751 you are building on ("build"), the machine that you are building for
752 ("host"), and the machine that GCC will produce code for ("target").
753 When you configure GCC, you specify these with `--build=', `--host=',
756 Specifying the host without specifying the build should be avoided, as
757 `configure' may (and once did) assume that the host you specify is also
758 the build, which may not be true.
760 If build, host, and target are all the same, this is called a
761 "native". If build and host are the same but target is different, this
762 is called a "cross". If build, host, and target are all different this
763 is called a "canadian" (for obscure reasons dealing with Canada's
764 political party and the background of the person working on the build
765 at that time). If host and target are the same, but build is
766 different, you are using a cross-compiler to build a native for a
767 different system. Some people call this a "host-x-host", "crossed
768 native", or "cross-built native". If build and target are the same,
769 but host is different, you are using a cross compiler to build a cross
770 compiler that produces code for the machine you're building on. This
771 is rare, so there is no common way of describing it. There is a
772 proposal to call this a "crossback".
774 If build and host are the same, the GCC you are building will also be
775 used to build the target libraries (like `libstdc++'). If build and
776 host are different, you must have already build and installed a cross
777 compiler that will be used to build the target libraries (if you
778 configured with `--target=foo-bar', this compiler will be called
781 In the case of target libraries, the machine you're building for is the
782 machine you specified with `--target'. So, build is the machine you're
783 building on (no change there), host is the machine you're building for
784 (the target libraries are built for the target, so host is the target
785 you specified), and target doesn't apply (because you're not building a
786 compiler, you're building libraries). The configure/make process will
787 adjust these variables as needed. It also sets `$with_cross_host' to
788 the original `--host' value in case you need it.
790 The `libiberty' support library is built up to three times: once for
791 the host, once for the target (even if they are the same), and once for
792 the build if build and host are different. This allows it to be used
793 by all programs which are generated in the course of the build process.
796 File: gccint.info, Node: Top Level, Next: gcc Directory, Prev: Configure Terms, Up: Source Tree
798 6.2 Top Level Source Directory
799 ==============================
801 The top level source directory in a GCC distribution contains several
802 files and directories that are shared with other software distributions
803 such as that of GNU Binutils. It also contains several subdirectories
804 that contain parts of GCC and its runtime libraries:
807 The Boehm conservative garbage collector, used as part of the Java
811 Contributed scripts that may be found useful in conjunction with
812 GCC. One of these, `contrib/texi2pod.pl', is used to generate man
813 pages from Texinfo manuals as part of the GCC build process.
816 An implementation of the `jar' command, used with the Java front
820 The main sources of GCC itself (except for runtime libraries),
821 including optimizers, support for different target architectures,
822 language front ends, and testsuites. *Note The `gcc'
823 Subdirectory: gcc Directory, for details.
826 Headers for the `libiberty' library.
829 The Ada runtime library.
832 The C preprocessor library.
835 The Fortran runtime library.
838 The `libffi' library, used as part of the Java runtime library.
841 The `libiberty' library, used for portability and for some
842 generally useful data structures and algorithms. *Note
843 Introduction: (libiberty)Top, for more information about this
847 The Java runtime library.
850 The `libmudflap' library, used for instrumenting pointer and array
851 dereferencing operations.
854 The Objective-C and Objective-C++ runtime library.
857 The C++ runtime library.
860 Scripts used by the `gccadmin' account on `gcc.gnu.org'.
863 The `zlib' compression library, used by the Java front end and as
864 part of the Java runtime library.
866 The build system in the top level directory, including how recursion
867 into subdirectories works and how building runtime libraries for
868 multilibs is handled, is documented in a separate manual, included with
869 GNU Binutils. *Note GNU configure and build system: (configure)Top,
873 File: gccint.info, Node: gcc Directory, Next: Testsuites, Prev: Top Level, Up: Source Tree
875 6.3 The `gcc' Subdirectory
876 ==========================
878 The `gcc' directory contains many files that are part of the C sources
879 of GCC, other files used as part of the configuration and build
880 process, and subdirectories including documentation and a testsuite.
881 The files that are sources of GCC are documented in a separate chapter.
882 *Note Passes and Files of the Compiler: Passes.
886 * Subdirectories:: Subdirectories of `gcc'.
887 * Configuration:: The configuration process, and the files it uses.
888 * Build:: The build system in the `gcc' directory.
889 * Makefile:: Targets in `gcc/Makefile'.
890 * Library Files:: Library source files and headers under `gcc/'.
891 * Headers:: Headers installed by GCC.
892 * Documentation:: Building documentation in GCC.
893 * Front End:: Anatomy of a language front end.
894 * Back End:: Anatomy of a target back end.
897 File: gccint.info, Node: Subdirectories, Next: Configuration, Up: gcc Directory
899 6.3.1 Subdirectories of `gcc'
900 -----------------------------
902 The `gcc' directory contains the following subdirectories:
905 Subdirectories for various languages. Directories containing a
906 file `config-lang.in' are language subdirectories. The contents of
907 the subdirectories `cp' (for C++), `objc' (for Objective-C) and
908 `objcp' (for Objective-C++) are documented in this manual (*note
909 Passes and Files of the Compiler: Passes.); those for other
910 languages are not. *Note Anatomy of a Language Front End: Front
911 End, for details of the files in these directories.
914 Configuration files for supported architectures and operating
915 systems. *Note Anatomy of a Target Back End: Back End, for
916 details of the files in this directory.
919 Texinfo documentation for GCC, together with automatically
920 generated man pages and support for converting the installation
921 manual to HTML. *Note Documentation::.
924 The support for fixing system headers to work with GCC. See
925 `fixinc/README' for more information. The headers fixed by this
926 mechanism are installed in `LIBSUBDIR/include'. Along with those
927 headers, `README-fixinc' is also installed, as
928 `LIBSUBDIR/include/README'.
931 System headers installed by GCC, mainly those required by the C
932 standard of freestanding implementations. *Note Headers Installed
933 by GCC: Headers, for details of when these and other headers are
937 GNU `libintl', from GNU `gettext', for systems which do not
938 include it in libc. Properly, this directory should be at top
939 level, parallel to the `gcc' directory.
942 Message catalogs with translations of messages produced by GCC into
943 various languages, `LANGUAGE.po'. This directory also contains
944 `gcc.pot', the template for these message catalogues, `exgettext',
945 a wrapper around `gettext' to extract the messages from the GCC
946 sources and create `gcc.pot', which is run by `make gcc.pot', and
947 `EXCLUDES', a list of files from which messages should not be
951 The GCC testsuites (except for those for runtime libraries).
955 File: gccint.info, Node: Configuration, Next: Build, Prev: Subdirectories, Up: gcc Directory
957 6.3.2 Configuration in the `gcc' Directory
958 ------------------------------------------
960 The `gcc' directory is configured with an Autoconf-generated script
961 `configure'. The `configure' script is generated from `configure.ac'
962 and `aclocal.m4'. From the files `configure.ac' and `acconfig.h',
963 Autoheader generates the file `config.in'. The file `cstamp-h.in' is
968 * Config Fragments:: Scripts used by `configure'.
969 * System Config:: The `config.build', `config.host', and
971 * Configuration Files:: Files created by running `configure'.
974 File: gccint.info, Node: Config Fragments, Next: System Config, Up: Configuration
976 6.3.2.1 Scripts Used by `configure'
977 ...................................
979 `configure' uses some other scripts to help in its work:
981 * The standard GNU `config.sub' and `config.guess' files, kept in
982 the top level directory, are used. FIXME: when is the
983 `config.guess' file in the `gcc' directory (that just calls the
986 * The file `config.gcc' is used to handle configuration specific to
987 the particular target machine. The file `config.build' is used to
988 handle configuration specific to the particular build machine.
989 The file `config.host' is used to handle configuration specific to
990 the particular host machine. (In general, these should only be
991 used for features that cannot reasonably be tested in Autoconf
992 feature tests.) *Note The `config.build'; `config.host'; and
993 `config.gcc' Files: System Config, for details of the contents of
996 * Each language subdirectory has a file `LANGUAGE/config-lang.in'
997 that is used for front-end-specific configuration. *Note The
998 Front End `config-lang.in' File: Front End Config, for details of
1001 * A helper script `configure.frag' is used as part of creating the
1002 output of `configure'.
1005 File: gccint.info, Node: System Config, Next: Configuration Files, Prev: Config Fragments, Up: Configuration
1007 6.3.2.2 The `config.build'; `config.host'; and `config.gcc' Files
1008 .................................................................
1010 The `config.build' file contains specific rules for particular systems
1011 which GCC is built on. This should be used as rarely as possible, as
1012 the behavior of the build system can always be detected by autoconf.
1014 The `config.host' file contains specific rules for particular systems
1015 which GCC will run on. This is rarely needed.
1017 The `config.gcc' file contains specific rules for particular systems
1018 which GCC will generate code for. This is usually needed.
1020 Each file has a list of the shell variables it sets, with
1021 descriptions, at the top of the file.
1023 FIXME: document the contents of these files, and what variables should
1024 be set to control build, host and target configuration.
1027 File: gccint.info, Node: Configuration Files, Prev: System Config, Up: Configuration
1029 6.3.2.3 Files Created by `configure'
1030 ....................................
1032 Here we spell out what files will be set up by `configure' in the `gcc'
1033 directory. Some other files are created as temporary files in the
1034 configuration process, and are not used in the subsequent build; these
1037 * `Makefile' is constructed from `Makefile.in', together with the
1038 host and target fragments (*note Makefile Fragments: Fragments.)
1039 `t-TARGET' and `x-HOST' from `config', if any, and language
1040 Makefile fragments `LANGUAGE/Make-lang.in'.
1042 * `auto-host.h' contains information about the host machine
1043 determined by `configure'. If the host machine is different from
1044 the build machine, then `auto-build.h' is also created, containing
1045 such information about the build machine.
1047 * `config.status' is a script that may be run to recreate the
1048 current configuration.
1050 * `configargs.h' is a header containing details of the arguments
1051 passed to `configure' to configure GCC, and of the thread model
1054 * `cstamp-h' is used as a timestamp.
1056 * `fixinc/Makefile' is constructed from `fixinc/Makefile.in'.
1058 * `gccbug', a script for reporting bugs in GCC, is constructed from
1061 * `intl/Makefile' is constructed from `intl/Makefile.in'.
1063 * `mklibgcc', a shell script to create a Makefile to build libgcc,
1064 is constructed from `mklibgcc.in'.
1066 * If a language `config-lang.in' file (*note The Front End
1067 `config-lang.in' File: Front End Config.) sets `outputs', then the
1068 files listed in `outputs' there are also generated.
1070 The following configuration headers are created from the Makefile,
1071 using `mkconfig.sh', rather than directly by `configure'. `config.h',
1072 `bconfig.h' and `tconfig.h' all contain the `xm-MACHINE.h' header, if
1073 any, appropriate to the host, build and target machines respectively,
1074 the configuration headers for the target, and some definitions; for the
1075 host and build machines, these include the autoconfigured headers
1076 generated by `configure'. The other configuration headers are
1077 determined by `config.gcc'. They also contain the typedefs for `rtx',
1080 * `config.h', for use in programs that run on the host machine.
1082 * `bconfig.h', for use in programs that run on the build machine.
1084 * `tconfig.h', for use in programs and libraries for the target
1087 * `tm_p.h', which includes the header `MACHINE-protos.h' that
1088 contains prototypes for functions in the target `.c' file. FIXME:
1089 why is such a separate header necessary?
1092 File: gccint.info, Node: Build, Next: Makefile, Prev: Configuration, Up: gcc Directory
1094 6.3.3 Build System in the `gcc' Directory
1095 -----------------------------------------
1097 FIXME: describe the build system, including what is built in what
1098 stages. Also list the various source files that are used in the build
1099 process but aren't source files of GCC itself and so aren't documented
1100 below (*note Passes::).
1103 File: gccint.info, Node: Makefile, Next: Library Files, Prev: Build, Up: gcc Directory
1105 6.3.4 Makefile Targets
1106 ----------------------
1109 This is the default target. Depending on what your
1110 build/host/target configuration is, it coordinates all the things
1111 that need to be built.
1114 Produce info-formatted documentation and man pages. Essentially it
1115 calls `make man' and `make info'.
1118 Produce DVI-formatted documentation.
1121 Produce HTML-formatted documentation.
1127 Generate info-formatted pages.
1130 Delete the files made while building the compiler.
1133 That, and all the other files built by `make all'.
1136 That, and all the files created by `configure'.
1139 Distclean plus any file that can be generated from other files.
1140 Note that additional tools may be required beyond what is normally
1141 needed to build gcc.
1144 Generates files in the source directory that do not exist in CVS
1145 but should go into a release tarball. One example is
1146 `gcc/java/parse.c' which is generated from the CVS source file
1151 Copies the info-formatted and manpage documentation into the source
1152 directory usually for the purpose of generating a release tarball.
1158 Deletes installed files.
1161 Run the testsuite. This creates a `testsuite' subdirectory that
1162 has various `.sum' and `.log' files containing the results of the
1163 testing. You can run subsets with, for example, `make check-gcc'.
1164 You can specify specific tests by setting RUNTESTFLAGS to be the
1165 name of the `.exp' file, optionally followed by (for some tests)
1166 an equals and a file wildcard, like:
1168 make check-gcc RUNTESTFLAGS="execute.exp=19980413-*"
1170 Note that running the testsuite may require additional tools be
1171 installed, such as TCL or dejagnu.
1174 Builds GCC three times--once with the native compiler, once with
1175 the native-built compiler it just built, and once with the
1176 compiler it built the second time. In theory, the last two should
1177 produce the same results, which `make compare' can check. Each
1178 step of this process is called a "stage", and the results of each
1179 stage N (N = 1...3) are copied to a subdirectory `stageN/'.
1182 Like `bootstrap', except that the various stages are removed once
1183 they're no longer needed. This saves disk space.
1186 This incrementally rebuilds each of the three stages, one at a
1187 time. It does this by "bubbling" the stages up from their
1188 subdirectories (if they had been built previously), rebuilding
1189 them, and copying them back to their subdirectories. This will
1190 allow you to, for example, continue a bootstrap after fixing a bug
1191 which causes the stage2 build to crash.
1194 Rebuilds the most recently built stage. Since each stage requires
1195 special invocation, using this target means you don't have to keep
1196 track of which stage you're on or what invocation that stage needs.
1199 Removed everything (`make clean') and rebuilds (`make bootstrap').
1202 Like `cleanstrap', except that the process starts from the first
1203 stage build, not from scratch.
1205 `stageN (N = 1...4)'
1206 For each stage, moves the appropriate files to the `stageN'
1209 `unstageN (N = 1...4)'
1210 Undoes the corresponding `stageN'.
1212 `restageN (N = 1...4)'
1213 Undoes the corresponding `stageN' and rebuilds it with the
1217 Compares the results of stages 2 and 3. This ensures that the
1218 compiler is running properly, since it should produce the same
1219 object files regardless of how it itself was compiled.
1222 Builds a compiler with profiling feedback information. For more
1223 information, see *Note Building with profile feedback:
1224 (gccinstall)Building. This is actually a target in the top-level
1225 directory, which then recurses into the `gcc' subdirectory
1230 File: gccint.info, Node: Library Files, Next: Headers, Prev: Makefile, Up: gcc Directory
1232 6.3.5 Library Source Files and Headers under the `gcc' Directory
1233 ----------------------------------------------------------------
1235 FIXME: list here, with explanation, all the C source files and headers
1236 under the `gcc' directory that aren't built into the GCC executable but
1237 rather are part of runtime libraries and object files, such as
1238 `crtstuff.c' and `unwind-dw2.c'. *Note Headers Installed by GCC:
1239 Headers, for more information about the `ginclude' directory.
1242 File: gccint.info, Node: Headers, Next: Documentation, Prev: Library Files, Up: gcc Directory
1244 6.3.6 Headers Installed by GCC
1245 ------------------------------
1247 In general, GCC expects the system C library to provide most of the
1248 headers to be used with it. However, GCC will fix those headers if
1249 necessary to make them work with GCC, and will install some headers
1250 required of freestanding implementations. These headers are installed
1251 in `LIBSUBDIR/include'. Headers for non-C runtime libraries are also
1252 installed by GCC; these are not documented here. (FIXME: document them
1255 Several of the headers GCC installs are in the `ginclude' directory.
1256 These headers, `iso646.h', `stdarg.h', `stdbool.h', and `stddef.h', are
1257 installed in `LIBSUBDIR/include', unless the target Makefile fragment
1258 (*note Target Fragment::) overrides this by setting `USER_H'.
1260 In addition to these headers and those generated by fixing system
1261 headers to work with GCC, some other headers may also be installed in
1262 `LIBSUBDIR/include'. `config.gcc' may set `extra_headers'; this
1263 specifies additional headers under `config' to be installed on some
1266 GCC installs its own version of `<float.h>', from `ginclude/float.h'.
1267 This is done to cope with command-line options that change the
1268 representation of floating point numbers.
1270 GCC also installs its own version of `<limits.h>'; this is generated
1271 from `glimits.h', together with `limitx.h' and `limity.h' if the system
1272 also has its own version of `<limits.h>'. (GCC provides its own header
1273 because it is required of ISO C freestanding implementations, but needs
1274 to include the system header from its own header as well because other
1275 standards such as POSIX specify additional values to be defined in
1276 `<limits.h>'.) The system's `<limits.h>' header is used via
1277 `LIBSUBDIR/include/syslimits.h', which is copied from `gsyslimits.h' if
1278 it does not need fixing to work with GCC; if it needs fixing,
1279 `syslimits.h' is the fixed copy.
1282 File: gccint.info, Node: Documentation, Next: Front End, Prev: Headers, Up: gcc Directory
1284 6.3.7 Building Documentation
1285 ----------------------------
1287 The main GCC documentation is in the form of manuals in Texinfo format.
1288 These are installed in Info format, and DVI versions may be generated
1289 by `make dvi' and HTML versions may be generated by `make html'. In
1290 addition, some man pages are generated from the Texinfo manuals, there
1291 are some other text files with miscellaneous documentation, and runtime
1292 libraries have their own documentation outside the `gcc' directory.
1293 FIXME: document the documentation for runtime libraries somewhere.
1297 * Texinfo Manuals:: GCC manuals in Texinfo format.
1298 * Man Page Generation:: Generating man pages from Texinfo manuals.
1299 * Miscellaneous Docs:: Miscellaneous text files with documentation.
1302 File: gccint.info, Node: Texinfo Manuals, Next: Man Page Generation, Up: Documentation
1304 6.3.7.1 Texinfo Manuals
1305 .......................
1307 The manuals for GCC as a whole, and the C and C++ front ends, are in
1308 files `doc/*.texi'. Other front ends have their own manuals in files
1309 `LANGUAGE/*.texi'. Common files `doc/include/*.texi' are provided
1310 which may be included in multiple manuals; the following files are in
1314 The GNU Free Documentation License.
1317 The section "Funding Free Software".
1320 Common definitions for manuals.
1323 The GNU General Public License.
1326 A copy of `texinfo.tex' known to work with the GCC manuals.
1328 DVI formatted manuals are generated by `make dvi', which uses
1329 `texi2dvi' (via the Makefile macro `$(TEXI2DVI)'). HTML formatted
1330 manuals are generated by `make html'. Info manuals are generated by
1331 `make info' (which is run as part of a bootstrap); this generates the
1332 manuals in the source directory, using `makeinfo' via the Makefile
1333 macro `$(MAKEINFO)', and they are included in release distributions.
1335 Manuals are also provided on the GCC web site, in both HTML and
1336 PostScript forms. This is done via the script
1337 `maintainer-scripts/update_web_docs'. Each manual to be provided
1338 online must be listed in the definition of `MANUALS' in that file; a
1339 file `NAME.texi' must only appear once in the source tree, and the
1340 output manual must have the same name as the source file. (However,
1341 other Texinfo files, included in manuals but not themselves the root
1342 files of manuals, may have names that appear more than once in the
1343 source tree.) The manual file `NAME.texi' should only include other
1344 files in its own directory or in `doc/include'. HTML manuals will be
1345 generated by `makeinfo --html' and PostScript manuals by `texi2dvi' and
1346 `dvips'. All Texinfo files that are parts of manuals must be checked
1347 into CVS, even if they are generated files, for the generation of
1348 online manuals to work.
1350 The installation manual, `doc/install.texi', is also provided on the
1351 GCC web site. The HTML version is generated by the script
1352 `doc/install.texi2html'.
1355 File: gccint.info, Node: Man Page Generation, Next: Miscellaneous Docs, Prev: Texinfo Manuals, Up: Documentation
1357 6.3.7.2 Man Page Generation
1358 ...........................
1360 Because of user demand, in addition to full Texinfo manuals, man pages
1361 are provided which contain extracts from those manuals. These man
1362 pages are generated from the Texinfo manuals using
1363 `contrib/texi2pod.pl' and `pod2man'. (The man page for `g++',
1364 `cp/g++.1', just contains a `.so' reference to `gcc.1', but all the
1365 other man pages are generated from Texinfo manuals.)
1367 Because many systems may not have the necessary tools installed to
1368 generate the man pages, they are only generated if the `configure'
1369 script detects that recent enough tools are installed, and the
1370 Makefiles allow generating man pages to fail without aborting the
1371 build. Man pages are also included in release distributions. They are
1372 generated in the source directory.
1374 Magic comments in Texinfo files starting `@c man' control what parts
1375 of a Texinfo file go into a man page. Only a subset of Texinfo is
1376 supported by `texi2pod.pl', and it may be necessary to add support for
1377 more Texinfo features to this script when generating new man pages. To
1378 improve the man page output, some special Texinfo macros are provided
1379 in `doc/include/gcc-common.texi' which `texi2pod.pl' understands:
1382 Use in the form `@table @gcctabopt' for tables of options, where
1383 for printed output the effect of `@code' is better than that of
1384 `@option' but for man page output a different effect is wanted.
1387 Use for summary lists of options in manuals.
1390 Use at the end of each line inside `@gccoptlist'. This is
1391 necessary to avoid problems with differences in how the
1392 `@gccoptlist' macro is handled by different Texinfo formatters.
1394 FIXME: describe the `texi2pod.pl' input language and magic comments in
1398 File: gccint.info, Node: Miscellaneous Docs, Prev: Man Page Generation, Up: Documentation
1400 6.3.7.3 Miscellaneous Documentation
1401 ...................................
1403 In addition to the formal documentation that is installed by GCC, there
1404 are several other text files with miscellaneous documentation:
1407 Notes on GCC's Native Language Support. FIXME: this should be
1408 part of this manual rather than a separate file.
1411 Notes on the Free Translation Project.
1414 The GNU General Public License.
1417 The GNU Lesser General Public License.
1421 Change log files for various parts of GCC.
1424 Details of a few changes to the GCC front-end interface. FIXME:
1425 the information in this file should be part of general
1426 documentation of the front-end interface in this manual.
1429 Information about new features in old versions of GCC. (For recent
1430 versions, the information is on the GCC web site.)
1432 `README.Portability'
1433 Information about portability issues when writing code in GCC.
1434 FIXME: why isn't this part of this manual or of the GCC Coding
1438 A pointer to the GNU Service Directory.
1440 FIXME: document such files in subdirectories, at least `config', `cp',
1441 `objc', `testsuite'.
1444 File: gccint.info, Node: Front End, Next: Back End, Prev: Documentation, Up: gcc Directory
1446 6.3.8 Anatomy of a Language Front End
1447 -------------------------------------
1449 A front end for a language in GCC has the following parts:
1451 * A directory `LANGUAGE' under `gcc' containing source files for
1452 that front end. *Note The Front End `LANGUAGE' Directory: Front
1453 End Directory, for details.
1455 * A mention of the language in the list of supported languages in
1456 `gcc/doc/install.texi'.
1458 * A mention of the name under which the language's runtime library is
1459 recognized by `--enable-shared=PACKAGE' in the documentation of
1460 that option in `gcc/doc/install.texi'.
1462 * A mention of any special prerequisites for building the front end
1463 in the documentation of prerequisites in `gcc/doc/install.texi'.
1465 * Details of contributors to that front end in
1466 `gcc/doc/contrib.texi'. If the details are in that front end's
1467 own manual then there should be a link to that manual's list in
1470 * Information about support for that language in
1471 `gcc/doc/frontends.texi'.
1473 * Information about standards for that language, and the front end's
1474 support for them, in `gcc/doc/standards.texi'. This may be a link
1475 to such information in the front end's own manual.
1477 * Details of source file suffixes for that language and `-x LANG'
1478 options supported, in `gcc/doc/invoke.texi'.
1480 * Entries in `default_compilers' in `gcc.c' for source file suffixes
1483 * Preferably testsuites, which may be under `gcc/testsuite' or
1484 runtime library directories. FIXME: document somewhere how to
1485 write testsuite harnesses.
1487 * Probably a runtime library for the language, outside the `gcc'
1488 directory. FIXME: document this further.
1490 * Details of the directories of any runtime libraries in
1491 `gcc/doc/sourcebuild.texi'.
1493 If the front end is added to the official GCC CVS repository, the
1494 following are also necessary:
1496 * At least one Bugzilla component for bugs in that front end and
1497 runtime libraries. This category needs to be mentioned in
1498 `gcc/gccbug.in', as well as being added to the Bugzilla database.
1500 * Normally, one or more maintainers of that front end listed in
1503 * Mentions on the GCC web site in `index.html' and `frontends.html',
1504 with any relevant links on `readings.html'. (Front ends that are
1505 not an official part of GCC may also be listed on
1506 `frontends.html', with relevant links.)
1508 * A news item on `index.html', and possibly an announcement on the
1509 <gcc-announce@gcc.gnu.org> mailing list.
1511 * The front end's manuals should be mentioned in
1512 `maintainer-scripts/update_web_docs' (*note Texinfo Manuals::) and
1513 the online manuals should be linked to from
1514 `onlinedocs/index.html'.
1516 * Any old releases or CVS repositories of the front end, before its
1517 inclusion in GCC, should be made available on the GCC FTP site
1518 `ftp://gcc.gnu.org/pub/gcc/old-releases/'.
1520 * The release and snapshot script `maintainer-scripts/gcc_release'
1521 should be updated to generate appropriate tarballs for this front
1522 end. The associated `maintainer-scripts/snapshot-README' and
1523 `maintainer-scripts/snapshot-index.html' files should be updated
1524 to list the tarballs and diffs for this front end.
1526 * If this front end includes its own version files that include the
1527 current date, `maintainer-scripts/update_version' should be
1528 updated accordingly.
1530 * `CVSROOT/modules' in the GCC CVS repository should be updated.
1534 * Front End Directory:: The front end `LANGUAGE' directory.
1535 * Front End Config:: The front end `config-lang.in' file.
1538 File: gccint.info, Node: Front End Directory, Next: Front End Config, Up: Front End
1540 6.3.8.1 The Front End `LANGUAGE' Directory
1541 ..........................................
1543 A front end `LANGUAGE' directory contains the source files of that
1544 front end (but not of any runtime libraries, which should be outside
1545 the `gcc' directory). This includes documentation, and possibly some
1546 subsidiary programs build alongside the front end. Certain files are
1547 special and other parts of the compiler depend on their names:
1550 This file is required in all language subdirectories. *Note The
1551 Front End `config-lang.in' File: Front End Config, for details of
1555 This file is required in all language subdirectories. It contains
1556 targets `LANG.HOOK' (where `LANG' is the setting of `language' in
1557 `config-lang.in') for the following values of `HOOK', and any
1558 other Makefile rules required to build those targets (which may if
1559 necessary use other Makefiles specified in `outputs' in
1560 `config-lang.in', although this is deprecated). Some hooks are
1561 defined by using a double-colon rule for `HOOK', rather than by
1562 using a target of form `LANG.HOOK'. These hooks are called
1563 "double-colon hooks" below. It also adds any testsuite targets
1564 that can use the standard rule in `gcc/Makefile.in' to the variable
1571 FIXME: exactly what goes in each of these targets?
1574 Build an `etags' `TAGS' file in the language subdirectory in
1578 Build info documentation for the front end, in the build
1579 directory. This target is only called by `make bootstrap' if
1580 a suitable version of `makeinfo' is available, so does not
1581 need to check for this, and should fail if an error occurs.
1584 Build DVI documentation for the front end, in the build
1585 directory. This should be done using `$(TEXI2DVI)', with
1586 appropriate `-I' arguments pointing to directories of
1587 included files. This hook is a double-colon hook.
1590 Build HTML documentation for the front end, in the build
1594 Build generated man pages for the front end from Texinfo
1595 manuals (*note Man Page Generation::), in the build
1596 directory. This target is only called if the necessary tools
1597 are available, but should ignore errors so as not to stop the
1598 build if errors occur; man pages are optional and the tools
1599 involved may be installed in a broken way.
1602 FIXME: what is this target for?
1605 Install everything that is part of the front end, apart from
1606 the compiler executables listed in `compilers' in
1610 Install info documentation for the front end, if it is
1611 present in the source directory. This target should have
1612 dependencies on info files that should be installed. This
1613 hook is a double-colon hook.
1616 Install man pages for the front end. This target should
1620 Copies its dependencies into the source directory. This
1621 generally should be used for generated files such as Bison
1622 output files which are not present in CVS, but should be
1623 included in any release tarballs. This target will be
1624 executed during a bootstrap if
1625 `--enable-generated-files-in-srcdir' was specified as a
1630 Copies its dependencies into the source directory. These
1631 targets will be executed during a bootstrap if
1632 `--enable-generated-files-in-srcdir' was specified as a
1636 Uninstall files installed by installing the compiler. This is
1637 currently documented not to be supported, so the hook need
1644 The language parts of the standard GNU `*clean' targets.
1645 *Note Standard Targets for Users: (standards)Standard
1646 Targets, for details of the standard targets. For GCC,
1647 `maintainer-clean' should delete all generated files in the
1648 source directory that are not checked into CVS, but should
1649 not delete anything checked into CVS.
1657 Move to the stage directory files not included in
1658 `stagestuff' in `config-lang.in' or otherwise moved by the
1662 This file registers the set of switches that the front end accepts
1663 on the command line, and their `--help' text. *Note Options::.
1666 This file provides entries for `default_compilers' in `gcc.c'
1667 which override the default of giving an error that a compiler for
1668 that language is not installed.
1671 This file, which need not exist, defines any language-specific tree
1675 File: gccint.info, Node: Front End Config, Prev: Front End Directory, Up: Front End
1677 6.3.8.2 The Front End `config-lang.in' File
1678 ...........................................
1680 Each language subdirectory contains a `config-lang.in' file. In
1681 addition the main directory contains `c-config-lang.in', which contains
1682 limited information for the C language. This file is a shell script
1683 that may define some variables describing the language:
1686 This definition must be present, and gives the name of the language
1687 for some purposes such as arguments to `--enable-languages'.
1690 If defined, this variable lists (space-separated) language front
1691 ends other than C that this front end requires to be enabled (with
1692 the names given being their `language' settings). For example, the
1693 Java front end depends on the C++ front end, so sets
1694 `lang_requires=c++'.
1697 If defined, this variable lists (space-separated) targets in the
1698 top level `Makefile' to build the runtime libraries for this
1699 language, such as `target-libobjc'.
1702 If defined, this variable lists (space-separated) top level
1703 directories (parallel to `gcc'), apart from the runtime libraries,
1704 that should not be configured if this front end is not built.
1707 If defined to `no', this language front end is not built unless
1708 enabled in a `--enable-languages' argument. Otherwise, front ends
1709 are built by default, subject to any special logic in
1710 `configure.ac' (as is present to disable the Ada front end if the
1711 Ada compiler is not already installed).
1714 If defined to `yes', this front end is built in stage 1 of the
1715 bootstrap. This is only relevant to front ends written in their
1719 If defined, a space-separated list of compiler executables that
1720 will be run by the driver. The names here will each end with
1724 If defined, a space-separated list of files that should be moved to
1725 the `stageN' directories in each stage of bootstrap.
1728 If defined, a space-separated list of files that should be
1729 generated by `configure' substituting values in them. This
1730 mechanism can be used to create a file `LANGUAGE/Makefile' from
1731 `LANGUAGE/Makefile.in', but this is deprecated, building
1732 everything from the single `gcc/Makefile' is preferred.
1735 If defined, a space-separated list of files that should be scanned
1736 by gengtype.c to generate the garbage collection tables and
1737 routines for this language. This excludes the files that are
1738 common to all front ends. *Note Type Information::.
1741 If defined to `yes', this frontend requires the GMP library.
1742 Enables configure tests for GMP, which set `GMPLIBS' and `GMPINC'
1747 File: gccint.info, Node: Back End, Prev: Front End, Up: gcc Directory
1749 6.3.9 Anatomy of a Target Back End
1750 ----------------------------------
1752 A back end for a target architecture in GCC has the following parts:
1754 * A directory `MACHINE' under `gcc/config', containing a machine
1755 description `MACHINE.md' file (*note Machine Descriptions: Machine
1756 Desc.), header files `MACHINE.h' and `MACHINE-protos.h' and a
1757 source file `MACHINE.c' (*note Target Description Macros and
1758 Functions: Target Macros.), possibly a target Makefile fragment
1759 `t-MACHINE' (*note The Target Makefile Fragment: Target
1760 Fragment.), and maybe some other files. The names of these files
1761 may be changed from the defaults given by explicit specifications
1764 * If necessary, a file `MACHINE-modes.def' in the `MACHINE'
1765 directory, containing additional machine modes to represent
1766 condition codes. *Note Condition Code::, for further details.
1768 * An optional `MACHINE.opt' file in the `MACHINE' directory,
1769 containing a list of target-specific options. You can also add
1770 other option files using the `extra_options' variable in
1771 `config.gcc'. *Note Options::.
1773 * Entries in `config.gcc' (*note The `config.gcc' File: System
1774 Config.) for the systems with this target architecture.
1776 * Documentation in `gcc/doc/invoke.texi' for any command-line
1777 options supported by this target (*note Run-time Target
1778 Specification: Run-time Target.). This means both entries in the
1779 summary table of options and details of the individual options.
1781 * Documentation in `gcc/doc/extend.texi' for any target-specific
1782 attributes supported (*note Defining target-specific uses of
1783 `__attribute__': Target Attributes.), including where the same
1784 attribute is already supported on some targets, which are
1785 enumerated in the manual.
1787 * Documentation in `gcc/doc/extend.texi' for any target-specific
1790 * Documentation in `gcc/doc/extend.texi' of any target-specific
1791 built-in functions supported.
1793 * Documentation in `gcc/doc/extend.texi' of any target-specific
1794 format checking styles supported.
1796 * Documentation in `gcc/doc/md.texi' of any target-specific
1797 constraint letters (*note Constraints for Particular Machines:
1798 Machine Constraints.).
1800 * A note in `gcc/doc/contrib.texi' under the person or people who
1801 contributed the target support.
1803 * Entries in `gcc/doc/install.texi' for all target triplets
1804 supported with this target architecture, giving details of any
1805 special notes about installation for this target, or saying that
1806 there are no special notes if there are none.
1808 * Possibly other support outside the `gcc' directory for runtime
1809 libraries. FIXME: reference docs for this. The libstdc++ porting
1810 manual needs to be installed as info for this to work, or to be a
1811 chapter of this manual.
1813 If the back end is added to the official GCC CVS repository, the
1814 following are also necessary:
1816 * An entry for the target architecture in `readings.html' on the GCC
1817 web site, with any relevant links.
1819 * Details of the properties of the back end and target architecture
1820 in `backends.html' on the GCC web site.
1822 * A news item about the contribution of support for that target
1823 architecture, in `index.html' on the GCC web site.
1825 * Normally, one or more maintainers of that target listed in
1826 `MAINTAINERS'. Some existing architectures may be unmaintained,
1827 but it would be unusual to add support for a target that does not
1828 have a maintainer when support is added.
1831 File: gccint.info, Node: Testsuites, Prev: gcc Directory, Up: Source Tree
1836 GCC contains several testsuites to help maintain compiler quality.
1837 Most of the runtime libraries and language front ends in GCC have
1838 testsuites. Currently only the C language testsuites are documented
1839 here; FIXME: document the others.
1843 * Test Idioms:: Idioms used in testsuite code.
1844 * Test Directives:: Directives used within DejaGnu tests.
1845 * Ada Tests:: The Ada language testsuites.
1846 * C Tests:: The C language testsuites.
1847 * libgcj Tests:: The Java library testsuites.
1848 * gcov Testing:: Support for testing gcov.
1849 * profopt Testing:: Support for testing profile-directed optimizations.
1850 * compat Testing:: Support for testing binary compatibility.
1853 File: gccint.info, Node: Test Idioms, Next: Test Directives, Up: Testsuites
1855 6.4.1 Idioms Used in Testsuite Code
1856 -----------------------------------
1858 In general, C testcases have a trailing `-N.c', starting with `-1.c',
1859 in case other testcases with similar names are added later. If the
1860 test is a test of some well-defined feature, it should have a name
1861 referring to that feature such as `FEATURE-1.c'. If it does not test a
1862 well-defined feature but just happens to exercise a bug somewhere in
1863 the compiler, and a bug report has been filed for this bug in the GCC
1864 bug database, `prBUG-NUMBER-1.c' is the appropriate form of name.
1865 Otherwise (for miscellaneous bugs not filed in the GCC bug database),
1866 and previously more generally, test cases are named after the date on
1867 which they were added. This allows people to tell at a glance whether
1868 a test failure is because of a recently found bug that has not yet been
1869 fixed, or whether it may be a regression, but does not give any other
1870 information about the bug or where discussion of it may be found. Some
1871 other language testsuites follow similar conventions.
1873 In the `gcc.dg' testsuite, it is often necessary to test that an error
1874 is indeed a hard error and not just a warning--for example, where it is
1875 a constraint violation in the C standard, which must become an error
1876 with `-pedantic-errors'. The following idiom, where the first line
1877 shown is line LINE of the file and the line that generates the error,
1880 /* { dg-bogus "warning" "warning in place of error" } */
1881 /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */
1883 It may be necessary to check that an expression is an integer constant
1884 expression and has a certain value. To check that `E' has value `V',
1885 an idiom similar to the following is used:
1887 char x[((E) == (V) ? 1 : -1)];
1889 In `gcc.dg' tests, `__typeof__' is sometimes used to make assertions
1890 about the types of expressions. See, for example,
1891 `gcc.dg/c99-condexpr-1.c'. The more subtle uses depend on the exact
1892 rules for the types of conditional expressions in the C standard; see,
1893 for example, `gcc.dg/c99-intconst-1.c'.
1895 It is useful to be able to test that optimizations are being made
1896 properly. This cannot be done in all cases, but it can be done where
1897 the optimization will lead to code being optimized away (for example,
1898 where flow analysis or alias analysis should show that certain code
1899 cannot be called) or to functions not being called because they have
1900 been expanded as built-in functions. Such tests go in
1901 `gcc.c-torture/execute'. Where code should be optimized away, a call
1902 to a nonexistent function such as `link_failure ()' may be inserted; a
1905 #ifndef __OPTIMIZE__
1913 will also be needed so that linking still succeeds when the test is run
1914 without optimization. When all calls to a built-in function should
1915 have been optimized and no calls to the non-built-in version of the
1916 function should remain, that function may be defined as `static' to
1917 call `abort ()' (although redeclaring a function as static may not work
1920 All testcases must be portable. Target-specific testcases must have
1921 appropriate code to avoid causing failures on unsupported systems;
1922 unfortunately, the mechanisms for this differ by directory.
1924 FIXME: discuss non-C testsuites here.
1927 File: gccint.info, Node: Test Directives, Next: Ada Tests, Prev: Test Idioms, Up: Testsuites
1929 6.4.2 Directives used within DejaGnu tests
1930 ------------------------------------------
1932 Test directives appear within comments in a test source file and begin
1933 with `dg-'. Some of these are defined within DejaGnu and others are
1934 local to the GCC testsuite.
1936 The order in which test directives appear in a test can be important:
1937 directives local to GCC sometimes override information used by the
1938 DejaGnu directives, which know nothing about the GCC directives, so the
1939 DejaGnu directives must precede GCC directives.
1941 Several test directives include selectors which are usually preceded by
1942 the keyword `target' or `xfail'. A selector is: one or more target
1943 triplets, possibly including wildcard characters; a single
1944 effective-target keyword; or a logical expression. Depending on the
1945 context, the selector specifies whether a test is skipped and reported
1946 as unsupported or is expected to fail. Use `*-*-*' to match any target.
1947 Effective-target keywords are defined in `target-supports.exp' in the
1950 A selector expression appears within curly braces and uses a single
1951 logical operator: one of `!', `&&', or `||'. An operand is another
1952 selector expression, an effective-target keyword, a single target
1953 triplet, or a list of target triplets within quotes or curly braces.
1956 { target { ! "hppa*-*-* ia64*-*-*" } }
1957 { target { powerpc*-*-* && lp64 } }
1958 { xfail { lp64 || vect_no_align } }
1960 `{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }'
1961 DO-WHAT-KEYWORD specifies how the test is compiled and whether it
1962 is executed. It is one of:
1965 Compile with `-E' to run only the preprocessor.
1968 Compile with `-S' to produce an assembly code file.
1971 Compile with `-c' to produce a relocatable object file.
1974 Compile, assemble, and link to produce an executable file.
1977 Produce and run an executable file, which is expected to
1978 return an exit code of 0.
1980 The default is `compile'. That can be overridden for a set of
1981 tests by redefining `dg-do-what-default' within the `.exp' file
1984 If the directive includes the optional `{ target SELECTOR }' then
1985 the test is skipped unless the target system is included in the
1986 list of target triplets or matches the effective-target keyword.
1988 If the directive includes the optional `{ xfail SELECTOR }' and
1989 the selector is met then the test is expected to fail. For `dg-do
1990 run', execution is expected to fail but compilation is expected to
1993 `{ dg-options OPTIONS [{ target SELECTOR }] }'
1994 This DejaGnu directive provides a list of compiler options, to be
1995 used if the target system matches SELECTOR, that replace the
1996 default options used for this set of tests.
1998 `{ dg-skip-if COMMENT { SELECTOR } { INCLUDE-OPTS } { EXCLUDE-OPTS } }'
1999 Skip the test if the test system is included in SELECTOR and if
2000 each of the options in INCLUDE-OPTS is in the set of options with
2001 which the test would be compiled and if none of the options in
2002 EXCLUDE-OPTS is in the set of options with which the test would be
2005 Use `"*"' for an empty INCLUDE-OPTS list and `""' for an empty
2008 `{ dg-xfail-if COMMENT { SELECTOR } { INCLUDE-OPTS } { EXCLUDE-OPTS } }'
2009 Expect the test to fail if the conditions (which are the same as
2010 for `dg-skip-if') are met.
2012 `{ dg-require-SUPPORT args }'
2013 Skip the test if the target does not provide the required support;
2014 see `gcc-dg.exp' in the GCC testsuite for the actual directives.
2015 These directives must appear after any `dg-do' directive in the
2016 test. They require at least one argument, which can be an empty
2017 string if the specific procedure does not examine the argument.
2019 `{ dg-require-effective-target KEYWORD }'
2020 Skip the test if the test target, including current multilib flags,
2021 is not covered by the effective-target keyword. This directive
2022 must appear after any `dg-do' directive in the test.
2024 `{ dg-shouldfail COMMENT { SELECTOR } { INCLUDE-OPTS } { EXCLUDE-OPTS } }'
2025 Expect the test executable to return a nonzero exit status if the
2026 conditions (which are the same as for `dg-skip-if') are met.
2028 `{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
2029 This DejaGnu directive appears on a source line that is expected
2030 to get an error message, or else specifies the source line
2031 associated with the message. If there is no message for that line
2032 or if the text of that message is not matched by REGEXP then the
2033 check fails and COMMENT is included in the `FAIL' message. The
2034 check does not look for the string `"error"' unless it is part of
2037 `{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
2038 This DejaGnu directive appears on a source line that is expected
2039 to get a warning message, or else specifies the source line
2040 associated with the message. If there is no message for that line
2041 or if the text of that message is not matched by REGEXP then the
2042 check fails and COMMENT is included in the `FAIL' message. The
2043 check does not look for the string `"warning"' unless it is part
2046 `{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
2047 This DejaGnu directive appears on a source line that should not
2048 get a message matching REGEXP, or else specifies the source line
2049 associated with the bogus message. It is usually used with `xfail'
2050 to indicate that the message is a known problem for a particular
2053 `{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }'
2054 This DejaGnu directive indicates that the test is expected to fail
2055 due to compiler messages that are not handled by `dg-error',
2056 `dg-warning' or `dg-bogus'.
2058 `{ dg-output REGEXP [{ target/xfail SELECTOR }] }'
2059 This DejaGnu directive compares REGEXP to the combined output that
2060 the test executable writes to `stdout' and `stderr'.
2062 `{ dg-prune-output REGEXP }'
2063 Prune messages matching REGEXP from test output.
2065 `{ dg-additional-files "FILELIST" }'
2066 Specify additional files, other than source files, that must be
2067 copied to the system where the compiler runs.
2069 `{ dg-additional-sources "FILELIST" }'
2070 Specify additional source files to appear in the compile line
2071 following the main test file.
2073 `{ dg-final { LOCAL-DIRECTIVE } }'
2074 This DejaGnu directive is placed within a comment anywhere in the
2075 source file and is processed after the test has been compiled and
2076 run. Multiple `dg-final' commands are processed in the order in
2077 which they appear in the source file.
2079 The GCC testsuite defines the following directives to be used
2082 `cleanup-coverage-files'
2083 Removes coverage data files generated for this test.
2085 `cleanup-repo-files'
2086 Removes files generated for this test for `-frepo'.
2088 `cleanup-rtl-dump SUFFIX'
2089 Removes RTL dump files generated for this test.
2091 `cleanup-tree-dump SUFFIX'
2092 Removes tree dump files matching SUFFIX which were generated
2095 `cleanup-saved-temps'
2096 Removes files for the current test which were kept for
2099 `scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]'
2100 Passes if REGEXP matches text in FILENAME.
2102 `scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]'
2103 Passes if REGEXP does not match text in FILENAME.
2105 `scan-hidden SYMBOL [{ target/xfail SELECTOR }]'
2106 Passes if SYMBOL is defined as a hidden symbol in the test's
2109 `scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]'
2110 Passes if SYMBOL is not defined as a hidden symbol in the
2111 test's assembly output.
2113 `scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]'
2114 Passes if REGEX is matched exactly NUM times in the test's
2117 `scan-assembler REGEX [{ target/xfail SELECTOR }]'
2118 Passes if REGEX matches text in the test's assembler output.
2120 `scan-assembler-not REGEX [{ target/xfail SELECTOR }]'
2121 Passes if REGEX does not match text in the test's assembler
2124 `scan-assembler-dem REGEX [{ target/xfail SELECTOR }]'
2125 Passes if REGEX matches text in the test's demangled
2128 `scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]'
2129 Passes if REGEX does not match text in the test's demangled
2132 `scan-tree-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]'
2133 Passes if REGEX is found exactly NUM times in the dump file
2136 `scan-tree-dump REGEX SUFFIX [{ target/xfail SELECTOR }]'
2137 Passes if REGEX matches text in the dump file with suffix
2140 `scan-tree-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]'
2141 Passes if REGEX does not match text in the dump file with
2144 `scan-tree-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]'
2145 Passes if REGEX matches demangled text in the dump file with
2148 `scan-tree-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]'
2149 Passes if REGEX does not match demangled text in the dump
2150 file with suffix SUFFIX.
2152 `output-exists [{ target/xfail SELECTOR }]'
2153 Passes if compiler output file exists.
2155 `output-exists-not [{ target/xfail SELECTOR }]'
2156 Passes if compiler output file does not exist.
2158 `run-gcov SOURCEFILE'
2159 Check line counts in `gcov' tests.
2161 `run-gcov [branches] [calls] { OPTS SOURCEFILE }'
2162 Check branch and/or call counts, in addition to line counts,
2166 File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites
2168 6.4.3 Ada Language Testsuites
2169 -----------------------------
2171 The Ada testsuite includes executable tests from the ACATS 2.5
2172 testsuite, publicly available at
2173 `http://www.adaic.org/compilers/acats/2.5'
2175 These tests are integrated in the GCC testsuite in the
2176 `gcc/testsuite/ada/acats' directory, and enabled automatically when
2177 running `make check', assuming the Ada language has been enabled when
2180 You can also run the Ada testsuite independently, using `make
2181 check-ada', or run a subset of the tests by specifying which chapter to
2184 $ make check-ada CHAPTERS="c3 c9"
2186 The tests are organized by directory, each directory corresponding to
2187 a chapter of the Ada Reference Manual. So for example, c9 corresponds
2188 to chapter 9, which deals with tasking features of the language.
2190 There is also an extra chapter called `gcc' containing a template for
2191 creating new executable tests.
2193 The tests are run using two `sh' scripts: `run_acats' and
2194 `run_all.sh'. To run the tests using a simulator or a cross target,
2195 see the small customization section at the top of `run_all.sh'.
2197 These tests are run using the build tree: they can be run without doing
2201 File: gccint.info, Node: C Tests, Next: libgcj Tests, Prev: Ada Tests, Up: Testsuites
2203 6.4.4 C Language Testsuites
2204 ---------------------------
2206 GCC contains the following C language testsuites, in the
2207 `gcc/testsuite' directory:
2210 This contains tests of particular features of the C compiler,
2211 using the more modern `dg' harness. Correctness tests for various
2212 compiler features should go here if possible.
2214 Magic comments determine whether the file is preprocessed,
2215 compiled, linked or run. In these tests, error and warning
2216 message texts are compared against expected texts or regular
2217 expressions given in comments. These tests are run with the
2218 options `-ansi -pedantic' unless other options are given in the
2219 test. Except as noted below they are not run with multiple
2220 optimization options.
2223 This subdirectory contains tests for binary compatibility using
2224 `compat.exp', which in turn uses the language-independent support
2225 (*note Support for testing binary compatibility: compat Testing.).
2228 This subdirectory contains tests of the preprocessor.
2231 This subdirectory contains tests for debug formats. Tests in this
2232 subdirectory are run for each debug format that the compiler
2236 This subdirectory contains tests of the `-Wformat' format
2237 checking. Tests in this directory are run with and without
2241 This subdirectory contains tests of code that should not compile
2242 and does not need any special compilation options. They are run
2243 with multiple optimization options, since sometimes invalid code
2244 crashes the compiler with optimization.
2247 FIXME: describe this.
2250 This contains particular code fragments which have historically
2251 broken easily. These tests are run with multiple optimization
2252 options, so tests for features which only break at some
2253 optimization levels belong here. This also contains tests to
2254 check that certain optimizations occur. It might be worthwhile to
2255 separate the correctness tests cleanly from the code quality
2256 tests, but it hasn't been done yet.
2258 `gcc.c-torture/compat'
2259 FIXME: describe this.
2261 This directory should probably not be used for new tests.
2263 `gcc.c-torture/compile'
2264 This testsuite contains test cases that should compile, but do not
2265 need to link or run. These test cases are compiled with several
2266 different combinations of optimization options. All warnings are
2267 disabled for these test cases, so this directory is not suitable if
2268 you wish to test for the presence or absence of compiler warnings.
2269 While special options can be set, and tests disabled on specific
2270 platforms, by the use of `.x' files, mostly these test cases
2271 should not contain platform dependencies. FIXME: discuss how
2272 defines such as `NO_LABEL_VALUES' and `STACK_SIZE' are used.
2274 `gcc.c-torture/execute'
2275 This testsuite contains test cases that should compile, link and
2276 run; otherwise the same comments as for `gcc.c-torture/compile'
2279 `gcc.c-torture/execute/ieee'
2280 This contains tests which are specific to IEEE floating point.
2282 `gcc.c-torture/unsorted'
2283 FIXME: describe this.
2285 This directory should probably not be used for new tests.
2287 `gcc.c-torture/misc-tests'
2288 This directory contains C tests that require special handling.
2289 Some of these tests have individual expect files, and others share
2290 special-purpose expect files:
2293 Test `-fbranch-probabilities' using `bprob.exp', which in
2294 turn uses the generic, language-independent framework (*note
2295 Support for testing profile-directed optimizations: profopt
2299 Test the testsuite itself using `dg-test.exp'.
2302 Test `gcov' output using `gcov.exp', which in turn uses the
2303 language-independent support (*note Support for testing gcov:
2307 Test i386-specific support for data prefetch using
2308 `i386-prefetch.exp'.
2311 FIXME: merge in `testsuite/README.gcc' and discuss the format of test
2312 cases and magic comments more.
2315 File: gccint.info, Node: libgcj Tests, Next: gcov Testing, Prev: C Tests, Up: Testsuites
2317 6.4.5 The Java library testsuites.
2318 ----------------------------------
2320 Runtime tests are executed via `make check' in the
2321 `TARGET/libjava/testsuite' directory in the build tree. Additional
2322 runtime tests can be checked into this testsuite.
2324 Regression testing of the core packages in libgcj is also covered by
2325 the Mauve testsuite. The Mauve Project develops tests for the Java
2326 Class Libraries. These tests are run as part of libgcj testing by
2327 placing the Mauve tree within the libjava testsuite sources at
2328 `libjava/testsuite/libjava.mauve/mauve', or by specifying the location
2329 of that tree when invoking `make', as in `make MAUVEDIR=~/mauve check'.
2331 To detect regressions, a mechanism in `mauve.exp' compares the
2332 failures for a test run against the list of expected failures in
2333 `libjava/testsuite/libjava.mauve/xfails' from the source hierarchy.
2334 Update this file when adding new failing tests to Mauve, or when fixing
2335 bugs in libgcj that had caused Mauve test failures.
2337 The Jacks project provides a testsuite for Java compilers that can be
2338 used to test changes that affect the GCJ front end. This testsuite is
2339 run as part of Java testing by placing the Jacks tree within the libjava
2340 testsuite sources at `libjava/testsuite/libjava.jacks/jacks'.
2342 We encourage developers to contribute test cases to Mauve and Jacks.
2345 File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: libgcj Tests, Up: Testsuites
2347 6.4.6 Support for testing `gcov'
2348 --------------------------------
2350 Language-independent support for testing `gcov', and for checking that
2351 branch profiling produces expected values, is provided by the expect
2352 file `gcov.exp'. `gcov' tests also rely on procedures in `gcc.dg.exp'
2353 to compile and run the test program. A typical `gcov' test contains
2354 the following DejaGnu commands within comments:
2356 { dg-options "-fprofile-arcs -ftest-coverage" }
2357 { dg-do run { target native } }
2358 { dg-final { run-gcov sourcefile } }
2360 Checks of `gcov' output can include line counts, branch percentages,
2361 and call return percentages. All of these checks are requested via
2362 commands that appear in comments in the test's source file. Commands
2363 to check line counts are processed by default. Commands to check
2364 branch percentages and call return percentages are processed if the
2365 `run-gcov' command has arguments `branches' or `calls', respectively.
2366 For example, the following specifies checking both, as well as passing
2369 { dg-final { run-gcov branches calls { -b sourcefile } } }
2371 A line count command appears within a comment on the source line that
2372 is expected to get the specified count and has the form `count(CNT)'.
2373 A test should only check line counts for lines that will get the same
2374 count for any architecture.
2376 Commands to check branch percentages (`branch') and call return
2377 percentages (`returns') are very similar to each other. A beginning
2378 command appears on or before the first of a range of lines that will
2379 report the percentage, and the ending command follows that range of
2380 lines. The beginning command can include a list of percentages, all of
2381 which are expected to be found within the range. A range is terminated
2382 by the next command of the same kind. A command `branch(end)' or
2383 `returns(end)' marks the end of a range without starting a new one.
2386 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */
2390 For a call return percentage, the value specified is the percentage of
2391 calls reported to return. For a branch percentage, the value is either
2392 the expected percentage or 100 minus that value, since the direction of
2393 a branch can differ depending on the target or the optimization level.
2395 Not all branches and calls need to be checked. A test should not
2396 check for branches that might be optimized away or replaced with
2397 predicated instructions. Don't check for calls inserted by the
2398 compiler or ones that might be inlined or optimized away.
2400 A single test can check for combinations of line counts, branch
2401 percentages, and call return percentages. The command to check a line
2402 count must appear on the line that will report that count, but commands
2403 to check branch percentages and call return percentages can bracket the
2404 lines that report them.
2407 File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites
2409 6.4.7 Support for testing profile-directed optimizations
2410 --------------------------------------------------------
2412 The file `profopt.exp' provides language-independent support for
2413 checking correct execution of a test built with profile-directed
2414 optimization. This testing requires that a test program be built and
2415 executed twice. The first time it is compiled to generate profile
2416 data, and the second time it is compiled to use the data that was
2417 generated during the first execution. The second execution is to
2418 verify that the test produces the expected results.
2420 To check that the optimization actually generated better code, a test
2421 can be built and run a third time with normal optimizations to verify
2422 that the performance is better with the profile-directed optimizations.
2423 `profopt.exp' has the beginnings of this kind of support.
2425 `profopt.exp' provides generic support for profile-directed
2426 optimizations. Each set of tests that uses it provides information
2427 about a specific optimization:
2430 tool being tested, e.g., `gcc'
2433 options used to generate profile data
2436 options used to optimize using that profile data
2439 suffix of profile data files
2442 list of options with which to run each test, similar to the lists
2446 File: gccint.info, Node: compat Testing, Prev: profopt Testing, Up: Testsuites
2448 6.4.8 Support for testing binary compatibility
2449 ----------------------------------------------
2451 The file `compat.exp' provides language-independent support for binary
2452 compatibility testing. It supports testing interoperability of two
2453 compilers that follow the same ABI, or of multiple sets of compiler
2454 options that should not affect binary compatibility. It is intended to
2455 be used for testsuites that complement ABI testsuites.
2457 A test supported by this framework has three parts, each in a separate
2458 source file: a main program and two pieces that interact with each
2459 other to split up the functionality being tested.
2461 `TESTNAME_main.SUFFIX'
2462 Contains the main program, which calls a function in file
2463 `TESTNAME_x.SUFFIX'.
2466 Contains at least one call to a function in `TESTNAME_y.SUFFIX'.
2469 Shares data with, or gets arguments from, `TESTNAME_x.SUFFIX'.
2471 Within each test, the main program and one functional piece are
2472 compiled by the GCC under test. The other piece can be compiled by an
2473 alternate compiler. If no alternate compiler is specified, then all
2474 three source files are all compiled by the GCC under test. You can
2475 specify pairs of sets of compiler options. The first element of such a
2476 pair specifies options used with the GCC under test, and the second
2477 element of the pair specifies options used with the alternate compiler.
2478 Each test is compiled with each pair of options.
2480 `compat.exp' defines default pairs of compiler options. These can be
2481 overridden by defining the environment variable `COMPAT_OPTIONS' as:
2483 COMPAT_OPTIONS="[list [list {TST1} {ALT1}]
2484 ...[list {TSTN} {ALTN}]]"
2486 where TSTI and ALTI are lists of options, with TSTI used by the
2487 compiler under test and ALTI used by the alternate compiler. For
2488 example, with `[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]',
2489 the test is first built with `-g -O0' by the compiler under test and
2490 with `-O3' by the alternate compiler. The test is built a second time
2491 using `-fpic' by the compiler under test and `-fPIC -O2' by the
2494 An alternate compiler is specified by defining an environment variable
2495 to be the full pathname of an installed compiler; for C define
2496 `ALT_CC_UNDER_TEST', and for C++ define `ALT_CXX_UNDER_TEST'. These
2497 will be written to the `site.exp' file used by DejaGnu. The default is
2498 to build each test with the compiler under test using the first of each
2499 pair of compiler options from `COMPAT_OPTIONS'. When
2500 `ALT_CC_UNDER_TEST' or `ALT_CXX_UNDER_TEST' is `same', each test is
2501 built using the compiler under test but with combinations of the
2502 options from `COMPAT_OPTIONS'.
2504 To run only the C++ compatibility suite using the compiler under test
2505 and another version of GCC using specific compiler options, do the
2506 following from `OBJDIR/gcc':
2510 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \
2511 COMPAT_OPTIONS="lists as shown above" \
2513 RUNTESTFLAGS="compat.exp"
2515 A test that fails when the source files are compiled with different
2516 compilers, but passes when the files are compiled with the same
2517 compiler, demonstrates incompatibility of the generated code or runtime
2518 support. A test that fails for the alternate compiler but passes for
2519 the compiler under test probably tests for a bug that was fixed in the
2520 compiler under test but is present in the alternate compiler.
2522 The binary compatibility tests support a small number of test framework
2523 commands that appear within comments in a test file.
2526 These commands can be used in `TESTNAME_main.SUFFIX' to skip the
2527 test if specific support is not available on the target.
2530 The specified options are used for compiling this particular source
2531 file, appended to the options from `COMPAT_OPTIONS'. When this
2532 command appears in `TESTNAME_main.SUFFIX' the options are also
2533 used to link the test program.
2536 This command can be used in a secondary source file to specify that
2537 compilation is expected to fail for particular options on
2541 File: gccint.info, Node: Options, Next: Passes, Prev: Source Tree, Up: Top
2543 7 Option specification files
2544 ****************************
2546 Most GCC command-line options are described by special option
2547 definition files, the names of which conventionally end in `.opt'.
2548 This chapter describes the format of these files.
2552 * Option file format:: The general layout of the files
2553 * Option properties:: Supported option properties
2556 File: gccint.info, Node: Option file format, Next: Option properties, Up: Options
2558 7.1 Option file format
2559 ======================
2561 Option files are a simple list of records in which each field occupies
2562 its own line and in which the records themselves are separated by blank
2563 lines. Comments may appear on their own line anywhere within the file
2564 and are preceded by semicolons. Whitespace is allowed before the
2567 The files can contain the following types of record:
2569 * A language definition record. These records have two fields: the
2570 string `Language' and the name of the language. Once a language
2571 has been declared in this way, it can be used as an option
2572 property. *Note Option properties::.
2574 * An option definition record. These records have the following
2577 1. the name of the option, with the leading "-" removed
2579 2. a space-separated list of option properties (*note Option
2582 3. the help text to use for `--help' (omitted if the second field
2583 contains the `Undocumented' property).
2585 By default, all options beginning with "f", "W" or "m" are
2586 implicitly assumed to take a "no-" form. This form should not be
2587 listed separately. If an option beginning with one of these
2588 letters does not have a "no-" form, you can use the
2589 `RejectNegative' property to reject it.
2591 The help text is automatically line-wrapped before being displayed.
2592 Normally the name of the option is printed on the left-hand side of
2593 the output and the help text is printed on the right. However, if
2594 the help text contains a tab character, the text to the left of
2595 the tab is used instead of the option's name and the text to the
2596 right of the tab forms the help text. This allows you to
2597 elaborate on what type of argument the option takes.
2599 * A target mask record. These records have one field of the form
2600 `Mask(X)'. The options-processing script will automatically
2601 allocate a bit in `target_flags' (*note Run-time Target::) for
2602 each mask name X and set the macro `MASK_X' to the appropriate
2603 bitmask. It will also declare a `TARGET_X' macro that has the
2604 value 1 when bit `MASK_X' is set and 0 otherwise.
2606 They are primarily intended to declare target masks that are not
2607 associated with user options, either because these masks represent
2608 internal switches or because the options are not available on all
2609 configurations and yet the masks always need to be defined.
2612 File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options
2614 7.2 Option properties
2615 =====================
2617 The second field of an option record can specify the following
2621 The option is available for all languages and targets.
2624 The option is available for all languages but is target-specific.
2627 The option is available when compiling for the given language.
2629 It is possible to specify several different languages for the same
2630 option. Each LANGUAGE must have been declared by an earlier
2631 `Language' record. *Note Option file format::.
2634 The option does not have a "no-" form. All options beginning with
2635 "f", "W" or "m" are assumed to have a "no-" form unless this
2640 The option takes a mandatory argument. `Joined' indicates that
2641 the option and argument can be included in the same `argv' entry
2642 (as with `-mflush-func=NAME', for example). `Separate' indicates
2643 that the option and argument can be separate `argv' entries (as
2644 with `-o'). An option is allowed to have both of these properties.
2647 The option takes an optional argument. If the argument is given,
2648 it will be part of the same `argv' entry as the option itself.
2650 This property cannot be used alongside `Joined' or `Separate'.
2653 The option's argument is a non-negative integer. The option parser
2654 will check and convert the argument before passing it to the
2655 relevant option handler.
2658 The state of this option should be stored in variable VAR. The
2659 way that the state is stored depends on the type of option:
2661 * If the option uses the `Mask' or `InverseMask' properties,
2662 VAR is the integer variable that contains the mask.
2664 * If the option is a normal on/off switch, VAR is an integer
2665 variable that is nonzero when the option is enabled. The
2666 options parser will set the variable to 1 when the positive
2667 form of the option is used and 0 when the "no-" form is used.
2669 * If the option takes an argument and has the `UInteger'
2670 property, VAR is an integer variable that stores the value of
2673 * Otherwise, if the option takes an argument, VAR is a pointer
2674 to the argument string. The pointer will be null if the
2675 argument is optional and wasn't given.
2677 The option-processing script will usually declare VAR in
2678 `options.c' and leave it to be zero-initialized at start-up time.
2679 You can modify this behavior using `VarExists' and `Init'.
2682 The option controls an integer variable VAR and is active when VAR
2683 equals SET. The option parser will set VAR to SET when the
2684 positive form of the option is used and `!SET' when the "no-" form
2687 VAR is declared in the same way as for the single-argument form
2691 The variable specified by the `Var' property already exists. No
2692 definition should be added to `options.c' in response to this
2695 You should use this property if an earlier option has already
2696 declared the variable or if the variable is declared outside
2700 The variable specified by the `Var' property should be statically
2701 initialized to VALUE.
2704 The option is associated with a bit in the `target_flags' variable
2705 (*note Run-time Target::) and is active when that bit is set. You
2706 may also specify `Var' to select a variable other than
2709 The options-processing script will automatically allocate a unique
2710 bit for the option. If the option is attached to `target_flags',
2711 the script will set the macro `MASK_NAME' to the appropriate
2712 bitmask. It will also declare a `TARGET_NAME' macro that has the
2713 value 1 when the option is active and 0 otherwise. If you use
2714 `Var' to attach the option to a different variable, the associated
2715 macros are called `OPTION_MASK_NAME' and `OPTION_NAME'
2718 You can disable automatic bit allocation using `MaskExists'.
2720 `InverseMask(OTHERNAME)'
2721 `InverseMask(OTHERNAME, THISNAME)'
2722 The option is the inverse of another option that has the
2723 `Mask(OTHERNAME)' property. If THISNAME is given, the
2724 options-processing script will declare a `TARGET_THISNAME' macro
2725 that is 1 when the option is active and 0 otherwise.
2728 The mask specified by the `Mask' property already exists. No
2729 `MASK' or `TARGET' definitions should be added to `options.h' in
2730 response to this option record.
2732 The main purpose of this property is to support synonymous options.
2733 The first option should use `Mask(NAME)' and the others should use
2734 `Mask(NAME) MaskExists'.
2737 The state of the option should be printed by `-fverbose-asm'.
2740 The option is deliberately missing documentation and should not be
2741 included in the `--help' output.
2744 The option should only be accepted if preprocessor condition COND
2745 is true. Note that any C declarations associated with the option
2746 will be present even if COND is false; COND simply controls
2747 whether the option is accepted and whether it is printed in the
2751 File: gccint.info, Node: Passes, Next: Trees, Prev: Options, Up: Top
2753 8 Passes and Files of the Compiler
2754 **********************************
2756 This chapter is dedicated to giving an overview of the optimization and
2757 code generation passes of the compiler. In the process, it describes
2758 some of the language front end interface, though this description is no
2759 where near complete.
2763 * Parsing pass:: The language front end turns text into bits.
2764 * Gimplification pass:: The bits are turned into something we can optimize.
2765 * Pass manager:: Sequencing the optimization passes.
2766 * Tree-SSA passes:: Optimizations on a high-level representation.
2767 * RTL passes:: Optimizations on a low-level representation.
2770 File: gccint.info, Node: Parsing pass, Next: Gimplification pass, Up: Passes
2775 The language front end is invoked only once, via
2776 `lang_hooks.parse_file', to parse the entire input. The language front
2777 end may use any intermediate language representation deemed
2778 appropriate. The C front end uses GENERIC trees (CROSSREF), plus a
2779 double handful of language specific tree codes defined in
2780 `c-common.def'. The Fortran front end uses a completely different
2781 private representation.
2783 At some point the front end must translate the representation used in
2784 the front end to a representation understood by the language-independent
2785 portions of the compiler. Current practice takes one of two forms.
2786 The C front end manually invokes the gimplifier (CROSSREF) on each
2787 function, and uses the gimplifier callbacks to convert the
2788 language-specific tree nodes directly to GIMPLE (CROSSREF) before
2789 passing the function off to be compiled. The Fortran front end
2790 converts from a private representation to GENERIC, which is later
2791 lowered to GIMPLE when the function is compiled. Which route to choose
2792 probably depends on how well GENERIC (plus extensions) can be made to
2793 match up with the source language and necessary parsing data structures.
2795 BUG: Gimplification must occur before nested function lowering, and
2796 nested function lowering must be done by the front end before passing
2797 the data off to cgraph.
2799 TODO: Cgraph should control nested function lowering. It would only
2800 be invoked when it is certain that the outer-most function is used.
2802 TODO: Cgraph needs a gimplify_function callback. It should be invoked
2803 when (1) it is certain that the function is used, (2) warning flags
2804 specified by the user require some amount of compilation in order to
2805 honor, (3) the language indicates that semantic analysis is not
2806 complete until gimplification occurs. Hum... this sounds overly
2807 complicated. Perhaps we should just have the front end gimplify
2808 always; in most cases it's only one function call.
2810 The front end needs to pass all function definitions and top level
2811 declarations off to the middle-end so that they can be compiled and
2812 emitted to the object file. For a simple procedural language, it is
2813 usually most convenient to do this as each top level declaration or
2814 definition is seen. There is also a distinction to be made between
2815 generating functional code and generating complete debug information.
2816 The only thing that is absolutely required for functional code is that
2817 function and data _definitions_ be passed to the middle-end. For
2818 complete debug information, function, data and type declarations should
2819 all be passed as well.
2821 In any case, the front end needs each complete top-level function or
2822 data declaration, and each data definition should be passed to
2823 `rest_of_decl_compilation'. Each complete type definition should be
2824 passed to `rest_of_type_compilation'. Each function definition should
2825 be passed to `cgraph_finalize_function'.
2827 TODO: I know rest_of_compilation currently has all sorts of
2828 rtl-generation semantics. I plan to move all code generation bits
2829 (both tree and rtl) to compile_function. Should we hide cgraph from
2830 the front ends and move back to rest_of_compilation as the official
2831 interface? Possibly we should rename all three interfaces such that
2832 the names match in some meaningful way and that is more descriptive
2835 The middle-end will, at its option, emit the function and data
2836 definitions immediately or queue them for later processing.
2839 File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Parsing pass, Up: Passes
2841 8.2 Gimplification pass
2842 =======================
2844 "Gimplification" is a whimsical term for the process of converting the
2845 intermediate representation of a function into the GIMPLE language
2846 (CROSSREF). The term stuck, and so words like "gimplification",
2847 "gimplify", "gimplifier" and the like are sprinkled throughout this
2850 While a front end may certainly choose to generate GIMPLE directly if
2851 it chooses, this can be a moderately complex process unless the
2852 intermediate language used by the front end is already fairly simple.
2853 Usually it is easier to generate GENERIC trees plus extensions and let
2854 the language-independent gimplifier do most of the work.
2856 The main entry point to this pass is `gimplify_function_tree' located
2857 in `gimplify.c'. From here we process the entire function gimplifying
2858 each statement in turn. The main workhorse for this pass is
2859 `gimplify_expr'. Approximately everything passes through here at least
2860 once, and it is from here that we invoke the `lang_hooks.gimplify_expr'
2863 The callback should examine the expression in question and return
2864 `GS_UNHANDLED' if the expression is not a language specific construct
2865 that requires attention. Otherwise it should alter the expression in
2866 some way to such that forward progress is made toward producing valid
2867 GIMPLE. If the callback is certain that the transformation is complete
2868 and the expression is valid GIMPLE, it should return `GS_ALL_DONE'.
2869 Otherwise it should return `GS_OK', which will cause the expression to
2870 be processed again. If the callback encounters an error during the
2871 transformation (because the front end is relying on the gimplification
2872 process to finish semantic checks), it should return `GS_ERROR'.
2875 File: gccint.info, Node: Pass manager, Next: Tree-SSA passes, Prev: Gimplification pass, Up: Passes
2880 The pass manager is located in `passes.c', `tree-optimize.c' and
2881 `tree-pass.h'. Its job is to run all of the individual passes in the
2882 correct order, and take care of standard bookkeeping that applies to
2885 The theory of operation is that each pass defines a structure that
2886 represents everything we need to know about that pass--when it should
2887 be run, how it should be run, what intermediate language form or
2888 on-the-side data structures it needs. We register the pass to be run
2889 in some particular order, and the pass manager arranges for everything
2890 to happen in the correct order.
2892 The actuality doesn't completely live up to the theory at present.
2893 Command-line switches and `timevar_id_t' enumerations must still be
2894 defined elsewhere. The pass manager validates constraints but does not
2895 attempt to (re-)generate data structures or lower intermediate language
2896 form based on the requirements of the next pass. Nevertheless, what is
2897 present is useful, and a far sight better than nothing at all.
2899 TODO: describe the global variables set up by the pass manager, and a
2900 brief description of how a new pass should use it. I need to look at
2901 what info rtl passes use first...
2904 File: gccint.info, Node: Tree-SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes
2909 The following briefly describes the tree optimization passes that are
2910 run after gimplification and what source files they are located in.
2912 * Remove useless statements
2914 This pass is an extremely simple sweep across the gimple code in
2915 which we identify obviously dead code and remove it. Here we do
2916 things like simplify `if' statements with constant conditions,
2917 remove exception handling constructs surrounding code that
2918 obviously cannot throw, remove lexical bindings that contain no
2919 variables, and other assorted simplistic cleanups. The idea is to
2920 get rid of the obvious stuff quickly rather than wait until later
2921 when it's more work to get rid of it. This pass is located in
2922 `tree-cfg.c' and described by `pass_remove_useless_stmts'.
2924 * Mudflap declaration registration
2926 If mudflap (*note -fmudflap -fmudflapth -fmudflapir:
2927 (gcc.info)Optimize Options.) is enabled, we generate code to
2928 register some variable declarations with the mudflap runtime.
2929 Specifically, the runtime tracks the lifetimes of those variable
2930 declarations that have their addresses taken, or whose bounds are
2931 unknown at compile time (`extern'). This pass generates new
2932 exception handling constructs (`try'/`finally'), and so must run
2933 before those are lowered. In addition, the pass enqueues
2934 declarations of static variables whose lifetimes extend to the
2935 entire program. The pass is located in `tree-mudflap.c' and is
2936 described by `pass_mudflap_1'.
2938 * Lower control flow
2940 This pass flattens `if' statements (`COND_EXPR') and moves lexical
2941 bindings (`BIND_EXPR') out of line. After this pass, all `if'
2942 statements will have exactly two `goto' statements in its `then'
2943 and `else' arms. Lexical binding information for each statement
2944 will be found in `TREE_BLOCK' rather than being inferred from its
2945 position under a `BIND_EXPR'. This pass is found in
2946 `gimple-low.c' and is described by `pass_lower_cf'.
2948 * Lower exception handling control flow
2950 This pass decomposes high-level exception handling constructs
2951 (`TRY_FINALLY_EXPR' and `TRY_CATCH_EXPR') into a form that
2952 explicitly represents the control flow involved. After this pass,
2953 `lookup_stmt_eh_region' will return a non-negative number for any
2954 statement that may have EH control flow semantics; examine
2955 `tree_can_throw_internal' or `tree_can_throw_external' for exact
2956 semantics. Exact control flow may be extracted from
2957 `foreach_reachable_handler'. The EH region nesting tree is defined
2958 in `except.h' and built in `except.c'. The lowering pass itself
2959 is in `tree-eh.c' and is described by `pass_lower_eh'.
2961 * Build the control flow graph
2963 This pass decomposes a function into basic blocks and creates all
2964 of the edges that connect them. It is located in `tree-cfg.c' and
2965 is described by `pass_build_cfg'.
2967 * Find all referenced variables
2969 This pass walks the entire function and collects an array of all
2970 variables referenced in the function, `referenced_vars'. The
2971 index at which a variable is found in the array is used as a UID
2972 for the variable within this function. This data is needed by the
2973 SSA rewriting routines. The pass is located in `tree-dfa.c' and
2974 is described by `pass_referenced_vars'.
2976 * Enter static single assignment form
2978 This pass rewrites the function such that it is in SSA form. After
2979 this pass, all `is_gimple_reg' variables will be referenced by
2980 `SSA_NAME', and all occurrences of other variables will be
2981 annotated with `VDEFS' and `VUSES'; PHI nodes will have been
2982 inserted as necessary for each basic block. This pass is located
2983 in `tree-ssa.c' and is described by `pass_build_ssa'.
2985 * Warn for uninitialized variables
2987 This pass scans the function for uses of `SSA_NAME's that are fed
2988 by default definition. For non-parameter variables, such uses are
2989 uninitialized. The pass is run twice, before and after
2990 optimization. In the first pass we only warn for uses that are
2991 positively uninitialized; in the second pass we warn for uses that
2992 are possibly uninitialized. The pass is located in `tree-ssa.c'
2993 and is defined by `pass_early_warn_uninitialized' and
2994 `pass_late_warn_uninitialized'.
2996 * Dead code elimination
2998 This pass scans the function for statements without side effects
2999 whose result is unused. It does not do memory life analysis, so
3000 any value that is stored in memory is considered used. The pass
3001 is run multiple times throughout the optimization process. It is
3002 located in `tree-ssa-dce.c' and is described by `pass_dce'.
3004 * Dominator optimizations
3006 This pass performs trivial dominator-based copy and constant
3007 propagation, expression simplification, and jump threading. It is
3008 run multiple times throughout the optimization process. It it
3009 located in `tree-ssa-dom.c' and is described by `pass_dominator'.
3011 * Redundant PHI elimination
3013 This pass removes PHI nodes for which all of the arguments are the
3014 same value, excluding feedback. Such degenerate forms are
3015 typically created by removing unreachable code. The pass is run
3016 multiple times throughout the optimization process. It is located
3017 in `tree-ssa.c' and is described by `pass_redundant_phi'.o
3019 * Forward propagation of single-use variables
3021 This pass attempts to remove redundant computation by substituting
3022 variables that are used once into the expression that uses them and
3023 seeing if the result can be simplified. It is located in
3024 `tree-ssa-forwprop.c' and is described by `pass_forwprop'.
3028 This pass attempts to change the name of compiler temporaries
3029 involved in copy operations such that SSA->normal can coalesce the
3030 copy away. When compiler temporaries are copies of user
3031 variables, it also renames the compiler temporary to the user
3032 variable resulting in better use of user symbols. It is located
3033 in `tree-ssa-copyrename.c' and is described by `pass_copyrename'.
3035 * PHI node optimizations
3037 This pass recognizes forms of PHI inputs that can be represented as
3038 conditional expressions and rewrites them into straight line code.
3039 It is located in `tree-ssa-phiopt.c' and is described by
3042 * May-alias optimization
3044 This pass performs a flow sensitive SSA-based points-to analysis.
3045 The resulting may-alias, must-alias, and escape analysis
3046 information is used to promote variables from in-memory
3047 addressable objects to non-aliased variables that can be renamed
3048 into SSA form. We also update the `VDEF'/`VUSE' memory tags for
3049 non-renameable aggregates so that we get fewer false kills. The
3050 pass is located in `tree-ssa-alias.c' and is described by
3055 This pass rewrites the function in order to collect runtime block
3056 and value profiling data. Such data may be fed back into the
3057 compiler on a subsequent run so as to allow optimization based on
3058 expected execution frequencies. The pass is located in
3059 `predict.c' and is described by `pass_profile'.
3061 * Lower complex arithmetic
3063 This pass rewrites complex arithmetic operations into their
3064 component scalar arithmetic operations. The pass is located in
3065 `tree-complex.c' and is described by `pass_lower_complex'.
3067 * Scalar replacement of aggregates
3069 This pass rewrites suitable non-aliased local aggregate variables
3070 into a set of scalar variables. The resulting scalar variables are
3071 rewritten into SSA form, which allows subsequent optimization
3072 passes to do a significantly better job with them. The pass is
3073 located in `tree-sra.c' and is described by `pass_sra'.
3075 * Dead store elimination
3077 This pass eliminates stores to memory that are subsequently
3078 overwritten by another store, without any intervening loads. The
3079 pass is located in `tree-ssa-dse.c' and is described by `pass_dse'.
3081 * Tail recursion elimination
3083 This pass transforms tail recursion into a loop. It is located in
3084 `tree-tailcall.c' and is described by `pass_tail_recursion'.
3086 * Forward store motion
3088 This pass sinks stores and assignments down the flowgraph closer
3089 to it's use point. The pass is located in `tree-ssa-sink.c' and is
3090 described by `pass_sink_code'.
3092 * Partial redundancy elimination
3094 This pass eliminates partially redundant computations, as well as
3095 performing load motion. The pass is located in `tree-ssa-pre.c'
3096 and is described by `pass_pre'.
3098 Just before partial redundancy elimination, if
3099 `-funsafe-math-optimizations' is on, GCC tries to convert
3100 divisions to multiplications by the reciprocal. The pass is
3101 located in `tree-ssa-math-opts.c' and is described by
3102 `pass_cse_reciprocal'.
3104 * Full redundancy elimination
3106 This is a simpler form of PRE that only eliminate redundancies that
3107 occur an all paths. It is located in `tree-ssa-pre.c' and
3108 described by `pass_fre'.
3112 The main driver of the pass is placed in `tree-ssa-loop.c' and
3113 described by `pass_loop'.
3115 The optimizations performed by this pass are:
3117 Loop invariant motion. This pass moves only invariants that would
3118 be hard to handle on rtl level (function calls, operations that
3119 expand to nontrivial sequences of insns). With `-funswitch-loops'
3120 it also moves operands of conditions that are invariant out of the
3121 loop, so that we can use just trivial invariantness analysis in
3122 loop unswitching. The pass also includes store motion. The pass
3123 is implemented in `tree-ssa-loop-im.c'.
3125 Canonical induction variable creation. This pass creates a simple
3126 counter for number of iterations of the loop and replaces the exit
3127 condition of the loop using it, in case when a complicated
3128 analysis is necessary to determine the number of iterations.
3129 Later optimizations then may determine the number easily. The
3130 pass is implemented in `tree-ssa-loop-ivcanon.c'.
3132 Induction variable optimizations. This pass performs standard
3133 induction variable optimizations, including strength reduction,
3134 induction variable merging and induction variable elimination.
3135 The pass is implemented in `tree-ssa-loop-ivopts.c'.
3137 Loop unswitching. This pass moves the conditional jumps that are
3138 invariant out of the loops. To achieve this, a duplicate of the
3139 loop is created for each possible outcome of conditional jump(s).
3140 The pass is implemented in `tree-ssa-loop-unswitch.c'. This pass
3141 should eventually replace the rtl-level loop unswitching in
3142 `loop-unswitch.c', but currently the rtl-level pass is not
3143 completely redundant yet due to deficiencies in tree level alias
3146 The optimizations also use various utility functions contained in
3147 `tree-ssa-loop-manip.c', `cfgloop.c', `cfgloopanal.c' and
3150 Vectorization. This pass transforms loops to operate on vector
3151 types instead of scalar types. Data parallelism across loop
3152 iterations is exploited to group data elements from consecutive
3153 iterations into a vector and operate on them in parallel.
3154 Depending on available target support the loop is conceptually
3155 unrolled by a factor `VF' (vectorization factor), which is the
3156 number of elements operated upon in parallel in each iteration,
3157 and the `VF' copies of each scalar operation are fused to form a
3158 vector operation. Additional loop transformations such as peeling
3159 and versioning may take place to align the number of iterations,
3160 and to align the memory accesses in the loop. The pass is
3161 implemented in `tree-vectorizer.c' (the main driver and general
3162 utilities), `tree-vect-analyze.c' and `tree-vect-transform.c'.
3163 Analysis of data references is in `tree-data-ref.c'.
3165 * Tree level if-conversion for vectorizer
3167 This pass applies if-conversion to simple loops to help vectorizer.
3168 We identify if convertible loops, if-convert statements and merge
3169 basic blocks in one big block. The idea is to present loop in such
3170 form so that vectorizer can have one to one mapping between
3171 statements and available vector operations. This patch
3172 re-introduces COND_EXPR at GIMPLE level. This pass is located in
3173 `tree-if-conv.c' and is described by `pass_if_conversion'.
3175 * Conditional constant propagation
3177 This pass relaxes a lattice of values in order to identify those
3178 that must be constant even in the presence of conditional branches.
3179 The pass is located in `tree-ssa-ccp.c' and is described by
3182 A related pass that works on memory loads and stores, and not just
3183 register values, is located in `tree-ssa-ccp.c' and described by
3186 * Conditional copy propagation
3188 This is similar to constant propagation but the lattice of values
3189 is the "copy-of" relation. It eliminates redundant copies from the
3190 code. The pass is located in `tree-ssa-copy.c' and described by
3193 A related pass that works on memory copies, and not just register
3194 copies, is located in `tree-ssa-copy.c' and described by
3195 `pass_store_copy_prop'.
3197 * Value range propagation
3199 This transformation is similar to constant propagation but instead
3200 of propagating single constant values, it propagates known value
3201 ranges. The implementation is based on Patterson's range
3202 propagation algorithm (Accurate Static Branch Prediction by Value
3203 Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to
3204 Patterson's algorithm, this implementation does not propagate
3205 branch probabilities nor it uses more than a single range per SSA
3206 name. This means that the current implementation cannot be used
3207 for branch prediction (though adapting it would not be difficult).
3208 The pass is located in `tree-vrp.c' and is described by
3211 * Folding built-in functions
3213 This pass simplifies built-in functions, as applicable, with
3214 constant arguments or with inferrable string lengths. It is
3215 located in `tree-ssa-ccp.c' and is described by
3216 `pass_fold_builtins'.
3218 * Split critical edges
3220 This pass identifies critical edges and inserts empty basic blocks
3221 such that the edge is no longer critical. The pass is located in
3222 `tree-cfg.c' and is described by `pass_split_crit_edges'.
3224 * Control dependence dead code elimination
3226 This pass is a stronger form of dead code elimination that can
3227 eliminate unnecessary control flow statements. It is located in
3228 `tree-ssa-dce.c' and is described by `pass_cd_dce'.
3230 * Tail call elimination
3232 This pass identifies function calls that may be rewritten into
3233 jumps. No code transformation is actually applied here, but the
3234 data and control flow problem is solved. The code transformation
3235 requires target support, and so is delayed until RTL. In the
3236 meantime `CALL_EXPR_TAILCALL' is set indicating the possibility.
3237 The pass is located in `tree-tailcall.c' and is described by
3238 `pass_tail_calls'. The RTL transformation is handled by
3239 `fixup_tail_calls' in `calls.c'.
3241 * Warn for function return without value
3243 For non-void functions, this pass locates return statements that do
3244 not specify a value and issues a warning. Such a statement may
3245 have been injected by falling off the end of the function. This
3246 pass is run last so that we have as much time as possible to prove
3247 that the statement is not reachable. It is located in
3248 `tree-cfg.c' and is described by `pass_warn_function_return'.
3250 * Mudflap statement annotation
3252 If mudflap is enabled, we rewrite some memory accesses with code to
3253 validate that the memory access is correct. In particular,
3254 expressions involving pointer dereferences (`INDIRECT_REF',
3255 `ARRAY_REF', etc.) are replaced by code that checks the selected
3256 address range against the mudflap runtime's database of valid
3257 regions. This check includes an inline lookup into a
3258 direct-mapped cache, based on shift/mask operations of the pointer
3259 value, with a fallback function call into the runtime. The pass
3260 is located in `tree-mudflap.c' and is described by
3263 * Leave static single assignment form
3265 This pass rewrites the function such that it is in normal form. At
3266 the same time, we eliminate as many single-use temporaries as
3267 possible, so the intermediate language is no longer GIMPLE, but
3268 GENERIC. The pass is located in `tree-outof-ssa.c' and is
3269 described by `pass_del_ssa'.
3271 * Merge PHI nodes that feed into one another
3273 This is part of the CFG cleanup passes. It attempts to join PHI
3274 nodes from a forwarder CFG block into another block with PHI
3275 nodes. The pass is located in `tree-cfgcleanup.c' and is
3276 described by `pass_merge_phi'.
3278 * Return value optimization
3280 If a function always returns the same local variable, and that
3281 local variable is an aggregate type, then the variable is replaced
3282 with the return value for the function (i.e., the function's
3283 DECL_RESULT). This is equivalent to the C++ named return value
3284 optimization applied to GIMPLE. The pass is located in
3285 `tree-nrv.c' and is described by `pass_nrv'.
3287 * Return slot optimization
3289 If a function returns a memory object and is called as `var =
3290 foo()', this pass tries to change the call so that the address of
3291 `var' is sent to the caller to avoid an extra memory copy. This
3292 pass is located in `tree-nrv.c' and is described by
3295 * Optimize calls to `__builtin_object_size'
3297 This is a propagation pass similar to CCP that tries to remove
3298 calls to `__builtin_object_size' when the size of the object can be
3299 computed at compile-time. This pass is located in
3300 `tree-object-size.c' and is described by `pass_object_sizes'.
3302 * Loop invariant motion
3304 This pass removes expensive loop-invariant computations out of
3305 loops. The pass is located in `tree-ssa-loop.c' and described by
3308 * Loop nest optimizations
3310 This is a family of loop transformations that works on loop nests.
3311 It includes loop interchange, scaling, skewing and reversal and
3312 they are all geared to the optimization of data locality in array
3313 traversals and the removal of dependencies that hamper
3314 optimizations such as loop parallelization and vectorization. The
3315 pass is located in `tree-loop-linear.c' and described by
3316 `pass_linear_transform'.
3318 * Removal of empty loops
3320 This pass removes loops with no code in them. The pass is located
3321 in `tree-ssa-loop-ivcanon.c' and described by `pass_empty_loop'.
3323 * Unrolling of small loops
3325 This pass completely unrolls loops with few iterations. The pass
3326 is located in `tree-ssa-loop-ivcanon.c' and described by
3327 `pass_complete_unroll'.
3331 This pass rewrites arithmetic expressions to enable optimizations
3332 that operate on them, like redundancy elimination and
3333 vectorization. The pass is located in `tree-ssa-reassoc.c' and
3334 described by `pass_reassoc'.
3336 * Optimization of `stdarg' functions
3338 This pass tries to avoid the saving of register arguments into the
3339 stack on entry to `stdarg' functions. If the function doesn't use
3340 any `va_start' macros, no registers need to be saved. If
3341 `va_start' macros are used, the `va_list' variables don't escape
3342 the function, it is only necessary to save registers that will be
3343 used in `va_arg' macros. For instance, if `va_arg' is only used
3344 with integral types in the function, floating point registers
3345 don't need to be saved. This pass is located in `tree-stdarg.c'
3346 and described by `pass_stdarg'.
3350 File: gccint.info, Node: RTL passes, Prev: Tree-SSA passes, Up: Passes
3355 The following briefly describes the rtl generation and optimization
3356 passes that are run after tree optimization.
3360 The source files for RTL generation include `stmt.c', `calls.c',
3361 `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and
3362 `emit-rtl.c'. Also, the file `insn-emit.c', generated from the
3363 machine description by the program `genemit', is used in this
3364 pass. The header file `expr.h' is used for communication within
3367 The header files `insn-flags.h' and `insn-codes.h', generated from
3368 the machine description by the programs `genflags' and `gencodes',
3369 tell this pass which standard names are available for use and
3370 which patterns correspond to them.
3372 * Generate exception handling landing pads
3374 This pass generates the glue that handles communication between the
3375 exception handling library routines and the exception handlers
3376 within the function. Entry points in the function that are
3377 invoked by the exception handling library are called "landing
3378 pads". The code for this pass is located within `except.c'.
3380 * Cleanup control flow graph
3382 This pass removes unreachable code, simplifies jumps to next,
3383 jumps to jump, jumps across jumps, etc. The pass is run multiple
3384 times. For historical reasons, it is occasionally referred to as
3385 the "jump optimization pass". The bulk of the code for this pass
3386 is in `cfgcleanup.c', and there are support routines in `cfgrtl.c'
3389 * Common subexpression elimination
3391 This pass removes redundant computation within basic blocks, and
3392 optimizes addressing modes based on cost. The pass is run twice.
3393 The source is located in `cse.c'.
3395 * Global common subexpression elimination.
3397 This pass performs two different types of GCSE depending on
3398 whether you are optimizing for size or not (LCM based GCSE tends
3399 to increase code size for a gain in speed, while Morel-Renvoise
3400 based GCSE does not). When optimizing for size, GCSE is done
3401 using Morel-Renvoise Partial Redundancy Elimination, with the
3402 exception that it does not try to move invariants out of
3403 loops--that is left to the loop optimization pass. If MR PRE
3404 GCSE is done, code hoisting (aka unification) is also done, as
3405 well as load motion. If you are optimizing for speed, LCM (lazy
3406 code motion) based GCSE is done. LCM is based on the work of
3407 Knoop, Ruthing, and Steffen. LCM based GCSE also does loop
3408 invariant code motion. We also perform load and store motion when
3409 optimizing for speed. Regardless of which type of GCSE is used,
3410 the GCSE pass also performs global constant and copy propagation.
3411 The source file for this pass is `gcse.c', and the LCM routines
3416 This pass moves constant expressions out of loops, and optionally
3417 does strength-reduction as well. The pass is located in `loop.c'.
3418 Loop dependency analysis routines are contained in `dependence.c'.
3419 This pass is seriously out-of-date and is supposed to be replaced
3420 by a new one described below in near future.
3422 A second loop optimization pass takes care of basic block level
3423 optimizations--unrolling, peeling and unswitching loops. The
3424 source files are `cfgloopanal.c' and `cfgloopmanip.c' containing
3425 generic loop analysis and manipulation code, `loop-init.c' with
3426 initialization and finalization code, `loop-unswitch.c' for loop
3427 unswitching and `loop-unroll.c' for loop unrolling and peeling.
3428 It also contains a separate loop invariant motion pass implemented
3429 in `loop-invariant.c'.
3433 This pass is an aggressive form of GCSE that transforms the control
3434 flow graph of a function by propagating constants into conditional
3435 branch instructions. The source file for this pass is `gcse.c'.
3439 This pass attempts to replace conditional branches and surrounding
3440 assignments with arithmetic, boolean value producing comparison
3441 instructions, and conditional move instructions. In the very last
3442 invocation after reload, it will generate predicated instructions
3443 when supported by the target. The pass is located in `ifcvt.c'.
3447 This pass splits independent uses of each pseudo-register. This
3448 can improve effect of the other transformation, such as CSE or
3449 register allocation. Its source files are `web.c'.
3453 This pass computes which pseudo-registers are live at each point in
3454 the program, and makes the first instruction that uses a value
3455 point at the instruction that computed the value. It then deletes
3456 computations whose results are never used, and combines memory
3457 references with add or subtract instructions to make autoincrement
3458 or autodecrement addressing. The pass is located in `flow.c'.
3460 * Instruction combination
3462 This pass attempts to combine groups of two or three instructions
3463 that are related by data flow into single instructions. It
3464 combines the RTL expressions for the instructions by substitution,
3465 simplifies the result using algebra, and then attempts to match
3466 the result against the machine description. The pass is located
3471 This pass looks for cases where matching constraints would force an
3472 instruction to need a reload, and this reload would be a
3473 register-to-register move. It then attempts to change the
3474 registers used by the instruction to avoid the move instruction.
3475 The pass is located in `regmove.c'.
3477 * Optimize mode switching
3479 This pass looks for instructions that require the processor to be
3480 in a specific "mode" and minimizes the number of mode changes
3481 required to satisfy all users. What these modes are, and what
3482 they apply to are completely target-specific. The source is
3483 located in `mode-switching.c'.
3487 This pass looks at innermost loops and reorders their instructions
3488 by overlapping different iterations. Modulo scheduling is
3489 performed immediately before instruction scheduling. The pass is
3490 located in (`modulo-sched.c').
3492 * Instruction scheduling
3494 This pass looks for instructions whose output will not be
3495 available by the time that it is used in subsequent instructions.
3496 Memory loads and floating point instructions often have this
3497 behavior on RISC machines. It re-orders instructions within a
3498 basic block to try to separate the definition and use of items
3499 that otherwise would cause pipeline stalls. This pass is
3500 performed twice, before and after register allocation. The pass
3501 is located in `haifa-sched.c', `sched-deps.c', `sched-ebb.c',
3502 `sched-rgn.c' and `sched-vis.c'.
3504 * Register allocation
3506 These passes make sure that all occurrences of pseudo registers are
3507 eliminated, either by allocating them to a hard register, replacing
3508 them by an equivalent expression (e.g. a constant) or by placing
3509 them on the stack. This is done in several subpasses:
3511 * Register class preferencing. The RTL code is scanned to find
3512 out which register class is best for each pseudo register.
3513 The source file is `regclass.c'.
3515 * Local register allocation. This pass allocates hard
3516 registers to pseudo registers that are used only within one
3517 basic block. Because the basic block is linear, it can use
3518 fast and powerful techniques to do a decent job. The source
3519 is located in `local-alloc.c'.
3521 * Global register allocation. This pass allocates hard
3522 registers for the remaining pseudo registers (those whose
3523 life spans are not contained in one basic block). The pass
3524 is located in `global.c'.
3526 * Reloading. This pass renumbers pseudo registers with the
3527 hardware registers numbers they were allocated. Pseudo
3528 registers that did not get hard registers are replaced with
3529 stack slots. Then it finds instructions that are invalid
3530 because a value has failed to end up in a register, or has
3531 ended up in a register of the wrong kind. It fixes up these
3532 instructions by reloading the problematical values
3533 temporarily into registers. Additional instructions are
3534 generated to do the copying.
3536 The reload pass also optionally eliminates the frame pointer
3537 and inserts instructions to save and restore call-clobbered
3538 registers around calls.
3540 Source files are `reload.c' and `reload1.c', plus the header
3541 `reload.h' used for communication between them.
3543 * Basic block reordering
3545 This pass implements profile guided code positioning. If profile
3546 information is not available, various types of static analysis are
3547 performed to make the predictions normally coming from the profile
3548 feedback (IE execution frequency, branch probability, etc). It is
3549 implemented in the file `bb-reorder.c', and the various prediction
3550 routines are in `predict.c'.
3554 This pass computes where the variables are stored at each position
3555 in code and generates notes describing the variable locations to
3556 RTL code. The location lists are then generated according to these
3557 notes to debug information if the debugging information format
3558 supports location lists.
3560 * Delayed branch scheduling
3562 This optional pass attempts to find instructions that can go into
3563 the delay slots of other instructions, usually jumps and calls.
3564 The source file name is `reorg.c'.
3568 On many RISC machines, branch instructions have a limited range.
3569 Thus, longer sequences of instructions must be used for long
3570 branches. In this pass, the compiler figures out what how far
3571 each instruction will be from each other instruction, and
3572 therefore whether the usual instructions, or the longer sequences,
3573 must be used for each branch.
3575 * Register-to-stack conversion
3577 Conversion from usage of some hard registers to usage of a register
3578 stack may be done at this point. Currently, this is supported only
3579 for the floating-point registers of the Intel 80387 coprocessor.
3580 The source file name is `reg-stack.c'.
3584 This pass outputs the assembler code for the function. The source
3585 files are `final.c' plus `insn-output.c'; the latter is generated
3586 automatically from the machine description by the tool `genoutput'.
3587 The header file `conditions.h' is used for communication between
3588 these files. If mudflap is enabled, the queue of deferred
3589 declarations and any addressed constants (e.g., string literals)
3590 is processed by `mudflap_finish_file' into a synthetic constructor
3591 function containing calls into the mudflap runtime.
3593 * Debugging information output
3595 This is run after final because it must output the stack slot
3596 offsets for pseudo registers that did not get hard registers.
3597 Source files are `dbxout.c' for DBX symbol table format,
3598 `sdbout.c' for SDB symbol table format, `dwarfout.c' for DWARF
3599 symbol table format, files `dwarf2out.c' and `dwarf2asm.c' for
3600 DWARF2 symbol table format, and `vmsdbgout.c' for VMS debug symbol
3605 File: gccint.info, Node: Trees, Next: RTL, Prev: Passes, Up: Top
3607 9 Trees: The intermediate representation used by the C and C++ front ends
3608 *************************************************************************
3610 This chapter documents the internal representation used by GCC to
3611 represent C and C++ source programs. When presented with a C or C++
3612 source program, GCC parses the program, performs semantic analysis
3613 (including the generation of error messages), and then produces the
3614 internal representation described here. This representation contains a
3615 complete representation for the entire translation unit provided as
3616 input to the front end. This representation is then typically processed
3617 by a code-generator in order to produce machine code, but could also be
3618 used in the creation of source browsers, intelligent editors, automatic
3619 documentation generators, interpreters, and any other programs needing
3620 the ability to process C or C++ code.
3622 This chapter explains the internal representation. In particular, it
3623 documents the internal representation for C and C++ source constructs,
3624 and the macros, functions, and variables that can be used to access
3625 these constructs. The C++ representation is largely a superset of the
3626 representation used in the C front end. There is only one construct
3627 used in C that does not appear in the C++ front end and that is the GNU
3628 "nested function" extension. Many of the macros documented here do not
3629 apply in C because the corresponding language constructs do not appear
3632 If you are developing a "back end", be it is a code-generator or some
3633 other tool, that uses this representation, you may occasionally find
3634 that you need to ask questions not easily answered by the functions and
3635 macros available here. If that situation occurs, it is quite likely
3636 that GCC already supports the functionality you desire, but that the
3637 interface is simply not documented here. In that case, you should ask
3638 the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting
3639 the functionality you require. Similarly, if you find yourself writing
3640 functions that do not deal directly with your back end, but instead
3641 might be useful to other people using the GCC front end, you should
3642 submit your patches for inclusion in GCC.
3646 * Deficiencies:: Topics net yet covered in this document.
3647 * Tree overview:: All about `tree's.
3648 * Types:: Fundamental and aggregate types.
3649 * Scopes:: Namespaces and classes.
3650 * Functions:: Overloading, function bodies, and linkage.
3651 * Declarations:: Type declarations and variables.
3652 * Attributes:: Declaration and type attributes.
3653 * Expression trees:: From `typeid' to `throw'.
3656 File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: Trees
3661 There are many places in which this document is incomplet and incorrekt.
3662 It is, as of yet, only _preliminary_ documentation.
3665 File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: Trees
3670 The central data structure used by the internal representation is the
3671 `tree'. These nodes, while all of the C type `tree', are of many
3672 varieties. A `tree' is a pointer type, but the object to which it
3673 points may be of a variety of types. From this point forward, we will
3674 refer to trees in ordinary type, rather than in `this font', except
3675 when talking about the actual C type `tree'.
3677 You can tell what kind of node a particular tree is by using the
3678 `TREE_CODE' macro. Many, many macros take trees as input and return
3679 trees as output. However, most macros require a certain kind of tree
3680 node as input. In other words, there is a type-system for trees, but
3681 it is not reflected in the C type-system.
3683 For safety, it is useful to configure GCC with `--enable-checking'.
3684 Although this results in a significant performance penalty (since all
3685 tree types are checked at run-time), and is therefore inappropriate in a
3686 release version, it is extremely helpful during the development process.
3688 Many macros behave as predicates. Many, although not all, of these
3689 predicates end in `_P'. Do not rely on the result type of these macros
3690 being of any particular type. You may, however, rely on the fact that
3691 the type can be compared to `0', so that statements like
3692 if (TEST_P (t) && !TEST_P (y))
3695 int i = (TEST_P (t) != 0);
3696 are legal. Macros that return `int' values now may be changed to
3697 return `tree' values, or other pointers in the future. Even those that
3698 continue to return `int' may return multiple nonzero codes where
3699 previously they returned only zero and one. Therefore, you should not
3701 if (TEST_P (t) == 1)
3702 as this code is not guaranteed to work correctly in the future.
3704 You should not take the address of values returned by the macros or
3705 functions described here. In particular, no guarantee is given that the
3708 In general, the names of macros are all in uppercase, while the names
3709 of functions are entirely in lowercase. There are rare exceptions to
3710 this rule. You should assume that any macro or function whose name is
3711 made up entirely of uppercase letters may evaluate its arguments more
3712 than once. You may assume that a macro or function whose name is made
3713 up entirely of lowercase letters will evaluate its arguments only once.
3715 The `error_mark_node' is a special tree. Its tree code is
3716 `ERROR_MARK', but since there is only ever one node with that code, the
3717 usual practice is to compare the tree against `error_mark_node'. (This
3718 test is just a test for pointer equality.) If an error has occurred
3719 during front-end processing the flag `errorcount' will be set. If the
3720 front end has encountered code it cannot handle, it will issue a
3721 message to the user and set `sorrycount'. When these flags are set,
3722 any macro or function which normally returns a tree of a particular
3723 kind may instead return the `error_mark_node'. Thus, if you intend to
3724 do any processing of erroneous code, you must be prepared to deal with
3725 the `error_mark_node'.
3727 Occasionally, a particular tree slot (like an operand to an expression,
3728 or a particular field in a declaration) will be referred to as
3729 "reserved for the back end". These slots are used to store RTL when
3730 the tree is converted to RTL for use by the GCC back end. However, if
3731 that process is not taking place (e.g., if the front end is being hooked
3732 up to an intelligent editor), then those slots may be used by the back
3733 end presently in use.
3735 If you encounter situations that do not match this documentation, such
3736 as tree nodes of types not mentioned here, or macros documented to
3737 return entities of a particular kind that instead return entities of
3738 some different kind, you have found a bug, either in the front end or in
3739 the documentation. Please report these bugs as you would any other bug.
3743 * Macros and Functions::Macros and functions that can be used with all trees.
3744 * Identifiers:: The names of things.
3745 * Containers:: Lists and vectors.
3748 File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview
3753 This section is not here yet.
3756 File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview
3761 An `IDENTIFIER_NODE' represents a slightly more general concept that
3762 the standard C or C++ concept of identifier. In particular, an
3763 `IDENTIFIER_NODE' may contain a `$', or other extraordinary characters.
3765 There are never two distinct `IDENTIFIER_NODE's representing the same
3766 identifier. Therefore, you may use pointer equality to compare
3767 `IDENTIFIER_NODE's, rather than using a routine like `strcmp'.
3769 You can use the following macros to access identifiers:
3770 `IDENTIFIER_POINTER'
3771 The string represented by the identifier, represented as a
3772 `char*'. This string is always `NUL'-terminated, and contains no
3773 embedded `NUL' characters.
3776 The length of the string returned by `IDENTIFIER_POINTER', not
3777 including the trailing `NUL'. This value of `IDENTIFIER_LENGTH
3778 (x)' is always the same as `strlen (IDENTIFIER_POINTER (x))'.
3780 `IDENTIFIER_OPNAME_P'
3781 This predicate holds if the identifier represents the name of an
3782 overloaded operator. In this case, you should not depend on the
3783 contents of either the `IDENTIFIER_POINTER' or the
3784 `IDENTIFIER_LENGTH'.
3786 `IDENTIFIER_TYPENAME_P'
3787 This predicate holds if the identifier represents the name of a
3788 user-defined conversion operator. In this case, the `TREE_TYPE' of
3789 the `IDENTIFIER_NODE' holds the type to which the conversion
3794 File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview
3799 Two common container data structures can be represented directly with
3800 tree nodes. A `TREE_LIST' is a singly linked list containing two trees
3801 per node. These are the `TREE_PURPOSE' and `TREE_VALUE' of each node.
3802 (Often, the `TREE_PURPOSE' contains some kind of tag, or additional
3803 information, while the `TREE_VALUE' contains the majority of the
3804 payload. In other cases, the `TREE_PURPOSE' is simply `NULL_TREE',
3805 while in still others both the `TREE_PURPOSE' and `TREE_VALUE' are of
3806 equal stature.) Given one `TREE_LIST' node, the next node is found by
3807 following the `TREE_CHAIN'. If the `TREE_CHAIN' is `NULL_TREE', then
3808 you have reached the end of the list.
3810 A `TREE_VEC' is a simple vector. The `TREE_VEC_LENGTH' is an integer
3811 (not a tree) giving the number of nodes in the vector. The nodes
3812 themselves are accessed using the `TREE_VEC_ELT' macro, which takes two
3813 arguments. The first is the `TREE_VEC' in question; the second is an
3814 integer indicating which element in the vector is desired. The
3815 elements are indexed from zero.
3818 File: gccint.info, Node: Types, Next: Scopes, Prev: Tree overview, Up: Trees
3823 All types have corresponding tree nodes. However, you should not assume
3824 that there is exactly one tree node corresponding to each type. There
3825 are often several nodes each of which correspond to the same type.
3827 For the most part, different kinds of types have different tree codes.
3828 (For example, pointer types use a `POINTER_TYPE' code while arrays use
3829 an `ARRAY_TYPE' code.) However, pointers to member functions use the
3830 `RECORD_TYPE' code. Therefore, when writing a `switch' statement that
3831 depends on the code associated with a particular type, you should take
3832 care to handle pointers to member functions under the `RECORD_TYPE'
3835 In C++, an array type is not qualified; rather the type of the array
3836 elements is qualified. This situation is reflected in the intermediate
3837 representation. The macros described here will always examine the
3838 qualification of the underlying element type when applied to an array
3839 type. (If the element type is itself an array, then the recursion
3840 continues until a non-array type is found, and the qualification of this
3841 type is examined.) So, for example, `CP_TYPE_CONST_P' will hold of the
3842 type `const int ()[7]', denoting an array of seven `int's.
3844 The following functions and macros deal with cv-qualification of types:
3846 This macro returns the set of type qualifiers applied to this type.
3847 This value is `TYPE_UNQUALIFIED' if no qualifiers have been
3848 applied. The `TYPE_QUAL_CONST' bit is set if the type is
3849 `const'-qualified. The `TYPE_QUAL_VOLATILE' bit is set if the
3850 type is `volatile'-qualified. The `TYPE_QUAL_RESTRICT' bit is set
3851 if the type is `restrict'-qualified.
3854 This macro holds if the type is `const'-qualified.
3856 `CP_TYPE_VOLATILE_P'
3857 This macro holds if the type is `volatile'-qualified.
3859 `CP_TYPE_RESTRICT_P'
3860 This macro holds if the type is `restrict'-qualified.
3862 `CP_TYPE_CONST_NON_VOLATILE_P'
3863 This predicate holds for a type that is `const'-qualified, but
3864 _not_ `volatile'-qualified; other cv-qualifiers are ignored as
3865 well: only the `const'-ness is tested.
3868 This macro returns the unqualified version of a type. It may be
3869 applied to an unqualified type, but it is not always the identity
3870 function in that case.
3872 A few other macros and functions are usable with all types:
3874 The number of bits required to represent the type, represented as
3875 an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be
3879 The alignment of the type, in bits, represented as an `int'.
3882 This macro returns a declaration (in the form of a `TYPE_DECL') for
3883 the type. (Note this macro does _not_ return a `IDENTIFIER_NODE',
3884 as you might expect, given its name!) You can look at the
3885 `DECL_NAME' of the `TYPE_DECL' to obtain the actual name of the
3886 type. The `TYPE_NAME' will be `NULL_TREE' for a type that is not
3887 a built-in type, the result of a typedef, or a named class type.
3890 This predicate holds if the type is an integral type. Notice that
3891 in C++, enumerations are _not_ integral types.
3894 This predicate holds if the type is an integral type (in the C++
3895 sense) or a floating point type.
3898 This predicate holds for a class-type.
3901 This predicate holds for a built-in type.
3904 This predicate holds if the type is a pointer to data member.
3907 This predicate holds if the type is a pointer type, and the
3908 pointee is not a data member.
3911 This predicate holds for a pointer to function type.
3914 This predicate holds for a pointer to object type. Note however
3915 that it does not hold for the generic pointer to object type `void
3916 *'. You may use `TYPE_PTROBV_P' to test for a pointer to object
3917 type as well as `void *'.
3920 This predicate takes two types as input, and holds if they are the
3921 same type. For example, if one type is a `typedef' for the other,
3922 or both are `typedef's for the same type. This predicate also
3923 holds if the two trees given as input are simply copies of one
3924 another; i.e., there is no difference between them at the source
3925 level, but, for whatever reason, a duplicate has been made in the
3926 representation. You should never use `==' (pointer equality) to
3927 compare types; always use `same_type_p' instead.
3929 Detailed below are the various kinds of types, and the macros that can
3930 be used to access them. Although other kinds of types are used
3931 elsewhere in G++, the types described here are the only ones that you
3932 will encounter while examining the intermediate representation.
3935 Used to represent the `void' type.
3938 Used to represent the various integral types, including `char',
3939 `short', `int', `long', and `long long'. This code is not used
3940 for enumeration types, nor for the `bool' type. Note that GCC's
3941 `CHAR_TYPE' node is _not_ used to represent `char'. The
3942 `TYPE_PRECISION' is the number of bits used in the representation,
3943 represented as an `unsigned int'. (Note that in the general case
3944 this is not the same value as `TYPE_SIZE'; suppose that there were
3945 a 24-bit integer type, but that alignment requirements for the ABI
3946 required 32-bit alignment. Then, `TYPE_SIZE' would be an
3947 `INTEGER_CST' for 32, while `TYPE_PRECISION' would be 24.) The
3948 integer type is unsigned if `TYPE_UNSIGNED' holds; otherwise, it
3951 The `TYPE_MIN_VALUE' is an `INTEGER_CST' for the smallest integer
3952 that may be represented by this type. Similarly, the
3953 `TYPE_MAX_VALUE' is an `INTEGER_CST' for the largest integer that
3954 may be represented by this type.
3957 Used to represent the `float', `double', and `long double' types.
3958 The number of bits in the floating-point representation is given
3959 by `TYPE_PRECISION', as in the `INTEGER_TYPE' case.
3962 Used to represent GCC built-in `__complex__' data types. The
3963 `TREE_TYPE' is the type of the real and imaginary parts.
3966 Used to represent an enumeration type. The `TYPE_PRECISION' gives
3967 (as an `int'), the number of bits used to represent the type. If
3968 there are no negative enumeration constants, `TYPE_UNSIGNED' will
3969 hold. The minimum and maximum enumeration constants may be
3970 obtained with `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE', respectively;
3971 each of these macros returns an `INTEGER_CST'.
3973 The actual enumeration constants themselves may be obtained by
3974 looking at the `TYPE_VALUES'. This macro will return a
3975 `TREE_LIST', containing the constants. The `TREE_PURPOSE' of each
3976 node will be an `IDENTIFIER_NODE' giving the name of the constant;
3977 the `TREE_VALUE' will be an `INTEGER_CST' giving the value
3978 assigned to that constant. These constants will appear in the
3979 order in which they were declared. The `TREE_TYPE' of each of
3980 these constants will be the type of enumeration type itself.
3983 Used to represent the `bool' type.
3986 Used to represent pointer types, and pointer to data member types.
3987 The `TREE_TYPE' gives the type to which this type points. If the
3988 type is a pointer to data member type, then `TYPE_PTRMEM_P' will
3989 hold. For a pointer to data member type of the form `T X::*',
3990 `TYPE_PTRMEM_CLASS_TYPE' will be the type `X', while
3991 `TYPE_PTRMEM_POINTED_TO_TYPE' will be the type `T'.
3994 Used to represent reference types. The `TREE_TYPE' gives the type
3995 to which this type refers.
3998 Used to represent the type of non-member functions and of static
3999 member functions. The `TREE_TYPE' gives the return type of the
4000 function. The `TYPE_ARG_TYPES' are a `TREE_LIST' of the argument
4001 types. The `TREE_VALUE' of each node in this list is the type of
4002 the corresponding argument; the `TREE_PURPOSE' is an expression
4003 for the default argument value, if any. If the last node in the
4004 list is `void_list_node' (a `TREE_LIST' node whose `TREE_VALUE' is
4005 the `void_type_node'), then functions of this type do not take
4006 variable arguments. Otherwise, they do take a variable number of
4009 Note that in C (but not in C++) a function declared like `void f()'
4010 is an unprototyped function taking a variable number of arguments;
4011 the `TYPE_ARG_TYPES' of such a function will be `NULL'.
4014 Used to represent the type of a non-static member function. Like a
4015 `FUNCTION_TYPE', the return type is given by the `TREE_TYPE'. The
4016 type of `*this', i.e., the class of which functions of this type
4017 are a member, is given by the `TYPE_METHOD_BASETYPE'. The
4018 `TYPE_ARG_TYPES' is the parameter list, as for a `FUNCTION_TYPE',
4019 and includes the `this' argument.
4022 Used to represent array types. The `TREE_TYPE' gives the type of
4023 the elements in the array. If the array-bound is present in the
4024 type, the `TYPE_DOMAIN' is an `INTEGER_TYPE' whose
4025 `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE' will be the lower and upper
4026 bounds of the array, respectively. The `TYPE_MIN_VALUE' will
4027 always be an `INTEGER_CST' for zero, while the `TYPE_MAX_VALUE'
4028 will be one less than the number of elements in the array, i.e.,
4029 the highest value which may be used to index an element in the
4033 Used to represent `struct' and `class' types, as well as pointers
4034 to member functions and similar constructs in other languages.
4035 `TYPE_FIELDS' contains the items contained in this type, each of
4036 which can be a `FIELD_DECL', `VAR_DECL', `CONST_DECL', or
4037 `TYPE_DECL'. You may not make any assumptions about the ordering
4038 of the fields in the type or whether one or more of them overlap.
4039 If `TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member
4040 type. In that case, the `TYPE_PTRMEMFUNC_FN_TYPE' is a
4041 `POINTER_TYPE' pointing to a `METHOD_TYPE'. The `METHOD_TYPE' is
4042 the type of a function pointed to by the pointer-to-member
4043 function. If `TYPE_PTRMEMFUNC_P' does not hold, this type is a
4044 class type. For more information, see *note Classes::.
4047 Used to represent `union' types. Similar to `RECORD_TYPE' except
4048 that all `FIELD_DECL' nodes in `TYPE_FIELD' start at bit position
4052 Used to represent part of a variant record in Ada. Similar to
4053 `UNION_TYPE' except that each `FIELD_DECL' has a `DECL_QUALIFIER'
4054 field, which contains a boolean expression that indicates whether
4055 the field is present in the object. The type will only have one
4056 field, so each field's `DECL_QUALIFIER' is only evaluated if none
4057 of the expressions in the previous fields in `TYPE_FIELDS' are
4058 nonzero. Normally these expressions will reference a field in the
4059 outer object using a `PLACEHOLDER_EXPR'.
4062 This node is used to represent a type the knowledge of which is
4063 insufficient for a sound processing.
4066 This node is used to represent a pointer-to-data member. For a
4067 data member `X::m' the `TYPE_OFFSET_BASETYPE' is `X' and the
4068 `TREE_TYPE' is the type of `m'.
4071 Used to represent a construct of the form `typename T::A'. The
4072 `TYPE_CONTEXT' is `T'; the `TYPE_NAME' is an `IDENTIFIER_NODE' for
4073 `A'. If the type is specified via a template-id, then
4074 `TYPENAME_TYPE_FULLNAME' yields a `TEMPLATE_ID_EXPR'. The
4075 `TREE_TYPE' is non-`NULL' if the node is implicitly generated in
4076 support for the implicit typename extension; in which case the
4077 `TREE_TYPE' is a type node for the base-class.
4080 Used to represent the `__typeof__' extension. The `TYPE_FIELDS'
4081 is the expression the type of which is being represented.
4083 There are variables whose values represent some of the basic types.
4091 `unsigned_type_node.'
4092 A node for `unsigned int'.
4096 It may sometimes be useful to compare one of these variables with a
4097 type in hand, using `same_type_p'.
4100 File: gccint.info, Node: Scopes, Next: Functions, Prev: Types, Up: Trees
4105 The root of the entire intermediate representation is the variable
4106 `global_namespace'. This is the namespace specified with `::' in C++
4107 source code. All other namespaces, types, variables, functions, and so
4108 forth can be found starting with this namespace.
4110 Besides namespaces, the other high-level scoping construct in C++ is
4111 the class. (Throughout this manual the term "class" is used to mean the
4112 types referred to in the ANSI/ISO C++ Standard as classes; these include
4113 types defined with the `class', `struct', and `union' keywords.)
4117 * Namespaces:: Member functions, types, etc.
4118 * Classes:: Members, bases, friends, etc.
4121 File: gccint.info, Node: Namespaces, Next: Classes, Up: Scopes
4126 A namespace is represented by a `NAMESPACE_DECL' node.
4128 However, except for the fact that it is distinguished as the root of
4129 the representation, the global namespace is no different from any other
4130 namespace. Thus, in what follows, we describe namespaces generally,
4131 rather than the global namespace in particular.
4133 The following macros and functions can be used on a `NAMESPACE_DECL':
4136 This macro is used to obtain the `IDENTIFIER_NODE' corresponding to
4137 the unqualified name of the name of the namespace (*note
4138 Identifiers::). The name of the global namespace is `::', even
4139 though in C++ the global namespace is unnamed. However, you
4140 should use comparison with `global_namespace', rather than
4141 `DECL_NAME' to determine whether or not a namespace is the global
4142 one. An unnamed namespace will have a `DECL_NAME' equal to
4143 `anonymous_namespace_name'. Within a single translation unit, all
4144 unnamed namespaces will have the same name.
4147 This macro returns the enclosing namespace. The `DECL_CONTEXT' for
4148 the `global_namespace' is `NULL_TREE'.
4150 `DECL_NAMESPACE_ALIAS'
4151 If this declaration is for a namespace alias, then
4152 `DECL_NAMESPACE_ALIAS' is the namespace for which this one is an
4155 Do not attempt to use `cp_namespace_decls' for a namespace which is
4156 an alias. Instead, follow `DECL_NAMESPACE_ALIAS' links until you
4157 reach an ordinary, non-alias, namespace, and call
4158 `cp_namespace_decls' there.
4160 `DECL_NAMESPACE_STD_P'
4161 This predicate holds if the namespace is the special `::std'
4164 `cp_namespace_decls'
4165 This function will return the declarations contained in the
4166 namespace, including types, overloaded functions, other
4167 namespaces, and so forth. If there are no declarations, this
4168 function will return `NULL_TREE'. The declarations are connected
4169 through their `TREE_CHAIN' fields.
4171 Although most entries on this list will be declarations,
4172 `TREE_LIST' nodes may also appear. In this case, the `TREE_VALUE'
4173 will be an `OVERLOAD'. The value of the `TREE_PURPOSE' is
4174 unspecified; back ends should ignore this value. As with the
4175 other kinds of declarations returned by `cp_namespace_decls', the
4176 `TREE_CHAIN' will point to the next declaration in this list.
4178 For more information on the kinds of declarations that can occur
4179 on this list, *Note Declarations::. Some declarations will not
4180 appear on this list. In particular, no `FIELD_DECL',
4181 `LABEL_DECL', or `PARM_DECL' nodes will appear here.
4183 This function cannot be used with namespaces that have
4184 `DECL_NAMESPACE_ALIAS' set.
4188 File: gccint.info, Node: Classes, Prev: Namespaces, Up: Scopes
4193 A class type is represented by either a `RECORD_TYPE' or a
4194 `UNION_TYPE'. A class declared with the `union' tag is represented by
4195 a `UNION_TYPE', while classes declared with either the `struct' or the
4196 `class' tag are represented by `RECORD_TYPE's. You can use the
4197 `CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular
4198 type is a `class' as opposed to a `struct'. This macro will be true
4199 only for classes declared with the `class' tag.
4201 Almost all non-function members are available on the `TYPE_FIELDS'
4202 list. Given one member, the next can be found by following the
4203 `TREE_CHAIN'. You should not depend in any way on the order in which
4204 fields appear on this list. All nodes on this list will be `DECL'
4205 nodes. A `FIELD_DECL' is used to represent a non-static data member, a
4206 `VAR_DECL' is used to represent a static data member, and a `TYPE_DECL'
4207 is used to represent a type. Note that the `CONST_DECL' for an
4208 enumeration constant will appear on this list, if the enumeration type
4209 was declared in the class. (Of course, the `TYPE_DECL' for the
4210 enumeration type will appear here as well.) There are no entries for
4211 base classes on this list. In particular, there is no `FIELD_DECL' for
4212 the "base-class portion" of an object.
4214 The `TYPE_VFIELD' is a compiler-generated field used to point to
4215 virtual function tables. It may or may not appear on the `TYPE_FIELDS'
4216 list. However, back ends should handle the `TYPE_VFIELD' just like all
4217 the entries on the `TYPE_FIELDS' list.
4219 The function members are available on the `TYPE_METHODS' list. Again,
4220 subsequent members are found by following the `TREE_CHAIN' field. If a
4221 function is overloaded, each of the overloaded functions appears; no
4222 `OVERLOAD' nodes appear on the `TYPE_METHODS' list. Implicitly
4223 declared functions (including default constructors, copy constructors,
4224 assignment operators, and destructors) will appear on this list as well.
4226 Every class has an associated "binfo", which can be obtained with
4227 `TYPE_BINFO'. Binfos are used to represent base-classes. The binfo
4228 given by `TYPE_BINFO' is the degenerate case, whereby every class is
4229 considered to be its own base-class. The base binfos for a particular
4230 binfo are held in a vector, whose length is obtained with
4231 `BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with
4232 `BINFO_BASE_BINFO' and `BINFO_BASE_ITERATE'. To add a new binfo, use
4233 `BINFO_BASE_APPEND'. The vector of base binfos can be obtained with
4234 `BINFO_BASE_BINFOS', but normally you do not need to use that. The
4235 class type associated with a binfo is given by `BINFO_TYPE'. It is not
4236 always the case that `BINFO_TYPE (TYPE_BINFO (x))', because of typedefs
4237 and qualified types. Neither is it the case that `TYPE_BINFO
4238 (BINFO_TYPE (y))' is the same binfo as `y'. The reason is that if `y'
4239 is a binfo representing a base-class `B' of a derived class `D', then
4240 `BINFO_TYPE (y)' will be `B', and `TYPE_BINFO (BINFO_TYPE (y))' will be
4241 `B' as its own base-class, rather than as a base-class of `D'.
4243 The access to a base type can be found with `BINFO_BASE_ACCESS'. This
4244 will produce `access_public_node', `access_private_node' or
4245 `access_protected_node'. If bases are always public,
4246 `BINFO_BASE_ACCESSES' may be `NULL'.
4248 `BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited
4249 virtually or not. The other flags, `BINFO_MARKED_P' and `BINFO_FLAG_1'
4250 to `BINFO_FLAG_6' can be used for language specific use.
4252 The following macros can be used on a tree node representing a
4256 This predicate holds if the class is local class _i.e._ declared
4257 inside a function body.
4259 `TYPE_POLYMORPHIC_P'
4260 This predicate holds if the class has at least one virtual function
4261 (declared or inherited).
4263 `TYPE_HAS_DEFAULT_CONSTRUCTOR'
4264 This predicate holds whenever its argument represents a class-type
4265 with default constructor.
4267 `CLASSTYPE_HAS_MUTABLE'
4268 `TYPE_HAS_MUTABLE_P'
4269 These predicates hold for a class-type having a mutable data
4272 `CLASSTYPE_NON_POD_P'
4273 This predicate holds only for class-types that are not PODs.
4275 `TYPE_HAS_NEW_OPERATOR'
4276 This predicate holds for a class-type that defines `operator new'.
4278 `TYPE_HAS_ARRAY_NEW_OPERATOR'
4279 This predicate holds for a class-type for which `operator new[]'
4282 `TYPE_OVERLOADS_CALL_EXPR'
4283 This predicate holds for class-type for which the function call
4284 `operator()' is overloaded.
4286 `TYPE_OVERLOADS_ARRAY_REF'
4287 This predicate holds for a class-type that overloads `operator[]'
4289 `TYPE_OVERLOADS_ARROW'
4290 This predicate holds for a class-type for which `operator->' is
4295 File: gccint.info, Node: Declarations, Next: Attributes, Prev: Functions, Up: Trees
4300 This section covers the various kinds of declarations that appear in the
4301 internal representation, except for declarations of functions
4302 (represented by `FUNCTION_DECL' nodes), which are described in *Note
4307 * Working with declarations:: Macros and functions that work on
4309 * Internal structure:: How declaration nodes are represented.
4312 File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations
4314 9.5.1 Working with declarations
4315 -------------------------------
4317 Some macros can be used with any kind of declaration. These include:
4319 This macro returns an `IDENTIFIER_NODE' giving the name of the
4323 This macro returns the type of the entity declared.
4326 This macro returns the name of the file in which the entity was
4327 declared, as a `char*'. For an entity declared implicitly by the
4328 compiler (like `__builtin_memcpy'), this will be the string
4332 This macro returns the line number at which the entity was
4333 declared, as an `int'.
4336 This predicate holds if the declaration was implicitly generated
4337 by the compiler. For example, this predicate will hold of an
4338 implicitly declared member function, or of the `TYPE_DECL'
4339 implicitly generated for a class type. Recall that in C++ code
4342 is roughly equivalent to C code like:
4345 The implicitly generated `typedef' declaration is represented by a
4346 `TYPE_DECL' for which `DECL_ARTIFICIAL' holds.
4348 `DECL_NAMESPACE_SCOPE_P'
4349 This predicate holds if the entity was declared at a namespace
4352 `DECL_CLASS_SCOPE_P'
4353 This predicate holds if the entity was declared at a class scope.
4355 `DECL_FUNCTION_SCOPE_P'
4356 This predicate holds if the entity was declared inside a function
4360 The various kinds of declarations include:
4362 These nodes are used to represent labels in function bodies. For
4363 more information, see *Note Functions::. These nodes only appear
4367 These nodes are used to represent enumeration constants. The
4368 value of the constant is given by `DECL_INITIAL' which will be an
4369 `INTEGER_CST' with the same type as the `TREE_TYPE' of the
4370 `CONST_DECL', i.e., an `ENUMERAL_TYPE'.
4373 These nodes represent the value returned by a function. When a
4374 value is assigned to a `RESULT_DECL', that indicates that the
4375 value should be returned, via bitwise copy, by the function. You
4376 can use `DECL_SIZE' and `DECL_ALIGN' on a `RESULT_DECL', just as
4380 These nodes represent `typedef' declarations. The `TREE_TYPE' is
4381 the type declared to have the name given by `DECL_NAME'. In some
4382 cases, there is no associated name.
4385 These nodes represent variables with namespace or block scope, as
4386 well as static data members. The `DECL_SIZE' and `DECL_ALIGN' are
4387 analogous to `TYPE_SIZE' and `TYPE_ALIGN'. For a declaration, you
4388 should always use the `DECL_SIZE' and `DECL_ALIGN' rather than the
4389 `TYPE_SIZE' and `TYPE_ALIGN' given by the `TREE_TYPE', since
4390 special attributes may have been applied to the variable to give
4391 it a particular size and alignment. You may use the predicates
4392 `DECL_THIS_STATIC' or `DECL_THIS_EXTERN' to test whether the
4393 storage class specifiers `static' or `extern' were used to declare
4396 If this variable is initialized (but does not require a
4397 constructor), the `DECL_INITIAL' will be an expression for the
4398 initializer. The initializer should be evaluated, and a bitwise
4399 copy into the variable performed. If the `DECL_INITIAL' is the
4400 `error_mark_node', there is an initializer, but it is given by an
4401 explicit statement later in the code; no bitwise copy is required.
4403 GCC provides an extension that allows either automatic variables,
4404 or global variables, to be placed in particular registers. This
4405 extension is being used for a particular `VAR_DECL' if
4406 `DECL_REGISTER' holds for the `VAR_DECL', and if
4407 `DECL_ASSEMBLER_NAME' is not equal to `DECL_NAME'. In that case,
4408 `DECL_ASSEMBLER_NAME' is the name of the register into which the
4409 variable will be placed.
4412 Used to represent a parameter to a function. Treat these nodes
4413 similarly to `VAR_DECL' nodes. These nodes only appear in the
4414 `DECL_ARGUMENTS' for a `FUNCTION_DECL'.
4416 The `DECL_ARG_TYPE' for a `PARM_DECL' is the type that will
4417 actually be used when a value is passed to this function. It may
4418 be a wider type than the `TREE_TYPE' of the parameter; for
4419 example, the ordinary type might be `short' while the
4420 `DECL_ARG_TYPE' is `int'.
4423 These nodes represent non-static data members. The `DECL_SIZE' and
4424 `DECL_ALIGN' behave as for `VAR_DECL' nodes. The
4425 `DECL_FIELD_BITPOS' gives the first bit used for this field, as an
4426 `INTEGER_CST'. These values are indexed from zero, where zero
4427 indicates the first bit in the object.
4429 If `DECL_C_BIT_FIELD' holds, this field is a bit-field.
4435 These nodes are used to represent class, function, and variable
4436 (static data member) templates. The
4437 `DECL_TEMPLATE_SPECIALIZATIONS' are a `TREE_LIST'. The
4438 `TREE_VALUE' of each node in the list is a `TEMPLATE_DECL's or
4439 `FUNCTION_DECL's representing specializations (including
4440 instantiations) of this template. Back ends can safely ignore
4441 `TEMPLATE_DECL's, but should examine `FUNCTION_DECL' nodes on the
4442 specializations list just as they would ordinary `FUNCTION_DECL'
4445 For a class template, the `DECL_TEMPLATE_INSTANTIATIONS' list
4446 contains the instantiations. The `TREE_VALUE' of each node is an
4447 instantiation of the class. The `DECL_TEMPLATE_SPECIALIZATIONS'
4448 contains partial specializations of the class.
4451 Back ends can safely ignore these nodes.
4455 File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations
4457 9.5.2 Internal structure
4458 ------------------------
4460 `DECL' nodes are represented internally as a hierarchy of structures.
4464 * Current structure hierarchy:: The current DECL node structure
4466 * Adding new DECL node types:: How to add a new DECL node to a
4470 File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure
4472 9.5.2.1 Current structure hierarchy
4473 ...................................
4475 `struct tree_decl_minimal'
4476 This is the minimal structure to inherit from in order for common
4477 `DECL' macros to work. The fields it contains are a unique ID,
4478 source location, context, and name.
4480 `struct tree_decl_common'
4481 This structure inherits from `struct tree_decl_minimal'. It
4482 contains fields that most `DECL' nodes need, such as a field to
4483 store alignment, machine mode, size, and attributes.
4485 `struct tree_field_decl'
4486 This structure inherits from `struct tree_decl_common'. It is
4487 used to represent `FIELD_DECL'.
4489 `struct tree_label_decl'
4490 This structure inherits from `struct tree_decl_common'. It is
4491 used to represent `LABEL_DECL'.
4493 `struct tree_translation_unit_decl'
4494 This structure inherits from `struct tree_decl_common'. It is
4495 used to represent `TRANSLATION_UNIT_DECL'.
4497 `struct tree_decl_with_rtl'
4498 This structure inherits from `struct tree_decl_common'. It
4499 contains a field to store the low-level RTL associated with a
4502 `struct tree_result_decl'
4503 This structure inherits from `struct tree_decl_with_rtl'. It is
4504 used to represent `RESULT_DECL'.
4506 `struct tree_const_decl'
4507 This structure inherits from `struct tree_decl_with_rtl'. It is
4508 used to represent `CONST_DECL'.
4510 `struct tree_parm_decl'
4511 This structure inherits from `struct tree_decl_with_rtl'. It is
4512 used to represent `PARM_DECL'.
4514 `struct tree_decl_with_vis'
4515 This structure inherits from `struct tree_decl_with_rtl'. It
4516 contains fields necessary to store visibility information, as well
4517 as a section name and assembler name.
4519 `struct tree_var_decl'
4520 This structure inherits from `struct tree_decl_with_vis'. It is
4521 used to represent `VAR_DECL'.
4523 `struct tree_function_decl'
4524 This structure inherits from `struct tree_decl_with_vis'. It is
4525 used to represent `FUNCTION_DECL'.
4529 File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure
4531 9.5.2.2 Adding new DECL node types
4532 ..................................
4534 Adding a new `DECL' tree consists of the following steps
4536 Add a new tree code for the `DECL' node
4537 For language specific `DECL' nodes, there is a `.def' file in each
4538 frontend directory where the tree code should be added. For
4539 `DECL' nodes that are part of the middle-end, the code should be
4540 added to `tree.def'.
4542 Create a new structure type for the `DECL' node
4543 These structures should inherit from one of the existing
4544 structures in the language hierarchy by using that structure as
4547 struct tree_foo_decl
4549 struct tree_decl_with_vis common;
4552 Would create a structure name `tree_foo_decl' that inherits from
4553 `struct tree_decl_with_vis'.
4555 For language specific `DECL' nodes, this new structure type should
4556 go in the appropriate `.h' file. For `DECL' nodes that are part
4557 of the middle-end, the structure type should go in `tree.h'.
4559 Add a member to the tree structure enumerator for the node
4560 For garbage collection and dynamic checking purposes, each `DECL'
4561 node structure type is required to have a unique enumerator value
4562 specified with it. For language specific `DECL' nodes, this new
4563 enumerator value should go in the appropriate `.def' file. For
4564 `DECL' nodes that are part of the middle-end, the enumerator
4565 values are specified in `treestruct.def'.
4567 Update `union tree_node'
4568 In order to make your new structure type usable, it must be added
4569 to `union tree_node'. For language specific `DECL' nodes, a new
4570 entry should be added to the appropriate `.h' file of the form
4571 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl;
4572 For `DECL' nodes that are part of the middle-end, the additional
4573 member goes directly into `union tree_node' in `tree.h'.
4575 Update dynamic checking info
4576 In order to be able to check whether accessing a named portion of
4577 `union tree_node' is legal, and whether a certain `DECL' node
4578 contains one of the enumerated `DECL' node structures in the
4579 hierarchy, a simple lookup table is used. This lookup table needs
4580 to be kept up to date with the tree structure hierarchy, or else
4581 checking and containment macros will fail inappropriately.
4583 For language specific `DECL' nodes, their is an `init_ts' function
4584 in an appropriate `.c' file, which initializes the lookup table.
4585 Code setting up the table for new `DECL' nodes should be added
4586 there. For each `DECL' tree code and enumerator value
4587 representing a member of the inheritance hierarchy, the table
4588 should contain 1 if that tree code inherits (directly or
4589 indirectly) from that member. Thus, a `FOO_DECL' node derived
4590 from `struct decl_with_rtl', and enumerator value `TS_FOO_DECL',
4591 would be set up as follows
4592 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1;
4593 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1;
4594 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1;
4595 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1;
4597 For `DECL' nodes that are part of the middle-end, the setup code
4600 Add macros to access any new fields and flags
4601 Each added field or flag should have a macro that is used to access
4602 it, that performs appropriate checking to ensure only the right
4603 type of `DECL' nodes access the field.
4605 These macros generally take the following form
4606 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname
4607 However, if the structure is simply a base class for further
4608 structures, something like the following should be used
4609 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT)
4610 #define BASE_STRUCT_FIELDNAME(NODE) \
4611 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname
4615 File: gccint.info, Node: Functions, Next: Declarations, Prev: Scopes, Up: Trees
4620 A function is represented by a `FUNCTION_DECL' node. A set of
4621 overloaded functions is sometimes represented by a `OVERLOAD' node.
4623 An `OVERLOAD' node is not a declaration, so none of the `DECL_' macros
4624 should be used on an `OVERLOAD'. An `OVERLOAD' node is similar to a
4625 `TREE_LIST'. Use `OVL_CURRENT' to get the function associated with an
4626 `OVERLOAD' node; use `OVL_NEXT' to get the next `OVERLOAD' node in the
4627 list of overloaded functions. The macros `OVL_CURRENT' and `OVL_NEXT'
4628 are actually polymorphic; you can use them to work with `FUNCTION_DECL'
4629 nodes as well as with overloads. In the case of a `FUNCTION_DECL',
4630 `OVL_CURRENT' will always return the function itself, and `OVL_NEXT'
4631 will always be `NULL_TREE'.
4633 To determine the scope of a function, you can use the `DECL_CONTEXT'
4634 macro. This macro will return the class (either a `RECORD_TYPE' or a
4635 `UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function
4636 is a member. For a virtual function, this macro returns the class in
4637 which the function was actually defined, not the base class in which
4638 the virtual declaration occurred.
4640 If a friend function is defined in a class scope, the
4641 `DECL_FRIEND_CONTEXT' macro can be used to determine the class in which
4642 it was defined. For example, in
4643 class C { friend void f() {} };
4644 the `DECL_CONTEXT' for `f' will be the `global_namespace', but the
4645 `DECL_FRIEND_CONTEXT' will be the `RECORD_TYPE' for `C'.
4647 In C, the `DECL_CONTEXT' for a function maybe another function. This
4648 representation indicates that the GNU nested function extension is in
4649 use. For details on the semantics of nested functions, see the GCC
4650 Manual. The nested function can refer to local variables in its
4651 containing function. Such references are not explicitly marked in the
4652 tree structure; back ends must look at the `DECL_CONTEXT' for the
4653 referenced `VAR_DECL'. If the `DECL_CONTEXT' for the referenced
4654 `VAR_DECL' is not the same as the function currently being processed,
4655 and neither `DECL_EXTERNAL' nor `DECL_STATIC' hold, then the reference
4656 is to a local variable in a containing function, and the back end must
4657 take appropriate action.
4661 * Function Basics:: Function names, linkage, and so forth.
4662 * Function Bodies:: The statements that make up a function body.
4665 File: gccint.info, Node: Function Basics, Next: Function Bodies, Up: Functions
4667 9.6.1 Function Basics
4668 ---------------------
4670 The following macros and functions can be used on a `FUNCTION_DECL':
4672 This predicate holds for a function that is the program entry point
4676 This macro returns the unqualified name of the function, as an
4677 `IDENTIFIER_NODE'. For an instantiation of a function template,
4678 the `DECL_NAME' is the unqualified name of the template, not
4679 something like `f<int>'. The value of `DECL_NAME' is undefined
4680 when used on a constructor, destructor, overloaded operator, or
4681 type-conversion operator, or any function that is implicitly
4682 generated by the compiler. See below for macros that can be used
4683 to distinguish these cases.
4685 `DECL_ASSEMBLER_NAME'
4686 This macro returns the mangled name of the function, also an
4687 `IDENTIFIER_NODE'. This name does not contain leading underscores
4688 on systems that prefix all identifiers with underscores. The
4689 mangled name is computed in the same way on all platforms; if
4690 special processing is required to deal with the object file format
4691 used on a particular platform, it is the responsibility of the
4692 back end to perform those modifications. (Of course, the back end
4693 should not modify `DECL_ASSEMBLER_NAME' itself.)
4695 Using `DECL_ASSEMBLER_NAME' will cause additional memory to be
4696 allocated (for the mangled name of the entity) so it should be used
4697 only when emitting assembly code. It should not be used within the
4698 optimizers to determine whether or not two declarations are the
4699 same, even though some of the existing optimizers do use it in
4700 that way. These uses will be removed over time.
4703 This predicate holds if the function is undefined.
4706 This predicate holds if the function has external linkage.
4708 `DECL_LOCAL_FUNCTION_P'
4709 This predicate holds if the function was declared at block scope,
4710 even though it has a global scope.
4713 This predicate holds if the function is a built-in function but its
4714 prototype is not yet explicitly declared.
4716 `DECL_EXTERN_C_FUNCTION_P'
4717 This predicate holds if the function is declared as an ``extern
4721 This macro holds if multiple copies of this function may be
4722 emitted in various translation units. It is the responsibility of
4723 the linker to merge the various copies. Template instantiations
4724 are the most common example of functions for which
4725 `DECL_LINKONCE_P' holds; G++ instantiates needed templates in all
4726 translation units which require them, and then relies on the
4727 linker to remove duplicate instantiations.
4729 FIXME: This macro is not yet implemented.
4731 `DECL_FUNCTION_MEMBER_P'
4732 This macro holds if the function is a member of a class, rather
4733 than a member of a namespace.
4735 `DECL_STATIC_FUNCTION_P'
4736 This predicate holds if the function a static member function.
4738 `DECL_NONSTATIC_MEMBER_FUNCTION_P'
4739 This macro holds for a non-static member function.
4741 `DECL_CONST_MEMFUNC_P'
4742 This predicate holds for a `const'-member function.
4744 `DECL_VOLATILE_MEMFUNC_P'
4745 This predicate holds for a `volatile'-member function.
4747 `DECL_CONSTRUCTOR_P'
4748 This macro holds if the function is a constructor.
4750 `DECL_NONCONVERTING_P'
4751 This predicate holds if the constructor is a non-converting
4754 `DECL_COMPLETE_CONSTRUCTOR_P'
4755 This predicate holds for a function which is a constructor for an
4756 object of a complete type.
4758 `DECL_BASE_CONSTRUCTOR_P'
4759 This predicate holds for a function which is a constructor for a
4760 base class sub-object.
4762 `DECL_COPY_CONSTRUCTOR_P'
4763 This predicate holds for a function which is a copy-constructor.
4766 This macro holds if the function is a destructor.
4768 `DECL_COMPLETE_DESTRUCTOR_P'
4769 This predicate holds if the function is the destructor for an
4770 object a complete type.
4772 `DECL_OVERLOADED_OPERATOR_P'
4773 This macro holds if the function is an overloaded operator.
4776 This macro holds if the function is a type-conversion operator.
4778 `DECL_GLOBAL_CTOR_P'
4779 This predicate holds if the function is a file-scope initialization
4782 `DECL_GLOBAL_DTOR_P'
4783 This predicate holds if the function is a file-scope finalization
4787 This predicate holds if the function is a thunk.
4789 These functions represent stub code that adjusts the `this' pointer
4790 and then jumps to another function. When the jumped-to function
4791 returns, control is transferred directly to the caller, without
4792 returning to the thunk. The first parameter to the thunk is
4793 always the `this' pointer; the thunk should add `THUNK_DELTA' to
4794 this value. (The `THUNK_DELTA' is an `int', not an `INTEGER_CST'.)
4796 Then, if `THUNK_VCALL_OFFSET' (an `INTEGER_CST') is nonzero the
4797 adjusted `this' pointer must be adjusted again. The complete
4798 calculation is given by the following pseudo-code:
4801 if (THUNK_VCALL_OFFSET)
4802 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET]
4804 Finally, the thunk should jump to the location given by
4805 `DECL_INITIAL'; this will always be an expression for the address
4808 `DECL_NON_THUNK_FUNCTION_P'
4809 This predicate holds if the function is _not_ a thunk function.
4811 `GLOBAL_INIT_PRIORITY'
4812 If either `DECL_GLOBAL_CTOR_P' or `DECL_GLOBAL_DTOR_P' holds, then
4813 this gives the initialization priority for the function. The
4814 linker will arrange that all functions for which
4815 `DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority
4816 before `main' is called. When the program exits, all functions for
4817 which `DECL_GLOBAL_DTOR_P' holds are run in the reverse order.
4820 This macro holds if the function was implicitly generated by the
4821 compiler, rather than explicitly declared. In addition to
4822 implicitly generated class member functions, this macro holds for
4823 the special functions created to implement static initialization
4824 and destruction, to compute run-time type information, and so
4828 This macro returns the `PARM_DECL' for the first argument to the
4829 function. Subsequent `PARM_DECL' nodes can be obtained by
4830 following the `TREE_CHAIN' links.
4833 This macro returns the `RESULT_DECL' for the function.
4836 This macro returns the `FUNCTION_TYPE' or `METHOD_TYPE' for the
4839 `TYPE_RAISES_EXCEPTIONS'
4840 This macro returns the list of exceptions that a (member-)function
4841 can raise. The returned list, if non `NULL', is comprised of nodes
4842 whose `TREE_VALUE' represents a type.
4845 This predicate holds when the exception-specification of its
4846 arguments if of the form ``()''.
4848 `DECL_ARRAY_DELETE_OPERATOR_P'
4849 This predicate holds if the function an overloaded `operator
4854 File: gccint.info, Node: Function Bodies, Prev: Function Basics, Up: Functions
4856 9.6.2 Function Bodies
4857 ---------------------
4859 A function that has a definition in the current translation unit will
4860 have a non-`NULL' `DECL_INITIAL'. However, back ends should not make
4861 use of the particular value given by `DECL_INITIAL'.
4863 The `DECL_SAVED_TREE' macro will give the complete body of the
4869 There are tree nodes corresponding to all of the source-level statement
4870 constructs, used within the C and C++ frontends. These are enumerated
4871 here, together with a list of the various macros that can be used to
4872 obtain information about them. There are a few macros that can be used
4873 with all statements:
4875 `STMT_IS_FULL_EXPR_P'
4876 In C++, statements normally constitute "full expressions";
4877 temporaries created during a statement are destroyed when the
4878 statement is complete. However, G++ sometimes represents
4879 expressions by statements; these statements will not have
4880 `STMT_IS_FULL_EXPR_P' set. Temporaries created during such
4881 statements should be destroyed when the innermost enclosing
4882 statement with `STMT_IS_FULL_EXPR_P' set is exited.
4885 Here is the list of the various statement nodes, and the macros used to
4886 access them. This documentation describes the use of these nodes in
4887 non-template functions (including instantiations of template functions).
4888 In template functions, the same nodes are used, but sometimes in
4889 slightly different ways.
4891 Many of the statements have substatements. For example, a `while'
4892 loop will have a body, which is itself a statement. If the substatement
4893 is `NULL_TREE', it is considered equivalent to a statement consisting
4894 of a single `;', i.e., an expression statement in which the expression
4895 has been omitted. A substatement may in fact be a list of statements,
4896 connected via their `TREE_CHAIN's. So, you should always process the
4897 statement tree by looping over substatements, like this:
4898 void process_stmt (stmt)
4903 switch (TREE_CODE (stmt))
4906 process_stmt (THEN_CLAUSE (stmt));
4907 /* More processing here. */
4913 stmt = TREE_CHAIN (stmt);
4916 In other words, while the `then' clause of an `if' statement in C++
4917 can be only one statement (although that one statement may be a
4918 compound statement), the intermediate representation will sometimes use
4919 several statements chained together.
4922 Used to represent an inline assembly statement. For an inline
4923 assembly statement like:
4925 The `ASM_STRING' macro will return a `STRING_CST' node for `"mov
4926 x, y"'. If the original statement made use of the
4927 extended-assembly syntax, then `ASM_OUTPUTS', `ASM_INPUTS', and
4928 `ASM_CLOBBERS' will be the outputs, inputs, and clobbers for the
4929 statement, represented as `STRING_CST' nodes. The
4930 extended-assembly syntax looks like:
4931 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
4932 The first string is the `ASM_STRING', containing the instruction
4933 template. The next two strings are the output and inputs,
4934 respectively; this statement has no clobbers. As this example
4935 indicates, "plain" assembly statements are merely a special case
4936 of extended assembly statements; they have no cv-qualifiers,
4937 outputs, inputs, or clobbers. All of the strings will be
4938 `NUL'-terminated, and will contain no embedded `NUL'-characters.
4940 If the assembly statement is declared `volatile', or if the
4941 statement was not an extended assembly statement, and is therefore
4942 implicitly volatile, then the predicate `ASM_VOLATILE_P' will hold
4946 Used to represent a `break' statement. There are no additional
4950 Use to represent a `case' label, range of `case' labels, or a
4951 `default' label. If `CASE_LOW' is `NULL_TREE', then this is a
4952 `default' label. Otherwise, if `CASE_HIGH' is `NULL_TREE', then
4953 this is an ordinary `case' label. In this case, `CASE_LOW' is an
4954 expression giving the value of the label. Both `CASE_LOW' and
4955 `CASE_HIGH' are `INTEGER_CST' nodes. These values will have the
4956 same type as the condition expression in the switch statement.
4958 Otherwise, if both `CASE_LOW' and `CASE_HIGH' are defined, the
4959 statement is a range of case labels. Such statements originate
4960 with the extension that allows users to write things of the form:
4962 The first value will be `CASE_LOW', while the second will be
4966 Used to represent an action that should take place upon exit from
4967 the enclosing scope. Typically, these actions are calls to
4968 destructors for local objects, but back ends cannot rely on this
4969 fact. If these nodes are in fact representing such destructors,
4970 `CLEANUP_DECL' will be the `VAR_DECL' destroyed. Otherwise,
4971 `CLEANUP_DECL' will be `NULL_TREE'. In any case, the
4972 `CLEANUP_EXPR' is the expression to execute. The cleanups
4973 executed on exit from a scope should be run in the reverse order
4974 of the order in which the associated `CLEANUP_STMT's were
4978 Used to represent a `continue' statement. There are no additional
4982 Used to mark the beginning (if `CTOR_BEGIN_P' holds) or end (if
4983 `CTOR_END_P' holds of the main body of a constructor. See also
4984 `SUBOBJECT' for more information on how to use these nodes.
4987 Used to represent a local declaration. The `DECL_STMT_DECL' macro
4988 can be used to obtain the entity declared. This declaration may
4989 be a `LABEL_DECL', indicating that the label declared is a local
4990 label. (As an extension, GCC allows the declaration of labels
4991 with scope.) In C, this declaration may be a `FUNCTION_DECL',
4992 indicating the use of the GCC nested function extension. For more
4993 information, *note Functions::.
4996 Used to represent a `do' loop. The body of the loop is given by
4997 `DO_BODY' while the termination condition for the loop is given by
4998 `DO_COND'. The condition for a `do'-statement is always an
5002 Used to represent a temporary object of a class with no data whose
5003 address is never taken. (All such objects are interchangeable.)
5004 The `TREE_TYPE' represents the type of the object.
5007 Used to represent an expression statement. Use `EXPR_STMT_EXPR' to
5008 obtain the expression.
5011 Used to represent a `for' statement. The `FOR_INIT_STMT' is the
5012 initialization statement for the loop. The `FOR_COND' is the
5013 termination condition. The `FOR_EXPR' is the expression executed
5014 right before the `FOR_COND' on each loop iteration; often, this
5015 expression increments a counter. The body of the loop is given by
5016 `FOR_BODY'. Note that `FOR_INIT_STMT' and `FOR_BODY' return
5017 statements, while `FOR_COND' and `FOR_EXPR' return expressions.
5020 Used to represent a `goto' statement. The `GOTO_DESTINATION' will
5021 usually be a `LABEL_DECL'. However, if the "computed goto"
5022 extension has been used, the `GOTO_DESTINATION' will be an
5023 arbitrary expression indicating the destination. This expression
5024 will always have pointer type.
5027 Used to represent a C++ `catch' block. The `HANDLER_TYPE' is the
5028 type of exception that will be caught by this handler; it is equal
5029 (by pointer equality) to `NULL' if this handler is for all types.
5030 `HANDLER_PARMS' is the `DECL_STMT' for the catch parameter, and
5031 `HANDLER_BODY' is the code for the block itself.
5034 Used to represent an `if' statement. The `IF_COND' is the
5037 If the condition is a `TREE_LIST', then the `TREE_PURPOSE' is a
5038 statement (usually a `DECL_STMT'). Each time the condition is
5039 evaluated, the statement should be executed. Then, the
5040 `TREE_VALUE' should be used as the conditional expression itself.
5041 This representation is used to handle C++ code like this:
5045 where there is a new local variable (or variables) declared within
5048 The `THEN_CLAUSE' represents the statement given by the `then'
5049 condition, while the `ELSE_CLAUSE' represents the statement given
5050 by the `else' condition.
5053 Used to represent a label. The `LABEL_DECL' declared by this
5054 statement can be obtained with the `LABEL_EXPR_LABEL' macro. The
5055 `IDENTIFIER_NODE' giving the name of the label can be obtained from
5056 the `LABEL_DECL' with `DECL_NAME'.
5059 If the function uses the G++ "named return value" extension,
5060 meaning that the function has been defined like:
5061 S f(int) return s {...}
5062 then there will be a `RETURN_INIT'. There is never a named
5063 returned value for a constructor. The first argument to the
5064 `RETURN_INIT' is the name of the object returned; the second
5065 argument is the initializer for the object. The object is
5066 initialized when the `RETURN_INIT' is encountered. The object
5067 referred to is the actual object returned; this extension is a
5068 manual way of doing the "return-value optimization". Therefore,
5069 the object must actually be constructed in the place where the
5070 object will be returned.
5073 Used to represent a `return' statement. The `RETURN_EXPR' is the
5074 expression returned; it will be `NULL_TREE' if the statement was
5079 In a constructor, these nodes are used to mark the point at which a
5080 subobject of `this' is fully constructed. If, after this point, an
5081 exception is thrown before a `CTOR_STMT' with `CTOR_END_P' set is
5082 encountered, the `SUBOBJECT_CLEANUP' must be executed. The
5083 cleanups must be executed in the reverse order in which they
5087 Used to represent a `switch' statement. The `SWITCH_STMT_COND' is
5088 the expression on which the switch is occurring. See the
5089 documentation for an `IF_STMT' for more information on the
5090 representation used for the condition. The `SWITCH_STMT_BODY' is
5091 the body of the switch statement. The `SWITCH_STMT_TYPE' is the
5092 original type of switch expression as given in the source, before
5093 any compiler conversions.
5096 Used to represent a `try' block. The body of the try block is
5097 given by `TRY_STMTS'. Each of the catch blocks is a `HANDLER'
5098 node. The first handler is given by `TRY_HANDLERS'. Subsequent
5099 handlers are obtained by following the `TREE_CHAIN' link from one
5100 handler to the next. The body of the handler is given by
5103 If `CLEANUP_P' holds of the `TRY_BLOCK', then the `TRY_HANDLERS'
5104 will not be a `HANDLER' node. Instead, it will be an expression
5105 that should be executed if an exception is thrown in the try
5106 block. It must rethrow the exception after executing that code.
5107 And, if an exception is thrown while the expression is executing,
5108 `terminate' must be called.
5111 Used to represent a `using' directive. The namespace is given by
5112 `USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node
5113 is needed inside template functions, to implement using directives
5114 during instantiation.
5117 Used to represent a `while' loop. The `WHILE_COND' is the
5118 termination condition for the loop. See the documentation for an
5119 `IF_STMT' for more information on the representation used for the
5122 The `WHILE_BODY' is the body of the loop.
5126 File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: Trees
5128 9.7 Attributes in trees
5129 =======================
5131 Attributes, as specified using the `__attribute__' keyword, are
5132 represented internally as a `TREE_LIST'. The `TREE_PURPOSE' is the
5133 name of the attribute, as an `IDENTIFIER_NODE'. The `TREE_VALUE' is a
5134 `TREE_LIST' of the arguments of the attribute, if any, or `NULL_TREE'
5135 if there are no arguments; the arguments are stored as the `TREE_VALUE'
5136 of successive entries in the list, and may be identifiers or
5137 expressions. The `TREE_CHAIN' of the attribute is the next attribute
5138 in a list of attributes applying to the same declaration or type, or
5139 `NULL_TREE' if there are no further attributes in the list.
5141 Attributes may be attached to declarations and to types; these
5142 attributes may be accessed with the following macros. All attributes
5143 are stored in this way, and many also cause other changes to the
5144 declaration or type or to other internal compiler data structures.
5146 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL)
5147 This macro returns the attributes on the declaration DECL.
5149 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE)
5150 This macro returns the attributes on the type TYPE.
5153 File: gccint.info, Node: Expression trees, Prev: Attributes, Up: Trees
5158 The internal representation for expressions is for the most part quite
5159 straightforward. However, there are a few facts that one must bear in
5160 mind. In particular, the expression "tree" is actually a directed
5161 acyclic graph. (For example there may be many references to the integer
5162 constant zero throughout the source program; many of these will be
5163 represented by the same expression node.) You should not rely on
5164 certain kinds of node being shared, nor should rely on certain kinds of
5165 nodes being unshared.
5167 The following macros can be used with all expression nodes:
5170 Returns the type of the expression. This value may not be
5171 precisely the same type that would be given the expression in the
5174 In what follows, some nodes that one might expect to always have type
5175 `bool' are documented to have either integral or boolean type. At some
5176 point in the future, the C front end may also make use of this same
5177 intermediate representation, and at this point these nodes will
5178 certainly have integral type. The previous sentence is not meant to
5179 imply that the C++ front end does not or will not give these nodes
5182 Below, we list the various kinds of expression nodes. Except where
5183 noted otherwise, the operands to an expression are accessed using the
5184 `TREE_OPERAND' macro. For example, to access the first operand to a
5185 binary plus expression `expr', use:
5187 TREE_OPERAND (expr, 0)
5188 As this example indicates, the operands are zero-indexed.
5190 The table below begins with constants, moves on to unary expressions,
5191 then proceeds to binary expressions, and concludes with various other
5192 kinds of expressions:
5195 These nodes represent integer constants. Note that the type of
5196 these constants is obtained with `TREE_TYPE'; they are not always
5197 of type `int'. In particular, `char' constants are represented
5198 with `INTEGER_CST' nodes. The value of the integer constant `e' is
5200 ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT)
5201 + TREE_INST_CST_LOW (e))
5202 HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms.
5203 Both `TREE_INT_CST_HIGH' and `TREE_INT_CST_LOW' return a
5204 `HOST_WIDE_INT'. The value of an `INTEGER_CST' is interpreted as
5205 a signed or unsigned quantity depending on the type of the
5206 constant. In general, the expression given above will overflow,
5207 so it should not be used to calculate the value of the constant.
5209 The variable `integer_zero_node' is an integer constant with value
5210 zero. Similarly, `integer_one_node' is an integer constant with
5211 value one. The `size_zero_node' and `size_one_node' variables are
5212 analogous, but have type `size_t' rather than `int'.
5214 The function `tree_int_cst_lt' is a predicate which holds if its
5215 first argument is less than its second. Both constants are
5216 assumed to have the same signedness (i.e., either both should be
5217 signed or both should be unsigned.) The full width of the
5218 constant is used when doing the comparison; the usual rules about
5219 promotions and conversions are ignored. Similarly,
5220 `tree_int_cst_equal' holds if the two constants are equal. The
5221 `tree_int_cst_sgn' function returns the sign of a constant. The
5222 value is `1', `0', or `-1' according on whether the constant is
5223 greater than, equal to, or less than zero. Again, the signedness
5224 of the constant's type is taken into account; an unsigned constant
5225 is never less than zero, no matter what its bit-pattern.
5228 FIXME: Talk about how to obtain representations of this constant,
5229 do comparisons, and so forth.
5232 These nodes are used to represent complex number constants, that
5233 is a `__complex__' whose parts are constant nodes. The
5234 `TREE_REALPART' and `TREE_IMAGPART' return the real and the
5235 imaginary parts respectively.
5238 These nodes are used to represent vector constants, whose parts are
5239 constant nodes. Each individual constant node is either an
5240 integer or a double constant node. The first operand is a
5241 `TREE_LIST' of the constant nodes and is accessed through
5242 `TREE_VECTOR_CST_ELTS'.
5245 These nodes represent string-constants. The `TREE_STRING_LENGTH'
5246 returns the length of the string, as an `int'. The
5247 `TREE_STRING_POINTER' is a `char*' containing the string itself.
5248 The string may not be `NUL'-terminated, and it may contain
5249 embedded `NUL' characters. Therefore, the `TREE_STRING_LENGTH'
5250 includes the trailing `NUL' if it is present.
5252 For wide string constants, the `TREE_STRING_LENGTH' is the number
5253 of bytes in the string, and the `TREE_STRING_POINTER' points to an
5254 array of the bytes of the string, as represented on the target
5255 system (that is, as integers in the target endianness). Wide and
5256 non-wide string constants are distinguished only by the `TREE_TYPE'
5257 of the `STRING_CST'.
5259 FIXME: The formats of string constants are not well-defined when
5260 the target system bytes are not the same width as host system
5264 These nodes are used to represent pointer-to-member constants. The
5265 `PTRMEM_CST_CLASS' is the class type (either a `RECORD_TYPE' or
5266 `UNION_TYPE' within which the pointer points), and the
5267 `PTRMEM_CST_MEMBER' is the declaration for the pointed to object.
5268 Note that the `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is in
5269 general different from the `PTRMEM_CST_CLASS'. For example, given:
5270 struct B { int i; };
5271 struct D : public B {};
5273 The `PTRMEM_CST_CLASS' for `&D::i' is `D', even though the
5274 `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is `B', since `B::i' is
5275 a member of `B', not `D'.
5278 These nodes represent variables, including static data members.
5279 For more information, *note Declarations::.
5282 These nodes represent unary negation of the single operand, for
5283 both integer and floating-point types. The type of negation can be
5284 determined by looking at the type of the expression.
5286 The behavior of this operation on signed arithmetic overflow is
5287 controlled by the `flag_wrapv' and `flag_trapv' variables.
5290 These nodes represent the absolute value of the single operand, for
5291 both integer and floating-point types. This is typically used to
5292 implement the `abs', `labs' and `llabs' builtins for integer
5293 types, and the `fabs', `fabsf' and `fabsl' builtins for floating
5294 point types. The type of abs operation can be determined by
5295 looking at the type of the expression.
5297 This node is not used for complex types. To represent the modulus
5298 or complex abs of a complex value, use the `BUILT_IN_CABS',
5299 `BUILT_IN_CABSF' or `BUILT_IN_CABSL' builtins, as used to
5300 implement the C99 `cabs', `cabsf' and `cabsl' built-in functions.
5303 These nodes represent bitwise complement, and will always have
5304 integral type. The only operand is the value to be complemented.
5307 These nodes represent logical negation, and will always have
5308 integral (or boolean) type. The operand is the value being
5309 negated. The type of the operand and that of the result are
5310 always of `BOOLEAN_TYPE' or `INTEGER_TYPE'.
5314 `POSTDECREMENT_EXPR'
5315 `POSTINCREMENT_EXPR'
5316 These nodes represent increment and decrement expressions. The
5317 value of the single operand is computed, and the operand
5318 incremented or decremented. In the case of `PREDECREMENT_EXPR' and
5319 `PREINCREMENT_EXPR', the value of the expression is the value
5320 resulting after the increment or decrement; in the case of
5321 `POSTDECREMENT_EXPR' and `POSTINCREMENT_EXPR' is the value before
5322 the increment or decrement occurs. The type of the operand, like
5323 that of the result, will be either integral, boolean, or
5327 These nodes are used to represent the address of an object. (These
5328 expressions will always have pointer or reference type.) The
5329 operand may be another expression, or it may be a declaration.
5331 As an extension, GCC allows users to take the address of a label.
5332 In this case, the operand of the `ADDR_EXPR' will be a
5333 `LABEL_DECL'. The type of such an expression is `void*'.
5335 If the object addressed is not an lvalue, a temporary is created,
5336 and the address of the temporary is used.
5339 These nodes are used to represent the object pointed to by a
5340 pointer. The operand is the pointer being dereferenced; it will
5341 always have pointer or reference type.
5344 These nodes represent conversion of a floating-point value to an
5345 integer. The single operand will have a floating-point type, while
5346 the complete expression will have an integral (or boolean) type.
5347 The operand is rounded towards zero.
5350 These nodes represent conversion of an integral (or boolean) value
5351 to a floating-point value. The single operand will have integral
5352 type, while the complete expression will have a floating-point
5355 FIXME: How is the operand supposed to be rounded? Is this
5356 dependent on `-mieee'?
5359 These nodes are used to represent complex numbers constructed from
5360 two expressions of the same (integer or real) type. The first
5361 operand is the real part and the second operand is the imaginary
5365 These nodes represent the conjugate of their operand.
5369 These nodes represent respectively the real and the imaginary parts
5370 of complex numbers (their sole argument).
5373 These nodes indicate that their one and only operand is not an
5374 lvalue. A back end can treat these identically to the single
5378 These nodes are used to represent conversions that do not require
5379 any code-generation. For example, conversion of a `char*' to an
5380 `int*' does not require any code be generated; such a conversion is
5381 represented by a `NOP_EXPR'. The single operand is the expression
5382 to be converted. The conversion from a pointer to a reference is
5383 also represented with a `NOP_EXPR'.
5386 These nodes are similar to `NOP_EXPR's, but are used in those
5387 situations where code may need to be generated. For example, if an
5388 `int*' is converted to an `int' code may need to be generated on
5389 some platforms. These nodes are never used for C++-specific
5390 conversions, like conversions between pointers to different
5391 classes in an inheritance hierarchy. Any adjustments that need to
5392 be made in such cases are always indicated explicitly. Similarly,
5393 a user-defined conversion is never represented by a
5394 `CONVERT_EXPR'; instead, the function calls are made explicit.
5397 These nodes represent `throw' expressions. The single operand is
5398 an expression for the code that should be executed to throw the
5399 exception. However, there is one implicit action not represented
5400 in that expression; namely the call to `__throw'. This function
5401 takes no arguments. If `setjmp'/`longjmp' exceptions are used, the
5402 function `__sjthrow' is called instead. The normal GCC back end
5403 uses the function `emit_throw' to generate this code; you can
5404 examine this function to see what needs to be done.
5408 These nodes represent left and right shifts, respectively. The
5409 first operand is the value to shift; it will always be of integral
5410 type. The second operand is an expression for the number of bits
5411 by which to shift. Right shift should be treated as arithmetic,
5412 i.e., the high-order bits should be zero-filled when the
5413 expression has unsigned type and filled with the sign bit when the
5414 expression has signed type. Note that the result is undefined if
5415 the second operand is larger than or equal to the first operand's
5421 These nodes represent bitwise inclusive or, bitwise exclusive or,
5422 and bitwise and, respectively. Both operands will always have
5427 These nodes represent logical and and logical or, respectively.
5428 These operators are not strict; i.e., the second operand is
5429 evaluated only if the value of the expression is not determined by
5430 evaluation of the first operand. The type of the operands and
5431 that of the result are always of `BOOLEAN_TYPE' or `INTEGER_TYPE'.
5436 These nodes represent logical and, logical or, and logical
5437 exclusive or. They are strict; both arguments are always
5438 evaluated. There are no corresponding operators in C or C++, but
5439 the front end will sometimes generate these expressions anyhow, if
5440 it can tell that strictness does not matter. The type of the
5441 operands and that of the result are always of `BOOLEAN_TYPE' or
5447 These nodes represent various binary arithmetic operations.
5448 Respectively, these operations are addition, subtraction (of the
5449 second operand from the first) and multiplication. Their operands
5450 may have either integral or floating type, but there will never be
5451 case in which one operand is of floating type and the other is of
5454 The behavior of these operations on signed arithmetic overflow is
5455 controlled by the `flag_wrapv' and `flag_trapv' variables.
5458 This node represents a floating point division operation.
5464 These nodes represent integer division operations that return an
5465 integer result. `TRUNC_DIV_EXPR' rounds towards zero,
5466 `FLOOR_DIV_EXPR' rounds towards negative infinity, `CEIL_DIV_EXPR'
5467 rounds towards positive infinity and `ROUND_DIV_EXPR' rounds to
5468 the closest integer. Integer division in C and C++ is truncating,
5469 i.e. `TRUNC_DIV_EXPR'.
5471 The behavior of these operations on signed arithmetic overflow,
5472 when dividing the minimum signed integer by minus one, is
5473 controlled by the `flag_wrapv' and `flag_trapv' variables.
5479 These nodes represent the integer remainder or modulus operation.
5480 The integer modulus of two operands `a' and `b' is defined as `a -
5481 (a/b)*b' where the division calculated using the corresponding
5482 division operator. Hence for `TRUNC_MOD_EXPR' this definition
5483 assumes division using truncation towards zero, i.e.
5484 `TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating
5485 division, i.e. `TRUNC_MOD_EXPR'.
5488 The `EXACT_DIV_EXPR' code is used to represent integer divisions
5489 where the numerator is known to be an exact multiple of the
5490 denominator. This allows the backend to choose between the faster
5491 of `TRUNC_DIV_EXPR', `CEIL_DIV_EXPR' and `FLOOR_DIV_EXPR' for the
5495 These nodes represent array accesses. The first operand is the
5496 array; the second is the index. To calculate the address of the
5497 memory accessed, you must scale the index by the size of the type
5498 of the array elements. The type of these expressions must be the
5499 type of a component of the array. The third and fourth operands
5500 are used after gimplification to represent the lower bound and
5501 component size but should not be used directly; call
5502 `array_ref_low_bound' and `array_ref_element_size' instead.
5505 These nodes represent access to a range (or "slice") of an array.
5506 The operands are the same as that for `ARRAY_REF' and have the same
5507 meanings. The type of these expressions must be an array whose
5508 component type is the same as that of the first operand. The
5509 range of that array type determines the amount of data these
5513 These nodes represent memory accesses whose address directly map to
5514 an addressing mode of the target architecture. The first argument
5515 is `TMR_SYMBOL' and must be a `VAR_DECL' of an object with a fixed
5516 address. The second argument is `TMR_BASE' and the third one is
5517 `TMR_INDEX'. The fourth argument is `TMR_STEP' and must be an
5518 `INTEGER_CST'. The fifth argument is `TMR_OFFSET' and must be an
5519 `INTEGER_CST'. Any of the arguments may be NULL if the
5520 appropriate component does not appear in the address. Address of
5521 the `TARGET_MEM_REF' is determined in the following way.
5523 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET
5525 The sixth argument is the reference to the original memory access,
5526 which is preserved for the purposes of the RTL alias analysis.
5527 The seventh argument is a tag representing the results of tree
5528 level alias analysis.
5536 These nodes represent the less than, less than or equal to, greater
5537 than, greater than or equal to, equal, and not equal comparison
5538 operators. The first and second operand with either be both of
5539 integral type or both of floating type. The result type of these
5540 expressions will always be of integral or boolean type. These
5541 operations return the result type's zero value for false, and the
5542 result type's one value for true.
5544 For floating point comparisons, if we honor IEEE NaNs and either
5545 operand is NaN, then `NE_EXPR' always returns true and the
5546 remaining operators always return false. On some targets,
5547 comparisons against an IEEE NaN, other than equality and
5548 inequality, may generate a floating point exception.
5552 These nodes represent non-trapping ordered and unordered comparison
5553 operators. These operations take two floating point operands and
5554 determine whether they are ordered or unordered relative to each
5555 other. If either operand is an IEEE NaN, their comparison is
5556 defined to be unordered, otherwise the comparison is defined to be
5557 ordered. The result type of these expressions will always be of
5558 integral or boolean type. These operations return the result
5559 type's zero value for false, and the result type's one value for
5568 These nodes represent the unordered comparison operators. These
5569 operations take two floating point operands and determine whether
5570 the operands are unordered or are less than, less than or equal to,
5571 greater than, greater than or equal to, or equal respectively. For
5572 example, `UNLT_EXPR' returns true if either operand is an IEEE NaN
5573 or the first operand is less than the second. With the possible
5574 exception of `LTGT_EXPR', all of these operations are guaranteed
5575 not to generate a floating point exception. The result type of
5576 these expressions will always be of integral or boolean type.
5577 These operations return the result type's zero value for false,
5578 and the result type's one value for true.
5581 These nodes represent assignment. The left-hand side is the first
5582 operand; the right-hand side is the second operand. The left-hand
5583 side will be a `VAR_DECL', `INDIRECT_REF', `COMPONENT_REF', or
5586 These nodes are used to represent not only assignment with `=' but
5587 also compound assignments (like `+='), by reduction to `='
5588 assignment. In other words, the representation for `i += 3' looks
5589 just like that for `i = i + 3'.
5592 These nodes are just like `MODIFY_EXPR', but are used only when a
5593 variable is initialized, rather than assigned to subsequently.
5594 This means that we can assume that the target of the
5595 initialization is not used in computing its own value; any
5596 reference to the lhs in computing the rhs is undefined.
5599 These nodes represent non-static data member accesses. The first
5600 operand is the object (rather than a pointer to it); the second
5601 operand is the `FIELD_DECL' for the data member. The third
5602 operand represents the byte offset of the field, but should not be
5603 used directly; call `component_ref_field_offset' instead.
5606 These nodes represent comma-expressions. The first operand is an
5607 expression whose value is computed and thrown away prior to the
5608 evaluation of the second operand. The value of the entire
5609 expression is the value of the second operand.
5612 These nodes represent `?:' expressions. The first operand is of
5613 boolean or integral type. If it evaluates to a nonzero value, the
5614 second operand should be evaluated, and returned as the value of
5615 the expression. Otherwise, the third operand is evaluated, and
5616 returned as the value of the expression.
5618 The second operand must have the same type as the entire
5619 expression, unless it unconditionally throws an exception or calls
5620 a noreturn function, in which case it should have void type. The
5621 same constraints apply to the third operand. This allows array
5622 bounds checks to be represented conveniently as `(i >= 0 && i <
5625 As a GNU extension, the C language front-ends allow the second
5626 operand of the `?:' operator may be omitted in the source. For
5627 example, `x ? : 3' is equivalent to `x ? x : 3', assuming that `x'
5628 is an expression without side-effects. In the tree
5629 representation, however, the second operand is always present,
5630 possibly protected by `SAVE_EXPR' if the first argument does cause
5634 These nodes are used to represent calls to functions, including
5635 non-static member functions. The first operand is a pointer to the
5636 function to call; it is always an expression whose type is a
5637 `POINTER_TYPE'. The second argument is a `TREE_LIST'. The
5638 arguments to the call appear left-to-right in the list. The
5639 `TREE_VALUE' of each list node contains the expression
5640 corresponding to that argument. (The value of `TREE_PURPOSE' for
5641 these nodes is unspecified, and should be ignored.) For non-static
5642 member functions, there will be an operand corresponding to the
5643 `this' pointer. There will always be expressions corresponding to
5644 all of the arguments, even if the function is declared with default
5645 arguments and some arguments are not explicitly provided at the
5649 These nodes are used to represent GCC's statement-expression
5650 extension. The statement-expression extension allows code like
5652 int f() { return ({ int j; j = 3; j + 7; }); }
5653 In other words, an sequence of statements may occur where a single
5654 expression would normally appear. The `STMT_EXPR' node represents
5655 such an expression. The `STMT_EXPR_STMT' gives the statement
5656 contained in the expression. The value of the expression is the
5657 value of the last sub-statement in the body. More precisely, the
5658 value is the value computed by the last statement nested inside
5659 `BIND_EXPR', `TRY_FINALLY_EXPR', or `TRY_CATCH_EXPR'. For
5662 the value is `3' while in:
5664 there is no value. If the `STMT_EXPR' does not yield a value,
5665 it's type will be `void'.
5668 These nodes represent local blocks. The first operand is a list of
5669 variables, connected via their `TREE_CHAIN' field. These will
5670 never require cleanups. The scope of these variables is just the
5671 body of the `BIND_EXPR'. The body of the `BIND_EXPR' is the
5675 These nodes represent "infinite" loops. The `LOOP_EXPR_BODY'
5676 represents the body of the loop. It should be executed forever,
5677 unless an `EXIT_EXPR' is encountered.
5680 These nodes represent conditional exits from the nearest enclosing
5681 `LOOP_EXPR'. The single operand is the condition; if it is
5682 nonzero, then the loop should be exited. An `EXIT_EXPR' will only
5683 appear within a `LOOP_EXPR'.
5685 `CLEANUP_POINT_EXPR'
5686 These nodes represent full-expressions. The single operand is an
5687 expression to evaluate. Any destructor calls engendered by the
5688 creation of temporaries during the evaluation of that expression
5689 should be performed immediately after the expression is evaluated.
5692 These nodes represent the brace-enclosed initializers for a
5693 structure or array. The first operand is reserved for use by the
5694 back end. The second operand is a `TREE_LIST'. If the
5695 `TREE_TYPE' of the `CONSTRUCTOR' is a `RECORD_TYPE' or
5696 `UNION_TYPE', then the `TREE_PURPOSE' of each node in the
5697 `TREE_LIST' will be a `FIELD_DECL' and the `TREE_VALUE' of each
5698 node will be the expression used to initialize that field.
5700 If the `TREE_TYPE' of the `CONSTRUCTOR' is an `ARRAY_TYPE', then
5701 the `TREE_PURPOSE' of each element in the `TREE_LIST' will be an
5702 `INTEGER_CST' or a `RANGE_EXPR' of two `INTEGER_CST's. A single
5703 `INTEGER_CST' indicates which element of the array (indexed from
5704 zero) is being assigned to. A `RANGE_EXPR' indicates an inclusive
5705 range of elements to initialize. In both cases the `TREE_VALUE'
5706 is the corresponding initializer. It is re-evaluated for each
5707 element of a `RANGE_EXPR'. If the `TREE_PURPOSE' is `NULL_TREE',
5708 then the initializer is for the next available array element.
5710 In the front end, you should not depend on the fields appearing in
5711 any particular order. However, in the middle end, fields must
5712 appear in declaration order. You should not assume that all
5713 fields will be represented. Unrepresented fields will be set to
5716 `COMPOUND_LITERAL_EXPR'
5717 These nodes represent ISO C99 compound literals. The
5718 `COMPOUND_LITERAL_EXPR_DECL_STMT' is a `DECL_STMT' containing an
5719 anonymous `VAR_DECL' for the unnamed object represented by the
5720 compound literal; the `DECL_INITIAL' of that `VAR_DECL' is a
5721 `CONSTRUCTOR' representing the brace-enclosed list of initializers
5722 in the compound literal. That anonymous `VAR_DECL' can also be
5723 accessed directly by the `COMPOUND_LITERAL_EXPR_DECL' macro.
5726 A `SAVE_EXPR' represents an expression (possibly involving
5727 side-effects) that is used more than once. The side-effects should
5728 occur only the first time the expression is evaluated. Subsequent
5729 uses should just reuse the computed value. The first operand to
5730 the `SAVE_EXPR' is the expression to evaluate. The side-effects
5731 should be executed where the `SAVE_EXPR' is first encountered in a
5732 depth-first preorder traversal of the expression tree.
5735 A `TARGET_EXPR' represents a temporary object. The first operand
5736 is a `VAR_DECL' for the temporary variable. The second operand is
5737 the initializer for the temporary. The initializer is evaluated
5738 and, if non-void, copied (bitwise) into the temporary. If the
5739 initializer is void, that means that it will perform the
5740 initialization itself.
5742 Often, a `TARGET_EXPR' occurs on the right-hand side of an
5743 assignment, or as the second operand to a comma-expression which is
5744 itself the right-hand side of an assignment, etc. In this case,
5745 we say that the `TARGET_EXPR' is "normal"; otherwise, we say it is
5746 "orphaned". For a normal `TARGET_EXPR' the temporary variable
5747 should be treated as an alias for the left-hand side of the
5748 assignment, rather than as a new temporary variable.
5750 The third operand to the `TARGET_EXPR', if present, is a
5751 cleanup-expression (i.e., destructor call) for the temporary. If
5752 this expression is orphaned, then this expression must be executed
5753 when the statement containing this expression is complete. These
5754 cleanups must always be executed in the order opposite to that in
5755 which they were encountered. Note that if a temporary is created
5756 on one branch of a conditional operator (i.e., in the second or
5757 third operand to a `COND_EXPR'), the cleanup must be run only if
5758 that branch is actually executed.
5760 See `STMT_IS_FULL_EXPR_P' for more information about running these
5764 An `AGGR_INIT_EXPR' represents the initialization as the return
5765 value of a function call, or as the result of a constructor. An
5766 `AGGR_INIT_EXPR' will only appear as a full-expression, or as the
5767 second operand of a `TARGET_EXPR'. The first operand to the
5768 `AGGR_INIT_EXPR' is the address of a function to call, just as in
5769 a `CALL_EXPR'. The second operand are the arguments to pass that
5770 function, as a `TREE_LIST', again in a manner similar to that of a
5773 If `AGGR_INIT_VIA_CTOR_P' holds of the `AGGR_INIT_EXPR', then the
5774 initialization is via a constructor call. The address of the third
5775 operand of the `AGGR_INIT_EXPR', which is always a `VAR_DECL', is
5776 taken, and this value replaces the first argument in the argument
5779 In either case, the expression is void.
5782 This node is used to implement support for the C/C++ variable
5783 argument-list mechanism. It represents expressions like `va_arg
5784 (ap, type)'. Its `TREE_TYPE' yields the tree representation for
5785 `type' and its sole argument yields the representation for `ap'.
5789 File: gccint.info, Node: Tree SSA, Next: Machine Desc, Prev: Control Flow, Up: Top
5791 10 Analysis and Optimization of GIMPLE Trees
5792 ********************************************
5794 GCC uses three main intermediate languages to represent the program
5795 during compilation: GENERIC, GIMPLE and RTL. GENERIC is a
5796 language-independent representation generated by each front end. It is
5797 used to serve as an interface between the parser and optimizer.
5798 GENERIC is a common representation that is able to represent programs
5799 written in all the languages supported by GCC.
5801 GIMPLE and RTL are used to optimize the program. GIMPLE is used for
5802 target and language independent optimizations (e.g., inlining, constant
5803 propagation, tail call elimination, redundancy elimination, etc). Much
5804 like GENERIC, GIMPLE is a language independent, tree based
5805 representation. However, it differs from GENERIC in that the GIMPLE
5806 grammar is more restrictive: expressions contain no more than 3
5807 operands (except function calls), it has no control flow structures and
5808 expressions with side-effects are only allowed on the right hand side
5809 of assignments. See the chapter describing GENERIC and GIMPLE for more
5812 This chapter describes the data structures and functions used in the
5813 GIMPLE optimizers (also known as "tree optimizers" or "middle end").
5814 In particular, it focuses on all the macros, data structures, functions
5815 and programming constructs needed to implement optimization passes for
5820 * GENERIC:: A high-level language-independent representation.
5821 * GIMPLE:: A lower-level factored tree representation.
5822 * Annotations:: Attributes for statements and variables.
5823 * Statement Operands:: Variables referenced by GIMPLE statements.
5824 * SSA:: Static Single Assignment representation.
5825 * Alias analysis:: Representing aliased loads and stores.
5828 File: gccint.info, Node: GENERIC, Next: GIMPLE, Up: Tree SSA
5833 The purpose of GENERIC is simply to provide a language-independent way
5834 of representing an entire function in trees. To this end, it was
5835 necessary to add a few new tree codes to the back end, but most
5836 everything was already there. If you can express it with the codes in
5837 `gcc/tree.def', it's GENERIC.
5839 Early on, there was a great deal of debate about how to think about
5840 statements in a tree IL. In GENERIC, a statement is defined as any
5841 expression whose value, if any, is ignored. A statement will always
5842 have `TREE_SIDE_EFFECTS' set (or it will be discarded), but a
5843 non-statement expression may also have side effects. A `CALL_EXPR',
5846 It would be possible for some local optimizations to work on the
5847 GENERIC form of a function; indeed, the adapted tree inliner works fine
5848 on GENERIC, but the current compiler performs inlining after lowering
5849 to GIMPLE (a restricted form described in the next section). Indeed,
5850 currently the frontends perform this lowering before handing off to
5851 `tree_rest_of_compilation', but this seems inelegant.
5853 If necessary, a front end can use some language-dependent tree codes
5854 in its GENERIC representation, so long as it provides a hook for
5855 converting them to GIMPLE and doesn't expect them to work with any
5856 (hypothetical) optimizers that run before the conversion to GIMPLE.
5857 The intermediate representation used while parsing C and C++ looks very
5858 little like GENERIC, but the C and C++ gimplifier hooks are perfectly
5859 happy to take it as input and spit out GIMPLE.
5862 File: gccint.info, Node: GIMPLE, Next: Annotations, Prev: GENERIC, Up: Tree SSA
5867 GIMPLE is a simplified subset of GENERIC for use in optimization. The
5868 particular subset chosen (and the name) was heavily influenced by the
5869 SIMPLE IL used by the McCAT compiler project at McGill University,
5870 though we have made some different choices. For one thing, SIMPLE
5871 doesn't support `goto'; a production compiler can't afford that kind of
5874 GIMPLE retains much of the structure of the parse trees: lexical
5875 scopes are represented as containers, rather than markers. However,
5876 expressions are broken down into a 3-address form, using temporary
5877 variables to hold intermediate values. Also, control structures are
5880 In GIMPLE no container node is ever used for its value; if a
5881 `COND_EXPR' or `BIND_EXPR' has a value, it is stored into a temporary
5882 within the controlled blocks, and that temporary is used in place of
5885 The compiler pass which lowers GENERIC to GIMPLE is referred to as the
5886 `gimplifier'. The gimplifier works recursively, replacing complex
5887 statements with sequences of simple statements.
5893 * GIMPLE Expressions::
5896 * Rough GIMPLE Grammar::
5899 File: gccint.info, Node: Interfaces, Next: Temporaries, Up: GIMPLE
5904 The tree representation of a function is stored in `DECL_SAVED_TREE'.
5905 It is lowered to GIMPLE by a call to `gimplify_function_tree'.
5907 If a front end wants to include language-specific tree codes in the
5908 tree representation which it provides to the back end, it must provide a
5909 definition of `LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the
5910 front end trees to GIMPLE. Usually such a hook will involve much of
5911 the same code for expanding front end trees to RTL. This function can
5912 return fully lowered GIMPLE, or it can return GENERIC trees and let the
5913 main gimplifier lower them the rest of the way; this is often simpler.
5915 The C and C++ front ends currently convert directly from front end
5916 trees to GIMPLE, and hand that off to the back end rather than first
5917 converting to GENERIC. Their gimplifier hooks know about all the
5918 `_STMT' nodes and how to convert them to GENERIC forms. There was some
5919 work done on a genericization pass which would run first, but the
5920 existence of `STMT_EXPR' meant that in order to convert all of the C
5921 statements into GENERIC equivalents would involve walking the entire
5922 tree anyway, so it was simpler to lower all the way. This might change
5923 in the future if someone writes an optimization pass which would work
5924 better with higher-level trees, but currently the optimizers all expect
5927 A front end which wants to use the tree optimizers (and already has
5928 some sort of whole-function tree representation) only needs to provide
5929 a definition of `LANG_HOOKS_GIMPLIFY_EXPR', call
5930 `gimplify_function_tree' to lower to GIMPLE, and then hand off to
5931 `tree_rest_of_compilation' to compile and output the function.
5933 You can tell the compiler to dump a C-like representation of the GIMPLE
5934 form with the flag `-fdump-tree-gimple'.
5937 File: gccint.info, Node: Temporaries, Next: GIMPLE Expressions, Prev: Interfaces, Up: GIMPLE
5942 When gimplification encounters a subexpression which is too complex, it
5943 creates a new temporary variable to hold the value of the subexpression,
5944 and adds a new statement to initialize it before the current statement.
5945 These special temporaries are known as `expression temporaries', and are
5946 allocated using `get_formal_tmp_var'. The compiler tries to always
5947 evaluate identical expressions into the same temporary, to simplify
5948 elimination of redundant calculations.
5950 We can only use expression temporaries when we know that it will not be
5951 reevaluated before its value is used, and that it will not be otherwise
5952 modified(1). Other temporaries can be allocated using
5953 `get_initialized_tmp_var' or `create_tmp_var'.
5955 Currently, an expression like `a = b + 5' is not reduced any further.
5956 We tried converting it to something like
5959 but this bloated the representation for minimal benefit. However, a
5960 variable which must live in memory cannot appear in an expression; its
5961 value is explicitly loaded into a temporary first. Similarly, storing
5962 the value of an expression to a memory variable goes through a
5965 ---------- Footnotes ----------
5967 (1) These restrictions are derived from those in Morgan 4.8.
5970 File: gccint.info, Node: GIMPLE Expressions, Next: Statements, Prev: Temporaries, Up: GIMPLE
5975 In general, expressions in GIMPLE consist of an operation and the
5976 appropriate number of simple operands; these operands must either be a
5977 GIMPLE rvalue (`is_gimple_val'), i.e. a constant or a register
5978 variable. More complex operands are factored out into temporaries, so
5985 The same rule holds for arguments to a `CALL_EXPR'.
5987 The target of an assignment is usually a variable, but can also be an
5988 `INDIRECT_REF' or a compound lvalue as described below.
5992 * Compound Expressions::
5993 * Compound Lvalues::
5994 * Conditional Expressions::
5995 * Logical Operators::
5998 File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: GIMPLE Expressions
6000 10.2.3.1 Compound Expressions
6001 .............................
6003 The left-hand side of a C comma expression is simply moved into a
6007 File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: GIMPLE Expressions
6009 10.2.3.2 Compound Lvalues
6010 .........................
6012 Currently compound lvalues involving array and structure field
6013 references are not broken down; an expression like `a.b[2] = 42' is not
6014 reduced any further (though complex array subscripts are). This
6015 restriction is a workaround for limitations in later optimizers; if we
6016 were to convert this to
6021 alias analysis would not remember that the reference to `T1[2]' came
6022 by way of `a.b', so it would think that the assignment could alias
6023 another member of `a'; this broke `struct-alias-1.c'. Future optimizer
6024 improvements may make this limitation unnecessary.
6027 File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: GIMPLE Expressions
6029 10.2.3.3 Conditional Expressions
6030 ................................
6032 A C `?:' expression is converted into an `if' statement with each
6033 branch assigning to the same temporary. So,
6043 Tree level if-conversion pass re-introduces `?:' expression, if
6044 appropriate. It is used to vectorize loops with conditions using
6045 vector conditional operations.
6047 Note that in GIMPLE, `if' statements are also represented using
6048 `COND_EXPR', as described below.
6051 File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: GIMPLE Expressions
6053 10.2.3.4 Logical Operators
6054 ..........................
6056 Except when they appear in the condition operand of a `COND_EXPR',
6057 logical `and' and `or' operators are simplified as follows: `a = b &&
6065 Note that `T1' in this example cannot be an expression temporary,
6066 because it has two different assignments.
6069 File: gccint.info, Node: Statements, Next: GIMPLE Example, Prev: GIMPLE Expressions, Up: GIMPLE
6074 Most statements will be assignment statements, represented by
6075 `MODIFY_EXPR'. A `CALL_EXPR' whose value is ignored can also be a
6076 statement. No other C expressions can appear at statement level; a
6077 reference to a volatile object is converted into a `MODIFY_EXPR'. In
6078 GIMPLE form, type of `MODIFY_EXPR' is not meaningful. Instead, use type
6081 There are also several varieties of complex statements.
6086 * Statement Sequences::
6087 * Empty Statements::
6089 * Selection Statements::
6092 * GIMPLE Exception Handling::
6095 File: gccint.info, Node: Blocks, Next: Statement Sequences, Up: Statements
6100 Block scopes and the variables they declare in GENERIC and GIMPLE are
6101 expressed using the `BIND_EXPR' code, which in previous versions of GCC
6102 was primarily used for the C statement-expression extension.
6104 Variables in a block are collected into `BIND_EXPR_VARS' in
6105 declaration order. Any runtime initialization is moved out of
6106 `DECL_INITIAL' and into a statement in the controlled block. When
6107 gimplifying from C or C++, this initialization replaces the `DECL_STMT'.
6109 Variable-length arrays (VLAs) complicate this process, as their size
6110 often refers to variables initialized earlier in the block. To handle
6111 this, we currently split the block at that point, and move the VLA into
6112 a new, inner `BIND_EXPR'. This strategy may change in the future.
6114 `DECL_SAVED_TREE' for a GIMPLE function will always be a `BIND_EXPR'
6115 which contains declarations for the temporary variables used in the
6118 A C++ program will usually contain more `BIND_EXPR's than there are
6119 syntactic blocks in the source code, since several C++ constructs have
6120 implicit scopes associated with them. On the other hand, although the
6121 C++ front end uses pseudo-scopes to handle cleanups for objects with
6122 destructors, these don't translate into the GIMPLE form; multiple
6123 declarations at the same level use the same `BIND_EXPR'.
6126 File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements
6128 10.2.4.2 Statement Sequences
6129 ............................
6131 Multiple statements at the same nesting level are collected into a
6132 `STATEMENT_LIST'. Statement lists are modified and traversed using the
6133 interface in `tree-iterator.h'.
6136 File: gccint.info, Node: Empty Statements, Next: Loops, Prev: Statement Sequences, Up: Statements
6138 10.2.4.3 Empty Statements
6139 .........................
6141 Whenever possible, statements with no effect are discarded. But if they
6142 are nested within another construct which cannot be discarded for some
6143 reason, they are instead replaced with an empty statement, generated by
6144 `build_empty_stmt'. Initially, all empty statements were shared, after
6145 the pattern of the Java front end, but this caused a lot of trouble in
6148 An empty statement is represented as `(void)0'.
6151 File: gccint.info, Node: Loops, Next: Selection Statements, Prev: Empty Statements, Up: Statements
6156 At one time loops were expressed in GIMPLE using `LOOP_EXPR', but now
6157 they are lowered to explicit gotos.
6160 File: gccint.info, Node: Selection Statements, Next: Jumps, Prev: Loops, Up: Statements
6162 10.2.4.5 Selection Statements
6163 .............................
6165 A simple selection statement, such as the C `if' statement, is
6166 expressed in GIMPLE using a void `COND_EXPR'. If only one branch is
6167 used, the other is filled with an empty statement.
6169 Normally, the condition expression is reduced to a simple comparison.
6170 If it is a shortcut (`&&' or `||') expression, however, we try to break
6171 up the `if' into multiple `if's so that the implied shortcut is taken
6172 directly, much like the transformation done by `do_jump' in the RTL
6175 A `SWITCH_EXPR' in GIMPLE contains the condition and a `TREE_VEC' of
6176 `CASE_LABEL_EXPR's describing the case values and corresponding
6177 `LABEL_DECL's to jump to. The body of the `switch' is moved after the
6181 File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Selection Statements, Up: Statements
6186 Other jumps are expressed by either `GOTO_EXPR' or `RETURN_EXPR'.
6188 The operand of a `GOTO_EXPR' must be either a label or a variable
6189 containing the address to jump to.
6191 The operand of a `RETURN_EXPR' is either `NULL_TREE' or a
6192 `MODIFY_EXPR' which sets the return value. It would be nice to move
6193 the `MODIFY_EXPR' into a separate statement, but the special return
6194 semantics in `expand_return' make that difficult. It may still happen
6195 in the future, perhaps by moving most of that logic into
6196 `expand_assignment'.
6199 File: gccint.info, Node: Cleanups, Next: GIMPLE Exception Handling, Prev: Jumps, Up: Statements
6204 Destructors for local C++ objects and similar dynamic cleanups are
6205 represented in GIMPLE by a `TRY_FINALLY_EXPR'. `TRY_FINALLY_EXPR' has
6206 two operands, both of which are a sequence of statements to execute.
6207 The first sequence is executed. When it completes the second sequence
6210 The first sequence may complete in the following ways:
6212 1. Execute the last statement in the sequence and fall off the end.
6214 2. Execute a goto statement (`GOTO_EXPR') to an ordinary label
6215 outside the sequence.
6217 3. Execute a return statement (`RETURN_EXPR').
6219 4. Throw an exception. This is currently not explicitly represented
6223 The second sequence is not executed if the first sequence completes by
6224 calling `setjmp' or `exit' or any other function that does not return.
6225 The second sequence is also not executed if the first sequence
6226 completes via a non-local goto or a computed goto (in general the
6227 compiler does not know whether such a goto statement exits the first
6228 sequence or not, so we assume that it doesn't).
6230 After the second sequence is executed, if it completes normally by
6231 falling off the end, execution continues wherever the first sequence
6232 would have continued, by falling off the end, or doing a goto, etc.
6234 `TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs
6235 to appear on every edge out of the controlled block; this reduces the
6236 freedom to move code across these edges. Therefore, the EH lowering
6237 pass which runs before most of the optimization passes eliminates these
6238 expressions by explicitly adding the cleanup to each edge. Rethrowing
6239 the exception is represented using `RESX_EXPR'.
6242 File: gccint.info, Node: GIMPLE Exception Handling, Prev: Cleanups, Up: Statements
6244 10.2.4.8 Exception Handling
6245 ...........................
6247 Other exception handling constructs are represented using
6248 `TRY_CATCH_EXPR'. `TRY_CATCH_EXPR' has two operands. The first
6249 operand is a sequence of statements to execute. If executing these
6250 statements does not throw an exception, then the second operand is
6251 ignored. Otherwise, if an exception is thrown, then the second operand
6252 of the `TRY_CATCH_EXPR' is checked. The second operand may have the
6255 1. A sequence of statements to execute. When an exception occurs,
6256 these statements are executed, and then the exception is rethrown.
6258 2. A sequence of `CATCH_EXPR' expressions. Each `CATCH_EXPR' has a
6259 list of applicable exception types and handler code. If the
6260 thrown exception matches one of the caught types, the associated
6261 handler code is executed. If the handler code falls off the
6262 bottom, execution continues after the original `TRY_CATCH_EXPR'.
6264 3. An `EH_FILTER_EXPR' expression. This has a list of permitted
6265 exception types, and code to handle a match failure. If the
6266 thrown exception does not match one of the allowed types, the
6267 associated match failure code is executed. If the thrown exception
6268 does match, it continues unwinding the stack looking for the next
6272 Currently throwing an exception is not directly represented in GIMPLE,
6273 since it is implemented by calling a function. At some point in the
6274 future we will want to add some way to express that the call will throw
6275 an exception of a known type.
6277 Just before running the optimizers, the compiler lowers the high-level
6278 EH constructs above into a set of `goto's, magic labels, and EH
6279 regions. Continuing to unwind at the end of a cleanup is represented
6283 File: gccint.info, Node: GIMPLE Example, Next: Rough GIMPLE Grammar, Prev: Statements, Up: GIMPLE
6285 10.2.5 GIMPLE Example
6286 ---------------------
6288 struct A { A(); ~A(); };
6295 int j = (--i, i ? 0 : 1);
6297 for (int x = 42; x > 0; --x)
6362 File: gccint.info, Node: Rough GIMPLE Grammar, Prev: GIMPLE Example, Up: GIMPLE
6364 10.2.6 Rough GIMPLE Grammar
6365 ---------------------------
6367 function : FUNCTION_DECL
6368 DECL_SAVED_TREE -> compound-stmt
6370 compound-stmt: STATEMENT_LIST
6385 BIND_EXPR_VARS -> chain of DECLs
6386 BIND_EXPR_BLOCK -> BLOCK
6387 BIND_EXPR_BODY -> compound-stmt
6391 op1 -> compound-stmt
6392 op2 -> compound-stmt
6394 switch-stmt : SWITCH_EXPR
6397 op2 -> TREE_VEC of CASE_LABEL_EXPRs
6398 The CASE_LABEL_EXPRs are sorted by CASE_LOW,
6399 and default is last.
6401 goto-stmt : GOTO_EXPR
6402 op0 -> LABEL_DECL | val
6404 return-stmt : RETURN_EXPR
6413 resx-stmt : RESX_EXPR
6415 label-stmt : LABEL_EXPR
6418 try-stmt : TRY_CATCH_EXPR
6419 op0 -> compound-stmt
6422 op0 -> compound-stmt
6423 op1 -> compound-stmt
6429 catch-seq : STATEMENT_LIST
6430 members -> CATCH_EXPR
6432 modify-stmt : MODIFY_EXPR
6436 call-stmt : CALL_EXPR
6437 op0 -> val | OBJ_TYPE_REF
6438 op1 -> call-arg-list
6440 call-arg-list: TREE_LIST
6441 members -> lhs | CONST
6446 addressable : addr-expr-arg
6449 with-size-arg: addressable
6452 indirectref : INDIRECT_REF
6458 op0 -> with-size-arg
6464 bitfieldref : BIT_FIELD_REF
6465 op0 -> inner-compref
6469 compref : inner-compref
6477 op0 -> inner-compref
6479 op0 -> inner-compref
6481 inner-compref: min-lval
6483 op0 -> inner-compref
6487 op0 -> inner-compref
6492 op0 -> inner-compref
6497 op0 -> inner-compref
6511 op0 -> addr-expr-arg
6526 File: gccint.info, Node: Annotations, Next: Statement Operands, Prev: GIMPLE, Up: Tree SSA
6531 The optimizers need to associate attributes with statements and
6532 variables during the optimization process. For instance, we need to
6533 know what basic block a statement belongs to or whether a variable has
6534 aliases. All these attributes are stored in data structures called
6535 annotations which are then linked to the field `ann' in `struct
6538 Presently, we define annotations for statements (`stmt_ann_t'),
6539 variables (`var_ann_t') and SSA names (`ssa_name_ann_t'). Annotations
6540 are defined and documented in `tree-flow.h'.
6543 File: gccint.info, Node: Statement Operands, Next: SSA, Prev: Annotations, Up: Tree SSA
6545 10.4 Statement Operands
6546 =======================
6548 Almost every GIMPLE statement will contain a reference to a variable or
6549 memory location. Since statements come in different shapes and sizes,
6550 their operands are going to be located at various spots inside the
6551 statement's tree. To facilitate access to the statement's operands,
6552 they are organized into lists associated inside each statement's
6553 annotation. Each element in an operand list is a pointer to a
6554 `VAR_DECL', `PARM_DECL' or `SSA_NAME' tree node. This provides a very
6555 convenient way of examining and replacing operands.
6557 Data flow analysis and optimization is done on all tree nodes
6558 representing variables. Any node for which `SSA_VAR_P' returns nonzero
6559 is considered when scanning statement operands. However, not all
6560 `SSA_VAR_P' variables are processed in the same way. For the purposes
6561 of optimization, we need to distinguish between references to local
6562 scalar variables and references to globals, statics, structures,
6563 arrays, aliased variables, etc. The reason is simple, the compiler can
6564 gather complete data flow information for a local scalar. On the other
6565 hand, a global variable may be modified by a function call, it may not
6566 be possible to keep track of all the elements of an array or the fields
6567 of a structure, etc.
6569 The operand scanner gathers two kinds of operands: "real" and
6570 "virtual". An operand for which `is_gimple_reg' returns true is
6571 considered real, otherwise it is a virtual operand. We also
6572 distinguish between uses and definitions. An operand is used if its
6573 value is loaded by the statement (e.g., the operand at the RHS of an
6574 assignment). If the statement assigns a new value to the operand, the
6575 operand is considered a definition (e.g., the operand at the LHS of an
6578 Virtual and real operands also have very different data flow
6579 properties. Real operands are unambiguous references to the full
6580 object that they represent. For instance, given
6587 Since `a' and `b' are non-aliased locals, the statement `a = b' will
6588 have one real definition and one real use because variable `b' is
6589 completely modified with the contents of variable `a'. Real definition
6590 are also known as "killing definitions". Similarly, the use of `a'
6593 In contrast, virtual operands are used with variables that can have a
6594 partial or ambiguous reference. This includes structures, arrays,
6595 globals, and aliased variables. In these cases, we have two types of
6596 definitions. For globals, structures, and arrays, we can determine from
6597 a statement whether a variable of these types has a killing definition.
6598 If the variable does, then the statement is marked as having a "must
6599 definition" of that variable. However, if a statement is only defining
6600 a part of the variable (i.e. a field in a structure), or if we know
6601 that a statement might define the variable but we cannot say for sure,
6602 then we mark that statement as having a "may definition". For
6616 The assignment `*p = 5' may be a definition of `a' or `b'. If we
6617 cannot determine statically where `p' is pointing to at the time of the
6618 store operation, we create virtual definitions to mark that statement
6619 as a potential definition site for `a' and `b'. Memory loads are
6620 similarly marked with virtual use operands. Virtual operands are shown
6621 in tree dumps right before the statement that contains them. To
6622 request a tree dump with virtual operands, use the `-vops' option to
6641 Notice that `V_MAY_DEF' operands have two copies of the referenced
6642 variable. This indicates that this is not a killing definition of that
6643 variable. In this case we refer to it as a "may definition" or
6644 "aliased store". The presence of the second copy of the variable in
6645 the `V_MAY_DEF' operand will become important when the function is
6646 converted into SSA form. This will be used to link all the non-killing
6647 definitions to prevent optimizations from making incorrect assumptions
6650 Operands are updated as soon as the statement is finished via a call
6651 to `update_stmt'. If statement elements are changed via `SET_USE' or
6652 `SET_DEF', then no further action is required (i.e., those macros take
6653 care of updating the statement). If changes are made by manipulating
6654 the statement's tree directly, then a call must be made to
6655 `update_stmt' when complete. Calling one of the `bsi_insert' routines
6656 or `bsi_replace' performs an implicit call to `update_stmt'.
6658 10.4.1 Operand Iterators And Access Routines
6659 --------------------------------------------
6661 Operands are collected by `tree-ssa-operands.c'. They are stored
6662 inside each statement's annotation and can be accessed through either
6663 the operand iterators or an access routine.
6665 The following access routines are available for examining operands:
6667 1. `SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return
6668 NULL unless there is exactly one operand matching the specified
6669 flags. If there is exactly one operand, the operand is returned
6670 as either a `tree', `def_operand_p', or `use_operand_p'.
6672 tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags);
6673 use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES);
6674 def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS);
6676 2. `ZERO_SSA_OPERANDS': This macro returns true if there are no
6677 operands matching the specified flags.
6679 if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS))
6682 3. `NUM_SSA_OPERANDS': This macro Returns the number of operands
6683 matching 'flags'. This actually executes a loop to perform the
6684 count, so only use this if it is really needed.
6686 int count = NUM_SSA_OPERANDS (stmt, flags)
6688 If you wish to iterate over some or all operands, use the
6689 `FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print
6690 all the operands for a statement:
6693 print_ops (tree stmt)
6698 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS)
6699 print_generic_expr (stderr, var, TDF_SLIM);
6702 How to choose the appropriate iterator:
6704 1. Determine whether you are need to see the operand pointers, or
6705 just the trees, and choose the appropriate macro:
6709 use_operand_p FOR_EACH_SSA_USE_OPERAND
6710 def_operand_p FOR_EACH_SSA_DEF_OPERAND
6711 tree FOR_EACH_SSA_TREE_OPERAND
6713 2. You need to declare a variable of the type you are interested
6714 in, and an ssa_op_iter structure which serves as the loop
6715 controlling variable.
6717 3. Determine which operands you wish to use, and specify the flags of
6718 those you are interested in. They are documented in
6719 `tree-ssa-operands.h':
6721 #define SSA_OP_USE 0x01 /* Real USE operands. */
6722 #define SSA_OP_DEF 0x02 /* Real DEF operands. */
6723 #define SSA_OP_VUSE 0x04 /* VUSE operands. */
6724 #define SSA_OP_VMAYUSE 0x08 /* USE portion of V_MAY_DEFS. */
6725 #define SSA_OP_VMAYDEF 0x10 /* DEF portion of V_MAY_DEFS. */
6726 #define SSA_OP_VMUSTDEF 0x20 /* V_MUST_DEF definitions. */
6728 /* These are commonly grouped operand flags. */
6729 #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE | SSA_OP_VMAYUSE)
6730 #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VMAYDEF | SSA_OP_VMUSTDEF)
6731 #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE)
6732 #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF)
6733 #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS)
6735 So if you want to look at the use pointers for all the `USE' and
6736 `VUSE' operands, you would do something like:
6738 use_operand_p use_p;
6741 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE))
6743 process_use_ptr (use_p);
6746 The `TREE' macro is basically the same as the `USE' and `DEF' macros,
6747 only with the use or def dereferenced via `USE_FROM_PTR (use_p)' and
6748 `DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use
6749 and defs flags can be mixed.
6754 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE | SSA_OP_VMUSTDEF)
6756 print_generic_expr (stderr, var, TDF_SLIM);
6759 `V_MAY_DEF's are broken into two flags, one for the `DEF' portion
6760 (`SSA_OP_VMAYDEF') and one for the USE portion (`SSA_OP_VMAYUSE'). If
6761 all you want to look at are the `V_MAY_DEF's together, there is a
6762 fourth iterator macro for this, which returns both a def_operand_p and
6763 a use_operand_p for each `V_MAY_DEF' in the statement. Note that you
6764 don't need any flags for this one.
6766 use_operand_p use_p;
6767 def_operand_p def_p;
6770 FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter)
6775 `V_MUST_DEF's are broken into two flags, one for the `DEF' portion
6776 (`SSA_OP_VMUSTDEF') and one for the kill portion (`SSA_OP_VMUSTKILL').
6777 If all you want to look at are the `V_MUST_DEF's together, there is a
6778 fourth iterator macro for this, which returns both a def_operand_p and
6779 a use_operand_p for each `V_MUST_DEF' in the statement. Note that you
6780 don't need any flags for this one.
6782 use_operand_p kill_p;
6783 def_operand_p def_p;
6786 FOR_EACH_SSA_MUSTDEF_OPERAND (def_p, kill_p, stmt, iter)
6791 There are many examples in the code as well, as well as the
6792 documentation in `tree-ssa-operands.h'.
6794 There are also a couple of variants on the stmt iterators regarding PHI
6797 `FOR_EACH_PHI_ARG' Works exactly like `FOR_EACH_SSA_USE_OPERAND',
6798 except it works over `PHI' arguments instead of statement operands.
6800 /* Look at every virtual PHI use. */
6801 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES)
6806 /* Look at every real PHI use. */
6807 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES)
6810 /* Look at every every PHI use. */
6811 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES)
6814 `FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like
6815 `FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a
6816 statement or a `PHI' node. These should be used when it is appropriate
6817 but they are not quite as efficient as the individual `FOR_EACH_PHI'
6818 and `FOR_EACH_SSA' routines.
6820 FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags)
6825 FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags)
6830 10.4.2 Immediate Uses
6831 ---------------------
6833 Immediate use information is now always available. Using the immediate
6834 use iterators, you may examine every use of any `SSA_NAME'. For
6835 instance, to change each use of `ssa_var' to `ssa_var2':
6837 use_operand_p imm_use_p;
6838 imm_use_iterator iterator;
6841 FOR_EACH_IMM_USE_SAFE (imm_use_p, iterator, ssa_var)
6842 SET_USE (imm_use_p, ssa_var_2);
6844 There are 2 iterators which can be used. `FOR_EACH_IMM_USE_FAST' is
6845 used when the immediate uses are not changed, i.e., you are looking at
6846 the uses, but not setting them.
6848 If they do get changed, then care must be taken that things are not
6849 changed under the iterators, so use the `FOR_EACH_IMM_USE_SAFE'
6850 iterator. It attempts to preserve the sanity of the use list by moving
6851 an iterator element through the use list, preventing insertions and
6852 deletions in the list from resulting in invalid pointers. This is a
6853 little slower since it adds a placeholder element and moves it through
6854 the list. This element must be also be removed if the loop is
6855 terminated early. A macro (`BREAK_FROM SAFE_IMM_USE') is provided for
6858 FOR_EACH_IMM_USE_SAFE (use_p, iter, var)
6860 if (var == last_var)
6861 BREAK_FROM_SAFE_IMM_USE (iter);
6863 SET_USE (use_p, var2);
6866 There are checks in `verify_ssa' which verify that the immediate use
6867 list is up to date, as well as checking that an optimization didn't
6868 break from the loop without using this macro. It is safe to simply
6869 'break'; from a `FOR_EACH_IMM_USE_FAST' traverse.
6871 Some useful functions and macros:
6872 1. `has_zero_uses (ssa_var)' : Returns true if there are no uses of
6875 2. `has_single_use (ssa_var)' : Returns true if there is only a
6876 single use of `ssa_var'.
6878 3. `single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' :
6879 Returns true if there is only a single use of `ssa_var', and also
6880 returns the use pointer and statement it occurs in in the second
6881 and third parameters.
6883 4. `num_imm_uses (ssa_var)' : Returns the number of immediate uses of
6884 `ssa_var'. It is better not to use this if possible since it simply
6885 utilizes a loop to count the uses.
6887 5. `PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a `PHI'
6888 node, return the index number for the use. An assert is triggered
6889 if the use isn't located in a `PHI' node.
6891 6. `USE_STMT (use_p)' : Return the statement a use occurs in.
6893 Note that uses are not put into an immediate use list until their
6894 statement is actually inserted into the instruction stream via a
6897 It is also still possible to utilize lazy updating of statements, but
6898 this should be used only when absolutely required. Both alias analysis
6899 and the dominator optimizations currently do this.
6901 When lazy updating is being used, the immediate use information is out
6902 of date and cannot be used reliably. Lazy updating is achieved by
6903 simply marking statements modified via calls to `mark_stmt_modified'
6904 instead of `update_stmt'. When lazy updating is no longer required,
6905 all the modified statements must have `update_stmt' called in order to
6906 bring them up to date. This must be done before the optimization is
6907 finished, or `verify_ssa' will trigger an abort.
6909 This is done with a simple loop over the instruction stream:
6910 block_stmt_iterator bsi;
6914 for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
6915 update_stmt_if_modified (bsi_stmt (bsi));
6919 File: gccint.info, Node: SSA, Next: Alias analysis, Prev: Statement Operands, Up: Tree SSA
6921 10.5 Static Single Assignment
6922 =============================
6924 Most of the tree optimizers rely on the data flow information provided
6925 by the Static Single Assignment (SSA) form. We implement the SSA form
6926 as described in `R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K.
6927 Zadeck. Efficiently Computing Static Single Assignment Form and the
6928 Control Dependence Graph. ACM Transactions on Programming Languages
6929 and Systems, 13(4):451-490, October 1991'.
6931 The SSA form is based on the premise that program variables are
6932 assigned in exactly one location in the program. Multiple assignments
6933 to the same variable create new versions of that variable. Naturally,
6934 actual programs are seldom in SSA form initially because variables tend
6935 to be assigned multiple times. The compiler modifies the program
6936 representation so that every time a variable is assigned in the code, a
6937 new version of the variable is created. Different versions of the same
6938 variable are distinguished by subscripting the variable name with its
6939 version number. Variables used in the right-hand side of expressions
6940 are renamed so that their version number matches that of the most
6943 We represent variable versions using `SSA_NAME' nodes. The renaming
6944 process in `tree-ssa.c' wraps every real and virtual operand with an
6945 `SSA_NAME' node which contains the version number and the statement
6946 that created the `SSA_NAME'. Only definitions and virtual definitions
6947 may create new `SSA_NAME' nodes.
6949 Sometimes, flow of control makes it impossible to determine what is the
6950 most recent version of a variable. In these cases, the compiler
6951 inserts an artificial definition for that variable called "PHI
6952 function" or "PHI node". This new definition merges all the incoming
6953 versions of the variable to create a new name for it. For instance,
6962 # a_4 = PHI <a_1, a_2, a_3>
6965 Since it is not possible to determine which of the three branches will
6966 be taken at runtime, we don't know which of `a_1', `a_2' or `a_3' to
6967 use at the return statement. So, the SSA renamer creates a new version
6968 `a_4' which is assigned the result of "merging" `a_1', `a_2' and `a_3'.
6969 Hence, PHI nodes mean "one of these operands. I don't know which".
6971 The following macros can be used to examine PHI nodes
6973 -- Macro: PHI_RESULT (PHI)
6974 Returns the `SSA_NAME' created by PHI node PHI (i.e., PHI's LHS).
6976 -- Macro: PHI_NUM_ARGS (PHI)
6977 Returns the number of arguments in PHI. This number is exactly
6978 the number of incoming edges to the basic block holding PHI.
6980 -- Macro: PHI_ARG_ELT (PHI, I)
6981 Returns a tuple representing the Ith argument of PHI. Each
6982 element of this tuple contains an `SSA_NAME' VAR and the incoming
6983 edge through which VAR flows.
6985 -- Macro: PHI_ARG_EDGE (PHI, I)
6986 Returns the incoming edge for the Ith argument of PHI.
6988 -- Macro: PHI_ARG_DEF (PHI, I)
6989 Returns the `SSA_NAME' for the Ith argument of PHI.
6991 10.5.1 Preserving the SSA form
6992 ------------------------------
6994 Some optimization passes make changes to the function that invalidate
6995 the SSA property. This can happen when a pass has added new symbols or
6996 changed the program so that variables that were previously aliased
6997 aren't anymore. Whenever something like this happens, the affected
6998 symbols must be renamed into SSA form again. Transformations that emit
6999 new code or replicate existing statements will also need to update the
7002 Since GCC implements two different SSA forms for register and virtual
7003 variables, keeping the SSA form up to date depends on whether you are
7004 updating register or virtual names. In both cases, the general idea
7005 behind incremental SSA updates is similar: when new SSA names are
7006 created, they typically are meant to replace other existing names in
7009 For instance, given the following code:
7012 2 x_1 = PHI (0, x_5)
7023 Suppose that we insert new names `x_10' and `x_11' (lines `4' and `8').
7026 2 x_1 = PHI (0, x_5)
7039 We want to replace all the uses of `x_1' with the new definitions of
7040 `x_10' and `x_11'. Note that the only uses that should be replaced are
7041 those at lines `5', `9' and `11'. Also, the use of `x_7' at line `9'
7042 should _not_ be replaced (this is why we cannot just mark symbol `x' for
7045 Additionally, we may need to insert a PHI node at line `11' because
7046 that is a merge point for `x_10' and `x_11'. So the use of `x_1' at
7047 line `11' will be replaced with the new PHI node. The insertion of PHI
7048 nodes is optional. They are not strictly necessary to preserve the SSA
7049 form, and depending on what the caller inserted, they may not even be
7050 useful for the optimizers.
7052 Updating the SSA form is a two step process. First, the pass has to
7053 identify which names need to be updated and/or which symbols need to be
7054 renamed into SSA form for the first time. When new names are
7055 introduced to replace existing names in the program, the mapping
7056 between the old and the new names are registered by calling
7057 `register_new_name_mapping' (note that if your pass creates new code by
7058 duplicating basic blocks, the call to `tree_duplicate_bb' will set up
7059 the necessary mappings automatically). On the other hand, if your pass
7060 exposes a new symbol that should be put in SSA form for the first time,
7061 the new symbol should be registered with `mark_sym_for_renaming'.
7063 After the replacement mappings have been registered and new symbols
7064 marked for renaming, a call to `update_ssa' makes the registered
7065 changes. This can be done with an explicit call or by creating `TODO'
7066 flags in the `tree_opt_pass' structure for your pass. There are
7067 several `TODO' flags that control the behavior of `update_ssa':
7069 * `TODO_update_ssa'. Update the SSA form inserting PHI nodes
7070 for newly exposed symbols and virtual names marked for updating.
7071 When updating real names, only insert PHI nodes for a real
7072 name `O_j' in blocks reached by all the new and old
7073 definitions for `O_j'. If the iterated dominance frontier
7074 for `O_j' is not pruned, we may end up inserting PHI nodes
7075 in blocks that have one or more edges with no incoming
7076 definition for `O_j'. This would lead to uninitialized
7077 warnings for `O_j''s symbol.
7079 * `TODO_update_ssa_no_phi'. Update the SSA form without
7080 inserting any new PHI nodes at all. This is used by passes that
7081 have either inserted all the PHI nodes themselves or passes
7082 that need only to patch use-def and def-def chains for
7083 virtuals (e.g., DCE).
7085 * `TODO_update_ssa_full_phi'. Insert PHI nodes everywhere
7086 they are needed. No pruning of the IDF is done. This is used
7087 by passes that need the PHI nodes for `O_j' even if it
7088 means that some arguments will come from the default definition
7089 of `O_j''s symbol (e.g., `pass_linear_transform').
7091 WARNING: If you need to use this flag, chances are that your
7092 pass may be doing something wrong. Inserting PHI nodes for an
7093 old name where not all edges carry a new replacement may lead to
7094 silent codegen errors or spurious uninitialized warnings.
7096 * `TODO_update_ssa_only_virtuals'. Passes that update the SSA
7097 form on their own may want to delegate the updating of
7098 virtual names to the generic updater. Since FUD chains are
7099 easier to maintain, this simplifies the work they need to do.
7100 NOTE: If this flag is used, any OLD->NEW mappings for real names
7101 are explicitly destroyed and only the symbols marked for
7102 renaming are processed.
7104 10.5.2 Examining `SSA_NAME' nodes
7105 ---------------------------------
7107 The following macros can be used to examine `SSA_NAME' nodes
7109 -- Macro: SSA_NAME_DEF_STMT (VAR)
7110 Returns the statement S that creates the `SSA_NAME' VAR. If S is
7111 an empty statement (i.e., `IS_EMPTY_STMT (S)' returns `true'), it
7112 means that the first reference to this variable is a USE or a VUSE.
7114 -- Macro: SSA_NAME_VERSION (VAR)
7115 Returns the version number of the `SSA_NAME' object VAR.
7117 10.5.3 Walking use-def chains
7118 -----------------------------
7120 -- Tree SSA function: void walk_use_def_chains (VAR, FN, DATA)
7121 Walks use-def chains starting at the `SSA_NAME' node VAR. Calls
7122 function FN at each reaching definition found. Function FN takes
7123 three arguments: VAR, its defining statement (DEF_STMT) and a
7124 generic pointer to whatever state information that FN may want to
7125 maintain (DATA). Function FN is able to stop the walk by
7126 returning `true', otherwise in order to continue the walk, FN
7127 should return `false'.
7129 Note, that if DEF_STMT is a `PHI' node, the semantics are slightly
7130 different. For each argument ARG of the PHI node, this function
7133 1. Walk the use-def chains for ARG.
7135 2. Call `FN (ARG, PHI, DATA)'.
7137 Note how the first argument to FN is no longer the original
7138 variable VAR, but the PHI argument currently being examined. If
7139 FN wants to get at VAR, it should call `PHI_RESULT' (PHI).
7141 10.5.4 Walking the dominator tree
7142 ---------------------------------
7144 -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB)
7145 This function walks the dominator tree for the current CFG calling
7146 a set of callback functions defined in STRUCT DOM_WALK_DATA in
7147 `domwalk.h'. The call back functions you need to define give you
7148 hooks to execute custom code at various points during traversal:
7150 1. Once to initialize any local data needed while processing
7151 BB and its children. This local data is pushed into an
7152 internal stack which is automatically pushed and popped as
7153 the walker traverses the dominator tree.
7155 2. Once before traversing all the statements in the BB.
7157 3. Once for every statement inside BB.
7159 4. Once after traversing all the statements and before recursing
7160 into BB's dominator children.
7162 5. It then recurses into all the dominator children of BB.
7164 6. After recursing into all the dominator children of BB it
7165 can, optionally, traverse every statement in BB again
7166 (i.e., repeating steps 2 and 3).
7168 7. Once after walking the statements in BB and BB's
7169 dominator children. At this stage, the block local data stack
7173 File: gccint.info, Node: Alias analysis, Prev: SSA, Up: Tree SSA
7178 Alias analysis proceeds in 4 main phases:
7180 1. Structural alias analysis.
7182 This phase walks the types for structure variables, and determines
7183 which of the fields can overlap using offset and size of each
7184 field. For each field, a "subvariable" called a "Structure field
7185 tag" (SFT) is created, which represents that field as a separate
7186 variable. All accesses that could possibly overlap with a given
7187 field will have virtual operands for the SFT of that field.
7197 int tmp1, tmp2, tmp3;
7198 SFT.0_2 = V_MUST_DEF <SFT.0_1>
7200 SFT.1_4 = V_MUST_DEF <SFT.1_3>
7208 tmp3_7 = tmp1_5 + tmp2_6;
7212 If you copy the type tag for a variable for some reason, you
7213 probably also want to copy the subvariables for that variable.
7215 2. Points-to and escape analysis.
7217 This phase walks the use-def chains in the SSA web looking for
7223 * Assignments of the form `P_i = &VAR'
7225 * Assignments of the form P_i = malloc()
7227 * Pointers and ADDR_EXPR that escape the current function.
7229 The concept of `escaping' is the same one used in the Java world.
7230 When a pointer or an ADDR_EXPR escapes, it means that it has been
7231 exposed outside of the current function. So, assignment to global
7232 variables, function arguments and returning a pointer are all
7235 This is where we are currently limited. Since not everything is
7236 renamed into SSA, we lose track of escape properties when a
7237 pointer is stashed inside a field in a structure, for instance.
7238 In those cases, we are assuming that the pointer does escape.
7240 We use escape analysis to determine whether a variable is
7241 call-clobbered. Simply put, if an ADDR_EXPR escapes, then the
7242 variable is call-clobbered. If a pointer P_i escapes, then all
7243 the variables pointed-to by P_i (and its memory tag) also escape.
7245 3. Compute flow-sensitive aliases
7247 We have two classes of memory tags. Memory tags associated with
7248 the pointed-to data type of the pointers in the program. These
7249 tags are called "type memory tag" (TMT). The other class are
7250 those associated with SSA_NAMEs, called "name memory tag" (NMT).
7251 The basic idea is that when adding operands for an INDIRECT_REF
7252 *P_i, we will first check whether P_i has a name tag, if it does
7253 we use it, because that will have more precise aliasing
7254 information. Otherwise, we use the standard type tag.
7256 In this phase, we go through all the pointers we found in
7257 points-to analysis and create alias sets for the name memory tags
7258 associated with each pointer P_i. If P_i escapes, we mark
7259 call-clobbered the variables it points to and its tag.
7261 4. Compute flow-insensitive aliases
7263 This pass will compare the alias set of every type memory tag and
7264 every addressable variable found in the program. Given a type
7265 memory tag TMT and an addressable variable V. If the alias sets
7266 of TMT and V conflict (as computed by may_alias_p), then V is
7267 marked as an alias tag and added to the alias set of TMT.
7269 For instance, consider the following function:
7286 After aliasing analysis has finished, the type memory tag for pointer
7287 `p' will have two aliases, namely variables `a' and `b'. Every time
7288 pointer `p' is dereferenced, we want to mark the operation as a
7289 potential reference to `a' and `b'.
7299 # p_1 = PHI <p_4(1), p_6(2)>;
7301 # a_7 = V_MAY_DEF <a_3>;
7302 # b_8 = V_MAY_DEF <b_5>;
7305 # a_9 = V_MAY_DEF <a_7>
7314 In certain cases, the list of may aliases for a pointer may grow too
7315 large. This may cause an explosion in the number of virtual operands
7316 inserted in the code. Resulting in increased memory consumption and
7319 When the number of virtual operands needed to represent aliased loads
7320 and stores grows too large (configurable with `--param
7321 max-aliased-vops'), alias sets are grouped to avoid severe compile-time
7322 slow downs and memory consumption. The alias grouping heuristic
7323 proceeds as follows:
7325 1. Sort the list of pointers in decreasing number of contributed
7328 2. Take the first pointer from the list and reverse the role of the
7329 memory tag and its aliases. Usually, whenever an aliased variable
7330 Vi is found to alias with a memory tag T, we add Vi to the
7331 may-aliases set for T. Meaning that after alias analysis, we will
7334 may-aliases(T) = { V1, V2, V3, ..., Vn }
7336 This means that every statement that references T, will get `n'
7337 virtual operands for each of the Vi tags. But, when alias
7338 grouping is enabled, we make T an alias tag and add it to the
7339 alias set of all the Vi variables:
7341 may-aliases(V1) = { T }
7342 may-aliases(V2) = { T }
7344 may-aliases(Vn) = { T }
7346 This has two effects: (a) statements referencing T will only get a
7347 single virtual operand, and, (b) all the variables Vi will now
7348 appear to alias each other. So, we lose alias precision to
7349 improve compile time. But, in theory, a program with such a high
7350 level of aliasing should not be very optimizable in the first
7353 3. Since variables may be in the alias set of more than one memory
7354 tag, the grouping done in step (2) needs to be extended to all the
7355 memory tags that have a non-empty intersection with the
7356 may-aliases set of tag T. For instance, if we originally had
7357 these may-aliases sets:
7359 may-aliases(T) = { V1, V2, V3 }
7360 may-aliases(R) = { V2, V4 }
7362 In step (2) we would have reverted the aliases for T as:
7364 may-aliases(V1) = { T }
7365 may-aliases(V2) = { T }
7366 may-aliases(V3) = { T }
7368 But note that now V2 is no longer aliased with R. We could add R
7369 to may-aliases(V2), but we are in the process of grouping aliases
7370 to reduce virtual operands so what we do is add V4 to the grouping
7373 may-aliases(V1) = { T }
7374 may-aliases(V2) = { T }
7375 may-aliases(V3) = { T }
7376 may-aliases(V4) = { T }
7378 4. If the total number of virtual operands due to aliasing is still
7379 above the threshold set by max-alias-vops, go back to (2).
7382 File: gccint.info, Node: RTL, Next: Control Flow, Prev: Trees, Up: Top
7384 11 RTL Representation
7385 *********************
7387 Most of the work of the compiler is done on an intermediate
7388 representation called register transfer language. In this language,
7389 the instructions to be output are described, pretty much one by one, in
7390 an algebraic form that describes what the instruction does.
7392 RTL is inspired by Lisp lists. It has both an internal form, made up
7393 of structures that point at other structures, and a textual form that
7394 is used in the machine description and in printed debugging dumps. The
7395 textual form uses nested parentheses to indicate the pointers in the
7400 * RTL Objects:: Expressions vs vectors vs strings vs integers.
7401 * RTL Classes:: Categories of RTL expression objects, and their structure.
7402 * Accessors:: Macros to access expression operands or vector elts.
7403 * Special Accessors:: Macros to access specific annotations on RTL.
7404 * Flags:: Other flags in an RTL expression.
7405 * Machine Modes:: Describing the size and format of a datum.
7406 * Constants:: Expressions with constant values.
7407 * Regs and Memory:: Expressions representing register contents or memory.
7408 * Arithmetic:: Expressions representing arithmetic on other expressions.
7409 * Comparisons:: Expressions representing comparison of expressions.
7410 * Bit-Fields:: Expressions representing bit-fields in memory or reg.
7411 * Vector Operations:: Expressions involving vector datatypes.
7412 * Conversions:: Extending, truncating, floating or fixing.
7413 * RTL Declarations:: Declaring volatility, constancy, etc.
7414 * Side Effects:: Expressions for storing in registers, etc.
7415 * Incdec:: Embedded side-effects for autoincrement addressing.
7416 * Assembler:: Representing `asm' with operands.
7417 * Insns:: Expression types for entire insns.
7418 * Calls:: RTL representation of function call insns.
7419 * Sharing:: Some expressions are unique; others *must* be copied.
7420 * Reading RTL:: Reading textual RTL from a file.
7423 File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL
7425 11.1 RTL Object Types
7426 =====================
7428 RTL uses five kinds of objects: expressions, integers, wide integers,
7429 strings and vectors. Expressions are the most important ones. An RTL
7430 expression ("RTX", for short) is a C structure, but it is usually
7431 referred to with a pointer; a type that is given the typedef name `rtx'.
7433 An integer is simply an `int'; their written form uses decimal digits.
7434 A wide integer is an integral object whose type is `HOST_WIDE_INT';
7435 their written form uses decimal digits.
7437 A string is a sequence of characters. In core it is represented as a
7438 `char *' in usual C fashion, and it is written in C syntax as well.
7439 However, strings in RTL may never be null. If you write an empty
7440 string in a machine description, it is represented in core as a null
7441 pointer rather than as a pointer to a null character. In certain
7442 contexts, these null pointers instead of strings are valid. Within RTL
7443 code, strings are most commonly found inside `symbol_ref' expressions,
7444 but they appear in other contexts in the RTL expressions that make up
7445 machine descriptions.
7447 In a machine description, strings are normally written with double
7448 quotes, as you would in C. However, strings in machine descriptions may
7449 extend over many lines, which is invalid C, and adjacent string
7450 constants are not concatenated as they are in C. Any string constant
7451 may be surrounded with a single set of parentheses. Sometimes this
7452 makes the machine description easier to read.
7454 There is also a special syntax for strings, which can be useful when C
7455 code is embedded in a machine description. Wherever a string can
7456 appear, it is also valid to write a C-style brace block. The entire
7457 brace block, including the outermost pair of braces, is considered to be
7458 the string constant. Double quote characters inside the braces are not
7459 special. Therefore, if you write string constants in the C code, you
7460 need not escape each quote character with a backslash.
7462 A vector contains an arbitrary number of pointers to expressions. The
7463 number of elements in the vector is explicitly present in the vector.
7464 The written form of a vector consists of square brackets (`[...]')
7465 surrounding the elements, in sequence and with whitespace separating
7466 them. Vectors of length zero are not created; null pointers are used
7469 Expressions are classified by "expression codes" (also called RTX
7470 codes). The expression code is a name defined in `rtl.def', which is
7471 also (in uppercase) a C enumeration constant. The possible expression
7472 codes and their meanings are machine-independent. The code of an RTX
7473 can be extracted with the macro `GET_CODE (X)' and altered with
7474 `PUT_CODE (X, NEWCODE)'.
7476 The expression code determines how many operands the expression
7477 contains, and what kinds of objects they are. In RTL, unlike Lisp, you
7478 cannot tell by looking at an operand what kind of object it is.
7479 Instead, you must know from its context--from the expression code of
7480 the containing expression. For example, in an expression of code
7481 `subreg', the first operand is to be regarded as an expression and the
7482 second operand as an integer. In an expression of code `plus', there
7483 are two operands, both of which are to be regarded as expressions. In
7484 a `symbol_ref' expression, there is one operand, which is to be
7485 regarded as a string.
7487 Expressions are written as parentheses containing the name of the
7488 expression type, its flags and machine mode if any, and then the
7489 operands of the expression (separated by spaces).
7491 Expression code names in the `md' file are written in lowercase, but
7492 when they appear in C code they are written in uppercase. In this
7493 manual, they are shown as follows: `const_int'.
7495 In a few contexts a null pointer is valid where an expression is
7496 normally wanted. The written form of this is `(nil)'.
7499 File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL
7501 11.2 RTL Classes and Formats
7502 ============================
7504 The various expression codes are divided into several "classes", which
7505 are represented by single characters. You can determine the class of
7506 an RTX code with the macro `GET_RTX_CLASS (CODE)'. Currently,
7507 `rtl.def' defines these classes:
7510 An RTX code that represents an actual object, such as a register
7511 (`REG') or a memory location (`MEM', `SYMBOL_REF'). `LO_SUM') is
7512 also included; instead, `SUBREG' and `STRICT_LOW_PART' are not in
7513 this class, but in class `x'.
7516 An RTX code that represents a constant object. `HIGH' is also
7517 included in this class.
7520 An RTX code for a non-symmetric comparison, such as `GEU' or `LT'.
7523 An RTX code for a symmetric (commutative) comparison, such as `EQ'
7527 An RTX code for a unary arithmetic operation, such as `NEG',
7528 `NOT', or `ABS'. This category also includes value extension
7529 (sign or zero) and conversions between integer and floating point.
7532 An RTX code for a commutative binary operation, such as `PLUS' or
7533 `AND'. `NE' and `EQ' are comparisons, so they have class `<'.
7536 An RTX code for a non-commutative binary operation, such as
7537 `MINUS', `DIV', or `ASHIFTRT'.
7540 An RTX code for a bit-field operation. Currently only
7541 `ZERO_EXTRACT' and `SIGN_EXTRACT'. These have three inputs and
7542 are lvalues (so they can be used for insertion as well). *Note
7546 An RTX code for other three input operations. Currently only
7547 `IF_THEN_ELSE' and `VEC_MERGE'.
7550 An RTX code for an entire instruction: `INSN', `JUMP_INSN', and
7551 `CALL_INSN'. *Note Insns::.
7554 An RTX code for something that matches in insns, such as
7555 `MATCH_DUP'. These only occur in machine descriptions.
7558 An RTX code for an auto-increment addressing mode, such as
7562 All other RTX codes. This category includes the remaining codes
7563 used only in machine descriptions (`DEFINE_*', etc.). It also
7564 includes all the codes describing side effects (`SET', `USE',
7565 `CLOBBER', etc.) and the non-insns that may appear on an insn
7566 chain, such as `NOTE', `BARRIER', and `CODE_LABEL'. `SUBREG' is
7567 also part of this class.
7569 For each expression code, `rtl.def' specifies the number of contained
7570 objects and their kinds using a sequence of characters called the
7571 "format" of the expression code. For example, the format of `subreg'
7574 These are the most commonly used format characters:
7577 An expression (actually a pointer to an expression).
7589 A vector of expressions.
7591 A few other format characters are used occasionally:
7594 `u' is equivalent to `e' except that it is printed differently in
7595 debugging dumps. It is used for pointers to insns.
7598 `n' is equivalent to `i' except that it is printed differently in
7599 debugging dumps. It is used for the line number or code number of
7603 `S' indicates a string which is optional. In the RTL objects in
7604 core, `S' is equivalent to `s', but when the object is read, from
7605 an `md' file, the string value of this operand may be omitted. An
7606 omitted string is taken to be the null string.
7609 `V' indicates a vector which is optional. In the RTL objects in
7610 core, `V' is equivalent to `E', but when the object is read from
7611 an `md' file, the vector value of this operand may be omitted. An
7612 omitted vector is effectively the same as a vector of no elements.
7615 `B' indicates a pointer to basic block structure.
7618 `0' means a slot whose contents do not fit any normal category.
7619 `0' slots are not printed at all in dumps, and are often used in
7620 special ways by small parts of the compiler.
7622 There are macros to get the number of operands and the format of an
7625 `GET_RTX_LENGTH (CODE)'
7626 Number of operands of an RTX of code CODE.
7628 `GET_RTX_FORMAT (CODE)'
7629 The format of an RTX of code CODE, as a C string.
7631 Some classes of RTX codes always have the same format. For example, it
7632 is safe to assume that all comparison operations have format `ee'.
7635 All codes of this class have format `e'.
7640 All codes of these classes have format `ee'.
7644 All codes of these classes have format `eee'.
7647 All codes of this class have formats that begin with `iuueiee'.
7648 *Note Insns::. Note that not all RTL objects linked onto an insn
7649 chain are of class `i'.
7654 You can make no assumptions about the format of these codes.
7657 File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL
7659 11.3 Access to Operands
7660 =======================
7662 Operands of expressions are accessed using the macros `XEXP', `XINT',
7663 `XWINT' and `XSTR'. Each of these macros takes two arguments: an
7664 expression-pointer (RTX) and an operand number (counting from zero).
7669 accesses operand 2 of expression X, as an expression.
7673 accesses the same operand as an integer. `XSTR', used in the same
7674 fashion, would access it as a string.
7676 Any operand can be accessed as an integer, as an expression or as a
7677 string. You must choose the correct method of access for the kind of
7678 value actually stored in the operand. You would do this based on the
7679 expression code of the containing expression. That is also how you
7680 would know how many operands there are.
7682 For example, if X is a `subreg' expression, you know that it has two
7683 operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X,
7684 1)'. If you did `XINT (X, 0)', you would get the address of the
7685 expression operand but cast as an integer; that might occasionally be
7686 useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP
7687 (X, 1)' would also compile without error, and would return the second,
7688 integer operand cast as an expression pointer, which would probably
7689 result in a crash when accessed. Nothing stops you from writing `XEXP
7690 (X, 28)' either, but this will access memory past the end of the
7691 expression with unpredictable results.
7693 Access to operands which are vectors is more complicated. You can use
7694 the macro `XVEC' to get the vector-pointer itself, or the macros
7695 `XVECEXP' and `XVECLEN' to access the elements and length of a vector.
7698 Access the vector-pointer which is operand number IDX in EXP.
7700 `XVECLEN (EXP, IDX)'
7701 Access the length (number of elements) in the vector which is in
7702 operand number IDX in EXP. This value is an `int'.
7704 `XVECEXP (EXP, IDX, ELTNUM)'
7705 Access element number ELTNUM in the vector which is in operand
7706 number IDX in EXP. This value is an RTX.
7708 It is up to you to make sure that ELTNUM is not negative and is
7709 less than `XVECLEN (EXP, IDX)'.
7711 All the macros defined in this section expand into lvalues and
7712 therefore can be used to assign the operands, lengths and vector
7713 elements as well as to access them.
7716 File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL
7718 11.4 Access to Special Operands
7719 ===============================
7721 Some RTL nodes have special annotations associated with them.
7726 If 0, X is not in any alias set, and may alias anything.
7727 Otherwise, X can only alias `MEM's in a conflicting alias
7728 set. This value is set in a language-dependent manner in the
7729 front-end, and should not be altered in the back-end. In
7730 some front-ends, these numbers may correspond in some way to
7731 types, or other language-level entities, but they need not,
7732 and the back-end makes no such assumptions. These set
7733 numbers are tested with `alias_sets_conflict_p'.
7736 If this register is known to hold the value of some user-level
7737 declaration, this is that tree node. It may also be a
7738 `COMPONENT_REF', in which case this is some field reference,
7739 and `TREE_OPERAND (X, 0)' contains the declaration, or
7740 another `COMPONENT_REF', or null if there is no compile-time
7741 object associated with the reference.
7744 The offset from the start of `MEM_EXPR' as a `CONST_INT' rtx.
7747 The size in bytes of the memory reference as a `CONST_INT'
7748 rtx. This is mostly relevant for `BLKmode' references as
7749 otherwise the size is implied by the mode.
7752 The known alignment in bits of the memory reference.
7756 `ORIGINAL_REGNO (X)'
7757 This field holds the number the register "originally" had;
7758 for a pseudo register turned into a hard reg this will hold
7759 the old pseudo register number.
7762 If this register is known to hold the value of some user-level
7763 declaration, this is that tree node.
7766 If this register is known to hold the value of some user-level
7767 declaration, this is the offset into that logical storage.
7771 `SYMBOL_REF_DECL (X)'
7772 If the `symbol_ref' X was created for a `VAR_DECL' or a
7773 `FUNCTION_DECL', that tree is recorded here. If this value is
7774 null, then X was created by back end code generation routines,
7775 and there is no associated front end symbol table entry.
7777 `SYMBOL_REF_DECL' may also point to a tree of class `'c'',
7778 that is, some sort of constant. In this case, the
7779 `symbol_ref' is an entry in the per-file constant pool;
7780 again, there is no associated front end symbol table entry.
7782 `SYMBOL_REF_FLAGS (X)'
7783 In a `symbol_ref', this is used to communicate various
7784 predicates about the symbol. Some of these are common enough
7785 to be computed by common code, some are specific to the
7786 target. The common bits are:
7788 `SYMBOL_FLAG_FUNCTION'
7789 Set if the symbol refers to a function.
7792 Set if the symbol is local to this "module". See
7793 `TARGET_BINDS_LOCAL_P'.
7795 `SYMBOL_FLAG_EXTERNAL'
7796 Set if this symbol is not defined in this translation
7797 unit. Note that this is not the inverse of
7798 `SYMBOL_FLAG_LOCAL'.
7801 Set if the symbol is located in the small data section.
7802 See `TARGET_IN_SMALL_DATA_P'.
7804 `SYMBOL_REF_TLS_MODEL (X)'
7805 This is a multi-bit field accessor that returns the
7806 `tls_model' to be used for a thread-local storage
7807 symbol. It returns zero for non-thread-local symbols.
7809 Bits beginning with `SYMBOL_FLAG_MACH_DEP' are available for
7813 File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL
7815 11.5 Flags in an RTL Expression
7816 ===============================
7818 RTL expressions contain several flags (one-bit bit-fields) that are
7819 used in certain types of expression. Most often they are accessed with
7820 the following macros, which expand into lvalues.
7822 `CONSTANT_POOL_ADDRESS_P (X)'
7823 Nonzero in a `symbol_ref' if it refers to part of the current
7824 function's constant pool. For most targets these addresses are in
7825 a `.rodata' section entirely separate from the function, but for
7826 some targets the addresses are close to the beginning of the
7827 function. In either case GCC assumes these addresses can be
7828 addressed directly, perhaps with the help of base registers.
7829 Stored in the `unchanging' field and printed as `/u'.
7831 `CONST_OR_PURE_CALL_P (X)'
7832 In a `call_insn', `note', or an `expr_list' for notes, indicates
7833 that the insn represents a call to a const or pure function.
7834 Stored in the `unchanging' field and printed as `/u'.
7836 `INSN_ANNULLED_BRANCH_P (X)'
7837 In a `jump_insn', `call_insn', or `insn' indicates that the branch
7838 is an annulling one. See the discussion under `sequence' below.
7839 Stored in the `unchanging' field and printed as `/u'.
7841 `INSN_DELETED_P (X)'
7842 In an `insn', `call_insn', `jump_insn', `code_label', `barrier',
7843 or `note', nonzero if the insn has been deleted. Stored in the
7844 `volatil' field and printed as `/v'.
7846 `INSN_FROM_TARGET_P (X)'
7847 In an `insn' or `jump_insn' or `call_insn' in a delay slot of a
7848 branch, indicates that the insn is from the target of the branch.
7849 If the branch insn has `INSN_ANNULLED_BRANCH_P' set, this insn
7850 will only be executed if the branch is taken. For annulled
7851 branches with `INSN_FROM_TARGET_P' clear, the insn will be
7852 executed only if the branch is not taken. When
7853 `INSN_ANNULLED_BRANCH_P' is not set, this insn will always be
7854 executed. Stored in the `in_struct' field and printed as `/s'.
7856 `LABEL_OUTSIDE_LOOP_P (X)'
7857 In `label_ref' expressions, nonzero if this is a reference to a
7858 label that is outside the innermost loop containing the reference
7859 to the label. Stored in the `in_struct' field and printed as `/s'.
7861 `LABEL_PRESERVE_P (X)'
7862 In a `code_label' or `note', indicates that the label is
7863 referenced by code or data not visible to the RTL of a given
7864 function. Labels referenced by a non-local goto will have this
7865 bit set. Stored in the `in_struct' field and printed as `/s'.
7867 `LABEL_REF_NONLOCAL_P (X)'
7868 In `label_ref' and `reg_label' expressions, nonzero if this is a
7869 reference to a non-local label. Stored in the `volatil' field and
7872 `MEM_IN_STRUCT_P (X)'
7873 In `mem' expressions, nonzero for reference to an entire structure,
7874 union or array, or to a component of one. Zero for references to a
7875 scalar variable or through a pointer to a scalar. If both this
7876 flag and `MEM_SCALAR_P' are clear, then we don't know whether this
7877 `mem' is in a structure or not. Both flags should never be
7878 simultaneously set. Stored in the `in_struct' field and printed
7881 `MEM_KEEP_ALIAS_SET_P (X)'
7882 In `mem' expressions, 1 if we should keep the alias set for this
7883 mem unchanged when we access a component. Set to 1, for example,
7884 when we are already in a non-addressable component of an aggregate.
7885 Stored in the `jump' field and printed as `/j'.
7888 In `mem' expressions, nonzero for reference to a scalar known not
7889 to be a member of a structure, union, or array. Zero for such
7890 references and for indirections through pointers, even pointers
7891 pointing to scalar types. If both this flag and `MEM_IN_STRUCT_P'
7892 are clear, then we don't know whether this `mem' is in a structure
7893 or not. Both flags should never be simultaneously set. Stored in
7894 the `frame_related' field and printed as `/f'.
7896 `MEM_VOLATILE_P (X)'
7897 In `mem', `asm_operands', and `asm_input' expressions, nonzero for
7898 volatile memory references. Stored in the `volatil' field and
7902 In `mem', nonzero for memory references that will not trap.
7903 Stored in the `call' field and printed as `/c'.
7905 `REG_FUNCTION_VALUE_P (X)'
7906 Nonzero in a `reg' if it is the place in which this function's
7907 value is going to be returned. (This happens only in a hard
7908 register.) Stored in the `integrated' field and printed as `/i'.
7911 Nonzero in a `reg' if the register holds a pointer. Stored in the
7912 `frame_related' field and printed as `/f'.
7915 In a `reg', nonzero if it corresponds to a variable present in the
7916 user's source code. Zero for temporaries generated internally by
7917 the compiler. Stored in the `volatil' field and printed as `/v'.
7919 The same hard register may be used also for collecting the values
7920 of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero
7921 in this kind of use.
7923 `RTX_FRAME_RELATED_P (X)'
7924 Nonzero in an `insn', `call_insn', `jump_insn', `barrier', or
7925 `set' which is part of a function prologue and sets the stack
7926 pointer, sets the frame pointer, or saves a register. This flag
7927 should also be set on an instruction that sets up a temporary
7928 register to use in place of the frame pointer. Stored in the
7929 `frame_related' field and printed as `/f'.
7931 In particular, on RISC targets where there are limits on the sizes
7932 of immediate constants, it is sometimes impossible to reach the
7933 register save area directly from the stack pointer. In that case,
7934 a temporary register is used that is near enough to the register
7935 save area, and the Canonical Frame Address, i.e., DWARF2's logical
7936 frame pointer, register must (temporarily) be changed to be this
7937 temporary register. So, the instruction that sets this temporary
7938 register must be marked as `RTX_FRAME_RELATED_P'.
7940 If the marked instruction is overly complex (defined in terms of
7941 what `dwarf2out_frame_debug_expr' can handle), you will also have
7942 to create a `REG_FRAME_RELATED_EXPR' note and attach it to the
7943 instruction. This note should contain a simple expression of the
7944 computation performed by this instruction, i.e., one that
7945 `dwarf2out_frame_debug_expr' can handle.
7947 This flag is required for exception handling support on targets
7950 `code_label', `insn_list', `const', or `note' if it resulted from
7951 an in-line function call. Stored in the `integrated' field and
7954 `MEM_READONLY_P (X)'
7955 Nonzero in a `mem', if the memory is statically allocated and
7958 Read-only in this context means never modified during the lifetime
7959 of the program, not necessarily in ROM or in write-disabled pages.
7960 A common example of the later is a shared library's global offset
7961 table. This table is initialized by the runtime loader, so the
7962 memory is technically writable, but after control is transfered
7963 from the runtime loader to the application, this memory will never
7964 be subsequently modified.
7966 Stored in the `unchanging' field and printed as `/u'.
7969 During instruction scheduling, in an `insn', `call_insn' or
7970 `jump_insn', indicates that the previous insn must be scheduled
7971 together with this insn. This is used to ensure that certain
7972 groups of instructions will not be split up by the instruction
7973 scheduling pass, for example, `use' insns before a `call_insn' may
7974 not be separated from the `call_insn'. Stored in the `in_struct'
7975 field and printed as `/s'.
7977 `SET_IS_RETURN_P (X)'
7978 For a `set', nonzero if it is for a return. Stored in the `jump'
7979 field and printed as `/j'.
7981 `SIBLING_CALL_P (X)'
7982 For a `call_insn', nonzero if the insn is a sibling call. Stored
7983 in the `jump' field and printed as `/j'.
7985 `STRING_POOL_ADDRESS_P (X)'
7986 For a `symbol_ref' expression, nonzero if it addresses this
7987 function's string constant pool. Stored in the `frame_related'
7988 field and printed as `/f'.
7990 `SUBREG_PROMOTED_UNSIGNED_P (X)'
7991 Returns a value greater then zero for a `subreg' that has
7992 `SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is
7993 kept zero-extended, zero if it is kept sign-extended, and less
7994 then zero if it is extended some other way via the `ptr_extend'
7995 instruction. Stored in the `unchanging' field and `volatil'
7996 field, printed as `/u' and `/v'. This macro may only be used to
7997 get the value it may not be used to change the value. Use
7998 `SUBREG_PROMOTED_UNSIGNED_SET' to change the value.
8000 `SUBREG_PROMOTED_UNSIGNED_SET (X)'
8001 Set the `unchanging' and `volatil' fields in a `subreg' to reflect
8002 zero, sign, or other extension. If `volatil' is zero, then
8003 `unchanging' as nonzero means zero extension and as zero means
8004 sign extension. If `volatil' is nonzero then some other type of
8005 extension was done via the `ptr_extend' instruction.
8007 `SUBREG_PROMOTED_VAR_P (X)'
8008 Nonzero in a `subreg' if it was made when accessing an object that
8009 was promoted to a wider mode in accord with the `PROMOTED_MODE'
8010 machine description macro (*note Storage Layout::). In this case,
8011 the mode of the `subreg' is the declared mode of the object and
8012 the mode of `SUBREG_REG' is the mode of the register that holds
8013 the object. Promoted variables are always either sign- or
8014 zero-extended to the wider mode on every assignment. Stored in
8015 the `in_struct' field and printed as `/s'.
8017 `SYMBOL_REF_USED (X)'
8018 In a `symbol_ref', indicates that X has been used. This is
8019 normally only used to ensure that X is only declared external
8020 once. Stored in the `used' field.
8022 `SYMBOL_REF_WEAK (X)'
8023 In a `symbol_ref', indicates that X has been declared weak.
8024 Stored in the `integrated' field and printed as `/i'.
8026 `SYMBOL_REF_FLAG (X)'
8027 In a `symbol_ref', this is used as a flag for machine-specific
8028 purposes. Stored in the `volatil' field and printed as `/v'.
8030 Most uses of `SYMBOL_REF_FLAG' are historic and may be subsumed by
8031 `SYMBOL_REF_FLAGS'. Certainly use of `SYMBOL_REF_FLAGS' is
8032 mandatory if the target requires more than one bit of storage.
8034 These are the fields to which the above macros refer:
8037 In a `mem', 1 means that the memory reference will not trap.
8039 In an RTL dump, this flag is represented as `/c'.
8042 In an `insn' or `set' expression, 1 means that it is part of a
8043 function prologue and sets the stack pointer, sets the frame
8044 pointer, saves a register, or sets up a temporary register to use
8045 in place of the frame pointer.
8047 In `reg' expressions, 1 means that the register holds a pointer.
8049 In `symbol_ref' expressions, 1 means that the reference addresses
8050 this function's string constant pool.
8052 In `mem' expressions, 1 means that the reference is to a scalar.
8054 In an RTL dump, this flag is represented as `/f'.
8057 In `mem' expressions, it is 1 if the memory datum referred to is
8058 all or part of a structure or array; 0 if it is (or might be) a
8059 scalar variable. A reference through a C pointer has 0 because
8060 the pointer might point to a scalar variable. This information
8061 allows the compiler to determine something about possible cases of
8064 In `reg' expressions, it is 1 if the register has its entire life
8065 contained within the test expression of some loop.
8067 In `subreg' expressions, 1 means that the `subreg' is accessing an
8068 object that has had its mode promoted from a wider mode.
8070 In `label_ref' expressions, 1 means that the referenced label is
8071 outside the innermost loop containing the insn in which the
8072 `label_ref' was found.
8074 In `code_label' expressions, it is 1 if the label may never be
8075 deleted. This is used for labels which are the target of
8076 non-local gotos. Such a label that would have been deleted is
8077 replaced with a `note' of type `NOTE_INSN_DELETED_LABEL'.
8079 In an `insn' during dead-code elimination, 1 means that the insn is
8082 In an `insn' or `jump_insn' during reorg for an insn in the delay
8083 slot of a branch, 1 means that this insn is from the target of the
8086 In an `insn' during instruction scheduling, 1 means that this insn
8087 must be scheduled as part of a group together with the previous
8090 In an RTL dump, this flag is represented as `/s'.
8093 In an `insn', `insn_list', or `const', 1 means the RTL was
8094 produced by procedure integration.
8096 In `reg' expressions, 1 means the register contains the value to
8097 be returned by the current function. On machines that pass
8098 parameters in registers, the same register number may be used for
8099 parameters as well, but this flag is not set on such uses.
8101 In `symbol_ref' expressions, 1 means the referenced symbol is weak.
8103 In an RTL dump, this flag is represented as `/i'.
8106 In a `mem' expression, 1 means we should keep the alias set for
8107 this mem unchanged when we access a component.
8109 In a `set', 1 means it is for a return.
8111 In a `call_insn', 1 means it is a sibling call.
8113 In an RTL dump, this flag is represented as `/j'.
8116 In `reg' and `mem' expressions, 1 means that the value of the
8117 expression never changes.
8119 In `subreg' expressions, it is 1 if the `subreg' references an
8120 unsigned object whose mode has been promoted to a wider mode.
8122 In an `insn' or `jump_insn' in the delay slot of a branch
8123 instruction, 1 means an annulling branch should be used.
8125 In a `symbol_ref' expression, 1 means that this symbol addresses
8126 something in the per-function constant pool.
8128 In a `call_insn', `note', or an `expr_list' of notes, 1 means that
8129 this instruction is a call to a const or pure function.
8131 In an RTL dump, this flag is represented as `/u'.
8134 This flag is used directly (without an access macro) at the end of
8135 RTL generation for a function, to count the number of times an
8136 expression appears in insns. Expressions that appear more than
8137 once are copied, according to the rules for shared structure
8140 For a `reg', it is used directly (without an access macro) by the
8141 leaf register renumbering code to ensure that each register is only
8144 In a `symbol_ref', it indicates that an external declaration for
8145 the symbol has already been written.
8148 In a `mem', `asm_operands', or `asm_input' expression, it is 1 if
8149 the memory reference is volatile. Volatile memory references may
8150 not be deleted, reordered or combined.
8152 In a `symbol_ref' expression, it is used for machine-specific
8155 In a `reg' expression, it is 1 if the value is a user-level
8156 variable. 0 indicates an internal compiler temporary.
8158 In an `insn', 1 means the insn has been deleted.
8160 In `label_ref' and `reg_label' expressions, 1 means a reference to
8163 In an RTL dump, this flag is represented as `/v'.
8166 File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL
8171 A machine mode describes a size of data object and the representation
8172 used for it. In the C code, machine modes are represented by an
8173 enumeration type, `enum machine_mode', defined in `machmode.def'. Each
8174 RTL expression has room for a machine mode and so do certain kinds of
8175 tree expressions (declarations and types, to be precise).
8177 In debugging dumps and machine descriptions, the machine mode of an RTL
8178 expression is written after the expression code with a colon to separate
8179 them. The letters `mode' which appear at the end of each machine mode
8180 name are omitted. For example, `(reg:SI 38)' is a `reg' expression
8181 with machine mode `SImode'. If the mode is `VOIDmode', it is not
8184 Here is a table of machine modes. The term "byte" below refers to an
8185 object of `BITS_PER_UNIT' bits (*note Storage Layout::).
8188 "Bit" mode represents a single bit, for predicate registers.
8191 "Quarter-Integer" mode represents a single byte treated as an
8195 "Half-Integer" mode represents a two-byte integer.
8198 "Partial Single Integer" mode represents an integer which occupies
8199 four bytes but which doesn't really use all four. On some
8200 machines, this is the right mode to use for pointers.
8203 "Single Integer" mode represents a four-byte integer.
8206 "Partial Double Integer" mode represents an integer which occupies
8207 eight bytes but which doesn't really use all eight. On some
8208 machines, this is the right mode to use for certain pointers.
8211 "Double Integer" mode represents an eight-byte integer.
8214 "Tetra Integer" (?) mode represents a sixteen-byte integer.
8217 "Octa Integer" (?) mode represents a thirty-two-byte integer.
8220 "Quarter-Floating" mode represents a quarter-precision (single
8221 byte) floating point number.
8224 "Half-Floating" mode represents a half-precision (two byte)
8225 floating point number.
8228 "Three-Quarter-Floating" (?) mode represents a
8229 three-quarter-precision (three byte) floating point number.
8232 "Single Floating" mode represents a four byte floating point
8233 number. In the common case, of a processor with IEEE arithmetic
8234 and 8-bit bytes, this is a single-precision IEEE floating point
8235 number; it can also be used for double-precision (on processors
8236 with 16-bit bytes) and single-precision VAX and IBM types.
8239 "Double Floating" mode represents an eight byte floating point
8240 number. In the common case, of a processor with IEEE arithmetic
8241 and 8-bit bytes, this is a double-precision IEEE floating point
8245 "Extended Floating" mode represents an IEEE extended floating point
8246 number. This mode only has 80 meaningful bits (ten bytes). Some
8247 processors require such numbers to be padded to twelve bytes,
8248 others to sixteen; this mode is used for either.
8251 "Tetra Floating" mode represents a sixteen byte floating point
8252 number all 128 of whose bits are meaningful. One common use is the
8253 IEEE quad-precision format.
8256 "Condition Code" mode represents the value of a condition code,
8257 which is a machine-specific set of bits used to represent the
8258 result of a comparison operation. Other machine-specific modes
8259 may also be used for the condition code. These modes are not used
8260 on machines that use `cc0' (see *note Condition Code::).
8263 "Block" mode represents values that are aggregates to which none of
8264 the other modes apply. In RTL, only memory references can have
8265 this mode, and only if they appear in string-move or vector
8266 instructions. On machines which have no such instructions,
8267 `BLKmode' will not appear in RTL.
8270 Void mode means the absence of a mode or an unspecified mode. For
8271 example, RTL expressions of code `const_int' have mode `VOIDmode'
8272 because they can be taken to have whatever mode the context
8273 requires. In debugging dumps of RTL, `VOIDmode' is expressed by
8274 the absence of any mode.
8276 `QCmode, HCmode, SCmode, DCmode, XCmode, TCmode'
8277 These modes stand for a complex number represented as a pair of
8278 floating point values. The floating point values are in `QFmode',
8279 `HFmode', `SFmode', `DFmode', `XFmode', and `TFmode', respectively.
8281 `CQImode, CHImode, CSImode, CDImode, CTImode, COImode'
8282 These modes stand for a complex number represented as a pair of
8283 integer values. The integer values are in `QImode', `HImode',
8284 `SImode', `DImode', `TImode', and `OImode', respectively.
8286 The machine description defines `Pmode' as a C macro which expands
8287 into the machine mode used for addresses. Normally this is the mode
8288 whose size is `BITS_PER_WORD', `SImode' on 32-bit machines.
8290 The only modes which a machine description must support are `QImode',
8291 and the modes corresponding to `BITS_PER_WORD', `FLOAT_TYPE_SIZE' and
8292 `DOUBLE_TYPE_SIZE'. The compiler will attempt to use `DImode' for
8293 8-byte structures and unions, but this can be prevented by overriding
8294 the definition of `MAX_FIXED_MODE_SIZE'. Alternatively, you can have
8295 the compiler use `TImode' for 16-byte structures and unions. Likewise,
8296 you can arrange for the C type `short int' to avoid using `HImode'.
8298 Very few explicit references to machine modes remain in the compiler
8299 and these few references will soon be removed. Instead, the machine
8300 modes are divided into mode classes. These are represented by the
8301 enumeration type `enum mode_class' defined in `machmode.h'. The
8302 possible mode classes are:
8305 Integer modes. By default these are `BImode', `QImode', `HImode',
8306 `SImode', `DImode', `TImode', and `OImode'.
8309 The "partial integer" modes, `PQImode', `PHImode', `PSImode' and
8313 Floating point modes. By default these are `QFmode', `HFmode',
8314 `TQFmode', `SFmode', `DFmode', `XFmode' and `TFmode'.
8317 Complex integer modes. (These are not currently implemented).
8319 `MODE_COMPLEX_FLOAT'
8320 Complex floating point modes. By default these are `QCmode',
8321 `HCmode', `SCmode', `DCmode', `XCmode', and `TCmode'.
8324 Algol or Pascal function variables including a static chain.
8325 (These are not currently implemented).
8328 Modes representing condition code values. These are `CCmode' plus
8329 any `CC_MODE' modes listed in the `MACHINE-modes.def'. *Note Jump
8330 Patterns::, also see *Note Condition Code::.
8333 This is a catchall mode class for modes which don't fit into the
8334 above classes. Currently `VOIDmode' and `BLKmode' are in
8337 Here are some C macros that relate to machine modes:
8340 Returns the machine mode of the RTX X.
8342 `PUT_MODE (X, NEWMODE)'
8343 Alters the machine mode of the RTX X to be NEWMODE.
8346 Stands for the number of machine modes available on the target
8347 machine. This is one greater than the largest numeric value of any
8351 Returns the name of mode M as a string.
8353 `GET_MODE_CLASS (M)'
8354 Returns the mode class of mode M.
8356 `GET_MODE_WIDER_MODE (M)'
8357 Returns the next wider natural mode. For example, the expression
8358 `GET_MODE_WIDER_MODE (QImode)' returns `HImode'.
8361 Returns the size in bytes of a datum of mode M.
8363 `GET_MODE_BITSIZE (M)'
8364 Returns the size in bits of a datum of mode M.
8367 Returns a bitmask containing 1 for all bits in a word that fit
8368 within mode M. This macro can only be used for modes whose
8369 bitsize is less than or equal to `HOST_BITS_PER_INT'.
8371 `GET_MODE_ALIGNMENT (M)'
8372 Return the required alignment, in bits, for an object of mode M.
8374 `GET_MODE_UNIT_SIZE (M)'
8375 Returns the size in bytes of the subunits of a datum of mode M.
8376 This is the same as `GET_MODE_SIZE' except in the case of complex
8377 modes. For them, the unit size is the size of the real or
8380 `GET_MODE_NUNITS (M)'
8381 Returns the number of units contained in a mode, i.e.,
8382 `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'.
8384 `GET_CLASS_NARROWEST_MODE (C)'
8385 Returns the narrowest mode in mode class C.
8387 The global variables `byte_mode' and `word_mode' contain modes whose
8388 classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or
8389 `BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode'
8390 and `SImode', respectively.
8393 File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL
8395 11.7 Constant Expression Types
8396 ==============================
8398 The simplest RTL expressions are those that represent constant values.
8401 This type of expression represents the integer value I. I is
8402 customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)',
8403 which is equivalent to `XWINT (EXP, 0)'.
8405 Constants generated for modes with fewer bits than `HOST_WIDE_INT'
8406 must be sign extended to full width (e.g., with `gen_int_mode').
8408 There is only one expression object for the integer value zero; it
8409 is the value of the variable `const0_rtx'. Likewise, the only
8410 expression for integer value one is found in `const1_rtx', the only
8411 expression for integer value two is found in `const2_rtx', and the
8412 only expression for integer value negative one is found in
8413 `constm1_rtx'. Any attempt to create an expression of code
8414 `const_int' and value zero, one, two or negative one will return
8415 `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as
8418 Similarly, there is only one object for the integer whose value is
8419 `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If
8420 `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will
8421 point to the same object. If `STORE_FLAG_VALUE' is -1,
8422 `const_true_rtx' and `constm1_rtx' will point to the same object.
8424 `(const_double:M ADDR I0 I1 ...)'
8425 Represents either a floating-point constant of mode M or an
8426 integer constant too large to fit into `HOST_BITS_PER_WIDE_INT'
8427 bits but small enough to fit within twice that number of bits (GCC
8428 does not provide a mechanism to represent even larger constants).
8429 In the latter case, M will be `VOIDmode'.
8431 `(const_vector:M [X0 X1 ...])'
8432 Represents a vector constant. The square brackets stand for the
8433 vector containing the constant elements. X0, X1 and so on are the
8434 `const_int' or `const_double' elements.
8436 The number of units in a `const_vector' is obtained with the macro
8437 `CONST_VECTOR_NUNITS' as in `CONST_VECTOR_NUNITS (V)'.
8439 Individual elements in a vector constant are accessed with the
8440 macro `CONST_VECTOR_ELT' as in `CONST_VECTOR_ELT (V, N)' where V
8441 is the vector constant and N is the element desired.
8443 ADDR is used to contain the `mem' expression that corresponds to
8444 the location in memory that at which the constant can be found. If
8445 it has not been allocated a memory location, but is on the chain
8446 of all `const_double' expressions in this compilation (maintained
8447 using an undisplayed field), ADDR contains `const0_rtx'. If it is
8448 not on the chain, ADDR contains `cc0_rtx'. ADDR is customarily
8449 accessed with the macro `CONST_DOUBLE_MEM' and the chain field via
8450 `CONST_DOUBLE_CHAIN'.
8452 If M is `VOIDmode', the bits of the value are stored in I0 and I1.
8453 I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and
8454 I1 with `CONST_DOUBLE_HIGH'.
8456 If the constant is floating point (regardless of its precision),
8457 then the number of integers used to store the value depends on the
8458 size of `REAL_VALUE_TYPE' (*note Floating Point::). The integers
8459 represent a floating point number, but not precisely in the target
8460 machine's or host machine's floating point format. To convert
8461 them to the precise bit pattern used by the target machine, use
8462 the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data
8465 The macro `CONST0_RTX (MODE)' refers to an expression with value 0
8466 in mode MODE. If mode MODE is of mode class `MODE_INT', it
8467 returns `const0_rtx'. If mode MODE is of mode class `MODE_FLOAT',
8468 it returns a `CONST_DOUBLE' expression in mode MODE. Otherwise,
8469 it returns a `CONST_VECTOR' expression in mode MODE. Similarly,
8470 the macro `CONST1_RTX (MODE)' refers to an expression with value 1
8471 in mode MODE and similarly for `CONST2_RTX'. The `CONST1_RTX' and
8472 `CONST2_RTX' macros are undefined for vector modes.
8474 `(const_string STR)'
8475 Represents a constant string with value STR. Currently this is
8476 used only for insn attributes (*note Insn Attributes::) since
8477 constant strings in C are placed in memory.
8479 `(symbol_ref:MODE SYMBOL)'
8480 Represents the value of an assembler label for data. SYMBOL is a
8481 string that describes the name of the assembler label. If it
8482 starts with a `*', the label is the rest of SYMBOL not including
8483 the `*'. Otherwise, the label is SYMBOL, usually prefixed with
8486 The `symbol_ref' contains a mode, which is usually `Pmode'.
8487 Usually that is the only mode for which a symbol is directly valid.
8489 `(label_ref:MODE LABEL)'
8490 Represents the value of an assembler label for code. It contains
8491 one operand, an expression, which must be a `code_label' or a
8492 `note' of type `NOTE_INSN_DELETED_LABEL' that appears in the
8493 instruction sequence to identify the place where the label should
8496 The reason for using a distinct expression type for code label
8497 references is so that jump optimization can distinguish them.
8499 The `label_ref' contains a mode, which is usually `Pmode'.
8500 Usually that is the only mode for which a label is directly valid.
8503 Represents a constant that is the result of an assembly-time
8504 arithmetic computation. The operand, EXP, is an expression that
8505 contains only constants (`const_int', `symbol_ref' and `label_ref'
8506 expressions) combined with `plus' and `minus'. However, not all
8507 combinations are valid, since the assembler cannot do arbitrary
8508 arithmetic on relocatable symbols.
8510 M should be `Pmode'.
8513 Represents the high-order bits of EXP, usually a `symbol_ref'.
8514 The number of bits is machine-dependent and is normally the number
8515 of bits specified in an instruction that initializes the high
8516 order bits of a register. It is used with `lo_sum' to represent
8517 the typical two-instruction sequence used in RISC machines to
8518 reference a global memory location.
8520 M should be `Pmode'.
8523 File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL
8525 11.8 Registers and Memory
8526 =========================
8528 Here are the RTL expression types for describing access to machine
8529 registers and to main memory.
8532 For small values of the integer N (those that are less than
8533 `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine
8534 register number N: a "hard register". For larger values of N, it
8535 stands for a temporary value or "pseudo register". The compiler's
8536 strategy is to generate code assuming an unlimited number of such
8537 pseudo registers, and later convert them into hard registers or
8538 into memory references.
8540 M is the machine mode of the reference. It is necessary because
8541 machines can generally refer to each register in more than one
8542 mode. For example, a register may contain a full word but there
8543 may be instructions to refer to it as a half word or as a single
8544 byte, as well as instructions to refer to it as a floating point
8545 number of various precisions.
8547 Even for a register that the machine can access in only one mode,
8548 the mode must always be specified.
8550 The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine
8551 description, since the number of hard registers on the machine is
8552 an invariant characteristic of the machine. Note, however, that
8553 not all of the machine registers must be general registers. All
8554 the machine registers that can be used for storage of data are
8555 given hard register numbers, even those that can be used only in
8556 certain instructions or can hold only certain types of data.
8558 A hard register may be accessed in various modes throughout one
8559 function, but each pseudo register is given a natural mode and is
8560 accessed only in that mode. When it is necessary to describe an
8561 access to a pseudo register using a nonnatural mode, a `subreg'
8564 A `reg' expression with a machine mode that specifies more than
8565 one word of data may actually stand for several consecutive
8566 registers. If in addition the register number specifies a
8567 hardware register, then it actually represents several consecutive
8568 hardware registers starting with the specified one.
8570 Each pseudo register number used in a function's RTL code is
8571 represented by a unique `reg' expression.
8573 Some pseudo register numbers, those within the range of
8574 `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear
8575 during the RTL generation phase and are eliminated before the
8576 optimization phases. These represent locations in the stack frame
8577 that cannot be determined until RTL generation for the function
8578 has been completed. The following virtual register numbers are
8581 `VIRTUAL_INCOMING_ARGS_REGNUM'
8582 This points to the first word of the incoming arguments
8583 passed on the stack. Normally these arguments are placed
8584 there by the caller, but the callee may have pushed some
8585 arguments that were previously passed in registers.
8587 When RTL generation is complete, this virtual register is
8588 replaced by the sum of the register given by
8589 `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'.
8591 `VIRTUAL_STACK_VARS_REGNUM'
8592 If `FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this
8593 points to immediately above the first variable on the stack.
8594 Otherwise, it points to the first variable on the stack.
8596 `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the
8597 register given by `FRAME_POINTER_REGNUM' and the value
8598 `STARTING_FRAME_OFFSET'.
8600 `VIRTUAL_STACK_DYNAMIC_REGNUM'
8601 This points to the location of dynamically allocated memory
8602 on the stack immediately after the stack pointer has been
8603 adjusted by the amount of memory desired.
8605 This virtual register is replaced by the sum of the register
8606 given by `STACK_POINTER_REGNUM' and the value
8607 `STACK_DYNAMIC_OFFSET'.
8609 `VIRTUAL_OUTGOING_ARGS_REGNUM'
8610 This points to the location in the stack at which outgoing
8611 arguments should be written when the stack is pre-pushed
8612 (arguments pushed using push insns should always use
8613 `STACK_POINTER_REGNUM').
8615 This virtual register is replaced by the sum of the register
8616 given by `STACK_POINTER_REGNUM' and the value
8617 `STACK_POINTER_OFFSET'.
8619 `(subreg:M REG BYTENUM)'
8620 `subreg' expressions are used to refer to a register in a machine
8621 mode other than its natural one, or to refer to one register of a
8622 multi-part `reg' that actually refers to several registers.
8624 Each pseudo-register has a natural mode. If it is necessary to
8625 operate on it in a different mode--for example, to perform a
8626 fullword move instruction on a pseudo-register that contains a
8627 single byte--the pseudo-register must be enclosed in a `subreg'.
8628 In such a case, BYTENUM is zero.
8630 Usually M is at least as narrow as the mode of REG, in which case
8631 it is restricting consideration to only the bits of REG that are
8634 Sometimes M is wider than the mode of REG. These `subreg'
8635 expressions are often called "paradoxical". They are used in
8636 cases where we want to refer to an object in a wider mode but do
8637 not care what value the additional bits have. The reload pass
8638 ensures that paradoxical references are only made to hard
8641 The other use of `subreg' is to extract the individual registers of
8642 a multi-register value. Machine modes such as `DImode' and
8643 `TImode' can indicate values longer than a word, values which
8644 usually require two or more consecutive registers. To access one
8645 of the registers, use a `subreg' with mode `SImode' and a BYTENUM
8646 offset that says which register.
8648 Storing in a non-paradoxical `subreg' has undefined results for
8649 bits belonging to the same word as the `subreg'. This laxity makes
8650 it easier to generate efficient code for such instructions. To
8651 represent an instruction that preserves all the bits outside of
8652 those in the `subreg', use `strict_low_part' around the `subreg'.
8654 The compilation parameter `WORDS_BIG_ENDIAN', if set to 1, says
8655 that byte number zero is part of the most significant word;
8656 otherwise, it is part of the least significant word.
8658 The compilation parameter `BYTES_BIG_ENDIAN', if set to 1, says
8659 that byte number zero is the most significant byte within a word;
8660 otherwise, it is the least significant byte within a word.
8662 On a few targets, `FLOAT_WORDS_BIG_ENDIAN' disagrees with
8663 `WORDS_BIG_ENDIAN'. However, most parts of the compiler treat
8664 floating point values as if they had the same endianness as
8665 integer values. This works because they handle them solely as a
8666 collection of integer values, with no particular numerical value.
8667 Only real.c and the runtime libraries care about
8668 `FLOAT_WORDS_BIG_ENDIAN'.
8670 Between the combiner pass and the reload pass, it is possible to
8671 have a paradoxical `subreg' which contains a `mem' instead of a
8672 `reg' as its first operand. After the reload pass, it is also
8673 possible to have a non-paradoxical `subreg' which contains a
8674 `mem'; this usually occurs when the `mem' is a stack slot which
8675 replaced a pseudo register.
8677 Note that it is not valid to access a `DFmode' value in `SFmode'
8678 using a `subreg'. On some machines the most significant part of a
8679 `DFmode' value does not have the same format as a single-precision
8682 It is also not valid to access a single word of a multi-word value
8683 in a hard register when less registers can hold the value than
8684 would be expected from its size. For example, some 32-bit
8685 machines have floating-point registers that can hold an entire
8686 `DFmode' value. If register 10 were such a register `(subreg:SI
8687 (reg:DF 10) 4)' would be invalid because there is no way to
8688 convert that reference to a single machine register. The reload
8689 pass prevents `subreg' expressions such as these from being formed.
8691 The first operand of a `subreg' expression is customarily accessed
8692 with the `SUBREG_REG' macro and the second operand is customarily
8693 accessed with the `SUBREG_BYTE' macro.
8696 This represents a scratch register that will be required for the
8697 execution of a single instruction and not used subsequently. It is
8698 converted into a `reg' by either the local register allocator or
8701 `scratch' is usually present inside a `clobber' operation (*note
8705 This refers to the machine's condition code register. It has no
8706 operands and may not have a machine mode. There are two ways to
8709 * To stand for a complete set of condition code flags. This is
8710 best on most machines, where each comparison sets the entire
8713 With this technique, `(cc0)' may be validly used in only two
8714 contexts: as the destination of an assignment (in test and
8715 compare instructions) and in comparison operators comparing
8716 against zero (`const_int' with value zero; that is to say,
8719 * To stand for a single flag that is the result of a single
8720 condition. This is useful on machines that have only a
8721 single flag bit, and in which comparison instructions must
8722 specify the condition to test.
8724 With this technique, `(cc0)' may be validly used in only two
8725 contexts: as the destination of an assignment (in test and
8726 compare instructions) where the source is a comparison
8727 operator, and as the first operand of `if_then_else' (in a
8728 conditional branch).
8730 There is only one expression object of code `cc0'; it is the value
8731 of the variable `cc0_rtx'. Any attempt to create an expression of
8732 code `cc0' will return `cc0_rtx'.
8734 Instructions can set the condition code implicitly. On many
8735 machines, nearly all instructions set the condition code based on
8736 the value that they compute or store. It is not necessary to
8737 record these actions explicitly in the RTL because the machine
8738 description includes a prescription for recognizing the
8739 instructions that do so (by means of the macro
8740 `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions
8741 whose sole purpose is to set the condition code, and instructions
8742 that use the condition code, need mention `(cc0)'.
8744 On some machines, the condition code register is given a register
8745 number and a `reg' is used instead of `(cc0)'. This is usually the
8746 preferable approach if only a small subset of instructions modify
8747 the condition code. Other machines store condition codes in
8748 general registers; in such cases a pseudo register should be used.
8750 Some machines, such as the SPARC and RS/6000, have two sets of
8751 arithmetic instructions, one that sets and one that does not set
8752 the condition code. This is best handled by normally generating
8753 the instruction that does not set the condition code, and making a
8754 pattern that both performs the arithmetic and sets the condition
8755 code register (which would not be `(cc0)' in this case). For
8756 examples, search for `addcc' and `andcc' in `sparc.md'.
8759 This represents the machine's program counter. It has no operands
8760 and may not have a machine mode. `(pc)' may be validly used only
8761 in certain specific contexts in jump instructions.
8763 There is only one expression object of code `pc'; it is the value
8764 of the variable `pc_rtx'. Any attempt to create an expression of
8765 code `pc' will return `pc_rtx'.
8767 All instructions that do not jump alter the program counter
8768 implicitly by incrementing it, but there is no need to mention
8771 `(mem:M ADDR ALIAS)'
8772 This RTX represents a reference to main memory at an address
8773 represented by the expression ADDR. M specifies how large a unit
8774 of memory is accessed. ALIAS specifies an alias set for the
8775 reference. In general two items are in different alias sets if
8776 they cannot reference the same memory address.
8778 The construct `(mem:BLK (scratch))' is considered to alias all
8779 other memories. Thus it may be used as a memory barrier in
8780 epilogue stack deallocation patterns.
8783 This RTX represents a request for the address of register REG.
8784 Its mode is always `Pmode'. If there are any `addressof'
8785 expressions left in the function after CSE, REG is forced into the
8786 stack and the `addressof' expression is replaced with a `plus'
8787 expression for the address of its stack slot.
8790 File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL
8792 11.9 RTL Expressions for Arithmetic
8793 ===================================
8795 Unless otherwise specified, all the operands of arithmetic expressions
8796 must be valid for mode M. An operand is valid for mode M if it has
8797 mode M, or if it is a `const_int' or `const_double' and M is a mode of
8800 For commutative binary operations, constants should be placed in the
8806 These three expressions all represent the sum of the values
8807 represented by X and Y carried out in machine mode M. They differ
8808 in their behavior on overflow of integer modes. `plus' wraps
8809 round modulo the width of M; `ss_plus' saturates at the maximum
8810 signed value representable in M; `us_plus' saturates at the
8811 maximum unsigned value.
8814 This expression represents the sum of X and the low-order bits of
8815 Y. It is used with `high' (*note Constants::) to represent the
8816 typical two-instruction sequence used in RISC machines to
8817 reference a global memory location.
8819 The number of low order bits is machine-dependent but is normally
8820 the number of bits in a `Pmode' item minus the number of bits set
8823 M should be `Pmode'.
8828 These three expressions represent the result of subtracting Y from
8829 X, carried out in mode M. Behavior on overflow is the same as for
8830 the three variants of `plus' (see above).
8833 Represents the result of subtracting Y from X for purposes of
8834 comparison. The result is computed without overflow, as if with
8837 Of course, machines can't really subtract with infinite precision.
8838 However, they can pretend to do so when only the sign of the
8839 result will be used, which is the case when the result is stored
8840 in the condition code. And that is the _only_ way this kind of
8841 expression may validly be used: as a value to be stored in the
8842 condition codes, either `(cc0)' or a register. *Note
8845 The mode M is not related to the modes of X and Y, but instead is
8846 the mode of the condition code value. If `(cc0)' is used, it is
8847 `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often
8848 `CCmode'. *Note Condition Code::. If M is `VOIDmode' or
8849 `CCmode', the operation returns sufficient information (in an
8850 unspecified format) so that any comparison operator can be applied
8851 to the result of the `COMPARE' operation. For other modes in
8852 class `MODE_CC', the operation only returns a subset of this
8855 Normally, X and Y must have the same mode. Otherwise, `compare'
8856 is valid only if the mode of X is in class `MODE_INT' and Y is a
8857 `const_int' or `const_double' with mode `VOIDmode'. The mode of X
8858 determines what mode the comparison is to be done in; thus it must
8861 If one of the operands is a constant, it should be placed in the
8862 second operand and the comparison code adjusted as appropriate.
8864 A `compare' specifying two `VOIDmode' constants is not valid since
8865 there is no way to know in what mode the comparison is to be
8866 performed; the comparison must either be folded during the
8867 compilation or the first operand must be loaded into a register
8868 while its mode is still known.
8871 Represents the negation (subtraction from zero) of the value
8872 represented by X, carried out in mode M.
8875 Represents the signed product of the values represented by X and Y
8876 carried out in machine mode M.
8878 Some machines support a multiplication that generates a product
8879 wider than the operands. Write the pattern for this as
8881 (mult:M (sign_extend:M X) (sign_extend:M Y))
8883 where M is wider than the modes of X and Y, which need not be the
8886 For unsigned widening multiplication, use the same idiom, but with
8887 `zero_extend' instead of `sign_extend'.
8890 Represents the quotient in signed division of X by Y, carried out
8891 in machine mode M. If M is a floating point mode, it represents
8892 the exact quotient; otherwise, the integerized quotient.
8894 Some machines have division instructions in which the operands and
8895 quotient widths are not all the same; you should represent such
8896 instructions using `truncate' and `sign_extend' as in,
8898 (truncate:M1 (div:M2 X (sign_extend:M2 Y)))
8901 Like `div' but represents unsigned division.
8905 Like `div' and `udiv' but represent the remainder instead of the
8910 Represents the smaller (for `smin') or larger (for `smax') of X
8911 and Y, interpreted as signed values in mode M. When used with
8912 floating point, if both operands are zeros, or if either operand
8913 is `NaN', then it is unspecified which of the two operands is
8914 returned as the result.
8918 Like `smin' and `smax', but the values are interpreted as unsigned
8922 Represents the bitwise complement of the value represented by X,
8923 carried out in mode M, which must be a fixed-point machine mode.
8926 Represents the bitwise logical-and of the values represented by X
8927 and Y, carried out in machine mode M, which must be a fixed-point
8931 Represents the bitwise inclusive-or of the values represented by X
8932 and Y, carried out in machine mode M, which must be a fixed-point
8936 Represents the bitwise exclusive-or of the values represented by X
8937 and Y, carried out in machine mode M, which must be a fixed-point
8941 Represents the result of arithmetically shifting X left by C
8942 places. X have mode M, a fixed-point machine mode. C be a
8943 fixed-point mode or be a constant with mode `VOIDmode'; which mode
8944 is determined by the mode called for in the machine description
8945 entry for the left-shift instruction. For example, on the VAX,
8946 the mode of C is `QImode' regardless of M.
8950 Like `ashift' but for right shift. Unlike the case for left shift,
8951 these two operations are distinct.
8955 Similar but represent left and right rotate. If C is a constant,
8959 Represents the absolute value of X, computed in mode M.
8962 Represents the square root of X, computed in mode M. Most often M
8963 will be a floating point mode.
8966 Represents one plus the index of the least significant 1-bit in X,
8967 represented as an integer of mode M. (The value is zero if X is
8968 zero.) The mode of X need not be M; depending on the target
8969 machine, various mode combinations may be valid.
8972 Represents the number of leading 0-bits in X, represented as an
8973 integer of mode M, starting at the most significant bit position.
8974 If X is zero, the value is determined by
8975 `CLZ_DEFINED_VALUE_AT_ZERO'. Note that this is one of the few
8976 expressions that is not invariant under widening. The mode of X
8977 will usually be an integer mode.
8980 Represents the number of trailing 0-bits in X, represented as an
8981 integer of mode M, starting at the least significant bit position.
8982 If X is zero, the value is determined by
8983 `CTZ_DEFINED_VALUE_AT_ZERO'. Except for this case, `ctz(x)' is
8984 equivalent to `ffs(X) - 1'. The mode of X will usually be an
8988 Represents the number of 1-bits in X, represented as an integer of
8989 mode M. The mode of X will usually be an integer mode.
8992 Represents the number of 1-bits modulo 2 in X, represented as an
8993 integer of mode M. The mode of X will usually be an integer mode.
8996 File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL
8998 11.10 Comparison Operations
8999 ===========================
9001 Comparison operators test a relation on two operands and are considered
9002 to represent a machine-dependent nonzero value described by, but not
9003 necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::) if the relation
9004 holds, or zero if it does not, for comparison operators whose results
9005 have a `MODE_INT' mode, `FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the
9006 relation holds, or zero if it does not, for comparison operators that
9007 return floating-point values, and a vector of either
9008 `VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of
9009 zeros if it does not, for comparison operators that return vector
9010 results. The mode of the comparison operation is independent of the
9011 mode of the data being compared. If the comparison operation is being
9012 tested (e.g., the first operand of an `if_then_else'), the mode must be
9015 There are two ways that comparison operations may be used. The
9016 comparison operators may be used to compare the condition codes `(cc0)'
9017 against zero, as in `(eq (cc0) (const_int 0))'. Such a construct
9018 actually refers to the result of the preceding instruction in which the
9019 condition codes were set. The instruction setting the condition code
9020 must be adjacent to the instruction using the condition code; only
9021 `note' insns may separate them.
9023 Alternatively, a comparison operation may directly compare two data
9024 objects. The mode of the comparison is determined by the operands; they
9025 must both be valid for a common machine mode. A comparison with both
9026 operands constant would be invalid as the machine mode could not be
9027 deduced from it, but such a comparison should never exist in RTL due to
9030 In the example above, if `(cc0)' were last set to `(compare X Y)', the
9031 comparison operation is identical to `(eq X Y)'. Usually only one style
9032 of comparisons is supported on a particular machine, but the combine
9033 pass will try to merge the operations to produce the `eq' shown in case
9034 it exists in the context of the particular insn involved.
9036 Inequality comparisons come in two flavors, signed and unsigned. Thus,
9037 there are distinct expression codes `gt' and `gtu' for signed and
9038 unsigned greater-than. These can produce different results for the same
9039 pair of integer values: for example, 1 is signed greater-than -1 but not
9040 unsigned greater-than, because -1 when regarded as unsigned is actually
9041 `0xffffffff' which is greater than 1.
9043 The signed comparisons are also used for floating point values.
9044 Floating point comparisons are distinguished by the machine modes of
9048 `STORE_FLAG_VALUE' if the values represented by X and Y are equal,
9052 `STORE_FLAG_VALUE' if the values represented by X and Y are not
9056 `STORE_FLAG_VALUE' if the X is greater than Y. If they are
9057 fixed-point, the comparison is done in a signed sense.
9060 Like `gt' but does unsigned comparison, on fixed-point numbers
9065 Like `gt' and `gtu' but test for "less than".
9069 Like `gt' and `gtu' but test for "greater than or equal".
9073 Like `gt' and `gtu' but test for "less than or equal".
9075 `(if_then_else COND THEN ELSE)'
9076 This is not a comparison operation but is listed here because it is
9077 always used in conjunction with a comparison operation. To be
9078 precise, COND is a comparison expression. This expression
9079 represents a choice, according to COND, between the value
9080 represented by THEN and the one represented by ELSE.
9082 On most machines, `if_then_else' expressions are valid only to
9083 express conditional jumps.
9085 `(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)'
9086 Similar to `if_then_else', but more general. Each of TEST1,
9087 TEST2, ... is performed in turn. The result of this expression is
9088 the VALUE corresponding to the first nonzero test, or DEFAULT if
9089 none of the tests are nonzero expressions.
9091 This is currently not valid for instruction patterns and is
9092 supported only for insn attributes. *Note Insn Attributes::.
9095 File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL
9100 Special expression codes exist to represent bit-field instructions.
9102 `(sign_extract:M LOC SIZE POS)'
9103 This represents a reference to a sign-extended bit-field contained
9104 or starting in LOC (a memory or register reference). The bit-field
9105 is SIZE bits wide and starts at bit POS. The compilation option
9106 `BITS_BIG_ENDIAN' says which end of the memory unit POS counts
9109 If LOC is in memory, its mode must be a single-byte integer mode.
9110 If LOC is in a register, the mode to use is specified by the
9111 operand of the `insv' or `extv' pattern (*note Standard Names::)
9112 and is usually a full-word integer mode, which is the default if
9115 The mode of POS is machine-specific and is also specified in the
9116 `insv' or `extv' pattern.
9118 The mode M is the same as the mode that would be used for LOC if
9121 A `sign_extract' can not appear as an lvalue, or part thereof, in
9124 `(zero_extract:M LOC SIZE POS)'
9125 Like `sign_extract' but refers to an unsigned or zero-extended
9126 bit-field. The same sequence of bits are extracted, but they are
9127 filled to an entire word with zeros instead of by sign-extension.
9129 Unlike `sign_extract', this type of expressions can be lvalues in
9130 RTL; they may appear on the left side of an assignment, indicating
9131 insertion of a value into the specified bit-field.
9134 File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL
9136 11.12 Vector Operations
9137 =======================
9139 All normal RTL expressions can be used with vector modes; they are
9140 interpreted as operating on each part of the vector independently.
9141 Additionally, there are a few new expressions to describe specific
9144 `(vec_merge:M VEC1 VEC2 ITEMS)'
9145 This describes a merge operation between two vectors. The result
9146 is a vector of mode M; its elements are selected from either VEC1
9147 or VEC2. Which elements are selected is described by ITEMS, which
9148 is a bit mask represented by a `const_int'; a zero bit indicates
9149 the corresponding element in the result vector is taken from VEC2
9150 while a set bit indicates it is taken from VEC1.
9152 `(vec_select:M VEC1 SELECTION)'
9153 This describes an operation that selects parts of a vector. VEC1
9154 is the source vector, SELECTION is a `parallel' that contains a
9155 `const_int' for each of the subparts of the result vector, giving
9156 the number of the source subpart that should be stored into it.
9158 `(vec_concat:M VEC1 VEC2)'
9159 Describes a vector concat operation. The result is a
9160 concatenation of the vectors VEC1 and VEC2; its length is the sum
9161 of the lengths of the two inputs.
9163 `(vec_duplicate:M VEC)'
9164 This operation converts a small vector into a larger one by
9165 duplicating the input values. The output vector mode must have
9166 the same submodes as the input vector mode, and the number of
9167 output parts must be an integer multiple of the number of input
9172 File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL
9177 All conversions between machine modes must be represented by explicit
9178 conversion operations. For example, an expression which is the sum of
9179 a byte and a full word cannot be written as `(plus:SI (reg:QI 34)
9180 (reg:SI 80))' because the `plus' operation requires two operands of the
9181 same machine mode. Therefore, the byte-sized operand is enclosed in a
9182 conversion operation, as in
9184 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80))
9186 The conversion operation is not a mere placeholder, because there may
9187 be more than one way of converting from a given starting mode to the
9188 desired final mode. The conversion operation code says how to do it.
9190 For all conversion operations, X must not be `VOIDmode' because the
9191 mode in which to do the conversion would not be known. The conversion
9192 must either be done at compile-time or X must be placed into a register.
9195 Represents the result of sign-extending the value X to machine
9196 mode M. M must be a fixed-point mode and X a fixed-point value of
9197 a mode narrower than M.
9200 Represents the result of zero-extending the value X to machine
9201 mode M. M must be a fixed-point mode and X a fixed-point value of
9202 a mode narrower than M.
9204 `(float_extend:M X)'
9205 Represents the result of extending the value X to machine mode M.
9206 M must be a floating point mode and X a floating point value of a
9207 mode narrower than M.
9210 Represents the result of truncating the value X to machine mode M.
9211 M must be a fixed-point mode and X a fixed-point value of a mode
9215 Represents the result of truncating the value X to machine mode M,
9216 using signed saturation in the case of overflow. Both M and the
9217 mode of X must be fixed-point modes.
9220 Represents the result of truncating the value X to machine mode M,
9221 using unsigned saturation in the case of overflow. Both M and the
9222 mode of X must be fixed-point modes.
9224 `(float_truncate:M X)'
9225 Represents the result of truncating the value X to machine mode M.
9226 M must be a floating point mode and X a floating point value of a
9230 Represents the result of converting fixed point value X, regarded
9231 as signed, to floating point mode M.
9233 `(unsigned_float:M X)'
9234 Represents the result of converting fixed point value X, regarded
9235 as unsigned, to floating point mode M.
9238 When M is a fixed point mode, represents the result of converting
9239 floating point value X to mode M, regarded as signed. How
9240 rounding is done is not specified, so this operation may be used
9241 validly in compiling C code only for integer-valued operands.
9243 `(unsigned_fix:M X)'
9244 Represents the result of converting floating point value X to
9245 fixed point mode M, regarded as unsigned. How rounding is done is
9249 When M is a floating point mode, represents the result of
9250 converting floating point value X (valid for mode M) to an
9251 integer, still represented in floating point mode M, by rounding
9255 File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL
9260 Declaration expression codes do not represent arithmetic operations but
9261 rather state assertions about their operands.
9263 `(strict_low_part (subreg:M (reg:N R) 0))'
9264 This expression code is used in only one context: as the
9265 destination operand of a `set' expression. In addition, the
9266 operand of this expression must be a non-paradoxical `subreg'
9269 The presence of `strict_low_part' says that the part of the
9270 register which is meaningful in mode N, but is not part of mode M,
9271 is not to be altered. Normally, an assignment to such a subreg is
9272 allowed to have undefined effects on the rest of the register when
9273 M is less than a word.
9276 File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL
9278 11.15 Side Effect Expressions
9279 =============================
9281 The expression codes described so far represent values, not actions.
9282 But machine instructions never produce values; they are meaningful only
9283 for their side effects on the state of the machine. Special expression
9284 codes are used to represent side effects.
9286 The body of an instruction is always one of these side effect codes;
9287 the codes described above, which represent values, appear only as the
9291 Represents the action of storing the value of X into the place
9292 represented by LVAL. LVAL must be an expression representing a
9293 place that can be stored in: `reg' (or `subreg', `strict_low_part'
9294 or `zero_extract'), `mem', `pc', `parallel', or `cc0'.
9296 If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then
9297 X must be valid for that mode.
9299 If LVAL is a `reg' whose machine mode is less than the full width
9300 of the register, then it means that the part of the register
9301 specified by the machine mode is given the specified value and the
9302 rest of the register receives an undefined value. Likewise, if
9303 LVAL is a `subreg' whose machine mode is narrower than the mode of
9304 the register, the rest of the register can be changed in an
9307 If LVAL is a `strict_low_part' of a subreg, then the part of the
9308 register specified by the machine mode of the `subreg' is given
9309 the value X and the rest of the register is not changed.
9311 If LVAL is a `zero_extract', then the referenced part of the
9312 bit-field (a memory or register reference) specified by the
9313 `zero_extract' is given the value X and the rest of the bit-field
9314 is not changed. Note that `sign_extract' can not appear in LVAL.
9316 If LVAL is `(cc0)', it has no machine mode, and X may be either a
9317 `compare' expression or a value that may have any mode. The
9318 latter case represents a "test" instruction. The expression `(set
9319 (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N)
9320 (const_int 0)))'. Use the former expression to save space during
9323 If LVAL is a `parallel', it is used to represent the case of a
9324 function returning a structure in multiple registers. Each element
9325 of the `parallel' is an `expr_list' whose first operand is a `reg'
9326 and whose second operand is a `const_int' representing the offset
9327 (in bytes) into the structure at which the data in that register
9328 corresponds. The first element may be null to indicate that the
9329 structure is also passed partly in memory.
9331 If LVAL is `(pc)', we have a jump instruction, and the
9332 possibilities for X are very limited. It may be a `label_ref'
9333 expression (unconditional jump). It may be an `if_then_else'
9334 (conditional jump), in which case either the second or the third
9335 operand must be `(pc)' (for the case which does not jump) and the
9336 other of the two must be a `label_ref' (for the case which does
9337 jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may
9338 be a `reg' or a `mem'; these unusual patterns are used to
9339 represent jumps through branch tables.
9341 If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not
9342 be `VOIDmode' and the mode of X must be valid for the mode of LVAL.
9344 LVAL is customarily accessed with the `SET_DEST' macro and X with
9345 the `SET_SRC' macro.
9348 As the sole expression in a pattern, represents a return from the
9349 current function, on machines where this can be done with one
9350 instruction, such as VAXen. On machines where a multi-instruction
9351 "epilogue" must be executed in order to return from the function,
9352 returning is done by jumping to a label which precedes the
9353 epilogue, and the `return' expression code is never used.
9355 Inside an `if_then_else' expression, represents the value to be
9356 placed in `pc' to return to the caller.
9358 Note that an insn pattern of `(return)' is logically equivalent to
9359 `(set (pc) (return))', but the latter form is never used.
9361 `(call FUNCTION NARGS)'
9362 Represents a function call. FUNCTION is a `mem' expression whose
9363 address is the address of the function to be called. NARGS is an
9364 expression which can be used for two purposes: on some machines it
9365 represents the number of bytes of stack argument; on others, it
9366 represents the number of argument registers.
9368 Each machine has a standard machine mode which FUNCTION must have.
9369 The machine description defines macro `FUNCTION_MODE' to expand
9370 into the requisite mode name. The purpose of this mode is to
9371 specify what kind of addressing is allowed, on machines where the
9372 allowed kinds of addressing depend on the machine mode being
9376 Represents the storing or possible storing of an unpredictable,
9377 undescribed value into X, which must be a `reg', `scratch',
9378 `parallel' or `mem' expression.
9380 One place this is used is in string instructions that store
9381 standard values into particular hard registers. It may not be
9382 worth the trouble to describe the values that are stored, but it
9383 is essential to inform the compiler that the registers will be
9384 altered, lest it attempt to keep data in them across the string
9387 If X is `(mem:BLK (const_int 0))' or `(mem:BLK (scratch))', it
9388 means that all memory locations must be presumed clobbered. If X
9389 is a `parallel', it has the same meaning as a `parallel' in a
9392 Note that the machine description classifies certain hard
9393 registers as "call-clobbered". All function call instructions are
9394 assumed by default to clobber these registers, so there is no need
9395 to use `clobber' expressions to indicate this fact. Also, each
9396 function call is assumed to have the potential to alter any memory
9397 location, unless the function is declared `const'.
9399 If the last group of expressions in a `parallel' are each a
9400 `clobber' expression whose arguments are `reg' or `match_scratch'
9401 (*note RTL Template::) expressions, the combiner phase can add the
9402 appropriate `clobber' expressions to an insn it has constructed
9403 when doing so will cause a pattern to be matched.
9405 This feature can be used, for example, on a machine that whose
9406 multiply and add instructions don't use an MQ register but which
9407 has an add-accumulate instruction that does clobber the MQ
9408 register. Similarly, a combined instruction might require a
9409 temporary register while the constituent instructions might not.
9411 When a `clobber' expression for a register appears inside a
9412 `parallel' with other side effects, the register allocator
9413 guarantees that the register is unoccupied both before and after
9414 that insn. However, the reload phase may allocate a register used
9415 for one of the inputs unless the `&' constraint is specified for
9416 the selected alternative (*note Modifiers::). You can clobber
9417 either a specific hard register, a pseudo register, or a `scratch'
9418 expression; in the latter two cases, GCC will allocate a hard
9419 register that is available there for use as a temporary.
9421 For instructions that require a temporary register, you should use
9422 `scratch' instead of a pseudo-register because this will allow the
9423 combiner phase to add the `clobber' when required. You do this by
9424 coding (`clobber' (`match_scratch' ...)). If you do clobber a
9425 pseudo register, use one which appears nowhere else--generate a
9426 new one each time. Otherwise, you may confuse CSE.
9428 There is one other known use for clobbering a pseudo register in a
9429 `parallel': when one of the input operands of the insn is also
9430 clobbered by the insn. In this case, using the same pseudo
9431 register in the clobber and elsewhere in the insn produces the
9435 Represents the use of the value of X. It indicates that the value
9436 in X at this point in the program is needed, even though it may
9437 not be apparent why this is so. Therefore, the compiler will not
9438 attempt to delete previous instructions whose only effect is to
9439 store a value in X. X must be a `reg' expression.
9441 In some situations, it may be tempting to add a `use' of a
9442 register in a `parallel' to describe a situation where the value
9443 of a special register will modify the behavior of the instruction.
9444 An hypothetical example might be a pattern for an addition that can
9445 either wrap around or use saturating addition depending on the
9446 value of a special control register:
9448 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3)
9452 This will not work, several of the optimizers only look at
9453 expressions locally; it is very likely that if you have multiple
9454 insns with identical inputs to the `unspec', they will be
9455 optimized away even if register 1 changes in between.
9457 This means that `use' can _only_ be used to describe that the
9458 register is live. You should think twice before adding `use'
9459 statements, more often you will want to use `unspec' instead. The
9460 `use' RTX is most commonly useful to describe that a fixed
9461 register is implicitly used in an insn. It is also safe to use in
9462 patterns where the compiler knows for other reasons that the result
9463 of the whole pattern is variable, such as `movmemM' or `call'
9466 During the reload phase, an insn that has a `use' as pattern can
9467 carry a reg_equal note. These `use' insns will be deleted before
9468 the reload phase exits.
9470 During the delayed branch scheduling phase, X may be an insn.
9471 This indicates that X previously was located at this place in the
9472 code and its data dependencies need to be taken into account.
9473 These `use' insns will be deleted before the delayed branch
9474 scheduling phase exits.
9476 `(parallel [X0 X1 ...])'
9477 Represents several side effects performed in parallel. The square
9478 brackets stand for a vector; the operand of `parallel' is a vector
9479 of expressions. X0, X1 and so on are individual side effect
9480 expressions--expressions of code `set', `call', `return',
9483 "In parallel" means that first all the values used in the
9484 individual side-effects are computed, and second all the actual
9485 side-effects are performed. For example,
9487 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
9488 (set (mem:SI (reg:SI 1)) (reg:SI 1))])
9490 says unambiguously that the values of hard register 1 and the
9491 memory location addressed by it are interchanged. In both places
9492 where `(reg:SI 1)' appears as a memory address it refers to the
9493 value in register 1 _before_ the execution of the insn.
9495 It follows that it is _incorrect_ to use `parallel' and expect the
9496 result of one `set' to be available for the next one. For
9497 example, people sometimes attempt to represent a jump-if-zero
9498 instruction this way:
9500 (parallel [(set (cc0) (reg:SI 34))
9501 (set (pc) (if_then_else
9502 (eq (cc0) (const_int 0))
9506 But this is incorrect, because it says that the jump condition
9507 depends on the condition code value _before_ this instruction, not
9508 on the new value that is set by this instruction.
9510 Peephole optimization, which takes place together with final
9511 assembly code output, can produce insns whose patterns consist of
9512 a `parallel' whose elements are the operands needed to output the
9513 resulting assembler code--often `reg', `mem' or constant
9514 expressions. This would not be well-formed RTL at any other stage
9515 in compilation, but it is ok then because no further optimization
9516 remains to be done. However, the definition of the macro
9517 `NOTICE_UPDATE_CC', if any, must deal with such insns if you
9518 define any peephole optimizations.
9520 `(cond_exec [COND EXPR])'
9521 Represents a conditionally executed expression. The EXPR is
9522 executed only if the COND is nonzero. The COND expression must
9523 not have side-effects, but the EXPR may very well have
9526 `(sequence [INSNS ...])'
9527 Represents a sequence of insns. Each of the INSNS that appears in
9528 the vector is suitable for appearing in the chain of insns, so it
9529 must be an `insn', `jump_insn', `call_insn', `code_label',
9530 `barrier' or `note'.
9532 A `sequence' RTX is never placed in an actual insn during RTL
9533 generation. It represents the sequence of insns that result from a
9534 `define_expand' _before_ those insns are passed to `emit_insn' to
9535 insert them in the chain of insns. When actually inserted, the
9536 individual sub-insns are separated out and the `sequence' is
9539 After delay-slot scheduling is completed, an insn and all the
9540 insns that reside in its delay slots are grouped together into a
9541 `sequence'. The insn requiring the delay slot is the first insn
9542 in the vector; subsequent insns are to be placed in the delay slot.
9544 `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to
9545 indicate that a branch insn should be used that will conditionally
9546 annul the effect of the insns in the delay slots. In such a case,
9547 `INSN_FROM_TARGET_P' indicates that the insn is from the target of
9548 the branch and should be executed only if the branch is taken;
9549 otherwise the insn should be executed only if the branch is not
9550 taken. *Note Delay Slots::.
9552 These expression codes appear in place of a side effect, as the body of
9553 an insn, though strictly speaking they do not always describe side
9557 Represents literal assembler code as described by the string S.
9559 `(unspec [OPERANDS ...] INDEX)'
9560 `(unspec_volatile [OPERANDS ...] INDEX)'
9561 Represents a machine-specific operation on OPERANDS. INDEX
9562 selects between multiple machine-specific operations.
9563 `unspec_volatile' is used for volatile operations and operations
9564 that may trap; `unspec' is used for other operations.
9566 These codes may appear inside a `pattern' of an insn, inside a
9567 `parallel', or inside an expression.
9569 `(addr_vec:M [LR0 LR1 ...])'
9570 Represents a table of jump addresses. The vector elements LR0,
9571 etc., are `label_ref' expressions. The mode M specifies how much
9572 space is given to each address; normally M would be `Pmode'.
9574 `(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)'
9575 Represents a table of jump addresses expressed as offsets from
9576 BASE. The vector elements LR0, etc., are `label_ref' expressions
9577 and so is BASE. The mode M specifies how much space is given to
9578 each address-difference. MIN and MAX are set up by branch
9579 shortening and hold a label with a minimum and a maximum address,
9580 respectively. FLAGS indicates the relative position of BASE, MIN
9581 and MAX to the containing insn and of MIN and MAX to BASE. See
9582 rtl.def for details.
9584 `(prefetch:M ADDR RW LOCALITY)'
9585 Represents prefetch of memory at address ADDR. Operand RW is 1 if
9586 the prefetch is for data to be written, 0 otherwise; targets that
9587 do not support write prefetches should treat this as a normal
9588 prefetch. Operand LOCALITY specifies the amount of temporal
9589 locality; 0 if there is none or 1, 2, or 3 for increasing levels
9590 of temporal locality; targets that do not support locality hints
9593 This insn is used to minimize cache-miss latency by moving data
9594 into a cache before it is accessed. It should use only
9595 non-faulting data prefetch instructions.
9598 File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL
9600 11.16 Embedded Side-Effects on Addresses
9601 ========================================
9603 Six special side-effect expression codes appear as memory addresses.
9606 Represents the side effect of decrementing X by a standard amount
9607 and represents also the value that X has after being decremented.
9608 X must be a `reg' or `mem', but most machines allow only a `reg'.
9609 M must be the machine mode for pointers on the machine in use.
9610 The amount X is decremented by is the length in bytes of the
9611 machine mode of the containing memory reference of which this
9612 expression serves as the address. Here is an example of its use:
9614 (mem:DF (pre_dec:SI (reg:SI 39)))
9616 This says to decrement pseudo register 39 by the length of a
9617 `DFmode' value and use the result to address a `DFmode' value.
9620 Similar, but specifies incrementing X instead of decrementing it.
9623 Represents the same side effect as `pre_dec' but a different
9624 value. The value represented here is the value X has before being
9628 Similar, but specifies incrementing X instead of decrementing it.
9630 `(post_modify:M X Y)'
9631 Represents the side effect of setting X to Y and represents X
9632 before X is modified. X must be a `reg' or `mem', but most
9633 machines allow only a `reg'. M must be the machine mode for
9634 pointers on the machine in use.
9636 The expression Y must be one of three forms:
9637 `(plus:M X Z)', `(minus:M X Z)', or `(plus:M X I)',
9638 where Z is an index register and I is a constant.
9640 Here is an example of its use:
9642 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42)
9645 This says to modify pseudo register 42 by adding the contents of
9646 pseudo register 48 to it, after the use of what ever 42 points to.
9648 `(pre_modify:M X EXPR)'
9649 Similar except side effects happen before the use.
9651 These embedded side effect expressions must be used with care.
9652 Instruction patterns may not use them. Until the `flow' pass of the
9653 compiler, they may occur only to represent pushes onto the stack. The
9654 `flow' pass finds cases where registers are incremented or decremented
9655 in one instruction and used as an address shortly before or after;
9656 these cases are then transformed to use pre- or post-increment or
9659 If a register used as the operand of these expressions is used in
9660 another address in an insn, the original value of the register is used.
9661 Uses of the register outside of an address are not permitted within the
9662 same insn as a use in an embedded side effect expression because such
9663 insns behave differently on different machines and hence must be treated
9664 as ambiguous and disallowed.
9666 An instruction that can be represented with an embedded side effect
9667 could also be represented using `parallel' containing an additional
9668 `set' to describe how the address register is altered. This is not
9669 done because machines that allow these operations at all typically
9670 allow them wherever a memory address is called for. Describing them as
9671 additional parallel stores would require doubling the number of entries
9672 in the machine description.
9675 File: gccint.info, Node: Assembler, Next: Insns, Prev: Incdec, Up: RTL
9677 11.17 Assembler Instructions as Expressions
9678 ===========================================
9680 The RTX code `asm_operands' represents a value produced by a
9681 user-specified assembler instruction. It is used to represent an `asm'
9682 statement with arguments. An `asm' statement with a single output
9685 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z));
9687 is represented using a single `asm_operands' RTX which represents the
9688 value that is stored in `outputvar':
9690 (set RTX-FOR-OUTPUTVAR
9691 (asm_operands "foo %1,%2,%0" "a" 0
9692 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z]
9694 (asm_input:M2 "di")]))
9696 Here the operands of the `asm_operands' RTX are the assembler template
9697 string, the output-operand's constraint, the index-number of the output
9698 operand among the output operands specified, a vector of input operand
9699 RTX's, and a vector of input-operand modes and constraints. The mode
9700 M1 is the mode of the sum `x+y'; M2 is that of `*z'.
9702 When an `asm' statement has multiple output values, its insn has
9703 several such `set' RTX's inside of a `parallel'. Each `set' contains a
9704 `asm_operands'; all of these share the same assembler template and
9705 vectors, but each contains the constraint for the respective output
9706 operand. They are also distinguished by the output-operand index
9707 number, which is 0, 1, ... for successive output operands.
9710 File: gccint.info, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL
9715 The RTL representation of the code for a function is a doubly-linked
9716 chain of objects called "insns". Insns are expressions with special
9717 codes that are used for no other purpose. Some insns are actual
9718 instructions; others represent dispatch tables for `switch' statements;
9719 others represent labels to jump to or various sorts of declarative
9722 In addition to its own specific data, each insn must have a unique
9723 id-number that distinguishes it from all other insns in the current
9724 function (after delayed branch scheduling, copies of an insn with the
9725 same id-number may be present in multiple places in a function, but
9726 these copies will always be identical and will only appear inside a
9727 `sequence'), and chain pointers to the preceding and following insns.
9728 These three fields occupy the same position in every insn, independent
9729 of the expression code of the insn. They could be accessed with `XEXP'
9730 and `XINT', but instead three special macros are always used:
9733 Accesses the unique id of insn I.
9736 Accesses the chain pointer to the insn preceding I. If I is the
9737 first insn, this is a null pointer.
9740 Accesses the chain pointer to the insn following I. If I is the
9741 last insn, this is a null pointer.
9743 The first insn in the chain is obtained by calling `get_insns'; the
9744 last insn is the result of calling `get_last_insn'. Within the chain
9745 delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must
9746 always correspond: if INSN is not the first insn,
9748 NEXT_INSN (PREV_INSN (INSN)) == INSN
9750 is always true and if INSN is not the last insn,
9752 PREV_INSN (NEXT_INSN (INSN)) == INSN
9756 After delay slot scheduling, some of the insns in the chain might be
9757 `sequence' expressions, which contain a vector of insns. The value of
9758 `NEXT_INSN' in all but the last of these insns is the next insn in the
9759 vector; the value of `NEXT_INSN' of the last insn in the vector is the
9760 same as the value of `NEXT_INSN' for the `sequence' in which it is
9761 contained. Similar rules apply for `PREV_INSN'.
9763 This means that the above invariants are not necessarily true for insns
9764 inside `sequence' expressions. Specifically, if INSN is the first insn
9765 in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn containing
9766 the `sequence' expression, as is the value of `PREV_INSN (NEXT_INSN
9767 (INSN))' if INSN is the last insn in the `sequence' expression. You
9768 can use these expressions to find the containing `sequence' expression.
9770 Every insn has one of the following six expression codes:
9773 The expression code `insn' is used for instructions that do not
9774 jump and do not do function calls. `sequence' expressions are
9775 always contained in insns with code `insn' even if one of those
9776 insns should jump or do function calls.
9778 Insns with code `insn' have four additional fields beyond the three
9779 mandatory ones listed above. These four are described in a table
9783 The expression code `jump_insn' is used for instructions that may
9784 jump (or, more generally, may contain `label_ref' expressions). If
9785 there is an instruction to return from the current function, it is
9786 recorded as a `jump_insn'.
9788 `jump_insn' insns have the same extra fields as `insn' insns,
9789 accessed in the same way and in addition contain a field
9790 `JUMP_LABEL' which is defined once jump optimization has completed.
9792 For simple conditional and unconditional jumps, this field contains
9793 the `code_label' to which this insn will (possibly conditionally)
9794 branch. In a more complex jump, `JUMP_LABEL' records one of the
9795 labels that the insn refers to; the only way to find the others is
9796 to scan the entire body of the insn. In an `addr_vec',
9797 `JUMP_LABEL' is `NULL_RTX'.
9799 Return insns count as jumps, but since they do not refer to any
9800 labels, their `JUMP_LABEL' is `NULL_RTX'.
9803 The expression code `call_insn' is used for instructions that may
9804 do function calls. It is important to distinguish these
9805 instructions because they imply that certain registers and memory
9806 locations may be altered unpredictably.
9808 `call_insn' insns have the same extra fields as `insn' insns,
9809 accessed in the same way and in addition contain a field
9810 `CALL_INSN_FUNCTION_USAGE', which contains a list (chain of
9811 `expr_list' expressions) containing `use' and `clobber'
9812 expressions that denote hard registers and `MEM's used or
9813 clobbered by the called function.
9815 A `MEM' generally points to a stack slots in which arguments passed
9816 to the libcall by reference (*note TARGET_PASS_BY_REFERENCE:
9817 Register Arguments.) are stored. If the argument is caller-copied
9818 (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot
9819 will be mentioned in `CLOBBER' and `USE' entries; if it's
9820 callee-copied, only a `USE' will appear, and the `MEM' may point
9821 to addresses that are not stack slots. These `MEM's are used only
9822 in libcalls, because, unlike regular function calls, `CONST_CALL's
9823 (which libcalls generally are, *note CONST_CALL_P: Flags.) aren't
9824 assumed to read and write all memory, so flow would consider the
9825 stores dead and remove them. Note that, since a libcall must
9826 never return values in memory (*note RETURN_IN_MEMORY: Aggregate
9827 Return.), there will never be a `CLOBBER' for a memory address
9828 holding a return value.
9830 `CLOBBER'ed registers in this list augment registers specified in
9831 `CALL_USED_REGISTERS' (*note Register Basics::).
9834 A `code_label' insn represents a label that a jump insn can jump
9835 to. It contains two special fields of data in addition to the
9836 three standard ones. `CODE_LABEL_NUMBER' is used to hold the
9837 "label number", a number that identifies this label uniquely among
9838 all the labels in the compilation (not just in the current
9839 function). Ultimately, the label is represented in the assembler
9840 output as an assembler label, usually of the form `LN' where N is
9843 When a `code_label' appears in an RTL expression, it normally
9844 appears within a `label_ref' which represents the address of the
9847 Besides as a `code_label', a label can also be represented as a
9848 `note' of type `NOTE_INSN_DELETED_LABEL'.
9850 The field `LABEL_NUSES' is only defined once the jump optimization
9851 phase is completed. It contains the number of times this label is
9852 referenced in the current function.
9854 The field `LABEL_KIND' differentiates four different types of
9855 labels: `LABEL_NORMAL', `LABEL_STATIC_ENTRY',
9856 `LABEL_GLOBAL_ENTRY', and `LABEL_WEAK_ENTRY'. The only labels
9857 that do not have type `LABEL_NORMAL' are "alternate entry points"
9858 to the current function. These may be static (visible only in the
9859 containing translation unit), global (exposed to all translation
9860 units), or weak (global, but can be overridden by another symbol
9861 with the same name).
9863 Much of the compiler treats all four kinds of label identically.
9864 Some of it needs to know whether or not a label is an alternate
9865 entry point; for this purpose, the macro `LABEL_ALT_ENTRY_P' is
9866 provided. It is equivalent to testing whether `LABEL_KIND (label)
9867 == LABEL_NORMAL'. The only place that cares about the distinction
9868 between static, global, and weak alternate entry points, besides
9869 the front-end code that creates them, is the function
9870 `output_alternate_entry_point', in `final.c'.
9872 To set the kind of a label, use the `SET_LABEL_KIND' macro.
9875 Barriers are placed in the instruction stream when control cannot
9876 flow past them. They are placed after unconditional jump
9877 instructions to indicate that the jumps are unconditional and
9878 after calls to `volatile' functions, which do not return (e.g.,
9879 `exit'). They contain no information beyond the three standard
9883 `note' insns are used to represent additional debugging and
9884 declarative information. They contain two nonstandard fields, an
9885 integer which is accessed with the macro `NOTE_LINE_NUMBER' and a
9886 string accessed with `NOTE_SOURCE_FILE'.
9888 If `NOTE_LINE_NUMBER' is positive, the note represents the
9889 position of a source line and `NOTE_SOURCE_FILE' is the source
9890 file name that the line came from. These notes control generation
9891 of line number data in the assembler output.
9893 Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a
9894 code with one of the following values (and `NOTE_SOURCE_FILE' must
9895 contain a null pointer):
9898 Such a note is completely ignorable. Some passes of the
9899 compiler delete insns by altering them into notes of this
9902 `NOTE_INSN_DELETED_LABEL'
9903 This marks what used to be a `code_label', but was not used
9904 for other purposes than taking its address and was
9905 transformed to mark that no code jumps to it.
9907 `NOTE_INSN_BLOCK_BEG'
9908 `NOTE_INSN_BLOCK_END'
9909 These types of notes indicate the position of the beginning
9910 and end of a level of scoping of variable names. They
9911 control the output of debugging information.
9913 `NOTE_INSN_EH_REGION_BEG'
9914 `NOTE_INSN_EH_REGION_END'
9915 These types of notes indicate the position of the beginning
9916 and end of a level of scoping for exception handling.
9917 `NOTE_BLOCK_NUMBER' identifies which `CODE_LABEL' or `note'
9918 of type `NOTE_INSN_DELETED_LABEL' is associated with the
9921 `NOTE_INSN_LOOP_BEG'
9922 `NOTE_INSN_LOOP_END'
9923 These types of notes indicate the position of the beginning
9924 and end of a `while' or `for' loop. They enable the loop
9925 optimizer to find loops quickly.
9927 `NOTE_INSN_LOOP_CONT'
9928 Appears at the place in a loop that `continue' statements
9931 `NOTE_INSN_LOOP_VTOP'
9932 This note indicates the place in a loop where the exit test
9933 begins for those loops in which the exit test has been
9934 duplicated. This position becomes another virtual start of
9935 the loop when considering loop invariants.
9937 `NOTE_INSN_FUNCTION_BEG'
9938 Appears at the start of the function body, after the function
9941 `NOTE_INSN_FUNCTION_END'
9942 Appears near the end of the function body, just before the
9943 label that `return' statements jump to (on machine where a
9944 single instruction does not suffice for returning). This
9945 note may be deleted by jump optimization.
9948 These codes are printed symbolically when they appear in debugging
9951 The machine mode of an insn is normally `VOIDmode', but some phases
9952 use the mode for various purposes.
9954 The common subexpression elimination pass sets the mode of an insn to
9955 `QImode' when it is the first insn in a block that has already been
9958 The second Haifa scheduling pass, for targets that can multiple issue,
9959 sets the mode of an insn to `TImode' when it is believed that the
9960 instruction begins an issue group. That is, when the instruction
9961 cannot issue simultaneously with the previous. This may be relied on
9962 by later passes, in particular machine-dependent reorg.
9964 Here is a table of the extra fields of `insn', `jump_insn' and
9968 An expression for the side effect performed by this insn. This
9969 must be one of the following codes: `set', `call', `use',
9970 `clobber', `return', `asm_input', `asm_output', `addr_vec',
9971 `addr_diff_vec', `trap_if', `unspec', `unspec_volatile',
9972 `parallel', `cond_exec', or `sequence'. If it is a `parallel',
9973 each element of the `parallel' must be one these codes, except that
9974 `parallel' expressions cannot be nested and `addr_vec' and
9975 `addr_diff_vec' are not permitted inside a `parallel' expression.
9978 An integer that says which pattern in the machine description
9979 matches this insn, or -1 if the matching has not yet been
9982 Such matching is never attempted and this field remains -1 on an
9983 insn whose pattern consists of a single `use', `clobber',
9984 `asm_input', `addr_vec' or `addr_diff_vec' expression.
9986 Matching is also never attempted on insns that result from an `asm'
9987 statement. These contain at least one `asm_operands' expression.
9988 The function `asm_noperands' returns a non-negative value for such
9991 In the debugging output, this field is printed as a number
9992 followed by a symbolic representation that locates the pattern in
9993 the `md' file as some small positive or negative offset from a
9997 A list (chain of `insn_list' expressions) giving information about
9998 dependencies between instructions within a basic block. Neither a
9999 jump nor a label may come between the related insns.
10002 A list (chain of `expr_list' and `insn_list' expressions) giving
10003 miscellaneous information about the insn. It is often information
10004 pertaining to the registers used in this insn.
10006 The `LOG_LINKS' field of an insn is a chain of `insn_list'
10007 expressions. Each of these has two operands: the first is an insn, and
10008 the second is another `insn_list' expression (the next one in the
10009 chain). The last `insn_list' in the chain has a null pointer as second
10010 operand. The significant thing about the chain is which insns appear
10011 in it (as first operands of `insn_list' expressions). Their order is
10014 This list is originally set up by the flow analysis pass; it is a null
10015 pointer until then. Flow only adds links for those data dependencies
10016 which can be used for instruction combination. For each insn, the flow
10017 analysis pass adds a link to insns which store into registers values
10018 that are used for the first time in this insn. The instruction
10019 scheduling pass adds extra links so that every dependence will be
10020 represented. Links represent data dependencies, antidependencies and
10021 output dependencies; the machine mode of the link distinguishes these
10022 three types: antidependencies have mode `REG_DEP_ANTI', output
10023 dependencies have mode `REG_DEP_OUTPUT', and data dependencies have
10026 The `REG_NOTES' field of an insn is a chain similar to the `LOG_LINKS'
10027 field but it includes `expr_list' expressions in addition to
10028 `insn_list' expressions. There are several kinds of register notes,
10029 which are distinguished by the machine mode, which in a register note
10030 is really understood as being an `enum reg_note'. The first operand OP
10031 of the note is data whose meaning depends on the kind of note.
10033 The macro `REG_NOTE_KIND (X)' returns the kind of register note. Its
10034 counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' sets the
10035 register note type of X to be NEWKIND.
10037 Register notes are of three classes: They may say something about an
10038 input to an insn, they may say something about an output of an insn, or
10039 they may create a linkage between two insns. There are also a set of
10040 values that are only used in `LOG_LINKS'.
10042 These register notes annotate inputs to an insn:
10045 The value in OP dies in this insn; that is to say, altering the
10046 value immediately after this insn would not affect the future
10047 behavior of the program.
10049 It does not follow that the register OP has no useful value after
10050 this insn since OP is not necessarily modified by this insn.
10051 Rather, no subsequent instruction uses the contents of OP.
10054 The register OP being set by this insn will not be used in a
10055 subsequent insn. This differs from a `REG_DEAD' note, which
10056 indicates that the value in an input will not be used subsequently.
10057 These two notes are independent; both may be present for the same
10061 The register OP is incremented (or decremented; at this level
10062 there is no distinction) by an embedded side effect inside this
10063 insn. This means it appears in a `post_inc', `pre_inc',
10064 `post_dec' or `pre_dec' expression.
10067 The register OP is known to have a nonnegative value when this
10068 insn is reached. This is used so that decrement and branch until
10069 zero instructions, such as the m68k dbra, can be matched.
10071 The `REG_NONNEG' note is added to insns only if the machine
10072 description has a `decrement_and_branch_until_zero' pattern.
10075 This insn does not cause a conflict between OP and the item being
10076 set by this insn even though it might appear that it does. In
10077 other words, if the destination register and OP could otherwise be
10078 assigned the same register, this insn does not prevent that
10081 Insns with this note are usually part of a block that begins with a
10082 `clobber' insn specifying a multi-word pseudo register (which will
10083 be the output of the block), a group of insns that each set one
10084 word of the value and have the `REG_NO_CONFLICT' note attached,
10085 and a final insn that copies the output to itself with an attached
10086 `REG_EQUAL' note giving the expression being computed. This block
10087 is encapsulated with `REG_LIBCALL' and `REG_RETVAL' notes on the
10088 first and last insns, respectively.
10091 This insn uses OP, a `code_label' or a `note' of type
10092 `NOTE_INSN_DELETED_LABEL', but is not a `jump_insn', or it is a
10093 `jump_insn' that required the label to be held in a register. The
10094 presence of this note allows jump optimization to be aware that OP
10095 is, in fact, being used, and flow optimization to build an
10096 accurate flow graph.
10098 `REG_CROSSING_JUMP'
10099 This insn is an branching instruction (either an unconditional
10100 jump or an indirect jump) which crosses between hot and cold
10101 sections, which could potentially be very far apart in the
10102 executable. The presence of this note indicates to other
10103 optimizations that this this branching instruction should not be
10104 "collapsed" into a simpler branching construct. It is used when
10105 the optimization to partition basic blocks into hot and cold
10106 sections is turned on.
10109 Appears attached to each `CALL_INSN' to `setjmp' or a related
10112 The following notes describe attributes of outputs of an insn:
10116 This note is only valid on an insn that sets only one register and
10117 indicates that that register will be equal to OP at run time; the
10118 scope of this equivalence differs between the two types of notes.
10119 The value which the insn explicitly copies into the register may
10120 look different from OP, but they will be equal at run time. If the
10121 output of the single `set' is a `strict_low_part' expression, the
10122 note refers to the register that is contained in `SUBREG_REG' of
10123 the `subreg' expression.
10125 For `REG_EQUIV', the register is equivalent to OP throughout the
10126 entire function, and could validly be replaced in all its
10127 occurrences by OP. ("Validly" here refers to the data flow of the
10128 program; simple replacement may make some insns invalid.) For
10129 example, when a constant is loaded into a register that is never
10130 assigned any other value, this kind of note is used.
10132 When a parameter is copied into a pseudo-register at entry to a
10133 function, a note of this kind records that the register is
10134 equivalent to the stack slot where the parameter was passed.
10135 Although in this case the register may be set by other insns, it
10136 is still valid to replace the register by the stack slot
10137 throughout the function.
10139 A `REG_EQUIV' note is also used on an instruction which copies a
10140 register parameter into a pseudo-register at entry to a function,
10141 if there is a stack slot where that parameter could be stored.
10142 Although other insns may set the pseudo-register, it is valid for
10143 the compiler to replace the pseudo-register by stack slot
10144 throughout the function, provided the compiler ensures that the
10145 stack slot is properly initialized by making the replacement in
10146 the initial copy instruction as well. This is used on machines
10147 for which the calling convention allocates stack space for
10148 register parameters. See `REG_PARM_STACK_SPACE' in *Note Stack
10151 In the case of `REG_EQUAL', the register that is set by this insn
10152 will be equal to OP at run time at the end of this insn but not
10153 necessarily elsewhere in the function. In this case, OP is
10154 typically an arithmetic expression. For example, when a sequence
10155 of insns such as a library call is used to perform an arithmetic
10156 operation, this kind of note is attached to the insn that produces
10157 or copies the final value.
10159 These two notes are used in different ways by the compiler passes.
10160 `REG_EQUAL' is used by passes prior to register allocation (such as
10161 common subexpression elimination and loop optimization) to tell
10162 them how to think of that value. `REG_EQUIV' notes are used by
10163 register allocation to indicate that there is an available
10164 substitute expression (either a constant or a `mem' expression for
10165 the location of a parameter on the stack) that may be used in
10166 place of a register if insufficient registers are available.
10168 Except for stack homes for parameters, which are indicated by a
10169 `REG_EQUIV' note and are not useful to the early optimization
10170 passes and pseudo registers that are equivalent to a memory
10171 location throughout their entire life, which is not detected until
10172 later in the compilation, all equivalences are initially indicated
10173 by an attached `REG_EQUAL' note. In the early stages of register
10174 allocation, a `REG_EQUAL' note is changed into a `REG_EQUIV' note
10175 if OP is a constant and the insn represents the only set of its
10176 destination register.
10178 Thus, compiler passes prior to register allocation need only check
10179 for `REG_EQUAL' notes and passes subsequent to register allocation
10180 need only check for `REG_EQUIV' notes.
10182 These notes describe linkages between insns. They occur in pairs: one
10183 insn has one of a pair of notes that points to a second insn, which has
10184 the inverse note pointing back to the first insn.
10187 This insn copies the value of a multi-insn sequence (for example, a
10188 library call), and OP is the first insn of the sequence (for a
10189 library call, the first insn that was generated to set up the
10190 arguments for the library call).
10192 Loop optimization uses this note to treat such a sequence as a
10193 single operation for code motion purposes and flow analysis uses
10194 this note to delete such sequences whose results are dead.
10196 A `REG_EQUAL' note will also usually be attached to this insn to
10197 provide the expression being computed by the sequence.
10199 These notes will be deleted after reload, since they are no longer
10200 accurate or useful.
10203 This is the inverse of `REG_RETVAL': it is placed on the first
10204 insn of a multi-insn sequence, and it points to the last one.
10206 These notes are deleted after reload, since they are no longer
10207 useful or accurate.
10211 On machines that use `cc0', the insns which set and use `cc0' set
10212 and use `cc0' are adjacent. However, when branch delay slot
10213 filling is done, this may no longer be true. In this case a
10214 `REG_CC_USER' note will be placed on the insn setting `cc0' to
10215 point to the insn using `cc0' and a `REG_CC_SETTER' note will be
10216 placed on the insn using `cc0' to point to the insn setting `cc0'.
10218 These values are only used in the `LOG_LINKS' field, and indicate the
10219 type of dependency that each link represents. Links which indicate a
10220 data dependence (a read after write dependence) do not use any code,
10221 they simply have mode `VOIDmode', and are printed without any
10225 This indicates an anti dependence (a write after read dependence).
10228 This indicates an output dependence (a write after write
10231 These notes describe information gathered from gcov profile data. They
10232 are stored in the `REG_NOTES' field of an insn as an `expr_list'.
10235 This is used to specify the ratio of branches to non-branches of a
10236 branch insn according to the profile data. The value is stored as
10237 a value between 0 and REG_BR_PROB_BASE; larger values indicate a
10238 higher probability that the branch will be taken.
10241 These notes are found in JUMP insns after delayed branch scheduling
10242 has taken place. They indicate both the direction and the
10243 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_*
10246 `REG_FRAME_RELATED_EXPR'
10247 This is used on an RTX_FRAME_RELATED_P insn wherein the attached
10248 expression is used in place of the actual insn pattern. This is
10249 done in cases where the pattern is either complex or misleading.
10251 For convenience, the machine mode in an `insn_list' or `expr_list' is
10252 printed using these symbolic codes in debugging dumps.
10254 The only difference between the expression codes `insn_list' and
10255 `expr_list' is that the first operand of an `insn_list' is assumed to
10256 be an insn and is printed in debugging dumps as the insn's unique id;
10257 the first operand of an `expr_list' is printed in the ordinary way as
10261 File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL
10263 11.19 RTL Representation of Function-Call Insns
10264 ===============================================
10266 Insns that call subroutines have the RTL expression code `call_insn'.
10267 These insns must satisfy special rules, and their bodies must use a
10268 special RTL expression code, `call'.
10270 A `call' expression has two operands, as follows:
10272 (call (mem:FM ADDR) NBYTES)
10274 Here NBYTES is an operand that represents the number of bytes of
10275 argument data being passed to the subroutine, FM is a machine mode
10276 (which must equal as the definition of the `FUNCTION_MODE' macro in the
10277 machine description) and ADDR represents the address of the subroutine.
10279 For a subroutine that returns no value, the `call' expression as shown
10280 above is the entire body of the insn, except that the insn might also
10281 contain `use' or `clobber' expressions.
10283 For a subroutine that returns a value whose mode is not `BLKmode', the
10284 value is returned in a hard register. If this register's number is R,
10285 then the body of the call insn looks like this:
10288 (call (mem:FM ADDR) NBYTES))
10290 This RTL expression makes it clear (to the optimizer passes) that the
10291 appropriate register receives a useful value in this insn.
10293 When a subroutine returns a `BLKmode' value, it is handled by passing
10294 to the subroutine the address of a place to store the value. So the
10295 call insn itself does not "return" any value, and it has the same RTL
10296 form as a call that returns nothing.
10298 On some machines, the call instruction itself clobbers some register,
10299 for example to contain the return address. `call_insn' insns on these
10300 machines should have a body which is a `parallel' that contains both
10301 the `call' expression and `clobber' expressions that indicate which
10302 registers are destroyed. Similarly, if the call instruction requires
10303 some register other than the stack pointer that is not explicitly
10304 mentioned in its RTL, a `use' subexpression should mention that
10307 Functions that are called are assumed to modify all registers listed in
10308 the configuration macro `CALL_USED_REGISTERS' (*note Register Basics::)
10309 and, with the exception of `const' functions and library calls, to
10310 modify all of memory.
10312 Insns containing just `use' expressions directly precede the
10313 `call_insn' insn to indicate which registers contain inputs to the
10314 function. Similarly, if registers other than those in
10315 `CALL_USED_REGISTERS' are clobbered by the called function, insns
10316 containing a single `clobber' follow immediately after the call to
10317 indicate which registers.
10320 File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL
10322 11.20 Structure Sharing Assumptions
10323 ===================================
10325 The compiler assumes that certain kinds of RTL expressions are unique;
10326 there do not exist two distinct objects representing the same value.
10327 In other cases, it makes an opposite assumption: that no RTL expression
10328 object of a certain kind appears in more than one place in the
10329 containing structure.
10331 These assumptions refer to a single function; except for the RTL
10332 objects that describe global variables and external functions, and a
10333 few standard objects such as small integer constants, no RTL objects
10334 are common to two functions.
10336 * Each pseudo-register has only a single `reg' object to represent
10337 it, and therefore only a single machine mode.
10339 * For any symbolic label, there is only one `symbol_ref' object
10342 * All `const_int' expressions with equal values are shared.
10344 * There is only one `pc' expression.
10346 * There is only one `cc0' expression.
10348 * There is only one `const_double' expression with value 0 for each
10349 floating point mode. Likewise for values 1 and 2.
10351 * There is only one `const_vector' expression with value 0 for each
10352 vector mode, be it an integer or a double constant vector.
10354 * No `label_ref' or `scratch' appears in more than one place in the
10355 RTL structure; in other words, it is safe to do a tree-walk of all
10356 the insns in the function and assume that each time a `label_ref'
10357 or `scratch' is seen it is distinct from all others that are seen.
10359 * Only one `mem' object is normally created for each static variable
10360 or stack slot, so these objects are frequently shared in all the
10361 places they appear. However, separate but equal objects for these
10362 variables are occasionally made.
10364 * When a single `asm' statement has multiple output operands, a
10365 distinct `asm_operands' expression is made for each output operand.
10366 However, these all share the vector which contains the sequence of
10367 input operands. This sharing is used later on to test whether two
10368 `asm_operands' expressions come from the same statement, so all
10369 optimizations must carefully preserve the sharing if they copy the
10372 * No RTL object appears in more than one place in the RTL structure
10373 except as described above. Many passes of the compiler rely on
10374 this by assuming that they can modify RTL objects in place without
10375 unwanted side-effects on other insns.
10377 * During initial RTL generation, shared structure is freely
10378 introduced. After all the RTL for a function has been generated,
10379 all shared structure is copied by `unshare_all_rtl' in
10380 `emit-rtl.c', after which the above rules are guaranteed to be
10383 * During the combiner pass, shared structure within an insn can exist
10384 temporarily. However, the shared structure is copied before the
10385 combiner is finished with the insn. This is done by calling
10386 `copy_rtx_if_shared', which is a subroutine of `unshare_all_rtl'.
10389 File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL
10394 To read an RTL object from a file, call `read_rtx'. It takes one
10395 argument, a stdio stream, and returns a single RTL object. This routine
10396 is defined in `read-rtl.c'. It is not available in the compiler
10397 itself, only the various programs that generate the compiler back end
10398 from the machine description.
10400 People frequently have the idea of using RTL stored as text in a file
10401 as an interface between a language front end and the bulk of GCC. This
10402 idea is not feasible.
10404 GCC was designed to use RTL internally only. Correct RTL for a given
10405 program is very dependent on the particular target machine. And the RTL
10406 does not contain all the information about the program.
10408 The proper way to interface GCC to a new language front end is with
10409 the "tree" data structure, described in the files `tree.h' and
10410 `tree.def'. The documentation for this structure (*note Trees::) is
10414 File: gccint.info, Node: Control Flow, Next: Tree SSA, Prev: RTL, Up: Top
10416 12 Control Flow Graph
10417 *********************
10419 A control flow graph (CFG) is a data structure built on top of the
10420 intermediate code representation (the RTL or `tree' instruction stream)
10421 abstracting the control flow behavior of a function that is being
10422 compiled. The CFG is a directed graph where the vertices represent
10423 basic blocks and edges represent possible transfer of control flow from
10424 one basic block to another. The data structures used to represent the
10425 control flow graph are defined in `basic-block.h'.
10429 * Basic Blocks:: The definition and representation of basic blocks.
10430 * Edges:: Types of edges and their representation.
10431 * Profile information:: Representation of frequencies and probabilities.
10432 * Maintaining the CFG:: Keeping the control flow graph and up to date.
10433 * Liveness information:: Using and maintaining liveness information.
10436 File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow
10441 A basic block is a straight-line sequence of code with only one entry
10442 point and only one exit. In GCC, basic blocks are represented using
10443 the `basic_block' data type.
10445 Two pointer members of the `basic_block' structure are the pointers
10446 `next_bb' and `prev_bb'. These are used to keep doubly linked chain of
10447 basic blocks in the same order as the underlying instruction stream.
10448 The chain of basic blocks is updated transparently by the provided API
10449 for manipulating the CFG. The macro `FOR_EACH_BB' can be used to visit
10450 all the basic blocks in lexicographical order. Dominator traversals
10451 are also possible using `walk_dominator_tree'. Given two basic blocks
10452 A and B, block A dominates block B if A is _always_ executed before B.
10454 The `BASIC_BLOCK' array contains all basic blocks in an unspecified
10455 order. Each `basic_block' structure has a field that holds a unique
10456 integer identifier `index' that is the index of the block in the
10457 `BASIC_BLOCK' array. The total number of basic blocks in the function
10458 is `n_basic_blocks'. Both the basic block indices and the total number
10459 of basic blocks may vary during the compilation process, as passes
10460 reorder, create, duplicate, and destroy basic blocks. The index for
10461 any block should never be greater than `last_basic_block'.
10463 Special basic blocks represent possible entry and exit points of a
10464 function. These blocks are called `ENTRY_BLOCK_PTR' and
10465 `EXIT_BLOCK_PTR'. These blocks do not contain any code, and are not
10466 elements of the `BASIC_BLOCK' array. Therefore they have been assigned
10467 unique, negative index numbers.
10469 Each `basic_block' also contains pointers to the first instruction
10470 (the "head") and the last instruction (the "tail") or "end" of the
10471 instruction stream contained in a basic block. In fact, since the
10472 `basic_block' data type is used to represent blocks in both major
10473 intermediate representations of GCC (`tree' and RTL), there are
10474 pointers to the head and end of a basic block for both representations.
10476 For RTL, these pointers are `rtx head, end'. In the RTL function
10477 representation, the head pointer always points either to a
10478 `NOTE_INSN_BASIC_BLOCK' or to a `CODE_LABEL', if present. In the RTL
10479 representation of a function, the instruction stream contains not only
10480 the "real" instructions, but also "notes". Any function that moves or
10481 duplicates the basic blocks needs to take care of updating of these
10482 notes. Many of these notes expect that the instruction stream consists
10483 of linear regions, making such updates difficult. The
10484 `NOTE_INSN_BASIC_BLOCK' note is the only kind of note that may appear
10485 in the instruction stream contained in a basic block. The instruction
10486 stream of a basic block always follows a `NOTE_INSN_BASIC_BLOCK', but
10487 zero or more `CODE_LABEL' nodes can precede the block note. A basic
10488 block ends by control flow instruction or last instruction before
10489 following `CODE_LABEL' or `NOTE_INSN_BASIC_BLOCK'. A `CODE_LABEL'
10490 cannot appear in the instruction stream of a basic block.
10492 In addition to notes, the jump table vectors are also represented as
10493 "pseudo-instructions" inside the insn stream. These vectors never
10494 appear in the basic block and should always be placed just after the
10495 table jump instructions referencing them. After removing the
10496 table-jump it is often difficult to eliminate the code computing the
10497 address and referencing the vector, so cleaning up these vectors is
10498 postponed until after liveness analysis. Thus the jump table vectors
10499 may appear in the insn stream unreferenced and without any purpose.
10500 Before any edge is made "fall-thru", the existence of such construct in
10501 the way needs to be checked by calling `can_fallthru' function.
10503 For the `tree' representation, the head and end of the basic block are
10504 being pointed to by the `stmt_list' field, but this special `tree'
10505 should never be referenced directly. Instead, at the tree level
10506 abstract containers and iterators are used to access statements and
10507 expressions in basic blocks. These iterators are called "block
10508 statement iterators" (BSIs). Grep for `^bsi' in the various `tree-*'
10509 files. The following snippet will pretty-print all the statements of
10510 the program in the GIMPLE representation.
10514 block_stmt_iterator si;
10516 for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (&si))
10518 tree stmt = bsi_stmt (si);
10519 print_generic_stmt (stderr, stmt, 0);
10524 File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow
10529 Edges represent possible control flow transfers from the end of some
10530 basic block A to the head of another basic block B. We say that A is a
10531 predecessor of B, and B is a successor of A. Edges are represented in
10532 GCC with the `edge' data type. Each `edge' acts as a link between two
10533 basic blocks: the `src' member of an edge points to the predecessor
10534 basic block of the `dest' basic block. The members `preds' and `succs'
10535 of the `basic_block' data type point to type-safe vectors of edges to
10536 the predecessors and successors of the block.
10538 When walking the edges in an edge vector, "edge iterators" should be
10539 used. Edge iterators are constructed using the `edge_iterator' data
10540 structure and several methods are available to operate on them:
10543 This function initializes an `edge_iterator' that points to the
10544 first edge in a vector of edges.
10547 This function initializes an `edge_iterator' that points to the
10548 last edge in a vector of edges.
10551 This predicate is `true' if an `edge_iterator' represents the last
10552 edge in an edge vector.
10554 `ei_one_before_end_p'
10555 This predicate is `true' if an `edge_iterator' represents the
10556 second last edge in an edge vector.
10559 This function takes a pointer to an `edge_iterator' and makes it
10560 point to the next edge in the sequence.
10563 This function takes a pointer to an `edge_iterator' and makes it
10564 point to the previous edge in the sequence.
10567 This function returns the `edge' currently pointed to by an
10571 This function returns the `edge' currently pointed to by an
10572 `edge_iterator', but returns `NULL' if the iterator is pointing at
10573 the end of the sequence. This function has been provided for
10574 existing code makes the assumption that a `NULL' edge indicates
10575 the end of the sequence.
10578 The convenience macro `FOR_EACH_EDGE' can be used to visit all of the
10579 edges in a sequence of predecessor or successor edges. It must not be
10580 used when an element might be removed during the traversal, otherwise
10581 elements will be missed. Here is an example of how to use the macro:
10586 FOR_EACH_EDGE (e, ei, bb->succs)
10588 if (e->flags & EDGE_FALLTHRU)
10592 There are various reasons why control flow may transfer from one block
10593 to another. One possibility is that some instruction, for example a
10594 `CODE_LABEL', in a linearized instruction stream just always starts a
10595 new basic block. In this case a "fall-thru" edge links the basic block
10596 to the first following basic block. But there are several other
10597 reasons why edges may be created. The `flags' field of the `edge' data
10598 type is used to store information about the type of edge we are dealing
10599 with. Each edge is of one of the following types:
10602 No type flags are set for edges corresponding to jump instructions.
10603 These edges are used for unconditional or conditional jumps and in
10604 RTL also for table jumps. They are the easiest to manipulate as
10605 they may be freely redirected when the flow graph is not in SSA
10609 Fall-thru edges are present in case where the basic block may
10610 continue execution to the following one without branching. These
10611 edges have the `EDGE_FALLTHRU' flag set. Unlike other types of
10612 edges, these edges must come into the basic block immediately
10613 following in the instruction stream. The function
10614 `force_nonfallthru' is available to insert an unconditional jump
10615 in the case that redirection is needed. Note that this may
10616 require creation of a new basic block.
10618 _exception handling_
10619 Exception handling edges represent possible control transfers from
10620 a trapping instruction to an exception handler. The definition of
10621 "trapping" varies. In C++, only function calls can throw, but for
10622 Java, exceptions like division by zero or segmentation fault are
10623 defined and thus each instruction possibly throwing this kind of
10624 exception needs to be handled as control flow instruction.
10625 Exception edges have the `EDGE_ABNORMAL' and `EDGE_EH' flags set.
10627 When updating the instruction stream it is easy to change possibly
10628 trapping instruction to non-trapping, by simply removing the
10629 exception edge. The opposite conversion is difficult, but should
10630 not happen anyway. The edges can be eliminated via
10631 `purge_dead_edges' call.
10633 In the RTL representation, the destination of an exception edge is
10634 specified by `REG_EH_REGION' note attached to the insn. In case
10635 of a trapping call the `EDGE_ABNORMAL_CALL' flag is set too. In
10636 the `tree' representation, this extra flag is not set.
10638 In the RTL representation, the predicate `may_trap_p' may be used
10639 to check whether instruction still may trap or not. For the tree
10640 representation, the `tree_could_trap_p' predicate is available,
10641 but this predicate only checks for possible memory traps, as in
10642 dereferencing an invalid pointer location.
10645 Sibling calls or tail calls terminate the function in a
10646 non-standard way and thus an edge to the exit must be present.
10647 `EDGE_SIBCALL' and `EDGE_ABNORMAL' are set in such case. These
10648 edges only exist in the RTL representation.
10651 Computed jumps contain edges to all labels in the function
10652 referenced from the code. All those edges have `EDGE_ABNORMAL'
10653 flag set. The edges used to represent computed jumps often cause
10654 compile time performance problems, since functions consisting of
10655 many taken labels and many computed jumps may have _very_ dense
10656 flow graphs, so these edges need to be handled with special care.
10657 During the earlier stages of the compilation process, GCC tries to
10658 avoid such dense flow graphs by factoring computed jumps. For
10659 example, given the following series of jumps,
10670 factoring the computed jumps results in the following code sequence
10671 which has a much simpler flow graph:
10685 However, the classic problem with this transformation is that it
10686 has a runtime cost in there resulting code: An extra jump.
10687 Therefore, the computed jumps are un-factored in the later passes
10688 of the compiler. Be aware of that when you work on passes in that
10689 area. There have been numerous examples already where the compile
10690 time for code with unfactored computed jumps caused some serious
10693 _nonlocal goto handlers_
10694 GCC allows nested functions to return into caller using a `goto'
10695 to a label passed to as an argument to the callee. The labels
10696 passed to nested functions contain special code to cleanup after
10697 function call. Such sections of code are referred to as "nonlocal
10698 goto receivers". If a function contains such nonlocal goto
10699 receivers, an edge from the call to the label is created with the
10700 `EDGE_ABNORMAL' and `EDGE_ABNORMAL_CALL' flags set.
10702 _function entry points_
10703 By definition, execution of function starts at basic block 0, so
10704 there is always an edge from the `ENTRY_BLOCK_PTR' to basic block
10705 0. There is no `tree' representation for alternate entry points at
10706 this moment. In RTL, alternate entry points are specified by
10707 `CODE_LABEL' with `LABEL_ALTERNATE_NAME' defined. This feature is
10708 currently used for multiple entry point prologues and is limited
10709 to post-reload passes only. This can be used by back-ends to emit
10710 alternate prologues for functions called from different contexts.
10711 In future full support for multiple entry functions defined by
10712 Fortran 90 needs to be implemented.
10715 In the pre-reload representation a function terminates after the
10716 last instruction in the insn chain and no explicit return
10717 instructions are used. This corresponds to the fall-thru edge
10718 into exit block. After reload, optimal RTL epilogues are used
10719 that use explicit (conditional) return instructions that are
10720 represented by edges with no flags set.
10724 File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow
10726 12.3 Profile information
10727 ========================
10729 In many cases a compiler must make a choice whether to trade speed in
10730 one part of code for speed in another, or to trade code size for code
10731 speed. In such cases it is useful to know information about how often
10732 some given block will be executed. That is the purpose for maintaining
10733 profile within the flow graph. GCC can handle profile information
10734 obtained through "profile feedback", but it can also estimate branch
10735 probabilities based on statics and heuristics.
10737 The feedback based profile is produced by compiling the program with
10738 instrumentation, executing it on a train run and reading the numbers of
10739 executions of basic blocks and edges back to the compiler while
10740 re-compiling the program to produce the final executable. This method
10741 provides very accurate information about where a program spends most of
10742 its time on the train run. Whether it matches the average run of
10743 course depends on the choice of train data set, but several studies
10744 have shown that the behavior of a program usually changes just
10745 marginally over different data sets.
10747 When profile feedback is not available, the compiler may be asked to
10748 attempt to predict the behavior of each branch in the program using a
10749 set of heuristics (see `predict.def' for details) and compute estimated
10750 frequencies of each basic block by propagating the probabilities over
10753 Each `basic_block' contains two integer fields to represent profile
10754 information: `frequency' and `count'. The `frequency' is an estimation
10755 how often is basic block executed within a function. It is represented
10756 as an integer scaled in the range from 0 to `BB_FREQ_BASE'. The most
10757 frequently executed basic block in function is initially set to
10758 `BB_FREQ_BASE' and the rest of frequencies are scaled accordingly.
10759 During optimization, the frequency of the most frequent basic block can
10760 both decrease (for instance by loop unrolling) or grow (for instance by
10761 cross-jumping optimization), so scaling sometimes has to be performed
10764 The `count' contains hard-counted numbers of execution measured during
10765 training runs and is nonzero only when profile feedback is available.
10766 This value is represented as the host's widest integer (typically a 64
10767 bit integer) of the special type `gcov_type'.
10769 Most optimization passes can use only the frequency information of a
10770 basic block, but a few passes may want to know hard execution counts.
10771 The frequencies should always match the counts after scaling, however
10772 during updating of the profile information numerical error may
10773 accumulate into quite large errors.
10775 Each edge also contains a branch probability field: an integer in the
10776 range from 0 to `REG_BR_PROB_BASE'. It represents probability of
10777 passing control from the end of the `src' basic block to the `dest'
10778 basic block, i.e. the probability that control will flow along this
10779 edge. The `EDGE_FREQUENCY' macro is available to compute how
10780 frequently a given edge is taken. There is a `count' field for each
10781 edge as well, representing same information as for a basic block.
10783 The basic block frequencies are not represented in the instruction
10784 stream, but in the RTL representation the edge frequencies are
10785 represented for conditional jumps (via the `REG_BR_PROB' macro) since
10786 they are used when instructions are output to the assembly file and the
10787 flow graph is no longer maintained.
10789 The probability that control flow arrives via a given edge to its
10790 destination basic block is called "reverse probability" and is not
10791 directly represented, but it may be easily computed from frequencies of
10794 Updating profile information is a delicate task that can unfortunately
10795 not be easily integrated with the CFG manipulation API. Many of the
10796 functions and hooks to modify the CFG, such as
10797 `redirect_edge_and_branch', do not have enough information to easily
10798 update the profile, so updating it is in the majority of cases left up
10799 to the caller. It is difficult to uncover bugs in the profile updating
10800 code, because they manifest themselves only by producing worse code,
10801 and checking profile consistency is not possible because of numeric
10802 error accumulation. Hence special attention needs to be given to this
10803 issue in each pass that modifies the CFG.
10805 It is important to point out that `REG_BR_PROB_BASE' and
10806 `BB_FREQ_BASE' are both set low enough to be possible to compute second
10807 power of any frequency or probability in the flow graph, it is not
10808 possible to even square the `count' field, as modern CPUs are fast
10809 enough to execute $2^32$ operations quickly.
10812 File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow
10814 12.4 Maintaining the CFG
10815 ========================
10817 An important task of each compiler pass is to keep both the control
10818 flow graph and all profile information up-to-date. Reconstruction of
10819 the control flow graph after each pass is not an option, since it may be
10820 very expensive and lost profile information cannot be reconstructed at
10823 GCC has two major intermediate representations, and both use the
10824 `basic_block' and `edge' data types to represent control flow. Both
10825 representations share as much of the CFG maintenance code as possible.
10826 For each representation, a set of "hooks" is defined so that each
10827 representation can provide its own implementation of CFG manipulation
10828 routines when necessary. These hooks are defined in `cfghooks.h'.
10829 There are hooks for almost all common CFG manipulations, including
10830 block splitting and merging, edge redirection and creating and deleting
10831 basic blocks. These hooks should provide everything you need to
10832 maintain and manipulate the CFG in both the RTL and `tree'
10835 At the moment, the basic block boundaries are maintained transparently
10836 when modifying instructions, so there rarely is a need to move them
10837 manually (such as in case someone wants to output instruction outside
10838 basic block explicitly). Often the CFG may be better viewed as
10839 integral part of instruction chain, than structure built on the top of
10840 it. However, in principle the control flow graph for the `tree'
10841 representation is _not_ an integral part of the representation, in that
10842 a function tree may be expanded without first building a flow graph
10843 for the `tree' representation at all. This happens when compiling
10844 without any `tree' optimization enabled. When the `tree' optimizations
10845 are enabled and the instruction stream is rewritten in SSA form, the
10846 CFG is very tightly coupled with the instruction stream. In
10847 particular, statement insertion and removal has to be done with care.
10848 In fact, the whole `tree' representation can not be easily used or
10849 maintained without proper maintenance of the CFG simultaneously.
10851 In the RTL representation, each instruction has a `BLOCK_FOR_INSN'
10852 value that represents pointer to the basic block that contains the
10853 instruction. In the `tree' representation, the function `bb_for_stmt'
10854 returns a pointer to the basic block containing the queried statement.
10856 When changes need to be applied to a function in its `tree'
10857 representation, "block statement iterators" should be used. These
10858 iterators provide an integrated abstraction of the flow graph and the
10859 instruction stream. Block statement iterators iterators are
10860 constructed using the `block_stmt_iterator' data structure and several
10861 modifier are available, including the following:
10864 This function initializes a `block_stmt_iterator' that points to
10865 the first non-empty statement in a basic block.
10868 This function initializes a `block_stmt_iterator' that points to
10869 the last statement in a basic block.
10872 This predicate is `true' if a `block_stmt_iterator' represents the
10873 end of a basic block.
10876 This function takes a `block_stmt_iterator' and makes it point to
10880 This function takes a `block_stmt_iterator' and makes it point to
10884 This function inserts a statement after the `block_stmt_iterator'
10885 passed in. The final parameter determines whether the statement
10886 iterator is updated to point to the newly inserted statement, or
10887 left pointing to the original statement.
10889 `bsi_insert_before'
10890 This function inserts a statement before the `block_stmt_iterator'
10891 passed in. The final parameter determines whether the statement
10892 iterator is updated to point to the newly inserted statement, or
10893 left pointing to the original statement.
10896 This function removes the `block_stmt_iterator' passed in and
10897 rechains the remaining statements in a basic block, if any.
10899 In the RTL representation, the macros `BB_HEAD' and `BB_END' may be
10900 used to get the head and end `rtx' of a basic block. No abstract
10901 iterators are defined for traversing the insn chain, but you can just
10902 use `NEXT_INSN' and `PREV_INSN' instead. See *Note Insns::.
10904 Usually a code manipulating pass simplifies the instruction stream and
10905 the flow of control, possibly eliminating some edges. This may for
10906 example happen when a conditional jump is replaced with an
10907 unconditional jump, but also when simplifying possibly trapping
10908 instruction to non-trapping while compiling Java. Updating of edges is
10909 not transparent and each optimization pass is required to do so
10910 manually. However only few cases occur in practice. The pass may call
10911 `purge_dead_edges' on a given basic block to remove superfluous edges,
10914 Another common scenario is redirection of branch instructions, but
10915 this is best modeled as redirection of edges in the control flow graph
10916 and thus use of `redirect_edge_and_branch' is preferred over more low
10917 level functions, such as `redirect_jump' that operate on RTL chain
10918 only. The CFG hooks defined in `cfghooks.h' should provide the
10919 complete API required for manipulating and maintaining the CFG.
10921 It is also possible that a pass has to insert control flow instruction
10922 into the middle of a basic block, thus creating an entry point in the
10923 middle of the basic block, which is impossible by definition: The block
10924 must be split to make sure it only has one entry point, i.e. the head
10925 of the basic block. The CFG hook `split_block' may be used when an
10926 instruction in the middle of a basic block has to become the target of
10927 a jump or branch instruction.
10929 For a global optimizer, a common operation is to split edges in the
10930 flow graph and insert instructions on them. In the RTL representation,
10931 this can be easily done using the `insert_insn_on_edge' function that
10932 emits an instruction "on the edge", caching it for a later
10933 `commit_edge_insertions' call that will take care of moving the
10934 inserted instructions off the edge into the instruction stream
10935 contained in a basic block. This includes the creation of new basic
10936 blocks where needed. In the `tree' representation, the equivalent
10937 functions are `bsi_insert_on_edge' which inserts a block statement
10938 iterator on an edge, and `bsi_commit_edge_inserts' which flushes the
10939 instruction to actual instruction stream.
10941 While debugging the optimization pass, an `verify_flow_info' function
10942 may be useful to find bugs in the control flow graph updating code.
10944 Note that at present, the representation of control flow in the `tree'
10945 representation is discarded before expanding to RTL. Long term the CFG
10946 should be maintained and "expanded" to the RTL representation along
10947 with the function `tree' itself.
10950 File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow
10952 12.5 Liveness information
10953 =========================
10955 Liveness information is useful to determine whether some register is
10956 "live" at given point of program, i.e. that it contains a value that
10957 may be used at a later point in the program. This information is used,
10958 for instance, during register allocation, as the pseudo registers only
10959 need to be assigned to a unique hard register or to a stack slot if
10960 they are live. The hard registers and stack slots may be freely reused
10961 for other values when a register is dead.
10963 The liveness information is stored partly in the RTL instruction
10964 stream and partly in the flow graph. Local information is stored in
10965 the instruction stream: Each instruction may contain `REG_DEAD' notes
10966 representing that the value of a given register is no longer needed, or
10967 `REG_UNUSED' notes representing that the value computed by the
10968 instruction is never used. The second is useful for instructions
10969 computing multiple values at once.
10971 Global liveness information is stored in the control flow graph. Each
10972 basic block contains two bitmaps, `global_live_at_start' and
10973 `global_live_at_end' representing liveness of each register at the
10974 entry and exit of the basic block. The file `flow.c' contains
10975 functions to compute liveness of each register at any given place in
10976 the instruction stream using this information.
10978 Liveness is expensive to compute and thus it is desirable to keep it
10979 up to date during code modifying passes. This can be easily
10980 accomplished using the `flags' field of a basic block. Functions
10981 modifying the instruction stream automatically set the `BB_DIRTY' flag
10982 of a modifies basic block, so the pass may simply use`clear_bb_flags'
10983 before doing any modifications and then ask the data flow module to
10984 have liveness updated via the `update_life_info_in_dirty_blocks'
10987 This scheme works reliably as long as no control flow graph
10988 transformations are done. The task of updating liveness after control
10989 flow graph changes is more difficult as normal iterative data flow
10990 analysis may produce invalid results or get into an infinite cycle when
10991 the initial solution is not below the desired one. Only simple
10992 transformations, like splitting basic blocks or inserting on edges, are
10993 safe, as functions to implement them already know how to update
10994 liveness information locally.
10997 File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Tree SSA, Up: Top
10999 13 Machine Descriptions
11000 ***********************
11002 A machine description has two parts: a file of instruction patterns
11003 (`.md' file) and a C header file of macro definitions.
11005 The `.md' file for a target machine contains a pattern for each
11006 instruction that the target machine supports (or at least each
11007 instruction that is worth telling the compiler about). It may also
11008 contain comments. A semicolon causes the rest of the line to be a
11009 comment, unless the semicolon is inside a quoted string.
11011 See the next chapter for information on the C header file.
11015 * Overview:: How the machine description is used.
11016 * Patterns:: How to write instruction patterns.
11017 * Example:: An explained example of a `define_insn' pattern.
11018 * RTL Template:: The RTL template defines what insns match a pattern.
11019 * Output Template:: The output template says how to make assembler code
11021 * Output Statement:: For more generality, write C code to output
11022 the assembler code.
11023 * Predicates:: Controlling what kinds of operands can be used
11025 * Constraints:: Fine-tuning operand selection.
11026 * Standard Names:: Names mark patterns to use for code generation.
11027 * Pattern Ordering:: When the order of patterns makes a difference.
11028 * Dependent Patterns:: Having one pattern may make you need another.
11029 * Jump Patterns:: Special considerations for patterns for jump insns.
11030 * Looping Patterns:: How to define patterns for special looping insns.
11031 * Insn Canonicalizations::Canonicalization of Instructions
11032 * Expander Definitions::Generating a sequence of several RTL insns
11033 for a standard operation.
11034 * Insn Splitting:: Splitting Instructions into Multiple Instructions.
11035 * Including Patterns:: Including Patterns in Machine Descriptions.
11036 * Peephole Definitions::Defining machine-specific peephole optimizations.
11037 * Insn Attributes:: Specifying the value of attributes for generated insns.
11038 * Conditional Execution::Generating `define_insn' patterns for
11040 * Constant Definitions::Defining symbolic constants that can be used in the
11042 * Macros:: Using macros to generate patterns from a template.
11045 File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc
11047 13.1 Overview of How the Machine Description is Used
11048 ====================================================
11050 There are three main conversions that happen in the compiler:
11052 1. The front end reads the source code and builds a parse tree.
11054 2. The parse tree is used to generate an RTL insn list based on named
11055 instruction patterns.
11057 3. The insn list is matched against the RTL templates to produce
11061 For the generate pass, only the names of the insns matter, from either
11062 a named `define_insn' or a `define_expand'. The compiler will choose
11063 the pattern with the right name and apply the operands according to the
11064 documentation later in this chapter, without regard for the RTL
11065 template or operand constraints. Note that the names the compiler looks
11066 for are hard-coded in the compiler--it will ignore unnamed patterns and
11067 patterns with names it doesn't know about, but if you don't provide a
11068 named pattern it needs, it will abort.
11070 If a `define_insn' is used, the template given is inserted into the
11071 insn list. If a `define_expand' is used, one of three things happens,
11072 based on the condition logic. The condition logic may manually create
11073 new insns for the insn list, say via `emit_insn()', and invoke `DONE'.
11074 For certain named patterns, it may invoke `FAIL' to tell the compiler
11075 to use an alternate way of performing that task. If it invokes neither
11076 `DONE' nor `FAIL', the template given in the pattern is inserted, as if
11077 the `define_expand' were a `define_insn'.
11079 Once the insn list is generated, various optimization passes convert,
11080 replace, and rearrange the insns in the insn list. This is where the
11081 `define_split' and `define_peephole' patterns get used, for example.
11083 Finally, the insn list's RTL is matched up with the RTL templates in
11084 the `define_insn' patterns, and those patterns are used to emit the
11085 final assembly code. For this purpose, each named `define_insn' acts
11086 like it's unnamed, since the names are ignored.
11089 File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc
11091 13.2 Everything about Instruction Patterns
11092 ==========================================
11094 Each instruction pattern contains an incomplete RTL expression, with
11095 pieces to be filled in later, operand constraints that restrict how the
11096 pieces can be filled in, and an output pattern or C code to generate
11097 the assembler output, all wrapped up in a `define_insn' expression.
11099 A `define_insn' is an RTL expression containing four or five operands:
11101 1. An optional name. The presence of a name indicate that this
11102 instruction pattern can perform a certain standard job for the
11103 RTL-generation pass of the compiler. This pass knows certain
11104 names and will use the instruction patterns with those names, if
11105 the names are defined in the machine description.
11107 The absence of a name is indicated by writing an empty string
11108 where the name should go. Nameless instruction patterns are never
11109 used for generating RTL code, but they may permit several simpler
11110 insns to be combined later on.
11112 Names that are not thus known and used in RTL-generation have no
11113 effect; they are equivalent to no name at all.
11115 For the purpose of debugging the compiler, you may also specify a
11116 name beginning with the `*' character. Such a name is used only
11117 for identifying the instruction in RTL dumps; it is entirely
11118 equivalent to having a nameless pattern for all other purposes.
11120 2. The "RTL template" (*note RTL Template::) is a vector of incomplete
11121 RTL expressions which show what the instruction should look like.
11122 It is incomplete because it may contain `match_operand',
11123 `match_operator', and `match_dup' expressions that stand for
11124 operands of the instruction.
11126 If the vector has only one element, that element is the template
11127 for the instruction pattern. If the vector has multiple elements,
11128 then the instruction pattern is a `parallel' expression containing
11129 the elements described.
11131 3. A condition. This is a string which contains a C expression that
11132 is the final test to decide whether an insn body matches this
11135 For a named pattern, the condition (if present) may not depend on
11136 the data in the insn being matched, but only the
11137 target-machine-type flags. The compiler needs to test these
11138 conditions during initialization in order to learn exactly which
11139 named instructions are available in a particular run.
11141 For nameless patterns, the condition is applied only when matching
11142 an individual insn, and only after the insn has matched the
11143 pattern's recognition template. The insn's operands may be found
11144 in the vector `operands'. For an insn where the condition has
11145 once matched, it can't be used to control register allocation, for
11146 example by excluding certain hard registers or hard register
11149 4. The "output template": a string that says how to output matching
11150 insns as assembler code. `%' in this string specifies where to
11151 substitute the value of an operand. *Note Output Template::.
11153 When simple substitution isn't general enough, you can specify a
11154 piece of C code to compute the output. *Note Output Statement::.
11156 5. Optionally, a vector containing the values of attributes for insns
11157 matching this pattern. *Note Insn Attributes::.
11160 File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc
11162 13.3 Example of `define_insn'
11163 =============================
11165 Here is an actual example of an instruction pattern, for the
11168 (define_insn "tstsi"
11170 (match_operand:SI 0 "general_operand" "rm"))]
11174 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
11175 return \"tstl %0\";
11176 return \"cmpl #0,%0\";
11179 This can also be written using braced strings:
11181 (define_insn "tstsi"
11183 (match_operand:SI 0 "general_operand" "rm"))]
11186 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
11188 return "cmpl #0,%0";
11191 This is an instruction that sets the condition codes based on the
11192 value of a general operand. It has no condition, so any insn whose RTL
11193 description has the form shown may be handled according to this
11194 pattern. The name `tstsi' means "test a `SImode' value" and tells the
11195 RTL generation pass that, when it is necessary to test such a value, an
11196 insn to do so can be constructed using this pattern.
11198 The output control string is a piece of C code which chooses which
11199 output template to return based on the kind of operand and the specific
11200 type of CPU for which code is being generated.
11202 `"rm"' is an operand constraint. Its meaning is explained below.
11205 File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc
11210 The RTL template is used to define which insns match the particular
11211 pattern and how to find their operands. For named patterns, the RTL
11212 template also says how to construct an insn from specified operands.
11214 Construction involves substituting specified operands into a copy of
11215 the template. Matching involves determining the values that serve as
11216 the operands in the insn being matched. Both of these activities are
11217 controlled by special expression types that direct matching and
11218 substitution of the operands.
11220 `(match_operand:M N PREDICATE CONSTRAINT)'
11221 This expression is a placeholder for operand number N of the insn.
11222 When constructing an insn, operand number N will be substituted
11223 at this point. When matching an insn, whatever appears at this
11224 position in the insn will be taken as operand number N; but it
11225 must satisfy PREDICATE or this instruction pattern will not match
11228 Operand numbers must be chosen consecutively counting from zero in
11229 each instruction pattern. There may be only one `match_operand'
11230 expression in the pattern for each operand number. Usually
11231 operands are numbered in the order of appearance in `match_operand'
11232 expressions. In the case of a `define_expand', any operand numbers
11233 used only in `match_dup' expressions have higher values than all
11234 other operand numbers.
11236 PREDICATE is a string that is the name of a function that accepts
11237 two arguments, an expression and a machine mode. *Note
11238 Predicates::. During matching, the function will be called with
11239 the putative operand as the expression and M as the mode argument
11240 (if M is not specified, `VOIDmode' will be used, which normally
11241 causes PREDICATE to accept any mode). If it returns zero, this
11242 instruction pattern fails to match. PREDICATE may be an empty
11243 string; then it means no test is to be done on the operand, so
11244 anything which occurs in this position is valid.
11246 Most of the time, PREDICATE will reject modes other than M--but
11247 not always. For example, the predicate `address_operand' uses M
11248 as the mode of memory ref that the address should be valid for.
11249 Many predicates accept `const_int' nodes even though their mode is
11252 CONSTRAINT controls reloading and the choice of the best register
11253 class to use for a value, as explained later (*note Constraints::).
11254 If the constraint would be an empty string, it can be omitted.
11256 People are often unclear on the difference between the constraint
11257 and the predicate. The predicate helps decide whether a given
11258 insn matches the pattern. The constraint plays no role in this
11259 decision; instead, it controls various decisions in the case of an
11260 insn which does match.
11262 `(match_scratch:M N CONSTRAINT)'
11263 This expression is also a placeholder for operand number N and
11264 indicates that operand must be a `scratch' or `reg' expression.
11266 When matching patterns, this is equivalent to
11268 (match_operand:M N "scratch_operand" PRED)
11270 but, when generating RTL, it produces a (`scratch':M) expression.
11272 If the last few expressions in a `parallel' are `clobber'
11273 expressions whose operands are either a hard register or
11274 `match_scratch', the combiner can add or delete them when
11275 necessary. *Note Side Effects::.
11278 This expression is also a placeholder for operand number N. It is
11279 used when the operand needs to appear more than once in the insn.
11281 In construction, `match_dup' acts just like `match_operand': the
11282 operand is substituted into the insn being constructed. But in
11283 matching, `match_dup' behaves differently. It assumes that operand
11284 number N has already been determined by a `match_operand'
11285 appearing earlier in the recognition template, and it matches only
11286 an identical-looking expression.
11288 Note that `match_dup' should not be used to tell the compiler that
11289 a particular register is being used for two operands (example:
11290 `add' that adds one register to another; the second register is
11291 both an input operand and the output operand). Use a matching
11292 constraint (*note Simple Constraints::) for those. `match_dup' is
11293 for the cases where one operand is used in two places in the
11294 template, such as an instruction that computes both a quotient and
11295 a remainder, where the opcode takes two input operands but the RTL
11296 template has to refer to each of those twice; once for the
11297 quotient pattern and once for the remainder pattern.
11299 `(match_operator:M N PREDICATE [OPERANDS...])'
11300 This pattern is a kind of placeholder for a variable RTL expression
11303 When constructing an insn, it stands for an RTL expression whose
11304 expression code is taken from that of operand N, and whose
11305 operands are constructed from the patterns OPERANDS.
11307 When matching an expression, it matches an expression if the
11308 function PREDICATE returns nonzero on that expression _and_ the
11309 patterns OPERANDS match the operands of the expression.
11311 Suppose that the function `commutative_operator' is defined as
11312 follows, to match any expression whose operator is one of the
11313 commutative arithmetic operators of RTL and whose mode is MODE:
11316 commutative_integer_operator (x, mode)
11318 enum machine_mode mode;
11320 enum rtx_code code = GET_CODE (x);
11321 if (GET_MODE (x) != mode)
11323 return (GET_RTX_CLASS (code) == RTX_COMM_ARITH
11324 || code == EQ || code == NE);
11327 Then the following pattern will match any RTL expression consisting
11328 of a commutative operator applied to two general operands:
11330 (match_operator:SI 3 "commutative_operator"
11331 [(match_operand:SI 1 "general_operand" "g")
11332 (match_operand:SI 2 "general_operand" "g")])
11334 Here the vector `[OPERANDS...]' contains two patterns because the
11335 expressions to be matched all contain two operands.
11337 When this pattern does match, the two operands of the commutative
11338 operator are recorded as operands 1 and 2 of the insn. (This is
11339 done by the two instances of `match_operand'.) Operand 3 of the
11340 insn will be the entire commutative expression: use `GET_CODE
11341 (operands[3])' to see which commutative operator was used.
11343 The machine mode M of `match_operator' works like that of
11344 `match_operand': it is passed as the second argument to the
11345 predicate function, and that function is solely responsible for
11346 deciding whether the expression to be matched "has" that mode.
11348 When constructing an insn, argument 3 of the gen-function will
11349 specify the operation (i.e. the expression code) for the
11350 expression to be made. It should be an RTL expression, whose
11351 expression code is copied into a new expression whose operands are
11352 arguments 1 and 2 of the gen-function. The subexpressions of
11353 argument 3 are not used; only its expression code matters.
11355 When `match_operator' is used in a pattern for matching an insn,
11356 it usually best if the operand number of the `match_operator' is
11357 higher than that of the actual operands of the insn. This improves
11358 register allocation because the register allocator often looks at
11359 operands 1 and 2 of insns to see if it can do register tying.
11361 There is no way to specify constraints in `match_operator'. The
11362 operand of the insn which corresponds to the `match_operator'
11363 never has any constraints because it is never reloaded as a whole.
11364 However, if parts of its OPERANDS are matched by `match_operand'
11365 patterns, those parts may have constraints of their own.
11367 `(match_op_dup:M N[OPERANDS...])'
11368 Like `match_dup', except that it applies to operators instead of
11369 operands. When constructing an insn, operand number N will be
11370 substituted at this point. But in matching, `match_op_dup' behaves
11371 differently. It assumes that operand number N has already been
11372 determined by a `match_operator' appearing earlier in the
11373 recognition template, and it matches only an identical-looking
11376 `(match_parallel N PREDICATE [SUBPAT...])'
11377 This pattern is a placeholder for an insn that consists of a
11378 `parallel' expression with a variable number of elements. This
11379 expression should only appear at the top level of an insn pattern.
11381 When constructing an insn, operand number N will be substituted at
11382 this point. When matching an insn, it matches if the body of the
11383 insn is a `parallel' expression with at least as many elements as
11384 the vector of SUBPAT expressions in the `match_parallel', if each
11385 SUBPAT matches the corresponding element of the `parallel', _and_
11386 the function PREDICATE returns nonzero on the `parallel' that is
11387 the body of the insn. It is the responsibility of the predicate
11388 to validate elements of the `parallel' beyond those listed in the
11391 A typical use of `match_parallel' is to match load and store
11392 multiple expressions, which can contain a variable number of
11393 elements in a `parallel'. For example,
11396 [(match_parallel 0 "load_multiple_operation"
11397 [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
11398 (match_operand:SI 2 "memory_operand" "m"))
11400 (clobber (reg:SI 179))])]
11404 This example comes from `a29k.md'. The function
11405 `load_multiple_operation' is defined in `a29k.c' and checks that
11406 subsequent elements in the `parallel' are the same as the `set' in
11407 the pattern, except that they are referencing subsequent registers
11408 and memory locations.
11410 An insn that matches this pattern might look like:
11413 [(set (reg:SI 20) (mem:SI (reg:SI 100)))
11415 (clobber (reg:SI 179))
11417 (mem:SI (plus:SI (reg:SI 100)
11420 (mem:SI (plus:SI (reg:SI 100)
11423 `(match_par_dup N [SUBPAT...])'
11424 Like `match_op_dup', but for `match_parallel' instead of
11429 File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc
11431 13.5 Output Templates and Operand Substitution
11432 ==============================================
11434 The "output template" is a string which specifies how to output the
11435 assembler code for an instruction pattern. Most of the template is a
11436 fixed string which is output literally. The character `%' is used to
11437 specify where to substitute an operand; it can also be used to identify
11438 places where different variants of the assembler require different
11441 In the simplest case, a `%' followed by a digit N says to output
11442 operand N at that point in the string.
11444 `%' followed by a letter and a digit says to output an operand in an
11445 alternate fashion. Four letters have standard, built-in meanings
11446 described below. The machine description macro `PRINT_OPERAND' can
11447 define additional letters with nonstandard meanings.
11449 `%cDIGIT' can be used to substitute an operand that is a constant
11450 value without the syntax that normally indicates an immediate operand.
11452 `%nDIGIT' is like `%cDIGIT' except that the value of the constant is
11453 negated before printing.
11455 `%aDIGIT' can be used to substitute an operand as if it were a memory
11456 reference, with the actual operand treated as the address. This may be
11457 useful when outputting a "load address" instruction, because often the
11458 assembler syntax for such an instruction requires you to write the
11459 operand as if it were a memory reference.
11461 `%lDIGIT' is used to substitute a `label_ref' into a jump instruction.
11463 `%=' outputs a number which is unique to each instruction in the
11464 entire compilation. This is useful for making local labels to be
11465 referred to more than once in a single template that generates multiple
11466 assembler instructions.
11468 `%' followed by a punctuation character specifies a substitution that
11469 does not use an operand. Only one case is standard: `%%' outputs a `%'
11470 into the assembler code. Other nonstandard cases can be defined in the
11471 `PRINT_OPERAND' macro. You must also define which punctuation
11472 characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro.
11474 The template may generate multiple assembler instructions. Write the
11475 text for the instructions, with `\;' between them.
11477 When the RTL contains two operands which are required by constraint to
11478 match each other, the output template must refer only to the
11479 lower-numbered operand. Matching operands are not always identical,
11480 and the rest of the compiler arranges to put the proper RTL expression
11481 for printing into the lower-numbered operand.
11483 One use of nonstandard letters or punctuation following `%' is to
11484 distinguish between different assembler languages for the same machine;
11485 for example, Motorola syntax versus MIT syntax for the 68000. Motorola
11486 syntax requires periods in most opcode names, while MIT syntax does
11487 not. For example, the opcode `movel' in MIT syntax is `move.l' in
11488 Motorola syntax. The same file of patterns is used for both kinds of
11489 output syntax, but the character sequence `%.' is used in each place
11490 where Motorola syntax wants a period. The `PRINT_OPERAND' macro for
11491 Motorola syntax defines the sequence to output a period; the macro for
11492 MIT syntax defines it to do nothing.
11494 As a special case, a template consisting of the single character `#'
11495 instructs the compiler to first split the insn, and then output the
11496 resulting instructions separately. This helps eliminate redundancy in
11497 the output templates. If you have a `define_insn' that needs to emit
11498 multiple assembler instructions, and there is an matching `define_split'
11499 already defined, then you can simply use `#' as the output template
11500 instead of writing an output template that emits the multiple assembler
11503 If the macro `ASSEMBLER_DIALECT' is defined, you can use construct of
11504 the form `{option0|option1|option2}' in the templates. These describe
11505 multiple variants of assembler language syntax. *Note Instruction
11509 File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc
11511 13.6 C Statements for Assembler Output
11512 ======================================
11514 Often a single fixed template string cannot produce correct and
11515 efficient assembler code for all the cases that are recognized by a
11516 single instruction pattern. For example, the opcodes may depend on the
11517 kinds of operands; or some unfortunate combinations of operands may
11518 require extra machine instructions.
11520 If the output control string starts with a `@', then it is actually a
11521 series of templates, each on a separate line. (Blank lines and leading
11522 spaces and tabs are ignored.) The templates correspond to the
11523 pattern's constraint alternatives (*note Multi-Alternative::). For
11524 example, if a target machine has a two-address add instruction `addr'
11525 to add into a register and another `addm' to add a register to memory,
11526 you might write this pattern:
11528 (define_insn "addsi3"
11529 [(set (match_operand:SI 0 "general_operand" "=r,m")
11530 (plus:SI (match_operand:SI 1 "general_operand" "0,0")
11531 (match_operand:SI 2 "general_operand" "g,r")))]
11537 If the output control string starts with a `*', then it is not an
11538 output template but rather a piece of C program that should compute a
11539 template. It should execute a `return' statement to return the
11540 template-string you want. Most such templates use C string literals,
11541 which require doublequote characters to delimit them. To include these
11542 doublequote characters in the string, prefix each one with `\'.
11544 If the output control string is written as a brace block instead of a
11545 double-quoted string, it is automatically assumed to be C code. In that
11546 case, it is not necessary to put in a leading asterisk, or to escape the
11547 doublequotes surrounding C string literals.
11549 The operands may be found in the array `operands', whose C data type
11552 It is very common to select different ways of generating assembler code
11553 based on whether an immediate operand is within a certain range. Be
11554 careful when doing this, because the result of `INTVAL' is an integer
11555 on the host machine. If the host machine has more bits in an `int'
11556 than the target machine has in the mode in which the constant will be
11557 used, then some of the bits you get from `INTVAL' will be superfluous.
11558 For proper results, you must carefully disregard the values of those
11561 It is possible to output an assembler instruction and then go on to
11562 output or compute more of them, using the subroutine `output_asm_insn'.
11563 This receives two arguments: a template-string and a vector of
11564 operands. The vector may be `operands', or it may be another array of
11565 `rtx' that you declare locally and initialize yourself.
11567 When an insn pattern has multiple alternatives in its constraints,
11568 often the appearance of the assembler code is determined mostly by
11569 which alternative was matched. When this is so, the C code can test
11570 the variable `which_alternative', which is the ordinal number of the
11571 alternative that was actually satisfied (0 for the first, 1 for the
11572 second alternative, etc.).
11574 For example, suppose there are two opcodes for storing zero, `clrreg'
11575 for registers and `clrmem' for memory locations. Here is how a pattern
11576 could use `which_alternative' to choose between them:
11579 [(set (match_operand:SI 0 "general_operand" "=r,m")
11583 return (which_alternative == 0
11584 ? "clrreg %0" : "clrmem %0");
11587 The example above, where the assembler code to generate was _solely_
11588 determined by the alternative, could also have been specified as
11589 follows, having the output control string start with a `@':
11592 [(set (match_operand:SI 0 "general_operand" "=r,m")
11600 File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc
11605 A predicate determines whether a `match_operand' or `match_operator'
11606 expression matches, and therefore whether the surrounding instruction
11607 pattern will be used for that combination of operands. GCC has a
11608 number of machine-independent predicates, and you can define
11609 machine-specific predicates as needed. By convention, predicates used
11610 with `match_operand' have names that end in `_operand', and those used
11611 with `match_operator' have names that end in `_operator'.
11613 All predicates are Boolean functions (in the mathematical sense) of
11614 two arguments: the RTL expression that is being considered at that
11615 position in the instruction pattern, and the machine mode that the
11616 `match_operand' or `match_operator' specifies. In this section, the
11617 first argument is called OP and the second argument MODE. Predicates
11618 can be called from C as ordinary two-argument functions; this can be
11619 useful in output templates or other machine-specific code.
11621 Operand predicates can allow operands that are not actually acceptable
11622 to the hardware, as long as the constraints give reload the ability to
11623 fix them up (*note Constraints::). However, GCC will usually generate
11624 better code if the predicates specify the requirements of the machine
11625 instructions as closely as possible. Reload cannot fix up operands
11626 that must be constants ("immediate operands"); you must use a predicate
11627 that allows only constants, or else enforce the requirement in the
11630 Most predicates handle their MODE argument in a uniform manner. If
11631 MODE is `VOIDmode' (unspecified), then OP can have any mode. If MODE
11632 is anything else, then OP must have the same mode, unless OP is a
11633 `CONST_INT' or integer `CONST_DOUBLE'. These RTL expressions always
11634 have `VOIDmode', so it would be counterproductive to check that their
11635 mode matches. Instead, predicates that accept `CONST_INT' and/or
11636 integer `CONST_DOUBLE' check that the value stored in the constant will
11637 fit in the requested mode.
11639 Predicates with this behavior are called "normal". `genrecog' can
11640 optimize the instruction recognizer based on knowledge of how normal
11641 predicates treat modes. It can also diagnose certain kinds of common
11642 errors in the use of normal predicates; for instance, it is almost
11643 always an error to use a normal predicate without specifying a mode.
11645 Predicates that do something different with their MODE argument are
11646 called "special". The generic predicates `address_operand' and
11647 `pmode_register_operand' are special predicates. `genrecog' does not
11648 do any optimizations or diagnosis when special predicates are used.
11652 * Machine-Independent Predicates:: Predicates available to all back ends.
11653 * Defining Predicates:: How to write machine-specific predicate
11657 File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates
11659 13.7.1 Machine-Independent Predicates
11660 -------------------------------------
11662 These are the generic predicates available to all back ends. They are
11663 defined in `recog.c'. The first category of predicates allow only
11664 constant, or "immediate", operands.
11666 -- Function: immediate_operand
11667 This predicate allows any sort of constant that fits in MODE. It
11668 is an appropriate choice for instructions that take operands that
11671 -- Function: const_int_operand
11672 This predicate allows any `CONST_INT' expression that fits in
11673 MODE. It is an appropriate choice for an immediate operand that
11674 does not allow a symbol or label.
11676 -- Function: const_double_operand
11677 This predicate accepts any `CONST_DOUBLE' expression that has
11678 exactly MODE. If MODE is `VOIDmode', it will also accept
11679 `CONST_INT'. It is intended for immediate floating point
11682 The second category of predicates allow only some kind of machine
11685 -- Function: register_operand
11686 This predicate allows any `REG' or `SUBREG' expression that is
11687 valid for MODE. It is often suitable for arithmetic instruction
11688 operands on a RISC machine.
11690 -- Function: pmode_register_operand
11691 This is a slight variant on `register_operand' which works around
11692 a limitation in the machine-description reader.
11694 (match_operand N "pmode_register_operand" CONSTRAINT)
11698 (match_operand:P N "register_operand" CONSTRAINT)
11700 would mean, if the machine-description reader accepted `:P' mode
11701 suffixes. Unfortunately, it cannot, because `Pmode' is an alias
11702 for some other mode, and might vary with machine-specific options.
11705 -- Function: scratch_operand
11706 This predicate allows hard registers and `SCRATCH' expressions,
11707 but not pseudo-registers. It is used internally by
11708 `match_scratch'; it should not be used directly.
11710 The third category of predicates allow only some kind of memory
11713 -- Function: memory_operand
11714 This predicate allows any valid reference to a quantity of mode
11715 MODE in memory, as determined by the weak form of
11716 `GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::).
11718 -- Function: address_operand
11719 This predicate is a little unusual; it allows any operand that is a
11720 valid expression for the _address_ of a quantity of mode MODE,
11721 again determined by the weak form of `GO_IF_LEGITIMATE_ADDRESS'.
11722 To first order, if `(mem:MODE (EXP))' is acceptable to
11723 `memory_operand', then EXP is acceptable to `address_operand'.
11724 Note that EXP does not necessarily have the mode MODE.
11726 -- Function: indirect_operand
11727 This is a stricter form of `memory_operand' which allows only
11728 memory references with a `general_operand' as the address
11729 expression. New uses of this predicate are discouraged, because
11730 `general_operand' is very permissive, so it's hard to tell what an
11731 `indirect_operand' does or does not allow. If a target has
11732 different requirements for memory operands for different
11733 instructions, it is better to define target-specific predicates
11734 which enforce the hardware's requirements explicitly.
11736 -- Function: push_operand
11737 This predicate allows a memory reference suitable for pushing a
11738 value onto the stack. This will be a `MEM' which refers to
11739 `stack_pointer_rtx', with a side-effect in its address expression
11740 (*note Incdec::); which one is determined by the `STACK_PUSH_CODE'
11741 macro (*note Frame Layout::).
11743 -- Function: pop_operand
11744 This predicate allows a memory reference suitable for popping a
11745 value off the stack. Again, this will be a `MEM' referring to
11746 `stack_pointer_rtx', with a side-effect in its address expression.
11747 However, this time `STACK_POP_CODE' is expected.
11749 The fourth category of predicates allow some combination of the above
11752 -- Function: nonmemory_operand
11753 This predicate allows any immediate or register operand valid for
11756 -- Function: nonimmediate_operand
11757 This predicate allows any register or memory operand valid for
11760 -- Function: general_operand
11761 This predicate allows any immediate, register, or memory operand
11764 Finally, there is one generic operator predicate.
11766 -- Function: comparison_operator
11767 This predicate matches any expression which performs an arithmetic
11768 comparison in MODE; that is, `COMPARISON_P' is true for the
11772 File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates
11774 13.7.2 Defining Machine-Specific Predicates
11775 -------------------------------------------
11777 Many machines have requirements for their operands that cannot be
11778 expressed precisely using the generic predicates. You can define
11779 additional predicates using `define_predicate' and
11780 `define_special_predicate' expressions. These expressions have three
11783 * The name of the predicate, as it will be referred to in
11784 `match_operand' or `match_operator' expressions.
11786 * An RTL expression which evaluates to true if the predicate allows
11787 the operand OP, false if it does not. This expression can only use
11788 the following RTL codes:
11791 When written inside a predicate expression, a `MATCH_OPERAND'
11792 expression evaluates to true if the predicate it names would
11793 allow OP. The operand number and constraint are ignored.
11794 Due to limitations in `genrecog', you can only refer to
11795 generic predicates and predicates that have already been
11799 This expression has one operand, a string constant containing
11800 a comma-separated list of RTX code names (in lower case). It
11801 evaluates to true if OP has any of the listed codes.
11804 This expression has one operand, a string constant containing
11805 a C expression. The predicate's arguments, OP and MODE, are
11806 available with those names in the C expression. The
11807 `MATCH_TEST' evaluates to true if the C expression evaluates
11808 to a nonzero value. `MATCH_TEST' expressions must not have
11815 The basic `MATCH_' expressions can be combined using these
11816 logical operators, which have the semantics of the C operators
11817 `&&', `||', `!', and `? :' respectively.
11819 * An optional block of C code, which should execute `return true' if
11820 the predicate is found to match and `return false' if it does not.
11821 It must not have any side effects. The predicate arguments, OP
11822 and MODE, are available with those names.
11824 If a code block is present in a predicate definition, then the RTL
11825 expression must evaluate to true _and_ the code block must execute
11826 `return true' for the predicate to allow the operand. The RTL
11827 expression is evaluated first; do not re-check anything in the
11828 code block that was checked in the RTL expression.
11830 The program `genrecog' scans `define_predicate' and
11831 `define_special_predicate' expressions to determine which RTX codes are
11832 possibly allowed. You should always make this explicit in the RTL
11833 predicate expression, using `MATCH_OPERAND' and `MATCH_CODE'.
11835 Here is an example of a simple predicate definition, from the IA64
11836 machine description:
11838 ;; True if OP is a `SYMBOL_REF' which refers to the sdata section.
11839 (define_predicate "small_addr_symbolic_operand"
11840 (and (match_code "symbol_ref")
11841 (match_test "SYMBOL_REF_SMALL_ADDR_P (op)")))
11843 And here is another, showing the use of the C block.
11845 ;; True if OP is a register operand that is (or could be) a GR reg.
11846 (define_predicate "gr_register_operand"
11847 (match_operand 0 "register_operand")
11849 unsigned int regno;
11850 if (GET_CODE (op) == SUBREG)
11851 op = SUBREG_REG (op);
11853 regno = REGNO (op);
11854 return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno));
11857 Predicates written with `define_predicate' automatically include a
11858 test that MODE is `VOIDmode', or OP has the same mode as MODE, or OP is
11859 a `CONST_INT' or `CONST_DOUBLE'. They do _not_ check specifically for
11860 integer `CONST_DOUBLE', nor do they test that the value of either kind
11861 of constant fits in the requested mode. This is because
11862 target-specific predicates that take constants usually have to do more
11863 stringent value checks anyway. If you need the exact same treatment of
11864 `CONST_INT' or `CONST_DOUBLE' that the generic predicates provide, use
11865 a `MATCH_OPERAND' subexpression to call `const_int_operand',
11866 `const_double_operand', or `immediate_operand'.
11868 Predicates written with `define_special_predicate' do not get any
11869 automatic mode checks, and are treated as having special mode handling
11872 The program `genpreds' is responsible for generating code to test
11873 predicates. It also writes a header file containing function
11874 declarations for all machine-specific predicates. It is not necessary
11875 to declare these predicates in `CPU-protos.h'.
11878 File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc
11880 13.8 Operand Constraints
11881 ========================
11883 Each `match_operand' in an instruction pattern can specify constraints
11884 for the operands allowed. The constraints allow you to fine-tune
11885 matching within the set of operands allowed by the predicate.
11887 Constraints can say whether an operand may be in a register, and which
11888 kinds of register; whether the operand can be a memory reference, and
11889 which kinds of address; whether the operand may be an immediate
11890 constant, and which possible values it may have. Constraints can also
11891 require two operands to match.
11895 * Simple Constraints:: Basic use of constraints.
11896 * Multi-Alternative:: When an insn has two alternative constraint-patterns.
11897 * Class Preferences:: Constraints guide which hard register to put things in.
11898 * Modifiers:: More precise control over effects of constraints.
11899 * Machine Constraints:: Existing constraints for some particular machines.
11902 File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints
11904 13.8.1 Simple Constraints
11905 -------------------------
11907 The simplest kind of constraint is a string full of letters, each of
11908 which describes one kind of operand that is permitted. Here are the
11909 letters that are allowed:
11912 Whitespace characters are ignored and can be inserted at any
11913 position except the first. This enables each alternative for
11914 different operands to be visually aligned in the machine
11915 description even if they have different number of constraints and
11919 A memory operand is allowed, with any kind of address that the
11920 machine supports in general.
11923 A memory operand is allowed, but only if the address is
11924 "offsettable". This means that adding a small integer (actually,
11925 the width in bytes of the operand, as determined by its machine
11926 mode) may be added to the address and the result is also a valid
11929 For example, an address which is constant is offsettable; so is an
11930 address that is the sum of a register and a constant (as long as a
11931 slightly larger constant is also within the range of
11932 address-offsets supported by the machine); but an autoincrement or
11933 autodecrement address is not offsettable. More complicated
11934 indirect/indexed addresses may or may not be offsettable depending
11935 on the other addressing modes that the machine supports.
11937 Note that in an output operand which can be matched by another
11938 operand, the constraint letter `o' is valid only when accompanied
11939 by both `<' (if the target machine has predecrement addressing)
11940 and `>' (if the target machine has preincrement addressing).
11943 A memory operand that is not offsettable. In other words,
11944 anything that would fit the `m' constraint but not the `o'
11948 A memory operand with autodecrement addressing (either
11949 predecrement or postdecrement) is allowed.
11952 A memory operand with autoincrement addressing (either
11953 preincrement or postincrement) is allowed.
11956 A register operand is allowed provided that it is in a general
11960 An immediate integer operand (one with constant value) is allowed.
11961 This includes symbolic constants whose values will be known only at
11962 assembly time or later.
11965 An immediate integer operand with a known numeric value is allowed.
11966 Many systems cannot support assembly-time constants for operands
11967 less than a word wide. Constraints for these operands should use
11968 `n' rather than `i'.
11970 `I', `J', `K', ... `P'
11971 Other letters in the range `I' through `P' may be defined in a
11972 machine-dependent fashion to permit immediate integer operands with
11973 explicit integer values in specified ranges. For example, on the
11974 68000, `I' is defined to stand for the range of values 1 to 8.
11975 This is the range permitted as a shift count in the shift
11979 An immediate floating operand (expression code `const_double') is
11980 allowed, but only if the target floating point format is the same
11981 as that of the host machine (on which the compiler is running).
11984 An immediate floating operand (expression code `const_double' or
11985 `const_vector') is allowed.
11988 `G' and `H' may be defined in a machine-dependent fashion to
11989 permit immediate floating operands in particular ranges of values.
11992 An immediate integer operand whose value is not an explicit
11993 integer is allowed.
11995 This might appear strange; if an insn allows a constant operand
11996 with a value not known at compile time, it certainly must allow
11997 any known value. So why use `s' instead of `i'? Sometimes it
11998 allows better code to be generated.
12000 For example, on the 68000 in a fullword instruction it is possible
12001 to use an immediate operand; but if the immediate value is between
12002 -128 and 127, better code results from loading the value into a
12003 register and using the register. This is because the load into
12004 the register can be done with a `moveq' instruction. We arrange
12005 for this to happen by defining the letter `K' to mean "any integer
12006 outside the range -128 to 127", and then specifying `Ks' in the
12007 operand constraints.
12010 Any register, memory or immediate integer operand is allowed,
12011 except for registers that are not general registers.
12014 Any operand whatsoever is allowed, even if it does not satisfy
12015 `general_operand'. This is normally used in the constraint of a
12016 `match_scratch' when certain alternatives will not actually
12017 require a scratch register.
12019 `0', `1', `2', ... `9'
12020 An operand that matches the specified operand number is allowed.
12021 If a digit is used together with letters within the same
12022 alternative, the digit should come last.
12024 This number is allowed to be more than a single digit. If multiple
12025 digits are encountered consecutively, they are interpreted as a
12026 single decimal integer. There is scant chance for ambiguity,
12027 since to-date it has never been desirable that `10' be interpreted
12028 as matching either operand 1 _or_ operand 0. Should this be
12029 desired, one can use multiple alternatives instead.
12031 This is called a "matching constraint" and what it really means is
12032 that the assembler has only a single operand that fills two roles
12033 considered separate in the RTL insn. For example, an add insn has
12034 two input operands and one output operand in the RTL, but on most
12035 CISC machines an add instruction really has only two operands, one
12036 of them an input-output operand:
12040 Matching constraints are used in these circumstances. More
12041 precisely, the two operands that match must include one input-only
12042 operand and one output-only operand. Moreover, the digit must be a
12043 smaller number than the number of the operand that uses it in the
12046 For operands to match in a particular case usually means that they
12047 are identical-looking RTL expressions. But in a few special cases
12048 specific kinds of dissimilarity are allowed. For example, `*x' as
12049 an input operand will match `*x++' as an output operand. For
12050 proper results in such cases, the output template should always
12051 use the output-operand's number when printing the operand.
12054 An operand that is a valid memory address is allowed. This is for
12055 "load address" and "push address" instructions.
12057 `p' in the constraint must be accompanied by `address_operand' as
12058 the predicate in the `match_operand'. This predicate interprets
12059 the mode specified in the `match_operand' as the mode of the memory
12060 reference for which the address would be valid.
12063 Other letters can be defined in machine-dependent fashion to stand
12064 for particular classes of registers or other arbitrary operand
12065 types. `d', `a' and `f' are defined on the 68000/68020 to stand
12066 for data, address and floating point registers.
12068 The machine description macro `REG_CLASS_FROM_LETTER' has first
12069 cut at the otherwise unused letters. If it evaluates to `NO_REGS',
12070 then `EXTRA_CONSTRAINT' is evaluated.
12072 A typical use for `EXTRA_CONSTRAINT' would be to distinguish
12073 certain types of memory references that affect other insn operands.
12075 In order to have valid assembler code, each operand must satisfy its
12076 constraint. But a failure to do so does not prevent the pattern from
12077 applying to an insn. Instead, it directs the compiler to modify the
12078 code so that the constraint will be satisfied. Usually this is done by
12079 copying an operand into a register.
12081 Contrast, therefore, the two instruction patterns that follow:
12084 [(set (match_operand:SI 0 "general_operand" "=r")
12085 (plus:SI (match_dup 0)
12086 (match_operand:SI 1 "general_operand" "r")))]
12090 which has two operands, one of which must appear in two places, and
12093 [(set (match_operand:SI 0 "general_operand" "=r")
12094 (plus:SI (match_operand:SI 1 "general_operand" "0")
12095 (match_operand:SI 2 "general_operand" "r")))]
12099 which has three operands, two of which are required by a constraint to
12100 be identical. If we are considering an insn of the form
12104 (plus:SI (reg:SI 6) (reg:SI 109)))
12107 the first pattern would not apply at all, because this insn does not
12108 contain two identical subexpressions in the right place. The pattern
12109 would say, "That does not look like an add instruction; try other
12110 patterns". The second pattern would say, "Yes, that's an add
12111 instruction, but there is something wrong with it". It would direct
12112 the reload pass of the compiler to generate additional insns to make
12113 the constraint true. The results might look like this:
12116 (set (reg:SI 3) (reg:SI 6))
12121 (plus:SI (reg:SI 3) (reg:SI 109)))
12124 It is up to you to make sure that each operand, in each pattern, has
12125 constraints that can handle any RTL expression that could be present for
12126 that operand. (When multiple alternatives are in use, each pattern
12127 must, for each possible combination of operand expressions, have at
12128 least one alternative which can handle that combination of operands.)
12129 The constraints don't need to _allow_ any possible operand--when this is
12130 the case, they do not constrain--but they must at least point the way to
12131 reloading any possible operand so that it will fit.
12133 * If the constraint accepts whatever operands the predicate permits,
12134 there is no problem: reloading is never necessary for this operand.
12136 For example, an operand whose constraints permit everything except
12137 registers is safe provided its predicate rejects registers.
12139 An operand whose predicate accepts only constant values is safe
12140 provided its constraints include the letter `i'. If any possible
12141 constant value is accepted, then nothing less than `i' will do; if
12142 the predicate is more selective, then the constraints may also be
12145 * Any operand expression can be reloaded by copying it into a
12146 register. So if an operand's constraints allow some kind of
12147 register, it is certain to be safe. It need not permit all
12148 classes of registers; the compiler knows how to copy a register
12149 into another register of the proper class in order to make an
12152 * A nonoffsettable memory reference can be reloaded by copying the
12153 address into a register. So if the constraint uses the letter
12154 `o', all memory references are taken care of.
12156 * A constant operand can be reloaded by allocating space in memory to
12157 hold it as preinitialized data. Then the memory reference can be
12158 used in place of the constant. So if the constraint uses the
12159 letters `o' or `m', constant operands are not a problem.
12161 * If the constraint permits a constant and a pseudo register used in
12162 an insn was not allocated to a hard register and is equivalent to
12163 a constant, the register will be replaced with the constant. If
12164 the predicate does not permit a constant and the insn is
12165 re-recognized for some reason, the compiler will crash. Thus the
12166 predicate must always recognize any objects allowed by the
12169 If the operand's predicate can recognize registers, but the constraint
12170 does not permit them, it can make the compiler crash. When this
12171 operand happens to be a register, the reload pass will be stymied,
12172 because it does not know how to copy a register temporarily into memory.
12174 If the predicate accepts a unary operator, the constraint applies to
12175 the operand. For example, the MIPS processor at ISA level 3 supports an
12176 instruction which adds two registers in `SImode' to produce a `DImode'
12177 result, but only if the registers are correctly sign extended. This
12178 predicate for the input operands accepts a `sign_extend' of an `SImode'
12179 register. Write the constraint to indicate the type of register that
12180 is required for the operand of the `sign_extend'.
12183 File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints
12185 13.8.2 Multiple Alternative Constraints
12186 ---------------------------------------
12188 Sometimes a single instruction has multiple alternative sets of possible
12189 operands. For example, on the 68000, a logical-or instruction can
12190 combine register or an immediate value into memory, or it can combine
12191 any kind of operand into a register; but it cannot combine one memory
12192 location into another.
12194 These constraints are represented as multiple alternatives. An
12195 alternative can be described by a series of letters for each operand.
12196 The overall constraint for an operand is made from the letters for this
12197 operand from the first alternative, a comma, the letters for this
12198 operand from the second alternative, a comma, and so on until the last
12199 alternative. Here is how it is done for fullword logical-or on the
12202 (define_insn "iorsi3"
12203 [(set (match_operand:SI 0 "general_operand" "=m,d")
12204 (ior:SI (match_operand:SI 1 "general_operand" "%0,0")
12205 (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
12208 The first alternative has `m' (memory) for operand 0, `0' for operand
12209 1 (meaning it must match operand 0), and `dKs' for operand 2. The
12210 second alternative has `d' (data register) for operand 0, `0' for
12211 operand 1, and `dmKs' for operand 2. The `=' and `%' in the
12212 constraints apply to all the alternatives; their meaning is explained
12213 in the next section (*note Class Preferences::).
12215 If all the operands fit any one alternative, the instruction is valid.
12216 Otherwise, for each alternative, the compiler counts how many
12217 instructions must be added to copy the operands so that that
12218 alternative applies. The alternative requiring the least copying is
12219 chosen. If two alternatives need the same amount of copying, the one
12220 that comes first is chosen. These choices can be altered with the `?'
12221 and `!' characters:
12224 Disparage slightly the alternative that the `?' appears in, as a
12225 choice when no alternative applies exactly. The compiler regards
12226 this alternative as one unit more costly for each `?' that appears
12230 Disparage severely the alternative that the `!' appears in. This
12231 alternative can still be used if it fits without reloading, but if
12232 reloading is needed, some other alternative will be used.
12234 When an insn pattern has multiple alternatives in its constraints,
12235 often the appearance of the assembler code is determined mostly by which
12236 alternative was matched. When this is so, the C code for writing the
12237 assembler code can use the variable `which_alternative', which is the
12238 ordinal number of the alternative that was actually satisfied (0 for
12239 the first, 1 for the second alternative, etc.). *Note Output
12243 File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints
12245 13.8.3 Register Class Preferences
12246 ---------------------------------
12248 The operand constraints have another function: they enable the compiler
12249 to decide which kind of hardware register a pseudo register is best
12250 allocated to. The compiler examines the constraints that apply to the
12251 insns that use the pseudo register, looking for the machine-dependent
12252 letters such as `d' and `a' that specify classes of registers. The
12253 pseudo register is put in whichever class gets the most "votes". The
12254 constraint letters `g' and `r' also vote: they vote in favor of a
12255 general register. The machine description says which registers are
12256 considered general.
12258 Of course, on some machines all registers are equivalent, and no
12259 register classes are defined. Then none of this complexity is relevant.
12262 File: gccint.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints
12264 13.8.4 Constraint Modifier Characters
12265 -------------------------------------
12267 Here are constraint modifier characters.
12270 Means that this operand is write-only for this instruction: the
12271 previous value is discarded and replaced by output data.
12274 Means that this operand is both read and written by the
12277 When the compiler fixes up the operands to satisfy the constraints,
12278 it needs to know which operands are inputs to the instruction and
12279 which are outputs from it. `=' identifies an output; `+'
12280 identifies an operand that is both input and output; all other
12281 operands are assumed to be input only.
12283 If you specify `=' or `+' in a constraint, you put it in the first
12284 character of the constraint string.
12287 Means (in a particular alternative) that this operand is an
12288 "earlyclobber" operand, which is modified before the instruction is
12289 finished using the input operands. Therefore, this operand may
12290 not lie in a register that is used as an input operand or as part
12291 of any memory address.
12293 `&' applies only to the alternative in which it is written. In
12294 constraints with multiple alternatives, sometimes one alternative
12295 requires `&' while others do not. See, for example, the `movdf'
12298 An input operand can be tied to an earlyclobber operand if its only
12299 use as an input occurs before the early result is written. Adding
12300 alternatives of this form often allows GCC to produce better code
12301 when only some of the inputs can be affected by the earlyclobber.
12302 See, for example, the `mulsi3' insn of the ARM.
12304 `&' does not obviate the need to write `='.
12307 Declares the instruction to be commutative for this operand and the
12308 following operand. This means that the compiler may interchange
12309 the two operands if that is the cheapest way to make all operands
12310 fit the constraints. This is often used in patterns for addition
12311 instructions that really have only two operands: the result must
12312 go in one of the arguments. Here for example, is how the 68000
12313 halfword-add instruction is defined:
12315 (define_insn "addhi3"
12316 [(set (match_operand:HI 0 "general_operand" "=m,r")
12317 (plus:HI (match_operand:HI 1 "general_operand" "%0,0")
12318 (match_operand:HI 2 "general_operand" "di,g")))]
12320 GCC can only handle one commutative pair in an asm; if you use
12321 more, the compiler may fail. Note that you need not use the
12322 modifier if the two alternatives are strictly identical; this
12323 would only waste time in the reload pass. The modifier is not
12324 operational after register allocation, so the result of
12325 `define_peephole2' and `define_split's performed after reload
12326 cannot rely on `%' to make the intended insn match.
12329 Says that all following characters, up to the next comma, are to be
12330 ignored as a constraint. They are significant only for choosing
12331 register preferences.
12334 Says that the following character should be ignored when choosing
12335 register preferences. `*' has no effect on the meaning of the
12336 constraint as a constraint, and no effect on reloading.
12338 Here is an example: the 68000 has an instruction to sign-extend a
12339 halfword in a data register, and can also sign-extend a value by
12340 copying it into an address register. While either kind of
12341 register is acceptable, the constraints on an address-register
12342 destination are less strict, so it is best if register allocation
12343 makes an address register its goal. Therefore, `*' is used so
12344 that the `d' constraint letter (for data register) is ignored when
12345 computing register preferences.
12347 (define_insn "extendhisi2"
12348 [(set (match_operand:SI 0 "general_operand" "=*d,a")
12350 (match_operand:HI 1 "general_operand" "0,g")))]
12354 File: gccint.info, Node: Machine Constraints, Prev: Modifiers, Up: Constraints
12356 13.8.5 Constraints for Particular Machines
12357 ------------------------------------------
12359 Whenever possible, you should use the general-purpose constraint letters
12360 in `asm' arguments, since they will convey meaning more readily to
12361 people reading your code. Failing that, use the constraint letters
12362 that usually have very similar meanings across architectures. The most
12363 commonly used constraints are `m' and `r' (for memory and
12364 general-purpose registers respectively; *note Simple Constraints::), and
12365 `I', usually the letter indicating the most common immediate-constant
12368 For each machine architecture, the `config/MACHINE/MACHINE.h' file
12369 defines additional constraints. These constraints are used by the
12370 compiler itself for instruction generation, as well as for `asm'
12371 statements; therefore, some of the constraints are not particularly
12372 interesting for `asm'. The constraints are defined through these
12375 `REG_CLASS_FROM_LETTER'
12376 Register class constraints (usually lowercase).
12378 `CONST_OK_FOR_LETTER_P'
12379 Immediate constant constraints, for non-floating point constants of
12380 word size or smaller precision (usually uppercase).
12382 `CONST_DOUBLE_OK_FOR_LETTER_P'
12383 Immediate constant constraints, for all floating point constants
12384 and for constants of greater than word size precision (usually
12388 Special cases of registers or memory. This macro is not required,
12389 and is only defined for some machines.
12391 Inspecting these macro definitions in the compiler source for your
12392 machine is the best way to be certain you have the right constraints.
12393 However, here is a summary of the machine-dependent constraints
12394 available on some particular machines.
12396 _ARM family--`arm.h'_
12399 Floating-point register
12402 VFP floating-point register
12405 One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0,
12409 Floating-point constant that would satisfy the constraint `F'
12413 Integer that is valid as an immediate operand in a data
12414 processing instruction. That is, an integer in the range 0
12415 to 255 rotated by a multiple of 2
12418 Integer in the range -4095 to 4095
12421 Integer that satisfies constraint `I' when inverted (ones
12425 Integer that satisfies constraint `I' when negated (twos
12429 Integer in the range 0 to 32
12432 A memory reference where the exact address is in a single
12433 register (``m'' is preferable for `asm' statements)
12436 An item in the constant pool
12439 A symbol in the text segment of the current file
12442 A memory reference suitable for VFP load/store insns
12443 (reg+constant offset)
12446 A memory reference suitable for iWMMXt load/store
12450 A memory reference suitable for the ARMv4 ldrsb instruction.
12452 _AVR family--`avr.h'_
12455 Registers from r0 to r15
12458 Registers from r16 to r23
12461 Registers from r16 to r31
12464 Registers from r24 to r31. These registers can be used in
12468 Pointer register (r26-r31)
12471 Base pointer register (r28-r31)
12474 Stack pointer register (SPH:SPL)
12477 Temporary register r0
12480 Register pair X (r27:r26)
12483 Register pair Y (r29:r28)
12486 Register pair Z (r31:r30)
12489 Constant greater than -1, less than 64
12492 Constant greater than -64, less than 1
12501 Constant that fits in 8 bits
12504 Constant integer -1
12507 Constant integer 8, 16, or 24
12513 A floating point constant 0.0
12515 _CRX Architecture--`crx.h'_
12518 Registers from r0 to r14 (registers without stack pointer)
12521 Register r16 (64-bit accumulator lo register)
12524 Register r17 (64-bit accumulator hi register)
12527 Register pair r16-r17. (64-bit accumulator lo-hi pair)
12530 Constant that fits in 3 bits
12533 Constant that fits in 4 bits
12536 Constant that fits in 5 bits
12539 Constant that is one of -1, 4, -4, 7, 8, 12, 16, 20, 32, 48
12542 Floating point constant that is legal for store immediate
12544 _PowerPC and IBM RS6000--`rs6000.h'_
12547 Address base register
12550 Floating point register
12556 `MQ', `CTR', or `LINK' register
12568 `CR' register (condition register) number 0
12571 `CR' register (condition register)
12574 `FPMEM' stack memory for FPR-GPR transfers
12577 Signed 16-bit constant
12580 Unsigned 16-bit constant shifted left 16 bits (use `L'
12581 instead for `SImode' constants)
12584 Unsigned 16-bit constant
12587 Signed 16-bit constant shifted left 16 bits
12590 Constant larger than 31
12599 Constant whose negation is a signed 16-bit constant
12602 Floating point constant that can be loaded into a register
12603 with one instruction per word
12606 Memory operand that is an offset from a register (`m' is
12607 preferable for `asm' statements)
12613 Constant suitable as a 64-bit mask operand
12616 Constant suitable as a 32-bit mask operand
12619 System V Release 4 small data area reference
12621 _MorphoTech family--`mt.h'_
12624 Constant for an arithmetic insn (16-bit signed integer).
12630 Constant for a logical insn (16-bit zero-extended integer).
12633 A constant that can be loaded with `lui' (i.e. the bottom 16
12637 A constant that takes two words to load (i.e. not matched by
12641 Negative 16-bit constants other than -65536.
12644 A 15-bit signed integer constant.
12647 A positive 16-bit constant.
12649 _Intel 386--`i386.h'_
12652 `a', `b', `c', or `d' register for the i386. For x86-64 it
12653 is equivalent to `r' class (for 8-bit instructions that do
12654 not use upper halves).
12657 `a', `b', `c', or `d' register (for 8-bit instructions, that
12658 do use upper halves).
12661 Legacy register--equivalent to `r' class in i386 mode. (for
12662 non-8-bit registers used together with 8-bit upper halves in
12663 a single instruction)
12666 Specifies the `a' or `d' registers. This is primarily useful
12667 for 64-bit integer values (when in 32-bit mode) intended to
12668 be returned with the `d' register holding the most
12669 significant bits and the `a' register holding the least
12673 Floating point register
12676 First (top of stack) floating point register
12679 Second floating point register
12691 Specifies constant that can be easily constructed in SSE
12692 register without loading it from memory.
12710 Constant in range 0 to 31 (for 32-bit shifts)
12713 Constant in range 0 to 63 (for 64-bit shifts)
12722 0, 1, 2, or 3 (shifts for `lea' instruction)
12725 Constant in range 0 to 255 (for `out' instruction)
12728 Constant in range 0 to `0xffffffff' or symbolic reference
12729 known to fit specified range. (for using immediates in zero
12730 extending 32-bit to 64-bit x86-64 instructions)
12733 Constant in range -2147483648 to 2147483647 or symbolic
12734 reference known to fit specified range. (for using
12735 immediates in 64-bit x86-64 instructions)
12738 Standard 80387 floating point constant
12740 _Intel IA-64--`ia64.h'_
12743 General register `r0' to `r3' for `addl' instruction
12749 Predicate register (`c' as in "conditional")
12752 Application register residing in M-unit
12755 Application register residing in I-unit
12758 Floating-point register
12761 Memory operand. Remember that `m' allows postincrement and
12762 postdecrement which require printing with `%Pn' on IA-64.
12763 Use `S' to disallow postincrement and postdecrement.
12766 Floating-point constant 0.0 or 1.0
12769 14-bit signed integer constant
12772 22-bit signed integer constant
12775 8-bit signed integer constant for logical instructions
12778 8-bit adjusted signed integer constant for compare pseudo-ops
12781 6-bit unsigned integer constant for shift counts
12784 9-bit signed integer constant for load and store
12791 0 or -1 for `dep' instruction
12794 Non-volatile memory for floating-point loads and stores
12797 Integer constant in the range 1 to 4 for `shladd' instruction
12800 Memory operand except postincrement and postdecrement
12805 Register in the class `ACC_REGS' (`acc0' to `acc7').
12808 Register in the class `EVEN_ACC_REGS' (`acc0' to `acc7').
12811 Register in the class `CC_REGS' (`fcc0' to `fcc3' and `icc0'
12815 Register in the class `GPR_REGS' (`gr0' to `gr63').
12818 Register in the class `EVEN_REGS' (`gr0' to `gr63'). Odd
12819 registers are excluded not in the class but through the use
12820 of a machine mode larger than 4 bytes.
12823 Register in the class `FPR_REGS' (`fr0' to `fr63').
12826 Register in the class `FEVEN_REGS' (`fr0' to `fr63'). Odd
12827 registers are excluded not in the class but through the use
12828 of a machine mode larger than 4 bytes.
12831 Register in the class `LR_REG' (the `lr' register).
12834 Register in the class `QUAD_REGS' (`gr2' to `gr63').
12835 Register numbers not divisible by 4 are excluded not in the
12836 class but through the use of a machine mode larger than 8
12840 Register in the class `ICC_REGS' (`icc0' to `icc3').
12843 Register in the class `FCC_REGS' (`fcc0' to `fcc3').
12846 Register in the class `ICR_REGS' (`cc4' to `cc7').
12849 Register in the class `FCR_REGS' (`cc0' to `cc3').
12852 Register in the class `QUAD_FPR_REGS' (`fr0' to `fr63').
12853 Register numbers not divisible by 4 are excluded not in the
12854 class but through the use of a machine mode larger than 8
12858 Register in the class `SPR_REGS' (`lcr' and `lr').
12861 Register in the class `QUAD_ACC_REGS' (`acc0' to `acc7').
12864 Register in the class `ACCG_REGS' (`accg0' to `accg7').
12867 Register in the class `CR_REGS' (`cc0' to `cc7').
12870 Floating point constant zero
12873 6-bit signed integer constant
12876 10-bit signed integer constant
12879 16-bit signed integer constant
12882 16-bit unsigned integer constant
12885 12-bit signed integer constant that is negative--i.e. in the
12886 range of -2048 to -1
12892 12-bit signed integer constant that is greater than
12893 zero--i.e. in the range of 1 to 2047.
12896 _Blackfin family--`bfin.h'_
12905 A call clobbered P register.
12908 Even-numbered D register
12911 Odd-numbered D register
12914 Accumulator register.
12917 Even-numbered accumulator register.
12920 Odd-numbered accumulator register.
12932 Registers used for circular buffering, i.e. I, B, or L
12939 Any D, P, B, M, I or L register.
12942 Additional registers typically used only in prologues and
12943 epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and
12947 Any register except accumulators or CC.
12950 Signed 16 bit integer (in the range -32768 to 32767)
12953 Unsigned 16 bit integer (in the range 0 to 65535)
12956 Signed 7 bit integer (in the range -64 to 63)
12959 Unsigned 7 bit integer (in the range 0 to 127)
12962 Unsigned 5 bit integer (in the range 0 to 31)
12965 Signed 4 bit integer (in the range -8 to 7)
12968 Signed 3 bit integer (in the range -3 to 4)
12971 Unsigned 3 bit integer (in the range 0 to 7)
12974 Constant N, where N is a single-digit constant in the range 0
12984 An integer constant with exactly a single bit set.
12987 An integer constant with all bits set except exactly one.
12999 `$sp', `$fb', `$sb'.
13002 Any control register, when they're 16 bits wide (nothing if control
13003 registers are 24 bits wide)
13006 Any control register, when they're 24 bits wide.
13012 $r0, $r1, $r2, $r3.
13015 $r0 or $r2, or $r2r0 for 32 bit values.
13018 $r1 or $r3, or $r3r1 for 32 bit values.
13021 A register that can hold a 64 bit value.
13024 $r0 or $r1 (registers with addressable high/low bytes)
13033 Address registers when they're 16 bits wide.
13036 Address registers when they're 24 bits wide.
13039 Registers that can hold QI values.
13042 Registers that can be used with displacements ($a0, $a1, $sb).
13045 Registers that can hold 32 bit values.
13048 Registers that can hold 16 bit values.
13051 Registers chat can hold 16 bit values, including all control
13055 $r0 through R1, plus $a0 and $a1.
13058 The flags register.
13061 The memory-based pseudo-registers $mem0 through $mem15.
13064 Registers that can hold pointers (16 bit registers for r8c, m16c;
13065 24 bit registers for m32cm, m32c).
13068 Matches multiple registers in a PARALLEL to form a larger register.
13069 Used to match function return values.
13084 -8 ... -1 or 1 ... 8
13087 -16 ... -1 or 1 ... 16
13090 -8 ... -1 or 1 ... 8
13096 An 8 bit value with exactly one bit set.
13099 A 16 bit value with exactly one bit set.
13102 The common src/dest memory addressing modes.
13105 Memory addressed using $a0 or $a1.
13108 Memory addressed with immediate addresses.
13111 Memory addressed using the stack pointer ($sp).
13114 Memory addressed using the frame base register ($fb).
13117 Memory addressed using the small base register ($sb).
13125 General-purpose integer register
13128 Floating-point register (if available)
13137 `Hi' or `Lo' register
13140 General-purpose integer register
13143 Floating-point status register
13146 Signed 16-bit constant (for arithmetic instructions)
13152 Zero-extended 16-bit constant (for logic instructions)
13155 Constant with low 16 bits zero (can be loaded with `lui')
13158 32-bit constant which requires two instructions to load (a
13159 constant which is not `I', `K', or `L')
13162 Negative 16-bit constant
13168 Positive 16-bit constant
13171 Floating point zero
13174 Memory reference that can be loaded with more than one
13175 instruction (`m' is preferable for `asm' statements)
13178 Memory reference that can be loaded with one instruction (`m'
13179 is preferable for `asm' statements)
13182 Memory reference in external OSF/rose PIC format (`m' is
13183 preferable for `asm' statements)
13185 _Motorola 680x0--`m68k.h'_
13194 68881 floating-point register, if available
13197 Integer in the range 1 to 8
13200 16-bit signed number
13203 Signed number whose magnitude is greater than 0x80
13206 Integer in the range -8 to -1
13209 Signed number whose magnitude is greater than 0x100
13212 Floating point constant that is not a 68881 constant
13214 _Motorola 68HC11 & 68HC12 families--`m68hc11.h'_
13229 Temporary soft register _.tmp
13232 A soft register _.d1 to _.d31
13235 Stack pointer register
13244 Pseudo register `z' (replaced by `x' or `y' at the end)
13247 An address register: x, y or z
13250 An address register: x or y
13253 Register pair (x:d) to form a 32-bit value
13256 Constants in the range -65536 to 65535
13259 Constants whose 16-bit low part is zero
13262 Constant integer 1 or -1
13265 Constant integer 16
13268 Constants in the range -8 to 2
13274 Floating-point register on the SPARC-V8 architecture and
13275 lower floating-point register on the SPARC-V9 architecture.
13278 Floating-point register. It is equivalent to `f' on the
13279 SPARC-V8 architecture and contains both lower and upper
13280 floating-point registers on the SPARC-V9 architecture.
13283 Floating-point condition code register.
13286 Lower floating-point register. It is only valid on the
13287 SPARC-V9 architecture when the Visual Instruction Set is
13291 Floating-point register. It is only valid on the SPARC-V9
13292 architecture when the Visual Instruction Set is available.
13295 64-bit global or out register for the SPARC-V8+ architecture.
13298 Signed 13-bit constant
13304 32-bit constant with the low 12 bits clear (a constant that
13305 can be loaded with the `sethi' instruction)
13308 A constant in the range supported by `movcc' instructions
13311 A constant in the range supported by `movrcc' instructions
13314 Same as `K', except that it verifies that bits that are not
13315 in the lower 32-bit range are all zero. Must be used instead
13316 of `K' for modes wider than `SImode'
13322 Floating-point zero
13325 Signed 13-bit constant, sign-extended to 32 or 64 bits
13328 Floating-point constant whose integral representation can be
13329 moved into an integer register using a single sethi
13333 Floating-point constant whose integral representation can be
13334 moved into an integer register using a single mov instruction
13337 Floating-point constant whose integral representation can be
13338 moved into an integer register using a high/lo_sum
13339 instruction sequence
13342 Memory address aligned to an 8-byte boundary
13348 Memory address for `e' constraint registers
13354 _TMS320C3x/C4x--`c4x.h'_
13357 Auxiliary (address) register (ar0-ar7)
13360 Stack pointer register (sp)
13363 Standard (32-bit) precision integer register
13366 Extended (40-bit) precision register (r0-r11)
13369 Block count register (bk)
13372 Extended (40-bit) precision low register (r0-r7)
13375 Extended (40-bit) precision register (r0-r1)
13378 Extended (40-bit) precision register (r2-r3)
13381 Repeat count register (rc)
13384 Index register (ir0-ir1)
13387 Status (condition code) register (st)
13390 Data page register (dp)
13393 Floating-point zero
13396 Immediate 16-bit floating-point constant
13399 Signed 16-bit constant
13402 Signed 8-bit constant
13405 Signed 5-bit constant
13408 Unsigned 16-bit constant
13411 Unsigned 8-bit constant
13414 Ones complement of unsigned 16-bit constant
13417 High 16-bit constant (32-bit constant with 16 LSBs zero)
13420 Indirect memory reference with signed 8-bit or index register
13424 Indirect memory reference with unsigned 5-bit displacement
13427 Indirect memory reference with 1 bit or index register
13431 Direct memory reference
13437 _S/390 and zSeries--`s390.h'_
13440 Address register (general purpose register except r0)
13443 Condition code register
13446 Data register (arbitrary general purpose register)
13449 Floating-point register
13452 Unsigned 8-bit constant (0-255)
13455 Unsigned 12-bit constant (0-4095)
13458 Signed 16-bit constant (-32768-32767)
13461 Value appropriate as displacement.
13463 for short displacement
13465 `(-524288..524287)'
13466 for long displacement
13469 Constant integer with a value of 0x7fffffff.
13472 Multiple letter constraint followed by 4 parameter letters.
13474 number of the part counting from most to least
13481 mode of the containing operand
13484 value of the other parts (F--all bits set)
13485 The constraint matches if the specified part of a constant
13486 has a value different from it's other parts.
13489 Memory reference without index register and with short
13493 Memory reference with index register and short displacement.
13496 Memory reference without index register but with long
13500 Memory reference with index register and long displacement.
13503 Pointer with short displacement.
13506 Pointer with long displacement.
13509 Shift count operand.
13512 _Xstormy16--`stormy16.h'_
13527 Registers r0 through r7.
13530 Registers r0 and r1.
13533 The carry register.
13536 Registers r8 and r9.
13539 A constant between 0 and 3 inclusive.
13542 A constant that has exactly one bit set.
13545 A constant that has exactly one bit clear.
13548 A constant between 0 and 255 inclusive.
13551 A constant between -255 and 0 inclusive.
13554 A constant between -3 and 0 inclusive.
13557 A constant between 1 and 4 inclusive.
13560 A constant between -4 and -1 inclusive.
13563 A memory reference that is a stack push.
13566 A memory reference that is a stack pop.
13569 A memory reference that refers to a constant address of known
13573 The register indicated by Rx (not implemented yet).
13576 A constant that is not between 2 and 15 inclusive.
13582 _Xtensa--`xtensa.h'_
13585 General-purpose 32-bit register
13588 One-bit boolean register
13591 MAC16 40-bit accumulator register
13594 Signed 12-bit integer constant, for use in MOVI instructions
13597 Signed 8-bit integer constant, for use in ADDI instructions
13600 Integer constant valid for BccI instructions
13603 Unsigned constant valid for BccUI instructions
13608 File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc
13610 13.9 Standard Pattern Names For Generation
13611 ==========================================
13613 Here is a table of the instruction names that are meaningful in the RTL
13614 generation pass of the compiler. Giving one of these names to an
13615 instruction pattern tells the RTL generation pass that it can use the
13616 pattern to accomplish a certain task.
13619 Here M stands for a two-letter machine mode name, in lowercase.
13620 This instruction pattern moves data with that machine mode from
13621 operand 1 to operand 0. For example, `movsi' moves full-word data.
13623 If operand 0 is a `subreg' with mode M of a register whose own
13624 mode is wider than M, the effect of this instruction is to store
13625 the specified value in the part of the register that corresponds
13626 to mode M. Bits outside of M, but which are within the same
13627 target word as the `subreg' are undefined. Bits which are outside
13628 the target word are left unchanged.
13630 This class of patterns is special in several ways. First of all,
13631 each of these names up to and including full word size _must_ be
13632 defined, because there is no other way to copy a datum from one
13633 place to another. If there are patterns accepting operands in
13634 larger modes, `movM' must be defined for integer modes of those
13637 Second, these patterns are not used solely in the RTL generation
13638 pass. Even the reload pass can generate move insns to copy values
13639 from stack slots into temporary registers. When it does so, one
13640 of the operands is a hard register and the other is an operand
13641 that can need to be reloaded into a register.
13643 Therefore, when given such a pair of operands, the pattern must
13644 generate RTL which needs no reloading and needs no temporary
13645 registers--no registers other than the operands. For example, if
13646 you support the pattern with a `define_expand', then in such a
13647 case the `define_expand' mustn't call `force_reg' or any other such
13648 function which might generate new pseudo registers.
13650 This requirement exists even for subword modes on a RISC machine
13651 where fetching those modes from memory normally requires several
13652 insns and some temporary registers.
13654 During reload a memory reference with an invalid address may be
13655 passed as an operand. Such an address will be replaced with a
13656 valid address later in the reload pass. In this case, nothing may
13657 be done with the address except to use it as it stands. If it is
13658 copied, it will not be replaced with a valid address. No attempt
13659 should be made to make such an address into a valid address and no
13660 routine (such as `change_address') that will do so may be called.
13661 Note that `general_operand' will fail when applied to such an
13664 The global variable `reload_in_progress' (which must be explicitly
13665 declared if required) can be used to determine whether such special
13666 handling is required.
13668 The variety of operands that have reloads depends on the rest of
13669 the machine description, but typically on a RISC machine these can
13670 only be pseudo registers that did not get hard registers, while on
13671 other machines explicit memory references will get optional
13674 If a scratch register is required to move an object to or from
13675 memory, it can be allocated using `gen_reg_rtx' prior to life
13678 If there are cases which need scratch registers during or after
13679 reload, you must define `SECONDARY_INPUT_RELOAD_CLASS' and/or
13680 `SECONDARY_OUTPUT_RELOAD_CLASS' to detect them, and provide
13681 patterns `reload_inM' or `reload_outM' to handle them. *Note
13682 Register Classes::.
13684 The global variable `no_new_pseudos' can be used to determine if it
13685 is unsafe to create new pseudo registers. If this variable is
13686 nonzero, then it is unsafe to call `gen_reg_rtx' to allocate a new
13689 The constraints on a `movM' must permit moving any hard register
13690 to any other hard register provided that `HARD_REGNO_MODE_OK'
13691 permits mode M in both registers and `REGISTER_MOVE_COST' applied
13692 to their classes returns a value of 2.
13694 It is obligatory to support floating point `movM' instructions
13695 into and out of any registers that can hold fixed point values,
13696 because unions and structures (which have modes `SImode' or
13697 `DImode') can be in those registers and they may have floating
13700 There may also be a need to support fixed point `movM'
13701 instructions in and out of floating point registers.
13702 Unfortunately, I have forgotten why this was so, and I don't know
13703 whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed
13704 point values in floating point registers, then the constraints of
13705 the fixed point `movM' instructions must be designed to avoid ever
13706 trying to reload into a floating point register.
13710 Like `movM', but used when a scratch register is required to move
13711 between operand 0 and operand 1. Operand 2 describes the scratch
13712 register. See the discussion of the `SECONDARY_RELOAD_CLASS'
13713 macro in *note Register Classes::.
13715 There are special restrictions on the form of the `match_operand's
13716 used in these patterns. First, only the predicate for the reload
13717 operand is examined, i.e., `reload_in' examines operand 1, but not
13718 the predicates for operand 0 or 2. Second, there may be only one
13719 alternative in the constraints. Third, only a single register
13720 class letter may be used for the constraint; subsequent constraint
13721 letters are ignored. As a special exception, an empty constraint
13722 string matches the `ALL_REGS' register class. This may relieve
13723 ports of the burden of defining an `ALL_REGS' constraint letter
13724 just for these patterns.
13727 Like `movM' except that if operand 0 is a `subreg' with mode M of
13728 a register whose natural mode is wider, the `movstrictM'
13729 instruction is guaranteed not to alter any of the register except
13730 the part which belongs to mode M.
13733 This variant of a move pattern is designed to load or store a value
13734 from a memory address that is not naturally aligned for its mode.
13735 For a store, the memory will be in operand 0; for a load, the
13736 memory will be in operand 1. The other operand is guaranteed not
13737 to be a memory, so that it's easy to tell whether this is a load
13740 This pattern is used by the autovectorizer, and when expanding a
13741 `MISALIGNED_INDIRECT_REF' expression.
13744 Load several consecutive memory locations into consecutive
13745 registers. Operand 0 is the first of the consecutive registers,
13746 operand 1 is the first memory location, and operand 2 is a
13747 constant: the number of consecutive registers.
13749 Define this only if the target machine really has such an
13750 instruction; do not define this if the most efficient way of
13751 loading consecutive registers from memory is to do them one at a
13754 On some machines, there are restrictions as to which consecutive
13755 registers can be stored into memory, such as particular starting or
13756 ending register numbers or only a range of valid counts. For those
13757 machines, use a `define_expand' (*note Expander Definitions::) and
13758 make the pattern fail if the restrictions are not met.
13760 Write the generated insn as a `parallel' with elements being a
13761 `set' of one register from the appropriate memory location (you may
13762 also need `use' or `clobber' elements). Use a `match_parallel'
13763 (*note RTL Template::) to recognize the insn. See `rs6000.md' for
13764 examples of the use of this insn pattern.
13767 Similar to `load_multiple', but store several consecutive registers
13768 into consecutive memory locations. Operand 0 is the first of the
13769 consecutive memory locations, operand 1 is the first register, and
13770 operand 2 is a constant: the number of consecutive registers.
13773 Set given field in the vector value. Operand 0 is the vector to
13774 modify, operand 1 is new value of field and operand 2 specify the
13778 Extract given field from the vector value. Operand 1 is the
13779 vector, operand 2 specify field index and operand 0 place to store
13783 Initialize the vector to given values. Operand 0 is the vector to
13784 initialize and operand 1 is parallel containing values for
13788 Output a push instruction. Operand 0 is value to push. Used only
13789 when `PUSH_ROUNDING' is defined. For historical reason, this
13790 pattern may be missing and in such case an `mov' expander is used
13791 instead, with a `MEM' expression forming the push operation. The
13792 `mov' expander method is deprecated.
13795 Add operand 2 and operand 1, storing the result in operand 0. All
13796 operands must have mode M. This can be used even on two-address
13797 machines, by means of constraints requiring operands 1 and 0 to be
13804 `andM3', `iorM3', `xorM3'
13805 Similar, for other arithmetic operations.
13808 Signed minimum and maximum operations. When used with floating
13809 point, if both operands are zeros, or if either operand is `NaN',
13810 then it is unspecified which of the two operands is returned as
13813 `reduc_smin_M', `reduc_smax_M'
13814 Find the signed minimum/maximum of the elements of a vector. The
13815 vector is operand 1, and the scalar result is stored in the least
13816 significant bits of operand 0 (also a vector). The output and
13817 input vector should have the same modes.
13819 `reduc_umin_M', `reduc_umax_M'
13820 Find the unsigned minimum/maximum of the elements of a vector. The
13821 vector is operand 1, and the scalar result is stored in the least
13822 significant bits of operand 0 (also a vector). The output and
13823 input vector should have the same modes.
13826 Compute the sum of the signed elements of a vector. The vector is
13827 operand 1, and the scalar result is stored in the least
13828 significant bits of operand 0 (also a vector). The output and
13829 input vector should have the same modes.
13832 Compute the sum of the unsigned elements of a vector. The vector
13833 is operand 1, and the scalar result is stored in the least
13834 significant bits of operand 0 (also a vector). The output and
13835 input vector should have the same modes.
13837 `vec_shl_M', `vec_shr_M'
13838 Whole vector left/right shift in bits. Operand 1 is a vector to
13839 be shifted. Operand 2 is an integer shift amount in bits.
13840 Operand 0 is where the resulting shifted vector is stored. The
13841 output and input vectors should have the same modes.
13844 Multiply operands 1 and 2, which have mode `HImode', and store a
13845 `SImode' product in operand 0.
13847 `mulqihi3', `mulsidi3'
13848 Similar widening-multiplication instructions of other widths.
13850 `umulqihi3', `umulhisi3', `umulsidi3'
13851 Similar widening-multiplication instructions that do unsigned
13855 Perform a signed multiplication of operands 1 and 2, which have
13856 mode M, and store the most significant half of the product in
13857 operand 0. The least significant half of the product is discarded.
13860 Similar, but the multiplication is unsigned.
13863 Signed division that produces both a quotient and a remainder.
13864 Operand 1 is divided by operand 2 to produce a quotient stored in
13865 operand 0 and a remainder stored in operand 3.
13867 For machines with an instruction that produces both a quotient and
13868 a remainder, provide a pattern for `divmodM4' but do not provide
13869 patterns for `divM3' and `modM3'. This allows optimization in the
13870 relatively common case when both the quotient and remainder are
13873 If an instruction that just produces a quotient or just a remainder
13874 exists and is more efficient than the instruction that produces
13875 both, write the output routine of `divmodM4' to call
13876 `find_reg_note' and look for a `REG_UNUSED' note on the quotient
13877 or remainder and generate the appropriate instruction.
13880 Similar, but does unsigned division.
13883 Arithmetic-shift operand 1 left by a number of bits specified by
13884 operand 2, and store the result in operand 0. Here M is the mode
13885 of operand 0 and operand 1; operand 2's mode is specified by the
13886 instruction pattern, and the compiler will convert the operand to
13887 that mode before generating the instruction. The meaning of
13888 out-of-range shift counts can optionally be specified by
13889 `TARGET_SHIFT_TRUNCATION_MASK'. *Note
13890 TARGET_SHIFT_TRUNCATION_MASK::.
13892 `ashrM3', `lshrM3', `rotlM3', `rotrM3'
13893 Other shift and rotate instructions, analogous to the `ashlM3'
13897 Negate operand 1 and store the result in operand 0.
13900 Store the absolute value of operand 1 into operand 0.
13903 Store the square root of operand 1 into operand 0.
13905 The `sqrt' built-in function of C always uses the mode which
13906 corresponds to the C data type `double' and the `sqrtf' built-in
13907 function uses the mode which corresponds to the C data type
13911 Store the cosine of operand 1 into operand 0.
13913 The `cos' built-in function of C always uses the mode which
13914 corresponds to the C data type `double' and the `cosf' built-in
13915 function uses the mode which corresponds to the C data type
13919 Store the sine of operand 1 into operand 0.
13921 The `sin' built-in function of C always uses the mode which
13922 corresponds to the C data type `double' and the `sinf' built-in
13923 function uses the mode which corresponds to the C data type
13927 Store the exponential of operand 1 into operand 0.
13929 The `exp' built-in function of C always uses the mode which
13930 corresponds to the C data type `double' and the `expf' built-in
13931 function uses the mode which corresponds to the C data type
13935 Store the natural logarithm of operand 1 into operand 0.
13937 The `log' built-in function of C always uses the mode which
13938 corresponds to the C data type `double' and the `logf' built-in
13939 function uses the mode which corresponds to the C data type
13943 Store the value of operand 1 raised to the exponent operand 2 into
13946 The `pow' built-in function of C always uses the mode which
13947 corresponds to the C data type `double' and the `powf' built-in
13948 function uses the mode which corresponds to the C data type
13952 Store the arc tangent (inverse tangent) of operand 1 divided by
13953 operand 2 into operand 0, using the signs of both arguments to
13954 determine the quadrant of the result.
13956 The `atan2' built-in function of C always uses the mode which
13957 corresponds to the C data type `double' and the `atan2f' built-in
13958 function uses the mode which corresponds to the C data type
13962 Store the largest integral value not greater than argument.
13964 The `floor' built-in function of C always uses the mode which
13965 corresponds to the C data type `double' and the `floorf' built-in
13966 function uses the mode which corresponds to the C data type
13970 Store the argument rounded to integer towards zero.
13972 The `trunc' built-in function of C always uses the mode which
13973 corresponds to the C data type `double' and the `truncf' built-in
13974 function uses the mode which corresponds to the C data type
13978 Store the argument rounded to integer away from zero.
13980 The `round' built-in function of C always uses the mode which
13981 corresponds to the C data type `double' and the `roundf' built-in
13982 function uses the mode which corresponds to the C data type
13986 Store the argument rounded to integer away from zero.
13988 The `ceil' built-in function of C always uses the mode which
13989 corresponds to the C data type `double' and the `ceilf' built-in
13990 function uses the mode which corresponds to the C data type
13994 Store the argument rounded according to the default rounding mode
13996 The `nearbyint' built-in function of C always uses the mode which
13997 corresponds to the C data type `double' and the `nearbyintf'
13998 built-in function uses the mode which corresponds to the C data
14002 Store the argument rounded according to the default rounding mode
14003 and raise the inexact exception when the result differs in value
14006 The `rint' built-in function of C always uses the mode which
14007 corresponds to the C data type `double' and the `rintf' built-in
14008 function uses the mode which corresponds to the C data type
14012 Store a value with the magnitude of operand 1 and the sign of
14013 operand 2 into operand 0.
14015 The `copysign' built-in function of C always uses the mode which
14016 corresponds to the C data type `double' and the `copysignf'
14017 built-in function uses the mode which corresponds to the C data
14021 Store into operand 0 one plus the index of the least significant
14022 1-bit of operand 1. If operand 1 is zero, store zero. M is the
14023 mode of operand 0; operand 1's mode is specified by the instruction
14024 pattern, and the compiler will convert the operand to that mode
14025 before generating the instruction.
14027 The `ffs' built-in function of C always uses the mode which
14028 corresponds to the C data type `int'.
14031 Store into operand 0 the number of leading 0-bits in X, starting
14032 at the most significant bit position. If X is 0, the result is
14033 undefined. M is the mode of operand 0; operand 1's mode is
14034 specified by the instruction pattern, and the compiler will
14035 convert the operand to that mode before generating the instruction.
14038 Store into operand 0 the number of trailing 0-bits in X, starting
14039 at the least significant bit position. If X is 0, the result is
14040 undefined. M is the mode of operand 0; operand 1's mode is
14041 specified by the instruction pattern, and the compiler will
14042 convert the operand to that mode before generating the instruction.
14045 Store into operand 0 the number of 1-bits in X. M is the mode of
14046 operand 0; operand 1's mode is specified by the instruction
14047 pattern, and the compiler will convert the operand to that mode
14048 before generating the instruction.
14051 Store into operand 0 the parity of X, i.e. the number of 1-bits in
14052 X modulo 2. M is the mode of operand 0; operand 1's mode is
14053 specified by the instruction pattern, and the compiler will convert
14054 the operand to that mode before generating the instruction.
14057 Store the bitwise-complement of operand 1 into operand 0.
14060 Compare operand 0 and operand 1, and set the condition codes. The
14061 RTL pattern should look like this:
14063 (set (cc0) (compare (match_operand:M 0 ...)
14064 (match_operand:M 1 ...)))
14067 Compare operand 0 against zero, and set the condition codes. The
14068 RTL pattern should look like this:
14070 (set (cc0) (match_operand:M 0 ...))
14072 `tstM' patterns should not be defined for machines that do not use
14073 `(cc0)'. Doing so would confuse the optimizer since it would no
14074 longer be clear which `set' operations were comparisons. The
14075 `cmpM' patterns should be used instead.
14078 Block move instruction. The destination and source blocks of
14079 memory are the first two operands, and both are `mem:BLK's with an
14080 address in mode `Pmode'.
14082 The number of bytes to move is the third operand, in mode M.
14083 Usually, you specify `word_mode' for M. However, if you can
14084 generate better code knowing the range of valid lengths is smaller
14085 than those representable in a full word, you should provide a
14086 pattern with a mode corresponding to the range of values you can
14087 handle efficiently (e.g., `QImode' for values in the range 0-127;
14088 note we avoid numbers that appear negative) and also a pattern
14091 The fourth operand is the known shared alignment of the source and
14092 destination, in the form of a `const_int' rtx. Thus, if the
14093 compiler knows that both source and destination are word-aligned,
14094 it may provide the value 4 for this operand.
14096 Descriptions of multiple `movmemM' patterns can only be beneficial
14097 if the patterns for smaller modes have fewer restrictions on their
14098 first, second and fourth operands. Note that the mode M in
14099 `movmemM' does not impose any restriction on the mode of
14100 individually moved data units in the block.
14102 These patterns need not give special consideration to the
14103 possibility that the source and destination strings might overlap.
14106 String copy instruction, with `stpcpy' semantics. Operand 0 is an
14107 output operand in mode `Pmode'. The addresses of the destination
14108 and source strings are operands 1 and 2, and both are `mem:BLK's
14109 with addresses in mode `Pmode'. The execution of the expansion of
14110 this pattern should store in operand 0 the address in which the
14111 `NUL' terminator was stored in the destination string.
14114 Block set instruction. The destination string is the first
14115 operand, given as a `mem:BLK' whose address is in mode `Pmode'.
14116 The number of bytes to set is the second operand, in mode M. The
14117 value to initialize the memory with is the third operand. Targets
14118 that only support the clearing of memory should reject any value
14119 that is not the constant 0. See `movmemM' for a discussion of the
14122 The fourth operand is the known alignment of the destination, in
14123 the form of a `const_int' rtx. Thus, if the compiler knows that
14124 the destination is word-aligned, it may provide the value 4 for
14127 The use for multiple `setmemM' is as for `movmemM'.
14130 String compare instruction, with five operands. Operand 0 is the
14131 output; it has mode M. The remaining four operands are like the
14132 operands of `movmemM'. The two memory blocks specified are
14133 compared byte by byte in lexicographic order starting at the
14134 beginning of each string. The instruction is not allowed to
14135 prefetch more than one byte at a time since either string may end
14136 in the first byte and reading past that may access an invalid page
14137 or segment and cause a fault. The effect of the instruction is to
14138 store a value in operand 0 whose sign indicates the result of the
14142 String compare instruction, without known maximum length. Operand
14143 0 is the output; it has mode M. The second and third operand are
14144 the blocks of memory to be compared; both are `mem:BLK' with an
14145 address in mode `Pmode'.
14147 The fourth operand is the known shared alignment of the source and
14148 destination, in the form of a `const_int' rtx. Thus, if the
14149 compiler knows that both source and destination are word-aligned,
14150 it may provide the value 4 for this operand.
14152 The two memory blocks specified are compared byte by byte in
14153 lexicographic order starting at the beginning of each string. The
14154 instruction is not allowed to prefetch more than one byte at a
14155 time since either string may end in the first byte and reading
14156 past that may access an invalid page or segment and cause a fault.
14157 The effect of the instruction is to store a value in operand 0
14158 whose sign indicates the result of the comparison.
14161 Block compare instruction, with five operands like the operands of
14162 `cmpstrM'. The two memory blocks specified are compared byte by
14163 byte in lexicographic order starting at the beginning of each
14164 block. Unlike `cmpstrM' the instruction can prefetch any bytes in
14165 the two memory blocks. The effect of the instruction is to store
14166 a value in operand 0 whose sign indicates the result of the
14170 Compute the length of a string, with three operands. Operand 0 is
14171 the result (of mode M), operand 1 is a `mem' referring to the
14172 first character of the string, operand 2 is the character to
14173 search for (normally zero), and operand 3 is a constant describing
14174 the known alignment of the beginning of the string.
14177 Convert signed integer operand 1 (valid for fixed point mode M) to
14178 floating point mode N and store in operand 0 (which has mode N).
14181 Convert unsigned integer operand 1 (valid for fixed point mode M)
14182 to floating point mode N and store in operand 0 (which has mode N).
14185 Convert operand 1 (valid for floating point mode M) to fixed point
14186 mode N as a signed number and store in operand 0 (which has mode
14187 N). This instruction's result is defined only when the value of
14188 operand 1 is an integer.
14190 If the machine description defines this pattern, it also needs to
14191 define the `ftrunc' pattern.
14194 Convert operand 1 (valid for floating point mode M) to fixed point
14195 mode N as an unsigned number and store in operand 0 (which has
14196 mode N). This instruction's result is defined only when the value
14197 of operand 1 is an integer.
14200 Convert operand 1 (valid for floating point mode M) to an integer
14201 value, still represented in floating point mode M, and store it in
14202 operand 0 (valid for floating point mode M).
14205 Like `fixMN2' but works for any floating point value of mode M by
14206 converting the value to an integer.
14209 Like `fixunsMN2' but works for any floating point value of mode M
14210 by converting the value to an integer.
14213 Truncate operand 1 (valid for mode M) to mode N and store in
14214 operand 0 (which has mode N). Both modes must be fixed point or
14215 both floating point.
14218 Sign-extend operand 1 (valid for mode M) to mode N and store in
14219 operand 0 (which has mode N). Both modes must be fixed point or
14220 both floating point.
14223 Zero-extend operand 1 (valid for mode M) to mode N and store in
14224 operand 0 (which has mode N). Both modes must be fixed point.
14227 Extract a bit-field from operand 1 (a register or memory operand),
14228 where operand 2 specifies the width in bits and operand 3 the
14229 starting bit, and store it in operand 0. Operand 0 must have mode
14230 `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode';
14231 often `word_mode' is allowed only for registers. Operands 2 and 3
14232 must be valid for `word_mode'.
14234 The RTL generation pass generates this instruction only with
14235 constants for operands 2 and 3 and the constant is never zero for
14238 The bit-field value is sign-extended to a full word integer before
14239 it is stored in operand 0.
14242 Like `extv' except that the bit-field value is zero-extended.
14245 Store operand 3 (which must be valid for `word_mode') into a
14246 bit-field in operand 0, where operand 1 specifies the width in
14247 bits and operand 2 the starting bit. Operand 0 may have mode
14248 `byte_mode' or `word_mode'; often `word_mode' is allowed only for
14249 registers. Operands 1 and 2 must be valid for `word_mode'.
14251 The RTL generation pass generates this instruction only with
14252 constants for operands 1 and 2 and the constant is never zero for
14256 Conditionally move operand 2 or operand 3 into operand 0 according
14257 to the comparison in operand 1. If the comparison is true,
14258 operand 2 is moved into operand 0, otherwise operand 3 is moved.
14260 The mode of the operands being compared need not be the same as
14261 the operands being moved. Some machines, sparc64 for example,
14262 have instructions that conditionally move an integer value based
14263 on the floating point condition codes and vice versa.
14265 If the machine does not have conditional move instructions, do not
14266 define these patterns.
14269 Similar to `movMODEcc' but for conditional addition. Conditionally
14270 move operand 2 or (operands 2 + operand 3) into operand 0
14271 according to the comparison in operand 1. If the comparison is
14272 true, operand 2 is moved into operand 0, otherwise (operand 2 +
14273 operand 3) is moved.
14276 Store zero or nonzero in the operand according to the condition
14277 codes. Value stored is nonzero iff the condition COND is true.
14278 COND is the name of a comparison operation expression code, such
14279 as `eq', `lt' or `leu'.
14281 You specify the mode that the operand must have when you write the
14282 `match_operand' expression. The compiler automatically sees which
14283 mode you have used and supplies an operand of that mode.
14285 The value stored for a true condition must have 1 as its low bit,
14286 or else must be negative. Otherwise the instruction is not
14287 suitable and you should omit it from the machine description. You
14288 describe to the compiler exactly which value is stored by defining
14289 the macro `STORE_FLAG_VALUE' (*note Misc::). If a description
14290 cannot be found that can be used for all the `sCOND' patterns, you
14291 should omit those operations from the machine description.
14293 These operations may fail, but should do so only in relatively
14294 uncommon cases; if they would fail for common cases involving
14295 integer comparisons, it is best to omit these patterns.
14297 If these operations are omitted, the compiler will usually
14298 generate code that copies the constant one to the target and
14299 branches around an assignment of zero to the target. If this code
14300 is more efficient than the potential instructions used for the
14301 `sCOND' pattern followed by those required to convert the result
14302 into a 1 or a zero in `SImode', you should omit the `sCOND'
14303 operations from the machine description.
14306 Conditional branch instruction. Operand 0 is a `label_ref' that
14307 refers to the label to jump to. Jump if the condition codes meet
14310 Some machines do not follow the model assumed here where a
14311 comparison instruction is followed by a conditional branch
14312 instruction. In that case, the `cmpM' (and `tstM') patterns should
14313 simply store the operands away and generate all the required insns
14314 in a `define_expand' (*note Expander Definitions::) for the
14315 conditional branch operations. All calls to expand `bCOND'
14316 patterns are immediately preceded by calls to expand either a
14317 `cmpM' pattern or a `tstM' pattern.
14319 Machines that use a pseudo register for the condition code value,
14320 or where the mode used for the comparison depends on the condition
14321 being tested, should also use the above mechanism. *Note Jump
14324 The above discussion also applies to the `movMODEcc' and `sCOND'
14328 Conditional branch instruction combined with a compare instruction.
14329 Operand 0 is a comparison operator. Operand 1 and operand 2 are
14330 the first and second operands of the comparison, respectively.
14331 Operand 3 is a `label_ref' that refers to the label to jump to.
14334 A jump inside a function; an unconditional branch. Operand 0 is
14335 the `label_ref' of the label to jump to. This pattern name is
14336 mandatory on all machines.
14339 Subroutine call instruction returning no value. Operand 0 is the
14340 function to call; operand 1 is the number of bytes of arguments
14341 pushed as a `const_int'; operand 2 is the number of registers used
14344 On most machines, operand 2 is not actually stored into the RTL
14345 pattern. It is supplied for the sake of some RISC machines which
14346 need to put this information into the assembler code; they can put
14347 it in the RTL instead of operand 1.
14349 Operand 0 should be a `mem' RTX whose address is the address of the
14350 function. Note, however, that this address can be a `symbol_ref'
14351 expression even if it would not be a legitimate memory address on
14352 the target machine. If it is also not a valid argument for a call
14353 instruction, the pattern for this operation should be a
14354 `define_expand' (*note Expander Definitions::) that places the
14355 address into a register and uses that register in the call
14359 Subroutine call instruction returning a value. Operand 0 is the
14360 hard register in which the value is returned. There are three more
14361 operands, the same as the three operands of the `call' instruction
14362 (but with numbers increased by one).
14364 Subroutines that return `BLKmode' objects use the `call' insn.
14366 `call_pop', `call_value_pop'
14367 Similar to `call' and `call_value', except used if defined and if
14368 `RETURN_POPS_ARGS' is nonzero. They should emit a `parallel' that
14369 contains both the function call and a `set' to indicate the
14370 adjustment made to the frame pointer.
14372 For machines where `RETURN_POPS_ARGS' can be nonzero, the use of
14373 these patterns increases the number of functions for which the
14374 frame pointer can be eliminated, if desired.
14377 Subroutine call instruction returning a value of any type.
14378 Operand 0 is the function to call; operand 1 is a memory location
14379 where the result of calling the function is to be stored; operand
14380 2 is a `parallel' expression where each element is a `set'
14381 expression that indicates the saving of a function return value
14382 into the result block.
14384 This instruction pattern should be defined to support
14385 `__builtin_apply' on machines where special instructions are needed
14386 to call a subroutine with arbitrary arguments or to save the value
14387 returned. This instruction pattern is required on machines that
14388 have multiple registers that can hold a return value (i.e.
14389 `FUNCTION_VALUE_REGNO_P' is true for more than one register).
14392 Subroutine return instruction. This instruction pattern name
14393 should be defined only if a single instruction can do all the work
14394 of returning from a function.
14396 Like the `movM' patterns, this pattern is also used after the RTL
14397 generation phase. In this case it is to support machines where
14398 multiple instructions are usually needed to return from a
14399 function, but some class of functions only requires one
14400 instruction to implement a return. Normally, the applicable
14401 functions are those which do not need to save any registers or
14402 allocate stack space.
14404 For such machines, the condition specified in this pattern should
14405 only be true when `reload_completed' is nonzero and the function's
14406 epilogue would only be a single instruction. For machines with
14407 register windows, the routine `leaf_function_p' may be used to
14408 determine if a register window push is required.
14410 Machines that have conditional return instructions should define
14415 (if_then_else (match_operator
14416 0 "comparison_operator"
14417 [(cc0) (const_int 0)])
14423 where CONDITION would normally be the same condition specified on
14424 the named `return' pattern.
14427 Untyped subroutine return instruction. This instruction pattern
14428 should be defined to support `__builtin_return' on machines where
14429 special instructions are needed to return a value of any type.
14431 Operand 0 is a memory location where the result of calling a
14432 function with `__builtin_apply' is stored; operand 1 is a
14433 `parallel' expression where each element is a `set' expression
14434 that indicates the restoring of a function return value from the
14438 No-op instruction. This instruction pattern name should always be
14439 defined to output a no-op in assembler code. `(const_int 0)' will
14440 do as an RTL pattern.
14443 An instruction to jump to an address which is operand zero. This
14444 pattern name is mandatory on all machines.
14447 Instruction to jump through a dispatch table, including bounds
14448 checking. This instruction takes five operands:
14450 1. The index to dispatch on, which has mode `SImode'.
14452 2. The lower bound for indices in the table, an integer constant.
14454 3. The total range of indices in the table--the largest index
14455 minus the smallest one (both inclusive).
14457 4. A label that precedes the table itself.
14459 5. A label to jump to if the index has a value outside the
14462 The table is a `addr_vec' or `addr_diff_vec' inside of a
14463 `jump_insn'. The number of elements in the table is one plus the
14464 difference between the upper bound and the lower bound.
14467 Instruction to jump to a variable address. This is a low-level
14468 capability which can be used to implement a dispatch table when
14469 there is no `casesi' pattern.
14471 This pattern requires two operands: the address or offset, and a
14472 label which should immediately precede the jump table. If the
14473 macro `CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then
14474 the first operand is an offset which counts from the address of
14475 the table; otherwise, it is an absolute address to jump to. In
14476 either case, the first operand has mode `Pmode'.
14478 The `tablejump' insn is always the last insn before the jump table
14479 it uses. Its assembler code normally has no need to use the
14480 second operand, but you should incorporate it in the RTL pattern so
14481 that the jump optimizer will not delete the table as unreachable
14484 `decrement_and_branch_until_zero'
14485 Conditional branch instruction that decrements a register and
14486 jumps if the register is nonzero. Operand 0 is the register to
14487 decrement and test; operand 1 is the label to jump to if the
14488 register is nonzero. *Note Looping Patterns::.
14490 This optional instruction pattern is only used by the combiner,
14491 typically for loops reversed by the loop optimizer when strength
14492 reduction is enabled.
14495 Conditional branch instruction that decrements a register and
14496 jumps if the register is nonzero. This instruction takes five
14497 operands: Operand 0 is the register to decrement and test; operand
14498 1 is the number of loop iterations as a `const_int' or
14499 `const0_rtx' if this cannot be determined until run-time; operand
14500 2 is the actual or estimated maximum number of iterations as a
14501 `const_int'; operand 3 is the number of enclosed loops as a
14502 `const_int' (an innermost loop has a value of 1); operand 4 is the
14503 label to jump to if the register is nonzero. *Note Looping
14506 This optional instruction pattern should be defined for machines
14507 with low-overhead looping instructions as the loop optimizer will
14508 try to modify suitable loops to utilize it. If nested
14509 low-overhead looping is not supported, use a `define_expand'
14510 (*note Expander Definitions::) and make the pattern fail if
14511 operand 3 is not `const1_rtx'. Similarly, if the actual or
14512 estimated maximum number of iterations is too large for this
14513 instruction, make it fail.
14516 Companion instruction to `doloop_end' required for machines that
14517 need to perform some initialization, such as loading special
14518 registers used by a low-overhead looping instruction. If
14519 initialization insns do not always need to be emitted, use a
14520 `define_expand' (*note Expander Definitions::) and make it fail.
14522 `canonicalize_funcptr_for_compare'
14523 Canonicalize the function pointer in operand 1 and store the result
14526 Operand 0 is always a `reg' and has mode `Pmode'; operand 1 may be
14527 a `reg', `mem', `symbol_ref', `const_int', etc and also has mode
14530 Canonicalization of a function pointer usually involves computing
14531 the address of the function which would be called if the function
14532 pointer were used in an indirect call.
14534 Only define this pattern if function pointers on the target machine
14535 can have different values but still call the same function when
14536 used in an indirect call.
14539 `save_stack_function'
14540 `save_stack_nonlocal'
14541 `restore_stack_block'
14542 `restore_stack_function'
14543 `restore_stack_nonlocal'
14544 Most machines save and restore the stack pointer by copying it to
14545 or from an object of mode `Pmode'. Do not define these patterns on
14548 Some machines require special handling for stack pointer saves and
14549 restores. On those machines, define the patterns corresponding to
14550 the non-standard cases by using a `define_expand' (*note Expander
14551 Definitions::) that produces the required insns. The three types
14552 of saves and restores are:
14554 1. `save_stack_block' saves the stack pointer at the start of a
14555 block that allocates a variable-sized object, and
14556 `restore_stack_block' restores the stack pointer when the
14559 2. `save_stack_function' and `restore_stack_function' do a
14560 similar job for the outermost block of a function and are
14561 used when the function allocates variable-sized objects or
14562 calls `alloca'. Only the epilogue uses the restored stack
14563 pointer, allowing a simpler save or restore sequence on some
14566 3. `save_stack_nonlocal' is used in functions that contain labels
14567 branched to by nested functions. It saves the stack pointer
14568 in such a way that the inner function can use
14569 `restore_stack_nonlocal' to restore the stack pointer. The
14570 compiler generates code to restore the frame and argument
14571 pointer registers, but some machines require saving and
14572 restoring additional data such as register window information
14573 or stack backchains. Place insns in these patterns to save
14574 and restore any such required data.
14576 When saving the stack pointer, operand 0 is the save area and
14577 operand 1 is the stack pointer. The mode used to allocate the
14578 save area defaults to `Pmode' but you can override that choice by
14579 defining the `STACK_SAVEAREA_MODE' macro (*note Storage Layout::).
14580 You must specify an integral mode, or `VOIDmode' if no save area
14581 is needed for a particular type of save (either because no save is
14582 needed or because a machine-specific save area can be used).
14583 Operand 0 is the stack pointer and operand 1 is the save area for
14584 restore operations. If `save_stack_block' is defined, operand 0
14585 must not be `VOIDmode' since these saves can be arbitrarily nested.
14587 A save area is a `mem' that is at a constant offset from
14588 `virtual_stack_vars_rtx' when the stack pointer is saved for use by
14589 nonlocal gotos and a `reg' in the other two cases.
14592 Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 1
14593 from the stack pointer to create space for dynamically allocated
14596 Store the resultant pointer to this space into operand 0. If you
14597 are allocating space from the main stack, do this by emitting a
14598 move insn to copy `virtual_stack_dynamic_rtx' to operand 0. If
14599 you are allocating the space elsewhere, generate code to copy the
14600 location of the space to operand 0. In the latter case, you must
14601 ensure this space gets freed when the corresponding space on the
14602 main stack is free.
14604 Do not define this pattern if all that must be done is the
14605 subtraction. Some machines require other operations such as stack
14606 probes or maintaining the back chain. Define this pattern to emit
14607 those operations in addition to updating the stack pointer.
14610 If stack checking cannot be done on your system by probing the
14611 stack with a load or store instruction (*note Stack Checking::),
14612 define this pattern to perform the needed check and signaling an
14613 error if the stack has overflowed. The single operand is the
14614 location in the stack furthest from the current stack pointer that
14615 you need to validate. Normally, on machines where this pattern is
14616 needed, you would obtain the stack limit from a global or
14617 thread-specific variable or register.
14620 Emit code to generate a non-local goto, e.g., a jump from one
14621 function to a label in an outer function. This pattern has four
14622 arguments, each representing a value to be used in the jump. The
14623 first argument is to be loaded into the frame pointer, the second
14624 is the address to branch to (code to dispatch to the actual label),
14625 the third is the address of a location where the stack is saved,
14626 and the last is the address of the label, to be placed in the
14627 location for the incoming static chain.
14629 On most machines you need not define this pattern, since GCC will
14630 already generate the correct code, which is to load the frame
14631 pointer and static chain, restore the stack (using the
14632 `restore_stack_nonlocal' pattern, if defined), and jump indirectly
14633 to the dispatcher. You need only define this pattern if this code
14634 will not work on your machine.
14636 `nonlocal_goto_receiver'
14637 This pattern, if defined, contains code needed at the target of a
14638 nonlocal goto after the code already generated by GCC. You will
14639 not normally need to define this pattern. A typical reason why
14640 you might need this pattern is if some value, such as a pointer to
14641 a global table, must be restored when the frame pointer is
14642 restored. Note that a nonlocal goto only occurs within a
14643 unit-of-translation, so a global table pointer that is shared by
14644 all functions of a given module need not be restored. There are
14647 `exception_receiver'
14648 This pattern, if defined, contains code needed at the site of an
14649 exception handler that isn't needed at the site of a nonlocal
14650 goto. You will not normally need to define this pattern. A
14651 typical reason why you might need this pattern is if some value,
14652 such as a pointer to a global table, must be restored after
14653 control flow is branched to the handler of an exception. There
14656 `builtin_setjmp_setup'
14657 This pattern, if defined, contains additional code needed to
14658 initialize the `jmp_buf'. You will not normally need to define
14659 this pattern. A typical reason why you might need this pattern is
14660 if some value, such as a pointer to a global table, must be
14661 restored. Though it is preferred that the pointer value be
14662 recalculated if possible (given the address of a label for
14663 instance). The single argument is a pointer to the `jmp_buf'.
14664 Note that the buffer is five words long and that the first three
14665 are normally used by the generic mechanism.
14667 `builtin_setjmp_receiver'
14668 This pattern, if defined, contains code needed at the site of an
14669 built-in setjmp that isn't needed at the site of a nonlocal goto.
14670 You will not normally need to define this pattern. A typical
14671 reason why you might need this pattern is if some value, such as a
14672 pointer to a global table, must be restored. It takes one
14673 argument, which is the label to which builtin_longjmp transfered
14674 control; this pattern may be emitted at a small offset from that
14678 This pattern, if defined, performs the entire action of the
14679 longjmp. You will not normally need to define this pattern unless
14680 you also define `builtin_setjmp_setup'. The single argument is a
14681 pointer to the `jmp_buf'.
14684 This pattern, if defined, affects the way `__builtin_eh_return',
14685 and thence the call frame exception handling library routines, are
14686 built. It is intended to handle non-trivial actions needed along
14687 the abnormal return path.
14689 The address of the exception handler to which the function should
14690 return is passed as operand to this pattern. It will normally
14691 need to copied by the pattern to some special register or memory
14692 location. If the pattern needs to determine the location of the
14693 target call frame in order to do so, it may use
14694 `EH_RETURN_STACKADJ_RTX', if defined; it will have already been
14697 If this pattern is not defined, the default action will be to
14698 simply copy the return address to `EH_RETURN_HANDLER_RTX'. Either
14699 that macro or this pattern needs to be defined if call frame
14700 exception handling is to be used.
14703 This pattern, if defined, emits RTL for entry to a function. The
14704 function entry is responsible for setting up the stack frame,
14705 initializing the frame pointer register, saving callee saved
14708 Using a prologue pattern is generally preferred over defining
14709 `TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the
14712 The `prologue' pattern is particularly useful for targets which
14713 perform instruction scheduling.
14716 This pattern emits RTL for exit from a function. The function
14717 exit is responsible for deallocating the stack frame, restoring
14718 callee saved registers and emitting the return instruction.
14720 Using an epilogue pattern is generally preferred over defining
14721 `TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the
14724 The `epilogue' pattern is particularly useful for targets which
14725 perform instruction scheduling or which have delay slots for their
14726 return instruction.
14729 This pattern, if defined, emits RTL for exit from a function
14730 without the final branch back to the calling function. This
14731 pattern will be emitted before any sibling call (aka tail call)
14734 The `sibcall_epilogue' pattern must not clobber any arguments used
14735 for parameter passing or any stack slots for arguments passed to
14736 the current function.
14739 This pattern, if defined, signals an error, typically by causing
14740 some kind of signal to be raised. Among other places, it is used
14741 by the Java front end to signal `invalid array index' exceptions.
14744 Conditional trap instruction. Operand 0 is a piece of RTL which
14745 performs a comparison. Operand 1 is the trap code, an integer.
14747 A typical `conditional_trap' pattern looks like
14749 (define_insn "conditional_trap"
14750 [(trap_if (match_operator 0 "trap_operator"
14751 [(cc0) (const_int 0)])
14752 (match_operand 1 "const_int_operand" "i"))]
14757 This pattern, if defined, emits code for a non-faulting data
14758 prefetch instruction. Operand 0 is the address of the memory to
14759 prefetch. Operand 1 is a constant 1 if the prefetch is preparing
14760 for a write to the memory address, or a constant 0 otherwise.
14761 Operand 2 is the expected degree of temporal locality of the data
14762 and is a value between 0 and 3, inclusive; 0 means that the data
14763 has no temporal locality, so it need not be left in the cache
14764 after the access; 3 means that the data has a high degree of
14765 temporal locality and should be left in all levels of cache
14766 possible; 1 and 2 mean, respectively, a low or moderate degree of
14769 Targets that do not support write prefetches or locality hints can
14770 ignore the values of operands 1 and 2.
14773 If the target memory model is not fully synchronous, then this
14774 pattern should be defined to an instruction that orders both loads
14775 and stores before the instruction with respect to loads and stores
14776 after the instruction. This pattern has no operands.
14778 `sync_compare_and_swapMODE'
14779 This pattern, if defined, emits code for an atomic compare-and-swap
14780 operation. Operand 1 is the memory on which the atomic operation
14781 is performed. Operand 2 is the "old" value to be compared against
14782 the current contents of the memory location. Operand 3 is the
14783 "new" value to store in the memory if the compare succeeds.
14784 Operand 0 is the result of the operation; it should contain the
14785 contents of the memory before the operation. If the compare
14786 succeeds, this should obviously be a copy of operand 2.
14788 This pattern must show that both operand 0 and operand 1 are
14791 This pattern must issue any memory barrier instructions such that
14792 all memory operations before the atomic operation occur before the
14793 atomic operation and all memory operations after the atomic
14794 operation occur after the atomic operation.
14796 `sync_compare_and_swap_ccMODE'
14797 This pattern is just like `sync_compare_and_swapMODE', except it
14798 should act as if compare part of the compare-and-swap were issued
14799 via `cmpM'. This comparison will only be used with `EQ' and `NE'
14800 branches and `setcc' operations.
14802 Some targets do expose the success or failure of the
14803 compare-and-swap operation via the status flags. Ideally we
14804 wouldn't need a separate named pattern in order to take advantage
14805 of this, but the combine pass does not handle patterns with
14806 multiple sets, which is required by definition for
14807 `sync_compare_and_swapMODE'.
14809 `sync_addMODE', `sync_subMODE'
14810 `sync_iorMODE', `sync_andMODE'
14811 `sync_xorMODE', `sync_nandMODE'
14812 These patterns emit code for an atomic operation on memory.
14813 Operand 0 is the memory on which the atomic operation is performed.
14814 Operand 1 is the second operand to the binary operator.
14816 The "nand" operation is `~op0 & op1'.
14818 This pattern must issue any memory barrier instructions such that
14819 all memory operations before the atomic operation occur before the
14820 atomic operation and all memory operations after the atomic
14821 operation occur after the atomic operation.
14823 If these patterns are not defined, the operation will be
14824 constructed from a compare-and-swap operation, if defined.
14826 `sync_old_addMODE', `sync_old_subMODE'
14827 `sync_old_iorMODE', `sync_old_andMODE'
14828 `sync_old_xorMODE', `sync_old_nandMODE'
14829 These patterns are emit code for an atomic operation on memory,
14830 and return the value that the memory contained before the
14831 operation. Operand 0 is the result value, operand 1 is the memory
14832 on which the atomic operation is performed, and operand 2 is the
14833 second operand to the binary operator.
14835 This pattern must issue any memory barrier instructions such that
14836 all memory operations before the atomic operation occur before the
14837 atomic operation and all memory operations after the atomic
14838 operation occur after the atomic operation.
14840 If these patterns are not defined, the operation will be
14841 constructed from a compare-and-swap operation, if defined.
14843 `sync_new_addMODE', `sync_new_subMODE'
14844 `sync_new_iorMODE', `sync_new_andMODE'
14845 `sync_new_xorMODE', `sync_new_nandMODE'
14846 These patterns are like their `sync_old_OP' counterparts, except
14847 that they return the value that exists in the memory location
14848 after the operation, rather than before the operation.
14850 `sync_lock_test_and_setMODE'
14851 This pattern takes two forms, based on the capabilities of the
14852 target. In either case, operand 0 is the result of the operand,
14853 operand 1 is the memory on which the atomic operation is
14854 performed, and operand 2 is the value to set in the lock.
14856 In the ideal case, this operation is an atomic exchange operation,
14857 in which the previous value in memory operand is copied into the
14858 result operand, and the value operand is stored in the memory
14861 For less capable targets, any value operand that is not the
14862 constant 1 should be rejected with `FAIL'. In this case the
14863 target may use an atomic test-and-set bit operation. The result
14864 operand should contain 1 if the bit was previously set and 0 if
14865 the bit was previously clear. The true contents of the memory
14866 operand are implementation defined.
14868 This pattern must issue any memory barrier instructions such that
14869 the pattern as a whole acts as an acquire barrier, that is all
14870 memory operations after the pattern do not occur until the lock is
14873 If this pattern is not defined, the operation will be constructed
14874 from a compare-and-swap operation, if defined.
14876 `sync_lock_releaseMODE'
14877 This pattern, if defined, releases a lock set by
14878 `sync_lock_test_and_setMODE'. Operand 0 is the memory that
14879 contains the lock; operand 1 is the value to store in the lock.
14881 If the target doesn't implement full semantics for
14882 `sync_lock_test_and_setMODE', any value operand which is not the
14883 constant 0 should be rejected with `FAIL', and the true contents
14884 of the memory operand are implementation defined.
14886 This pattern must issue any memory barrier instructions such that
14887 the pattern as a whole acts as a release barrier, that is the lock
14888 is released only after all previous memory operations have
14891 If this pattern is not defined, then a `memory_barrier' pattern
14892 will be emitted, followed by a store of the value to the memory
14895 `stack_protect_set'
14896 This pattern, if defined, moves a `Pmode' value from the memory in
14897 operand 1 to the memory in operand 0 without leaving the value in
14898 a register afterward. This is to avoid leaking the value some
14899 place that an attacker might use to rewrite the stack guard slot
14900 after having clobbered it.
14902 If this pattern is not defined, then a plain move pattern is
14905 `stack_protect_test'
14906 This pattern, if defined, compares a `Pmode' value from the memory
14907 in operand 1 with the memory in operand 0 without leaving the
14908 value in a register afterward and branches to operand 2 if the
14909 values weren't equal.
14911 If this pattern is not defined, then a plain compare pattern and
14912 conditional branch pattern is used.
14916 File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc
14918 13.10 When the Order of Patterns Matters
14919 ========================================
14921 Sometimes an insn can match more than one instruction pattern. Then the
14922 pattern that appears first in the machine description is the one used.
14923 Therefore, more specific patterns (patterns that will match fewer
14924 things) and faster instructions (those that will produce better code
14925 when they do match) should usually go first in the description.
14927 In some cases the effect of ordering the patterns can be used to hide
14928 a pattern when it is not valid. For example, the 68000 has an
14929 instruction for converting a fullword to floating point and another for
14930 converting a byte to floating point. An instruction converting an
14931 integer to floating point could match either one. We put the pattern
14932 to convert the fullword first to make sure that one will be used rather
14933 than the other. (Otherwise a large integer might be generated as a
14934 single-byte immediate quantity, which would not work.) Instead of
14935 using this pattern ordering it would be possible to make the pattern
14936 for convert-a-byte smart enough to deal properly with any constant
14940 File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc
14942 13.11 Interdependence of Patterns
14943 =================================
14945 Every machine description must have a named pattern for each of the
14946 conditional branch names `bCOND'. The recognition template must always
14950 (if_then_else (COND (cc0) (const_int 0))
14951 (label_ref (match_operand 0 "" ""))
14954 In addition, every machine description must have an anonymous pattern
14955 for each of the possible reverse-conditional branches. Their templates
14959 (if_then_else (COND (cc0) (const_int 0))
14961 (label_ref (match_operand 0 "" ""))))
14963 They are necessary because jump optimization can turn direct-conditional
14964 branches into reverse-conditional branches.
14966 It is often convenient to use the `match_operator' construct to reduce
14967 the number of patterns that must be specified for branches. For
14972 (if_then_else (match_operator 0 "comparison_operator"
14973 [(cc0) (const_int 0)])
14975 (label_ref (match_operand 1 "" ""))))]
14979 In some cases machines support instructions identical except for the
14980 machine mode of one or more operands. For example, there may be
14981 "sign-extend halfword" and "sign-extend byte" instructions whose
14984 (set (match_operand:SI 0 ...)
14985 (extend:SI (match_operand:HI 1 ...)))
14987 (set (match_operand:SI 0 ...)
14988 (extend:SI (match_operand:QI 1 ...)))
14990 Constant integers do not specify a machine mode, so an instruction to
14991 extend a constant value could match either pattern. The pattern it
14992 actually will match is the one that appears first in the file. For
14993 correct results, this must be the one for the widest possible mode
14994 (`HImode', here). If the pattern matches the `QImode' instruction, the
14995 results will be incorrect if the constant value does not actually fit
14998 Such instructions to extend constants are rarely generated because
14999 they are optimized away, but they do occasionally happen in nonoptimized
15002 If a constraint in a pattern allows a constant, the reload pass may
15003 replace a register with a constant permitted by the constraint in some
15004 cases. Similarly for memory references. Because of this substitution,
15005 you should not provide separate patterns for increment and decrement
15006 instructions. Instead, they should be generated from the same pattern
15007 that supports register-register add insns by examining the operands and
15008 generating the appropriate machine instruction.
15011 File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc
15013 13.12 Defining Jump Instruction Patterns
15014 ========================================
15016 For most machines, GCC assumes that the machine has a condition code.
15017 A comparison insn sets the condition code, recording the results of both
15018 signed and unsigned comparison of the given operands. A separate branch
15019 insn tests the condition code and branches or not according its value.
15020 The branch insns come in distinct signed and unsigned flavors. Many
15021 common machines, such as the VAX, the 68000 and the 32000, work this
15024 Some machines have distinct signed and unsigned compare instructions,
15025 and only one set of conditional branch instructions. The easiest way
15026 to handle these machines is to treat them just like the others until
15027 the final stage where assembly code is written. At this time, when
15028 outputting code for the compare instruction, peek ahead at the
15029 following branch using `next_cc0_user (insn)'. (The variable `insn'
15030 refers to the insn being output, in the output-writing code in an
15031 instruction pattern.) If the RTL says that is an unsigned branch,
15032 output an unsigned compare; otherwise output a signed compare. When
15033 the branch itself is output, you can treat signed and unsigned branches
15036 The reason you can do this is that GCC always generates a pair of
15037 consecutive RTL insns, possibly separated by `note' insns, one to set
15038 the condition code and one to test it, and keeps the pair inviolate
15041 To go with this technique, you must define the machine-description
15042 macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no
15043 compare instruction is superfluous.
15045 Some machines have compare-and-branch instructions and no condition
15046 code. A similar technique works for them. When it is time to "output"
15047 a compare instruction, record its operands in two static variables.
15048 When outputting the branch-on-condition-code instruction that follows,
15049 actually output a compare-and-branch instruction that uses the
15050 remembered operands.
15052 It also works to define patterns for compare-and-branch instructions.
15053 In optimizing compilation, the pair of compare and branch instructions
15054 will be combined according to these patterns. But this does not happen
15055 if optimization is not requested. So you must use one of the solutions
15056 above in addition to any special patterns you define.
15058 In many RISC machines, most instructions do not affect the condition
15059 code and there may not even be a separate condition code register. On
15060 these machines, the restriction that the definition and use of the
15061 condition code be adjacent insns is not necessary and can prevent
15062 important optimizations. For example, on the IBM RS/6000, there is a
15063 delay for taken branches unless the condition code register is set three
15064 instructions earlier than the conditional branch. The instruction
15065 scheduler cannot perform this optimization if it is not permitted to
15066 separate the definition and use of the condition code register.
15068 On these machines, do not use `(cc0)', but instead use a register to
15069 represent the condition code. If there is a specific condition code
15070 register in the machine, use a hard register. If the condition code or
15071 comparison result can be placed in any general register, or if there are
15072 multiple condition registers, use a pseudo register.
15074 On some machines, the type of branch instruction generated may depend
15075 on the way the condition code was produced; for example, on the 68k and
15076 SPARC, setting the condition code directly from an add or subtract
15077 instruction does not clear the overflow bit the way that a test
15078 instruction does, so a different branch instruction must be used for
15079 some conditional branches. For machines that use `(cc0)', the set and
15080 use of the condition code must be adjacent (separated only by `note'
15081 insns) allowing flags in `cc_status' to be used. (*Note Condition
15082 Code::.) Also, the comparison and branch insns can be located from
15083 each other by using the functions `prev_cc0_setter' and `next_cc0_user'.
15085 However, this is not true on machines that do not use `(cc0)'. On
15086 those machines, no assumptions can be made about the adjacency of the
15087 compare and branch insns and the above methods cannot be used. Instead,
15088 we use the machine mode of the condition code register to record
15089 different formats of the condition code register.
15091 Registers used to store the condition code value should have a mode
15092 that is in class `MODE_CC'. Normally, it will be `CCmode'. If
15093 additional modes are required (as for the add example mentioned above in
15094 the SPARC), define them in `MACHINE-modes.def' (*note Condition
15095 Code::). Also define `SELECT_CC_MODE' to choose a mode given an
15096 operand of a compare.
15098 If it is known during RTL generation that a different mode will be
15099 required (for example, if the machine has separate compare instructions
15100 for signed and unsigned quantities, like most IBM processors), they can
15101 be specified at that time.
15103 If the cases that require different modes would be made by instruction
15104 combination, the macro `SELECT_CC_MODE' determines which machine mode
15105 should be used for the comparison result. The patterns should be
15106 written using that mode. To support the case of the add on the SPARC
15107 discussed above, we have the pattern
15110 [(set (reg:CC_NOOV 0)
15112 (plus:SI (match_operand:SI 0 "register_operand" "%r")
15113 (match_operand:SI 1 "arith_operand" "rI"))
15118 The `SELECT_CC_MODE' macro on the SPARC returns `CC_NOOVmode' for
15119 comparisons whose argument is a `plus'.
15122 File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc
15124 13.13 Defining Looping Instruction Patterns
15125 ===========================================
15127 Some machines have special jump instructions that can be utilized to
15128 make loops more efficient. A common example is the 68000 `dbra'
15129 instruction which performs a decrement of a register and a branch if the
15130 result was greater than zero. Other machines, in particular digital
15131 signal processors (DSPs), have special block repeat instructions to
15132 provide low-overhead loop support. For example, the TI TMS320C3x/C4x
15133 DSPs have a block repeat instruction that loads special registers to
15134 mark the top and end of a loop and to count the number of loop
15135 iterations. This avoids the need for fetching and executing a
15136 `dbra'-like instruction and avoids pipeline stalls associated with the
15139 GCC has three special named patterns to support low overhead looping.
15140 They are `decrement_and_branch_until_zero', `doloop_begin', and
15141 `doloop_end'. The first pattern, `decrement_and_branch_until_zero', is
15142 not emitted during RTL generation but may be emitted during the
15143 instruction combination phase. This requires the assistance of the
15144 loop optimizer, using information collected during strength reduction,
15145 to reverse a loop to count down to zero. Some targets also require the
15146 loop optimizer to add a `REG_NONNEG' note to indicate that the
15147 iteration count is always positive. This is needed if the target
15148 performs a signed loop termination test. For example, the 68000 uses a
15149 pattern similar to the following for its `dbra' instruction:
15151 (define_insn "decrement_and_branch_until_zero"
15154 (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am")
15157 (label_ref (match_operand 1 "" ""))
15160 (plus:SI (match_dup 0)
15162 "find_reg_note (insn, REG_NONNEG, 0)"
15165 Note that since the insn is both a jump insn and has an output, it must
15166 deal with its own reloads, hence the `m' constraints. Also note that
15167 since this insn is generated by the instruction combination phase
15168 combining two sequential insns together into an implicit parallel insn,
15169 the iteration counter needs to be biased by the same amount as the
15170 decrement operation, in this case -1. Note that the following similar
15171 pattern will not be matched by the combiner.
15173 (define_insn "decrement_and_branch_until_zero"
15176 (ge (match_operand:SI 0 "general_operand" "+d*am")
15178 (label_ref (match_operand 1 "" ""))
15181 (plus:SI (match_dup 0)
15183 "find_reg_note (insn, REG_NONNEG, 0)"
15186 The other two special looping patterns, `doloop_begin' and
15187 `doloop_end', are emitted by the loop optimizer for certain
15188 well-behaved loops with a finite number of loop iterations using
15189 information collected during strength reduction.
15191 The `doloop_end' pattern describes the actual looping instruction (or
15192 the implicit looping operation) and the `doloop_begin' pattern is an
15193 optional companion pattern that can be used for initialization needed
15194 for some low-overhead looping instructions.
15196 Note that some machines require the actual looping instruction to be
15197 emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting
15198 the true RTL for a looping instruction at the top of the loop can cause
15199 problems with flow analysis. So instead, a dummy `doloop' insn is
15200 emitted at the end of the loop. The machine dependent reorg pass checks
15201 for the presence of this `doloop' insn and then searches back to the
15202 top of the loop, where it inserts the true looping insn (provided there
15203 are no instructions in the loop which would cause problems). Any
15204 additional labels can be emitted at this point. In addition, if the
15205 desired special iteration counter register was not allocated, this
15206 machine dependent reorg pass could emit a traditional compare and jump
15209 The essential difference between the `decrement_and_branch_until_zero'
15210 and the `doloop_end' patterns is that the loop optimizer allocates an
15211 additional pseudo register for the latter as an iteration counter.
15212 This pseudo register cannot be used within the loop (i.e., general
15213 induction variables cannot be derived from it), however, in many cases
15214 the loop induction variable may become redundant and removed by the
15218 File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc
15220 13.14 Canonicalization of Instructions
15221 ======================================
15223 There are often cases where multiple RTL expressions could represent an
15224 operation performed by a single machine instruction. This situation is
15225 most commonly encountered with logical, branch, and multiply-accumulate
15226 instructions. In such cases, the compiler attempts to convert these
15227 multiple RTL expressions into a single canonical form to reduce the
15228 number of insn patterns required.
15230 In addition to algebraic simplifications, following canonicalizations
15233 * For commutative and comparison operators, a constant is always
15234 made the second operand. If a machine only supports a constant as
15235 the second operand, only patterns that match a constant in the
15236 second operand need be supplied.
15238 * For associative operators, a sequence of operators will always
15239 chain to the left; for instance, only the left operand of an
15240 integer `plus' can itself be a `plus'. `and', `ior', `xor',
15241 `plus', `mult', `smin', `smax', `umin', and `umax' are associative
15242 when applied to integers, and sometimes to floating-point.
15244 * For these operators, if only one operand is a `neg', `not',
15245 `mult', `plus', or `minus' expression, it will be the first
15248 * In combinations of `neg', `mult', `plus', and `minus', the `neg'
15249 operations (if any) will be moved inside the operations as far as
15250 possible. For instance, `(neg (mult A B))' is canonicalized as
15251 `(mult (neg A) B)', but `(plus (mult (neg A) B) C)' is
15252 canonicalized as `(minus A (mult B C))'.
15254 * For the `compare' operator, a constant is always the second operand
15255 on machines where `cc0' is used (*note Jump Patterns::). On other
15256 machines, there are rare cases where the compiler might want to
15257 construct a `compare' with a constant as the first operand.
15258 However, these cases are not common enough for it to be worthwhile
15259 to provide a pattern matching a constant as the first operand
15260 unless the machine actually has such an instruction.
15262 An operand of `neg', `not', `mult', `plus', or `minus' is made the
15263 first operand under the same conditions as above.
15265 * `(minus X (const_int N))' is converted to `(plus X (const_int
15268 * Within address computations (i.e., inside `mem'), a left shift is
15269 converted into the appropriate multiplication by a power of two.
15271 * De Morgan's Law is used to move bitwise negation inside a bitwise
15272 logical-and or logical-or operation. If this results in only one
15273 operand being a `not' expression, it will be the first one.
15275 A machine that has an instruction that performs a bitwise
15276 logical-and of one operand with the bitwise negation of the other
15277 should specify the pattern for that instruction as
15280 [(set (match_operand:M 0 ...)
15281 (and:M (not:M (match_operand:M 1 ...))
15282 (match_operand:M 2 ...)))]
15286 Similarly, a pattern for a "NAND" instruction should be written
15289 [(set (match_operand:M 0 ...)
15290 (ior:M (not:M (match_operand:M 1 ...))
15291 (not:M (match_operand:M 2 ...))))]
15295 In both cases, it is not necessary to include patterns for the many
15296 logically equivalent RTL expressions.
15298 * The only possible RTL expressions involving both bitwise
15299 exclusive-or and bitwise negation are `(xor:M X Y)' and `(not:M
15302 * The sum of three items, one of which is a constant, will only
15305 (plus:M (plus:M X Y) CONSTANT)
15307 * On machines that do not use `cc0', `(compare X (const_int 0))'
15308 will be converted to X.
15310 * Equality comparisons of a group of bits (usually a single bit)
15311 with zero will be written using `zero_extract' rather than the
15312 equivalent `and' or `sign_extract' operations.
15316 File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc
15318 13.15 Defining RTL Sequences for Code Generation
15319 ================================================
15321 On some target machines, some standard pattern names for RTL generation
15322 cannot be handled with single insn, but a sequence of RTL insns can
15323 represent them. For these target machines, you can write a
15324 `define_expand' to specify how to generate the sequence of RTL.
15326 A `define_expand' is an RTL expression that looks almost like a
15327 `define_insn'; but, unlike the latter, a `define_expand' is used only
15328 for RTL generation and it can produce more than one RTL insn.
15330 A `define_expand' RTX has four operands:
15332 * The name. Each `define_expand' must have a name, since the only
15333 use for it is to refer to it by name.
15335 * The RTL template. This is a vector of RTL expressions representing
15336 a sequence of separate instructions. Unlike `define_insn', there
15337 is no implicit surrounding `PARALLEL'.
15339 * The condition, a string containing a C expression. This
15340 expression is used to express how the availability of this pattern
15341 depends on subclasses of target machine, selected by command-line
15342 options when GCC is run. This is just like the condition of a
15343 `define_insn' that has a standard name. Therefore, the condition
15344 (if present) may not depend on the data in the insn being matched,
15345 but only the target-machine-type flags. The compiler needs to
15346 test these conditions during initialization in order to learn
15347 exactly which named instructions are available in a particular run.
15349 * The preparation statements, a string containing zero or more C
15350 statements which are to be executed before RTL code is generated
15351 from the RTL template.
15353 Usually these statements prepare temporary registers for use as
15354 internal operands in the RTL template, but they can also generate
15355 RTL insns directly by calling routines such as `emit_insn', etc.
15356 Any such insns precede the ones that come from the RTL template.
15358 Every RTL insn emitted by a `define_expand' must match some
15359 `define_insn' in the machine description. Otherwise, the compiler will
15360 crash when trying to generate code for the insn or trying to optimize
15363 The RTL template, in addition to controlling generation of RTL insns,
15364 also describes the operands that need to be specified when this pattern
15365 is used. In particular, it gives a predicate for each operand.
15367 A true operand, which needs to be specified in order to generate RTL
15368 from the pattern, should be described with a `match_operand' in its
15369 first occurrence in the RTL template. This enters information on the
15370 operand's predicate into the tables that record such things. GCC uses
15371 the information to preload the operand into a register if that is
15372 required for valid RTL code. If the operand is referred to more than
15373 once, subsequent references should use `match_dup'.
15375 The RTL template may also refer to internal "operands" which are
15376 temporary registers or labels used only within the sequence made by the
15377 `define_expand'. Internal operands are substituted into the RTL
15378 template with `match_dup', never with `match_operand'. The values of
15379 the internal operands are not passed in as arguments by the compiler
15380 when it requests use of this pattern. Instead, they are computed
15381 within the pattern, in the preparation statements. These statements
15382 compute the values and store them into the appropriate elements of
15383 `operands' so that `match_dup' can find them.
15385 There are two special macros defined for use in the preparation
15386 statements: `DONE' and `FAIL'. Use them with a following semicolon, as
15390 Use the `DONE' macro to end RTL generation for the pattern. The
15391 only RTL insns resulting from the pattern on this occasion will be
15392 those already emitted by explicit calls to `emit_insn' within the
15393 preparation statements; the RTL template will not be generated.
15396 Make the pattern fail on this occasion. When a pattern fails, it
15397 means that the pattern was not truly available. The calling
15398 routines in the compiler will try other strategies for code
15399 generation using other patterns.
15401 Failure is currently supported only for binary (addition,
15402 multiplication, shifting, etc.) and bit-field (`extv', `extzv',
15403 and `insv') operations.
15405 If the preparation falls through (invokes neither `DONE' nor `FAIL'),
15406 then the `define_expand' acts like a `define_insn' in that the RTL
15407 template is used to generate the insn.
15409 The RTL template is not used for matching, only for generating the
15410 initial insn list. If the preparation statement always invokes `DONE'
15411 or `FAIL', the RTL template may be reduced to a simple list of
15412 operands, such as this example:
15414 (define_expand "addsi3"
15415 [(match_operand:SI 0 "register_operand" "")
15416 (match_operand:SI 1 "register_operand" "")
15417 (match_operand:SI 2 "register_operand" "")]
15421 handle_add (operands[0], operands[1], operands[2]);
15425 Here is an example, the definition of left-shift for the SPUR chip:
15427 (define_expand "ashlsi3"
15428 [(set (match_operand:SI 0 "register_operand" "")
15430 (match_operand:SI 1 "register_operand" "")
15431 (match_operand:SI 2 "nonmemory_operand" "")))]
15436 if (GET_CODE (operands[2]) != CONST_INT
15437 || (unsigned) INTVAL (operands[2]) > 3)
15441 This example uses `define_expand' so that it can generate an RTL insn
15442 for shifting when the shift-count is in the supported range of 0 to 3
15443 but fail in other cases where machine insns aren't available. When it
15444 fails, the compiler tries another strategy using different patterns
15445 (such as, a library call).
15447 If the compiler were able to handle nontrivial condition-strings in
15448 patterns with names, then it would be possible to use a `define_insn'
15449 in that case. Here is another case (zero-extension on the 68000) which
15450 makes more use of the power of `define_expand':
15452 (define_expand "zero_extendhisi2"
15453 [(set (match_operand:SI 0 "general_operand" "")
15455 (set (strict_low_part
15459 (match_operand:HI 1 "general_operand" ""))]
15461 "operands[1] = make_safe_from (operands[1], operands[0]);")
15463 Here two RTL insns are generated, one to clear the entire output operand
15464 and the other to copy the input operand into its low half. This
15465 sequence is incorrect if the input operand refers to [the old value of]
15466 the output operand, so the preparation statement makes sure this isn't
15467 so. The function `make_safe_from' copies the `operands[1]' into a
15468 temporary register if it refers to `operands[0]'. It does this by
15469 emitting another RTL insn.
15471 Finally, a third example shows the use of an internal operand.
15472 Zero-extension on the SPUR chip is done by `and'-ing the result against
15473 a halfword mask. But this mask cannot be represented by a `const_int'
15474 because the constant value is too large to be legitimate on this
15475 machine. So it must be copied into a register with `force_reg' and
15476 then the register used in the `and'.
15478 (define_expand "zero_extendhisi2"
15479 [(set (match_operand:SI 0 "register_operand" "")
15481 (match_operand:HI 1 "register_operand" "")
15486 = force_reg (SImode, GEN_INT (65535)); ")
15488 _Note:_ If the `define_expand' is used to serve a standard binary or
15489 unary arithmetic operation or a bit-field operation, then the last insn
15490 it generates must not be a `code_label', `barrier' or `note'. It must
15491 be an `insn', `jump_insn' or `call_insn'. If you don't need a real insn
15492 at the end, emit an insn to copy the result of the operation into
15493 itself. Such an insn will generate no code, but it can avoid problems
15497 File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc
15499 13.16 Defining How to Split Instructions
15500 ========================================
15502 There are two cases where you should specify how to split a pattern
15503 into multiple insns. On machines that have instructions requiring
15504 delay slots (*note Delay Slots::) or that have instructions whose
15505 output is not available for multiple cycles (*note Processor pipeline
15506 description::), the compiler phases that optimize these cases need to
15507 be able to move insns into one-instruction delay slots. However, some
15508 insns may generate more than one machine instruction. These insns
15509 cannot be placed into a delay slot.
15511 Often you can rewrite the single insn as a list of individual insns,
15512 each corresponding to one machine instruction. The disadvantage of
15513 doing so is that it will cause the compilation to be slower and require
15514 more space. If the resulting insns are too complex, it may also
15515 suppress some optimizations. The compiler splits the insn if there is a
15516 reason to believe that it might improve instruction or delay slot
15519 The insn combiner phase also splits putative insns. If three insns are
15520 merged into one insn with a complex expression that cannot be matched by
15521 some `define_insn' pattern, the combiner phase attempts to split the
15522 complex pattern into two insns that are recognized. Usually it can
15523 break the complex pattern into two patterns by splitting out some
15524 subexpression. However, in some other cases, such as performing an
15525 addition of a large constant in two insns on a RISC machine, the way to
15526 split the addition into two insns is machine-dependent.
15528 The `define_split' definition tells the compiler how to split a
15529 complex insn into several simpler insns. It looks like this:
15534 [NEW-INSN-PATTERN-1
15537 "PREPARATION-STATEMENTS")
15539 INSN-PATTERN is a pattern that needs to be split and CONDITION is the
15540 final condition to be tested, as in a `define_insn'. When an insn
15541 matching INSN-PATTERN and satisfying CONDITION is found, it is replaced
15542 in the insn list with the insns given by NEW-INSN-PATTERN-1,
15543 NEW-INSN-PATTERN-2, etc.
15545 The PREPARATION-STATEMENTS are similar to those statements that are
15546 specified for `define_expand' (*note Expander Definitions::) and are
15547 executed before the new RTL is generated to prepare for the generated
15548 code or emit some insns whose pattern is not fixed. Unlike those in
15549 `define_expand', however, these statements must not generate any new
15550 pseudo-registers. Once reload has completed, they also must not
15551 allocate any space in the stack frame.
15553 Patterns are matched against INSN-PATTERN in two different
15554 circumstances. If an insn needs to be split for delay slot scheduling
15555 or insn scheduling, the insn is already known to be valid, which means
15556 that it must have been matched by some `define_insn' and, if
15557 `reload_completed' is nonzero, is known to satisfy the constraints of
15558 that `define_insn'. In that case, the new insn patterns must also be
15559 insns that are matched by some `define_insn' and, if `reload_completed'
15560 is nonzero, must also satisfy the constraints of those definitions.
15562 As an example of this usage of `define_split', consider the following
15563 example from `a29k.md', which splits a `sign_extend' from `HImode' to
15564 `SImode' into a pair of shift insns:
15567 [(set (match_operand:SI 0 "gen_reg_operand" "")
15568 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))]
15570 [(set (match_dup 0)
15571 (ashift:SI (match_dup 1)
15574 (ashiftrt:SI (match_dup 0)
15577 { operands[1] = gen_lowpart (SImode, operands[1]); }")
15579 When the combiner phase tries to split an insn pattern, it is always
15580 the case that the pattern is _not_ matched by any `define_insn'. The
15581 combiner pass first tries to split a single `set' expression and then
15582 the same `set' expression inside a `parallel', but followed by a
15583 `clobber' of a pseudo-reg to use as a scratch register. In these
15584 cases, the combiner expects exactly two new insn patterns to be
15585 generated. It will verify that these patterns match some `define_insn'
15586 definitions, so you need not do this test in the `define_split' (of
15587 course, there is no point in writing a `define_split' that will never
15588 produce insns that match).
15590 Here is an example of this use of `define_split', taken from
15594 [(set (match_operand:SI 0 "gen_reg_operand" "")
15595 (plus:SI (match_operand:SI 1 "gen_reg_operand" "")
15596 (match_operand:SI 2 "non_add_cint_operand" "")))]
15598 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3)))
15599 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))]
15602 int low = INTVAL (operands[2]) & 0xffff;
15603 int high = (unsigned) INTVAL (operands[2]) >> 16;
15606 high++, low |= 0xffff0000;
15608 operands[3] = GEN_INT (high << 16);
15609 operands[4] = GEN_INT (low);
15612 Here the predicate `non_add_cint_operand' matches any `const_int' that
15613 is _not_ a valid operand of a single add insn. The add with the
15614 smaller displacement is written so that it can be substituted into the
15615 address of a subsequent operation.
15617 An example that uses a scratch register, from the same file, generates
15618 an equality comparison of a register and a large constant:
15621 [(set (match_operand:CC 0 "cc_reg_operand" "")
15622 (compare:CC (match_operand:SI 1 "gen_reg_operand" "")
15623 (match_operand:SI 2 "non_short_cint_operand" "")))
15624 (clobber (match_operand:SI 3 "gen_reg_operand" ""))]
15625 "find_single_use (operands[0], insn, 0)
15626 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ
15627 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)"
15628 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4)))
15629 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))]
15632 /* Get the constant we are comparing against, C, and see what it
15633 looks like sign-extended to 16 bits. Then see what constant
15634 could be XOR'ed with C to get the sign-extended value. */
15636 int c = INTVAL (operands[2]);
15637 int sextc = (c << 16) >> 16;
15638 int xorv = c ^ sextc;
15640 operands[4] = GEN_INT (xorv);
15641 operands[5] = GEN_INT (sextc);
15644 To avoid confusion, don't write a single `define_split' that accepts
15645 some insns that match some `define_insn' as well as some insns that
15646 don't. Instead, write two separate `define_split' definitions, one for
15647 the insns that are valid and one for the insns that are not valid.
15649 The splitter is allowed to split jump instructions into sequence of
15650 jumps or create new jumps in while splitting non-jump instructions. As
15651 the central flowgraph and branch prediction information needs to be
15652 updated, several restriction apply.
15654 Splitting of jump instruction into sequence that over by another jump
15655 instruction is always valid, as compiler expect identical behavior of
15656 new jump. When new sequence contains multiple jump instructions or new
15657 labels, more assistance is needed. Splitter is required to create only
15658 unconditional jumps, or simple conditional jump instructions.
15659 Additionally it must attach a `REG_BR_PROB' note to each conditional
15660 jump. A global variable `split_branch_probability' holds the
15661 probability of the original branch in case it was an simple conditional
15662 jump, -1 otherwise. To simplify recomputing of edge frequencies, the
15663 new sequence is required to have only forward jumps to the newly
15666 For the common case where the pattern of a define_split exactly
15667 matches the pattern of a define_insn, use `define_insn_and_split'. It
15670 (define_insn_and_split
15675 [NEW-INSN-PATTERN-1
15678 "PREPARATION-STATEMENTS"
15681 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used
15682 as in `define_insn'. The NEW-INSN-PATTERN vector and the
15683 PREPARATION-STATEMENTS are used as in a `define_split'. The
15684 SPLIT-CONDITION is also used as in `define_split', with the additional
15685 behavior that if the condition starts with `&&', the condition used for
15686 the split will be the constructed as a logical "and" of the split
15687 condition with the insn condition. For example, from i386.md:
15689 (define_insn_and_split "zero_extendhisi2_and"
15690 [(set (match_operand:SI 0 "register_operand" "=r")
15691 (zero_extend:SI (match_operand:HI 1 "register_operand" "0")))
15692 (clobber (reg:CC 17))]
15693 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size"
15695 "&& reload_completed"
15696 [(parallel [(set (match_dup 0)
15697 (and:SI (match_dup 0) (const_int 65535)))
15698 (clobber (reg:CC 17))])]
15700 [(set_attr "type" "alu1")])
15702 In this case, the actual split condition will be
15703 `TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'.
15705 The `define_insn_and_split' construction provides exactly the same
15706 functionality as two separate `define_insn' and `define_split'
15707 patterns. It exists for compactness, and as a maintenance tool to
15708 prevent having to ensure the two patterns' templates match.
15711 File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc
15713 13.17 Including Patterns in Machine Descriptions.
15714 =================================================
15716 The `include' pattern tells the compiler tools where to look for
15717 patterns that are in files other than in the file `.md'. This is used
15718 only at build time and there is no preprocessing allowed.
15729 (include "filestuff")
15731 Where PATHNAME is a string that specifies the location of the file,
15732 specifies the include file to be in `gcc/config/target/filestuff'. The
15733 directory `gcc/config/target' is regarded as the default directory.
15735 Machine descriptions may be split up into smaller more manageable
15736 subsections and placed into subdirectories.
15741 (include "BOGUS/filestuff")
15743 the include file is specified to be in
15744 `gcc/config/TARGET/BOGUS/filestuff'.
15746 Specifying an absolute path for the include file such as;
15748 (include "/u2/BOGUS/filestuff")
15749 is permitted but is not encouraged.
15751 13.17.1 RTL Generation Tool Options for Directory Search
15752 --------------------------------------------------------
15754 The `-IDIR' option specifies directories to search for machine
15755 descriptions. For example:
15758 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md
15760 Add the directory DIR to the head of the list of directories to be
15761 searched for header files. This can be used to override a system
15762 machine definition file, substituting your own version, since these
15763 directories are searched before the default machine description file
15764 directories. If you use more than one `-I' option, the directories are
15765 scanned in left-to-right order; the standard default directory come
15769 File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc
15771 13.18 Machine-Specific Peephole Optimizers
15772 ==========================================
15774 In addition to instruction patterns the `md' file may contain
15775 definitions of machine-specific peephole optimizations.
15777 The combiner does not notice certain peephole optimizations when the
15778 data flow in the program does not suggest that it should try them. For
15779 example, sometimes two consecutive insns related in purpose can be
15780 combined even though the second one does not appear to use a register
15781 computed in the first one. A machine-specific peephole optimizer can
15782 detect such opportunities.
15784 There are two forms of peephole definitions that may be used. The
15785 original `define_peephole' is run at assembly output time to match
15786 insns and substitute assembly text. Use of `define_peephole' is
15789 A newer `define_peephole2' matches insns and substitutes new insns.
15790 The `peephole2' pass is run after register allocation but before
15791 scheduling, which may result in much better code for targets that do
15796 * define_peephole:: RTL to Text Peephole Optimizers
15797 * define_peephole2:: RTL to RTL Peephole Optimizers
15800 File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions
15802 13.18.1 RTL to Text Peephole Optimizers
15803 ---------------------------------------
15805 A definition looks like this:
15813 "OPTIONAL-INSN-ATTRIBUTES")
15815 The last string operand may be omitted if you are not using any
15816 machine-specific information in this machine description. If present,
15817 it must obey the same rules as in a `define_insn'.
15819 In this skeleton, INSN-PATTERN-1 and so on are patterns to match
15820 consecutive insns. The optimization applies to a sequence of insns when
15821 INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next,
15824 Each of the insns matched by a peephole must also match a
15825 `define_insn'. Peepholes are checked only at the last stage just
15826 before code generation, and only optionally. Therefore, any insn which
15827 would match a peephole but no `define_insn' will cause a crash in code
15828 generation in an unoptimized compilation, or at various optimization
15831 The operands of the insns are matched with `match_operands',
15832 `match_operator', and `match_dup', as usual. What is not usual is that
15833 the operand numbers apply to all the insn patterns in the definition.
15834 So, you can check for identical operands in two insns by using
15835 `match_operand' in one insn and `match_dup' in the other.
15837 The operand constraints used in `match_operand' patterns do not have
15838 any direct effect on the applicability of the peephole, but they will
15839 be validated afterward, so make sure your constraints are general enough
15840 to apply whenever the peephole matches. If the peephole matches but
15841 the constraints are not satisfied, the compiler will crash.
15843 It is safe to omit constraints in all the operands of the peephole; or
15844 you can write constraints which serve as a double-check on the criteria
15847 Once a sequence of insns matches the patterns, the CONDITION is
15848 checked. This is a C expression which makes the final decision whether
15849 to perform the optimization (we do so if the expression is nonzero). If
15850 CONDITION is omitted (in other words, the string is empty) then the
15851 optimization is applied to every sequence of insns that matches the
15854 The defined peephole optimizations are applied after register
15855 allocation is complete. Therefore, the peephole definition can check
15856 which operands have ended up in which kinds of registers, just by
15857 looking at the operands.
15859 The way to refer to the operands in CONDITION is to write
15860 `operands[I]' for operand number I (as matched by `(match_operand I
15861 ...)'). Use the variable `insn' to refer to the last of the insns
15862 being matched; use `prev_active_insn' to find the preceding insns.
15864 When optimizing computations with intermediate results, you can use
15865 CONDITION to match only when the intermediate results are not used
15866 elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where INSN
15867 is the insn in which you expect the value to be used for the last time
15868 (from the value of `insn', together with use of `prev_nonnote_insn'),
15869 and OP is the intermediate value (from `operands[I]').
15871 Applying the optimization means replacing the sequence of insns with
15872 one new insn. The TEMPLATE controls ultimate output of assembler code
15873 for this combined insn. It works exactly like the template of a
15874 `define_insn'. Operand numbers in this template are the same ones used
15875 in matching the original sequence of insns.
15877 The result of a defined peephole optimizer does not need to match any
15878 of the insn patterns in the machine description; it does not even have
15879 an opportunity to match them. The peephole optimizer definition itself
15880 serves as the insn pattern to control how the insn is output.
15882 Defined peephole optimizers are run as assembler code is being output,
15883 so the insns they produce are never combined or rearranged in any way.
15885 Here is an example, taken from the 68000 machine description:
15888 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4)))
15889 (set (match_operand:DF 0 "register_operand" "=f")
15890 (match_operand:DF 1 "register_operand" "ad"))]
15891 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
15894 xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1);
15896 output_asm_insn ("move.l %1,(sp)", xoperands);
15897 output_asm_insn ("move.l %1,-(sp)", operands);
15898 return "fmove.d (sp)+,%0";
15900 output_asm_insn ("movel %1,sp@", xoperands);
15901 output_asm_insn ("movel %1,sp@-", operands);
15902 return "fmoved sp@+,%0";
15906 The effect of this optimization is to change
15921 INSN-PATTERN-1 and so on look _almost_ like the second operand of
15922 `define_insn'. There is one important difference: the second operand
15923 of `define_insn' consists of one or more RTX's enclosed in square
15924 brackets. Usually, there is only one: then the same action can be
15925 written as an element of a `define_peephole'. But when there are
15926 multiple actions in a `define_insn', they are implicitly enclosed in a
15927 `parallel'. Then you must explicitly write the `parallel', and the
15928 square brackets within it, in the `define_peephole'. Thus, if an insn
15929 pattern looks like this,
15931 (define_insn "divmodsi4"
15932 [(set (match_operand:SI 0 "general_operand" "=d")
15933 (div:SI (match_operand:SI 1 "general_operand" "0")
15934 (match_operand:SI 2 "general_operand" "dmsK")))
15935 (set (match_operand:SI 3 "general_operand" "=d")
15936 (mod:SI (match_dup 1) (match_dup 2)))]
15938 "divsl%.l %2,%3:%0")
15940 then the way to mention this insn in a peephole is as follows:
15945 [(set (match_operand:SI 0 "general_operand" "=d")
15946 (div:SI (match_operand:SI 1 "general_operand" "0")
15947 (match_operand:SI 2 "general_operand" "dmsK")))
15948 (set (match_operand:SI 3 "general_operand" "=d")
15949 (mod:SI (match_dup 1) (match_dup 2)))])
15954 File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions
15956 13.18.2 RTL to RTL Peephole Optimizers
15957 --------------------------------------
15959 The `define_peephole2' definition tells the compiler how to substitute
15960 one sequence of instructions for another sequence, what additional
15961 scratch registers may be needed and what their lifetimes must be.
15968 [NEW-INSN-PATTERN-1
15971 "PREPARATION-STATEMENTS")
15973 The definition is almost identical to `define_split' (*note Insn
15974 Splitting::) except that the pattern to match is not a single
15975 instruction, but a sequence of instructions.
15977 It is possible to request additional scratch registers for use in the
15978 output template. If appropriate registers are not free, the pattern
15979 will simply not match.
15981 Scratch registers are requested with a `match_scratch' pattern at the
15982 top level of the input pattern. The allocated register (initially) will
15983 be dead at the point requested within the original sequence. If the
15984 scratch is used at more than a single point, a `match_dup' pattern at
15985 the top level of the input pattern marks the last position in the input
15986 sequence at which the register must be available.
15988 Here is an example from the IA-32 machine description:
15991 [(match_scratch:SI 2 "r")
15992 (parallel [(set (match_operand:SI 0 "register_operand" "")
15993 (match_operator:SI 3 "arith_or_logical_operator"
15995 (match_operand:SI 1 "memory_operand" "")]))
15996 (clobber (reg:CC 17))])]
15997 "! optimize_size && ! TARGET_READ_MODIFY"
15998 [(set (match_dup 2) (match_dup 1))
15999 (parallel [(set (match_dup 0)
16000 (match_op_dup 3 [(match_dup 0) (match_dup 2)]))
16001 (clobber (reg:CC 17))])]
16004 This pattern tries to split a load from its use in the hopes that we'll
16005 be able to schedule around the memory load latency. It allocates a
16006 single `SImode' register of class `GENERAL_REGS' (`"r"') that needs to
16007 be live only at the point just before the arithmetic.
16009 A real example requiring extended scratch lifetimes is harder to come
16010 by, so here's a silly made-up example:
16013 [(match_scratch:SI 4 "r")
16014 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" ""))
16015 (set (match_operand:SI 2 "" "") (match_dup 1))
16017 (set (match_operand:SI 3 "" "") (match_dup 1))]
16018 "/* determine 1 does not overlap 0 and 2 */"
16019 [(set (match_dup 4) (match_dup 1))
16020 (set (match_dup 0) (match_dup 4))
16021 (set (match_dup 2) (match_dup 4))]
16022 (set (match_dup 3) (match_dup 4))]
16025 If we had not added the `(match_dup 4)' in the middle of the input
16026 sequence, it might have been the case that the register we chose at the
16027 beginning of the sequence is killed by the first or second `set'.
16030 File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc
16032 13.19 Instruction Attributes
16033 ============================
16035 In addition to describing the instruction supported by the target
16036 machine, the `md' file also defines a group of "attributes" and a set of
16037 values for each. Every generated insn is assigned a value for each
16038 attribute. One possible attribute would be the effect that the insn
16039 has on the machine's condition code. This attribute can then be used
16040 by `NOTICE_UPDATE_CC' to track the condition codes.
16044 * Defining Attributes:: Specifying attributes and their values.
16045 * Expressions:: Valid expressions for attribute values.
16046 * Tagging Insns:: Assigning attribute values to insns.
16047 * Attr Example:: An example of assigning attributes.
16048 * Insn Lengths:: Computing the length of insns.
16049 * Constant Attributes:: Defining attributes that are constant.
16050 * Delay Slots:: Defining delay slots required for a machine.
16051 * Processor pipeline description:: Specifying information for insn scheduling.
16054 File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes
16056 13.19.1 Defining Attributes and their Values
16057 --------------------------------------------
16059 The `define_attr' expression is used to define each attribute required
16060 by the target machine. It looks like:
16062 (define_attr NAME LIST-OF-VALUES DEFAULT)
16064 NAME is a string specifying the name of the attribute being defined.
16066 LIST-OF-VALUES is either a string that specifies a comma-separated
16067 list of values that can be assigned to the attribute, or a null string
16068 to indicate that the attribute takes numeric values.
16070 DEFAULT is an attribute expression that gives the value of this
16071 attribute for insns that match patterns whose definition does not
16072 include an explicit value for this attribute. *Note Attr Example::,
16073 for more information on the handling of defaults. *Note Constant
16074 Attributes::, for information on attributes that do not depend on any
16077 For each defined attribute, a number of definitions are written to the
16078 `insn-attr.h' file. For cases where an explicit set of values is
16079 specified for an attribute, the following are defined:
16081 * A `#define' is written for the symbol `HAVE_ATTR_NAME'.
16083 * An enumerated class is defined for `attr_NAME' with elements of
16084 the form `UPPER-NAME_UPPER-VALUE' where the attribute name and
16085 value are first converted to uppercase.
16087 * A function `get_attr_NAME' is defined that is passed an insn and
16088 returns the attribute value for that insn.
16090 For example, if the following is present in the `md' file:
16092 (define_attr "type" "branch,fp,load,store,arith" ...)
16094 the following lines will be written to the file `insn-attr.h'.
16096 #define HAVE_ATTR_type
16097 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD,
16098 TYPE_STORE, TYPE_ARITH};
16099 extern enum attr_type get_attr_type ();
16101 If the attribute takes numeric values, no `enum' type will be defined
16102 and the function to obtain the attribute's value will return `int'.
16105 File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes
16107 13.19.2 Attribute Expressions
16108 -----------------------------
16110 RTL expressions used to define attributes use the codes described above
16111 plus a few specific to attribute definitions, to be discussed below.
16112 Attribute value expressions must have one of the following forms:
16115 The integer I specifies the value of a numeric attribute. I must
16118 The value of a numeric attribute can be specified either with a
16119 `const_int', or as an integer represented as a string in
16120 `const_string', `eq_attr' (see below), `attr', `symbol_ref',
16121 simple arithmetic expressions, and `set_attr' overrides on
16122 specific instructions (*note Tagging Insns::).
16124 `(const_string VALUE)'
16125 The string VALUE specifies a constant attribute value. If VALUE
16126 is specified as `"*"', it means that the default value of the
16127 attribute is to be used for the insn containing this expression.
16128 `"*"' obviously cannot be used in the DEFAULT expression of a
16131 If the attribute whose value is being specified is numeric, VALUE
16132 must be a string containing a non-negative integer (normally
16133 `const_int' would be used in this case). Otherwise, it must
16134 contain one of the valid values for the attribute.
16136 `(if_then_else TEST TRUE-VALUE FALSE-VALUE)'
16137 TEST specifies an attribute test, whose format is defined below.
16138 The value of this expression is TRUE-VALUE if TEST is true,
16139 otherwise it is FALSE-VALUE.
16141 `(cond [TEST1 VALUE1 ...] DEFAULT)'
16142 The first operand of this expression is a vector containing an even
16143 number of expressions and consisting of pairs of TEST and VALUE
16144 expressions. The value of the `cond' expression is that of the
16145 VALUE corresponding to the first true TEST expression. If none of
16146 the TEST expressions are true, the value of the `cond' expression
16147 is that of the DEFAULT expression.
16149 TEST expressions can have one of the following forms:
16152 This test is true if I is nonzero and false otherwise.
16155 `(ior TEST1 TEST2)'
16156 `(and TEST1 TEST2)'
16157 These tests are true if the indicated logical function is true.
16159 `(match_operand:M N PRED CONSTRAINTS)'
16160 This test is true if operand N of the insn whose attribute value
16161 is being determined has mode M (this part of the test is ignored
16162 if M is `VOIDmode') and the function specified by the string PRED
16163 returns a nonzero value when passed operand N and mode M (this
16164 part of the test is ignored if PRED is the null string).
16166 The CONSTRAINTS operand is ignored and should be the null string.
16168 `(le ARITH1 ARITH2)'
16169 `(leu ARITH1 ARITH2)'
16170 `(lt ARITH1 ARITH2)'
16171 `(ltu ARITH1 ARITH2)'
16172 `(gt ARITH1 ARITH2)'
16173 `(gtu ARITH1 ARITH2)'
16174 `(ge ARITH1 ARITH2)'
16175 `(geu ARITH1 ARITH2)'
16176 `(ne ARITH1 ARITH2)'
16177 `(eq ARITH1 ARITH2)'
16178 These tests are true if the indicated comparison of the two
16179 arithmetic expressions is true. Arithmetic expressions are formed
16180 with `plus', `minus', `mult', `div', `mod', `abs', `neg', `and',
16181 `ior', `xor', `not', `ashift', `lshiftrt', and `ashiftrt'
16184 `const_int' and `symbol_ref' are always valid terms (*note Insn
16185 Lengths::,for additional forms). `symbol_ref' is a string
16186 denoting a C expression that yields an `int' when evaluated by the
16187 `get_attr_...' routine. It should normally be a global variable.
16189 `(eq_attr NAME VALUE)'
16190 NAME is a string specifying the name of an attribute.
16192 VALUE is a string that is either a valid value for attribute NAME,
16193 a comma-separated list of values, or `!' followed by a value or
16194 list. If VALUE does not begin with a `!', this test is true if
16195 the value of the NAME attribute of the current insn is in the list
16196 specified by VALUE. If VALUE begins with a `!', this test is true
16197 if the attribute's value is _not_ in the specified list.
16201 (eq_attr "type" "load,store")
16205 (ior (eq_attr "type" "load") (eq_attr "type" "store"))
16207 If NAME specifies an attribute of `alternative', it refers to the
16208 value of the compiler variable `which_alternative' (*note Output
16209 Statement::) and the values must be small integers. For example,
16211 (eq_attr "alternative" "2,3")
16215 (ior (eq (symbol_ref "which_alternative") (const_int 2))
16216 (eq (symbol_ref "which_alternative") (const_int 3)))
16218 Note that, for most attributes, an `eq_attr' test is simplified in
16219 cases where the value of the attribute being tested is known for
16220 all insns matching a particular pattern. This is by far the most
16224 The value of an `attr_flag' expression is true if the flag
16225 specified by NAME is true for the `insn' currently being scheduled.
16227 NAME is a string specifying one of a fixed set of flags to test.
16228 Test the flags `forward' and `backward' to determine the direction
16229 of a conditional branch. Test the flags `very_likely', `likely',
16230 `very_unlikely', and `unlikely' to determine if a conditional
16231 branch is expected to be taken.
16233 If the `very_likely' flag is true, then the `likely' flag is also
16234 true. Likewise for the `very_unlikely' and `unlikely' flags.
16236 This example describes a conditional branch delay slot which can
16237 be nullified for forward branches that are taken (annul-true) or
16238 for backward branches which are not taken (annul-false).
16240 (define_delay (eq_attr "type" "cbranch")
16241 [(eq_attr "in_branch_delay" "true")
16242 (and (eq_attr "in_branch_delay" "true")
16243 (attr_flag "forward"))
16244 (and (eq_attr "in_branch_delay" "true")
16245 (attr_flag "backward"))])
16247 The `forward' and `backward' flags are false if the current `insn'
16248 being scheduled is not a conditional branch.
16250 The `very_likely' and `likely' flags are true if the `insn' being
16251 scheduled is not a conditional branch. The `very_unlikely' and
16252 `unlikely' flags are false if the `insn' being scheduled is not a
16253 conditional branch.
16255 `attr_flag' is only used during delay slot scheduling and has no
16256 meaning to other passes of the compiler.
16259 The value of another attribute is returned. This is most useful
16260 for numeric attributes, as `eq_attr' and `attr_flag' produce more
16261 efficient code for non-numeric attributes.
16264 File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes
16266 13.19.3 Assigning Attribute Values to Insns
16267 -------------------------------------------
16269 The value assigned to an attribute of an insn is primarily determined by
16270 which pattern is matched by that insn (or which `define_peephole'
16271 generated it). Every `define_insn' and `define_peephole' can have an
16272 optional last argument to specify the values of attributes for matching
16273 insns. The value of any attribute not specified in a particular insn
16274 is set to the default value for that attribute, as specified in its
16275 `define_attr'. Extensive use of default values for attributes permits
16276 the specification of the values for only one or two attributes in the
16277 definition of most insn patterns, as seen in the example in the next
16280 The optional last argument of `define_insn' and `define_peephole' is a
16281 vector of expressions, each of which defines the value for a single
16282 attribute. The most general way of assigning an attribute's value is
16283 to use a `set' expression whose first operand is an `attr' expression
16284 giving the name of the attribute being set. The second operand of the
16285 `set' is an attribute expression (*note Expressions::) giving the value
16288 When the attribute value depends on the `alternative' attribute (i.e.,
16289 which is the applicable alternative in the constraint of the insn), the
16290 `set_attr_alternative' expression can be used. It allows the
16291 specification of a vector of attribute expressions, one for each
16294 When the generality of arbitrary attribute expressions is not required,
16295 the simpler `set_attr' expression can be used, which allows specifying
16296 a string giving either a single attribute value or a list of attribute
16297 values, one for each alternative.
16299 The form of each of the above specifications is shown below. In each
16300 case, NAME is a string specifying the attribute to be set.
16302 `(set_attr NAME VALUE-STRING)'
16303 VALUE-STRING is either a string giving the desired attribute value,
16304 or a string containing a comma-separated list giving the values for
16305 succeeding alternatives. The number of elements must match the
16306 number of alternatives in the constraint of the insn pattern.
16308 Note that it may be useful to specify `*' for some alternative, in
16309 which case the attribute will assume its default value for insns
16310 matching that alternative.
16312 `(set_attr_alternative NAME [VALUE1 VALUE2 ...])'
16313 Depending on the alternative of the insn, the value will be one of
16314 the specified values. This is a shorthand for using a `cond' with
16315 tests on the `alternative' attribute.
16317 `(set (attr NAME) VALUE)'
16318 The first operand of this `set' must be the special RTL expression
16319 `attr', whose sole operand is a string giving the name of the
16320 attribute being set. VALUE is the value of the attribute.
16322 The following shows three different ways of representing the same
16323 attribute value specification:
16325 (set_attr "type" "load,store,arith")
16327 (set_attr_alternative "type"
16328 [(const_string "load") (const_string "store")
16329 (const_string "arith")])
16332 (cond [(eq_attr "alternative" "1") (const_string "load")
16333 (eq_attr "alternative" "2") (const_string "store")]
16334 (const_string "arith")))
16336 The `define_asm_attributes' expression provides a mechanism to specify
16337 the attributes assigned to insns produced from an `asm' statement. It
16340 (define_asm_attributes [ATTR-SETS])
16342 where ATTR-SETS is specified the same as for both the `define_insn' and
16343 the `define_peephole' expressions.
16345 These values will typically be the "worst case" attribute values. For
16346 example, they might indicate that the condition code will be clobbered.
16348 A specification for a `length' attribute is handled specially. The
16349 way to compute the length of an `asm' insn is to multiply the length
16350 specified in the expression `define_asm_attributes' by the number of
16351 machine instructions specified in the `asm' statement, determined by
16352 counting the number of semicolons and newlines in the string.
16353 Therefore, the value of the `length' attribute specified in a
16354 `define_asm_attributes' should be the maximum possible length of a
16355 single machine instruction.
16358 File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes
16360 13.19.4 Example of Attribute Specifications
16361 -------------------------------------------
16363 The judicious use of defaulting is important in the efficient use of
16364 insn attributes. Typically, insns are divided into "types" and an
16365 attribute, customarily called `type', is used to represent this value.
16366 This attribute is normally used only to define the default value for
16367 other attributes. An example will clarify this usage.
16369 Assume we have a RISC machine with a condition code and in which only
16370 full-word operations are performed in registers. Let us assume that we
16371 can divide all insns into loads, stores, (integer) arithmetic
16372 operations, floating point operations, and branches.
16374 Here we will concern ourselves with determining the effect of an insn
16375 on the condition code and will limit ourselves to the following possible
16376 effects: The condition code can be set unpredictably (clobbered), not
16377 be changed, be set to agree with the results of the operation, or only
16378 changed if the item previously set into the condition code has been
16381 Here is part of a sample `md' file for such a machine:
16383 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith"))
16385 (define_attr "cc" "clobber,unchanged,set,change0"
16386 (cond [(eq_attr "type" "load")
16387 (const_string "change0")
16388 (eq_attr "type" "store,branch")
16389 (const_string "unchanged")
16390 (eq_attr "type" "arith")
16391 (if_then_else (match_operand:SI 0 "" "")
16392 (const_string "set")
16393 (const_string "clobber"))]
16394 (const_string "clobber")))
16397 [(set (match_operand:SI 0 "general_operand" "=r,r,m")
16398 (match_operand:SI 1 "general_operand" "r,m,r"))]
16404 [(set_attr "type" "arith,load,store")])
16406 Note that we assume in the above example that arithmetic operations
16407 performed on quantities smaller than a machine word clobber the
16408 condition code since they will set the condition code to a value
16409 corresponding to the full-word result.
16412 File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes
16414 13.19.5 Computing the Length of an Insn
16415 ---------------------------------------
16417 For many machines, multiple types of branch instructions are provided,
16418 each for different length branch displacements. In most cases, the
16419 assembler will choose the correct instruction to use. However, when
16420 the assembler cannot do so, GCC can when a special attribute, the
16421 `length' attribute, is defined. This attribute must be defined to have
16422 numeric values by specifying a null string in its `define_attr'.
16424 In the case of the `length' attribute, two additional forms of
16425 arithmetic terms are allowed in test expressions:
16428 This refers to the address of operand N of the current insn, which
16429 must be a `label_ref'.
16432 This refers to the address of the _current_ insn. It might have
16433 been more consistent with other usage to make this the address of
16434 the _next_ insn but this would be confusing because the length of
16435 the current insn is to be computed.
16437 For normal insns, the length will be determined by value of the
16438 `length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn
16439 patterns, the length is computed as the number of vectors multiplied by
16440 the size of each vector.
16442 Lengths are measured in addressable storage units (bytes).
16444 The following macros can be used to refine the length computation:
16446 `ADJUST_INSN_LENGTH (INSN, LENGTH)'
16447 If defined, modifies the length assigned to instruction INSN as a
16448 function of the context in which it is used. LENGTH is an lvalue
16449 that contains the initially computed length of the insn and should
16450 be updated with the correct length of the insn.
16452 This macro will normally not be required. A case in which it is
16453 required is the ROMP. On this machine, the size of an `addr_vec'
16454 insn must be increased by two to compensate for the fact that
16455 alignment may be required.
16457 The routine that returns `get_attr_length' (the value of the `length'
16458 attribute) can be used by the output routine to determine the form of
16459 the branch instruction to be written, as the example below illustrates.
16461 As an example of the specification of variable-length branches,
16462 consider the IBM 360. If we adopt the convention that a register will
16463 be set to the starting address of a function, we can jump to labels
16464 within 4k of the start using a four-byte instruction. Otherwise, we
16465 need a six-byte sequence to load the address from memory and then
16468 On such a machine, a pattern for a branch instruction might be
16469 specified as follows:
16471 (define_insn "jump"
16473 (label_ref (match_operand 0 "" "")))]
16476 return (get_attr_length (insn) == 4
16477 ? "b %l0" : "l r15,=a(%l0); br r15");
16479 [(set (attr "length")
16480 (if_then_else (lt (match_dup 0) (const_int 4096))
16485 File: gccint.info, Node: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes
16487 13.19.6 Constant Attributes
16488 ---------------------------
16490 A special form of `define_attr', where the expression for the default
16491 value is a `const' expression, indicates an attribute that is constant
16492 for a given run of the compiler. Constant attributes may be used to
16493 specify which variety of processor is used. For example,
16495 (define_attr "cpu" "m88100,m88110,m88000"
16497 (cond [(symbol_ref "TARGET_88100") (const_string "m88100")
16498 (symbol_ref "TARGET_88110") (const_string "m88110")]
16499 (const_string "m88000"))))
16501 (define_attr "memory" "fast,slow"
16503 (if_then_else (symbol_ref "TARGET_FAST_MEM")
16504 (const_string "fast")
16505 (const_string "slow"))))
16507 The routine generated for constant attributes has no parameters as it
16508 does not depend on any particular insn. RTL expressions used to define
16509 the value of a constant attribute may use the `symbol_ref' form, but
16510 may not use either the `match_operand' form or `eq_attr' forms
16511 involving insn attributes.
16514 File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Constant Attributes, Up: Insn Attributes
16516 13.19.7 Delay Slot Scheduling
16517 -----------------------------
16519 The insn attribute mechanism can be used to specify the requirements for
16520 delay slots, if any, on a target machine. An instruction is said to
16521 require a "delay slot" if some instructions that are physically after
16522 the instruction are executed as if they were located before it.
16523 Classic examples are branch and call instructions, which often execute
16524 the following instruction before the branch or call is performed.
16526 On some machines, conditional branch instructions can optionally
16527 "annul" instructions in the delay slot. This means that the
16528 instruction will not be executed for certain branch outcomes. Both
16529 instructions that annul if the branch is true and instructions that
16530 annul if the branch is false are supported.
16532 Delay slot scheduling differs from instruction scheduling in that
16533 determining whether an instruction needs a delay slot is dependent only
16534 on the type of instruction being generated, not on data flow between the
16535 instructions. See the next section for a discussion of data-dependent
16536 instruction scheduling.
16538 The requirement of an insn needing one or more delay slots is indicated
16539 via the `define_delay' expression. It has the following form:
16542 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1
16543 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2
16546 TEST is an attribute test that indicates whether this `define_delay'
16547 applies to a particular insn. If so, the number of required delay
16548 slots is determined by the length of the vector specified as the second
16549 argument. An insn placed in delay slot N must satisfy attribute test
16550 DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns
16551 may be annulled if the branch is true. Similarly, ANNUL-FALSE-N
16552 specifies which insns in the delay slot may be annulled if the branch
16553 is false. If annulling is not supported for that delay slot, `(nil)'
16556 For example, in the common case where branch and call insns require a
16557 single delay slot, which may contain any insn other than a branch or
16558 call, the following would be placed in the `md' file:
16560 (define_delay (eq_attr "type" "branch,call")
16561 [(eq_attr "type" "!branch,call") (nil) (nil)])
16563 Multiple `define_delay' expressions may be specified. In this case,
16564 each such expression specifies different delay slot requirements and
16565 there must be no insn for which tests in two `define_delay' expressions
16568 For example, if we have a machine that requires one delay slot for
16569 branches but two for calls, no delay slot can contain a branch or call
16570 insn, and any valid insn in the delay slot for the branch can be
16571 annulled if the branch is true, we might represent this as follows:
16573 (define_delay (eq_attr "type" "branch")
16574 [(eq_attr "type" "!branch,call")
16575 (eq_attr "type" "!branch,call")
16578 (define_delay (eq_attr "type" "call")
16579 [(eq_attr "type" "!branch,call") (nil) (nil)
16580 (eq_attr "type" "!branch,call") (nil) (nil)])
16583 File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes
16585 13.19.8 Specifying processor pipeline description
16586 -------------------------------------------------
16588 To achieve better performance, most modern processors (super-pipelined,
16589 superscalar RISC, and VLIW processors) have many "functional units" on
16590 which several instructions can be executed simultaneously. An
16591 instruction starts execution if its issue conditions are satisfied. If
16592 not, the instruction is stalled until its conditions are satisfied.
16593 Such "interlock (pipeline) delay" causes interruption of the fetching
16594 of successor instructions (or demands nop instructions, e.g. for some
16597 There are two major kinds of interlock delays in modern processors.
16598 The first one is a data dependence delay determining "instruction
16599 latency time". The instruction execution is not started until all
16600 source data have been evaluated by prior instructions (there are more
16601 complex cases when the instruction execution starts even when the data
16602 are not available but will be ready in given time after the instruction
16603 execution start). Taking the data dependence delays into account is
16604 simple. The data dependence (true, output, and anti-dependence) delay
16605 between two instructions is given by a constant. In most cases this
16606 approach is adequate. The second kind of interlock delays is a
16607 reservation delay. The reservation delay means that two instructions
16608 under execution will be in need of shared processors resources, i.e.
16609 buses, internal registers, and/or functional units, which are reserved
16610 for some time. Taking this kind of delay into account is complex
16611 especially for modern RISC processors.
16613 The task of exploiting more processor parallelism is solved by an
16614 instruction scheduler. For a better solution to this problem, the
16615 instruction scheduler has to have an adequate description of the
16616 processor parallelism (or "pipeline description"). GCC machine
16617 descriptions describe processor parallelism and functional unit
16618 reservations for groups of instructions with the aid of "regular
16621 The GCC instruction scheduler uses a "pipeline hazard recognizer" to
16622 figure out the possibility of the instruction issue by the processor on
16623 a given simulated processor cycle. The pipeline hazard recognizer is
16624 automatically generated from the processor pipeline description. The
16625 pipeline hazard recognizer generated from the machine description is
16626 based on a deterministic finite state automaton (DFA): the instruction
16627 issue is possible if there is a transition from one automaton state to
16628 another one. This algorithm is very fast, and furthermore, its speed
16629 is not dependent on processor complexity(1).
16631 The rest of this section describes the directives that constitute an
16632 automaton-based processor pipeline description. The order of these
16633 constructions within the machine description file is not important.
16635 The following optional construction describes names of automata
16636 generated and used for the pipeline hazards recognition. Sometimes the
16637 generated finite state automaton used by the pipeline hazard recognizer
16638 is large. If we use more than one automaton and bind functional units
16639 to the automata, the total size of the automata is usually less than
16640 the size of the single automaton. If there is no one such
16641 construction, only one finite state automaton is generated.
16643 (define_automaton AUTOMATA-NAMES)
16645 AUTOMATA-NAMES is a string giving names of the automata. The names
16646 are separated by commas. All the automata should have unique names.
16647 The automaton name is used in the constructions `define_cpu_unit' and
16648 `define_query_cpu_unit'.
16650 Each processor functional unit used in the description of instruction
16651 reservations should be described by the following construction.
16653 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME])
16655 UNIT-NAMES is a string giving the names of the functional units
16656 separated by commas. Don't use name `nothing', it is reserved for
16659 AUTOMATON-NAME is a string giving the name of the automaton with which
16660 the unit is bound. The automaton should be described in construction
16661 `define_automaton'. You should give "automaton-name", if there is a
16664 The assignment of units to automata are constrained by the uses of the
16665 units in insn reservations. The most important constraint is: if a
16666 unit reservation is present on a particular cycle of an alternative for
16667 an insn reservation, then some unit from the same automaton must be
16668 present on the same cycle for the other alternatives of the insn
16669 reservation. The rest of the constraints are mentioned in the
16670 description of the subsequent constructions.
16672 The following construction describes CPU functional units analogously
16673 to `define_cpu_unit'. The reservation of such units can be queried for
16674 an automaton state. The instruction scheduler never queries
16675 reservation of functional units for given automaton state. So as a
16676 rule, you don't need this construction. This construction could be
16677 used for future code generation goals (e.g. to generate VLIW insn
16680 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME])
16682 UNIT-NAMES is a string giving names of the functional units separated
16685 AUTOMATON-NAME is a string giving the name of the automaton with which
16688 The following construction is the major one to describe pipeline
16689 characteristics of an instruction.
16691 (define_insn_reservation INSN-NAME DEFAULT_LATENCY
16694 DEFAULT_LATENCY is a number giving latency time of the instruction.
16695 There is an important difference between the old description and the
16696 automaton based pipeline description. The latency time is used for all
16697 dependencies when we use the old description. In the automaton based
16698 pipeline description, the given latency time is only used for true
16699 dependencies. The cost of anti-dependencies is always zero and the
16700 cost of output dependencies is the difference between latency times of
16701 the producing and consuming insns (if the difference is negative, the
16702 cost is considered to be zero). You can always change the default
16703 costs for any description by using the target hook
16704 `TARGET_SCHED_ADJUST_COST' (*note Scheduling::).
16706 INSN-NAME is a string giving the internal name of the insn. The
16707 internal names are used in constructions `define_bypass' and in the
16708 automaton description file generated for debugging. The internal name
16709 has nothing in common with the names in `define_insn'. It is a good
16710 practice to use insn classes described in the processor manual.
16712 CONDITION defines what RTL insns are described by this construction.
16713 You should remember that you will be in trouble if CONDITION for two or
16714 more different `define_insn_reservation' constructions is TRUE for an
16715 insn. In this case what reservation will be used for the insn is not
16716 defined. Such cases are not checked during generation of the pipeline
16717 hazards recognizer because in general recognizing that two conditions
16718 may have the same value is quite difficult (especially if the conditions
16719 contain `symbol_ref'). It is also not checked during the pipeline
16720 hazard recognizer work because it would slow down the recognizer
16723 REGEXP is a string describing the reservation of the cpu's functional
16724 units by the instruction. The reservations are described by a regular
16725 expression according to the following syntax:
16727 regexp = regexp "," oneof
16730 oneof = oneof "|" allof
16733 allof = allof "+" repeat
16736 repeat = element "*" number
16739 element = cpu_function_unit_name
16745 * `,' is used for describing the start of the next cycle in the
16748 * `|' is used for describing a reservation described by the first
16749 regular expression *or* a reservation described by the second
16750 regular expression *or* etc.
16752 * `+' is used for describing a reservation described by the first
16753 regular expression *and* a reservation described by the second
16754 regular expression *and* etc.
16756 * `*' is used for convenience and simply means a sequence in which
16757 the regular expression are repeated NUMBER times with cycle
16758 advancing (see `,').
16760 * `cpu_function_unit_name' denotes reservation of the named
16763 * `reservation_name' -- see description of construction
16764 `define_reservation'.
16766 * `nothing' denotes no unit reservations.
16768 Sometimes unit reservations for different insns contain common parts.
16769 In such case, you can simplify the pipeline description by describing
16770 the common part by the following construction
16772 (define_reservation RESERVATION-NAME REGEXP)
16774 RESERVATION-NAME is a string giving name of REGEXP. Functional unit
16775 names and reservation names are in the same name space. So the
16776 reservation names should be different from the functional unit names
16777 and can not be the reserved name `nothing'.
16779 The following construction is used to describe exceptions in the
16780 latency time for given instruction pair. This is so called bypasses.
16782 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES
16785 NUMBER defines when the result generated by the instructions given in
16786 string OUT_INSN_NAMES will be ready for the instructions given in
16787 string IN_INSN_NAMES. The instructions in the string are separated by
16790 GUARD is an optional string giving the name of a C function which
16791 defines an additional guard for the bypass. The function will get the
16792 two insns as parameters. If the function returns zero the bypass will
16793 be ignored for this case. The additional guard is necessary to
16794 recognize complicated bypasses, e.g. when the consumer is only an
16795 address of insn `store' (not a stored value).
16797 The following five constructions are usually used to describe VLIW
16798 processors, or more precisely, to describe a placement of small
16799 instructions into VLIW instruction slots. They can be used for RISC
16802 (exclusion_set UNIT-NAMES UNIT-NAMES)
16803 (presence_set UNIT-NAMES PATTERNS)
16804 (final_presence_set UNIT-NAMES PATTERNS)
16805 (absence_set UNIT-NAMES PATTERNS)
16806 (final_absence_set UNIT-NAMES PATTERNS)
16808 UNIT-NAMES is a string giving names of functional units separated by
16811 PATTERNS is a string giving patterns of functional units separated by
16812 comma. Currently pattern is one unit or units separated by
16815 The first construction (`exclusion_set') means that each functional
16816 unit in the first string can not be reserved simultaneously with a unit
16817 whose name is in the second string and vice versa. For example, the
16818 construction is useful for describing processors (e.g. some SPARC
16819 processors) with a fully pipelined floating point functional unit which
16820 can execute simultaneously only single floating point insns or only
16821 double floating point insns.
16823 The second construction (`presence_set') means that each functional
16824 unit in the first string can not be reserved unless at least one of
16825 pattern of units whose names are in the second string is reserved.
16826 This is an asymmetric relation. For example, it is useful for
16827 description that VLIW `slot1' is reserved after `slot0' reservation.
16828 We could describe it by the following construction
16830 (presence_set "slot1" "slot0")
16832 Or `slot1' is reserved only after `slot0' and unit `b0' reservation.
16833 In this case we could write
16835 (presence_set "slot1" "slot0 b0")
16837 The third construction (`final_presence_set') is analogous to
16838 `presence_set'. The difference between them is when checking is done.
16839 When an instruction is issued in given automaton state reflecting all
16840 current and planned unit reservations, the automaton state is changed.
16841 The first state is a source state, the second one is a result state.
16842 Checking for `presence_set' is done on the source state reservation,
16843 checking for `final_presence_set' is done on the result reservation.
16844 This construction is useful to describe a reservation which is actually
16845 two subsequent reservations. For example, if we use
16847 (presence_set "slot1" "slot0")
16849 the following insn will be never issued (because `slot1' requires
16850 `slot0' which is absent in the source state).
16852 (define_reservation "insn_and_nop" "slot0 + slot1")
16854 but it can be issued if we use analogous `final_presence_set'.
16856 The forth construction (`absence_set') means that each functional unit
16857 in the first string can be reserved only if each pattern of units whose
16858 names are in the second string is not reserved. This is an asymmetric
16859 relation (actually `exclusion_set' is analogous to this one but it is
16860 symmetric). For example, it is useful for description that VLIW
16861 `slot0' can not be reserved after `slot1' or `slot2' reservation. We
16862 could describe it by the following construction
16864 (absence_set "slot2" "slot0, slot1")
16866 Or `slot2' can not be reserved if `slot0' and unit `b0' are reserved
16867 or `slot1' and unit `b1' are reserved. In this case we could write
16869 (absence_set "slot2" "slot0 b0, slot1 b1")
16871 All functional units mentioned in a set should belong to the same
16874 The last construction (`final_absence_set') is analogous to
16875 `absence_set' but checking is done on the result (state) reservation.
16876 See comments for `final_presence_set'.
16878 You can control the generator of the pipeline hazard recognizer with
16879 the following construction.
16881 (automata_option OPTIONS)
16883 OPTIONS is a string giving options which affect the generated code.
16884 Currently there are the following options:
16886 * "no-minimization" makes no minimization of the automaton. This is
16887 only worth to do when we are debugging the description and need to
16888 look more accurately at reservations of states.
16890 * "time" means printing additional time statistics about generation
16893 * "v" means a generation of the file describing the result automata.
16894 The file has suffix `.dfa' and can be used for the description
16895 verification and debugging.
16897 * "w" means a generation of warning instead of error for
16898 non-critical errors.
16900 * "ndfa" makes nondeterministic finite state automata. This affects
16901 the treatment of operator `|' in the regular expressions. The
16902 usual treatment of the operator is to try the first alternative
16903 and, if the reservation is not possible, the second alternative.
16904 The nondeterministic treatment means trying all alternatives, some
16905 of them may be rejected by reservations in the subsequent insns.
16907 * "progress" means output of a progress bar showing how many states
16908 were generated so far for automaton being processed. This is
16909 useful during debugging a DFA description. If you see too many
16910 generated states, you could interrupt the generator of the pipeline
16911 hazard recognizer and try to figure out a reason for generation of
16912 the huge automaton.
16914 As an example, consider a superscalar RISC machine which can issue
16915 three insns (two integer insns and one floating point insn) on the
16916 cycle but can finish only two insns. To describe this, we define the
16917 following functional units.
16919 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline")
16920 (define_cpu_unit "port0, port1")
16922 All simple integer insns can be executed in any integer pipeline and
16923 their result is ready in two cycles. The simple integer insns are
16924 issued into the first pipeline unless it is reserved, otherwise they
16925 are issued into the second pipeline. Integer division and
16926 multiplication insns can be executed only in the second integer
16927 pipeline and their results are ready correspondingly in 8 and 4 cycles.
16928 The integer division is not pipelined, i.e. the subsequent integer
16929 division insn can not be issued until the current division insn
16930 finished. Floating point insns are fully pipelined and their results
16931 are ready in 3 cycles. Where the result of a floating point insn is
16932 used by an integer insn, an additional delay of one cycle is incurred.
16933 To describe all of this we could specify
16935 (define_cpu_unit "div")
16937 (define_insn_reservation "simple" 2 (eq_attr "type" "int")
16938 "(i0_pipeline | i1_pipeline), (port0 | port1)")
16940 (define_insn_reservation "mult" 4 (eq_attr "type" "mult")
16941 "i1_pipeline, nothing*2, (port0 | port1)")
16943 (define_insn_reservation "div" 8 (eq_attr "type" "div")
16944 "i1_pipeline, div*7, div + (port0 | port1)")
16946 (define_insn_reservation "float" 3 (eq_attr "type" "float")
16947 "f_pipeline, nothing, (port0 | port1))
16949 (define_bypass 4 "float" "simple,mult,div")
16951 To simplify the description we could describe the following reservation
16953 (define_reservation "finish" "port0|port1")
16955 and use it in all `define_insn_reservation' as in the following
16958 (define_insn_reservation "simple" 2 (eq_attr "type" "int")
16959 "(i0_pipeline | i1_pipeline), finish")
16961 ---------- Footnotes ----------
16963 (1) However, the size of the automaton depends on processor
16964 complexity. To limit this effect, machine descriptions can split
16965 orthogonal parts of the machine description among several automata:
16966 but then, since each of these must be stepped independently, this
16967 does cause a small decrease in the algorithm's performance.
16970 File: gccint.info, Node: Conditional Execution, Next: Constant Definitions, Prev: Insn Attributes, Up: Machine Desc
16972 13.20 Conditional Execution
16973 ===========================
16975 A number of architectures provide for some form of conditional
16976 execution, or predication. The hallmark of this feature is the ability
16977 to nullify most of the instructions in the instruction set. When the
16978 instruction set is large and not entirely symmetric, it can be quite
16979 tedious to describe these forms directly in the `.md' file. An
16980 alternative is the `define_cond_exec' template.
16983 [PREDICATE-PATTERN]
16987 PREDICATE-PATTERN is the condition that must be true for the insn to
16988 be executed at runtime and should match a relational operator. One can
16989 use `match_operator' to match several relational operators at once.
16990 Any `match_operand' operands must have no more than one alternative.
16992 CONDITION is a C expression that must be true for the generated
16995 OUTPUT-TEMPLATE is a string similar to the `define_insn' output
16996 template (*note Output Template::), except that the `*' and `@' special
16997 cases do not apply. This is only useful if the assembly text for the
16998 predicate is a simple prefix to the main insn. In order to handle the
16999 general case, there is a global variable `current_insn_predicate' that
17000 will contain the entire predicate if the current insn is predicated,
17001 and will otherwise be `NULL'.
17003 When `define_cond_exec' is used, an implicit reference to the
17004 `predicable' instruction attribute is made. *Note Insn Attributes::.
17005 This attribute must be boolean (i.e. have exactly two elements in its
17006 LIST-OF-VALUES). Further, it must not be used with complex
17007 expressions. That is, the default and all uses in the insns must be a
17008 simple constant, not dependent on the alternative or anything else.
17010 For each `define_insn' for which the `predicable' attribute is true, a
17011 new `define_insn' pattern will be generated that matches a predicated
17012 version of the instruction. For example,
17014 (define_insn "addsi"
17015 [(set (match_operand:SI 0 "register_operand" "r")
17016 (plus:SI (match_operand:SI 1 "register_operand" "r")
17017 (match_operand:SI 2 "register_operand" "r")))]
17022 [(ne (match_operand:CC 0 "register_operand" "c")
17027 generates a new pattern
17031 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0))
17032 (set (match_operand:SI 0 "register_operand" "r")
17033 (plus:SI (match_operand:SI 1 "register_operand" "r")
17034 (match_operand:SI 2 "register_operand" "r"))))]
17035 "(TEST2) && (TEST1)"
17036 "(%3) add %2,%1,%0")
17039 File: gccint.info, Node: Constant Definitions, Next: Macros, Prev: Conditional Execution, Up: Machine Desc
17041 13.21 Constant Definitions
17042 ==========================
17044 Using literal constants inside instruction patterns reduces legibility
17045 and can be a maintenance problem.
17047 To overcome this problem, you may use the `define_constants'
17048 expression. It contains a vector of name-value pairs. From that point
17049 on, wherever any of the names appears in the MD file, it is as if the
17050 corresponding value had been written instead. You may use
17051 `define_constants' multiple times; each appearance adds more constants
17052 to the table. It is an error to redefine a constant with a different
17055 To come back to the a29k load multiple example, instead of
17058 [(match_parallel 0 "load_multiple_operation"
17059 [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
17060 (match_operand:SI 2 "memory_operand" "m"))
17062 (clobber (reg:SI 179))])]
17068 (define_constants [
17076 [(match_parallel 0 "load_multiple_operation"
17077 [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
17078 (match_operand:SI 2 "memory_operand" "m"))
17079 (use (reg:SI R_CR))
17080 (clobber (reg:SI R_CR))])]
17084 The constants that are defined with a define_constant are also output
17085 in the insn-codes.h header file as #defines.
17088 File: gccint.info, Node: Macros, Prev: Constant Definitions, Up: Machine Desc
17093 Ports often need to define similar patterns for more than one machine
17094 mode or for more than one rtx code. GCC provides some simple macro
17095 facilities to make this process easier.
17099 * Mode Macros:: Generating variations of patterns for different modes.
17100 * Code Macros:: Doing the same for codes.
17103 File: gccint.info, Node: Mode Macros, Next: Code Macros, Up: Macros
17105 13.22.1 Mode Macros
17106 -------------------
17108 Ports often need to define similar patterns for two or more different
17109 modes. For example:
17111 * If a processor has hardware support for both single and double
17112 floating-point arithmetic, the `SFmode' patterns tend to be very
17113 similar to the `DFmode' ones.
17115 * If a port uses `SImode' pointers in one configuration and `DImode'
17116 pointers in another, it will usually have very similar `SImode'
17117 and `DImode' patterns for manipulating pointers.
17119 Mode macros allow several patterns to be instantiated from one `.md'
17120 file template. They can be used with any type of rtx-based construct,
17121 such as a `define_insn', `define_split', or `define_peephole2'.
17125 * Defining Mode Macros:: Defining a new mode macro.
17126 * Substitutions:: Combining mode macros with substitutions
17127 * Examples:: Examples
17130 File: gccint.info, Node: Defining Mode Macros, Next: Substitutions, Up: Mode Macros
17132 13.22.1.1 Defining Mode Macros
17133 ..............................
17135 The syntax for defining a mode macro is:
17137 (define_mode_macro NAME [(MODE1 "COND1") ... (MODEN "CONDN")])
17139 This allows subsequent `.md' file constructs to use the mode suffix
17140 `:NAME'. Every construct that does so will be expanded N times, once
17141 with every use of `:NAME' replaced by `:MODE1', once with every use
17142 replaced by `:MODE2', and so on. In the expansion for a particular
17143 MODEI, every C condition will also require that CONDI be true.
17147 (define_mode_macro P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
17149 defines a new mode suffix `:P'. Every construct that uses `:P' will
17150 be expanded twice, once with every `:P' replaced by `:SI' and once with
17151 every `:P' replaced by `:DI'. The `:SI' version will only apply if
17152 `Pmode == SImode' and the `:DI' version will only apply if `Pmode ==
17155 As with other `.md' conditions, an empty string is treated as "always
17156 true". `(MODE "")' can also be abbreviated to `MODE'. For example:
17158 (define_mode_macro GPR [SI (DI "TARGET_64BIT")])
17160 means that the `:DI' expansion only applies if `TARGET_64BIT' but that
17161 the `:SI' expansion has no such constraint.
17163 Macros are applied in the order they are defined. This can be
17164 significant if two macros are used in a construct that requires
17165 substitutions. *Note Substitutions::.
17168 File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Macros, Up: Mode Macros
17170 13.22.1.2 Substitution in Mode Macros
17171 .....................................
17173 If an `.md' file construct uses mode macros, each version of the
17174 construct will often need slightly different strings or modes. For
17177 * When a `define_expand' defines several `addM3' patterns (*note
17178 Standard Names::), each expander will need to use the appropriate
17181 * When a `define_insn' defines several instruction patterns, each
17182 instruction will often use a different assembler mnemonic.
17184 * When a `define_insn' requires operands with different modes, using
17185 a macro for one of the operand modes usually requires a specific
17186 mode for the other operand(s).
17188 GCC supports such variations through a system of "mode attributes".
17189 There are two standard attributes: `mode', which is the name of the
17190 mode in lower case, and `MODE', which is the same thing in upper case.
17191 You can define other attributes using:
17193 (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")])
17195 where NAME is the name of the attribute and VALUEI is the value
17196 associated with MODEI.
17198 When GCC replaces some :MACRO with :MODE, it will scan each string and
17199 mode in the pattern for sequences of the form `<MACRO:ATTR>', where
17200 ATTR is the name of a mode attribute. If the attribute is defined for
17201 MODE, the whole `<...>' sequence will be replaced by the appropriate
17204 For example, suppose an `.md' file has:
17206 (define_mode_macro P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
17207 (define_mode_attr load [(SI "lw") (DI "ld")])
17209 If one of the patterns that uses `:P' contains the string
17210 `"<P:load>\t%0,%1"', the `SI' version of that pattern will use
17211 `"lw\t%0,%1"' and the `DI' version will use `"ld\t%0,%1"'.
17213 Here is an example of using an attribute for a mode:
17215 (define_mode_macro LONG [SI DI])
17216 (define_mode_attr SHORT [(SI "HI") (DI "SI")])
17218 (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...)
17220 The `MACRO:' prefix may be omitted, in which case the substitution
17221 will be attempted for every macro expansion.
17224 File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Macros
17226 13.22.1.3 Mode Macro Examples
17227 .............................
17229 Here is an example from the MIPS port. It defines the following modes
17230 and attributes (among others):
17232 (define_mode_macro GPR [SI (DI "TARGET_64BIT")])
17233 (define_mode_attr d [(SI "") (DI "d")])
17235 and uses the following template to define both `subsi3' and `subdi3':
17237 (define_insn "sub<mode>3"
17238 [(set (match_operand:GPR 0 "register_operand" "=d")
17239 (minus:GPR (match_operand:GPR 1 "register_operand" "d")
17240 (match_operand:GPR 2 "register_operand" "d")))]
17242 "<d>subu\t%0,%1,%2"
17243 [(set_attr "type" "arith")
17244 (set_attr "mode" "<MODE>")])
17246 This is exactly equivalent to:
17248 (define_insn "subsi3"
17249 [(set (match_operand:SI 0 "register_operand" "=d")
17250 (minus:SI (match_operand:SI 1 "register_operand" "d")
17251 (match_operand:SI 2 "register_operand" "d")))]
17254 [(set_attr "type" "arith")
17255 (set_attr "mode" "SI")])
17257 (define_insn "subdi3"
17258 [(set (match_operand:DI 0 "register_operand" "=d")
17259 (minus:DI (match_operand:DI 1 "register_operand" "d")
17260 (match_operand:DI 2 "register_operand" "d")))]
17263 [(set_attr "type" "arith")
17264 (set_attr "mode" "DI")])
17267 File: gccint.info, Node: Code Macros, Prev: Mode Macros, Up: Macros
17269 13.22.2 Code Macros
17270 -------------------
17272 Code macros operate in a similar way to mode macros. *Note Mode
17277 (define_code_macro NAME [(CODE1 "COND1") ... (CODEN "CONDN")])
17279 defines a pseudo rtx code NAME that can be instantiated as CODEI if
17280 condition CONDI is true. Each CODEI must have the same rtx format.
17281 *Note RTL Classes::.
17283 As with mode macros, each pattern that uses NAME will be expanded N
17284 times, once with all uses of NAME replaced by CODE1, once with all uses
17285 replaced by CODE2, and so on. *Note Defining Mode Macros::.
17287 It is possible to define attributes for codes as well as for modes.
17288 There are two standard code attributes: `code', the name of the code in
17289 lower case, and `CODE', the name of the code in upper case. Other
17290 attributes are defined using:
17292 (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")])
17294 Here's an example of code macros in action, taken from the MIPS port:
17296 (define_code_macro any_cond [unordered ordered unlt unge uneq ltgt unle ungt
17297 eq ne gt ge lt le gtu geu ltu leu])
17299 (define_expand "b<code>"
17301 (if_then_else (any_cond:CC (cc0)
17303 (label_ref (match_operand 0 ""))
17307 gen_conditional_branch (operands, <CODE>);
17311 This is equivalent to:
17313 (define_expand "bunordered"
17315 (if_then_else (unordered:CC (cc0)
17317 (label_ref (match_operand 0 ""))
17321 gen_conditional_branch (operands, UNORDERED);
17325 (define_expand "bordered"
17327 (if_then_else (ordered:CC (cc0)
17329 (label_ref (match_operand 0 ""))
17333 gen_conditional_branch (operands, ORDERED);
17340 File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top
17342 14 Target Description Macros and Functions
17343 ******************************************
17345 In addition to the file `MACHINE.md', a machine description includes a
17346 C header file conventionally given the name `MACHINE.h' and a C source
17347 file named `MACHINE.c'. The header file defines numerous macros that
17348 convey the information about the target machine that does not fit into
17349 the scheme of the `.md' file. The file `tm.h' should be a link to
17350 `MACHINE.h'. The header file `config.h' includes `tm.h' and most
17351 compiler source files include `config.h'. The source file defines a
17352 variable `targetm', which is a structure containing pointers to
17353 functions and data relating to the target machine. `MACHINE.c' should
17354 also contain their definitions, if they are not defined elsewhere in
17355 GCC, and other functions called through the macros defined in the `.h'
17360 * Target Structure:: The `targetm' variable.
17361 * Driver:: Controlling how the driver runs the compilation passes.
17362 * Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'.
17363 * Per-Function Data:: Defining data structures for per-function information.
17364 * Storage Layout:: Defining sizes and alignments of data.
17365 * Type Layout:: Defining sizes and properties of basic user data types.
17366 * Registers:: Naming and describing the hardware registers.
17367 * Register Classes:: Defining the classes of hardware registers.
17368 * Stack and Calling:: Defining which way the stack grows and by how much.
17369 * Varargs:: Defining the varargs macros.
17370 * Trampolines:: Code set up at run time to enter a nested function.
17371 * Library Calls:: Controlling how library routines are implicitly called.
17372 * Addressing Modes:: Defining addressing modes valid for memory operands.
17373 * Condition Code:: Defining how insns update the condition code.
17374 * Costs:: Defining relative costs of different operations.
17375 * Scheduling:: Adjusting the behavior of the instruction scheduler.
17376 * Sections:: Dividing storage into text, data, and other sections.
17377 * PIC:: Macros for position independent code.
17378 * Assembler Format:: Defining how to write insns and pseudo-ops to output.
17379 * Debugging Info:: Defining the format of debugging output.
17380 * Floating Point:: Handling floating point for cross-compilers.
17381 * Mode Switching:: Insertion of mode-switching instructions.
17382 * Target Attributes:: Defining target-specific uses of `__attribute__'.
17383 * MIPS Coprocessors:: MIPS coprocessor support and how to customize it.
17384 * PCH Target:: Validity checking for precompiled headers.
17385 * C++ ABI:: Controlling C++ ABI changes.
17386 * Misc:: Everything else.
17389 File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros
17391 14.1 The Global `targetm' Variable
17392 ==================================
17394 -- Variable: struct gcc_target targetm
17395 The target `.c' file must define the global `targetm' variable
17396 which contains pointers to functions and data relating to the
17397 target machine. The variable is declared in `target.h';
17398 `target-def.h' defines the macro `TARGET_INITIALIZER' which is
17399 used to initialize the variable, and macros for the default
17400 initializers for elements of the structure. The `.c' file should
17401 override those macros for which the default definition is
17402 inappropriate. For example:
17403 #include "target.h"
17404 #include "target-def.h"
17406 /* Initialize the GCC target structure. */
17408 #undef TARGET_COMP_TYPE_ATTRIBUTES
17409 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes
17411 struct gcc_target targetm = TARGET_INITIALIZER;
17413 Where a macro should be defined in the `.c' file in this manner to form
17414 part of the `targetm' structure, it is documented below as a "Target
17415 Hook" with a prototype. Many macros will change in future from being
17416 defined in the `.h' file to being part of the `targetm' structure.
17419 File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros
17421 14.2 Controlling the Compilation Driver, `gcc'
17422 ==============================================
17424 You can control the compilation driver.
17426 -- Macro: SWITCH_TAKES_ARG (CHAR)
17427 A C expression which determines whether the option `-CHAR' takes
17428 arguments. The value should be the number of arguments that
17429 option takes-zero, for many options.
17431 By default, this macro is defined as `DEFAULT_SWITCH_TAKES_ARG',
17432 which handles the standard options properly. You need not define
17433 `SWITCH_TAKES_ARG' unless you wish to add additional options which
17434 take arguments. Any redefinition should call
17435 `DEFAULT_SWITCH_TAKES_ARG' and then check for additional options.
17437 -- Macro: WORD_SWITCH_TAKES_ARG (NAME)
17438 A C expression which determines whether the option `-NAME' takes
17439 arguments. The value should be the number of arguments that
17440 option takes-zero, for many options. This macro rather than
17441 `SWITCH_TAKES_ARG' is used for multi-character option names.
17443 By default, this macro is defined as
17444 `DEFAULT_WORD_SWITCH_TAKES_ARG', which handles the standard options
17445 properly. You need not define `WORD_SWITCH_TAKES_ARG' unless you
17446 wish to add additional options which take arguments. Any
17447 redefinition should call `DEFAULT_WORD_SWITCH_TAKES_ARG' and then
17448 check for additional options.
17450 -- Macro: SWITCH_CURTAILS_COMPILATION (CHAR)
17451 A C expression which determines whether the option `-CHAR' stops
17452 compilation before the generation of an executable. The value is
17453 boolean, nonzero if the option does stop an executable from being
17454 generated, zero otherwise.
17456 By default, this macro is defined as
17457 `DEFAULT_SWITCH_CURTAILS_COMPILATION', which handles the standard
17458 options properly. You need not define
17459 `SWITCH_CURTAILS_COMPILATION' unless you wish to add additional
17460 options which affect the generation of an executable. Any
17461 redefinition should call `DEFAULT_SWITCH_CURTAILS_COMPILATION' and
17462 then check for additional options.
17464 -- Macro: SWITCHES_NEED_SPACES
17465 A string-valued C expression which enumerates the options for which
17466 the linker needs a space between the option and its argument.
17468 If this macro is not defined, the default value is `""'.
17470 -- Macro: TARGET_OPTION_TRANSLATE_TABLE
17471 If defined, a list of pairs of strings, the first of which is a
17472 potential command line target to the `gcc' driver program, and the
17473 second of which is a space-separated (tabs and other whitespace
17474 are not supported) list of options with which to replace the first
17475 option. The target defining this list is responsible for assuring
17476 that the results are valid. Replacement options may not be the
17477 `--opt' style, they must be the `-opt' style. It is the intention
17478 of this macro to provide a mechanism for substitution that affects
17479 the multilibs chosen, such as one option that enables many
17480 options, some of which select multilibs. Example nonsensical
17481 definition, where `-malt-abi', `-EB', and `-mspoo' cause different
17482 multilibs to be chosen:
17484 #define TARGET_OPTION_TRANSLATE_TABLE \
17485 { "-fast", "-march=fast-foo -malt-abi -I/usr/fast-foo" }, \
17486 { "-compat", "-EB -malign=4 -mspoo" }
17488 -- Macro: DRIVER_SELF_SPECS
17489 A list of specs for the driver itself. It should be a suitable
17490 initializer for an array of strings, with no surrounding braces.
17492 The driver applies these specs to its own command line between
17493 loading default `specs' files (but not command-line specified
17494 ones) and choosing the multilib directory or running any
17495 subcommands. It applies them in the order given, so each spec can
17496 depend on the options added by earlier ones. It is also possible
17497 to remove options using `%<OPTION' in the usual way.
17499 This macro can be useful when a port has several interdependent
17500 target options. It provides a way of standardizing the command
17501 line so that the other specs are easier to write.
17503 Do not define this macro if it does not need to do anything.
17505 -- Macro: OPTION_DEFAULT_SPECS
17506 A list of specs used to support configure-time default options
17507 (i.e. `--with' options) in the driver. It should be a suitable
17508 initializer for an array of structures, each containing two
17509 strings, without the outermost pair of surrounding braces.
17511 The first item in the pair is the name of the default. This must
17512 match the code in `config.gcc' for the target. The second item is
17513 a spec to apply if a default with this name was specified. The
17514 string `%(VALUE)' in the spec will be replaced by the value of the
17515 default everywhere it occurs.
17517 The driver will apply these specs to its own command line between
17518 loading default `specs' files and processing `DRIVER_SELF_SPECS',
17519 using the same mechanism as `DRIVER_SELF_SPECS'.
17521 Do not define this macro if it does not need to do anything.
17524 A C string constant that tells the GCC driver program options to
17525 pass to CPP. It can also specify how to translate options you
17526 give to GCC into options for GCC to pass to the CPP.
17528 Do not define this macro if it does not need to do anything.
17530 -- Macro: CPLUSPLUS_CPP_SPEC
17531 This macro is just like `CPP_SPEC', but is used for C++, rather
17532 than C. If you do not define this macro, then the value of
17533 `CPP_SPEC' (if any) will be used instead.
17536 A C string constant that tells the GCC driver program options to
17537 pass to `cc1', `cc1plus', `f771', and the other language front
17538 ends. It can also specify how to translate options you give to
17539 GCC into options for GCC to pass to front ends.
17541 Do not define this macro if it does not need to do anything.
17543 -- Macro: CC1PLUS_SPEC
17544 A C string constant that tells the GCC driver program options to
17545 pass to `cc1plus'. It can also specify how to translate options
17546 you give to GCC into options for GCC to pass to the `cc1plus'.
17548 Do not define this macro if it does not need to do anything. Note
17549 that everything defined in CC1_SPEC is already passed to `cc1plus'
17550 so there is no need to duplicate the contents of CC1_SPEC in
17554 A C string constant that tells the GCC driver program options to
17555 pass to the assembler. It can also specify how to translate
17556 options you give to GCC into options for GCC to pass to the
17557 assembler. See the file `sun3.h' for an example of this.
17559 Do not define this macro if it does not need to do anything.
17561 -- Macro: ASM_FINAL_SPEC
17562 A C string constant that tells the GCC driver program how to run
17563 any programs which cleanup after the normal assembler. Normally,
17564 this is not needed. See the file `mips.h' for an example of this.
17566 Do not define this macro if it does not need to do anything.
17568 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT
17569 Define this macro, with no value, if the driver should give the
17570 assembler an argument consisting of a single dash, `-', to
17571 instruct it to read from its standard input (which will be a pipe
17572 connected to the output of the compiler proper). This argument is
17573 given after any `-o' option specifying the name of the output file.
17575 If you do not define this macro, the assembler is assumed to read
17576 its standard input if given no non-option arguments. If your
17577 assembler cannot read standard input at all, use a `%{pipe:%e}'
17578 construct; see `mips.h' for instance.
17580 -- Macro: LINK_SPEC
17581 A C string constant that tells the GCC driver program options to
17582 pass to the linker. It can also specify how to translate options
17583 you give to GCC into options for GCC to pass to the linker.
17585 Do not define this macro if it does not need to do anything.
17588 Another C string constant used much like `LINK_SPEC'. The
17589 difference between the two is that `LIB_SPEC' is used at the end
17590 of the command given to the linker.
17592 If this macro is not defined, a default is provided that loads the
17593 standard C library from the usual place. See `gcc.c'.
17595 -- Macro: LIBGCC_SPEC
17596 Another C string constant that tells the GCC driver program how
17597 and when to place a reference to `libgcc.a' into the linker
17598 command line. This constant is placed both before and after the
17599 value of `LIB_SPEC'.
17601 If this macro is not defined, the GCC driver provides a default
17602 that passes the string `-lgcc' to the linker.
17604 -- Macro: REAL_LIBGCC_SPEC
17605 By default, if `ENABLE_SHARED_LIBGCC' is defined, the
17606 `LIBGCC_SPEC' is not directly used by the driver program but is
17607 instead modified to refer to different versions of `libgcc.a'
17608 depending on the values of the command line flags `-static',
17609 `-shared', `-static-libgcc', and `-shared-libgcc'. On targets
17610 where these modifications are inappropriate, define
17611 `REAL_LIBGCC_SPEC' instead. `REAL_LIBGCC_SPEC' tells the driver
17612 how to place a reference to `libgcc' on the link command line,
17613 but, unlike `LIBGCC_SPEC', it is used unmodified.
17615 -- Macro: USE_LD_AS_NEEDED
17616 A macro that controls the modifications to `LIBGCC_SPEC' mentioned
17617 in `REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that
17618 uses -as-needed and the shared libgcc in place of the static
17619 exception handler library, when linking without any of `-static',
17620 `-static-libgcc', or `-shared-libgcc'.
17622 -- Macro: LINK_EH_SPEC
17623 If defined, this C string constant is added to `LINK_SPEC'. When
17624 `USE_LD_AS_NEEDED' is zero or undefined, it also affects the
17625 modifications to `LIBGCC_SPEC' mentioned in `REAL_LIBGCC_SPEC'.
17627 -- Macro: STARTFILE_SPEC
17628 Another C string constant used much like `LINK_SPEC'. The
17629 difference between the two is that `STARTFILE_SPEC' is used at the
17630 very beginning of the command given to the linker.
17632 If this macro is not defined, a default is provided that loads the
17633 standard C startup file from the usual place. See `gcc.c'.
17635 -- Macro: ENDFILE_SPEC
17636 Another C string constant used much like `LINK_SPEC'. The
17637 difference between the two is that `ENDFILE_SPEC' is used at the
17638 very end of the command given to the linker.
17640 Do not define this macro if it does not need to do anything.
17642 -- Macro: THREAD_MODEL_SPEC
17643 GCC `-v' will print the thread model GCC was configured to use.
17644 However, this doesn't work on platforms that are multilibbed on
17645 thread models, such as AIX 4.3. On such platforms, define
17646 `THREAD_MODEL_SPEC' such that it evaluates to a string without
17647 blanks that names one of the recognized thread models. `%*', the
17648 default value of this macro, will expand to the value of
17649 `thread_file' set in `config.gcc'.
17651 -- Macro: SYSROOT_SUFFIX_SPEC
17652 Define this macro to add a suffix to the target sysroot when GCC is
17653 configured with a sysroot. This will cause GCC to search for
17654 usr/lib, et al, within sysroot+suffix.
17656 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC
17657 Define this macro to add a headers_suffix to the target sysroot
17658 when GCC is configured with a sysroot. This will cause GCC to
17659 pass the updated sysroot+headers_suffix to CPP, causing it to
17660 search for usr/include, et al, within sysroot+headers_suffix.
17662 -- Macro: EXTRA_SPECS
17663 Define this macro to provide additional specifications to put in
17664 the `specs' file that can be used in various specifications like
17667 The definition should be an initializer for an array of structures,
17668 containing a string constant, that defines the specification name,
17669 and a string constant that provides the specification.
17671 Do not define this macro if it does not need to do anything.
17673 `EXTRA_SPECS' is useful when an architecture contains several
17674 related targets, which have various `..._SPECS' which are similar
17675 to each other, and the maintainer would like one central place to
17676 keep these definitions.
17678 For example, the PowerPC System V.4 targets use `EXTRA_SPECS' to
17679 define either `_CALL_SYSV' when the System V calling sequence is
17680 used or `_CALL_AIX' when the older AIX-based calling sequence is
17683 The `config/rs6000/rs6000.h' target file defines:
17685 #define EXTRA_SPECS \
17686 { "cpp_sysv_default", CPP_SYSV_DEFAULT },
17688 #define CPP_SYS_DEFAULT ""
17690 The `config/rs6000/sysv.h' target file defines:
17693 "%{posix: -D_POSIX_SOURCE } \
17694 %{mcall-sysv: -D_CALL_SYSV } \
17695 %{!mcall-sysv: %(cpp_sysv_default) } \
17696 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}"
17698 #undef CPP_SYSV_DEFAULT
17699 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV"
17701 while the `config/rs6000/eabiaix.h' target file defines
17702 `CPP_SYSV_DEFAULT' as:
17704 #undef CPP_SYSV_DEFAULT
17705 #define CPP_SYSV_DEFAULT "-D_CALL_AIX"
17707 -- Macro: LINK_LIBGCC_SPECIAL_1
17708 Define this macro if the driver program should find the library
17709 `libgcc.a'. If you do not define this macro, the driver program
17710 will pass the argument `-lgcc' to tell the linker to do the search.
17712 -- Macro: LINK_GCC_C_SEQUENCE_SPEC
17713 The sequence in which libgcc and libc are specified to the linker.
17714 By default this is `%G %L %G'.
17716 -- Macro: LINK_COMMAND_SPEC
17717 A C string constant giving the complete command line need to
17718 execute the linker. When you do this, you will need to update
17719 your port each time a change is made to the link command line
17720 within `gcc.c'. Therefore, define this macro only if you need to
17721 completely redefine the command line for invoking the linker and
17722 there is no other way to accomplish the effect you need.
17723 Overriding this macro may be avoidable by overriding
17724 `LINK_GCC_C_SEQUENCE_SPEC' instead.
17726 -- Macro: LINK_ELIMINATE_DUPLICATE_LDIRECTORIES
17727 A nonzero value causes `collect2' to remove duplicate
17728 `-LDIRECTORY' search directories from linking commands. Do not
17729 give it a nonzero value if removing duplicate search directories
17730 changes the linker's semantics.
17732 -- Macro: MULTILIB_DEFAULTS
17733 Define this macro as a C expression for the initializer of an
17734 array of string to tell the driver program which options are
17735 defaults for this target and thus do not need to be handled
17736 specially when using `MULTILIB_OPTIONS'.
17738 Do not define this macro if `MULTILIB_OPTIONS' is not defined in
17739 the target makefile fragment or if none of the options listed in
17740 `MULTILIB_OPTIONS' are set by default. *Note Target Fragment::.
17742 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR
17743 Define this macro to tell `gcc' that it should only translate a
17744 `-B' prefix into a `-L' linker option if the prefix indicates an
17745 absolute file name.
17747 -- Macro: MD_EXEC_PREFIX
17748 If defined, this macro is an additional prefix to try after
17749 `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the
17750 `-b' option is used, or the compiler is built as a cross compiler.
17751 If you define `MD_EXEC_PREFIX', then be sure to add it to the
17752 list of directories used to find the assembler in `configure.in'.
17754 -- Macro: STANDARD_STARTFILE_PREFIX
17755 Define this macro as a C string constant if you wish to override
17756 the standard choice of `libdir' as the default prefix to try when
17757 searching for startup files such as `crt0.o'.
17758 `STANDARD_STARTFILE_PREFIX' is not searched when the compiler is
17759 built as a cross compiler.
17761 -- Macro: STANDARD_STARTFILE_PREFIX_1
17762 Define this macro as a C string constant if you wish to override
17763 the standard choice of `/lib' as a prefix to try after the default
17764 prefix when searching for startup files such as `crt0.o'.
17765 `STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is
17766 built as a cross compiler.
17768 -- Macro: STANDARD_STARTFILE_PREFIX_2
17769 Define this macro as a C string constant if you wish to override
17770 the standard choice of `/lib' as yet another prefix to try after
17771 the default prefix when searching for startup files such as
17772 `crt0.o'. `STANDARD_STARTFILE_PREFIX_2' is not searched when the
17773 compiler is built as a cross compiler.
17775 -- Macro: MD_STARTFILE_PREFIX
17776 If defined, this macro supplies an additional prefix to try after
17777 the standard prefixes. `MD_EXEC_PREFIX' is not searched when the
17778 `-b' option is used, or when the compiler is built as a cross
17781 -- Macro: MD_STARTFILE_PREFIX_1
17782 If defined, this macro supplies yet another prefix to try after the
17783 standard prefixes. It is not searched when the `-b' option is
17784 used, or when the compiler is built as a cross compiler.
17786 -- Macro: INIT_ENVIRONMENT
17787 Define this macro as a C string constant if you wish to set
17788 environment variables for programs called by the driver, such as
17789 the assembler and loader. The driver passes the value of this
17790 macro to `putenv' to initialize the necessary environment
17793 -- Macro: LOCAL_INCLUDE_DIR
17794 Define this macro as a C string constant if you wish to override
17795 the standard choice of `/usr/local/include' as the default prefix
17796 to try when searching for local header files. `LOCAL_INCLUDE_DIR'
17797 comes before `SYSTEM_INCLUDE_DIR' in the search order.
17799 Cross compilers do not search either `/usr/local/include' or its
17802 -- Macro: MODIFY_TARGET_NAME
17803 Define this macro if you wish to define command-line switches that
17804 modify the default target name.
17806 For each switch, you can include a string to be appended to the
17807 first part of the configuration name or a string to be deleted
17808 from the configuration name, if present. The definition should be
17809 an initializer for an array of structures. Each array element
17810 should have three elements: the switch name (a string constant,
17811 including the initial dash), one of the enumeration codes `ADD' or
17812 `DELETE' to indicate whether the string should be inserted or
17813 deleted, and the string to be inserted or deleted (a string
17816 For example, on a machine where `64' at the end of the
17817 configuration name denotes a 64-bit target and you want the `-32'
17818 and `-64' switches to select between 32- and 64-bit targets, you
17821 #define MODIFY_TARGET_NAME \
17822 { { "-32", DELETE, "64"}, \
17823 {"-64", ADD, "64"}}
17825 -- Macro: SYSTEM_INCLUDE_DIR
17826 Define this macro as a C string constant if you wish to specify a
17827 system-specific directory to search for header files before the
17828 standard directory. `SYSTEM_INCLUDE_DIR' comes before
17829 `STANDARD_INCLUDE_DIR' in the search order.
17831 Cross compilers do not use this macro and do not search the
17832 directory specified.
17834 -- Macro: STANDARD_INCLUDE_DIR
17835 Define this macro as a C string constant if you wish to override
17836 the standard choice of `/usr/include' as the default prefix to try
17837 when searching for header files.
17839 Cross compilers ignore this macro and do not search either
17840 `/usr/include' or its replacement.
17842 -- Macro: STANDARD_INCLUDE_COMPONENT
17843 The "component" corresponding to `STANDARD_INCLUDE_DIR'. See
17844 `INCLUDE_DEFAULTS', below, for the description of components. If
17845 you do not define this macro, no component is used.
17847 -- Macro: INCLUDE_DEFAULTS
17848 Define this macro if you wish to override the entire default
17849 search path for include files. For a native compiler, the default
17850 search path usually consists of `GCC_INCLUDE_DIR',
17851 `LOCAL_INCLUDE_DIR', `SYSTEM_INCLUDE_DIR',
17852 `GPLUSPLUS_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition,
17853 `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are defined
17854 automatically by `Makefile', and specify private search areas for
17855 GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used only for C++
17858 The definition should be an initializer for an array of structures.
17859 Each array element should have four elements: the directory name (a
17860 string constant), the component name (also a string constant), a
17861 flag for C++-only directories, and a flag showing that the
17862 includes in the directory don't need to be wrapped in `extern `C''
17863 when compiling C++. Mark the end of the array with a null element.
17865 The component name denotes what GNU package the include file is
17866 part of, if any, in all uppercase letters. For example, it might
17867 be `GCC' or `BINUTILS'. If the package is part of a
17868 vendor-supplied operating system, code the component name as `0'.
17870 For example, here is the definition used for VAX/VMS:
17872 #define INCLUDE_DEFAULTS \
17874 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \
17875 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \
17876 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \
17881 Here is the order of prefixes tried for exec files:
17883 1. Any prefixes specified by the user with `-B'.
17885 2. The environment variable `GCC_EXEC_PREFIX', if any.
17887 3. The directories specified by the environment variable
17890 4. The macro `STANDARD_EXEC_PREFIX'.
17892 5. `/usr/lib/gcc/'.
17894 6. The macro `MD_EXEC_PREFIX', if any.
17896 Here is the order of prefixes tried for startfiles:
17898 1. Any prefixes specified by the user with `-B'.
17900 2. The environment variable `GCC_EXEC_PREFIX', if any.
17902 3. The directories specified by the environment variable
17903 `LIBRARY_PATH' (or port-specific name; native only, cross
17904 compilers do not use this).
17906 4. The macro `STANDARD_EXEC_PREFIX'.
17908 5. `/usr/lib/gcc/'.
17910 6. The macro `MD_EXEC_PREFIX', if any.
17912 7. The macro `MD_STARTFILE_PREFIX', if any.
17914 8. The macro `STANDARD_STARTFILE_PREFIX'.
17921 File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros
17923 14.3 Run-time Target Specification
17924 ==================================
17926 Here are run-time target specifications.
17928 -- Macro: TARGET_CPU_CPP_BUILTINS ()
17929 This function-like macro expands to a block of code that defines
17930 built-in preprocessor macros and assertions for the target cpu,
17931 using the functions `builtin_define', `builtin_define_std' and
17932 `builtin_assert'. When the front end calls this macro it provides
17933 a trailing semicolon, and since it has finished command line
17934 option processing your code can use those results freely.
17936 `builtin_assert' takes a string in the form you pass to the
17937 command-line option `-A', such as `cpu=mips', and creates the
17938 assertion. `builtin_define' takes a string in the form accepted
17939 by option `-D' and unconditionally defines the macro.
17941 `builtin_define_std' takes a string representing the name of an
17942 object-like macro. If it doesn't lie in the user's namespace,
17943 `builtin_define_std' defines it unconditionally. Otherwise, it
17944 defines a version with two leading underscores, and another version
17945 with two leading and trailing underscores, and defines the original
17946 only if an ISO standard was not requested on the command line. For
17947 example, passing `unix' defines `__unix', `__unix__' and possibly
17948 `unix'; passing `_mips' defines `__mips', `__mips__' and possibly
17949 `_mips', and passing `_ABI64' defines only `_ABI64'.
17951 You can also test for the C dialect being compiled. The variable
17952 `c_language' is set to one of `clk_c', `clk_cplusplus' or
17953 `clk_objective_c'. Note that if we are preprocessing assembler,
17954 this variable will be `clk_c' but the function-like macro
17955 `preprocessing_asm_p()' will return true, so you might want to
17956 check for that first. If you need to check for strict ANSI, the
17957 variable `flag_iso' can be used. The function-like macro
17958 `preprocessing_trad_p()' can be used to check for traditional
17961 -- Macro: TARGET_OS_CPP_BUILTINS ()
17962 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional
17963 and is used for the target operating system instead.
17965 -- Macro: TARGET_OBJFMT_CPP_BUILTINS ()
17966 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional
17967 and is used for the target object format. `elfos.h' uses this
17968 macro to define `__ELF__', so you probably do not need to define
17971 -- Variable: extern int target_flags
17972 This variable is declared in `options.h', which is included before
17973 any target-specific headers.
17975 -- Variable: Target Hook int TARGET_DEFAULT_TARGET_FLAGS
17976 This variable specifies the initial value of `target_flags'. Its
17977 default setting is 0.
17979 -- Target Hook: bool TARGET_HANDLE_OPTION (size_t CODE, const char
17981 This hook is called whenever the user specifies one of the
17982 target-specific options described by the `.opt' definition files
17983 (*note Options::). It has the opportunity to do some
17984 option-specific processing and should return true if the option is
17985 valid. The default definition does nothing but return true.
17987 CODE specifies the `OPT_NAME' enumeration value associated with
17988 the selected option; NAME is just a rendering of the option name
17989 in which non-alphanumeric characters are replaced by underscores.
17990 ARG specifies the string argument and is null if no argument was
17991 given. If the option is flagged as a `UInteger' (*note Option
17992 properties::), VALUE is the numeric value of the argument.
17993 Otherwise VALUE is 1 if the positive form of the option was used
17994 and 0 if the "no-" form was.
17996 -- Macro: TARGET_VERSION
17997 This macro is a C statement to print on `stderr' a string
17998 describing the particular machine description choice. Every
17999 machine description should define `TARGET_VERSION'. For example:
18002 #define TARGET_VERSION \
18003 fprintf (stderr, " (68k, Motorola syntax)");
18005 #define TARGET_VERSION \
18006 fprintf (stderr, " (68k, MIT syntax)");
18009 -- Macro: OVERRIDE_OPTIONS
18010 Sometimes certain combinations of command options do not make
18011 sense on a particular target machine. You can define a macro
18012 `OVERRIDE_OPTIONS' to take account of this. This macro, if
18013 defined, is executed once just after all the command options have
18016 Don't use this macro to turn on various extra optimizations for
18017 `-O'. That is what `OPTIMIZATION_OPTIONS' is for.
18019 -- Macro: OPTIMIZATION_OPTIONS (LEVEL, SIZE)
18020 Some machines may desire to change what optimizations are
18021 performed for various optimization levels. This macro, if
18022 defined, is executed once just after the optimization level is
18023 determined and before the remainder of the command options have
18024 been parsed. Values set in this macro are used as the default
18025 values for the other command line options.
18027 LEVEL is the optimization level specified; 2 if `-O2' is
18028 specified, 1 if `-O' is specified, and 0 if neither is specified.
18030 SIZE is nonzero if `-Os' is specified and zero otherwise.
18032 You should not use this macro to change options that are not
18033 machine-specific. These should uniformly selected by the same
18034 optimization level on all supported machines. Use this macro to
18035 enable machine-specific optimizations.
18037 *Do not examine `write_symbols' in this macro!* The debugging
18038 options are not supposed to alter the generated code.
18040 -- Macro: CAN_DEBUG_WITHOUT_FP
18041 Define this macro if debugging can be performed even without a
18042 frame pointer. If this macro is defined, GCC will turn on the
18043 `-fomit-frame-pointer' option whenever `-O' is specified.
18046 File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros
18048 14.4 Defining data structures for per-function information.
18049 ===========================================================
18051 If the target needs to store information on a per-function basis, GCC
18052 provides a macro and a couple of variables to allow this. Note, just
18053 using statics to store the information is a bad idea, since GCC supports
18054 nested functions, so you can be halfway through encoding one function
18055 when another one comes along.
18057 GCC defines a data structure called `struct function' which contains
18058 all of the data specific to an individual function. This structure
18059 contains a field called `machine' whose type is `struct
18060 machine_function *', which can be used by targets to point to their own
18063 If a target needs per-function specific data it should define the type
18064 `struct machine_function' and also the macro `INIT_EXPANDERS'. This
18065 macro should be used to initialize the function pointer
18066 `init_machine_status'. This pointer is explained below.
18068 One typical use of per-function, target specific data is to create an
18069 RTX to hold the register containing the function's return address. This
18070 RTX can then be used to implement the `__builtin_return_address'
18071 function, for level 0.
18073 Note--earlier implementations of GCC used a single data area to hold
18074 all of the per-function information. Thus when processing of a nested
18075 function began the old per-function data had to be pushed onto a stack,
18076 and when the processing was finished, it had to be popped off the
18077 stack. GCC used to provide function pointers called
18078 `save_machine_status' and `restore_machine_status' to handle the saving
18079 and restoring of the target specific information. Since the single
18080 data area approach is no longer used, these pointers are no longer
18083 -- Macro: INIT_EXPANDERS
18084 Macro called to initialize any target specific information. This
18085 macro is called once per function, before generation of any RTL
18086 has begun. The intention of this macro is to allow the
18087 initialization of the function pointer `init_machine_status'.
18089 -- Variable: void (*)(struct function *) init_machine_status
18090 If this function pointer is non-`NULL' it will be called once per
18091 function, before function compilation starts, in order to allow the
18092 target to perform any target specific initialization of the
18093 `struct function' structure. It is intended that this would be
18094 used to initialize the `machine' of that structure.
18096 `struct machine_function' structures are expected to be freed by
18097 GC. Generally, any memory that they reference must be allocated
18098 by using `ggc_alloc', including the structure itself.
18101 File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros
18103 14.5 Storage Layout
18104 ===================
18106 Note that the definitions of the macros in this table which are sizes or
18107 alignments measured in bits do not need to be constant. They can be C
18108 expressions that refer to static variables, such as the `target_flags'.
18109 *Note Run-time Target::.
18111 -- Macro: BITS_BIG_ENDIAN
18112 Define this macro to have the value 1 if the most significant bit
18113 in a byte has the lowest number; otherwise define it to have the
18114 value zero. This means that bit-field instructions count from the
18115 most significant bit. If the machine has no bit-field
18116 instructions, then this must still be defined, but it doesn't
18117 matter which value it is defined to. This macro need not be a
18120 This macro does not affect the way structure fields are packed into
18121 bytes or words; that is controlled by `BYTES_BIG_ENDIAN'.
18123 -- Macro: BYTES_BIG_ENDIAN
18124 Define this macro to have the value 1 if the most significant byte
18125 in a word has the lowest number. This macro need not be a
18128 -- Macro: WORDS_BIG_ENDIAN
18129 Define this macro to have the value 1 if, in a multiword object,
18130 the most significant word has the lowest number. This applies to
18131 both memory locations and registers; GCC fundamentally assumes
18132 that the order of words in memory is the same as the order in
18133 registers. This macro need not be a constant.
18135 -- Macro: LIBGCC2_WORDS_BIG_ENDIAN
18136 Define this macro if `WORDS_BIG_ENDIAN' is not constant. This
18137 must be a constant value with the same meaning as
18138 `WORDS_BIG_ENDIAN', which will be used only when compiling
18139 `libgcc2.c'. Typically the value will be set based on
18140 preprocessor defines.
18142 -- Macro: FLOAT_WORDS_BIG_ENDIAN
18143 Define this macro to have the value 1 if `DFmode', `XFmode' or
18144 `TFmode' floating point numbers are stored in memory with the word
18145 containing the sign bit at the lowest address; otherwise define it
18146 to have the value 0. This macro need not be a constant.
18148 You need not define this macro if the ordering is the same as for
18149 multi-word integers.
18151 -- Macro: BITS_PER_UNIT
18152 Define this macro to be the number of bits in an addressable
18153 storage unit (byte). If you do not define this macro the default
18156 -- Macro: BITS_PER_WORD
18157 Number of bits in a word. If you do not define this macro, the
18158 default is `BITS_PER_UNIT * UNITS_PER_WORD'.
18160 -- Macro: MAX_BITS_PER_WORD
18161 Maximum number of bits in a word. If this is undefined, the
18162 default is `BITS_PER_WORD'. Otherwise, it is the constant value
18163 that is the largest value that `BITS_PER_WORD' can have at
18166 -- Macro: UNITS_PER_WORD
18167 Number of storage units in a word; normally the size of a
18168 general-purpose register, a power of two from 1 or 8.
18170 -- Macro: MIN_UNITS_PER_WORD
18171 Minimum number of units in a word. If this is undefined, the
18172 default is `UNITS_PER_WORD'. Otherwise, it is the constant value
18173 that is the smallest value that `UNITS_PER_WORD' can have at
18176 -- Macro: UNITS_PER_SIMD_WORD
18177 Number of units in the vectors that the vectorizer can produce.
18178 The default is equal to `UNITS_PER_WORD', because the vectorizer
18179 can do some transformations even in absence of specialized SIMD
18182 -- Macro: POINTER_SIZE
18183 Width of a pointer, in bits. You must specify a value no wider
18184 than the width of `Pmode'. If it is not equal to the width of
18185 `Pmode', you must define `POINTERS_EXTEND_UNSIGNED'. If you do
18186 not specify a value the default is `BITS_PER_WORD'.
18188 -- Macro: POINTERS_EXTEND_UNSIGNED
18189 A C expression whose value is greater than zero if pointers that
18190 need to be extended from being `POINTER_SIZE' bits wide to `Pmode'
18191 are to be zero-extended and zero if they are to be sign-extended.
18192 If the value is less then zero then there must be an "ptr_extend"
18193 instruction that extends a pointer from `POINTER_SIZE' to `Pmode'.
18195 You need not define this macro if the `POINTER_SIZE' is equal to
18196 the width of `Pmode'.
18198 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE)
18199 A macro to update M and UNSIGNEDP when an object whose type is
18200 TYPE and which has the specified mode and signedness is to be
18201 stored in a register. This macro is only called when TYPE is a
18204 On most RISC machines, which only have operations that operate on
18205 a full register, define this macro to set M to `word_mode' if M is
18206 an integer mode narrower than `BITS_PER_WORD'. In most cases,
18207 only integer modes should be widened because wider-precision
18208 floating-point operations are usually more expensive than their
18209 narrower counterparts.
18211 For most machines, the macro definition does not change UNSIGNEDP.
18212 However, some machines, have instructions that preferentially
18213 handle either signed or unsigned quantities of certain modes. For
18214 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add
18215 instructions sign-extend the result to 64 bits. On such machines,
18216 set UNSIGNEDP according to which kind of extension is more
18219 Do not define this macro if it would never modify M.
18221 -- Macro: PROMOTE_FUNCTION_MODE
18222 Like `PROMOTE_MODE', but is applied to outgoing function arguments
18223 or function return values, as specified by
18224 `TARGET_PROMOTE_FUNCTION_ARGS' and
18225 `TARGET_PROMOTE_FUNCTION_RETURN', respectively.
18227 The default is `PROMOTE_MODE'.
18229 -- Target Hook: bool TARGET_PROMOTE_FUNCTION_ARGS (tree FNTYPE)
18230 This target hook should return `true' if the promotion described by
18231 `PROMOTE_FUNCTION_MODE' should be done for outgoing function
18234 -- Target Hook: bool TARGET_PROMOTE_FUNCTION_RETURN (tree FNTYPE)
18235 This target hook should return `true' if the promotion described by
18236 `PROMOTE_FUNCTION_MODE' should be done for the return value of
18239 If this target hook returns `true', `FUNCTION_VALUE' must perform
18240 the same promotions done by `PROMOTE_FUNCTION_MODE'.
18242 -- Macro: PARM_BOUNDARY
18243 Normal alignment required for function parameters on the stack, in
18244 bits. All stack parameters receive at least this much alignment
18245 regardless of data type. On most machines, this is the same as the
18246 size of an integer.
18248 -- Macro: STACK_BOUNDARY
18249 Define this macro to the minimum alignment enforced by hardware
18250 for the stack pointer on this machine. The definition is a C
18251 expression for the desired alignment (measured in bits). This
18252 value is used as a default if `PREFERRED_STACK_BOUNDARY' is not
18253 defined. On most machines, this should be the same as
18256 -- Macro: PREFERRED_STACK_BOUNDARY
18257 Define this macro if you wish to preserve a certain alignment for
18258 the stack pointer, greater than what the hardware enforces. The
18259 definition is a C expression for the desired alignment (measured
18260 in bits). This macro must evaluate to a value equal to or larger
18261 than `STACK_BOUNDARY'.
18263 -- Macro: FUNCTION_BOUNDARY
18264 Alignment required for a function entry point, in bits.
18266 -- Macro: BIGGEST_ALIGNMENT
18267 Biggest alignment that any data type can require on this machine,
18270 -- Macro: MINIMUM_ATOMIC_ALIGNMENT
18271 If defined, the smallest alignment, in bits, that can be given to
18272 an object that can be referenced in one operation, without
18273 disturbing any nearby object. Normally, this is `BITS_PER_UNIT',
18274 but may be larger on machines that don't have byte or half-word
18277 -- Macro: BIGGEST_FIELD_ALIGNMENT
18278 Biggest alignment that any structure or union field can require on
18279 this machine, in bits. If defined, this overrides
18280 `BIGGEST_ALIGNMENT' for structure and union fields only, unless
18281 the field alignment has been set by the `__attribute__ ((aligned
18284 -- Macro: ADJUST_FIELD_ALIGN (FIELD, COMPUTED)
18285 An expression for the alignment of a structure field FIELD if the
18286 alignment computed in the usual way (including applying of
18287 `BIGGEST_ALIGNMENT' and `BIGGEST_FIELD_ALIGNMENT' to the
18288 alignment) is COMPUTED. It overrides alignment only if the field
18289 alignment has not been set by the `__attribute__ ((aligned (N)))'
18292 -- Macro: MAX_OFILE_ALIGNMENT
18293 Biggest alignment supported by the object file format of this
18294 machine. Use this macro to limit the alignment which can be
18295 specified using the `__attribute__ ((aligned (N)))' construct. If
18296 not defined, the default value is `BIGGEST_ALIGNMENT'.
18298 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN)
18299 If defined, a C expression to compute the alignment for a variable
18300 in the static store. TYPE is the data type, and BASIC-ALIGN is
18301 the alignment that the object would ordinarily have. The value of
18302 this macro is used instead of that alignment to align the object.
18304 If this macro is not defined, then BASIC-ALIGN is used.
18306 One use of this macro is to increase alignment of medium-size data
18307 to make it all fit in fewer cache lines. Another is to cause
18308 character arrays to be word-aligned so that `strcpy' calls that
18309 copy constants to character arrays can be done inline.
18311 -- Macro: CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN)
18312 If defined, a C expression to compute the alignment given to a
18313 constant that is being placed in memory. CONSTANT is the constant
18314 and BASIC-ALIGN is the alignment that the object would ordinarily
18315 have. The value of this macro is used instead of that alignment to
18318 If this macro is not defined, then BASIC-ALIGN is used.
18320 The typical use of this macro is to increase alignment for string
18321 constants to be word aligned so that `strcpy' calls that copy
18322 constants can be done inline.
18324 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN)
18325 If defined, a C expression to compute the alignment for a variable
18326 in the local store. TYPE is the data type, and BASIC-ALIGN is the
18327 alignment that the object would ordinarily have. The value of this
18328 macro is used instead of that alignment to align the object.
18330 If this macro is not defined, then BASIC-ALIGN is used.
18332 One use of this macro is to increase alignment of medium-size data
18333 to make it all fit in fewer cache lines.
18335 -- Macro: EMPTY_FIELD_BOUNDARY
18336 Alignment in bits to be given to a structure bit-field that
18337 follows an empty field such as `int : 0;'.
18339 If `PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro.
18341 -- Macro: STRUCTURE_SIZE_BOUNDARY
18342 Number of bits which any structure or union's size must be a
18343 multiple of. Each structure or union's size is rounded up to a
18346 If you do not define this macro, the default is the same as
18349 -- Macro: STRICT_ALIGNMENT
18350 Define this macro to be the value 1 if instructions will fail to
18351 work if given data not on the nominal alignment. If instructions
18352 will merely go slower in that case, define this macro as 0.
18354 -- Macro: PCC_BITFIELD_TYPE_MATTERS
18355 Define this if you wish to imitate the way many other C compilers
18356 handle alignment of bit-fields and the structures that contain
18359 The behavior is that the type written for a named bit-field (`int',
18360 `short', or other integer type) imposes an alignment for the entire
18361 structure, as if the structure really did contain an ordinary
18362 field of that type. In addition, the bit-field is placed within
18363 the structure so that it would fit within such a field, not
18364 crossing a boundary for it.
18366 Thus, on most machines, a named bit-field whose type is written as
18367 `int' would not cross a four-byte boundary, and would force
18368 four-byte alignment for the whole structure. (The alignment used
18369 may not be four bytes; it is controlled by the other alignment
18372 An unnamed bit-field will not affect the alignment of the
18373 containing structure.
18375 If the macro is defined, its definition should be a C expression;
18376 a nonzero value for the expression enables this behavior.
18378 Note that if this macro is not defined, or its value is zero, some
18379 bit-fields may cross more than one alignment boundary. The
18380 compiler can support such references if there are `insv', `extv',
18381 and `extzv' insns that can directly reference memory.
18383 The other known way of making bit-fields work is to define
18384 `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then
18385 every structure can be accessed with fullwords.
18387 Unless the machine has bit-field instructions or you define
18388 `STRUCTURE_SIZE_BOUNDARY' that way, you must define
18389 `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value.
18391 If your aim is to make GCC use the same conventions for laying out
18392 bit-fields as are used by another compiler, here is how to
18393 investigate what the other compiler does. Compile and run this
18412 printf ("Size of foo1 is %d\n",
18413 sizeof (struct foo1));
18414 printf ("Size of foo2 is %d\n",
18415 sizeof (struct foo2));
18419 If this prints 2 and 5, then the compiler's behavior is what you
18420 would get from `PCC_BITFIELD_TYPE_MATTERS'.
18422 -- Macro: BITFIELD_NBYTES_LIMITED
18423 Like `PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited
18424 to aligning a bit-field within the structure.
18426 -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELDS (void)
18427 When `PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine
18428 whether unnamed bitfields affect the alignment of the containing
18429 structure. The hook should return true if the structure should
18430 inherit the alignment requirements of an unnamed bitfield's type.
18432 -- Macro: MEMBER_TYPE_FORCES_BLK (FIELD, MODE)
18433 Return 1 if a structure or array containing FIELD should be
18434 accessed using `BLKMODE'.
18436 If FIELD is the only field in the structure, MODE is its mode,
18437 otherwise MODE is VOIDmode. MODE is provided in the case where
18438 structures of one field would require the structure's mode to
18439 retain the field's mode.
18441 Normally, this is not needed. See the file `c4x.h' for an example
18442 of how to use this macro to prevent a structure having a floating
18443 point field from being accessed in an integer mode.
18445 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED)
18446 Define this macro as an expression for the alignment of a type
18447 (given by TYPE as a tree node) if the alignment computed in the
18448 usual way is COMPUTED and the alignment explicitly specified was
18451 The default is to use SPECIFIED if it is larger; otherwise, use
18452 the smaller of COMPUTED and `BIGGEST_ALIGNMENT'
18454 -- Macro: MAX_FIXED_MODE_SIZE
18455 An integer expression for the size in bits of the largest integer
18456 machine mode that should actually be used. All integer machine
18457 modes of this size or smaller can be used for structures and
18458 unions with the appropriate sizes. If this macro is undefined,
18459 `GET_MODE_BITSIZE (DImode)' is assumed.
18461 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL)
18462 If defined, an expression of type `enum machine_mode' that
18463 specifies the mode of the save area operand of a
18464 `save_stack_LEVEL' named pattern (*note Standard Names::).
18465 SAVE_LEVEL is one of `SAVE_BLOCK', `SAVE_FUNCTION', or
18466 `SAVE_NONLOCAL' and selects which of the three named patterns is
18467 having its mode specified.
18469 You need not define this macro if it always returns `Pmode'. You
18470 would most commonly define this macro if the `save_stack_LEVEL'
18471 patterns need to support both a 32- and a 64-bit mode.
18473 -- Macro: STACK_SIZE_MODE
18474 If defined, an expression of type `enum machine_mode' that
18475 specifies the mode of the size increment operand of an
18476 `allocate_stack' named pattern (*note Standard Names::).
18478 You need not define this macro if it always returns `word_mode'.
18479 You would most commonly define this macro if the `allocate_stack'
18480 pattern needs to support both a 32- and a 64-bit mode.
18482 -- Macro: TARGET_FLOAT_FORMAT
18483 A code distinguishing the floating point format of the target
18484 machine. There are four defined values:
18486 `IEEE_FLOAT_FORMAT'
18487 This code indicates IEEE floating point. It is the default;
18488 there is no need to define `TARGET_FLOAT_FORMAT' when the
18492 This code indicates the "F float" (for `float') and "D float"
18493 or "G float" formats (for `double') used on the VAX and
18497 This code indicates the format used on the IBM System/370.
18500 This code indicates the format used on the TMS320C3x/C4x.
18502 If your target uses a floating point format other than these, you
18503 must define a new NAME_FLOAT_FORMAT code for it, and add support
18504 for it to `real.c'.
18506 The ordering of the component words of floating point values
18507 stored in memory is controlled by `FLOAT_WORDS_BIG_ENDIAN'.
18509 -- Macro: MODE_HAS_NANS (MODE)
18510 When defined, this macro should be true if MODE has a NaN
18511 representation. The compiler assumes that NaNs are not equal to
18512 anything (including themselves) and that addition, subtraction,
18513 multiplication and division all return NaNs when one operand is
18516 By default, this macro is true if MODE is a floating-point mode
18517 and the target floating-point format is IEEE.
18519 -- Macro: MODE_HAS_INFINITIES (MODE)
18520 This macro should be true if MODE can represent infinity. At
18521 present, the compiler uses this macro to decide whether `x - x' is
18522 always defined. By default, the macro is true when MODE is a
18523 floating-point mode and the target format is IEEE.
18525 -- Macro: MODE_HAS_SIGNED_ZEROS (MODE)
18526 True if MODE distinguishes between positive and negative zero.
18527 The rules are expected to follow the IEEE standard:
18529 * `x + x' has the same sign as `x'.
18531 * If the sum of two values with opposite sign is zero, the
18532 result is positive for all rounding modes expect towards
18533 -infinity, for which it is negative.
18535 * The sign of a product or quotient is negative when exactly one
18536 of the operands is negative.
18538 The default definition is true if MODE is a floating-point mode
18539 and the target format is IEEE.
18541 -- Macro: MODE_HAS_SIGN_DEPENDENT_ROUNDING (MODE)
18542 If defined, this macro should be true for MODE if it has at least
18543 one rounding mode in which `x' and `-x' can be rounded to numbers
18544 of different magnitude. Two such modes are towards -infinity and
18547 The default definition of this macro is true if MODE is a
18548 floating-point mode and the target format is IEEE.
18550 -- Macro: ROUND_TOWARDS_ZERO
18551 If defined, this macro should be true if the prevailing rounding
18552 mode is towards zero. A true value has the following effects:
18554 * `MODE_HAS_SIGN_DEPENDENT_ROUNDING' will be false for all
18557 * `libgcc.a''s floating-point emulator will round towards zero
18558 rather than towards nearest.
18560 * The compiler's floating-point emulator will round towards
18561 zero after doing arithmetic, and when converting from the
18562 internal float format to the target format.
18564 The macro does not affect the parsing of string literals. When the
18565 primary rounding mode is towards zero, library functions like
18566 `strtod' might still round towards nearest, and the compiler's
18567 parser should behave like the target's `strtod' where possible.
18569 Not defining this macro is equivalent to returning zero.
18571 -- Macro: LARGEST_EXPONENT_IS_NORMAL (SIZE)
18572 This macro should return true if floats with SIZE bits do not have
18573 a NaN or infinity representation, but use the largest exponent for
18574 normal numbers instead.
18576 Defining this macro to true for SIZE causes `MODE_HAS_NANS' and
18577 `MODE_HAS_INFINITIES' to be false for SIZE-bit modes. It also
18578 affects the way `libgcc.a' and `real.c' emulate floating-point
18581 The default definition of this macro returns false for all sizes.
18583 -- Target Hook: bool TARGET_VECTOR_OPAQUE_P (tree TYPE)
18584 This target hook should return `true' a vector is opaque. That
18585 is, if no cast is needed when copying a vector value of type TYPE
18586 into another vector lvalue of the same size. Vector opaque types
18587 cannot be initialized. The default is that there are no such
18590 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (tree RECORD_TYPE)
18591 This target hook returns `true' if bit-fields in the given
18592 RECORD_TYPE are to be laid out following the rules of Microsoft
18593 Visual C/C++, namely: (i) a bit-field won't share the same storage
18594 unit with the previous bit-field if their underlying types have
18595 different sizes, and the bit-field will be aligned to the highest
18596 alignment of the underlying types of itself and of the previous
18597 bit-field; (ii) a zero-sized bit-field will affect the alignment of
18598 the whole enclosing structure, even if it is unnamed; except that
18599 (iii) a zero-sized bit-field will be disregarded unless it follows
18600 another bit-field of nonzero size. If this hook returns `true',
18601 other macros that control bit-field layout are ignored.
18603 When a bit-field is inserted into a packed record, the whole size
18604 of the underlying type is used by one or more same-size adjacent
18605 bit-fields (that is, if its long:3, 32 bits is used in the record,
18606 and any additional adjacent long bit-fields are packed into the
18607 same chunk of 32 bits. However, if the size changes, a new field
18608 of that size is allocated). In an unpacked record, this is the
18609 same as using alignment, but not equivalent when packing.
18611 If both MS bit-fields and `__attribute__((packed))' are used, the
18612 latter will take precedence. If `__attribute__((packed))' is used
18613 on a single field when MS bit-fields are in use, it will take
18614 precedence for that field, but the alignment of the rest of the
18615 structure may affect its placement.
18617 -- Target Hook: const char * TARGET_MANGLE_FUNDAMENTAL_TYPE (tree TYPE)
18618 If your target defines any fundamental types, define this hook to
18619 return the appropriate encoding for these types as part of a C++
18620 mangled name. The TYPE argument is the tree structure
18621 representing the type to be mangled. The hook may be applied to
18622 trees which are not target-specific fundamental types; it should
18623 return `NULL' for all such types, as well as arguments it does not
18624 recognize. If the return value is not `NULL', it must point to a
18625 statically-allocated string constant.
18627 Target-specific fundamental types might be new fundamental types or
18628 qualified versions of ordinary fundamental types. Encode new
18629 fundamental types as `u N NAME', where NAME is the name used for
18630 the type in source code, and N is the length of NAME in decimal.
18631 Encode qualified versions of ordinary types as `U N NAME CODE',
18632 where NAME is the name used for the type qualifier in source code,
18633 N is the length of NAME as above, and CODE is the code used to
18634 represent the unqualified version of this type. (See
18635 `write_builtin_type' in `cp/mangle.c' for the list of codes.) In
18636 both cases the spaces are for clarity; do not include any spaces
18639 The default version of this hook always returns `NULL', which is
18640 appropriate for a target that does not define any new fundamental
18644 File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros
18646 14.6 Layout of Source Language Data Types
18647 =========================================
18649 These macros define the sizes and other characteristics of the standard
18650 basic data types used in programs being compiled. Unlike the macros in
18651 the previous section, these apply to specific features of C and related
18652 languages, rather than to fundamental aspects of storage layout.
18654 -- Macro: INT_TYPE_SIZE
18655 A C expression for the size in bits of the type `int' on the
18656 target machine. If you don't define this, the default is one word.
18658 -- Macro: SHORT_TYPE_SIZE
18659 A C expression for the size in bits of the type `short' on the
18660 target machine. If you don't define this, the default is half a
18661 word. (If this would be less than one storage unit, it is rounded
18664 -- Macro: LONG_TYPE_SIZE
18665 A C expression for the size in bits of the type `long' on the
18666 target machine. If you don't define this, the default is one word.
18668 -- Macro: ADA_LONG_TYPE_SIZE
18669 On some machines, the size used for the Ada equivalent of the type
18670 `long' by a native Ada compiler differs from that used by C. In
18671 that situation, define this macro to be a C expression to be used
18672 for the size of that type. If you don't define this, the default
18673 is the value of `LONG_TYPE_SIZE'.
18675 -- Macro: LONG_LONG_TYPE_SIZE
18676 A C expression for the size in bits of the type `long long' on the
18677 target machine. If you don't define this, the default is two
18678 words. If you want to support GNU Ada on your machine, the value
18679 of this macro must be at least 64.
18681 -- Macro: CHAR_TYPE_SIZE
18682 A C expression for the size in bits of the type `char' on the
18683 target machine. If you don't define this, the default is
18686 -- Macro: BOOL_TYPE_SIZE
18687 A C expression for the size in bits of the C++ type `bool' and C99
18688 type `_Bool' on the target machine. If you don't define this, and
18689 you probably shouldn't, the default is `CHAR_TYPE_SIZE'.
18691 -- Macro: FLOAT_TYPE_SIZE
18692 A C expression for the size in bits of the type `float' on the
18693 target machine. If you don't define this, the default is one word.
18695 -- Macro: DOUBLE_TYPE_SIZE
18696 A C expression for the size in bits of the type `double' on the
18697 target machine. If you don't define this, the default is two
18700 -- Macro: LONG_DOUBLE_TYPE_SIZE
18701 A C expression for the size in bits of the type `long double' on
18702 the target machine. If you don't define this, the default is two
18705 -- Macro: LIBGCC2_LONG_DOUBLE_TYPE_SIZE
18706 Define this macro if `LONG_DOUBLE_TYPE_SIZE' is not constant or if
18707 you want routines in `libgcc2.a' for a size other than
18708 `LONG_DOUBLE_TYPE_SIZE'. If you don't define this, the default is
18709 `LONG_DOUBLE_TYPE_SIZE'.
18711 -- Macro: LIBGCC2_HAS_DF_MODE
18712 Define this macro if neither `LIBGCC2_DOUBLE_TYPE_SIZE' nor
18713 `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is `DFmode' but you want `DFmode'
18714 routines in `libgcc2.a' anyway. If you don't define this and
18715 either `LIBGCC2_DOUBLE_TYPE_SIZE' or
18716 `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 64 then the default is 1,
18719 -- Macro: LIBGCC2_HAS_XF_MODE
18720 Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not
18721 `XFmode' but you want `XFmode' routines in `libgcc2.a' anyway. If
18722 you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 80
18723 then the default is 1, otherwise it is 0.
18725 -- Macro: LIBGCC2_HAS_TF_MODE
18726 Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not
18727 `TFmode' but you want `TFmode' routines in `libgcc2.a' anyway. If
18728 you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 128
18729 then the default is 1, otherwise it is 0.
18731 -- Macro: TARGET_FLT_EVAL_METHOD
18732 A C expression for the value for `FLT_EVAL_METHOD' in `float.h',
18733 assuming, if applicable, that the floating-point control word is
18734 in its default state. If you do not define this macro the value of
18735 `FLT_EVAL_METHOD' will be zero.
18737 -- Macro: WIDEST_HARDWARE_FP_SIZE
18738 A C expression for the size in bits of the widest floating-point
18739 format supported by the hardware. If you define this macro, you
18740 must specify a value less than or equal to the value of
18741 `LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the
18742 value of `LONG_DOUBLE_TYPE_SIZE' is the default.
18744 -- Macro: DEFAULT_SIGNED_CHAR
18745 An expression whose value is 1 or 0, according to whether the type
18746 `char' should be signed or unsigned by default. The user can
18747 always override this default with the options `-fsigned-char' and
18750 -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void)
18751 This target hook should return true if the compiler should give an
18752 `enum' type only as many bytes as it takes to represent the range
18753 of possible values of that type. It should return false if all
18754 `enum' types should be allocated like `int'.
18756 The default is to return false.
18758 -- Macro: SIZE_TYPE
18759 A C expression for a string describing the name of the data type
18760 to use for size values. The typedef name `size_t' is defined
18761 using the contents of the string.
18763 The string can contain more than one keyword. If so, separate
18764 them with spaces, and write first any length keyword, then
18765 `unsigned' if appropriate, and finally `int'. The string must
18766 exactly match one of the data type names defined in the function
18767 `init_decl_processing' in the file `c-decl.c'. You may not omit
18768 `int' or change the order--that would cause the compiler to crash
18771 If you don't define this macro, the default is `"long unsigned
18774 -- Macro: PTRDIFF_TYPE
18775 A C expression for a string describing the name of the data type
18776 to use for the result of subtracting two pointers. The typedef
18777 name `ptrdiff_t' is defined using the contents of the string. See
18778 `SIZE_TYPE' above for more information.
18780 If you don't define this macro, the default is `"long int"'.
18782 -- Macro: WCHAR_TYPE
18783 A C expression for a string describing the name of the data type
18784 to use for wide characters. The typedef name `wchar_t' is defined
18785 using the contents of the string. See `SIZE_TYPE' above for more
18788 If you don't define this macro, the default is `"int"'.
18790 -- Macro: WCHAR_TYPE_SIZE
18791 A C expression for the size in bits of the data type for wide
18792 characters. This is used in `cpp', which cannot make use of
18795 -- Macro: WINT_TYPE
18796 A C expression for a string describing the name of the data type to
18797 use for wide characters passed to `printf' and returned from
18798 `getwc'. The typedef name `wint_t' is defined using the contents
18799 of the string. See `SIZE_TYPE' above for more information.
18801 If you don't define this macro, the default is `"unsigned int"'.
18803 -- Macro: INTMAX_TYPE
18804 A C expression for a string describing the name of the data type
18805 that can represent any value of any standard or extended signed
18806 integer type. The typedef name `intmax_t' is defined using the
18807 contents of the string. See `SIZE_TYPE' above for more
18810 If you don't define this macro, the default is the first of
18811 `"int"', `"long int"', or `"long long int"' that has as much
18812 precision as `long long int'.
18814 -- Macro: UINTMAX_TYPE
18815 A C expression for a string describing the name of the data type
18816 that can represent any value of any standard or extended unsigned
18817 integer type. The typedef name `uintmax_t' is defined using the
18818 contents of the string. See `SIZE_TYPE' above for more
18821 If you don't define this macro, the default is the first of
18822 `"unsigned int"', `"long unsigned int"', or `"long long unsigned
18823 int"' that has as much precision as `long long unsigned int'.
18825 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION
18826 The C++ compiler represents a pointer-to-member-function with a
18827 struct that looks like:
18832 ptrdiff_t vtable_index;
18837 The C++ compiler must use one bit to indicate whether the function
18838 that will be called through a pointer-to-member-function is
18839 virtual. Normally, we assume that the low-order bit of a function
18840 pointer must always be zero. Then, by ensuring that the
18841 vtable_index is odd, we can distinguish which variant of the union
18842 is in use. But, on some platforms function pointers can be odd,
18843 and so this doesn't work. In that case, we use the low-order bit
18844 of the `delta' field, and shift the remainder of the `delta' field
18847 GCC will automatically make the right selection about where to
18848 store this bit using the `FUNCTION_BOUNDARY' setting for your
18849 platform. However, some platforms such as ARM/Thumb have
18850 `FUNCTION_BOUNDARY' set such that functions always start at even
18851 addresses, but the lowest bit of pointers to functions indicate
18852 whether the function at that address is in ARM or Thumb mode. If
18853 this is the case of your architecture, you should define this
18854 macro to `ptrmemfunc_vbit_in_delta'.
18856 In general, you should not have to define this macro. On
18857 architectures in which function addresses are always even,
18858 according to `FUNCTION_BOUNDARY', GCC will automatically define
18859 this macro to `ptrmemfunc_vbit_in_pfn'.
18861 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS
18862 Normally, the C++ compiler uses function pointers in vtables. This
18863 macro allows the target to change to use "function descriptors"
18864 instead. Function descriptors are found on targets for whom a
18865 function pointer is actually a small data structure. Normally the
18866 data structure consists of the actual code address plus a data
18867 pointer to which the function's data is relative.
18869 If vtables are used, the value of this macro should be the number
18870 of words that the function descriptor occupies.
18872 -- Macro: TARGET_VTABLE_ENTRY_ALIGN
18873 By default, the vtable entries are void pointers, the so the
18874 alignment is the same as pointer alignment. The value of this
18875 macro specifies the alignment of the vtable entry in bits. It
18876 should be defined only when special alignment is necessary. */
18878 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE
18879 There are a few non-descriptor entries in the vtable at offsets
18880 below zero. If these entries must be padded (say, to preserve the
18881 alignment specified by `TARGET_VTABLE_ENTRY_ALIGN'), set this to
18882 the number of words in each data entry.
18885 File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros
18887 14.7 Register Usage
18888 ===================
18890 This section explains how to describe what registers the target machine
18891 has, and how (in general) they can be used.
18893 The description of which registers a specific instruction can use is
18894 done with register classes; see *Note Register Classes::. For
18895 information on using registers to access a stack frame, see *Note Frame
18896 Registers::. For passing values in registers, see *Note Register
18897 Arguments::. For returning values in registers, see *Note Scalar
18902 * Register Basics:: Number and kinds of registers.
18903 * Allocation Order:: Order in which registers are allocated.
18904 * Values in Registers:: What kinds of values each reg can hold.
18905 * Leaf Functions:: Renumbering registers for leaf functions.
18906 * Stack Registers:: Handling a register stack such as 80387.
18909 File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers
18911 14.7.1 Basic Characteristics of Registers
18912 -----------------------------------------
18914 Registers have various characteristics.
18916 -- Macro: FIRST_PSEUDO_REGISTER
18917 Number of hardware registers known to the compiler. They receive
18918 numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first
18919 pseudo register's number really is assigned the number
18920 `FIRST_PSEUDO_REGISTER'.
18922 -- Macro: FIXED_REGISTERS
18923 An initializer that says which registers are used for fixed
18924 purposes all throughout the compiled code and are therefore not
18925 available for general allocation. These would include the stack
18926 pointer, the frame pointer (except on machines where that can be
18927 used as a general register when no frame pointer is needed), the
18928 program counter on machines where that is considered one of the
18929 addressable registers, and any other numbered register with a
18932 This information is expressed as a sequence of numbers, separated
18933 by commas and surrounded by braces. The Nth number is 1 if
18934 register N is fixed, 0 otherwise.
18936 The table initialized from this macro, and the table initialized by
18937 the following one, may be overridden at run time either
18938 automatically, by the actions of the macro
18939 `CONDITIONAL_REGISTER_USAGE', or by the user with the command
18940 options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'.
18942 -- Macro: CALL_USED_REGISTERS
18943 Like `FIXED_REGISTERS' but has 1 for each register that is
18944 clobbered (in general) by function calls as well as for fixed
18945 registers. This macro therefore identifies the registers that are
18946 not available for general allocation of values that must live
18947 across function calls.
18949 If a register has 0 in `CALL_USED_REGISTERS', the compiler
18950 automatically saves it on function entry and restores it on
18951 function exit, if the register is used within the function.
18953 -- Macro: CALL_REALLY_USED_REGISTERS
18954 Like `CALL_USED_REGISTERS' except this macro doesn't require that
18955 the entire set of `FIXED_REGISTERS' be included.
18956 (`CALL_USED_REGISTERS' must be a superset of `FIXED_REGISTERS').
18957 This macro is optional. If not specified, it defaults to the value
18958 of `CALL_USED_REGISTERS'.
18960 -- Macro: HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE)
18961 A C expression that is nonzero if it is not permissible to store a
18962 value of mode MODE in hard register number REGNO across a call
18963 without some part of it being clobbered. For most machines this
18964 macro need not be defined. It is only required for machines that
18965 do not preserve the entire contents of a register across a call.
18967 -- Macro: CONDITIONAL_REGISTER_USAGE
18968 Zero or more C statements that may conditionally modify five
18969 variables `fixed_regs', `call_used_regs', `global_regs',
18970 `reg_names', and `reg_class_contents', to take into account any
18971 dependence of these register sets on target flags. The first three
18972 of these are of type `char []' (interpreted as Boolean vectors).
18973 `global_regs' is a `const char *[]', and `reg_class_contents' is a
18974 `HARD_REG_SET'. Before the macro is called, `fixed_regs',
18975 `call_used_regs', `reg_class_contents', and `reg_names' have been
18976 initialized from `FIXED_REGISTERS', `CALL_USED_REGISTERS',
18977 `REG_CLASS_CONTENTS', and `REGISTER_NAMES', respectively.
18978 `global_regs' has been cleared, and any `-ffixed-REG',
18979 `-fcall-used-REG' and `-fcall-saved-REG' command options have been
18982 You need not define this macro if it has no work to do.
18984 If the usage of an entire class of registers depends on the target
18985 flags, you may indicate this to GCC by using this macro to modify
18986 `fixed_regs' and `call_used_regs' to 1 for each of the registers
18987 in the classes which should not be used by GCC. Also define the
18988 macro `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' to
18989 return `NO_REGS' if it is called with a letter for a class that
18992 (However, if this class is not included in `GENERAL_REGS' and all
18993 of the insn patterns whose constraints permit this class are
18994 controlled by target switches, then GCC will automatically avoid
18995 using these registers when the target switches are opposed to
18998 -- Macro: INCOMING_REGNO (OUT)
18999 Define this macro if the target machine has register windows.
19000 This C expression returns the register number as seen by the
19001 called function corresponding to the register number OUT as seen
19002 by the calling function. Return OUT if register number OUT is not
19003 an outbound register.
19005 -- Macro: OUTGOING_REGNO (IN)
19006 Define this macro if the target machine has register windows.
19007 This C expression returns the register number as seen by the
19008 calling function corresponding to the register number IN as seen
19009 by the called function. Return IN if register number IN is not an
19012 -- Macro: LOCAL_REGNO (REGNO)
19013 Define this macro if the target machine has register windows.
19014 This C expression returns true if the register is call-saved but
19015 is in the register window. Unlike most call-saved registers, such
19016 registers need not be explicitly restored on function exit or
19017 during non-local gotos.
19019 -- Macro: PC_REGNUM
19020 If the program counter has a register number, define this as that
19021 register number. Otherwise, do not define it.
19024 File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers
19026 14.7.2 Order of Allocation of Registers
19027 ---------------------------------------
19029 Registers are allocated in order.
19031 -- Macro: REG_ALLOC_ORDER
19032 If defined, an initializer for a vector of integers, containing the
19033 numbers of hard registers in the order in which GCC should prefer
19034 to use them (from most preferred to least).
19036 If this macro is not defined, registers are used lowest numbered
19037 first (all else being equal).
19039 One use of this macro is on machines where the highest numbered
19040 registers must always be saved and the save-multiple-registers
19041 instruction supports only sequences of consecutive registers. On
19042 such machines, define `REG_ALLOC_ORDER' to be an initializer that
19043 lists the highest numbered allocable register first.
19045 -- Macro: ORDER_REGS_FOR_LOCAL_ALLOC
19046 A C statement (sans semicolon) to choose the order in which to
19047 allocate hard registers for pseudo-registers local to a basic
19050 Store the desired register order in the array `reg_alloc_order'.
19051 Element 0 should be the register to allocate first; element 1, the
19052 next register; and so on.
19054 The macro body should not assume anything about the contents of
19055 `reg_alloc_order' before execution of the macro.
19057 On most machines, it is not necessary to define this macro.
19060 File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers
19062 14.7.3 How Values Fit in Registers
19063 ----------------------------------
19065 This section discusses the macros that describe which kinds of values
19066 (specifically, which machine modes) each register can hold, and how many
19067 consecutive registers are needed for a given mode.
19069 -- Macro: HARD_REGNO_NREGS (REGNO, MODE)
19070 A C expression for the number of consecutive hard registers,
19071 starting at register number REGNO, required to hold a value of mode
19074 On a machine where all registers are exactly one word, a suitable
19075 definition of this macro is
19077 #define HARD_REGNO_NREGS(REGNO, MODE) \
19078 ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
19081 -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE)
19082 A C expression that is nonzero if a value of mode MODE, stored in
19083 memory, ends with padding that causes it to take up more space than
19084 in registers starting at register number REGNO (as determined by
19085 multiplying GCC's notion of the size of the register when
19086 containing this mode by the number of registers returned by
19087 `HARD_REGNO_NREGS'). By default this is zero.
19089 For example, if a floating-point value is stored in three 32-bit
19090 registers but takes up 128 bits in memory, then this would be
19093 This macros only needs to be defined if there are cases where
19094 `subreg_regno_offset' and `subreg_offset_representable_p' would
19095 otherwise wrongly determine that a `subreg' can be represented by
19096 an offset to the register number, when in fact such a `subreg'
19097 would contain some of the padding not stored in registers and so
19098 not be representable.
19100 -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE)
19101 For values of REGNO and MODE for which
19102 `HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression
19103 returning the greater number of registers required to hold the
19104 value including any padding. In the example above, the value
19107 -- Macro: REGMODE_NATURAL_SIZE (MODE)
19108 Define this macro if the natural size of registers that hold values
19109 of mode MODE is not the word size. It is a C expression that
19110 should give the natural size in bytes for the specified mode. It
19111 is used by the register allocator to try to optimize its results.
19112 This happens for example on SPARC 64-bit where the natural size of
19113 floating-point registers is still 32-bit.
19115 -- Macro: HARD_REGNO_MODE_OK (REGNO, MODE)
19116 A C expression that is nonzero if it is permissible to store a
19117 value of mode MODE in hard register number REGNO (or in several
19118 registers starting with that one). For a machine where all
19119 registers are equivalent, a suitable definition is
19121 #define HARD_REGNO_MODE_OK(REGNO, MODE) 1
19123 You need not include code to check for the numbers of fixed
19124 registers, because the allocation mechanism considers them to be
19127 On some machines, double-precision values must be kept in even/odd
19128 register pairs. You can implement that by defining this macro to
19129 reject odd register numbers for such modes.
19131 The minimum requirement for a mode to be OK in a register is that
19132 the `movMODE' instruction pattern support moves between the
19133 register and other hard register in the same class and that moving
19134 a value into the register and back out not alter it.
19136 Since the same instruction used to move `word_mode' will work for
19137 all narrower integer modes, it is not necessary on any machine for
19138 `HARD_REGNO_MODE_OK' to distinguish between these modes, provided
19139 you define patterns `movhi', etc., to take advantage of this. This
19140 is useful because of the interaction between `HARD_REGNO_MODE_OK'
19141 and `MODES_TIEABLE_P'; it is very desirable for all integer modes
19144 Many machines have special registers for floating point arithmetic.
19145 Often people assume that floating point machine modes are allowed
19146 only in floating point registers. This is not true. Any
19147 registers that can hold integers can safely _hold_ a floating
19148 point machine mode, whether or not floating arithmetic can be done
19149 on it in those registers. Integer move instructions can be used
19150 to move the values.
19152 On some machines, though, the converse is true: fixed-point machine
19153 modes may not go in floating registers. This is true if the
19154 floating registers normalize any value stored in them, because
19155 storing a non-floating value there would garble it. In this case,
19156 `HARD_REGNO_MODE_OK' should reject fixed-point machine modes in
19157 floating registers. But if the floating registers do not
19158 automatically normalize, if you can store any bit pattern in one
19159 and retrieve it unchanged without a trap, then any machine mode
19160 may go in a floating register, so you can define this macro to say
19163 The primary significance of special floating registers is rather
19164 that they are the registers acceptable in floating point arithmetic
19165 instructions. However, this is of no concern to
19166 `HARD_REGNO_MODE_OK'. You handle it by writing the proper
19167 constraints for those instructions.
19169 On some machines, the floating registers are especially slow to
19170 access, so that it is better to store a value in a stack frame
19171 than in such a register if floating point arithmetic is not being
19172 done. As long as the floating registers are not in class
19173 `GENERAL_REGS', they will not be used unless some pattern's
19174 constraint asks for one.
19176 -- Macro: HARD_REGNO_RENAME_OK (FROM, TO)
19177 A C expression that is nonzero if it is OK to rename a hard
19178 register FROM to another hard register TO.
19180 One common use of this macro is to prevent renaming of a register
19181 to another register that is not saved by a prologue in an interrupt
19184 The default is always nonzero.
19186 -- Macro: MODES_TIEABLE_P (MODE1, MODE2)
19187 A C expression that is nonzero if a value of mode MODE1 is
19188 accessible in mode MODE2 without copying.
19190 If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R,
19191 MODE2)' are always the same for any R, then `MODES_TIEABLE_P
19192 (MODE1, MODE2)' should be nonzero. If they differ for any R, you
19193 should define this macro to return zero unless some other
19194 mechanism ensures the accessibility of the value in a narrower
19197 You should define this macro to return nonzero in as many cases as
19198 possible since doing so will allow GCC to perform better register
19201 -- Macro: AVOID_CCMODE_COPIES
19202 Define this macro if the compiler should avoid copies to/from
19203 `CCmode' registers. You should only define this macro if support
19204 for copying to/from `CCmode' is incomplete.
19207 File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers
19209 14.7.4 Handling Leaf Functions
19210 ------------------------------
19212 On some machines, a leaf function (i.e., one which makes no calls) can
19213 run more efficiently if it does not make its own register window.
19214 Often this means it is required to receive its arguments in the
19215 registers where they are passed by the caller, instead of the registers
19216 where they would normally arrive.
19218 The special treatment for leaf functions generally applies only when
19219 other conditions are met; for example, often they may use only those
19220 registers for its own variables and temporaries. We use the term "leaf
19221 function" to mean a function that is suitable for this special
19222 handling, so that functions with no calls are not necessarily "leaf
19225 GCC assigns register numbers before it knows whether the function is
19226 suitable for leaf function treatment. So it needs to renumber the
19227 registers in order to output a leaf function. The following macros
19230 -- Macro: LEAF_REGISTERS
19231 Name of a char vector, indexed by hard register number, which
19232 contains 1 for a register that is allowable in a candidate for leaf
19233 function treatment.
19235 If leaf function treatment involves renumbering the registers,
19236 then the registers marked here should be the ones before
19237 renumbering--those that GCC would ordinarily allocate. The
19238 registers which will actually be used in the assembler code, after
19239 renumbering, should not be marked with 1 in this vector.
19241 Define this macro only if the target machine offers a way to
19242 optimize the treatment of leaf functions.
19244 -- Macro: LEAF_REG_REMAP (REGNO)
19245 A C expression whose value is the register number to which REGNO
19246 should be renumbered, when a function is treated as a leaf
19249 If REGNO is a register number which should not appear in a leaf
19250 function before renumbering, then the expression should yield -1,
19251 which will cause the compiler to abort.
19253 Define this macro only if the target machine offers a way to
19254 optimize the treatment of leaf functions, and registers need to be
19255 renumbered to do this.
19257 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' must
19258 usually treat leaf functions specially. They can test the C variable
19259 `current_function_is_leaf' which is nonzero for leaf functions.
19260 `current_function_is_leaf' is set prior to local register allocation
19261 and is valid for the remaining compiler passes. They can also test the
19262 C variable `current_function_uses_only_leaf_regs' which is nonzero for
19263 leaf functions which only use leaf registers.
19264 `current_function_uses_only_leaf_regs' is valid after all passes that
19265 modify the instructions have been run and is only useful if
19266 `LEAF_REGISTERS' is defined.
19269 File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers
19271 14.7.5 Registers That Form a Stack
19272 ----------------------------------
19274 There are special features to handle computers where some of the
19275 "registers" form a stack. Stack registers are normally written by
19276 pushing onto the stack, and are numbered relative to the top of the
19279 Currently, GCC can only handle one group of stack-like registers, and
19280 they must be consecutively numbered. Furthermore, the existing support
19281 for stack-like registers is specific to the 80387 floating point
19282 coprocessor. If you have a new architecture that uses stack-like
19283 registers, you will need to do substantial work on `reg-stack.c' and
19284 write your machine description to cooperate with it, as well as
19285 defining these macros.
19287 -- Macro: STACK_REGS
19288 Define this if the machine has any stack-like registers.
19290 -- Macro: FIRST_STACK_REG
19291 The number of the first stack-like register. This one is the top
19294 -- Macro: LAST_STACK_REG
19295 The number of the last stack-like register. This one is the
19296 bottom of the stack.
19299 File: gccint.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros
19301 14.8 Register Classes
19302 =====================
19304 On many machines, the numbered registers are not all equivalent. For
19305 example, certain registers may not be allowed for indexed addressing;
19306 certain registers may not be allowed in some instructions. These
19307 machine restrictions are described to the compiler using "register
19310 You define a number of register classes, giving each one a name and
19311 saying which of the registers belong to it. Then you can specify
19312 register classes that are allowed as operands to particular instruction
19315 In general, each register will belong to several classes. In fact, one
19316 class must be named `ALL_REGS' and contain all the registers. Another
19317 class must be named `NO_REGS' and contain no registers. Often the
19318 union of two classes will be another class; however, this is not
19321 One of the classes must be named `GENERAL_REGS'. There is nothing
19322 terribly special about the name, but the operand constraint letters `r'
19323 and `g' specify this class. If `GENERAL_REGS' is the same as
19324 `ALL_REGS', just define it as a macro which expands to `ALL_REGS'.
19326 Order the classes so that if class X is contained in class Y then X
19327 has a lower class number than Y.
19329 The way classes other than `GENERAL_REGS' are specified in operand
19330 constraints is through machine-dependent operand constraint letters.
19331 You can define such letters to correspond to various classes, then use
19332 them in operand constraints.
19334 You should define a class for the union of two classes whenever some
19335 instruction allows both classes. For example, if an instruction allows
19336 either a floating point (coprocessor) register or a general register
19337 for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS'
19338 which includes both of them. Otherwise you will get suboptimal code.
19340 You must also specify certain redundant information about the register
19341 classes: for each class, which classes contain it and which ones are
19342 contained in it; for each pair of classes, the largest class contained
19345 When a value occupying several consecutive registers is expected in a
19346 certain class, all the registers used must belong to that class.
19347 Therefore, register classes cannot be used to enforce a requirement for
19348 a register pair to start with an even-numbered register. The way to
19349 specify this requirement is with `HARD_REGNO_MODE_OK'.
19351 Register classes used for input-operands of bitwise-and or shift
19352 instructions have a special requirement: each such class must have, for
19353 each fixed-point machine mode, a subclass whose registers can transfer
19354 that mode to or from memory. For example, on some machines, the
19355 operations for single-byte values (`QImode') are limited to certain
19356 registers. When this is so, each register class that is used in a
19357 bitwise-and or shift instruction must have a subclass consisting of
19358 registers from which single-byte values can be loaded or stored. This
19359 is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to
19362 -- Data type: enum reg_class
19363 An enumerated type that must be defined with all the register
19364 class names as enumerated values. `NO_REGS' must be first.
19365 `ALL_REGS' must be the last register class, followed by one more
19366 enumerated value, `LIM_REG_CLASSES', which is not a register class
19367 but rather tells how many classes there are.
19369 Each register class has a number, which is the value of casting
19370 the class name to type `int'. The number serves as an index in
19371 many of the tables described below.
19373 -- Macro: N_REG_CLASSES
19374 The number of distinct register classes, defined as follows:
19376 #define N_REG_CLASSES (int) LIM_REG_CLASSES
19378 -- Macro: REG_CLASS_NAMES
19379 An initializer containing the names of the register classes as C
19380 string constants. These names are used in writing some of the
19383 -- Macro: REG_CLASS_CONTENTS
19384 An initializer containing the contents of the register classes, as
19385 integers which are bit masks. The Nth integer specifies the
19386 contents of class N. The way the integer MASK is interpreted is
19387 that register R is in the class if `MASK & (1 << R)' is 1.
19389 When the machine has more than 32 registers, an integer does not
19390 suffice. Then the integers are replaced by sub-initializers,
19391 braced groupings containing several integers. Each
19392 sub-initializer must be suitable as an initializer for the type
19393 `HARD_REG_SET' which is defined in `hard-reg-set.h'. In this
19394 situation, the first integer in each sub-initializer corresponds to
19395 registers 0 through 31, the second integer to registers 32 through
19398 -- Macro: REGNO_REG_CLASS (REGNO)
19399 A C expression whose value is a register class containing hard
19400 register REGNO. In general there is more than one such class;
19401 choose a class which is "minimal", meaning that no smaller class
19402 also contains the register.
19404 -- Macro: BASE_REG_CLASS
19405 A macro whose definition is the name of the class to which a valid
19406 base register must belong. A base register is one used in an
19407 address which is the register value plus a displacement.
19409 -- Macro: MODE_BASE_REG_CLASS (MODE)
19410 This is a variation of the `BASE_REG_CLASS' macro which allows the
19411 selection of a base register in a mode dependent manner. If MODE
19412 is VOIDmode then it should return the same value as
19415 -- Macro: MODE_BASE_REG_REG_CLASS (MODE)
19416 A C expression whose value is the register class to which a valid
19417 base register must belong in order to be used in a base plus index
19418 register address. You should define this macro if base plus index
19419 addresses have different requirements than other base register
19422 -- Macro: INDEX_REG_CLASS
19423 A macro whose definition is the name of the class to which a valid
19424 index register must belong. An index register is one used in an
19425 address where its value is either multiplied by a scale factor or
19426 added to another register (as well as added to a displacement).
19428 -- Macro: CONSTRAINT_LEN (CHAR, STR)
19429 For the constraint at the start of STR, which starts with the
19430 letter C, return the length. This allows you to have register
19431 class / constant / extra constraints that are longer than a single
19432 letter; you don't need to define this macro if you can do with
19433 single-letter constraints only. The definition of this macro
19434 should use DEFAULT_CONSTRAINT_LEN for all the characters that you
19435 don't want to handle specially. There are some sanity checks in
19436 genoutput.c that check the constraint lengths for the md file, so
19437 you can also use this macro to help you while you are
19438 transitioning from a byzantine single-letter-constraint scheme:
19439 when you return a negative length for a constraint you want to
19440 re-use, genoutput will complain about every instance where it is
19441 used in the md file.
19443 -- Macro: REG_CLASS_FROM_LETTER (CHAR)
19444 A C expression which defines the machine-dependent operand
19445 constraint letters for register classes. If CHAR is such a
19446 letter, the value should be the register class corresponding to
19447 it. Otherwise, the value should be `NO_REGS'. The register
19448 letter `r', corresponding to class `GENERAL_REGS', will not be
19449 passed to this macro; you do not need to handle it.
19451 -- Macro: REG_CLASS_FROM_CONSTRAINT (CHAR, STR)
19452 Like `REG_CLASS_FROM_LETTER', but you also get the constraint
19453 string passed in STR, so that you can use suffixes to distinguish
19454 between different variants.
19456 -- Macro: REGNO_OK_FOR_BASE_P (NUM)
19457 A C expression which is nonzero if register number NUM is suitable
19458 for use as a base register in operand addresses. It may be either
19459 a suitable hard register or a pseudo register that has been
19460 allocated such a hard register.
19462 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE)
19463 A C expression that is just like `REGNO_OK_FOR_BASE_P', except that
19464 that expression may examine the mode of the memory reference in
19465 MODE. You should define this macro if the mode of the memory
19466 reference affects whether a register may be used as a base
19467 register. If you define this macro, the compiler will use it
19468 instead of `REGNO_OK_FOR_BASE_P'.
19470 -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE)
19471 A C expression which is nonzero if register number NUM is suitable
19472 for use as a base register in base plus index operand addresses,
19473 accessing memory in mode MODE. It may be either a suitable hard
19474 register or a pseudo register that has been allocated such a hard
19475 register. You should define this macro if base plus index
19476 addresses have different requirements than other base register
19479 -- Macro: REGNO_OK_FOR_INDEX_P (NUM)
19480 A C expression which is nonzero if register number NUM is suitable
19481 for use as an index register in operand addresses. It may be
19482 either a suitable hard register or a pseudo register that has been
19483 allocated such a hard register.
19485 The difference between an index register and a base register is
19486 that the index register may be scaled. If an address involves the
19487 sum of two registers, neither one of them scaled, then either one
19488 may be labeled the "base" and the other the "index"; but whichever
19489 labeling is used must fit the machine's constraints of which
19490 registers may serve in each capacity. The compiler will try both
19491 labelings, looking for one that is valid, and will reload one or
19492 both registers only if neither labeling works.
19494 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS)
19495 A C expression that places additional restrictions on the register
19496 class to use when it is necessary to copy value X into a register
19497 in class CLASS. The value is a register class; perhaps CLASS, or
19498 perhaps another, smaller class. On many machines, the following
19499 definition is safe:
19501 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
19503 Sometimes returning a more restrictive class makes better code.
19504 For example, on the 68000, when X is an integer constant that is
19505 in range for a `moveq' instruction, the value of this macro is
19506 always `DATA_REGS' as long as CLASS includes the data registers.
19507 Requiring a data register guarantees that a `moveq' will be used.
19509 One case where `PREFERRED_RELOAD_CLASS' must not return CLASS is
19510 if X is a legitimate constant which cannot be loaded into some
19511 register class. By returning `NO_REGS' you can force X into a
19512 memory location. For example, rs6000 can load immediate values
19513 into general-purpose registers, but does not have an instruction
19514 for loading an immediate value into a floating-point register, so
19515 `PREFERRED_RELOAD_CLASS' returns `NO_REGS' when X is a
19516 floating-point constant. If the constant can't be loaded into any
19517 kind of register, code generation will be better if
19518 `LEGITIMATE_CONSTANT_P' makes the constant illegitimate instead of
19519 using `PREFERRED_RELOAD_CLASS'.
19521 -- Macro: PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS)
19522 Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of
19523 input reloads. If you don't define this macro, the default is to
19524 use CLASS, unchanged.
19526 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS)
19527 A C expression that places additional restrictions on the register
19528 class to use when it is necessary to be able to hold a value of
19529 mode MODE in a reload register for which class CLASS would
19530 ordinarily be used.
19532 Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when
19533 there are certain modes that simply can't go in certain reload
19536 The value is a register class; perhaps CLASS, or perhaps another,
19539 Don't define this macro unless the target machine has limitations
19540 which require the macro to do something nontrivial.
19542 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X)
19543 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)
19544 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)
19545 Many machines have some registers that cannot be copied directly
19546 to or from memory or even from other types of registers. An
19547 example is the `MQ' register, which on most machines, can only be
19548 copied to or from general registers, but not memory. Some
19549 machines allow copying all registers to and from memory, but
19550 require a scratch register for stores to some memory locations
19551 (e.g., those with symbolic address on the RT, and those with
19552 certain symbolic address on the SPARC when compiling PIC). In
19553 some cases, both an intermediate and a scratch register are
19556 You should define these macros to indicate to the reload phase
19557 that it may need to allocate at least one register for a reload in
19558 addition to the register to contain the data. Specifically, if
19559 copying X to a register CLASS in MODE requires an intermediate
19560 register, you should define `SECONDARY_INPUT_RELOAD_CLASS' to
19561 return the largest register class all of whose registers can be
19562 used as intermediate registers or scratch registers.
19564 If copying a register CLASS in MODE to X requires an intermediate
19565 or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' should be
19566 defined to return the largest register class required. If the
19567 requirements for input and output reloads are the same, the macro
19568 `SECONDARY_RELOAD_CLASS' should be used instead of defining both
19569 macros identically.
19571 The values returned by these macros are often `GENERAL_REGS'.
19572 Return `NO_REGS' if no spare register is needed; i.e., if X can be
19573 directly copied to or from a register of CLASS in MODE without
19574 requiring a scratch register. Do not define this macro if it
19575 would always return `NO_REGS'.
19577 If a scratch register is required (either with or without an
19578 intermediate register), you should define patterns for
19579 `reload_inM' or `reload_outM', as required (*note Standard
19580 Names::. These patterns, which will normally be implemented with
19581 a `define_expand', should be similar to the `movM' patterns,
19582 except that operand 2 is the scratch register.
19584 Define constraints for the reload register and scratch register
19585 that contain a single register class. If the original reload
19586 register (whose class is CLASS) can meet the constraint given in
19587 the pattern, the value returned by these macros is used for the
19588 class of the scratch register. Otherwise, two additional reload
19589 registers are required. Their classes are obtained from the
19590 constraints in the insn pattern.
19592 X might be a pseudo-register or a `subreg' of a pseudo-register,
19593 which could either be in a hard register or in memory. Use
19594 `true_regnum' to find out; it will return -1 if the pseudo is in
19595 memory and the hard register number if it is in a register.
19597 These macros should not be used in the case where a particular
19598 class of registers can only be copied to memory and not to another
19599 class of registers. In that case, secondary reload registers are
19600 not needed and would not be helpful. Instead, a stack location
19601 must be used to perform the copy and the `movM' pattern should use
19602 memory as an intermediate storage. This case often occurs between
19603 floating-point and general registers.
19605 -- Macro: SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M)
19606 Certain machines have the property that some registers cannot be
19607 copied to some other registers without using memory. Define this
19608 macro on those machines to be a C expression that is nonzero if
19609 objects of mode M in registers of CLASS1 can only be copied to
19610 registers of class CLASS2 by storing a register of CLASS1 into
19611 memory and loading that memory location into a register of CLASS2.
19613 Do not define this macro if its value would always be zero.
19615 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE)
19616 Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler
19617 allocates a stack slot for a memory location needed for register
19618 copies. If this macro is defined, the compiler instead uses the
19619 memory location defined by this macro.
19621 Do not define this macro if you do not define
19622 `SECONDARY_MEMORY_NEEDED'.
19624 -- Macro: SECONDARY_MEMORY_NEEDED_MODE (MODE)
19625 When the compiler needs a secondary memory location to copy
19626 between two registers of mode MODE, it normally allocates
19627 sufficient memory to hold a quantity of `BITS_PER_WORD' bits and
19628 performs the store and load operations in a mode that many bits
19629 wide and whose class is the same as that of MODE.
19631 This is right thing to do on most machines because it ensures that
19632 all bits of the register are copied and prevents accesses to the
19633 registers in a narrower mode, which some machines prohibit for
19634 floating-point registers.
19636 However, this default behavior is not correct on some machines,
19637 such as the DEC Alpha, that store short integers in floating-point
19638 registers differently than in integer registers. On those
19639 machines, the default widening will not work correctly and you
19640 must define this macro to suppress that widening in some cases.
19641 See the file `alpha.h' for details.
19643 Do not define this macro if you do not define
19644 `SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is
19645 `BITS_PER_WORD' bits wide is correct for your machine.
19647 -- Macro: SMALL_REGISTER_CLASSES
19648 On some machines, it is risky to let hard registers live across
19649 arbitrary insns. Typically, these machines have instructions that
19650 require values to be in specific registers (like an accumulator),
19651 and reload will fail if the required hard register is used for
19652 another purpose across such an insn.
19654 Define `SMALL_REGISTER_CLASSES' to be an expression with a nonzero
19655 value on these machines. When this macro has a nonzero value, the
19656 compiler will try to minimize the lifetime of hard registers.
19658 It is always safe to define this macro with a nonzero value, but
19659 if you unnecessarily define it, you will reduce the amount of
19660 optimizations that can be performed in some cases. If you do not
19661 define this macro with a nonzero value when it is required, the
19662 compiler will run out of spill registers and print a fatal error
19663 message. For most machines, you should not define this macro at
19666 -- Macro: CLASS_LIKELY_SPILLED_P (CLASS)
19667 A C expression whose value is nonzero if pseudos that have been
19668 assigned to registers of class CLASS would likely be spilled
19669 because registers of CLASS are needed for spill registers.
19671 The default value of this macro returns 1 if CLASS has exactly one
19672 register and zero otherwise. On most machines, this default
19673 should be used. Only define this macro to some other expression
19674 if pseudos allocated by `local-alloc.c' end up in memory because
19675 their hard registers were needed for spill registers. If this
19676 macro returns nonzero for those classes, those pseudos will only
19677 be allocated by `global.c', which knows how to reallocate the
19678 pseudo to another register. If there would not be another
19679 register available for reallocation, you should not change the
19680 definition of this macro since the only effect of such a
19681 definition would be to slow down register allocation.
19683 -- Macro: CLASS_MAX_NREGS (CLASS, MODE)
19684 A C expression for the maximum number of consecutive registers of
19685 class CLASS needed to hold a value of mode MODE.
19687 This is closely related to the macro `HARD_REGNO_NREGS'. In fact,
19688 the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be
19689 the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all
19690 REGNO values in the class CLASS.
19692 This macro helps control the handling of multiple-word values in
19695 -- Macro: CANNOT_CHANGE_MODE_CLASS (FROM, TO, CLASS)
19696 If defined, a C expression that returns nonzero for a CLASS for
19697 which a change from mode FROM to mode TO is invalid.
19699 For the example, loading 32-bit integer or floating-point objects
19700 into floating-point registers on the Alpha extends them to 64 bits.
19701 Therefore loading a 64-bit object and then storing it as a 32-bit
19702 object does not store the low-order 32 bits, as would be the case
19703 for a normal register. Therefore, `alpha.h' defines
19704 `CANNOT_CHANGE_MODE_CLASS' as below:
19706 #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \
19707 (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \
19708 ? reg_classes_intersect_p (FLOAT_REGS, (CLASS)) : 0)
19710 Three other special macros describe which operands fit which constraint
19713 -- Macro: CONST_OK_FOR_LETTER_P (VALUE, C)
19714 A C expression that defines the machine-dependent operand
19715 constraint letters (`I', `J', `K', ... `P') that specify
19716 particular ranges of integer values. If C is one of those
19717 letters, the expression should check that VALUE, an integer, is in
19718 the appropriate range and return 1 if so, 0 otherwise. If C is
19719 not one of those letters, the value should be 0 regardless of
19722 -- Macro: CONST_OK_FOR_CONSTRAINT_P (VALUE, C, STR)
19723 Like `CONST_OK_FOR_LETTER_P', but you also get the constraint
19724 string passed in STR, so that you can use suffixes to distinguish
19725 between different variants.
19727 -- Macro: CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)
19728 A C expression that defines the machine-dependent operand
19729 constraint letters that specify particular ranges of
19730 `const_double' values (`G' or `H').
19732 If C is one of those letters, the expression should check that
19733 VALUE, an RTX of code `const_double', is in the appropriate range
19734 and return 1 if so, 0 otherwise. If C is not one of those
19735 letters, the value should be 0 regardless of VALUE.
19737 `const_double' is used for all floating-point constants and for
19738 `DImode' fixed-point constants. A given letter can accept either
19739 or both kinds of values. It can use `GET_MODE' to distinguish
19740 between these kinds.
19742 -- Macro: CONST_DOUBLE_OK_FOR_CONSTRAINT_P (VALUE, C, STR)
19743 Like `CONST_DOUBLE_OK_FOR_LETTER_P', but you also get the
19744 constraint string passed in STR, so that you can use suffixes to
19745 distinguish between different variants.
19747 -- Macro: EXTRA_CONSTRAINT (VALUE, C)
19748 A C expression that defines the optional machine-dependent
19749 constraint letters that can be used to segregate specific types of
19750 operands, usually memory references, for the target machine. Any
19751 letter that is not elsewhere defined and not matched by
19752 `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' may be used.
19753 Normally this macro will not be defined.
19755 If it is required for a particular target machine, it should
19756 return 1 if VALUE corresponds to the operand type represented by
19757 the constraint letter C. If C is not defined as an extra
19758 constraint, the value returned should be 0 regardless of VALUE.
19760 For example, on the ROMP, load instructions cannot have their
19761 output in r0 if the memory reference contains a symbolic address.
19762 Constraint letter `Q' is defined as representing a memory address
19763 that does _not_ contain a symbolic address. An alternative is
19764 specified with a `Q' constraint on the input and `r' on the
19765 output. The next alternative specifies `m' on the input and a
19766 register class that does not include r0 on the output.
19768 -- Macro: EXTRA_CONSTRAINT_STR (VALUE, C, STR)
19769 Like `EXTRA_CONSTRAINT', but you also get the constraint string
19770 passed in STR, so that you can use suffixes to distinguish between
19771 different variants.
19773 -- Macro: EXTRA_MEMORY_CONSTRAINT (C, STR)
19774 A C expression that defines the optional machine-dependent
19775 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT',
19776 that should be treated like memory constraints by the reload pass.
19778 It should return 1 if the operand type represented by the
19779 constraint at the start of STR, the first letter of which is the
19780 letter C, comprises a subset of all memory references including
19781 all those whose address is simply a base register. This allows
19782 the reload pass to reload an operand, if it does not directly
19783 correspond to the operand type of C, by copying its address into a
19786 For example, on the S/390, some instructions do not accept
19787 arbitrary memory references, but only those that do not make use
19788 of an index register. The constraint letter `Q' is defined via
19789 `EXTRA_CONSTRAINT' as representing a memory address of this type.
19790 If the letter `Q' is marked as `EXTRA_MEMORY_CONSTRAINT', a `Q'
19791 constraint can handle any memory operand, because the reload pass
19792 knows it can be reloaded by copying the memory address into a base
19793 register if required. This is analogous to the way a `o'
19794 constraint can handle any memory operand.
19796 -- Macro: EXTRA_ADDRESS_CONSTRAINT (C, STR)
19797 A C expression that defines the optional machine-dependent
19798 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT' /
19799 `EXTRA_CONSTRAINT_STR', that should be treated like address
19800 constraints by the reload pass.
19802 It should return 1 if the operand type represented by the
19803 constraint at the start of STR, which starts with the letter C,
19804 comprises a subset of all memory addresses including all those
19805 that consist of just a base register. This allows the reload pass
19806 to reload an operand, if it does not directly correspond to the
19807 operand type of STR, by copying it into a base register.
19809 Any constraint marked as `EXTRA_ADDRESS_CONSTRAINT' can only be
19810 used with the `address_operand' predicate. It is treated
19811 analogously to the `p' constraint.
19814 File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros
19816 14.9 Stack Layout and Calling Conventions
19817 =========================================
19819 This describes the stack layout and calling conventions.
19824 * Exception Handling::
19826 * Frame Registers::
19828 * Stack Arguments::
19829 * Register Arguments::
19831 * Aggregate Return::
19836 * Stack Smashing Protection::
19839 File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling
19841 14.9.1 Basic Stack Layout
19842 -------------------------
19844 Here is the basic stack layout.
19846 -- Macro: STACK_GROWS_DOWNWARD
19847 Define this macro if pushing a word onto the stack moves the stack
19848 pointer to a smaller address.
19850 When we say, "define this macro if ...", it means that the
19851 compiler checks this macro only with `#ifdef' so the precise
19852 definition used does not matter.
19854 -- Macro: STACK_PUSH_CODE
19855 This macro defines the operation used when something is pushed on
19856 the stack. In RTL, a push operation will be `(set (mem
19857 (STACK_PUSH_CODE (reg sp))) ...)'
19859 The choices are `PRE_DEC', `POST_DEC', `PRE_INC', and `POST_INC'.
19860 Which of these is correct depends on the stack direction and on
19861 whether the stack pointer points to the last item on the stack or
19862 whether it points to the space for the next item on the stack.
19864 The default is `PRE_DEC' when `STACK_GROWS_DOWNWARD' is defined,
19865 which is almost always right, and `PRE_INC' otherwise, which is
19868 -- Macro: FRAME_GROWS_DOWNWARD
19869 Define this macro to nonzero value if the addresses of local
19870 variable slots are at negative offsets from the frame pointer.
19872 -- Macro: ARGS_GROW_DOWNWARD
19873 Define this macro if successive arguments to a function occupy
19874 decreasing addresses on the stack.
19876 -- Macro: STARTING_FRAME_OFFSET
19877 Offset from the frame pointer to the first local variable slot to
19880 If `FRAME_GROWS_DOWNWARD', find the next slot's offset by
19881 subtracting the first slot's length from `STARTING_FRAME_OFFSET'.
19882 Otherwise, it is found by adding the length of the first slot to
19883 the value `STARTING_FRAME_OFFSET'.
19885 -- Macro: STACK_ALIGNMENT_NEEDED
19886 Define to zero to disable final alignment of the stack during
19887 reload. The nonzero default for this macro is suitable for most
19890 On ports where `STARTING_FRAME_OFFSET' is nonzero or where there
19891 is a register save block following the local block that doesn't
19892 require alignment to `STACK_BOUNDARY', it may be beneficial to
19893 disable stack alignment and do it in the backend.
19895 -- Macro: STACK_POINTER_OFFSET
19896 Offset from the stack pointer register to the first location at
19897 which outgoing arguments are placed. If not specified, the
19898 default value of zero is used. This is the proper value for most
19901 If `ARGS_GROW_DOWNWARD', this is the offset to the location above
19902 the first location at which outgoing arguments are placed.
19904 -- Macro: FIRST_PARM_OFFSET (FUNDECL)
19905 Offset from the argument pointer register to the first argument's
19906 address. On some machines it may depend on the data type of the
19909 If `ARGS_GROW_DOWNWARD', this is the offset to the location above
19910 the first argument's address.
19912 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL)
19913 Offset from the stack pointer register to an item dynamically
19914 allocated on the stack, e.g., by `alloca'.
19916 The default value for this macro is `STACK_POINTER_OFFSET' plus the
19917 length of the outgoing arguments. The default is correct for most
19918 machines. See `function.c' for details.
19920 -- Macro: INITIAL_FRAME_ADDRESS_RTX
19921 A C expression whose value is RTL representing the address of the
19922 initial stack frame. This address is passed to `RETURN_ADDR_RTX'
19923 and `DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a
19924 reasonable default value will be used. Define this macro in order
19925 to make frame pointer elimination work in the presence of
19926 `__builtin_frame_address (count)' and `__builtin_return_address
19927 (count)' for `count' not equal to zero.
19929 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)
19930 A C expression whose value is RTL representing the address in a
19931 stack frame where the pointer to the caller's frame is stored.
19932 Assume that FRAMEADDR is an RTL expression for the address of the
19933 stack frame itself.
19935 If you don't define this macro, the default is to return the value
19936 of FRAMEADDR--that is, the stack frame address is also the address
19937 of the stack word that points to the previous frame.
19939 -- Macro: SETUP_FRAME_ADDRESSES
19940 If defined, a C expression that produces the machine-specific code
19941 to setup the stack so that arbitrary frames can be accessed. For
19942 example, on the SPARC, we must flush all of the register windows
19943 to the stack before we can access arbitrary stack frames. You
19944 will seldom need to define this macro.
19946 -- Target Hook: bool TARGET_BUILTIN_SETJMP_FRAME_VALUE ()
19947 This target hook should return an rtx that is used to store the
19948 address of the current frame into the built in `setjmp' buffer.
19949 The default value, `virtual_stack_vars_rtx', is correct for most
19950 machines. One reason you may need to define this target hook is if
19951 `hard_frame_pointer_rtx' is the appropriate value on your machine.
19953 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR)
19954 A C expression whose value is RTL representing the value of the
19955 return address for the frame COUNT steps up from the current
19956 frame, after the prologue. FRAMEADDR is the frame pointer of the
19957 COUNT frame, or the frame pointer of the COUNT - 1 frame if
19958 `RETURN_ADDR_IN_PREVIOUS_FRAME' is defined.
19960 The value of the expression must always be the correct address when
19961 COUNT is zero, but may be `NULL_RTX' if there is not way to
19962 determine the return address of other frames.
19964 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME
19965 Define this if the return address of a particular stack frame is
19966 accessed from the frame pointer of the previous stack frame.
19968 -- Macro: INCOMING_RETURN_ADDR_RTX
19969 A C expression whose value is RTL representing the location of the
19970 incoming return address at the beginning of any function, before
19971 the prologue. This RTL is either a `REG', indicating that the
19972 return value is saved in `REG', or a `MEM' representing a location
19975 You only need to define this macro if you want to support call
19976 frame debugging information like that provided by DWARF 2.
19978 If this RTL is a `REG', you should also define
19979 `DWARF_FRAME_RETURN_COLUMN' to `DWARF_FRAME_REGNUM (REGNO)'.
19981 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN
19982 A C expression whose value is an integer giving a DWARF 2 column
19983 number that may be used as an alternate return column. This should
19984 be defined only if `DWARF_FRAME_RETURN_COLUMN' is set to a general
19985 register, but an alternate column needs to be used for signal
19988 -- Macro: DWARF_ZERO_REG
19989 A C expression whose value is an integer giving a DWARF 2 register
19990 number that is considered to always have the value zero. This
19991 should only be defined if the target has an architected zero
19992 register, and someone decided it was a good idea to use that
19993 register number to terminate the stack backtrace. New ports
19996 -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char
19997 *LABEL, rtx PATTERN, int INDEX)
19998 This target hook allows the backend to emit frame-related insns
19999 that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame
20000 debugging info engine will invoke it on insns of the form
20001 (set (reg) (unspec [...] UNSPEC_INDEX))
20003 (set (reg) (unspec_volatile [...] UNSPECV_INDEX)).
20004 to let the backend emit the call frame instructions. LABEL is the
20005 CFI label attached to the insn, PATTERN is the pattern of the insn
20006 and INDEX is `UNSPEC_INDEX' or `UNSPECV_INDEX'.
20008 -- Macro: INCOMING_FRAME_SP_OFFSET
20009 A C expression whose value is an integer giving the offset, in
20010 bytes, from the value of the stack pointer register to the top of
20011 the stack frame at the beginning of any function, before the
20012 prologue. The top of the frame is defined to be the value of the
20013 stack pointer in the previous frame, just before the call
20016 You only need to define this macro if you want to support call
20017 frame debugging information like that provided by DWARF 2.
20019 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL)
20020 A C expression whose value is an integer giving the offset, in
20021 bytes, from the argument pointer to the canonical frame address
20022 (cfa). The final value should coincide with that calculated by
20023 `INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable
20024 during virtual register instantiation.
20026 The default value for this macro is `FIRST_PARM_OFFSET (fundecl)',
20027 which is correct for most machines; in general, the arguments are
20028 found immediately before the stack frame. Note that this is not
20029 the case on some targets that save registers into the caller's
20030 frame, such as SPARC and rs6000, and so such targets need to
20033 You only need to define this macro if the default is incorrect,
20034 and you want to support call frame debugging information like that
20035 provided by DWARF 2.
20037 -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL)
20038 If defined, a C expression whose value is an integer giving the
20039 offset in bytes from the frame pointer to the canonical frame
20040 address (cfa). The final value should conincide with that
20041 calculated by `INCOMING_FRAME_SP_OFFSET'.
20043 Normally the CFA is calculated as an offset from the argument
20044 pointer, via `ARG_POINTER_CFA_OFFSET', but if the argument pointer
20045 is variable due to the ABI, this may not be possible. If this
20046 macro is defined, it imples that the virtual register
20047 instantiation should be based on the frame pointer instead of the
20048 argument pointer. Only one of `FRAME_POINTER_CFA_OFFSET' and
20049 `ARG_POINTER_CFA_OFFSET' should be defined.
20052 File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling
20054 14.9.2 Exception Handling Support
20055 ---------------------------------
20057 -- Macro: EH_RETURN_DATA_REGNO (N)
20058 A C expression whose value is the Nth register number used for
20059 data by exception handlers, or `INVALID_REGNUM' if fewer than N
20060 registers are usable.
20062 The exception handling library routines communicate with the
20063 exception handlers via a set of agreed upon registers. Ideally
20064 these registers should be call-clobbered; it is possible to use
20065 call-saved registers, but may negatively impact code size. The
20066 target must support at least 2 data registers, but should define 4
20067 if there are enough free registers.
20069 You must define this macro if you want to support call frame
20070 exception handling like that provided by DWARF 2.
20072 -- Macro: EH_RETURN_STACKADJ_RTX
20073 A C expression whose value is RTL representing a location in which
20074 to store a stack adjustment to be applied before function return.
20075 This is used to unwind the stack to an exception handler's call
20076 frame. It will be assigned zero on code paths that return
20079 Typically this is a call-clobbered hard register that is otherwise
20080 untouched by the epilogue, but could also be a stack slot.
20082 Do not define this macro if the stack pointer is saved and restored
20083 by the regular prolog and epilog code in the call frame itself; in
20084 this case, the exception handling library routines will update the
20085 stack location to be restored in place. Otherwise, you must define
20086 this macro if you want to support call frame exception handling
20087 like that provided by DWARF 2.
20089 -- Macro: EH_RETURN_HANDLER_RTX
20090 A C expression whose value is RTL representing a location in which
20091 to store the address of an exception handler to which we should
20092 return. It will not be assigned on code paths that return
20095 Typically this is the location in the call frame at which the
20096 normal return address is stored. For targets that return by
20097 popping an address off the stack, this might be a memory address
20098 just below the _target_ call frame rather than inside the current
20099 call frame. If defined, `EH_RETURN_STACKADJ_RTX' will have already
20100 been assigned, so it may be used to calculate the location of the
20103 Some targets have more complex requirements than storing to an
20104 address calculable during initial code generation. In that case
20105 the `eh_return' instruction pattern should be used instead.
20107 If you want to support call frame exception handling, you must
20108 define either this macro or the `eh_return' instruction pattern.
20110 -- Macro: RETURN_ADDR_OFFSET
20111 If defined, an integer-valued C expression for which rtl will be
20112 generated to add it to the exception handler address before it is
20113 searched in the exception handling tables, and to subtract it
20114 again from the address before using it to return to the exception
20117 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL)
20118 This macro chooses the encoding of pointers embedded in the
20119 exception handling sections. If at all possible, this should be
20120 defined such that the exception handling section will not require
20121 dynamic relocations, and so may be read-only.
20123 CODE is 0 for data, 1 for code labels, 2 for function pointers.
20124 GLOBAL is true if the symbol may be affected by dynamic
20125 relocations. The macro should return a combination of the
20126 `DW_EH_PE_*' defines as found in `dwarf2.h'.
20128 If this macro is not defined, pointers will not be encoded but
20129 represented directly.
20131 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE,
20133 This macro allows the target to emit whatever special magic is
20134 required to represent the encoding chosen by
20135 `ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of
20136 pc-relative and indirect encodings; this must be defined if the
20137 target uses text-relative or data-relative encodings.
20139 This is a C statement that branches to DONE if the format was
20140 handled. ENCODING is the format chosen, SIZE is the number of
20141 bytes that the format occupies, ADDR is the `SYMBOL_REF' to be
20144 -- Macro: MD_UNWIND_SUPPORT
20145 A string specifying a file to be #include'd in unwind-dw2.c. The
20146 file so included typically defines `MD_FALLBACK_FRAME_STATE_FOR'.
20148 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS)
20149 This macro allows the target to add cpu and operating system
20150 specific code to the call-frame unwinder for use when there is no
20151 unwind data available. The most common reason to implement this
20152 macro is to unwind through signal frames.
20154 This macro is called from `uw_frame_state_for' in `unwind-dw2.c'
20155 and `unwind-ia64.c'. CONTEXT is an `_Unwind_Context'; FS is an
20156 `_Unwind_FrameState'. Examine `context->ra' for the address of
20157 the code being executed and `context->cfa' for the stack pointer
20158 value. If the frame can be decoded, the register save addresses
20159 should be updated in FS and the macro should evaluate to
20160 `_URC_NO_REASON'. If the frame cannot be decoded, the macro should
20161 evaluate to `_URC_END_OF_STACK'.
20163 For proper signal handling in Java this macro is accompanied by
20164 `MAKE_THROW_FRAME', defined in `libjava/include/*-signal.h'
20167 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS)
20168 This macro allows the target to add operating system specific code
20169 to the call-frame unwinder to handle the IA-64 `.unwabi' unwinding
20170 directive, usually used for signal or interrupt frames.
20172 This macro is called from `uw_update_context' in `unwind-ia64.c'.
20173 CONTEXT is an `_Unwind_Context'; FS is an `_Unwind_FrameState'.
20174 Examine `fs->unwabi' for the abi and context in the `.unwabi'
20175 directive. If the `.unwabi' directive can be handled, the
20176 register save addresses should be updated in FS.
20178 -- Macro: TARGET_USES_WEAK_UNWIND_INFO
20179 A C expression that evaluates to true if the target requires unwind
20180 info to be given comdat linkage. Define it to be `1' if comdat
20181 linkage is necessary. The default is `0'.
20184 File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling
20186 14.9.3 Specifying How Stack Checking is Done
20187 --------------------------------------------
20189 GCC will check that stack references are within the boundaries of the
20190 stack, if the `-fstack-check' is specified, in one of three ways:
20192 1. If the value of the `STACK_CHECK_BUILTIN' macro is nonzero, GCC
20193 will assume that you have arranged for stack checking to be done at
20194 appropriate places in the configuration files, e.g., in
20195 `TARGET_ASM_FUNCTION_PROLOGUE'. GCC will do not other special
20198 2. If `STACK_CHECK_BUILTIN' is zero and you defined a named pattern
20199 called `check_stack' in your `md' file, GCC will call that pattern
20200 with one argument which is the address to compare the stack value
20201 against. You must arrange for this pattern to report an error if
20202 the stack pointer is out of range.
20204 3. If neither of the above are true, GCC will generate code to
20205 periodically "probe" the stack pointer using the values of the
20206 macros defined below.
20208 Normally, you will use the default values of these macros, so GCC will
20209 use the third approach.
20211 -- Macro: STACK_CHECK_BUILTIN
20212 A nonzero value if stack checking is done by the configuration
20213 files in a machine-dependent manner. You should define this macro
20214 if stack checking is require by the ABI of your machine or if you
20215 would like to have to stack checking in some more efficient way
20216 than GCC's portable approach. The default value of this macro is
20219 -- Macro: STACK_CHECK_PROBE_INTERVAL
20220 An integer representing the interval at which GCC must generate
20221 stack probe instructions. You will normally define this macro to
20222 be no larger than the size of the "guard pages" at the end of a
20223 stack area. The default value of 4096 is suitable for most
20226 -- Macro: STACK_CHECK_PROBE_LOAD
20227 A integer which is nonzero if GCC should perform the stack probe
20228 as a load instruction and zero if GCC should use a store
20229 instruction. The default is zero, which is the most efficient
20230 choice on most systems.
20232 -- Macro: STACK_CHECK_PROTECT
20233 The number of bytes of stack needed to recover from a stack
20234 overflow, for languages where such a recovery is supported. The
20235 default value of 75 words should be adequate for most machines.
20237 -- Macro: STACK_CHECK_MAX_FRAME_SIZE
20238 The maximum size of a stack frame, in bytes. GCC will generate
20239 probe instructions in non-leaf functions to ensure at least this
20240 many bytes of stack are available. If a stack frame is larger
20241 than this size, stack checking will not be reliable and GCC will
20242 issue a warning. The default is chosen so that GCC only generates
20243 one instruction on most systems. You should normally not change
20244 the default value of this macro.
20246 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE
20247 GCC uses this value to generate the above warning message. It
20248 represents the amount of fixed frame used by a function, not
20249 including space for any callee-saved registers, temporaries and
20250 user variables. You need only specify an upper bound for this
20251 amount and will normally use the default of four words.
20253 -- Macro: STACK_CHECK_MAX_VAR_SIZE
20254 The maximum size, in bytes, of an object that GCC will place in the
20255 fixed area of the stack frame when the user specifies
20256 `-fstack-check'. GCC computed the default from the values of the
20257 above macros and you will normally not need to override that
20261 File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling
20263 14.9.4 Registers That Address the Stack Frame
20264 ---------------------------------------------
20266 This discusses registers that address the stack frame.
20268 -- Macro: STACK_POINTER_REGNUM
20269 The register number of the stack pointer register, which must also
20270 be a fixed register according to `FIXED_REGISTERS'. On most
20271 machines, the hardware determines which register this is.
20273 -- Macro: FRAME_POINTER_REGNUM
20274 The register number of the frame pointer register, which is used to
20275 access automatic variables in the stack frame. On some machines,
20276 the hardware determines which register this is. On other
20277 machines, you can choose any register you wish for this purpose.
20279 -- Macro: HARD_FRAME_POINTER_REGNUM
20280 On some machines the offset between the frame pointer and starting
20281 offset of the automatic variables is not known until after register
20282 allocation has been done (for example, because the saved registers
20283 are between these two locations). On those machines, define
20284 `FRAME_POINTER_REGNUM' the number of a special, fixed register to
20285 be used internally until the offset is known, and define
20286 `HARD_FRAME_POINTER_REGNUM' to be the actual hard register number
20287 used for the frame pointer.
20289 You should define this macro only in the very rare circumstances
20290 when it is not possible to calculate the offset between the frame
20291 pointer and the automatic variables until after register
20292 allocation has been completed. When this macro is defined, you
20293 must also indicate in your definition of `ELIMINABLE_REGS' how to
20294 eliminate `FRAME_POINTER_REGNUM' into either
20295 `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'.
20297 Do not define this macro if it would be the same as
20298 `FRAME_POINTER_REGNUM'.
20300 -- Macro: ARG_POINTER_REGNUM
20301 The register number of the arg pointer register, which is used to
20302 access the function's argument list. On some machines, this is
20303 the same as the frame pointer register. On some machines, the
20304 hardware determines which register this is. On other machines,
20305 you can choose any register you wish for this purpose. If this is
20306 not the same register as the frame pointer register, then you must
20307 mark it as a fixed register according to `FIXED_REGISTERS', or
20308 arrange to be able to eliminate it (*note Elimination::).
20310 -- Macro: RETURN_ADDRESS_POINTER_REGNUM
20311 The register number of the return address pointer register, which
20312 is used to access the current function's return address from the
20313 stack. On some machines, the return address is not at a fixed
20314 offset from the frame pointer or stack pointer or argument
20315 pointer. This register can be defined to point to the return
20316 address on the stack, and then be converted by `ELIMINABLE_REGS'
20317 into either the frame pointer or stack pointer.
20319 Do not define this macro unless there is no other way to get the
20320 return address from the stack.
20322 -- Macro: STATIC_CHAIN_REGNUM
20323 -- Macro: STATIC_CHAIN_INCOMING_REGNUM
20324 Register numbers used for passing a function's static chain
20325 pointer. If register windows are used, the register number as
20326 seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM',
20327 while the register number as seen by the calling function is
20328 `STATIC_CHAIN_REGNUM'. If these registers are the same,
20329 `STATIC_CHAIN_INCOMING_REGNUM' need not be defined.
20331 The static chain register need not be a fixed register.
20333 If the static chain is passed in memory, these macros should not be
20334 defined; instead, the next two macros should be defined.
20336 -- Macro: STATIC_CHAIN
20337 -- Macro: STATIC_CHAIN_INCOMING
20338 If the static chain is passed in memory, these macros provide rtx
20339 giving `mem' expressions that denote where they are stored.
20340 `STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as
20341 seen by the calling and called functions, respectively. Often the
20342 former will be at an offset from the stack pointer and the latter
20343 at an offset from the frame pointer.
20345 The variables `stack_pointer_rtx', `frame_pointer_rtx', and
20346 `arg_pointer_rtx' will have been initialized prior to the use of
20347 these macros and should be used to refer to those items.
20349 If the static chain is passed in a register, the two previous
20350 macros should be defined instead.
20352 -- Macro: DWARF_FRAME_REGISTERS
20353 This macro specifies the maximum number of hard registers that can
20354 be saved in a call frame. This is used to size data structures
20355 used in DWARF2 exception handling.
20357 Prior to GCC 3.0, this macro was needed in order to establish a
20358 stable exception handling ABI in the face of adding new hard
20359 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is
20360 insulated from changes in the number of hard registers.
20361 Nevertheless, this macro can still be used to reduce the runtime
20362 memory requirements of the exception handling routines, which can
20363 be substantial if the ISA contains a lot of registers that are not
20366 If this macro is not defined, it defaults to
20367 `FIRST_PSEUDO_REGISTER'.
20369 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS
20370 This macro is similar to `DWARF_FRAME_REGISTERS', but is provided
20371 for backward compatibility in pre GCC 3.0 compiled code.
20373 If this macro is not defined, it defaults to
20374 `DWARF_FRAME_REGISTERS'.
20376 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO)
20377 Define this macro if the target's representation for dwarf
20378 registers is different than the internal representation for unwind
20379 column. Given a dwarf register, this macro should return the
20380 internal unwind column number to use instead.
20382 See the PowerPC's SPE target for an example.
20384 -- Macro: DWARF_FRAME_REGNUM (REGNO)
20385 Define this macro if the target's representation for dwarf
20386 registers used in .eh_frame or .debug_frame is different from that
20387 used in other debug info sections. Given a GCC hard register
20388 number, this macro should return the .eh_frame register number.
20389 The default is `DBX_REGISTER_NUMBER (REGNO)'.
20392 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH)
20393 Define this macro to map register numbers held in the call frame
20394 info that GCC has collected using `DWARF_FRAME_REGNUM' to those
20395 that should be output in .debug_frame (`FOR_EH' is zero) and
20396 .eh_frame (`FOR_EH' is nonzero). The default is to return `REGNO'.
20400 File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling
20402 14.9.5 Eliminating Frame Pointer and Arg Pointer
20403 ------------------------------------------------
20405 This is about eliminating the frame pointer and arg pointer.
20407 -- Macro: FRAME_POINTER_REQUIRED
20408 A C expression which is nonzero if a function must have and use a
20409 frame pointer. This expression is evaluated in the reload pass.
20410 If its value is nonzero the function will have a frame pointer.
20412 The expression can in principle examine the current function and
20413 decide according to the facts, but on most machines the constant 0
20414 or the constant 1 suffices. Use 0 when the machine allows code to
20415 be generated with no frame pointer, and doing so saves some time
20416 or space. Use 1 when there is no possible advantage to avoiding a
20419 In certain cases, the compiler does not know how to produce valid
20420 code without a frame pointer. The compiler recognizes those cases
20421 and automatically gives the function a frame pointer regardless of
20422 what `FRAME_POINTER_REQUIRED' says. You don't need to worry about
20425 In a function that does not require a frame pointer, the frame
20426 pointer register can be allocated for ordinary usage, unless you
20427 mark it as a fixed register. See `FIXED_REGISTERS' for more
20430 -- Macro: INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)
20431 A C statement to store in the variable DEPTH-VAR the difference
20432 between the frame pointer and the stack pointer values immediately
20433 after the function prologue. The value would be computed from
20434 information such as the result of `get_frame_size ()' and the
20435 tables of registers `regs_ever_live' and `call_used_regs'.
20437 If `ELIMINABLE_REGS' is defined, this macro will be not be used and
20438 need not be defined. Otherwise, it must be defined even if
20439 `FRAME_POINTER_REQUIRED' is defined to always be true; in that
20440 case, you may set DEPTH-VAR to anything.
20442 -- Macro: ELIMINABLE_REGS
20443 If defined, this macro specifies a table of register pairs used to
20444 eliminate unneeded registers that point into the stack frame. If
20445 it is not defined, the only elimination attempted by the compiler
20446 is to replace references to the frame pointer with references to
20449 The definition of this macro is a list of structure
20450 initializations, each of which specifies an original and
20451 replacement register.
20453 On some machines, the position of the argument pointer is not
20454 known until the compilation is completed. In such a case, a
20455 separate hard register must be used for the argument pointer.
20456 This register can be eliminated by replacing it with either the
20457 frame pointer or the argument pointer, depending on whether or not
20458 the frame pointer has been eliminated.
20460 In this case, you might specify:
20461 #define ELIMINABLE_REGS \
20462 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
20463 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
20464 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
20466 Note that the elimination of the argument pointer with the stack
20467 pointer is specified first since that is the preferred elimination.
20469 -- Macro: CAN_ELIMINATE (FROM-REG, TO-REG)
20470 A C expression that returns nonzero if the compiler is allowed to
20471 try to replace register number FROM-REG with register number
20472 TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is
20473 defined, and will usually be the constant 1, since most of the
20474 cases preventing register elimination are things that the compiler
20475 already knows about.
20477 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)
20478 This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It
20479 specifies the initial difference between the specified pair of
20480 registers. This macro must be defined if `ELIMINABLE_REGS' is
20484 File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling
20486 14.9.6 Passing Function Arguments on the Stack
20487 ----------------------------------------------
20489 The macros in this section control how arguments are passed on the
20490 stack. See the following section for other macros that control passing
20491 certain arguments in registers.
20493 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (tree FNTYPE)
20494 This target hook returns `true' if an argument declared in a
20495 prototype as an integral type smaller than `int' should actually be
20496 passed as an `int'. In addition to avoiding errors in certain
20497 cases of mismatch, it also makes for better code on certain
20498 machines. The default is to not promote prototypes.
20500 -- Macro: PUSH_ARGS
20501 A C expression. If nonzero, push insns will be used to pass
20502 outgoing arguments. If the target machine does not have a push
20503 instruction, set it to zero. That directs GCC to use an alternate
20504 strategy: to allocate the entire argument block and then store the
20505 arguments into it. When `PUSH_ARGS' is nonzero, `PUSH_ROUNDING'
20506 must be defined too.
20508 -- Macro: PUSH_ARGS_REVERSED
20509 A C expression. If nonzero, function arguments will be evaluated
20510 from last to first, rather than from first to last. If this macro
20511 is not defined, it defaults to `PUSH_ARGS' on targets where the
20512 stack and args grow in opposite directions, and 0 otherwise.
20514 -- Macro: PUSH_ROUNDING (NPUSHED)
20515 A C expression that is the number of bytes actually pushed onto the
20516 stack when an instruction attempts to push NPUSHED bytes.
20518 On some machines, the definition
20520 #define PUSH_ROUNDING(BYTES) (BYTES)
20522 will suffice. But on other machines, instructions that appear to
20523 push one byte actually push two bytes in an attempt to maintain
20524 alignment. Then the definition should be
20526 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
20528 -- Macro: ACCUMULATE_OUTGOING_ARGS
20529 A C expression. If nonzero, the maximum amount of space required
20530 for outgoing arguments will be computed and placed into the
20531 variable `current_function_outgoing_args_size'. No space will be
20532 pushed onto the stack for each call; instead, the function
20533 prologue should increase the stack frame size by this amount.
20535 Setting both `PUSH_ARGS' and `ACCUMULATE_OUTGOING_ARGS' is not
20538 -- Macro: REG_PARM_STACK_SPACE (FNDECL)
20539 Define this macro if functions should assume that stack space has
20540 been allocated for arguments even when their values are passed in
20543 The value of this macro is the size, in bytes, of the area
20544 reserved for arguments passed in registers for the function
20545 represented by FNDECL, which can be zero if GCC is calling a
20548 This space can be allocated by the caller, or be a part of the
20549 machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says
20552 -- Macro: OUTGOING_REG_PARM_STACK_SPACE
20553 Define this if it is the responsibility of the caller to allocate
20554 the area reserved for arguments passed in registers.
20556 If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls
20557 whether the space for these arguments counts in the value of
20558 `current_function_outgoing_args_size'.
20560 -- Macro: STACK_PARMS_IN_REG_PARM_AREA
20561 Define this macro if `REG_PARM_STACK_SPACE' is defined, but the
20562 stack parameters don't skip the area specified by it.
20564 Normally, when a parameter is not passed in registers, it is
20565 placed on the stack beyond the `REG_PARM_STACK_SPACE' area.
20566 Defining this macro suppresses this behavior and causes the
20567 parameter to be passed on the stack in its natural location.
20569 -- Macro: RETURN_POPS_ARGS (FUNDECL, FUNTYPE, STACK-SIZE)
20570 A C expression that should indicate the number of bytes of its own
20571 arguments that a function pops on returning, or 0 if the function
20572 pops no arguments and the caller must therefore pop them all after
20573 the function returns.
20575 FUNDECL is a C variable whose value is a tree node that describes
20576 the function in question. Normally it is a node of type
20577 `FUNCTION_DECL' that describes the declaration of the function.
20578 From this you can obtain the `DECL_ATTRIBUTES' of the function.
20580 FUNTYPE is a C variable whose value is a tree node that describes
20581 the function in question. Normally it is a node of type
20582 `FUNCTION_TYPE' that describes the data type of the function.
20583 From this it is possible to obtain the data types of the value and
20584 arguments (if known).
20586 When a call to a library function is being considered, FUNDECL
20587 will contain an identifier node for the library function. Thus, if
20588 you need to distinguish among various library functions, you can
20589 do so by their names. Note that "library function" in this
20590 context means a function used to perform arithmetic, whose name is
20591 known specially in the compiler and was not mentioned in the C
20592 code being compiled.
20594 STACK-SIZE is the number of bytes of arguments passed on the
20595 stack. If a variable number of bytes is passed, it is zero, and
20596 argument popping will always be the responsibility of the calling
20599 On the VAX, all functions always pop their arguments, so the
20600 definition of this macro is STACK-SIZE. On the 68000, using the
20601 standard calling convention, no functions pop their arguments, so
20602 the value of the macro is always 0 in this case. But an
20603 alternative calling convention is available in which functions
20604 that take a fixed number of arguments pop them but other functions
20605 (such as `printf') pop nothing (the caller pops all). When this
20606 convention is in use, FUNTYPE is examined to determine whether a
20607 function takes a fixed number of arguments.
20609 -- Macro: CALL_POPS_ARGS (CUM)
20610 A C expression that should indicate the number of bytes a call
20611 sequence pops off the stack. It is added to the value of
20612 `RETURN_POPS_ARGS' when compiling a function call.
20614 CUM is the variable in which all arguments to the called function
20615 have been accumulated.
20617 On certain architectures, such as the SH5, a call trampoline is
20618 used that pops certain registers off the stack, depending on the
20619 arguments that have been passed to the function. Since this is a
20620 property of the call site, not of the called function,
20621 `RETURN_POPS_ARGS' is not appropriate.
20624 File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling
20626 14.9.7 Passing Arguments in Registers
20627 -------------------------------------
20629 This section describes the macros which let you control how various
20630 types of arguments are passed in registers or how they are arranged in
20633 -- Macro: FUNCTION_ARG (CUM, MODE, TYPE, NAMED)
20634 A C expression that controls whether a function argument is passed
20635 in a register, and which register.
20637 The arguments are CUM, which summarizes all the previous
20638 arguments; MODE, the machine mode of the argument; TYPE, the data
20639 type of the argument as a tree node or 0 if that is not known
20640 (which happens for C support library functions); and NAMED, which
20641 is 1 for an ordinary argument and 0 for nameless arguments that
20642 correspond to `...' in the called function's prototype. TYPE can
20643 be an incomplete type if a syntax error has previously occurred.
20645 The value of the expression is usually either a `reg' RTX for the
20646 hard register in which to pass the argument, or zero to pass the
20647 argument on the stack.
20649 For machines like the VAX and 68000, where normally all arguments
20650 are pushed, zero suffices as a definition.
20652 The value of the expression can also be a `parallel' RTX. This is
20653 used when an argument is passed in multiple locations. The mode
20654 of the `parallel' should be the mode of the entire argument. The
20655 `parallel' holds any number of `expr_list' pairs; each one
20656 describes where part of the argument is passed. In each
20657 `expr_list' the first operand must be a `reg' RTX for the hard
20658 register in which to pass this part of the argument, and the mode
20659 of the register RTX indicates how large this part of the argument
20660 is. The second operand of the `expr_list' is a `const_int' which
20661 gives the offset in bytes into the entire argument of where this
20662 part starts. As a special exception the first `expr_list' in the
20663 `parallel' RTX may have a first operand of zero. This indicates
20664 that the entire argument is also stored on the stack.
20666 The last time this macro is called, it is called with `MODE ==
20667 VOIDmode', and its result is passed to the `call' or `call_value'
20668 pattern as operands 2 and 3 respectively.
20670 The usual way to make the ISO library `stdarg.h' work on a machine
20671 where some arguments are usually passed in registers, is to cause
20672 nameless arguments to be passed on the stack instead. This is done
20673 by making `FUNCTION_ARG' return 0 whenever NAMED is 0.
20675 You may use the hook `targetm.calls.must_pass_in_stack' in the
20676 definition of this macro to determine if this argument is of a
20677 type that must be passed in the stack. If `REG_PARM_STACK_SPACE'
20678 is not defined and `FUNCTION_ARG' returns nonzero for such an
20679 argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is
20680 defined, the argument will be computed in the stack and then
20681 loaded into a register.
20683 -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (enum machine_mode
20685 This target hook should return `true' if we should not pass TYPE
20686 solely in registers. The file `expr.h' defines a definition that
20687 is usually appropriate, refer to `expr.h' for additional
20690 -- Macro: FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)
20691 Define this macro if the target machine has "register windows", so
20692 that the register in which a function sees an arguments is not
20693 necessarily the same as the one in which the caller passed the
20696 For such machines, `FUNCTION_ARG' computes the register in which
20697 the caller passes the value, and `FUNCTION_INCOMING_ARG' should be
20698 defined in a similar fashion to tell the function being called
20699 where the arguments will arrive.
20701 If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
20704 -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (CUMULATIVE_ARGS *CUM,
20705 enum machine_mode MODE, tree TYPE, bool NAMED)
20706 This target hook returns the number of bytes at the beginning of an
20707 argument that must be put in registers. The value must be zero for
20708 arguments that are passed entirely in registers or that are
20709 entirely pushed on the stack.
20711 On some machines, certain arguments must be passed partially in
20712 registers and partially in memory. On these machines, typically
20713 the first few words of arguments are passed in registers, and the
20714 rest on the stack. If a multi-word argument (a `double' or a
20715 structure) crosses that boundary, its first few words must be
20716 passed in registers and the rest must be pushed. This macro tells
20717 the compiler when this occurs, and how many bytes should go in
20720 `FUNCTION_ARG' for these arguments should return the first
20721 register to be used by the caller for this argument; likewise
20722 `FUNCTION_INCOMING_ARG', for the called function.
20724 -- Target Hook: bool TARGET_PASS_BY_REFERENCE (CUMULATIVE_ARGS *CUM,
20725 enum machine_mode MODE, tree TYPE, bool NAMED)
20726 This target hook should return `true' if an argument at the
20727 position indicated by CUM should be passed by reference. This
20728 predicate is queried after target independent reasons for being
20729 passed by reference, such as `TREE_ADDRESSABLE (type)'.
20731 If the hook returns true, a copy of that argument is made in
20732 memory and a pointer to the argument is passed instead of the
20733 argument itself. The pointer is passed in whatever way is
20734 appropriate for passing a pointer to that type.
20736 -- Target Hook: bool TARGET_CALLEE_COPIES (CUMULATIVE_ARGS *CUM, enum
20737 machine_mode MODE, tree TYPE, bool NAMED)
20738 The function argument described by the parameters to this hook is
20739 known to be passed by reference. The hook should return true if
20740 the function argument should be copied by the callee instead of
20741 copied by the caller.
20743 For any argument for which the hook returns true, if it can be
20744 determined that the argument is not modified, then a copy need not
20747 The default version of this hook always returns false.
20749 -- Macro: CUMULATIVE_ARGS
20750 A C type for declaring a variable that is used as the first
20751 argument of `FUNCTION_ARG' and other related values. For some
20752 target machines, the type `int' suffices and can hold the number
20753 of bytes of argument so far.
20755 There is no need to record in `CUMULATIVE_ARGS' anything about the
20756 arguments that have been passed on the stack. The compiler has
20757 other variables to keep track of that. For target machines on
20758 which all arguments are passed on the stack, there is no need to
20759 store anything in `CUMULATIVE_ARGS'; however, the data structure
20760 must exist and should not be empty, so use `int'.
20762 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL,
20764 A C statement (sans semicolon) for initializing the variable CUM
20765 for the state at the beginning of the argument list. The variable
20766 has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node
20767 for the data type of the function which will receive the args, or
20768 0 if the args are to a compiler support library function. For
20769 direct calls that are not libcalls, FNDECL contain the declaration
20770 node of the function. FNDECL is also set when
20771 `INIT_CUMULATIVE_ARGS' is used to find arguments for the function
20772 being compiled. N_NAMED_ARGS is set to the number of named
20773 arguments, including a structure return address if it is passed as
20774 a parameter, when making a call. When processing incoming
20775 arguments, N_NAMED_ARGS is set to -1.
20777 When processing a call to a compiler support library function,
20778 LIBNAME identifies which one. It is a `symbol_ref' rtx which
20779 contains the name of the function, as a string. LIBNAME is 0 when
20780 an ordinary C function call is being processed. Thus, each time
20781 this macro is called, either LIBNAME or FNTYPE is nonzero, but
20782 never both of them at once.
20784 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME)
20785 Like `INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls,
20786 it gets a `MODE' argument instead of FNTYPE, that would be `NULL'.
20787 INDIRECT would always be zero, too. If this macro is not
20788 defined, `INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is
20791 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)
20792 Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of
20793 finding the arguments for the function being compiled. If this
20794 macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead.
20796 The value passed for LIBNAME is always 0, since library routines
20797 with special calling conventions are never compiled with GCC. The
20798 argument LIBNAME exists for symmetry with `INIT_CUMULATIVE_ARGS'.
20800 -- Macro: FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)
20801 A C statement (sans semicolon) to update the summarizer variable
20802 CUM to advance past an argument in the argument list. The values
20803 MODE, TYPE and NAMED describe that argument. Once this is done,
20804 the variable CUM is suitable for analyzing the _following_
20805 argument with `FUNCTION_ARG', etc.
20807 This macro need not do anything if the argument in question was
20808 passed on the stack. The compiler knows how to track the amount
20809 of stack space used for arguments without any special help.
20811 -- Macro: FUNCTION_ARG_PADDING (MODE, TYPE)
20812 If defined, a C expression which determines whether, and in which
20813 direction, to pad out an argument with extra space. The value
20814 should be of type `enum direction': either `upward' to pad above
20815 the argument, `downward' to pad below, or `none' to inhibit
20818 The _amount_ of padding is always just enough to reach the next
20819 multiple of `FUNCTION_ARG_BOUNDARY'; this macro does not control
20822 This macro has a default definition which is right for most
20823 systems. For little-endian machines, the default is to pad
20824 upward. For big-endian machines, the default is to pad downward
20825 for an argument of constant size shorter than an `int', and upward
20828 -- Macro: PAD_VARARGS_DOWN
20829 If defined, a C expression which determines whether the default
20830 implementation of va_arg will attempt to pad down before reading
20831 the next argument, if that argument is smaller than its aligned
20832 space as controlled by `PARM_BOUNDARY'. If this macro is not
20833 defined, all such arguments are padded down if `BYTES_BIG_ENDIAN'
20836 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST)
20837 Specify padding for the last element of a block move between
20838 registers and memory. FIRST is nonzero if this is the only
20839 element. Defining this macro allows better control of register
20840 function parameters on big-endian machines, without using
20841 `PARALLEL' rtl. In particular, `MUST_PASS_IN_STACK' need not test
20842 padding and mode of types in registers, as there is no longer a
20843 "wrong" part of a register; For example, a three byte aggregate
20844 may be passed in the high part of a register if so required.
20846 -- Macro: FUNCTION_ARG_BOUNDARY (MODE, TYPE)
20847 If defined, a C expression that gives the alignment boundary, in
20848 bits, of an argument with the specified mode and type. If it is
20849 not defined, `PARM_BOUNDARY' is used for all arguments.
20851 -- Macro: FUNCTION_ARG_REGNO_P (REGNO)
20852 A C expression that is nonzero if REGNO is the number of a hard
20853 register in which function arguments are sometimes passed. This
20854 does _not_ include implicit arguments such as the static chain and
20855 the structure-value address. On many machines, no registers can be
20856 used for this purpose since all function arguments are pushed on
20859 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (tree TYPE)
20860 This hook should return true if parameter of type TYPE are passed
20861 as two scalar parameters. By default, GCC will attempt to pack
20862 complex arguments into the target's word size. Some ABIs require
20863 complex arguments to be split and treated as their individual
20864 components. For example, on AIX64, complex floats should be
20865 passed in a pair of floating point registers, even though a
20866 complex float would fit in one 64-bit floating point register.
20868 The default value of this hook is `NULL', which is treated as
20871 -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void)
20872 This hook returns a type node for `va_list' for the target. The
20873 default version of the hook returns `void*'.
20875 -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree
20876 TYPE, tree *PRE_P, tree *POST_P)
20877 This hook performs target-specific gimplification of
20878 `VA_ARG_EXPR'. The first two parameters correspond to the
20879 arguments to `va_arg'; the latter two are as in
20880 `gimplify.c:gimplify_expr'.
20882 -- Target Hook: bool TARGET_VALID_POINTER_MODE (enum machine_mode MODE)
20883 Define this to return nonzero if the port can handle pointers with
20884 machine mode MODE. The default version of this hook returns true
20885 for both `ptr_mode' and `Pmode'.
20887 -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (enum machine_mode
20889 Define this to return nonzero if the port is prepared to handle
20890 insns involving scalar mode MODE. For a scalar mode to be
20891 considered supported, all the basic arithmetic and comparisons
20894 The default version of this hook returns true for any mode
20895 required to handle the basic C types (as defined by the port).
20896 Included here are the double-word arithmetic supported by the code
20899 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (enum machine_mode
20901 Define this to return nonzero if the port is prepared to handle
20902 insns involving vector mode MODE. At the very least, it must have
20903 move patterns for this mode.
20906 File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling
20908 14.9.8 How Scalar Function Values Are Returned
20909 ----------------------------------------------
20911 This section discusses the macros that control returning scalars as
20912 values--values that can fit in registers.
20914 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC)
20915 A C expression to create an RTX representing the place where a
20916 function returns a value of data type VALTYPE. VALTYPE is a tree
20917 node representing a data type. Write `TYPE_MODE (VALTYPE)' to get
20918 the machine mode used to represent that type. On many machines,
20919 only the mode is relevant. (Actually, on most machines, scalar
20920 values are returned in the same place regardless of mode).
20922 The value of the expression is usually a `reg' RTX for the hard
20923 register where the return value is stored. The value can also be a
20924 `parallel' RTX, if the return value is in multiple places. See
20925 `FUNCTION_ARG' for an explanation of the `parallel' form.
20927 If `TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply
20928 the same promotion rules specified in `PROMOTE_MODE' if VALTYPE is
20931 If the precise function being called is known, FUNC is a tree node
20932 (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
20933 makes it possible to use a different value-returning convention
20934 for specific functions when all their calls are known.
20936 `FUNCTION_VALUE' is not used for return vales with aggregate data
20937 types, because these are returned in another way. See
20938 `TARGET_STRUCT_VALUE_RTX' and related macros, below.
20940 -- Macro: FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)
20941 Define this macro if the target machine has "register windows" so
20942 that the register in which a function returns its value is not the
20943 same as the one in which the caller sees the value.
20945 For such machines, `FUNCTION_VALUE' computes the register in which
20946 the caller will see the value. `FUNCTION_OUTGOING_VALUE' should be
20947 defined in a similar fashion to tell the function where to put the
20950 If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE'
20951 serves both purposes.
20953 `FUNCTION_OUTGOING_VALUE' is not used for return vales with
20954 aggregate data types, because these are returned in another way.
20955 See `TARGET_STRUCT_VALUE_RTX' and related macros, below.
20957 -- Macro: LIBCALL_VALUE (MODE)
20958 A C expression to create an RTX representing the place where a
20959 library function returns a value of mode MODE. If the precise
20960 function being called is known, FUNC is a tree node
20961 (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
20962 makes it possible to use a different value-returning convention
20963 for specific functions when all their calls are known.
20965 Note that "library function" in this context means a compiler
20966 support routine, used to perform arithmetic, whose name is known
20967 specially by the compiler and was not mentioned in the C code being
20970 The definition of `LIBRARY_VALUE' need not be concerned aggregate
20971 data types, because none of the library functions returns such
20974 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO)
20975 A C expression that is nonzero if REGNO is the number of a hard
20976 register in which the values of called function may come back.
20978 A register whose use for returning values is limited to serving as
20979 the second of a pair (for a value of type `double', say) need not
20980 be recognized by this macro. So for most machines, this definition
20983 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
20985 If the machine has register windows, so that the caller and the
20986 called function use different registers for the return value, this
20987 macro should recognize only the caller's register numbers.
20989 -- Macro: APPLY_RESULT_SIZE
20990 Define this macro if `untyped_call' and `untyped_return' need more
20991 space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and
20992 restoring an arbitrary return value.
20994 -- Target Hook: bool TARGET_RETURN_IN_MSB (tree TYPE)
20995 This hook should return true if values of type TYPE are returned
20996 at the most significant end of a register (in other words, if they
20997 are padded at the least significant end). You can assume that TYPE
20998 is returned in a register; the caller is required to check this.
21000 Note that the register provided by `FUNCTION_VALUE' must be able
21001 to hold the complete return value. For example, if a 1-, 2- or
21002 3-byte structure is returned at the most significant end of a
21003 4-byte register, `FUNCTION_VALUE' should provide an `SImode' rtx.
21006 File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling
21008 14.9.9 How Large Values Are Returned
21009 ------------------------------------
21011 When a function value's mode is `BLKmode' (and in some other cases),
21012 the value is not returned according to `FUNCTION_VALUE' (*note Scalar
21013 Return::). Instead, the caller passes the address of a block of memory
21014 in which the value should be stored. This address is called the
21015 "structure value address".
21017 This section describes how to control returning structure values in
21020 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (tree TYPE, tree FNTYPE)
21021 This target hook should return a nonzero value to say to return the
21022 function value in memory, just as large structures are always
21023 returned. Here TYPE will be the data type of the value, and FNTYPE
21024 will be the type of the function doing the returning, or `NULL' for
21027 Note that values of mode `BLKmode' must be explicitly handled by
21028 this function. Also, the option `-fpcc-struct-return' takes
21029 effect regardless of this macro. On most systems, it is possible
21030 to leave the hook undefined; this causes a default definition to
21031 be used, whose value is the constant 1 for `BLKmode' values, and 0
21034 Do not use this hook to indicate that structures and unions should
21035 always be returned in memory. You should instead use
21036 `DEFAULT_PCC_STRUCT_RETURN' to indicate this.
21038 -- Macro: DEFAULT_PCC_STRUCT_RETURN
21039 Define this macro to be 1 if all structure and union return values
21040 must be in memory. Since this results in slower code, this should
21041 be defined only if needed for compatibility with other compilers
21042 or with an ABI. If you define this macro to be 0, then the
21043 conventions used for structure and union return values are decided
21044 by the `TARGET_RETURN_IN_MEMORY' target hook.
21046 If not defined, this defaults to the value 1.
21048 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING)
21049 This target hook should return the location of the structure value
21050 address (normally a `mem' or `reg'), or 0 if the address is passed
21051 as an "invisible" first argument. Note that FNDECL may be `NULL',
21052 for libcalls. You do not need to define this target hook if the
21053 address is always passed as an "invisible" first argument.
21055 On some architectures the place where the structure value address
21056 is found by the called function is not the same place that the
21057 caller put it. This can be due to register windows, or it could
21058 be because the function prologue moves it to a different place.
21059 INCOMING is `true' when the location is needed in the context of
21060 the called function, and `false' in the context of the caller.
21062 If INCOMING is `true' and the address is to be found on the stack,
21063 return a `mem' which refers to the frame pointer.
21065 -- Macro: PCC_STATIC_STRUCT_RETURN
21066 Define this macro if the usual system convention on the target
21067 machine for returning structures and unions is for the called
21068 function to return the address of a static variable containing the
21071 Do not define this if the usual system convention is for the
21072 caller to pass an address to the subroutine.
21074 This macro has effect in `-fpcc-struct-return' mode, but it does
21075 nothing when you use `-freg-struct-return' mode.
21078 File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling
21080 14.9.10 Caller-Saves Register Allocation
21081 ----------------------------------------
21083 If you enable it, GCC can save registers around function calls. This
21084 makes it possible to use call-clobbered registers to hold variables that
21085 must live across calls.
21087 -- Macro: CALLER_SAVE_PROFITABLE (REFS, CALLS)
21088 A C expression to determine whether it is worthwhile to consider
21089 placing a pseudo-register in a call-clobbered hard register and
21090 saving and restoring it around each function call. The expression
21091 should be 1 when this is worth doing, and 0 otherwise.
21093 If you don't define this macro, a default is used which is good on
21094 most machines: `4 * CALLS < REFS'.
21096 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS)
21097 A C expression specifying which mode is required for saving NREGS
21098 of a pseudo-register in call-clobbered hard register REGNO. If
21099 REGNO is unsuitable for caller save, `VOIDmode' should be
21100 returned. For most machines this macro need not be defined since
21101 GCC will select the smallest suitable mode.
21104 File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling
21106 14.9.11 Function Entry and Exit
21107 -------------------------------
21109 This section describes the macros that output function entry
21110 ("prologue") and exit ("epilogue") code.
21112 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE,
21113 HOST_WIDE_INT SIZE)
21114 If defined, a function that outputs the assembler code for entry
21115 to a function. The prologue is responsible for setting up the
21116 stack frame, initializing the frame pointer register, saving
21117 registers that must be saved, and allocating SIZE additional bytes
21118 of storage for the local variables. SIZE is an integer. FILE is
21119 a stdio stream to which the assembler code should be output.
21121 The label for the beginning of the function need not be output by
21122 this macro. That has already been done when the macro is run.
21124 To determine which registers to save, the macro can refer to the
21125 array `regs_ever_live': element R is nonzero if hard register R is
21126 used anywhere within the function. This implies the function
21127 prologue should save register R, provided it is not one of the
21128 call-used registers. (`TARGET_ASM_FUNCTION_EPILOGUE' must
21129 likewise use `regs_ever_live'.)
21131 On machines that have "register windows", the function entry code
21132 does not save on the stack the registers that are in the windows,
21133 even if they are supposed to be preserved by function calls;
21134 instead it takes appropriate steps to "push" the register stack,
21135 if any non-call-used registers are used in the function.
21137 On machines where functions may or may not have frame-pointers, the
21138 function entry code must vary accordingly; it must set up the frame
21139 pointer if one is wanted, and not otherwise. To determine whether
21140 a frame pointer is in wanted, the macro can refer to the variable
21141 `frame_pointer_needed'. The variable's value will be 1 at run
21142 time in a function that needs a frame pointer. *Note
21145 The function entry code is responsible for allocating any stack
21146 space required for the function. This stack space consists of the
21147 regions listed below. In most cases, these regions are allocated
21148 in the order listed, with the last listed region closest to the
21149 top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is
21150 defined, and the highest address if it is not defined). You can
21151 use a different order for a machine if doing so is more convenient
21152 or required for compatibility reasons. Except in cases where
21153 required by standard or by a debugger, there is no reason why the
21154 stack layout used by GCC need agree with that used by other
21155 compilers for a machine.
21157 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE)
21158 If defined, a function that outputs assembler code at the end of a
21159 prologue. This should be used when the function prologue is being
21160 emitted as RTL, and you have some extra assembler that needs to be
21161 emitted. *Note prologue instruction pattern::.
21163 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE)
21164 If defined, a function that outputs assembler code at the start of
21165 an epilogue. This should be used when the function epilogue is
21166 being emitted as RTL, and you have some extra assembler that needs
21167 to be emitted. *Note epilogue instruction pattern::.
21169 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE,
21170 HOST_WIDE_INT SIZE)
21171 If defined, a function that outputs the assembler code for exit
21172 from a function. The epilogue is responsible for restoring the
21173 saved registers and stack pointer to their values when the
21174 function was called, and returning control to the caller. This
21175 macro takes the same arguments as the macro
21176 `TARGET_ASM_FUNCTION_PROLOGUE', and the registers to restore are
21177 determined from `regs_ever_live' and `CALL_USED_REGISTERS' in the
21180 On some machines, there is a single instruction that does all the
21181 work of returning from the function. On these machines, give that
21182 instruction the name `return' and do not define the macro
21183 `TARGET_ASM_FUNCTION_EPILOGUE' at all.
21185 Do not define a pattern named `return' if you want the
21186 `TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target
21187 switches to control whether return instructions or epilogues are
21188 used, define a `return' pattern with a validity condition that
21189 tests the target switches appropriately. If the `return'
21190 pattern's validity condition is false, epilogues will be used.
21192 On machines where functions may or may not have frame-pointers, the
21193 function exit code must vary accordingly. Sometimes the code for
21194 these two cases is completely different. To determine whether a
21195 frame pointer is wanted, the macro can refer to the variable
21196 `frame_pointer_needed'. The variable's value will be 1 when
21197 compiling a function that needs a frame pointer.
21199 Normally, `TARGET_ASM_FUNCTION_PROLOGUE' and
21200 `TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially.
21201 The C variable `current_function_is_leaf' is nonzero for such a
21202 function. *Note Leaf Functions::.
21204 On some machines, some functions pop their arguments on exit while
21205 others leave that for the caller to do. For example, the 68020
21206 when given `-mrtd' pops arguments in functions that take a fixed
21207 number of arguments.
21209 Your definition of the macro `RETURN_POPS_ARGS' decides which
21210 functions pop their own arguments. `TARGET_ASM_FUNCTION_EPILOGUE'
21211 needs to know what was decided. The variable that is called
21212 `current_function_pops_args' is the number of bytes of its
21213 arguments that a function should pop. *Note Scalar Return::.
21215 * A region of `current_function_pretend_args_size' bytes of
21216 uninitialized space just underneath the first argument arriving on
21217 the stack. (This may not be at the very start of the allocated
21218 stack region if the calling sequence has pushed anything else
21219 since pushing the stack arguments. But usually, on such machines,
21220 nothing else has been pushed yet, because the function prologue
21221 itself does all the pushing.) This region is used on machines
21222 where an argument may be passed partly in registers and partly in
21223 memory, and, in some cases to support the features in `<stdarg.h>'.
21225 * An area of memory used to save certain registers used by the
21226 function. The size of this area, which may also include space for
21227 such things as the return address and pointers to previous stack
21228 frames, is machine-specific and usually depends on which registers
21229 have been used in the function. Machines with register windows
21230 often do not require a save area.
21232 * A region of at least SIZE bytes, possibly rounded up to an
21233 allocation boundary, to contain the local variables of the
21234 function. On some machines, this region and the save area may
21235 occur in the opposite order, with the save area closer to the top
21238 * Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a region of
21239 `current_function_outgoing_args_size' bytes to be used for outgoing
21240 argument lists of the function. *Note Stack Arguments::.
21242 -- Macro: EXIT_IGNORE_STACK
21243 Define this macro as a C expression that is nonzero if the return
21244 instruction or the function epilogue ignores the value of the stack
21245 pointer; in other words, if it is safe to delete an instruction to
21246 adjust the stack pointer before a return from the function. The
21249 Note that this macro's value is relevant only for functions for
21250 which frame pointers are maintained. It is never safe to delete a
21251 final stack adjustment in a function that has no frame pointer,
21252 and the compiler knows this regardless of `EXIT_IGNORE_STACK'.
21254 -- Macro: EPILOGUE_USES (REGNO)
21255 Define this macro as a C expression that is nonzero for registers
21256 that are used by the epilogue or the `return' pattern. The stack
21257 and frame pointer registers are already be assumed to be used as
21260 -- Macro: EH_USES (REGNO)
21261 Define this macro as a C expression that is nonzero for registers
21262 that are used by the exception handling mechanism, and so should
21263 be considered live on entry to an exception edge.
21265 -- Macro: DELAY_SLOTS_FOR_EPILOGUE
21266 Define this macro if the function epilogue contains delay slots to
21267 which instructions from the rest of the function can be "moved".
21268 The definition should be a C expression whose value is an integer
21269 representing the number of delay slots there.
21271 -- Macro: ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)
21272 A C expression that returns 1 if INSN can be placed in delay slot
21273 number N of the epilogue.
21275 The argument N is an integer which identifies the delay slot now
21276 being considered (since different slots may have different rules of
21277 eligibility). It is never negative and is always less than the
21278 number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE'
21279 returns). If you reject a particular insn for a given delay slot,
21280 in principle, it may be reconsidered for a subsequent delay slot.
21281 Also, other insns may (at least in principle) be considered for
21282 the so far unfilled delay slot.
21284 The insns accepted to fill the epilogue delay slots are put in an
21285 RTL list made with `insn_list' objects, stored in the variable
21286 `current_function_epilogue_delay_list'. The insn for the first
21287 delay slot comes first in the list. Your definition of the macro
21288 `TARGET_ASM_FUNCTION_EPILOGUE' should fill the delay slots by
21289 outputting the insns in this list, usually by calling
21292 You need not define this macro if you did not define
21293 `DELAY_SLOTS_FOR_EPILOGUE'.
21295 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree
21296 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT
21297 VCALL_OFFSET, tree FUNCTION)
21298 A function that outputs the assembler code for a thunk function,
21299 used to implement C++ virtual function calls with multiple
21300 inheritance. The thunk acts as a wrapper around a virtual
21301 function, adjusting the implicit object parameter before handing
21302 control off to the real function.
21304 First, emit code to add the integer DELTA to the location that
21305 contains the incoming first argument. Assume that this argument
21306 contains a pointer, and is the one used to pass the `this' pointer
21307 in C++. This is the incoming argument _before_ the function
21308 prologue, e.g. `%o0' on a sparc. The addition must preserve the
21309 values of all other incoming arguments.
21311 Then, if VCALL_OFFSET is nonzero, an additional adjustment should
21312 be made after adding `delta'. In particular, if P is the adjusted
21313 pointer, the following adjustment should be made:
21315 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)]
21317 After the additions, emit code to jump to FUNCTION, which is a
21318 `FUNCTION_DECL'. This is a direct pure jump, not a call, and does
21319 not touch the return address. Hence returning from FUNCTION will
21320 return to whoever called the current `thunk'.
21322 The effect must be as if FUNCTION had been called directly with
21323 the adjusted first argument. This macro is responsible for
21324 emitting all of the code for a thunk function;
21325 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE'
21328 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already
21329 been extracted from it.) It might possibly be useful on some
21330 targets, but probably not.
21332 If you do not define this macro, the target-independent code in
21333 the C++ front end will generate a less efficient heavyweight thunk
21334 that calls FUNCTION instead of jumping to it. The generic
21335 approach does not support varargs.
21337 -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (tree
21338 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT
21339 VCALL_OFFSET, tree FUNCTION)
21340 A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would
21341 be able to output the assembler code for the thunk function
21342 specified by the arguments it is passed, and false otherwise. In
21343 the latter case, the generic approach will be used by the C++
21344 front end, with the limitations previously exposed.
21347 File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling
21349 14.9.12 Generating Code for Profiling
21350 -------------------------------------
21352 These macros will help you generate code for profiling.
21354 -- Macro: FUNCTION_PROFILER (FILE, LABELNO)
21355 A C statement or compound statement to output to FILE some
21356 assembler code to call the profiling subroutine `mcount'.
21358 The details of how `mcount' expects to be called are determined by
21359 your operating system environment, not by GCC. To figure them out,
21360 compile a small program for profiling using the system's installed
21361 C compiler and look at the assembler code that results.
21363 Older implementations of `mcount' expect the address of a counter
21364 variable to be loaded into some register. The name of this
21365 variable is `LP' followed by the number LABELNO, so you would
21366 generate the name using `LP%d' in a `fprintf'.
21368 -- Macro: PROFILE_HOOK
21369 A C statement or compound statement to output to FILE some assembly
21370 code to call the profiling subroutine `mcount' even the target does
21371 not support profiling.
21373 -- Macro: NO_PROFILE_COUNTERS
21374 Define this macro to be an expression with a nonzero value if the
21375 `mcount' subroutine on your system does not need a counter variable
21376 allocated for each function. This is true for almost all modern
21377 implementations. If you define this macro, you must not use the
21378 LABELNO argument to `FUNCTION_PROFILER'.
21380 -- Macro: PROFILE_BEFORE_PROLOGUE
21381 Define this macro if the code for function profiling should come
21382 before the function prologue. Normally, the profiling code comes
21386 File: gccint.info, Node: Tail Calls, Next: Stack Smashing Protection, Prev: Profiling, Up: Stack and Calling
21388 14.9.13 Permitting tail calls
21389 -----------------------------
21391 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree
21393 True if it is ok to do sibling call optimization for the specified
21394 call expression EXP. DECL will be the called function, or `NULL'
21395 if this is an indirect call.
21397 It is not uncommon for limitations of calling conventions to
21398 prevent tail calls to functions outside the current unit of
21399 translation, or during PIC compilation. The hook is used to
21400 enforce these restrictions, as the `sibcall' md pattern can not
21401 fail, or fall over to a "normal" call. The criteria for
21402 successful sibling call optimization may vary greatly between
21403 different architectures.
21406 File: gccint.info, Node: Stack Smashing Protection, Prev: Tail Calls, Up: Stack and Calling
21408 14.9.14 Stack smashing protection
21409 ---------------------------------
21411 -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void)
21412 This hook returns a `DECL' node for the external variable to use
21413 for the stack protection guard. This variable is initialized by
21414 the runtime to some random value and is used to initialize the
21415 guard value that is placed at the top of the local stack frame.
21416 The type of this variable must be `ptr_type_node'.
21418 The default version of this hook creates a variable called
21419 `__stack_chk_guard', which is normally defined in `libgcc2.c'.
21421 -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void)
21422 This hook returns a tree expression that alerts the runtime that
21423 the stack protect guard variable has been modified. This
21424 expression should involve a call to a `noreturn' function.
21426 The default version of this hook invokes a function called
21427 `__stack_chk_fail', taking no arguments. This function is
21428 normally defined in `libgcc2.c'.
21431 File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros
21433 14.10 Implementing the Varargs Macros
21434 =====================================
21436 GCC comes with an implementation of `<varargs.h>' and `<stdarg.h>' that
21437 work without change on machines that pass arguments on the stack.
21438 Other machines require their own implementations of varargs, and the
21439 two machine independent header files must have conditionals to include
21442 ISO `<stdarg.h>' differs from traditional `<varargs.h>' mainly in the
21443 calling convention for `va_start'. The traditional implementation
21444 takes just one argument, which is the variable in which to store the
21445 argument pointer. The ISO implementation of `va_start' takes an
21446 additional second argument. The user is supposed to write the last
21447 named argument of the function here.
21449 However, `va_start' should not use this argument. The way to find the
21450 end of the named arguments is with the built-in functions described
21453 -- Macro: __builtin_saveregs ()
21454 Use this built-in function to save the argument registers in
21455 memory so that the varargs mechanism can access them. Both ISO
21456 and traditional versions of `va_start' must use
21457 `__builtin_saveregs', unless you use
21458 `TARGET_SETUP_INCOMING_VARARGS' (see below) instead.
21460 On some machines, `__builtin_saveregs' is open-coded under the
21461 control of the target hook `TARGET_EXPAND_BUILTIN_SAVEREGS'. On
21462 other machines, it calls a routine written in assembler language,
21463 found in `libgcc2.c'.
21465 Code generated for the call to `__builtin_saveregs' appears at the
21466 beginning of the function, as opposed to where the call to
21467 `__builtin_saveregs' is written, regardless of what the code is.
21468 This is because the registers must be saved before the function
21469 starts to use them for its own purposes.
21471 -- Macro: __builtin_args_info (CATEGORY)
21472 Use this built-in function to find the first anonymous arguments in
21475 In general, a machine may have several categories of registers
21476 used for arguments, each for a particular category of data types.
21477 (For example, on some machines, floating-point registers are used
21478 for floating-point arguments while other arguments are passed in
21479 the general registers.) To make non-varargs functions use the
21480 proper calling convention, you have defined the `CUMULATIVE_ARGS'
21481 data type to record how many registers in each category have been
21484 `__builtin_args_info' accesses the same data structure of type
21485 `CUMULATIVE_ARGS' after the ordinary argument layout is finished
21486 with it, with CATEGORY specifying which word to access. Thus, the
21487 value indicates the first unused register in a given category.
21489 Normally, you would use `__builtin_args_info' in the implementation
21490 of `va_start', accessing each category just once and storing the
21491 value in the `va_list' object. This is because `va_list' will
21492 have to update the values, and there is no way to alter the values
21493 accessed by `__builtin_args_info'.
21495 -- Macro: __builtin_next_arg (LASTARG)
21496 This is the equivalent of `__builtin_args_info', for stack
21497 arguments. It returns the address of the first anonymous stack
21498 argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns
21499 the address of the location above the first anonymous stack
21500 argument. Use it in `va_start' to initialize the pointer for
21501 fetching arguments from the stack. Also use it in `va_start' to
21502 verify that the second parameter LASTARG is the last named argument
21503 of the current function.
21505 -- Macro: __builtin_classify_type (OBJECT)
21506 Since each machine has its own conventions for which data types are
21507 passed in which kind of register, your implementation of `va_arg'
21508 has to embody these conventions. The easiest way to categorize the
21509 specified data type is to use `__builtin_classify_type' together
21510 with `sizeof' and `__alignof__'.
21512 `__builtin_classify_type' ignores the value of OBJECT, considering
21513 only its data type. It returns an integer describing what kind of
21514 type that is--integer, floating, pointer, structure, and so on.
21516 The file `typeclass.h' defines an enumeration that you can use to
21517 interpret the values of `__builtin_classify_type'.
21519 These machine description macros help implement varargs:
21521 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void)
21522 If defined, this hook produces the machine-specific code for a
21523 call to `__builtin_saveregs'. This code will be moved to the very
21524 beginning of the function, before any parameter access are made.
21525 The return value of this function should be an RTX that contains
21526 the value to use as the return of `__builtin_saveregs'.
21528 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (CUMULATIVE_ARGS
21529 *ARGS_SO_FAR, enum machine_mode MODE, tree TYPE, int
21530 *PRETEND_ARGS_SIZE, int SECOND_TIME)
21531 This target hook offers an alternative to using
21532 `__builtin_saveregs' and defining the hook
21533 `TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous
21534 register arguments into the stack so that all the arguments appear
21535 to have been passed consecutively on the stack. Once this is
21536 done, you can use the standard implementation of varargs that
21537 works for machines that pass all their arguments on the stack.
21539 The argument ARGS_SO_FAR points to the `CUMULATIVE_ARGS' data
21540 structure, containing the values that are obtained after
21541 processing the named arguments. The arguments MODE and TYPE
21542 describe the last named argument--its machine mode and its data
21543 type as a tree node.
21545 The target hook should do two things: first, push onto the stack
21546 all the argument registers _not_ used for the named arguments, and
21547 second, store the size of the data thus pushed into the
21548 `int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value
21549 that you store here will serve as additional offset for setting up
21552 Because you must generate code to push the anonymous arguments at
21553 compile time without knowing their data types,
21554 `TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that
21555 have just a single category of argument register and use it
21556 uniformly for all data types.
21558 If the argument SECOND_TIME is nonzero, it means that the
21559 arguments of the function are being analyzed for the second time.
21560 This happens for an inline function, which is not actually
21561 compiled until the end of the source file. The hook
21562 `TARGET_SETUP_INCOMING_VARARGS' should not generate any
21563 instructions in this case.
21565 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (CUMULATIVE_ARGS
21567 Define this hook to return `true' if the location where a function
21568 argument is passed depends on whether or not it is a named
21571 This hook controls how the NAMED argument to `FUNCTION_ARG' is set
21572 for varargs and stdarg functions. If this hook returns `true',
21573 the NAMED argument is always true for named arguments, and false
21574 for unnamed arguments. If it returns `false', but
21575 `TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns `true', then all
21576 arguments are treated as named. Otherwise, all named arguments
21577 except the last are treated as named.
21579 You need not define this hook if it always returns zero.
21581 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED
21582 If you need to conditionally change ABIs so that one works with
21583 `TARGET_SETUP_INCOMING_VARARGS', but the other works like neither
21584 `TARGET_SETUP_INCOMING_VARARGS' nor
21585 `TARGET_STRICT_ARGUMENT_NAMING' was defined, then define this hook
21586 to return `true' if `TARGET_SETUP_INCOMING_VARARGS' is used,
21587 `false' otherwise. Otherwise, you should not define this hook.
21590 File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros
21592 14.11 Trampolines for Nested Functions
21593 ======================================
21595 A "trampoline" is a small piece of code that is created at run time
21596 when the address of a nested function is taken. It normally resides on
21597 the stack, in the stack frame of the containing function. These macros
21598 tell GCC how to generate code to allocate and initialize a trampoline.
21600 The instructions in the trampoline must do two things: load a constant
21601 address into the static chain register, and jump to the real address of
21602 the nested function. On CISC machines such as the m68k, this requires
21603 two instructions, a move immediate and a jump. Then the two addresses
21604 exist in the trampoline as word-long immediate operands. On RISC
21605 machines, it is often necessary to load each address into a register in
21606 two parts. Then pieces of each address form separate immediate
21609 The code generated to initialize the trampoline must store the variable
21610 parts--the static chain value and the function address--into the
21611 immediate operands of the instructions. On a CISC machine, this is
21612 simply a matter of copying each address to a memory reference at the
21613 proper offset from the start of the trampoline. On a RISC machine, it
21614 may be necessary to take out pieces of the address and store them
21617 -- Macro: TRAMPOLINE_TEMPLATE (FILE)
21618 A C statement to output, on the stream FILE, assembler code for a
21619 block of data that contains the constant parts of a trampoline.
21620 This code should not include a label--the label is taken care of
21623 If you do not define this macro, it means no template is needed
21624 for the target. Do not define this macro on systems where the
21625 block move code to copy the trampoline into place would be larger
21626 than the code to generate it on the spot.
21628 -- Macro: TRAMPOLINE_SECTION
21629 The name of a subroutine to switch to the section in which the
21630 trampoline template is to be placed (*note Sections::). The
21631 default is a value of `readonly_data_section', which places the
21632 trampoline in the section containing read-only data.
21634 -- Macro: TRAMPOLINE_SIZE
21635 A C expression for the size in bytes of the trampoline, as an
21638 -- Macro: TRAMPOLINE_ALIGNMENT
21639 Alignment required for trampolines, in bits.
21641 If you don't define this macro, the value of `BIGGEST_ALIGNMENT'
21642 is used for aligning trampolines.
21644 -- Macro: INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)
21645 A C statement to initialize the variable parts of a trampoline.
21646 ADDR is an RTX for the address of the trampoline; FNADDR is an RTX
21647 for the address of the nested function; STATIC_CHAIN is an RTX for
21648 the static chain value that should be passed to the function when
21651 -- Macro: TRAMPOLINE_ADJUST_ADDRESS (ADDR)
21652 A C statement that should perform any machine-specific adjustment
21653 in the address of the trampoline. Its argument contains the
21654 address that was passed to `INITIALIZE_TRAMPOLINE'. In case the
21655 address to be used for a function call should be different from
21656 the address in which the template was stored, the different
21657 address should be assigned to ADDR. If this macro is not defined,
21658 ADDR will be used for function calls.
21660 If this macro is not defined, by default the trampoline is
21661 allocated as a stack slot. This default is right for most
21662 machines. The exceptions are machines where it is impossible to
21663 execute instructions in the stack area. On such machines, you may
21664 have to implement a separate stack, using this macro in
21665 conjunction with `TARGET_ASM_FUNCTION_PROLOGUE' and
21666 `TARGET_ASM_FUNCTION_EPILOGUE'.
21668 FP points to a data structure, a `struct function', which
21669 describes the compilation status of the immediate containing
21670 function of the function which the trampoline is for. The stack
21671 slot for the trampoline is in the stack frame of this containing
21672 function. Other allocation strategies probably must do something
21673 analogous with this information.
21675 Implementing trampolines is difficult on many machines because they
21676 have separate instruction and data caches. Writing into a stack
21677 location fails to clear the memory in the instruction cache, so when
21678 the program jumps to that location, it executes the old contents.
21680 Here are two possible solutions. One is to clear the relevant parts of
21681 the instruction cache whenever a trampoline is set up. The other is to
21682 make all trampolines identical, by having them jump to a standard
21683 subroutine. The former technique makes trampoline execution faster; the
21684 latter makes initialization faster.
21686 To clear the instruction cache when a trampoline is initialized, define
21687 the following macro.
21689 -- Macro: CLEAR_INSN_CACHE (BEG, END)
21690 If defined, expands to a C expression clearing the _instruction
21691 cache_ in the specified interval. The definition of this macro
21692 would typically be a series of `asm' statements. Both BEG and END
21693 are both pointer expressions.
21695 The operating system may also require the stack to be made executable
21696 before calling the trampoline. To implement this requirement, define
21697 the following macro.
21699 -- Macro: ENABLE_EXECUTE_STACK
21700 Define this macro if certain operations must be performed before
21701 executing code located on the stack. The macro should expand to a
21702 series of C file-scope constructs (e.g. functions) and provide a
21703 unique entry point named `__enable_execute_stack'. The target is
21704 responsible for emitting calls to the entry point in the code, for
21705 example from the `INITIALIZE_TRAMPOLINE' macro.
21707 To use a standard subroutine, define the following macro. In addition,
21708 you must make sure that the instructions in a trampoline fill an entire
21709 cache line with identical instructions, or else ensure that the
21710 beginning of the trampoline code is always aligned at the same point in
21711 its cache line. Look in `m68k.h' as a guide.
21713 -- Macro: TRANSFER_FROM_TRAMPOLINE
21714 Define this macro if trampolines need a special subroutine to do
21715 their work. The macro should expand to a series of `asm'
21716 statements which will be compiled with GCC. They go in a library
21717 function named `__transfer_from_trampoline'.
21719 If you need to avoid executing the ordinary prologue code of a
21720 compiled C function when you jump to the subroutine, you can do so
21721 by placing a special label of your own in the assembler code. Use
21722 one `asm' statement to generate an assembler label, and another to
21723 make the label global. Then trampolines can use that label to
21724 jump directly to your special assembler code.
21727 File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros
21729 14.12 Implicit Calls to Library Routines
21730 ========================================
21732 Here is an explanation of implicit calls to library routines.
21734 -- Macro: DECLARE_LIBRARY_RENAMES
21735 This macro, if defined, should expand to a piece of C code that
21736 will get expanded when compiling functions for libgcc.a. It can
21737 be used to provide alternate names for GCC's internal library
21738 functions if there are ABI-mandated names that the compiler should
21741 -- Target Hook: void TARGET_INIT_LIBFUNCS (void)
21742 This hook should declare additional library routines or rename
21743 existing ones, using the functions `set_optab_libfunc' and
21744 `init_one_libfunc' defined in `optabs.c'. `init_optabs' calls
21745 this macro after initializing all the normal library routines.
21747 The default is to do nothing. Most ports don't need to define
21750 -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON)
21751 This macro should return `true' if the library routine that
21752 implements the floating point comparison operator COMPARISON in
21753 mode MODE will return a boolean, and FALSE if it will return a
21756 GCC's own floating point libraries return tristates from the
21757 comparison operators, so the default returns false always. Most
21758 ports don't need to define this macro.
21760 -- Macro: TARGET_LIB_INT_CMP_BIASED
21761 This macro should evaluate to `true' if the integer comparison
21762 functions (like `__cmpdi2') return 0 to indicate that the first
21763 operand is smaller than the second, 1 to indicate that they are
21764 equal, and 2 to indicate that the first operand is greater than
21765 the second. If this macro evaluates to `false' the comparison
21766 functions return -1, 0, and 1 instead of 0, 1, and 2. If the
21767 target uses the routines in `libgcc.a', you do not need to define
21770 -- Macro: US_SOFTWARE_GOFAST
21771 Define this macro if your system C library uses the US Software
21772 GOFAST library to provide floating point emulation.
21774 In addition to defining this macro, your architecture must set
21775 `TARGET_INIT_LIBFUNCS' to `gofast_maybe_init_libfuncs', or else
21776 call that function from its version of that hook. It is defined
21777 in `config/gofast.h', which must be included by your
21778 architecture's `CPU.c' file. See `sparc/sparc.c' for an example.
21780 If this macro is defined, the
21781 `TARGET_FLOAT_LIB_COMPARE_RETURNS_BOOL' target hook must return
21782 false for `SFmode' and `DFmode' comparisons.
21784 -- Macro: TARGET_EDOM
21785 The value of `EDOM' on the target machine, as a C integer constant
21786 expression. If you don't define this macro, GCC does not attempt
21787 to deposit the value of `EDOM' into `errno' directly. Look in
21788 `/usr/include/errno.h' to find the value of `EDOM' on your system.
21790 If you do not define `TARGET_EDOM', then compiled code reports
21791 domain errors by calling the library function and letting it
21792 report the error. If mathematical functions on your system use
21793 `matherr' when there is an error, then you should leave
21794 `TARGET_EDOM' undefined so that `matherr' is used normally.
21796 -- Macro: GEN_ERRNO_RTX
21797 Define this macro as a C expression to create an rtl expression
21798 that refers to the global "variable" `errno'. (On certain systems,
21799 `errno' may not actually be a variable.) If you don't define this
21800 macro, a reasonable default is used.
21802 -- Macro: TARGET_C99_FUNCTIONS
21803 When this macro is nonzero, GCC will implicitly optimize `sin'
21804 calls into `sinf' and similarly for other functions defined by C99
21805 standard. The default is nonzero that should be proper value for
21806 most modern systems, however number of existing systems lacks
21807 support for these functions in the runtime so they needs this
21808 macro to be redefined to 0.
21810 -- Macro: NEXT_OBJC_RUNTIME
21811 Define this macro to generate code for Objective-C message sending
21812 using the calling convention of the NeXT system. This calling
21813 convention involves passing the object, the selector and the
21814 method arguments all at once to the method-lookup library function.
21816 The default calling convention passes just the object and the
21817 selector to the lookup function, which returns a pointer to the
21821 File: gccint.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros
21823 14.13 Addressing Modes
21824 ======================
21826 This is about addressing modes.
21828 -- Macro: HAVE_PRE_INCREMENT
21829 -- Macro: HAVE_PRE_DECREMENT
21830 -- Macro: HAVE_POST_INCREMENT
21831 -- Macro: HAVE_POST_DECREMENT
21832 A C expression that is nonzero if the machine supports
21833 pre-increment, pre-decrement, post-increment, or post-decrement
21834 addressing respectively.
21836 -- Macro: HAVE_PRE_MODIFY_DISP
21837 -- Macro: HAVE_POST_MODIFY_DISP
21838 A C expression that is nonzero if the machine supports pre- or
21839 post-address side-effect generation involving constants other than
21840 the size of the memory operand.
21842 -- Macro: HAVE_PRE_MODIFY_REG
21843 -- Macro: HAVE_POST_MODIFY_REG
21844 A C expression that is nonzero if the machine supports pre- or
21845 post-address side-effect generation involving a register
21848 -- Macro: CONSTANT_ADDRESS_P (X)
21849 A C expression that is 1 if the RTX X is a constant which is a
21850 valid address. On most machines, this can be defined as
21851 `CONSTANT_P (X)', but a few machines are more restrictive in which
21852 constant addresses are supported.
21854 -- Macro: CONSTANT_P (X)
21855 `CONSTANT_P', which is defined by target-independent code, accepts
21856 integer-values expressions whose values are not explicitly known,
21857 such as `symbol_ref', `label_ref', and `high' expressions and
21858 `const' arithmetic expressions, in addition to `const_int' and
21859 `const_double' expressions.
21861 -- Macro: MAX_REGS_PER_ADDRESS
21862 A number, the maximum number of registers that can appear in a
21863 valid memory address. Note that it is up to you to specify a
21864 value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS'
21867 -- Macro: GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)
21868 A C compound statement with a conditional `goto LABEL;' executed
21869 if X (an RTX) is a legitimate memory address on the target machine
21870 for a memory operand of mode MODE.
21872 It usually pays to define several simpler macros to serve as
21873 subroutines for this one. Otherwise it may be too complicated to
21876 This macro must exist in two variants: a strict variant and a
21877 non-strict one. The strict variant is used in the reload pass. It
21878 must be defined so that any pseudo-register that has not been
21879 allocated a hard register is considered a memory reference. In
21880 contexts where some kind of register is required, a pseudo-register
21881 with no hard register must be rejected.
21883 The non-strict variant is used in other passes. It must be
21884 defined to accept all pseudo-registers in every context where some
21885 kind of register is required.
21887 Compiler source files that want to use the strict variant of this
21888 macro define the macro `REG_OK_STRICT'. You should use an `#ifdef
21889 REG_OK_STRICT' conditional to define the strict variant in that
21890 case and the non-strict variant otherwise.
21892 Subroutines to check for acceptable registers for various purposes
21893 (one for base registers, one for index registers, and so on) are
21894 typically among the subroutines used to define
21895 `GO_IF_LEGITIMATE_ADDRESS'. Then only these subroutine macros
21896 need have two variants; the higher levels of macros may be the
21897 same whether strict or not.
21899 Normally, constant addresses which are the sum of a `symbol_ref'
21900 and an integer are stored inside a `const' RTX to mark them as
21901 constant. Therefore, there is no need to recognize such sums
21902 specifically as legitimate addresses. Normally you would simply
21903 recognize any `const' as legitimate.
21905 Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant
21906 sums that are not marked with `const'. It assumes that a naked
21907 `plus' indicates indexing. If so, then you _must_ reject such
21908 naked constant sums as illegitimate addresses, so that none of
21909 them will be given to `PRINT_OPERAND_ADDRESS'.
21911 On some machines, whether a symbolic address is legitimate depends
21912 on the section that the address refers to. On these machines,
21913 define the target hook `TARGET_ENCODE_SECTION_INFO' to store the
21914 information into the `symbol_ref', and then check for it here.
21915 When you see a `const', you will have to look inside it to find the
21916 `symbol_ref' in order to determine the section. *Note Assembler
21919 -- Macro: REG_OK_FOR_BASE_P (X)
21920 A C expression that is nonzero if X (assumed to be a `reg' RTX) is
21921 valid for use as a base register. For hard registers, it should
21922 always accept those which the hardware permits and reject the
21923 others. Whether the macro accepts or rejects pseudo registers
21924 must be controlled by `REG_OK_STRICT' as described above. This
21925 usually requires two variant definitions, of which `REG_OK_STRICT'
21926 controls the one actually used.
21928 -- Macro: REG_MODE_OK_FOR_BASE_P (X, MODE)
21929 A C expression that is just like `REG_OK_FOR_BASE_P', except that
21930 that expression may examine the mode of the memory reference in
21931 MODE. You should define this macro if the mode of the memory
21932 reference affects whether a register may be used as a base
21933 register. If you define this macro, the compiler will use it
21934 instead of `REG_OK_FOR_BASE_P'.
21936 -- Macro: REG_MODE_OK_FOR_REG_BASE_P (X, MODE)
21937 A C expression which is nonzero if X (assumed to be a `reg' RTX)
21938 is suitable for use as a base register in base plus index operand
21939 addresses, accessing memory in mode MODE. It may be either a
21940 suitable hard register or a pseudo register that has been
21941 allocated such a hard register. You should define this macro if
21942 base plus index addresses have different requirements than other
21943 base register uses.
21945 -- Macro: REG_OK_FOR_INDEX_P (X)
21946 A C expression that is nonzero if X (assumed to be a `reg' RTX) is
21947 valid for use as an index register.
21949 The difference between an index register and a base register is
21950 that the index register may be scaled. If an address involves the
21951 sum of two registers, neither one of them scaled, then either one
21952 may be labeled the "base" and the other the "index"; but whichever
21953 labeling is used must fit the machine's constraints of which
21954 registers may serve in each capacity. The compiler will try both
21955 labelings, looking for one that is valid, and will reload one or
21956 both registers only if neither labeling works.
21958 -- Macro: FIND_BASE_TERM (X)
21959 A C expression to determine the base term of address X. This
21960 macro is used in only one place: `find_base_term' in alias.c.
21962 It is always safe for this macro to not be defined. It exists so
21963 that alias analysis can understand machine-dependent addresses.
21965 The typical use of this macro is to handle addresses containing a
21966 label_ref or symbol_ref within an UNSPEC.
21968 -- Macro: LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)
21969 A C compound statement that attempts to replace X with a valid
21970 memory address for an operand of mode MODE. WIN will be a C
21971 statement label elsewhere in the code; the macro definition may use
21973 GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
21975 to avoid further processing if the address has become legitimate.
21977 X will always be the result of a call to `break_out_memory_refs',
21978 and OLDX will be the operand that was given to that function to
21981 The code generated by this macro should not alter the substructure
21982 of X. If it transforms X into a more legitimate form, it should
21983 assign X (which will always be a C variable) a new value.
21985 It is not necessary for this macro to come up with a legitimate
21986 address. The compiler has standard ways of doing so in all cases.
21987 In fact, it is safe to omit this macro. But often a
21988 machine-dependent strategy can generate better code.
21990 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS,
21992 A C compound statement that attempts to replace X, which is an
21993 address that needs reloading, with a valid memory address for an
21994 operand of mode MODE. WIN will be a C statement label elsewhere
21995 in the code. It is not necessary to define this macro, but it
21996 might be useful for performance reasons.
21998 For example, on the i386, it is sometimes possible to use a single
21999 reload register instead of two by reloading a sum of two pseudo
22000 registers into a register. On the other hand, for number of RISC
22001 processors offsets are limited so that often an intermediate
22002 address needs to be generated in order to address a stack slot.
22003 By defining `LEGITIMIZE_RELOAD_ADDRESS' appropriately, the
22004 intermediate addresses generated for adjacent some stack slots can
22005 be made identical, and thus be shared.
22007 _Note_: This macro should be used with caution. It is necessary
22008 to know something of how reload works in order to effectively use
22009 this, and it is quite easy to produce macros that build in too
22010 much knowledge of reload internals.
22012 _Note_: This macro must be able to reload an address created by a
22013 previous invocation of this macro. If it fails to handle such
22014 addresses then the compiler may generate incorrect code or abort.
22016 The macro definition should use `push_reload' to indicate parts
22017 that need reloading; OPNUM, TYPE and IND_LEVELS are usually
22018 suitable to be passed unaltered to `push_reload'.
22020 The code generated by this macro must not alter the substructure of
22021 X. If it transforms X into a more legitimate form, it should
22022 assign X (which will always be a C variable) a new value. This
22023 also applies to parts that you change indirectly by calling
22026 The macro definition may use `strict_memory_address_p' to test if
22027 the address has become legitimate.
22029 If you want to change only a part of X, one standard way of doing
22030 this is to use `copy_rtx'. Note, however, that is unshares only a
22031 single level of rtl. Thus, if the part to be changed is not at the
22032 top level, you'll need to replace first the top level. It is not
22033 necessary for this macro to come up with a legitimate address;
22034 but often a machine-dependent strategy can generate better code.
22036 -- Macro: GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)
22037 A C statement or compound statement with a conditional `goto
22038 LABEL;' executed if memory address X (an RTX) can have different
22039 meanings depending on the machine mode of the memory reference it
22040 is used for or if the address is valid for some modes but not
22043 Autoincrement and autodecrement addresses typically have
22044 mode-dependent effects because the amount of the increment or
22045 decrement is the size of the operand being addressed. Some
22046 machines have other mode-dependent addresses. Many RISC machines
22047 have no mode-dependent addresses.
22049 You may assume that ADDR is a valid address for the machine.
22051 -- Macro: LEGITIMATE_CONSTANT_P (X)
22052 A C expression that is nonzero if X is a legitimate constant for
22053 an immediate operand on the target machine. You can assume that X
22054 satisfies `CONSTANT_P', so you need not check this. In fact, `1'
22055 is a suitable definition for this macro on machines where anything
22056 `CONSTANT_P' is valid.
22058 -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X)
22059 This hook is used to undo the possibly obfuscating effects of the
22060 `LEGITIMIZE_ADDRESS' and `LEGITIMIZE_RELOAD_ADDRESS' target
22061 macros. Some backend implementations of these macros wrap symbol
22062 references inside an `UNSPEC' rtx to represent PIC or similar
22063 addressing modes. This target hook allows GCC's optimizers to
22064 understand the semantics of these opaque `UNSPEC's by converting
22065 them back into their original form.
22067 -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (rtx X)
22068 This hook should return true if X is of a form that cannot (or
22069 should not) be spilled to the constant pool. The default version
22070 of this hook returns false.
22072 The primary reason to define this hook is to prevent reload from
22073 deciding that a non-legitimate constant would be better reloaded
22074 from the constant pool instead of spilling and reloading a register
22075 holding the constant. This restriction is often true of addresses
22076 of TLS symbols for various targets.
22078 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void)
22079 This hook should return the DECL of a function F that given an
22080 address ADDR as an argument returns a mask M that can be used to
22081 extract from two vectors the relevant data that resides in ADDR in
22082 case ADDR is not properly aligned.
22084 The autovectrizer, when vectorizing a load operation from an
22085 address ADDR that may be unaligned, will generate two vector loads
22086 from the two aligned addresses around ADDR. It then generates a
22087 `REALIGN_LOAD' operation to extract the relevant data from the two
22088 loaded vectors. The first two arguments to `REALIGN_LOAD', V1 and
22089 V2, are the two vectors, each of size VS, and the third argument,
22090 OFF, defines how the data will be extracted from these two
22091 vectors: if OFF is 0, then the returned vector is V2; otherwise,
22092 the returned vector is composed from the last VS-OFF elements of
22093 V1 concatenated to the first OFF elements of V2.
22095 If this hook is defined, the autovectorizer will generate a call
22096 to F (using the DECL tree that this hook returns) and will use the
22097 return value of F as the argument OFF to `REALIGN_LOAD'.
22098 Therefore, the mask M returned by F should comply with the
22099 semantics expected by `REALIGN_LOAD' described above. If this
22100 hook is not defined, then ADDR will be used as the argument OFF to
22101 `REALIGN_LOAD', in which case the low log2(VS)-1 bits of ADDR will
22105 File: gccint.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Target Macros
22107 14.14 Condition Code Status
22108 ===========================
22110 This describes the condition code status.
22112 The file `conditions.h' defines a variable `cc_status' to describe how
22113 the condition code was computed (in case the interpretation of the
22114 condition code depends on the instruction that it was set by). This
22115 variable contains the RTL expressions on which the condition code is
22116 currently based, and several standard flags.
22118 Sometimes additional machine-specific flags must be defined in the
22119 machine description header file. It can also add additional
22120 machine-specific information by defining `CC_STATUS_MDEP'.
22122 -- Macro: CC_STATUS_MDEP
22123 C code for a data type which is used for declaring the `mdep'
22124 component of `cc_status'. It defaults to `int'.
22126 This macro is not used on machines that do not use `cc0'.
22128 -- Macro: CC_STATUS_MDEP_INIT
22129 A C expression to initialize the `mdep' field to "empty". The
22130 default definition does nothing, since most machines don't use the
22131 field anyway. If you want to use the field, you should probably
22132 define this macro to initialize it.
22134 This macro is not used on machines that do not use `cc0'.
22136 -- Macro: NOTICE_UPDATE_CC (EXP, INSN)
22137 A C compound statement to set the components of `cc_status'
22138 appropriately for an insn INSN whose body is EXP. It is this
22139 macro's responsibility to recognize insns that set the condition
22140 code as a byproduct of other activity as well as those that
22141 explicitly set `(cc0)'.
22143 This macro is not used on machines that do not use `cc0'.
22145 If there are insns that do not set the condition code but do alter
22146 other machine registers, this macro must check to see whether they
22147 invalidate the expressions that the condition code is recorded as
22148 reflecting. For example, on the 68000, insns that store in address
22149 registers do not set the condition code, which means that usually
22150 `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns.
22151 But suppose that the previous insn set the condition code based
22152 on location `a4@(102)' and the current insn stores a new value in
22153 `a4'. Although the condition code is not changed by this, it will
22154 no longer be true that it reflects the contents of `a4@(102)'.
22155 Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case
22156 to say that nothing is known about the condition code value.
22158 The definition of `NOTICE_UPDATE_CC' must be prepared to deal with
22159 the results of peephole optimization: insns whose patterns are
22160 `parallel' RTXs containing various `reg', `mem' or constants which
22161 are just the operands. The RTL structure of these insns is not
22162 sufficient to indicate what the insns actually do. What
22163 `NOTICE_UPDATE_CC' should do when it sees one is just to run
22166 A possible definition of `NOTICE_UPDATE_CC' is to call a function
22167 that looks at an attribute (*note Insn Attributes::) named, for
22168 example, `cc'. This avoids having detailed information about
22169 patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'.
22171 -- Macro: SELECT_CC_MODE (OP, X, Y)
22172 Returns a mode from class `MODE_CC' to be used when comparison
22173 operation code OP is applied to rtx X and Y. For example, on the
22174 SPARC, `SELECT_CC_MODE' is defined as (see *note Jump Patterns::
22175 for a description of the reason for this definition)
22177 #define SELECT_CC_MODE(OP,X,Y) \
22178 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \
22179 ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \
22180 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \
22181 || GET_CODE (X) == NEG) \
22182 ? CC_NOOVmode : CCmode))
22184 You should define this macro if and only if you define extra CC
22185 modes in `MACHINE-modes.def'.
22187 -- Macro: CANONICALIZE_COMPARISON (CODE, OP0, OP1)
22188 On some machines not all possible comparisons are defined, but you
22189 can convert an invalid comparison into a valid one. For example,
22190 the Alpha does not have a `GT' comparison, but you can use an `LT'
22191 comparison instead and swap the order of the operands.
22193 On such machines, define this macro to be a C statement to do any
22194 required conversions. CODE is the initial comparison code and OP0
22195 and OP1 are the left and right operands of the comparison,
22196 respectively. You should modify CODE, OP0, and OP1 as required.
22198 GCC will not assume that the comparison resulting from this macro
22199 is valid but will see if the resulting insn matches a pattern in
22202 You need not define this macro if it would never change the
22203 comparison code or operands.
22205 -- Macro: REVERSIBLE_CC_MODE (MODE)
22206 A C expression whose value is one if it is always safe to reverse a
22207 comparison whose mode is MODE. If `SELECT_CC_MODE' can ever
22208 return MODE for a floating-point inequality comparison, then
22209 `REVERSIBLE_CC_MODE (MODE)' must be zero.
22211 You need not define this macro if it would always returns zero or
22212 if the floating-point format is anything other than
22213 `IEEE_FLOAT_FORMAT'. For example, here is the definition used on
22214 the SPARC, where floating-point inequality comparisons are always
22217 #define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode)
22219 -- Macro: REVERSE_CONDITION (CODE, MODE)
22220 A C expression whose value is reversed condition code of the CODE
22221 for comparison done in CC_MODE MODE. The macro is used only in
22222 case `REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in
22223 case machine has some non-standard way how to reverse certain
22224 conditionals. For instance in case all floating point conditions
22225 are non-trapping, compiler may freely convert unordered compares
22226 to ordered one. Then definition may look like:
22228 #define REVERSE_CONDITION(CODE, MODE) \
22229 ((MODE) != CCFPmode ? reverse_condition (CODE) \
22230 : reverse_condition_maybe_unordered (CODE))
22232 -- Macro: REVERSE_CONDEXEC_PREDICATES_P (OP1, OP2)
22233 A C expression that returns true if the conditional execution
22234 predicate OP1, a comparison operation, is the inverse of OP2 and
22235 vice versa. Define this to return 0 if the target has conditional
22236 execution predicates that cannot be reversed safely. There is no
22237 need to validate that the arguments of op1 and op2 are the same,
22238 this is done separately. If no expansion is specified, this macro
22239 is defined as follows:
22241 #define REVERSE_CONDEXEC_PREDICATES_P (x, y) \
22242 (GET_CODE ((x)) == reversed_comparison_code ((y), NULL))
22244 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int *,
22246 On targets which do not use `(cc0)', and which use a hard register
22247 rather than a pseudo-register to hold condition codes, the regular
22248 CSE passes are often not able to identify cases in which the hard
22249 register is set to a common value. Use this hook to enable a
22250 small pass which optimizes such cases. This hook should return
22251 true to enable this pass, and it should set the integers to which
22252 its arguments point to the hard register numbers used for
22253 condition codes. When there is only one such register, as is true
22254 on most systems, the integer pointed to by the second argument
22255 should be set to `INVALID_REGNUM'.
22257 The default version of this hook returns false.
22259 -- Target Hook: enum machine_mode TARGET_CC_MODES_COMPATIBLE (enum
22260 machine_mode, enum machine_mode)
22261 On targets which use multiple condition code modes in class
22262 `MODE_CC', it is sometimes the case that a comparison can be
22263 validly done in more than one mode. On such a system, define this
22264 target hook to take two mode arguments and to return a mode in
22265 which both comparisons may be validly done. If there is no such
22266 mode, return `VOIDmode'.
22268 The default version of this hook checks whether the modes are the
22269 same. If they are, it returns that mode. If they are different,
22270 it returns `VOIDmode'.
22273 File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros
22275 14.15 Describing Relative Costs of Operations
22276 =============================================
22278 These macros let you describe the relative speed of various operations
22279 on the target machine.
22281 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO)
22282 A C expression for the cost of moving data of mode MODE from a
22283 register in class FROM to one in class TO. The classes are
22284 expressed using the enumeration values such as `GENERAL_REGS'. A
22285 value of 2 is the default; other values are interpreted relative to
22288 It is not required that the cost always equal 2 when FROM is the
22289 same as TO; on some machines it is expensive to move between
22290 registers if they are not general registers.
22292 If reload sees an insn consisting of a single `set' between two
22293 hard registers, and if `REGISTER_MOVE_COST' applied to their
22294 classes returns a value of 2, reload does not check to ensure that
22295 the constraints of the insn are met. Setting a cost of other than
22296 2 will allow reload to verify that the constraints are met. You
22297 should do this if the `movM' pattern's constraints do not allow
22300 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN)
22301 A C expression for the cost of moving data of mode MODE between a
22302 register of class CLASS and memory; IN is zero if the value is to
22303 be written to memory, nonzero if it is to be read in. This cost
22304 is relative to those in `REGISTER_MOVE_COST'. If moving between
22305 registers and memory is more expensive than between two registers,
22306 you should define this macro to express the relative cost.
22308 If you do not define this macro, GCC uses a default cost of 4 plus
22309 the cost of copying via a secondary reload register, if one is
22310 needed. If your machine requires a secondary reload register to
22311 copy between memory and a register of CLASS but the reload
22312 mechanism is more complex than copying via an intermediate, define
22313 this macro to reflect the actual cost of the move.
22315 GCC defines the function `memory_move_secondary_cost' if secondary
22316 reloads are needed. It computes the costs due to copying via a
22317 secondary register. If your machine copies from memory using a
22318 secondary register in the conventional way but the default base
22319 value of 4 is not correct for your machine, define this macro to
22320 add some other value to the result of that function. The
22321 arguments to that function are the same as to this macro.
22323 -- Macro: BRANCH_COST
22324 A C expression for the cost of a branch instruction. A value of 1
22325 is the default; other values are interpreted relative to that.
22327 Here are additional macros which do not specify precise relative costs,
22328 but only that certain actions are more expensive than GCC would
22331 -- Macro: SLOW_BYTE_ACCESS
22332 Define this macro as a C expression which is nonzero if accessing
22333 less than a word of memory (i.e. a `char' or a `short') is no
22334 faster than accessing a word of memory, i.e., if such access
22335 require more than one instruction or if there is no difference in
22336 cost between byte and (aligned) word loads.
22338 When this macro is not defined, the compiler will access a field by
22339 finding the smallest containing object; when it is defined, a
22340 fullword load will be used if alignment permits. Unless bytes
22341 accesses are faster than word accesses, using word accesses is
22342 preferable since it may eliminate subsequent memory access if
22343 subsequent accesses occur to other fields in the same word of the
22344 structure, but to different bytes.
22346 -- Macro: SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT)
22347 Define this macro to be the value 1 if memory accesses described
22348 by the MODE and ALIGNMENT parameters have a cost many times greater
22349 than aligned accesses, for example if they are emulated in a trap
22352 When this macro is nonzero, the compiler will act as if
22353 `STRICT_ALIGNMENT' were nonzero when generating code for block
22354 moves. This can cause significantly more instructions to be
22355 produced. Therefore, do not set this macro nonzero if unaligned
22356 accesses only add a cycle or two to the time for a memory access.
22358 If the value of this macro is always zero, it need not be defined.
22359 If this macro is defined, it should produce a nonzero value when
22360 `STRICT_ALIGNMENT' is nonzero.
22362 -- Macro: MOVE_RATIO
22363 The threshold of number of scalar memory-to-memory move insns,
22364 _below_ which a sequence of insns should be generated instead of a
22365 string move insn or a library call. Increasing the value will
22366 always make code faster, but eventually incurs high cost in
22367 increased code size.
22369 Note that on machines where the corresponding move insn is a
22370 `define_expand' that emits a sequence of insns, this macro counts
22371 the number of such sequences.
22373 If you don't define this, a reasonable default is used.
22375 -- Macro: MOVE_BY_PIECES_P (SIZE, ALIGNMENT)
22376 A C expression used to determine whether `move_by_pieces' will be
22377 used to copy a chunk of memory, or whether some other block move
22378 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns'
22379 returns less than `MOVE_RATIO'.
22381 -- Macro: MOVE_MAX_PIECES
22382 A C expression used by `move_by_pieces' to determine the largest
22383 unit a load or store used to copy memory is. Defaults to
22386 -- Macro: CLEAR_RATIO
22387 The threshold of number of scalar move insns, _below_ which a
22388 sequence of insns should be generated to clear memory instead of a
22389 string clear insn or a library call. Increasing the value will
22390 always make code faster, but eventually incurs high cost in
22391 increased code size.
22393 If you don't define this, a reasonable default is used.
22395 -- Macro: CLEAR_BY_PIECES_P (SIZE, ALIGNMENT)
22396 A C expression used to determine whether `clear_by_pieces' will be
22397 used to clear a chunk of memory, or whether some other block clear
22398 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns'
22399 returns less than `CLEAR_RATIO'.
22401 -- Macro: STORE_BY_PIECES_P (SIZE, ALIGNMENT)
22402 A C expression used to determine whether `store_by_pieces' will be
22403 used to set a chunk of memory to a constant value, or whether some
22404 other mechanism will be used. Used by `__builtin_memset' when
22405 storing values other than constant zero and by `__builtin_strcpy'
22406 when when called with a constant source string. Defaults to 1 if
22407 `move_by_pieces_ninsns' returns less than `MOVE_RATIO'.
22409 -- Macro: USE_LOAD_POST_INCREMENT (MODE)
22410 A C expression used to determine whether a load postincrement is a
22411 good thing to use for a given mode. Defaults to the value of
22412 `HAVE_POST_INCREMENT'.
22414 -- Macro: USE_LOAD_POST_DECREMENT (MODE)
22415 A C expression used to determine whether a load postdecrement is a
22416 good thing to use for a given mode. Defaults to the value of
22417 `HAVE_POST_DECREMENT'.
22419 -- Macro: USE_LOAD_PRE_INCREMENT (MODE)
22420 A C expression used to determine whether a load preincrement is a
22421 good thing to use for a given mode. Defaults to the value of
22422 `HAVE_PRE_INCREMENT'.
22424 -- Macro: USE_LOAD_PRE_DECREMENT (MODE)
22425 A C expression used to determine whether a load predecrement is a
22426 good thing to use for a given mode. Defaults to the value of
22427 `HAVE_PRE_DECREMENT'.
22429 -- Macro: USE_STORE_POST_INCREMENT (MODE)
22430 A C expression used to determine whether a store postincrement is
22431 a good thing to use for a given mode. Defaults to the value of
22432 `HAVE_POST_INCREMENT'.
22434 -- Macro: USE_STORE_POST_DECREMENT (MODE)
22435 A C expression used to determine whether a store postdecrement is
22436 a good thing to use for a given mode. Defaults to the value of
22437 `HAVE_POST_DECREMENT'.
22439 -- Macro: USE_STORE_PRE_INCREMENT (MODE)
22440 This macro is used to determine whether a store preincrement is a
22441 good thing to use for a given mode. Defaults to the value of
22442 `HAVE_PRE_INCREMENT'.
22444 -- Macro: USE_STORE_PRE_DECREMENT (MODE)
22445 This macro is used to determine whether a store predecrement is a
22446 good thing to use for a given mode. Defaults to the value of
22447 `HAVE_PRE_DECREMENT'.
22449 -- Macro: NO_FUNCTION_CSE
22450 Define this macro if it is as good or better to call a constant
22451 function address than to call an address kept in a register.
22453 -- Macro: RANGE_TEST_NON_SHORT_CIRCUIT
22454 Define this macro if a non-short-circuit operation produced by
22455 `fold_range_test ()' is optimal. This macro defaults to true if
22456 `BRANCH_COST' is greater than or equal to the value 2.
22458 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, int CODE, int
22459 OUTER_CODE, int *TOTAL)
22460 This target hook describes the relative costs of RTL expressions.
22462 The cost may depend on the precise form of the expression, which is
22463 available for examination in X, and the rtx code of the expression
22464 in which it is contained, found in OUTER_CODE. CODE is the
22465 expression code--redundant, since it can be obtained with
22468 In implementing this hook, you can use the construct
22469 `COSTS_N_INSNS (N)' to specify a cost equal to N fast instructions.
22471 On entry to the hook, `*TOTAL' contains a default estimate for the
22472 cost of the expression. The hook should modify this value as
22473 necessary. Traditionally, the default costs are `COSTS_N_INSNS
22474 (5)' for multiplications, `COSTS_N_INSNS (7)' for division and
22475 modulus operations, and `COSTS_N_INSNS (1)' for all other
22478 When optimizing for code size, i.e. when `optimize_size' is
22479 nonzero, this target hook should be used to estimate the relative
22480 size cost of an expression, again relative to `COSTS_N_INSNS'.
22482 The hook returns true when all subexpressions of X have been
22483 processed, and false when `rtx_cost' should recurse.
22485 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS)
22486 This hook computes the cost of an addressing mode that contains
22487 ADDRESS. If not defined, the cost is computed from the ADDRESS
22488 expression and the `TARGET_RTX_COST' hook.
22490 For most CISC machines, the default cost is a good approximation
22491 of the true cost of the addressing mode. However, on RISC
22492 machines, all instructions normally have the same length and
22493 execution time. Hence all addresses will have equal costs.
22495 In cases where more than one form of an address is known, the form
22496 with the lowest cost will be used. If multiple forms have the
22497 same, lowest, cost, the one that is the most complex will be used.
22499 For example, suppose an address that is equal to the sum of a
22500 register and a constant is used twice in the same basic block.
22501 When this macro is not defined, the address will be computed in a
22502 register and memory references will be indirect through that
22503 register. On machines where the cost of the addressing mode
22504 containing the sum is no higher than that of a simple indirect
22505 reference, this will produce an additional instruction and
22506 possibly require an additional register. Proper specification of
22507 this macro eliminates this overhead for such machines.
22509 This hook is never called with an invalid address.
22511 On machines where an address involving more than one register is as
22512 cheap as an address computation involving only one register,
22513 defining `TARGET_ADDRESS_COST' to reflect this can cause two
22514 registers to be live over a region of code where only one would
22515 have been if `TARGET_ADDRESS_COST' were not defined in that
22516 manner. This effect should be considered in the definition of
22517 this macro. Equivalent costs should probably only be given to
22518 addresses with different numbers of registers on machines with
22522 File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros
22524 14.16 Adjusting the Instruction Scheduler
22525 =========================================
22527 The instruction scheduler may need a fair amount of machine-specific
22528 adjustment in order to produce good code. GCC provides several target
22529 hooks for this purpose. It is usually enough to define just a few of
22530 them: try the first ones in this list first.
22532 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void)
22533 This hook returns the maximum number of instructions that can ever
22534 issue at the same time on the target machine. The default is one.
22535 Although the insn scheduler can define itself the possibility of
22536 issue an insn on the same cycle, the value can serve as an
22537 additional constraint to issue insns on the same simulated
22538 processor cycle (see hooks `TARGET_SCHED_REORDER' and
22539 `TARGET_SCHED_REORDER2'). This value must be constant over the
22540 entire compilation. If you need it to vary depending on what the
22541 instructions are, you must use `TARGET_SCHED_VARIABLE_ISSUE'.
22543 You could define this hook to return the value of the macro
22544 `MAX_DFA_ISSUE_RATE'.
22546 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int
22547 VERBOSE, rtx INSN, int MORE)
22548 This hook is executed by the scheduler after it has scheduled an
22549 insn from the ready list. It should return the number of insns
22550 which can still be issued in the current cycle. The default is
22551 `MORE - 1' for insns other than `CLOBBER' and `USE', which
22552 normally are not counted against the issue rate. You should
22553 define this hook if some insns take more machine resources than
22554 others, so that fewer insns can follow them in the same cycle.
22555 FILE is either a null pointer, or a stdio stream to write any
22556 debug output to. VERBOSE is the verbose level provided by
22557 `-fsched-verbose-N'. INSN is the instruction that was scheduled.
22559 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx INSN, rtx LINK, rtx
22560 DEP_INSN, int COST)
22561 This function corrects the value of COST based on the relationship
22562 between INSN and DEP_INSN through the dependence LINK. It should
22563 return the new value. The default is to make no adjustment to
22564 COST. This can be used for example to specify to the scheduler
22565 using the traditional pipeline description that an output- or
22566 anti-dependence does not incur the same cost as a data-dependence.
22567 If the scheduler using the automaton based pipeline description,
22568 the cost of anti-dependence is zero and the cost of
22569 output-dependence is maximum of one and the difference of latency
22570 times of the first and the second insns. If these values are not
22571 acceptable, you could use the hook to modify them too. See also
22572 *note Processor pipeline description::.
22574 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx INSN, int
22576 This hook adjusts the integer scheduling priority PRIORITY of
22577 INSN. It should return the new priority. Reduce the priority to
22578 execute INSN earlier, increase the priority to execute INSN later.
22579 Do not define this hook if you do not need to adjust the
22580 scheduling priorities of insns.
22582 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, rtx
22583 *READY, int *N_READYP, int CLOCK)
22584 This hook is executed by the scheduler after it has scheduled the
22585 ready list, to allow the machine description to reorder it (for
22586 example to combine two small instructions together on `VLIW'
22587 machines). FILE is either a null pointer, or a stdio stream to
22588 write any debug output to. VERBOSE is the verbose level provided
22589 by `-fsched-verbose-N'. READY is a pointer to the ready list of
22590 instructions that are ready to be scheduled. N_READYP is a
22591 pointer to the number of elements in the ready list. The scheduler
22592 reads the ready list in reverse order, starting with
22593 READY[*N_READYP-1] and going to READY[0]. CLOCK is the timer tick
22594 of the scheduler. You may modify the ready list and the number of
22595 ready insns. The return value is the number of insns that can
22596 issue this cycle; normally this is just `issue_rate'. See also
22597 `TARGET_SCHED_REORDER2'.
22599 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE,
22600 rtx *READY, int *N_READY, CLOCK)
22601 Like `TARGET_SCHED_REORDER', but called at a different time. That
22602 function is called whenever the scheduler starts a new cycle.
22603 This one is called once per iteration over a cycle, immediately
22604 after `TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list
22605 and return the number of insns to be scheduled in the same cycle.
22606 Defining this hook can be useful if there are frequent situations
22607 where scheduling one insn causes other insns to become ready in
22608 the same cycle. These other insns can then be taken into account
22611 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK (rtx
22613 This hook is called after evaluation forward dependencies of insns
22614 in chain given by two parameter values (HEAD and TAIL
22615 correspondingly) but before insns scheduling of the insn chain.
22616 For example, it can be used for better insn classification if it
22617 requires analysis of dependencies. This hook can use backward and
22618 forward dependencies of the insn scheduler because they are already
22621 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int
22623 This hook is executed by the scheduler at the beginning of each
22624 block of instructions that are to be scheduled. FILE is either a
22625 null pointer, or a stdio stream to write any debug output to.
22626 VERBOSE is the verbose level provided by `-fsched-verbose-N'.
22627 MAX_READY is the maximum number of insns in the current scheduling
22628 region that can be live at the same time. This can be used to
22629 allocate scratch space if it is needed, e.g. by
22630 `TARGET_SCHED_REORDER'.
22632 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE)
22633 This hook is executed by the scheduler at the end of each block of
22634 instructions that are to be scheduled. It can be used to perform
22635 cleanup of any actions done by the other scheduling hooks. FILE
22636 is either a null pointer, or a stdio stream to write any debug
22637 output to. VERBOSE is the verbose level provided by
22638 `-fsched-verbose-N'.
22640 -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int
22641 VERBOSE, int OLD_MAX_UID)
22642 This hook is executed by the scheduler after function level
22643 initializations. FILE is either a null pointer, or a stdio stream
22644 to write any debug output to. VERBOSE is the verbose level
22645 provided by `-fsched-verbose-N'. OLD_MAX_UID is the maximum insn
22646 uid when scheduling begins.
22648 -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int
22650 This is the cleanup hook corresponding to
22651 `TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a
22652 stdio stream to write any debug output to. VERBOSE is the verbose
22653 level provided by `-fsched-verbose-N'.
22655 -- Target Hook: int TARGET_SCHED_DFA_PRE_CYCLE_INSN (void)
22656 The hook returns an RTL insn. The automaton state used in the
22657 pipeline hazard recognizer is changed as if the insn were scheduled
22658 when the new simulated processor cycle starts. Usage of the hook
22659 may simplify the automaton pipeline description for some VLIW
22660 processors. If the hook is defined, it is used only for the
22661 automaton based pipeline description. The default is not to
22662 change the state when the new simulated processor cycle starts.
22664 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void)
22665 The hook can be used to initialize data used by the previous hook.
22667 -- Target Hook: int TARGET_SCHED_DFA_POST_CYCLE_INSN (void)
22668 The hook is analogous to `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used
22669 to changed the state as if the insn were scheduled when the new
22670 simulated processor cycle finishes.
22672 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void)
22673 The hook is analogous to `TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but
22674 used to initialize data used by the previous hook.
22676 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD
22678 This hook controls better choosing an insn from the ready insn
22679 queue for the DFA-based insn scheduler. Usually the scheduler
22680 chooses the first insn from the queue. If the hook returns a
22681 positive value, an additional scheduler code tries all
22682 permutations of `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD
22683 ()' subsequent ready insns to choose an insn whose issue will
22684 result in maximal number of issued insns on the same cycle. For
22685 the VLIW processor, the code could actually solve the problem of
22686 packing simple insns into the VLIW insn. Of course, if the rules
22687 of VLIW packing are described in the automaton.
22689 This code also could be used for superscalar RISC processors. Let
22690 us consider a superscalar RISC processor with 3 pipelines. Some
22691 insns can be executed in pipelines A or B, some insns can be
22692 executed only in pipelines B or C, and one insn can be executed in
22693 pipeline B. The processor may issue the 1st insn into A and the
22694 2nd one into B. In this case, the 3rd insn will wait for freeing B
22695 until the next cycle. If the scheduler issues the 3rd insn the
22696 first, the processor could issue all 3 insns per cycle.
22698 Actually this code demonstrates advantages of the automaton based
22699 pipeline hazard recognizer. We try quickly and easy many insn
22700 schedules to choose the best one.
22702 The default is no multipass scheduling.
22704 -- Target Hook: int
22705 TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD (rtx)
22706 This hook controls what insns from the ready insn queue will be
22707 considered for the multipass insn scheduling. If the hook returns
22708 zero for insn passed as the parameter, the insn will be not chosen
22711 The default is that any ready insns can be chosen to be issued.
22713 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *, int, rtx, int,
22715 This hook is called by the insn scheduler before issuing insn
22716 passed as the third parameter on given cycle. If the hook returns
22717 nonzero, the insn is not issued on given processors cycle.
22718 Instead of that, the processor cycle is advanced. If the value
22719 passed through the last parameter is zero, the insn ready queue is
22720 not sorted on the new cycle start as usually. The first parameter
22721 passes file for debugging output. The second one passes the
22722 scheduler verbose level of the debugging output. The forth and
22723 the fifth parameter values are correspondingly processor cycle on
22724 which the previous insn has been issued and the current processor
22727 -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (rtx INSN1, rtx
22728 INSN2, rtx DEP_LINK, int DEP_COST, int DISTANCE)
22729 This hook is used to define which dependences are considered
22730 costly by the target, so costly that it is not advisable to
22731 schedule the insns that are involved in the dependence too close
22732 to one another. The parameters to this hook are as follows: The
22733 second parameter INSN2 is dependent upon the first parameter
22734 INSN1. The dependence between INSN1 and INSN2 is represented by
22735 the third parameter DEP_LINK. The fourth parameter COST is the
22736 cost of the dependence, and the fifth parameter DISTANCE is the
22737 distance in cycles between the two insns. The hook returns `true'
22738 if considering the distance between the two insns the dependence
22739 between them is considered costly by the target, and `false'
22742 Defining this hook can be useful in multiple-issue out-of-order
22743 machines, where (a) it's practically hopeless to predict the
22744 actual data/resource delays, however: (b) there's a better chance
22745 to predict the actual grouping that will be formed, and (c)
22746 correctly emulating the grouping can be very important. In such
22747 targets one may want to allow issuing dependent insns closer to
22748 one another--i.e., closer than the dependence distance; however,
22749 not in cases of "costly dependences", which this hooks allows to
22752 Macros in the following table are generated by the program `genattr'
22753 and can be useful for writing the hooks.
22755 -- Macro: MAX_DFA_ISSUE_RATE
22756 The macro definition is generated in the automaton based pipeline
22757 description interface. Its value is calculated from the automaton
22758 based pipeline description and is equal to maximal number of all
22759 insns described in constructions `define_insn_reservation' which
22760 can be issued on the same processor cycle.
22763 File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros
22765 14.17 Dividing the Output into Sections (Texts, Data, ...)
22766 ==========================================================
22768 An object file is divided into sections containing different types of
22769 data. In the most common case, there are three sections: the "text
22770 section", which holds instructions and read-only data; the "data
22771 section", which holds initialized writable data; and the "bss section",
22772 which holds uninitialized data. Some systems have other kinds of
22775 The compiler must tell the assembler when to switch sections. These
22776 macros control what commands to output to tell the assembler this. You
22777 can also define additional sections.
22779 -- Macro: TEXT_SECTION_ASM_OP
22780 A C expression whose value is a string, including spacing,
22781 containing the assembler operation that should precede
22782 instructions and read-only data. Normally `"\t.text"' is right.
22784 -- Macro: HOT_TEXT_SECTION_NAME
22785 If defined, a C string constant for the name of the section
22786 containing most frequently executed functions of the program. If
22787 not defined, GCC will provide a default definition if the target
22788 supports named sections.
22790 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME
22791 If defined, a C string constant for the name of the section
22792 containing unlikely executed functions in the program.
22794 -- Macro: DATA_SECTION_ASM_OP
22795 A C expression whose value is a string, including spacing,
22796 containing the assembler operation to identify the following data
22797 as writable initialized data. Normally `"\t.data"' is right.
22799 -- Macro: READONLY_DATA_SECTION_ASM_OP
22800 A C expression whose value is a string, including spacing,
22801 containing the assembler operation to identify the following data
22802 as read-only initialized data.
22804 -- Macro: READONLY_DATA_SECTION
22805 A macro naming a function to call to switch to the proper section
22806 for read-only data. The default is to use
22807 `READONLY_DATA_SECTION_ASM_OP' if defined, else fall back to
22810 The most common definition will be `data_section', if the target
22811 does not have a special read-only data section, and does not put
22812 data in the text section.
22814 -- Macro: BSS_SECTION_ASM_OP
22815 If defined, a C expression whose value is a string, including
22816 spacing, containing the assembler operation to identify the
22817 following data as uninitialized global data. If not defined, and
22818 neither `ASM_OUTPUT_BSS' nor `ASM_OUTPUT_ALIGNED_BSS' are defined,
22819 uninitialized global data will be output in the data section if
22820 `-fno-common' is passed, otherwise `ASM_OUTPUT_COMMON' will be
22823 -- Macro: INIT_SECTION_ASM_OP
22824 If defined, a C expression whose value is a string, including
22825 spacing, containing the assembler operation to identify the
22826 following data as initialization code. If not defined, GCC will
22827 assume such a section does not exist.
22829 -- Macro: FINI_SECTION_ASM_OP
22830 If defined, a C expression whose value is a string, including
22831 spacing, containing the assembler operation to identify the
22832 following data as finalization code. If not defined, GCC will
22833 assume such a section does not exist.
22835 -- Macro: INIT_ARRAY_SECTION_ASM_OP
22836 If defined, a C expression whose value is a string, including
22837 spacing, containing the assembler operation to identify the
22838 following data as part of the `.init_array' (or equivalent)
22839 section. If not defined, GCC will assume such a section does not
22840 exist. Do not define both this macro and `INIT_SECTION_ASM_OP'.
22842 -- Macro: FINI_ARRAY_SECTION_ASM_OP
22843 If defined, a C expression whose value is a string, including
22844 spacing, containing the assembler operation to identify the
22845 following data as part of the `.fini_array' (or equivalent)
22846 section. If not defined, GCC will assume such a section does not
22847 exist. Do not define both this macro and `FINI_SECTION_ASM_OP'.
22849 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION)
22850 If defined, an ASM statement that switches to a different section
22851 via SECTION_OP, calls FUNCTION, and switches back to the text
22852 section. This is used in `crtstuff.c' if `INIT_SECTION_ASM_OP' or
22853 `FINI_SECTION_ASM_OP' to calls to initialization and finalization
22854 functions from the init and fini sections. By default, this macro
22855 uses a simple function call. Some ports need hand-crafted
22856 assembly code to avoid dependencies on registers initialized in
22857 the function prologue or to ensure that constant pools don't end
22858 up too far way in the text section.
22860 -- Macro: FORCE_CODE_SECTION_ALIGN
22861 If defined, an ASM statement that aligns a code section to some
22862 arbitrary boundary. This is used to force all fragments of the
22863 `.init' and `.fini' sections to have to same alignment and thus
22864 prevent the linker from having to add any padding.
22866 -- Macro: EXTRA_SECTIONS
22867 A list of names for sections other than the standard two, which are
22868 `in_text' and `in_data'. You need not define this macro on a
22869 system with no other sections (that GCC needs to use).
22871 -- Macro: EXTRA_SECTION_FUNCTIONS
22872 One or more functions to be defined in `varasm.c'. These
22873 functions should do jobs analogous to those of `text_section' and
22874 `data_section', for your additional sections. Do not define this
22875 macro if you do not define `EXTRA_SECTIONS'.
22877 -- Macro: JUMP_TABLES_IN_TEXT_SECTION
22878 Define this macro to be an expression with a nonzero value if jump
22879 tables (for `tablejump' insns) should be output in the text
22880 section, along with the assembler instructions. Otherwise, the
22881 readonly data section is used.
22883 This macro is irrelevant if there is no separate readonly data
22886 -- Target Hook: void TARGET_ASM_SELECT_SECTION (tree EXP, int RELOC,
22887 unsigned HOST_WIDE_INT ALIGN)
22888 Switches to the appropriate section for output of EXP. You can
22889 assume that EXP is either a `VAR_DECL' node or a constant of some
22890 sort. RELOC indicates whether the initial value of EXP requires
22891 link-time relocations. Bit 0 is set when variable contains local
22892 relocations only, while bit 1 is set for global relocations.
22893 Select the section by calling `data_section' or one of the
22894 alternatives for other sections. ALIGN is the constant alignment
22897 The default version of this function takes care of putting
22898 read-only variables in `readonly_data_section'.
22900 See also USE_SELECT_SECTION_FOR_FUNCTIONS.
22902 -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS
22903 Define this macro if you wish TARGET_ASM_SELECT_SECTION to be
22904 called for `FUNCTION_DECL's as well as for variables and constants.
22906 In the case of a `FUNCTION_DECL', RELOC will be zero if the
22907 function has been determined to be likely to be called, and
22908 nonzero if it is unlikely to be called.
22910 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC)
22911 Build up a unique section name, expressed as a `STRING_CST' node,
22912 and assign it to `DECL_SECTION_NAME (DECL)'. As with
22913 `TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial
22914 value of EXP requires link-time relocations.
22916 The default version of this function appends the symbol name to the
22917 ELF section name that would normally be used for the symbol. For
22918 example, the function `foo' would be placed in `.text.foo'.
22919 Whatever the actual target object format, this is often good
22922 -- Target Hook: void TARGET_ASM_FUNCTION_RODATA_SECTION (tree DECL)
22923 Switches to a readonly data section associated with
22924 `DECL_SECTION_NAME (DECL)'. The default version of this function
22925 switches to `.gnu.linkonce.r.name' section if function's section
22926 is `.gnu.linkonce.t.name', to `.rodata.name' if function is in
22927 `.text.name' section and otherwise switches to the normal readonly
22930 -- Target Hook: void TARGET_ASM_SELECT_RTX_SECTION (enum machine_mode
22931 MODE, rtx X, unsigned HOST_WIDE_INT ALIGN)
22932 Switches to the appropriate section for output of constant pool
22933 entry X in MODE. You can assume that X is some kind of constant
22934 in RTL. The argument MODE is redundant except in the case of a
22935 `const_int' rtx. Select the section by calling
22936 `readonly_data_section' or one of the alternatives for other
22937 sections. ALIGN is the constant alignment in bits.
22939 The default version of this function takes care of putting symbolic
22940 constants in `flag_pic' mode in `data_section' and everything else
22941 in `readonly_data_section'.
22943 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL,
22945 Define this hook if references to a symbol or a constant must be
22946 treated differently depending on something about the variable or
22947 function named by the symbol (such as what section it is in).
22949 The hook is executed immediately after rtl has been created for
22950 DECL, which may be a variable or function declaration or an entry
22951 in the constant pool. In either case, RTL is the rtl in question.
22952 Do _not_ use `DECL_RTL (DECL)' in this hook; that field may not
22953 have been initialized yet.
22955 In the case of a constant, it is safe to assume that the rtl is a
22956 `mem' whose address is a `symbol_ref'. Most decls will also have
22957 this form, but that is not guaranteed. Global register variables,
22958 for instance, will have a `reg' for their rtl. (Normally the
22959 right thing to do with such unusual rtl is leave it alone.)
22961 The NEW_DECL_P argument will be true if this is the first time
22962 that `TARGET_ENCODE_SECTION_INFO' has been invoked on this decl.
22963 It will be false for subsequent invocations, which will happen for
22964 duplicate declarations. Whether or not anything must be done for
22965 the duplicate declaration depends on whether the hook examines
22966 `DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is
22967 called for a constant.
22969 The usual thing for this hook to do is to record flags in the
22970 `symbol_ref', using `SYMBOL_REF_FLAG' or `SYMBOL_REF_FLAGS'.
22971 Historically, the name string was modified if it was necessary to
22972 encode more than one bit of information, but this practice is now
22973 discouraged; use `SYMBOL_REF_FLAGS'.
22975 The default definition of this hook, `default_encode_section_info'
22976 in `varasm.c', sets a number of commonly-useful bits in
22977 `SYMBOL_REF_FLAGS'. Check whether the default does what you need
22978 before overriding it.
22980 -- Target Hook: const char *TARGET_STRIP_NAME_ENCODING (const char
22982 Decode NAME and return the real name part, sans the characters
22983 that `TARGET_ENCODE_SECTION_INFO' may have added.
22985 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (tree EXP)
22986 Returns true if EXP should be placed into a "small data" section.
22987 The default version of this hook always returns false.
22989 -- Variable: Target Hook bool TARGET_HAVE_SRODATA_SECTION
22990 Contains the value true if the target places read-only "small
22991 data" into a separate section. The default value is false.
22993 -- Target Hook: bool TARGET_BINDS_LOCAL_P (tree EXP)
22994 Returns true if EXP names an object for which name resolution
22995 rules must resolve to the current "module" (dynamic shared library
22996 or executable image).
22998 The default version of this hook implements the name resolution
22999 rules for ELF, which has a looser model of global name binding
23000 than other currently supported object file formats.
23002 -- Variable: Target Hook bool TARGET_HAVE_TLS
23003 Contains the value true if the target supports thread-local
23004 storage. The default value is false.
23007 File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros
23009 14.18 Position Independent Code
23010 ===============================
23012 This section describes macros that help implement generation of position
23013 independent code. Simply defining these macros is not enough to
23014 generate valid PIC; you must also add support to the macros
23015 `GO_IF_LEGITIMATE_ADDRESS' and `PRINT_OPERAND_ADDRESS', as well as
23016 `LEGITIMIZE_ADDRESS'. You must modify the definition of `movsi' to do
23017 something appropriate when the source operand contains a symbolic
23018 address. You may also need to alter the handling of switch statements
23019 so that they use relative addresses.
23021 -- Macro: PIC_OFFSET_TABLE_REGNUM
23022 The register number of the register used to address a table of
23023 static data addresses in memory. In some cases this register is
23024 defined by a processor's "application binary interface" (ABI).
23025 When this macro is defined, RTL is generated for this register
23026 once, as with the stack pointer and frame pointer registers. If
23027 this macro is not defined, it is up to the machine-dependent files
23028 to allocate such a register (if necessary). Note that this
23029 register must be fixed when in use (e.g. when `flag_pic' is true).
23031 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED
23032 Define this macro if the register defined by
23033 `PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. Do not define
23034 this macro if `PIC_OFFSET_TABLE_REGNUM' is not defined.
23036 -- Macro: LEGITIMATE_PIC_OPERAND_P (X)
23037 A C expression that is nonzero if X is a legitimate immediate
23038 operand on the target machine when generating position independent
23039 code. You can assume that X satisfies `CONSTANT_P', so you need
23040 not check this. You can also assume FLAG_PIC is true, so you need
23041 not check it either. You need not define this macro if all
23042 constants (including `SYMBOL_REF') can be immediate operands when
23043 generating position independent code.
23046 File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros
23048 14.19 Defining the Output Assembler Language
23049 ============================================
23051 This section describes macros whose principal purpose is to describe how
23052 to write instructions in assembler language--rather than what the
23057 * File Framework:: Structural information for the assembler file.
23058 * Data Output:: Output of constants (numbers, strings, addresses).
23059 * Uninitialized Data:: Output of uninitialized variables.
23060 * Label Output:: Output and generation of labels.
23061 * Initialization:: General principles of initialization
23062 and termination routines.
23063 * Macros for Initialization::
23064 Specific macros that control the handling of
23065 initialization and termination routines.
23066 * Instruction Output:: Output of actual instructions.
23067 * Dispatch Tables:: Output of jump tables.
23068 * Exception Region Output:: Output of exception region code.
23069 * Alignment Output:: Pseudo ops for alignment and skipping data.
23072 File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format
23074 14.19.1 The Overall Framework of an Assembler File
23075 --------------------------------------------------
23077 This describes the overall framework of an assembly file.
23079 -- Target Hook: void TARGET_ASM_FILE_START ()
23080 Output to `asm_out_file' any text which the assembler expects to
23081 find at the beginning of a file. The default behavior is
23082 controlled by two flags, documented below. Unless your target's
23083 assembler is quite unusual, if you override the default, you
23084 should call `default_file_start' at some point in your target
23085 hook. This lets other target files rely on these variables.
23087 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF
23088 If this flag is true, the text of the macro `ASM_APP_OFF' will be
23089 printed as the very first line in the assembly file, unless
23090 `-fverbose-asm' is in effect. (If that macro has been defined to
23091 the empty string, this variable has no effect.) With the normal
23092 definition of `ASM_APP_OFF', the effect is to notify the GNU
23093 assembler that it need not bother stripping comments or extra
23094 whitespace from its input. This allows it to work a bit faster.
23096 The default is false. You should not set it to true unless you
23097 have verified that your port does not generate any extra
23098 whitespace or comments that will cause GAS to issue errors in
23101 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE
23102 If this flag is true, `output_file_directive' will be called for
23103 the primary source file, immediately after printing `ASM_APP_OFF'
23104 (if that is enabled). Most ELF assemblers expect this to be done.
23105 The default is false.
23107 -- Target Hook: void TARGET_ASM_FILE_END ()
23108 Output to `asm_out_file' any text which the assembler expects to
23109 find at the end of a file. The default is to output nothing.
23111 -- Function: void file_end_indicate_exec_stack ()
23112 Some systems use a common convention, the `.note.GNU-stack'
23113 special section, to indicate whether or not an object file relies
23114 on the stack being executable. If your system uses this
23115 convention, you should define `TARGET_ASM_FILE_END' to this
23116 function. If you need to do other things in that hook, have your
23117 hook function call this function.
23119 -- Macro: ASM_COMMENT_START
23120 A C string constant describing how to begin a comment in the target
23121 assembler language. The compiler assumes that the comment will
23122 end at the end of the line.
23124 -- Macro: ASM_APP_ON
23125 A C string constant for text to be output before each `asm'
23126 statement or group of consecutive ones. Normally this is
23127 `"#APP"', which is a comment that has no effect on most assemblers
23128 but tells the GNU assembler that it must check the lines that
23129 follow for all valid assembler constructs.
23131 -- Macro: ASM_APP_OFF
23132 A C string constant for text to be output after each `asm'
23133 statement or group of consecutive ones. Normally this is
23134 `"#NO_APP"', which tells the GNU assembler to resume making the
23135 time-saving assumptions that are valid for ordinary compiler
23138 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME)
23139 A C statement to output COFF information or DWARF debugging
23140 information which indicates that filename NAME is the current
23141 source file to the stdio stream STREAM.
23143 This macro need not be defined if the standard form of output for
23144 the file format in use is appropriate.
23146 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING)
23147 A C statement to output the string STRING to the stdio stream
23148 STREAM. If you do not call the function `output_quoted_string' in
23149 your config files, GCC will only call it to output filenames to
23150 the assembler source. So you can use it to canonicalize the format
23151 of the filename using this macro.
23153 -- Macro: ASM_OUTPUT_IDENT (STREAM, STRING)
23154 A C statement to output something to the assembler file to handle a
23155 `#ident' directive containing the text STRING. If this macro is
23156 not defined, nothing is output for a `#ident' directive.
23158 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME,
23159 unsigned int FLAGS, unsigned int ALIGN)
23160 Output assembly directives to switch to section NAME. The section
23161 should have attributes as specified by FLAGS, which is a bit mask
23162 of the `SECTION_*' flags defined in `output.h'. If ALIGN is
23163 nonzero, it contains an alignment in bytes to be used for the
23164 section, otherwise some target default should be used. Only
23165 targets that must specify an alignment within the section
23166 directive need pay attention to ALIGN - we will still use
23167 `ASM_OUTPUT_ALIGN'.
23169 -- Target Hook: bool TARGET_HAVE_NAMED_SECTIONS
23170 This flag is true if the target supports
23171 `TARGET_ASM_NAMED_SECTION'.
23173 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL,
23174 const char *NAME, int RELOC)
23175 Choose a set of section attributes for use by
23176 `TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a
23177 section name, and whether or not the declaration's initializer may
23178 contain runtime relocations. DECL may be null, in which case
23179 read-write data should be assumed.
23181 The default version if this function handles choosing code vs data,
23182 read-only vs read-write data, and `flag_pic'. You should only
23183 need to override this if your target has special flags that might
23184 be set via `__attribute__'.
23187 File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format
23189 14.19.2 Output of Data
23190 ----------------------
23192 -- Target Hook: const char * TARGET_ASM_BYTE_OP
23193 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP
23194 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP
23195 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP
23196 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP
23197 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP
23198 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP
23199 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP
23200 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP
23201 These hooks specify assembly directives for creating certain kinds
23202 of integer object. The `TARGET_ASM_BYTE_OP' directive creates a
23203 byte-sized object, the `TARGET_ASM_ALIGNED_HI_OP' one creates an
23204 aligned two-byte object, and so on. Any of the hooks may be
23205 `NULL', indicating that no suitable directive is available.
23207 The compiler will print these strings at the start of a new line,
23208 followed immediately by the object's initial value. In most cases,
23209 the string should contain a tab, a pseudo-op, and then another tab.
23211 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int
23213 The `assemble_integer' function uses this hook to output an
23214 integer object. X is the object's value, SIZE is its size in
23215 bytes and ALIGNED_P indicates whether it is aligned. The function
23216 should return `true' if it was able to output the object. If it
23217 returns false, `assemble_integer' will try to split the object
23218 into smaller parts.
23220 The default implementation of this hook will use the
23221 `TARGET_ASM_BYTE_OP' family of strings, returning `false' when the
23222 relevant string is `NULL'.
23224 -- Macro: OUTPUT_ADDR_CONST_EXTRA (STREAM, X, FAIL)
23225 A C statement to recognize RTX patterns that `output_addr_const'
23226 can't deal with, and output assembly code to STREAM corresponding
23227 to the pattern X. This may be used to allow machine-dependent
23228 `UNSPEC's to appear within constants.
23230 If `OUTPUT_ADDR_CONST_EXTRA' fails to recognize a pattern, it must
23231 `goto fail', so that a standard error message is printed. If it
23232 prints an error message itself, by calling, for example,
23233 `output_operand_lossage', it may just complete normally.
23235 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN)
23236 A C statement to output to the stdio stream STREAM an assembler
23237 instruction to assemble a string constant containing the LEN bytes
23238 at PTR. PTR will be a C expression of type `char *' and LEN a C
23239 expression of type `int'.
23241 If the assembler has a `.ascii' pseudo-op as found in the Berkeley
23242 Unix assembler, do not define the macro `ASM_OUTPUT_ASCII'.
23244 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N)
23245 A C statement to output word N of a function descriptor for DECL.
23246 This must be defined if `TARGET_VTABLE_USES_DESCRIPTORS' is
23247 defined, and is otherwise unused.
23249 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION
23250 You may define this macro as a C expression. You should define the
23251 expression to have a nonzero value if GCC should output the
23252 constant pool for a function before the code for the function, or
23253 a zero value if GCC should output the constant pool after the
23254 function. If you do not define this macro, the usual case, GCC
23255 will output the constant pool before the function.
23257 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE)
23258 A C statement to output assembler commands to define the start of
23259 the constant pool for a function. FUNNAME is a string giving the
23260 name of the function. Should the return type of the function be
23261 required, it can be obtained via FUNDECL. SIZE is the size, in
23262 bytes, of the constant pool that will be written immediately after
23265 If no constant-pool prefix is required, the usual case, this macro
23266 need not be defined.
23268 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN,
23270 A C statement (with or without semicolon) to output a constant in
23271 the constant pool, if it needs special treatment. (This macro
23272 need not do anything for RTL expressions that can be output
23275 The argument FILE is the standard I/O stream to output the
23276 assembler code on. X is the RTL expression for the constant to
23277 output, and MODE is the machine mode (in case X is a `const_int').
23278 ALIGN is the required alignment for the value X; you should
23279 output an assembler directive to force this much alignment.
23281 The argument LABELNO is a number to use in an internal label for
23282 the address of this pool entry. The definition of this macro is
23283 responsible for outputting the label definition at the proper
23284 place. Here is how to do this:
23286 `(*targetm.asm_out.internal_label)' (FILE, "LC", LABELNO);
23288 When you output a pool entry specially, you should end with a
23289 `goto' to the label JUMPTO. This will prevent the same pool entry
23290 from being output a second time in the usual manner.
23292 You need not define this macro if it would do nothing.
23294 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE)
23295 A C statement to output assembler commands to at the end of the
23296 constant pool for a function. FUNNAME is a string giving the name
23297 of the function. Should the return type of the function be
23298 required, you can obtain it via FUNDECL. SIZE is the size, in
23299 bytes, of the constant pool that GCC wrote immediately before this
23302 If no constant-pool epilogue is required, the usual case, you need
23303 not define this macro.
23305 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C)
23306 Define this macro as a C expression which is nonzero if C is used
23307 as a logical line separator by the assembler.
23309 If you do not define this macro, the default is that only the
23310 character `;' is treated as a logical line separator.
23312 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN
23313 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN
23314 These target hooks are C string constants, describing the syntax
23315 in the assembler for grouping arithmetic expressions. If not
23316 overridden, they default to normal parentheses, which is correct
23317 for most assemblers.
23319 These macros are provided by `real.h' for writing the definitions of
23320 `ASM_OUTPUT_DOUBLE' and the like:
23322 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L)
23323 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L)
23324 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L)
23325 These translate X, of type `REAL_VALUE_TYPE', to the target's
23326 floating point representation, and store its bit pattern in the
23327 variable L. For `REAL_VALUE_TO_TARGET_SINGLE', this variable
23328 should be a simple `long int'. For the others, it should be an
23329 array of `long int'. The number of elements in this array is
23330 determined by the size of the desired target floating point data
23331 type: 32 bits of it go in each `long int' array element. Each
23332 array element holds 32 bits of the result, even if `long int' is
23333 wider than 32 bits on the host machine.
23335 The array element values are designed so that you can print them
23336 out using `fprintf' in the order they should appear in the target
23340 File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format
23342 14.19.3 Output of Uninitialized Variables
23343 -----------------------------------------
23345 Each of the macros in this section is used to do the whole job of
23346 outputting a single uninitialized variable.
23348 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED)
23349 A C statement (sans semicolon) to output to the stdio stream
23350 STREAM the assembler definition of a common-label named NAME whose
23351 size is SIZE bytes. The variable ROUNDED is the size rounded up
23352 to whatever alignment the caller wants.
23354 Use the expression `assemble_name (STREAM, NAME)' to output the
23355 name itself; before and after that, output the additional
23356 assembler syntax for defining the name, and a newline.
23358 This macro controls how the assembler definitions of uninitialized
23359 common global variables are output.
23361 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT)
23362 Like `ASM_OUTPUT_COMMON' except takes the required alignment as a
23363 separate, explicit argument. If you define this macro, it is used
23364 in place of `ASM_OUTPUT_COMMON', and gives you more flexibility in
23365 handling the required alignment of the variable. The alignment is
23366 specified as the number of bits.
23368 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE,
23370 Like `ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable
23371 to be output, if there is one, or `NULL_TREE' if there is no
23372 corresponding variable. If you define this macro, GCC will use it
23373 in place of both `ASM_OUTPUT_COMMON' and
23374 `ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to
23375 see the variable's decl in order to chose what to output.
23377 -- Macro: ASM_OUTPUT_SHARED_COMMON (STREAM, NAME, SIZE, ROUNDED)
23378 If defined, it is similar to `ASM_OUTPUT_COMMON', except that it
23379 is used when NAME is shared. If not defined, `ASM_OUTPUT_COMMON'
23382 -- Macro: ASM_OUTPUT_BSS (STREAM, DECL, NAME, SIZE, ROUNDED)
23383 A C statement (sans semicolon) to output to the stdio stream
23384 STREAM the assembler definition of uninitialized global DECL named
23385 NAME whose size is SIZE bytes. The variable ROUNDED is the size
23386 rounded up to whatever alignment the caller wants.
23388 Try to use function `asm_output_bss' defined in `varasm.c' when
23389 defining this macro. If unable, use the expression `assemble_name
23390 (STREAM, NAME)' to output the name itself; before and after that,
23391 output the additional assembler syntax for defining the name, and
23394 This macro controls how the assembler definitions of uninitialized
23395 global variables are output. This macro exists to properly
23396 support languages like C++ which do not have `common' data.
23397 However, this macro currently is not defined for all targets. If
23398 this macro and `ASM_OUTPUT_ALIGNED_BSS' are not defined then
23399 `ASM_OUTPUT_COMMON' or `ASM_OUTPUT_ALIGNED_COMMON' or
23400 `ASM_OUTPUT_ALIGNED_DECL_COMMON' is used.
23402 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT)
23403 Like `ASM_OUTPUT_BSS' except takes the required alignment as a
23404 separate, explicit argument. If you define this macro, it is used
23405 in place of `ASM_OUTPUT_BSS', and gives you more flexibility in
23406 handling the required alignment of the variable. The alignment is
23407 specified as the number of bits.
23409 Try to use function `asm_output_aligned_bss' defined in file
23410 `varasm.c' when defining this macro.
23412 -- Macro: ASM_OUTPUT_SHARED_BSS (STREAM, DECL, NAME, SIZE, ROUNDED)
23413 If defined, it is similar to `ASM_OUTPUT_BSS', except that it is
23414 used when NAME is shared. If not defined, `ASM_OUTPUT_BSS' will
23417 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED)
23418 A C statement (sans semicolon) to output to the stdio stream
23419 STREAM the assembler definition of a local-common-label named NAME
23420 whose size is SIZE bytes. The variable ROUNDED is the size
23421 rounded up to whatever alignment the caller wants.
23423 Use the expression `assemble_name (STREAM, NAME)' to output the
23424 name itself; before and after that, output the additional
23425 assembler syntax for defining the name, and a newline.
23427 This macro controls how the assembler definitions of uninitialized
23428 static variables are output.
23430 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT)
23431 Like `ASM_OUTPUT_LOCAL' except takes the required alignment as a
23432 separate, explicit argument. If you define this macro, it is used
23433 in place of `ASM_OUTPUT_LOCAL', and gives you more flexibility in
23434 handling the required alignment of the variable. The alignment is
23435 specified as the number of bits.
23437 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE,
23439 Like `ASM_OUTPUT_ALIGNED_DECL' except that DECL of the variable to
23440 be output, if there is one, or `NULL_TREE' if there is no
23441 corresponding variable. If you define this macro, GCC will use it
23442 in place of both `ASM_OUTPUT_DECL' and `ASM_OUTPUT_ALIGNED_DECL'.
23443 Define this macro when you need to see the variable's decl in
23444 order to chose what to output.
23446 -- Macro: ASM_OUTPUT_SHARED_LOCAL (STREAM, NAME, SIZE, ROUNDED)
23447 If defined, it is similar to `ASM_OUTPUT_LOCAL', except that it is
23448 used when NAME is shared. If not defined, `ASM_OUTPUT_LOCAL' will
23452 File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format
23454 14.19.4 Output and Generation of Labels
23455 ---------------------------------------
23457 This is about outputting labels.
23459 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME)
23460 A C statement (sans semicolon) to output to the stdio stream
23461 STREAM the assembler definition of a label named NAME. Use the
23462 expression `assemble_name (STREAM, NAME)' to output the name
23463 itself; before and after that, output the additional assembler
23464 syntax for defining the name, and a newline. A default definition
23465 of this macro is provided which is correct for most systems.
23467 -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME)
23468 Identical to `ASM_OUTPUT_LABEL', except that NAME is known to
23469 refer to a compiler-generated label. The default definition uses
23470 `assemble_name_raw', which is like `assemble_name' except that it
23473 -- Macro: SIZE_ASM_OP
23474 A C string containing the appropriate assembler directive to
23475 specify the size of a symbol, without any arguments. On systems
23476 that use ELF, the default (in `config/elfos.h') is `"\t.size\t"';
23477 on other systems, the default is not to define this macro.
23479 Define this macro only if it is correct to use the default
23480 definitions of `ASM_OUTPUT_SIZE_DIRECTIVE' and
23481 `ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own
23482 custom definitions of those macros, or if you do not need explicit
23483 symbol sizes at all, do not define this macro.
23485 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE)
23486 A C statement (sans semicolon) to output to the stdio stream
23487 STREAM a directive telling the assembler that the size of the
23488 symbol NAME is SIZE. SIZE is a `HOST_WIDE_INT'. If you define
23489 `SIZE_ASM_OP', a default definition of this macro is provided.
23491 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME)
23492 A C statement (sans semicolon) to output to the stdio stream
23493 STREAM a directive telling the assembler to calculate the size of
23494 the symbol NAME by subtracting its address from the current
23497 If you define `SIZE_ASM_OP', a default definition of this macro is
23498 provided. The default assumes that the assembler recognizes a
23499 special `.' symbol as referring to the current address, and can
23500 calculate the difference between this and another symbol. If your
23501 assembler does not recognize `.' or cannot do calculations with
23502 it, you will need to redefine `ASM_OUTPUT_MEASURED_SIZE' to use
23503 some other technique.
23505 -- Macro: TYPE_ASM_OP
23506 A C string containing the appropriate assembler directive to
23507 specify the type of a symbol, without any arguments. On systems
23508 that use ELF, the default (in `config/elfos.h') is `"\t.type\t"';
23509 on other systems, the default is not to define this macro.
23511 Define this macro only if it is correct to use the default
23512 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you
23513 need your own custom definition of this macro, or if you do not
23514 need explicit symbol types at all, do not define this macro.
23516 -- Macro: TYPE_OPERAND_FMT
23517 A C string which specifies (using `printf' syntax) the format of
23518 the second operand to `TYPE_ASM_OP'. On systems that use ELF, the
23519 default (in `config/elfos.h') is `"@%s"'; on other systems, the
23520 default is not to define this macro.
23522 Define this macro only if it is correct to use the default
23523 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you
23524 need your own custom definition of this macro, or if you do not
23525 need explicit symbol types at all, do not define this macro.
23527 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE)
23528 A C statement (sans semicolon) to output to the stdio stream
23529 STREAM a directive telling the assembler that the type of the
23530 symbol NAME is TYPE. TYPE is a C string; currently, that string
23531 is always either `"function"' or `"object"', but you should not
23534 If you define `TYPE_ASM_OP' and `TYPE_OPERAND_FMT', a default
23535 definition of this macro is provided.
23537 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL)
23538 A C statement (sans semicolon) to output to the stdio stream
23539 STREAM any text necessary for declaring the name NAME of a
23540 function which is being defined. This macro is responsible for
23541 outputting the label definition (perhaps using
23542 `ASM_OUTPUT_LABEL'). The argument DECL is the `FUNCTION_DECL'
23543 tree node representing the function.
23545 If this macro is not defined, then the function name is defined in
23546 the usual manner as a label (by means of `ASM_OUTPUT_LABEL').
23548 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition
23551 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL)
23552 A C statement (sans semicolon) to output to the stdio stream
23553 STREAM any text necessary for declaring the size of a function
23554 which is being defined. The argument NAME is the name of the
23555 function. The argument DECL is the `FUNCTION_DECL' tree node
23556 representing the function.
23558 If this macro is not defined, then the function size is not
23561 You may wish to use `ASM_OUTPUT_MEASURED_SIZE' in the definition
23564 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL)
23565 A C statement (sans semicolon) to output to the stdio stream
23566 STREAM any text necessary for declaring the name NAME of an
23567 initialized variable which is being defined. This macro must
23568 output the label definition (perhaps using `ASM_OUTPUT_LABEL').
23569 The argument DECL is the `VAR_DECL' tree node representing the
23572 If this macro is not defined, then the variable name is defined in
23573 the usual manner as a label (by means of `ASM_OUTPUT_LABEL').
23575 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' and/or
23576 `ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro.
23578 -- Macro: ASM_DECLARE_CONSTANT_NAME (STREAM, NAME, EXP, SIZE)
23579 A C statement (sans semicolon) to output to the stdio stream
23580 STREAM any text necessary for declaring the name NAME of a
23581 constant which is being defined. This macro is responsible for
23582 outputting the label definition (perhaps using
23583 `ASM_OUTPUT_LABEL'). The argument EXP is the value of the
23584 constant, and SIZE is the size of the constant in bytes. NAME
23585 will be an internal label.
23587 If this macro is not defined, then the NAME is defined in the
23588 usual manner as a label (by means of `ASM_OUTPUT_LABEL').
23590 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition
23593 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME)
23594 A C statement (sans semicolon) to output to the stdio stream
23595 STREAM any text necessary for claiming a register REGNO for a
23596 global variable DECL with name NAME.
23598 If you don't define this macro, that is equivalent to defining it
23601 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND)
23602 A C statement (sans semicolon) to finish up declaring a variable
23603 name once the compiler has processed its initializer fully and
23604 thus has had a chance to determine the size of an array when
23605 controlled by an initializer. This is used on systems where it's
23606 necessary to declare something about the size of the object.
23608 If you don't define this macro, that is equivalent to defining it
23611 You may wish to use `ASM_OUTPUT_SIZE_DIRECTIVE' and/or
23612 `ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro.
23614 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const
23616 This target hook is a function to output to the stdio stream
23617 STREAM some commands that will make the label NAME global; that
23618 is, available for reference from other files.
23620 The default implementation relies on a proper definition of
23623 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME)
23624 A C statement (sans semicolon) to output to the stdio stream
23625 STREAM some commands that will make the label NAME weak; that is,
23626 available for reference from other files but only used if no other
23627 definition is available. Use the expression `assemble_name
23628 (STREAM, NAME)' to output the name itself; before and after that,
23629 output the additional assembler syntax for making that name weak,
23632 If you don't define this macro or `ASM_WEAKEN_DECL', GCC will not
23633 support weak symbols and you should not define the `SUPPORTS_WEAK'
23636 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE)
23637 Combines (and replaces) the function of `ASM_WEAKEN_LABEL' and
23638 `ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function
23639 or variable decl. If VALUE is not `NULL', this C statement should
23640 output to the stdio stream STREAM assembler code which defines
23641 (equates) the weak symbol NAME to have the value VALUE. If VALUE
23642 is `NULL', it should output commands to make NAME weak.
23644 -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE)
23645 Outputs a directive that enables NAME to be used to refer to
23646 symbol VALUE with weak-symbol semantics. `decl' is the
23647 declaration of `name'.
23649 -- Macro: SUPPORTS_WEAK
23650 A C expression which evaluates to true if the target supports weak
23653 If you don't define this macro, `defaults.h' provides a default
23654 definition. If either `ASM_WEAKEN_LABEL' or `ASM_WEAKEN_DECL' is
23655 defined, the default definition is `1'; otherwise, it is `0'.
23656 Define this macro if you want to control weak symbol support with
23657 a compiler flag such as `-melf'.
23659 -- Macro: MAKE_DECL_ONE_ONLY (DECL)
23660 A C statement (sans semicolon) to mark DECL to be emitted as a
23661 public symbol such that extra copies in multiple translation units
23662 will be discarded by the linker. Define this macro if your object
23663 file format provides support for this concept, such as the `COMDAT'
23664 section flags in the Microsoft Windows PE/COFF format, and this
23665 support requires changes to DECL, such as putting it in a separate
23668 -- Macro: SUPPORTS_ONE_ONLY
23669 A C expression which evaluates to true if the target supports
23670 one-only semantics.
23672 If you don't define this macro, `varasm.c' provides a default
23673 definition. If `MAKE_DECL_ONE_ONLY' is defined, the default
23674 definition is `1'; otherwise, it is `0'. Define this macro if you
23675 want to control one-only symbol support with a compiler flag, or if
23676 setting the `DECL_ONE_ONLY' flag is enough to mark a declaration to
23677 be emitted as one-only.
23679 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, const
23681 This target hook is a function to output to ASM_OUT_FILE some
23682 commands that will make the symbol(s) associated with DECL have
23683 hidden, protected or internal visibility as specified by
23686 -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC
23687 A C expression that evaluates to true if the target's linker
23688 expects that weak symbols do not appear in a static archive's
23689 table of contents. The default is `0'.
23691 Leaving weak symbols out of an archive's table of contents means
23692 that, if a symbol will only have a definition in one translation
23693 unit and will have undefined references from other translation
23694 units, that symbol should not be weak. Defining this macro to be
23695 nonzero will thus have the effect that certain symbols that would
23696 normally be weak (explicit template instantiations, and vtables
23697 for polymorphic classes with noninline key methods) will instead
23700 The C++ ABI requires this macro to be zero. Define this macro for
23701 targets where full C++ ABI compliance is impossible and where
23702 linker restrictions require weak symbols to be left out of a
23703 static archive's table of contents.
23705 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME)
23706 A C statement (sans semicolon) to output to the stdio stream
23707 STREAM any text necessary for declaring the name of an external
23708 symbol named NAME which is referenced in this compilation but not
23709 defined. The value of DECL is the tree node for the declaration.
23711 This macro need not be defined if it does not need to output
23712 anything. The GNU assembler and most Unix assemblers don't
23715 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF)
23716 This target hook is a function to output to ASM_OUT_FILE an
23717 assembler pseudo-op to declare a library function name external.
23718 The name of the library function is given by SYMREF, which is a
23721 -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (tree DECL)
23722 This target hook is a function to output to ASM_OUT_FILE an
23723 assembler directive to annotate used symbol. Darwin target use
23724 .no_dead_code_strip directive.
23726 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME)
23727 A C statement (sans semicolon) to output to the stdio stream
23728 STREAM a reference in assembler syntax to a label named NAME.
23729 This should add `_' to the front of the name, if that is customary
23730 on your operating system, as it is in most Berkeley Unix systems.
23731 This macro is used in `assemble_name'.
23733 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM)
23734 A C statement (sans semicolon) to output a reference to
23735 `SYMBOL_REF' SYM. If not defined, `assemble_name' will be used to
23736 output the name of the symbol. This macro may be used to modify
23737 the way a symbol is referenced depending on information encoded by
23738 `TARGET_ENCODE_SECTION_INFO'.
23740 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF)
23741 A C statement (sans semicolon) to output a reference to BUF, the
23742 result of `ASM_GENERATE_INTERNAL_LABEL'. If not defined,
23743 `assemble_name' will be used to output the name of the symbol.
23744 This macro is not used by `output_asm_label', or the `%l'
23745 specifier that calls it; the intention is that this macro should
23746 be set when it is necessary to output a label differently when its
23747 address is being taken.
23749 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const
23750 char *PREFIX, unsigned long LABELNO)
23751 A function to output to the stdio stream STREAM a label whose name
23752 is made from the string PREFIX and the number LABELNO.
23754 It is absolutely essential that these labels be distinct from the
23755 labels used for user-level functions and variables. Otherwise,
23756 certain programs will have name conflicts with internal labels.
23758 It is desirable to exclude internal labels from the symbol table
23759 of the object file. Most assemblers have a naming convention for
23760 labels that should be excluded; on many systems, the letter `L' at
23761 the beginning of a label has this effect. You should find out what
23762 convention your system uses, and follow it.
23764 The default version of this function utilizes
23765 `ASM_GENERATE_INTERNAL_LABEL'.
23767 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM)
23768 A C statement to output to the stdio stream STREAM a debug info
23769 label whose name is made from the string PREFIX and the number
23770 NUM. This is useful for VLIW targets, where debug info labels may
23771 need to be treated differently than branch target labels. On some
23772 systems, branch target labels must be at the beginning of
23773 instruction bundles, but debug info labels can occur in the middle
23774 of instruction bundles.
23776 If this macro is not defined, then
23777 `(*targetm.asm_out.internal_label)' will be used.
23779 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM)
23780 A C statement to store into the string STRING a label whose name
23781 is made from the string PREFIX and the number NUM.
23783 This string, when output subsequently by `assemble_name', should
23784 produce the output that `(*targetm.asm_out.internal_label)' would
23785 produce with the same PREFIX and NUM.
23787 If the string begins with `*', then `assemble_name' will output
23788 the rest of the string unchanged. It is often convenient for
23789 `ASM_GENERATE_INTERNAL_LABEL' to use `*' in this way. If the
23790 string doesn't start with `*', then `ASM_OUTPUT_LABELREF' gets to
23791 output the string, and may change it. (Of course,
23792 `ASM_OUTPUT_LABELREF' is also part of your machine description, so
23793 you should know what it does on your machine.)
23795 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER)
23796 A C expression to assign to OUTVAR (which is a variable of type
23797 `char *') a newly allocated string made from the string NAME and
23798 the number NUMBER, with some suitable punctuation added. Use
23799 `alloca' to get space for the string.
23801 The string will be used as an argument to `ASM_OUTPUT_LABELREF' to
23802 produce an assembler label for an internal static variable whose
23803 name is NAME. Therefore, the string must be such as to result in
23804 valid assembler code. The argument NUMBER is different each time
23805 this macro is executed; it prevents conflicts between
23806 similarly-named internal static variables in different scopes.
23808 Ideally this string should not be a valid C identifier, to prevent
23809 any conflict with the user's own symbols. Most assemblers allow
23810 periods or percent signs in assembler symbols; putting at least
23811 one of these between the name and the number will suffice.
23813 If this macro is not defined, a default definition will be provided
23814 which is correct for most systems.
23816 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE)
23817 A C statement to output to the stdio stream STREAM assembler code
23818 which defines (equates) the symbol NAME to have the value VALUE.
23820 If `SET_ASM_OP' is defined, a default definition is provided which
23821 is correct for most systems.
23823 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME,
23825 A C statement to output to the stdio stream STREAM assembler code
23826 which defines (equates) the symbol whose tree node is DECL_OF_NAME
23827 to have the value of the tree node DECL_OF_VALUE. This macro will
23828 be used in preference to `ASM_OUTPUT_DEF' if it is defined and if
23829 the tree nodes are available.
23831 If `SET_ASM_OP' is defined, a default definition is provided which
23832 is correct for most systems.
23834 -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE)
23835 A C statement that evaluates to true if the assembler code which
23836 defines (equates) the symbol whose tree node is DECL_OF_NAME to
23837 have the value of the tree node DECL_OF_VALUE should be emitted
23838 near the end of the current compilation unit. The default is to
23839 not defer output of defines. This macro affects defines output by
23840 `ASM_OUTPUT_DEF' and `ASM_OUTPUT_DEF_FROM_DECLS'.
23842 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE)
23843 A C statement to output to the stdio stream STREAM assembler code
23844 which defines (equates) the weak symbol NAME to have the value
23845 VALUE. If VALUE is `NULL', it defines NAME as an undefined weak
23848 Define this macro if the target only supports weak aliases; define
23849 `ASM_OUTPUT_DEF' instead if possible.
23851 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME,
23853 Define this macro to override the default assembler names used for
23854 Objective-C methods.
23856 The default name is a unique method number followed by the name of
23857 the class (e.g. `_1_Foo'). For methods in categories, the name of
23858 the category is also included in the assembler name (e.g.
23861 These names are safe on most systems, but make debugging difficult
23862 since the method's selector is not present in the name.
23863 Therefore, particular systems define other ways of computing names.
23865 BUF is an expression of type `char *' which gives you a buffer in
23866 which to store the name; its length is as long as CLASS_NAME,
23867 CAT_NAME and SEL_NAME put together, plus 50 characters extra.
23869 The argument IS_INST specifies whether the method is an instance
23870 method or a class method; CLASS_NAME is the name of the class;
23871 CAT_NAME is the name of the category (or `NULL' if the method is
23872 not in a category); and SEL_NAME is the name of the selector.
23874 On systems where the assembler can handle quoted names, you can
23875 use this macro to provide more human-readable names.
23877 -- Macro: ASM_DECLARE_CLASS_REFERENCE (STREAM, NAME)
23878 A C statement (sans semicolon) to output to the stdio stream
23879 STREAM commands to declare that the label NAME is an Objective-C
23880 class reference. This is only needed for targets whose linkers
23881 have special support for NeXT-style runtimes.
23883 -- Macro: ASM_DECLARE_UNRESOLVED_REFERENCE (STREAM, NAME)
23884 A C statement (sans semicolon) to output to the stdio stream
23885 STREAM commands to declare that the label NAME is an unresolved
23886 Objective-C class reference. This is only needed for targets
23887 whose linkers have special support for NeXT-style runtimes.
23890 File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format
23892 14.19.5 How Initialization Functions Are Handled
23893 ------------------------------------------------
23895 The compiled code for certain languages includes "constructors" (also
23896 called "initialization routines")--functions to initialize data in the
23897 program when the program is started. These functions need to be called
23898 before the program is "started"--that is to say, before `main' is
23901 Compiling some languages generates "destructors" (also called
23902 "termination routines") that should be called when the program
23905 To make the initialization and termination functions work, the compiler
23906 must output something in the assembler code to cause those functions to
23907 be called at the appropriate time. When you port the compiler to a new
23908 system, you need to specify how to do this.
23910 There are two major ways that GCC currently supports the execution of
23911 initialization and termination functions. Each way has two variants.
23912 Much of the structure is common to all four variations.
23914 The linker must build two lists of these functions--a list of
23915 initialization functions, called `__CTOR_LIST__', and a list of
23916 termination functions, called `__DTOR_LIST__'.
23918 Each list always begins with an ignored function pointer (which may
23919 hold 0, -1, or a count of the function pointers after it, depending on
23920 the environment). This is followed by a series of zero or more function
23921 pointers to constructors (or destructors), followed by a function
23922 pointer containing zero.
23924 Depending on the operating system and its executable file format,
23925 either `crtstuff.c' or `libgcc2.c' traverses these lists at startup
23926 time and exit time. Constructors are called in reverse order of the
23927 list; destructors in forward order.
23929 The best way to handle static constructors works only for object file
23930 formats which provide arbitrarily-named sections. A section is set
23931 aside for a list of constructors, and another for a list of destructors.
23932 Traditionally these are called `.ctors' and `.dtors'. Each object file
23933 that defines an initialization function also puts a word in the
23934 constructor section to point to that function. The linker accumulates
23935 all these words into one contiguous `.ctors' section. Termination
23936 functions are handled similarly.
23938 This method will be chosen as the default by `target-def.h' if
23939 `TARGET_ASM_NAMED_SECTION' is defined. A target that does not support
23940 arbitrary sections, but does support special designated constructor and
23941 destructor sections may define `CTORS_SECTION_ASM_OP' and
23942 `DTORS_SECTION_ASM_OP' to achieve the same effect.
23944 When arbitrary sections are available, there are two variants,
23945 depending upon how the code in `crtstuff.c' is called. On systems that
23946 support a ".init" section which is executed at program startup, parts
23947 of `crtstuff.c' are compiled into that section. The program is linked
23948 by the `gcc' driver like this:
23950 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o
23952 The prologue of a function (`__init') appears in the `.init' section
23953 of `crti.o'; the epilogue appears in `crtn.o'. Likewise for the
23954 function `__fini' in the ".fini" section. Normally these files are
23955 provided by the operating system or by the GNU C library, but are
23956 provided by GCC for a few targets.
23958 The objects `crtbegin.o' and `crtend.o' are (for most targets)
23959 compiled from `crtstuff.c'. They contain, among other things, code
23960 fragments within the `.init' and `.fini' sections that branch to
23961 routines in the `.text' section. The linker will pull all parts of a
23962 section together, which results in a complete `__init' function that
23963 invokes the routines we need at startup.
23965 To use this variant, you must define the `INIT_SECTION_ASM_OP' macro
23968 If no init section is available, when GCC compiles any function called
23969 `main' (or more accurately, any function designated as a program entry
23970 point by the language front end calling `expand_main_function'), it
23971 inserts a procedure call to `__main' as the first executable code after
23972 the function prologue. The `__main' function is defined in `libgcc2.c'
23973 and runs the global constructors.
23975 In file formats that don't support arbitrary sections, there are again
23976 two variants. In the simplest variant, the GNU linker (GNU `ld') and
23977 an `a.out' format must be used. In this case, `TARGET_ASM_CONSTRUCTOR'
23978 is defined to produce a `.stabs' entry of type `N_SETT', referencing
23979 the name `__CTOR_LIST__', and with the address of the void function
23980 containing the initialization code as its value. The GNU linker
23981 recognizes this as a request to add the value to a "set"; the values
23982 are accumulated, and are eventually placed in the executable as a
23983 vector in the format described above, with a leading (ignored) count
23984 and a trailing zero element. `TARGET_ASM_DESTRUCTOR' is handled
23985 similarly. Since no init section is available, the absence of
23986 `INIT_SECTION_ASM_OP' causes the compilation of `main' to call `__main'
23987 as above, starting the initialization process.
23989 The last variant uses neither arbitrary sections nor the GNU linker.
23990 This is preferable when you want to do dynamic linking and when using
23991 file formats which the GNU linker does not support, such as `ECOFF'. In
23992 this case, `TARGET_HAVE_CTORS_DTORS' is false, initialization and
23993 termination functions are recognized simply by their names. This
23994 requires an extra program in the linkage step, called `collect2'. This
23995 program pretends to be the linker, for use with GCC; it does its job by
23996 running the ordinary linker, but also arranges to include the vectors of
23997 initialization and termination functions. These functions are called
23998 via `__main' as described above. In order to use this method,
23999 `use_collect2' must be defined in the target in `config.gcc'.
24001 The following section describes the specific macros that control and
24002 customize the handling of initialization and termination functions.
24005 File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format
24007 14.19.6 Macros Controlling Initialization Routines
24008 --------------------------------------------------
24010 Here are the macros that control how the compiler handles initialization
24011 and termination functions:
24013 -- Macro: INIT_SECTION_ASM_OP
24014 If defined, a C string constant, including spacing, for the
24015 assembler operation to identify the following data as
24016 initialization code. If not defined, GCC will assume such a
24017 section does not exist. When you are using special sections for
24018 initialization and termination functions, this macro also controls
24019 how `crtstuff.c' and `libgcc2.c' arrange to run the initialization
24022 -- Macro: HAS_INIT_SECTION
24023 If defined, `main' will not call `__main' as described above.
24024 This macro should be defined for systems that control start-up code
24025 on a symbol-by-symbol basis, such as OSF/1, and should not be
24026 defined explicitly for systems that support `INIT_SECTION_ASM_OP'.
24028 -- Macro: LD_INIT_SWITCH
24029 If defined, a C string constant for a switch that tells the linker
24030 that the following symbol is an initialization routine.
24032 -- Macro: LD_FINI_SWITCH
24033 If defined, a C string constant for a switch that tells the linker
24034 that the following symbol is a finalization routine.
24036 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC)
24037 If defined, a C statement that will write a function that can be
24038 automatically called when a shared library is loaded. The function
24039 should call FUNC, which takes no arguments. If not defined, and
24040 the object format requires an explicit initialization function,
24041 then a function called `_GLOBAL__DI' will be generated.
24043 This function and the following one are used by collect2 when
24044 linking a shared library that needs constructors or destructors,
24045 or has DWARF2 exception tables embedded in the code.
24047 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC)
24048 If defined, a C statement that will write a function that can be
24049 automatically called when a shared library is unloaded. The
24050 function should call FUNC, which takes no arguments. If not
24051 defined, and the object format requires an explicit finalization
24052 function, then a function called `_GLOBAL__DD' will be generated.
24054 -- Macro: INVOKE__main
24055 If defined, `main' will call `__main' despite the presence of
24056 `INIT_SECTION_ASM_OP'. This macro should be defined for systems
24057 where the init section is not actually run automatically, but is
24058 still useful for collecting the lists of constructors and
24061 -- Macro: SUPPORTS_INIT_PRIORITY
24062 If nonzero, the C++ `init_priority' attribute is supported and the
24063 compiler should emit instructions to control the order of
24064 initialization of objects. If zero, the compiler will issue an
24065 error message upon encountering an `init_priority' attribute.
24067 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS
24068 This value is true if the target supports some "native" method of
24069 collecting constructors and destructors to be run at startup and
24070 exit. It is false if we must use `collect2'.
24072 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY)
24073 If defined, a function that outputs assembler code to arrange to
24074 call the function referenced by SYMBOL at initialization time.
24076 Assume that SYMBOL is a `SYMBOL_REF' for a function taking no
24077 arguments and with no return value. If the target supports
24078 initialization priorities, PRIORITY is a value between 0 and
24079 `MAX_INIT_PRIORITY'; otherwise it must be `DEFAULT_INIT_PRIORITY'.
24081 If this macro is not defined by the target, a suitable default will
24082 be chosen if (1) the target supports arbitrary section names, (2)
24083 the target defines `CTORS_SECTION_ASM_OP', or (3) `USE_COLLECT2'
24086 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY)
24087 This is like `TARGET_ASM_CONSTRUCTOR' but used for termination
24088 functions rather than initialization functions.
24090 If `TARGET_HAVE_CTORS_DTORS' is true, the initialization routine
24091 generated for the generated object file will have static linkage.
24093 If your system uses `collect2' as the means of processing
24094 constructors, then that program normally uses `nm' to scan an object
24095 file for constructor functions to be called.
24097 On certain kinds of systems, you can define this macro to make
24098 `collect2' work faster (and, in some cases, make it work at all):
24100 -- Macro: OBJECT_FORMAT_COFF
24101 Define this macro if the system uses COFF (Common Object File
24102 Format) object files, so that `collect2' can assume this format
24103 and scan object files directly for dynamic constructor/destructor
24106 This macro is effective only in a native compiler; `collect2' as
24107 part of a cross compiler always uses `nm' for the target machine.
24109 -- Macro: REAL_NM_FILE_NAME
24110 Define this macro as a C string constant containing the file name
24111 to use to execute `nm'. The default is to search the path
24114 If your system supports shared libraries and has a program to list
24115 the dynamic dependencies of a given library or executable, you can
24116 define these macros to enable support for running initialization
24117 and termination functions in shared libraries:
24119 -- Macro: LDD_SUFFIX
24120 Define this macro to a C string constant containing the name of
24121 the program which lists dynamic dependencies, like `"ldd"' under
24124 -- Macro: PARSE_LDD_OUTPUT (PTR)
24125 Define this macro to be C code that extracts filenames from the
24126 output of the program denoted by `LDD_SUFFIX'. PTR is a variable
24127 of type `char *' that points to the beginning of a line of output
24128 from `LDD_SUFFIX'. If the line lists a dynamic dependency, the
24129 code must advance PTR to the beginning of the filename on that
24130 line. Otherwise, it must set PTR to `NULL'.
24133 File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format
24135 14.19.7 Output of Assembler Instructions
24136 ----------------------------------------
24138 This describes assembler instruction output.
24140 -- Macro: REGISTER_NAMES
24141 A C initializer containing the assembler's names for the machine
24142 registers, each one as a C string constant. This is what
24143 translates register numbers in the compiler into assembler
24146 -- Macro: ADDITIONAL_REGISTER_NAMES
24147 If defined, a C initializer for an array of structures containing
24148 a name and a register number. This macro defines additional names
24149 for hard registers, thus allowing the `asm' option in declarations
24150 to refer to registers using alternate names.
24152 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR)
24153 Define this macro if you are using an unusual assembler that
24154 requires different names for the machine instructions.
24156 The definition is a C statement or statements which output an
24157 assembler instruction opcode to the stdio stream STREAM. The
24158 macro-operand PTR is a variable of type `char *' which points to
24159 the opcode name in its "internal" form--the form that is written
24160 in the machine description. The definition should output the
24161 opcode name to STREAM, performing any translation you desire, and
24162 increment the variable PTR to point at the end of the opcode so
24163 that it will not be output twice.
24165 In fact, your macro definition may process less than the entire
24166 opcode name, or more than the opcode name; but if you want to
24167 process text that includes `%'-sequences to substitute operands,
24168 you must take care of the substitution yourself. Just be sure to
24169 increment PTR over whatever text should not be output normally.
24171 If you need to look at the operand values, they can be found as the
24172 elements of `recog_data.operand'.
24174 If the macro definition does nothing, the instruction is output in
24177 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS)
24178 If defined, a C statement to be executed just prior to the output
24179 of assembler code for INSN, to modify the extracted operands so
24180 they will be output differently.
24182 Here the argument OPVEC is the vector containing the operands
24183 extracted from INSN, and NOPERANDS is the number of elements of
24184 the vector which contain meaningful data for this insn. The
24185 contents of this vector are what will be used to convert the insn
24186 template into assembler code, so you can change the assembler
24187 output by changing the contents of the vector.
24189 This macro is useful when various assembler syntaxes share a single
24190 file of instruction patterns; by defining this macro differently,
24191 you can cause a large class of instructions to be output
24192 differently (such as with rearranged operands). Naturally,
24193 variations in assembler syntax affecting individual insn patterns
24194 ought to be handled by writing conditional output routines in
24197 If this macro is not defined, it is equivalent to a null statement.
24199 -- Macro: PRINT_OPERAND (STREAM, X, CODE)
24200 A C compound statement to output to stdio stream STREAM the
24201 assembler syntax for an instruction operand X. X is an RTL
24204 CODE is a value that can be used to specify one of several ways of
24205 printing the operand. It is used when identical operands must be
24206 printed differently depending on the context. CODE comes from the
24207 `%' specification that was used to request printing of the
24208 operand. If the specification was just `%DIGIT' then CODE is 0;
24209 if the specification was `%LTR DIGIT' then CODE is the ASCII code
24212 If X is a register, this macro should print the register's name.
24213 The names can be found in an array `reg_names' whose type is `char
24214 *[]'. `reg_names' is initialized from `REGISTER_NAMES'.
24216 When the machine description has a specification `%PUNCT' (a `%'
24217 followed by a punctuation character), this macro is called with a
24218 null pointer for X and the punctuation character for CODE.
24220 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE)
24221 A C expression which evaluates to true if CODE is a valid
24222 punctuation character for use in the `PRINT_OPERAND' macro. If
24223 `PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no
24224 punctuation characters (except for the standard one, `%') are used
24227 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X)
24228 A C compound statement to output to stdio stream STREAM the
24229 assembler syntax for an instruction operand that is a memory
24230 reference whose address is X. X is an RTL expression.
24232 On some machines, the syntax for a symbolic address depends on the
24233 section that the address refers to. On these machines, define the
24234 hook `TARGET_ENCODE_SECTION_INFO' to store the information into the
24235 `symbol_ref', and then check for it here. *Note Assembler
24238 -- Macro: DBR_OUTPUT_SEQEND (FILE)
24239 A C statement, to be executed after all slot-filler instructions
24240 have been output. If necessary, call `dbr_sequence_length' to
24241 determine the number of slots filled in a sequence (zero if not
24242 currently outputting a sequence), to decide how many no-ops to
24243 output, or whatever.
24245 Don't define this macro if it has nothing to do, but it is helpful
24246 in reading assembly output if the extent of the delay sequence is
24247 made explicit (e.g. with white space).
24249 Note that output routines for instructions with delay slots must be
24250 prepared to deal with not being output as part of a sequence (i.e. when
24251 the scheduling pass is not run, or when no slot fillers could be
24252 found.) The variable `final_sequence' is null when not processing a
24253 sequence, otherwise it contains the `sequence' rtx being output.
24255 -- Macro: REGISTER_PREFIX
24256 -- Macro: LOCAL_LABEL_PREFIX
24257 -- Macro: USER_LABEL_PREFIX
24258 -- Macro: IMMEDIATE_PREFIX
24259 If defined, C string expressions to be used for the `%R', `%L',
24260 `%U', and `%I' options of `asm_fprintf' (see `final.c'). These
24261 are useful when a single `md' file must support multiple assembler
24262 formats. In that case, the various `tm.h' files can define these
24263 macros differently.
24265 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT)
24266 If defined this macro should expand to a series of `case'
24267 statements which will be parsed inside the `switch' statement of
24268 the `asm_fprintf' function. This allows targets to define extra
24269 printf formats which may useful when generating their assembler
24270 statements. Note that uppercase letters are reserved for future
24271 generic extensions to asm_fprintf, and so are not available to
24272 target specific code. The output file is given by the parameter
24273 FILE. The varargs input pointer is ARGPTR and the rest of the
24274 format string, starting the character after the one that is being
24275 switched upon, is pointed to by FORMAT.
24277 -- Macro: ASSEMBLER_DIALECT
24278 If your target supports multiple dialects of assembler language
24279 (such as different opcodes), define this macro as a C expression
24280 that gives the numeric index of the assembler language dialect to
24281 use, with zero as the first variant.
24283 If this macro is defined, you may use constructs of the form
24284 `{option0|option1|option2...}'
24285 in the output templates of patterns (*note Output Template::) or
24286 in the first argument of `asm_fprintf'. This construct outputs
24287 `option0', `option1', `option2', etc., if the value of
24288 `ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters
24289 within these strings retain their usual meaning. If there are
24290 fewer alternatives within the braces than the value of
24291 `ASSEMBLER_DIALECT', the construct outputs nothing.
24293 If you do not define this macro, the characters `{', `|' and `}'
24294 do not have any special meaning when used in templates or operands
24297 Define the macros `REGISTER_PREFIX', `LOCAL_LABEL_PREFIX',
24298 `USER_LABEL_PREFIX' and `IMMEDIATE_PREFIX' if you can express the
24299 variations in assembler language syntax with that mechanism.
24300 Define `ASSEMBLER_DIALECT' and use the `{option0|option1}' syntax
24301 if the syntax variant are larger and involve such things as
24302 different opcodes or operand order.
24304 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO)
24305 A C expression to output to STREAM some assembler code which will
24306 push hard register number REGNO onto the stack. The code need not
24307 be optimal, since this macro is used only when profiling.
24309 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO)
24310 A C expression to output to STREAM some assembler code which will
24311 pop hard register number REGNO off of the stack. The code need
24312 not be optimal, since this macro is used only when profiling.
24315 File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format
24317 14.19.8 Output of Dispatch Tables
24318 ---------------------------------
24320 This concerns dispatch tables.
24322 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL)
24323 A C statement to output to the stdio stream STREAM an assembler
24324 pseudo-instruction to generate a difference between two labels.
24325 VALUE and REL are the numbers of two internal labels. The
24326 definitions of these labels are output using
24327 `(*targetm.asm_out.internal_label)', and they must be printed in
24328 the same way here. For example,
24330 fprintf (STREAM, "\t.word L%d-L%d\n",
24333 You must provide this macro on machines where the addresses in a
24334 dispatch table are relative to the table's own address. If
24335 defined, GCC will also use this macro on all machines when
24336 producing PIC. BODY is the body of the `ADDR_DIFF_VEC'; it is
24337 provided so that the mode and flags can be read.
24339 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE)
24340 This macro should be provided on machines where the addresses in a
24341 dispatch table are absolute.
24343 The definition should be a C statement to output to the stdio
24344 stream STREAM an assembler pseudo-instruction to generate a
24345 reference to a label. VALUE is the number of an internal label
24346 whose definition is output using
24347 `(*targetm.asm_out.internal_label)'. For example,
24349 fprintf (STREAM, "\t.word L%d\n", VALUE)
24351 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE)
24352 Define this if the label before a jump-table needs to be output
24353 specially. The first three arguments are the same as for
24354 `(*targetm.asm_out.internal_label)'; the fourth argument is the
24355 jump-table which follows (a `jump_insn' containing an `addr_vec'
24356 or `addr_diff_vec').
24358 This feature is used on system V to output a `swbeg' statement for
24361 If this macro is not defined, these labels are output with
24362 `(*targetm.asm_out.internal_label)'.
24364 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE)
24365 Define this if something special must be output at the end of a
24366 jump-table. The definition should be a C statement to be executed
24367 after the assembler code for the table is written. It should write
24368 the appropriate code to stdio stream STREAM. The argument TABLE
24369 is the jump-table insn, and NUM is the label-number of the
24372 If this macro is not defined, nothing special is output at the end
24375 -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (STREAM, DECL,
24377 This target hook emits a label at the beginning of each FDE. It
24378 should be defined on targets where FDEs need special labels, and it
24379 should write the appropriate label, for the FDE associated with the
24380 function declaration DECL, to the stdio stream STREAM. The third
24381 argument, FOR_EH, is a boolean: true if this is for an exception
24382 table. The fourth argument, EMPTY, is a boolean: true if this is
24383 a placeholder label for an omitted FDE.
24385 The default is that FDEs are not given nonlocal labels.
24387 -- Taget Hook: void TARGET_UNWIND_EMIT (FILE * STREAM, rtx INSN)
24388 This target hook emits and assembly directives required to unwind
24389 the given instruction. This is only used when TARGET_UNWIND_INFO
24393 File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format
24395 14.19.9 Assembler Commands for Exception Regions
24396 ------------------------------------------------
24398 This describes commands marking the start and the end of an exception
24401 -- Macro: EH_FRAME_SECTION_NAME
24402 If defined, a C string constant for the name of the section
24403 containing exception handling frame unwind information. If not
24404 defined, GCC will provide a default definition if the target
24405 supports named sections. `crtstuff.c' uses this macro to switch
24406 to the appropriate section.
24408 You should define this symbol if your target supports DWARF 2 frame
24409 unwind information and the default definition does not work.
24411 -- Macro: EH_FRAME_IN_DATA_SECTION
24412 If defined, DWARF 2 frame unwind information will be placed in the
24413 data section even though the target supports named sections. This
24414 might be necessary, for instance, if the system linker does garbage
24415 collection and sections cannot be marked as not to be collected.
24417 Do not define this macro unless `TARGET_ASM_NAMED_SECTION' is also
24420 -- Macro: EH_TABLES_CAN_BE_READ_ONLY
24421 Define this macro to 1 if your target is such that no frame unwind
24422 information encoding used with non-PIC code will ever require a
24423 runtime relocation, but the linker may not support merging
24424 read-only and read-write sections into a single read-write section.
24426 -- Macro: MASK_RETURN_ADDR
24427 An rtx used to mask the return address found via
24428 `RETURN_ADDR_RTX', so that it does not contain any extraneous set
24431 -- Macro: DWARF2_UNWIND_INFO
24432 Define this macro to 0 if your target supports DWARF 2 frame unwind
24433 information, but it does not yet work with exception handling.
24434 Otherwise, if your target supports this information (if it defines
24435 `INCOMING_RETURN_ADDR_RTX' and either `UNALIGNED_INT_ASM_OP' or
24436 `OBJECT_FORMAT_ELF'), GCC will provide a default definition of 1.
24438 If `TARGET_UNWIND_INFO' is defined, the target specific unwinder
24439 will be used in all cases. Defining this macro will enable the
24440 generation of DWARF 2 frame debugging information.
24442 If `TARGET_UNWIND_INFO' is not defined, and this macro is defined
24443 to 1, the DWARF 2 unwinder will be the default exception handling
24444 mechanism; otherwise, `setjmp'/`longjmp' will be used by default.
24446 -- Macro: TARGET_UNWIND_INFO
24447 Define this macro if your target has ABI specified unwind tables.
24448 Usually these will be output by `TARGET_UNWIND_EMIT'.
24450 -- Variable: Target Hook bool TARGET_UNWID_TABLES_DEFAULT
24451 This variable should be set to `true' if the target ABI requires
24452 unwinding tables even when exceptions are not used.
24454 -- Macro: MUST_USE_SJLJ_EXCEPTIONS
24455 This macro need only be defined if `DWARF2_UNWIND_INFO' is
24456 runtime-variable. In that case, `except.h' cannot correctly
24457 determine the corresponding definition of
24458 `MUST_USE_SJLJ_EXCEPTIONS', so the target must provide it directly.
24460 -- Macro: DWARF_CIE_DATA_ALIGNMENT
24461 This macro need only be defined if the target might save registers
24462 in the function prologue at an offset to the stack pointer that is
24463 not aligned to `UNITS_PER_WORD'. The definition should be the
24464 negative minimum alignment if `STACK_GROWS_DOWNWARD' is defined,
24465 and the positive minimum alignment otherwise. *Note SDB and
24466 DWARF::. Only applicable if the target supports DWARF 2 frame
24467 unwind information.
24469 -- Target Hook: void TARGET_ASM_EXCEPTION_SECTION ()
24470 If defined, a function that switches to the section in which the
24471 main exception table is to be placed (*note Sections::). The
24472 default is a function that switches to a section named
24473 `.gcc_except_table' on machines that support named sections via
24474 `TARGET_ASM_NAMED_SECTION', otherwise if `-fpic' or `-fPIC' is in
24475 effect, the `data_section', otherwise the `readonly_data_section'.
24477 -- Target Hook: void TARGET_ASM_EH_FRAME_SECTION ()
24478 If defined, a function that switches to the section in which the
24479 DWARF 2 frame unwind information to be placed (*note Sections::).
24480 The default is a function that outputs a standard GAS section
24481 directive, if `EH_FRAME_SECTION_NAME' is defined, or else a data
24482 section directive followed by a synthetic label.
24484 -- Variable: Target Hook bool TARGET_TERMINATE_DW2_EH_FRAME_INFO
24485 Contains the value true if the target should add a zero word onto
24486 the end of a Dwarf-2 frame info section when used for exception
24487 handling. Default value is false if `EH_FRAME_SECTION_NAME' is
24488 defined, and true otherwise.
24490 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG)
24491 Given a register, this hook should return a parallel of registers
24492 to represent where to find the register pieces. Define this hook
24493 if the register and its mode are represented in Dwarf in
24494 non-contiguous locations, or if the register should be represented
24495 in more than one register in Dwarf. Otherwise, this hook should
24496 return `NULL_RTX'. If not defined, the default is to return
24499 -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM)
24500 This hook is used to output a reference from a frame unwinding
24501 table to the type_info object identified by SYM. It should return
24502 `true' if the reference was output. Returning `false' will cause
24503 the reference to be output using the normal Dwarf2 routines.
24505 -- Target Hook: bool TARGET_ARM_EABI_UNWINDER
24506 This hook should be set to `true' on targets that use an ARM EABI
24507 based unwinding library, and `false' on other targets. This
24508 effects the format of unwinding tables, and how the unwinder in
24509 entered after running a cleanup. The default is `false'.
24512 File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format
24514 14.19.10 Assembler Commands for Alignment
24515 -----------------------------------------
24517 This describes commands for alignment.
24519 -- Macro: JUMP_ALIGN (LABEL)
24520 The alignment (log base 2) to put in front of LABEL, which is a
24521 common destination of jumps and has no fallthru incoming edge.
24523 This macro need not be defined if you don't want any special
24524 alignment to be done at such a time. Most machine descriptions do
24525 not currently define the macro.
24527 Unless it's necessary to inspect the LABEL parameter, it is better
24528 to set the variable ALIGN_JUMPS in the target's
24529 `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's
24530 selection in ALIGN_JUMPS in a `JUMP_ALIGN' implementation.
24532 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL)
24533 The alignment (log base 2) to put in front of LABEL, which follows
24536 This macro need not be defined if you don't want any special
24537 alignment to be done at such a time. Most machine descriptions do
24538 not currently define the macro.
24540 -- Macro: LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP
24541 The maximum number of bytes to skip when applying
24542 `LABEL_ALIGN_AFTER_BARRIER'. This works only if
24543 `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined.
24545 -- Macro: LOOP_ALIGN (LABEL)
24546 The alignment (log base 2) to put in front of LABEL, which follows
24547 a `NOTE_INSN_LOOP_BEG' note.
24549 This macro need not be defined if you don't want any special
24550 alignment to be done at such a time. Most machine descriptions do
24551 not currently define the macro.
24553 Unless it's necessary to inspect the LABEL parameter, it is better
24554 to set the variable `align_loops' in the target's
24555 `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's
24556 selection in `align_loops' in a `LOOP_ALIGN' implementation.
24558 -- Macro: LOOP_ALIGN_MAX_SKIP
24559 The maximum number of bytes to skip when applying `LOOP_ALIGN'.
24560 This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined.
24562 -- Macro: LABEL_ALIGN (LABEL)
24563 The alignment (log base 2) to put in front of LABEL. If
24564 `LABEL_ALIGN_AFTER_BARRIER' / `LOOP_ALIGN' specify a different
24565 alignment, the maximum of the specified values is used.
24567 Unless it's necessary to inspect the LABEL parameter, it is better
24568 to set the variable `align_labels' in the target's
24569 `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's
24570 selection in `align_labels' in a `LABEL_ALIGN' implementation.
24572 -- Macro: LABEL_ALIGN_MAX_SKIP
24573 The maximum number of bytes to skip when applying `LABEL_ALIGN'.
24574 This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined.
24576 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES)
24577 A C statement to output to the stdio stream STREAM an assembler
24578 instruction to advance the location counter by NBYTES bytes.
24579 Those bytes should be zero when loaded. NBYTES will be a C
24580 expression of type `int'.
24582 -- Macro: ASM_NO_SKIP_IN_TEXT
24583 Define this macro if `ASM_OUTPUT_SKIP' should not be used in the
24584 text section because it fails to put zeros in the bytes that are
24585 skipped. This is true on many Unix systems, where the pseudo-op
24586 to skip bytes produces no-op instructions rather than zeros when
24587 used in the text section.
24589 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER)
24590 A C statement to output to the stdio stream STREAM an assembler
24591 command to advance the location counter to a multiple of 2 to the
24592 POWER bytes. POWER will be a C expression of type `int'.
24594 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER)
24595 Like `ASM_OUTPUT_ALIGN', except that the "nop" instruction is used
24596 for padding, if necessary.
24598 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP)
24599 A C statement to output to the stdio stream STREAM an assembler
24600 command to advance the location counter to a multiple of 2 to the
24601 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to
24602 satisfy the alignment request. POWER and MAX_SKIP will be a C
24603 expression of type `int'.
24606 File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros
24608 14.20 Controlling Debugging Information Format
24609 ==============================================
24611 This describes how to specify debugging information.
24615 * All Debuggers:: Macros that affect all debugging formats uniformly.
24616 * DBX Options:: Macros enabling specific options in DBX format.
24617 * DBX Hooks:: Hook macros for varying DBX format.
24618 * File Names and DBX:: Macros controlling output of file names in DBX format.
24619 * SDB and DWARF:: Macros for SDB (COFF) and DWARF formats.
24620 * VMS Debug:: Macros for VMS debug format.
24623 File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info
24625 14.20.1 Macros Affecting All Debugging Formats
24626 ----------------------------------------------
24628 These macros affect all debugging formats.
24630 -- Macro: DBX_REGISTER_NUMBER (REGNO)
24631 A C expression that returns the DBX register number for the
24632 compiler register number REGNO. In the default macro provided,
24633 the value of this expression will be REGNO itself. But sometimes
24634 there are some registers that the compiler knows about and DBX
24635 does not, or vice versa. In such cases, some register may need to
24636 have one number in the compiler and another for DBX.
24638 If two registers have consecutive numbers inside GCC, and they can
24639 be used as a pair to hold a multiword value, then they _must_ have
24640 consecutive numbers after renumbering with `DBX_REGISTER_NUMBER'.
24641 Otherwise, debuggers will be unable to access such a pair, because
24642 they expect register pairs to be consecutive in their own
24645 If you find yourself defining `DBX_REGISTER_NUMBER' in way that
24646 does not preserve register pairs, then what you must do instead is
24647 redefine the actual register numbering scheme.
24649 -- Macro: DEBUGGER_AUTO_OFFSET (X)
24650 A C expression that returns the integer offset value for an
24651 automatic variable having address X (an RTL expression). The
24652 default computation assumes that X is based on the frame-pointer
24653 and gives the offset from the frame-pointer. This is required for
24654 targets that produce debugging output for DBX or COFF-style
24655 debugging output for SDB and allow the frame-pointer to be
24656 eliminated when the `-g' options is used.
24658 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X)
24659 A C expression that returns the integer offset value for an
24660 argument having address X (an RTL expression). The nominal offset
24663 -- Macro: PREFERRED_DEBUGGING_TYPE
24664 A C expression that returns the type of debugging output GCC should
24665 produce when the user specifies just `-g'. Define this if you
24666 have arranged for GCC to support more than one format of debugging
24667 output. Currently, the allowable values are `DBX_DEBUG',
24668 `SDB_DEBUG', `DWARF_DEBUG', `DWARF2_DEBUG', `XCOFF_DEBUG',
24669 `VMS_DEBUG', and `VMS_AND_DWARF2_DEBUG'.
24671 When the user specifies `-ggdb', GCC normally also uses the value
24672 of this macro to select the debugging output format, but with two
24673 exceptions. If `DWARF2_DEBUGGING_INFO' is defined, GCC uses the
24674 value `DWARF2_DEBUG'. Otherwise, if `DBX_DEBUGGING_INFO' is
24675 defined, GCC uses `DBX_DEBUG'.
24677 The value of this macro only affects the default debugging output;
24678 the user can always get a specific type of output by using
24679 `-gstabs', `-gcoff', `-gdwarf-2', `-gxcoff', or `-gvms'.
24682 File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info
24684 14.20.2 Specific Options for DBX Output
24685 ---------------------------------------
24687 These are specific options for DBX output.
24689 -- Macro: DBX_DEBUGGING_INFO
24690 Define this macro if GCC should produce debugging output for DBX
24691 in response to the `-g' option.
24693 -- Macro: XCOFF_DEBUGGING_INFO
24694 Define this macro if GCC should produce XCOFF format debugging
24695 output in response to the `-g' option. This is a variant of DBX
24698 -- Macro: DEFAULT_GDB_EXTENSIONS
24699 Define this macro to control whether GCC should by default generate
24700 GDB's extended version of DBX debugging information (assuming
24701 DBX-format debugging information is enabled at all). If you don't
24702 define the macro, the default is 1: always generate the extended
24703 information if there is any occasion to.
24705 -- Macro: DEBUG_SYMS_TEXT
24706 Define this macro if all `.stabs' commands should be output while
24707 in the text section.
24709 -- Macro: ASM_STABS_OP
24710 A C string constant, including spacing, naming the assembler
24711 pseudo op to use instead of `"\t.stabs\t"' to define an ordinary
24712 debugging symbol. If you don't define this macro, `"\t.stabs\t"'
24713 is used. This macro applies only to DBX debugging information
24716 -- Macro: ASM_STABD_OP
24717 A C string constant, including spacing, naming the assembler
24718 pseudo op to use instead of `"\t.stabd\t"' to define a debugging
24719 symbol whose value is the current location. If you don't define
24720 this macro, `"\t.stabd\t"' is used. This macro applies only to
24721 DBX debugging information format.
24723 -- Macro: ASM_STABN_OP
24724 A C string constant, including spacing, naming the assembler
24725 pseudo op to use instead of `"\t.stabn\t"' to define a debugging
24726 symbol with no name. If you don't define this macro,
24727 `"\t.stabn\t"' is used. This macro applies only to DBX debugging
24728 information format.
24730 -- Macro: DBX_NO_XREFS
24731 Define this macro if DBX on your system does not support the
24732 construct `xsTAGNAME'. On some systems, this construct is used to
24733 describe a forward reference to a structure named TAGNAME. On
24734 other systems, this construct is not supported at all.
24736 -- Macro: DBX_CONTIN_LENGTH
24737 A symbol name in DBX-format debugging information is normally
24738 continued (split into two separate `.stabs' directives) when it
24739 exceeds a certain length (by default, 80 characters). On some
24740 operating systems, DBX requires this splitting; on others,
24741 splitting must not be done. You can inhibit splitting by defining
24742 this macro with the value zero. You can override the default
24743 splitting-length by defining this macro as an expression for the
24746 -- Macro: DBX_CONTIN_CHAR
24747 Normally continuation is indicated by adding a `\' character to
24748 the end of a `.stabs' string when a continuation follows. To use
24749 a different character instead, define this macro as a character
24750 constant for the character you want to use. Do not define this
24751 macro if backslash is correct for your system.
24753 -- Macro: DBX_STATIC_STAB_DATA_SECTION
24754 Define this macro if it is necessary to go to the data section
24755 before outputting the `.stabs' pseudo-op for a non-global static
24758 -- Macro: DBX_TYPE_DECL_STABS_CODE
24759 The value to use in the "code" field of the `.stabs' directive for
24760 a typedef. The default is `N_LSYM'.
24762 -- Macro: DBX_STATIC_CONST_VAR_CODE
24763 The value to use in the "code" field of the `.stabs' directive for
24764 a static variable located in the text section. DBX format does not
24765 provide any "right" way to do this. The default is `N_FUN'.
24767 -- Macro: DBX_REGPARM_STABS_CODE
24768 The value to use in the "code" field of the `.stabs' directive for
24769 a parameter passed in registers. DBX format does not provide any
24770 "right" way to do this. The default is `N_RSYM'.
24772 -- Macro: DBX_REGPARM_STABS_LETTER
24773 The letter to use in DBX symbol data to identify a symbol as a
24774 parameter passed in registers. DBX format does not customarily
24775 provide any way to do this. The default is `'P''.
24777 -- Macro: DBX_FUNCTION_FIRST
24778 Define this macro if the DBX information for a function and its
24779 arguments should precede the assembler code for the function.
24780 Normally, in DBX format, the debugging information entirely
24781 follows the assembler code.
24783 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE
24784 Define this macro, with value 1, if the value of a symbol
24785 describing the scope of a block (`N_LBRAC' or `N_RBRAC') should be
24786 relative to the start of the enclosing function. Normally, GCC
24787 uses an absolute address.
24789 -- Macro: DBX_LINES_FUNCTION_RELATIVE
24790 Define this macro, with value 1, if the value of a symbol
24791 indicating the current line number (`N_SLINE') should be relative
24792 to the start of the enclosing function. Normally, GCC uses an
24795 -- Macro: DBX_USE_BINCL
24796 Define this macro if GCC should generate `N_BINCL' and `N_EINCL'
24797 stabs for included header files, as on Sun systems. This macro
24798 also directs GCC to output a type number as a pair of a file
24799 number and a type number within the file. Normally, GCC does not
24800 generate `N_BINCL' or `N_EINCL' stabs, and it outputs a single
24801 number for a type number.
24804 File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info
24806 14.20.3 Open-Ended Hooks for DBX Format
24807 ---------------------------------------
24809 These are hooks for DBX format.
24811 -- Macro: DBX_OUTPUT_LBRAC (STREAM, NAME)
24812 Define this macro to say how to output to STREAM the debugging
24813 information for the start of a scope level for variable names. The
24814 argument NAME is the name of an assembler symbol (for use with
24815 `assemble_name') whose value is the address where the scope begins.
24817 -- Macro: DBX_OUTPUT_RBRAC (STREAM, NAME)
24818 Like `DBX_OUTPUT_LBRAC', but for the end of a scope level.
24820 -- Macro: DBX_OUTPUT_NFUN (STREAM, LSCOPE_LABEL, DECL)
24821 Define this macro if the target machine requires special handling
24822 to output an `N_FUN' entry for the function DECL.
24824 -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER)
24825 A C statement to output DBX debugging information before code for
24826 line number LINE of the current source file to the stdio stream
24827 STREAM. COUNTER is the number of time the macro was invoked,
24828 including the current invocation; it is intended to generate
24829 unique labels in the assembly output.
24831 This macro should not be defined if the default output is correct,
24832 or if it can be made correct by defining
24833 `DBX_LINES_FUNCTION_RELATIVE'.
24835 -- Macro: NO_DBX_FUNCTION_END
24836 Some stabs encapsulation formats (in particular ECOFF), cannot
24837 handle the `.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx
24838 extension construct. On those machines, define this macro to turn
24839 this feature off without disturbing the rest of the gdb extensions.
24841 -- Macro: NO_DBX_BNSYM_ENSYM
24842 Some assemblers cannot handle the `.stabd BNSYM/ENSYM,0,0' gdb dbx
24843 extension construct. On those machines, define this macro to turn
24844 this feature off without disturbing the rest of the gdb extensions.
24847 File: gccint.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info
24849 14.20.4 File Names in DBX Format
24850 --------------------------------
24852 This describes file names in DBX format.
24854 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME)
24855 A C statement to output DBX debugging information to the stdio
24856 stream STREAM, which indicates that file NAME is the main source
24857 file--the file specified as the input file for compilation. This
24858 macro is called only once, at the beginning of compilation.
24860 This macro need not be defined if the standard form of output for
24861 DBX debugging information is appropriate.
24863 It may be necessary to refer to a label equal to the beginning of
24864 the text section. You can use `assemble_name (stream,
24865 ltext_label_name)' to do so. If you do this, you must also set
24866 the variable USED_LTEXT_LABEL_NAME to `true'.
24868 -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY
24869 Define this macro, with value 1, if GCC should not emit an
24870 indication of the current directory for compilation and current
24871 source language at the beginning of the file.
24873 -- Macro: NO_DBX_GCC_MARKER
24874 Define this macro, with value 1, if GCC should not emit an
24875 indication that this object file was compiled by GCC. The default
24876 is to emit an `N_OPT' stab at the beginning of every source file,
24877 with `gcc2_compiled.' for the string and value 0.
24879 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME)
24880 A C statement to output DBX debugging information at the end of
24881 compilation of the main source file NAME. Output should be
24882 written to the stdio stream STREAM.
24884 If you don't define this macro, nothing special is output at the
24885 end of compilation, which is correct for most machines.
24887 -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END
24888 Define this macro _instead of_ defining
24889 `DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at
24890 the end of compilation is a `N_SO' stab with an empty string,
24891 whose value is the highest absolute text address in the file.
24894 File: gccint.info, Node: SDB and DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info
24896 14.20.5 Macros for SDB and DWARF Output
24897 ---------------------------------------
24899 Here are macros for SDB and DWARF output.
24901 -- Macro: SDB_DEBUGGING_INFO
24902 Define this macro if GCC should produce COFF-style debugging output
24903 for SDB in response to the `-g' option.
24905 -- Macro: DWARF2_DEBUGGING_INFO
24906 Define this macro if GCC should produce dwarf version 2 format
24907 debugging output in response to the `-g' option.
24909 -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (tree
24911 Define this to enable the dwarf attribute
24912 `DW_AT_calling_convention' to be emitted for each function.
24913 Instead of an integer return the enum value for the `DW_CC_'
24916 To support optional call frame debugging information, you must also
24917 define `INCOMING_RETURN_ADDR_RTX' and either set
24918 `RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the
24919 prologue, or call `dwarf2out_def_cfa' and `dwarf2out_reg_save' as
24920 appropriate from `TARGET_ASM_FUNCTION_PROLOGUE' if you don't.
24922 -- Macro: DWARF2_FRAME_INFO
24923 Define this macro to a nonzero value if GCC should always output
24924 Dwarf 2 frame information. If `DWARF2_UNWIND_INFO' (*note
24925 Exception Region Output:: is nonzero, GCC will output this
24926 information not matter how you define `DWARF2_FRAME_INFO'.
24928 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO
24929 Define this macro to be a nonzero value if the assembler can
24930 generate Dwarf 2 line debug info sections. This will result in
24931 much more compact line number tables, and hence is desirable if it
24934 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2)
24935 A C statement to issue assembly directives that create a difference
24936 between the two given labels, using an integer of the given size.
24938 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL)
24939 A C statement to issue assembly directives that create a
24940 section-relative reference to the given label, using an integer of
24943 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL)
24944 A C statement to issue assembly directives that create a
24945 self-relative reference to the given label, using an integer of
24948 -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int
24950 If defined, this target hook is a function which outputs a
24951 DTP-relative reference to the given TLS symbol of the specified
24954 -- Macro: PUT_SDB_...
24955 Define these macros to override the assembler syntax for the
24956 special SDB assembler directives. See `sdbout.c' for a list of
24957 these macros and their arguments. If the standard syntax is used,
24958 you need not define them yourself.
24960 -- Macro: SDB_DELIM
24961 Some assemblers do not support a semicolon as a delimiter, even
24962 between SDB assembler directives. In that case, define this macro
24963 to be the delimiter to use (usually `\n'). It is not necessary to
24964 define a new set of `PUT_SDB_OP' macros if this is the only change
24967 -- Macro: SDB_ALLOW_UNKNOWN_REFERENCES
24968 Define this macro to allow references to unknown structure, union,
24969 or enumeration tags to be emitted. Standard COFF does not allow
24970 handling of unknown references, MIPS ECOFF has support for it.
24972 -- Macro: SDB_ALLOW_FORWARD_REFERENCES
24973 Define this macro to allow references to structure, union, or
24974 enumeration tags that have not yet been seen to be handled. Some
24975 assemblers choke if forward tags are used, while some require it.
24977 -- Macro: SDB_OUTPUT_SOURCE_LINE (STREAM, LINE)
24978 A C statement to output SDB debugging information before code for
24979 line number LINE of the current source file to the stdio stream
24980 STREAM. The default is to emit an `.ln' directive.
24983 File: gccint.info, Node: VMS Debug, Prev: SDB and DWARF, Up: Debugging Info
24985 14.20.6 Macros for VMS Debug Format
24986 -----------------------------------
24988 Here are macros for VMS debug format.
24990 -- Macro: VMS_DEBUGGING_INFO
24991 Define this macro if GCC should produce debugging output for VMS
24992 in response to the `-g' option. The default behavior for VMS is
24993 to generate minimal debug info for a traceback in the absence of
24994 `-g' unless explicitly overridden with `-g0'. This behavior is
24995 controlled by `OPTIMIZATION_OPTIONS' and `OVERRIDE_OPTIONS'.
24998 File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros
25000 14.21 Cross Compilation and Floating Point
25001 ==========================================
25003 While all modern machines use twos-complement representation for
25004 integers, there are a variety of representations for floating point
25005 numbers. This means that in a cross-compiler the representation of
25006 floating point numbers in the compiled program may be different from
25007 that used in the machine doing the compilation.
25009 Because different representation systems may offer different amounts of
25010 range and precision, all floating point constants must be represented in
25011 the target machine's format. Therefore, the cross compiler cannot
25012 safely use the host machine's floating point arithmetic; it must emulate
25013 the target's arithmetic. To ensure consistency, GCC always uses
25014 emulation to work with floating point values, even when the host and
25015 target floating point formats are identical.
25017 The following macros are provided by `real.h' for the compiler to use.
25018 All parts of the compiler which generate or optimize floating-point
25019 calculations must use these macros. They may evaluate their operands
25020 more than once, so operands must not have side effects.
25022 -- Macro: REAL_VALUE_TYPE
25023 The C data type to be used to hold a floating point value in the
25024 target machine's format. Typically this is a `struct' containing
25025 an array of `HOST_WIDE_INT', but all code should treat it as an
25028 -- Macro: int REAL_VALUES_EQUAL (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
25029 Compares for equality the two values, X and Y. If the target
25030 floating point format supports negative zeroes and/or NaNs,
25031 `REAL_VALUES_EQUAL (-0.0, 0.0)' is true, and `REAL_VALUES_EQUAL
25032 (NaN, NaN)' is false.
25034 -- Macro: int REAL_VALUES_LESS (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
25035 Tests whether X is less than Y.
25037 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X)
25038 Truncates X to a signed integer, rounding toward zero.
25040 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX
25041 (REAL_VALUE_TYPE X)
25042 Truncates X to an unsigned integer, rounding toward zero. If X is
25043 negative, returns zero.
25045 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, enum
25047 Converts STRING into a floating point number in the target
25048 machine's representation for mode MODE. This routine can handle
25049 both decimal and hexadecimal floating point constants, using the
25050 syntax defined by the C language for both.
25052 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X)
25053 Returns 1 if X is negative (including negative zero), 0 otherwise.
25055 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X)
25056 Determines whether X represents infinity (positive or negative).
25058 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X)
25059 Determines whether X represents a "NaN" (not-a-number).
25061 -- Macro: void REAL_ARITHMETIC (REAL_VALUE_TYPE OUTPUT, enum tree_code
25062 CODE, REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
25063 Calculates an arithmetic operation on the two floating point values
25064 X and Y, storing the result in OUTPUT (which must be a variable).
25066 The operation to be performed is specified by CODE. Only the
25067 following codes are supported: `PLUS_EXPR', `MINUS_EXPR',
25068 `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'.
25070 If `REAL_ARITHMETIC' is asked to evaluate division by zero and the
25071 target's floating point format cannot represent infinity, it will
25072 call `abort'. Callers should check for this situation first, using
25073 `MODE_HAS_INFINITIES'. *Note Storage Layout::.
25075 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X)
25076 Returns the negative of the floating point value X.
25078 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X)
25079 Returns the absolute value of X.
25081 -- Macro: REAL_VALUE_TYPE REAL_VALUE_TRUNCATE (REAL_VALUE_TYPE MODE,
25082 enum machine_mode X)
25083 Truncates the floating point value X to fit in MODE. The return
25084 value is still a full-size `REAL_VALUE_TYPE', but it has an
25085 appropriate bit pattern to be output asa floating constant whose
25086 precision accords with mode MODE.
25088 -- Macro: void REAL_VALUE_TO_INT (HOST_WIDE_INT LOW, HOST_WIDE_INT
25089 HIGH, REAL_VALUE_TYPE X)
25090 Converts a floating point value X into a double-precision integer
25091 which is then stored into LOW and HIGH. If the value is not
25092 integral, it is truncated.
25094 -- Macro: void REAL_VALUE_FROM_INT (REAL_VALUE_TYPE X, HOST_WIDE_INT
25095 LOW, HOST_WIDE_INT HIGH, enum machine_mode MODE)
25096 Converts a double-precision integer found in LOW and HIGH, into a
25097 floating point value which is then stored into X. The value is
25098 truncated to fit in mode MODE.
25101 File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros
25103 14.22 Mode Switching Instructions
25104 =================================
25106 The following macros control mode switching optimizations:
25108 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY)
25109 Define this macro if the port needs extra instructions inserted
25110 for mode switching in an optimizing compilation.
25112 For an example, the SH4 can perform both single and double
25113 precision floating point operations, but to perform a single
25114 precision operation, the FPSCR PR bit has to be cleared, while for
25115 a double precision operation, this bit has to be set. Changing
25116 the PR bit requires a general purpose register as a scratch
25117 register, hence these FPSCR sets have to be inserted before
25118 reload, i.e. you can't put this into instruction emitting or
25119 `TARGET_MACHINE_DEPENDENT_REORG'.
25121 You can have multiple entities that are mode-switched, and select
25122 at run time which entities actually need it.
25123 `OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY
25124 that needs mode-switching. If you define this macro, you also
25125 have to define `NUM_MODES_FOR_MODE_SWITCHING', `MODE_NEEDED',
25126 `MODE_PRIORITY_TO_MODE' and `EMIT_MODE_SET'. `MODE_AFTER',
25127 `MODE_ENTRY', and `MODE_EXIT' are optional.
25129 -- Macro: NUM_MODES_FOR_MODE_SWITCHING
25130 If you define `OPTIMIZE_MODE_SWITCHING', you have to define this as
25131 initializer for an array of integers. Each initializer element N
25132 refers to an entity that needs mode switching, and specifies the
25133 number of different modes that might need to be set for this
25134 entity. The position of the initializer in the
25135 initializer--starting counting at zero--determines the integer
25136 that is used to refer to the mode-switched entity in question. In
25137 macros that take mode arguments / yield a mode result, modes are
25138 represented as numbers 0 ... N - 1. N is used to specify that no
25139 mode switch is needed / supplied.
25141 -- Macro: MODE_NEEDED (ENTITY, INSN)
25142 ENTITY is an integer specifying a mode-switched entity. If
25143 `OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to
25144 return an integer value not larger than the corresponding element
25145 in `NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY
25146 must be switched into prior to the execution of INSN.
25148 -- Macro: MODE_AFTER (MODE, INSN)
25149 If this macro is defined, it is evaluated for every INSN during
25150 mode switching. It determines the mode that an insn results in (if
25151 different from the incoming mode).
25153 -- Macro: MODE_ENTRY (ENTITY)
25154 If this macro is defined, it is evaluated for every ENTITY that
25155 needs mode switching. It should evaluate to an integer, which is
25156 a mode that ENTITY is assumed to be switched to at function entry.
25157 If `MODE_ENTRY' is defined then `MODE_EXIT' must be defined.
25159 -- Macro: MODE_EXIT (ENTITY)
25160 If this macro is defined, it is evaluated for every ENTITY that
25161 needs mode switching. It should evaluate to an integer, which is
25162 a mode that ENTITY is assumed to be switched to at function exit.
25163 If `MODE_EXIT' is defined then `MODE_ENTRY' must be defined.
25165 -- Macro: MODE_PRIORITY_TO_MODE (ENTITY, N)
25166 This macro specifies the order in which modes for ENTITY are
25167 processed. 0 is the highest priority,
25168 `NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value
25169 of the macro should be an integer designating a mode for ENTITY.
25170 For any fixed ENTITY, `mode_priority_to_mode' (ENTITY, N) shall be
25171 a bijection in 0 ... `num_modes_for_mode_switching[ENTITY] - 1'.
25173 -- Macro: EMIT_MODE_SET (ENTITY, MODE, HARD_REGS_LIVE)
25174 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE
25175 is the set of hard registers live at the point where the insn(s)
25176 are to be inserted.
25179 File: gccint.info, Node: Target Attributes, Next: MIPS Coprocessors, Prev: Mode Switching, Up: Target Macros
25181 14.23 Defining target-specific uses of `__attribute__'
25182 ======================================================
25184 Target-specific attributes may be defined for functions, data and types.
25185 These are described using the following target hooks; they also need to
25186 be documented in `extend.texi'.
25188 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE
25189 If defined, this target hook points to an array of `struct
25190 attribute_spec' (defined in `tree.h') specifying the machine
25191 specific attributes for this target and some of the restrictions
25192 on the entities to which these attributes are applied and the
25193 arguments they take.
25195 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (tree TYPE1, tree
25197 If defined, this target hook is a function which returns zero if
25198 the attributes on TYPE1 and TYPE2 are incompatible, one if they
25199 are compatible, and two if they are nearly compatible (which
25200 causes a warning to be generated). If this is not defined,
25201 machine-specific attributes are supposed always to be compatible.
25203 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE)
25204 If defined, this target hook is a function which assigns default
25205 attributes to newly defined TYPE.
25207 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree
25209 Define this target hook if the merging of type attributes needs
25210 special handling. If defined, the result is a list of the combined
25211 `TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that
25212 `comptypes' has already been called and returned 1. This function
25213 may call `merge_attributes' to handle machine-independent merging.
25215 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree
25217 Define this target hook if the merging of decl attributes needs
25218 special handling. If defined, the result is a list of the combined
25219 `DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate
25220 declaration of OLDDECL. Examples of when this is needed are when
25221 one attribute overrides another, or when an attribute is nullified
25222 by a subsequent definition. This function may call
25223 `merge_attributes' to handle machine-independent merging.
25225 If the only target-specific handling you require is `dllimport'
25226 for Microsoft Windows targets, you should define the macro
25227 `TARGET_DLLIMPORT_DECL_ATTRIBUTES' to `1'. The compiler will then
25228 define a function called `merge_dllimport_decl_attributes' which
25229 can then be defined as the expansion of
25230 `TARGET_MERGE_DECL_ATTRIBUTES'. You can also add
25231 `handle_dll_attribute' in the attribute table for your port to
25232 perform initial processing of the `dllimport' and `dllexport'
25233 attributes. This is done in `i386/cygwin.h' and `i386/i386.c',
25236 -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (tree DECL)
25237 DECL is a variable or function with `__attribute__((dllimport))'
25238 specified. Use this hook if the target needs to add extra
25239 validation checks to `handle_dll_attribute'.
25241 -- Macro: TARGET_DECLSPEC
25242 Define this macro to a nonzero value if you want to treat
25243 `__declspec(X)' as equivalent to `__attribute((X))'. By default,
25244 this behavior is enabled only for targets that define
25245 `TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of
25246 `__declspec' is via a built-in macro, but you should not rely on
25247 this implementation detail.
25249 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree
25251 Define this target hook if you want to be able to add attributes
25252 to a decl when it is being created. This is normally useful for
25253 back ends which wish to implement a pragma by using the attributes
25254 which correspond to the pragma's effect. The NODE argument is the
25255 decl which is being created. The ATTR_PTR argument is a pointer
25256 to the attribute list for this decl. The list itself should not
25257 be modified, since it may be shared with other decls, but
25258 attributes may be chained on the head of the list and `*ATTR_PTR'
25259 modified to point to the new attributes, or a copy of the list may
25260 be made if further changes are needed.
25262 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (tree
25264 This target hook returns `true' if it is ok to inline FNDECL into
25265 the current function, despite its having target-specific
25266 attributes, `false' otherwise. By default, if a function has a
25267 target specific attribute attached to it, it will not be inlined.
25270 File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Target Attributes, Up: Target Macros
25272 14.24 Defining coprocessor specifics for MIPS targets.
25273 ======================================================
25275 The MIPS specification allows MIPS implementations to have as many as 4
25276 coprocessors, each with as many as 32 private registers. GCC supports
25277 accessing these registers and transferring values between the registers
25278 and memory using asm-ized variables. For example:
25280 register unsigned int cp0count asm ("c0r1");
25285 ("c0r1" is the default name of register 1 in coprocessor 0; alternate
25286 names may be added as described below, or the default names may be
25287 overridden entirely in `SUBTARGET_CONDITIONAL_REGISTER_USAGE'.)
25289 Coprocessor registers are assumed to be epilogue-used; sets to them
25290 will be preserved even if it does not appear that the register is used
25291 again later in the function.
25293 Another note: according to the MIPS spec, coprocessor 1 (if present) is
25294 the FPU. One accesses COP1 registers through standard mips
25295 floating-point support; they are not included in this mechanism.
25297 There is one macro used in defining the MIPS coprocessor interface
25298 which you may want to override in subtargets; it is described below.
25300 -- Macro: ALL_COP_ADDITIONAL_REGISTER_NAMES
25301 A comma-separated list (with leading comma) of pairs describing the
25302 alternate names of coprocessor registers. The format of each
25304 { ALTERNATENAME, REGISTER_NUMBER}
25308 File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros
25310 14.25 Parameters for Precompiled Header Validity Checking
25311 =========================================================
25313 -- Target Hook: void *TARGET_GET_PCH_VALIDITY (size_t *SZ)
25314 This hook returns the data needed by `TARGET_PCH_VALID_P' and sets
25315 `*SZ' to the size of the data in bytes.
25317 -- Target Hook: const char *TARGET_PCH_VALID_P (const void *DATA,
25319 This hook checks whether the options used to create a PCH file are
25320 compatible with the current settings. It returns `NULL' if so and
25321 a suitable error message if not. Error messages will be presented
25322 to the user and must be localized using `_(MSG)'.
25324 DATA is the data that was returned by `TARGET_GET_PCH_VALIDITY'
25325 when the PCH file was created and SZ is the size of that data in
25326 bytes. It's safe to assume that the data was created by the same
25327 version of the compiler, so no format checking is needed.
25329 The default definition of `default_pch_valid_p' should be suitable
25332 -- Target Hook: const char *TARGET_CHECK_PCH_TARGET_FLAGS (int
25334 If this hook is nonnull, the default implementation of
25335 `TARGET_PCH_VALID_P' will use it to check for compatible values of
25336 `target_flags'. PCH_FLAGS specifies the value that `target_flags'
25337 had when the PCH file was created. The return value is the same
25338 as for `TARGET_PCH_VALID_P'.
25341 File: gccint.info, Node: C++ ABI, Next: Misc, Prev: PCH Target, Up: Target Macros
25343 14.26 C++ ABI parameters
25344 ========================
25346 -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void)
25347 Define this hook to override the integer type used for guard
25348 variables. These are used to implement one-time construction of
25349 static objects. The default is long_long_integer_type_node.
25351 -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void)
25352 This hook determines how guard variables are used. It should
25353 return `false' (the default) if first byte should be used. A
25354 return value of `true' indicates the least significant bit should
25357 -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE)
25358 This hook returns the size of the cookie to use when allocating an
25359 array whose elements have the indicated TYPE. Assumes that it is
25360 already known that a cookie is needed. The default is `max(sizeof
25361 (size_t), alignof(type))', as defined in section 2.7 of the
25362 IA64/Generic C++ ABI.
25364 -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void)
25365 This hook should return `true' if the element size should be
25366 stored in array cookies. The default is to return `false'.
25368 -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int
25370 If defined by a backend this hook allows the decision made to
25371 export class TYPE to be overruled. Upon entry IMPORT_EXPORT will
25372 contain 1 if the class is going to be exported, -1 if it is going
25373 to be imported and 0 otherwise. This function should return the
25374 modified value and perform any other actions necessary to support
25375 the backend's targeted operating system.
25377 -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void)
25378 This hook should return `true' if constructors and destructors
25379 return the address of the object created/destroyed. The default
25380 is to return `false'.
25382 -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void)
25383 This hook returns true if the key method for a class (i.e., the
25384 method which, if defined in the current translation unit, causes
25385 the virtual table to be emitted) may be an inline function. Under
25386 the standard Itanium C++ ABI the key method may be an inline
25387 function so long as the function is not declared inline in the
25388 class definition. Under some variants of the ABI, an inline
25389 function can never be the key method. The default is to return
25392 -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree
25394 DECL is a virtual table, virtual table table, typeinfo object, or
25395 other similar implicit class data object that will be emitted with
25396 external linkage in this translation unit. No ELF visibility has
25397 been explicitly specified. If the target needs to specify a
25398 visibility other than that of the containing class, use this hook
25399 to set `DECL_VISIBILITY' and `DECL_VISIBILITY_SPECIFIED'.
25401 -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void)
25402 This hook returns true (the default) if virtual tables and other
25403 similar implicit class data objects are always COMDAT if they have
25404 external linkage. If this hook returns false, then class data for
25405 classes whose virtual table will be emitted in only one translation
25406 unit will not be COMDAT.
25408 -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void)
25409 This hook returns true if `__aeabi_atexit' (as defined by the ARM
25410 EABI) should be used to register static destructors when
25411 `-fuse-cxa-atexit' is in effect. The default is to return false
25412 to use `__cxa_atexit'.
25414 -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE)
25415 TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has
25416 just been defined. Use this hook to make adjustments to the class
25417 (eg, tweak visibility or perform any other required target
25421 File: gccint.info, Node: Misc, Prev: C++ ABI, Up: Target Macros
25423 14.27 Miscellaneous Parameters
25424 ==============================
25426 Here are several miscellaneous parameters.
25428 -- Macro: HAS_LONG_COND_BRANCH
25429 Define this boolean macro to indicate whether or not your
25430 architecture has conditional branches that can span all of memory.
25431 It is used in conjunction with an optimization that partitions
25432 hot and cold basic blocks into separate sections of the
25433 executable. If this macro is set to false, gcc will convert any
25434 conditional branches that attempt to cross between sections into
25435 unconditional branches or indirect jumps.
25437 -- Macro: HAS_LONG_UNCOND_BRANCH
25438 Define this boolean macro to indicate whether or not your
25439 architecture has unconditional branches that can span all of
25440 memory. It is used in conjunction with an optimization that
25441 partitions hot and cold basic blocks into separate sections of the
25442 executable. If this macro is set to false, gcc will convert any
25443 unconditional branches that attempt to cross between sections into
25446 -- Macro: CASE_VECTOR_MODE
25447 An alias for a machine mode name. This is the machine mode that
25448 elements of a jump-table should have.
25450 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY)
25451 Optional: return the preferred mode for an `addr_diff_vec' when
25452 the minimum and maximum offset are known. If you define this, it
25453 enables extra code in branch shortening to deal with
25454 `addr_diff_vec'. To make this work, you also have to define
25455 `INSN_ALIGN' and make the alignment for `addr_diff_vec' explicit.
25456 The BODY argument is provided so that the offset_unsigned and scale
25457 flags can be updated.
25459 -- Macro: CASE_VECTOR_PC_RELATIVE
25460 Define this macro to be a C expression to indicate when jump-tables
25461 should contain relative addresses. You need not define this macro
25462 if jump-tables never contain relative addresses, or jump-tables
25463 should contain relative addresses only when `-fPIC' or `-fPIC' is
25466 -- Macro: CASE_VALUES_THRESHOLD
25467 Define this to be the smallest number of different values for
25468 which it is best to use a jump-table instead of a tree of
25469 conditional branches. The default is four for machines with a
25470 `casesi' instruction and five otherwise. This is best for most
25473 -- Macro: CASE_USE_BIT_TESTS
25474 Define this macro to be a C expression to indicate whether C switch
25475 statements may be implemented by a sequence of bit tests. This is
25476 advantageous on processors that can efficiently implement left
25477 shift of 1 by the number of bits held in a register, but
25478 inappropriate on targets that would require a loop. By default,
25479 this macro returns `true' if the target defines an `ashlsi3'
25480 pattern, and `false' otherwise.
25482 -- Macro: WORD_REGISTER_OPERATIONS
25483 Define this macro if operations between registers with integral
25484 mode smaller than a word are always performed on the entire
25485 register. Most RISC machines have this property and most CISC
25488 -- Macro: LOAD_EXTEND_OP (MEM_MODE)
25489 Define this macro to be a C expression indicating when insns that
25490 read memory in MEM_MODE, an integral mode narrower than a word,
25491 set the bits outside of MEM_MODE to be either the sign-extension
25492 or the zero-extension of the data read. Return `SIGN_EXTEND' for
25493 values of MEM_MODE for which the insn sign-extends, `ZERO_EXTEND'
25494 for which it zero-extends, and `UNKNOWN' for other modes.
25496 This macro is not called with MEM_MODE non-integral or with a width
25497 greater than or equal to `BITS_PER_WORD', so you may return any
25498 value in this case. Do not define this macro if it would always
25499 return `UNKNOWN'. On machines where this macro is defined, you
25500 will normally define it as the constant `SIGN_EXTEND' or
25503 You may return a non-`UNKNOWN' value even if for some hard
25504 registers the sign extension is not performed, if for the
25505 `REGNO_REG_CLASS' of these hard registers
25506 `CANNOT_CHANGE_MODE_CLASS' returns nonzero when the FROM mode is
25507 MEM_MODE and the TO mode is any integral mode larger than this but
25508 not larger than `word_mode'.
25510 You must return `UNKNOWN' if for some hard registers that allow
25511 this mode, `CANNOT_CHANGE_MODE_CLASS' says that they cannot change
25512 to `word_mode', but that they can change to another integral mode
25513 that is larger then MEM_MODE but still smaller than `word_mode'.
25515 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND
25516 Define this macro if loading short immediate values into registers
25519 -- Macro: FIXUNS_TRUNC_LIKE_FIX_TRUNC
25520 Define this macro if the same instructions that convert a floating
25521 point number to a signed fixed point number also convert validly
25522 to an unsigned one.
25524 -- Target Hook: int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL (enum
25526 When `-ffast-math' is in effect, GCC tries to optimize divisions
25527 by the same divisor, by turning them into multiplications by the
25528 reciprocal. This target hook specifies the minimum number of
25529 divisions that should be there for GCC to perform the optimization
25530 for a variable of mode MODE. The default implementation returns 3
25531 if the machine has an instruction for the division, and 2 if it
25535 The maximum number of bytes that a single instruction can move
25536 quickly between memory and registers or between two memory
25539 -- Macro: MAX_MOVE_MAX
25540 The maximum number of bytes that a single instruction can move
25541 quickly between memory and registers or between two memory
25542 locations. If this is undefined, the default is `MOVE_MAX'.
25543 Otherwise, it is the constant value that is the largest value that
25544 `MOVE_MAX' can have at run-time.
25546 -- Macro: SHIFT_COUNT_TRUNCATED
25547 A C expression that is nonzero if on this machine the number of
25548 bits actually used for the count of a shift operation is equal to
25549 the number of bits needed to represent the size of the object
25550 being shifted. When this macro is nonzero, the compiler will
25551 assume that it is safe to omit a sign-extend, zero-extend, and
25552 certain bitwise `and' instructions that truncates the count of a
25553 shift operation. On machines that have instructions that act on
25554 bit-fields at variable positions, which may include `bit test'
25555 instructions, a nonzero `SHIFT_COUNT_TRUNCATED' also enables
25556 deletion of truncations of the values that serve as arguments to
25557 bit-field instructions.
25559 If both types of instructions truncate the count (for shifts) and
25560 position (for bit-field operations), or if no variable-position
25561 bit-field instructions exist, you should define this macro.
25563 However, on some machines, such as the 80386 and the 680x0,
25564 truncation only applies to shift operations and not the (real or
25565 pretended) bit-field operations. Define `SHIFT_COUNT_TRUNCATED'
25566 to be zero on such machines. Instead, add patterns to the `md'
25567 file that include the implied truncation of the shift instructions.
25569 You need not define this macro if it would always have the value
25572 -- Target Hook: int TARGET_SHIFT_TRUNCATION_MASK (enum machine_mode
25574 This function describes how the standard shift patterns for MODE
25575 deal with shifts by negative amounts or by more than the width of
25576 the mode. *Note shift patterns::.
25578 On many machines, the shift patterns will apply a mask M to the
25579 shift count, meaning that a fixed-width shift of X by Y is
25580 equivalent to an arbitrary-width shift of X by Y & M. If this is
25581 true for mode MODE, the function should return M, otherwise it
25582 should return 0. A return value of 0 indicates that no particular
25583 behavior is guaranteed.
25585 Note that, unlike `SHIFT_COUNT_TRUNCATED', this function does
25586 _not_ apply to general shift rtxes; it applies only to instructions
25587 that are generated by the named shift patterns.
25589 The default implementation of this function returns
25590 `GET_MODE_BITSIZE (MODE) - 1' if `SHIFT_COUNT_TRUNCATED' and 0
25591 otherwise. This definition is always safe, but if
25592 `SHIFT_COUNT_TRUNCATED' is false, and some shift patterns
25593 nevertheless truncate the shift count, you may get better code by
25596 -- Macro: TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)
25597 A C expression which is nonzero if on this machine it is safe to
25598 "convert" an integer of INPREC bits to one of OUTPREC bits (where
25599 OUTPREC is smaller than INPREC) by merely operating on it as if it
25600 had only OUTPREC bits.
25602 On many machines, this expression can be 1.
25604 When `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for
25605 modes for which `MODES_TIEABLE_P' is 0, suboptimal code can result.
25606 If this is the case, making `TRULY_NOOP_TRUNCATION' return 0 in
25607 such cases may improve things.
25609 -- Macro: STORE_FLAG_VALUE
25610 A C expression describing the value returned by a comparison
25611 operator with an integral mode and stored by a store-flag
25612 instruction (`sCOND') when the condition is true. This
25613 description must apply to _all_ the `sCOND' patterns and all the
25614 comparison operators whose results have a `MODE_INT' mode.
25616 A value of 1 or -1 means that the instruction implementing the
25617 comparison operator returns exactly 1 or -1 when the comparison is
25618 true and 0 when the comparison is false. Otherwise, the value
25619 indicates which bits of the result are guaranteed to be 1 when the
25620 comparison is true. This value is interpreted in the mode of the
25621 comparison operation, which is given by the mode of the first
25622 operand in the `sCOND' pattern. Either the low bit or the sign
25623 bit of `STORE_FLAG_VALUE' be on. Presently, only those bits are
25624 used by the compiler.
25626 If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will
25627 generate code that depends only on the specified bits. It can also
25628 replace comparison operators with equivalent operations if they
25629 cause the required bits to be set, even if the remaining bits are
25630 undefined. For example, on a machine whose comparison operators
25631 return an `SImode' value and where `STORE_FLAG_VALUE' is defined as
25632 `0x80000000', saying that just the sign bit is relevant, the
25635 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0))
25637 can be converted to
25639 (ashift:SI X (const_int N))
25641 where N is the appropriate shift count to move the bit being
25642 tested into the sign bit.
25644 There is no way to describe a machine that always sets the
25645 low-order bit for a true value, but does not guarantee the value
25646 of any other bits, but we do not know of any machine that has such
25647 an instruction. If you are trying to port GCC to such a machine,
25648 include an instruction to perform a logical-and of the result with
25649 1 in the pattern for the comparison operators and let us know at
25652 Often, a machine will have multiple instructions that obtain a
25653 value from a comparison (or the condition codes). Here are rules
25654 to guide the choice of value for `STORE_FLAG_VALUE', and hence the
25655 instructions to be used:
25657 * Use the shortest sequence that yields a valid definition for
25658 `STORE_FLAG_VALUE'. It is more efficient for the compiler to
25659 "normalize" the value (convert it to, e.g., 1 or 0) than for
25660 the comparison operators to do so because there may be
25661 opportunities to combine the normalization with other
25664 * For equal-length sequences, use a value of 1 or -1, with -1
25665 being slightly preferred on machines with expensive jumps and
25666 1 preferred on other machines.
25668 * As a second choice, choose a value of `0x80000001' if
25669 instructions exist that set both the sign and low-order bits
25670 but do not define the others.
25672 * Otherwise, use a value of `0x80000000'.
25674 Many machines can produce both the value chosen for
25675 `STORE_FLAG_VALUE' and its negation in the same number of
25676 instructions. On those machines, you should also define a pattern
25677 for those cases, e.g., one matching
25679 (set A (neg:M (ne:M B C)))
25681 Some machines can also perform `and' or `plus' operations on
25682 condition code values with less instructions than the corresponding
25683 `sCOND' insn followed by `and' or `plus'. On those machines,
25684 define the appropriate patterns. Use the names `incscc' and
25685 `decscc', respectively, for the patterns which perform `plus' or
25686 `minus' operations on condition code values. See `rs6000.md' for
25687 some examples. The GNU Superoptizer can be used to find such
25688 instruction sequences on other machines.
25690 If this macro is not defined, the default value, 1, is used. You
25691 need not define `STORE_FLAG_VALUE' if the machine has no store-flag
25692 instructions, or if the value generated by these instructions is 1.
25694 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE)
25695 A C expression that gives a nonzero `REAL_VALUE_TYPE' value that is
25696 returned when comparison operators with floating-point results are
25697 true. Define this macro on machines that have comparison
25698 operations that return floating-point values. If there are no
25699 such operations, do not define this macro.
25701 -- Macro: VECTOR_STORE_FLAG_VALUE (MODE)
25702 A C expression that gives a rtx representing the nonzero true
25703 element for vector comparisons. The returned rtx should be valid
25704 for the inner mode of MODE which is guaranteed to be a vector
25705 mode. Define this macro on machines that have vector comparison
25706 operations that return a vector result. If there are no such
25707 operations, do not define this macro. Typically, this macro is
25708 defined as `const1_rtx' or `constm1_rtx'. This macro may return
25709 `NULL_RTX' to prevent the compiler optimizing such vector
25710 comparison operations for the given mode.
25712 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
25713 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
25714 A C expression that evaluates to true if the architecture defines
25715 a value for `clz' or `ctz' with a zero operand. If so, VALUE
25716 should be set to this value. If this macro is not defined, the
25717 value of `clz' or `ctz' is assumed to be undefined.
25719 This macro must be defined if the target's expansion for `ffs'
25720 relies on a particular value to get correct results. Otherwise it
25721 is not necessary, though it may be used to optimize some corner
25724 Note that regardless of this macro the "definedness" of `clz' and
25725 `ctz' at zero do _not_ extend to the builtin functions visible to
25726 the user. Thus one may be free to adjust the value at will to
25727 match the target expansion of these operations without fear of
25731 An alias for the machine mode for pointers. On most machines,
25732 define this to be the integer mode corresponding to the width of a
25733 hardware pointer; `SImode' on 32-bit machine or `DImode' on 64-bit
25734 machines. On some machines you must define this to be one of the
25735 partial integer modes, such as `PSImode'.
25737 The width of `Pmode' must be at least as large as the value of
25738 `POINTER_SIZE'. If it is not equal, you must define the macro
25739 `POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to
25742 -- Macro: FUNCTION_MODE
25743 An alias for the machine mode used for memory references to
25744 functions being called, in `call' RTL expressions. On most
25745 machines this should be `QImode'.
25747 -- Macro: STDC_0_IN_SYSTEM_HEADERS
25748 In normal operation, the preprocessor expands `__STDC__' to the
25749 constant 1, to signify that GCC conforms to ISO Standard C. On
25750 some hosts, like Solaris, the system compiler uses a different
25751 convention, where `__STDC__' is normally 0, but is 1 if the user
25752 specifies strict conformance to the C Standard.
25754 Defining `STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host
25755 convention when processing system header files, but when
25756 processing user files `__STDC__' will always expand to 1.
25758 -- Macro: NO_IMPLICIT_EXTERN_C
25759 Define this macro if the system header files support C++ as well
25760 as C. This macro inhibits the usual method of using system header
25761 files in C++, which is to pretend that the file's contents are
25762 enclosed in `extern "C" {...}'.
25764 -- Macro: REGISTER_TARGET_PRAGMAS ()
25765 Define this macro if you want to implement any target-specific
25766 pragmas. If defined, it is a C expression which makes a series of
25767 calls to `c_register_pragma' or `c_register_pragma_with_expansion'
25768 for each pragma. The macro may also do any setup required for the
25771 The primary reason to define this macro is to provide
25772 compatibility with other compilers for the same target. In
25773 general, we discourage definition of target-specific pragmas for
25776 If the pragma can be implemented by attributes then you should
25777 consider defining the target hook `TARGET_INSERT_ATTRIBUTES' as
25780 Preprocessor macros that appear on pragma lines are not expanded.
25781 All `#pragma' directives that do not match any registered pragma
25782 are silently ignored, unless the user specifies
25783 `-Wunknown-pragmas'.
25785 -- Function: void c_register_pragma (const char *SPACE, const char
25786 *NAME, void (*CALLBACK) (struct cpp_reader *))
25787 -- Function: void c_register_pragma_with_expansion (const char *SPACE,
25788 const char *NAME, void (*CALLBACK) (struct cpp_reader *))
25789 Each call to `c_register_pragma' or
25790 `c_register_pragma_with_expansion' establishes one pragma. The
25791 CALLBACK routine will be called when the preprocessor encounters a
25794 #pragma [SPACE] NAME ...
25796 SPACE is the case-sensitive namespace of the pragma, or `NULL' to
25797 put the pragma in the global namespace. The callback routine
25798 receives PFILE as its first argument, which can be passed on to
25799 cpplib's functions if necessary. You can lex tokens after the
25800 NAME by calling `c_lex'. Tokens that are not read by the callback
25801 will be silently ignored. The end of the line is indicated by a
25802 token of type `CPP_EOF'. Macro expansion occurs on the arguments
25803 of pragmas registered with `c_register_pragma_with_expansion' but
25804 not on the arguments of pragmas registered with
25805 `c_register_pragma'.
25807 For an example use of this routine, see `c4x.h' and the callback
25808 routines defined in `c4x-c.c'.
25810 Note that the use of `c_lex' is specific to the C and C++
25811 compilers. It will not work in the Java or Fortran compilers, or
25812 any other language compilers for that matter. Thus if `c_lex' is
25813 going to be called from target-specific code, it must only be done
25814 so when building the C and C++ compilers. This can be done by
25815 defining the variables `c_target_objs' and `cxx_target_objs' in the
25816 target entry in the `config.gcc' file. These variables should name
25817 the target-specific, language-specific object file which contains
25818 the code that uses `c_lex'. Note it will also be necessary to add
25819 a rule to the makefile fragment pointed to by `tmake_file' that
25820 shows how to build this object file.
25822 -- Macro: HANDLE_SYSV_PRAGMA
25823 Define this macro (to a value of 1) if you want the System V style
25824 pragmas `#pragma pack(<n>)' and `#pragma weak <name> [=<value>]'
25825 to be supported by gcc.
25827 The pack pragma specifies the maximum alignment (in bytes) of
25828 fields within a structure, in much the same way as the
25829 `__aligned__' and `__packed__' `__attribute__'s do. A pack value
25830 of zero resets the behavior to the default.
25832 A subtlety for Microsoft Visual C/C++ style bit-field packing
25833 (e.g. -mms-bitfields) for targets that support it: When a
25834 bit-field is inserted into a packed record, the whole size of the
25835 underlying type is used by one or more same-size adjacent
25836 bit-fields (that is, if its long:3, 32 bits is used in the record,
25837 and any additional adjacent long bit-fields are packed into the
25838 same chunk of 32 bits. However, if the size changes, a new field
25839 of that size is allocated).
25841 If both MS bit-fields and `__attribute__((packed))' are used, the
25842 latter will take precedence. If `__attribute__((packed))' is used
25843 on a single field when MS bit-fields are in use, it will take
25844 precedence for that field, but the alignment of the rest of the
25845 structure may affect its placement.
25847 The weak pragma only works if `SUPPORTS_WEAK' and
25848 `ASM_WEAKEN_LABEL' are defined. If enabled it allows the creation
25849 of specifically named weak labels, optionally with a value.
25851 -- Macro: HANDLE_PRAGMA_PACK_PUSH_POP
25852 Define this macro (to a value of 1) if you want to support the
25853 Win32 style pragmas `#pragma pack(push[,N])' and `#pragma
25854 pack(pop)'. The `pack(push,[N])' pragma specifies the maximum
25855 alignment (in bytes) of fields within a structure, in much the
25856 same way as the `__aligned__' and `__packed__' `__attribute__'s
25857 do. A pack value of zero resets the behavior to the default.
25858 Successive invocations of this pragma cause the previous values to
25859 be stacked, so that invocations of `#pragma pack(pop)' will return
25860 to the previous value.
25862 -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION
25863 Define this macro, as well as `HANDLE_SYSV_PRAGMA', if macros
25864 should be expanded in the arguments of `#pragma pack'.
25866 -- Macro: TARGET_DEFAULT_PACK_STRUCT
25867 If your target requires a structure packing default other than 0
25868 (meaning the machine default), define this macro to the necessary
25869 value (in bytes). This must be a value that would also valid to
25870 be used with `#pragma pack()' (that is, a small power of two).
25872 -- Macro: DOLLARS_IN_IDENTIFIERS
25873 Define this macro to control use of the character `$' in
25874 identifier names for the C family of languages. 0 means `$' is
25875 not allowed by default; 1 means it is allowed. 1 is the default;
25876 there is no need to define this macro in that case.
25878 -- Macro: NO_DOLLAR_IN_LABEL
25879 Define this macro if the assembler does not accept the character
25880 `$' in label names. By default constructors and destructors in
25881 G++ have `$' in the identifiers. If this macro is defined, `.' is
25884 -- Macro: NO_DOT_IN_LABEL
25885 Define this macro if the assembler does not accept the character
25886 `.' in label names. By default constructors and destructors in G++
25887 have names that use `.'. If this macro is defined, these names
25888 are rewritten to avoid `.'.
25890 -- Macro: INSN_SETS_ARE_DELAYED (INSN)
25891 Define this macro as a C expression that is nonzero if it is safe
25892 for the delay slot scheduler to place instructions in the delay
25893 slot of INSN, even if they appear to use a resource set or
25894 clobbered in INSN. INSN is always a `jump_insn' or an `insn'; GCC
25895 knows that every `call_insn' has this behavior. On machines where
25896 some `insn' or `jump_insn' is really a function call and hence has
25897 this behavior, you should define this macro.
25899 You need not define this macro if it would always return zero.
25901 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN)
25902 Define this macro as a C expression that is nonzero if it is safe
25903 for the delay slot scheduler to place instructions in the delay
25904 slot of INSN, even if they appear to set or clobber a resource
25905 referenced in INSN. INSN is always a `jump_insn' or an `insn'.
25906 On machines where some `insn' or `jump_insn' is really a function
25907 call and its operands are registers whose use is actually in the
25908 subroutine it calls, you should define this macro. Doing so
25909 allows the delay slot scheduler to move instructions which copy
25910 arguments into the argument registers into the delay slot of INSN.
25912 You need not define this macro if it would always return zero.
25914 -- Macro: MULTIPLE_SYMBOL_SPACES
25915 Define this macro as a C expression that is nonzero if, in some
25916 cases, global symbols from one translation unit may not be bound
25917 to undefined symbols in another translation unit without user
25918 intervention. For instance, under Microsoft Windows symbols must
25919 be explicitly imported from shared libraries (DLLs).
25921 You need not define this macro if it would always evaluate to zero.
25923 -- Target Hook: tree TARGET_MD_ASM_CLOBBERS (tree OUTPUTS, tree
25924 INPUTS, tree CLOBBERS)
25925 This target hook should add to CLOBBERS `STRING_CST' trees for any
25926 hard regs the port wishes to automatically clobber for an asm. It
25927 should return the result of the last `tree_cons' used to add a
25928 clobber. The OUTPUTS, INPUTS and CLOBBER lists are the
25929 corresponding parameters to the asm and may be inspected to avoid
25930 clobbering a register that is an input or output of the asm. You
25931 can use `tree_overlaps_hard_reg_set', declared in `tree.h', to test
25932 for overlap with regards to asm-declared registers.
25934 -- Macro: MATH_LIBRARY
25935 Define this macro as a C string constant for the linker argument
25936 to link in the system math library, or `""' if the target does not
25937 have a separate math library.
25939 You need only define this macro if the default of `"-lm"' is wrong.
25941 -- Macro: LIBRARY_PATH_ENV
25942 Define this macro as a C string constant for the environment
25943 variable that specifies where the linker should look for libraries.
25945 You need only define this macro if the default of `"LIBRARY_PATH"'
25948 -- Macro: TARGET_POSIX_IO
25949 Define this macro if the target supports the following POSIX file
25950 functions, access, mkdir and file locking with fcntl / F_SETLKW.
25951 Defining `TARGET_POSIX_IO' will enable the test coverage code to
25952 use file locking when exiting a program, which avoids race
25953 conditions if the program has forked. It will also create
25954 directories at run-time for cross-profiling.
25956 -- Macro: MAX_CONDITIONAL_EXECUTE
25957 A C expression for the maximum number of instructions to execute
25958 via conditional execution instructions instead of a branch. A
25959 value of `BRANCH_COST'+1 is the default if the machine does not
25960 use cc0, and 1 if it does use cc0.
25962 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR)
25963 Used if the target needs to perform machine-dependent
25964 modifications on the conditionals used for turning basic blocks
25965 into conditionally executed code. CE_INFO points to a data
25966 structure, `struct ce_if_block', which contains information about
25967 the currently processed blocks. TRUE_EXPR and FALSE_EXPR are the
25968 tests that are used for converting the then-block and the
25969 else-block, respectively. Set either TRUE_EXPR or FALSE_EXPR to a
25970 null pointer if the tests cannot be converted.
25972 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR,
25974 Like `IFCVT_MODIFY_TESTS', but used when converting more
25975 complicated if-statements into conditions combined by `and' and
25976 `or' operations. BB contains the basic block that contains the
25977 test that is currently being processed and about to be turned into
25980 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN)
25981 A C expression to modify the PATTERN of an INSN that is to be
25982 converted to conditional execution format. CE_INFO points to a
25983 data structure, `struct ce_if_block', which contains information
25984 about the currently processed blocks.
25986 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO)
25987 A C expression to perform any final machine dependent
25988 modifications in converting code to conditional execution. The
25989 involved basic blocks can be found in the `struct ce_if_block'
25990 structure that is pointed to by CE_INFO.
25992 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO)
25993 A C expression to cancel any machine dependent modifications in
25994 converting code to conditional execution. The involved basic
25995 blocks can be found in the `struct ce_if_block' structure that is
25996 pointed to by CE_INFO.
25998 -- Macro: IFCVT_INIT_EXTRA_FIELDS (CE_INFO)
25999 A C expression to initialize any extra fields in a `struct
26000 ce_if_block' structure, which are defined by the
26001 `IFCVT_EXTRA_FIELDS' macro.
26003 -- Macro: IFCVT_EXTRA_FIELDS
26004 If defined, it should expand to a set of field declarations that
26005 will be added to the `struct ce_if_block' structure. These should
26006 be initialized by the `IFCVT_INIT_EXTRA_FIELDS' macro.
26008 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG ()
26009 If non-null, this hook performs a target-specific pass over the
26010 instruction stream. The compiler will run it at all optimization
26011 levels, just before the point at which it normally does
26012 delayed-branch scheduling.
26014 The exact purpose of the hook varies from target to target. Some
26015 use it to do transformations that are necessary for correctness,
26016 such as laying out in-function constant pools or avoiding hardware
26017 hazards. Others use it as an opportunity to do some
26018 machine-dependent optimizations.
26020 You need not implement the hook if it has nothing to do. The
26021 default definition is null.
26023 -- Target Hook: void TARGET_INIT_BUILTINS ()
26024 Define this hook if you have any machine-specific built-in
26025 functions that need to be defined. It should be a function that
26026 performs the necessary setup.
26028 Machine specific built-in functions can be useful to expand
26029 special machine instructions that would otherwise not normally be
26030 generated because they have no equivalent in the source language
26031 (for example, SIMD vector instructions or prefetch instructions).
26033 To create a built-in function, call the function
26034 `lang_hooks.builtin_function' which is defined by the language
26035 front end. You can use any type nodes set up by
26036 `build_common_tree_nodes' and `build_common_tree_nodes_2'; only
26037 language front ends that use those two functions will call
26038 `TARGET_INIT_BUILTINS'.
26040 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx
26041 SUBTARGET, enum machine_mode MODE, int IGNORE)
26042 Expand a call to a machine specific built-in function that was set
26043 up by `TARGET_INIT_BUILTINS'. EXP is the expression for the
26044 function call; the result should go to TARGET if that is
26045 convenient, and have mode MODE if that is convenient. SUBTARGET
26046 may be used as the target for computing one of EXP's operands.
26047 IGNORE is nonzero if the value is to be ignored. This function
26048 should return the result of the call to the built-in function.
26050 -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (tree FNDECL,
26052 Select a replacement for a machine specific built-in function that
26053 was set up by `TARGET_INIT_BUILTINS'. This is done _before_
26054 regular type checking, and so allows the target to implement a
26055 crude form of function overloading. FNDECL is the declaration of
26056 the built-in function. ARGLIST is the list of arguments passed to
26057 the built-in function. The result is a complete expression that
26058 implements the operation, usually another `CALL_EXPR'.
26060 -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, tree ARGLIST,
26062 Fold a call to a machine specific built-in function that was set
26063 up by `TARGET_INIT_BUILTINS'. FNDECL is the declaration of the
26064 built-in function. ARGLIST is the list of arguments passed to the
26065 built-in function. The result is another tree containing a
26066 simplified expression for the call's result. If IGNORE is true
26067 the value will be ignored.
26069 -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (rtx INSN)
26070 Take an instruction in INSN and return NULL if it is valid within a
26071 low-overhead loop, otherwise return a string why doloop could not
26074 Many targets use special registers for low-overhead looping. For
26075 any instruction that clobbers these this function should return a
26076 string indicating the reason why the doloop could not be applied.
26077 By default, the RTL loop optimizer does not use a present doloop
26078 pattern for loops containing function calls or branch on table
26081 -- Macro: MD_CAN_REDIRECT_BRANCH (BRANCH1, BRANCH2)
26082 Take a branch insn in BRANCH1 and another in BRANCH2. Return true
26083 if redirecting BRANCH1 to the destination of BRANCH2 is possible.
26085 On some targets, branches may have a limited range. Optimizing the
26086 filling of delay slots can result in branches being redirected,
26087 and this may in turn cause a branch offset to overflow.
26089 -- Target Hook: bool TARGET_COMMUTATIVE_P (rtx X, OUTER_CODE)
26090 This target hook returns `true' if X is considered to be
26091 commutative. Usually, this is just COMMUTATIVE_P (X), but the HP
26092 PA doesn't consider PLUS to be commutative inside a MEM.
26093 OUTER_CODE is the rtx code of the enclosing rtl, if known,
26094 otherwise it is UNKNOWN.
26096 -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG)
26097 When the initial value of a hard register has been copied in a
26098 pseudo register, it is often not necessary to actually allocate
26099 another register to this pseudo register, because the original
26100 hard register or a stack slot it has been saved into can be used.
26101 `TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register
26102 allocation once for each hard register that had its initial value
26103 copied by using `get_func_hard_reg_initial_val' or
26104 `get_hard_reg_initial_val'. Possible values are `NULL_RTX', if
26105 you don't want to do any special allocation, a `REG' rtx--that
26106 would typically be the hard register itself, if it is known not to
26107 be clobbered--or a `MEM'. If you are returning a `MEM', this is
26108 only a hint for the allocator; it might decide to use another
26109 register anyways. You may use `current_function_leaf_function' in
26110 the hook, functions that use `REG_N_SETS', to determine if the hard
26111 register in question will not be clobbered. The default value of
26112 this hook is `NULL', which disables any special allocation.
26114 -- Macro: TARGET_OBJECT_SUFFIX
26115 Define this macro to be a C string representing the suffix for
26116 object files on your target machine. If you do not define this
26117 macro, GCC will use `.o' as the suffix for object files.
26119 -- Macro: TARGET_EXECUTABLE_SUFFIX
26120 Define this macro to be a C string representing the suffix to be
26121 automatically added to executable files on your target machine.
26122 If you do not define this macro, GCC will use the null string as
26123 the suffix for executable files.
26125 -- Macro: COLLECT_EXPORT_LIST
26126 If defined, `collect2' will scan the individual object files
26127 specified on its command line and create an export list for the
26128 linker. Define this macro for systems like AIX, where the linker
26129 discards object files that are not referenced from `main' and uses
26132 -- Macro: MODIFY_JNI_METHOD_CALL (MDECL)
26133 Define this macro to a C expression representing a variant of the
26134 method call MDECL, if Java Native Interface (JNI) methods must be
26135 invoked differently from other methods on your target. For
26136 example, on 32-bit Microsoft Windows, JNI methods must be invoked
26137 using the `stdcall' calling convention and this macro is then
26138 defined as this expression:
26140 build_type_attribute_variant (MDECL,
26142 (get_identifier ("stdcall"),
26145 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void)
26146 This target hook returns `true' past the point in which new jump
26147 instructions could be created. On machines that require a
26148 register for every jump such as the SHmedia ISA of SH5, this point
26149 would typically be reload, so this target hook should be defined
26150 to a function such as:
26153 cannot_modify_jumps_past_reload_p ()
26155 return (reload_completed || reload_in_progress);
26158 -- Target Hook: int TARGET_BRANCH_TARGET_REGISTER_CLASS (void)
26159 This target hook returns a register class for which branch target
26160 register optimizations should be applied. All registers in this
26161 class should be usable interchangeably. After reload, registers
26162 in this class will be re-allocated and loads will be hoisted out
26163 of loops and be subjected to inter-block scheduling.
26165 -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool
26166 AFTER_PROLOGUE_EPILOGUE_GEN)
26167 Branch target register optimization will by default exclude
26168 callee-saved registers that are not already live during the
26169 current function; if this target hook returns true, they will be
26170 included. The target code must than make sure that all target
26171 registers in the class returned by
26172 `TARGET_BRANCH_TARGET_REGISTER_CLASS' that might need saving are
26173 saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates if prologues and
26174 epilogues have already been generated. Note, even if you only
26175 return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, you still
26176 are likely to have to make special provisions in
26177 `INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved
26180 -- Macro: POWI_MAX_MULTS
26181 If defined, this macro is interpreted as a signed integer C
26182 expression that specifies the maximum number of floating point
26183 multiplications that should be emitted when expanding
26184 exponentiation by an integer constant inline. When this value is
26185 defined, exponentiation requiring more than this number of
26186 multiplications is implemented by calling the system library's
26187 `pow', `powf' or `powl' routines. The default value places no
26188 upper bound on the multiplication count.
26190 -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char
26191 *IPREFIX, int STDINC)
26192 This target hook should register any extra include files for the
26193 target. The parameter STDINC indicates if normal include files
26194 are present. The parameter SYSROOT is the system root directory.
26195 The parameter IPREFIX is the prefix for the gcc directory.
26197 -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const
26198 char *IPREFIX, int STDINC)
26199 This target hook should register any extra include files for the
26200 target before any standard headers. The parameter STDINC
26201 indicates if normal include files are present. The parameter
26202 SYSROOT is the system root directory. The parameter IPREFIX is
26203 the prefix for the gcc directory.
26205 -- Macro: void TARGET_OPTF (char *PATH)
26206 This target hook should register special include paths for the
26207 target. The parameter PATH is the include to register. On Darwin
26208 systems, this is used for Framework includes, which have semantics
26209 that are different from `-I'.
26211 -- Target Hook: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL)
26212 This target hook returns `true' if it is safe to use a local alias
26213 for a virtual function FNDECL when constructing thunks, `false'
26214 otherwise. By default, the hook returns `true' for all functions,
26215 if a target supports aliases (i.e. defines `ASM_OUTPUT_DEF'),
26218 -- Macro: TARGET_FORMAT_TYPES
26219 If defined, this macro is the name of a global variable containing
26220 target-specific format checking information for the `-Wformat'
26221 option. The default is to have no target-specific format checks.
26223 -- Macro: TARGET_N_FORMAT_TYPES
26224 If defined, this macro is the number of entries in
26225 `TARGET_FORMAT_TYPES'.
26227 -- Target Hook: bool TARGET_RELAXED_ORDERING
26228 If set to `true', means that the target's memory model does not
26229 guarantee that loads which do not depend on one another will access
26230 main memory in the order of the instruction stream; if ordering is
26231 important, an explicit memory barrier must be used. This is true
26232 of many recent processors which implement a policy of "relaxed,"
26233 "weak," or "release" memory consistency, such as Alpha, PowerPC,
26234 and ia64. The default is `false'.
26236 -- Target Hook: const char *TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN
26237 (tree TYPELIST, tree FUNCDECL, tree VAL)
26238 If defined, this macro returns the diagnostic message when it is
26239 illegal to pass argument VAL to function FUNCDECL with prototype
26242 -- Target Hook: const char * TARGET_INVALID_CONVERSION (tree FROMTYPE,
26244 If defined, this macro returns the diagnostic message when it is
26245 invalid to convert from FROMTYPE to TOTYPE, or `NULL' if validity
26246 should be determined by the front end.
26248 -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, tree
26250 If defined, this macro returns the diagnostic message when it is
26251 invalid to apply operation OP (where unary plus is denoted by
26252 `CONVERT_EXPR') to an operand of type TYPE, or `NULL' if validity
26253 should be determined by the front end.
26255 -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, tree
26257 If defined, this macro returns the diagnostic message when it is
26258 invalid to apply operation OP to operands of types TYPE1 and
26259 TYPE2, or `NULL' if validity should be determined by the front end.
26261 -- Macro: TARGET_USE_JCR_SECTION
26262 This macro determines whether to use the JCR section to register
26263 Java classes. By default, TARGET_USE_JCR_SECTION is defined to 1
26264 if both SUPPORTS_WEAK and TARGET_HAVE_NAMED_SECTIONS are true,
26268 File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top
26270 15 Host Configuration
26271 *********************
26273 Most details about the machine and system on which the compiler is
26274 actually running are detected by the `configure' script. Some things
26275 are impossible for `configure' to detect; these are described in two
26276 ways, either by macros defined in a file named `xm-MACHINE.h' or by
26277 hook functions in the file specified by the OUT_HOST_HOOK_OBJ variable
26278 in `config.gcc'. (The intention is that very few hosts will need a
26279 header file but nearly every fully supported host will need to override
26282 If you need to define only a few macros, and they have simple
26283 definitions, consider using the `xm_defines' variable in your
26284 `config.gcc' entry instead of creating a host configuration header.
26285 *Note System Config::.
26289 * Host Common:: Things every host probably needs implemented.
26290 * Filesystem:: Your host can't have the letter `a' in filenames?
26291 * Host Misc:: Rare configuration options for hosts.
26294 File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config
26299 Some things are just not portable, even between similar operating
26300 systems, and are too difficult for autoconf to detect. They get
26301 implemented using hook functions in the file specified by the
26302 HOST_HOOK_OBJ variable in `config.gcc'.
26304 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void)
26305 This host hook is used to set up handling for extra signals. The
26306 most common thing to do in this hook is to detect stack overflow.
26308 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int
26310 This host hook returns the address of some space that is likely to
26311 be free in some subsequent invocation of the compiler. We intend
26312 to load the PCH data at this address such that the data need not
26313 be relocated. The area should be able to hold SIZE bytes. If the
26314 host uses `mmap', FD is an open file descriptor that can be used
26317 -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS,
26318 size_t SIZE, int FD, size_t OFFSET)
26319 This host hook is called when a PCH file is about to be loaded.
26320 We want to load SIZE bytes from FD at OFFSET into memory at
26321 ADDRESS. The given address will be the result of a previous
26322 invocation of `HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we
26323 couldn't allocate SIZE bytes at ADDRESS. Return 0 if the memory
26324 is allocated but the data is not loaded. Return 1 if the hook has
26325 performed everything.
26327 If the implementation uses reserved address space, free any
26328 reserved space beyond SIZE, regardless of the return value. If no
26329 PCH will be loaded, this hook may be called with SIZE zero, in
26330 which case all reserved address space should be freed.
26332 Do not try to handle values of ADDRESS that could not have been
26333 returned by this executable; just return -1. Such values usually
26334 indicate an out-of-date PCH file (built by some other GCC
26335 executable), and such a PCH file won't work.
26337 -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void);
26338 This host hook returns the alignment required for allocating
26339 virtual memory. Usually this is the same as getpagesize, but on
26340 some hosts the alignment for reserving memory differs from the
26341 pagesize for committing memory.
26344 File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config
26346 15.2 Host Filesystem
26347 ====================
26349 GCC needs to know a number of things about the semantics of the host
26350 machine's filesystem. Filesystems with Unix and MS-DOS semantics are
26351 automatically detected. For other systems, you can define the
26352 following macros in `xm-MACHINE.h'.
26354 `HAVE_DOS_BASED_FILE_SYSTEM'
26355 This macro is automatically defined by `system.h' if the host file
26356 system obeys the semantics defined by MS-DOS instead of Unix. DOS
26357 file systems are case insensitive, file specifications may begin
26358 with a drive letter, and both forward slash and backslash (`/' and
26359 `\') are directory separators.
26363 If defined, these macros expand to character constants specifying
26364 separators for directory names within a file specification.
26365 `system.h' will automatically give them appropriate values on Unix
26366 and MS-DOS file systems. If your file system is neither of these,
26367 define one or both appropriately in `xm-MACHINE.h'.
26369 However, operating systems like VMS, where constructing a pathname
26370 is more complicated than just stringing together directory names
26371 separated by a special character, should not define either of these
26375 If defined, this macro should expand to a character constant
26376 specifying the separator for elements of search paths. The default
26377 value is a colon (`:'). DOS-based systems usually, but not
26378 always, use semicolon (`;').
26381 Define this macro if the host system is VMS.
26383 `HOST_OBJECT_SUFFIX'
26384 Define this macro to be a C string representing the suffix for
26385 object files on your host machine. If you do not define this
26386 macro, GCC will use `.o' as the suffix for object files.
26388 `HOST_EXECUTABLE_SUFFIX'
26389 Define this macro to be a C string representing the suffix for
26390 executable files on your host machine. If you do not define this
26391 macro, GCC will use the null string as the suffix for executable
26395 A pathname defined by the host operating system, which can be
26396 opened as a file and written to, but all the information written
26397 is discarded. This is commonly known as a "bit bucket" or "null
26398 device". If you do not define this macro, GCC will use
26399 `/dev/null' as the bit bucket. If the host does not support a bit
26400 bucket, define this macro to an invalid filename.
26402 `UPDATE_PATH_HOST_CANONICALIZE (PATH)'
26403 If defined, a C statement (sans semicolon) that performs
26404 host-dependent canonicalization when a path used in a compilation
26405 driver or preprocessor is canonicalized. PATH is a malloc-ed path
26406 to be canonicalized. If the C statement does canonicalize PATH
26407 into a different buffer, the old path should be freed and the new
26408 buffer should have been allocated with malloc.
26411 Define this macro to be a C string representing the format to use
26412 for constructing the index part of debugging dump file names. The
26413 resultant string must fit in fifteen bytes. The full filename
26414 will be the concatenation of: the prefix of the assembler file
26415 name, the string resulting from applying this format to an index
26416 number, and a string unique to each dump file kind, e.g. `rtl'.
26418 If you do not define this macro, GCC will use `.%02d.'. You should
26419 define this macro if using the default will create an invalid file
26422 `DELETE_IF_ORDINARY'
26423 Define this macro to be a C statement (sans semicolon) that
26424 performs host-dependent removal of ordinary temp files in the
26425 compilation driver.
26427 If you do not define this macro, GCC will use the default version.
26428 You should define this macro if the default version does not
26429 reliably remove the temp file as, for example, on VMS which allows
26430 multiple versions of a file.
26432 `HOST_LACKS_INODE_NUMBERS'
26433 Define this macro if the host filesystem does not report
26434 meaningful inode numbers in struct stat.
26437 File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config
26443 A C expression for the status code to be returned when the compiler
26444 exits after serious errors. The default is the system-provided
26445 macro `EXIT_FAILURE', or `1' if the system doesn't define that
26446 macro. Define this macro only if these defaults are incorrect.
26448 `SUCCESS_EXIT_CODE'
26449 A C expression for the status code to be returned when the compiler
26450 exits without serious errors. (Warnings are not serious errors.)
26451 The default is the system-provided macro `EXIT_SUCCESS', or `0' if
26452 the system doesn't define that macro. Define this macro only if
26453 these defaults are incorrect.
26456 Define this macro if GCC should use the C implementation of
26457 `alloca' provided by `libiberty.a'. This only affects how some
26458 parts of the compiler itself allocate memory. It does not change
26461 When GCC is built with a compiler other than itself, the C `alloca'
26462 is always used. This is because most other implementations have
26463 serious bugs. You should define this macro only on a system where
26464 no stack-based `alloca' can possibly work. For instance, if a
26465 system has a small limit on the size of the stack, GCC's builtin
26466 `alloca' will not work reliably.
26468 `COLLECT2_HOST_INITIALIZATION'
26469 If defined, a C statement (sans semicolon) that performs
26470 host-dependent initialization when `collect2' is being initialized.
26472 `GCC_DRIVER_HOST_INITIALIZATION'
26473 If defined, a C statement (sans semicolon) that performs
26474 host-dependent initialization when a compilation driver is being
26478 Define this macro if the host system has a small limit on the total
26479 size of an argument vector. This causes the driver to take more
26480 care not to pass unnecessary arguments to subprocesses.
26482 `HOST_LONG_LONG_FORMAT'
26483 If defined, the string used to indicate an argument of type `long
26484 long' to functions like `printf'. The default value is `"ll"'.
26486 In addition, if `configure' generates an incorrect definition of any
26487 of the macros in `auto-host.h', you can override that definition in a
26488 host configuration header. If you need to do this, first see if it is
26489 possible to fix `configure'.
26492 File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top
26494 16 Makefile Fragments
26495 *********************
26497 When you configure GCC using the `configure' script, it will construct
26498 the file `Makefile' from the template file `Makefile.in'. When it does
26499 this, it can incorporate makefile fragments from the `config'
26500 directory. These are used to set Makefile parameters that are not
26501 amenable to being calculated by autoconf. The list of fragments to
26502 incorporate is set by `config.gcc' (and occasionally `config.build' and
26503 `config.host'); *Note System Config::.
26505 Fragments are named either `t-TARGET' or `x-HOST', depending on
26506 whether they are relevant to configuring GCC to produce code for a
26507 particular target, or to configuring GCC to run on a particular host.
26508 Here TARGET and HOST are mnemonics which usually have some relationship
26509 to the canonical system name, but no formal connection.
26511 If these files do not exist, it means nothing needs to be added for a
26512 given target or host. Most targets need a few `t-TARGET' fragments,
26513 but needing `x-HOST' fragments is rare.
26517 * Target Fragment:: Writing `t-TARGET' files.
26518 * Host Fragment:: Writing `x-HOST' files.
26521 File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments
26523 16.1 Target Makefile Fragments
26524 ==============================
26526 Target makefile fragments can set these Makefile variables.
26529 Compiler flags to use when compiling `libgcc2.c'.
26532 A list of source file names to be compiled or assembled and
26533 inserted into `libgcc.a'.
26535 `Floating Point Emulation'
26536 To have GCC include software floating point libraries in `libgcc.a'
26537 define `FPBIT' and `DPBIT' along with a few rules as follows:
26538 # We want fine grained libraries, so use the new code
26539 # to build the floating point emulation libraries.
26544 fp-bit.c: $(srcdir)/config/fp-bit.c
26545 echo '#define FLOAT' > fp-bit.c
26546 cat $(srcdir)/config/fp-bit.c >> fp-bit.c
26548 dp-bit.c: $(srcdir)/config/fp-bit.c
26549 cat $(srcdir)/config/fp-bit.c > dp-bit.c
26551 You may need to provide additional #defines at the beginning of
26552 `fp-bit.c' and `dp-bit.c' to control target endianness and other
26555 `CRTSTUFF_T_CFLAGS'
26556 Special flags used when compiling `crtstuff.c'. *Note
26559 `CRTSTUFF_T_CFLAGS_S'
26560 Special flags used when compiling `crtstuff.c' for shared linking.
26561 Used if you use `crtbeginS.o' and `crtendS.o' in `EXTRA-PARTS'.
26562 *Note Initialization::.
26565 For some targets, invoking GCC in different ways produces objects
26566 that can not be linked together. For example, for some targets GCC
26567 produces both big and little endian code. For these targets, you
26568 must arrange for multiple versions of `libgcc.a' to be compiled,
26569 one for each set of incompatible options. When GCC invokes the
26570 linker, it arranges to link in the right version of `libgcc.a',
26571 based on the command line options used.
26573 The `MULTILIB_OPTIONS' macro lists the set of options for which
26574 special versions of `libgcc.a' must be built. Write options that
26575 are mutually incompatible side by side, separated by a slash.
26576 Write options that may be used together separated by a space. The
26577 build procedure will build all combinations of compatible options.
26579 For example, if you set `MULTILIB_OPTIONS' to `m68000/m68020
26580 msoft-float', `Makefile' will build special versions of `libgcc.a'
26581 using the following sets of options: `-m68000', `-m68020',
26582 `-msoft-float', `-m68000 -msoft-float', and `-m68020 -msoft-float'.
26584 `MULTILIB_DIRNAMES'
26585 If `MULTILIB_OPTIONS' is used, this variable specifies the
26586 directory names that should be used to hold the various libraries.
26587 Write one element in `MULTILIB_DIRNAMES' for each element in
26588 `MULTILIB_OPTIONS'. If `MULTILIB_DIRNAMES' is not used, the
26589 default value will be `MULTILIB_OPTIONS', with all slashes treated
26592 For example, if `MULTILIB_OPTIONS' is set to `m68000/m68020
26593 msoft-float', then the default value of `MULTILIB_DIRNAMES' is
26594 `m68000 m68020 msoft-float'. You may specify a different value if
26595 you desire a different set of directory names.
26598 Sometimes the same option may be written in two different ways.
26599 If an option is listed in `MULTILIB_OPTIONS', GCC needs to know
26600 about any synonyms. In that case, set `MULTILIB_MATCHES' to a
26601 list of items of the form `option=option' to describe all relevant
26602 synonyms. For example, `m68000=mc68000 m68020=mc68020'.
26604 `MULTILIB_EXCEPTIONS'
26605 Sometimes when there are multiple sets of `MULTILIB_OPTIONS' being
26606 specified, there are combinations that should not be built. In
26607 that case, set `MULTILIB_EXCEPTIONS' to be all of the switch
26608 exceptions in shell case syntax that should not be built.
26610 For example the ARM processor cannot execute both hardware floating
26611 point instructions and the reduced size THUMB instructions at the
26612 same time, so there is no need to build libraries with both of
26613 these options enabled. Therefore `MULTILIB_EXCEPTIONS' is set to:
26614 *mthumb/*mhard-float*
26616 `MULTILIB_EXTRA_OPTS'
26617 Sometimes it is desirable that when building multiple versions of
26618 `libgcc.a' certain options should always be passed on to the
26619 compiler. In that case, set `MULTILIB_EXTRA_OPTS' to be the list
26620 of options to be used for all builds. If you set this, you should
26621 probably set `CRTSTUFF_T_CFLAGS' to a dash followed by it.
26623 `NATIVE_SYSTEM_HEADER_DIR'
26624 If the default location for system headers is not `/usr/include',
26625 you must set this to the directory containing the headers. This
26626 value should match the value of the `SYSTEM_INCLUDE_DIR' macro.
26629 Unfortunately, setting `MULTILIB_EXTRA_OPTS' is not enough, since
26630 it does not affect the build of target libraries, at least not the
26631 build of the default multilib. One possible work-around is to use
26632 `DRIVER_SELF_SPECS' to bring options from the `specs' file as if
26633 they had been passed in the compiler driver command line.
26634 However, you don't want to be adding these options after the
26635 toolchain is installed, so you can instead tweak the `specs' file
26636 that will be used during the toolchain build, while you still
26637 install the original, built-in `specs'. The trick is to set
26638 `SPECS' to some other filename (say `specs.install'), that will
26639 then be created out of the built-in specs, and introduce a
26640 `Makefile' rule to generate the `specs' file that's going to be
26641 used at build time out of your `specs.install'.
26644 File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments
26646 16.2 Host Makefile Fragments
26647 ============================
26649 The use of `x-HOST' fragments is discouraged. You should do so only if
26650 there is no other mechanism to get the behavior desired. Host
26651 fragments should never forcibly override variables set by the configure
26652 script, as they may have been adjusted by the user.
26654 Variables provided for host fragments to set include:
26658 These are extra flags to pass to the C compiler and preprocessor,
26659 respectively. They are used both when building GCC, and when
26660 compiling things with the just-built GCC.
26663 These are extra flags to use when building the compiler. They are
26664 not used when compiling `libgcc.a'. However, they _are_ used when
26665 recompiling the compiler with itself in later stages of a
26669 Flags to be passed to the linker when recompiling the compiler with
26670 itself in later stages of a bootstrap. You might need to use this
26671 if, for instance, one of the front ends needs more text space than
26672 the linker provides by default.
26675 A list of additional programs required to use the compiler on this
26676 host, which should be compiled with GCC and installed alongside
26677 the front ends. If you set this variable, you must also provide
26678 rules to build the extra programs.
26682 File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top
26687 GCC uses a utility called `collect2' on nearly all systems to arrange
26688 to call various initialization functions at start time.
26690 The program `collect2' works by linking the program once and looking
26691 through the linker output file for symbols with particular names
26692 indicating they are constructor functions. If it finds any, it creates
26693 a new temporary `.c' file containing a table of them, compiles it, and
26694 links the program a second time including that file.
26696 The actual calls to the constructors are carried out by a subroutine
26697 called `__main', which is called (automatically) at the beginning of
26698 the body of `main' (provided `main' was compiled with GNU CC). Calling
26699 `__main' is necessary, even when compiling C code, to allow linking C
26700 and C++ object code together. (If you use `-nostdlib', you get an
26701 unresolved reference to `__main', since it's defined in the standard
26702 GCC library. Include `-lgcc' at the end of your compiler command line
26703 to resolve this reference.)
26705 The program `collect2' is installed as `ld' in the directory where the
26706 passes of the compiler are installed. When `collect2' needs to find
26707 the _real_ `ld', it tries the following file names:
26709 * `real-ld' in the directories listed in the compiler's search
26712 * `real-ld' in the directories listed in the environment variable
26715 * The file specified in the `REAL_LD_FILE_NAME' configuration macro,
26718 * `ld' in the compiler's search directories, except that `collect2'
26719 will not execute itself recursively.
26723 "The compiler's search directories" means all the directories where
26724 `gcc' searches for passes of the compiler. This includes directories
26725 that you specify with `-B'.
26727 Cross-compilers search a little differently:
26729 * `real-ld' in the compiler's search directories.
26731 * `TARGET-real-ld' in `PATH'.
26733 * The file specified in the `REAL_LD_FILE_NAME' configuration macro,
26736 * `ld' in the compiler's search directories.
26738 * `TARGET-ld' in `PATH'.
26740 `collect2' explicitly avoids running `ld' using the file name under
26741 which `collect2' itself was invoked. In fact, it remembers up a list
26742 of such names--in case one copy of `collect2' finds another copy (or
26743 version) of `collect2' installed as `ld' in a second place in the
26746 `collect2' searches for the utilities `nm' and `strip' using the same
26747 algorithm as above for `ld'.
26750 File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top
26752 18 Standard Header File Directories
26753 ***********************************
26755 `GCC_INCLUDE_DIR' means the same thing for native and cross. It is
26756 where GCC stores its private include files, and also where GCC stores
26757 the fixed include files. A cross compiled GCC runs `fixincludes' on
26758 the header files in `$(tooldir)/include'. (If the cross compilation
26759 header files need to be fixed, they must be installed before GCC is
26760 built. If the cross compilation header files are already suitable for
26761 GCC, nothing special need be done).
26763 `GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It
26764 is where `g++' looks first for header files. The C++ library installs
26765 only target independent header files in that directory.
26767 `LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't
26768 install anything there. It is normally `/usr/local/include'. This is
26769 where local additions to a packaged system should place header files.
26771 `CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't
26772 install anything there.
26774 `TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is
26775 the place for other packages to install header files that GCC will use.
26776 For a cross-compiler, this is the equivalent of `/usr/include'. When
26777 you build a cross-compiler, `fixincludes' processes any header files in
26781 File: gccint.info, Node: Type Information, Next: Funding, Prev: Header Dirs, Up: Top
26783 19 Memory Management and Type Information
26784 *****************************************
26786 GCC uses some fairly sophisticated memory management techniques, which
26787 involve determining information about GCC's data structures from GCC's
26788 source code and using this information to perform garbage collection and
26789 implement precompiled headers.
26791 A full C parser would be too complicated for this task, so a limited
26792 subset of C is interpreted and special markers are used to determine
26793 what parts of the source to look at. All `struct' and `union'
26794 declarations that define data structures that are allocated under
26795 control of the garbage collector must be marked. All global variables
26796 that hold pointers to garbage-collected memory must also be marked.
26797 Finally, all global variables that need to be saved and restored by a
26798 precompiled header must be marked. (The precompiled header mechanism
26799 can only save static variables if they're scalar. Complex data
26800 structures must be allocated in garbage-collected memory to be saved in
26801 a precompiled header.)
26803 The full format of a marker is
26804 GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...))
26805 but in most cases no options are needed. The outer double parentheses
26806 are still necessary, though: `GTY(())'. Markers can appear:
26808 * In a structure definition, before the open brace;
26810 * In a global variable declaration, after the keyword `static' or
26813 * In a structure field definition, before the name of the field.
26815 Here are some examples of marking simple data structures and globals.
26822 typedef struct TAG GTY(())
26827 static GTY(()) struct TAG *LIST; /* points to GC memory */
26828 static GTY(()) int COUNTER; /* save counter in a PCH */
26830 The parser understands simple typedefs such as `typedef struct TAG
26831 *NAME;' and `typedef int NAME;'. These don't need to be marked.
26835 * GTY Options:: What goes inside a `GTY(())'.
26836 * GGC Roots:: Making global variables GGC roots.
26837 * Files:: How the generated files work.
26840 File: gccint.info, Node: GTY Options, Next: GGC Roots, Up: Type Information
26842 19.1 The Inside of a `GTY(())'
26843 ==============================
26845 Sometimes the C code is not enough to fully describe the type
26846 structure. Extra information can be provided with `GTY' options and
26847 additional markers. Some options take a parameter, which may be either
26848 a string or a type name, depending on the parameter. If an option
26849 takes no parameter, it is acceptable either to omit the parameter
26850 entirely, or to provide an empty string as a parameter. For example,
26851 `GTY ((skip))' and `GTY ((skip ("")))' are equivalent.
26853 When the parameter is a string, often it is a fragment of C code. Four
26854 special escapes may be used in these strings, to refer to pieces of the
26855 data structure being marked:
26858 The current structure.
26861 The structure that immediately contains the current structure.
26864 The outermost structure that contains the current structure.
26867 A partial expression of the form `[i1][i2]...' that indexes the
26868 array item currently being marked.
26870 For instance, suppose that you have a structure of the form
26877 and `b' is a variable of type `struct B'. When marking `b.foo[11]',
26878 `%h' would expand to `b.foo[11]', `%0' and `%1' would both expand to
26879 `b', and `%a' would expand to `[11]'.
26881 As in ordinary C, adjacent strings will be concatenated; this is
26882 helpful when you have a complicated expression.
26883 GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE"
26884 " ? TYPE_NEXT_VARIANT (&%h.generic)"
26885 " : TREE_CHAIN (&%h.generic)")))
26887 The available options are:
26889 `length ("EXPRESSION")'
26890 There are two places the type machinery will need to be explicitly
26891 told the length of an array. The first case is when a structure
26892 ends in a variable-length array, like this:
26893 struct rtvec_def GTY(()) {
26894 int num_elem; /* number of elements */
26895 rtx GTY ((length ("%h.num_elem"))) elem[1];
26898 In this case, the `length' option is used to override the specified
26899 array length (which should usually be `1'). The parameter of the
26900 option is a fragment of C code that calculates the length.
26902 The second case is when a structure or a global variable contains a
26903 pointer to an array, like this:
26905 GTY ((length ("%h.regno_pointer_align_length"))) regno_decl;
26906 In this case, `regno_decl' has been allocated by writing something
26909 ggc_alloc (x->regno_pointer_align_length * sizeof (tree));
26910 and the `length' provides the length of the field.
26912 This second use of `length' also works on global variables, like:
26913 static GTY((length ("reg_base_value_size")))
26914 rtx *reg_base_value;
26917 If `skip' is applied to a field, the type machinery will ignore it.
26918 This is somewhat dangerous; the only safe use is in a union when
26919 one field really isn't ever used.
26921 `desc ("EXPRESSION")'
26924 The type machinery needs to be told which field of a `union' is
26925 currently active. This is done by giving each field a constant
26926 `tag' value, and then specifying a discriminator using `desc'.
26927 The value of the expression given by `desc' is compared against
26928 each `tag' value, each of which should be different. If no `tag'
26929 is matched, the field marked with `default' is used if there is
26930 one, otherwise no field in the union will be marked.
26932 In the `desc' option, the "current structure" is the union that it
26933 discriminates. Use `%1' to mean the structure containing it.
26934 There are no escapes available to the `tag' option, since it is a
26938 struct tree_binding GTY(())
26940 struct tree_common common;
26941 union tree_binding_u {
26942 tree GTY ((tag ("0"))) scope;
26943 struct cp_binding_level * GTY ((tag ("1"))) level;
26944 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope;
26948 In this example, the value of BINDING_HAS_LEVEL_P when applied to a
26949 `struct tree_binding *' is presumed to be 0 or 1. If 1, the type
26950 mechanism will treat the field `level' as being present and if 0,
26951 will treat the field `scope' as being present.
26955 Sometimes it's convenient to define some data structure to work on
26956 generic pointers (that is, `PTR') and then use it with a specific
26957 type. `param_is' specifies the real type pointed to, and
26958 `use_param' says where in the generic data structure that type
26961 For instance, to have a `htab_t' that points to trees, one would
26962 write the definition of `htab_t' like this:
26963 typedef struct GTY(()) {
26965 void ** GTY ((use_param, ...)) entries;
26968 and then declare variables like this:
26969 static htab_t GTY ((param_is (union tree_node))) ict;
26973 In more complicated cases, the data structure might need to work on
26974 several different types, which might not necessarily all be
26975 pointers. For this, `param1_is' through `param9_is' may be used to
26976 specify the real type of a field identified by `use_param1' through
26980 When a structure contains another structure that is parameterized,
26981 there's no need to do anything special, the inner structure
26982 inherits the parameters of the outer one. When a structure
26983 contains a pointer to a parameterized structure, the type
26984 machinery won't automatically detect this (it could, it just
26985 doesn't yet), so it's necessary to tell it that the pointed-to
26986 structure should use the same parameters as the outer structure.
26987 This is done by marking the pointer with the `use_params' option.
26990 `deletable', when applied to a global variable, indicates that when
26991 garbage collection runs, there's no need to mark anything pointed
26992 to by this variable, it can just be set to `NULL' instead. This
26993 is used to keep a list of free structures around for re-use.
26995 `if_marked ("EXPRESSION")'
26996 Suppose you want some kinds of object to be unique, and so you put
26997 them in a hash table. If garbage collection marks the hash table,
26998 these objects will never be freed, even if the last other
26999 reference to them goes away. GGC has special handling to deal
27000 with this: if you use the `if_marked' option on a global hash
27001 table, GGC will call the routine whose name is the parameter to
27002 the option on each hash table entry. If the routine returns
27003 nonzero, the hash table entry will be marked as usual. If the
27004 routine returns zero, the hash table entry will be deleted.
27006 The routine `ggc_marked_p' can be used to determine if an element
27007 has been marked already; in fact, the usual case is to use
27008 `if_marked ("ggc_marked_p")'.
27011 When applied to a field, `maybe_undef' indicates that it's OK if
27012 the structure that this fields points to is never defined, so long
27013 as this field is always `NULL'. This is used to avoid requiring
27014 backends to define certain optional structures. It doesn't work
27015 with language frontends.
27017 `nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")'
27018 The type machinery expects all pointers to point to the start of an
27019 object. Sometimes for abstraction purposes it's convenient to have
27020 a pointer which points inside an object. So long as it's possible
27021 to convert the original object to and from the pointer, such
27022 pointers can still be used. TYPE is the type of the original
27023 object, the TO EXPRESSION returns the pointer given the original
27024 object, and the FROM EXPRESSION returns the original object given
27025 the pointer. The pointer will be available using the `%h' escape.
27027 `chain_next ("EXPRESSION")'
27028 `chain_prev ("EXPRESSION")'
27029 It's helpful for the type machinery to know if objects are often
27030 chained together in long lists; this lets it generate code that
27031 uses less stack space by iterating along the list instead of
27032 recursing down it. `chain_next' is an expression for the next
27033 item in the list, `chain_prev' is an expression for the previous
27034 item. For singly linked lists, use only `chain_next'; for doubly
27035 linked lists, use both. The machinery requires that taking the
27036 next item of the previous item gives the original item.
27038 `reorder ("FUNCTION NAME")'
27039 Some data structures depend on the relative ordering of pointers.
27040 If the precompiled header machinery needs to change that ordering,
27041 it will call the function referenced by the `reorder' option,
27042 before changing the pointers in the object that's pointed to by
27043 the field the option applies to. The function must take four
27044 arguments, with the signature
27045 `void *, void *, gt_pointer_operator, void *'. The first
27046 parameter is a pointer to the structure that contains the object
27047 being updated, or the object itself if there is no containing
27048 structure. The second parameter is a cookie that should be
27049 ignored. The third parameter is a routine that, given a pointer,
27050 will update it to its correct new value. The fourth parameter is
27051 a cookie that must be passed to the second parameter.
27053 PCH cannot handle data structures that depend on the absolute
27054 values of pointers. `reorder' functions can be expensive. When
27055 possible, it is better to depend on properties of the data, like
27056 an ID number or the hash of a string instead.
27059 The `special' option is used to mark types that have to be dealt
27060 with by special case machinery. The parameter is the name of the
27061 special case. See `gengtype.c' for further details. Avoid adding
27062 new special cases unless there is no other alternative.
27065 File: gccint.info, Node: GGC Roots, Next: Files, Prev: GTY Options, Up: Type Information
27067 19.2 Marking Roots for the Garbage Collector
27068 ============================================
27070 In addition to keeping track of types, the type machinery also locates
27071 the global variables ("roots") that the garbage collector starts at.
27072 Roots must be declared using one of the following syntaxes:
27074 * `extern GTY(([OPTIONS])) TYPE NAME;'
27076 * `static GTY(([OPTIONS])) TYPE NAME;'
27078 * `GTY(([OPTIONS])) TYPE NAME;'
27079 is _not_ accepted. There should be an `extern' declaration of such a
27080 variable in a header somewhere--mark that, not the definition. Or, if
27081 the variable is only used in one file, make it `static'.
27084 File: gccint.info, Node: Files, Prev: GGC Roots, Up: Type Information
27086 19.3 Source Files Containing Type Information
27087 =============================================
27089 Whenever you add `GTY' markers to a source file that previously had
27090 none, or create a new source file containing `GTY' markers, there are
27091 three things you need to do:
27093 1. You need to add the file to the list of source files the type
27094 machinery scans. There are four cases:
27096 a. For a back-end file, this is usually done automatically; if
27097 not, you should add it to `target_gtfiles' in the appropriate
27098 port's entries in `config.gcc'.
27100 b. For files shared by all front ends, add the filename to the
27101 `GTFILES' variable in `Makefile.in'.
27103 c. For files that are part of one front end, add the filename to
27104 the `gtfiles' variable defined in the appropriate
27105 `config-lang.in'. For C, the file is `c-config-lang.in'.
27107 d. For files that are part of some but not all front ends, add
27108 the filename to the `gtfiles' variable of _all_ the front ends
27111 2. If the file was a header file, you'll need to check that it's
27112 included in the right place to be visible to the generated files.
27113 For a back-end header file, this should be done automatically.
27114 For a front-end header file, it needs to be included by the same
27115 file that includes `gtype-LANG.h'. For other header files, it
27116 needs to be included in `gtype-desc.c', which is a generated file,
27117 so add it to `ifiles' in `open_base_file' in `gengtype.c'.
27119 For source files that aren't header files, the machinery will
27120 generate a header file that should be included in the source file
27121 you just changed. The file will be called `gt-PATH.h' where PATH
27122 is the pathname relative to the `gcc' directory with slashes
27123 replaced by -, so for example the header file to be included in
27124 `cp/parser.c' is called `gt-cp-parser.c'. The generated header
27125 file should be included after everything else in the source file.
27126 Don't forget to mention this file as a dependency in the
27129 3. If a new `gt-PATH.h' file is needed, you need to arrange to add a
27130 `Makefile' rule that will ensure this file can be built. This is
27131 done by making it a dependency of `s-gtype', like this:
27132 gt-path.h : s-gtype ; @true
27134 For language frontends, there is another file that needs to be included
27135 somewhere. It will be called `gtype-LANG.h', where LANG is the name of
27136 the subdirectory the language is contained in. It will need `Makefile'
27137 rules just like the other generated files.
27140 File: gccint.info, Node: Funding, Next: GNU Project, Prev: Type Information, Up: Top
27142 Funding Free Software
27143 *********************
27145 If you want to have more free software a few years from now, it makes
27146 sense for you to help encourage people to contribute funds for its
27147 development. The most effective approach known is to encourage
27148 commercial redistributors to donate.
27150 Users of free software systems can boost the pace of development by
27151 encouraging for-a-fee distributors to donate part of their selling price
27152 to free software developers--the Free Software Foundation, and others.
27154 The way to convince distributors to do this is to demand it and expect
27155 it from them. So when you compare distributors, judge them partly by
27156 how much they give to free software development. Show distributors
27157 they must compete to be the one who gives the most.
27159 To make this approach work, you must insist on numbers that you can
27160 compare, such as, "We will donate ten dollars to the Frobnitz project
27161 for each disk sold." Don't be satisfied with a vague promise, such as
27162 "A portion of the profits are donated," since it doesn't give a basis
27165 Even a precise fraction "of the profits from this disk" is not very
27166 meaningful, since creative accounting and unrelated business decisions
27167 can greatly alter what fraction of the sales price counts as profit.
27168 If the price you pay is $50, ten percent of the profit is probably less
27169 than a dollar; it might be a few cents, or nothing at all.
27171 Some redistributors do development work themselves. This is useful
27172 too; but to keep everyone honest, you need to inquire how much they do,
27173 and what kind. Some kinds of development make much more long-term
27174 difference than others. For example, maintaining a separate version of
27175 a program contributes very little; maintaining the standard version of a
27176 program for the whole community contributes much. Easy new ports
27177 contribute little, since someone else would surely do them; difficult
27178 ports such as adding a new CPU to the GNU Compiler Collection
27179 contribute more; major new features or packages contribute the most.
27181 By establishing the idea that supporting further development is "the
27182 proper thing to do" when distributing free software for a fee, we can
27183 assure a steady flow of resources into making more free software.
27185 Copyright (C) 1994 Free Software Foundation, Inc.
27186 Verbatim copying and redistribution of this section is permitted
27187 without royalty; alteration is not permitted.
27190 File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top
27192 The GNU Project and GNU/Linux
27193 *****************************
27195 The GNU Project was launched in 1984 to develop a complete Unix-like
27196 operating system which is free software: the GNU system. (GNU is a
27197 recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".)
27198 Variants of the GNU operating system, which use the kernel Linux, are
27199 now widely used; though these systems are often referred to as "Linux",
27200 they are more accurately called GNU/Linux systems.
27202 For more information, see:
27203 `http://www.gnu.org/'
27204 `http://www.gnu.org/gnu/linux-and-gnu.html'
27207 File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top
27209 GNU GENERAL PUBLIC LICENSE
27210 **************************
27212 Version 2, June 1991
27214 Copyright (C) 1989, 1991 Free Software Foundation, Inc.
27215 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
27217 Everyone is permitted to copy and distribute verbatim copies
27218 of this license document, but changing it is not allowed.
27223 The licenses for most software are designed to take away your freedom
27224 to share and change it. By contrast, the GNU General Public License is
27225 intended to guarantee your freedom to share and change free
27226 software--to make sure the software is free for all its users. This
27227 General Public License applies to most of the Free Software
27228 Foundation's software and to any other program whose authors commit to
27229 using it. (Some other Free Software Foundation software is covered by
27230 the GNU Library General Public License instead.) You can apply it to
27231 your programs, too.
27233 When we speak of free software, we are referring to freedom, not
27234 price. Our General Public Licenses are designed to make sure that you
27235 have the freedom to distribute copies of free software (and charge for
27236 this service if you wish), that you receive source code or can get it
27237 if you want it, that you can change the software or use pieces of it in
27238 new free programs; and that you know you can do these things.
27240 To protect your rights, we need to make restrictions that forbid
27241 anyone to deny you these rights or to ask you to surrender the rights.
27242 These restrictions translate to certain responsibilities for you if you
27243 distribute copies of the software, or if you modify it.
27245 For example, if you distribute copies of such a program, whether
27246 gratis or for a fee, you must give the recipients all the rights that
27247 you have. You must make sure that they, too, receive or can get the
27248 source code. And you must show them these terms so they know their
27251 We protect your rights with two steps: (1) copyright the software, and
27252 (2) offer you this license which gives you legal permission to copy,
27253 distribute and/or modify the software.
27255 Also, for each author's protection and ours, we want to make certain
27256 that everyone understands that there is no warranty for this free
27257 software. If the software is modified by someone else and passed on, we
27258 want its recipients to know that what they have is not the original, so
27259 that any problems introduced by others will not reflect on the original
27260 authors' reputations.
27262 Finally, any free program is threatened constantly by software
27263 patents. We wish to avoid the danger that redistributors of a free
27264 program will individually obtain patent licenses, in effect making the
27265 program proprietary. To prevent this, we have made it clear that any
27266 patent must be licensed for everyone's free use or not licensed at all.
27268 The precise terms and conditions for copying, distribution and
27269 modification follow.
27271 TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
27272 0. This License applies to any program or other work which contains a
27273 notice placed by the copyright holder saying it may be distributed
27274 under the terms of this General Public License. The "Program",
27275 below, refers to any such program or work, and a "work based on
27276 the Program" means either the Program or any derivative work under
27277 copyright law: that is to say, a work containing the Program or a
27278 portion of it, either verbatim or with modifications and/or
27279 translated into another language. (Hereinafter, translation is
27280 included without limitation in the term "modification".) Each
27281 licensee is addressed as "you".
27283 Activities other than copying, distribution and modification are
27284 not covered by this License; they are outside its scope. The act
27285 of running the Program is not restricted, and the output from the
27286 Program is covered only if its contents constitute a work based on
27287 the Program (independent of having been made by running the
27288 Program). Whether that is true depends on what the Program does.
27290 1. You may copy and distribute verbatim copies of the Program's
27291 source code as you receive it, in any medium, provided that you
27292 conspicuously and appropriately publish on each copy an appropriate
27293 copyright notice and disclaimer of warranty; keep intact all the
27294 notices that refer to this License and to the absence of any
27295 warranty; and give any other recipients of the Program a copy of
27296 this License along with the Program.
27298 You may charge a fee for the physical act of transferring a copy,
27299 and you may at your option offer warranty protection in exchange
27302 2. You may modify your copy or copies of the Program or any portion
27303 of it, thus forming a work based on the Program, and copy and
27304 distribute such modifications or work under the terms of Section 1
27305 above, provided that you also meet all of these conditions:
27307 a. You must cause the modified files to carry prominent notices
27308 stating that you changed the files and the date of any change.
27310 b. You must cause any work that you distribute or publish, that
27311 in whole or in part contains or is derived from the Program
27312 or any part thereof, to be licensed as a whole at no charge
27313 to all third parties under the terms of this License.
27315 c. If the modified program normally reads commands interactively
27316 when run, you must cause it, when started running for such
27317 interactive use in the most ordinary way, to print or display
27318 an announcement including an appropriate copyright notice and
27319 a notice that there is no warranty (or else, saying that you
27320 provide a warranty) and that users may redistribute the
27321 program under these conditions, and telling the user how to
27322 view a copy of this License. (Exception: if the Program
27323 itself is interactive but does not normally print such an
27324 announcement, your work based on the Program is not required
27325 to print an announcement.)
27327 These requirements apply to the modified work as a whole. If
27328 identifiable sections of that work are not derived from the
27329 Program, and can be reasonably considered independent and separate
27330 works in themselves, then this License, and its terms, do not
27331 apply to those sections when you distribute them as separate
27332 works. But when you distribute the same sections as part of a
27333 whole which is a work based on the Program, the distribution of
27334 the whole must be on the terms of this License, whose permissions
27335 for other licensees extend to the entire whole, and thus to each
27336 and every part regardless of who wrote it.
27338 Thus, it is not the intent of this section to claim rights or
27339 contest your rights to work written entirely by you; rather, the
27340 intent is to exercise the right to control the distribution of
27341 derivative or collective works based on the Program.
27343 In addition, mere aggregation of another work not based on the
27344 Program with the Program (or with a work based on the Program) on
27345 a volume of a storage or distribution medium does not bring the
27346 other work under the scope of this License.
27348 3. You may copy and distribute the Program (or a work based on it,
27349 under Section 2) in object code or executable form under the terms
27350 of Sections 1 and 2 above provided that you also do one of the
27353 a. Accompany it with the complete corresponding machine-readable
27354 source code, which must be distributed under the terms of
27355 Sections 1 and 2 above on a medium customarily used for
27356 software interchange; or,
27358 b. Accompany it with a written offer, valid for at least three
27359 years, to give any third party, for a charge no more than your
27360 cost of physically performing source distribution, a complete
27361 machine-readable copy of the corresponding source code, to be
27362 distributed under the terms of Sections 1 and 2 above on a
27363 medium customarily used for software interchange; or,
27365 c. Accompany it with the information you received as to the offer
27366 to distribute corresponding source code. (This alternative is
27367 allowed only for noncommercial distribution and only if you
27368 received the program in object code or executable form with
27369 such an offer, in accord with Subsection b above.)
27371 The source code for a work means the preferred form of the work for
27372 making modifications to it. For an executable work, complete
27373 source code means all the source code for all modules it contains,
27374 plus any associated interface definition files, plus the scripts
27375 used to control compilation and installation of the executable.
27376 However, as a special exception, the source code distributed need
27377 not include anything that is normally distributed (in either
27378 source or binary form) with the major components (compiler,
27379 kernel, and so on) of the operating system on which the executable
27380 runs, unless that component itself accompanies the executable.
27382 If distribution of executable or object code is made by offering
27383 access to copy from a designated place, then offering equivalent
27384 access to copy the source code from the same place counts as
27385 distribution of the source code, even though third parties are not
27386 compelled to copy the source along with the object code.
27388 4. You may not copy, modify, sublicense, or distribute the Program
27389 except as expressly provided under this License. Any attempt
27390 otherwise to copy, modify, sublicense or distribute the Program is
27391 void, and will automatically terminate your rights under this
27392 License. However, parties who have received copies, or rights,
27393 from you under this License will not have their licenses
27394 terminated so long as such parties remain in full compliance.
27396 5. You are not required to accept this License, since you have not
27397 signed it. However, nothing else grants you permission to modify
27398 or distribute the Program or its derivative works. These actions
27399 are prohibited by law if you do not accept this License.
27400 Therefore, by modifying or distributing the Program (or any work
27401 based on the Program), you indicate your acceptance of this
27402 License to do so, and all its terms and conditions for copying,
27403 distributing or modifying the Program or works based on it.
27405 6. Each time you redistribute the Program (or any work based on the
27406 Program), the recipient automatically receives a license from the
27407 original licensor to copy, distribute or modify the Program
27408 subject to these terms and conditions. You may not impose any
27409 further restrictions on the recipients' exercise of the rights
27410 granted herein. You are not responsible for enforcing compliance
27411 by third parties to this License.
27413 7. If, as a consequence of a court judgment or allegation of patent
27414 infringement or for any other reason (not limited to patent
27415 issues), conditions are imposed on you (whether by court order,
27416 agreement or otherwise) that contradict the conditions of this
27417 License, they do not excuse you from the conditions of this
27418 License. If you cannot distribute so as to satisfy simultaneously
27419 your obligations under this License and any other pertinent
27420 obligations, then as a consequence you may not distribute the
27421 Program at all. For example, if a patent license would not permit
27422 royalty-free redistribution of the Program by all those who
27423 receive copies directly or indirectly through you, then the only
27424 way you could satisfy both it and this License would be to refrain
27425 entirely from distribution of the Program.
27427 If any portion of this section is held invalid or unenforceable
27428 under any particular circumstance, the balance of the section is
27429 intended to apply and the section as a whole is intended to apply
27430 in other circumstances.
27432 It is not the purpose of this section to induce you to infringe any
27433 patents or other property right claims or to contest validity of
27434 any such claims; this section has the sole purpose of protecting
27435 the integrity of the free software distribution system, which is
27436 implemented by public license practices. Many people have made
27437 generous contributions to the wide range of software distributed
27438 through that system in reliance on consistent application of that
27439 system; it is up to the author/donor to decide if he or she is
27440 willing to distribute software through any other system and a
27441 licensee cannot impose that choice.
27443 This section is intended to make thoroughly clear what is believed
27444 to be a consequence of the rest of this License.
27446 8. If the distribution and/or use of the Program is restricted in
27447 certain countries either by patents or by copyrighted interfaces,
27448 the original copyright holder who places the Program under this
27449 License may add an explicit geographical distribution limitation
27450 excluding those countries, so that distribution is permitted only
27451 in or among countries not thus excluded. In such case, this
27452 License incorporates the limitation as if written in the body of
27455 9. The Free Software Foundation may publish revised and/or new
27456 versions of the General Public License from time to time. Such
27457 new versions will be similar in spirit to the present version, but
27458 may differ in detail to address new problems or concerns.
27460 Each version is given a distinguishing version number. If the
27461 Program specifies a version number of this License which applies
27462 to it and "any later version", you have the option of following
27463 the terms and conditions either of that version or of any later
27464 version published by the Free Software Foundation. If the Program
27465 does not specify a version number of this License, you may choose
27466 any version ever published by the Free Software Foundation.
27468 10. If you wish to incorporate parts of the Program into other free
27469 programs whose distribution conditions are different, write to the
27470 author to ask for permission. For software which is copyrighted
27471 by the Free Software Foundation, write to the Free Software
27472 Foundation; we sometimes make exceptions for this. Our decision
27473 will be guided by the two goals of preserving the free status of
27474 all derivatives of our free software and of promoting the sharing
27475 and reuse of software generally.
27478 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
27479 WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
27480 LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
27481 HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT
27482 WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT
27483 NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
27484 FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE
27485 QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
27486 PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
27487 SERVICING, REPAIR OR CORRECTION.
27489 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
27490 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
27491 MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE
27492 LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
27493 INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
27494 INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
27495 DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU
27496 OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
27497 OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN
27498 ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
27500 END OF TERMS AND CONDITIONS
27501 Appendix: How to Apply These Terms to Your New Programs
27502 =======================================================
27504 If you develop a new program, and you want it to be of the greatest
27505 possible use to the public, the best way to achieve this is to make it
27506 free software which everyone can redistribute and change under these
27509 To do so, attach the following notices to the program. It is safest
27510 to attach them to the start of each source file to most effectively
27511 convey the exclusion of warranty; and each file should have at least
27512 the "copyright" line and a pointer to where the full notice is found.
27514 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
27515 Copyright (C) YEAR NAME OF AUTHOR
27517 This program is free software; you can redistribute it and/or modify
27518 it under the terms of the GNU General Public License as published by
27519 the Free Software Foundation; either version 2 of the License, or
27520 (at your option) any later version.
27522 This program is distributed in the hope that it will be useful,
27523 but WITHOUT ANY WARRANTY; without even the implied warranty of
27524 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
27525 GNU General Public License for more details.
27527 You should have received a copy of the GNU General Public License
27528 along with this program; if not, write to the Free Software
27529 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
27531 Also add information on how to contact you by electronic and paper
27534 If the program is interactive, make it output a short notice like this
27535 when it starts in an interactive mode:
27537 Gnomovision version 69, Copyright (C) YEAR NAME OF AUTHOR
27538 Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
27540 This is free software, and you are welcome to redistribute it
27541 under certain conditions; type `show c' for details.
27543 The hypothetical commands `show w' and `show c' should show the
27544 appropriate parts of the General Public License. Of course, the
27545 commands you use may be called something other than `show w' and `show
27546 c'; they could even be mouse-clicks or menu items--whatever suits your
27549 You should also get your employer (if you work as a programmer) or your
27550 school, if any, to sign a "copyright disclaimer" for the program, if
27551 necessary. Here is a sample; alter the names:
27553 Yoyodyne, Inc., hereby disclaims all copyright interest in the program
27554 `Gnomovision' (which makes passes at compilers) written by James Hacker.
27556 SIGNATURE OF TY COON, 1 April 1989
27557 Ty Coon, President of Vice
27559 This General Public License does not permit incorporating your program
27560 into proprietary programs. If your program is a subroutine library,
27561 you may consider it more useful to permit linking proprietary
27562 applications with the library. If this is what you want to do, use the
27563 GNU Library General Public License instead of this License.
27566 File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top
27568 GNU Free Documentation License
27569 ******************************
27571 Version 1.2, November 2002
27573 Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
27574 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
27576 Everyone is permitted to copy and distribute verbatim copies
27577 of this license document, but changing it is not allowed.
27581 The purpose of this License is to make a manual, textbook, or other
27582 functional and useful document "free" in the sense of freedom: to
27583 assure everyone the effective freedom to copy and redistribute it,
27584 with or without modifying it, either commercially or
27585 noncommercially. Secondarily, this License preserves for the
27586 author and publisher a way to get credit for their work, while not
27587 being considered responsible for modifications made by others.
27589 This License is a kind of "copyleft", which means that derivative
27590 works of the document must themselves be free in the same sense.
27591 It complements the GNU General Public License, which is a copyleft
27592 license designed for free software.
27594 We have designed this License in order to use it for manuals for
27595 free software, because free software needs free documentation: a
27596 free program should come with manuals providing the same freedoms
27597 that the software does. But this License is not limited to
27598 software manuals; it can be used for any textual work, regardless
27599 of subject matter or whether it is published as a printed book.
27600 We recommend this License principally for works whose purpose is
27601 instruction or reference.
27603 1. APPLICABILITY AND DEFINITIONS
27605 This License applies to any manual or other work, in any medium,
27606 that contains a notice placed by the copyright holder saying it
27607 can be distributed under the terms of this License. Such a notice
27608 grants a world-wide, royalty-free license, unlimited in duration,
27609 to use that work under the conditions stated herein. The
27610 "Document", below, refers to any such manual or work. Any member
27611 of the public is a licensee, and is addressed as "you". You
27612 accept the license if you copy, modify or distribute the work in a
27613 way requiring permission under copyright law.
27615 A "Modified Version" of the Document means any work containing the
27616 Document or a portion of it, either copied verbatim, or with
27617 modifications and/or translated into another language.
27619 A "Secondary Section" is a named appendix or a front-matter section
27620 of the Document that deals exclusively with the relationship of the
27621 publishers or authors of the Document to the Document's overall
27622 subject (or to related matters) and contains nothing that could
27623 fall directly within that overall subject. (Thus, if the Document
27624 is in part a textbook of mathematics, a Secondary Section may not
27625 explain any mathematics.) The relationship could be a matter of
27626 historical connection with the subject or with related matters, or
27627 of legal, commercial, philosophical, ethical or political position
27630 The "Invariant Sections" are certain Secondary Sections whose
27631 titles are designated, as being those of Invariant Sections, in
27632 the notice that says that the Document is released under this
27633 License. If a section does not fit the above definition of
27634 Secondary then it is not allowed to be designated as Invariant.
27635 The Document may contain zero Invariant Sections. If the Document
27636 does not identify any Invariant Sections then there are none.
27638 The "Cover Texts" are certain short passages of text that are
27639 listed, as Front-Cover Texts or Back-Cover Texts, in the notice
27640 that says that the Document is released under this License. A
27641 Front-Cover Text may be at most 5 words, and a Back-Cover Text may
27642 be at most 25 words.
27644 A "Transparent" copy of the Document means a machine-readable copy,
27645 represented in a format whose specification is available to the
27646 general public, that is suitable for revising the document
27647 straightforwardly with generic text editors or (for images
27648 composed of pixels) generic paint programs or (for drawings) some
27649 widely available drawing editor, and that is suitable for input to
27650 text formatters or for automatic translation to a variety of
27651 formats suitable for input to text formatters. A copy made in an
27652 otherwise Transparent file format whose markup, or absence of
27653 markup, has been arranged to thwart or discourage subsequent
27654 modification by readers is not Transparent. An image format is
27655 not Transparent if used for any substantial amount of text. A
27656 copy that is not "Transparent" is called "Opaque".
27658 Examples of suitable formats for Transparent copies include plain
27659 ASCII without markup, Texinfo input format, LaTeX input format,
27660 SGML or XML using a publicly available DTD, and
27661 standard-conforming simple HTML, PostScript or PDF designed for
27662 human modification. Examples of transparent image formats include
27663 PNG, XCF and JPG. Opaque formats include proprietary formats that
27664 can be read and edited only by proprietary word processors, SGML or
27665 XML for which the DTD and/or processing tools are not generally
27666 available, and the machine-generated HTML, PostScript or PDF
27667 produced by some word processors for output purposes only.
27669 The "Title Page" means, for a printed book, the title page itself,
27670 plus such following pages as are needed to hold, legibly, the
27671 material this License requires to appear in the title page. For
27672 works in formats which do not have any title page as such, "Title
27673 Page" means the text near the most prominent appearance of the
27674 work's title, preceding the beginning of the body of the text.
27676 A section "Entitled XYZ" means a named subunit of the Document
27677 whose title either is precisely XYZ or contains XYZ in parentheses
27678 following text that translates XYZ in another language. (Here XYZ
27679 stands for a specific section name mentioned below, such as
27680 "Acknowledgements", "Dedications", "Endorsements", or "History".)
27681 To "Preserve the Title" of such a section when you modify the
27682 Document means that it remains a section "Entitled XYZ" according
27683 to this definition.
27685 The Document may include Warranty Disclaimers next to the notice
27686 which states that this License applies to the Document. These
27687 Warranty Disclaimers are considered to be included by reference in
27688 this License, but only as regards disclaiming warranties: any other
27689 implication that these Warranty Disclaimers may have is void and
27690 has no effect on the meaning of this License.
27692 2. VERBATIM COPYING
27694 You may copy and distribute the Document in any medium, either
27695 commercially or noncommercially, provided that this License, the
27696 copyright notices, and the license notice saying this License
27697 applies to the Document are reproduced in all copies, and that you
27698 add no other conditions whatsoever to those of this License. You
27699 may not use technical measures to obstruct or control the reading
27700 or further copying of the copies you make or distribute. However,
27701 you may accept compensation in exchange for copies. If you
27702 distribute a large enough number of copies you must also follow
27703 the conditions in section 3.
27705 You may also lend copies, under the same conditions stated above,
27706 and you may publicly display copies.
27708 3. COPYING IN QUANTITY
27710 If you publish printed copies (or copies in media that commonly
27711 have printed covers) of the Document, numbering more than 100, and
27712 the Document's license notice requires Cover Texts, you must
27713 enclose the copies in covers that carry, clearly and legibly, all
27714 these Cover Texts: Front-Cover Texts on the front cover, and
27715 Back-Cover Texts on the back cover. Both covers must also clearly
27716 and legibly identify you as the publisher of these copies. The
27717 front cover must present the full title with all words of the
27718 title equally prominent and visible. You may add other material
27719 on the covers in addition. Copying with changes limited to the
27720 covers, as long as they preserve the title of the Document and
27721 satisfy these conditions, can be treated as verbatim copying in
27724 If the required texts for either cover are too voluminous to fit
27725 legibly, you should put the first ones listed (as many as fit
27726 reasonably) on the actual cover, and continue the rest onto
27729 If you publish or distribute Opaque copies of the Document
27730 numbering more than 100, you must either include a
27731 machine-readable Transparent copy along with each Opaque copy, or
27732 state in or with each Opaque copy a computer-network location from
27733 which the general network-using public has access to download
27734 using public-standard network protocols a complete Transparent
27735 copy of the Document, free of added material. If you use the
27736 latter option, you must take reasonably prudent steps, when you
27737 begin distribution of Opaque copies in quantity, to ensure that
27738 this Transparent copy will remain thus accessible at the stated
27739 location until at least one year after the last time you
27740 distribute an Opaque copy (directly or through your agents or
27741 retailers) of that edition to the public.
27743 It is requested, but not required, that you contact the authors of
27744 the Document well before redistributing any large number of
27745 copies, to give them a chance to provide you with an updated
27746 version of the Document.
27750 You may copy and distribute a Modified Version of the Document
27751 under the conditions of sections 2 and 3 above, provided that you
27752 release the Modified Version under precisely this License, with
27753 the Modified Version filling the role of the Document, thus
27754 licensing distribution and modification of the Modified Version to
27755 whoever possesses a copy of it. In addition, you must do these
27756 things in the Modified Version:
27758 A. Use in the Title Page (and on the covers, if any) a title
27759 distinct from that of the Document, and from those of
27760 previous versions (which should, if there were any, be listed
27761 in the History section of the Document). You may use the
27762 same title as a previous version if the original publisher of
27763 that version gives permission.
27765 B. List on the Title Page, as authors, one or more persons or
27766 entities responsible for authorship of the modifications in
27767 the Modified Version, together with at least five of the
27768 principal authors of the Document (all of its principal
27769 authors, if it has fewer than five), unless they release you
27770 from this requirement.
27772 C. State on the Title page the name of the publisher of the
27773 Modified Version, as the publisher.
27775 D. Preserve all the copyright notices of the Document.
27777 E. Add an appropriate copyright notice for your modifications
27778 adjacent to the other copyright notices.
27780 F. Include, immediately after the copyright notices, a license
27781 notice giving the public permission to use the Modified
27782 Version under the terms of this License, in the form shown in
27783 the Addendum below.
27785 G. Preserve in that license notice the full lists of Invariant
27786 Sections and required Cover Texts given in the Document's
27789 H. Include an unaltered copy of this License.
27791 I. Preserve the section Entitled "History", Preserve its Title,
27792 and add to it an item stating at least the title, year, new
27793 authors, and publisher of the Modified Version as given on
27794 the Title Page. If there is no section Entitled "History" in
27795 the Document, create one stating the title, year, authors,
27796 and publisher of the Document as given on its Title Page,
27797 then add an item describing the Modified Version as stated in
27798 the previous sentence.
27800 J. Preserve the network location, if any, given in the Document
27801 for public access to a Transparent copy of the Document, and
27802 likewise the network locations given in the Document for
27803 previous versions it was based on. These may be placed in
27804 the "History" section. You may omit a network location for a
27805 work that was published at least four years before the
27806 Document itself, or if the original publisher of the version
27807 it refers to gives permission.
27809 K. For any section Entitled "Acknowledgements" or "Dedications",
27810 Preserve the Title of the section, and preserve in the
27811 section all the substance and tone of each of the contributor
27812 acknowledgements and/or dedications given therein.
27814 L. Preserve all the Invariant Sections of the Document,
27815 unaltered in their text and in their titles. Section numbers
27816 or the equivalent are not considered part of the section
27819 M. Delete any section Entitled "Endorsements". Such a section
27820 may not be included in the Modified Version.
27822 N. Do not retitle any existing section to be Entitled
27823 "Endorsements" or to conflict in title with any Invariant
27826 O. Preserve any Warranty Disclaimers.
27828 If the Modified Version includes new front-matter sections or
27829 appendices that qualify as Secondary Sections and contain no
27830 material copied from the Document, you may at your option
27831 designate some or all of these sections as invariant. To do this,
27832 add their titles to the list of Invariant Sections in the Modified
27833 Version's license notice. These titles must be distinct from any
27834 other section titles.
27836 You may add a section Entitled "Endorsements", provided it contains
27837 nothing but endorsements of your Modified Version by various
27838 parties--for example, statements of peer review or that the text
27839 has been approved by an organization as the authoritative
27840 definition of a standard.
27842 You may add a passage of up to five words as a Front-Cover Text,
27843 and a passage of up to 25 words as a Back-Cover Text, to the end
27844 of the list of Cover Texts in the Modified Version. Only one
27845 passage of Front-Cover Text and one of Back-Cover Text may be
27846 added by (or through arrangements made by) any one entity. If the
27847 Document already includes a cover text for the same cover,
27848 previously added by you or by arrangement made by the same entity
27849 you are acting on behalf of, you may not add another; but you may
27850 replace the old one, on explicit permission from the previous
27851 publisher that added the old one.
27853 The author(s) and publisher(s) of the Document do not by this
27854 License give permission to use their names for publicity for or to
27855 assert or imply endorsement of any Modified Version.
27857 5. COMBINING DOCUMENTS
27859 You may combine the Document with other documents released under
27860 this License, under the terms defined in section 4 above for
27861 modified versions, provided that you include in the combination
27862 all of the Invariant Sections of all of the original documents,
27863 unmodified, and list them all as Invariant Sections of your
27864 combined work in its license notice, and that you preserve all
27865 their Warranty Disclaimers.
27867 The combined work need only contain one copy of this License, and
27868 multiple identical Invariant Sections may be replaced with a single
27869 copy. If there are multiple Invariant Sections with the same name
27870 but different contents, make the title of each such section unique
27871 by adding at the end of it, in parentheses, the name of the
27872 original author or publisher of that section if known, or else a
27873 unique number. Make the same adjustment to the section titles in
27874 the list of Invariant Sections in the license notice of the
27877 In the combination, you must combine any sections Entitled
27878 "History" in the various original documents, forming one section
27879 Entitled "History"; likewise combine any sections Entitled
27880 "Acknowledgements", and any sections Entitled "Dedications". You
27881 must delete all sections Entitled "Endorsements."
27883 6. COLLECTIONS OF DOCUMENTS
27885 You may make a collection consisting of the Document and other
27886 documents released under this License, and replace the individual
27887 copies of this License in the various documents with a single copy
27888 that is included in the collection, provided that you follow the
27889 rules of this License for verbatim copying of each of the
27890 documents in all other respects.
27892 You may extract a single document from such a collection, and
27893 distribute it individually under this License, provided you insert
27894 a copy of this License into the extracted document, and follow
27895 this License in all other respects regarding verbatim copying of
27898 7. AGGREGATION WITH INDEPENDENT WORKS
27900 A compilation of the Document or its derivatives with other
27901 separate and independent documents or works, in or on a volume of
27902 a storage or distribution medium, is called an "aggregate" if the
27903 copyright resulting from the compilation is not used to limit the
27904 legal rights of the compilation's users beyond what the individual
27905 works permit. When the Document is included in an aggregate, this
27906 License does not apply to the other works in the aggregate which
27907 are not themselves derivative works of the Document.
27909 If the Cover Text requirement of section 3 is applicable to these
27910 copies of the Document, then if the Document is less than one half
27911 of the entire aggregate, the Document's Cover Texts may be placed
27912 on covers that bracket the Document within the aggregate, or the
27913 electronic equivalent of covers if the Document is in electronic
27914 form. Otherwise they must appear on printed covers that bracket
27915 the whole aggregate.
27919 Translation is considered a kind of modification, so you may
27920 distribute translations of the Document under the terms of section
27921 4. Replacing Invariant Sections with translations requires special
27922 permission from their copyright holders, but you may include
27923 translations of some or all Invariant Sections in addition to the
27924 original versions of these Invariant Sections. You may include a
27925 translation of this License, and all the license notices in the
27926 Document, and any Warranty Disclaimers, provided that you also
27927 include the original English version of this License and the
27928 original versions of those notices and disclaimers. In case of a
27929 disagreement between the translation and the original version of
27930 this License or a notice or disclaimer, the original version will
27933 If a section in the Document is Entitled "Acknowledgements",
27934 "Dedications", or "History", the requirement (section 4) to
27935 Preserve its Title (section 1) will typically require changing the
27940 You may not copy, modify, sublicense, or distribute the Document
27941 except as expressly provided for under this License. Any other
27942 attempt to copy, modify, sublicense or distribute the Document is
27943 void, and will automatically terminate your rights under this
27944 License. However, parties who have received copies, or rights,
27945 from you under this License will not have their licenses
27946 terminated so long as such parties remain in full compliance.
27948 10. FUTURE REVISIONS OF THIS LICENSE
27950 The Free Software Foundation may publish new, revised versions of
27951 the GNU Free Documentation License from time to time. Such new
27952 versions will be similar in spirit to the present version, but may
27953 differ in detail to address new problems or concerns. See
27954 `http://www.gnu.org/copyleft/'.
27956 Each version of the License is given a distinguishing version
27957 number. If the Document specifies that a particular numbered
27958 version of this License "or any later version" applies to it, you
27959 have the option of following the terms and conditions either of
27960 that specified version or of any later version that has been
27961 published (not as a draft) by the Free Software Foundation. If
27962 the Document does not specify a version number of this License,
27963 you may choose any version ever published (not as a draft) by the
27964 Free Software Foundation.
27966 ADDENDUM: How to use this License for your documents
27967 ====================================================
27969 To use this License in a document you have written, include a copy of
27970 the License in the document and put the following copyright and license
27971 notices just after the title page:
27973 Copyright (C) YEAR YOUR NAME.
27974 Permission is granted to copy, distribute and/or modify this document
27975 under the terms of the GNU Free Documentation License, Version 1.2
27976 or any later version published by the Free Software Foundation;
27977 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
27978 Texts. A copy of the license is included in the section entitled ``GNU
27979 Free Documentation License''.
27981 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
27982 replace the "with...Texts." line with this:
27984 with the Invariant Sections being LIST THEIR TITLES, with
27985 the Front-Cover Texts being LIST, and with the Back-Cover Texts
27988 If you have Invariant Sections without Cover Texts, or some other
27989 combination of the three, merge those two alternatives to suit the
27992 If your document contains nontrivial examples of program code, we
27993 recommend releasing these examples in parallel under your choice of
27994 free software license, such as the GNU General Public License, to
27995 permit their use in free software.
27998 File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top
28000 Contributors to GCC
28001 *******************
28003 The GCC project would like to thank its many contributors. Without
28004 them the project would not have been nearly as successful as it has
28005 been. Any omissions in this list are accidental. Feel free to contact
28006 <law@redhat.com> or <gerald@pfeifer.com> if you have been left out or
28007 some of your contributions are not listed. Please keep this list in
28008 alphabetical order.
28010 * Analog Devices helped implement the support for complex data types
28013 * John David Anglin for threading-related fixes and improvements to
28014 libstdc++-v3, and the HP-UX port.
28016 * James van Artsdalen wrote the code that makes efficient use of the
28017 Intel 80387 register stack.
28019 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta
28022 * Alasdair Baird for various bug fixes.
28024 * Giovanni Bajo for analyzing lots of complicated C++ problem
28027 * Peter Barada for his work to improve code generation for new
28030 * Gerald Baumgartner added the signature extension to the C++ front
28033 * Godmar Back for his Java improvements and encouragement.
28035 * Scott Bambrough for help porting the Java compiler.
28037 * Wolfgang Bangerth for processing tons of bug reports.
28039 * Jon Beniston for his Microsoft Windows port of Java.
28041 * Daniel Berlin for better DWARF2 support, faster/better
28042 optimizations, improved alias analysis, plus migrating GCC to
28045 * Geoff Berry for his Java object serialization work and various
28048 * Eric Blake for helping to make GCJ and libgcj conform to the
28051 * Janne Blomqvist for contributions to gfortran.
28053 * Segher Boessenkool for various fixes.
28055 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and
28058 * Neil Booth for work on cpplib, lang hooks, debug hooks and other
28059 miscellaneous clean-ups.
28061 * Steven Bosscher for integrating the gfortran front end into GCC
28062 and for contributing to the tree-ssa branch.
28064 * Eric Botcazou for fixing middle- and backend bugs left and right.
28066 * Per Bothner for his direction via the steering committee and
28067 various improvements to the infrastructure for supporting new
28068 languages. Chill front end implementation. Initial
28069 implementations of cpplib, fix-header, config.guess, libio, and
28070 past C++ library (libg++) maintainer. Dreaming up, designing and
28071 implementing much of GCJ.
28073 * Devon Bowen helped port GCC to the Tahoe.
28075 * Don Bowman for mips-vxworks contributions.
28077 * Dave Brolley for work on cpplib and Chill.
28079 * Paul Brook for work on the ARM architecture and maintaining
28082 * Robert Brown implemented the support for Encore 32000 systems.
28084 * Christian Bruel for improvements to local store elimination.
28086 * Herman A.J. ten Brugge for various fixes.
28088 * Joerg Brunsmann for Java compiler hacking and help with the GCJ
28091 * Joe Buck for his direction via the steering committee.
28093 * Craig Burley for leadership of the G77 Fortran effort.
28095 * Stephan Buys for contributing Doxygen notes for libstdc++.
28097 * Paolo Carlini for libstdc++ work: lots of efficiency improvements
28098 to the C++ strings, streambufs and formatted I/O, hard detective
28099 work on the frustrating localization issues, and keeping up with
28100 the problem reports.
28102 * John Carr for his alias work, SPARC hacking, infrastructure
28103 improvements, previous contributions to the steering committee,
28104 loop optimizations, etc.
28106 * Stephane Carrez for 68HC11 and 68HC12 ports.
28108 * Steve Chamberlain for support for the Renesas SH and H8 processors
28109 and the PicoJava processor, and for GCJ config fixes.
28111 * Glenn Chambers for help with the GCJ FAQ.
28113 * John-Marc Chandonia for various libgcj patches.
28115 * Scott Christley for his Objective-C contributions.
28117 * Eric Christopher for his Java porting help and clean-ups.
28119 * Branko Cibej for more warning contributions.
28121 * The GNU Classpath project for all of their merged runtime code.
28123 * Nick Clifton for arm, mcore, fr30, v850, m32r work, `--help', and
28124 other random hacking.
28126 * Michael Cook for libstdc++ cleanup patches to reduce warnings.
28128 * R. Kelley Cook for making GCC buildable from a read-only directory
28129 as well as other miscellaneous build process and documentation
28132 * Ralf Corsepius for SH testing and minor bugfixing.
28134 * Stan Cox for care and feeding of the x86 port and lots of behind
28135 the scenes hacking.
28137 * Alex Crain provided changes for the 3b1.
28139 * Ian Dall for major improvements to the NS32k port.
28141 * Paul Dale for his work to add uClinux platform support to the m68k
28144 * Dario Dariol contributed the four varieties of sample programs
28145 that print a copy of their source.
28147 * Russell Davidson for fstream and stringstream fixes in libstdc++.
28149 * Bud Davis for work on the G77 and gfortran compilers.
28151 * Mo DeJong for GCJ and libgcj bug fixes.
28153 * DJ Delorie for the DJGPP port, build and libiberty maintenance,
28154 various bug fixes, and the M32C port.
28156 * Arnaud Desitter for helping to debug gfortran.
28158 * Gabriel Dos Reis for contributions to G++, contributions and
28159 maintenance of GCC diagnostics infrastructure, libstdc++-v3,
28160 including `valarray<>', `complex<>', maintaining the numerics
28161 library (including that pesky `<limits>' :-) and keeping
28162 up-to-date anything to do with numbers.
28164 * Ulrich Drepper for his work on glibc, testing of GCC using glibc,
28165 ISO C99 support, CFG dumping support, etc., plus support of the
28166 C++ runtime libraries including for all kinds of C interface
28167 issues, contributing and maintaining `complex<>', sanity checking
28168 and disbursement, configuration architecture, libio maintenance,
28169 and early math work.
28171 * Zdenek Dvorak for a new loop unroller and various fixes.
28173 * Richard Earnshaw for his ongoing work with the ARM.
28175 * David Edelsohn for his direction via the steering committee,
28176 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa
28177 loop changes, doing the entire AIX port of libstdc++ with his bare
28178 hands, and for ensuring GCC properly keeps working on AIX.
28180 * Kevin Ediger for the floating point formatting of num_put::do_put
28183 * Phil Edwards for libstdc++ work including configuration hackery,
28184 documentation maintainer, chief breaker of the web pages, the
28185 occasional iostream bug fix, and work on shared library symbol
28188 * Paul Eggert for random hacking all over GCC.
28190 * Mark Elbrecht for various DJGPP improvements, and for libstdc++
28191 configuration support for locales and fstream-related fixes.
28193 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and
28196 * Christian Ehrhardt for dealing with bug reports.
28198 * Ben Elliston for his work to move the Objective-C runtime into its
28199 own subdirectory and for his work on autoconf.
28201 * Marc Espie for OpenBSD support.
28203 * Doug Evans for much of the global optimization framework, arc,
28204 m32r, and SPARC work.
28206 * Christopher Faylor for his work on the Cygwin port and for caring
28207 and feeding the gcc.gnu.org box and saving its users tons of spam.
28209 * Fred Fish for BeOS support and Ada fixes.
28211 * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ.
28213 * Peter Gerwinski for various bug fixes and the Pascal front end.
28215 * Kaveh R. Ghazi for his direction via the steering committee,
28216 amazing work to make `-W -Wall -W* -Werror' useful, and
28217 continuously testing GCC on a plethora of platforms. Kaveh
28218 extends his gratitude to the CAIP Center at Rutgers University for
28219 providing him with computing resources to work on Free Software
28220 since the late 1980s.
28222 * John Gilmore for a donation to the FSF earmarked improving GNU
28225 * Judy Goldberg for c++ contributions.
28227 * Torbjorn Granlund for various fixes and the c-torture testsuite,
28228 multiply- and divide-by-constant optimization, improved long long
28229 support, improved leaf function register allocation, and his
28230 direction via the steering committee.
28232 * Anthony Green for his `-Os' contributions and Java front end work.
28234 * Stu Grossman for gdb hacking, allowing GCJ developers to debug
28237 * Michael K. Gschwind contributed the port to the PDP-11.
28239 * Ron Guilmette implemented the `protoize' and `unprotoize' tools,
28240 the support for Dwarf symbolic debugging information, and much of
28241 the support for System V Release 4. He has also worked heavily on
28242 the Intel 386 and 860 support.
28244 * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload
28247 * Bruno Haible for improvements in the runtime overhead for EH, new
28248 warnings and assorted bug fixes.
28250 * Andrew Haley for his amazing Java compiler and library efforts.
28252 * Chris Hanson assisted in making GCC work on HP-UX for the 9000
28255 * Michael Hayes for various thankless work he's done trying to get
28256 the c30/c40 ports functional. Lots of loop and unroll
28257 improvements and fixes.
28259 * Dara Hazeghi for wading through myriads of target-specific bug
28262 * Kate Hedstrom for staking the G77 folks with an initial testsuite.
28264 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64
28265 work, loop opts, and generally fixing lots of old problems we've
28266 ignored for years, flow rewrite and lots of further stuff,
28267 including reviewing tons of patches.
28269 * Aldy Hernandez for working on the PowerPC port, SIMD support, and
28272 * Nobuyuki Hikichi of Software Research Associates, Tokyo,
28273 contributed the support for the Sony NEWS machine.
28275 * Kazu Hirata for caring and feeding the Renesas H8/300 port and
28278 * Katherine Holcomb for work on gfortran.
28280 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots
28281 of testing and bug fixing, particularly of GCC configury code.
28283 * Steve Holmgren for MachTen patches.
28285 * Jan Hubicka for his x86 port improvements.
28287 * Falk Hueffner for working on C and optimization bug reports.
28289 * Bernardo Innocenti for his m68k work, including merging of
28290 ColdFire improvements and uClinux support.
28292 * Christian Iseli for various bug fixes.
28294 * Kamil Iskra for general m68k hacking.
28296 * Lee Iverson for random fixes and MIPS testing.
28298 * Andreas Jaeger for testing and benchmarking of GCC and various bug
28301 * Jakub Jelinek for his SPARC work and sibling call optimizations as
28302 well as lots of bug fixes and test cases, and for improving the
28305 * Janis Johnson for ia64 testing and fixes, her quality improvement
28306 sidetracks, and web page maintenance.
28308 * Kean Johnston for SCO OpenServer support and various fixes.
28310 * Tim Josling for the sample language treelang based originally on
28311 Richard Kenner's "toy" language.
28313 * Nicolai Josuttis for additional libstdc++ documentation.
28315 * Klaus Kaempf for his ongoing work to make alpha-vms a viable
28318 * Steven G. Kargl for work on gfortran.
28320 * David Kashtan of SRI adapted GCC to VMS.
28322 * Ryszard Kabatek for many, many libstdc++ bug fixes and
28323 optimizations of strings, especially member functions, and for
28326 * Geoffrey Keating for his ongoing work to make the PPC work for
28327 GNU/Linux and his automatic regression tester.
28329 * Brendan Kehoe for his ongoing work with G++ and for a lot of early
28330 work in just about every part of libstdc++.
28332 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the
28335 * Richard Kenner of the New York University Ultracomputer Research
28336 Laboratory wrote the machine descriptions for the AMD 29000, the
28337 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the
28338 support for instruction attributes. He also made changes to
28339 better support RISC processors including changes to common
28340 subexpression elimination, strength reduction, function calling
28341 sequence handling, and condition code support, in addition to
28342 generalizing the code for frame pointer elimination and delay slot
28343 scheduling. Richard Kenner was also the head maintainer of GCC
28346 * Mumit Khan for various contributions to the Cygwin and Mingw32
28347 ports and maintaining binary releases for Microsoft Windows hosts,
28348 and for massive libstdc++ porting work to Cygwin/Mingw32.
28350 * Robin Kirkham for cpu32 support.
28352 * Mark Klein for PA improvements.
28354 * Thomas Koenig for various bug fixes.
28356 * Bruce Korb for the new and improved fixincludes code.
28358 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3
28361 * Charles LaBrec contributed the support for the Integrated Solutions
28364 * Asher Langton and Mike Kumbera for contributing Cray pointer
28365 support to gfortran, and for other gfortran improvements.
28367 * Jeff Law for his direction via the steering committee,
28368 coordinating the entire egcs project and GCC 2.95, rolling out
28369 snapshots and releases, handling merges from GCC2, reviewing tons
28370 of patches that might have fallen through the cracks else, and
28371 random but extensive hacking.
28373 * Marc Lehmann for his direction via the steering committee and
28374 helping with analysis and improvements of x86 performance.
28376 * Victor Leikehman for work on gfortran.
28378 * Ted Lemon wrote parts of the RTL reader and printer.
28380 * Kriang Lerdsuwanakij for C++ improvements including template as
28381 template parameter support, and many C++ fixes.
28383 * Warren Levy for tremendous work on libgcj (Java Runtime Library)
28384 and random work on the Java front end.
28386 * Alain Lichnewsky ported GCC to the MIPS CPU.
28388 * Oskar Liljeblad for hacking on AWT and his many Java bug reports
28391 * Robert Lipe for OpenServer support, new testsuites, testing, etc.
28393 * Weiwen Liu for testing and various bug fixes.
28395 * Dave Love for his ongoing work with the Fortran front end and
28398 * Martin von Lo"wis for internal consistency checking infrastructure,
28399 various C++ improvements including namespace support, and tons of
28400 assistance with libstdc++/compiler merges.
28402 * H.J. Lu for his previous contributions to the steering committee,
28403 many x86 bug reports, prototype patches, and keeping the GNU/Linux
28406 * Greg McGary for random fixes and (someday) bounded pointers.
28408 * Andrew MacLeod for his ongoing work in building a real EH system,
28409 various code generation improvements, work on the global
28412 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC
28413 hacking improvements to compile-time performance, overall
28414 knowledge and direction in the area of instruction scheduling, and
28415 design and implementation of the automaton based instruction
28418 * Bob Manson for his behind the scenes work on dejagnu.
28420 * Philip Martin for lots of libstdc++ string and vector iterator
28421 fixes and improvements, and string clean up and testsuites.
28423 * All of the Mauve project contributors, for Java test code.
28425 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements.
28427 * Adam Megacz for his work on the Microsoft Windows port of GCJ.
28429 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS,
28430 powerpc, haifa, ECOFF debug support, and other assorted hacking.
28432 * Jason Merrill for his direction via the steering committee and
28433 leading the G++ effort.
28435 * David Miller for his direction via the steering committee, lots of
28436 SPARC work, improvements in jump.c and interfacing with the Linux
28439 * Gary Miller ported GCC to Charles River Data Systems machines.
28441 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning
28442 the entire libstdc++ testsuite namespace-compatible.
28444 * Mark Mitchell for his direction via the steering committee,
28445 mountains of C++ work, load/store hoisting out of loops, alias
28446 analysis improvements, ISO C `restrict' support, and serving as
28447 release manager for GCC 3.x.
28449 * Alan Modra for various GNU/Linux bits and testing.
28451 * Toon Moene for his direction via the steering committee, Fortran
28452 maintenance, and his ongoing work to make us make Fortran run fast.
28454 * Jason Molenda for major help in the care and feeding of all the
28455 services on the gcc.gnu.org (formerly egcs.cygnus.com)
28456 machine--mail, web services, ftp services, etc etc. Doing all
28457 this work on scrap paper and the backs of envelopes would have
28460 * Catherine Moore for fixing various ugly problems we have sent her
28461 way, including the haifa bug which was killing the Alpha & PowerPC
28464 * Mike Moreton for his various Java patches.
28466 * David Mosberger-Tang for various Alpha improvements, and for the
28467 initial IA-64 port.
28469 * Stephen Moshier contributed the floating point emulator that
28470 assists in cross-compilation and permits support for floating
28471 point numbers wider than 64 bits and for ISO C99 support.
28473 * Bill Moyer for his behind the scenes work on various issues.
28475 * Philippe De Muyter for his work on the m68k port.
28477 * Joseph S. Myers for his work on the PDP-11 port, format checking
28478 and ISO C99 support, and continuous emphasis on (and contributions
28481 * Nathan Myers for his work on libstdc++-v3: architecture and
28482 authorship through the first three snapshots, including
28483 implementation of locale infrastructure, string, shadow C headers,
28484 and the initial project documentation (DESIGN, CHECKLIST, and so
28485 forth). Later, more work on MT-safe string and shadow headers.
28487 * Felix Natter for documentation on porting libstdc++.
28489 * Nathanael Nerode for cleaning up the configuration/build process.
28491 * NeXT, Inc. donated the front end that supports the Objective-C
28494 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to
28495 the search engine setup, various documentation fixes and other
28498 * Geoff Noer for his work on getting cygwin native builds working.
28500 * Diego Novillo for his SPEC performance tracking web pages and
28501 assorted fixes in the middle end and various back ends.
28503 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64,
28504 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and
28505 related infrastructure improvements.
28507 * Alexandre Oliva for various build infrastructure improvements,
28508 scripts and amazing testing work, including keeping libtool issues
28511 * Stefan Olsson for work on mt_alloc.
28513 * Melissa O'Neill for various NeXT fixes.
28515 * Rainer Orth for random MIPS work, including improvements to GCC's
28516 o32 ABI support, improvements to dejagnu's MIPS support, Java
28517 configuration clean-ups and porting work, etc.
28519 * Hartmut Penner for work on the s390 port.
28521 * Paul Petersen wrote the machine description for the Alliant FX/8.
28523 * Alexandre Petit-Bianco for implementing much of the Java compiler
28524 and continued Java maintainership.
28526 * Matthias Pfaller for major improvements to the NS32k port.
28528 * Gerald Pfeifer for his direction via the steering committee,
28529 pointing out lots of problems we need to solve, maintenance of the
28530 web pages, and taking care of documentation maintenance in general.
28532 * Andrew Pinski for processing bug reports by the dozen.
28534 * Ovidiu Predescu for his work on the Objective-C front end and
28537 * Jerry Quinn for major performance improvements in C++ formatted
28540 * Ken Raeburn for various improvements to checker, MIPS ports and
28541 various cleanups in the compiler.
28543 * Rolf W. Rasmussen for hacking on AWT.
28545 * David Reese of Sun Microsystems contributed to the Solaris on
28548 * Volker Reichelt for keeping up with the problem reports.
28550 * Joern Rennecke for maintaining the sh port, loop, regmove & reload
28553 * Loren J. Rittle for improvements to libstdc++-v3 including the
28554 FreeBSD port, threading fixes, thread-related configury changes,
28555 critical threading documentation, and solutions to really tricky
28556 I/O problems, as well as keeping GCC properly working on FreeBSD
28557 and continuous testing.
28559 * Craig Rodrigues for processing tons of bug reports.
28561 * Ola Ro"nnerup for work on mt_alloc.
28563 * Gavin Romig-Koch for lots of behind the scenes MIPS work.
28565 * David Ronis inspired and encouraged Craig to rewrite the G77
28566 documentation in texinfo format by contributing a first pass at a
28567 translation of the old `g77-0.5.16/f/DOC' file.
28569 * Ken Rose for fixes to GCC's delay slot filling code.
28571 * Paul Rubin wrote most of the preprocessor.
28573 * Pe'tur Runo'lfsson for major performance improvements in C++
28574 formatted I/O and large file support in C++ filebuf.
28576 * Chip Salzenberg for libstdc++ patches and improvements to locales,
28577 traits, Makefiles, libio, libtool hackery, and "long long" support.
28579 * Juha Sarlin for improvements to the H8 code generator.
28581 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series
28584 * Roger Sayle for improvements to constant folding and GCC's RTL
28585 optimizers as well as for fixing numerous bugs.
28587 * Bradley Schatz for his work on the GCJ FAQ.
28589 * Peter Schauer wrote the code to allow debugging to work on the
28592 * William Schelter did most of the work on the Intel 80386 support.
28594 * Tobias Schlu"ter for work on gfortran.
28596 * Bernd Schmidt for various code generation improvements and major
28597 work in the reload pass as well a serving as release manager for
28600 * Peter Schmid for constant testing of libstdc++--especially
28601 application testing, going above and beyond what was requested for
28602 the release criteria--and libstdc++ header file tweaks.
28604 * Jason Schroeder for jcf-dump patches.
28606 * Andreas Schwab for his work on the m68k port.
28608 * Lars Segerlund for work on gfortran.
28610 * Joel Sherrill for his direction via the steering committee, RTEMS
28611 contributions and RTEMS testing.
28613 * Nathan Sidwell for many C++ fixes/improvements.
28615 * Jeffrey Siegal for helping RMS with the original design of GCC,
28616 some code which handles the parse tree and RTL data structures,
28617 constant folding and help with the original VAX & m68k ports.
28619 * Kenny Simpson for prompting libstdc++ fixes due to defect reports
28620 from the LWG (thereby keeping GCC in line with updates from the
28623 * Franz Sirl for his ongoing work with making the PPC port stable
28626 * Andrey Slepuhin for assorted AIX hacking.
28628 * Christopher Smith did the port for Convex machines.
28630 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports.
28632 * Randy Smith finished the Sun FPA support.
28634 * Scott Snyder for queue, iterator, istream, and string fixes and
28635 libstdc++ testsuite entries. Also for providing the patch to G77
28636 to add rudimentary support for `INTEGER*1', `INTEGER*2', and
28639 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique.
28641 * Richard Stallman, for writing the original GCC and launching the
28644 * Jan Stein of the Chalmers Computer Society provided support for
28645 Genix, as well as part of the 32000 machine description.
28647 * Nigel Stephens for various mips16 related fixes/improvements.
28649 * Jonathan Stone wrote the machine description for the Pyramid
28652 * Graham Stott for various infrastructure improvements.
28654 * John Stracke for his Java HTTP protocol fixes.
28656 * Mike Stump for his Elxsi port, G++ contributions over the years
28657 and more recently his vxworks contributions
28659 * Jeff Sturm for Java porting help, bug fixes, and encouragement.
28661 * Shigeya Suzuki for this fixes for the bsdi platforms.
28663 * Ian Lance Taylor for his mips16 work, general configury hacking,
28666 * Holger Teutsch provided the support for the Clipper CPU.
28668 * Gary Thomas for his ongoing work to make the PPC work for
28671 * Philipp Thomas for random bug fixes throughout the compiler
28673 * Jason Thorpe for thread support in libstdc++ on NetBSD.
28675 * Kresten Krab Thorup wrote the run time support for the Objective-C
28676 language and the fantastic Java bytecode interpreter.
28678 * Michael Tiemann for random bug fixes, the first instruction
28679 scheduler, initial C++ support, function integration, NS32k, SPARC
28680 and M88k machine description work, delay slot scheduling.
28682 * Andreas Tobler for his work porting libgcj to Darwin.
28684 * Teemu Torma for thread safe exception handling support.
28686 * Leonard Tower wrote parts of the parser, RTL generator, and RTL
28687 definitions, and of the VAX machine description.
28689 * Tom Tromey for internationalization support and for his many Java
28690 contributions and libgcj maintainership.
28692 * Lassi Tuura for improvements to config.guess to determine HP
28695 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes.
28697 * Andy Vaught for the design and initial implementation of the
28698 gfortran front end.
28700 * Brent Verner for work with the libstdc++ cshadow files and their
28701 associated configure steps.
28703 * Todd Vierling for contributions for NetBSD ports.
28705 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML
28708 * Dean Wakerley for converting the install documentation from HTML
28709 to texinfo in time for GCC 3.0.
28711 * Krister Walfridsson for random bug fixes.
28713 * Feng Wang for contributions to gfortran.
28715 * Stephen M. Webb for time and effort on making libstdc++ shadow
28716 files work with the tricky Solaris 8+ headers, and for pushing the
28717 build-time header tree.
28719 * John Wehle for various improvements for the x86 code generator,
28720 related infrastructure improvements to help x86 code generation,
28721 value range propagation and other work, WE32k port.
28723 * Ulrich Weigand for work on the s390 port.
28725 * Zack Weinberg for major work on cpplib and various other bug fixes.
28727 * Matt Welsh for help with Linux Threads support in GCJ.
28729 * Urban Widmark for help fixing java.io.
28731 * Mark Wielaard for new Java library code and his work integrating
28734 * Dale Wiles helped port GCC to the Tahoe.
28736 * Bob Wilson from Tensilica, Inc. for the Xtensa port.
28738 * Jim Wilson for his direction via the steering committee, tackling
28739 hard problems in various places that nobody else wanted to work
28740 on, strength reduction and other loop optimizations.
28742 * Paul Woegerer and Tal Agmon for the CRX port.
28744 * Carlo Wood for various fixes.
28746 * Tom Wood for work on the m88k port.
28748 * Canqun Yang for work on gfortran.
28750 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine
28751 description for the Tron architecture (specifically, the Gmicro).
28753 * Kevin Zachmann helped port GCC to the Tahoe.
28755 * Ayal Zaks for Swing Modulo Scheduling (SMS).
28757 * Xiaoqiang Zhang for work on gfortran.
28759 * Gilles Zunino for help porting Java to Irix.
28762 The following people are recognized for their contributions to GNAT,
28763 the Ada front end of GCC:
28766 * Romain Berrendonner
28816 * Hristian Kirtchev
28859 The following people are recognized for their contributions of new
28860 features, bug reports, testing and integration of classpath/libgcj for
28862 * Lillian Angel for `JTree' implementation and lots Free Swing
28863 additions and bugfixes.
28865 * Wolfgang Baer for `GapContent' bugfixes.
28867 * Anthony Balkissoon for `JList', Free Swing 1.5 updates and mouse
28868 event fixes, lots of Free Swing work including `JTable' editing.
28870 * Stuart Ballard for RMI constant fixes.
28872 * Goffredo Baroncelli for `HTTPURLConnection' fixes.
28874 * Gary Benson for `MessageFormat' fixes.
28876 * Daniel Bonniot for `Serialization' fixes.
28878 * Chris Burdess for lots of gnu.xml and http protocol fixes, `StAX'
28879 and `DOM xml:id' support.
28881 * Ka-Hing Cheung for `TreePath' and `TreeSelection' fixes.
28883 * Archie Cobbs for build fixes, VM interface updates,
28884 `URLClassLoader' updates.
28886 * Kelley Cook for build fixes.
28888 * Martin Cordova for Suggestions for better `SocketTimeoutException'.
28890 * David Daney for `BitSet' bugfixes, `HttpURLConnection' rewrite and
28893 * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo
28894 2D support. Lots of imageio framework additions, lots of AWT and
28895 Free Swing bugfixes.
28897 * Jeroen Frijters for `ClassLoader' and nio cleanups, serialization
28898 fixes, better `Proxy' support, bugfixes and IKVM integration.
28900 * Santiago Gala for `AccessControlContext' fixes.
28902 * Nicolas Geoffray for `VMClassLoader' and `AccessController'
28905 * David Gilbert for `basic' and `metal' icon and plaf support and
28906 lots of documenting, Lots of Free Swing and metal theme additions.
28907 `MetalIconFactory' implementation.
28909 * Anthony Green for `MIDI' framework, `ALSA' and `DSSI' providers.
28911 * Andrew Haley for `Serialization' and `URLClassLoader' fixes, gcj
28914 * Kim Ho for `JFileChooser' implementation.
28916 * Andrew John Hughes for `Locale' and net fixes, URI RFC2986
28917 updates, `Serialization' fixes, `Properties' XML support and
28918 generic branch work, VMIntegration guide update.
28920 * Bastiaan Huisman for `TimeZone' bugfixing.
28922 * Andreas Jaeger for mprec updates.
28924 * Paul Jenner for better `-Werror' support.
28926 * Ito Kazumitsu for `NetworkInterface' implementation and updates.
28928 * Roman Kennke for `BoxLayout', `GrayFilter' and `SplitPane', plus
28929 bugfixes all over. Lots of Free Swing work including styled text.
28931 * Simon Kitching for `String' cleanups and optimization suggestions.
28933 * Michael Koch for configuration fixes, `Locale' updates, bug and
28936 * Guilhem Lavaux for configuration, thread and channel fixes and
28937 Kaffe integration. JCL native `Pointer' updates. Logger bugfixes.
28939 * David Lichteblau for JCL support library global/local reference
28942 * Aaron Luchko for JDWP updates and documentation fixes.
28944 * Ziga Mahkovec for `Graphics2D' upgraded to Cairo 0.5 and new regex
28947 * Sven de Marothy for BMP imageio support, CSS and `TextLayout'
28948 fixes. `GtkImage' rewrite, 2D, awt, free swing and date/time fixes
28949 and implementing the Qt4 peers.
28951 * Casey Marshall for crypto algorithm fixes, `FileChannel' lock,
28952 `SystemLogger' and `FileHandler' rotate implementations, NIO
28953 `FileChannel.map' support, security and policy updates.
28955 * Bryce McKinlay for RMI work.
28957 * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus
28958 testing and documenting.
28960 * Kalle Olavi Niemitalo for build fixes.
28962 * Rainer Orth for build fixes.
28964 * Andrew Overholt for `File' locking fixes.
28966 * Ingo Proetel for `Image', `Logger' and `URLClassLoader' updates.
28968 * Olga Rodimina for `MenuSelectionManager' implemenation.
28970 * Jan Roehrich for `BasicTreeUI' and `JTree' fixes.
28972 * Julian Scheid for documentation updates and gjdoc support.
28974 * Christian Schlichtherle for zip fixes and cleanups.
28976 * Robert Schuster for documentation updates and beans fixes,
28977 `TreeNode' enumerations and `ActionCommand' and various fixes, XML
28978 and URL, AWT and Free Swing bugfixes.
28980 * Keith Seitz for lots of JDWP work.
28982 * Christian Thalinger for 64-bit cleanups, Configuration and VM
28983 interface fixes and `CACAO' integration, `fdlibm' updates.
28985 * Gael Thomas for `VMClassLoader' boot packages support sugestions.
28987 * Andreas Tobler for Darwin and Solaris testing and fixing, `Qt4'
28988 support for Darwin/OS X, `Graphics2D' support, `gtk+' updates.
28990 * Dalibor Topic for better `DEBUG' support, build cleanups and Kaffe
28991 integration. `Qt4' build infrastructure, `SHA1PRNG' and
28992 `GdkPixbugDecoder' updates.
28994 * Tom Tromey for Eclipse integration, generics work, lots of bugfixes
28995 and gcj integration including coordinating The Big Merge.
28997 * Mark Wielaard for bugfixes, packaging and release management,
28998 `Clipboard' implementation, system call interrupts and network
28999 timeouts and `GdkPixpufDecoder' fixes.
29002 In addition to the above, all of which also contributed time and
29003 energy in testing GCC, we would like to thank the following for their
29004 contributions to testing:
29006 * Michael Abd-El-Malek
29016 * David Billinghurst
29020 * Stephane Bortzmeyer
29030 * Bradford Castalia
29050 * Charles-Antoine Gauthier
29072 * Kevin B. Hendricks
29076 * Christian Joensson
29084 * Anand Krishnaswamy
29086 * A. O. V. Le Blanc
29150 * Pedro A. M. Vazquez
29160 And finally we'd like to thank everyone who uses the compiler, submits
29161 bug reports and generally reminds us why we're doing this work in the
29165 File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top
29170 GCC's command line options are indexed here without any initial `-' or
29171 `--'. Where an option has both positive and negative forms (such as
29172 `-fOPTION' and `-fno-OPTION'), relevant entries in the manual are
29173 indexed under the most appropriate form; it may sometimes be useful to
29174 look up both forms.
29179 * msoft-float: Soft float library routines.
29183 File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top
29191 * ! in constraint: Multi-Alternative. (line 47)
29192 * # in constraint: Modifiers. (line 67)
29193 * # in template: Output Template. (line 66)
29194 * #pragma: Misc. (line 344)
29195 * % in constraint: Modifiers. (line 45)
29196 * % in GTY option: GTY Options. (line 18)
29197 * % in template: Output Template. (line 6)
29198 * & in constraint: Modifiers. (line 25)
29199 * (nil): RTL Objects. (line 73)
29200 * *: Host Common. (line 17)
29201 * * in constraint: Modifiers. (line 72)
29202 * * in template: Output Statement. (line 29)
29203 * *TARGET_GET_PCH_VALIDITY: PCH Target. (line 7)
29204 * + in constraint: Modifiers. (line 12)
29205 * /c in RTL dump: Flags. (line 224)
29206 * /f in RTL dump: Flags. (line 229)
29207 * /i in RTL dump: Flags. (line 280)
29208 * /j in RTL dump: Flags. (line 293)
29209 * /s in RTL dump: Flags. (line 244)
29210 * /u in RTL dump: Flags. (line 303)
29211 * /v in RTL dump: Flags. (line 335)
29212 * 0 in constraint: Simple Constraints. (line 118)
29213 * < in constraint: Simple Constraints. (line 46)
29214 * = in constraint: Modifiers. (line 8)
29215 * > in constraint: Simple Constraints. (line 50)
29216 * ? in constraint: Multi-Alternative. (line 41)
29217 * \: Output Template. (line 46)
29218 * __absvdi2: Integer library routines.
29220 * __absvsi2: Integer library routines.
29222 * __adddf3: Soft float library routines.
29224 * __addsf3: Soft float library routines.
29226 * __addtf3: Soft float library routines.
29228 * __addvdi3: Integer library routines.
29230 * __addvsi3: Integer library routines.
29232 * __addxf3: Soft float library routines.
29234 * __ashldi3: Integer library routines.
29236 * __ashlsi3: Integer library routines.
29238 * __ashlti3: Integer library routines.
29240 * __ashrdi3: Integer library routines.
29242 * __ashrsi3: Integer library routines.
29244 * __ashrti3: Integer library routines.
29246 * __builtin_args_info: Varargs. (line 42)
29247 * __builtin_classify_type: Varargs. (line 76)
29248 * __builtin_next_arg: Varargs. (line 66)
29249 * __builtin_saveregs: Varargs. (line 24)
29250 * __clear_cache: Miscellaneous routines.
29252 * __clzdi2: Integer library routines.
29254 * __clzsi2: Integer library routines.
29256 * __clzti2: Integer library routines.
29258 * __cmpdf2: Soft float library routines.
29260 * __cmpdi2: Integer library routines.
29262 * __cmpsf2: Soft float library routines.
29264 * __cmptf2: Soft float library routines.
29266 * __cmpti2: Integer library routines.
29268 * __CTOR_LIST__: Initialization. (line 25)
29269 * __ctzdi2: Integer library routines.
29271 * __ctzsi2: Integer library routines.
29273 * __ctzti2: Integer library routines.
29275 * __divdf3: Soft float library routines.
29277 * __divdi3: Integer library routines.
29279 * __divsf3: Soft float library routines.
29281 * __divsi3: Integer library routines.
29283 * __divtf3: Soft float library routines.
29285 * __divti3: Integer library routines.
29287 * __divxf3: Soft float library routines.
29289 * __DTOR_LIST__: Initialization. (line 25)
29290 * __eqdf2: Soft float library routines.
29292 * __eqsf2: Soft float library routines.
29294 * __eqtf2: Soft float library routines.
29296 * __extenddftf2: Soft float library routines.
29298 * __extenddfxf2: Soft float library routines.
29300 * __extendsfdf2: Soft float library routines.
29302 * __extendsftf2: Soft float library routines.
29304 * __extendsfxf2: Soft float library routines.
29306 * __ffsdi2: Integer library routines.
29308 * __ffsti2: Integer library routines.
29310 * __fixdfdi: Soft float library routines.
29312 * __fixdfsi: Soft float library routines.
29314 * __fixdfti: Soft float library routines.
29316 * __fixsfdi: Soft float library routines.
29318 * __fixsfsi: Soft float library routines.
29320 * __fixsfti: Soft float library routines.
29322 * __fixtfdi: Soft float library routines.
29324 * __fixtfsi: Soft float library routines.
29326 * __fixtfti: Soft float library routines.
29328 * __fixunsdfdi: Soft float library routines.
29330 * __fixunsdfsi: Soft float library routines.
29332 * __fixunsdfti: Soft float library routines.
29334 * __fixunssfdi: Soft float library routines.
29336 * __fixunssfsi: Soft float library routines.
29338 * __fixunssfti: Soft float library routines.
29340 * __fixunstfdi: Soft float library routines.
29342 * __fixunstfsi: Soft float library routines.
29344 * __fixunstfti: Soft float library routines.
29346 * __fixunsxfdi: Soft float library routines.
29348 * __fixunsxfsi: Soft float library routines.
29350 * __fixunsxfti: Soft float library routines.
29352 * __fixxfdi: Soft float library routines.
29354 * __fixxfsi: Soft float library routines.
29356 * __fixxfti: Soft float library routines.
29358 * __floatdidf: Soft float library routines.
29360 * __floatdisf: Soft float library routines.
29362 * __floatditf: Soft float library routines.
29364 * __floatdixf: Soft float library routines.
29366 * __floatsidf: Soft float library routines.
29368 * __floatsisf: Soft float library routines.
29370 * __floatsitf: Soft float library routines.
29372 * __floatsixf: Soft float library routines.
29374 * __floattidf: Soft float library routines.
29376 * __floattisf: Soft float library routines.
29378 * __floattitf: Soft float library routines.
29380 * __floattixf: Soft float library routines.
29382 * __gedf2: Soft float library routines.
29384 * __gesf2: Soft float library routines.
29386 * __getf2: Soft float library routines.
29388 * __gtdf2: Soft float library routines.
29390 * __gtsf2: Soft float library routines.
29392 * __gttf2: Soft float library routines.
29394 * __ledf2: Soft float library routines.
29396 * __lesf2: Soft float library routines.
29398 * __letf2: Soft float library routines.
29400 * __lshrdi3: Integer library routines.
29402 * __lshrsi3: Integer library routines.
29404 * __lshrti3: Integer library routines.
29406 * __ltdf2: Soft float library routines.
29408 * __ltsf2: Soft float library routines.
29410 * __lttf2: Soft float library routines.
29412 * __main: Collect2. (line 15)
29413 * __moddi3: Integer library routines.
29415 * __modsi3: Integer library routines.
29417 * __modti3: Integer library routines.
29419 * __muldf3: Soft float library routines.
29421 * __muldi3: Integer library routines.
29423 * __mulsf3: Soft float library routines.
29425 * __mulsi3: Integer library routines.
29427 * __multf3: Soft float library routines.
29429 * __multi3: Integer library routines.
29431 * __mulvdi3: Integer library routines.
29433 * __mulvsi3: Integer library routines.
29435 * __mulxf3: Soft float library routines.
29437 * __nedf2: Soft float library routines.
29439 * __negdf2: Soft float library routines.
29441 * __negdi2: Integer library routines.
29443 * __negsf2: Soft float library routines.
29445 * __negtf2: Soft float library routines.
29447 * __negti2: Integer library routines.
29449 * __negvdi2: Integer library routines.
29451 * __negvsi2: Integer library routines.
29453 * __negxf2: Soft float library routines.
29455 * __nesf2: Soft float library routines.
29457 * __netf2: Soft float library routines.
29459 * __paritydi2: Integer library routines.
29461 * __paritysi2: Integer library routines.
29463 * __parityti2: Integer library routines.
29465 * __popcountdi2: Integer library routines.
29467 * __popcountsi2: Integer library routines.
29469 * __popcountti2: Integer library routines.
29471 * __subdf3: Soft float library routines.
29473 * __subsf3: Soft float library routines.
29475 * __subtf3: Soft float library routines.
29477 * __subvdi3: Integer library routines.
29479 * __subvsi3: Integer library routines.
29481 * __subxf3: Soft float library routines.
29483 * __truncdfsf2: Soft float library routines.
29485 * __trunctfdf2: Soft float library routines.
29487 * __trunctfsf2: Soft float library routines.
29489 * __truncxfdf2: Soft float library routines.
29491 * __truncxfsf2: Soft float library routines.
29493 * __ucmpdi2: Integer library routines.
29495 * __ucmpti2: Integer library routines.
29497 * __udivdi3: Integer library routines.
29499 * __udivmoddi3: Integer library routines.
29501 * __udivsi3: Integer library routines.
29503 * __udivti3: Integer library routines.
29505 * __umoddi3: Integer library routines.
29507 * __umodsi3: Integer library routines.
29509 * __umodti3: Integer library routines.
29511 * __unorddf2: Soft float library routines.
29513 * __unordsf2: Soft float library routines.
29515 * __unordtf2: Soft float library routines.
29517 * abort: Portability. (line 21)
29518 * abs: Arithmetic. (line 169)
29519 * abs and attributes: Expressions. (line 64)
29520 * ABS_EXPR: Expression trees. (line 6)
29521 * absence_set: Processor pipeline description.
29523 * absM2 instruction pattern: Standard Names. (line 292)
29524 * absolute value: Arithmetic. (line 169)
29525 * access to operands: Accessors. (line 6)
29526 * access to special operands: Special Accessors. (line 6)
29527 * accessors: Accessors. (line 6)
29528 * ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 46)
29529 * ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 135)
29530 * ADA_LONG_TYPE_SIZE: Type Layout. (line 26)
29531 * ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 15)
29532 * addM3 instruction pattern: Standard Names. (line 187)
29533 * addMODEcc instruction pattern: Standard Names. (line 661)
29534 * addr_diff_vec: Side Effects. (line 299)
29535 * addr_diff_vec, length of: Insn Lengths. (line 26)
29536 * ADDR_EXPR: Expression trees. (line 6)
29537 * addr_vec: Side Effects. (line 294)
29538 * addr_vec, length of: Insn Lengths. (line 26)
29539 * address constraints: Simple Constraints. (line 152)
29540 * address_operand <1>: Simple Constraints. (line 156)
29541 * address_operand: Machine-Independent Predicates.
29543 * addressing modes: Addressing Modes. (line 6)
29544 * addressof: Regs and Memory. (line 260)
29545 * ADJUST_FIELD_ALIGN: Storage Layout. (line 185)
29546 * ADJUST_INSN_LENGTH: Insn Lengths. (line 35)
29547 * AGGR_INIT_EXPR: Expression trees. (line 6)
29548 * aggregates as return values: Aggregate Return. (line 6)
29549 * alias: Alias analysis. (line 6)
29550 * ALL_COP_ADDITIONAL_REGISTER_NAMES: MIPS Coprocessors. (line 32)
29551 * ALL_REGS: Register Classes. (line 17)
29552 * allocate_stack instruction pattern: Standard Names. (line 984)
29553 * alternate entry points: Insns. (line 145)
29554 * and: Arithmetic. (line 136)
29555 * and and attributes: Expressions. (line 50)
29556 * and, canonicalization of: Insn Canonicalizations.
29558 * andM3 instruction pattern: Standard Names. (line 193)
29559 * annotations: Annotations. (line 6)
29560 * APPLY_RESULT_SIZE: Scalar Return. (line 85)
29561 * ARG_POINTER_CFA_OFFSET: Frame Layout. (line 182)
29562 * ARG_POINTER_REGNUM: Frame Registers. (line 41)
29563 * ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65)
29564 * arg_pointer_rtx: Frame Registers. (line 85)
29565 * ARGS_GROW_DOWNWARD: Frame Layout. (line 35)
29566 * argument passing: Interface. (line 36)
29567 * arguments in registers: Register Arguments. (line 6)
29568 * arguments on stack: Stack Arguments. (line 6)
29569 * arithmetic library: Soft float library routines.
29571 * arithmetic shift: Arithmetic. (line 151)
29572 * arithmetic, in RTL: Arithmetic. (line 6)
29573 * ARITHMETIC_TYPE_P: Types. (line 76)
29574 * array: Types. (line 6)
29575 * ARRAY_RANGE_REF: Expression trees. (line 6)
29576 * ARRAY_REF: Expression trees. (line 6)
29577 * ARRAY_TYPE: Types. (line 6)
29578 * AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 151)
29579 * ashift: Arithmetic. (line 151)
29580 * ashift and attributes: Expressions. (line 64)
29581 * ashiftrt: Arithmetic. (line 159)
29582 * ashiftrt and attributes: Expressions. (line 64)
29583 * ashlM3 instruction pattern: Standard Names. (line 275)
29584 * ashrM3 instruction pattern: Standard Names. (line 285)
29585 * ASM_APP_OFF: File Framework. (line 61)
29586 * ASM_APP_ON: File Framework. (line 54)
29587 * ASM_COMMENT_START: File Framework. (line 49)
29588 * ASM_DECLARE_CLASS_REFERENCE: Label Output. (line 427)
29589 * ASM_DECLARE_CONSTANT_NAME: Label Output. (line 128)
29590 * ASM_DECLARE_FUNCTION_NAME: Label Output. (line 87)
29591 * ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 101)
29592 * ASM_DECLARE_OBJECT_NAME: Label Output. (line 114)
29593 * ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 143)
29594 * ASM_DECLARE_UNRESOLVED_REFERENCE: Label Output. (line 433)
29595 * ASM_FINAL_SPEC: Driver. (line 144)
29596 * ASM_FINISH_DECLARE_OBJECT: Label Output. (line 151)
29597 * ASM_FORMAT_PRIVATE_NAME: Label Output. (line 345)
29598 * asm_fprintf: Instruction Output. (line 123)
29599 * ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 134)
29600 * ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 329)
29601 * asm_input: Side Effects. (line 281)
29602 * asm_input and /v: Flags. (line 84)
29603 * ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 82)
29604 * ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 72)
29605 * asm_noperands: Insns. (line 277)
29606 * asm_operands and /v: Flags. (line 84)
29607 * asm_operands, RTL sharing: Sharing. (line 45)
29608 * asm_operands, usage: Assembler. (line 6)
29609 * ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 9)
29610 * ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 26)
29611 * ASM_OUTPUT_ALIGN: Alignment Output. (line 79)
29612 * ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 84)
29613 * ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 64)
29614 * ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 23)
29615 * ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 31)
29616 * ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 100)
29617 * ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 92)
29618 * ASM_OUTPUT_ASCII: Data Output. (line 50)
29619 * ASM_OUTPUT_BSS: Uninitialized Data. (line 44)
29620 * ASM_OUTPUT_CASE_END: Dispatch Tables. (line 51)
29621 * ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 38)
29622 * ASM_OUTPUT_COMMON: Uninitialized Data. (line 10)
29623 * ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 317)
29624 * ASM_OUTPUT_DEF: Label Output. (line 366)
29625 * ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 374)
29626 * ASM_OUTPUT_DWARF_DELTA: SDB and DWARF. (line 42)
29627 * ASM_OUTPUT_DWARF_OFFSET: SDB and DWARF. (line 46)
29628 * ASM_OUTPUT_DWARF_PCREL: SDB and DWARF. (line 51)
29629 * ASM_OUTPUT_EXTERNAL: Label Output. (line 255)
29630 * ASM_OUTPUT_FDESC: Data Output. (line 59)
29631 * ASM_OUTPUT_IDENT: File Framework. (line 83)
29632 * ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 17)
29633 * ASM_OUTPUT_LABEL: Label Output. (line 9)
29634 * ASM_OUTPUT_LABEL_REF: Label Output. (line 290)
29635 * ASM_OUTPUT_LABELREF: Label Output. (line 276)
29636 * ASM_OUTPUT_LOCAL: Uninitialized Data. (line 79)
29637 * ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 88)
29638 * ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 41)
29639 * ASM_OUTPUT_OPCODE: Instruction Output. (line 21)
29640 * ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 109)
29641 * ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 72)
29642 * ASM_OUTPUT_REG_POP: Instruction Output. (line 178)
29643 * ASM_OUTPUT_REG_PUSH: Instruction Output. (line 173)
29644 * ASM_OUTPUT_SHARED_BSS: Uninitialized Data. (line 74)
29645 * ASM_OUTPUT_SHARED_COMMON: Uninitialized Data. (line 39)
29646 * ASM_OUTPUT_SHARED_LOCAL: Uninitialized Data. (line 108)
29647 * ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 35)
29648 * ASM_OUTPUT_SKIP: Alignment Output. (line 66)
29649 * ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 68)
29650 * ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 84)
29651 * ASM_OUTPUT_SYMBOL_REF: Label Output. (line 283)
29652 * ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 77)
29653 * ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 392)
29654 * ASM_OUTPUT_WEAKREF: Label Output. (line 194)
29655 * ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 67)
29656 * ASM_SPEC: Driver. (line 136)
29657 * ASM_STABD_OP: DBX Options. (line 36)
29658 * ASM_STABN_OP: DBX Options. (line 43)
29659 * ASM_STABS_OP: DBX Options. (line 29)
29660 * ASM_WEAKEN_DECL: Label Output. (line 186)
29661 * ASM_WEAKEN_LABEL: Label Output. (line 173)
29662 * assemble_name: Label Output. (line 8)
29663 * assemble_name_raw: Label Output. (line 16)
29664 * assembler format: File Framework. (line 6)
29665 * assembler instructions in RTL: Assembler. (line 6)
29666 * ASSEMBLER_DIALECT: Instruction Output. (line 146)
29667 * assigning attribute values to insns: Tagging Insns. (line 6)
29668 * assignment operator: Function Basics. (line 6)
29669 * asterisk in template: Output Statement. (line 29)
29670 * atan2M3 instruction pattern: Standard Names. (line 344)
29671 * attr <1>: Tagging Insns. (line 54)
29672 * attr: Expressions. (line 154)
29673 * attr_flag: Expressions. (line 119)
29674 * attribute expressions: Expressions. (line 6)
29675 * attribute specifications: Attr Example. (line 6)
29676 * attribute specifications example: Attr Example. (line 6)
29677 * attributes: Attributes. (line 6)
29678 * attributes, defining: Defining Attributes.
29680 * attributes, target-specific: Target Attributes. (line 6)
29681 * autoincrement addressing, availability: Portability. (line 21)
29682 * autoincrement/decrement addressing: Simple Constraints. (line 28)
29683 * automata_option: Processor pipeline description.
29685 * automaton based pipeline description: Processor pipeline description.
29687 * automaton based scheduler: Processor pipeline description.
29689 * AVOID_CCMODE_COPIES: Values in Registers.
29691 * backslash: Output Template. (line 46)
29692 * barrier: Insns. (line 165)
29693 * barrier and /f: Flags. (line 111)
29694 * barrier and /i: Flags. (line 138)
29695 * barrier and /v: Flags. (line 29)
29696 * BASE_REG_CLASS: Register Classes. (line 107)
29697 * basic block: Basic Blocks. (line 6)
29698 * basic-block.h: Control Flow. (line 6)
29699 * BASIC_BLOCK: Basic Blocks. (line 19)
29700 * basic_block: Basic Blocks. (line 6)
29701 * BB_DIRTY, clear_bb_flags, update_life_info_in_dirty_blocks: Liveness information.
29703 * BB_HEAD, BB_END: Maintaining the CFG.
29705 * bCOND instruction pattern: Standard Names. (line 698)
29706 * BIGGEST_ALIGNMENT: Storage Layout. (line 167)
29707 * BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 178)
29708 * BImode: Machine Modes. (line 22)
29709 * BIND_EXPR: Expression trees. (line 6)
29710 * BINFO_TYPE: Classes. (line 6)
29711 * bit-fields: Bit-Fields. (line 6)
29712 * BIT_AND_EXPR: Expression trees. (line 6)
29713 * BIT_IOR_EXPR: Expression trees. (line 6)
29714 * BIT_NOT_EXPR: Expression trees. (line 6)
29715 * BIT_XOR_EXPR: Expression trees. (line 6)
29716 * BITFIELD_NBYTES_LIMITED: Storage Layout. (line 323)
29717 * BITS_BIG_ENDIAN: Storage Layout. (line 12)
29718 * BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8)
29719 * BITS_PER_UNIT: Storage Layout. (line 52)
29720 * BITS_PER_WORD: Storage Layout. (line 57)
29721 * bitwise complement: Arithmetic. (line 132)
29722 * bitwise exclusive-or: Arithmetic. (line 146)
29723 * bitwise inclusive-or: Arithmetic. (line 141)
29724 * bitwise logical-and: Arithmetic. (line 136)
29725 * BLKmode: Machine Modes. (line 97)
29726 * BLKmode, and function return values: Calls. (line 23)
29727 * block statement iterators <1>: Maintaining the CFG.
29729 * block statement iterators: Basic Blocks. (line 68)
29730 * BLOCK_FOR_INSN, bb_for_stmt: Maintaining the CFG.
29732 * BLOCK_REG_PADDING: Register Arguments. (line 214)
29733 * Blocks: Blocks. (line 6)
29734 * bool <1>: Exception Region Output.
29736 * bool: Sections. (line 228)
29737 * BOOL_TYPE_SIZE: Type Layout. (line 44)
29738 * BOOLEAN_TYPE: Types. (line 6)
29739 * branch prediction: Profile information.
29741 * BRANCH_COST: Costs. (line 52)
29742 * break_out_memory_refs: Addressing Modes. (line 157)
29743 * BREAK_STMT: Function Bodies. (line 6)
29744 * bsi_commit_edge_inserts: Maintaining the CFG.
29746 * bsi_end_p: Maintaining the CFG.
29748 * bsi_insert_after: Maintaining the CFG.
29750 * bsi_insert_before: Maintaining the CFG.
29752 * bsi_insert_on_edge: Maintaining the CFG.
29754 * bsi_last: Maintaining the CFG.
29756 * bsi_next: Maintaining the CFG.
29758 * bsi_prev: Maintaining the CFG.
29760 * bsi_remove: Maintaining the CFG.
29762 * bsi_start: Maintaining the CFG.
29764 * BSS_SECTION_ASM_OP: Sections. (line 53)
29765 * btruncM2 instruction pattern: Standard Names. (line 362)
29766 * builtin_longjmp instruction pattern: Standard Names. (line 1070)
29767 * builtin_setjmp_receiver instruction pattern: Standard Names.
29769 * builtin_setjmp_setup instruction pattern: Standard Names. (line 1049)
29770 * byte_mode: Machine Modes. (line 222)
29771 * BYTES_BIG_ENDIAN: Storage Layout. (line 24)
29772 * BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 136)
29773 * C statements for assembler output: Output Statement. (line 6)
29774 * C/C++ Internal Representation: Trees. (line 6)
29775 * C4X_FLOAT_FORMAT: Storage Layout. (line 399)
29776 * C99 math functions, implicit usage: Library Calls. (line 76)
29777 * c_register_pragma: Misc. (line 367)
29778 * c_register_pragma_with_expansion: Misc. (line 369)
29779 * call <1>: Side Effects. (line 86)
29780 * call: Flags. (line 224)
29781 * call instruction pattern: Standard Names. (line 731)
29782 * call usage: Calls. (line 10)
29783 * call, in mem: Flags. (line 89)
29784 * call-clobbered register: Register Basics. (line 35)
29785 * call-saved register: Register Basics. (line 35)
29786 * call-used register: Register Basics. (line 35)
29787 * CALL_EXPR: Expression trees. (line 6)
29788 * call_insn: Insns. (line 93)
29789 * call_insn and /f: Flags. (line 111)
29790 * call_insn and /i: Flags. (line 138)
29791 * call_insn and /j: Flags. (line 169)
29792 * call_insn and /s: Flags. (line 34)
29793 * call_insn and /u: Flags. (line 19)
29794 * call_insn and /v: Flags. (line 29)
29795 * CALL_INSN_FUNCTION_USAGE: Insns. (line 99)
29796 * call_pop instruction pattern: Standard Names. (line 759)
29797 * CALL_POPS_ARGS: Stack Arguments. (line 127)
29798 * CALL_REALLY_USED_REGISTERS: Register Basics. (line 46)
29799 * CALL_USED_REGISTERS: Register Basics. (line 35)
29800 * call_used_regs: Register Basics. (line 59)
29801 * call_value instruction pattern: Standard Names. (line 751)
29802 * call_value_pop instruction pattern: Standard Names. (line 759)
29803 * CALLER_SAVE_PROFITABLE: Caller Saves. (line 11)
29804 * calling conventions: Stack and Calling. (line 6)
29805 * calling functions in RTL: Calls. (line 6)
29806 * CAN_DEBUG_WITHOUT_FP: Run-time Target. (line 121)
29807 * CAN_ELIMINATE: Elimination. (line 71)
29808 * can_fallthru: Basic Blocks. (line 57)
29809 * canadian: Configure Terms. (line 6)
29810 * CANNOT_CHANGE_MODE_CLASS: Register Classes. (line 398)
29811 * canonicalization of instructions: Insn Canonicalizations.
29813 * CANONICALIZE_COMPARISON: Condition Code. (line 84)
29814 * canonicalize_funcptr_for_compare instruction pattern: Standard Names.
29816 * CASE_USE_BIT_TESTS: Misc. (line 54)
29817 * CASE_VALUES_THRESHOLD: Misc. (line 47)
29818 * CASE_VECTOR_MODE: Misc. (line 27)
29819 * CASE_VECTOR_PC_RELATIVE: Misc. (line 40)
29820 * CASE_VECTOR_SHORTEN_MODE: Misc. (line 31)
29821 * casesi instruction pattern: Standard Names. (line 839)
29822 * cbranchMODE4 instruction pattern: Standard Names. (line 720)
29823 * cc0: Regs and Memory. (line 182)
29824 * cc0, RTL sharing: Sharing. (line 27)
29825 * cc0_rtx: Regs and Memory. (line 208)
29826 * CC1_SPEC: Driver. (line 118)
29827 * CC1PLUS_SPEC: Driver. (line 126)
29828 * cc_status: Condition Code. (line 8)
29829 * CC_STATUS_MDEP: Condition Code. (line 19)
29830 * CC_STATUS_MDEP_INIT: Condition Code. (line 25)
29831 * CCmode: Machine Modes. (line 90)
29832 * CDImode: Machine Modes. (line 116)
29833 * CEIL_DIV_EXPR: Expression trees. (line 6)
29834 * CEIL_MOD_EXPR: Expression trees. (line 6)
29835 * ceilM2 instruction pattern: Standard Names. (line 378)
29836 * CFG, Control Flow Graph: Control Flow. (line 6)
29837 * cfghooks.h: Maintaining the CFG.
29839 * cgraph_finalize_function: Parsing pass. (line 52)
29840 * chain_next: GTY Options. (line 188)
29841 * chain_prev: GTY Options. (line 188)
29842 * change_address: Standard Names. (line 47)
29843 * char <1>: Misc. (line 650)
29844 * char <2>: PCH Target. (line 12)
29845 * char: Sections. (line 220)
29846 * CHAR_TYPE_SIZE: Type Layout. (line 39)
29847 * check_stack instruction pattern: Standard Names. (line 1002)
29848 * CHImode: Machine Modes. (line 116)
29849 * class: Classes. (line 6)
29850 * class definitions, register: Register Classes. (line 6)
29851 * class preference constraints: Class Preferences. (line 6)
29852 * CLASS_LIKELY_SPILLED_P: Register Classes. (line 369)
29853 * CLASS_MAX_NREGS: Register Classes. (line 386)
29854 * CLASS_TYPE_P: Types. (line 80)
29855 * classes of RTX codes: RTL Classes. (line 6)
29856 * CLASSTYPE_DECLARED_CLASS: Classes. (line 6)
29857 * CLASSTYPE_HAS_MUTABLE: Classes. (line 80)
29858 * CLASSTYPE_NON_POD_P: Classes. (line 85)
29859 * CLEANUP_DECL: Function Bodies. (line 6)
29860 * CLEANUP_EXPR: Function Bodies. (line 6)
29861 * CLEANUP_POINT_EXPR: Expression trees. (line 6)
29862 * CLEANUP_STMT: Function Bodies. (line 6)
29863 * Cleanups: Cleanups. (line 6)
29864 * CLEAR_BY_PIECES_P: Costs. (line 124)
29865 * CLEAR_INSN_CACHE: Trampolines. (line 101)
29866 * CLEAR_RATIO: Costs. (line 115)
29867 * clobber: Side Effects. (line 100)
29868 * clz: Arithmetic. (line 182)
29869 * CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 293)
29870 * clzM2 instruction pattern: Standard Names. (line 423)
29871 * cmpM instruction pattern: Standard Names. (line 452)
29872 * cmpmemM instruction pattern: Standard Names. (line 553)
29873 * cmpstrM instruction pattern: Standard Names. (line 534)
29874 * cmpstrnM instruction pattern: Standard Names. (line 522)
29875 * code generation RTL sequences: Expander Definitions.
29877 * code macros in .md files: Code Macros. (line 6)
29878 * code_label: Insns. (line 124)
29879 * code_label and /i: Flags. (line 49)
29880 * code_label and /v: Flags. (line 29)
29881 * CODE_LABEL_NUMBER: Insns. (line 124)
29882 * codes, RTL expression: RTL Objects. (line 47)
29883 * COImode: Machine Modes. (line 116)
29884 * COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32)
29885 * COLLECT_EXPORT_LIST: Misc. (line 706)
29886 * COLLECT_SHARED_FINI_FUNC: Macros for Initialization.
29888 * COLLECT_SHARED_INIT_FUNC: Macros for Initialization.
29890 * combiner pass: Regs and Memory. (line 148)
29891 * commit_edge_insertions: Maintaining the CFG.
29893 * compare: Arithmetic. (line 43)
29894 * compare, canonicalization of: Insn Canonicalizations.
29896 * comparison_operator: Machine-Independent Predicates.
29898 * compiler passes and files: Passes. (line 6)
29899 * complement, bitwise: Arithmetic. (line 132)
29900 * COMPLEX_CST: Expression trees. (line 6)
29901 * COMPLEX_EXPR: Expression trees. (line 6)
29902 * COMPLEX_TYPE: Types. (line 6)
29903 * COMPONENT_REF: Expression trees. (line 6)
29904 * Compound Expressions: Compound Expressions.
29906 * Compound Lvalues: Compound Lvalues. (line 6)
29907 * COMPOUND_EXPR: Expression trees. (line 6)
29908 * COMPOUND_LITERAL_EXPR: Expression trees. (line 6)
29909 * COMPOUND_LITERAL_EXPR_DECL: Expression trees. (line 565)
29910 * COMPOUND_LITERAL_EXPR_DECL_STMT: Expression trees. (line 565)
29911 * computed jump: Edges. (line 128)
29912 * computing the length of an insn: Insn Lengths. (line 6)
29913 * cond: Comparisons. (line 90)
29914 * cond and attributes: Expressions. (line 37)
29915 * cond_exec: Side Effects. (line 245)
29916 * COND_EXPR: Expression trees. (line 6)
29917 * condition code register: Regs and Memory. (line 182)
29918 * condition code status: Condition Code. (line 6)
29919 * condition codes: Comparisons. (line 20)
29920 * conditional execution: Conditional Execution.
29922 * Conditional Expressions: Conditional Expressions.
29924 * CONDITIONAL_REGISTER_USAGE: Register Basics. (line 60)
29925 * conditional_trap instruction pattern: Standard Names. (line 1136)
29926 * conditions, in patterns: Patterns. (line 43)
29927 * configuration file <1>: Host Misc. (line 6)
29928 * configuration file: Filesystem. (line 6)
29929 * configure terms: Configure Terms. (line 6)
29930 * CONJ_EXPR: Expression trees. (line 6)
29931 * const and /i: Flags. (line 138)
29932 * CONST0_RTX: Constants. (line 73)
29933 * const0_rtx: Constants. (line 16)
29934 * CONST1_RTX: Constants. (line 73)
29935 * const1_rtx: Constants. (line 16)
29936 * CONST2_RTX: Constants. (line 73)
29937 * const2_rtx: Constants. (line 16)
29938 * CONST_DECL: Declarations. (line 6)
29939 * const_double: Constants. (line 32)
29940 * const_double, RTL sharing: Sharing. (line 29)
29941 * CONST_DOUBLE_CHAIN: Constants. (line 51)
29942 * CONST_DOUBLE_LOW: Constants. (line 60)
29943 * CONST_DOUBLE_MEM: Constants. (line 51)
29944 * CONST_DOUBLE_OK_FOR_CONSTRAINT_P: Register Classes. (line 445)
29945 * CONST_DOUBLE_OK_FOR_LETTER_P: Register Classes. (line 430)
29946 * const_double_operand: Machine-Independent Predicates.
29948 * const_int: Constants. (line 8)
29949 * const_int and attribute tests: Expressions. (line 47)
29950 * const_int and attributes: Expressions. (line 10)
29951 * const_int, RTL sharing: Sharing. (line 23)
29952 * const_int_operand: Machine-Independent Predicates.
29954 * CONST_OK_FOR_CONSTRAINT_P: Register Classes. (line 425)
29955 * CONST_OK_FOR_LETTER_P: Register Classes. (line 416)
29956 * CONST_OR_PURE_CALL_P: Flags. (line 19)
29957 * const_string: Constants. (line 82)
29958 * const_string and attributes: Expressions. (line 20)
29959 * const_true_rtx: Constants. (line 26)
29960 * const_vector: Constants. (line 39)
29961 * const_vector, RTL sharing: Sharing. (line 32)
29962 * constant attributes: Constant Attributes.
29964 * constant definitions: Constant Definitions.
29966 * CONSTANT_ADDRESS_P: Addressing Modes. (line 29)
29967 * CONSTANT_ALIGNMENT: Storage Layout. (line 212)
29968 * CONSTANT_P: Addressing Modes. (line 35)
29969 * CONSTANT_POOL_ADDRESS_P: Flags. (line 10)
29970 * CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 64)
29971 * constants in constraints: Simple Constraints. (line 58)
29972 * constm1_rtx: Constants. (line 16)
29973 * constraint modifier characters: Modifiers. (line 6)
29974 * constraint, matching: Simple Constraints. (line 130)
29975 * CONSTRAINT_LEN: Register Classes. (line 131)
29976 * constraints: Constraints. (line 6)
29977 * constraints, machine specific: Machine Constraints.
29979 * CONSTRUCTOR: Expression trees. (line 6)
29980 * constructor: Function Basics. (line 6)
29981 * constructors, automatic calls: Collect2. (line 15)
29982 * constructors, output of: Initialization. (line 6)
29983 * container: Containers. (line 6)
29984 * CONTINUE_STMT: Function Bodies. (line 6)
29985 * contributors: Contributors. (line 6)
29986 * controlling register usage: Register Basics. (line 76)
29987 * controlling the compilation driver: Driver. (line 6)
29988 * conventions, run-time: Interface. (line 6)
29989 * conversions: Conversions. (line 6)
29990 * CONVERT_EXPR: Expression trees. (line 6)
29991 * copy constructor: Function Basics. (line 6)
29992 * copy_rtx: Addressing Modes. (line 209)
29993 * copy_rtx_if_shared: Sharing. (line 64)
29994 * copysignM3 instruction pattern: Standard Names. (line 404)
29995 * cosM2 instruction pattern: Standard Names. (line 303)
29996 * costs of instructions: Costs. (line 6)
29997 * CP_INTEGRAL_TYPE: Types. (line 72)
29998 * cp_namespace_decls: Namespaces. (line 44)
29999 * CP_TYPE_CONST_NON_VOLATILE_P: Types. (line 45)
30000 * CP_TYPE_CONST_P: Types. (line 36)
30001 * CP_TYPE_QUALS: Types. (line 6)
30002 * CP_TYPE_RESTRICT_P: Types. (line 42)
30003 * CP_TYPE_VOLATILE_P: Types. (line 39)
30004 * CPLUSPLUS_CPP_SPEC: Driver. (line 113)
30005 * CPP_SPEC: Driver. (line 106)
30006 * CQImode: Machine Modes. (line 116)
30007 * cross compilation and floating point: Floating Point. (line 6)
30008 * CRT_CALL_STATIC_FUNCTION: Sections. (line 88)
30009 * CRTSTUFF_T_CFLAGS: Target Fragment. (line 35)
30010 * CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 39)
30011 * CSImode: Machine Modes. (line 116)
30012 * CTImode: Machine Modes. (line 116)
30013 * ctz: Arithmetic. (line 190)
30014 * CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 294)
30015 * ctzM2 instruction pattern: Standard Names. (line 430)
30016 * CUMULATIVE_ARGS: Register Arguments. (line 127)
30017 * current_function_epilogue_delay_list: Function Entry. (line 181)
30018 * current_function_is_leaf: Leaf Functions. (line 51)
30019 * current_function_outgoing_args_size: Stack Arguments. (line 45)
30020 * current_function_pops_args: Function Entry. (line 106)
30021 * current_function_pretend_args_size: Function Entry. (line 112)
30022 * current_function_uses_only_leaf_regs: Leaf Functions. (line 51)
30023 * current_insn_predicate: Conditional Execution.
30025 * data bypass: Processor pipeline description.
30027 * data dependence delays: Processor pipeline description.
30029 * data structures: Per-Function Data. (line 6)
30030 * DATA_ALIGNMENT: Storage Layout. (line 199)
30031 * data_section: Sections. (line 109)
30032 * DATA_SECTION_ASM_OP: Sections. (line 33)
30033 * DBR_OUTPUT_SEQEND: Instruction Output. (line 107)
30034 * dbr_sequence_length: Instruction Output. (line 106)
30035 * DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 103)
30036 * DBX_CONTIN_CHAR: DBX Options. (line 66)
30037 * DBX_CONTIN_LENGTH: DBX Options. (line 56)
30038 * DBX_DEBUGGING_INFO: DBX Options. (line 9)
30039 * DBX_FUNCTION_FIRST: DBX Options. (line 97)
30040 * DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 109)
30041 * DBX_NO_XREFS: DBX Options. (line 50)
30042 * DBX_OUTPUT_LBRAC: DBX Hooks. (line 9)
30043 * DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 34)
30044 * DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 9)
30045 * DBX_OUTPUT_NFUN: DBX Hooks. (line 18)
30046 * DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX.
30048 * DBX_OUTPUT_RBRAC: DBX Hooks. (line 15)
30049 * DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 22)
30050 * DBX_REGISTER_NUMBER: All Debuggers. (line 9)
30051 * DBX_REGPARM_STABS_CODE: DBX Options. (line 87)
30052 * DBX_REGPARM_STABS_LETTER: DBX Options. (line 92)
30053 * DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 82)
30054 * DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 73)
30055 * DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 78)
30056 * DBX_USE_BINCL: DBX Options. (line 115)
30057 * DCmode: Machine Modes. (line 111)
30058 * De Morgan's law: Insn Canonicalizations.
30060 * dead_or_set_p: define_peephole. (line 65)
30061 * DEBUG_SYMS_TEXT: DBX Options. (line 25)
30062 * DEBUGGER_ARG_OFFSET: All Debuggers. (line 37)
30063 * DEBUGGER_AUTO_OFFSET: All Debuggers. (line 28)
30064 * DECL_ALIGN: Declarations. (line 6)
30065 * DECL_ANTICIPATED: Function Basics. (line 48)
30066 * DECL_ARGUMENTS: Function Basics. (line 163)
30067 * DECL_ARRAY_DELETE_OPERATOR_P: Function Basics. (line 184)
30068 * DECL_ARTIFICIAL <1>: Function Basics. (line 6)
30069 * DECL_ARTIFICIAL: Working with declarations.
30071 * DECL_ASSEMBLER_NAME: Function Basics. (line 6)
30072 * DECL_ATTRIBUTES: Attributes. (line 22)
30073 * DECL_BASE_CONSTRUCTOR_P: Function Basics. (line 94)
30074 * DECL_CLASS_SCOPE_P: Working with declarations.
30076 * DECL_COMPLETE_CONSTRUCTOR_P: Function Basics. (line 90)
30077 * DECL_COMPLETE_DESTRUCTOR_P: Function Basics. (line 104)
30078 * DECL_CONST_MEMFUNC_P: Function Basics. (line 77)
30079 * DECL_CONSTRUCTOR_P: Function Basics. (line 6)
30080 * DECL_CONTEXT: Namespaces. (line 26)
30081 * DECL_CONV_FN_P: Function Basics. (line 6)
30082 * DECL_COPY_CONSTRUCTOR_P: Function Basics. (line 98)
30083 * DECL_DESTRUCTOR_P: Function Basics. (line 6)
30084 * DECL_EXTERN_C_FUNCTION_P: Function Basics. (line 52)
30085 * DECL_EXTERNAL <1>: Function Basics. (line 38)
30086 * DECL_EXTERNAL: Declarations. (line 6)
30087 * DECL_FUNCTION_MEMBER_P: Function Basics. (line 6)
30088 * DECL_FUNCTION_SCOPE_P: Working with declarations.
30090 * DECL_GLOBAL_CTOR_P: Function Basics. (line 6)
30091 * DECL_GLOBAL_DTOR_P: Function Basics. (line 6)
30092 * DECL_INITIAL: Declarations. (line 6)
30093 * DECL_LINKONCE_P: Function Basics. (line 6)
30094 * DECL_LOCAL_FUNCTION_P: Function Basics. (line 44)
30095 * DECL_MAIN_P: Function Basics. (line 7)
30096 * DECL_NAME <1>: Function Basics. (line 6)
30097 * DECL_NAME <2>: Working with declarations.
30099 * DECL_NAME: Namespaces. (line 15)
30100 * DECL_NAMESPACE_ALIAS: Namespaces. (line 30)
30101 * DECL_NAMESPACE_SCOPE_P: Working with declarations.
30103 * DECL_NAMESPACE_STD_P: Namespaces. (line 40)
30104 * DECL_NON_THUNK_FUNCTION_P: Function Basics. (line 144)
30105 * DECL_NONCONVERTING_P: Function Basics. (line 86)
30106 * DECL_NONSTATIC_MEMBER_FUNCTION_P: Function Basics. (line 74)
30107 * DECL_OVERLOADED_OPERATOR_P: Function Basics. (line 6)
30108 * DECL_RESULT: Function Basics. (line 168)
30109 * DECL_SIZE: Declarations. (line 6)
30110 * DECL_STATIC_FUNCTION_P: Function Basics. (line 71)
30111 * DECL_STMT: Function Bodies. (line 6)
30112 * DECL_STMT_DECL: Function Bodies. (line 6)
30113 * DECL_THUNK_P: Function Basics. (line 122)
30114 * DECL_VOLATILE_MEMFUNC_P: Function Basics. (line 80)
30115 * declaration: Declarations. (line 6)
30116 * declarations, RTL: RTL Declarations. (line 6)
30117 * DECLARE_LIBRARY_RENAMES: Library Calls. (line 9)
30118 * decrement_and_branch_until_zero instruction pattern: Standard Names.
30120 * default: GTY Options. (line 82)
30121 * default_file_start: File Framework. (line 9)
30122 * DEFAULT_GDB_EXTENSIONS: DBX Options. (line 18)
30123 * DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 34)
30124 * DEFAULT_SIGNED_CHAR: Type Layout. (line 102)
30125 * define_asm_attributes: Tagging Insns. (line 73)
30126 * define_attr: Defining Attributes.
30128 * define_automaton: Processor pipeline description.
30130 * define_bypass: Processor pipeline description.
30132 * define_code_attr: Code Macros. (line 6)
30133 * define_code_macro: Code Macros. (line 6)
30134 * define_cond_exec: Conditional Execution.
30136 * define_constants: Constant Definitions.
30138 * define_cpu_unit: Processor pipeline description.
30140 * define_delay: Delay Slots. (line 25)
30141 * define_expand: Expander Definitions.
30143 * define_insn: Patterns. (line 6)
30144 * define_insn example: Example. (line 6)
30145 * define_insn_and_split: Insn Splitting. (line 170)
30146 * define_insn_reservation: Processor pipeline description.
30148 * define_mode_attr: Substitutions. (line 6)
30149 * define_mode_macro: Defining Mode Macros.
30151 * define_peephole: define_peephole. (line 6)
30152 * define_peephole2: define_peephole2. (line 6)
30153 * define_predicate: Defining Predicates.
30155 * define_query_cpu_unit: Processor pipeline description.
30157 * define_reservation: Processor pipeline description.
30159 * define_special_predicate: Defining Predicates.
30161 * define_split: Insn Splitting. (line 32)
30162 * defining attributes and their values: Defining Attributes.
30164 * defining jump instruction patterns: Jump Patterns. (line 6)
30165 * defining looping instruction patterns: Looping Patterns. (line 6)
30166 * defining peephole optimizers: Peephole Definitions.
30168 * defining predicates: Defining Predicates.
30170 * defining RTL sequences for code generation: Expander Definitions.
30172 * delay slots, defining: Delay Slots. (line 6)
30173 * DELAY_SLOTS_FOR_EPILOGUE: Function Entry. (line 163)
30174 * deletable: GTY Options. (line 150)
30175 * DELETE_IF_ORDINARY: Filesystem. (line 79)
30176 * Dependent Patterns: Dependent Patterns. (line 6)
30177 * desc: GTY Options. (line 82)
30178 * destructor: Function Basics. (line 6)
30179 * destructors, output of: Initialization. (line 6)
30180 * deterministic finite state automaton: Processor pipeline description.
30182 * DFmode: Machine Modes. (line 73)
30183 * digits in constraint: Simple Constraints. (line 118)
30184 * DImode: Machine Modes. (line 45)
30185 * DIR_SEPARATOR: Filesystem. (line 18)
30186 * DIR_SEPARATOR_2: Filesystem. (line 19)
30187 * directory options .md: Including Patterns. (line 44)
30188 * disabling certain registers: Register Basics. (line 76)
30189 * dispatch table: Dispatch Tables. (line 8)
30190 * div: Arithmetic. (line 100)
30191 * div and attributes: Expressions. (line 64)
30192 * division: Arithmetic. (line 100)
30193 * divM3 instruction pattern: Standard Names. (line 193)
30194 * divmodM4 instruction pattern: Standard Names. (line 255)
30195 * DO_BODY: Function Bodies. (line 6)
30196 * DO_COND: Function Bodies. (line 6)
30197 * DO_STMT: Function Bodies. (line 6)
30198 * DOLLARS_IN_IDENTIFIERS: Misc. (line 453)
30199 * doloop_begin instruction pattern: Standard Names. (line 908)
30200 * doloop_end instruction pattern: Standard Names. (line 887)
30201 * DONE: Expander Definitions.
30203 * DOUBLE_TYPE_SIZE: Type Layout. (line 53)
30204 * driver: Driver. (line 6)
30205 * DRIVER_SELF_SPECS: Driver. (line 71)
30206 * DUMPFILE_FORMAT: Filesystem. (line 67)
30207 * DWARF2_ASM_LINE_DEBUG_INFO: SDB and DWARF. (line 36)
30208 * DWARF2_DEBUGGING_INFO: SDB and DWARF. (line 13)
30209 * DWARF2_FRAME_INFO: SDB and DWARF. (line 30)
30210 * DWARF2_FRAME_REG_OUT: Frame Registers. (line 133)
30211 * DWARF2_UNWIND_INFO: Exception Region Output.
30213 * DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 144)
30214 * DWARF_CIE_DATA_ALIGNMENT: Exception Region Output.
30216 * DWARF_FRAME_REGISTERS: Frame Registers. (line 93)
30217 * DWARF_FRAME_REGNUM: Frame Registers. (line 125)
30218 * DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 117)
30219 * DWARF_ZERO_REG: Frame Layout. (line 151)
30220 * DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 92)
30221 * E in constraint: Simple Constraints. (line 77)
30222 * earlyclobber operand: Modifiers. (line 25)
30223 * edge: Edges. (line 6)
30224 * edge in the flow graph: Edges. (line 6)
30225 * edge iterators: Edges. (line 15)
30226 * edge splitting: Maintaining the CFG.
30228 * EDGE_ABNORMAL: Edges. (line 128)
30229 * EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 171)
30230 * EDGE_ABNORMAL, EDGE_EH: Edges. (line 96)
30231 * EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 122)
30232 * EDGE_FALLTHRU, force_nonfallthru: Edges. (line 86)
30233 * EDOM, implicit usage: Library Calls. (line 58)
30234 * EH_FRAME_IN_DATA_SECTION: Exception Region Output.
30236 * EH_FRAME_SECTION_NAME: Exception Region Output.
30238 * eh_return instruction pattern: Standard Names. (line 1076)
30239 * EH_RETURN_DATA_REGNO: Exception Handling. (line 7)
30240 * EH_RETURN_HANDLER_RTX: Exception Handling. (line 39)
30241 * EH_RETURN_STACKADJ_RTX: Exception Handling. (line 22)
30242 * EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output.
30244 * EH_USES: Function Entry. (line 158)
30245 * ei_edge: Edges. (line 43)
30246 * ei_end_p: Edges. (line 27)
30247 * ei_last: Edges. (line 23)
30248 * ei_next: Edges. (line 35)
30249 * ei_one_before_end_p: Edges. (line 31)
30250 * ei_prev: Edges. (line 39)
30251 * ei_safe_safe: Edges. (line 47)
30252 * ei_start: Edges. (line 19)
30253 * ELIGIBLE_FOR_EPILOGUE_DELAY: Function Entry. (line 169)
30254 * ELIMINABLE_REGS: Elimination. (line 44)
30255 * ELSE_CLAUSE: Function Bodies. (line 6)
30256 * EMIT_MODE_SET: Mode Switching. (line 74)
30257 * Empty Statements: Empty Statements. (line 6)
30258 * EMPTY_CLASS_EXPR: Function Bodies. (line 6)
30259 * EMPTY_FIELD_BOUNDARY: Storage Layout. (line 236)
30260 * ENABLE_EXECUTE_STACK: Trampolines. (line 111)
30261 * ENDFILE_SPEC: Driver. (line 218)
30262 * endianness: Portability. (line 21)
30263 * ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 28)
30264 * enum machine_mode: Machine Modes. (line 6)
30265 * enum reg_class: Register Classes. (line 65)
30266 * ENUMERAL_TYPE: Types. (line 6)
30267 * epilogue: Function Entry. (line 6)
30268 * epilogue instruction pattern: Standard Names. (line 1108)
30269 * EPILOGUE_USES: Function Entry. (line 152)
30270 * eq: Comparisons. (line 52)
30271 * eq and attributes: Expressions. (line 64)
30272 * eq_attr: Expressions. (line 85)
30273 * EQ_EXPR: Expression trees. (line 6)
30274 * equal: Comparisons. (line 52)
30275 * errno, implicit usage: Library Calls. (line 70)
30276 * EXACT_DIV_EXPR: Expression trees. (line 6)
30277 * examining SSA_NAMEs: SSA. (line 189)
30278 * exception handling <1>: Exception Handling. (line 6)
30279 * exception handling: Edges. (line 96)
30280 * exception_receiver instruction pattern: Standard Names. (line 1040)
30281 * exclamation point: Multi-Alternative. (line 47)
30282 * exclusion_set: Processor pipeline description.
30284 * exclusive-or, bitwise: Arithmetic. (line 146)
30285 * EXIT_EXPR: Expression trees. (line 6)
30286 * EXIT_IGNORE_STACK: Function Entry. (line 140)
30287 * expander definitions: Expander Definitions.
30289 * expM2 instruction pattern: Standard Names. (line 319)
30290 * expr_list: Insns. (line 545)
30291 * EXPR_STMT: Function Bodies. (line 6)
30292 * EXPR_STMT_EXPR: Function Bodies. (line 6)
30293 * expression: Expression trees. (line 6)
30294 * expression codes: RTL Objects. (line 47)
30295 * extendMN2 instruction pattern: Standard Names. (line 610)
30296 * extensible constraints: Simple Constraints. (line 161)
30297 * EXTRA_ADDRESS_CONSTRAINT: Register Classes. (line 499)
30298 * EXTRA_CONSTRAINT: Register Classes. (line 450)
30299 * EXTRA_CONSTRAINT_STR: Register Classes. (line 471)
30300 * EXTRA_MEMORY_CONSTRAINT: Register Classes. (line 476)
30301 * EXTRA_SECTION_FUNCTIONS: Sections. (line 110)
30302 * EXTRA_SECTIONS: Sections. (line 105)
30303 * EXTRA_SPECS: Driver. (line 245)
30304 * extv instruction pattern: Standard Names. (line 619)
30305 * extzv instruction pattern: Standard Names. (line 634)
30306 * F in constraint: Simple Constraints. (line 82)
30307 * FAIL: Expander Definitions.
30309 * fall-thru: Edges. (line 69)
30310 * FATAL_EXIT_CODE: Host Misc. (line 6)
30311 * FDL, GNU Free Documentation License: GNU Free Documentation License.
30313 * features, optional, in system conventions: Run-time Target.
30315 * ffs: Arithmetic. (line 176)
30316 * ffsM2 instruction pattern: Standard Names. (line 413)
30317 * FIELD_DECL: Declarations. (line 6)
30318 * file_end_indicate_exec_stack: File Framework. (line 41)
30319 * files and passes of the compiler: Passes. (line 6)
30320 * files, generated: Files. (line 6)
30321 * final_absence_set: Processor pipeline description.
30323 * FINAL_PRESCAN_INSN: Instruction Output. (line 46)
30324 * final_presence_set: Processor pipeline description.
30326 * final_scan_insn: Function Entry. (line 181)
30327 * final_sequence: Instruction Output. (line 117)
30328 * FIND_BASE_TERM: Addressing Modes. (line 139)
30329 * FINI_ARRAY_SECTION_ASM_OP: Sections. (line 81)
30330 * FINI_SECTION_ASM_OP: Sections. (line 68)
30331 * finite state automaton minimization: Processor pipeline description.
30333 * FIRST_PARM_OFFSET: Frame Layout. (line 67)
30334 * FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65)
30335 * FIRST_PSEUDO_REGISTER: Register Basics. (line 9)
30336 * FIRST_STACK_REG: Stack Registers. (line 23)
30337 * FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51)
30338 * fix: Conversions. (line 66)
30339 * FIX_TRUNC_EXPR: Expression trees. (line 6)
30340 * fix_truncMN2 instruction pattern: Standard Names. (line 597)
30341 * fixed register: Register Basics. (line 15)
30342 * FIXED_REGISTERS: Register Basics. (line 15)
30343 * fixed_regs: Register Basics. (line 59)
30344 * fixMN2 instruction pattern: Standard Names. (line 577)
30345 * FIXUNS_TRUNC_LIKE_FIX_TRUNC: Misc. (line 100)
30346 * fixuns_truncMN2 instruction pattern: Standard Names. (line 601)
30347 * fixunsMN2 instruction pattern: Standard Names. (line 586)
30348 * flags in RTL expression: Flags. (line 6)
30349 * float: Conversions. (line 58)
30350 * FLOAT_EXPR: Expression trees. (line 6)
30351 * float_extend: Conversions. (line 33)
30352 * FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 25)
30353 * FLOAT_STORE_FLAG_VALUE: Misc. (line 275)
30354 * float_truncate: Conversions. (line 53)
30355 * FLOAT_TYPE_SIZE: Type Layout. (line 49)
30356 * FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 43)
30357 * FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory.
30359 * floating point and cross compilation: Floating Point. (line 6)
30360 * Floating Point Emulation: Target Fragment. (line 15)
30361 * floating point emulation library, US Software GOFAST: Library Calls.
30363 * floatMN2 instruction pattern: Standard Names. (line 569)
30364 * floatunsMN2 instruction pattern: Standard Names. (line 573)
30365 * FLOOR_DIV_EXPR: Expression trees. (line 6)
30366 * FLOOR_MOD_EXPR: Expression trees. (line 6)
30367 * floorM2 instruction pattern: Standard Names. (line 354)
30368 * flow-insensitive alias analysis: Alias analysis. (line 6)
30369 * flow-sensitive alias analysis: Alias analysis. (line 6)
30370 * FOR_BODY: Function Bodies. (line 6)
30371 * FOR_COND: Function Bodies. (line 6)
30372 * FOR_EXPR: Function Bodies. (line 6)
30373 * FOR_INIT_STMT: Function Bodies. (line 6)
30374 * FOR_STMT: Function Bodies. (line 6)
30375 * FORCE_CODE_SECTION_ALIGN: Sections. (line 99)
30376 * force_reg: Standard Names. (line 36)
30377 * frame layout: Frame Layout. (line 6)
30378 * FRAME_GROWS_DOWNWARD: Frame Layout. (line 31)
30379 * FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory.
30381 * FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 200)
30382 * frame_pointer_needed: Function Entry. (line 34)
30383 * FRAME_POINTER_REGNUM: Frame Registers. (line 14)
30384 * FRAME_POINTER_REGNUM and virtual registers: Regs and Memory.
30386 * FRAME_POINTER_REQUIRED: Elimination. (line 9)
30387 * frame_pointer_rtx: Frame Registers. (line 85)
30388 * frame_related: Flags. (line 229)
30389 * frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags.
30391 * frame_related, in mem: Flags. (line 75)
30392 * frame_related, in reg: Flags. (line 98)
30393 * frame_related, in symbol_ref: Flags. (line 173)
30394 * frequency, count, BB_FREQ_BASE: Profile information.
30396 * ftruncM2 instruction pattern: Standard Names. (line 592)
30397 * function: Functions. (line 6)
30398 * function body: Function Bodies. (line 6)
30399 * function call conventions: Interface. (line 6)
30400 * function entry and exit: Function Entry. (line 6)
30401 * function entry point, alternate function entry point: Edges.
30403 * function-call insns: Calls. (line 6)
30404 * FUNCTION_ARG: Register Arguments. (line 11)
30405 * FUNCTION_ARG_ADVANCE: Register Arguments. (line 178)
30406 * FUNCTION_ARG_BOUNDARY: Register Arguments. (line 224)
30407 * FUNCTION_ARG_PADDING: Register Arguments. (line 189)
30408 * FUNCTION_ARG_REGNO_P: Register Arguments. (line 229)
30409 * FUNCTION_BOUNDARY: Storage Layout. (line 164)
30410 * FUNCTION_DECL: Functions. (line 6)
30411 * FUNCTION_INCOMING_ARG: Register Arguments. (line 68)
30412 * FUNCTION_MODE: Misc. (line 323)
30413 * FUNCTION_OUTGOING_VALUE: Scalar Return. (line 36)
30414 * FUNCTION_PROFILER: Profiling. (line 9)
30415 * FUNCTION_TYPE: Types. (line 6)
30416 * FUNCTION_VALUE: Scalar Return. (line 10)
30417 * FUNCTION_VALUE_REGNO_P: Scalar Return. (line 70)
30418 * functions, leaf: Leaf Functions. (line 6)
30419 * fundamental type: Types. (line 6)
30420 * g in constraint: Simple Constraints. (line 108)
30421 * G in constraint: Simple Constraints. (line 86)
30422 * GCC and portability: Portability. (line 6)
30423 * GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36)
30424 * gcov_type: Profile information.
30426 * ge: Comparisons. (line 72)
30427 * ge and attributes: Expressions. (line 64)
30428 * GE_EXPR: Expression trees. (line 6)
30429 * GEN_ERRNO_RTX: Library Calls. (line 71)
30430 * gencodes: RTL passes. (line 18)
30431 * general_operand: Machine-Independent Predicates.
30433 * GENERAL_REGS: Register Classes. (line 23)
30434 * generated files: Files. (line 6)
30435 * generating assembler output: Output Statement. (line 6)
30436 * generating insns: RTL Template. (line 6)
30437 * GENERIC <1>: GENERIC. (line 6)
30438 * GENERIC <2>: Gimplification pass.
30440 * GENERIC: Parsing pass. (line 6)
30441 * generic predicates: Machine-Independent Predicates.
30443 * genflags: RTL passes. (line 18)
30444 * get_attr: Expressions. (line 80)
30445 * get_attr_length: Insn Lengths. (line 46)
30446 * GET_CLASS_NARROWEST_MODE: Machine Modes. (line 219)
30447 * GET_CODE: RTL Objects. (line 47)
30448 * get_frame_size: Elimination. (line 31)
30449 * get_insns: Insns. (line 34)
30450 * get_last_insn: Insns. (line 34)
30451 * GET_MODE: Machine Modes. (line 174)
30452 * GET_MODE_ALIGNMENT: Machine Modes. (line 206)
30453 * GET_MODE_BITSIZE: Machine Modes. (line 198)
30454 * GET_MODE_CLASS: Machine Modes. (line 188)
30455 * GET_MODE_MASK: Machine Modes. (line 201)
30456 * GET_MODE_NAME: Machine Modes. (line 185)
30457 * GET_MODE_NUNITS: Machine Modes. (line 215)
30458 * GET_MODE_SIZE: Machine Modes. (line 195)
30459 * GET_MODE_UNIT_SIZE: Machine Modes. (line 209)
30460 * GET_MODE_WIDER_MODE: Machine Modes. (line 191)
30461 * GET_RTX_CLASS: RTL Classes. (line 6)
30462 * GET_RTX_FORMAT: RTL Classes. (line 130)
30463 * GET_RTX_LENGTH: RTL Classes. (line 127)
30464 * geu: Comparisons. (line 72)
30465 * geu and attributes: Expressions. (line 64)
30466 * GGC: Type Information. (line 6)
30467 * GIMPLE <1>: GIMPLE. (line 6)
30468 * GIMPLE <2>: Gimplification pass.
30470 * GIMPLE: Parsing pass. (line 14)
30471 * GIMPLE Example: GIMPLE Example. (line 6)
30472 * GIMPLE Exception Handling: GIMPLE Exception Handling.
30474 * GIMPLE Expressions: GIMPLE Expressions. (line 6)
30475 * gimplification <1>: Interfaces. (line 6)
30476 * gimplification <2>: Gimplification pass.
30478 * gimplification: Parsing pass. (line 14)
30479 * gimplifier: Parsing pass. (line 14)
30480 * gimplify_expr: Gimplification pass.
30482 * gimplify_function_tree: Gimplification pass.
30484 * GLOBAL_INIT_PRIORITY: Function Basics. (line 6)
30485 * global_live_at_start, global_live_at_end: Liveness information.
30487 * global_regs: Register Basics. (line 59)
30488 * GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 48)
30489 * GO_IF_MODE_DEPENDENT_ADDRESS: Addressing Modes. (line 217)
30490 * GOFAST, floating point emulation library: Library Calls. (line 44)
30491 * gofast_maybe_init_libfuncs: Library Calls. (line 44)
30492 * greater than: Comparisons. (line 60)
30493 * gt: Comparisons. (line 60)
30494 * gt and attributes: Expressions. (line 64)
30495 * GT_EXPR: Expression trees. (line 6)
30496 * gtu: Comparisons. (line 64)
30497 * gtu and attributes: Expressions. (line 64)
30498 * GTY: Type Information. (line 6)
30499 * H in constraint: Simple Constraints. (line 86)
30500 * HANDLE_PRAGMA_PACK_PUSH_POP: Misc. (line 432)
30501 * HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 443)
30502 * HANDLE_SYSV_PRAGMA: Misc. (line 403)
30503 * HANDLER: Function Bodies. (line 6)
30504 * HANDLER_BODY: Function Bodies. (line 6)
30505 * HANDLER_PARMS: Function Bodies. (line 6)
30506 * hard registers: Regs and Memory. (line 9)
30507 * HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 20)
30508 * HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 53)
30509 * HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 20)
30510 * HARD_REGNO_MODE_OK: Values in Registers.
30512 * HARD_REGNO_NREGS: Values in Registers.
30514 * HARD_REGNO_NREGS_HAS_PADDING: Values in Registers.
30516 * HARD_REGNO_NREGS_WITH_PADDING: Values in Registers.
30518 * HARD_REGNO_RENAME_OK: Values in Registers.
30520 * HAS_INIT_SECTION: Macros for Initialization.
30522 * HAS_LONG_COND_BRANCH: Misc. (line 9)
30523 * HAS_LONG_UNCOND_BRANCH: Misc. (line 18)
30524 * HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11)
30525 * HAVE_POST_DECREMENT: Addressing Modes. (line 12)
30526 * HAVE_POST_INCREMENT: Addressing Modes. (line 11)
30527 * HAVE_POST_MODIFY_DISP: Addressing Modes. (line 18)
30528 * HAVE_POST_MODIFY_REG: Addressing Modes. (line 24)
30529 * HAVE_PRE_DECREMENT: Addressing Modes. (line 10)
30530 * HAVE_PRE_INCREMENT: Addressing Modes. (line 9)
30531 * HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 17)
30532 * HAVE_PRE_MODIFY_REG: Addressing Modes. (line 23)
30533 * HCmode: Machine Modes. (line 111)
30534 * HFmode: Machine Modes. (line 58)
30535 * high: Constants. (line 120)
30536 * HImode: Machine Modes. (line 29)
30537 * HImode, in insn: Insns. (line 242)
30538 * host configuration: Host Config. (line 6)
30539 * host functions: Host Common. (line 6)
30540 * host hooks: Host Common. (line 6)
30541 * host makefile fragment: Host Fragment. (line 6)
30542 * HOST_BIT_BUCKET: Filesystem. (line 51)
30543 * HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45)
30544 * HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 12)
30545 * HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 45)
30546 * HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 26)
30547 * HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89)
30548 * HOST_LONG_LONG_FORMAT: Host Misc. (line 46)
30549 * HOST_OBJECT_SUFFIX: Filesystem. (line 40)
30550 * HOT_TEXT_SECTION_NAME: Sections. (line 23)
30551 * I in constraint: Simple Constraints. (line 69)
30552 * i in constraint: Simple Constraints. (line 58)
30553 * IBM_FLOAT_FORMAT: Storage Layout. (line 396)
30554 * identifier: Identifiers. (line 6)
30555 * IDENTIFIER_LENGTH: Identifiers. (line 20)
30556 * IDENTIFIER_NODE: Identifiers. (line 6)
30557 * IDENTIFIER_OPNAME_P: Identifiers. (line 25)
30558 * IDENTIFIER_POINTER: Identifiers. (line 15)
30559 * IDENTIFIER_TYPENAME_P: Identifiers. (line 31)
30560 * IEEE_FLOAT_FORMAT: Storage Layout. (line 386)
30561 * IF_COND: Function Bodies. (line 6)
30562 * if_marked: GTY Options. (line 156)
30563 * IF_STMT: Function Bodies. (line 6)
30564 * if_then_else: Comparisons. (line 80)
30565 * if_then_else and attributes: Expressions. (line 32)
30566 * if_then_else usage: Side Effects. (line 56)
30567 * IFCVT_EXTRA_FIELDS: Misc. (line 584)
30568 * IFCVT_INIT_EXTRA_FIELDS: Misc. (line 579)
30569 * IFCVT_MODIFY_CANCEL: Misc. (line 573)
30570 * IFCVT_MODIFY_FINAL: Misc. (line 567)
30571 * IFCVT_MODIFY_INSN: Misc. (line 561)
30572 * IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 554)
30573 * IFCVT_MODIFY_TESTS: Misc. (line 543)
30574 * IMAGPART_EXPR: Expression trees. (line 6)
30575 * Immediate Uses: Statement Operands. (line 291)
30576 * immediate_operand: Machine-Independent Predicates.
30578 * IMMEDIATE_PREFIX: Instruction Output. (line 127)
30579 * in_data: Sections. (line 104)
30580 * in_struct: Flags. (line 244)
30581 * in_struct, in code_label and note: Flags. (line 49)
30582 * in_struct, in insn and jump_insn and call_insn: Flags. (line 34)
30583 * in_struct, in insn, jump_insn and call_insn: Flags. (line 156)
30584 * in_struct, in label_ref: Flags. (line 44)
30585 * in_struct, in mem: Flags. (line 60)
30586 * in_struct, in subreg: Flags. (line 195)
30587 * in_text: Sections. (line 104)
30588 * include: Including Patterns. (line 6)
30589 * INCLUDE_DEFAULTS: Driver. (line 430)
30590 * inclusive-or, bitwise: Arithmetic. (line 141)
30591 * INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 171)
30592 * INCOMING_REGNO: Register Basics. (line 91)
30593 * INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 131)
30594 * INDEX_REG_CLASS: Register Classes. (line 125)
30595 * indirect_jump instruction pattern: Standard Names. (line 835)
30596 * indirect_operand: Machine-Independent Predicates.
30598 * INDIRECT_REF: Expression trees. (line 6)
30599 * INIT_ARRAY_SECTION_ASM_OP: Sections. (line 74)
30600 * INIT_CUMULATIVE_ARGS: Register Arguments. (line 141)
30601 * INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 169)
30602 * INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 162)
30603 * INIT_ENVIRONMENT: Driver. (line 369)
30604 * INIT_EXPANDERS: Per-Function Data. (line 39)
30605 * INIT_EXPR: Expression trees. (line 6)
30606 * init_machine_status: Per-Function Data. (line 45)
30607 * init_one_libfunc: Library Calls. (line 15)
30608 * INIT_SECTION_ASM_OP <1>: Macros for Initialization.
30610 * INIT_SECTION_ASM_OP: Sections. (line 62)
30611 * INITIAL_ELIMINATION_OFFSET: Elimination. (line 79)
30612 * INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 83)
30613 * INITIAL_FRAME_POINTER_OFFSET: Elimination. (line 32)
30614 * initialization routines: Initialization. (line 6)
30615 * INITIALIZE_TRAMPOLINE: Trampolines. (line 56)
30616 * inlining: Target Attributes. (line 86)
30617 * insert_insn_on_edge: Maintaining the CFG.
30619 * insn: Insns. (line 63)
30620 * insn and /f: Flags. (line 111)
30621 * insn and /i: Flags. (line 138)
30622 * insn and /j: Flags. (line 165)
30623 * insn and /s: Flags. (line 34)
30624 * insn and /u: Flags. (line 24)
30625 * insn and /v: Flags. (line 29)
30626 * insn attributes: Insn Attributes. (line 6)
30627 * insn canonicalization: Insn Canonicalizations.
30629 * insn includes: Including Patterns. (line 6)
30630 * insn lengths, computing: Insn Lengths. (line 6)
30631 * insn splitting: Insn Splitting. (line 6)
30632 * insn-attr.h: Defining Attributes.
30634 * INSN_ANNULLED_BRANCH_P: Flags. (line 24)
30635 * INSN_CODE: Insns. (line 268)
30636 * INSN_DELETED_P: Flags. (line 29)
30637 * INSN_FROM_TARGET_P: Flags. (line 34)
30638 * insn_list: Insns. (line 545)
30639 * insn_list and /i: Flags. (line 138)
30640 * INSN_REFERENCES_ARE_DELAYED: Misc. (line 482)
30641 * INSN_SETS_ARE_DELAYED: Misc. (line 471)
30642 * INSN_UID: Insns. (line 23)
30643 * insns: Insns. (line 6)
30644 * insns, generating: RTL Template. (line 6)
30645 * insns, recognizing: RTL Template. (line 6)
30646 * instruction attributes: Insn Attributes. (line 6)
30647 * instruction latency time: Processor pipeline description.
30649 * instruction patterns: Patterns. (line 6)
30650 * instruction splitting: Insn Splitting. (line 6)
30651 * insv instruction pattern: Standard Names. (line 637)
30652 * int: Run-time Target. (line 56)
30653 * INT_TYPE_SIZE: Type Layout. (line 12)
30654 * INTEGER_CST: Expression trees. (line 6)
30655 * INTEGER_TYPE: Types. (line 6)
30656 * integrated: Flags. (line 280)
30657 * integrated, in insn, call_insn, jump_insn, barrier, code_label, insn_list, const, and note: Flags.
30659 * integrated, in reg: Flags. (line 93)
30660 * integrated, in symbol_ref: Flags. (line 210)
30661 * Interdependence of Patterns: Dependent Patterns. (line 6)
30662 * interfacing to GCC output: Interface. (line 6)
30663 * interlock delays: Processor pipeline description.
30665 * intermediate representation lowering: Parsing pass. (line 14)
30666 * INTMAX_TYPE: Type Layout. (line 161)
30667 * introduction: Top. (line 6)
30668 * INVOKE__main: Macros for Initialization.
30670 * ior: Arithmetic. (line 141)
30671 * ior and attributes: Expressions. (line 50)
30672 * ior, canonicalization of: Insn Canonicalizations.
30674 * iorM3 instruction pattern: Standard Names. (line 193)
30675 * IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 120)
30676 * jump: Flags. (line 293)
30677 * jump instruction pattern: Standard Names. (line 726)
30678 * jump instruction patterns: Jump Patterns. (line 6)
30679 * jump instructions and set: Side Effects. (line 56)
30680 * jump, in call_insn: Flags. (line 169)
30681 * jump, in insn: Flags. (line 165)
30682 * jump, in mem: Flags. (line 69)
30683 * JUMP_ALIGN: Alignment Output. (line 9)
30684 * jump_insn: Insns. (line 73)
30685 * jump_insn and /f: Flags. (line 111)
30686 * jump_insn and /i: Flags. (line 138)
30687 * jump_insn and /s: Flags. (line 34)
30688 * jump_insn and /u: Flags. (line 24)
30689 * jump_insn and /v: Flags. (line 29)
30690 * JUMP_LABEL: Insns. (line 79)
30691 * JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 116)
30692 * Jumps: Jumps. (line 6)
30693 * LABEL_ALIGN: Alignment Output. (line 52)
30694 * LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 22)
30695 * LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output. (line 30)
30696 * LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 62)
30697 * LABEL_ALT_ENTRY_P: Insns. (line 145)
30698 * LABEL_ALTERNATE_NAME: Edges. (line 180)
30699 * LABEL_DECL: Declarations. (line 6)
30700 * LABEL_KIND: Insns. (line 145)
30701 * LABEL_NUSES: Insns. (line 141)
30702 * LABEL_OUTSIDE_LOOP_P: Flags. (line 44)
30703 * LABEL_PRESERVE_P: Flags. (line 49)
30704 * label_ref: Constants. (line 97)
30705 * label_ref and /s: Flags. (line 44)
30706 * label_ref and /v: Flags. (line 55)
30707 * label_ref, RTL sharing: Sharing. (line 35)
30708 * LABEL_REF_NONLOCAL_P: Flags. (line 55)
30709 * lang_hooks.gimplify_expr: Gimplification pass.
30711 * lang_hooks.parse_file: Parsing pass. (line 6)
30712 * language-independent intermediate representation: Parsing pass.
30714 * large return values: Aggregate Return. (line 6)
30715 * LARGEST_EXPONENT_IS_NORMAL: Storage Layout. (line 472)
30716 * LAST_STACK_REG: Stack Registers. (line 27)
30717 * LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51)
30718 * LD_FINI_SWITCH: Macros for Initialization.
30720 * LD_INIT_SWITCH: Macros for Initialization.
30722 * LDD_SUFFIX: Macros for Initialization.
30724 * le: Comparisons. (line 76)
30725 * le and attributes: Expressions. (line 64)
30726 * LE_EXPR: Expression trees. (line 6)
30727 * leaf functions: Leaf Functions. (line 6)
30728 * leaf_function_p: Standard Names. (line 797)
30729 * LEAF_REG_REMAP: Leaf Functions. (line 39)
30730 * LEAF_REGISTERS: Leaf Functions. (line 25)
30731 * left rotate: Arithmetic. (line 164)
30732 * left shift: Arithmetic. (line 151)
30733 * LEGITIMATE_CONSTANT_P: Addressing Modes. (line 232)
30734 * LEGITIMATE_PIC_OPERAND_P: PIC. (line 31)
30735 * LEGITIMIZE_ADDRESS: Addressing Modes. (line 149)
30736 * LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 172)
30737 * length: GTY Options. (line 50)
30738 * less than: Comparisons. (line 68)
30739 * less than or equal: Comparisons. (line 76)
30740 * leu: Comparisons. (line 76)
30741 * leu and attributes: Expressions. (line 64)
30742 * LIB2FUNCS_EXTRA: Target Fragment. (line 11)
30743 * LIB_SPEC: Driver. (line 170)
30744 * LIBCALL_VALUE: Scalar Return. (line 53)
30745 * libgcc.a: Library Calls. (line 6)
30746 * LIBGCC2_CFLAGS: Target Fragment. (line 8)
30747 * LIBGCC2_HAS_DF_MODE: Type Layout. (line 69)
30748 * LIBGCC2_HAS_TF_MODE: Type Layout. (line 83)
30749 * LIBGCC2_HAS_XF_MODE: Type Layout. (line 77)
30750 * LIBGCC2_LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 63)
30751 * LIBGCC2_WORDS_BIG_ENDIAN: Storage Layout. (line 36)
30752 * LIBGCC_SPEC: Driver. (line 178)
30753 * library subroutine names: Library Calls. (line 6)
30754 * LIBRARY_PATH_ENV: Misc. (line 522)
30755 * LIMIT_RELOAD_CLASS: Register Classes. (line 229)
30756 * LINK_COMMAND_SPEC: Driver. (line 299)
30757 * LINK_EH_SPEC: Driver. (line 205)
30758 * LINK_ELIMINATE_DUPLICATE_LDIRECTORIES: Driver. (line 309)
30759 * LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 295)
30760 * LINK_LIBGCC_SPECIAL_1: Driver. (line 290)
30761 * LINK_SPEC: Driver. (line 163)
30762 * linkage: Function Basics. (line 6)
30763 * list: Containers. (line 6)
30764 * Liveness representation: Liveness information.
30766 * lo_sum: Arithmetic. (line 24)
30767 * load address instruction: Simple Constraints. (line 152)
30768 * LOAD_EXTEND_OP: Misc. (line 69)
30769 * load_multiple instruction pattern: Standard Names. (line 136)
30770 * LOCAL_ALIGNMENT: Storage Layout. (line 225)
30771 * LOCAL_CLASS_P: Classes. (line 68)
30772 * LOCAL_INCLUDE_DIR: Driver. (line 376)
30773 * LOCAL_LABEL_PREFIX: Instruction Output. (line 125)
30774 * LOCAL_REGNO: Register Basics. (line 105)
30775 * LOG_LINKS: Insns. (line 287)
30776 * Logical Operators: Logical Operators. (line 6)
30777 * logical-and, bitwise: Arithmetic. (line 136)
30778 * logM2 instruction pattern: Standard Names. (line 327)
30779 * LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 58)
30780 * LONG_LONG_TYPE_SIZE: Type Layout. (line 33)
30781 * LONG_TYPE_SIZE: Type Layout. (line 22)
30782 * longjmp and automatic variables: Interface. (line 52)
30783 * LOOP_ALIGN: Alignment Output. (line 35)
30784 * LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 48)
30785 * LOOP_EXPR: Expression trees. (line 6)
30786 * looping instruction patterns: Looping Patterns. (line 6)
30787 * Loops: Loops. (line 6)
30788 * lowering, language-dependent intermediate representation: Parsing pass.
30790 * LSHIFT_EXPR: Expression trees. (line 6)
30791 * lshiftrt: Arithmetic. (line 159)
30792 * lshiftrt and attributes: Expressions. (line 64)
30793 * lshrM3 instruction pattern: Standard Names. (line 285)
30794 * lt: Comparisons. (line 68)
30795 * lt and attributes: Expressions. (line 64)
30796 * LT_EXPR: Expression trees. (line 6)
30797 * LTGT_EXPR: Expression trees. (line 6)
30798 * ltu: Comparisons. (line 68)
30799 * m in constraint: Simple Constraints. (line 17)
30800 * machine attributes: Target Attributes. (line 6)
30801 * machine description macros: Target Macros. (line 6)
30802 * machine descriptions: Machine Desc. (line 6)
30803 * machine mode conversions: Conversions. (line 6)
30804 * machine modes: Machine Modes. (line 6)
30805 * machine specific constraints: Machine Constraints.
30807 * machine-independent predicates: Machine-Independent Predicates.
30809 * machine_mode: Condition Code. (line 157)
30810 * macros in .md files: Macros. (line 6)
30811 * macros, target description: Target Macros. (line 6)
30812 * MAKE_DECL_ONE_ONLY: Label Output. (line 209)
30813 * make_safe_from: Expander Definitions.
30815 * makefile fragment: Fragments. (line 6)
30816 * makefile targets: Makefile. (line 6)
30817 * marking roots: GGC Roots. (line 6)
30818 * MASK_RETURN_ADDR: Exception Region Output.
30820 * match_dup <1>: define_peephole2. (line 28)
30821 * match_dup: RTL Template. (line 73)
30822 * match_dup and attributes: Insn Lengths. (line 16)
30823 * match_op_dup: RTL Template. (line 163)
30824 * match_operand: RTL Template. (line 16)
30825 * match_operand and attributes: Expressions. (line 55)
30826 * match_operator: RTL Template. (line 95)
30827 * match_par_dup: RTL Template. (line 219)
30828 * match_parallel: RTL Template. (line 172)
30829 * match_scratch <1>: define_peephole2. (line 28)
30830 * match_scratch: RTL Template. (line 58)
30831 * matching constraint: Simple Constraints. (line 130)
30832 * matching operands: Output Template. (line 49)
30833 * math library: Soft float library routines.
30835 * math, in RTL: Arithmetic. (line 6)
30836 * MATH_LIBRARY: Misc. (line 515)
30837 * matherr: Library Calls. (line 58)
30838 * MAX_BITS_PER_WORD: Storage Layout. (line 61)
30839 * MAX_CONDITIONAL_EXECUTE: Misc. (line 537)
30840 * MAX_DFA_ISSUE_RATE: Scheduling. (line 235)
30841 * MAX_FIXED_MODE_SIZE: Storage Layout. (line 355)
30842 * MAX_MOVE_MAX: Misc. (line 120)
30843 * MAX_OFILE_ALIGNMENT: Storage Layout. (line 193)
30844 * MAX_REGS_PER_ADDRESS: Addressing Modes. (line 42)
30845 * maxM3 instruction pattern: Standard Names. (line 200)
30846 * may_trap_p, tree_could_trap_p: Edges. (line 115)
30847 * maybe_undef: GTY Options. (line 171)
30848 * mcount: Profiling. (line 12)
30849 * MD_CAN_REDIRECT_BRANCH: Misc. (line 662)
30850 * MD_EXEC_PREFIX: Driver. (line 330)
30851 * MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 98)
30852 * MD_HANDLE_UNWABI: Exception Handling. (line 117)
30853 * MD_STARTFILE_PREFIX: Driver. (line 358)
30854 * MD_STARTFILE_PREFIX_1: Driver. (line 364)
30855 * MD_UNWIND_SUPPORT: Exception Handling. (line 94)
30856 * mem: Regs and Memory. (line 249)
30857 * mem and /c: Flags. (line 89)
30858 * mem and /f: Flags. (line 75)
30859 * mem and /j: Flags. (line 69)
30860 * mem and /s: Flags. (line 60)
30861 * mem and /u: Flags. (line 142)
30862 * mem and /v: Flags. (line 84)
30863 * mem, RTL sharing: Sharing. (line 40)
30864 * MEM_ALIAS_SET: Special Accessors. (line 9)
30865 * MEM_ALIGN: Special Accessors. (line 36)
30866 * MEM_EXPR: Special Accessors. (line 20)
30867 * MEM_IN_STRUCT_P: Flags. (line 60)
30868 * MEM_KEEP_ALIAS_SET_P: Flags. (line 69)
30869 * MEM_NOTRAP_P: Flags. (line 89)
30870 * MEM_OFFSET: Special Accessors. (line 28)
30871 * MEM_READONLY_P: Flags. (line 142)
30872 * MEM_SCALAR_P: Flags. (line 75)
30873 * MEM_SIZE: Special Accessors. (line 31)
30874 * MEM_VOLATILE_P: Flags. (line 84)
30875 * MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 333)
30876 * memory reference, nonoffsettable: Simple Constraints. (line 251)
30877 * memory references in constraints: Simple Constraints. (line 17)
30878 * memory_barrier instruction pattern: Standard Names. (line 1165)
30879 * MEMORY_MOVE_COST: Costs. (line 29)
30880 * memory_operand: Machine-Independent Predicates.
30882 * METHOD_TYPE: Types. (line 6)
30883 * MIN_UNITS_PER_WORD: Storage Layout. (line 71)
30884 * MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 171)
30885 * minM3 instruction pattern: Standard Names. (line 200)
30886 * minus: Arithmetic. (line 36)
30887 * minus and attributes: Expressions. (line 64)
30888 * minus, canonicalization of: Insn Canonicalizations.
30890 * MINUS_EXPR: Expression trees. (line 6)
30891 * MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6)
30892 * mod: Arithmetic. (line 114)
30893 * mod and attributes: Expressions. (line 64)
30894 * mode classes: Machine Modes. (line 133)
30895 * mode macros in .md files: Mode Macros. (line 6)
30896 * mode switching: Mode Switching. (line 6)
30897 * MODE_AFTER: Mode Switching. (line 49)
30898 * MODE_BASE_REG_CLASS: Register Classes. (line 112)
30899 * MODE_BASE_REG_REG_CLASS: Register Classes. (line 118)
30900 * MODE_CC: Machine Modes. (line 162)
30901 * MODE_COMPLEX_FLOAT: Machine Modes. (line 154)
30902 * MODE_COMPLEX_INT: Machine Modes. (line 151)
30903 * MODE_ENTRY: Mode Switching. (line 54)
30904 * MODE_EXIT: Mode Switching. (line 60)
30905 * MODE_FLOAT: Machine Modes. (line 147)
30906 * MODE_FUNCTION: Machine Modes. (line 158)
30907 * MODE_HAS_INFINITIES: Storage Layout. (line 420)
30908 * MODE_HAS_NANS: Storage Layout. (line 410)
30909 * MODE_HAS_SIGN_DEPENDENT_ROUNDING: Storage Layout. (line 442)
30910 * MODE_HAS_SIGNED_ZEROS: Storage Layout. (line 426)
30911 * MODE_INT: Machine Modes. (line 139)
30912 * MODE_NEEDED: Mode Switching. (line 42)
30913 * MODE_PARTIAL_INT: Machine Modes. (line 143)
30914 * MODE_PRIORITY_TO_MODE: Mode Switching. (line 66)
30915 * MODE_RANDOM: Machine Modes. (line 167)
30916 * MODES_TIEABLE_P: Values in Registers.
30918 * modifiers in constraints: Modifiers. (line 6)
30919 * MODIFY_EXPR: Expression trees. (line 6)
30920 * MODIFY_JNI_METHOD_CALL: Misc. (line 713)
30921 * MODIFY_TARGET_NAME: Driver. (line 385)
30922 * modM3 instruction pattern: Standard Names. (line 193)
30923 * modulo scheduling: RTL passes. (line 136)
30924 * MOVE_BY_PIECES_P: Costs. (line 104)
30925 * MOVE_MAX: Misc. (line 115)
30926 * MOVE_MAX_PIECES: Costs. (line 110)
30927 * MOVE_RATIO: Costs. (line 91)
30928 * movM instruction pattern: Standard Names. (line 11)
30929 * movmemM instruction pattern: Standard Names. (line 470)
30930 * movmisalignM instruction pattern: Standard Names. (line 125)
30931 * movMODEcc instruction pattern: Standard Names. (line 648)
30932 * movstr instruction pattern: Standard Names. (line 498)
30933 * movstrictM instruction pattern: Standard Names. (line 119)
30934 * mulhisi3 instruction pattern: Standard Names. (line 236)
30935 * mulM3 instruction pattern: Standard Names. (line 193)
30936 * mulqihi3 instruction pattern: Standard Names. (line 240)
30937 * mulsidi3 instruction pattern: Standard Names. (line 240)
30938 * mult: Arithmetic. (line 85)
30939 * mult and attributes: Expressions. (line 64)
30940 * mult, canonicalization of: Insn Canonicalizations.
30942 * MULT_EXPR: Expression trees. (line 6)
30943 * MULTILIB_DEFAULTS: Driver. (line 315)
30944 * MULTILIB_DIRNAMES: Target Fragment. (line 64)
30945 * MULTILIB_EXCEPTIONS: Target Fragment. (line 84)
30946 * MULTILIB_EXTRA_OPTS: Target Fragment. (line 96)
30947 * MULTILIB_MATCHES: Target Fragment. (line 77)
30948 * MULTILIB_OPTIONS: Target Fragment. (line 44)
30949 * multiple alternative constraints: Multi-Alternative. (line 6)
30950 * MULTIPLE_SYMBOL_SPACES: Misc. (line 495)
30951 * multiplication: Arithmetic. (line 85)
30952 * MUST_USE_SJLJ_EXCEPTIONS: Exception Region Output.
30954 * n in constraint: Simple Constraints. (line 63)
30955 * N_REG_CLASSES: Register Classes. (line 76)
30956 * name: Identifiers. (line 6)
30957 * named patterns and conditions: Patterns. (line 47)
30958 * names, pattern: Standard Names. (line 6)
30959 * namespace: Namespaces. (line 6)
30960 * namespace, class, scope: Scopes. (line 6)
30961 * NAMESPACE_DECL <1>: Declarations. (line 6)
30962 * NAMESPACE_DECL: Namespaces. (line 6)
30963 * NATIVE_SYSTEM_HEADER_DIR: Target Fragment. (line 103)
30964 * ne: Comparisons. (line 56)
30965 * ne and attributes: Expressions. (line 64)
30966 * NE_EXPR: Expression trees. (line 6)
30967 * nearbyintM2 instruction pattern: Standard Names. (line 386)
30968 * neg: Arithmetic. (line 81)
30969 * neg and attributes: Expressions. (line 64)
30970 * neg, canonicalization of: Insn Canonicalizations.
30972 * NEGATE_EXPR: Expression trees. (line 6)
30973 * negM2 instruction pattern: Standard Names. (line 289)
30974 * nested functions, trampolines for: Trampolines. (line 6)
30975 * nested_ptr: GTY Options. (line 178)
30976 * next_bb, prev_bb, FOR_EACH_BB: Basic Blocks. (line 10)
30977 * next_cc0_user: Jump Patterns. (line 64)
30978 * NEXT_INSN: Insns. (line 30)
30979 * NEXT_OBJC_RUNTIME: Library Calls. (line 85)
30980 * nil: RTL Objects. (line 73)
30981 * NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 39)
30982 * NO_DBX_FUNCTION_END: DBX Hooks. (line 33)
30983 * NO_DBX_GCC_MARKER: File Names and DBX. (line 28)
30984 * NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 23)
30985 * NO_DOLLAR_IN_LABEL: Misc. (line 459)
30986 * NO_DOT_IN_LABEL: Misc. (line 465)
30987 * NO_FUNCTION_CSE: Costs. (line 178)
30988 * NO_IMPLICIT_EXTERN_C: Misc. (line 339)
30989 * no_new_pseudos: Standard Names. (line 77)
30990 * NO_PROFILE_COUNTERS: Profiling. (line 28)
30991 * NO_REGS: Register Classes. (line 17)
30992 * NON_LVALUE_EXPR: Expression trees. (line 6)
30993 * nondeterministic finite state automaton: Processor pipeline description.
30995 * nonimmediate_operand: Machine-Independent Predicates.
30997 * nonlocal goto handler: Edges. (line 171)
30998 * nonlocal_goto instruction pattern: Standard Names. (line 1012)
30999 * nonlocal_goto_receiver instruction pattern: Standard Names.
31001 * nonmemory_operand: Machine-Independent Predicates.
31003 * nonoffsettable memory reference: Simple Constraints. (line 251)
31004 * nop instruction pattern: Standard Names. (line 830)
31005 * NOP_EXPR: Expression trees. (line 6)
31006 * normal predicates: Predicates. (line 31)
31007 * not: Arithmetic. (line 132)
31008 * not and attributes: Expressions. (line 50)
31009 * not equal: Comparisons. (line 56)
31010 * not, canonicalization of: Insn Canonicalizations.
31012 * note: Insns. (line 173)
31013 * note and /i: Flags. (line 49)
31014 * note and /v: Flags. (line 29)
31015 * NOTE_INSN_BASIC_BLOCK, CODE_LABEL, notes: Basic Blocks. (line 41)
31016 * NOTE_INSN_BLOCK_BEG: Insns. (line 198)
31017 * NOTE_INSN_BLOCK_END: Insns. (line 198)
31018 * NOTE_INSN_DELETED: Insns. (line 188)
31019 * NOTE_INSN_DELETED_LABEL: Insns. (line 193)
31020 * NOTE_INSN_EH_REGION_BEG: Insns. (line 204)
31021 * NOTE_INSN_EH_REGION_END: Insns. (line 204)
31022 * NOTE_INSN_FUNCTION_BEG: Insns. (line 228)
31023 * NOTE_INSN_FUNCTION_END: Insns. (line 232)
31024 * NOTE_INSN_LOOP_BEG: Insns. (line 212)
31025 * NOTE_INSN_LOOP_CONT: Insns. (line 218)
31026 * NOTE_INSN_LOOP_END: Insns. (line 212)
31027 * NOTE_INSN_LOOP_VTOP: Insns. (line 222)
31028 * NOTE_LINE_NUMBER: Insns. (line 173)
31029 * NOTE_SOURCE_FILE: Insns. (line 173)
31030 * NOTICE_UPDATE_CC: Condition Code. (line 33)
31031 * NUM_MACHINE_MODES: Machine Modes. (line 180)
31032 * NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30)
31033 * o in constraint: Simple Constraints. (line 21)
31034 * OBJC_GEN_METHOD_LABEL: Label Output. (line 402)
31035 * OBJECT_FORMAT_COFF: Macros for Initialization.
31037 * OFFSET_TYPE: Types. (line 6)
31038 * offsettable address: Simple Constraints. (line 21)
31039 * OImode: Machine Modes. (line 51)
31040 * one_cmplM2 instruction pattern: Standard Names. (line 449)
31041 * operand access: Accessors. (line 6)
31042 * Operand Access Routines: Statement Operands. (line 119)
31043 * operand constraints: Constraints. (line 6)
31044 * Operand Iterators: Statement Operands. (line 119)
31045 * operand predicates: Predicates. (line 6)
31046 * operand substitution: Output Template. (line 6)
31047 * operands <1>: Patterns. (line 53)
31048 * operands: Statement Operands. (line 6)
31049 * operator predicates: Predicates. (line 6)
31050 * Optimization infrastructure for GIMPLE: Tree SSA. (line 6)
31051 * OPTIMIZATION_OPTIONS: Run-time Target. (line 100)
31052 * OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 9)
31053 * option specification files: Options. (line 6)
31054 * OPTION_DEFAULT_SPECS: Driver. (line 88)
31055 * optional hardware or system features: Run-time Target. (line 59)
31056 * options, directory search: Including Patterns. (line 44)
31057 * opts.sh: Options. (line 6)
31058 * order of register allocation: Allocation Order. (line 6)
31059 * ORDER_REGS_FOR_LOCAL_ALLOC: Allocation Order. (line 23)
31060 * ORDERED_EXPR: Expression trees. (line 6)
31061 * Ordering of Patterns: Pattern Ordering. (line 6)
31062 * ORIGINAL_REGNO: Special Accessors. (line 40)
31063 * other register constraints: Simple Constraints. (line 161)
31064 * OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 70)
31065 * OUTGOING_REGNO: Register Basics. (line 98)
31066 * output of assembler code: File Framework. (line 6)
31067 * output statements: Output Statement. (line 6)
31068 * output templates: Output Template. (line 6)
31069 * OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 39)
31070 * output_asm_insn: Output Statement. (line 53)
31071 * OUTPUT_QUOTED_STRING: File Framework. (line 76)
31072 * OVERLOAD: Functions. (line 6)
31073 * OVERRIDE_OPTIONS: Run-time Target. (line 90)
31074 * OVL_CURRENT: Functions. (line 6)
31075 * OVL_NEXT: Functions. (line 6)
31076 * p in constraint: Simple Constraints. (line 152)
31077 * PAD_VARARGS_DOWN: Register Arguments. (line 206)
31078 * parallel: Side Effects. (line 201)
31079 * param_is: GTY Options. (line 114)
31080 * parameters, c++ abi: C++ ABI. (line 6)
31081 * parameters, miscellaneous: Misc. (line 6)
31082 * parameters, precompiled headers: PCH Target. (line 6)
31083 * paramN_is: GTY Options. (line 132)
31084 * parity: Arithmetic. (line 202)
31085 * parityM2 instruction pattern: Standard Names. (line 443)
31086 * PARM_BOUNDARY: Storage Layout. (line 143)
31087 * PARM_DECL: Declarations. (line 6)
31088 * PARSE_LDD_OUTPUT: Macros for Initialization.
31090 * passes and files of the compiler: Passes. (line 6)
31091 * passing arguments: Interface. (line 36)
31092 * PATH_SEPARATOR: Filesystem. (line 31)
31093 * PATTERN: Insns. (line 258)
31094 * pattern conditions: Patterns. (line 43)
31095 * pattern names: Standard Names. (line 6)
31096 * Pattern Ordering: Pattern Ordering. (line 6)
31097 * patterns: Patterns. (line 6)
31098 * pc: Regs and Memory. (line 236)
31099 * pc and attributes: Insn Lengths. (line 20)
31100 * pc, RTL sharing: Sharing. (line 25)
31101 * PC_REGNUM: Register Basics. (line 112)
31102 * pc_rtx: Regs and Memory. (line 241)
31103 * PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 255)
31104 * PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 61)
31105 * PDImode: Machine Modes. (line 40)
31106 * peephole optimization, RTL representation: Side Effects. (line 235)
31107 * peephole optimizer definitions: Peephole Definitions.
31109 * per-function data: Per-Function Data. (line 6)
31110 * percent sign: Output Template. (line 6)
31111 * PHI_ARG_DEF: SSA. (line 71)
31112 * PHI_ARG_EDGE: SSA. (line 68)
31113 * PHI_ARG_ELT: SSA. (line 63)
31114 * PHI_NUM_ARGS: SSA. (line 59)
31115 * PHI_RESULT: SSA. (line 56)
31116 * PIC: PIC. (line 6)
31117 * PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 26)
31118 * PIC_OFFSET_TABLE_REGNUM: PIC. (line 16)
31119 * pipeline hazard recognizer: Processor pipeline description.
31121 * plus: Arithmetic. (line 14)
31122 * plus and attributes: Expressions. (line 64)
31123 * plus, canonicalization of: Insn Canonicalizations.
31125 * PLUS_EXPR: Expression trees. (line 6)
31126 * Pmode: Misc. (line 311)
31127 * pmode_register_operand: Machine-Independent Predicates.
31129 * pointer: Types. (line 6)
31130 * POINTER_SIZE: Storage Layout. (line 83)
31131 * POINTER_TYPE: Types. (line 6)
31132 * POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 89)
31133 * pop_operand: Machine-Independent Predicates.
31135 * popcount: Arithmetic. (line 198)
31136 * popcountM2 instruction pattern: Standard Names. (line 437)
31137 * portability: Portability. (line 6)
31138 * position independent code: PIC. (line 6)
31139 * post_dec: Incdec. (line 25)
31140 * post_inc: Incdec. (line 30)
31141 * post_modify: Incdec. (line 33)
31142 * POSTDECREMENT_EXPR: Expression trees. (line 6)
31143 * POSTINCREMENT_EXPR: Expression trees. (line 6)
31144 * POWI_MAX_MULTS: Misc. (line 761)
31145 * powM3 instruction pattern: Standard Names. (line 335)
31146 * pragma: Misc. (line 344)
31147 * pre_dec: Incdec. (line 8)
31148 * PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 110)
31149 * pre_inc: Incdec. (line 22)
31150 * pre_modify: Incdec. (line 51)
31151 * PREDECREMENT_EXPR: Expression trees. (line 6)
31152 * predefined macros: Run-time Target. (line 6)
31153 * predicates: Predicates. (line 6)
31154 * predicates and machine modes: Predicates. (line 31)
31155 * predication: Conditional Execution.
31157 * predict.def: Profile information.
31159 * PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 42)
31160 * PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 224)
31161 * PREFERRED_RELOAD_CLASS: Register Classes. (line 197)
31162 * PREFERRED_STACK_BOUNDARY: Storage Layout. (line 157)
31163 * prefetch: Side Effects. (line 309)
31164 * prefetch instruction pattern: Standard Names. (line 1149)
31165 * PREINCREMENT_EXPR: Expression trees. (line 6)
31166 * presence_set: Processor pipeline description.
31168 * preserving SSA form: SSA. (line 76)
31169 * prev_active_insn: define_peephole. (line 60)
31170 * prev_cc0_setter: Jump Patterns. (line 64)
31171 * PREV_INSN: Insns. (line 26)
31172 * PRINT_OPERAND: Instruction Output. (line 68)
31173 * PRINT_OPERAND_ADDRESS: Instruction Output. (line 96)
31174 * PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 89)
31175 * processor functional units: Processor pipeline description.
31177 * processor pipeline description: Processor pipeline description.
31179 * product: Arithmetic. (line 85)
31180 * profile feedback: Profile information.
31182 * profile representation: Profile information.
31184 * PROFILE_BEFORE_PROLOGUE: Profiling. (line 35)
31185 * PROFILE_HOOK: Profiling. (line 23)
31186 * profiling, code generation: Profiling. (line 6)
31187 * program counter: Regs and Memory. (line 237)
31188 * prologue: Function Entry. (line 6)
31189 * prologue instruction pattern: Standard Names. (line 1095)
31190 * PROMOTE_FUNCTION_MODE: Storage Layout. (line 122)
31191 * PROMOTE_MODE: Storage Layout. (line 99)
31192 * pseudo registers: Regs and Memory. (line 9)
31193 * PSImode: Machine Modes. (line 32)
31194 * PTRDIFF_TYPE: Type Layout. (line 132)
31195 * PTRMEM_CST: Expression trees. (line 6)
31196 * PTRMEM_CST_CLASS: Expression trees. (line 6)
31197 * PTRMEM_CST_MEMBER: Expression trees. (line 6)
31198 * purge_dead_edges <1>: Maintaining the CFG.
31200 * purge_dead_edges: Edges. (line 104)
31201 * push address instruction: Simple Constraints. (line 152)
31202 * PUSH_ARGS: Stack Arguments. (line 18)
31203 * PUSH_ARGS_REVERSED: Stack Arguments. (line 26)
31204 * push_operand: Machine-Independent Predicates.
31206 * push_reload: Addressing Modes. (line 196)
31207 * PUSH_ROUNDING: Stack Arguments. (line 32)
31208 * pushM1 instruction pattern: Standard Names. (line 180)
31209 * PUT_CODE: RTL Objects. (line 47)
31210 * PUT_MODE: Machine Modes. (line 177)
31211 * PUT_REG_NOTE_KIND: Insns. (line 324)
31212 * PUT_SDB_: SDB and DWARF. (line 62)
31213 * QCmode: Machine Modes. (line 111)
31214 * QFmode: Machine Modes. (line 54)
31215 * QImode: Machine Modes. (line 25)
31216 * QImode, in insn: Insns. (line 242)
31217 * qualified type: Types. (line 6)
31218 * querying function unit reservations: Processor pipeline description.
31220 * question mark: Multi-Alternative. (line 41)
31221 * quotient: Arithmetic. (line 100)
31222 * r in constraint: Simple Constraints. (line 54)
31223 * RANGE_TEST_NON_SHORT_CIRCUIT: Costs. (line 182)
31224 * RDIV_EXPR: Expression trees. (line 6)
31225 * READONLY_DATA_SECTION: Sections. (line 43)
31226 * READONLY_DATA_SECTION_ASM_OP: Sections. (line 38)
31227 * real operands: Statement Operands. (line 6)
31228 * REAL_ARITHMETIC: Floating Point. (line 66)
31229 * REAL_CST: Expression trees. (line 6)
31230 * REAL_LIBGCC_SPEC: Driver. (line 187)
31231 * REAL_NM_FILE_NAME: Macros for Initialization.
31233 * REAL_TYPE: Types. (line 6)
31234 * REAL_VALUE_ABS: Floating Point. (line 82)
31235 * REAL_VALUE_ATOF: Floating Point. (line 50)
31236 * REAL_VALUE_FIX: Floating Point. (line 41)
31237 * REAL_VALUE_FROM_INT: Floating Point. (line 99)
31238 * REAL_VALUE_ISINF: Floating Point. (line 59)
31239 * REAL_VALUE_ISNAN: Floating Point. (line 62)
31240 * REAL_VALUE_NEGATE: Floating Point. (line 79)
31241 * REAL_VALUE_NEGATIVE: Floating Point. (line 56)
31242 * REAL_VALUE_TO_INT: Floating Point. (line 93)
31243 * REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 138)
31244 * REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 139)
31245 * REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 137)
31246 * REAL_VALUE_TRUNCATE: Floating Point. (line 86)
31247 * REAL_VALUE_TYPE: Floating Point. (line 26)
31248 * REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 45)
31249 * REAL_VALUES_EQUAL: Floating Point. (line 32)
31250 * REAL_VALUES_LESS: Floating Point. (line 38)
31251 * REALPART_EXPR: Expression trees. (line 6)
31252 * recog_data.operand: Instruction Output. (line 39)
31253 * recognizing insns: RTL Template. (line 6)
31254 * RECORD_TYPE <1>: Classes. (line 6)
31255 * RECORD_TYPE: Types. (line 6)
31256 * redirect_edge_and_branch: Profile information.
31258 * redirect_edge_and_branch, redirect_jump: Maintaining the CFG.
31260 * reduc_smax_M instruction pattern: Standard Names. (line 206)
31261 * reduc_smin_M instruction pattern: Standard Names. (line 206)
31262 * reduc_splus_M instruction pattern: Standard Names. (line 218)
31263 * reduc_umax_M instruction pattern: Standard Names. (line 212)
31264 * reduc_umin_M instruction pattern: Standard Names. (line 212)
31265 * reduc_uplus_M instruction pattern: Standard Names. (line 224)
31266 * reference: Types. (line 6)
31267 * REFERENCE_TYPE: Types. (line 6)
31268 * reg: Regs and Memory. (line 9)
31269 * reg and /f: Flags. (line 98)
31270 * reg and /i: Flags. (line 93)
31271 * reg and /v: Flags. (line 102)
31272 * reg, RTL sharing: Sharing. (line 17)
31273 * REG_ALLOC_ORDER: Allocation Order. (line 9)
31274 * REG_BR_PRED: Insns. (line 531)
31275 * REG_BR_PROB: Insns. (line 525)
31276 * REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information.
31278 * REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information.
31280 * REG_CC_SETTER: Insns. (line 500)
31281 * REG_CC_USER: Insns. (line 500)
31282 * REG_CLASS_CONTENTS: Register Classes. (line 86)
31283 * reg_class_contents: Register Basics. (line 59)
31284 * REG_CLASS_FROM_CONSTRAINT: Register Classes. (line 154)
31285 * REG_CLASS_FROM_LETTER: Register Classes. (line 146)
31286 * REG_CLASS_NAMES: Register Classes. (line 81)
31287 * REG_CROSSING_JUMP: Insns. (line 389)
31288 * REG_DEAD: Insns. (line 335)
31289 * REG_DEAD, REG_UNUSED: Liveness information.
31291 * REG_DEP_ANTI: Insns. (line 515)
31292 * REG_DEP_OUTPUT: Insns. (line 518)
31293 * REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 110)
31294 * REG_EQUAL: Insns. (line 405)
31295 * REG_EQUIV: Insns. (line 405)
31296 * REG_EXPR: Special Accessors. (line 46)
31297 * REG_FRAME_RELATED_EXPR: Insns. (line 537)
31298 * REG_FUNCTION_VALUE_P: Flags. (line 93)
31299 * REG_INC: Insns. (line 351)
31300 * REG_LABEL: Insns. (line 381)
31301 * reg_label and /v: Flags. (line 55)
31302 * REG_LIBCALL: Insns. (line 493)
31303 * REG_MODE_OK_FOR_BASE_P: Addressing Modes. (line 109)
31304 * REG_MODE_OK_FOR_REG_BASE_P: Addressing Modes. (line 117)
31305 * reg_names <1>: Instruction Output. (line 80)
31306 * reg_names: Register Basics. (line 59)
31307 * REG_NO_CONFLICT: Insns. (line 365)
31308 * REG_NONNEG: Insns. (line 357)
31309 * REG_NOTE_KIND: Insns. (line 324)
31310 * REG_NOTES: Insns. (line 292)
31311 * REG_OFFSET: Special Accessors. (line 50)
31312 * REG_OK_FOR_BASE_P: Addressing Modes. (line 100)
31313 * REG_OK_FOR_INDEX_P: Addressing Modes. (line 126)
31314 * REG_OK_STRICT: Addressing Modes. (line 67)
31315 * REG_PARM_STACK_SPACE: Stack Arguments. (line 56)
31316 * REG_PARM_STACK_SPACE, and FUNCTION_ARG: Register Arguments.
31318 * REG_POINTER: Flags. (line 98)
31319 * REG_RETVAL: Insns. (line 477)
31320 * REG_SETJMP: Insns. (line 399)
31321 * REG_UNUSED: Insns. (line 344)
31322 * REG_USERVAR_P: Flags. (line 102)
31323 * register allocation order: Allocation Order. (line 6)
31324 * register class definitions: Register Classes. (line 6)
31325 * register class preference constraints: Class Preferences. (line 6)
31326 * register pairs: Values in Registers.
31328 * Register Transfer Language (RTL): RTL. (line 6)
31329 * register usage: Registers. (line 6)
31330 * REGISTER_MOVE_COST: Costs. (line 10)
31331 * REGISTER_NAMES: Instruction Output. (line 9)
31332 * register_operand: Machine-Independent Predicates.
31334 * REGISTER_PREFIX: Instruction Output. (line 124)
31335 * REGISTER_TARGET_PRAGMAS: Misc. (line 345)
31336 * registers arguments: Register Arguments. (line 6)
31337 * registers in constraints: Simple Constraints. (line 54)
31338 * REGMODE_NATURAL_SIZE: Values in Registers.
31340 * REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 165)
31341 * REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 173)
31342 * REGNO_OK_FOR_BASE_P: Register Classes. (line 159)
31343 * REGNO_OK_FOR_INDEX_P: Register Classes. (line 182)
31344 * REGNO_REG_CLASS: Register Classes. (line 101)
31345 * regs_ever_live: Function Entry. (line 21)
31346 * regular expressions: Processor pipeline description.
31348 * relative costs: Costs. (line 6)
31349 * RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 325)
31350 * reload pass: Regs and Memory. (line 148)
31351 * reload_completed: Standard Names. (line 797)
31352 * reload_in instruction pattern: Standard Names. (line 101)
31353 * reload_in_progress: Standard Names. (line 57)
31354 * reload_out instruction pattern: Standard Names. (line 101)
31355 * reloading: RTL passes. (line 177)
31356 * remainder: Arithmetic. (line 114)
31357 * reorder: GTY Options. (line 199)
31358 * representation of RTL: RTL. (line 6)
31359 * reservation delays: Processor pipeline description.
31361 * rest_of_decl_compilation: Parsing pass. (line 52)
31362 * rest_of_type_compilation: Parsing pass. (line 52)
31363 * restore_stack_block instruction pattern: Standard Names. (line 931)
31364 * restore_stack_function instruction pattern: Standard Names.
31366 * restore_stack_nonlocal instruction pattern: Standard Names.
31368 * RESULT_DECL: Declarations. (line 6)
31369 * return: Side Effects. (line 72)
31370 * return instruction pattern: Standard Names. (line 784)
31371 * return values in registers: Scalar Return. (line 6)
31372 * RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 127)
31373 * RETURN_ADDR_OFFSET: Exception Handling. (line 60)
31374 * RETURN_ADDR_RTX: Frame Layout. (line 116)
31375 * RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 51)
31376 * RETURN_EXPR: Function Bodies. (line 6)
31377 * RETURN_INIT: Function Bodies. (line 6)
31378 * RETURN_POPS_ARGS: Stack Arguments. (line 87)
31379 * RETURN_STMT: Function Bodies. (line 6)
31380 * returning aggregate values: Aggregate Return. (line 6)
31381 * returning structures and unions: Interface. (line 10)
31382 * reverse probability: Profile information.
31384 * REVERSE_CONDEXEC_PREDICATES_P: Condition Code. (line 129)
31385 * REVERSE_CONDITION: Condition Code. (line 116)
31386 * REVERSIBLE_CC_MODE: Condition Code. (line 102)
31387 * right rotate: Arithmetic. (line 164)
31388 * right shift: Arithmetic. (line 159)
31389 * rintM2 instruction pattern: Standard Names. (line 394)
31390 * RISC: Processor pipeline description.
31392 * roots, marking: GGC Roots. (line 6)
31393 * rotate: Arithmetic. (line 164)
31394 * rotatert: Arithmetic. (line 164)
31395 * rotlM3 instruction pattern: Standard Names. (line 285)
31396 * rotrM3 instruction pattern: Standard Names. (line 285)
31397 * Rough GIMPLE Grammar: Rough GIMPLE Grammar.
31399 * ROUND_DIV_EXPR: Expression trees. (line 6)
31400 * ROUND_MOD_EXPR: Expression trees. (line 6)
31401 * ROUND_TOWARDS_ZERO: Storage Layout. (line 451)
31402 * ROUND_TYPE_ALIGN: Storage Layout. (line 346)
31403 * roundM2 instruction pattern: Standard Names. (line 370)
31404 * RSHIFT_EXPR: Expression trees. (line 6)
31405 * RTL addition: Arithmetic. (line 14)
31406 * RTL addition with signed saturation: Arithmetic. (line 14)
31407 * RTL addition with unsigned saturation: Arithmetic. (line 14)
31408 * RTL classes: RTL Classes. (line 6)
31409 * RTL comparison: Arithmetic. (line 43)
31410 * RTL comparison operations: Comparisons. (line 6)
31411 * RTL constant expression types: Constants. (line 6)
31412 * RTL constants: Constants. (line 6)
31413 * RTL declarations: RTL Declarations. (line 6)
31414 * RTL difference: Arithmetic. (line 36)
31415 * RTL expression: RTL Objects. (line 6)
31416 * RTL expressions for arithmetic: Arithmetic. (line 6)
31417 * RTL format: RTL Classes. (line 71)
31418 * RTL format characters: RTL Classes. (line 76)
31419 * RTL function-call insns: Calls. (line 6)
31420 * RTL insn template: RTL Template. (line 6)
31421 * RTL integers: RTL Objects. (line 6)
31422 * RTL memory expressions: Regs and Memory. (line 6)
31423 * RTL object types: RTL Objects. (line 6)
31424 * RTL postdecrement: Incdec. (line 6)
31425 * RTL postincrement: Incdec. (line 6)
31426 * RTL predecrement: Incdec. (line 6)
31427 * RTL preincrement: Incdec. (line 6)
31428 * RTL register expressions: Regs and Memory. (line 6)
31429 * RTL representation: RTL. (line 6)
31430 * RTL side effect expressions: Side Effects. (line 6)
31431 * RTL strings: RTL Objects. (line 6)
31432 * RTL structure sharing assumptions: Sharing. (line 6)
31433 * RTL subtraction: Arithmetic. (line 36)
31434 * RTL subtraction with signed saturation: Arithmetic. (line 36)
31435 * RTL subtraction with unsigned saturation: Arithmetic. (line 36)
31436 * RTL sum: Arithmetic. (line 14)
31437 * RTL vectors: RTL Objects. (line 6)
31438 * RTX (See RTL): RTL Objects. (line 6)
31439 * RTX codes, classes of: RTL Classes. (line 6)
31440 * RTX_FRAME_RELATED_P: Flags. (line 111)
31441 * run-time conventions: Interface. (line 6)
31442 * run-time target specification: Run-time Target. (line 6)
31443 * s in constraint: Simple Constraints. (line 90)
31444 * same_type_p: Types. (line 102)
31445 * SAVE_EXPR: Expression trees. (line 6)
31446 * save_stack_block instruction pattern: Standard Names. (line 931)
31447 * save_stack_function instruction pattern: Standard Names. (line 931)
31448 * save_stack_nonlocal instruction pattern: Standard Names. (line 931)
31449 * scalars, returned as values: Scalar Return. (line 6)
31450 * SCHED_GROUP_P: Flags. (line 156)
31451 * SCmode: Machine Modes. (line 111)
31452 * sCOND instruction pattern: Standard Names. (line 668)
31453 * scratch: Regs and Memory. (line 173)
31454 * scratch operands: Regs and Memory. (line 173)
31455 * scratch, RTL sharing: Sharing. (line 35)
31456 * scratch_operand: Machine-Independent Predicates.
31458 * SDB_ALLOW_FORWARD_REFERENCES: SDB and DWARF. (line 80)
31459 * SDB_ALLOW_UNKNOWN_REFERENCES: SDB and DWARF. (line 75)
31460 * SDB_DEBUGGING_INFO: SDB and DWARF. (line 9)
31461 * SDB_DELIM: SDB and DWARF. (line 68)
31462 * SDB_OUTPUT_SOURCE_LINE: SDB and DWARF. (line 85)
31463 * search options: Including Patterns. (line 44)
31464 * SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 246)
31465 * SECONDARY_MEMORY_NEEDED: Register Classes. (line 308)
31466 * SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 327)
31467 * SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 318)
31468 * SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 247)
31469 * SECONDARY_RELOAD_CLASS: Register Classes. (line 245)
31470 * SELECT_CC_MODE: Condition Code. (line 68)
31471 * Selection Statements: Selection Statements.
31473 * sequence: Side Effects. (line 251)
31474 * set: Side Effects. (line 15)
31475 * set and /f: Flags. (line 111)
31476 * SET_ASM_OP: Label Output. (line 369)
31477 * set_attr: Tagging Insns. (line 31)
31478 * set_attr_alternative: Tagging Insns. (line 49)
31479 * SET_DEST: Side Effects. (line 69)
31480 * SET_IS_RETURN_P: Flags. (line 165)
31481 * SET_LABEL_KIND: Insns. (line 145)
31482 * set_optab_libfunc: Library Calls. (line 15)
31483 * SET_SRC: Side Effects. (line 69)
31484 * setmemM instruction pattern: Standard Names. (line 506)
31485 * SETUP_FRAME_ADDRESSES: Frame Layout. (line 102)
31486 * SFmode: Machine Modes. (line 66)
31487 * sharing of RTL components: Sharing. (line 6)
31488 * shift: Arithmetic. (line 151)
31489 * SHIFT_COUNT_TRUNCATED: Misc. (line 127)
31490 * SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 96)
31491 * SHORT_TYPE_SIZE: Type Layout. (line 16)
31492 * sibcall_epilogue instruction pattern: Standard Names. (line 1121)
31493 * sibling call: Edges. (line 122)
31494 * SIBLING_CALL_P: Flags. (line 169)
31495 * sign_extend: Conversions. (line 23)
31496 * sign_extract: Bit-Fields. (line 8)
31497 * sign_extract, canonicalization of: Insn Canonicalizations.
31499 * signed division: Arithmetic. (line 100)
31500 * signed maximum: Arithmetic. (line 119)
31501 * signed minimum: Arithmetic. (line 119)
31502 * SImode: Machine Modes. (line 37)
31503 * simple constraints: Simple Constraints. (line 6)
31504 * sinM2 instruction pattern: Standard Names. (line 311)
31505 * SIZE_ASM_OP: Label Output. (line 23)
31506 * SIZE_TYPE: Type Layout. (line 116)
31507 * skip: GTY Options. (line 77)
31508 * SLOW_BYTE_ACCESS: Costs. (line 60)
31509 * SLOW_UNALIGNED_ACCESS: Costs. (line 75)
31510 * SMALL_ARG_MAX: Host Misc. (line 41)
31511 * SMALL_REGISTER_CLASSES: Register Classes. (line 350)
31512 * smax: Arithmetic. (line 119)
31513 * smin: Arithmetic. (line 119)
31514 * sms, swing, software pipelining: RTL passes. (line 136)
31515 * smulM3_highpart instruction pattern: Standard Names. (line 247)
31516 * soft float library: Soft float library routines.
31518 * special: GTY Options. (line 219)
31519 * special predicates: Predicates. (line 31)
31520 * SPECS: Target Fragment. (line 108)
31521 * speed of instructions: Costs. (line 6)
31522 * split_block: Maintaining the CFG.
31524 * splitting instructions: Insn Splitting. (line 6)
31525 * sqrt: Arithmetic. (line 172)
31526 * sqrtM2 instruction pattern: Standard Names. (line 295)
31527 * square root: Arithmetic. (line 172)
31528 * ss_minus: Arithmetic. (line 36)
31529 * ss_plus: Arithmetic. (line 14)
31530 * ss_truncate: Conversions. (line 43)
31531 * SSA: SSA. (line 6)
31532 * SSA_NAME_DEF_STMT: SSA. (line 192)
31533 * SSA_NAME_VERSION: SSA. (line 197)
31534 * stack arguments: Stack Arguments. (line 6)
31535 * stack frame layout: Frame Layout. (line 6)
31536 * stack smashing protection: Stack Smashing Protection.
31538 * STACK_ALIGNMENT_NEEDED: Frame Layout. (line 48)
31539 * STACK_BOUNDARY: Storage Layout. (line 149)
31540 * STACK_CHECK_BUILTIN: Stack Checking. (line 29)
31541 * STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 64)
31542 * STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 55)
31543 * STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 71)
31544 * STACK_CHECK_PROBE_INTERVAL: Stack Checking. (line 37)
31545 * STACK_CHECK_PROBE_LOAD: Stack Checking. (line 44)
31546 * STACK_CHECK_PROTECT: Stack Checking. (line 50)
31547 * STACK_DYNAMIC_OFFSET: Frame Layout. (line 75)
31548 * STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory.
31550 * STACK_GROWS_DOWNWARD: Frame Layout. (line 9)
31551 * STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 78)
31552 * STACK_POINTER_OFFSET: Frame Layout. (line 58)
31553 * STACK_POINTER_OFFSET and virtual registers: Regs and Memory.
31555 * STACK_POINTER_REGNUM: Frame Registers. (line 9)
31556 * STACK_POINTER_REGNUM and virtual registers: Regs and Memory.
31558 * stack_pointer_rtx: Frame Registers. (line 85)
31559 * stack_protect_set instruction pattern: Standard Names. (line 1288)
31560 * stack_protect_test instruction pattern: Standard Names. (line 1298)
31561 * STACK_PUSH_CODE: Frame Layout. (line 17)
31562 * STACK_REGS: Stack Registers. (line 20)
31563 * STACK_SAVEAREA_MODE: Storage Layout. (line 362)
31564 * STACK_SIZE_MODE: Storage Layout. (line 374)
31565 * standard pattern names: Standard Names. (line 6)
31566 * STANDARD_INCLUDE_COMPONENT: Driver. (line 425)
31567 * STANDARD_INCLUDE_DIR: Driver. (line 417)
31568 * STANDARD_STARTFILE_PREFIX: Driver. (line 337)
31569 * STANDARD_STARTFILE_PREFIX_1: Driver. (line 344)
31570 * STANDARD_STARTFILE_PREFIX_2: Driver. (line 351)
31571 * STARTFILE_SPEC: Driver. (line 210)
31572 * STARTING_FRAME_OFFSET: Frame Layout. (line 39)
31573 * STARTING_FRAME_OFFSET and virtual registers: Regs and Memory.
31575 * Statement Sequences: Statement Sequences.
31577 * Statements: Statements. (line 6)
31578 * statements: Function Bodies. (line 6)
31579 * Static profile estimation: Profile information.
31581 * static single assignment: SSA. (line 6)
31582 * STATIC_CHAIN: Frame Registers. (line 77)
31583 * STATIC_CHAIN_INCOMING: Frame Registers. (line 78)
31584 * STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 64)
31585 * STATIC_CHAIN_REGNUM: Frame Registers. (line 63)
31586 * stdarg.h and register arguments: Register Arguments. (line 47)
31587 * STDC_0_IN_SYSTEM_HEADERS: Misc. (line 328)
31588 * STMT_EXPR: Expression trees. (line 6)
31589 * STMT_IS_FULL_EXPR_P: Function Bodies. (line 22)
31590 * storage layout: Storage Layout. (line 6)
31591 * STORE_BY_PIECES_P: Costs. (line 130)
31592 * STORE_FLAG_VALUE: Misc. (line 190)
31593 * store_multiple instruction pattern: Standard Names. (line 159)
31594 * strcpy: Storage Layout. (line 206)
31595 * STRICT_ALIGNMENT: Storage Layout. (line 250)
31596 * strict_low_part: RTL Declarations. (line 9)
31597 * strict_memory_address_p: Addressing Modes. (line 206)
31598 * STRING_CST: Expression trees. (line 6)
31599 * STRING_POOL_ADDRESS_P: Flags. (line 173)
31600 * strlenM instruction pattern: Standard Names. (line 562)
31601 * structure value address: Aggregate Return. (line 6)
31602 * STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 242)
31603 * structures, returning: Interface. (line 10)
31604 * subM3 instruction pattern: Standard Names. (line 193)
31605 * SUBOBJECT: Function Bodies. (line 6)
31606 * SUBOBJECT_CLEANUP: Function Bodies. (line 6)
31607 * subreg: Regs and Memory. (line 97)
31608 * subreg and /s: Flags. (line 195)
31609 * subreg and /u: Flags. (line 188)
31610 * subreg and /u and /v: Flags. (line 178)
31611 * subreg, in strict_low_part: RTL Declarations. (line 9)
31612 * subreg, special reload handling: Regs and Memory. (line 148)
31613 * SUBREG_BYTE: Regs and Memory. (line 169)
31614 * SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 178)
31615 * SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 188)
31616 * SUBREG_PROMOTED_VAR_P: Flags. (line 195)
31617 * SUBREG_REG: Regs and Memory. (line 169)
31618 * SUCCESS_EXIT_CODE: Host Misc. (line 12)
31619 * SUPPORTS_INIT_PRIORITY: Macros for Initialization.
31621 * SUPPORTS_ONE_ONLY: Label Output. (line 218)
31622 * SUPPORTS_WEAK: Label Output. (line 199)
31623 * SWITCH_BODY: Function Bodies. (line 6)
31624 * SWITCH_COND: Function Bodies. (line 6)
31625 * SWITCH_CURTAILS_COMPILATION: Driver. (line 33)
31626 * SWITCH_STMT: Function Bodies. (line 6)
31627 * SWITCH_TAKES_ARG: Driver. (line 9)
31628 * SWITCHES_NEED_SPACES: Driver. (line 47)
31629 * SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 80)
31630 * SYMBOL_FLAG_FUNCTION: Special Accessors. (line 73)
31631 * SYMBOL_FLAG_LOCAL: Special Accessors. (line 76)
31632 * SYMBOL_FLAG_SMALL: Special Accessors. (line 85)
31633 * SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 89)
31634 * symbol_ref: Constants. (line 87)
31635 * symbol_ref and /f: Flags. (line 173)
31636 * symbol_ref and /i: Flags. (line 210)
31637 * symbol_ref and /u: Flags. (line 10)
31638 * symbol_ref and /v: Flags. (line 214)
31639 * symbol_ref, RTL sharing: Sharing. (line 20)
31640 * SYMBOL_REF_DECL: Special Accessors. (line 55)
31641 * SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 80)
31642 * SYMBOL_REF_FLAG: Flags. (line 214)
31643 * SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 207)
31644 * SYMBOL_REF_FLAGS: Special Accessors. (line 67)
31645 * SYMBOL_REF_FUNCTION_P: Special Accessors. (line 73)
31646 * SYMBOL_REF_LOCAL_P: Special Accessors. (line 76)
31647 * SYMBOL_REF_SMALL_P: Special Accessors. (line 85)
31648 * SYMBOL_REF_TLS_MODEL: Special Accessors. (line 89)
31649 * SYMBOL_REF_USED: Flags. (line 205)
31650 * SYMBOL_REF_WEAK: Flags. (line 210)
31651 * symbolic label: Sharing. (line 20)
31652 * sync_addMODE instruction pattern: Standard Names. (line 1202)
31653 * sync_andMODE instruction pattern: Standard Names. (line 1202)
31654 * sync_compare_and_swap_ccMODE instruction pattern: Standard Names.
31656 * sync_compare_and_swapMODE instruction pattern: Standard Names.
31658 * sync_iorMODE instruction pattern: Standard Names. (line 1202)
31659 * sync_lock_releaseMODE instruction pattern: Standard Names. (line 1269)
31660 * sync_lock_test_and_setMODE instruction pattern: Standard Names.
31662 * sync_nandMODE instruction pattern: Standard Names. (line 1202)
31663 * sync_new_addMODE instruction pattern: Standard Names. (line 1236)
31664 * sync_new_andMODE instruction pattern: Standard Names. (line 1236)
31665 * sync_new_iorMODE instruction pattern: Standard Names. (line 1236)
31666 * sync_new_nandMODE instruction pattern: Standard Names. (line 1236)
31667 * sync_new_subMODE instruction pattern: Standard Names. (line 1236)
31668 * sync_new_xorMODE instruction pattern: Standard Names. (line 1236)
31669 * sync_old_addMODE instruction pattern: Standard Names. (line 1219)
31670 * sync_old_andMODE instruction pattern: Standard Names. (line 1219)
31671 * sync_old_iorMODE instruction pattern: Standard Names. (line 1219)
31672 * sync_old_nandMODE instruction pattern: Standard Names. (line 1219)
31673 * sync_old_subMODE instruction pattern: Standard Names. (line 1219)
31674 * sync_old_xorMODE instruction pattern: Standard Names. (line 1219)
31675 * sync_subMODE instruction pattern: Standard Names. (line 1202)
31676 * sync_xorMODE instruction pattern: Standard Names. (line 1202)
31677 * SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 239)
31678 * SYSROOT_SUFFIX_SPEC: Driver. (line 234)
31679 * SYSTEM_INCLUDE_DIR: Driver. (line 408)
31680 * t-TARGET: Target Fragment. (line 6)
31681 * table jump: Basic Blocks. (line 57)
31682 * tablejump instruction pattern: Standard Names. (line 859)
31683 * tag: GTY Options. (line 82)
31684 * tagging insns: Tagging Insns. (line 6)
31685 * tail calls: Tail Calls. (line 6)
31686 * target attributes: Target Attributes. (line 6)
31687 * target description macros: Target Macros. (line 6)
31688 * target functions: Target Structure. (line 6)
31689 * target hooks: Target Structure. (line 6)
31690 * target makefile fragment: Target Fragment. (line 6)
31691 * target specifications: Run-time Target. (line 6)
31692 * TARGET_ADDRESS_COST: Costs. (line 214)
31693 * TARGET_ALIGN_ANON_BITFIELDS: Storage Layout. (line 327)
31694 * TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 677)
31695 * TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 83)
31696 * TARGET_ARM_EABI_UNWINDER: Exception Region Output.
31698 * TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 10)
31699 * TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 8)
31700 * TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 9)
31701 * TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 11)
31702 * TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 230)
31703 * TARGET_ASM_BYTE_OP: Data Output. (line 7)
31704 * TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 237)
31705 * TARGET_ASM_CLOSE_PAREN: Data Output. (line 128)
31706 * TARGET_ASM_CONSTRUCTOR: Macros for Initialization.
31708 * TARGET_ASM_DESTRUCTOR: Macros for Initialization.
31710 * TARGET_ASM_EH_FRAME_SECTION: Exception Region Output.
31712 * TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 63)
31713 * TARGET_ASM_EXCEPTION_SECTION: Exception Region Output.
31715 * TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 265)
31716 * TARGET_ASM_FILE_END: File Framework. (line 37)
31717 * TARGET_ASM_FILE_START: File Framework. (line 9)
31718 * TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 17)
31719 * TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 31)
31720 * TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 61)
31721 * TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 55)
31722 * TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 68)
31723 * TARGET_ASM_FUNCTION_EPILOGUE and trampolines: Trampolines. (line 71)
31724 * TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 11)
31725 * TARGET_ASM_FUNCTION_PROLOGUE and trampolines: Trampolines. (line 71)
31726 * TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 161)
31727 * TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 165)
31728 * TARGET_ASM_INTEGER: Data Output. (line 27)
31729 * TARGET_ASM_INTERNAL_LABEL: Label Output. (line 300)
31730 * TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 271)
31731 * TARGET_ASM_NAMED_SECTION: File Framework. (line 89)
31732 * TARGET_ASM_OPEN_PAREN: Data Output. (line 127)
31733 * TARGET_ASM_OUTPUT_DWARF_DTPREL: SDB and DWARF. (line 57)
31734 * TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 195)
31735 * TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 170)
31736 * TARGET_ASM_SELECT_SECTION: Sections. (line 126)
31737 * TARGET_ASM_TTYPE: Exception Region Output.
31739 * TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 14)
31740 * TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 12)
31741 * TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 13)
31742 * TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 15)
31743 * TARGET_ASM_UNIQUE_SECTION: Sections. (line 149)
31744 * TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 11)
31745 * TARGET_BINDS_LOCAL_P: Sections. (line 232)
31746 * TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 747)
31747 * TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 739)
31748 * TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 249)
31749 * TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 109)
31750 * TARGET_C99_FUNCTIONS: Library Calls. (line 77)
31751 * TARGET_CALLEE_COPIES: Register Arguments. (line 115)
31752 * TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 248)
31753 * TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 726)
31754 * TARGET_COMMUTATIVE_P: Misc. (line 670)
31755 * TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 19)
31756 * TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 9)
31757 * TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 75)
31758 * TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 38)
31759 * TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 62)
31760 * TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 25)
31761 * TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 54)
31762 * TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 18)
31763 * TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 12)
31764 * TARGET_CXX_GUARD_TYPE: C++ ABI. (line 7)
31765 * TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 30)
31766 * TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 43)
31767 * TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 69)
31768 * TARGET_DECLSPEC: Target Attributes. (line 64)
31769 * TARGET_DEFAULT_PACK_STRUCT: Misc. (line 447)
31770 * TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 108)
31771 * TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 384)
31772 * TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 239)
31773 * TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 47)
31774 * TARGET_DWARF_CALLING_CONVENTION: SDB and DWARF. (line 18)
31775 * TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 160)
31776 * TARGET_DWARF_REGISTER_SPAN: Exception Region Output.
31778 * TARGET_EDOM: Library Calls. (line 59)
31779 * TARGET_ENCODE_SECTION_INFO: Sections. (line 183)
31780 * TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes.
31782 * TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 100)
31783 * TARGET_EXECUTABLE_SUFFIX: Misc. (line 700)
31784 * TARGET_EXPAND_BUILTIN: Misc. (line 622)
31785 * TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 92)
31786 * TARGET_EXPR: Expression trees. (line 6)
31787 * TARGET_EXTRA_INCLUDES: Misc. (line 772)
31788 * TARGET_EXTRA_PRE_INCLUDES: Misc. (line 779)
31789 * TARGET_FIXED_CONDITION_CODE_REGS: Condition Code. (line 142)
31790 * target_flags: Run-time Target. (line 52)
31791 * TARGET_FLOAT_FORMAT: Storage Layout. (line 383)
31792 * TARGET_FLT_EVAL_METHOD: Type Layout. (line 89)
31793 * TARGET_FOLD_BUILTIN: Misc. (line 642)
31794 * TARGET_FORMAT_TYPES: Misc. (line 799)
31795 * TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 86)
31796 * TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 8)
31797 * TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 254)
31798 * TARGET_HANDLE_OPTION: Run-time Target. (line 61)
31799 * TARGET_HAVE_CTORS_DTORS: Macros for Initialization.
31801 * TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 99)
31802 * TARGET_IN_SMALL_DATA_P: Sections. (line 224)
31803 * TARGET_INIT_BUILTINS: Misc. (line 604)
31804 * TARGET_INIT_LIBFUNCS: Library Calls. (line 16)
31805 * TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 73)
31806 * TARGET_INVALID_BINARY_OP: Misc. (line 837)
31807 * TARGET_INVALID_CONVERSION: Misc. (line 824)
31808 * TARGET_INVALID_UNARY_OP: Misc. (line 830)
31809 * TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 35)
31810 * TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 589)
31811 * TARGET_MANGLE_FUNDAMENTAL_TYPE: Storage Layout. (line 518)
31812 * TARGET_MD_ASM_CLOBBERS: Misc. (line 505)
31813 * TARGET_MEM_REF: Expression trees. (line 6)
31814 * TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 39)
31815 * TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 31)
31816 * TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 106)
31817 * TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 491)
31818 * TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 62)
31819 * TARGET_MUST_PASS_IN_STACK, and FUNCTION_ARG: Register Arguments.
31821 * TARGET_N_FORMAT_TYPES: Misc. (line 804)
31822 * TARGET_OBJECT_SUFFIX: Misc. (line 695)
31823 * TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 46)
31824 * TARGET_OPTF: Misc. (line 786)
31825 * TARGET_OPTION_TRANSLATE_TABLE: Driver. (line 53)
31826 * TARGET_OS_CPP_BUILTINS: Run-time Target. (line 42)
31827 * TARGET_PASS_BY_REFERENCE: Register Arguments. (line 103)
31828 * TARGET_POSIX_IO: Misc. (line 529)
31829 * TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 152)
31830 * TARGET_PROMOTE_FUNCTION_ARGS: Storage Layout. (line 130)
31831 * TARGET_PROMOTE_FUNCTION_RETURN: Storage Layout. (line 135)
31832 * TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 11)
31833 * TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 183)
31834 * TARGET_RELAXED_ORDERING: Misc. (line 808)
31835 * TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 632)
31836 * TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 16)
31837 * TARGET_RETURN_IN_MSB: Scalar Return. (line 90)
31838 * TARGET_RTX_COSTS: Costs. (line 188)
31839 * TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 266)
31840 * TARGET_SCHED_ADJUST_COST: Scheduling. (line 40)
31841 * TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 55)
31842 * TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 92)
31843 * TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 194)
31844 * TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 147)
31845 * TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 135)
31846 * TARGET_SCHED_FINISH: Scheduling. (line 112)
31847 * TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 129)
31848 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling.
31850 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling.
31852 * TARGET_SCHED_INIT: Scheduling. (line 102)
31853 * TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 152)
31854 * TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 144)
31855 * TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 121)
31856 * TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 208)
31857 * TARGET_SCHED_ISSUE_RATE: Scheduling. (line 12)
31858 * TARGET_SCHED_REORDER: Scheduling. (line 63)
31859 * TARGET_SCHED_REORDER2: Scheduling. (line 80)
31860 * TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 27)
31861 * TARGET_SECTION_TYPE_FLAGS: File Framework. (line 104)
31862 * TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 26)
31863 * TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 101)
31864 * TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 154)
31865 * TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 237)
31866 * TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection.
31868 * TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection.
31870 * TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 137)
31871 * TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 44)
31872 * TARGET_UNWIND_EMIT: Dispatch Tables. (line 74)
31873 * TARGET_UNWIND_INFO: Exception Region Output.
31875 * TARGET_USE_JCR_SECTION: Misc. (line 842)
31876 * TARGET_USE_LOCAL_THUNK_ALIAS_P: Misc. (line 792)
31877 * TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 128)
31878 * TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 59)
31879 * TARGET_VALID_POINTER_MODE: Register Arguments. (line 260)
31880 * TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 278)
31881 * TARGET_VECTOR_OPAQUE_P: Storage Layout. (line 484)
31882 * TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 259)
31883 * TARGET_VERSION: Run-time Target. (line 77)
31884 * TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 236)
31885 * TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 230)
31886 * TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 219)
31887 * TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 236)
31888 * targetm: Target Structure. (line 7)
31889 * targets, makefile: Makefile. (line 6)
31890 * TCmode: Machine Modes. (line 111)
31891 * TEMPLATE_DECL: Declarations. (line 6)
31892 * Temporaries: Temporaries. (line 6)
31893 * termination routines: Initialization. (line 6)
31894 * text_section: Sections. (line 109)
31895 * TEXT_SECTION_ASM_OP: Sections. (line 18)
31896 * TFmode: Machine Modes. (line 85)
31897 * THEN_CLAUSE: Function Bodies. (line 6)
31898 * THREAD_MODEL_SPEC: Driver. (line 225)
31899 * THROW_EXPR: Expression trees. (line 6)
31900 * THUNK_DECL: Declarations. (line 6)
31901 * THUNK_DELTA: Declarations. (line 6)
31902 * TImode: Machine Modes. (line 48)
31903 * TImode, in insn: Insns. (line 242)
31904 * tm.h macros: Target Macros. (line 6)
31905 * TQFmode: Machine Modes. (line 62)
31906 * TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 63)
31907 * TRAMPOLINE_ALIGNMENT: Trampolines. (line 50)
31908 * TRAMPOLINE_SECTION: Trampolines. (line 40)
31909 * TRAMPOLINE_SIZE: Trampolines. (line 46)
31910 * TRAMPOLINE_TEMPLATE: Trampolines. (line 29)
31911 * trampolines for nested functions: Trampolines. (line 6)
31912 * TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 125)
31913 * trap instruction pattern: Standard Names. (line 1131)
31914 * tree <1>: Macros and Functions.
31916 * tree: Tree overview. (line 6)
31917 * Tree SSA: Tree SSA. (line 6)
31918 * TREE_CODE: Tree overview. (line 6)
31919 * TREE_FILENAME: Working with declarations.
31921 * tree_int_cst_equal: Expression trees. (line 6)
31922 * TREE_INT_CST_HIGH: Expression trees. (line 6)
31923 * TREE_INT_CST_LOW: Expression trees. (line 6)
31924 * tree_int_cst_lt: Expression trees. (line 6)
31925 * TREE_LINENO: Working with declarations.
31927 * TREE_LIST: Containers. (line 6)
31928 * TREE_OPERAND: Expression trees. (line 6)
31929 * TREE_PUBLIC: Function Basics. (line 6)
31930 * TREE_PURPOSE: Containers. (line 6)
31931 * TREE_STRING_LENGTH: Expression trees. (line 6)
31932 * TREE_STRING_POINTER: Expression trees. (line 6)
31933 * TREE_TYPE <1>: Expression trees. (line 6)
31934 * TREE_TYPE <2>: Function Basics. (line 171)
31935 * TREE_TYPE <3>: Working with declarations.
31937 * TREE_TYPE: Types. (line 6)
31938 * TREE_VALUE: Containers. (line 6)
31939 * TREE_VEC: Containers. (line 6)
31940 * TREE_VEC_ELT: Containers. (line 6)
31941 * TREE_VEC_LENGTH: Containers. (line 6)
31942 * Trees: Trees. (line 6)
31943 * TRULY_NOOP_TRUNCATION: Misc. (line 177)
31944 * TRUNC_DIV_EXPR: Expression trees. (line 6)
31945 * TRUNC_MOD_EXPR: Expression trees. (line 6)
31946 * truncate: Conversions. (line 38)
31947 * truncMN2 instruction pattern: Standard Names. (line 605)
31948 * TRUTH_AND_EXPR: Expression trees. (line 6)
31949 * TRUTH_ANDIF_EXPR: Expression trees. (line 6)
31950 * TRUTH_NOT_EXPR: Expression trees. (line 6)
31951 * TRUTH_OR_EXPR: Expression trees. (line 6)
31952 * TRUTH_ORIF_EXPR: Expression trees. (line 6)
31953 * TRUTH_XOR_EXPR: Expression trees. (line 6)
31954 * TRY_BLOCK: Function Bodies. (line 6)
31955 * TRY_HANDLERS: Function Bodies. (line 6)
31956 * TRY_STMTS: Function Bodies. (line 6)
31957 * tstM instruction pattern: Standard Names. (line 459)
31958 * type: Types. (line 6)
31959 * type declaration: Declarations. (line 6)
31960 * TYPE_ALIGN: Types. (line 6)
31961 * TYPE_ARG_TYPES: Types. (line 6)
31962 * TYPE_ASM_OP: Label Output. (line 55)
31963 * TYPE_ATTRIBUTES: Attributes. (line 25)
31964 * TYPE_BINFO: Classes. (line 6)
31965 * TYPE_BUILT_IN: Types. (line 83)
31966 * TYPE_CONTEXT: Types. (line 6)
31967 * TYPE_DECL: Declarations. (line 6)
31968 * TYPE_FIELDS <1>: Classes. (line 6)
31969 * TYPE_FIELDS: Types. (line 6)
31970 * TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 91)
31971 * TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 76)
31972 * TYPE_HAS_MUTABLE_P: Classes. (line 81)
31973 * TYPE_HAS_NEW_OPERATOR: Classes. (line 88)
31974 * TYPE_MAIN_VARIANT: Types. (line 6)
31975 * TYPE_MAX_VALUE: Types. (line 6)
31976 * TYPE_METHOD_BASETYPE: Types. (line 6)
31977 * TYPE_METHODS: Classes. (line 6)
31978 * TYPE_MIN_VALUE: Types. (line 6)
31979 * TYPE_NAME: Types. (line 6)
31980 * TYPE_NOTHROW_P: Function Basics. (line 180)
31981 * TYPE_OFFSET_BASETYPE: Types. (line 6)
31982 * TYPE_OPERAND_FMT: Label Output. (line 66)
31983 * TYPE_OVERLOADS_ARRAY_REF: Classes. (line 99)
31984 * TYPE_OVERLOADS_ARROW: Classes. (line 102)
31985 * TYPE_OVERLOADS_CALL_EXPR: Classes. (line 95)
31986 * TYPE_POLYMORPHIC_P: Classes. (line 72)
31987 * TYPE_PRECISION: Types. (line 6)
31988 * TYPE_PTR_P: Types. (line 89)
31989 * TYPE_PTRFN_P: Types. (line 93)
31990 * TYPE_PTRMEM_P: Types. (line 6)
31991 * TYPE_PTROB_P: Types. (line 96)
31992 * TYPE_PTROBV_P: Types. (line 6)
31993 * TYPE_QUAL_CONST: Types. (line 6)
31994 * TYPE_QUAL_RESTRICT: Types. (line 6)
31995 * TYPE_QUAL_VOLATILE: Types. (line 6)
31996 * TYPE_RAISES_EXCEPTIONS: Function Basics. (line 175)
31997 * TYPE_SIZE: Types. (line 6)
31998 * TYPE_UNQUALIFIED: Types. (line 6)
31999 * TYPE_VFIELD: Classes. (line 6)
32000 * TYPENAME_TYPE: Types. (line 6)
32001 * TYPENAME_TYPE_FULLNAME: Types. (line 6)
32002 * TYPEOF_TYPE: Types. (line 6)
32003 * udiv: Arithmetic. (line 111)
32004 * udivM3 instruction pattern: Standard Names. (line 193)
32005 * udivmodM4 instruction pattern: Standard Names. (line 272)
32006 * UINTMAX_TYPE: Type Layout. (line 172)
32007 * umax: Arithmetic. (line 127)
32008 * umaxM3 instruction pattern: Standard Names. (line 193)
32009 * umin: Arithmetic. (line 127)
32010 * uminM3 instruction pattern: Standard Names. (line 193)
32011 * umod: Arithmetic. (line 114)
32012 * umodM3 instruction pattern: Standard Names. (line 193)
32013 * umulhisi3 instruction pattern: Standard Names. (line 243)
32014 * umulM3_highpart instruction pattern: Standard Names. (line 252)
32015 * umulqihi3 instruction pattern: Standard Names. (line 243)
32016 * umulsidi3 instruction pattern: Standard Names. (line 243)
32017 * unchanging: Flags. (line 303)
32018 * unchanging, in call_insn: Flags. (line 19)
32019 * unchanging, in jump_insn, call_insn and insn: Flags. (line 24)
32020 * unchanging, in mem: Flags. (line 142)
32021 * unchanging, in subreg: Flags. (line 178)
32022 * unchanging, in symbol_ref: Flags. (line 10)
32023 * UNEQ_EXPR: Expression trees. (line 6)
32024 * UNGE_EXPR: Expression trees. (line 6)
32025 * UNGT_EXPR: Expression trees. (line 6)
32026 * UNION_TYPE <1>: Classes. (line 6)
32027 * UNION_TYPE: Types. (line 6)
32028 * unions, returning: Interface. (line 10)
32029 * UNITS_PER_SIMD_WORD: Storage Layout. (line 77)
32030 * UNITS_PER_WORD: Storage Layout. (line 67)
32031 * UNKNOWN_TYPE: Types. (line 6)
32032 * UNLE_EXPR: Expression trees. (line 6)
32033 * UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 29)
32034 * UNLT_EXPR: Expression trees. (line 6)
32035 * UNORDERED_EXPR: Expression trees. (line 6)
32036 * unshare_all_rtl: Sharing. (line 58)
32037 * unsigned division: Arithmetic. (line 111)
32038 * unsigned greater than: Comparisons. (line 64)
32039 * unsigned less than: Comparisons. (line 68)
32040 * unsigned minimum and maximum: Arithmetic. (line 127)
32041 * unsigned_fix: Conversions. (line 72)
32042 * unsigned_float: Conversions. (line 62)
32043 * unspec: Side Effects. (line 284)
32044 * unspec_volatile: Side Effects. (line 284)
32045 * untyped_call instruction pattern: Standard Names. (line 769)
32046 * untyped_return instruction pattern: Standard Names. (line 819)
32047 * UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59)
32048 * update_ssa: SSA. (line 76)
32049 * update_stmt: Statement Operands. (line 6)
32050 * US Software GOFAST, floating point emulation library: Library Calls.
32052 * us_minus: Arithmetic. (line 36)
32053 * us_plus: Arithmetic. (line 14)
32054 * US_SOFTWARE_GOFAST: Library Calls. (line 45)
32055 * us_truncate: Conversions. (line 48)
32056 * use: Side Effects. (line 159)
32057 * USE_C_ALLOCA: Host Misc. (line 19)
32058 * USE_LD_AS_NEEDED: Driver. (line 198)
32059 * USE_LOAD_POST_DECREMENT: Costs. (line 143)
32060 * USE_LOAD_POST_INCREMENT: Costs. (line 138)
32061 * USE_LOAD_PRE_DECREMENT: Costs. (line 153)
32062 * USE_LOAD_PRE_INCREMENT: Costs. (line 148)
32063 * use_param: GTY Options. (line 114)
32064 * use_paramN: GTY Options. (line 132)
32065 * use_params: GTY Options. (line 140)
32066 * USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 141)
32067 * USE_STORE_POST_DECREMENT: Costs. (line 163)
32068 * USE_STORE_POST_INCREMENT: Costs. (line 158)
32069 * USE_STORE_PRE_DECREMENT: Costs. (line 173)
32070 * USE_STORE_PRE_INCREMENT: Costs. (line 168)
32071 * used: Flags. (line 321)
32072 * used, in symbol_ref: Flags. (line 205)
32073 * USER_LABEL_PREFIX: Instruction Output. (line 126)
32074 * USING_DECL: Declarations. (line 6)
32075 * USING_STMT: Function Bodies. (line 6)
32076 * V in constraint: Simple Constraints. (line 41)
32077 * VA_ARG_EXPR: Expression trees. (line 6)
32078 * values, returned by functions: Scalar Return. (line 6)
32079 * VAR_DECL <1>: Expression trees. (line 6)
32080 * VAR_DECL: Declarations. (line 6)
32081 * varargs implementation: Varargs. (line 6)
32082 * variable: Declarations. (line 6)
32083 * VAX_FLOAT_FORMAT: Storage Layout. (line 391)
32084 * vec_concat: Vector Operations. (line 25)
32085 * vec_duplicate: Vector Operations. (line 30)
32086 * vec_extractM instruction pattern: Standard Names. (line 170)
32087 * vec_initM instruction pattern: Standard Names. (line 175)
32088 * vec_merge: Vector Operations. (line 11)
32089 * vec_select: Vector Operations. (line 19)
32090 * vec_setM instruction pattern: Standard Names. (line 165)
32091 * vec_shl_M instruction pattern: Standard Names. (line 230)
32092 * vec_shr_M instruction pattern: Standard Names. (line 230)
32093 * vector: Containers. (line 6)
32094 * vector operations: Vector Operations. (line 6)
32095 * VECTOR_CST: Expression trees. (line 6)
32096 * VECTOR_STORE_FLAG_VALUE: Misc. (line 282)
32097 * virtual operands: Statement Operands. (line 6)
32098 * VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59)
32099 * VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87)
32100 * VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78)
32101 * VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69)
32102 * VLIW: Processor pipeline description.
32104 * VMS: Filesystem. (line 37)
32105 * VMS_DEBUGGING_INFO: VMS Debug. (line 9)
32106 * VOID_TYPE: Types. (line 6)
32107 * VOIDmode: Machine Modes. (line 104)
32108 * volatil: Flags. (line 335)
32109 * volatil, in insn, call_insn, jump_insn, code_label, barrier, and note: Flags.
32111 * volatil, in label_ref and reg_label: Flags. (line 55)
32112 * volatil, in mem, asm_operands, and asm_input: Flags. (line 84)
32113 * volatil, in reg: Flags. (line 102)
32114 * volatil, in subreg: Flags. (line 178)
32115 * volatil, in symbol_ref: Flags. (line 214)
32116 * volatile memory references: Flags. (line 336)
32117 * voting between constraint alternatives: Class Preferences. (line 6)
32118 * walk_dominator_tree: SSA. (line 227)
32119 * walk_use_def_chains: SSA. (line 203)
32120 * WCHAR_TYPE: Type Layout. (line 140)
32121 * WCHAR_TYPE_SIZE: Type Layout. (line 148)
32122 * which_alternative: Output Statement. (line 59)
32123 * WHILE_BODY: Function Bodies. (line 6)
32124 * WHILE_COND: Function Bodies. (line 6)
32125 * WHILE_STMT: Function Bodies. (line 6)
32126 * WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 95)
32127 * WINT_TYPE: Type Layout. (line 153)
32128 * word_mode: Machine Modes. (line 222)
32129 * WORD_REGISTER_OPERATIONS: Misc. (line 63)
32130 * WORD_SWITCH_TAKES_ARG: Driver. (line 20)
32131 * WORDS_BIG_ENDIAN: Storage Layout. (line 29)
32132 * WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 132)
32133 * X in constraint: Simple Constraints. (line 112)
32134 * x-HOST: Host Fragment. (line 6)
32135 * XCmode: Machine Modes. (line 111)
32136 * XCOFF_DEBUGGING_INFO: DBX Options. (line 13)
32137 * XEXP: Accessors. (line 6)
32138 * XFmode: Machine Modes. (line 79)
32139 * XINT: Accessors. (line 6)
32140 * xm-MACHINE.h <1>: Host Misc. (line 6)
32141 * xm-MACHINE.h: Filesystem. (line 6)
32142 * xor: Arithmetic. (line 146)
32143 * xor, canonicalization of: Insn Canonicalizations.
32145 * xorM3 instruction pattern: Standard Names. (line 193)
32146 * XSTR: Accessors. (line 6)
32147 * XVEC: Accessors. (line 41)
32148 * XVECEXP: Accessors. (line 48)
32149 * XVECLEN: Accessors. (line 44)
32150 * XWINT: Accessors. (line 6)
32151 * zero_extend: Conversions. (line 28)
32152 * zero_extendMN2 instruction pattern: Standard Names. (line 615)
32153 * zero_extract: Bit-Fields. (line 30)
32154 * zero_extract, canonicalization of: Insn Canonicalizations.
32161 Node: Contributing
\7f4888
32162 Node: Portability
\7f5629
32163 Node: Interface
\7f7417
32164 Node: Libgcc
\7f10457
32165 Node: Integer library routines
\7f12203
32166 Node: Soft float library routines
\7f18888
32167 Node: Exception handling routines
\7f28346
32168 Node: Miscellaneous routines
\7f29441
32169 Node: Languages
\7f29824
32170 Node: Source Tree
\7f31371
32171 Node: Configure Terms
\7f31990
32172 Node: Top Level
\7f34948
32173 Node: gcc Directory
\7f37296
32174 Node: Subdirectories
\7f38265
32175 Node: Configuration
\7f40603
32176 Node: Config Fragments
\7f41323
32177 Node: System Config
\7f42667
32178 Node: Configuration Files
\7f43603
32179 Node: Build
\7f46289
32180 Node: Makefile
\7f46701
32181 Node: Library Files
\7f50939
32182 Node: Headers
\7f51501
32183 Node: Documentation
\7f53480
32184 Node: Texinfo Manuals
\7f54330
32185 Node: Man Page Generation
\7f56512
32186 Node: Miscellaneous Docs
\7f58427
32187 Node: Front End
\7f59782
32188 Node: Front End Directory
\7f63549
32189 Node: Front End Config
\7f68898
32190 Node: Back End
\7f71816
32191 Node: Testsuites
\7f75490
32192 Node: Test Idioms
\7f76282
32193 Node: Test Directives
\7f79683
32194 Node: Ada Tests
\7f89731
32195 Node: C Tests
\7f91023
32196 Node: libgcj Tests
\7f95378
32197 Node: gcov Testing
\7f96798
32198 Node: profopt Testing
\7f99782
32199 Node: compat Testing
\7f101225
32200 Node: Options
\7f105447
32201 Node: Option file format
\7f105888
32202 Node: Option properties
\7f108438
32203 Node: Passes
\7f113904
32204 Node: Parsing pass
\7f114639
32205 Node: Gimplification pass
\7f118167
32206 Node: Pass manager
\7f119994
32207 Node: Tree-SSA passes
\7f121322
32208 Node: RTL passes
\7f141697
32209 Node: Trees
\7f153370
32210 Node: Deficiencies
\7f156096
32211 Node: Tree overview
\7f156333
32212 Node: Macros and Functions
\7f160456
32213 Node: Identifiers
\7f160602
32214 Node: Containers
\7f162127
32215 Node: Types
\7f163282
32216 Node: Scopes
\7f175890
32217 Node: Namespaces
\7f176652
32218 Node: Classes
\7f179464
32219 Node: Declarations
\7f184221
32220 Node: Working with declarations
\7f184716
32221 Node: Internal structure
\7f190588
32222 Node: Current structure hierarchy
\7f190970
32223 Node: Adding new DECL node types
\7f193062
32224 Node: Functions
\7f197133
32225 Node: Function Basics
\7f199536
32226 Node: Function Bodies
\7f206701
32227 Node: Attributes
\7f218677
32228 Node: Expression trees
\7f219918
32229 Node: Tree SSA
\7f250063
32230 Node: GENERIC
\7f251920
32231 Node: GIMPLE
\7f253530
32232 Node: Interfaces
\7f254821
32233 Node: Temporaries
\7f256699
32234 Ref: Temporaries-Footnote-1
\7f258019
32235 Node: GIMPLE Expressions
\7f258082
32236 Node: Compound Expressions
\7f258854
32237 Node: Compound Lvalues
\7f259102
32238 Node: Conditional Expressions
\7f259882
32239 Node: Logical Operators
\7f260559
32240 Node: Statements
\7f261052
32241 Node: Blocks
\7f261760
32242 Node: Statement Sequences
\7f263177
32243 Node: Empty Statements
\7f263514
32244 Node: Loops
\7f264092
32245 Node: Selection Statements
\7f264336
32246 Node: Jumps
\7f265189
32247 Node: Cleanups
\7f265834
32248 Node: GIMPLE Exception Handling
\7f267625
32249 Node: GIMPLE Example
\7f269504
32250 Node: Rough GIMPLE Grammar
\7f270915
32251 Node: Annotations
\7f276171
32252 Node: Statement Operands
\7f276837
32254 Node: Alias analysis
\7f302807
32256 Node: RTL Objects
\7f312078
32257 Node: RTL Classes
\7f315952
32258 Node: Accessors
\7f320904
32259 Node: Special Accessors
\7f323298
32260 Node: Flags
\7f327168
32261 Node: Machine Modes
\7f342622
32262 Node: Constants
\7f351347
32263 Node: Regs and Memory
\7f357602
32264 Node: Arithmetic
\7f370676
32265 Node: Comparisons
\7f378809
32266 Node: Bit-Fields
\7f383101
32267 Node: Vector Operations
\7f384653
32268 Node: Conversions
\7f386279
32269 Node: RTL Declarations
\7f389594
32270 Node: Side Effects
\7f390415
32271 Node: Incdec
\7f406531
32272 Node: Assembler
\7f409871
32273 Node: Insns
\7f411403
32274 Node: Calls
\7f437230
32275 Node: Sharing
\7f439823
32276 Node: Reading RTL
\7f442933
32277 Node: Control Flow
\7f443923
32278 Node: Basic Blocks
\7f444894
32279 Node: Edges
\7f449462
32280 Node: Profile information
\7f458024
32281 Node: Maintaining the CFG
\7f462710
32282 Node: Liveness information
\7f469602
32283 Node: Machine Desc
\7f472022
32284 Node: Overview
\7f474477
32285 Node: Patterns
\7f476518
32286 Node: Example
\7f479956
32287 Node: RTL Template
\7f481391
32288 Node: Output Template
\7f492046
32289 Node: Output Statement
\7f496012
32290 Node: Predicates
\7f499974
32291 Node: Machine-Independent Predicates
\7f502892
32292 Node: Defining Predicates
\7f507524
32293 Node: Constraints
\7f512173
32294 Node: Simple Constraints
\7f513202
32295 Node: Multi-Alternative
\7f525590
32296 Node: Class Preferences
\7f528431
32297 Node: Modifiers
\7f529323
32298 Node: Machine Constraints
\7f533449
32299 Node: Standard Names
\7f559587
32300 Ref: shift patterns
\7f572181
32301 Ref: prologue instruction pattern
\7f609259
32302 Ref: epilogue instruction pattern
\7f609752
32303 Node: Pattern Ordering
\7f618775
32304 Node: Dependent Patterns
\7f620011
32305 Node: Jump Patterns
\7f622825
32306 Node: Looping Patterns
\7f628521
32307 Node: Insn Canonicalizations
\7f633123
32308 Node: Expander Definitions
\7f637285
32309 Node: Insn Splitting
\7f645403
32310 Node: Including Patterns
\7f654999
32311 Node: Peephole Definitions
\7f656779
32312 Node: define_peephole
\7f658032
32313 Node: define_peephole2
\7f664363
32314 Node: Insn Attributes
\7f667430
32315 Node: Defining Attributes
\7f668536
32316 Node: Expressions
\7f670553
32317 Node: Tagging Insns
\7f677155
32318 Node: Attr Example
\7f681508
32319 Node: Insn Lengths
\7f683882
32320 Node: Constant Attributes
\7f686941
32321 Node: Delay Slots
\7f688110
32322 Node: Processor pipeline description
\7f691334
32323 Ref: Processor pipeline description-Footnote-1
\7f708576
32324 Node: Conditional Execution
\7f708906
32325 Node: Constant Definitions
\7f711759
32326 Node: Macros
\7f713351
32327 Node: Mode Macros
\7f713780
32328 Node: Defining Mode Macros
\7f714719
32329 Node: Substitutions
\7f716183
32330 Node: Examples
\7f718387
32331 Node: Code Macros
\7f719823
32332 Node: Target Macros
\7f722038
32333 Node: Target Structure
\7f724844
32334 Node: Driver
\7f726113
32335 Node: Run-time Target
\7f748373
32336 Node: Per-Function Data
\7f754308
32337 Node: Storage Layout
\7f757071
32338 Node: Type Layout
\7f781354
32339 Node: Registers
\7f792230
32340 Node: Register Basics
\7f793153
32341 Node: Allocation Order
\7f798720
32342 Node: Values in Registers
\7f800165
32343 Node: Leaf Functions
\7f807138
32344 Node: Stack Registers
\7f809996
32345 Node: Register Classes
\7f811112
32346 Node: Stack and Calling
\7f837285
32347 Node: Frame Layout
\7f837818
32348 Node: Exception Handling
\7f847717
32349 Node: Stack Checking
\7f854065
32350 Node: Frame Registers
\7f857694
32351 Node: Elimination
\7f864298
32352 Node: Stack Arguments
\7f868327
32353 Node: Register Arguments
\7f874902
32354 Node: Scalar Return
\7f889129
32355 Node: Aggregate Return
\7f893900
32356 Node: Caller Saves
\7f897351
32357 Node: Function Entry
\7f898527
32358 Node: Profiling
\7f911143
32359 Node: Tail Calls
\7f912840
32360 Node: Stack Smashing Protection
\7f913706
32361 Node: Varargs
\7f914816
32362 Node: Trampolines
\7f922776
32363 Node: Library Calls
\7f929551
32364 Node: Addressing Modes
\7f933971
32365 Node: Condition Code
\7f948021
32366 Node: Costs
\7f956308
32367 Node: Scheduling
\7f968308
32368 Node: Sections
\7f981363
32370 Node: Assembler Format
\7f995201
32371 Node: File Framework
\7f996280
32372 Node: Data Output
\7f1001843
32373 Node: Uninitialized Data
\7f1009274
32374 Node: Label Output
\7f1014806
32375 Node: Initialization
\7f1036095
32376 Node: Macros for Initialization
\7f1042057
32377 Node: Instruction Output
\7f1048120
32378 Node: Dispatch Tables
\7f1057114
32379 Node: Exception Region Output
\7f1060599
32380 Node: Alignment Output
\7f1066477
32381 Node: Debugging Info
\7f1070621
32382 Node: All Debuggers
\7f1071291
32383 Node: DBX Options
\7f1074146
32384 Node: DBX Hooks
\7f1079595
32385 Node: File Names and DBX
\7f1081521
32386 Node: SDB and DWARF
\7f1083632
32387 Node: VMS Debug
\7f1087567
32388 Node: Floating Point
\7f1088137
32389 Node: Mode Switching
\7f1092959
32390 Node: Target Attributes
\7f1096885
32391 Node: MIPS Coprocessors
\7f1101627
32392 Node: PCH Target
\7f1103201
32393 Node: C++ ABI
\7f1104722
32394 Node: Misc
\7f1108694
32395 Ref: TARGET_SHIFT_TRUNCATION_MASK
\7f1116065
32396 Node: Host Config
\7f1150974
32397 Node: Host Common
\7f1152034
32398 Node: Filesystem
\7f1154413
32399 Node: Host Misc
\7f1158528
32400 Node: Fragments
\7f1160888
32401 Node: Target Fragment
\7f1162083
32402 Node: Host Fragment
\7f1167749
32403 Node: Collect2
\7f1169191
32404 Node: Header Dirs
\7f1171734
32405 Node: Type Information
\7f1173157
32406 Node: GTY Options
\7f1175345
32407 Node: GGC Roots
\7f1185479
32408 Node: Files
\7f1186199
32409 Node: Funding
\7f1188863
32410 Node: GNU Project
\7f1191359
32411 Node: Copying
\7f1192008
32412 Node: GNU Free Documentation License
\7f1211188
32413 Node: Contributors
\7f1233597
32414 Node: Option Index
\7f1269164
32415 Node: Concept Index
\7f1269749