1 This is doc/gccint.info, produced by makeinfo version 4.8 from
2 /scratch/mitchell/gcc-releases/gcc-4.1.1/gcc-4.1.1/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.1.
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', in
1859 case other testcases with similar names are added later. If the test
1860 is a test of some well-defined feature, it should have a name referring
1861 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 DegaGnu 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-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
2025 This DejaGnu directive appears on a source line that is expected
2026 to get an error message, or else specifies the source line
2027 associated with the message. If there is no message for that line
2028 or if the text of that message is not matched by REGEXP then the
2029 check fails and COMMENT is included in the `FAIL' message. The
2030 check does not look for the string `"error"' unless it is part of
2033 `{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
2034 This DejaGnu directive appears on a source line that is expected
2035 to get a warning message, or else specifies the source line
2036 associated with the message. If there is no message for that line
2037 or if the text of that message is not matched by REGEXP then the
2038 check fails and COMMENT is included in the `FAIL' message. The
2039 check does not look for the string `"warning"' unless it is part
2042 `{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
2043 This DejaGnu directive appears on a source line that should not
2044 get a message matching REGEXP, or else specifies the source line
2045 associated with the bogus message. It is usually used with `xfail'
2046 to indicate that the message is a known problem for a particular
2049 `{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }'
2050 This DejaGnu directive indicates that the test is expected to fail
2051 due to compiler messages that are not handled by `dg-error',
2052 `dg-warning' or `dg-bogus'.
2054 `{ dg-output REGEXP [{ target/xfail SELECTOR }] }'
2055 This DejaGnu directive compares REGEXP to the combined output that
2056 the test executable writes to `stdout' and `stderr'.
2058 `{ dg-prune-output REGEXP }'
2059 Prune messages matching REGEXP from test output.
2061 `{ dg-additional-files "FILELIST" }'
2062 Specify additional files, other than source files, that must be
2063 copied to the system where the compiler runs.
2065 `{ dg-additional-sources "FILELIST" }'
2066 Specify additional source files to appear in the compile line
2067 following the main test file.
2069 `{ dg-final { LOCAL-DIRECTIVE } }'
2070 This DejaGnu directive is placed within a comment anywhere in the
2071 source file and is processed after the test has been compiled and
2072 run. Multiple `dg-final' commands are processed in the order in
2073 which they appear in the source file.
2075 The GCC testsuite defines the following directives to be used
2078 `cleanup-coverage-files'
2079 Removes coverage data files generated for this test.
2081 `cleanup-repo-files'
2082 Removes files generated for this test for `-frepo'.
2084 `cleanup-rtl-dump SUFFIX'
2085 Removes RTL dump files generated for this test.
2087 `cleanup-tree-dump SUFFIX'
2088 Removes tree dump files matching SUFFIX which were generated
2091 `cleanup-saved-temps'
2092 Removes files for the current test which were kept for
2095 `scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]'
2096 Passes if REGEXP matches text in FILENAME.
2098 `scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]'
2099 Passes if REGEXP does not match text in FILENAME.
2101 `scan-hidden SYMBOL [{ target/xfail SELECTOR }]'
2102 Passes if SYMBOL is defined as a hidden symbol in the test's
2105 `scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]'
2106 Passes if SYMBOL is not defined as a hidden symbol in the
2107 test's assembly output.
2109 `scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]'
2110 Passes if REGEX is matched exactly NUM times in the test's
2113 `scan-assembler REGEX [{ target/xfail SELECTOR }]'
2114 Passes if REGEX matches text in the test's assembler output.
2116 `scan-assembler-not REGEX [{ target/xfail SELECTOR }]'
2117 Passes if REGEX does not match text in the test's assembler
2120 `scan-assembler-dem REGEX [{ target/xfail SELECTOR }]'
2121 Passes if REGEX matches text in the test's demangled
2124 `scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]'
2125 Passes if REGEX does not match text in the test's demangled
2128 `scan-tree-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]'
2129 Passes if REGEX is found exactly NUM times in the dump file
2132 `scan-tree-dump REGEX SUFFIX [{ target/xfail SELECTOR }]'
2133 Passes if REGEX matches text in the dump file with suffix
2136 `scan-tree-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]'
2137 Passes if REGEX does not match text in the dump file with
2140 `scan-tree-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]'
2141 Passes if REGEX matches demangled text in the dump file with
2144 `scan-tree-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]'
2145 Passes if REGEX does not match demangled text in the dump
2146 file with suffix SUFFIX.
2148 `run-gcov SOURCEFILE'
2149 Check line counts in `gcov' tests.
2151 `run-gcov [branches] [calls] { OPTS SOURCEFILE }'
2152 Check branch and/or call counts, in addition to line counts,
2156 File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites
2158 6.4.3 Ada Language Testsuites
2159 -----------------------------
2161 The Ada testsuite includes executable tests from the ACATS 2.5
2162 testsuite, publicly available at
2163 `http://www.adaic.org/compilers/acats/2.5'
2165 These tests are integrated in the GCC testsuite in the
2166 `gcc/testsuite/ada/acats' directory, and enabled automatically when
2167 running `make check', assuming the Ada language has been enabled when
2170 You can also run the Ada testsuite independently, using `make
2171 check-ada', or run a subset of the tests by specifying which chapter to
2174 $ make check-ada CHAPTERS="c3 c9"
2176 The tests are organized by directory, each directory corresponding to
2177 a chapter of the Ada Reference Manual. So for example, c9 corresponds
2178 to chapter 9, which deals with tasking features of the language.
2180 There is also an extra chapter called `gcc' containing a template for
2181 creating new executable tests.
2183 The tests are run using two `sh' scripts: `run_acats' and
2184 `run_all.sh'. To run the tests using a simulator or a cross target,
2185 see the small customization section at the top of `run_all.sh'.
2187 These tests are run using the build tree: they can be run without doing
2191 File: gccint.info, Node: C Tests, Next: libgcj Tests, Prev: Ada Tests, Up: Testsuites
2193 6.4.4 C Language Testsuites
2194 ---------------------------
2196 GCC contains the following C language testsuites, in the
2197 `gcc/testsuite' directory:
2200 This contains tests of particular features of the C compiler,
2201 using the more modern `dg' harness. Correctness tests for various
2202 compiler features should go here if possible.
2204 Magic comments determine whether the file is preprocessed,
2205 compiled, linked or run. In these tests, error and warning
2206 message texts are compared against expected texts or regular
2207 expressions given in comments. These tests are run with the
2208 options `-ansi -pedantic' unless other options are given in the
2209 test. Except as noted below they are not run with multiple
2210 optimization options.
2213 This subdirectory contains tests for binary compatibility using
2214 `compat.exp', which in turn uses the language-independent support
2215 (*note Support for testing binary compatibility: compat Testing.).
2218 This subdirectory contains tests of the preprocessor.
2221 This subdirectory contains tests for debug formats. Tests in this
2222 subdirectory are run for each debug format that the compiler
2226 This subdirectory contains tests of the `-Wformat' format
2227 checking. Tests in this directory are run with and without
2231 This subdirectory contains tests of code that should not compile
2232 and does not need any special compilation options. They are run
2233 with multiple optimization options, since sometimes invalid code
2234 crashes the compiler with optimization.
2237 FIXME: describe this.
2240 This contains particular code fragments which have historically
2241 broken easily. These tests are run with multiple optimization
2242 options, so tests for features which only break at some
2243 optimization levels belong here. This also contains tests to
2244 check that certain optimizations occur. It might be worthwhile to
2245 separate the correctness tests cleanly from the code quality
2246 tests, but it hasn't been done yet.
2248 `gcc.c-torture/compat'
2249 FIXME: describe this.
2251 This directory should probably not be used for new tests.
2253 `gcc.c-torture/compile'
2254 This testsuite contains test cases that should compile, but do not
2255 need to link or run. These test cases are compiled with several
2256 different combinations of optimization options. All warnings are
2257 disabled for these test cases, so this directory is not suitable if
2258 you wish to test for the presence or absence of compiler warnings.
2259 While special options can be set, and tests disabled on specific
2260 platforms, by the use of `.x' files, mostly these test cases
2261 should not contain platform dependencies. FIXME: discuss how
2262 defines such as `NO_LABEL_VALUES' and `STACK_SIZE' are used.
2264 `gcc.c-torture/execute'
2265 This testsuite contains test cases that should compile, link and
2266 run; otherwise the same comments as for `gcc.c-torture/compile'
2269 `gcc.c-torture/execute/ieee'
2270 This contains tests which are specific to IEEE floating point.
2272 `gcc.c-torture/unsorted'
2273 FIXME: describe this.
2275 This directory should probably not be used for new tests.
2277 `gcc.c-torture/misc-tests'
2278 This directory contains C tests that require special handling.
2279 Some of these tests have individual expect files, and others share
2280 special-purpose expect files:
2283 Test `-fbranch-probabilities' using `bprob.exp', which in
2284 turn uses the generic, language-independent framework (*note
2285 Support for testing profile-directed optimizations: profopt
2289 Test the testsuite itself using `dg-test.exp'.
2292 Test `gcov' output using `gcov.exp', which in turn uses the
2293 language-independent support (*note Support for testing gcov:
2297 Test i386-specific support for data prefetch using
2298 `i386-prefetch.exp'.
2301 FIXME: merge in `testsuite/README.gcc' and discuss the format of test
2302 cases and magic comments more.
2305 File: gccint.info, Node: libgcj Tests, Next: gcov Testing, Prev: C Tests, Up: Testsuites
2307 6.4.5 The Java library testsuites.
2308 ----------------------------------
2310 Runtime tests are executed via `make check' in the
2311 `TARGET/libjava/testsuite' directory in the build tree. Additional
2312 runtime tests can be checked into this testsuite.
2314 Regression testing of the core packages in libgcj is also covered by
2315 the Mauve testsuite. The Mauve Project develops tests for the Java
2316 Class Libraries. These tests are run as part of libgcj testing by
2317 placing the Mauve tree within the libjava testsuite sources at
2318 `libjava/testsuite/libjava.mauve/mauve', or by specifying the location
2319 of that tree when invoking `make', as in `make MAUVEDIR=~/mauve check'.
2321 To detect regressions, a mechanism in `mauve.exp' compares the
2322 failures for a test run against the list of expected failures in
2323 `libjava/testsuite/libjava.mauve/xfails' from the source hierarchy.
2324 Update this file when adding new failing tests to Mauve, or when fixing
2325 bugs in libgcj that had caused Mauve test failures.
2327 The Jacks project provides a testsuite for Java compilers that can be
2328 used to test changes that affect the GCJ front end. This testsuite is
2329 run as part of Java testing by placing the Jacks tree within the libjava
2330 testsuite sources at `libjava/testsuite/libjava.jacks/jacks'.
2332 We encourage developers to contribute test cases to Mauve and Jacks.
2335 File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: libgcj Tests, Up: Testsuites
2337 6.4.6 Support for testing `gcov'
2338 --------------------------------
2340 Language-independent support for testing `gcov', and for checking that
2341 branch profiling produces expected values, is provided by the expect
2342 file `gcov.exp'. `gcov' tests also rely on procedures in `gcc.dg.exp'
2343 to compile and run the test program. A typical `gcov' test contains
2344 the following DejaGnu commands within comments:
2346 { dg-options "-fprofile-arcs -ftest-coverage" }
2347 { dg-do run { target native } }
2348 { dg-final { run-gcov sourcefile } }
2350 Checks of `gcov' output can include line counts, branch percentages,
2351 and call return percentages. All of these checks are requested via
2352 commands that appear in comments in the test's source file. Commands
2353 to check line counts are processed by default. Commands to check
2354 branch percentages and call return percentages are processed if the
2355 `run-gcov' command has arguments `branches' or `calls', respectively.
2356 For example, the following specifies checking both, as well as passing
2359 { dg-final { run-gcov branches calls { -b sourcefile } } }
2361 A line count command appears within a comment on the source line that
2362 is expected to get the specified count and has the form `count(CNT)'.
2363 A test should only check line counts for lines that will get the same
2364 count for any architecture.
2366 Commands to check branch percentages (`branch') and call return
2367 percentages (`returns') are very similar to each other. A beginning
2368 command appears on or before the first of a range of lines that will
2369 report the percentage, and the ending command follows that range of
2370 lines. The beginning command can include a list of percentages, all of
2371 which are expected to be found within the range. A range is terminated
2372 by the next command of the same kind. A command `branch(end)' or
2373 `returns(end)' marks the end of a range without starting a new one.
2376 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */
2380 For a call return percentage, the value specified is the percentage of
2381 calls reported to return. For a branch percentage, the value is either
2382 the expected percentage or 100 minus that value, since the direction of
2383 a branch can differ depending on the target or the optimization level.
2385 Not all branches and calls need to be checked. A test should not
2386 check for branches that might be optimized away or replaced with
2387 predicated instructions. Don't check for calls inserted by the
2388 compiler or ones that might be inlined or optimized away.
2390 A single test can check for combinations of line counts, branch
2391 percentages, and call return percentages. The command to check a line
2392 count must appear on the line that will report that count, but commands
2393 to check branch percentages and call return percentages can bracket the
2394 lines that report them.
2397 File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites
2399 6.4.7 Support for testing profile-directed optimizations
2400 --------------------------------------------------------
2402 The file `profopt.exp' provides language-independent support for
2403 checking correct execution of a test built with profile-directed
2404 optimization. This testing requires that a test program be built and
2405 executed twice. The first time it is compiled to generate profile
2406 data, and the second time it is compiled to use the data that was
2407 generated during the first execution. The second execution is to
2408 verify that the test produces the expected results.
2410 To check that the optimization actually generated better code, a test
2411 can be built and run a third time with normal optimizations to verify
2412 that the performance is better with the profile-directed optimizations.
2413 `profopt.exp' has the beginnings of this kind of support.
2415 `profopt.exp' provides generic support for profile-directed
2416 optimizations. Each set of tests that uses it provides information
2417 about a specific optimization:
2420 tool being tested, e.g., `gcc'
2423 options used to generate profile data
2426 options used to optimize using that profile data
2429 suffix of profile data files
2432 list of options with which to run each test, similar to the lists
2436 File: gccint.info, Node: compat Testing, Prev: profopt Testing, Up: Testsuites
2438 6.4.8 Support for testing binary compatibility
2439 ----------------------------------------------
2441 The file `compat.exp' provides language-independent support for binary
2442 compatibility testing. It supports testing interoperability of two
2443 compilers that follow the same ABI, or of multiple sets of compiler
2444 options that should not affect binary compatibility. It is intended to
2445 be used for testsuites that complement ABI testsuites.
2447 A test supported by this framework has three parts, each in a separate
2448 source file: a main program and two pieces that interact with each
2449 other to split up the functionality being tested.
2451 `TESTNAME_main.SUFFIX'
2452 Contains the main program, which calls a function in file
2453 `TESTNAME_x.SUFFIX'.
2456 Contains at least one call to a function in `TESTNAME_y.SUFFIX'.
2459 Shares data with, or gets arguments from, `TESTNAME_x.SUFFIX'.
2461 Within each test, the main program and one functional piece are
2462 compiled by the GCC under test. The other piece can be compiled by an
2463 alternate compiler. If no alternate compiler is specified, then all
2464 three source files are all compiled by the GCC under test. You can
2465 specify pairs of sets of compiler options. The first element of such a
2466 pair specifies options used with the GCC under test, and the second
2467 element of the pair specifies options used with the alternate compiler.
2468 Each test is compiled with each pair of options.
2470 `compat.exp' defines default pairs of compiler options. These can be
2471 overridden by defining the environment variable `COMPAT_OPTIONS' as:
2473 COMPAT_OPTIONS="[list [list {TST1} {ALT1}]
2474 ...[list {TSTN} {ALTN}]]"
2476 where TSTI and ALTI are lists of options, with TSTI used by the
2477 compiler under test and ALTI used by the alternate compiler. For
2478 example, with `[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]',
2479 the test is first built with `-g -O0' by the compiler under test and
2480 with `-O3' by the alternate compiler. The test is built a second time
2481 using `-fpic' by the compiler under test and `-fPIC -O2' by the
2484 An alternate compiler is specified by defining an environment variable
2485 to be the full pathname of an installed compiler; for C define
2486 `ALT_CC_UNDER_TEST', and for C++ define `ALT_CXX_UNDER_TEST'. These
2487 will be written to the `site.exp' file used by DejaGnu. The default is
2488 to build each test with the compiler under test using the first of each
2489 pair of compiler options from `COMPAT_OPTIONS'. When
2490 `ALT_CC_UNDER_TEST' or `ALT_CXX_UNDER_TEST' is `same', each test is
2491 built using the compiler under test but with combinations of the
2492 options from `COMPAT_OPTIONS'.
2494 To run only the C++ compatibility suite using the compiler under test
2495 and another version of GCC using specific compiler options, do the
2496 following from `OBJDIR/gcc':
2500 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \
2501 COMPAT_OPTIONS="lists as shown above" \
2503 RUNTESTFLAGS="compat.exp"
2505 A test that fails when the source files are compiled with different
2506 compilers, but passes when the files are compiled with the same
2507 compiler, demonstrates incompatibility of the generated code or runtime
2508 support. A test that fails for the alternate compiler but passes for
2509 the compiler under test probably tests for a bug that was fixed in the
2510 compiler under test but is present in the alternate compiler.
2512 The binary compatibility tests support a small number of test framework
2513 commands that appear within comments in a test file.
2516 These commands can be used in `TESTNAME_main.SUFFIX' to skip the
2517 test if specific support is not available on the target.
2520 The specified options are used for compiling this particular source
2521 file, appended to the options from `COMPAT_OPTIONS'. When this
2522 command appears in `TESTNAME_main.SUFFIX' the options are also
2523 used to link the test program.
2526 This command can be used in a secondary source file to specify that
2527 compilation is expected to fail for particular options on
2531 File: gccint.info, Node: Options, Next: Passes, Prev: Source Tree, Up: Top
2533 7 Option specification files
2534 ****************************
2536 Most GCC command-line options are described by special option
2537 definition files, the names of which conventionally end in `.opt'.
2538 This chapter describes the format of these files.
2542 * Option file format:: The general layout of the files
2543 * Option properties:: Supported option properties
2546 File: gccint.info, Node: Option file format, Next: Option properties, Up: Options
2548 7.1 Option file format
2549 ======================
2551 Option files are a simple list of records in which each field occupies
2552 its own line and in which the records themselves are separated by blank
2553 lines. Comments may appear on their own line anywhere within the file
2554 and are preceded by semicolons. Whitespace is allowed before the
2557 The files can contain the following types of record:
2559 * A language definition record. These records have two fields: the
2560 string `Language' and the name of the language. Once a language
2561 has been declared in this way, it can be used as an option
2562 property. *Note Option properties::.
2564 * An option definition record. These records have the following
2567 1. the name of the option, with the leading "-" removed
2569 2. a space-separated list of option properties (*note Option
2572 3. the help text to use for `--help' (omitted if the second field
2573 contains the `Undocumented' property).
2575 By default, all options beginning with "f", "W" or "m" are
2576 implicitly assumed to take a "no-" form. This form should not be
2577 listed separately. If an option beginning with one of these
2578 letters does not have a "no-" form, you can use the
2579 `RejectNegative' property to reject it.
2581 The help text is automatically line-wrapped before being displayed.
2582 Normally the name of the option is printed on the left-hand side of
2583 the output and the help text is printed on the right. However, if
2584 the help text contains a tab character, the text to the left of
2585 the tab is used instead of the option's name and the text to the
2586 right of the tab forms the help text. This allows you to
2587 elaborate on what type of argument the option takes.
2589 * A target mask record. These records have one field of the form
2590 `Mask(X)'. The options-processing script will automatically
2591 allocate a bit in `target_flags' (*note Run-time Target::) for
2592 each mask name X and set the macro `MASK_X' to the appropriate
2593 bitmask. It will also declare a `TARGET_X' macro that has the
2594 value 1 when bit `MASK_X' is set and 0 otherwise.
2596 They are primarily intended to declare target masks that are not
2597 associated with user options, either because these masks represent
2598 internal switches or because the options are not available on all
2599 configurations and yet the masks always need to be defined.
2602 File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options
2604 7.2 Option properties
2605 =====================
2607 The second field of an option record can specify the following
2611 The option is available for all languages and targets.
2614 The option is available for all languages but is target-specific.
2617 The option is available when compiling for the given language.
2619 It is possible to specify several different languages for the same
2620 option. Each LANGUAGE must have been declared by an earlier
2621 `Language' record. *Note Option file format::.
2624 The option does not have a "no-" form. All options beginning with
2625 "f", "W" or "m" are assumed to have a "no-" form unless this
2630 The option takes a mandatory argument. `Joined' indicates that
2631 the option and argument can be included in the same `argv' entry
2632 (as with `-mflush-func=NAME', for example). `Separate' indicates
2633 that the option and argument can be separate `argv' entries (as
2634 with `-o'). An option is allowed to have both of these properties.
2637 The option takes an optional argument. If the argument is given,
2638 it will be part of the same `argv' entry as the option itself.
2640 This property cannot be used alongside `Joined' or `Separate'.
2643 The option's argument is a non-negative integer. The option parser
2644 will check and convert the argument before passing it to the
2645 relevant option handler.
2648 The state of this option should be stored in variable VAR. The
2649 way that the state is stored depends on the type of option:
2651 * If the option uses the `Mask' or `InverseMask' properties,
2652 VAR is the integer variable that contains the mask.
2654 * If the option is a normal on/off switch, VAR is an integer
2655 variable that is nonzero when the option is enabled. The
2656 options parser will set the variable to 1 when the positive
2657 form of the option is used and 0 when the "no-" form is used.
2659 * If the option takes an argument and has the `UInteger'
2660 property, VAR is an integer variable that stores the value of
2663 * Otherwise, if the option takes an argument, VAR is a pointer
2664 to the argument string. The pointer will be null if the
2665 argument is optional and wasn't given.
2667 The option-processing script will usually declare VAR in
2668 `options.c' and leave it to be zero-initialized at start-up time.
2669 You can modify this behavior using `VarExists' and `Init'.
2672 The option controls an integer variable VAR and is active when VAR
2673 equals SET. The option parser will set VAR to SET when the
2674 positive form of the option is used and `!SET' when the "no-" form
2677 VAR is declared in the same way as for the single-argument form
2681 The variable specified by the `Var' property already exists. No
2682 definition should be added to `options.c' in response to this
2685 You should use this property if an earlier option has already
2686 declared the variable or if the variable is declared outside
2690 The variable specified by the `Var' property should be statically
2691 initialized to VALUE.
2694 The option is associated with a bit in the `target_flags' variable
2695 (*note Run-time Target::) and is active when that bit is set. You
2696 may also specify `Var' to select a variable other than
2699 The options-processing script will automatically allocate a unique
2700 bit for the option. If the option is attached to `target_flags',
2701 the script will set the macro `MASK_NAME' to the appropriate
2702 bitmask. It will also declare a `TARGET_NAME' macro that has the
2703 value 1 when the option is active and 0 otherwise. If you use
2704 `Var' to attach the option to a different variable, the associated
2705 macros are called `OPTION_MASK_NAME' and `OPTION_NAME'
2708 You can disable automatic bit allocation using `MaskExists'.
2710 `InverseMask(OTHERNAME)'
2711 `InverseMask(OTHERNAME, THISNAME)'
2712 The option is the inverse of another option that has the
2713 `Mask(OTHERNAME)' property. If THISNAME is given, the
2714 options-processing script will declare a `TARGET_THISNAME' macro
2715 that is 1 when the option is active and 0 otherwise.
2718 The mask specified by the `Mask' property already exists. No
2719 `MASK' or `TARGET' definitions should be added to `options.h' in
2720 response to this option record.
2722 The main purpose of this property is to support synonymous options.
2723 The first option should use `Mask(NAME)' and the others should use
2724 `Mask(NAME) MaskExists'.
2727 The state of the option should be printed by `-fverbose-asm'.
2730 The option is deliberately missing documentation and should not be
2731 included in the `--help' output.
2734 The option should only be accepted if preprocessor condition COND
2735 is true. Note that any C declarations associated with the option
2736 will be present even if COND is false; COND simply controls
2737 whether the option is accepted and whether it is printed in the
2741 File: gccint.info, Node: Passes, Next: Trees, Prev: Options, Up: Top
2743 8 Passes and Files of the Compiler
2744 **********************************
2746 This chapter is dedicated to giving an overview of the optimization and
2747 code generation passes of the compiler. In the process, it describes
2748 some of the language front end interface, though this description is no
2749 where near complete.
2753 * Parsing pass:: The language front end turns text into bits.
2754 * Gimplification pass:: The bits are turned into something we can optimize.
2755 * Pass manager:: Sequencing the optimization passes.
2756 * Tree-SSA passes:: Optimizations on a high-level representation.
2757 * RTL passes:: Optimizations on a low-level representation.
2760 File: gccint.info, Node: Parsing pass, Next: Gimplification pass, Up: Passes
2765 The language front end is invoked only once, via
2766 `lang_hooks.parse_file', to parse the entire input. The language front
2767 end may use any intermediate language representation deemed
2768 appropriate. The C front end uses GENERIC trees (CROSSREF), plus a
2769 double handful of language specific tree codes defined in
2770 `c-common.def'. The Fortran front end uses a completely different
2771 private representation.
2773 At some point the front end must translate the representation used in
2774 the front end to a representation understood by the language-independent
2775 portions of the compiler. Current practice takes one of two forms.
2776 The C front end manually invokes the gimplifier (CROSSREF) on each
2777 function, and uses the gimplifier callbacks to convert the
2778 language-specific tree nodes directly to GIMPLE (CROSSREF) before
2779 passing the function off to be compiled. The Fortran front end
2780 converts from a private representation to GENERIC, which is later
2781 lowered to GIMPLE when the function is compiled. Which route to choose
2782 probably depends on how well GENERIC (plus extensions) can be made to
2783 match up with the source language and necessary parsing data structures.
2785 BUG: Gimplification must occur before nested function lowering, and
2786 nested function lowering must be done by the front end before passing
2787 the data off to cgraph.
2789 TODO: Cgraph should control nested function lowering. It would only
2790 be invoked when it is certain that the outer-most function is used.
2792 TODO: Cgraph needs a gimplify_function callback. It should be invoked
2793 when (1) it is certain that the function is used, (2) warning flags
2794 specified by the user require some amount of compilation in order to
2795 honor, (3) the language indicates that semantic analysis is not
2796 complete until gimplification occurs. Hum... this sounds overly
2797 complicated. Perhaps we should just have the front end gimplify
2798 always; in most cases it's only one function call.
2800 The front end needs to pass all function definitions and top level
2801 declarations off to the middle-end so that they can be compiled and
2802 emitted to the object file. For a simple procedural language, it is
2803 usually most convenient to do this as each top level declaration or
2804 definition is seen. There is also a distinction to be made between
2805 generating functional code and generating complete debug information.
2806 The only thing that is absolutely required for functional code is that
2807 function and data _definitions_ be passed to the middle-end. For
2808 complete debug information, function, data and type declarations should
2809 all be passed as well.
2811 In any case, the front end needs each complete top-level function or
2812 data declaration, and each data definition should be passed to
2813 `rest_of_decl_compilation'. Each complete type definition should be
2814 passed to `rest_of_type_compilation'. Each function definition should
2815 be passed to `cgraph_finalize_function'.
2817 TODO: I know rest_of_compilation currently has all sorts of
2818 rtl-generation semantics. I plan to move all code generation bits
2819 (both tree and rtl) to compile_function. Should we hide cgraph from
2820 the front ends and move back to rest_of_compilation as the official
2821 interface? Possibly we should rename all three interfaces such that
2822 the names match in some meaningful way and that is more descriptive
2825 The middle-end will, at its option, emit the function and data
2826 definitions immediately or queue them for later processing.
2829 File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Parsing pass, Up: Passes
2831 8.2 Gimplification pass
2832 =======================
2834 "Gimplification" is a whimsical term for the process of converting the
2835 intermediate representation of a function into the GIMPLE language
2836 (CROSSREF). The term stuck, and so words like "gimplification",
2837 "gimplify", "gimplifier" and the like are sprinkled throughout this
2840 While a front end may certainly choose to generate GIMPLE directly if
2841 it chooses, this can be a moderately complex process unless the
2842 intermediate language used by the front end is already fairly simple.
2843 Usually it is easier to generate GENERIC trees plus extensions and let
2844 the language-independent gimplifier do most of the work.
2846 The main entry point to this pass is `gimplify_function_tree' located
2847 in `gimplify.c'. From here we process the entire function gimplifying
2848 each statement in turn. The main workhorse for this pass is
2849 `gimplify_expr'. Approximately everything passes through here at least
2850 once, and it is from here that we invoke the `lang_hooks.gimplify_expr'
2853 The callback should examine the expression in question and return
2854 `GS_UNHANDLED' if the expression is not a language specific construct
2855 that requires attention. Otherwise it should alter the expression in
2856 some way to such that forward progress is made toward producing valid
2857 GIMPLE. If the callback is certain that the transformation is complete
2858 and the expression is valid GIMPLE, it should return `GS_ALL_DONE'.
2859 Otherwise it should return `GS_OK', which will cause the expression to
2860 be processed again. If the callback encounters an error during the
2861 transformation (because the front end is relying on the gimplification
2862 process to finish semantic checks), it should return `GS_ERROR'.
2865 File: gccint.info, Node: Pass manager, Next: Tree-SSA passes, Prev: Gimplification pass, Up: Passes
2870 The pass manager is located in `passes.c', `tree-optimize.c' and
2871 `tree-pass.h'. Its job is to run all of the individual passes in the
2872 correct order, and take care of standard bookkeeping that applies to
2875 The theory of operation is that each pass defines a structure that
2876 represents everything we need to know about that pass--when it should
2877 be run, how it should be run, what intermediate language form or
2878 on-the-side data structures it needs. We register the pass to be run
2879 in some particular order, and the pass manager arranges for everything
2880 to happen in the correct order.
2882 The actuality doesn't completely live up to the theory at present.
2883 Command-line switches and `timevar_id_t' enumerations must still be
2884 defined elsewhere. The pass manager validates constraints but does not
2885 attempt to (re-)generate data structures or lower intermediate language
2886 form based on the requirements of the next pass. Nevertheless, what is
2887 present is useful, and a far sight better than nothing at all.
2889 TODO: describe the global variables set up by the pass manager, and a
2890 brief description of how a new pass should use it. I need to look at
2891 what info rtl passes use first...
2894 File: gccint.info, Node: Tree-SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes
2899 The following briefly describes the tree optimization passes that are
2900 run after gimplification and what source files they are located in.
2902 * Remove useless statements
2904 This pass is an extremely simple sweep across the gimple code in
2905 which we identify obviously dead code and remove it. Here we do
2906 things like simplify `if' statements with constant conditions,
2907 remove exception handling constructs surrounding code that
2908 obviously cannot throw, remove lexical bindings that contain no
2909 variables, and other assorted simplistic cleanups. The idea is to
2910 get rid of the obvious stuff quickly rather than wait until later
2911 when it's more work to get rid of it. This pass is located in
2912 `tree-cfg.c' and described by `pass_remove_useless_stmts'.
2914 * Mudflap declaration registration
2916 If mudflap (*note -fmudflap -fmudflapth -fmudflapir:
2917 (gcc.info)Optimize Options.) is enabled, we generate code to
2918 register some variable declarations with the mudflap runtime.
2919 Specifically, the runtime tracks the lifetimes of those variable
2920 declarations that have their addresses taken, or whose bounds are
2921 unknown at compile time (`extern'). This pass generates new
2922 exception handling constructs (`try'/`finally'), and so must run
2923 before those are lowered. In addition, the pass enqueues
2924 declarations of static variables whose lifetimes extend to the
2925 entire program. The pass is located in `tree-mudflap.c' and is
2926 described by `pass_mudflap_1'.
2928 * Lower control flow
2930 This pass flattens `if' statements (`COND_EXPR') and and moves
2931 lexical bindings (`BIND_EXPR') out of line. After this pass, all
2932 `if' statements will have exactly two `goto' statements in its
2933 `then' and `else' arms. Lexical binding information for each
2934 statement will be found in `TREE_BLOCK' rather than being inferred
2935 from its position under a `BIND_EXPR'. This pass is found in
2936 `gimple-low.c' and is described by `pass_lower_cf'.
2938 * Lower exception handling control flow
2940 This pass decomposes high-level exception handling constructs
2941 (`TRY_FINALLY_EXPR' and `TRY_CATCH_EXPR') into a form that
2942 explicitly represents the control flow involved. After this pass,
2943 `lookup_stmt_eh_region' will return a non-negative number for any
2944 statement that may have EH control flow semantics; examine
2945 `tree_can_throw_internal' or `tree_can_throw_external' for exact
2946 semantics. Exact control flow may be extracted from
2947 `foreach_reachable_handler'. The EH region nesting tree is defined
2948 in `except.h' and built in `except.c'. The lowering pass itself
2949 is in `tree-eh.c' and is described by `pass_lower_eh'.
2951 * Build the control flow graph
2953 This pass decomposes a function into basic blocks and creates all
2954 of the edges that connect them. It is located in `tree-cfg.c' and
2955 is described by `pass_build_cfg'.
2957 * Find all referenced variables
2959 This pass walks the entire function and collects an array of all
2960 variables referenced in the function, `referenced_vars'. The
2961 index at which a variable is found in the array is used as a UID
2962 for the variable within this function. This data is needed by the
2963 SSA rewriting routines. The pass is located in `tree-dfa.c' and
2964 is described by `pass_referenced_vars'.
2966 * Enter static single assignment form
2968 This pass rewrites the function such that it is in SSA form. After
2969 this pass, all `is_gimple_reg' variables will be referenced by
2970 `SSA_NAME', and all occurrences of other variables will be
2971 annotated with `VDEFS' and `VUSES'; phi nodes will have been
2972 inserted as necessary for each basic block. This pass is located
2973 in `tree-ssa.c' and is described by `pass_build_ssa'.
2975 * Warn for uninitialized variables
2977 This pass scans the function for uses of `SSA_NAME's that are fed
2978 by default definition. For non-parameter variables, such uses are
2979 uninitialized. The pass is run twice, before and after
2980 optimization. In the first pass we only warn for uses that are
2981 positively uninitialized; in the second pass we warn for uses that
2982 are possibly uninitialized. The pass is located in `tree-ssa.c'
2983 and is defined by `pass_early_warn_uninitialized' and
2984 `pass_late_warn_uninitialized'.
2986 * Dead code elimination
2988 This pass scans the function for statements without side effects
2989 whose result is unused. It does not do memory life analysis, so
2990 any value that is stored in memory is considered used. The pass
2991 is run multiple times throughout the optimization process. It is
2992 located in `tree-ssa-dce.c' and is described by `pass_dce'.
2994 * Dominator optimizations
2996 This pass performs trivial dominator-based copy and constant
2997 propagation, expression simplification, and jump threading. It is
2998 run multiple times throughout the optimization process. It it
2999 located in `tree-ssa-dom.c' and is described by `pass_dominator'.
3001 * Redundant phi elimination
3003 This pass removes phi nodes for which all of the arguments are the
3004 same value, excluding feedback. Such degenerate forms are
3005 typically created by removing unreachable code. The pass is run
3006 multiple times throughout the optimization process. It is located
3007 in `tree-ssa.c' and is described by `pass_redundant_phi'.o
3009 * Forward propagation of single-use variables
3011 This pass attempts to remove redundant computation by substituting
3012 variables that are used once into the expression that uses them and
3013 seeing if the result can be simplified. It is located in
3014 `tree-ssa-forwprop.c' and is described by `pass_forwprop'.
3018 This pass attempts to change the name of compiler temporaries
3019 involved in copy operations such that SSA->normal can coalesce the
3020 copy away. When compiler temporaries are copies of user
3021 variables, it also renames the compiler temporary to the user
3022 variable resulting in better use of user symbols. It is located
3023 in `tree-ssa-copyrename.c' and is described by `pass_copyrename'.
3025 * PHI node optimizations
3027 This pass recognizes forms of phi inputs that can be represented as
3028 conditional expressions and rewrites them into straight line code.
3029 It is located in `tree-ssa-phiopt.c' and is described by
3032 * May-alias optimization
3034 This pass performs a flow sensitive SSA-based points-to analysis.
3035 The resulting may-alias, must-alias, and escape analysis
3036 information is used to promote variables from in-memory
3037 addressable objects to non-aliased variables that can be renamed
3038 into SSA form. We also update the `VDEF'/`VUSE' memory tags for
3039 non-renamable aggregates so that we get fewer false kills. The
3040 pass is located in `tree-ssa-alias.c' and is described by
3045 This pass rewrites the function in order to collect runtime block
3046 and value profiling data. Such data may be fed back into the
3047 compiler on a subsequent run so as to allow optimization based on
3048 expected execution frequencies. The pass is located in
3049 `predict.c' and is described by `pass_profile'.
3051 * Lower complex arithmetic
3053 This pass rewrites complex arithmetic operations into their
3054 component scalar arithmetic operations. The pass is located in
3055 `tree-complex.c' and is described by `pass_lower_complex'.
3057 * Scalar replacement of aggregates
3059 This pass rewrites suitable non-aliased local aggregate variables
3060 into a set of scalar variables. The resulting scalar variables are
3061 rewritten into SSA form, which allows subsequent optimization
3062 passes to do a significantly better job with them. The pass is
3063 located in `tree-sra.c' and is described by `pass_sra'.
3065 * Dead store elimination
3067 This pass eliminates stores to memory that are subsequently
3068 overwritten by another store, without any intervening loads. The
3069 pass is located in `tree-ssa-dse.c' and is described by `pass_dse'.
3071 * Tail recursion elimination
3073 This pass transforms tail recursion into a loop. It is located in
3074 `tree-tailcall.c' and is described by `pass_tail_recursion'.
3076 * Forward store motion
3078 This pass sinks stores and assignments down the flowgraph closer
3079 to it's use point. The pass is located in `tree-ssa-sink.c' and is
3080 described by `pass_sink_code'.
3082 * Partial redundancy elimination
3084 This pass eliminates partially redundant computations, as well as
3085 performing load motion. The pass is located in `tree-ssa-pre.c'
3086 and is described by `pass_pre'.
3088 Just before partial redundancy elimination, if
3089 `-funsafe-math-optimizations' is on, GCC tries to convert
3090 divisions to multiplications by the reciprocal. The pass is
3091 located in `tree-ssa-math-opts.c' and is described by
3092 `pass_cse_reciprocal'.
3096 The main driver of the pass is placed in `tree-ssa-loop.c' and
3097 described by `pass_loop'.
3099 The optimizations performed by this pass are:
3101 Loop invariant motion. This pass moves only invariants that would
3102 be hard to handle on rtl level (function calls, operations that
3103 expand to nontrivial sequences of insns). With `-funswitch-loops'
3104 it also moves operands of conditions that are invariant out of the
3105 loop, so that we can use just trivial invariantness analysis in
3106 loop unswitching. The pass also includes store motion. The pass
3107 is implemented in `tree-ssa-loop-im.c'.
3109 Canonical induction variable creation. This pass creates a simple
3110 counter for number of iterations of the loop and replaces the exit
3111 condition of the loop using it, in case when a complicated
3112 analysis is necessary to determine the number of iterations.
3113 Later optimizations then may determine the number easily. The
3114 pass is implemented in `tree-ssa-loop-ivcanon.c'.
3116 Induction variable optimizations. This pass performs standard
3117 induction variable optimizations, including strength reduction,
3118 induction variable merging and induction variable elimination.
3119 The pass is implemented in `tree-ssa-loop-ivopts.c'.
3121 Loop unswitching. This pass moves the conditional jumps that are
3122 invariant out of the loops. To achieve this, a duplicate of the
3123 loop is created for each possible outcome of conditional jump(s).
3124 The pass is implemented in `tree-ssa-loop-unswitch.c'. This pass
3125 should eventually replace the rtl-level loop unswitching in
3126 `loop-unswitch.c', but currently the rtl-level pass is not
3127 completely redundant yet due to deficiencies in tree level alias
3130 The optimizations also use various utility functions contained in
3131 `tree-ssa-loop-manip.c', `cfgloop.c', `cfgloopanal.c' and
3134 Vectorization. This pass transforms loops to operate on vector
3135 types instead of scalar types. Data parallelism across loop
3136 iterations is exploited to group data elements from consecutive
3137 iterations into a vector and operate on them in parallel.
3138 Depending on available target support the loop is conceptually
3139 unrolled by a factor `VF' (vectorization factor), which is the
3140 number of elements operated upon in parallel in each iteration,
3141 and the `VF' copies of each scalar operation are fused to form a
3142 vector operation. Additional loop transformations such as peeling
3143 and versioning may take place to align the number of iterations,
3144 and to align the memory accesses in the loop. The pass is
3145 implemented in `tree-vectorizer.c' (the main driver and general
3146 utilities), `tree-vect-analyze.c' and `tree-vect-transform.c'.
3147 Analysis of data references is in `tree-data-ref.c'.
3149 * Tree level if-conversion for vectorizer
3151 This pass applies if-conversion to simple loops to help vectorizer.
3152 We identify if convertable loops, if-convert statements and merge
3153 basic blocks in one big block. The idea is to present loop in such
3154 form so that vectorizer can have one to one mapping between
3155 statements and available vector operations. This patch
3156 re-introduces COND_EXPR at GIMPLE level. This pass is located in
3159 * Conditional constant propagation
3161 This pass relaxes a lattice of values in order to identify those
3162 that must be constant even in the presence of conditional branches.
3163 The pass is located in `tree-ssa-ccp.c' and is described by
3166 * Folding builtin functions
3168 This pass simplifies builtin functions, as applicable, with
3169 constant arguments or with inferrable string lengths. It is
3170 located in `tree-ssa-ccp.c' and is described by
3171 `pass_fold_builtins'.
3173 * Split critical edges
3175 This pass identifies critical edges and inserts empty basic blocks
3176 such that the edge is no longer critical. The pass is located in
3177 `tree-cfg.c' and is described by `pass_split_crit_edges'.
3179 * Partial redundancy elimination
3181 This pass answers the question "given a hypothetical temporary
3182 variable, what expressions could we eliminate?" It is located in
3183 `tree-ssa-pre.c' and is described by `pass_pre'.
3185 * Control dependence dead code elimination
3187 This pass is a stronger form of dead code elimination that can
3188 eliminate unnecessary control flow statements. It is located in
3189 `tree-ssa-dce.c' and is described by `pass_cd_dce'.
3191 * Tail call elimination
3193 This pass identifies function calls that may be rewritten into
3194 jumps. No code transformation is actually applied here, but the
3195 data and control flow problem is solved. The code transformation
3196 requires target support, and so is delayed until RTL. In the
3197 meantime `CALL_EXPR_TAILCALL' is set indicating the possibility.
3198 The pass is located in `tree-tailcall.c' and is described by
3199 `pass_tail_calls'. The RTL transformation is handled by
3200 `fixup_tail_calls' in `calls.c'.
3202 * Warn for function return without value
3204 For non-void functions, this pass locates return statements that do
3205 not specify a value and issues a warning. Such a statement may
3206 have been injected by falling off the end of the function. This
3207 pass is run last so that we have as much time as possible to prove
3208 that the statement is not reachable. It is located in
3209 `tree-cfg.c' and is described by `pass_warn_function_return'.
3211 * Mudflap statement annotation
3213 If mudflap is enabled, we rewrite some memory accesses with code to
3214 validate that the memory access is correct. In particular,
3215 expressions involving pointer dereferences (`INDIRECT_REF',
3216 `ARRAY_REF', etc.) are replaced by code that checks the selected
3217 address range against the mudflap runtime's database of valid
3218 regions. This check includes an inline lookup into a
3219 direct-mapped cache, based on shift/mask operations of the pointer
3220 value, with a fallback function call into the runtime. The pass
3221 is located in `tree-mudflap.c' and is described by
3224 * Leave static single assignment form
3226 This pass rewrites the function such that it is in normal form. At
3227 the same time, we eliminate as many single-use temporaries as
3228 possible, so the intermediate language is no longer GIMPLE, but
3229 GENERIC. The pass is located in `tree-ssa.c' and is described by
3233 File: gccint.info, Node: RTL passes, Prev: Tree-SSA passes, Up: Passes
3238 The following briefly describes the rtl generation and optimization
3239 passes that are run after tree optimization.
3243 The source files for RTL generation include `stmt.c', `calls.c',
3244 `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and
3245 `emit-rtl.c'. Also, the file `insn-emit.c', generated from the
3246 machine description by the program `genemit', is used in this
3247 pass. The header file `expr.h' is used for communication within
3250 The header files `insn-flags.h' and `insn-codes.h', generated from
3251 the machine description by the programs `genflags' and `gencodes',
3252 tell this pass which standard names are available for use and
3253 which patterns correspond to them.
3255 * Generate exception handling landing pads
3257 This pass generates the glue that handles communication between the
3258 exception handling library routines and the exception handlers
3259 within the function. Entry points in the function that are
3260 invoked by the exception handling library are called "landing
3261 pads". The code for this pass is located within `except.c'.
3263 * Cleanup control flow graph
3265 This pass removes unreachable code, simplifies jumps to next,
3266 jumps to jump, jumps across jumps, etc. The pass is run multiple
3267 times. For historical reasons, it is occasionally referred to as
3268 the "jump optimization pass". The bulk of the code for this pass
3269 is in `cfgcleanup.c', and there are support routines in `cfgrtl.c'
3272 * Common subexpression elimination
3274 This pass removes redundant computation within basic blocks, and
3275 optimizes addressing modes based on cost. The pass is run twice.
3276 The source is located in `cse.c'.
3278 * Global common subexpression elimination.
3280 This pass performs two different types of GCSE depending on
3281 whether you are optimizing for size or not (LCM based GCSE tends
3282 to increase code size for a gain in speed, while Morel-Renvoise
3283 based GCSE does not). When optimizing for size, GCSE is done
3284 using Morel-Renvoise Partial Redundancy Elimination, with the
3285 exception that it does not try to move invariants out of
3286 loops--that is left to the loop optimization pass. If MR PRE
3287 GCSE is done, code hoisting (aka unification) is also done, as
3288 well as load motion. If you are optimizing for speed, LCM (lazy
3289 code motion) based GCSE is done. LCM is based on the work of
3290 Knoop, Ruthing, and Steffen. LCM based GCSE also does loop
3291 invariant code motion. We also perform load and store motion when
3292 optimizing for speed. Regardless of which type of GCSE is used,
3293 the GCSE pass also performs global constant and copy propagation.
3294 The source file for this pass is `gcse.c', and the LCM routines
3299 This pass moves constant expressions out of loops, and optionally
3300 does strength-reduction as well. The pass is located in `loop.c'.
3301 Loop dependency analysis routines are contained in `dependence.c'.
3302 This pass is seriously out-of-date and is supposed to be replaced
3303 by a new one described below in near future.
3305 A second loop optimization pass takes care of basic block level
3306 optimizations--unrolling, peeling and unswitching loops. The
3307 source files are `cfgloopanal.c' and `cfgloopmanip.c' containing
3308 generic loop analysis and manipulation code, `loop-init.c' with
3309 initialization and finalization code, `loop-unswitch.c' for loop
3310 unswitching and `loop-unroll.c' for loop unrolling and peeling.
3311 It also contains a separate loop invariant motion pass implemented
3312 in `loop-invariant.c'.
3316 This pass is an aggressive form of GCSE that transforms the control
3317 flow graph of a function by propagating constants into conditional
3318 branch instructions. The source file for this pass is `gcse.c'.
3322 This pass attempts to replace conditional branches and surrounding
3323 assignments with arithmetic, boolean value producing comparison
3324 instructions, and conditional move instructions. In the very last
3325 invocation after reload, it will generate predicated instructions
3326 when supported by the target. The pass is located in `ifcvt.c'.
3330 This pass splits independent uses of each pseudo-register. This
3331 can improve effect of the other transformation, such as CSE or
3332 register allocation. Its source files are `web.c'.
3336 This pass computes which pseudo-registers are live at each point in
3337 the program, and makes the first instruction that uses a value
3338 point at the instruction that computed the value. It then deletes
3339 computations whose results are never used, and combines memory
3340 references with add or subtract instructions to make autoincrement
3341 or autodecrement addressing. The pass is located in `flow.c'.
3343 * Instruction combination
3345 This pass attempts to combine groups of two or three instructions
3346 that are related by data flow into single instructions. It
3347 combines the RTL expressions for the instructions by substitution,
3348 simplifies the result using algebra, and then attempts to match
3349 the result against the machine description. The pass is located
3354 This pass looks for cases where matching constraints would force an
3355 instruction to need a reload, and this reload would be a
3356 register-to-register move. It then attempts to change the
3357 registers used by the instruction to avoid the move instruction.
3358 The pass is located in `regmove.c'.
3360 * Optimize mode switching
3362 This pass looks for instructions that require the processor to be
3363 in a specific "mode" and minimizes the number of mode changes
3364 required to satisfy all users. What these modes are, and what
3365 they apply to are completely target-specific. The source is
3366 located in `mode-switching.c'.
3370 This pass looks at innermost loops and reorders their instructions
3371 by overlapping different iterations. Modulo scheduling is
3372 performed immediately before instruction scheduling. The pass is
3373 located in (`modulo-sched.c').
3375 * Instruction scheduling
3377 This pass looks for instructions whose output will not be
3378 available by the time that it is used in subsequent instructions.
3379 Memory loads and floating point instructions often have this
3380 behavior on RISC machines. It re-orders instructions within a
3381 basic block to try to separate the definition and use of items
3382 that otherwise would cause pipeline stalls. This pass is
3383 performed twice, before and after register allocation. The pass
3384 is located in `haifa-sched.c', `sched-deps.c', `sched-ebb.c',
3385 `sched-rgn.c' and `sched-vis.c'.
3387 * Register allocation
3389 These passes make sure that all occurrences of pseudo registers are
3390 eliminated, either by allocating them to a hard register, replacing
3391 them by an equivalent expression (e.g. a constant) or by placing
3392 them on the stack. This is done in several subpasses:
3394 * Register class preferencing. The RTL code is scanned to find
3395 out which register class is best for each pseudo register.
3396 The source file is `regclass.c'.
3398 * Local register allocation. This pass allocates hard
3399 registers to pseudo registers that are used only within one
3400 basic block. Because the basic block is linear, it can use
3401 fast and powerful techniques to do a decent job. The source
3402 is located in `local-alloc.c'.
3404 * Global register allocation. This pass allocates hard
3405 registers for the remaining pseudo registers (those whose
3406 life spans are not contained in one basic block). The pass
3407 is located in `global.c'.
3409 * Reloading. This pass renumbers pseudo registers with the
3410 hardware registers numbers they were allocated. Pseudo
3411 registers that did not get hard registers are replaced with
3412 stack slots. Then it finds instructions that are invalid
3413 because a value has failed to end up in a register, or has
3414 ended up in a register of the wrong kind. It fixes up these
3415 instructions by reloading the problematical values
3416 temporarily into registers. Additional instructions are
3417 generated to do the copying.
3419 The reload pass also optionally eliminates the frame pointer
3420 and inserts instructions to save and restore call-clobbered
3421 registers around calls.
3423 Source files are `reload.c' and `reload1.c', plus the header
3424 `reload.h' used for communication between them.
3426 * Basic block reordering
3428 This pass implements profile guided code positioning. If profile
3429 information is not available, various types of static analysis are
3430 performed to make the predictions normally coming from the profile
3431 feedback (IE execution frequency, branch probability, etc). It is
3432 implemented in the file `bb-reorder.c', and the various prediction
3433 routines are in `predict.c'.
3437 This pass computes where the variables are stored at each position
3438 in code and generates notes describing the variable locations to
3439 RTL code. The location lists are then generated according to these
3440 notes to debug information if the debugging information format
3441 supports location lists.
3443 * Delayed branch scheduling
3445 This optional pass attempts to find instructions that can go into
3446 the delay slots of other instructions, usually jumps and calls.
3447 The source file name is `reorg.c'.
3451 On many RISC machines, branch instructions have a limited range.
3452 Thus, longer sequences of instructions must be used for long
3453 branches. In this pass, the compiler figures out what how far
3454 each instruction will be from each other instruction, and
3455 therefore whether the usual instructions, or the longer sequences,
3456 must be used for each branch.
3458 * Register-to-stack conversion
3460 Conversion from usage of some hard registers to usage of a register
3461 stack may be done at this point. Currently, this is supported only
3462 for the floating-point registers of the Intel 80387 coprocessor.
3463 The source file name is `reg-stack.c'.
3467 This pass outputs the assembler code for the function. The source
3468 files are `final.c' plus `insn-output.c'; the latter is generated
3469 automatically from the machine description by the tool `genoutput'.
3470 The header file `conditions.h' is used for communication between
3471 these files. If mudflap is enabled, the queue of deferred
3472 declarations and any addressed constants (e.g., string literals)
3473 is processed by `mudflap_finish_file' into a synthetic constructor
3474 function containing calls into the mudflap runtime.
3476 * Debugging information output
3478 This is run after final because it must output the stack slot
3479 offsets for pseudo registers that did not get hard registers.
3480 Source files are `dbxout.c' for DBX symbol table format,
3481 `sdbout.c' for SDB symbol table format, `dwarfout.c' for DWARF
3482 symbol table format, files `dwarf2out.c' and `dwarf2asm.c' for
3483 DWARF2 symbol table format, and `vmsdbgout.c' for VMS debug symbol
3488 File: gccint.info, Node: Trees, Next: RTL, Prev: Passes, Up: Top
3490 9 Trees: The intermediate representation used by the C and C++ front ends
3491 *************************************************************************
3493 This chapter documents the internal representation used by GCC to
3494 represent C and C++ source programs. When presented with a C or C++
3495 source program, GCC parses the program, performs semantic analysis
3496 (including the generation of error messages), and then produces the
3497 internal representation described here. This representation contains a
3498 complete representation for the entire translation unit provided as
3499 input to the front end. This representation is then typically processed
3500 by a code-generator in order to produce machine code, but could also be
3501 used in the creation of source browsers, intelligent editors, automatic
3502 documentation generators, interpreters, and any other programs needing
3503 the ability to process C or C++ code.
3505 This chapter explains the internal representation. In particular, it
3506 documents the internal representation for C and C++ source constructs,
3507 and the macros, functions, and variables that can be used to access
3508 these constructs. The C++ representation is largely a superset of the
3509 representation used in the C front end. There is only one construct
3510 used in C that does not appear in the C++ front end and that is the GNU
3511 "nested function" extension. Many of the macros documented here do not
3512 apply in C because the corresponding language constructs do not appear
3515 If you are developing a "back end", be it is a code-generator or some
3516 other tool, that uses this representation, you may occasionally find
3517 that you need to ask questions not easily answered by the functions and
3518 macros available here. If that situation occurs, it is quite likely
3519 that GCC already supports the functionality you desire, but that the
3520 interface is simply not documented here. In that case, you should ask
3521 the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting
3522 the functionality you require. Similarly, if you find yourself writing
3523 functions that do not deal directly with your back end, but instead
3524 might be useful to other people using the GCC front end, you should
3525 submit your patches for inclusion in GCC.
3529 * Deficiencies:: Topics net yet covered in this document.
3530 * Tree overview:: All about `tree's.
3531 * Types:: Fundamental and aggregate types.
3532 * Scopes:: Namespaces and classes.
3533 * Functions:: Overloading, function bodies, and linkage.
3534 * Declarations:: Type declarations and variables.
3535 * Attributes:: Declaration and type attributes.
3536 * Expression trees:: From `typeid' to `throw'.
3539 File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: Trees
3544 There are many places in which this document is incomplet and incorrekt.
3545 It is, as of yet, only _preliminary_ documentation.
3548 File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: Trees
3553 The central data structure used by the internal representation is the
3554 `tree'. These nodes, while all of the C type `tree', are of many
3555 varieties. A `tree' is a pointer type, but the object to which it
3556 points may be of a variety of types. From this point forward, we will
3557 refer to trees in ordinary type, rather than in `this font', except
3558 when talking about the actual C type `tree'.
3560 You can tell what kind of node a particular tree is by using the
3561 `TREE_CODE' macro. Many, many macros take trees as input and return
3562 trees as output. However, most macros require a certain kind of tree
3563 node as input. In other words, there is a type-system for trees, but
3564 it is not reflected in the C type-system.
3566 For safety, it is useful to configure GCC with `--enable-checking'.
3567 Although this results in a significant performance penalty (since all
3568 tree types are checked at run-time), and is therefore inappropriate in a
3569 release version, it is extremely helpful during the development process.
3571 Many macros behave as predicates. Many, although not all, of these
3572 predicates end in `_P'. Do not rely on the result type of these macros
3573 being of any particular type. You may, however, rely on the fact that
3574 the type can be compared to `0', so that statements like
3575 if (TEST_P (t) && !TEST_P (y))
3578 int i = (TEST_P (t) != 0);
3579 are legal. Macros that return `int' values now may be changed to
3580 return `tree' values, or other pointers in the future. Even those that
3581 continue to return `int' may return multiple nonzero codes where
3582 previously they returned only zero and one. Therefore, you should not
3584 if (TEST_P (t) == 1)
3585 as this code is not guaranteed to work correctly in the future.
3587 You should not take the address of values returned by the macros or
3588 functions described here. In particular, no guarantee is given that the
3591 In general, the names of macros are all in uppercase, while the names
3592 of functions are entirely in lowercase. There are rare exceptions to
3593 this rule. You should assume that any macro or function whose name is
3594 made up entirely of uppercase letters may evaluate its arguments more
3595 than once. You may assume that a macro or function whose name is made
3596 up entirely of lowercase letters will evaluate its arguments only once.
3598 The `error_mark_node' is a special tree. Its tree code is
3599 `ERROR_MARK', but since there is only ever one node with that code, the
3600 usual practice is to compare the tree against `error_mark_node'. (This
3601 test is just a test for pointer equality.) If an error has occurred
3602 during front-end processing the flag `errorcount' will be set. If the
3603 front end has encountered code it cannot handle, it will issue a
3604 message to the user and set `sorrycount'. When these flags are set,
3605 any macro or function which normally returns a tree of a particular
3606 kind may instead return the `error_mark_node'. Thus, if you intend to
3607 do any processing of erroneous code, you must be prepared to deal with
3608 the `error_mark_node'.
3610 Occasionally, a particular tree slot (like an operand to an expression,
3611 or a particular field in a declaration) will be referred to as
3612 "reserved for the back end". These slots are used to store RTL when
3613 the tree is converted to RTL for use by the GCC back end. However, if
3614 that process is not taking place (e.g., if the front end is being hooked
3615 up to an intelligent editor), then those slots may be used by the back
3616 end presently in use.
3618 If you encounter situations that do not match this documentation, such
3619 as tree nodes of types not mentioned here, or macros documented to
3620 return entities of a particular kind that instead return entities of
3621 some different kind, you have found a bug, either in the front end or in
3622 the documentation. Please report these bugs as you would any other bug.
3626 * Macros and Functions::Macros and functions that can be used with all trees.
3627 * Identifiers:: The names of things.
3628 * Containers:: Lists and vectors.
3631 File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview
3636 This section is not here yet.
3639 File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview
3644 An `IDENTIFIER_NODE' represents a slightly more general concept that
3645 the standard C or C++ concept of identifier. In particular, an
3646 `IDENTIFIER_NODE' may contain a `$', or other extraordinary characters.
3648 There are never two distinct `IDENTIFIER_NODE's representing the same
3649 identifier. Therefore, you may use pointer equality to compare
3650 `IDENTIFIER_NODE's, rather than using a routine like `strcmp'.
3652 You can use the following macros to access identifiers:
3653 `IDENTIFIER_POINTER'
3654 The string represented by the identifier, represented as a
3655 `char*'. This string is always `NUL'-terminated, and contains no
3656 embedded `NUL' characters.
3659 The length of the string returned by `IDENTIFIER_POINTER', not
3660 including the trailing `NUL'. This value of `IDENTIFIER_LENGTH
3661 (x)' is always the same as `strlen (IDENTIFIER_POINTER (x))'.
3663 `IDENTIFIER_OPNAME_P'
3664 This predicate holds if the identifier represents the name of an
3665 overloaded operator. In this case, you should not depend on the
3666 contents of either the `IDENTIFIER_POINTER' or the
3667 `IDENTIFIER_LENGTH'.
3669 `IDENTIFIER_TYPENAME_P'
3670 This predicate holds if the identifier represents the name of a
3671 user-defined conversion operator. In this case, the `TREE_TYPE' of
3672 the `IDENTIFIER_NODE' holds the type to which the conversion
3677 File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview
3682 Two common container data structures can be represented directly with
3683 tree nodes. A `TREE_LIST' is a singly linked list containing two trees
3684 per node. These are the `TREE_PURPOSE' and `TREE_VALUE' of each node.
3685 (Often, the `TREE_PURPOSE' contains some kind of tag, or additional
3686 information, while the `TREE_VALUE' contains the majority of the
3687 payload. In other cases, the `TREE_PURPOSE' is simply `NULL_TREE',
3688 while in still others both the `TREE_PURPOSE' and `TREE_VALUE' are of
3689 equal stature.) Given one `TREE_LIST' node, the next node is found by
3690 following the `TREE_CHAIN'. If the `TREE_CHAIN' is `NULL_TREE', then
3691 you have reached the end of the list.
3693 A `TREE_VEC' is a simple vector. The `TREE_VEC_LENGTH' is an integer
3694 (not a tree) giving the number of nodes in the vector. The nodes
3695 themselves are accessed using the `TREE_VEC_ELT' macro, which takes two
3696 arguments. The first is the `TREE_VEC' in question; the second is an
3697 integer indicating which element in the vector is desired. The
3698 elements are indexed from zero.
3701 File: gccint.info, Node: Types, Next: Scopes, Prev: Tree overview, Up: Trees
3706 All types have corresponding tree nodes. However, you should not assume
3707 that there is exactly one tree node corresponding to each type. There
3708 are often several nodes each of which correspond to the same type.
3710 For the most part, different kinds of types have different tree codes.
3711 (For example, pointer types use a `POINTER_TYPE' code while arrays use
3712 an `ARRAY_TYPE' code.) However, pointers to member functions use the
3713 `RECORD_TYPE' code. Therefore, when writing a `switch' statement that
3714 depends on the code associated with a particular type, you should take
3715 care to handle pointers to member functions under the `RECORD_TYPE'
3718 In C++, an array type is not qualified; rather the type of the array
3719 elements is qualified. This situation is reflected in the intermediate
3720 representation. The macros described here will always examine the
3721 qualification of the underlying element type when applied to an array
3722 type. (If the element type is itself an array, then the recursion
3723 continues until a non-array type is found, and the qualification of this
3724 type is examined.) So, for example, `CP_TYPE_CONST_P' will hold of the
3725 type `const int ()[7]', denoting an array of seven `int's.
3727 The following functions and macros deal with cv-qualification of types:
3729 This macro returns the set of type qualifiers applied to this type.
3730 This value is `TYPE_UNQUALIFIED' if no qualifiers have been
3731 applied. The `TYPE_QUAL_CONST' bit is set if the type is
3732 `const'-qualified. The `TYPE_QUAL_VOLATILE' bit is set if the
3733 type is `volatile'-qualified. The `TYPE_QUAL_RESTRICT' bit is set
3734 if the type is `restrict'-qualified.
3737 This macro holds if the type is `const'-qualified.
3739 `CP_TYPE_VOLATILE_P'
3740 This macro holds if the type is `volatile'-qualified.
3742 `CP_TYPE_RESTRICT_P'
3743 This macro holds if the type is `restrict'-qualified.
3745 `CP_TYPE_CONST_NON_VOLATILE_P'
3746 This predicate holds for a type that is `const'-qualified, but
3747 _not_ `volatile'-qualified; other cv-qualifiers are ignored as
3748 well: only the `const'-ness is tested.
3751 This macro returns the unqualified version of a type. It may be
3752 applied to an unqualified type, but it is not always the identity
3753 function in that case.
3755 A few other macros and functions are usable with all types:
3757 The number of bits required to represent the type, represented as
3758 an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be
3762 The alignment of the type, in bits, represented as an `int'.
3765 This macro returns a declaration (in the form of a `TYPE_DECL') for
3766 the type. (Note this macro does _not_ return a `IDENTIFIER_NODE',
3767 as you might expect, given its name!) You can look at the
3768 `DECL_NAME' of the `TYPE_DECL' to obtain the actual name of the
3769 type. The `TYPE_NAME' will be `NULL_TREE' for a type that is not
3770 a built-in type, the result of a typedef, or a named class type.
3773 This predicate holds if the type is an integral type. Notice that
3774 in C++, enumerations are _not_ integral types.
3777 This predicate holds if the type is an integral type (in the C++
3778 sense) or a floating point type.
3781 This predicate holds for a class-type.
3784 This predicate holds for a built-in type.
3787 This predicate holds if the type is a pointer to data member.
3790 This predicate holds if the type is a pointer type, and the
3791 pointee is not a data member.
3794 This predicate holds for a pointer to function type.
3797 This predicate holds for a pointer to object type. Note however
3798 that it does not hold for the generic pointer to object type `void
3799 *'. You may use `TYPE_PTROBV_P' to test for a pointer to object
3800 type as well as `void *'.
3803 This predicate takes two types as input, and holds if they are the
3804 same type. For example, if one type is a `typedef' for the other,
3805 or both are `typedef's for the same type. This predicate also
3806 holds if the two trees given as input are simply copies of one
3807 another; i.e., there is no difference between them at the source
3808 level, but, for whatever reason, a duplicate has been made in the
3809 representation. You should never use `==' (pointer equality) to
3810 compare types; always use `same_type_p' instead.
3812 Detailed below are the various kinds of types, and the macros that can
3813 be used to access them. Although other kinds of types are used
3814 elsewhere in G++, the types described here are the only ones that you
3815 will encounter while examining the intermediate representation.
3818 Used to represent the `void' type.
3821 Used to represent the various integral types, including `char',
3822 `short', `int', `long', and `long long'. This code is not used
3823 for enumeration types, nor for the `bool' type. Note that GCC's
3824 `CHAR_TYPE' node is _not_ used to represent `char'. The
3825 `TYPE_PRECISION' is the number of bits used in the representation,
3826 represented as an `unsigned int'. (Note that in the general case
3827 this is not the same value as `TYPE_SIZE'; suppose that there were
3828 a 24-bit integer type, but that alignment requirements for the ABI
3829 required 32-bit alignment. Then, `TYPE_SIZE' would be an
3830 `INTEGER_CST' for 32, while `TYPE_PRECISION' would be 24.) The
3831 integer type is unsigned if `TYPE_UNSIGNED' holds; otherwise, it
3834 The `TYPE_MIN_VALUE' is an `INTEGER_CST' for the smallest integer
3835 that may be represented by this type. Similarly, the
3836 `TYPE_MAX_VALUE' is an `INTEGER_CST' for the largest integer that
3837 may be represented by this type.
3840 Used to represent the `float', `double', and `long double' types.
3841 The number of bits in the floating-point representation is given
3842 by `TYPE_PRECISION', as in the `INTEGER_TYPE' case.
3845 Used to represent GCC built-in `__complex__' data types. The
3846 `TREE_TYPE' is the type of the real and imaginary parts.
3849 Used to represent an enumeration type. The `TYPE_PRECISION' gives
3850 (as an `int'), the number of bits used to represent the type. If
3851 there are no negative enumeration constants, `TYPE_UNSIGNED' will
3852 hold. The minimum and maximum enumeration constants may be
3853 obtained with `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE', respectively;
3854 each of these macros returns an `INTEGER_CST'.
3856 The actual enumeration constants themselves may be obtained by
3857 looking at the `TYPE_VALUES'. This macro will return a
3858 `TREE_LIST', containing the constants. The `TREE_PURPOSE' of each
3859 node will be an `IDENTIFIER_NODE' giving the name of the constant;
3860 the `TREE_VALUE' will be an `INTEGER_CST' giving the value
3861 assigned to that constant. These constants will appear in the
3862 order in which they were declared. The `TREE_TYPE' of each of
3863 these constants will be the type of enumeration type itself.
3866 Used to represent the `bool' type.
3869 Used to represent pointer types, and pointer to data member types.
3870 The `TREE_TYPE' gives the type to which this type points. If the
3871 type is a pointer to data member type, then `TYPE_PTRMEM_P' will
3872 hold. For a pointer to data member type of the form `T X::*',
3873 `TYPE_PTRMEM_CLASS_TYPE' will be the type `X', while
3874 `TYPE_PTRMEM_POINTED_TO_TYPE' will be the type `T'.
3877 Used to represent reference types. The `TREE_TYPE' gives the type
3878 to which this type refers.
3881 Used to represent the type of non-member functions and of static
3882 member functions. The `TREE_TYPE' gives the return type of the
3883 function. The `TYPE_ARG_TYPES' are a `TREE_LIST' of the argument
3884 types. The `TREE_VALUE' of each node in this list is the type of
3885 the corresponding argument; the `TREE_PURPOSE' is an expression
3886 for the default argument value, if any. If the last node in the
3887 list is `void_list_node' (a `TREE_LIST' node whose `TREE_VALUE' is
3888 the `void_type_node'), then functions of this type do not take
3889 variable arguments. Otherwise, they do take a variable number of
3892 Note that in C (but not in C++) a function declared like `void f()'
3893 is an unprototyped function taking a variable number of arguments;
3894 the `TYPE_ARG_TYPES' of such a function will be `NULL'.
3897 Used to represent the type of a non-static member function. Like a
3898 `FUNCTION_TYPE', the return type is given by the `TREE_TYPE'. The
3899 type of `*this', i.e., the class of which functions of this type
3900 are a member, is given by the `TYPE_METHOD_BASETYPE'. The
3901 `TYPE_ARG_TYPES' is the parameter list, as for a `FUNCTION_TYPE',
3902 and includes the `this' argument.
3905 Used to represent array types. The `TREE_TYPE' gives the type of
3906 the elements in the array. If the array-bound is present in the
3907 type, the `TYPE_DOMAIN' is an `INTEGER_TYPE' whose
3908 `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE' will be the lower and upper
3909 bounds of the array, respectively. The `TYPE_MIN_VALUE' will
3910 always be an `INTEGER_CST' for zero, while the `TYPE_MAX_VALUE'
3911 will be one less than the number of elements in the array, i.e.,
3912 the highest value which may be used to index an element in the
3916 Used to represent `struct' and `class' types, as well as pointers
3917 to member functions and similar constructs in other languages.
3918 `TYPE_FIELDS' contains the items contained in this type, each of
3919 which can be a `FIELD_DECL', `VAR_DECL', `CONST_DECL', or
3920 `TYPE_DECL'. You may not make any assumptions about the ordering
3921 of the fields in the type or whether one or more of them overlap.
3922 If `TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member
3923 type. In that case, the `TYPE_PTRMEMFUNC_FN_TYPE' is a
3924 `POINTER_TYPE' pointing to a `METHOD_TYPE'. The `METHOD_TYPE' is
3925 the type of a function pointed to by the pointer-to-member
3926 function. If `TYPE_PTRMEMFUNC_P' does not hold, this type is a
3927 class type. For more information, see *note Classes::.
3930 Used to represent `union' types. Similar to `RECORD_TYPE' except
3931 that all `FIELD_DECL' nodes in `TYPE_FIELD' start at bit position
3935 Used to represent part of a variant record in Ada. Similar to
3936 `UNION_TYPE' except that each `FIELD_DECL' has a `DECL_QUALIFIER'
3937 field, which contains a boolean expression that indicates whether
3938 the field is present in the object. The type will only have one
3939 field, so each field's `DECL_QUALIFIER' is only evaluated if none
3940 of the expressions in the previous fields in `TYPE_FIELDS' are
3941 nonzero. Normally these expressions will reference a field in the
3942 outer object using a `PLACEHOLDER_EXPR'.
3945 This node is used to represent a type the knowledge of which is
3946 insufficient for a sound processing.
3949 This node is used to represent a pointer-to-data member. For a
3950 data member `X::m' the `TYPE_OFFSET_BASETYPE' is `X' and the
3951 `TREE_TYPE' is the type of `m'.
3954 Used to represent a construct of the form `typename T::A'. The
3955 `TYPE_CONTEXT' is `T'; the `TYPE_NAME' is an `IDENTIFIER_NODE' for
3956 `A'. If the type is specified via a template-id, then
3957 `TYPENAME_TYPE_FULLNAME' yields a `TEMPLATE_ID_EXPR'. The
3958 `TREE_TYPE' is non-`NULL' if the node is implicitly generated in
3959 support for the implicit typename extension; in which case the
3960 `TREE_TYPE' is a type node for the base-class.
3963 Used to represent the `__typeof__' extension. The `TYPE_FIELDS'
3964 is the expression the type of which is being represented.
3966 There are variables whose values represent some of the basic types.
3974 `unsigned_type_node.'
3975 A node for `unsigned int'.
3979 It may sometimes be useful to compare one of these variables with a
3980 type in hand, using `same_type_p'.
3983 File: gccint.info, Node: Scopes, Next: Functions, Prev: Types, Up: Trees
3988 The root of the entire intermediate representation is the variable
3989 `global_namespace'. This is the namespace specified with `::' in C++
3990 source code. All other namespaces, types, variables, functions, and so
3991 forth can be found starting with this namespace.
3993 Besides namespaces, the other high-level scoping construct in C++ is
3994 the class. (Throughout this manual the term "class" is used to mean the
3995 types referred to in the ANSI/ISO C++ Standard as classes; these include
3996 types defined with the `class', `struct', and `union' keywords.)
4000 * Namespaces:: Member functions, types, etc.
4001 * Classes:: Members, bases, friends, etc.
4004 File: gccint.info, Node: Namespaces, Next: Classes, Up: Scopes
4009 A namespace is represented by a `NAMESPACE_DECL' node.
4011 However, except for the fact that it is distinguished as the root of
4012 the representation, the global namespace is no different from any other
4013 namespace. Thus, in what follows, we describe namespaces generally,
4014 rather than the global namespace in particular.
4016 The following macros and functions can be used on a `NAMESPACE_DECL':
4019 This macro is used to obtain the `IDENTIFIER_NODE' corresponding to
4020 the unqualified name of the name of the namespace (*note
4021 Identifiers::). The name of the global namespace is `::', even
4022 though in C++ the global namespace is unnamed. However, you
4023 should use comparison with `global_namespace', rather than
4024 `DECL_NAME' to determine whether or not a namespace is the global
4025 one. An unnamed namespace will have a `DECL_NAME' equal to
4026 `anonymous_namespace_name'. Within a single translation unit, all
4027 unnamed namespaces will have the same name.
4030 This macro returns the enclosing namespace. The `DECL_CONTEXT' for
4031 the `global_namespace' is `NULL_TREE'.
4033 `DECL_NAMESPACE_ALIAS'
4034 If this declaration is for a namespace alias, then
4035 `DECL_NAMESPACE_ALIAS' is the namespace for which this one is an
4038 Do not attempt to use `cp_namespace_decls' for a namespace which is
4039 an alias. Instead, follow `DECL_NAMESPACE_ALIAS' links until you
4040 reach an ordinary, non-alias, namespace, and call
4041 `cp_namespace_decls' there.
4043 `DECL_NAMESPACE_STD_P'
4044 This predicate holds if the namespace is the special `::std'
4047 `cp_namespace_decls'
4048 This function will return the declarations contained in the
4049 namespace, including types, overloaded functions, other
4050 namespaces, and so forth. If there are no declarations, this
4051 function will return `NULL_TREE'. The declarations are connected
4052 through their `TREE_CHAIN' fields.
4054 Although most entries on this list will be declarations,
4055 `TREE_LIST' nodes may also appear. In this case, the `TREE_VALUE'
4056 will be an `OVERLOAD'. The value of the `TREE_PURPOSE' is
4057 unspecified; back ends should ignore this value. As with the
4058 other kinds of declarations returned by `cp_namespace_decls', the
4059 `TREE_CHAIN' will point to the next declaration in this list.
4061 For more information on the kinds of declarations that can occur
4062 on this list, *Note Declarations::. Some declarations will not
4063 appear on this list. In particular, no `FIELD_DECL',
4064 `LABEL_DECL', or `PARM_DECL' nodes will appear here.
4066 This function cannot be used with namespaces that have
4067 `DECL_NAMESPACE_ALIAS' set.
4071 File: gccint.info, Node: Classes, Prev: Namespaces, Up: Scopes
4076 A class type is represented by either a `RECORD_TYPE' or a
4077 `UNION_TYPE'. A class declared with the `union' tag is represented by
4078 a `UNION_TYPE', while classes declared with either the `struct' or the
4079 `class' tag are represented by `RECORD_TYPE's. You can use the
4080 `CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular
4081 type is a `class' as opposed to a `struct'. This macro will be true
4082 only for classes declared with the `class' tag.
4084 Almost all non-function members are available on the `TYPE_FIELDS'
4085 list. Given one member, the next can be found by following the
4086 `TREE_CHAIN'. You should not depend in any way on the order in which
4087 fields appear on this list. All nodes on this list will be `DECL'
4088 nodes. A `FIELD_DECL' is used to represent a non-static data member, a
4089 `VAR_DECL' is used to represent a static data member, and a `TYPE_DECL'
4090 is used to represent a type. Note that the `CONST_DECL' for an
4091 enumeration constant will appear on this list, if the enumeration type
4092 was declared in the class. (Of course, the `TYPE_DECL' for the
4093 enumeration type will appear here as well.) There are no entries for
4094 base classes on this list. In particular, there is no `FIELD_DECL' for
4095 the "base-class portion" of an object.
4097 The `TYPE_VFIELD' is a compiler-generated field used to point to
4098 virtual function tables. It may or may not appear on the `TYPE_FIELDS'
4099 list. However, back ends should handle the `TYPE_VFIELD' just like all
4100 the entries on the `TYPE_FIELDS' list.
4102 The function members are available on the `TYPE_METHODS' list. Again,
4103 subsequent members are found by following the `TREE_CHAIN' field. If a
4104 function is overloaded, each of the overloaded functions appears; no
4105 `OVERLOAD' nodes appear on the `TYPE_METHODS' list. Implicitly
4106 declared functions (including default constructors, copy constructors,
4107 assignment operators, and destructors) will appear on this list as well.
4109 Every class has an associated "binfo", which can be obtained with
4110 `TYPE_BINFO'. Binfos are used to represent base-classes. The binfo
4111 given by `TYPE_BINFO' is the degenerate case, whereby every class is
4112 considered to be its own base-class. The base binfos for a particular
4113 binfo are held in a vector, whose length is obtained with
4114 `BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with
4115 `BINFO_BASE_BINFO' and `BINFO_BASE_ITERATE'. To add a new binfo, use
4116 `BINFO_BASE_APPEND'. The vector of base binfos can be obtained with
4117 `BINFO_BASE_BINFOS', but normally you do not need to use that. The
4118 class type associated with a binfo is given by `BINFO_TYPE'. It is not
4119 always the case that `BINFO_TYPE (TYPE_BINFO (x))', because of typedefs
4120 and qualified types. Neither is it the case that `TYPE_BINFO
4121 (BINFO_TYPE (y))' is the same binfo as `y'. The reason is that if `y'
4122 is a binfo representing a base-class `B' of a derived class `D', then
4123 `BINFO_TYPE (y)' will be `B', and `TYPE_BINFO (BINFO_TYPE (y))' will be
4124 `B' as its own base-class, rather than as a base-class of `D'.
4126 The access to a base type can be found with `BINFO_BASE_ACCESS'. This
4127 will produce `access_public_node', `access_private_node' or
4128 `access_protected_node'. If bases are always public,
4129 `BINFO_BASE_ACCESSES' may be `NULL'.
4131 `BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited
4132 virtually or not. The other flags, `BINFO_MARKED_P' and `BINFO_FLAG_1'
4133 to `BINFO_FLAG_6' can be used for language specific use.
4135 The following macros can be used on a tree node representing a
4139 This predicate holds if the class is local class _i.e._ declared
4140 inside a function body.
4142 `TYPE_POLYMORPHIC_P'
4143 This predicate holds if the class has at least one virtual function
4144 (declared or inherited).
4146 `TYPE_HAS_DEFAULT_CONSTRUCTOR'
4147 This predicate holds whenever its argument represents a class-type
4148 with default constructor.
4150 `CLASSTYPE_HAS_MUTABLE'
4151 `TYPE_HAS_MUTABLE_P'
4152 These predicates hold for a class-type having a mutable data
4155 `CLASSTYPE_NON_POD_P'
4156 This predicate holds only for class-types that are not PODs.
4158 `TYPE_HAS_NEW_OPERATOR'
4159 This predicate holds for a class-type that defines `operator new'.
4161 `TYPE_HAS_ARRAY_NEW_OPERATOR'
4162 This predicate holds for a class-type for which `operator new[]'
4165 `TYPE_OVERLOADS_CALL_EXPR'
4166 This predicate holds for class-type for which the function call
4167 `operator()' is overloaded.
4169 `TYPE_OVERLOADS_ARRAY_REF'
4170 This predicate holds for a class-type that overloads `operator[]'
4172 `TYPE_OVERLOADS_ARROW'
4173 This predicate holds for a class-type for which `operator->' is
4178 File: gccint.info, Node: Declarations, Next: Attributes, Prev: Functions, Up: Trees
4183 This section covers the various kinds of declarations that appear in the
4184 internal representation, except for declarations of functions
4185 (represented by `FUNCTION_DECL' nodes), which are described in *Note
4190 * Working with declarations:: Macros and functions that work on
4192 * Internal structure:: How declaration nodes are represented.
4195 File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations
4197 9.5.1 Working with declarations
4198 -------------------------------
4200 Some macros can be used with any kind of declaration. These include:
4202 This macro returns an `IDENTIFIER_NODE' giving the name of the
4206 This macro returns the type of the entity declared.
4209 This macro returns the name of the file in which the entity was
4210 declared, as a `char*'. For an entity declared implicitly by the
4211 compiler (like `__builtin_memcpy'), this will be the string
4215 This macro returns the line number at which the entity was
4216 declared, as an `int'.
4219 This predicate holds if the declaration was implicitly generated
4220 by the compiler. For example, this predicate will hold of an
4221 implicitly declared member function, or of the `TYPE_DECL'
4222 implicitly generated for a class type. Recall that in C++ code
4225 is roughly equivalent to C code like:
4228 The implicitly generated `typedef' declaration is represented by a
4229 `TYPE_DECL' for which `DECL_ARTIFICIAL' holds.
4231 `DECL_NAMESPACE_SCOPE_P'
4232 This predicate holds if the entity was declared at a namespace
4235 `DECL_CLASS_SCOPE_P'
4236 This predicate holds if the entity was declared at a class scope.
4238 `DECL_FUNCTION_SCOPE_P'
4239 This predicate holds if the entity was declared inside a function
4243 The various kinds of declarations include:
4245 These nodes are used to represent labels in function bodies. For
4246 more information, see *Note Functions::. These nodes only appear
4250 These nodes are used to represent enumeration constants. The
4251 value of the constant is given by `DECL_INITIAL' which will be an
4252 `INTEGER_CST' with the same type as the `TREE_TYPE' of the
4253 `CONST_DECL', i.e., an `ENUMERAL_TYPE'.
4256 These nodes represent the value returned by a function. When a
4257 value is assigned to a `RESULT_DECL', that indicates that the
4258 value should be returned, via bitwise copy, by the function. You
4259 can use `DECL_SIZE' and `DECL_ALIGN' on a `RESULT_DECL', just as
4263 These nodes represent `typedef' declarations. The `TREE_TYPE' is
4264 the type declared to have the name given by `DECL_NAME'. In some
4265 cases, there is no associated name.
4268 These nodes represent variables with namespace or block scope, as
4269 well as static data members. The `DECL_SIZE' and `DECL_ALIGN' are
4270 analogous to `TYPE_SIZE' and `TYPE_ALIGN'. For a declaration, you
4271 should always use the `DECL_SIZE' and `DECL_ALIGN' rather than the
4272 `TYPE_SIZE' and `TYPE_ALIGN' given by the `TREE_TYPE', since
4273 special attributes may have been applied to the variable to give
4274 it a particular size and alignment. You may use the predicates
4275 `DECL_THIS_STATIC' or `DECL_THIS_EXTERN' to test whether the
4276 storage class specifiers `static' or `extern' were used to declare
4279 If this variable is initialized (but does not require a
4280 constructor), the `DECL_INITIAL' will be an expression for the
4281 initializer. The initializer should be evaluated, and a bitwise
4282 copy into the variable performed. If the `DECL_INITIAL' is the
4283 `error_mark_node', there is an initializer, but it is given by an
4284 explicit statement later in the code; no bitwise copy is required.
4286 GCC provides an extension that allows either automatic variables,
4287 or global variables, to be placed in particular registers. This
4288 extension is being used for a particular `VAR_DECL' if
4289 `DECL_REGISTER' holds for the `VAR_DECL', and if
4290 `DECL_ASSEMBLER_NAME' is not equal to `DECL_NAME'. In that case,
4291 `DECL_ASSEMBLER_NAME' is the name of the register into which the
4292 variable will be placed.
4295 Used to represent a parameter to a function. Treat these nodes
4296 similarly to `VAR_DECL' nodes. These nodes only appear in the
4297 `DECL_ARGUMENTS' for a `FUNCTION_DECL'.
4299 The `DECL_ARG_TYPE' for a `PARM_DECL' is the type that will
4300 actually be used when a value is passed to this function. It may
4301 be a wider type than the `TREE_TYPE' of the parameter; for
4302 example, the ordinary type might be `short' while the
4303 `DECL_ARG_TYPE' is `int'.
4306 These nodes represent non-static data members. The `DECL_SIZE' and
4307 `DECL_ALIGN' behave as for `VAR_DECL' nodes. The
4308 `DECL_FIELD_BITPOS' gives the first bit used for this field, as an
4309 `INTEGER_CST'. These values are indexed from zero, where zero
4310 indicates the first bit in the object.
4312 If `DECL_C_BIT_FIELD' holds, this field is a bit-field.
4318 These nodes are used to represent class, function, and variable
4319 (static data member) templates. The
4320 `DECL_TEMPLATE_SPECIALIZATIONS' are a `TREE_LIST'. The
4321 `TREE_VALUE' of each node in the list is a `TEMPLATE_DECL's or
4322 `FUNCTION_DECL's representing specializations (including
4323 instantiations) of this template. Back ends can safely ignore
4324 `TEMPLATE_DECL's, but should examine `FUNCTION_DECL' nodes on the
4325 specializations list just as they would ordinary `FUNCTION_DECL'
4328 For a class template, the `DECL_TEMPLATE_INSTANTIATIONS' list
4329 contains the instantiations. The `TREE_VALUE' of each node is an
4330 instantiation of the class. The `DECL_TEMPLATE_SPECIALIZATIONS'
4331 contains partial specializations of the class.
4334 Back ends can safely ignore these nodes.
4338 File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations
4340 9.5.2 Internal structure
4341 ------------------------
4343 `DECL' nodes are represented internally as a hierarchy of structures.
4347 * Current structure hierarchy:: The current DECL node structure
4349 * Adding new DECL node types:: How to add a new DECL node to a
4353 File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure
4355 9.5.2.1 Current structure hierarchy
4356 ...................................
4358 `struct tree_decl_minimal'
4359 This is the minimal structure to inherit from in order for common
4360 `DECL' macros to work. The fields it contains are a unique ID,
4361 source location, context, and name.
4363 `struct tree_decl_common'
4364 This structure inherits from `struct tree_decl_minimal'. It
4365 contains fields that most `DECL' nodes need, such as a field to
4366 store alignment, machine mode, size, and attributes.
4368 `struct tree_field_decl'
4369 This structure inherits from `struct tree_decl_common'. It is
4370 used to represent `FIELD_DECL'.
4372 `struct tree_label_decl'
4373 This structure inherits from `struct tree_decl_common'. It is
4374 used to represent `LABEL_DECL'.
4376 `struct tree_translation_unit_decl'
4377 This structure inherits from `struct tree_decl_common'. It is
4378 used to represent `TRANSLATION_UNIT_DECL'.
4380 `struct tree_decl_with_rtl'
4381 This structure inherits from `struct tree_decl_common'. It
4382 contains a field to store the low-level RTL associated with a
4385 `struct tree_result_decl'
4386 This structure inherits from `struct tree_decl_with_rtl'. It is
4387 used to represent `RESULT_DECL'.
4389 `struct tree_const_decl'
4390 This structure inherits from `struct tree_decl_with_rtl'. It is
4391 used to represent `CONST_DECL'.
4393 `struct tree_parm_decl'
4394 This structure inherits from `struct tree_decl_with_rtl'. It is
4395 used to represent `PARM_DECL'.
4397 `struct tree_decl_with_vis'
4398 This structure inherits from `struct tree_decl_with_rtl'. It
4399 contains fields necessary to store visibility information, as well
4400 as a section name and assembler name.
4402 `struct tree_var_decl'
4403 This structure inherits from `struct tree_decl_with_vis'. It is
4404 used to represent `VAR_DECL'.
4406 `struct tree_function_decl'
4407 This structure inherits from `struct tree_decl_with_vis'. It is
4408 used to represent `FUNCTION_DECL'.
4412 File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure
4414 9.5.2.2 Adding new DECL node types
4415 ..................................
4417 Adding a new `DECL' tree consists of the following steps
4419 Add a new tree code for the `DECL' node
4420 For language specific `DECL' nodes, there is a `.def' file in each
4421 frontend directory where the tree code should be added. For
4422 `DECL' nodes that are part of the middle-end, the code should be
4423 added to `tree.def'.
4425 Create a new structure type for the `DECL' node
4426 These structures should inherit from one of the existing
4427 structures in the language hierarchy by using that structure as
4430 struct tree_foo_decl
4432 struct tree_decl_with_vis common;
4435 Would create a structure name `tree_foo_decl' that inherits from
4436 `struct tree_decl_with_vis'.
4438 For language specific `DECL' nodes, this new structure type should
4439 go in the appropriate `.h' file. For `DECL' nodes that are part
4440 of the middle-end, the structure type should go in `tree.h'.
4442 Add a member to the tree structure enumerator for the node
4443 For garbage collection and dynamic checking purposes, each `DECL'
4444 node structure type is required to have a unique enumerator value
4445 specified with it. For language specific `DECL' nodes, this new
4446 enumerator value should go in the appropriate `.def' file. For
4447 `DECL' nodes that are part of the middle-end, the enumerator
4448 values are specified in `treestruct.def'.
4450 Update `union tree_node'
4451 In order to make your new structure type usable, it must be added
4452 to `union tree_node'. For language specific `DECL' nodes, a new
4453 entry should be added to the appropriate `.h' file of the form
4454 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl;
4455 For `DECL' nodes that are part of the middle-end, the additional
4456 member goes directly into `union tree_node' in `tree.h'.
4458 Update dynamic checking info
4459 In order to be able to check whether accessing a named portion of
4460 `union tree_node' is legal, and whether a certain `DECL' node
4461 contains one of the enumerated `DECL' node structures in the
4462 hierarchy, a simple lookup table is used. This lookup table needs
4463 to be kept up to date with the tree structure hierarchy, or else
4464 checking and containment macros will fail inappropriately.
4466 For language specific `DECL' nodes, their is an `init_ts' function
4467 in an appropriate `.c' file, which initializes the lookup table.
4468 Code setting up the table for new `DECL' nodes should be added
4469 there. For each `DECL' tree code and enumerator value
4470 representing a member of the inheritance hierarchy, the table
4471 should contain 1 if that tree code inherits (directly or
4472 indirectly) from that member. Thus, a `FOO_DECL' node derived
4473 from `struct decl_with_rtl', and enumerator value `TS_FOO_DECL',
4474 would be set up as follows
4475 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1;
4476 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1;
4477 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1;
4478 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1;
4480 For `DECL' nodes that are part of the middle-end, the setup code
4483 Add macros to access any new fields and flags
4484 Each added field or flag should have a macro that is used to access
4485 it, that performs appropriate checking to ensure only the right
4486 type of `DECL' nodes access the field.
4488 These macros generally take the following form
4489 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname
4490 However, if the structure is simply a base class for further
4491 structures, something like the following should be used
4492 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT)
4493 #define BASE_STRUCT_FIELDNAME(NODE) \
4494 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname
4498 File: gccint.info, Node: Functions, Next: Declarations, Prev: Scopes, Up: Trees
4503 A function is represented by a `FUNCTION_DECL' node. A set of
4504 overloaded functions is sometimes represented by a `OVERLOAD' node.
4506 An `OVERLOAD' node is not a declaration, so none of the `DECL_' macros
4507 should be used on an `OVERLOAD'. An `OVERLOAD' node is similar to a
4508 `TREE_LIST'. Use `OVL_CURRENT' to get the function associated with an
4509 `OVERLOAD' node; use `OVL_NEXT' to get the next `OVERLOAD' node in the
4510 list of overloaded functions. The macros `OVL_CURRENT' and `OVL_NEXT'
4511 are actually polymorphic; you can use them to work with `FUNCTION_DECL'
4512 nodes as well as with overloads. In the case of a `FUNCTION_DECL',
4513 `OVL_CURRENT' will always return the function itself, and `OVL_NEXT'
4514 will always be `NULL_TREE'.
4516 To determine the scope of a function, you can use the `DECL_CONTEXT'
4517 macro. This macro will return the class (either a `RECORD_TYPE' or a
4518 `UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function
4519 is a member. For a virtual function, this macro returns the class in
4520 which the function was actually defined, not the base class in which
4521 the virtual declaration occurred.
4523 If a friend function is defined in a class scope, the
4524 `DECL_FRIEND_CONTEXT' macro can be used to determine the class in which
4525 it was defined. For example, in
4526 class C { friend void f() {} };
4527 the `DECL_CONTEXT' for `f' will be the `global_namespace', but the
4528 `DECL_FRIEND_CONTEXT' will be the `RECORD_TYPE' for `C'.
4530 In C, the `DECL_CONTEXT' for a function maybe another function. This
4531 representation indicates that the GNU nested function extension is in
4532 use. For details on the semantics of nested functions, see the GCC
4533 Manual. The nested function can refer to local variables in its
4534 containing function. Such references are not explicitly marked in the
4535 tree structure; back ends must look at the `DECL_CONTEXT' for the
4536 referenced `VAR_DECL'. If the `DECL_CONTEXT' for the referenced
4537 `VAR_DECL' is not the same as the function currently being processed,
4538 and neither `DECL_EXTERNAL' nor `DECL_STATIC' hold, then the reference
4539 is to a local variable in a containing function, and the back end must
4540 take appropriate action.
4544 * Function Basics:: Function names, linkage, and so forth.
4545 * Function Bodies:: The statements that make up a function body.
4548 File: gccint.info, Node: Function Basics, Next: Function Bodies, Up: Functions
4550 9.6.1 Function Basics
4551 ---------------------
4553 The following macros and functions can be used on a `FUNCTION_DECL':
4555 This predicate holds for a function that is the program entry point
4559 This macro returns the unqualified name of the function, as an
4560 `IDENTIFIER_NODE'. For an instantiation of a function template,
4561 the `DECL_NAME' is the unqualified name of the template, not
4562 something like `f<int>'. The value of `DECL_NAME' is undefined
4563 when used on a constructor, destructor, overloaded operator, or
4564 type-conversion operator, or any function that is implicitly
4565 generated by the compiler. See below for macros that can be used
4566 to distinguish these cases.
4568 `DECL_ASSEMBLER_NAME'
4569 This macro returns the mangled name of the function, also an
4570 `IDENTIFIER_NODE'. This name does not contain leading underscores
4571 on systems that prefix all identifiers with underscores. The
4572 mangled name is computed in the same way on all platforms; if
4573 special processing is required to deal with the object file format
4574 used on a particular platform, it is the responsibility of the
4575 back end to perform those modifications. (Of course, the back end
4576 should not modify `DECL_ASSEMBLER_NAME' itself.)
4578 Using `DECL_ASSEMBLER_NAME' will cause additional memory to be
4579 allocated (for the mangled name of the entity) so it should be used
4580 only when emitting assembly code. It should not be used within the
4581 optimizers to determine whether or not two declarations are the
4582 same, even though some of the existing optimizers do use it in
4583 that way. These uses will be removed over time.
4586 This predicate holds if the function is undefined.
4589 This predicate holds if the function has external linkage.
4591 `DECL_LOCAL_FUNCTION_P'
4592 This predicate holds if the function was declared at block scope,
4593 even though it has a global scope.
4596 This predicate holds if the function is a built-in function but its
4597 prototype is not yet explicitly declared.
4599 `DECL_EXTERN_C_FUNCTION_P'
4600 This predicate holds if the function is declared as an ``extern
4604 This macro holds if multiple copies of this function may be
4605 emitted in various translation units. It is the responsibility of
4606 the linker to merge the various copies. Template instantiations
4607 are the most common example of functions for which
4608 `DECL_LINKONCE_P' holds; G++ instantiates needed templates in all
4609 translation units which require them, and then relies on the
4610 linker to remove duplicate instantiations.
4612 FIXME: This macro is not yet implemented.
4614 `DECL_FUNCTION_MEMBER_P'
4615 This macro holds if the function is a member of a class, rather
4616 than a member of a namespace.
4618 `DECL_STATIC_FUNCTION_P'
4619 This predicate holds if the function a static member function.
4621 `DECL_NONSTATIC_MEMBER_FUNCTION_P'
4622 This macro holds for a non-static member function.
4624 `DECL_CONST_MEMFUNC_P'
4625 This predicate holds for a `const'-member function.
4627 `DECL_VOLATILE_MEMFUNC_P'
4628 This predicate holds for a `volatile'-member function.
4630 `DECL_CONSTRUCTOR_P'
4631 This macro holds if the function is a constructor.
4633 `DECL_NONCONVERTING_P'
4634 This predicate holds if the constructor is a non-converting
4637 `DECL_COMPLETE_CONSTRUCTOR_P'
4638 This predicate holds for a function which is a constructor for an
4639 object of a complete type.
4641 `DECL_BASE_CONSTRUCTOR_P'
4642 This predicate holds for a function which is a constructor for a
4643 base class sub-object.
4645 `DECL_COPY_CONSTRUCTOR_P'
4646 This predicate holds for a function which is a copy-constructor.
4649 This macro holds if the function is a destructor.
4651 `DECL_COMPLETE_DESTRUCTOR_P'
4652 This predicate holds if the function is the destructor for an
4653 object a complete type.
4655 `DECL_OVERLOADED_OPERATOR_P'
4656 This macro holds if the function is an overloaded operator.
4659 This macro holds if the function is a type-conversion operator.
4661 `DECL_GLOBAL_CTOR_P'
4662 This predicate holds if the function is a file-scope initialization
4665 `DECL_GLOBAL_DTOR_P'
4666 This predicate holds if the function is a file-scope finalization
4670 This predicate holds if the function is a thunk.
4672 These functions represent stub code that adjusts the `this' pointer
4673 and then jumps to another function. When the jumped-to function
4674 returns, control is transferred directly to the caller, without
4675 returning to the thunk. The first parameter to the thunk is
4676 always the `this' pointer; the thunk should add `THUNK_DELTA' to
4677 this value. (The `THUNK_DELTA' is an `int', not an `INTEGER_CST'.)
4679 Then, if `THUNK_VCALL_OFFSET' (an `INTEGER_CST') is nonzero the
4680 adjusted `this' pointer must be adjusted again. The complete
4681 calculation is given by the following pseudo-code:
4684 if (THUNK_VCALL_OFFSET)
4685 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET]
4687 Finally, the thunk should jump to the location given by
4688 `DECL_INITIAL'; this will always be an expression for the address
4691 `DECL_NON_THUNK_FUNCTION_P'
4692 This predicate holds if the function is _not_ a thunk function.
4694 `GLOBAL_INIT_PRIORITY'
4695 If either `DECL_GLOBAL_CTOR_P' or `DECL_GLOBAL_DTOR_P' holds, then
4696 this gives the initialization priority for the function. The
4697 linker will arrange that all functions for which
4698 `DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority
4699 before `main' is called. When the program exits, all functions for
4700 which `DECL_GLOBAL_DTOR_P' holds are run in the reverse order.
4703 This macro holds if the function was implicitly generated by the
4704 compiler, rather than explicitly declared. In addition to
4705 implicitly generated class member functions, this macro holds for
4706 the special functions created to implement static initialization
4707 and destruction, to compute run-time type information, and so
4711 This macro returns the `PARM_DECL' for the first argument to the
4712 function. Subsequent `PARM_DECL' nodes can be obtained by
4713 following the `TREE_CHAIN' links.
4716 This macro returns the `RESULT_DECL' for the function.
4719 This macro returns the `FUNCTION_TYPE' or `METHOD_TYPE' for the
4722 `TYPE_RAISES_EXCEPTIONS'
4723 This macro returns the list of exceptions that a (member-)function
4724 can raise. The returned list, if non `NULL', is comprised of nodes
4725 whose `TREE_VALUE' represents a type.
4728 This predicate holds when the exception-specification of its
4729 arguments if of the form ``()''.
4731 `DECL_ARRAY_DELETE_OPERATOR_P'
4732 This predicate holds if the function an overloaded `operator
4737 File: gccint.info, Node: Function Bodies, Prev: Function Basics, Up: Functions
4739 9.6.2 Function Bodies
4740 ---------------------
4742 A function that has a definition in the current translation unit will
4743 have a non-`NULL' `DECL_INITIAL'. However, back ends should not make
4744 use of the particular value given by `DECL_INITIAL'.
4746 The `DECL_SAVED_TREE' macro will give the complete body of the
4752 There are tree nodes corresponding to all of the source-level statement
4753 constructs, used within the C and C++ frontends. These are enumerated
4754 here, together with a list of the various macros that can be used to
4755 obtain information about them. There are a few macros that can be used
4756 with all statements:
4758 `STMT_IS_FULL_EXPR_P'
4759 In C++, statements normally constitute "full expressions";
4760 temporaries created during a statement are destroyed when the
4761 statement is complete. However, G++ sometimes represents
4762 expressions by statements; these statements will not have
4763 `STMT_IS_FULL_EXPR_P' set. Temporaries created during such
4764 statements should be destroyed when the innermost enclosing
4765 statement with `STMT_IS_FULL_EXPR_P' set is exited.
4768 Here is the list of the various statement nodes, and the macros used to
4769 access them. This documentation describes the use of these nodes in
4770 non-template functions (including instantiations of template functions).
4771 In template functions, the same nodes are used, but sometimes in
4772 slightly different ways.
4774 Many of the statements have substatements. For example, a `while'
4775 loop will have a body, which is itself a statement. If the substatement
4776 is `NULL_TREE', it is considered equivalent to a statement consisting
4777 of a single `;', i.e., an expression statement in which the expression
4778 has been omitted. A substatement may in fact be a list of statements,
4779 connected via their `TREE_CHAIN's. So, you should always process the
4780 statement tree by looping over substatements, like this:
4781 void process_stmt (stmt)
4786 switch (TREE_CODE (stmt))
4789 process_stmt (THEN_CLAUSE (stmt));
4790 /* More processing here. */
4796 stmt = TREE_CHAIN (stmt);
4799 In other words, while the `then' clause of an `if' statement in C++
4800 can be only one statement (although that one statement may be a
4801 compound statement), the intermediate representation will sometimes use
4802 several statements chained together.
4805 Used to represent an inline assembly statement. For an inline
4806 assembly statement like:
4808 The `ASM_STRING' macro will return a `STRING_CST' node for `"mov
4809 x, y"'. If the original statement made use of the
4810 extended-assembly syntax, then `ASM_OUTPUTS', `ASM_INPUTS', and
4811 `ASM_CLOBBERS' will be the outputs, inputs, and clobbers for the
4812 statement, represented as `STRING_CST' nodes. The
4813 extended-assembly syntax looks like:
4814 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
4815 The first string is the `ASM_STRING', containing the instruction
4816 template. The next two strings are the output and inputs,
4817 respectively; this statement has no clobbers. As this example
4818 indicates, "plain" assembly statements are merely a special case
4819 of extended assembly statements; they have no cv-qualifiers,
4820 outputs, inputs, or clobbers. All of the strings will be
4821 `NUL'-terminated, and will contain no embedded `NUL'-characters.
4823 If the assembly statement is declared `volatile', or if the
4824 statement was not an extended assembly statement, and is therefore
4825 implicitly volatile, then the predicate `ASM_VOLATILE_P' will hold
4829 Used to represent a `break' statement. There are no additional
4833 Use to represent a `case' label, range of `case' labels, or a
4834 `default' label. If `CASE_LOW' is `NULL_TREE', then this is a
4835 `default' label. Otherwise, if `CASE_HIGH' is `NULL_TREE', then
4836 this is an ordinary `case' label. In this case, `CASE_LOW' is an
4837 expression giving the value of the label. Both `CASE_LOW' and
4838 `CASE_HIGH' are `INTEGER_CST' nodes. These values will have the
4839 same type as the condition expression in the switch statement.
4841 Otherwise, if both `CASE_LOW' and `CASE_HIGH' are defined, the
4842 statement is a range of case labels. Such statements originate
4843 with the extension that allows users to write things of the form:
4845 The first value will be `CASE_LOW', while the second will be
4849 Used to represent an action that should take place upon exit from
4850 the enclosing scope. Typically, these actions are calls to
4851 destructors for local objects, but back ends cannot rely on this
4852 fact. If these nodes are in fact representing such destructors,
4853 `CLEANUP_DECL' will be the `VAR_DECL' destroyed. Otherwise,
4854 `CLEANUP_DECL' will be `NULL_TREE'. In any case, the
4855 `CLEANUP_EXPR' is the expression to execute. The cleanups
4856 executed on exit from a scope should be run in the reverse order
4857 of the order in which the associated `CLEANUP_STMT's were
4861 Used to represent a `continue' statement. There are no additional
4865 Used to mark the beginning (if `CTOR_BEGIN_P' holds) or end (if
4866 `CTOR_END_P' holds of the main body of a constructor. See also
4867 `SUBOBJECT' for more information on how to use these nodes.
4870 Used to represent a local declaration. The `DECL_STMT_DECL' macro
4871 can be used to obtain the entity declared. This declaration may
4872 be a `LABEL_DECL', indicating that the label declared is a local
4873 label. (As an extension, GCC allows the declaration of labels
4874 with scope.) In C, this declaration may be a `FUNCTION_DECL',
4875 indicating the use of the GCC nested function extension. For more
4876 information, *note Functions::.
4879 Used to represent a `do' loop. The body of the loop is given by
4880 `DO_BODY' while the termination condition for the loop is given by
4881 `DO_COND'. The condition for a `do'-statement is always an
4885 Used to represent a temporary object of a class with no data whose
4886 address is never taken. (All such objects are interchangeable.)
4887 The `TREE_TYPE' represents the type of the object.
4890 Used to represent an expression statement. Use `EXPR_STMT_EXPR' to
4891 obtain the expression.
4894 Used to represent a `for' statement. The `FOR_INIT_STMT' is the
4895 initialization statement for the loop. The `FOR_COND' is the
4896 termination condition. The `FOR_EXPR' is the expression executed
4897 right before the `FOR_COND' on each loop iteration; often, this
4898 expression increments a counter. The body of the loop is given by
4899 `FOR_BODY'. Note that `FOR_INIT_STMT' and `FOR_BODY' return
4900 statements, while `FOR_COND' and `FOR_EXPR' return expressions.
4903 Used to represent a `goto' statement. The `GOTO_DESTINATION' will
4904 usually be a `LABEL_DECL'. However, if the "computed goto"
4905 extension has been used, the `GOTO_DESTINATION' will be an
4906 arbitrary expression indicating the destination. This expression
4907 will always have pointer type.
4910 Used to represent a C++ `catch' block. The `HANDLER_TYPE' is the
4911 type of exception that will be caught by this handler; it is equal
4912 (by pointer equality) to `NULL' if this handler is for all types.
4913 `HANDLER_PARMS' is the `DECL_STMT' for the catch parameter, and
4914 `HANDLER_BODY' is the code for the block itself.
4917 Used to represent an `if' statement. The `IF_COND' is the
4920 If the condition is a `TREE_LIST', then the `TREE_PURPOSE' is a
4921 statement (usually a `DECL_STMT'). Each time the condition is
4922 evaluated, the statement should be executed. Then, the
4923 `TREE_VALUE' should be used as the conditional expression itself.
4924 This representation is used to handle C++ code like this:
4928 where there is a new local variable (or variables) declared within
4931 The `THEN_CLAUSE' represents the statement given by the `then'
4932 condition, while the `ELSE_CLAUSE' represents the statement given
4933 by the `else' condition.
4936 Used to represent a label. The `LABEL_DECL' declared by this
4937 statement can be obtained with the `LABEL_EXPR_LABEL' macro. The
4938 `IDENTIFIER_NODE' giving the name of the label can be obtained from
4939 the `LABEL_DECL' with `DECL_NAME'.
4942 If the function uses the G++ "named return value" extension,
4943 meaning that the function has been defined like:
4944 S f(int) return s {...}
4945 then there will be a `RETURN_INIT'. There is never a named
4946 returned value for a constructor. The first argument to the
4947 `RETURN_INIT' is the name of the object returned; the second
4948 argument is the initializer for the object. The object is
4949 initialized when the `RETURN_INIT' is encountered. The object
4950 referred to is the actual object returned; this extension is a
4951 manual way of doing the "return-value optimization". Therefore,
4952 the object must actually be constructed in the place where the
4953 object will be returned.
4956 Used to represent a `return' statement. The `RETURN_EXPR' is the
4957 expression returned; it will be `NULL_TREE' if the statement was
4962 In a constructor, these nodes are used to mark the point at which a
4963 subobject of `this' is fully constructed. If, after this point, an
4964 exception is thrown before a `CTOR_STMT' with `CTOR_END_P' set is
4965 encountered, the `SUBOBJECT_CLEANUP' must be executed. The
4966 cleanups must be executed in the reverse order in which they
4970 Used to represent a `switch' statement. The `SWITCH_STMT_COND' is
4971 the expression on which the switch is occurring. See the
4972 documentation for an `IF_STMT' for more information on the
4973 representation used for the condition. The `SWITCH_STMT_BODY' is
4974 the body of the switch statement. The `SWITCH_STMT_TYPE' is the
4975 original type of switch expression as given in the source, before
4976 any compiler conversions.
4979 Used to represent a `try' block. The body of the try block is
4980 given by `TRY_STMTS'. Each of the catch blocks is a `HANDLER'
4981 node. The first handler is given by `TRY_HANDLERS'. Subsequent
4982 handlers are obtained by following the `TREE_CHAIN' link from one
4983 handler to the next. The body of the handler is given by
4986 If `CLEANUP_P' holds of the `TRY_BLOCK', then the `TRY_HANDLERS'
4987 will not be a `HANDLER' node. Instead, it will be an expression
4988 that should be executed if an exception is thrown in the try
4989 block. It must rethrow the exception after executing that code.
4990 And, if an exception is thrown while the expression is executing,
4991 `terminate' must be called.
4994 Used to represent a `using' directive. The namespace is given by
4995 `USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node
4996 is needed inside template functions, to implement using directives
4997 during instantiation.
5000 Used to represent a `while' loop. The `WHILE_COND' is the
5001 termination condition for the loop. See the documentation for an
5002 `IF_STMT' for more information on the representation used for the
5005 The `WHILE_BODY' is the body of the loop.
5009 File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: Trees
5011 9.7 Attributes in trees
5012 =======================
5014 Attributes, as specified using the `__attribute__' keyword, are
5015 represented internally as a `TREE_LIST'. The `TREE_PURPOSE' is the
5016 name of the attribute, as an `IDENTIFIER_NODE'. The `TREE_VALUE' is a
5017 `TREE_LIST' of the arguments of the attribute, if any, or `NULL_TREE'
5018 if there are no arguments; the arguments are stored as the `TREE_VALUE'
5019 of successive entries in the list, and may be identifiers or
5020 expressions. The `TREE_CHAIN' of the attribute is the next attribute
5021 in a list of attributes applying to the same declaration or type, or
5022 `NULL_TREE' if there are no further attributes in the list.
5024 Attributes may be attached to declarations and to types; these
5025 attributes may be accessed with the following macros. All attributes
5026 are stored in this way, and many also cause other changes to the
5027 declaration or type or to other internal compiler data structures.
5029 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL)
5030 This macro returns the attributes on the declaration DECL.
5032 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE)
5033 This macro returns the attributes on the type TYPE.
5036 File: gccint.info, Node: Expression trees, Prev: Attributes, Up: Trees
5041 The internal representation for expressions is for the most part quite
5042 straightforward. However, there are a few facts that one must bear in
5043 mind. In particular, the expression "tree" is actually a directed
5044 acyclic graph. (For example there may be many references to the integer
5045 constant zero throughout the source program; many of these will be
5046 represented by the same expression node.) You should not rely on
5047 certain kinds of node being shared, nor should rely on certain kinds of
5048 nodes being unshared.
5050 The following macros can be used with all expression nodes:
5053 Returns the type of the expression. This value may not be
5054 precisely the same type that would be given the expression in the
5057 In what follows, some nodes that one might expect to always have type
5058 `bool' are documented to have either integral or boolean type. At some
5059 point in the future, the C front end may also make use of this same
5060 intermediate representation, and at this point these nodes will
5061 certainly have integral type. The previous sentence is not meant to
5062 imply that the C++ front end does not or will not give these nodes
5065 Below, we list the various kinds of expression nodes. Except where
5066 noted otherwise, the operands to an expression are accessed using the
5067 `TREE_OPERAND' macro. For example, to access the first operand to a
5068 binary plus expression `expr', use:
5070 TREE_OPERAND (expr, 0)
5071 As this example indicates, the operands are zero-indexed.
5073 The table below begins with constants, moves on to unary expressions,
5074 then proceeds to binary expressions, and concludes with various other
5075 kinds of expressions:
5078 These nodes represent integer constants. Note that the type of
5079 these constants is obtained with `TREE_TYPE'; they are not always
5080 of type `int'. In particular, `char' constants are represented
5081 with `INTEGER_CST' nodes. The value of the integer constant `e' is
5083 ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT)
5084 + TREE_INST_CST_LOW (e))
5085 HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms.
5086 Both `TREE_INT_CST_HIGH' and `TREE_INT_CST_LOW' return a
5087 `HOST_WIDE_INT'. The value of an `INTEGER_CST' is interpreted as
5088 a signed or unsigned quantity depending on the type of the
5089 constant. In general, the expression given above will overflow,
5090 so it should not be used to calculate the value of the constant.
5092 The variable `integer_zero_node' is an integer constant with value
5093 zero. Similarly, `integer_one_node' is an integer constant with
5094 value one. The `size_zero_node' and `size_one_node' variables are
5095 analogous, but have type `size_t' rather than `int'.
5097 The function `tree_int_cst_lt' is a predicate which holds if its
5098 first argument is less than its second. Both constants are
5099 assumed to have the same signedness (i.e., either both should be
5100 signed or both should be unsigned.) The full width of the
5101 constant is used when doing the comparison; the usual rules about
5102 promotions and conversions are ignored. Similarly,
5103 `tree_int_cst_equal' holds if the two constants are equal. The
5104 `tree_int_cst_sgn' function returns the sign of a constant. The
5105 value is `1', `0', or `-1' according on whether the constant is
5106 greater than, equal to, or less than zero. Again, the signedness
5107 of the constant's type is taken into account; an unsigned constant
5108 is never less than zero, no matter what its bit-pattern.
5111 FIXME: Talk about how to obtain representations of this constant,
5112 do comparisons, and so forth.
5115 These nodes are used to represent complex number constants, that
5116 is a `__complex__' whose parts are constant nodes. The
5117 `TREE_REALPART' and `TREE_IMAGPART' return the real and the
5118 imaginary parts respectively.
5121 These nodes are used to represent vector constants, whose parts are
5122 constant nodes. Each individual constant node is either an
5123 integer or a double constant node. The first operand is a
5124 `TREE_LIST' of the constant nodes and is accessed through
5125 `TREE_VECTOR_CST_ELTS'.
5128 These nodes represent string-constants. The `TREE_STRING_LENGTH'
5129 returns the length of the string, as an `int'. The
5130 `TREE_STRING_POINTER' is a `char*' containing the string itself.
5131 The string may not be `NUL'-terminated, and it may contain
5132 embedded `NUL' characters. Therefore, the `TREE_STRING_LENGTH'
5133 includes the trailing `NUL' if it is present.
5135 For wide string constants, the `TREE_STRING_LENGTH' is the number
5136 of bytes in the string, and the `TREE_STRING_POINTER' points to an
5137 array of the bytes of the string, as represented on the target
5138 system (that is, as integers in the target endianness). Wide and
5139 non-wide string constants are distinguished only by the `TREE_TYPE'
5140 of the `STRING_CST'.
5142 FIXME: The formats of string constants are not well-defined when
5143 the target system bytes are not the same width as host system
5147 These nodes are used to represent pointer-to-member constants. The
5148 `PTRMEM_CST_CLASS' is the class type (either a `RECORD_TYPE' or
5149 `UNION_TYPE' within which the pointer points), and the
5150 `PTRMEM_CST_MEMBER' is the declaration for the pointed to object.
5151 Note that the `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is in
5152 general different from the `PTRMEM_CST_CLASS'. For example, given:
5153 struct B { int i; };
5154 struct D : public B {};
5156 The `PTRMEM_CST_CLASS' for `&D::i' is `D', even though the
5157 `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is `B', since `B::i' is
5158 a member of `B', not `D'.
5161 These nodes represent variables, including static data members.
5162 For more information, *note Declarations::.
5165 These nodes represent unary negation of the single operand, for
5166 both integer and floating-point types. The type of negation can be
5167 determined by looking at the type of the expression.
5169 The behavior of this operation on signed arithmetic overflow is
5170 controlled by the `flag_wrapv' and `flag_trapv' variables.
5173 These nodes represent the absolute value of the single operand, for
5174 both integer and floating-point types. This is typically used to
5175 implement the `abs', `labs' and `llabs' builtins for integer
5176 types, and the `fabs', `fabsf' and `fabsl' builtins for floating
5177 point types. The type of abs operation can be determined by
5178 looking at the type of the expression.
5180 This node is not used for complex types. To represent the modulus
5181 or complex abs of a complex value, use the `BUILT_IN_CABS',
5182 `BUILT_IN_CABSF' or `BUILT_IN_CABSL' builtins, as used to
5183 implement the C99 `cabs', `cabsf' and `cabsl' built-in functions.
5186 These nodes represent bitwise complement, and will always have
5187 integral type. The only operand is the value to be complemented.
5190 These nodes represent logical negation, and will always have
5191 integral (or boolean) type. The operand is the value being
5192 negated. The type of the operand and that of the result are
5193 always of `BOOLEAN_TYPE' or `INTEGER_TYPE'.
5197 `POSTDECREMENT_EXPR'
5198 `POSTINCREMENT_EXPR'
5199 These nodes represent increment and decrement expressions. The
5200 value of the single operand is computed, and the operand
5201 incremented or decremented. In the case of `PREDECREMENT_EXPR' and
5202 `PREINCREMENT_EXPR', the value of the expression is the value
5203 resulting after the increment or decrement; in the case of
5204 `POSTDECREMENT_EXPR' and `POSTINCREMENT_EXPR' is the value before
5205 the increment or decrement occurs. The type of the operand, like
5206 that of the result, will be either integral, boolean, or
5210 These nodes are used to represent the address of an object. (These
5211 expressions will always have pointer or reference type.) The
5212 operand may be another expression, or it may be a declaration.
5214 As an extension, GCC allows users to take the address of a label.
5215 In this case, the operand of the `ADDR_EXPR' will be a
5216 `LABEL_DECL'. The type of such an expression is `void*'.
5218 If the object addressed is not an lvalue, a temporary is created,
5219 and the address of the temporary is used.
5222 These nodes are used to represent the object pointed to by a
5223 pointer. The operand is the pointer being dereferenced; it will
5224 always have pointer or reference type.
5227 These nodes represent conversion of a floating-point value to an
5228 integer. The single operand will have a floating-point type,
5229 while the the complete expression will have an integral (or
5230 boolean) type. The operand is rounded towards zero.
5233 These nodes represent conversion of an integral (or boolean) value
5234 to a floating-point value. The single operand will have integral
5235 type, while the complete expression will have a floating-point
5238 FIXME: How is the operand supposed to be rounded? Is this
5239 dependent on `-mieee'?
5242 These nodes are used to represent complex numbers constructed from
5243 two expressions of the same (integer or real) type. The first
5244 operand is the real part and the second operand is the imaginary
5248 These nodes represent the conjugate of their operand.
5252 These nodes represent respectively the real and the imaginary parts
5253 of complex numbers (their sole argument).
5256 These nodes indicate that their one and only operand is not an
5257 lvalue. A back end can treat these identically to the single
5261 These nodes are used to represent conversions that do not require
5262 any code-generation. For example, conversion of a `char*' to an
5263 `int*' does not require any code be generated; such a conversion is
5264 represented by a `NOP_EXPR'. The single operand is the expression
5265 to be converted. The conversion from a pointer to a reference is
5266 also represented with a `NOP_EXPR'.
5269 These nodes are similar to `NOP_EXPR's, but are used in those
5270 situations where code may need to be generated. For example, if an
5271 `int*' is converted to an `int' code may need to be generated on
5272 some platforms. These nodes are never used for C++-specific
5273 conversions, like conversions between pointers to different
5274 classes in an inheritance hierarchy. Any adjustments that need to
5275 be made in such cases are always indicated explicitly. Similarly,
5276 a user-defined conversion is never represented by a
5277 `CONVERT_EXPR'; instead, the function calls are made explicit.
5280 These nodes represent `throw' expressions. The single operand is
5281 an expression for the code that should be executed to throw the
5282 exception. However, there is one implicit action not represented
5283 in that expression; namely the call to `__throw'. This function
5284 takes no arguments. If `setjmp'/`longjmp' exceptions are used, the
5285 function `__sjthrow' is called instead. The normal GCC back end
5286 uses the function `emit_throw' to generate this code; you can
5287 examine this function to see what needs to be done.
5291 These nodes represent left and right shifts, respectively. The
5292 first operand is the value to shift; it will always be of integral
5293 type. The second operand is an expression for the number of bits
5294 by which to shift. Right shift should be treated as arithmetic,
5295 i.e., the high-order bits should be zero-filled when the
5296 expression has unsigned type and filled with the sign bit when the
5297 expression has signed type. Note that the result is undefined if
5298 the second operand is larger than or equal to the first operand's
5304 These nodes represent bitwise inclusive or, bitwise exclusive or,
5305 and bitwise and, respectively. Both operands will always have
5310 These nodes represent logical and and logical or, respectively.
5311 These operators are not strict; i.e., the second operand is
5312 evaluated only if the value of the expression is not determined by
5313 evaluation of the first operand. The type of the operands and
5314 that of the result are always of `BOOLEAN_TYPE' or `INTEGER_TYPE'.
5319 These nodes represent logical and, logical or, and logical
5320 exclusive or. They are strict; both arguments are always
5321 evaluated. There are no corresponding operators in C or C++, but
5322 the front end will sometimes generate these expressions anyhow, if
5323 it can tell that strictness does not matter. The type of the
5324 operands and that of the result are always of `BOOLEAN_TYPE' or
5330 These nodes represent various binary arithmetic operations.
5331 Respectively, these operations are addition, subtraction (of the
5332 second operand from the first) and multiplication. Their operands
5333 may have either integral or floating type, but there will never be
5334 case in which one operand is of floating type and the other is of
5337 The behavior of these operations on signed arithmetic overflow is
5338 controlled by the `flag_wrapv' and `flag_trapv' variables.
5341 This node represents a floating point division operation.
5347 These nodes represent integer division operations that return an
5348 integer result. `TRUNC_DIV_EXPR' rounds towards zero,
5349 `FLOOR_DIV_EXPR' rounds towards negative infinity, `CEIL_DIV_EXPR'
5350 rounds towards positive infinity and `ROUND_DIV_EXPR' rounds to
5351 the closest integer. Integer division in C and C++ is truncating,
5352 i.e. `TRUNC_DIV_EXPR'.
5354 The behavior of these operations on signed arithmetic overflow,
5355 when dividing the minimum signed integer by minus one, is
5356 controlled by the `flag_wrapv' and `flag_trapv' variables.
5362 These nodes represent the integer remainder or modulus operation.
5363 The integer modulus of two operands `a' and `b' is defined as `a -
5364 (a/b)*b' where the division calculated using the corresponding
5365 division operator. Hence for `TRUNC_MOD_EXPR' this definition
5366 assumes division using truncation towards zero, i.e.
5367 `TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating
5368 division, i.e. `TRUNC_MOD_EXPR'.
5371 The `EXACT_DIV_EXPR' code is used to represent integer divisions
5372 where the numerator is known to be an exact multiple of the
5373 denominator. This allows the backend to choose between the faster
5374 of `TRUNC_DIV_EXPR', `CEIL_DIV_EXPR' and `FLOOR_DIV_EXPR' for the
5378 These nodes represent array accesses. The first operand is the
5379 array; the second is the index. To calculate the address of the
5380 memory accessed, you must scale the index by the size of the type
5381 of the array elements. The type of these expressions must be the
5382 type of a component of the array. The third and fourth operands
5383 are used after gimplification to represent the lower bound and
5384 component size but should not be used directly; call
5385 `array_ref_low_bound' and `array_ref_element_size' instead.
5388 These nodes represent access to a range (or "slice") of an array.
5389 The operands are the same as that for `ARRAY_REF' and have the same
5390 meanings. The type of these expressions must be an array whose
5391 component type is the same as that of the first operand. The
5392 range of that array type determines the amount of data these
5396 These nodes represent memory accesses whose address directly map to
5397 an addressing mode of the target architecture. The first argument
5398 is `TMR_SYMBOL' and must be a `VAR_DECL' of an object with a fixed
5399 address. The second argument is `TMR_BASE' and the third one is
5400 `TMR_INDEX'. The fourth argument is `TMR_STEP' and must be an
5401 `INTEGER_CST'. The fifth argument is `TMR_OFFSET' and must be an
5402 `INTEGER_CST'. Any of the arguments may be NULL if the
5403 appropriate component does not appear in the address. Address of
5404 the `TARGET_MEM_REF' is determined in the following way.
5406 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET
5408 The sixth argument is the reference to the original memory access,
5409 which is preserved for the purposes of the RTL alias analysis.
5410 The seventh argument is a tag representing the results of tree
5411 level alias analysis.
5419 These nodes represent the less than, less than or equal to, greater
5420 than, greater than or equal to, equal, and not equal comparison
5421 operators. The first and second operand with either be both of
5422 integral type or both of floating type. The result type of these
5423 expressions will always be of integral or boolean type. These
5424 operations return the result type's zero value for false, and the
5425 result type's one value for true.
5427 For floating point comparisons, if we honor IEEE NaNs and either
5428 operand is NaN, then `NE_EXPR' always returns true and the
5429 remaining operators always return false. On some targets,
5430 comparisons against an IEEE NaN, other than equality and
5431 inequality, may generate a floating point exception.
5435 These nodes represent non-trapping ordered and unordered comparison
5436 operators. These operations take two floating point operands and
5437 determine whether they are ordered or unordered relative to each
5438 other. If either operand is an IEEE NaN, their comparison is
5439 defined to be unordered, otherwise the comparison is defined to be
5440 ordered. The result type of these expressions will always be of
5441 integral or boolean type. These operations return the result
5442 type's zero value for false, and the result type's one value for
5451 These nodes represent the unordered comparison operators. These
5452 operations take two floating point operands and determine whether
5453 the operands are unordered or are less than, less than or equal to,
5454 greater than, greater than or equal to, or equal respectively. For
5455 example, `UNLT_EXPR' returns true if either operand is an IEEE NaN
5456 or the first operand is less than the second. With the possible
5457 exception of `LTGT_EXPR', all of these operations are guaranteed
5458 not to generate a floating point exception. The result type of
5459 these expressions will always be of integral or boolean type.
5460 These operations return the result type's zero value for false,
5461 and the result type's one value for true.
5464 These nodes represent assignment. The left-hand side is the first
5465 operand; the right-hand side is the second operand. The left-hand
5466 side will be a `VAR_DECL', `INDIRECT_REF', `COMPONENT_REF', or
5469 These nodes are used to represent not only assignment with `=' but
5470 also compound assignments (like `+='), by reduction to `='
5471 assignment. In other words, the representation for `i += 3' looks
5472 just like that for `i = i + 3'.
5475 These nodes are just like `MODIFY_EXPR', but are used only when a
5476 variable is initialized, rather than assigned to subsequently.
5477 This means that we can assume that the target of the
5478 initialization is not used in computing its own value; any
5479 reference to the lhs in computing the rhs is undefined.
5482 These nodes represent non-static data member accesses. The first
5483 operand is the object (rather than a pointer to it); the second
5484 operand is the `FIELD_DECL' for the data member. The third
5485 operand represents the byte offset of the field, but should not be
5486 used directly; call `component_ref_field_offset' instead.
5489 These nodes represent comma-expressions. The first operand is an
5490 expression whose value is computed and thrown away prior to the
5491 evaluation of the second operand. The value of the entire
5492 expression is the value of the second operand.
5495 These nodes represent `?:' expressions. The first operand is of
5496 boolean or integral type. If it evaluates to a nonzero value, the
5497 second operand should be evaluated, and returned as the value of
5498 the expression. Otherwise, the third operand is evaluated, and
5499 returned as the value of the expression.
5501 The second operand must have the same type as the entire
5502 expression, unless it unconditionally throws an exception or calls
5503 a noreturn function, in which case it should have void type. The
5504 same constraints apply to the third operand. This allows array
5505 bounds checks to be represented conveniently as `(i >= 0 && i <
5508 As a GNU extension, the C language front-ends allow the second
5509 operand of the `?:' operator may be omitted in the source. For
5510 example, `x ? : 3' is equivalent to `x ? x : 3', assuming that `x'
5511 is an expression without side-effects. In the tree
5512 representation, however, the second operand is always present,
5513 possibly protected by `SAVE_EXPR' if the first argument does cause
5517 These nodes are used to represent calls to functions, including
5518 non-static member functions. The first operand is a pointer to the
5519 function to call; it is always an expression whose type is a
5520 `POINTER_TYPE'. The second argument is a `TREE_LIST'. The
5521 arguments to the call appear left-to-right in the list. The
5522 `TREE_VALUE' of each list node contains the expression
5523 corresponding to that argument. (The value of `TREE_PURPOSE' for
5524 these nodes is unspecified, and should be ignored.) For non-static
5525 member functions, there will be an operand corresponding to the
5526 `this' pointer. There will always be expressions corresponding to
5527 all of the arguments, even if the function is declared with default
5528 arguments and some arguments are not explicitly provided at the
5532 These nodes are used to represent GCC's statement-expression
5533 extension. The statement-expression extension allows code like
5535 int f() { return ({ int j; j = 3; j + 7; }); }
5536 In other words, an sequence of statements may occur where a single
5537 expression would normally appear. The `STMT_EXPR' node represents
5538 such an expression. The `STMT_EXPR_STMT' gives the statement
5539 contained in the expression. The value of the expression is the
5540 value of the last sub-statement in the body. More precisely, the
5541 value is the value computed by the last statement nested inside
5542 `BIND_EXPR', `TRY_FINALLY_EXPR', or `TRY_CATCH_EXPR'. For
5545 the value is `3' while in:
5547 there is no value. If the `STMT_EXPR' does not yield a value,
5548 it's type will be `void'.
5551 These nodes represent local blocks. The first operand is a list of
5552 variables, connected via their `TREE_CHAIN' field. These will
5553 never require cleanups. The scope of these variables is just the
5554 body of the `BIND_EXPR'. The body of the `BIND_EXPR' is the
5558 These nodes represent "infinite" loops. The `LOOP_EXPR_BODY'
5559 represents the body of the loop. It should be executed forever,
5560 unless an `EXIT_EXPR' is encountered.
5563 These nodes represent conditional exits from the nearest enclosing
5564 `LOOP_EXPR'. The single operand is the condition; if it is
5565 nonzero, then the loop should be exited. An `EXIT_EXPR' will only
5566 appear within a `LOOP_EXPR'.
5568 `CLEANUP_POINT_EXPR'
5569 These nodes represent full-expressions. The single operand is an
5570 expression to evaluate. Any destructor calls engendered by the
5571 creation of temporaries during the evaluation of that expression
5572 should be performed immediately after the expression is evaluated.
5575 These nodes represent the brace-enclosed initializers for a
5576 structure or array. The first operand is reserved for use by the
5577 back end. The second operand is a `TREE_LIST'. If the
5578 `TREE_TYPE' of the `CONSTRUCTOR' is a `RECORD_TYPE' or
5579 `UNION_TYPE', then the `TREE_PURPOSE' of each node in the
5580 `TREE_LIST' will be a `FIELD_DECL' and the `TREE_VALUE' of each
5581 node will be the expression used to initialize that field.
5583 If the `TREE_TYPE' of the `CONSTRUCTOR' is an `ARRAY_TYPE', then
5584 the `TREE_PURPOSE' of each element in the `TREE_LIST' will be an
5585 `INTEGER_CST' or a `RANGE_EXPR' of two `INTEGER_CST's. A single
5586 `INTEGER_CST' indicates which element of the array (indexed from
5587 zero) is being assigned to. A `RANGE_EXPR' indicates an inclusive
5588 range of elements to initialize. In both cases the `TREE_VALUE'
5589 is the corresponding initializer. It is re-evaluated for each
5590 element of a `RANGE_EXPR'. If the `TREE_PURPOSE' is `NULL_TREE',
5591 then the initializer is for the next available array element.
5593 In the front end, you should not depend on the fields appearing in
5594 any particular order. However, in the middle end, fields must
5595 appear in declaration order. You should not assume that all
5596 fields will be represented. Unrepresented fields will be set to
5599 `COMPOUND_LITERAL_EXPR'
5600 These nodes represent ISO C99 compound literals. The
5601 `COMPOUND_LITERAL_EXPR_DECL_STMT' is a `DECL_STMT' containing an
5602 anonymous `VAR_DECL' for the unnamed object represented by the
5603 compound literal; the `DECL_INITIAL' of that `VAR_DECL' is a
5604 `CONSTRUCTOR' representing the brace-enclosed list of initializers
5605 in the compound literal. That anonymous `VAR_DECL' can also be
5606 accessed directly by the `COMPOUND_LITERAL_EXPR_DECL' macro.
5609 A `SAVE_EXPR' represents an expression (possibly involving
5610 side-effects) that is used more than once. The side-effects should
5611 occur only the first time the expression is evaluated. Subsequent
5612 uses should just reuse the computed value. The first operand to
5613 the `SAVE_EXPR' is the expression to evaluate. The side-effects
5614 should be executed where the `SAVE_EXPR' is first encountered in a
5615 depth-first preorder traversal of the expression tree.
5618 A `TARGET_EXPR' represents a temporary object. The first operand
5619 is a `VAR_DECL' for the temporary variable. The second operand is
5620 the initializer for the temporary. The initializer is evaluated
5621 and, if non-void, copied (bitwise) into the temporary. If the
5622 initializer is void, that means that it will perform the
5623 initialization itself.
5625 Often, a `TARGET_EXPR' occurs on the right-hand side of an
5626 assignment, or as the second operand to a comma-expression which is
5627 itself the right-hand side of an assignment, etc. In this case,
5628 we say that the `TARGET_EXPR' is "normal"; otherwise, we say it is
5629 "orphaned". For a normal `TARGET_EXPR' the temporary variable
5630 should be treated as an alias for the left-hand side of the
5631 assignment, rather than as a new temporary variable.
5633 The third operand to the `TARGET_EXPR', if present, is a
5634 cleanup-expression (i.e., destructor call) for the temporary. If
5635 this expression is orphaned, then this expression must be executed
5636 when the statement containing this expression is complete. These
5637 cleanups must always be executed in the order opposite to that in
5638 which they were encountered. Note that if a temporary is created
5639 on one branch of a conditional operator (i.e., in the second or
5640 third operand to a `COND_EXPR'), the cleanup must be run only if
5641 that branch is actually executed.
5643 See `STMT_IS_FULL_EXPR_P' for more information about running these
5647 An `AGGR_INIT_EXPR' represents the initialization as the return
5648 value of a function call, or as the result of a constructor. An
5649 `AGGR_INIT_EXPR' will only appear as a full-expression, or as the
5650 second operand of a `TARGET_EXPR'. The first operand to the
5651 `AGGR_INIT_EXPR' is the address of a function to call, just as in
5652 a `CALL_EXPR'. The second operand are the arguments to pass that
5653 function, as a `TREE_LIST', again in a manner similar to that of a
5656 If `AGGR_INIT_VIA_CTOR_P' holds of the `AGGR_INIT_EXPR', then the
5657 initialization is via a constructor call. The address of the third
5658 operand of the `AGGR_INIT_EXPR', which is always a `VAR_DECL', is
5659 taken, and this value replaces the first argument in the argument
5662 In either case, the expression is void.
5665 This node is used to implement support for the C/C++ variable
5666 argument-list mechanism. It represents expressions like `va_arg
5667 (ap, type)'. Its `TREE_TYPE' yields the tree representation for
5668 `type' and its sole argument yields the representation for `ap'.
5672 File: gccint.info, Node: Tree SSA, Next: Machine Desc, Prev: Control Flow, Up: Top
5674 10 Analysis and Optimization of GIMPLE Trees
5675 ********************************************
5677 GCC uses three main intermediate languages to represent the program
5678 during compilation: GENERIC, GIMPLE and RTL. GENERIC is a
5679 language-independent representation generated by each front end. It is
5680 used to serve as an interface between the parser and optimizer.
5681 GENERIC is a common representation that is able to represent programs
5682 written in all the languages supported by GCC.
5684 GIMPLE and RTL are used to optimize the program. GIMPLE is used for
5685 target and language independent optimizations (e.g., inlining, constant
5686 propagation, tail call elimination, redundancy elimination, etc). Much
5687 like GENERIC, GIMPLE is a language independent, tree based
5688 representation. However, it differs from GENERIC in that the GIMPLE
5689 grammar is more restrictive: expressions contain no more than 3
5690 operands (except function calls), it has no control flow structures and
5691 expressions with side-effects are only allowed on the right hand side
5692 of assignments. See the chapter describing GENERIC and GIMPLE for more
5695 This chapter describes the data structures and functions used in the
5696 GIMPLE optimizers (also known as "tree optimizers" or "middle end").
5697 In particular, it focuses on all the macros, data structures, functions
5698 and programming constructs needed to implement optimization passes for
5703 * GENERIC:: A high-level language-independent representation.
5704 * GIMPLE:: A lower-level factored tree representation.
5705 * Annotations:: Attributes for statements and variables.
5706 * Statement Operands:: Variables referenced by GIMPLE statements.
5707 * SSA:: Static Single Assignment representation.
5708 * Alias analysis:: Representing aliased loads and stores.
5711 File: gccint.info, Node: GENERIC, Next: GIMPLE, Up: Tree SSA
5716 The purpose of GENERIC is simply to provide a language-independent way
5717 of representing an entire function in trees. To this end, it was
5718 necessary to add a few new tree codes to the back end, but most
5719 everything was already there. If you can express it with the codes in
5720 `gcc/tree.def', it's GENERIC.
5722 Early on, there was a great deal of debate about how to think about
5723 statements in a tree IL. In GENERIC, a statement is defined as any
5724 expression whose value, if any, is ignored. A statement will always
5725 have `TREE_SIDE_EFFECTS' set (or it will be discarded), but a
5726 non-statement expression may also have side effects. A `CALL_EXPR',
5729 It would be possible for some local optimizations to work on the
5730 GENERIC form of a function; indeed, the adapted tree inliner works fine
5731 on GENERIC, but the current compiler performs inlining after lowering
5732 to GIMPLE (a restricted form described in the next section). Indeed,
5733 currently the frontends perform this lowering before handing off to
5734 `tree_rest_of_compilation', but this seems inelegant.
5736 If necessary, a front end can use some language-dependent tree codes
5737 in its GENERIC representation, so long as it provides a hook for
5738 converting them to GIMPLE and doesn't expect them to work with any
5739 (hypothetical) optimizers that run before the conversion to GIMPLE.
5740 The intermediate representation used while parsing C and C++ looks very
5741 little like GENERIC, but the C and C++ gimplifier hooks are perfectly
5742 happy to take it as input and spit out GIMPLE.
5745 File: gccint.info, Node: GIMPLE, Next: Annotations, Prev: GENERIC, Up: Tree SSA
5750 GIMPLE is a simplified subset of GENERIC for use in optimization. The
5751 particular subset chosen (and the name) was heavily influenced by the
5752 SIMPLE IL used by the McCAT compiler project at McGill University,
5753 though we have made some different choices. For one thing, SIMPLE
5754 doesn't support `goto'; a production compiler can't afford that kind of
5757 GIMPLE retains much of the structure of the parse trees: lexical
5758 scopes are represented as containers, rather than markers. However,
5759 expressions are broken down into a 3-address form, using temporary
5760 variables to hold intermediate values. Also, control structures are
5763 In GIMPLE no container node is ever used for its value; if a
5764 `COND_EXPR' or `BIND_EXPR' has a value, it is stored into a temporary
5765 within the controlled blocks, and that temporary is used in place of
5768 The compiler pass which lowers GENERIC to GIMPLE is referred to as the
5769 `gimplifier'. The gimplifier works recursively, replacing complex
5770 statements with sequences of simple statements.
5776 * GIMPLE Expressions::
5779 * Rough GIMPLE Grammar::
5782 File: gccint.info, Node: Interfaces, Next: Temporaries, Up: GIMPLE
5787 The tree representation of a function is stored in `DECL_SAVED_TREE'.
5788 It is lowered to GIMPLE by a call to `gimplify_function_tree'.
5790 If a front end wants to include language-specific tree codes in the
5791 tree representation which it provides to the back end, it must provide a
5792 definition of `LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the
5793 front end trees to GIMPLE. Usually such a hook will involve much of
5794 the same code for expanding front end trees to RTL. This function can
5795 return fully lowered GIMPLE, or it can return GENERIC trees and let the
5796 main gimplifier lower them the rest of the way; this is often simpler.
5798 The C and C++ front ends currently convert directly from front end
5799 trees to GIMPLE, and hand that off to the back end rather than first
5800 converting to GENERIC. Their gimplifier hooks know about all the
5801 `_STMT' nodes and how to convert them to GENERIC forms. There was some
5802 work done on a genericization pass which would run first, but the
5803 existence of `STMT_EXPR' meant that in order to convert all of the C
5804 statements into GENERIC equivalents would involve walking the entire
5805 tree anyway, so it was simpler to lower all the way. This might change
5806 in the future if someone writes an optimization pass which would work
5807 better with higher-level trees, but currently the optimizers all expect
5810 A front end which wants to use the tree optimizers (and already has
5811 some sort of whole-function tree representation) only needs to provide
5812 a definition of `LANG_HOOKS_GIMPLIFY_EXPR', call
5813 `gimplify_function_tree' to lower to GIMPLE, and then hand off to
5814 `tree_rest_of_compilation' to compile and output the function.
5816 You can tell the compiler to dump a C-like representation of the GIMPLE
5817 form with the flag `-fdump-tree-gimple'.
5820 File: gccint.info, Node: Temporaries, Next: GIMPLE Expressions, Prev: Interfaces, Up: GIMPLE
5825 When gimplification encounters a subexpression which is too complex, it
5826 creates a new temporary variable to hold the value of the subexpression,
5827 and adds a new statement to initialize it before the current statement.
5828 These special temporaries are known as `expression temporaries', and are
5829 allocated using `get_formal_tmp_var'. The compiler tries to always
5830 evaluate identical expressions into the same temporary, to simplify
5831 elimination of redundant calculations.
5833 We can only use expression temporaries when we know that it will not be
5834 reevaluated before its value is used, and that it will not be otherwise
5835 modified(1). Other temporaries can be allocated using
5836 `get_initialized_tmp_var' or `create_tmp_var'.
5838 Currently, an expression like `a = b + 5' is not reduced any further.
5839 We tried converting it to something like
5842 but this bloated the representation for minimal benefit. However, a
5843 variable which must live in memory cannot appear in an expression; its
5844 value is explicitly loaded into a temporary first. Similarly, storing
5845 the value of an expression to a memory variable goes through a
5848 ---------- Footnotes ----------
5850 (1) These restrictions are derived from those in Morgan 4.8.
5853 File: gccint.info, Node: GIMPLE Expressions, Next: Statements, Prev: Temporaries, Up: GIMPLE
5858 In general, expressions in GIMPLE consist of an operation and the
5859 appropriate number of simple operands; these operands must either be a
5860 GIMPLE rvalue (`is_gimple_val'), i.e. a constant or a register
5861 variable. More complex operands are factored out into temporaries, so
5868 The same rule holds for arguments to a `CALL_EXPR'.
5870 The target of an assignment is usually a variable, but can also be an
5871 `INDIRECT_REF' or a compound lvalue as described below.
5875 * Compound Expressions::
5876 * Compound Lvalues::
5877 * Conditional Expressions::
5878 * Logical Operators::
5881 File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: GIMPLE Expressions
5883 10.2.3.1 Compound Expressions
5884 .............................
5886 The left-hand side of a C comma expression is simply moved into a
5890 File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: GIMPLE Expressions
5892 10.2.3.2 Compound Lvalues
5893 .........................
5895 Currently compound lvalues involving array and structure field
5896 references are not broken down; an expression like `a.b[2] = 42' is not
5897 reduced any further (though complex array subscripts are). This
5898 restriction is a workaround for limitations in later optimizers; if we
5899 were to convert this to
5904 alias analysis would not remember that the reference to `T1[2]' came
5905 by way of `a.b', so it would think that the assignment could alias
5906 another member of `a'; this broke `struct-alias-1.c'. Future optimizer
5907 improvements may make this limitation unnecessary.
5910 File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: GIMPLE Expressions
5912 10.2.3.3 Conditional Expressions
5913 ................................
5915 A C `?:' expression is converted into an `if' statement with each
5916 branch assigning to the same temporary. So,
5926 Tree level if-conversion pass re-introduces `?:' expression, if
5927 appropriate. It is used to vectorize loops with conditions using
5928 vector conditional operations.
5930 Note that in GIMPLE, `if' statements are also represented using
5931 `COND_EXPR', as described below.
5934 File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: GIMPLE Expressions
5936 10.2.3.4 Logical Operators
5937 ..........................
5939 Except when they appear in the condition operand of a `COND_EXPR',
5940 logical `and' and `or' operators are simplified as follows: `a = b &&
5948 Note that `T1' in this example cannot be an expression temporary,
5949 because it has two different assignments.
5952 File: gccint.info, Node: Statements, Next: GIMPLE Example, Prev: GIMPLE Expressions, Up: GIMPLE
5957 Most statements will be assignment statements, represented by
5958 `MODIFY_EXPR'. A `CALL_EXPR' whose value is ignored can also be a
5959 statement. No other C expressions can appear at statement level; a
5960 reference to a volatile object is converted into a `MODIFY_EXPR'. In
5961 GIMPLE form, type of `MODIFY_EXPR' is not meaningful. Instead, use type
5964 There are also several varieties of complex statements.
5969 * Statement Sequences::
5970 * Empty Statements::
5972 * Selection Statements::
5975 * GIMPLE Exception Handling::
5978 File: gccint.info, Node: Blocks, Next: Statement Sequences, Up: Statements
5983 Block scopes and the variables they declare in GENERIC and GIMPLE are
5984 expressed using the `BIND_EXPR' code, which in previous versions of GCC
5985 was primarily used for the C statement-expression extension.
5987 Variables in a block are collected into `BIND_EXPR_VARS' in
5988 declaration order. Any runtime initialization is moved out of
5989 `DECL_INITIAL' and into a statement in the controlled block. When
5990 gimplifying from C or C++, this initialization replaces the `DECL_STMT'.
5992 Variable-length arrays (VLAs) complicate this process, as their size
5993 often refers to variables initialized earlier in the block. To handle
5994 this, we currently split the block at that point, and move the VLA into
5995 a new, inner `BIND_EXPR'. This strategy may change in the future.
5997 `DECL_SAVED_TREE' for a GIMPLE function will always be a `BIND_EXPR'
5998 which contains declarations for the temporary variables used in the
6001 A C++ program will usually contain more `BIND_EXPR's than there are
6002 syntactic blocks in the source code, since several C++ constructs have
6003 implicit scopes associated with them. On the other hand, although the
6004 C++ front end uses pseudo-scopes to handle cleanups for objects with
6005 destructors, these don't translate into the GIMPLE form; multiple
6006 declarations at the same level use the same `BIND_EXPR'.
6009 File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements
6011 10.2.4.2 Statement Sequences
6012 ............................
6014 Multiple statements at the same nesting level are collected into a
6015 `STATEMENT_LIST'. Statement lists are modified and traversed using the
6016 interface in `tree-iterator.h'.
6019 File: gccint.info, Node: Empty Statements, Next: Loops, Prev: Statement Sequences, Up: Statements
6021 10.2.4.3 Empty Statements
6022 .........................
6024 Whenever possible, statements with no effect are discarded. But if they
6025 are nested within another construct which cannot be discarded for some
6026 reason, they are instead replaced with an empty statement, generated by
6027 `build_empty_stmt'. Initially, all empty statements were shared, after
6028 the pattern of the Java front end, but this caused a lot of trouble in
6031 An empty statement is represented as `(void)0'.
6034 File: gccint.info, Node: Loops, Next: Selection Statements, Prev: Empty Statements, Up: Statements
6039 At one time loops were expressed in GIMPLE using `LOOP_EXPR', but now
6040 they are lowered to explicit gotos.
6043 File: gccint.info, Node: Selection Statements, Next: Jumps, Prev: Loops, Up: Statements
6045 10.2.4.5 Selection Statements
6046 .............................
6048 A simple selection statement, such as the C `if' statement, is
6049 expressed in GIMPLE using a void `COND_EXPR'. If only one branch is
6050 used, the other is filled with an empty statement.
6052 Normally, the condition expression is reduced to a simple comparison.
6053 If it is a shortcut (`&&' or `||') expression, however, we try to break
6054 up the `if' into multiple `if's so that the implied shortcut is taken
6055 directly, much like the transformation done by `do_jump' in the RTL
6058 A `SWITCH_EXPR' in GIMPLE contains the condition and a `TREE_VEC' of
6059 `CASE_LABEL_EXPR's describing the case values and corresponding
6060 `LABEL_DECL's to jump to. The body of the `switch' is moved after the
6064 File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Selection Statements, Up: Statements
6069 Other jumps are expressed by either `GOTO_EXPR' or `RETURN_EXPR'.
6071 The operand of a `GOTO_EXPR' must be either a label or a variable
6072 containing the address to jump to.
6074 The operand of a `RETURN_EXPR' is either `NULL_TREE' or a
6075 `MODIFY_EXPR' which sets the return value. It would be nice to move
6076 the `MODIFY_EXPR' into a separate statement, but the special return
6077 semantics in `expand_return' make that difficult. It may still happen
6078 in the future, perhaps by moving most of that logic into
6079 `expand_assignment'.
6082 File: gccint.info, Node: Cleanups, Next: GIMPLE Exception Handling, Prev: Jumps, Up: Statements
6087 Destructors for local C++ objects and similar dynamic cleanups are
6088 represented in GIMPLE by a `TRY_FINALLY_EXPR'. `TRY_FINALLY_EXPR' has
6089 two operands, both of which are a sequence of statements to execute.
6090 The first sequence is executed. When it completes the second sequence
6093 The first sequence may complete in the following ways:
6095 1. Execute the last statement in the sequence and fall off the end.
6097 2. Execute a goto statement (`GOTO_EXPR') to an ordinary label
6098 outside the sequence.
6100 3. Execute a return statement (`RETURN_EXPR').
6102 4. Throw an exception. This is currently not explicitly represented
6106 The second sequence is not executed if the first sequence completes by
6107 calling `setjmp' or `exit' or any other function that does not return.
6108 The second sequence is also not executed if the first sequence
6109 completes via a non-local goto or a computed goto (in general the
6110 compiler does not know whether such a goto statement exits the first
6111 sequence or not, so we assume that it doesn't).
6113 After the second sequence is executed, if it completes normally by
6114 falling off the end, execution continues wherever the first sequence
6115 would have continued, by falling off the end, or doing a goto, etc.
6117 `TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs
6118 to appear on every edge out of the controlled block; this reduces the
6119 freedom to move code across these edges. Therefore, the EH lowering
6120 pass which runs before most of the optimization passes eliminates these
6121 expressions by explicitly adding the cleanup to each edge. Rethrowing
6122 the exception is represented using `RESX_EXPR'.
6125 File: gccint.info, Node: GIMPLE Exception Handling, Prev: Cleanups, Up: Statements
6127 10.2.4.8 Exception Handling
6128 ...........................
6130 Other exception handling constructs are represented using
6131 `TRY_CATCH_EXPR'. `TRY_CATCH_EXPR' has two operands. The first
6132 operand is a sequence of statements to execute. If executing these
6133 statements does not throw an exception, then the second operand is
6134 ignored. Otherwise, if an exception is thrown, then the second operand
6135 of the `TRY_CATCH_EXPR' is checked. The second operand may have the
6138 1. A sequence of statements to execute. When an exception occurs,
6139 these statements are executed, and then the exception is rethrown.
6141 2. A sequence of `CATCH_EXPR' expressions. Each `CATCH_EXPR' has a
6142 list of applicable exception types and handler code. If the
6143 thrown exception matches one of the caught types, the associated
6144 handler code is executed. If the handler code falls off the
6145 bottom, execution continues after the original `TRY_CATCH_EXPR'.
6147 3. An `EH_FILTER_EXPR' expression. This has a list of permitted
6148 exception types, and code to handle a match failure. If the
6149 thrown exception does not match one of the allowed types, the
6150 associated match failure code is executed. If the thrown exception
6151 does match, it continues unwinding the stack looking for the next
6155 Currently throwing an exception is not directly represented in GIMPLE,
6156 since it is implemented by calling a function. At some point in the
6157 future we will want to add some way to express that the call will throw
6158 an exception of a known type.
6160 Just before running the optimizers, the compiler lowers the high-level
6161 EH constructs above into a set of `goto's, magic labels, and EH
6162 regions. Continuing to unwind at the end of a cleanup is represented
6166 File: gccint.info, Node: GIMPLE Example, Next: Rough GIMPLE Grammar, Prev: Statements, Up: GIMPLE
6168 10.2.5 GIMPLE Example
6169 ---------------------
6171 struct A { A(); ~A(); };
6178 int j = (--i, i ? 0 : 1);
6180 for (int x = 42; x > 0; --x)
6245 File: gccint.info, Node: Rough GIMPLE Grammar, Prev: GIMPLE Example, Up: GIMPLE
6247 10.2.6 Rough GIMPLE Grammar
6248 ---------------------------
6250 function : FUNCTION_DECL
6251 DECL_SAVED_TREE -> compound-stmt
6253 compound-stmt: STATEMENT_LIST
6268 BIND_EXPR_VARS -> chain of DECLs
6269 BIND_EXPR_BLOCK -> BLOCK
6270 BIND_EXPR_BODY -> compound-stmt
6274 op1 -> compound-stmt
6275 op2 -> compound-stmt
6277 switch-stmt : SWITCH_EXPR
6280 op2 -> TREE_VEC of CASE_LABEL_EXPRs
6281 The CASE_LABEL_EXPRs are sorted by CASE_LOW,
6282 and default is last.
6284 goto-stmt : GOTO_EXPR
6285 op0 -> LABEL_DECL | val
6287 return-stmt : RETURN_EXPR
6296 resx-stmt : RESX_EXPR
6298 label-stmt : LABEL_EXPR
6301 try-stmt : TRY_CATCH_EXPR
6302 op0 -> compound-stmt
6305 op0 -> compound-stmt
6306 op1 -> compound-stmt
6312 catch-seq : STATEMENT_LIST
6313 members -> CATCH_EXPR
6315 modify-stmt : MODIFY_EXPR
6319 call-stmt : CALL_EXPR
6320 op0 -> val | OBJ_TYPE_REF
6321 op1 -> call-arg-list
6323 call-arg-list: TREE_LIST
6324 members -> lhs | CONST
6329 addressable : addr-expr-arg
6332 with-size-arg: addressable
6335 indirectref : INDIRECT_REF
6341 op0 -> with-size-arg
6347 bitfieldref : BIT_FIELD_REF
6348 op0 -> inner-compref
6352 compref : inner-compref
6360 op0 -> inner-compref
6362 op0 -> inner-compref
6364 inner-compref: min-lval
6366 op0 -> inner-compref
6370 op0 -> inner-compref
6375 op0 -> inner-compref
6380 op0 -> inner-compref
6394 op0 -> addr-expr-arg
6409 File: gccint.info, Node: Annotations, Next: Statement Operands, Prev: GIMPLE, Up: Tree SSA
6414 The optimizers need to associate attributes with statements and
6415 variables during the optimization process. For instance, we need to
6416 know what basic block a statement belongs to or whether a variable has
6417 aliases. All these attributes are stored in data structures called
6418 annotations which are then linked to the field `ann' in `struct
6421 Presently, we define annotations for statements (`stmt_ann_t'),
6422 variables (`var_ann_t') and SSA names (`ssa_name_ann_t'). Annotations
6423 are defined and documented in `tree-flow.h'.
6426 File: gccint.info, Node: Statement Operands, Next: SSA, Prev: Annotations, Up: Tree SSA
6428 10.4 Statement Operands
6429 =======================
6431 Almost every GIMPLE statement will contain a reference to a variable or
6432 memory location. Since statements come in different shapes and sizes,
6433 their operands are going to be located at various spots inside the
6434 statement's tree. To facilitate access to the statement's operands,
6435 they are organized into lists associated inside each statement's
6436 annotation. Each element in an operand list is a pointer to a
6437 `VAR_DECL', `PARM_DECL' or `SSA_NAME' tree node. This provides a very
6438 convenient way of examining and replacing operands.
6440 Data flow analysis and optimization is done on all tree nodes
6441 representing variables. Any node for which `SSA_VAR_P' returns nonzero
6442 is considered when scanning statement operands. However, not all
6443 `SSA_VAR_P' variables are processed in the same way. For the purposes
6444 of optimization, we need to distinguish between references to local
6445 scalar variables and references to globals, statics, structures,
6446 arrays, aliased variables, etc. The reason is simple, the compiler can
6447 gather complete data flow information for a local scalar. On the other
6448 hand, a global variable may be modified by a function call, it may not
6449 be possible to keep track of all the elements of an array or the fields
6450 of a structure, etc.
6452 The operand scanner gathers two kinds of operands: "real" and
6453 "virtual". An operand for which `is_gimple_reg' returns true is
6454 considered real, otherwise it is a virtual operand. We also
6455 distinguish between uses and definitions. An operand is used if its
6456 value is loaded by the statement (e.g., the operand at the RHS of an
6457 assignment). If the statement assigns a new value to the operand, the
6458 operand is considered a definition (e.g., the operand at the LHS of an
6461 Virtual and real operands also have very different data flow
6462 properties. Real operands are unambiguous references to the full
6463 object that they represent. For instance, given
6470 Since `a' and `b' are non-aliased locals, the statement `a = b' will
6471 have one real definition and one real use because variable `b' is
6472 completely modified with the contents of variable `a'. Real definition
6473 are also known as "killing definitions". Similarly, the use of `a'
6476 In contrast, virtual operands are used with variables that can have a
6477 partial or ambiguous reference. This includes structures, arrays,
6478 globals, and aliased variables. In these cases, we have two types of
6479 definitions. For globals, structures, and arrays, we can determine from
6480 a statement whether a variable of these types has a killing definition.
6481 If the variable does, then the statement is marked as having a "must
6482 definition" of that variable. However, if a statement is only defining
6483 a part of the variable (i.e. a field in a structure), or if we know
6484 that a statement might define the variable but we cannot say for sure,
6485 then we mark that statement as having a "may definition". For
6499 The assignment `*p = 5' may be a definition of `a' or `b'. If we
6500 cannot determine statically where `p' is pointing to at the time of the
6501 store operation, we create virtual definitions to mark that statement
6502 as a potential definition site for `a' and `b'. Memory loads are
6503 similarly marked with virtual use operands. Virtual operands are shown
6504 in tree dumps right before the statement that contains them. To
6505 request a tree dump with virtual operands, use the `-vops' option to
6524 Notice that `V_MAY_DEF' operands have two copies of the referenced
6525 variable. This indicates that this is not a killing definition of that
6526 variable. In this case we refer to it as a "may definition" or
6527 "aliased store". The presence of the second copy of the variable in
6528 the `V_MAY_DEF' operand will become important when the function is
6529 converted into SSA form. This will be used to link all the non-killing
6530 definitions to prevent optimizations from making incorrect assumptions
6533 Operands are updated as soon as the statement is finished via a call
6534 to `update_stmt'. If statement elements are changed via `SET_USE' or
6535 `SET_DEF', then no further action is required (ie, those macros take
6536 care of updating the statement). If changes are made by manipulating
6537 the statement's tree directly, then a call must be made to
6538 `update_stmt' when complete. Calling one of the `bsi_insert' routines
6539 or `bsi_replace' performs an implicit call to `update_stmt'.
6541 10.4.1 Operand Iterators And Access Routines
6542 --------------------------------------------
6544 Operands are collected by `tree-ssa-operands.c'. They are stored
6545 inside each statement's annotation and can be accessed through either
6546 the operand iterators or an access routine.
6548 The following access routines are available for examining operands:
6550 1. `SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return
6551 NULL unless there is exactly one operand matching the specified
6552 flags. If there is exactly one operand, the operand is returned
6553 as either a `tree', `def_operand_p', or `use_operand_p'.
6555 tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags);
6556 use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES);
6557 def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS);
6559 2. `ZERO_SSA_OPERANDS': This macro returns true if there are no
6560 operands matching the specified flags.
6562 if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS))
6565 3. `NUM_SSA_OPERANDS': This macro Returns the number of operands
6566 matching 'flags'. This actually executes a loop to perform the
6567 count, so only use this if it is really needed.
6569 int count = NUM_SSA_OPERANDS (stmt, flags)
6571 If you wish to iterate over some or all operands, use the
6572 `FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print
6573 all the operands for a statement:
6576 print_ops (tree stmt)
6581 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS)
6582 print_generic_expr (stderr, var, TDF_SLIM);
6585 How to choose the appropriate iterator:
6587 1. Determine whether you are need to see the operand pointers, or
6588 just the trees, and choose the appropriate macro:
6592 use_operand_p FOR_EACH_SSA_USE_OPERAND
6593 def_operand_p FOR_EACH_SSA_DEF_OPERAND
6594 tree FOR_EACH_SSA_TREE_OPERAND
6596 2. You need to declare a variable of the type you are interested
6597 in, and an ssa_op_iter structure which serves as the loop
6598 controlling variable.
6600 3. Determine which operands you wish to use, and specify the flags of
6601 those you are interested in. They are documented in
6602 `tree-ssa-operands.h':
6604 #define SSA_OP_USE 0x01 /* Real USE operands. */
6605 #define SSA_OP_DEF 0x02 /* Real DEF operands. */
6606 #define SSA_OP_VUSE 0x04 /* VUSE operands. */
6607 #define SSA_OP_VMAYUSE 0x08 /* USE portion of V_MAY_DEFS. */
6608 #define SSA_OP_VMAYDEF 0x10 /* DEF portion of V_MAY_DEFS. */
6609 #define SSA_OP_VMUSTDEF 0x20 /* V_MUST_DEF definitions. */
6611 /* These are commonly grouped operand flags. */
6612 #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE | SSA_OP_VMAYUSE)
6613 #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VMAYDEF | SSA_OP_VMUSTDEF)
6614 #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE)
6615 #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF)
6616 #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS)
6618 So if you want to look at the use pointers for all the `USE' and
6619 `VUSE' operands, you would do something like:
6621 use_operand_p use_p;
6624 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE))
6626 process_use_ptr (use_p);
6629 The `TREE' macro is basically the same as the `USE' and `DEF' macros,
6630 only with the use or def dereferenced via `USE_FROM_PTR (use_p)' and
6631 `DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use
6632 and defs flags can be mixed.
6637 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE | SSA_OP_VMUSTDEF)
6639 print_generic_expr (stderr, var, TDF_SLIM);
6642 `V_MAY_DEF's are broken into two flags, one for the `DEF' portion
6643 (`SSA_OP_VMAYDEF') and one for the USE portion (`SSA_OP_VMAYUSE'). If
6644 all you want to look at are the `V_MAY_DEF's together, there is a
6645 fourth iterator macro for this, which returns both a def_operand_p and
6646 a use_operand_p for each `V_MAY_DEF' in the statement. Note that you
6647 don't need any flags for this one.
6649 use_operand_p use_p;
6650 def_operand_p def_p;
6653 FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter)
6658 `V_MUST_DEF's are broken into two flags, one for the `DEF' portion
6659 (`SSA_OP_VMUSTDEF') and one for the kill portion (`SSA_OP_VMUSTKILL').
6660 If all you want to look at are the `V_MUST_DEF's together, there is a
6661 fourth iterator macro for this, which returns both a def_operand_p and
6662 a use_operand_p for each `V_MUST_DEF' in the statement. Note that you
6663 don't need any flags for this one.
6665 use_operand_p kill_p;
6666 def_operand_p def_p;
6669 FOR_EACH_SSA_MUSTDEF_OPERAND (def_p, kill_p, stmt, iter)
6674 There are many examples in the code as well, as well as the
6675 documentation in `tree-ssa-operands.h'.
6677 There are also a couple of variants on the stmt iterators regarding PHI
6680 `FOR_EACH_PHI_ARG' Works exactly like `FOR_EACH_SSA_USE_OPERAND',
6681 except it works over `PHI' arguments instead of statement operands.
6683 /* Look at every virtual PHI use. */
6684 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES)
6689 /* Look at every real PHI use. */
6690 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES)
6693 /* Look at every every PHI use. */
6694 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES)
6697 `FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like
6698 `FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a
6699 statement or a `PHI' node. These should be used when it is appropriate
6700 but they are not quite as efficient as the individual `FOR_EACH_PHI'
6701 and `FOR_EACH_SSA' routines.
6703 FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags)
6708 FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags)
6713 10.4.2 Immediate Uses
6714 ---------------------
6716 Immediate use information is now always available. Using the immediate
6717 use iterators, you may examine every use of any `SSA_NAME'. For
6718 instance, to change each use of `ssa_var' to `ssa_var2':
6720 use_operand_p imm_use_p;
6721 imm_use_iterator iterator;
6724 FOR_EACH_IMM_USE_SAFE (imm_use_p, iterator, ssa_var)
6725 SET_USE (imm_use_p, ssa_var_2);
6727 There are 2 iterators which can be used. `FOR_EACH_IMM_USE_FAST' is
6728 used when the immediate uses are not changed, ie. you are looking at
6729 the uses, but not setting them.
6731 If they do get changed, then care must be taken that things are not
6732 changed under the iterators, so use the `FOR_EACH_IMM_USE_SAFE'
6733 iterator. It attempts to preserve the sanity of the use list by moving
6734 an iterator element through the use list, preventing insertions and
6735 deletions in the list from resulting in invalid pointers. This is a
6736 little slower since it adds a placeholder element and moves it through
6737 the list. This element must be also be removed if the loop is
6738 terminated early. A macro (`BREAK_FROM SAFE_IMM_USE') is provided for
6741 FOR_EACH_IMM_USE_SAFE (use_p, iter, var)
6743 if (var == last_var)
6744 BREAK_FROM_SAFE_IMM_USE (iter);
6746 SET_USE (use_p, var2);
6749 There are checks in `verify_ssa' which verify that the immediate use
6750 list is up to date, as well as checking that an optimization didn't
6751 break from the loop without using this macro. It is safe to simply
6752 'break'; from a `FOR_EACH_IMM_USE_FAST' traverse.
6754 Some useful functions and macros:
6755 1. `has_zero_uses (ssa_var)' : Returns true if there are no uses of
6758 2. `has_single_use (ssa_var)' : Returns true if there is only a
6759 single use of `ssa_var'.
6761 3. `single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' :
6762 Returns true if there is only a single use of `ssa_var', and also
6763 returns the use pointer and statement it occurs in in the second
6764 and third parameters.
6766 4. `num_imm_uses (ssa_var)' : Returns the number of immediate uses of
6767 `ssa_var'. It is better not to use this if possible since it simply
6768 utilizes a loop to count the uses.
6770 5. `PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a `PHI'
6771 node, return the index number for the use. An assert is triggered
6772 if the use isn't located in a `PHI' node.
6774 6. `USE_STMT (use_p)' : Return the statement a use occurs in.
6776 Note that uses are not put into an immediate use list until their
6777 statement is actually inserted into the instruction stream via a
6780 It is also still possible to utilize lazy updating of statements, but
6781 this should be used only when absolutely required. Both alias analysis
6782 and the dominator optimizations currently do this.
6784 When lazy updating is being used, the immediate use information is out
6785 of date and cannot be used reliably. Lazy updating is achieved by
6786 simply marking statements modified via calls to `mark_stmt_modified'
6787 instead of `update_stmt'. When lazy updating is no longer required,
6788 all the modified statements must have `update_stmt' called in order to
6789 bring them up to date. This must be done before the optimization is
6790 finished, or `verify_ssa' will trigger an abort.
6792 This is done with a simple loop over the instruction stream:
6793 block_stmt_iterator bsi;
6797 for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
6798 update_stmt_if_modified (bsi_stmt (bsi));
6802 File: gccint.info, Node: SSA, Next: Alias analysis, Prev: Statement Operands, Up: Tree SSA
6804 10.5 Static Single Assignment
6805 =============================
6807 Most of the tree optimizers rely on the data flow information provided
6808 by the Static Single Assignment (SSA) form. We implement the SSA form
6809 as described in `R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K.
6810 Zadeck. Efficiently Computing Static Single Assignment Form and the
6811 Control Dependence Graph. ACM Transactions on Programming Languages
6812 and Systems, 13(4):451-490, October 1991'.
6814 The SSA form is based on the premise that program variables are
6815 assigned in exactly one location in the program. Multiple assignments
6816 to the same variable create new versions of that variable. Naturally,
6817 actual programs are seldom in SSA form initially because variables tend
6818 to be assigned multiple times. The compiler modifies the program
6819 representation so that every time a variable is assigned in the code, a
6820 new version of the variable is created. Different versions of the same
6821 variable are distinguished by subscripting the variable name with its
6822 version number. Variables used in the right-hand side of expressions
6823 are renamed so that their version number matches that of the most
6826 We represent variable versions using `SSA_NAME' nodes. The renaming
6827 process in `tree-ssa.c' wraps every real and virtual operand with an
6828 `SSA_NAME' node which contains the version number and the statement
6829 that created the `SSA_NAME'. Only definitions and virtual definitions
6830 may create new `SSA_NAME' nodes.
6832 Sometimes, flow of control makes it impossible to determine what is the
6833 most recent version of a variable. In these cases, the compiler
6834 inserts an artificial definition for that variable called "PHI
6835 function" or "PHI node". This new definition merges all the incoming
6836 versions of the variable to create a new name for it. For instance,
6845 # a_4 = PHI <a_1, a_2, a_3>
6848 Since it is not possible to determine which of the three branches will
6849 be taken at runtime, we don't know which of `a_1', `a_2' or `a_3' to
6850 use at the return statement. So, the SSA renamer creates a new version
6851 `a_4' which is assigned the result of "merging" `a_1', `a_2' and `a_3'.
6852 Hence, PHI nodes mean "one of these operands. I don't know which".
6854 The following macros can be used to examine PHI nodes
6856 -- Macro: PHI_RESULT (PHI)
6857 Returns the `SSA_NAME' created by PHI node PHI (i.e., PHI's LHS).
6859 -- Macro: PHI_NUM_ARGS (PHI)
6860 Returns the number of arguments in PHI. This number is exactly
6861 the number of incoming edges to the basic block holding PHI.
6863 -- Macro: PHI_ARG_ELT (PHI, I)
6864 Returns a tuple representing the Ith argument of PHI. Each
6865 element of this tuple contains an `SSA_NAME' VAR and the incoming
6866 edge through which VAR flows.
6868 -- Macro: PHI_ARG_EDGE (PHI, I)
6869 Returns the incoming edge for the Ith argument of PHI.
6871 -- Macro: PHI_ARG_DEF (PHI, I)
6872 Returns the `SSA_NAME' for the Ith argument of PHI.
6874 10.5.1 Preserving the SSA form
6875 ------------------------------
6877 Some optimization passes make changes to the function that invalidate
6878 the SSA property. This can happen when a pass has added new symbols or
6879 changed the program so that variables that were previously aliased
6880 aren't anymore. Whenever something like this happens, the affected
6881 symbols must be renamed into SSA form again. Transformations that emit
6882 new code or replicate existing statements will also need to update the
6885 Since GCC implements two different SSA forms for register and virtual
6886 variables, keeping the SSA form up to date depends on whether you are
6887 updating register or virtual names. In both cases, the general idea
6888 behind incremental SSA updates is similar: when new SSA names are
6889 created, they typically are meant to replace other existing names in
6892 For instance, given the following code:
6895 2 x_1 = PHI (0, x_5)
6906 Suppose that we insert new names `x_10' and `x_11' (lines `4' and `8').
6909 2 x_1 = PHI (0, x_5)
6922 We want to replace all the uses of `x_1' with the new definitions of
6923 `x_10' and `x_11'. Note that the only uses that should be replaced are
6924 those at lines `5', `9' and `11'. Also, the use of `x_7' at line `9'
6925 should _not_ be replaced (this is why we cannot just mark symbol `x' for
6928 Additionally, we may need to insert a PHI node at line `11' because
6929 that is a merge point for `x_10' and `x_11'. So the use of `x_1' at
6930 line `11' will be replaced with the new PHI node. The insertion of PHI
6931 nodes is optional. They are not strictly necessary to preserve the SSA
6932 form, and depending on what the caller inserted, they may not even be
6933 useful for the optimizers.
6935 Updating the SSA form is a two step process. First, the pass has to
6936 identify which names need to be updated and/or which symbols need to be
6937 renamed into SSA form for the first time. When new names are
6938 introduced to replace existing names in the program, the mapping
6939 between the old and the new names are registered by calling
6940 `register_new_name_mapping' (note that if your pass creates new code by
6941 duplicating basic blocks, the call to `tree_duplicate_bb' will set up
6942 the necessary mappings automatically). On the other hand, if your pass
6943 exposes a new symbol that should be put in SSA form for the first time,
6944 the new symbol should be registered with `mark_sym_for_renaming'.
6946 After the replacement mappings have been registered and new symbols
6947 marked for renaming, a call to `update_ssa' makes the registered
6948 changes. This can be done with an explicit call or by creating `TODO'
6949 flags in the `tree_opt_pass' structure for your pass. There are
6950 several `TODO' flags that control the behavior of `update_ssa':
6952 * `TODO_update_ssa'. Update the SSA form inserting PHI nodes
6953 for newly exposed symbols and virtual names marked for updating.
6954 When updating real names, only insert PHI nodes for a real
6955 name `O_j' in blocks reached by all the new and old
6956 definitions for `O_j'. If the iterated dominance frontier
6957 for `O_j' is not pruned, we may end up inserting PHI nodes
6958 in blocks that have one or more edges with no incoming
6959 definition for `O_j'. This would lead to uninitialized
6960 warnings for `O_j''s symbol.
6962 * `TODO_update_ssa_no_phi'. Update the SSA form without
6963 inserting any new PHI nodes at all. This is used by passes that
6964 have either inserted all the PHI nodes themselves or passes
6965 that need only to patch use-def and def-def chains for
6966 virtuals (e.g., DCE).
6968 * `TODO_update_ssa_full_phi'. Insert PHI nodes everywhere
6969 they are needed. No pruning of the IDF is done. This is used
6970 by passes that need the PHI nodes for `O_j' even if it
6971 means that some arguments will come from the default definition
6972 of `O_j''s symbol (e.g., `pass_linear_transform').
6974 WARNING: If you need to use this flag, chances are that your
6975 pass may be doing something wrong. Inserting PHI nodes for an
6976 old name where not all edges carry a new replacement may lead to
6977 silent codegen errors or spurious uninitialized warnings.
6979 * `TODO_update_ssa_only_virtuals'. Passes that update the SSA
6980 form on their own may want to delegate the updating of
6981 virtual names to the generic updater. Since FUD chains are
6982 easier to maintain, this simplifies the work they need to do.
6983 NOTE: If this flag is used, any OLD->NEW mappings for real names
6984 are explicitly destroyed and only the symbols marked for
6985 renaming are processed.
6987 10.5.2 Examining `SSA_NAME' nodes
6988 ---------------------------------
6990 The following macros can be used to examine `SSA_NAME' nodes
6992 -- Macro: SSA_NAME_DEF_STMT (VAR)
6993 Returns the statement S that creates the `SSA_NAME' VAR. If S is
6994 an empty statement (i.e., `IS_EMPTY_STMT (S)' returns `true'), it
6995 means that the first reference to this variable is a USE or a VUSE.
6997 -- Macro: SSA_NAME_VERSION (VAR)
6998 Returns the version number of the `SSA_NAME' object VAR.
7000 10.5.3 Walking use-def chains
7001 -----------------------------
7003 -- Tree SSA function: void walk_use_def_chains (VAR, FN, DATA)
7004 Walks use-def chains starting at the `SSA_NAME' node VAR. Calls
7005 function FN at each reaching definition found. Function FN takes
7006 three arguments: VAR, its defining statement (DEF_STMT) and a
7007 generic pointer to whatever state information that FN may want to
7008 maintain (DATA). Function FN is able to stop the walk by
7009 returning `true', otherwise in order to continue the walk, FN
7010 should return `false'.
7012 Note, that if DEF_STMT is a `PHI' node, the semantics are slightly
7013 different. For each argument ARG of the PHI node, this function
7016 1. Walk the use-def chains for ARG.
7018 2. Call `FN (ARG, PHI, DATA)'.
7020 Note how the first argument to FN is no longer the original
7021 variable VAR, but the PHI argument currently being examined. If
7022 FN wants to get at VAR, it should call `PHI_RESULT' (PHI).
7024 10.5.4 Walking the dominator tree
7025 ---------------------------------
7027 -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB)
7028 This function walks the dominator tree for the current CFG calling
7029 a set of callback functions defined in STRUCT DOM_WALK_DATA in
7030 `domwalk.h'. The call back functions you need to define give you
7031 hooks to execute custom code at various points during traversal:
7033 1. Once to initialize any local data needed while processing
7034 BB and its children. This local data is pushed into an
7035 internal stack which is automatically pushed and popped as
7036 the walker traverses the dominator tree.
7038 2. Once before traversing all the statements in the BB.
7040 3. Once for every statement inside BB.
7042 4. Once after traversing all the statements and before recursing
7043 into BB's dominator children.
7045 5. It then recurses into all the dominator children of BB.
7047 6. After recursing into all the dominator children of BB it
7048 can, optionally, traverse every statement in BB again
7049 (i.e., repeating steps 2 and 3).
7051 7. Once after walking the statements in BB and BB's
7052 dominator children. At this stage, the block local data stack
7056 File: gccint.info, Node: Alias analysis, Prev: SSA, Up: Tree SSA
7061 Alias analysis proceeds in 4 main phases:
7063 1. Structural alias analysis.
7065 This phase walks the types for structure variables, and determines
7066 which of the fields can overlap using offset and size of each
7067 field. For each field, a "subvariable" called a "Structure field
7068 tag" (SFT) is created, which represents that field as a separate
7069 variable. All accesses that could possibly overlap with a given
7070 field will have virtual operands for the SFT of that field.
7080 int tmp1, tmp2, tmp3;
7081 SFT.0_2 = V_MUST_DEF <SFT.0_1>
7083 SFT.1_4 = V_MUST_DEF <SFT.1_3>
7091 tmp3_7 = tmp1_5 + tmp2_6;
7095 If you copy the type tag for a variable for some reason, you
7096 probably also want to copy the subvariables for that variable.
7098 2. Points-to and escape analysis.
7100 This phase walks the use-def chains in the SSA web looking for
7106 * Assignments of the form `P_i = &VAR'
7108 * Assignments of the form P_i = malloc()
7110 * Pointers and ADDR_EXPR that escape the current function.
7112 The concept of `escaping' is the same one used in the Java world.
7113 When a pointer or an ADDR_EXPR escapes, it means that it has been
7114 exposed outside of the current function. So, assignment to global
7115 variables, function arguments and returning a pointer are all
7118 This is where we are currently limited. Since not everything is
7119 renamed into SSA, we lose track of escape properties when a
7120 pointer is stashed inside a field in a structure, for instance.
7121 In those cases, we are assuming that the pointer does escape.
7123 We use escape analysis to determine whether a variable is
7124 call-clobbered. Simply put, if an ADDR_EXPR escapes, then the
7125 variable is call-clobbered. If a pointer P_i escapes, then all
7126 the variables pointed-to by P_i (and its memory tag) also escape.
7128 3. Compute flow-sensitive aliases
7130 We have two classes of memory tags. Memory tags associated with
7131 the pointed-to data type of the pointers in the program. These
7132 tags are called "type memory tag" (TMT). The other class are
7133 those associated with SSA_NAMEs, called "name memory tag" (NMT).
7134 The basic idea is that when adding operands for an INDIRECT_REF
7135 *P_i, we will first check whether P_i has a name tag, if it does
7136 we use it, because that will have more precise aliasing
7137 information. Otherwise, we use the standard type tag.
7139 In this phase, we go through all the pointers we found in
7140 points-to analysis and create alias sets for the name memory tags
7141 associated with each pointer P_i. If P_i escapes, we mark
7142 call-clobbered the variables it points to and its tag.
7144 4. Compute flow-insensitive aliases
7146 This pass will compare the alias set of every type memory tag and
7147 every addressable variable found in the program. Given a type
7148 memory tag TMT and an addressable variable V. If the alias sets
7149 of TMT and V conflict (as computed by may_alias_p), then V is
7150 marked as an alias tag and added to the alias set of TMT.
7152 For instance, consider the following function:
7169 After aliasing analysis has finished, the type memory tag for pointer
7170 `p' will have two aliases, namely variables `a' and `b'. Every time
7171 pointer `p' is dereferenced, we want to mark the operation as a
7172 potential reference to `a' and `b'.
7182 # p_1 = PHI <p_4(1), p_6(2)>;
7184 # a_7 = V_MAY_DEF <a_3>;
7185 # b_8 = V_MAY_DEF <b_5>;
7188 # a_9 = V_MAY_DEF <a_7>
7197 In certain cases, the list of may aliases for a pointer may grow too
7198 large. This may cause an explosion in the number of virtual operands
7199 inserted in the code. Resulting in increased memory consumption and
7202 When the number of virtual operands needed to represent aliased loads
7203 and stores grows too large (configurable with `--param
7204 max-aliased-vops'), alias sets are grouped to avoid severe compile-time
7205 slow downs and memory consumption. The alias grouping heuristic
7206 proceeds as follows:
7208 1. Sort the list of pointers in decreasing number of contributed
7211 2. Take the first pointer from the list and reverse the role of the
7212 memory tag and its aliases. Usually, whenever an aliased variable
7213 Vi is found to alias with a memory tag T, we add Vi to the
7214 may-aliases set for T. Meaning that after alias analysis, we will
7217 may-aliases(T) = { V1, V2, V3, ..., Vn }
7219 This means that every statement that references T, will get `n'
7220 virtual operands for each of the Vi tags. But, when alias
7221 grouping is enabled, we make T an alias tag and add it to the
7222 alias set of all the Vi variables:
7224 may-aliases(V1) = { T }
7225 may-aliases(V2) = { T }
7227 may-aliases(Vn) = { T }
7229 This has two effects: (a) statements referencing T will only get a
7230 single virtual operand, and, (b) all the variables Vi will now
7231 appear to alias each other. So, we lose alias precision to
7232 improve compile time. But, in theory, a program with such a high
7233 level of aliasing should not be very optimizable in the first
7236 3. Since variables may be in the alias set of more than one memory
7237 tag, the grouping done in step (2) needs to be extended to all the
7238 memory tags that have a non-empty intersection with the
7239 may-aliases set of tag T. For instance, if we originally had
7240 these may-aliases sets:
7242 may-aliases(T) = { V1, V2, V3 }
7243 may-aliases(R) = { V2, V4 }
7245 In step (2) we would have reverted the aliases for T as:
7247 may-aliases(V1) = { T }
7248 may-aliases(V2) = { T }
7249 may-aliases(V3) = { T }
7251 But note that now V2 is no longer aliased with R. We could add R
7252 to may-aliases(V2), but we are in the process of grouping aliases
7253 to reduce virtual operands so what we do is add V4 to the grouping
7256 may-aliases(V1) = { T }
7257 may-aliases(V2) = { T }
7258 may-aliases(V3) = { T }
7259 may-aliases(V4) = { T }
7261 4. If the total number of virtual operands due to aliasing is still
7262 above the threshold set by max-alias-vops, go back to (2).
7265 File: gccint.info, Node: RTL, Next: Control Flow, Prev: Trees, Up: Top
7267 11 RTL Representation
7268 *********************
7270 Most of the work of the compiler is done on an intermediate
7271 representation called register transfer language. In this language,
7272 the instructions to be output are described, pretty much one by one, in
7273 an algebraic form that describes what the instruction does.
7275 RTL is inspired by Lisp lists. It has both an internal form, made up
7276 of structures that point at other structures, and a textual form that
7277 is used in the machine description and in printed debugging dumps. The
7278 textual form uses nested parentheses to indicate the pointers in the
7283 * RTL Objects:: Expressions vs vectors vs strings vs integers.
7284 * RTL Classes:: Categories of RTL expression objects, and their structure.
7285 * Accessors:: Macros to access expression operands or vector elts.
7286 * Special Accessors:: Macros to access specific annotations on RTL.
7287 * Flags:: Other flags in an RTL expression.
7288 * Machine Modes:: Describing the size and format of a datum.
7289 * Constants:: Expressions with constant values.
7290 * Regs and Memory:: Expressions representing register contents or memory.
7291 * Arithmetic:: Expressions representing arithmetic on other expressions.
7292 * Comparisons:: Expressions representing comparison of expressions.
7293 * Bit-Fields:: Expressions representing bit-fields in memory or reg.
7294 * Vector Operations:: Expressions involving vector datatypes.
7295 * Conversions:: Extending, truncating, floating or fixing.
7296 * RTL Declarations:: Declaring volatility, constancy, etc.
7297 * Side Effects:: Expressions for storing in registers, etc.
7298 * Incdec:: Embedded side-effects for autoincrement addressing.
7299 * Assembler:: Representing `asm' with operands.
7300 * Insns:: Expression types for entire insns.
7301 * Calls:: RTL representation of function call insns.
7302 * Sharing:: Some expressions are unique; others *must* be copied.
7303 * Reading RTL:: Reading textual RTL from a file.
7306 File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL
7308 11.1 RTL Object Types
7309 =====================
7311 RTL uses five kinds of objects: expressions, integers, wide integers,
7312 strings and vectors. Expressions are the most important ones. An RTL
7313 expression ("RTX", for short) is a C structure, but it is usually
7314 referred to with a pointer; a type that is given the typedef name `rtx'.
7316 An integer is simply an `int'; their written form uses decimal digits.
7317 A wide integer is an integral object whose type is `HOST_WIDE_INT';
7318 their written form uses decimal digits.
7320 A string is a sequence of characters. In core it is represented as a
7321 `char *' in usual C fashion, and it is written in C syntax as well.
7322 However, strings in RTL may never be null. If you write an empty
7323 string in a machine description, it is represented in core as a null
7324 pointer rather than as a pointer to a null character. In certain
7325 contexts, these null pointers instead of strings are valid. Within RTL
7326 code, strings are most commonly found inside `symbol_ref' expressions,
7327 but they appear in other contexts in the RTL expressions that make up
7328 machine descriptions.
7330 In a machine description, strings are normally written with double
7331 quotes, as you would in C. However, strings in machine descriptions may
7332 extend over many lines, which is invalid C, and adjacent string
7333 constants are not concatenated as they are in C. Any string constant
7334 may be surrounded with a single set of parentheses. Sometimes this
7335 makes the machine description easier to read.
7337 There is also a special syntax for strings, which can be useful when C
7338 code is embedded in a machine description. Wherever a string can
7339 appear, it is also valid to write a C-style brace block. The entire
7340 brace block, including the outermost pair of braces, is considered to be
7341 the string constant. Double quote characters inside the braces are not
7342 special. Therefore, if you write string constants in the C code, you
7343 need not escape each quote character with a backslash.
7345 A vector contains an arbitrary number of pointers to expressions. The
7346 number of elements in the vector is explicitly present in the vector.
7347 The written form of a vector consists of square brackets (`[...]')
7348 surrounding the elements, in sequence and with whitespace separating
7349 them. Vectors of length zero are not created; null pointers are used
7352 Expressions are classified by "expression codes" (also called RTX
7353 codes). The expression code is a name defined in `rtl.def', which is
7354 also (in uppercase) a C enumeration constant. The possible expression
7355 codes and their meanings are machine-independent. The code of an RTX
7356 can be extracted with the macro `GET_CODE (X)' and altered with
7357 `PUT_CODE (X, NEWCODE)'.
7359 The expression code determines how many operands the expression
7360 contains, and what kinds of objects they are. In RTL, unlike Lisp, you
7361 cannot tell by looking at an operand what kind of object it is.
7362 Instead, you must know from its context--from the expression code of
7363 the containing expression. For example, in an expression of code
7364 `subreg', the first operand is to be regarded as an expression and the
7365 second operand as an integer. In an expression of code `plus', there
7366 are two operands, both of which are to be regarded as expressions. In
7367 a `symbol_ref' expression, there is one operand, which is to be
7368 regarded as a string.
7370 Expressions are written as parentheses containing the name of the
7371 expression type, its flags and machine mode if any, and then the
7372 operands of the expression (separated by spaces).
7374 Expression code names in the `md' file are written in lowercase, but
7375 when they appear in C code they are written in uppercase. In this
7376 manual, they are shown as follows: `const_int'.
7378 In a few contexts a null pointer is valid where an expression is
7379 normally wanted. The written form of this is `(nil)'.
7382 File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL
7384 11.2 RTL Classes and Formats
7385 ============================
7387 The various expression codes are divided into several "classes", which
7388 are represented by single characters. You can determine the class of
7389 an RTX code with the macro `GET_RTX_CLASS (CODE)'. Currently,
7390 `rtl.def' defines these classes:
7393 An RTX code that represents an actual object, such as a register
7394 (`REG') or a memory location (`MEM', `SYMBOL_REF'). `LO_SUM') is
7395 also included; instead, `SUBREG' and `STRICT_LOW_PART' are not in
7396 this class, but in class `x'.
7399 An RTX code that represents a constant object. `HIGH' is also
7400 included in this class.
7403 An RTX code for a non-symmetric comparison, such as `GEU' or `LT'.
7406 An RTX code for a symmetric (commutative) comparison, such as `EQ'
7410 An RTX code for a unary arithmetic operation, such as `NEG',
7411 `NOT', or `ABS'. This category also includes value extension
7412 (sign or zero) and conversions between integer and floating point.
7415 An RTX code for a commutative binary operation, such as `PLUS' or
7416 `AND'. `NE' and `EQ' are comparisons, so they have class `<'.
7419 An RTX code for a non-commutative binary operation, such as
7420 `MINUS', `DIV', or `ASHIFTRT'.
7423 An RTX code for a bit-field operation. Currently only
7424 `ZERO_EXTRACT' and `SIGN_EXTRACT'. These have three inputs and
7425 are lvalues (so they can be used for insertion as well). *Note
7429 An RTX code for other three input operations. Currently only
7430 `IF_THEN_ELSE' and `VEC_MERGE'.
7433 An RTX code for an entire instruction: `INSN', `JUMP_INSN', and
7434 `CALL_INSN'. *Note Insns::.
7437 An RTX code for something that matches in insns, such as
7438 `MATCH_DUP'. These only occur in machine descriptions.
7441 An RTX code for an auto-increment addressing mode, such as
7445 All other RTX codes. This category includes the remaining codes
7446 used only in machine descriptions (`DEFINE_*', etc.). It also
7447 includes all the codes describing side effects (`SET', `USE',
7448 `CLOBBER', etc.) and the non-insns that may appear on an insn
7449 chain, such as `NOTE', `BARRIER', and `CODE_LABEL'. `SUBREG' is
7450 also part of this class.
7452 For each expression code, `rtl.def' specifies the number of contained
7453 objects and their kinds using a sequence of characters called the
7454 "format" of the expression code. For example, the format of `subreg'
7457 These are the most commonly used format characters:
7460 An expression (actually a pointer to an expression).
7472 A vector of expressions.
7474 A few other format characters are used occasionally:
7477 `u' is equivalent to `e' except that it is printed differently in
7478 debugging dumps. It is used for pointers to insns.
7481 `n' is equivalent to `i' except that it is printed differently in
7482 debugging dumps. It is used for the line number or code number of
7486 `S' indicates a string which is optional. In the RTL objects in
7487 core, `S' is equivalent to `s', but when the object is read, from
7488 an `md' file, the string value of this operand may be omitted. An
7489 omitted string is taken to be the null string.
7492 `V' indicates a vector which is optional. In the RTL objects in
7493 core, `V' is equivalent to `E', but when the object is read from
7494 an `md' file, the vector value of this operand may be omitted. An
7495 omitted vector is effectively the same as a vector of no elements.
7498 `B' indicates a pointer to basic block structure.
7501 `0' means a slot whose contents do not fit any normal category.
7502 `0' slots are not printed at all in dumps, and are often used in
7503 special ways by small parts of the compiler.
7505 There are macros to get the number of operands and the format of an
7508 `GET_RTX_LENGTH (CODE)'
7509 Number of operands of an RTX of code CODE.
7511 `GET_RTX_FORMAT (CODE)'
7512 The format of an RTX of code CODE, as a C string.
7514 Some classes of RTX codes always have the same format. For example, it
7515 is safe to assume that all comparison operations have format `ee'.
7518 All codes of this class have format `e'.
7523 All codes of these classes have format `ee'.
7527 All codes of these classes have format `eee'.
7530 All codes of this class have formats that begin with `iuueiee'.
7531 *Note Insns::. Note that not all RTL objects linked onto an insn
7532 chain are of class `i'.
7537 You can make no assumptions about the format of these codes.
7540 File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL
7542 11.3 Access to Operands
7543 =======================
7545 Operands of expressions are accessed using the macros `XEXP', `XINT',
7546 `XWINT' and `XSTR'. Each of these macros takes two arguments: an
7547 expression-pointer (RTX) and an operand number (counting from zero).
7552 accesses operand 2 of expression X, as an expression.
7556 accesses the same operand as an integer. `XSTR', used in the same
7557 fashion, would access it as a string.
7559 Any operand can be accessed as an integer, as an expression or as a
7560 string. You must choose the correct method of access for the kind of
7561 value actually stored in the operand. You would do this based on the
7562 expression code of the containing expression. That is also how you
7563 would know how many operands there are.
7565 For example, if X is a `subreg' expression, you know that it has two
7566 operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X,
7567 1)'. If you did `XINT (X, 0)', you would get the address of the
7568 expression operand but cast as an integer; that might occasionally be
7569 useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP
7570 (X, 1)' would also compile without error, and would return the second,
7571 integer operand cast as an expression pointer, which would probably
7572 result in a crash when accessed. Nothing stops you from writing `XEXP
7573 (X, 28)' either, but this will access memory past the end of the
7574 expression with unpredictable results.
7576 Access to operands which are vectors is more complicated. You can use
7577 the macro `XVEC' to get the vector-pointer itself, or the macros
7578 `XVECEXP' and `XVECLEN' to access the elements and length of a vector.
7581 Access the vector-pointer which is operand number IDX in EXP.
7583 `XVECLEN (EXP, IDX)'
7584 Access the length (number of elements) in the vector which is in
7585 operand number IDX in EXP. This value is an `int'.
7587 `XVECEXP (EXP, IDX, ELTNUM)'
7588 Access element number ELTNUM in the vector which is in operand
7589 number IDX in EXP. This value is an RTX.
7591 It is up to you to make sure that ELTNUM is not negative and is
7592 less than `XVECLEN (EXP, IDX)'.
7594 All the macros defined in this section expand into lvalues and
7595 therefore can be used to assign the operands, lengths and vector
7596 elements as well as to access them.
7599 File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL
7601 11.4 Access to Special Operands
7602 ===============================
7604 Some RTL nodes have special annotations associated with them.
7609 If 0, X is not in any alias set, and may alias anything.
7610 Otherwise, X can only alias `MEM's in a conflicting alias
7611 set. This value is set in a language-dependent manner in the
7612 front-end, and should not be altered in the back-end. In
7613 some front-ends, these numbers may correspond in some way to
7614 types, or other language-level entities, but they need not,
7615 and the back-end makes no such assumptions. These set
7616 numbers are tested with `alias_sets_conflict_p'.
7619 If this register is known to hold the value of some user-level
7620 declaration, this is that tree node. It may also be a
7621 `COMPONENT_REF', in which case this is some field reference,
7622 and `TREE_OPERAND (X, 0)' contains the declaration, or
7623 another `COMPONENT_REF', or null if there is no compile-time
7624 object associated with the reference.
7627 The offset from the start of `MEM_EXPR' as a `CONST_INT' rtx.
7630 The size in bytes of the memory reference as a `CONST_INT'
7631 rtx. This is mostly relevant for `BLKmode' references as
7632 otherwise the size is implied by the mode.
7635 The known alignment in bits of the memory reference.
7639 `ORIGINAL_REGNO (X)'
7640 This field holds the number the register "originally" had;
7641 for a pseudo register turned into a hard reg this will hold
7642 the old pseudo register number.
7645 If this register is known to hold the value of some user-level
7646 declaration, this is that tree node.
7649 If this register is known to hold the value of some user-level
7650 declaration, this is the offset into that logical storage.
7654 `SYMBOL_REF_DECL (X)'
7655 If the `symbol_ref' X was created for a `VAR_DECL' or a
7656 `FUNCTION_DECL', that tree is recorded here. If this value is
7657 null, then X was created by back end code generation routines,
7658 and there is no associated front end symbol table entry.
7660 `SYMBOL_REF_DECL' may also point to a tree of class `'c'',
7661 that is, some sort of constant. In this case, the
7662 `symbol_ref' is an entry in the per-file constant pool;
7663 again, there is no associated front end symbol table entry.
7665 `SYMBOL_REF_FLAGS (X)'
7666 In a `symbol_ref', this is used to communicate various
7667 predicates about the symbol. Some of these are common enough
7668 to be computed by common code, some are specific to the
7669 target. The common bits are:
7671 `SYMBOL_FLAG_FUNCTION'
7672 Set if the symbol refers to a function.
7675 Set if the symbol is local to this "module". See
7676 `TARGET_BINDS_LOCAL_P'.
7678 `SYMBOL_FLAG_EXTERNAL'
7679 Set if this symbol is not defined in this translation
7680 unit. Note that this is not the inverse of
7681 `SYMBOL_FLAG_LOCAL'.
7684 Set if the symbol is located in the small data section.
7685 See `TARGET_IN_SMALL_DATA_P'.
7687 `SYMBOL_REF_TLS_MODEL (X)'
7688 This is a multi-bit field accessor that returns the
7689 `tls_model' to be used for a thread-local storage
7690 symbol. It returns zero for non-thread-local symbols.
7692 Bits beginning with `SYMBOL_FLAG_MACH_DEP' are available for
7696 File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL
7698 11.5 Flags in an RTL Expression
7699 ===============================
7701 RTL expressions contain several flags (one-bit bit-fields) that are
7702 used in certain types of expression. Most often they are accessed with
7703 the following macros, which expand into lvalues.
7705 `CONSTANT_POOL_ADDRESS_P (X)'
7706 Nonzero in a `symbol_ref' if it refers to part of the current
7707 function's constant pool. For most targets these addresses are in
7708 a `.rodata' section entirely separate from the function, but for
7709 some targets the addresses are close to the beginning of the
7710 function. In either case GCC assumes these addresses can be
7711 addressed directly, perhaps with the help of base registers.
7712 Stored in the `unchanging' field and printed as `/u'.
7714 `CONST_OR_PURE_CALL_P (X)'
7715 In a `call_insn', `note', or an `expr_list' for notes, indicates
7716 that the insn represents a call to a const or pure function.
7717 Stored in the `unchanging' field and printed as `/u'.
7719 `INSN_ANNULLED_BRANCH_P (X)'
7720 In a `jump_insn', `call_insn', or `insn' indicates that the branch
7721 is an annulling one. See the discussion under `sequence' below.
7722 Stored in the `unchanging' field and printed as `/u'.
7724 `INSN_DELETED_P (X)'
7725 In an `insn', `call_insn', `jump_insn', `code_label', `barrier',
7726 or `note', nonzero if the insn has been deleted. Stored in the
7727 `volatil' field and printed as `/v'.
7729 `INSN_FROM_TARGET_P (X)'
7730 In an `insn' or `jump_insn' or `call_insn' in a delay slot of a
7731 branch, indicates that the insn is from the target of the branch.
7732 If the branch insn has `INSN_ANNULLED_BRANCH_P' set, this insn
7733 will only be executed if the branch is taken. For annulled
7734 branches with `INSN_FROM_TARGET_P' clear, the insn will be
7735 executed only if the branch is not taken. When
7736 `INSN_ANNULLED_BRANCH_P' is not set, this insn will always be
7737 executed. Stored in the `in_struct' field and printed as `/s'.
7739 `LABEL_OUTSIDE_LOOP_P (X)'
7740 In `label_ref' expressions, nonzero if this is a reference to a
7741 label that is outside the innermost loop containing the reference
7742 to the label. Stored in the `in_struct' field and printed as `/s'.
7744 `LABEL_PRESERVE_P (X)'
7745 In a `code_label' or `note', indicates that the label is
7746 referenced by code or data not visible to the RTL of a given
7747 function. Labels referenced by a non-local goto will have this
7748 bit set. Stored in the `in_struct' field and printed as `/s'.
7750 `LABEL_REF_NONLOCAL_P (X)'
7751 In `label_ref' and `reg_label' expressions, nonzero if this is a
7752 reference to a non-local label. Stored in the `volatil' field and
7755 `MEM_IN_STRUCT_P (X)'
7756 In `mem' expressions, nonzero for reference to an entire structure,
7757 union or array, or to a component of one. Zero for references to a
7758 scalar variable or through a pointer to a scalar. If both this
7759 flag and `MEM_SCALAR_P' are clear, then we don't know whether this
7760 `mem' is in a structure or not. Both flags should never be
7761 simultaneously set. Stored in the `in_struct' field and printed
7764 `MEM_KEEP_ALIAS_SET_P (X)'
7765 In `mem' expressions, 1 if we should keep the alias set for this
7766 mem unchanged when we access a component. Set to 1, for example,
7767 when we are already in a non-addressable component of an aggregate.
7768 Stored in the `jump' field and printed as `/j'.
7771 In `mem' expressions, nonzero for reference to a scalar known not
7772 to be a member of a structure, union, or array. Zero for such
7773 references and for indirections through pointers, even pointers
7774 pointing to scalar types. If both this flag and `MEM_IN_STRUCT_P'
7775 are clear, then we don't know whether this `mem' is in a structure
7776 or not. Both flags should never be simultaneously set. Stored in
7777 the `frame_related' field and printed as `/f'.
7779 `MEM_VOLATILE_P (X)'
7780 In `mem', `asm_operands', and `asm_input' expressions, nonzero for
7781 volatile memory references. Stored in the `volatil' field and
7785 In `mem', nonzero for memory references that will not trap.
7786 Stored in the `call' field and printed as `/c'.
7788 `REG_FUNCTION_VALUE_P (X)'
7789 Nonzero in a `reg' if it is the place in which this function's
7790 value is going to be returned. (This happens only in a hard
7791 register.) Stored in the `integrated' field and printed as `/i'.
7794 Nonzero in a `reg' if the register holds a pointer. Stored in the
7795 `frame_related' field and printed as `/f'.
7798 In a `reg', nonzero if it corresponds to a variable present in the
7799 user's source code. Zero for temporaries generated internally by
7800 the compiler. Stored in the `volatil' field and printed as `/v'.
7802 The same hard register may be used also for collecting the values
7803 of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero
7804 in this kind of use.
7806 `RTX_FRAME_RELATED_P (X)'
7807 Nonzero in an `insn', `call_insn', `jump_insn', `barrier', or
7808 `set' which is part of a function prologue and sets the stack
7809 pointer, sets the frame pointer, or saves a register. This flag
7810 should also be set on an instruction that sets up a temporary
7811 register to use in place of the frame pointer. Stored in the
7812 `frame_related' field and printed as `/f'.
7814 In particular, on RISC targets where there are limits on the sizes
7815 of immediate constants, it is sometimes impossible to reach the
7816 register save area directly from the stack pointer. In that case,
7817 a temporary register is used that is near enough to the register
7818 save area, and the Canonical Frame Address, i.e., DWARF2's logical
7819 frame pointer, register must (temporarily) be changed to be this
7820 temporary register. So, the instruction that sets this temporary
7821 register must be marked as `RTX_FRAME_RELATED_P'.
7823 If the marked instruction is overly complex (defined in terms of
7824 what `dwarf2out_frame_debug_expr' can handle), you will also have
7825 to create a `REG_FRAME_RELATED_EXPR' note and attach it to the
7826 instruction. This note should contain a simple expression of the
7827 computation performed by this instruction, i.e., one that
7828 `dwarf2out_frame_debug_expr' can handle.
7830 This flag is required for exception handling support on targets
7833 `code_label', `insn_list', `const', or `note' if it resulted from
7834 an in-line function call. Stored in the `integrated' field and
7837 `MEM_READONLY_P (X)'
7838 Nonzero in a `mem', if the memory is statically allocated and
7841 Read-only in this context means never modified during the lifetime
7842 of the program, not necessarily in ROM or in write-disabled pages.
7843 A common example of the later is a shared library's global offset
7844 table. This table is initialized by the runtime loader, so the
7845 memory is technically writable, but after control is transfered
7846 from the runtime loader to the application, this memory will never
7847 be subsequently modified.
7849 Stored in the `unchanging' field and printed as `/u'.
7852 During instruction scheduling, in an `insn', `call_insn' or
7853 `jump_insn', indicates that the previous insn must be scheduled
7854 together with this insn. This is used to ensure that certain
7855 groups of instructions will not be split up by the instruction
7856 scheduling pass, for example, `use' insns before a `call_insn' may
7857 not be separated from the `call_insn'. Stored in the `in_struct'
7858 field and printed as `/s'.
7860 `SET_IS_RETURN_P (X)'
7861 For a `set', nonzero if it is for a return. Stored in the `jump'
7862 field and printed as `/j'.
7864 `SIBLING_CALL_P (X)'
7865 For a `call_insn', nonzero if the insn is a sibling call. Stored
7866 in the `jump' field and printed as `/j'.
7868 `STRING_POOL_ADDRESS_P (X)'
7869 For a `symbol_ref' expression, nonzero if it addresses this
7870 function's string constant pool. Stored in the `frame_related'
7871 field and printed as `/f'.
7873 `SUBREG_PROMOTED_UNSIGNED_P (X)'
7874 Returns a value greater then zero for a `subreg' that has
7875 `SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is
7876 kept zero-extended, zero if it is kept sign-extended, and less
7877 then zero if it is extended some other way via the `ptr_extend'
7878 instruction. Stored in the `unchanging' field and `volatil'
7879 field, printed as `/u' and `/v'. This macro may only be used to
7880 get the value it may not be used to change the value. Use
7881 `SUBREG_PROMOTED_UNSIGNED_SET' to change the value.
7883 `SUBREG_PROMOTED_UNSIGNED_SET (X)'
7884 Set the `unchanging' and `volatil' fields in a `subreg' to reflect
7885 zero, sign, or other extension. If `volatil' is zero, then
7886 `unchanging' as nonzero means zero extension and as zero means
7887 sign extension. If `volatil' is nonzero then some other type of
7888 extension was done via the `ptr_extend' instruction.
7890 `SUBREG_PROMOTED_VAR_P (X)'
7891 Nonzero in a `subreg' if it was made when accessing an object that
7892 was promoted to a wider mode in accord with the `PROMOTED_MODE'
7893 machine description macro (*note Storage Layout::). In this case,
7894 the mode of the `subreg' is the declared mode of the object and
7895 the mode of `SUBREG_REG' is the mode of the register that holds
7896 the object. Promoted variables are always either sign- or
7897 zero-extended to the wider mode on every assignment. Stored in
7898 the `in_struct' field and printed as `/s'.
7900 `SYMBOL_REF_USED (X)'
7901 In a `symbol_ref', indicates that X has been used. This is
7902 normally only used to ensure that X is only declared external
7903 once. Stored in the `used' field.
7905 `SYMBOL_REF_WEAK (X)'
7906 In a `symbol_ref', indicates that X has been declared weak.
7907 Stored in the `integrated' field and printed as `/i'.
7909 `SYMBOL_REF_FLAG (X)'
7910 In a `symbol_ref', this is used as a flag for machine-specific
7911 purposes. Stored in the `volatil' field and printed as `/v'.
7913 Most uses of `SYMBOL_REF_FLAG' are historic and may be subsumed by
7914 `SYMBOL_REF_FLAGS'. Certainly use of `SYMBOL_REF_FLAGS' is
7915 mandatory if the target requires more than one bit of storage.
7917 These are the fields to which the above macros refer:
7920 In a `mem', 1 means that the memory reference will not trap.
7922 In an RTL dump, this flag is represented as `/c'.
7925 In an `insn' or `set' expression, 1 means that it is part of a
7926 function prologue and sets the stack pointer, sets the frame
7927 pointer, saves a register, or sets up a temporary register to use
7928 in place of the frame pointer.
7930 In `reg' expressions, 1 means that the register holds a pointer.
7932 In `symbol_ref' expressions, 1 means that the reference addresses
7933 this function's string constant pool.
7935 In `mem' expressions, 1 means that the reference is to a scalar.
7937 In an RTL dump, this flag is represented as `/f'.
7940 In `mem' expressions, it is 1 if the memory datum referred to is
7941 all or part of a structure or array; 0 if it is (or might be) a
7942 scalar variable. A reference through a C pointer has 0 because
7943 the pointer might point to a scalar variable. This information
7944 allows the compiler to determine something about possible cases of
7947 In `reg' expressions, it is 1 if the register has its entire life
7948 contained within the test expression of some loop.
7950 In `subreg' expressions, 1 means that the `subreg' is accessing an
7951 object that has had its mode promoted from a wider mode.
7953 In `label_ref' expressions, 1 means that the referenced label is
7954 outside the innermost loop containing the insn in which the
7955 `label_ref' was found.
7957 In `code_label' expressions, it is 1 if the label may never be
7958 deleted. This is used for labels which are the target of
7959 non-local gotos. Such a label that would have been deleted is
7960 replaced with a `note' of type `NOTE_INSN_DELETED_LABEL'.
7962 In an `insn' during dead-code elimination, 1 means that the insn is
7965 In an `insn' or `jump_insn' during reorg for an insn in the delay
7966 slot of a branch, 1 means that this insn is from the target of the
7969 In an `insn' during instruction scheduling, 1 means that this insn
7970 must be scheduled as part of a group together with the previous
7973 In an RTL dump, this flag is represented as `/s'.
7976 In an `insn', `insn_list', or `const', 1 means the RTL was
7977 produced by procedure integration.
7979 In `reg' expressions, 1 means the register contains the value to
7980 be returned by the current function. On machines that pass
7981 parameters in registers, the same register number may be used for
7982 parameters as well, but this flag is not set on such uses.
7984 In `symbol_ref' expressions, 1 means the referenced symbol is weak.
7986 In an RTL dump, this flag is represented as `/i'.
7989 In a `mem' expression, 1 means we should keep the alias set for
7990 this mem unchanged when we access a component.
7992 In a `set', 1 means it is for a return.
7994 In a `call_insn', 1 means it is a sibling call.
7996 In an RTL dump, this flag is represented as `/j'.
7999 In `reg' and `mem' expressions, 1 means that the value of the
8000 expression never changes.
8002 In `subreg' expressions, it is 1 if the `subreg' references an
8003 unsigned object whose mode has been promoted to a wider mode.
8005 In an `insn' or `jump_insn' in the delay slot of a branch
8006 instruction, 1 means an annulling branch should be used.
8008 In a `symbol_ref' expression, 1 means that this symbol addresses
8009 something in the per-function constant pool.
8011 In a `call_insn', `note', or an `expr_list' of notes, 1 means that
8012 this instruction is a call to a const or pure function.
8014 In an RTL dump, this flag is represented as `/u'.
8017 This flag is used directly (without an access macro) at the end of
8018 RTL generation for a function, to count the number of times an
8019 expression appears in insns. Expressions that appear more than
8020 once are copied, according to the rules for shared structure
8023 For a `reg', it is used directly (without an access macro) by the
8024 leaf register renumbering code to ensure that each register is only
8027 In a `symbol_ref', it indicates that an external declaration for
8028 the symbol has already been written.
8031 In a `mem', `asm_operands', or `asm_input' expression, it is 1 if
8032 the memory reference is volatile. Volatile memory references may
8033 not be deleted, reordered or combined.
8035 In a `symbol_ref' expression, it is used for machine-specific
8038 In a `reg' expression, it is 1 if the value is a user-level
8039 variable. 0 indicates an internal compiler temporary.
8041 In an `insn', 1 means the insn has been deleted.
8043 In `label_ref' and `reg_label' expressions, 1 means a reference to
8046 In an RTL dump, this flag is represented as `/v'.
8049 File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL
8054 A machine mode describes a size of data object and the representation
8055 used for it. In the C code, machine modes are represented by an
8056 enumeration type, `enum machine_mode', defined in `machmode.def'. Each
8057 RTL expression has room for a machine mode and so do certain kinds of
8058 tree expressions (declarations and types, to be precise).
8060 In debugging dumps and machine descriptions, the machine mode of an RTL
8061 expression is written after the expression code with a colon to separate
8062 them. The letters `mode' which appear at the end of each machine mode
8063 name are omitted. For example, `(reg:SI 38)' is a `reg' expression
8064 with machine mode `SImode'. If the mode is `VOIDmode', it is not
8067 Here is a table of machine modes. The term "byte" below refers to an
8068 object of `BITS_PER_UNIT' bits (*note Storage Layout::).
8071 "Bit" mode represents a single bit, for predicate registers.
8074 "Quarter-Integer" mode represents a single byte treated as an
8078 "Half-Integer" mode represents a two-byte integer.
8081 "Partial Single Integer" mode represents an integer which occupies
8082 four bytes but which doesn't really use all four. On some
8083 machines, this is the right mode to use for pointers.
8086 "Single Integer" mode represents a four-byte integer.
8089 "Partial Double Integer" mode represents an integer which occupies
8090 eight bytes but which doesn't really use all eight. On some
8091 machines, this is the right mode to use for certain pointers.
8094 "Double Integer" mode represents an eight-byte integer.
8097 "Tetra Integer" (?) mode represents a sixteen-byte integer.
8100 "Octa Integer" (?) mode represents a thirty-two-byte integer.
8103 "Quarter-Floating" mode represents a quarter-precision (single
8104 byte) floating point number.
8107 "Half-Floating" mode represents a half-precision (two byte)
8108 floating point number.
8111 "Three-Quarter-Floating" (?) mode represents a
8112 three-quarter-precision (three byte) floating point number.
8115 "Single Floating" mode represents a four byte floating point
8116 number. In the common case, of a processor with IEEE arithmetic
8117 and 8-bit bytes, this is a single-precision IEEE floating point
8118 number; it can also be used for double-precision (on processors
8119 with 16-bit bytes) and single-precision VAX and IBM types.
8122 "Double Floating" mode represents an eight byte floating point
8123 number. In the common case, of a processor with IEEE arithmetic
8124 and 8-bit bytes, this is a double-precision IEEE floating point
8128 "Extended Floating" mode represents an IEEE extended floating point
8129 number. This mode only has 80 meaningful bits (ten bytes). Some
8130 processors require such numbers to be padded to twelve bytes,
8131 others to sixteen; this mode is used for either.
8134 "Tetra Floating" mode represents a sixteen byte floating point
8135 number all 128 of whose bits are meaningful. One common use is the
8136 IEEE quad-precision format.
8139 "Condition Code" mode represents the value of a condition code,
8140 which is a machine-specific set of bits used to represent the
8141 result of a comparison operation. Other machine-specific modes
8142 may also be used for the condition code. These modes are not used
8143 on machines that use `cc0' (see *note Condition Code::).
8146 "Block" mode represents values that are aggregates to which none of
8147 the other modes apply. In RTL, only memory references can have
8148 this mode, and only if they appear in string-move or vector
8149 instructions. On machines which have no such instructions,
8150 `BLKmode' will not appear in RTL.
8153 Void mode means the absence of a mode or an unspecified mode. For
8154 example, RTL expressions of code `const_int' have mode `VOIDmode'
8155 because they can be taken to have whatever mode the context
8156 requires. In debugging dumps of RTL, `VOIDmode' is expressed by
8157 the absence of any mode.
8159 `QCmode, HCmode, SCmode, DCmode, XCmode, TCmode'
8160 These modes stand for a complex number represented as a pair of
8161 floating point values. The floating point values are in `QFmode',
8162 `HFmode', `SFmode', `DFmode', `XFmode', and `TFmode', respectively.
8164 `CQImode, CHImode, CSImode, CDImode, CTImode, COImode'
8165 These modes stand for a complex number represented as a pair of
8166 integer values. The integer values are in `QImode', `HImode',
8167 `SImode', `DImode', `TImode', and `OImode', respectively.
8169 The machine description defines `Pmode' as a C macro which expands
8170 into the machine mode used for addresses. Normally this is the mode
8171 whose size is `BITS_PER_WORD', `SImode' on 32-bit machines.
8173 The only modes which a machine description must support are `QImode',
8174 and the modes corresponding to `BITS_PER_WORD', `FLOAT_TYPE_SIZE' and
8175 `DOUBLE_TYPE_SIZE'. The compiler will attempt to use `DImode' for
8176 8-byte structures and unions, but this can be prevented by overriding
8177 the definition of `MAX_FIXED_MODE_SIZE'. Alternatively, you can have
8178 the compiler use `TImode' for 16-byte structures and unions. Likewise,
8179 you can arrange for the C type `short int' to avoid using `HImode'.
8181 Very few explicit references to machine modes remain in the compiler
8182 and these few references will soon be removed. Instead, the machine
8183 modes are divided into mode classes. These are represented by the
8184 enumeration type `enum mode_class' defined in `machmode.h'. The
8185 possible mode classes are:
8188 Integer modes. By default these are `BImode', `QImode', `HImode',
8189 `SImode', `DImode', `TImode', and `OImode'.
8192 The "partial integer" modes, `PQImode', `PHImode', `PSImode' and
8196 Floating point modes. By default these are `QFmode', `HFmode',
8197 `TQFmode', `SFmode', `DFmode', `XFmode' and `TFmode'.
8200 Complex integer modes. (These are not currently implemented).
8202 `MODE_COMPLEX_FLOAT'
8203 Complex floating point modes. By default these are `QCmode',
8204 `HCmode', `SCmode', `DCmode', `XCmode', and `TCmode'.
8207 Algol or Pascal function variables including a static chain.
8208 (These are not currently implemented).
8211 Modes representing condition code values. These are `CCmode' plus
8212 any `CC_MODE' modes listed in the `MACHINE-modes.def'. *Note Jump
8213 Patterns::, also see *Note Condition Code::.
8216 This is a catchall mode class for modes which don't fit into the
8217 above classes. Currently `VOIDmode' and `BLKmode' are in
8220 Here are some C macros that relate to machine modes:
8223 Returns the machine mode of the RTX X.
8225 `PUT_MODE (X, NEWMODE)'
8226 Alters the machine mode of the RTX X to be NEWMODE.
8229 Stands for the number of machine modes available on the target
8230 machine. This is one greater than the largest numeric value of any
8234 Returns the name of mode M as a string.
8236 `GET_MODE_CLASS (M)'
8237 Returns the mode class of mode M.
8239 `GET_MODE_WIDER_MODE (M)'
8240 Returns the next wider natural mode. For example, the expression
8241 `GET_MODE_WIDER_MODE (QImode)' returns `HImode'.
8244 Returns the size in bytes of a datum of mode M.
8246 `GET_MODE_BITSIZE (M)'
8247 Returns the size in bits of a datum of mode M.
8250 Returns a bitmask containing 1 for all bits in a word that fit
8251 within mode M. This macro can only be used for modes whose
8252 bitsize is less than or equal to `HOST_BITS_PER_INT'.
8254 `GET_MODE_ALIGNMENT (M)'
8255 Return the required alignment, in bits, for an object of mode M.
8257 `GET_MODE_UNIT_SIZE (M)'
8258 Returns the size in bytes of the subunits of a datum of mode M.
8259 This is the same as `GET_MODE_SIZE' except in the case of complex
8260 modes. For them, the unit size is the size of the real or
8263 `GET_MODE_NUNITS (M)'
8264 Returns the number of units contained in a mode, i.e.,
8265 `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'.
8267 `GET_CLASS_NARROWEST_MODE (C)'
8268 Returns the narrowest mode in mode class C.
8270 The global variables `byte_mode' and `word_mode' contain modes whose
8271 classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or
8272 `BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode'
8273 and `SImode', respectively.
8276 File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL
8278 11.7 Constant Expression Types
8279 ==============================
8281 The simplest RTL expressions are those that represent constant values.
8284 This type of expression represents the integer value I. I is
8285 customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)',
8286 which is equivalent to `XWINT (EXP, 0)'.
8288 Constants generated for modes with fewer bits than `HOST_WIDE_INT'
8289 must be sign extended to full width (e.g., with `gen_int_mode').
8291 There is only one expression object for the integer value zero; it
8292 is the value of the variable `const0_rtx'. Likewise, the only
8293 expression for integer value one is found in `const1_rtx', the only
8294 expression for integer value two is found in `const2_rtx', and the
8295 only expression for integer value negative one is found in
8296 `constm1_rtx'. Any attempt to create an expression of code
8297 `const_int' and value zero, one, two or negative one will return
8298 `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as
8301 Similarly, there is only one object for the integer whose value is
8302 `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If
8303 `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will
8304 point to the same object. If `STORE_FLAG_VALUE' is -1,
8305 `const_true_rtx' and `constm1_rtx' will point to the same object.
8307 `(const_double:M ADDR I0 I1 ...)'
8308 Represents either a floating-point constant of mode M or an
8309 integer constant too large to fit into `HOST_BITS_PER_WIDE_INT'
8310 bits but small enough to fit within twice that number of bits (GCC
8311 does not provide a mechanism to represent even larger constants).
8312 In the latter case, M will be `VOIDmode'.
8314 `(const_vector:M [X0 X1 ...])'
8315 Represents a vector constant. The square brackets stand for the
8316 vector containing the constant elements. X0, X1 and so on are the
8317 `const_int' or `const_double' elements.
8319 The number of units in a `const_vector' is obtained with the macro
8320 `CONST_VECTOR_NUNITS' as in `CONST_VECTOR_NUNITS (V)'.
8322 Individual elements in a vector constant are accessed with the
8323 macro `CONST_VECTOR_ELT' as in `CONST_VECTOR_ELT (V, N)' where V
8324 is the vector constant and N is the element desired.
8326 ADDR is used to contain the `mem' expression that corresponds to
8327 the location in memory that at which the constant can be found. If
8328 it has not been allocated a memory location, but is on the chain
8329 of all `const_double' expressions in this compilation (maintained
8330 using an undisplayed field), ADDR contains `const0_rtx'. If it is
8331 not on the chain, ADDR contains `cc0_rtx'. ADDR is customarily
8332 accessed with the macro `CONST_DOUBLE_MEM' and the chain field via
8333 `CONST_DOUBLE_CHAIN'.
8335 If M is `VOIDmode', the bits of the value are stored in I0 and I1.
8336 I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and
8337 I1 with `CONST_DOUBLE_HIGH'.
8339 If the constant is floating point (regardless of its precision),
8340 then the number of integers used to store the value depends on the
8341 size of `REAL_VALUE_TYPE' (*note Floating Point::). The integers
8342 represent a floating point number, but not precisely in the target
8343 machine's or host machine's floating point format. To convert
8344 them to the precise bit pattern used by the target machine, use
8345 the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data
8348 The macro `CONST0_RTX (MODE)' refers to an expression with value 0
8349 in mode MODE. If mode MODE is of mode class `MODE_INT', it
8350 returns `const0_rtx'. If mode MODE is of mode class `MODE_FLOAT',
8351 it returns a `CONST_DOUBLE' expression in mode MODE. Otherwise,
8352 it returns a `CONST_VECTOR' expression in mode MODE. Similarly,
8353 the macro `CONST1_RTX (MODE)' refers to an expression with value 1
8354 in mode MODE and similarly for `CONST2_RTX'. The `CONST1_RTX' and
8355 `CONST2_RTX' macros are undefined for vector modes.
8357 `(const_string STR)'
8358 Represents a constant string with value STR. Currently this is
8359 used only for insn attributes (*note Insn Attributes::) since
8360 constant strings in C are placed in memory.
8362 `(symbol_ref:MODE SYMBOL)'
8363 Represents the value of an assembler label for data. SYMBOL is a
8364 string that describes the name of the assembler label. If it
8365 starts with a `*', the label is the rest of SYMBOL not including
8366 the `*'. Otherwise, the label is SYMBOL, usually prefixed with
8369 The `symbol_ref' contains a mode, which is usually `Pmode'.
8370 Usually that is the only mode for which a symbol is directly valid.
8372 `(label_ref:MODE LABEL)'
8373 Represents the value of an assembler label for code. It contains
8374 one operand, an expression, which must be a `code_label' or a
8375 `note' of type `NOTE_INSN_DELETED_LABEL' that appears in the
8376 instruction sequence to identify the place where the label should
8379 The reason for using a distinct expression type for code label
8380 references is so that jump optimization can distinguish them.
8382 The `label_ref' contains a mode, which is usually `Pmode'.
8383 Usually that is the only mode for which a label is directly valid.
8386 Represents a constant that is the result of an assembly-time
8387 arithmetic computation. The operand, EXP, is an expression that
8388 contains only constants (`const_int', `symbol_ref' and `label_ref'
8389 expressions) combined with `plus' and `minus'. However, not all
8390 combinations are valid, since the assembler cannot do arbitrary
8391 arithmetic on relocatable symbols.
8393 M should be `Pmode'.
8396 Represents the high-order bits of EXP, usually a `symbol_ref'.
8397 The number of bits is machine-dependent and is normally the number
8398 of bits specified in an instruction that initializes the high
8399 order bits of a register. It is used with `lo_sum' to represent
8400 the typical two-instruction sequence used in RISC machines to
8401 reference a global memory location.
8403 M should be `Pmode'.
8406 File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL
8408 11.8 Registers and Memory
8409 =========================
8411 Here are the RTL expression types for describing access to machine
8412 registers and to main memory.
8415 For small values of the integer N (those that are less than
8416 `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine
8417 register number N: a "hard register". For larger values of N, it
8418 stands for a temporary value or "pseudo register". The compiler's
8419 strategy is to generate code assuming an unlimited number of such
8420 pseudo registers, and later convert them into hard registers or
8421 into memory references.
8423 M is the machine mode of the reference. It is necessary because
8424 machines can generally refer to each register in more than one
8425 mode. For example, a register may contain a full word but there
8426 may be instructions to refer to it as a half word or as a single
8427 byte, as well as instructions to refer to it as a floating point
8428 number of various precisions.
8430 Even for a register that the machine can access in only one mode,
8431 the mode must always be specified.
8433 The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine
8434 description, since the number of hard registers on the machine is
8435 an invariant characteristic of the machine. Note, however, that
8436 not all of the machine registers must be general registers. All
8437 the machine registers that can be used for storage of data are
8438 given hard register numbers, even those that can be used only in
8439 certain instructions or can hold only certain types of data.
8441 A hard register may be accessed in various modes throughout one
8442 function, but each pseudo register is given a natural mode and is
8443 accessed only in that mode. When it is necessary to describe an
8444 access to a pseudo register using a nonnatural mode, a `subreg'
8447 A `reg' expression with a machine mode that specifies more than
8448 one word of data may actually stand for several consecutive
8449 registers. If in addition the register number specifies a
8450 hardware register, then it actually represents several consecutive
8451 hardware registers starting with the specified one.
8453 Each pseudo register number used in a function's RTL code is
8454 represented by a unique `reg' expression.
8456 Some pseudo register numbers, those within the range of
8457 `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear
8458 during the RTL generation phase and are eliminated before the
8459 optimization phases. These represent locations in the stack frame
8460 that cannot be determined until RTL generation for the function
8461 has been completed. The following virtual register numbers are
8464 `VIRTUAL_INCOMING_ARGS_REGNUM'
8465 This points to the first word of the incoming arguments
8466 passed on the stack. Normally these arguments are placed
8467 there by the caller, but the callee may have pushed some
8468 arguments that were previously passed in registers.
8470 When RTL generation is complete, this virtual register is
8471 replaced by the sum of the register given by
8472 `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'.
8474 `VIRTUAL_STACK_VARS_REGNUM'
8475 If `FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this
8476 points to immediately above the first variable on the stack.
8477 Otherwise, it points to the first variable on the stack.
8479 `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the
8480 register given by `FRAME_POINTER_REGNUM' and the value
8481 `STARTING_FRAME_OFFSET'.
8483 `VIRTUAL_STACK_DYNAMIC_REGNUM'
8484 This points to the location of dynamically allocated memory
8485 on the stack immediately after the stack pointer has been
8486 adjusted by the amount of memory desired.
8488 This virtual register is replaced by the sum of the register
8489 given by `STACK_POINTER_REGNUM' and the value
8490 `STACK_DYNAMIC_OFFSET'.
8492 `VIRTUAL_OUTGOING_ARGS_REGNUM'
8493 This points to the location in the stack at which outgoing
8494 arguments should be written when the stack is pre-pushed
8495 (arguments pushed using push insns should always use
8496 `STACK_POINTER_REGNUM').
8498 This virtual register is replaced by the sum of the register
8499 given by `STACK_POINTER_REGNUM' and the value
8500 `STACK_POINTER_OFFSET'.
8502 `(subreg:M REG BYTENUM)'
8503 `subreg' expressions are used to refer to a register in a machine
8504 mode other than its natural one, or to refer to one register of a
8505 multi-part `reg' that actually refers to several registers.
8507 Each pseudo-register has a natural mode. If it is necessary to
8508 operate on it in a different mode--for example, to perform a
8509 fullword move instruction on a pseudo-register that contains a
8510 single byte--the pseudo-register must be enclosed in a `subreg'.
8511 In such a case, BYTENUM is zero.
8513 Usually M is at least as narrow as the mode of REG, in which case
8514 it is restricting consideration to only the bits of REG that are
8517 Sometimes M is wider than the mode of REG. These `subreg'
8518 expressions are often called "paradoxical". They are used in
8519 cases where we want to refer to an object in a wider mode but do
8520 not care what value the additional bits have. The reload pass
8521 ensures that paradoxical references are only made to hard
8524 The other use of `subreg' is to extract the individual registers of
8525 a multi-register value. Machine modes such as `DImode' and
8526 `TImode' can indicate values longer than a word, values which
8527 usually require two or more consecutive registers. To access one
8528 of the registers, use a `subreg' with mode `SImode' and a BYTENUM
8529 offset that says which register.
8531 Storing in a non-paradoxical `subreg' has undefined results for
8532 bits belonging to the same word as the `subreg'. This laxity makes
8533 it easier to generate efficient code for such instructions. To
8534 represent an instruction that preserves all the bits outside of
8535 those in the `subreg', use `strict_low_part' around the `subreg'.
8537 The compilation parameter `WORDS_BIG_ENDIAN', if set to 1, says
8538 that byte number zero is part of the most significant word;
8539 otherwise, it is part of the least significant word.
8541 The compilation parameter `BYTES_BIG_ENDIAN', if set to 1, says
8542 that byte number zero is the most significant byte within a word;
8543 otherwise, it is the least significant byte within a word.
8545 On a few targets, `FLOAT_WORDS_BIG_ENDIAN' disagrees with
8546 `WORDS_BIG_ENDIAN'. However, most parts of the compiler treat
8547 floating point values as if they had the same endianness as
8548 integer values. This works because they handle them solely as a
8549 collection of integer values, with no particular numerical value.
8550 Only real.c and the runtime libraries care about
8551 `FLOAT_WORDS_BIG_ENDIAN'.
8553 Between the combiner pass and the reload pass, it is possible to
8554 have a paradoxical `subreg' which contains a `mem' instead of a
8555 `reg' as its first operand. After the reload pass, it is also
8556 possible to have a non-paradoxical `subreg' which contains a
8557 `mem'; this usually occurs when the `mem' is a stack slot which
8558 replaced a pseudo register.
8560 Note that it is not valid to access a `DFmode' value in `SFmode'
8561 using a `subreg'. On some machines the most significant part of a
8562 `DFmode' value does not have the same format as a single-precision
8565 It is also not valid to access a single word of a multi-word value
8566 in a hard register when less registers can hold the value than
8567 would be expected from its size. For example, some 32-bit
8568 machines have floating-point registers that can hold an entire
8569 `DFmode' value. If register 10 were such a register `(subreg:SI
8570 (reg:DF 10) 4)' would be invalid because there is no way to
8571 convert that reference to a single machine register. The reload
8572 pass prevents `subreg' expressions such as these from being formed.
8574 The first operand of a `subreg' expression is customarily accessed
8575 with the `SUBREG_REG' macro and the second operand is customarily
8576 accessed with the `SUBREG_BYTE' macro.
8579 This represents a scratch register that will be required for the
8580 execution of a single instruction and not used subsequently. It is
8581 converted into a `reg' by either the local register allocator or
8584 `scratch' is usually present inside a `clobber' operation (*note
8588 This refers to the machine's condition code register. It has no
8589 operands and may not have a machine mode. There are two ways to
8592 * To stand for a complete set of condition code flags. This is
8593 best on most machines, where each comparison sets the entire
8596 With this technique, `(cc0)' may be validly used in only two
8597 contexts: as the destination of an assignment (in test and
8598 compare instructions) and in comparison operators comparing
8599 against zero (`const_int' with value zero; that is to say,
8602 * To stand for a single flag that is the result of a single
8603 condition. This is useful on machines that have only a
8604 single flag bit, and in which comparison instructions must
8605 specify the condition to test.
8607 With this technique, `(cc0)' may be validly used in only two
8608 contexts: as the destination of an assignment (in test and
8609 compare instructions) where the source is a comparison
8610 operator, and as the first operand of `if_then_else' (in a
8611 conditional branch).
8613 There is only one expression object of code `cc0'; it is the value
8614 of the variable `cc0_rtx'. Any attempt to create an expression of
8615 code `cc0' will return `cc0_rtx'.
8617 Instructions can set the condition code implicitly. On many
8618 machines, nearly all instructions set the condition code based on
8619 the value that they compute or store. It is not necessary to
8620 record these actions explicitly in the RTL because the machine
8621 description includes a prescription for recognizing the
8622 instructions that do so (by means of the macro
8623 `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions
8624 whose sole purpose is to set the condition code, and instructions
8625 that use the condition code, need mention `(cc0)'.
8627 On some machines, the condition code register is given a register
8628 number and a `reg' is used instead of `(cc0)'. This is usually the
8629 preferable approach if only a small subset of instructions modify
8630 the condition code. Other machines store condition codes in
8631 general registers; in such cases a pseudo register should be used.
8633 Some machines, such as the SPARC and RS/6000, have two sets of
8634 arithmetic instructions, one that sets and one that does not set
8635 the condition code. This is best handled by normally generating
8636 the instruction that does not set the condition code, and making a
8637 pattern that both performs the arithmetic and sets the condition
8638 code register (which would not be `(cc0)' in this case). For
8639 examples, search for `addcc' and `andcc' in `sparc.md'.
8642 This represents the machine's program counter. It has no operands
8643 and may not have a machine mode. `(pc)' may be validly used only
8644 in certain specific contexts in jump instructions.
8646 There is only one expression object of code `pc'; it is the value
8647 of the variable `pc_rtx'. Any attempt to create an expression of
8648 code `pc' will return `pc_rtx'.
8650 All instructions that do not jump alter the program counter
8651 implicitly by incrementing it, but there is no need to mention
8654 `(mem:M ADDR ALIAS)'
8655 This RTX represents a reference to main memory at an address
8656 represented by the expression ADDR. M specifies how large a unit
8657 of memory is accessed. ALIAS specifies an alias set for the
8658 reference. In general two items are in different alias sets if
8659 they cannot reference the same memory address.
8661 The construct `(mem:BLK (scratch))' is considered to alias all
8662 other memories. Thus it may be used as a memory barrier in
8663 epilogue stack deallocation patterns.
8666 This RTX represents a request for the address of register REG.
8667 Its mode is always `Pmode'. If there are any `addressof'
8668 expressions left in the function after CSE, REG is forced into the
8669 stack and the `addressof' expression is replaced with a `plus'
8670 expression for the address of its stack slot.
8673 File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL
8675 11.9 RTL Expressions for Arithmetic
8676 ===================================
8678 Unless otherwise specified, all the operands of arithmetic expressions
8679 must be valid for mode M. An operand is valid for mode M if it has
8680 mode M, or if it is a `const_int' or `const_double' and M is a mode of
8683 For commutative binary operations, constants should be placed in the
8689 These three expressions all represent the sum of the values
8690 represented by X and Y carried out in machine mode M. They differ
8691 in their behavior on overflow of integer modes. `plus' wraps
8692 round modulo the width of M; `ss_plus' saturates at the maximum
8693 signed value representable in M; `us_plus' saturates at the
8694 maximum unsigned value.
8697 This expression represents the sum of X and the low-order bits of
8698 Y. It is used with `high' (*note Constants::) to represent the
8699 typical two-instruction sequence used in RISC machines to
8700 reference a global memory location.
8702 The number of low order bits is machine-dependent but is normally
8703 the number of bits in a `Pmode' item minus the number of bits set
8706 M should be `Pmode'.
8711 These three expressions represent the result of subtracting Y from
8712 X, carried out in mode M. Behavior on overflow is the same as for
8713 the three variants of `plus' (see above).
8716 Represents the result of subtracting Y from X for purposes of
8717 comparison. The result is computed without overflow, as if with
8720 Of course, machines can't really subtract with infinite precision.
8721 However, they can pretend to do so when only the sign of the
8722 result will be used, which is the case when the result is stored
8723 in the condition code. And that is the _only_ way this kind of
8724 expression may validly be used: as a value to be stored in the
8725 condition codes, either `(cc0)' or a register. *Note
8728 The mode M is not related to the modes of X and Y, but instead is
8729 the mode of the condition code value. If `(cc0)' is used, it is
8730 `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often
8731 `CCmode'. *Note Condition Code::. If M is `VOIDmode' or
8732 `CCmode', the operation returns sufficient information (in an
8733 unspecified format) so that any comparison operator can be applied
8734 to the result of the `COMPARE' operation. For other modes in
8735 class `MODE_CC', the operation only returns a subset of this
8738 Normally, X and Y must have the same mode. Otherwise, `compare'
8739 is valid only if the mode of X is in class `MODE_INT' and Y is a
8740 `const_int' or `const_double' with mode `VOIDmode'. The mode of X
8741 determines what mode the comparison is to be done in; thus it must
8744 If one of the operands is a constant, it should be placed in the
8745 second operand and the comparison code adjusted as appropriate.
8747 A `compare' specifying two `VOIDmode' constants is not valid since
8748 there is no way to know in what mode the comparison is to be
8749 performed; the comparison must either be folded during the
8750 compilation or the first operand must be loaded into a register
8751 while its mode is still known.
8754 Represents the negation (subtraction from zero) of the value
8755 represented by X, carried out in mode M.
8758 Represents the signed product of the values represented by X and Y
8759 carried out in machine mode M.
8761 Some machines support a multiplication that generates a product
8762 wider than the operands. Write the pattern for this as
8764 (mult:M (sign_extend:M X) (sign_extend:M Y))
8766 where M is wider than the modes of X and Y, which need not be the
8769 For unsigned widening multiplication, use the same idiom, but with
8770 `zero_extend' instead of `sign_extend'.
8773 Represents the quotient in signed division of X by Y, carried out
8774 in machine mode M. If M is a floating point mode, it represents
8775 the exact quotient; otherwise, the integerized quotient.
8777 Some machines have division instructions in which the operands and
8778 quotient widths are not all the same; you should represent such
8779 instructions using `truncate' and `sign_extend' as in,
8781 (truncate:M1 (div:M2 X (sign_extend:M2 Y)))
8784 Like `div' but represents unsigned division.
8788 Like `div' and `udiv' but represent the remainder instead of the
8793 Represents the smaller (for `smin') or larger (for `smax') of X
8794 and Y, interpreted as signed values in mode M. When used with
8795 floating point, if both operands are zeros, or if either operand
8796 is `NaN', then it is unspecified which of the two operands is
8797 returned as the result.
8801 Like `smin' and `smax', but the values are interpreted as unsigned
8805 Represents the bitwise complement of the value represented by X,
8806 carried out in mode M, which must be a fixed-point machine mode.
8809 Represents the bitwise logical-and of the values represented by X
8810 and Y, carried out in machine mode M, which must be a fixed-point
8814 Represents the bitwise inclusive-or of the values represented by X
8815 and Y, carried out in machine mode M, which must be a fixed-point
8819 Represents the bitwise exclusive-or of the values represented by X
8820 and Y, carried out in machine mode M, which must be a fixed-point
8824 Represents the result of arithmetically shifting X left by C
8825 places. X have mode M, a fixed-point machine mode. C be a
8826 fixed-point mode or be a constant with mode `VOIDmode'; which mode
8827 is determined by the mode called for in the machine description
8828 entry for the left-shift instruction. For example, on the VAX,
8829 the mode of C is `QImode' regardless of M.
8833 Like `ashift' but for right shift. Unlike the case for left shift,
8834 these two operations are distinct.
8838 Similar but represent left and right rotate. If C is a constant,
8842 Represents the absolute value of X, computed in mode M.
8845 Represents the square root of X, computed in mode M. Most often M
8846 will be a floating point mode.
8849 Represents one plus the index of the least significant 1-bit in X,
8850 represented as an integer of mode M. (The value is zero if X is
8851 zero.) The mode of X need not be M; depending on the target
8852 machine, various mode combinations may be valid.
8855 Represents the number of leading 0-bits in X, represented as an
8856 integer of mode M, starting at the most significant bit position.
8857 If X is zero, the value is determined by
8858 `CLZ_DEFINED_VALUE_AT_ZERO'. Note that this is one of the few
8859 expressions that is not invariant under widening. The mode of X
8860 will usually be an integer mode.
8863 Represents the number of trailing 0-bits in X, represented as an
8864 integer of mode M, starting at the least significant bit position.
8865 If X is zero, the value is determined by
8866 `CTZ_DEFINED_VALUE_AT_ZERO'. Except for this case, `ctz(x)' is
8867 equivalent to `ffs(X) - 1'. The mode of X will usually be an
8871 Represents the number of 1-bits in X, represented as an integer of
8872 mode M. The mode of X will usually be an integer mode.
8875 Represents the number of 1-bits modulo 2 in X, represented as an
8876 integer of mode M. The mode of X will usually be an integer mode.
8879 File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL
8881 11.10 Comparison Operations
8882 ===========================
8884 Comparison operators test a relation on two operands and are considered
8885 to represent a machine-dependent nonzero value described by, but not
8886 necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::) if the relation
8887 holds, or zero if it does not, for comparison operators whose results
8888 have a `MODE_INT' mode, `FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the
8889 relation holds, or zero if it does not, for comparison operators that
8890 return floating-point values, and a vector of either
8891 `VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of
8892 zeros if it does not, for comparison operators that return vector
8893 results. The mode of the comparison operation is independent of the
8894 mode of the data being compared. If the comparison operation is being
8895 tested (e.g., the first operand of an `if_then_else'), the mode must be
8898 There are two ways that comparison operations may be used. The
8899 comparison operators may be used to compare the condition codes `(cc0)'
8900 against zero, as in `(eq (cc0) (const_int 0))'. Such a construct
8901 actually refers to the result of the preceding instruction in which the
8902 condition codes were set. The instruction setting the condition code
8903 must be adjacent to the instruction using the condition code; only
8904 `note' insns may separate them.
8906 Alternatively, a comparison operation may directly compare two data
8907 objects. The mode of the comparison is determined by the operands; they
8908 must both be valid for a common machine mode. A comparison with both
8909 operands constant would be invalid as the machine mode could not be
8910 deduced from it, but such a comparison should never exist in RTL due to
8913 In the example above, if `(cc0)' were last set to `(compare X Y)', the
8914 comparison operation is identical to `(eq X Y)'. Usually only one style
8915 of comparisons is supported on a particular machine, but the combine
8916 pass will try to merge the operations to produce the `eq' shown in case
8917 it exists in the context of the particular insn involved.
8919 Inequality comparisons come in two flavors, signed and unsigned. Thus,
8920 there are distinct expression codes `gt' and `gtu' for signed and
8921 unsigned greater-than. These can produce different results for the same
8922 pair of integer values: for example, 1 is signed greater-than -1 but not
8923 unsigned greater-than, because -1 when regarded as unsigned is actually
8924 `0xffffffff' which is greater than 1.
8926 The signed comparisons are also used for floating point values.
8927 Floating point comparisons are distinguished by the machine modes of
8931 `STORE_FLAG_VALUE' if the values represented by X and Y are equal,
8935 `STORE_FLAG_VALUE' if the values represented by X and Y are not
8939 `STORE_FLAG_VALUE' if the X is greater than Y. If they are
8940 fixed-point, the comparison is done in a signed sense.
8943 Like `gt' but does unsigned comparison, on fixed-point numbers
8948 Like `gt' and `gtu' but test for "less than".
8952 Like `gt' and `gtu' but test for "greater than or equal".
8956 Like `gt' and `gtu' but test for "less than or equal".
8958 `(if_then_else COND THEN ELSE)'
8959 This is not a comparison operation but is listed here because it is
8960 always used in conjunction with a comparison operation. To be
8961 precise, COND is a comparison expression. This expression
8962 represents a choice, according to COND, between the value
8963 represented by THEN and the one represented by ELSE.
8965 On most machines, `if_then_else' expressions are valid only to
8966 express conditional jumps.
8968 `(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)'
8969 Similar to `if_then_else', but more general. Each of TEST1,
8970 TEST2, ... is performed in turn. The result of this expression is
8971 the VALUE corresponding to the first nonzero test, or DEFAULT if
8972 none of the tests are nonzero expressions.
8974 This is currently not valid for instruction patterns and is
8975 supported only for insn attributes. *Note Insn Attributes::.
8978 File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL
8983 Special expression codes exist to represent bit-field instructions.
8985 `(sign_extract:M LOC SIZE POS)'
8986 This represents a reference to a sign-extended bit-field contained
8987 or starting in LOC (a memory or register reference). The bit-field
8988 is SIZE bits wide and starts at bit POS. The compilation option
8989 `BITS_BIG_ENDIAN' says which end of the memory unit POS counts
8992 If LOC is in memory, its mode must be a single-byte integer mode.
8993 If LOC is in a register, the mode to use is specified by the
8994 operand of the `insv' or `extv' pattern (*note Standard Names::)
8995 and is usually a full-word integer mode, which is the default if
8998 The mode of POS is machine-specific and is also specified in the
8999 `insv' or `extv' pattern.
9001 The mode M is the same as the mode that would be used for LOC if
9004 A `sign_extract' can not appear as an lvalue, or part thereof, in
9007 `(zero_extract:M LOC SIZE POS)'
9008 Like `sign_extract' but refers to an unsigned or zero-extended
9009 bit-field. The same sequence of bits are extracted, but they are
9010 filled to an entire word with zeros instead of by sign-extension.
9012 Unlike `sign_extract', this type of expressions can be lvalues in
9013 RTL; they may appear on the left side of an assignment, indicating
9014 insertion of a value into the specified bit-field.
9017 File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL
9019 11.12 Vector Operations
9020 =======================
9022 All normal RTL expressions can be used with vector modes; they are
9023 interpreted as operating on each part of the vector independently.
9024 Additionally, there are a few new expressions to describe specific
9027 `(vec_merge:M VEC1 VEC2 ITEMS)'
9028 This describes a merge operation between two vectors. The result
9029 is a vector of mode M; its elements are selected from either VEC1
9030 or VEC2. Which elements are selected is described by ITEMS, which
9031 is a bit mask represented by a `const_int'; a zero bit indicates
9032 the corresponding element in the result vector is taken from VEC2
9033 while a set bit indicates it is taken from VEC1.
9035 `(vec_select:M VEC1 SELECTION)'
9036 This describes an operation that selects parts of a vector. VEC1
9037 is the source vector, SELECTION is a `parallel' that contains a
9038 `const_int' for each of the subparts of the result vector, giving
9039 the number of the source subpart that should be stored into it.
9041 `(vec_concat:M VEC1 VEC2)'
9042 Describes a vector concat operation. The result is a
9043 concatenation of the vectors VEC1 and VEC2; its length is the sum
9044 of the lengths of the two inputs.
9046 `(vec_duplicate:M VEC)'
9047 This operation converts a small vector into a larger one by
9048 duplicating the input values. The output vector mode must have
9049 the same submodes as the input vector mode, and the number of
9050 output parts must be an integer multiple of the number of input
9055 File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL
9060 All conversions between machine modes must be represented by explicit
9061 conversion operations. For example, an expression which is the sum of
9062 a byte and a full word cannot be written as `(plus:SI (reg:QI 34)
9063 (reg:SI 80))' because the `plus' operation requires two operands of the
9064 same machine mode. Therefore, the byte-sized operand is enclosed in a
9065 conversion operation, as in
9067 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80))
9069 The conversion operation is not a mere placeholder, because there may
9070 be more than one way of converting from a given starting mode to the
9071 desired final mode. The conversion operation code says how to do it.
9073 For all conversion operations, X must not be `VOIDmode' because the
9074 mode in which to do the conversion would not be known. The conversion
9075 must either be done at compile-time or X must be placed into a register.
9078 Represents the result of sign-extending the value X to machine
9079 mode M. M must be a fixed-point mode and X a fixed-point value of
9080 a mode narrower than M.
9083 Represents the result of zero-extending the value X to machine
9084 mode M. M must be a fixed-point mode and X a fixed-point value of
9085 a mode narrower than M.
9087 `(float_extend:M X)'
9088 Represents the result of extending the value X to machine mode M.
9089 M must be a floating point mode and X a floating point value of a
9090 mode narrower than M.
9093 Represents the result of truncating the value X to machine mode M.
9094 M must be a fixed-point mode and X a fixed-point value of a mode
9098 Represents the result of truncating the value X to machine mode M,
9099 using signed saturation in the case of overflow. Both M and the
9100 mode of X must be fixed-point modes.
9103 Represents the result of truncating the value X to machine mode M,
9104 using unsigned saturation in the case of overflow. Both M and the
9105 mode of X must be fixed-point modes.
9107 `(float_truncate:M X)'
9108 Represents the result of truncating the value X to machine mode M.
9109 M must be a floating point mode and X a floating point value of a
9113 Represents the result of converting fixed point value X, regarded
9114 as signed, to floating point mode M.
9116 `(unsigned_float:M X)'
9117 Represents the result of converting fixed point value X, regarded
9118 as unsigned, to floating point mode M.
9121 When M is a fixed point mode, represents the result of converting
9122 floating point value X to mode M, regarded as signed. How
9123 rounding is done is not specified, so this operation may be used
9124 validly in compiling C code only for integer-valued operands.
9126 `(unsigned_fix:M X)'
9127 Represents the result of converting floating point value X to
9128 fixed point mode M, regarded as unsigned. How rounding is done is
9132 When M is a floating point mode, represents the result of
9133 converting floating point value X (valid for mode M) to an
9134 integer, still represented in floating point mode M, by rounding
9138 File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL
9143 Declaration expression codes do not represent arithmetic operations but
9144 rather state assertions about their operands.
9146 `(strict_low_part (subreg:M (reg:N R) 0))'
9147 This expression code is used in only one context: as the
9148 destination operand of a `set' expression. In addition, the
9149 operand of this expression must be a non-paradoxical `subreg'
9152 The presence of `strict_low_part' says that the part of the
9153 register which is meaningful in mode N, but is not part of mode M,
9154 is not to be altered. Normally, an assignment to such a subreg is
9155 allowed to have undefined effects on the rest of the register when
9156 M is less than a word.
9159 File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL
9161 11.15 Side Effect Expressions
9162 =============================
9164 The expression codes described so far represent values, not actions.
9165 But machine instructions never produce values; they are meaningful only
9166 for their side effects on the state of the machine. Special expression
9167 codes are used to represent side effects.
9169 The body of an instruction is always one of these side effect codes;
9170 the codes described above, which represent values, appear only as the
9174 Represents the action of storing the value of X into the place
9175 represented by LVAL. LVAL must be an expression representing a
9176 place that can be stored in: `reg' (or `subreg', `strict_low_part'
9177 or `zero_extract'), `mem', `pc', `parallel', or `cc0'.
9179 If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then
9180 X must be valid for that mode.
9182 If LVAL is a `reg' whose machine mode is less than the full width
9183 of the register, then it means that the part of the register
9184 specified by the machine mode is given the specified value and the
9185 rest of the register receives an undefined value. Likewise, if
9186 LVAL is a `subreg' whose machine mode is narrower than the mode of
9187 the register, the rest of the register can be changed in an
9190 If LVAL is a `strict_low_part' of a subreg, then the part of the
9191 register specified by the machine mode of the `subreg' is given
9192 the value X and the rest of the register is not changed.
9194 If LVAL is a `zero_extract', then the referenced part of the
9195 bit-field (a memory or register reference) specified by the
9196 `zero_extract' is given the value X and the rest of the bit-field
9197 is not changed. Note that `sign_extract' can not appear in LVAL.
9199 If LVAL is `(cc0)', it has no machine mode, and X may be either a
9200 `compare' expression or a value that may have any mode. The
9201 latter case represents a "test" instruction. The expression `(set
9202 (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N)
9203 (const_int 0)))'. Use the former expression to save space during
9206 If LVAL is a `parallel', it is used to represent the case of a
9207 function returning a structure in multiple registers. Each element
9208 of the `parallel' is an `expr_list' whose first operand is a `reg'
9209 and whose second operand is a `const_int' representing the offset
9210 (in bytes) into the structure at which the data in that register
9211 corresponds. The first element may be null to indicate that the
9212 structure is also passed partly in memory.
9214 If LVAL is `(pc)', we have a jump instruction, and the
9215 possibilities for X are very limited. It may be a `label_ref'
9216 expression (unconditional jump). It may be an `if_then_else'
9217 (conditional jump), in which case either the second or the third
9218 operand must be `(pc)' (for the case which does not jump) and the
9219 other of the two must be a `label_ref' (for the case which does
9220 jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may
9221 be a `reg' or a `mem'; these unusual patterns are used to
9222 represent jumps through branch tables.
9224 If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not
9225 be `VOIDmode' and the mode of X must be valid for the mode of LVAL.
9227 LVAL is customarily accessed with the `SET_DEST' macro and X with
9228 the `SET_SRC' macro.
9231 As the sole expression in a pattern, represents a return from the
9232 current function, on machines where this can be done with one
9233 instruction, such as VAXen. On machines where a multi-instruction
9234 "epilogue" must be executed in order to return from the function,
9235 returning is done by jumping to a label which precedes the
9236 epilogue, and the `return' expression code is never used.
9238 Inside an `if_then_else' expression, represents the value to be
9239 placed in `pc' to return to the caller.
9241 Note that an insn pattern of `(return)' is logically equivalent to
9242 `(set (pc) (return))', but the latter form is never used.
9244 `(call FUNCTION NARGS)'
9245 Represents a function call. FUNCTION is a `mem' expression whose
9246 address is the address of the function to be called. NARGS is an
9247 expression which can be used for two purposes: on some machines it
9248 represents the number of bytes of stack argument; on others, it
9249 represents the number of argument registers.
9251 Each machine has a standard machine mode which FUNCTION must have.
9252 The machine description defines macro `FUNCTION_MODE' to expand
9253 into the requisite mode name. The purpose of this mode is to
9254 specify what kind of addressing is allowed, on machines where the
9255 allowed kinds of addressing depend on the machine mode being
9259 Represents the storing or possible storing of an unpredictable,
9260 undescribed value into X, which must be a `reg', `scratch',
9261 `parallel' or `mem' expression.
9263 One place this is used is in string instructions that store
9264 standard values into particular hard registers. It may not be
9265 worth the trouble to describe the values that are stored, but it
9266 is essential to inform the compiler that the registers will be
9267 altered, lest it attempt to keep data in them across the string
9270 If X is `(mem:BLK (const_int 0))' or `(mem:BLK (scratch))', it
9271 means that all memory locations must be presumed clobbered. If X
9272 is a `parallel', it has the same meaning as a `parallel' in a
9275 Note that the machine description classifies certain hard
9276 registers as "call-clobbered". All function call instructions are
9277 assumed by default to clobber these registers, so there is no need
9278 to use `clobber' expressions to indicate this fact. Also, each
9279 function call is assumed to have the potential to alter any memory
9280 location, unless the function is declared `const'.
9282 If the last group of expressions in a `parallel' are each a
9283 `clobber' expression whose arguments are `reg' or `match_scratch'
9284 (*note RTL Template::) expressions, the combiner phase can add the
9285 appropriate `clobber' expressions to an insn it has constructed
9286 when doing so will cause a pattern to be matched.
9288 This feature can be used, for example, on a machine that whose
9289 multiply and add instructions don't use an MQ register but which
9290 has an add-accumulate instruction that does clobber the MQ
9291 register. Similarly, a combined instruction might require a
9292 temporary register while the constituent instructions might not.
9294 When a `clobber' expression for a register appears inside a
9295 `parallel' with other side effects, the register allocator
9296 guarantees that the register is unoccupied both before and after
9297 that insn. However, the reload phase may allocate a register used
9298 for one of the inputs unless the `&' constraint is specified for
9299 the selected alternative (*note Modifiers::). You can clobber
9300 either a specific hard register, a pseudo register, or a `scratch'
9301 expression; in the latter two cases, GCC will allocate a hard
9302 register that is available there for use as a temporary.
9304 For instructions that require a temporary register, you should use
9305 `scratch' instead of a pseudo-register because this will allow the
9306 combiner phase to add the `clobber' when required. You do this by
9307 coding (`clobber' (`match_scratch' ...)). If you do clobber a
9308 pseudo register, use one which appears nowhere else--generate a
9309 new one each time. Otherwise, you may confuse CSE.
9311 There is one other known use for clobbering a pseudo register in a
9312 `parallel': when one of the input operands of the insn is also
9313 clobbered by the insn. In this case, using the same pseudo
9314 register in the clobber and elsewhere in the insn produces the
9318 Represents the use of the value of X. It indicates that the value
9319 in X at this point in the program is needed, even though it may
9320 not be apparent why this is so. Therefore, the compiler will not
9321 attempt to delete previous instructions whose only effect is to
9322 store a value in X. X must be a `reg' expression.
9324 In some situations, it may be tempting to add a `use' of a
9325 register in a `parallel' to describe a situation where the value
9326 of a special register will modify the behavior of the instruction.
9327 An hypothetical example might be a pattern for an addition that can
9328 either wrap around or use saturating addition depending on the
9329 value of a special control register:
9331 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3)
9335 This will not work, several of the optimizers only look at
9336 expressions locally; it is very likely that if you have multiple
9337 insns with identical inputs to the `unspec', they will be
9338 optimized away even if register 1 changes in between.
9340 This means that `use' can _only_ be used to describe that the
9341 register is live. You should think twice before adding `use'
9342 statements, more often you will want to use `unspec' instead. The
9343 `use' RTX is most commonly useful to describe that a fixed
9344 register is implicitly used in an insn. It is also safe to use in
9345 patterns where the compiler knows for other reasons that the result
9346 of the whole pattern is variable, such as `movmemM' or `call'
9349 During the reload phase, an insn that has a `use' as pattern can
9350 carry a reg_equal note. These `use' insns will be deleted before
9351 the reload phase exits.
9353 During the delayed branch scheduling phase, X may be an insn.
9354 This indicates that X previously was located at this place in the
9355 code and its data dependencies need to be taken into account.
9356 These `use' insns will be deleted before the delayed branch
9357 scheduling phase exits.
9359 `(parallel [X0 X1 ...])'
9360 Represents several side effects performed in parallel. The square
9361 brackets stand for a vector; the operand of `parallel' is a vector
9362 of expressions. X0, X1 and so on are individual side effect
9363 expressions--expressions of code `set', `call', `return',
9366 "In parallel" means that first all the values used in the
9367 individual side-effects are computed, and second all the actual
9368 side-effects are performed. For example,
9370 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
9371 (set (mem:SI (reg:SI 1)) (reg:SI 1))])
9373 says unambiguously that the values of hard register 1 and the
9374 memory location addressed by it are interchanged. In both places
9375 where `(reg:SI 1)' appears as a memory address it refers to the
9376 value in register 1 _before_ the execution of the insn.
9378 It follows that it is _incorrect_ to use `parallel' and expect the
9379 result of one `set' to be available for the next one. For
9380 example, people sometimes attempt to represent a jump-if-zero
9381 instruction this way:
9383 (parallel [(set (cc0) (reg:SI 34))
9384 (set (pc) (if_then_else
9385 (eq (cc0) (const_int 0))
9389 But this is incorrect, because it says that the jump condition
9390 depends on the condition code value _before_ this instruction, not
9391 on the new value that is set by this instruction.
9393 Peephole optimization, which takes place together with final
9394 assembly code output, can produce insns whose patterns consist of
9395 a `parallel' whose elements are the operands needed to output the
9396 resulting assembler code--often `reg', `mem' or constant
9397 expressions. This would not be well-formed RTL at any other stage
9398 in compilation, but it is ok then because no further optimization
9399 remains to be done. However, the definition of the macro
9400 `NOTICE_UPDATE_CC', if any, must deal with such insns if you
9401 define any peephole optimizations.
9403 `(cond_exec [COND EXPR])'
9404 Represents a conditionally executed expression. The EXPR is
9405 executed only if the COND is nonzero. The COND expression must
9406 not have side-effects, but the EXPR may very well have
9409 `(sequence [INSNS ...])'
9410 Represents a sequence of insns. Each of the INSNS that appears in
9411 the vector is suitable for appearing in the chain of insns, so it
9412 must be an `insn', `jump_insn', `call_insn', `code_label',
9413 `barrier' or `note'.
9415 A `sequence' RTX is never placed in an actual insn during RTL
9416 generation. It represents the sequence of insns that result from a
9417 `define_expand' _before_ those insns are passed to `emit_insn' to
9418 insert them in the chain of insns. When actually inserted, the
9419 individual sub-insns are separated out and the `sequence' is
9422 After delay-slot scheduling is completed, an insn and all the
9423 insns that reside in its delay slots are grouped together into a
9424 `sequence'. The insn requiring the delay slot is the first insn
9425 in the vector; subsequent insns are to be placed in the delay slot.
9427 `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to
9428 indicate that a branch insn should be used that will conditionally
9429 annul the effect of the insns in the delay slots. In such a case,
9430 `INSN_FROM_TARGET_P' indicates that the insn is from the target of
9431 the branch and should be executed only if the branch is taken;
9432 otherwise the insn should be executed only if the branch is not
9433 taken. *Note Delay Slots::.
9435 These expression codes appear in place of a side effect, as the body of
9436 an insn, though strictly speaking they do not always describe side
9440 Represents literal assembler code as described by the string S.
9442 `(unspec [OPERANDS ...] INDEX)'
9443 `(unspec_volatile [OPERANDS ...] INDEX)'
9444 Represents a machine-specific operation on OPERANDS. INDEX
9445 selects between multiple machine-specific operations.
9446 `unspec_volatile' is used for volatile operations and operations
9447 that may trap; `unspec' is used for other operations.
9449 These codes may appear inside a `pattern' of an insn, inside a
9450 `parallel', or inside an expression.
9452 `(addr_vec:M [LR0 LR1 ...])'
9453 Represents a table of jump addresses. The vector elements LR0,
9454 etc., are `label_ref' expressions. The mode M specifies how much
9455 space is given to each address; normally M would be `Pmode'.
9457 `(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)'
9458 Represents a table of jump addresses expressed as offsets from
9459 BASE. The vector elements LR0, etc., are `label_ref' expressions
9460 and so is BASE. The mode M specifies how much space is given to
9461 each address-difference. MIN and MAX are set up by branch
9462 shortening and hold a label with a minimum and a maximum address,
9463 respectively. FLAGS indicates the relative position of BASE, MIN
9464 and MAX to the containing insn and of MIN and MAX to BASE. See
9465 rtl.def for details.
9467 `(prefetch:M ADDR RW LOCALITY)'
9468 Represents prefetch of memory at address ADDR. Operand RW is 1 if
9469 the prefetch is for data to be written, 0 otherwise; targets that
9470 do not support write prefetches should treat this as a normal
9471 prefetch. Operand LOCALITY specifies the amount of temporal
9472 locality; 0 if there is none or 1, 2, or 3 for increasing levels
9473 of temporal locality; targets that do not support locality hints
9476 This insn is used to minimize cache-miss latency by moving data
9477 into a cache before it is accessed. It should use only
9478 non-faulting data prefetch instructions.
9481 File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL
9483 11.16 Embedded Side-Effects on Addresses
9484 ========================================
9486 Six special side-effect expression codes appear as memory addresses.
9489 Represents the side effect of decrementing X by a standard amount
9490 and represents also the value that X has after being decremented.
9491 X must be a `reg' or `mem', but most machines allow only a `reg'.
9492 M must be the machine mode for pointers on the machine in use.
9493 The amount X is decremented by is the length in bytes of the
9494 machine mode of the containing memory reference of which this
9495 expression serves as the address. Here is an example of its use:
9497 (mem:DF (pre_dec:SI (reg:SI 39)))
9499 This says to decrement pseudo register 39 by the length of a
9500 `DFmode' value and use the result to address a `DFmode' value.
9503 Similar, but specifies incrementing X instead of decrementing it.
9506 Represents the same side effect as `pre_dec' but a different
9507 value. The value represented here is the value X has before being
9511 Similar, but specifies incrementing X instead of decrementing it.
9513 `(post_modify:M X Y)'
9514 Represents the side effect of setting X to Y and represents X
9515 before X is modified. X must be a `reg' or `mem', but most
9516 machines allow only a `reg'. M must be the machine mode for
9517 pointers on the machine in use.
9519 The expression Y must be one of three forms:
9520 `(plus:M X Z)', `(minus:M X Z)', or `(plus:M X I)',
9521 where Z is an index register and I is a constant.
9523 Here is an example of its use:
9525 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42)
9528 This says to modify pseudo register 42 by adding the contents of
9529 pseudo register 48 to it, after the use of what ever 42 points to.
9531 `(pre_modify:M X EXPR)'
9532 Similar except side effects happen before the use.
9534 These embedded side effect expressions must be used with care.
9535 Instruction patterns may not use them. Until the `flow' pass of the
9536 compiler, they may occur only to represent pushes onto the stack. The
9537 `flow' pass finds cases where registers are incremented or decremented
9538 in one instruction and used as an address shortly before or after;
9539 these cases are then transformed to use pre- or post-increment or
9542 If a register used as the operand of these expressions is used in
9543 another address in an insn, the original value of the register is used.
9544 Uses of the register outside of an address are not permitted within the
9545 same insn as a use in an embedded side effect expression because such
9546 insns behave differently on different machines and hence must be treated
9547 as ambiguous and disallowed.
9549 An instruction that can be represented with an embedded side effect
9550 could also be represented using `parallel' containing an additional
9551 `set' to describe how the address register is altered. This is not
9552 done because machines that allow these operations at all typically
9553 allow them wherever a memory address is called for. Describing them as
9554 additional parallel stores would require doubling the number of entries
9555 in the machine description.
9558 File: gccint.info, Node: Assembler, Next: Insns, Prev: Incdec, Up: RTL
9560 11.17 Assembler Instructions as Expressions
9561 ===========================================
9563 The RTX code `asm_operands' represents a value produced by a
9564 user-specified assembler instruction. It is used to represent an `asm'
9565 statement with arguments. An `asm' statement with a single output
9568 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z));
9570 is represented using a single `asm_operands' RTX which represents the
9571 value that is stored in `outputvar':
9573 (set RTX-FOR-OUTPUTVAR
9574 (asm_operands "foo %1,%2,%0" "a" 0
9575 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z]
9577 (asm_input:M2 "di")]))
9579 Here the operands of the `asm_operands' RTX are the assembler template
9580 string, the output-operand's constraint, the index-number of the output
9581 operand among the output operands specified, a vector of input operand
9582 RTX's, and a vector of input-operand modes and constraints. The mode
9583 M1 is the mode of the sum `x+y'; M2 is that of `*z'.
9585 When an `asm' statement has multiple output values, its insn has
9586 several such `set' RTX's inside of a `parallel'. Each `set' contains a
9587 `asm_operands'; all of these share the same assembler template and
9588 vectors, but each contains the constraint for the respective output
9589 operand. They are also distinguished by the output-operand index
9590 number, which is 0, 1, ... for successive output operands.
9593 File: gccint.info, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL
9598 The RTL representation of the code for a function is a doubly-linked
9599 chain of objects called "insns". Insns are expressions with special
9600 codes that are used for no other purpose. Some insns are actual
9601 instructions; others represent dispatch tables for `switch' statements;
9602 others represent labels to jump to or various sorts of declarative
9605 In addition to its own specific data, each insn must have a unique
9606 id-number that distinguishes it from all other insns in the current
9607 function (after delayed branch scheduling, copies of an insn with the
9608 same id-number may be present in multiple places in a function, but
9609 these copies will always be identical and will only appear inside a
9610 `sequence'), and chain pointers to the preceding and following insns.
9611 These three fields occupy the same position in every insn, independent
9612 of the expression code of the insn. They could be accessed with `XEXP'
9613 and `XINT', but instead three special macros are always used:
9616 Accesses the unique id of insn I.
9619 Accesses the chain pointer to the insn preceding I. If I is the
9620 first insn, this is a null pointer.
9623 Accesses the chain pointer to the insn following I. If I is the
9624 last insn, this is a null pointer.
9626 The first insn in the chain is obtained by calling `get_insns'; the
9627 last insn is the result of calling `get_last_insn'. Within the chain
9628 delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must
9629 always correspond: if INSN is not the first insn,
9631 NEXT_INSN (PREV_INSN (INSN)) == INSN
9633 is always true and if INSN is not the last insn,
9635 PREV_INSN (NEXT_INSN (INSN)) == INSN
9639 After delay slot scheduling, some of the insns in the chain might be
9640 `sequence' expressions, which contain a vector of insns. The value of
9641 `NEXT_INSN' in all but the last of these insns is the next insn in the
9642 vector; the value of `NEXT_INSN' of the last insn in the vector is the
9643 same as the value of `NEXT_INSN' for the `sequence' in which it is
9644 contained. Similar rules apply for `PREV_INSN'.
9646 This means that the above invariants are not necessarily true for insns
9647 inside `sequence' expressions. Specifically, if INSN is the first insn
9648 in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn containing
9649 the `sequence' expression, as is the value of `PREV_INSN (NEXT_INSN
9650 (INSN))' if INSN is the last insn in the `sequence' expression. You
9651 can use these expressions to find the containing `sequence' expression.
9653 Every insn has one of the following six expression codes:
9656 The expression code `insn' is used for instructions that do not
9657 jump and do not do function calls. `sequence' expressions are
9658 always contained in insns with code `insn' even if one of those
9659 insns should jump or do function calls.
9661 Insns with code `insn' have four additional fields beyond the three
9662 mandatory ones listed above. These four are described in a table
9666 The expression code `jump_insn' is used for instructions that may
9667 jump (or, more generally, may contain `label_ref' expressions). If
9668 there is an instruction to return from the current function, it is
9669 recorded as a `jump_insn'.
9671 `jump_insn' insns have the same extra fields as `insn' insns,
9672 accessed in the same way and in addition contain a field
9673 `JUMP_LABEL' which is defined once jump optimization has completed.
9675 For simple conditional and unconditional jumps, this field contains
9676 the `code_label' to which this insn will (possibly conditionally)
9677 branch. In a more complex jump, `JUMP_LABEL' records one of the
9678 labels that the insn refers to; the only way to find the others is
9679 to scan the entire body of the insn. In an `addr_vec',
9680 `JUMP_LABEL' is `NULL_RTX'.
9682 Return insns count as jumps, but since they do not refer to any
9683 labels, their `JUMP_LABEL' is `NULL_RTX'.
9686 The expression code `call_insn' is used for instructions that may
9687 do function calls. It is important to distinguish these
9688 instructions because they imply that certain registers and memory
9689 locations may be altered unpredictably.
9691 `call_insn' insns have the same extra fields as `insn' insns,
9692 accessed in the same way and in addition contain a field
9693 `CALL_INSN_FUNCTION_USAGE', which contains a list (chain of
9694 `expr_list' expressions) containing `use' and `clobber'
9695 expressions that denote hard registers and `MEM's used or
9696 clobbered by the called function.
9698 A `MEM' generally points to a stack slots in which arguments passed
9699 to the libcall by reference (*note TARGET_PASS_BY_REFERENCE:
9700 Register Arguments.) are stored. If the argument is caller-copied
9701 (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot
9702 will be mentioned in `CLOBBER' and `USE' entries; if it's
9703 callee-copied, only a `USE' will appear, and the `MEM' may point
9704 to addresses that are not stack slots. These `MEM's are used only
9705 in libcalls, because, unlike regular function calls, `CONST_CALL's
9706 (which libcalls generally are, *note CONST_CALL_P: Flags.) aren't
9707 assumed to read and write all memory, so flow would consider the
9708 stores dead and remove them. Note that, since a libcall must
9709 never return values in memory (*note RETURN_IN_MEMORY: Aggregate
9710 Return.), there will never be a `CLOBBER' for a memory address
9711 holding a return value.
9713 `CLOBBER'ed registers in this list augment registers specified in
9714 `CALL_USED_REGISTERS' (*note Register Basics::).
9717 A `code_label' insn represents a label that a jump insn can jump
9718 to. It contains two special fields of data in addition to the
9719 three standard ones. `CODE_LABEL_NUMBER' is used to hold the
9720 "label number", a number that identifies this label uniquely among
9721 all the labels in the compilation (not just in the current
9722 function). Ultimately, the label is represented in the assembler
9723 output as an assembler label, usually of the form `LN' where N is
9726 When a `code_label' appears in an RTL expression, it normally
9727 appears within a `label_ref' which represents the address of the
9730 Besides as a `code_label', a label can also be represented as a
9731 `note' of type `NOTE_INSN_DELETED_LABEL'.
9733 The field `LABEL_NUSES' is only defined once the jump optimization
9734 phase is completed. It contains the number of times this label is
9735 referenced in the current function.
9737 The field `LABEL_KIND' differentiates four different types of
9738 labels: `LABEL_NORMAL', `LABEL_STATIC_ENTRY',
9739 `LABEL_GLOBAL_ENTRY', and `LABEL_WEAK_ENTRY'. The only labels
9740 that do not have type `LABEL_NORMAL' are "alternate entry points"
9741 to the current function. These may be static (visible only in the
9742 containing translation unit), global (exposed to all translation
9743 units), or weak (global, but can be overridden by another symbol
9744 with the same name).
9746 Much of the compiler treats all four kinds of label identically.
9747 Some of it needs to know whether or not a label is an alternate
9748 entry point; for this purpose, the macro `LABEL_ALT_ENTRY_P' is
9749 provided. It is equivalent to testing whether `LABEL_KIND (label)
9750 == LABEL_NORMAL'. The only place that cares about the distinction
9751 between static, global, and weak alternate entry points, besides
9752 the front-end code that creates them, is the function
9753 `output_alternate_entry_point', in `final.c'.
9755 To set the kind of a label, use the `SET_LABEL_KIND' macro.
9758 Barriers are placed in the instruction stream when control cannot
9759 flow past them. They are placed after unconditional jump
9760 instructions to indicate that the jumps are unconditional and
9761 after calls to `volatile' functions, which do not return (e.g.,
9762 `exit'). They contain no information beyond the three standard
9766 `note' insns are used to represent additional debugging and
9767 declarative information. They contain two nonstandard fields, an
9768 integer which is accessed with the macro `NOTE_LINE_NUMBER' and a
9769 string accessed with `NOTE_SOURCE_FILE'.
9771 If `NOTE_LINE_NUMBER' is positive, the note represents the
9772 position of a source line and `NOTE_SOURCE_FILE' is the source
9773 file name that the line came from. These notes control generation
9774 of line number data in the assembler output.
9776 Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a
9777 code with one of the following values (and `NOTE_SOURCE_FILE' must
9778 contain a null pointer):
9781 Such a note is completely ignorable. Some passes of the
9782 compiler delete insns by altering them into notes of this
9785 `NOTE_INSN_DELETED_LABEL'
9786 This marks what used to be a `code_label', but was not used
9787 for other purposes than taking its address and was
9788 transformed to mark that no code jumps to it.
9790 `NOTE_INSN_BLOCK_BEG'
9791 `NOTE_INSN_BLOCK_END'
9792 These types of notes indicate the position of the beginning
9793 and end of a level of scoping of variable names. They
9794 control the output of debugging information.
9796 `NOTE_INSN_EH_REGION_BEG'
9797 `NOTE_INSN_EH_REGION_END'
9798 These types of notes indicate the position of the beginning
9799 and end of a level of scoping for exception handling.
9800 `NOTE_BLOCK_NUMBER' identifies which `CODE_LABEL' or `note'
9801 of type `NOTE_INSN_DELETED_LABEL' is associated with the
9804 `NOTE_INSN_LOOP_BEG'
9805 `NOTE_INSN_LOOP_END'
9806 These types of notes indicate the position of the beginning
9807 and end of a `while' or `for' loop. They enable the loop
9808 optimizer to find loops quickly.
9810 `NOTE_INSN_LOOP_CONT'
9811 Appears at the place in a loop that `continue' statements
9814 `NOTE_INSN_LOOP_VTOP'
9815 This note indicates the place in a loop where the exit test
9816 begins for those loops in which the exit test has been
9817 duplicated. This position becomes another virtual start of
9818 the loop when considering loop invariants.
9820 `NOTE_INSN_FUNCTION_BEG'
9821 Appears at the start of the function body, after the function
9824 `NOTE_INSN_FUNCTION_END'
9825 Appears near the end of the function body, just before the
9826 label that `return' statements jump to (on machine where a
9827 single instruction does not suffice for returning). This
9828 note may be deleted by jump optimization.
9831 These codes are printed symbolically when they appear in debugging
9834 The machine mode of an insn is normally `VOIDmode', but some phases
9835 use the mode for various purposes.
9837 The common subexpression elimination pass sets the mode of an insn to
9838 `QImode' when it is the first insn in a block that has already been
9841 The second Haifa scheduling pass, for targets that can multiple issue,
9842 sets the mode of an insn to `TImode' when it is believed that the
9843 instruction begins an issue group. That is, when the instruction
9844 cannot issue simultaneously with the previous. This may be relied on
9845 by later passes, in particular machine-dependent reorg.
9847 Here is a table of the extra fields of `insn', `jump_insn' and
9851 An expression for the side effect performed by this insn. This
9852 must be one of the following codes: `set', `call', `use',
9853 `clobber', `return', `asm_input', `asm_output', `addr_vec',
9854 `addr_diff_vec', `trap_if', `unspec', `unspec_volatile',
9855 `parallel', `cond_exec', or `sequence'. If it is a `parallel',
9856 each element of the `parallel' must be one these codes, except that
9857 `parallel' expressions cannot be nested and `addr_vec' and
9858 `addr_diff_vec' are not permitted inside a `parallel' expression.
9861 An integer that says which pattern in the machine description
9862 matches this insn, or -1 if the matching has not yet been
9865 Such matching is never attempted and this field remains -1 on an
9866 insn whose pattern consists of a single `use', `clobber',
9867 `asm_input', `addr_vec' or `addr_diff_vec' expression.
9869 Matching is also never attempted on insns that result from an `asm'
9870 statement. These contain at least one `asm_operands' expression.
9871 The function `asm_noperands' returns a non-negative value for such
9874 In the debugging output, this field is printed as a number
9875 followed by a symbolic representation that locates the pattern in
9876 the `md' file as some small positive or negative offset from a
9880 A list (chain of `insn_list' expressions) giving information about
9881 dependencies between instructions within a basic block. Neither a
9882 jump nor a label may come between the related insns.
9885 A list (chain of `expr_list' and `insn_list' expressions) giving
9886 miscellaneous information about the insn. It is often information
9887 pertaining to the registers used in this insn.
9889 The `LOG_LINKS' field of an insn is a chain of `insn_list'
9890 expressions. Each of these has two operands: the first is an insn, and
9891 the second is another `insn_list' expression (the next one in the
9892 chain). The last `insn_list' in the chain has a null pointer as second
9893 operand. The significant thing about the chain is which insns appear
9894 in it (as first operands of `insn_list' expressions). Their order is
9897 This list is originally set up by the flow analysis pass; it is a null
9898 pointer until then. Flow only adds links for those data dependencies
9899 which can be used for instruction combination. For each insn, the flow
9900 analysis pass adds a link to insns which store into registers values
9901 that are used for the first time in this insn. The instruction
9902 scheduling pass adds extra links so that every dependence will be
9903 represented. Links represent data dependencies, antidependencies and
9904 output dependencies; the machine mode of the link distinguishes these
9905 three types: antidependencies have mode `REG_DEP_ANTI', output
9906 dependencies have mode `REG_DEP_OUTPUT', and data dependencies have
9909 The `REG_NOTES' field of an insn is a chain similar to the `LOG_LINKS'
9910 field but it includes `expr_list' expressions in addition to
9911 `insn_list' expressions. There are several kinds of register notes,
9912 which are distinguished by the machine mode, which in a register note
9913 is really understood as being an `enum reg_note'. The first operand OP
9914 of the note is data whose meaning depends on the kind of note.
9916 The macro `REG_NOTE_KIND (X)' returns the kind of register note. Its
9917 counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' sets the
9918 register note type of X to be NEWKIND.
9920 Register notes are of three classes: They may say something about an
9921 input to an insn, they may say something about an output of an insn, or
9922 they may create a linkage between two insns. There are also a set of
9923 values that are only used in `LOG_LINKS'.
9925 These register notes annotate inputs to an insn:
9928 The value in OP dies in this insn; that is to say, altering the
9929 value immediately after this insn would not affect the future
9930 behavior of the program.
9932 It does not follow that the register OP has no useful value after
9933 this insn since OP is not necessarily modified by this insn.
9934 Rather, no subsequent instruction uses the contents of OP.
9937 The register OP being set by this insn will not be used in a
9938 subsequent insn. This differs from a `REG_DEAD' note, which
9939 indicates that the value in an input will not be used subsequently.
9940 These two notes are independent; both may be present for the same
9944 The register OP is incremented (or decremented; at this level
9945 there is no distinction) by an embedded side effect inside this
9946 insn. This means it appears in a `post_inc', `pre_inc',
9947 `post_dec' or `pre_dec' expression.
9950 The register OP is known to have a nonnegative value when this
9951 insn is reached. This is used so that decrement and branch until
9952 zero instructions, such as the m68k dbra, can be matched.
9954 The `REG_NONNEG' note is added to insns only if the machine
9955 description has a `decrement_and_branch_until_zero' pattern.
9958 This insn does not cause a conflict between OP and the item being
9959 set by this insn even though it might appear that it does. In
9960 other words, if the destination register and OP could otherwise be
9961 assigned the same register, this insn does not prevent that
9964 Insns with this note are usually part of a block that begins with a
9965 `clobber' insn specifying a multi-word pseudo register (which will
9966 be the output of the block), a group of insns that each set one
9967 word of the value and have the `REG_NO_CONFLICT' note attached,
9968 and a final insn that copies the output to itself with an attached
9969 `REG_EQUAL' note giving the expression being computed. This block
9970 is encapsulated with `REG_LIBCALL' and `REG_RETVAL' notes on the
9971 first and last insns, respectively.
9974 This insn uses OP, a `code_label' or a `note' of type
9975 `NOTE_INSN_DELETED_LABEL', but is not a `jump_insn', or it is a
9976 `jump_insn' that required the label to be held in a register. The
9977 presence of this note allows jump optimization to be aware that OP
9978 is, in fact, being used, and flow optimization to build an
9979 accurate flow graph.
9982 This insn is an branching instruction (either an unconditional
9983 jump or an indirect jump) which crosses between hot and cold
9984 sections, which could potentially be very far apart in the
9985 executable. The presence of this note indicates to other
9986 optimizations that this this branching instruction should not be
9987 "collapsed" into a simpler branching construct. It is used when
9988 the optimization to partition basic blocks into hot and cold
9989 sections is turned on.
9992 Appears attached to each `CALL_INSN' to `setjmp' or a related
9995 The following notes describe attributes of outputs of an insn:
9999 This note is only valid on an insn that sets only one register and
10000 indicates that that register will be equal to OP at run time; the
10001 scope of this equivalence differs between the two types of notes.
10002 The value which the insn explicitly copies into the register may
10003 look different from OP, but they will be equal at run time. If the
10004 output of the single `set' is a `strict_low_part' expression, the
10005 note refers to the register that is contained in `SUBREG_REG' of
10006 the `subreg' expression.
10008 For `REG_EQUIV', the register is equivalent to OP throughout the
10009 entire function, and could validly be replaced in all its
10010 occurrences by OP. ("Validly" here refers to the data flow of the
10011 program; simple replacement may make some insns invalid.) For
10012 example, when a constant is loaded into a register that is never
10013 assigned any other value, this kind of note is used.
10015 When a parameter is copied into a pseudo-register at entry to a
10016 function, a note of this kind records that the register is
10017 equivalent to the stack slot where the parameter was passed.
10018 Although in this case the register may be set by other insns, it
10019 is still valid to replace the register by the stack slot
10020 throughout the function.
10022 A `REG_EQUIV' note is also used on an instruction which copies a
10023 register parameter into a pseudo-register at entry to a function,
10024 if there is a stack slot where that parameter could be stored.
10025 Although other insns may set the pseudo-register, it is valid for
10026 the compiler to replace the pseudo-register by stack slot
10027 throughout the function, provided the compiler ensures that the
10028 stack slot is properly initialized by making the replacement in
10029 the initial copy instruction as well. This is used on machines
10030 for which the calling convention allocates stack space for
10031 register parameters. See `REG_PARM_STACK_SPACE' in *Note Stack
10034 In the case of `REG_EQUAL', the register that is set by this insn
10035 will be equal to OP at run time at the end of this insn but not
10036 necessarily elsewhere in the function. In this case, OP is
10037 typically an arithmetic expression. For example, when a sequence
10038 of insns such as a library call is used to perform an arithmetic
10039 operation, this kind of note is attached to the insn that produces
10040 or copies the final value.
10042 These two notes are used in different ways by the compiler passes.
10043 `REG_EQUAL' is used by passes prior to register allocation (such as
10044 common subexpression elimination and loop optimization) to tell
10045 them how to think of that value. `REG_EQUIV' notes are used by
10046 register allocation to indicate that there is an available
10047 substitute expression (either a constant or a `mem' expression for
10048 the location of a parameter on the stack) that may be used in
10049 place of a register if insufficient registers are available.
10051 Except for stack homes for parameters, which are indicated by a
10052 `REG_EQUIV' note and are not useful to the early optimization
10053 passes and pseudo registers that are equivalent to a memory
10054 location throughout their entire life, which is not detected until
10055 later in the compilation, all equivalences are initially indicated
10056 by an attached `REG_EQUAL' note. In the early stages of register
10057 allocation, a `REG_EQUAL' note is changed into a `REG_EQUIV' note
10058 if OP is a constant and the insn represents the only set of its
10059 destination register.
10061 Thus, compiler passes prior to register allocation need only check
10062 for `REG_EQUAL' notes and passes subsequent to register allocation
10063 need only check for `REG_EQUIV' notes.
10065 These notes describe linkages between insns. They occur in pairs: one
10066 insn has one of a pair of notes that points to a second insn, which has
10067 the inverse note pointing back to the first insn.
10070 This insn copies the value of a multi-insn sequence (for example, a
10071 library call), and OP is the first insn of the sequence (for a
10072 library call, the first insn that was generated to set up the
10073 arguments for the library call).
10075 Loop optimization uses this note to treat such a sequence as a
10076 single operation for code motion purposes and flow analysis uses
10077 this note to delete such sequences whose results are dead.
10079 A `REG_EQUAL' note will also usually be attached to this insn to
10080 provide the expression being computed by the sequence.
10082 These notes will be deleted after reload, since they are no longer
10083 accurate or useful.
10086 This is the inverse of `REG_RETVAL': it is placed on the first
10087 insn of a multi-insn sequence, and it points to the last one.
10089 These notes are deleted after reload, since they are no longer
10090 useful or accurate.
10094 On machines that use `cc0', the insns which set and use `cc0' set
10095 and use `cc0' are adjacent. However, when branch delay slot
10096 filling is done, this may no longer be true. In this case a
10097 `REG_CC_USER' note will be placed on the insn setting `cc0' to
10098 point to the insn using `cc0' and a `REG_CC_SETTER' note will be
10099 placed on the insn using `cc0' to point to the insn setting `cc0'.
10101 These values are only used in the `LOG_LINKS' field, and indicate the
10102 type of dependency that each link represents. Links which indicate a
10103 data dependence (a read after write dependence) do not use any code,
10104 they simply have mode `VOIDmode', and are printed without any
10108 This indicates an anti dependence (a write after read dependence).
10111 This indicates an output dependence (a write after write
10114 These notes describe information gathered from gcov profile data. They
10115 are stored in the `REG_NOTES' field of an insn as an `expr_list'.
10118 This is used to specify the ratio of branches to non-branches of a
10119 branch insn according to the profile data. The value is stored as
10120 a value between 0 and REG_BR_PROB_BASE; larger values indicate a
10121 higher probability that the branch will be taken.
10124 These notes are found in JUMP insns after delayed branch scheduling
10125 has taken place. They indicate both the direction and the
10126 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_*
10129 `REG_FRAME_RELATED_EXPR'
10130 This is used on an RTX_FRAME_RELATED_P insn wherein the attached
10131 expression is used in place of the actual insn pattern. This is
10132 done in cases where the pattern is either complex or misleading.
10134 For convenience, the machine mode in an `insn_list' or `expr_list' is
10135 printed using these symbolic codes in debugging dumps.
10137 The only difference between the expression codes `insn_list' and
10138 `expr_list' is that the first operand of an `insn_list' is assumed to
10139 be an insn and is printed in debugging dumps as the insn's unique id;
10140 the first operand of an `expr_list' is printed in the ordinary way as
10144 File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL
10146 11.19 RTL Representation of Function-Call Insns
10147 ===============================================
10149 Insns that call subroutines have the RTL expression code `call_insn'.
10150 These insns must satisfy special rules, and their bodies must use a
10151 special RTL expression code, `call'.
10153 A `call' expression has two operands, as follows:
10155 (call (mem:FM ADDR) NBYTES)
10157 Here NBYTES is an operand that represents the number of bytes of
10158 argument data being passed to the subroutine, FM is a machine mode
10159 (which must equal as the definition of the `FUNCTION_MODE' macro in the
10160 machine description) and ADDR represents the address of the subroutine.
10162 For a subroutine that returns no value, the `call' expression as shown
10163 above is the entire body of the insn, except that the insn might also
10164 contain `use' or `clobber' expressions.
10166 For a subroutine that returns a value whose mode is not `BLKmode', the
10167 value is returned in a hard register. If this register's number is R,
10168 then the body of the call insn looks like this:
10171 (call (mem:FM ADDR) NBYTES))
10173 This RTL expression makes it clear (to the optimizer passes) that the
10174 appropriate register receives a useful value in this insn.
10176 When a subroutine returns a `BLKmode' value, it is handled by passing
10177 to the subroutine the address of a place to store the value. So the
10178 call insn itself does not "return" any value, and it has the same RTL
10179 form as a call that returns nothing.
10181 On some machines, the call instruction itself clobbers some register,
10182 for example to contain the return address. `call_insn' insns on these
10183 machines should have a body which is a `parallel' that contains both
10184 the `call' expression and `clobber' expressions that indicate which
10185 registers are destroyed. Similarly, if the call instruction requires
10186 some register other than the stack pointer that is not explicitly
10187 mentioned in its RTL, a `use' subexpression should mention that
10190 Functions that are called are assumed to modify all registers listed in
10191 the configuration macro `CALL_USED_REGISTERS' (*note Register Basics::)
10192 and, with the exception of `const' functions and library calls, to
10193 modify all of memory.
10195 Insns containing just `use' expressions directly precede the
10196 `call_insn' insn to indicate which registers contain inputs to the
10197 function. Similarly, if registers other than those in
10198 `CALL_USED_REGISTERS' are clobbered by the called function, insns
10199 containing a single `clobber' follow immediately after the call to
10200 indicate which registers.
10203 File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL
10205 11.20 Structure Sharing Assumptions
10206 ===================================
10208 The compiler assumes that certain kinds of RTL expressions are unique;
10209 there do not exist two distinct objects representing the same value.
10210 In other cases, it makes an opposite assumption: that no RTL expression
10211 object of a certain kind appears in more than one place in the
10212 containing structure.
10214 These assumptions refer to a single function; except for the RTL
10215 objects that describe global variables and external functions, and a
10216 few standard objects such as small integer constants, no RTL objects
10217 are common to two functions.
10219 * Each pseudo-register has only a single `reg' object to represent
10220 it, and therefore only a single machine mode.
10222 * For any symbolic label, there is only one `symbol_ref' object
10225 * All `const_int' expressions with equal values are shared.
10227 * There is only one `pc' expression.
10229 * There is only one `cc0' expression.
10231 * There is only one `const_double' expression with value 0 for each
10232 floating point mode. Likewise for values 1 and 2.
10234 * There is only one `const_vector' expression with value 0 for each
10235 vector mode, be it an integer or a double constant vector.
10237 * No `label_ref' or `scratch' appears in more than one place in the
10238 RTL structure; in other words, it is safe to do a tree-walk of all
10239 the insns in the function and assume that each time a `label_ref'
10240 or `scratch' is seen it is distinct from all others that are seen.
10242 * Only one `mem' object is normally created for each static variable
10243 or stack slot, so these objects are frequently shared in all the
10244 places they appear. However, separate but equal objects for these
10245 variables are occasionally made.
10247 * When a single `asm' statement has multiple output operands, a
10248 distinct `asm_operands' expression is made for each output operand.
10249 However, these all share the vector which contains the sequence of
10250 input operands. This sharing is used later on to test whether two
10251 `asm_operands' expressions come from the same statement, so all
10252 optimizations must carefully preserve the sharing if they copy the
10255 * No RTL object appears in more than one place in the RTL structure
10256 except as described above. Many passes of the compiler rely on
10257 this by assuming that they can modify RTL objects in place without
10258 unwanted side-effects on other insns.
10260 * During initial RTL generation, shared structure is freely
10261 introduced. After all the RTL for a function has been generated,
10262 all shared structure is copied by `unshare_all_rtl' in
10263 `emit-rtl.c', after which the above rules are guaranteed to be
10266 * During the combiner pass, shared structure within an insn can exist
10267 temporarily. However, the shared structure is copied before the
10268 combiner is finished with the insn. This is done by calling
10269 `copy_rtx_if_shared', which is a subroutine of `unshare_all_rtl'.
10272 File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL
10277 To read an RTL object from a file, call `read_rtx'. It takes one
10278 argument, a stdio stream, and returns a single RTL object. This routine
10279 is defined in `read-rtl.c'. It is not available in the compiler
10280 itself, only the various programs that generate the compiler back end
10281 from the machine description.
10283 People frequently have the idea of using RTL stored as text in a file
10284 as an interface between a language front end and the bulk of GCC. This
10285 idea is not feasible.
10287 GCC was designed to use RTL internally only. Correct RTL for a given
10288 program is very dependent on the particular target machine. And the RTL
10289 does not contain all the information about the program.
10291 The proper way to interface GCC to a new language front end is with
10292 the "tree" data structure, described in the files `tree.h' and
10293 `tree.def'. The documentation for this structure (*note Trees::) is
10297 File: gccint.info, Node: Control Flow, Next: Tree SSA, Prev: RTL, Up: Top
10299 12 Control Flow Graph
10300 *********************
10302 A control flow graph (CFG) is a data structure built on top of the
10303 intermediate code representation (the RTL or `tree' instruction stream)
10304 abstracting the control flow behavior of a function that is being
10305 compiled. The CFG is a directed graph where the vertices represent
10306 basic blocks and edges represent possible transfer of control flow from
10307 one basic block to another. The data structures used to represent the
10308 control flow graph are defined in `basic-block.h'.
10312 * Basic Blocks:: The definition and representation of basic blocks.
10313 * Edges:: Types of edges and their representation.
10314 * Profile information:: Representation of frequencies and probabilities.
10315 * Maintaining the CFG:: Keeping the control flow graph and up to date.
10316 * Liveness information:: Using and maintaining liveness information.
10319 File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow
10324 A basic block is a straight-line sequence of code with only one entry
10325 point and only one exit. In GCC, basic blocks are represented using
10326 the `basic_block' data type.
10328 Two pointer members of the `basic_block' structure are the pointers
10329 `next_bb' and `prev_bb'. These are used to keep doubly linked chain of
10330 basic blocks in the same order as the underlying instruction stream.
10331 The chain of basic blocks is updated transparently by the provided API
10332 for manipulating the CFG. The macro `FOR_EACH_BB' can be used to visit
10333 all the basic blocks in lexicographical order. Dominator traversals
10334 are also possible using `walk_dominator_tree'. Given two basic blocks
10335 A and B, block A dominates block B if A is _always_ executed before B.
10337 The `BASIC_BLOCK' array contains all basic blocks in an unspecified
10338 order. Each `basic_block' structure has a field that holds a unique
10339 integer identifier `index' that is the index of the block in the
10340 `BASIC_BLOCK' array. The total number of basic blocks in the function
10341 is `n_basic_blocks'. Both the basic block indices and the total number
10342 of basic blocks may vary during the compilation process, as passes
10343 reorder, create, duplicate, and destroy basic blocks. The index for
10344 any block should never be greater than `last_basic_block'.
10346 Special basic blocks represent possible entry and exit points of a
10347 function. These blocks are called `ENTRY_BLOCK_PTR' and
10348 `EXIT_BLOCK_PTR'. These blocks do not contain any code, and are not
10349 elements of the `BASIC_BLOCK' array. Therefore they have been assigned
10350 unique, negative index numbers.
10352 Each `basic_block' also contains pointers to the first instruction
10353 (the "head") and the last instruction (the "tail") or "end" of the
10354 instruction stream contained in a basic block. In fact, since the
10355 `basic_block' data type is used to represent blocks in both major
10356 intermediate representations of GCC (`tree' and RTL), there are
10357 pointers to the head and end of a basic block for both representations.
10359 For RTL, these pointers are `rtx head, end'. In the RTL function
10360 representation, the head pointer always points either to a
10361 `NOTE_INSN_BASIC_BLOCK' or to a `CODE_LABEL', if present. In the RTL
10362 representation of a function, the instruction stream contains not only
10363 the "real" instructions, but also "notes". Any function that moves or
10364 duplicates the basic blocks needs to take care of updating of these
10365 notes. Many of these notes expect that the instruction stream consists
10366 of linear regions, making such updates difficult. The
10367 `NOTE_INSN_BASIC_BLOCK' note is the only kind of note that may appear
10368 in the instruction stream contained in a basic block. The instruction
10369 stream of a basic block always follows a `NOTE_INSN_BASIC_BLOCK', but
10370 zero or more `CODE_LABEL' nodes can precede the block note. A basic
10371 block ends by control flow instruction or last instruction before
10372 following `CODE_LABEL' or `NOTE_INSN_BASIC_BLOCK'. A `CODE_LABEL'
10373 cannot appear in the instruction stream of a basic block.
10375 In addition to notes, the jump table vectors are also represented as
10376 "pseudo-instructions" inside the insn stream. These vectors never
10377 appear in the basic block and should always be placed just after the
10378 table jump instructions referencing them. After removing the
10379 table-jump it is often difficult to eliminate the code computing the
10380 address and referencing the vector, so cleaning up these vectors is
10381 postponed until after liveness analysis. Thus the jump table vectors
10382 may appear in the insn stream unreferenced and without any purpose.
10383 Before any edge is made "fall-thru", the existence of such construct in
10384 the way needs to be checked by calling `can_fallthru' function.
10386 For the `tree' representation, the head and end of the basic block are
10387 being pointed to by the `stmt_list' field, but this special `tree'
10388 should never be referenced directly. Instead, at the tree level
10389 abstract containers and iterators are used to access statements and
10390 expressions in basic blocks. These iterators are called "block
10391 statement iterators" (BSIs). Grep for `^bsi' in the various `tree-*'
10392 files. The following snippet will pretty-print all the statements of
10393 the program in the GIMPLE representation.
10397 block_stmt_iterator si;
10399 for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (&si))
10401 tree stmt = bsi_stmt (si);
10402 print_generic_stmt (stderr, stmt, 0);
10407 File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow
10412 Edges represent possible control flow transfers from the end of some
10413 basic block A to the head of another basic block B. We say that A is a
10414 predecessor of B, and B is a successor of A. Edges are represented in
10415 GCC with the `edge' data type. Each `edge' acts as a link between two
10416 basic blocks: the `src' member of an edge points to the predecessor
10417 basic block of the `dest' basic block. The members `preds' and `succs'
10418 of the `basic_block' data type point to type-safe vectors of edges to
10419 the predecessors and successors of the block.
10421 When walking the edges in an edge vector, "edge iterators" should be
10422 used. Edge iterators are constructed using the `edge_iterator' data
10423 structure and several methods are available to operate on them:
10426 This function initializes an `edge_iterator' that points to the
10427 first edge in a vector of edges.
10430 This function initializes an `edge_iterator' that points to the
10431 last edge in a vector of edges.
10434 This predicate is `true' if an `edge_iterator' represents the last
10435 edge in an edge vector.
10437 `ei_one_before_end_p'
10438 This predicate is `true' if an `edge_iterator' represents the
10439 second last edge in an edge vector.
10442 This function takes a pointer to an `edge_iterator' and makes it
10443 point to the next edge in the sequence.
10446 This function takes a pointer to an `edge_iterator' and makes it
10447 point to the previous edge in the sequence.
10450 This function returns the `edge' currently pointed to by an
10454 This function returns the `edge' currently pointed to by an
10455 `edge_iterator', but returns `NULL' if the iterator is pointing at
10456 the end of the sequence. This function has been provided for
10457 existing code makes the assumption that a `NULL' edge indicates
10458 the end of the sequence.
10461 The convenience macro `FOR_EACH_EDGE' can be used to visit all of the
10462 edges in a sequence of predecessor or successor edges. It must not be
10463 used when an element might be removed during the traversal, otherwise
10464 elements will be missed. Here is an example of how to use the macro:
10469 FOR_EACH_EDGE (e, ei, bb->succs)
10471 if (e->flags & EDGE_FALLTHRU)
10475 There are various reasons why control flow may transfer from one block
10476 to another. One possibility is that some instruction, for example a
10477 `CODE_LABEL', in a linearized instruction stream just always starts a
10478 new basic block. In this case a "fall-thru" edge links the basic block
10479 to the first following basic block. But there are several other
10480 reasons why edges may be created. The `flags' field of the `edge' data
10481 type is used to store information about the type of edge we are dealing
10482 with. Each edge is of one of the following types:
10485 No type flags are set for edges corresponding to jump instructions.
10486 These edges are used for unconditional or conditional jumps and in
10487 RTL also for table jumps. They are the easiest to manipulate as
10488 they may be freely redirected when the flow graph is not in SSA
10492 Fall-thru edges are present in case where the basic block may
10493 continue execution to the following one without branching. These
10494 edges have the `EDGE_FALLTHRU' flag set. Unlike other types of
10495 edges, these edges must come into the basic block immediately
10496 following in the instruction stream. The function
10497 `force_nonfallthru' is available to insert an unconditional jump
10498 in the case that redirection is needed. Note that this may
10499 require creation of a new basic block.
10501 _exception handling_
10502 Exception handling edges represent possible control transfers from
10503 a trapping instruction to an exception handler. The definition of
10504 "trapping" varies. In C++, only function calls can throw, but for
10505 Java, exceptions like division by zero or segmentation fault are
10506 defined and thus each instruction possibly throwing this kind of
10507 exception needs to be handled as control flow instruction.
10508 Exception edges have the `EDGE_ABNORMAL' and `EDGE_EH' flags set.
10510 When updating the instruction stream it is easy to change possibly
10511 trapping instruction to non-trapping, by simply removing the
10512 exception edge. The opposite conversion is difficult, but should
10513 not happen anyway. The edges can be eliminated via
10514 `purge_dead_edges' call.
10516 In the RTL representation, the destination of an exception edge is
10517 specified by `REG_EH_REGION' note attached to the insn. In case
10518 of a trapping call the `EDGE_ABNORMAL_CALL' flag is set too. In
10519 the `tree' representation, this extra flag is not set.
10521 In the RTL representation, the predicate `may_trap_p' may be used
10522 to check whether instruction still may trap or not. For the tree
10523 representation, the `tree_could_trap_p' predicate is available,
10524 but this predicate only checks for possible memory traps, as in
10525 dereferencing an invalid pointer location.
10528 Sibling calls or tail calls terminate the function in a
10529 non-standard way and thus an edge to the exit must be present.
10530 `EDGE_SIBCALL' and `EDGE_ABNORMAL' are set in such case. These
10531 edges only exist in the RTL representation.
10534 Computed jumps contain edges to all labels in the function
10535 referenced from the code. All those edges have `EDGE_ABNORMAL'
10536 flag set. The edges used to represent computed jumps often cause
10537 compile time performance problems, since functions consisting of
10538 many taken labels and many computed jumps may have _very_ dense
10539 flow graphs, so these edges need to be handled with special care.
10540 During the earlier stages of the compilation process, GCC tries to
10541 avoid such dense flow graphs by factoring computed jumps. For
10542 example, given the following series of jumps,
10553 factoring the computed jumps results in the following code sequence
10554 which has a much simpler flow graph:
10568 However, the classic problem with this transformation is that it
10569 has a runtime cost in there resulting code: An extra jump.
10570 Therefore, the computed jumps are un-factored in the later passes
10571 of the compiler. Be aware of that when you work on passes in that
10572 area. There have been numerous examples already where the compile
10573 time for code with unfactored computed jumps caused some serious
10576 _nonlocal goto handlers_
10577 GCC allows nested functions to return into caller using a `goto'
10578 to a label passed to as an argument to the callee. The labels
10579 passed to nested functions contain special code to cleanup after
10580 function call. Such sections of code are referred to as "nonlocal
10581 goto receivers". If a function contains such nonlocal goto
10582 receivers, an edge from the call to the label is created with the
10583 `EDGE_ABNORMAL' and `EDGE_ABNORMAL_CALL' flags set.
10585 _function entry points_
10586 By definition, execution of function starts at basic block 0, so
10587 there is always an edge from the `ENTRY_BLOCK_PTR' to basic block
10588 0. There is no `tree' representation for alternate entry points at
10589 this moment. In RTL, alternate entry points are specified by
10590 `CODE_LABEL' with `LABEL_ALTERNATE_NAME' defined. This feature is
10591 currently used for multiple entry point prologues and is limited
10592 to post-reload passes only. This can be used by back-ends to emit
10593 alternate prologues for functions called from different contexts.
10594 In future full support for multiple entry functions defined by
10595 Fortran 90 needs to be implemented.
10598 In the pre-reload representation a function terminates after the
10599 last instruction in the insn chain and no explicit return
10600 instructions are used. This corresponds to the fall-thru edge
10601 into exit block. After reload, optimal RTL epilogues are used
10602 that use explicit (conditional) return instructions that are
10603 represented by edges with no flags set.
10607 File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow
10609 12.3 Profile information
10610 ========================
10612 In many cases a compiler must make a choice whether to trade speed in
10613 one part of code for speed in another, or to trade code size for code
10614 speed. In such cases it is useful to know information about how often
10615 some given block will be executed. That is the purpose for maintaining
10616 profile within the flow graph. GCC can handle profile information
10617 obtained through "profile feedback", but it can also estimate branch
10618 probabilities based on statics and heuristics.
10620 The feedback based profile is produced by compiling the program with
10621 instrumentation, executing it on a train run and reading the numbers of
10622 executions of basic blocks and edges back to the compiler while
10623 re-compiling the program to produce the final executable. This method
10624 provides very accurate information about where a program spends most of
10625 its time on the train run. Whether it matches the average run of
10626 course depends on the choice of train data set, but several studies
10627 have shown that the behavior of a program usually changes just
10628 marginally over different data sets.
10630 When profile feedback is not available, the compiler may be asked to
10631 attempt to predict the behavior of each branch in the program using a
10632 set of heuristics (see `predict.def' for details) and compute estimated
10633 frequencies of each basic block by propagating the probabilities over
10636 Each `basic_block' contains two integer fields to represent profile
10637 information: `frequency' and `count'. The `frequency' is an estimation
10638 how often is basic block executed within a function. It is represented
10639 as an integer scaled in the range from 0 to `BB_FREQ_BASE'. The most
10640 frequently executed basic block in function is initially set to
10641 `BB_FREQ_BASE' and the rest of frequencies are scaled accordingly.
10642 During optimization, the frequency of the most frequent basic block can
10643 both decrease (for instance by loop unrolling) or grow (for instance by
10644 cross-jumping optimization), so scaling sometimes has to be performed
10647 The `count' contains hard-counted numbers of execution measured during
10648 training runs and is nonzero only when profile feedback is available.
10649 This value is represented as the host's widest integer (typically a 64
10650 bit integer) of the special type `gcov_type'.
10652 Most optimization passes can use only the frequency information of a
10653 basic block, but a few passes may want to know hard execution counts.
10654 The frequencies should always match the counts after scaling, however
10655 during updating of the profile information numerical error may
10656 accumulate into quite large errors.
10658 Each edge also contains a branch probability field: an integer in the
10659 range from 0 to `REG_BR_PROB_BASE'. It represents probability of
10660 passing control from the end of the `src' basic block to the `dest'
10661 basic block, i.e. the probability that control will flow along this
10662 edge. The `EDGE_FREQUENCY' macro is available to compute how
10663 frequently a given edge is taken. There is a `count' field for each
10664 edge as well, representing same information as for a basic block.
10666 The basic block frequencies are not represented in the instruction
10667 stream, but in the RTL representation the edge frequencies are
10668 represented for conditional jumps (via the `REG_BR_PROB' macro) since
10669 they are used when instructions are output to the assembly file and the
10670 flow graph is no longer maintained.
10672 The probability that control flow arrives via a given edge to its
10673 destination basic block is called "reverse probability" and is not
10674 directly represented, but it may be easily computed from frequencies of
10677 Updating profile information is a delicate task that can unfortunately
10678 not be easily integrated with the CFG manipulation API. Many of the
10679 functions and hooks to modify the CFG, such as
10680 `redirect_edge_and_branch', do not have enough information to easily
10681 update the profile, so updating it is in the majority of cases left up
10682 to the caller. It is difficult to uncover bugs in the profile updating
10683 code, because they manifest themselves only by producing worse code,
10684 and checking profile consistency is not possible because of numeric
10685 error accumulation. Hence special attention needs to be given to this
10686 issue in each pass that modifies the CFG.
10688 It is important to point out that `REG_BR_PROB_BASE' and
10689 `BB_FREQ_BASE' are both set low enough to be possible to compute second
10690 power of any frequency or probability in the flow graph, it is not
10691 possible to even square the `count' field, as modern CPUs are fast
10692 enough to execute $2^32$ operations quickly.
10695 File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow
10697 12.4 Maintaining the CFG
10698 ========================
10700 An important task of each compiler pass is to keep both the control
10701 flow graph and all profile information up-to-date. Reconstruction of
10702 the control flow graph after each pass is not an option, since it may be
10703 very expensive and lost profile information cannot be reconstructed at
10706 GCC has two major intermediate representations, and both use the
10707 `basic_block' and `edge' data types to represent control flow. Both
10708 representations share as much of the CFG maintenance code as possible.
10709 For each representation, a set of "hooks" is defined so that each
10710 representation can provide its own implementation of CFG manipulation
10711 routines when necessary. These hooks are defined in `cfghooks.h'.
10712 There are hooks for almost all common CFG manipulations, including
10713 block splitting and merging, edge redirection and creating and deleting
10714 basic blocks. These hooks should provide everything you need to
10715 maintain and manipulate the CFG in both the RTL and `tree'
10718 At the moment, the basic block boundaries are maintained transparently
10719 when modifying instructions, so there rarely is a need to move them
10720 manually (such as in case someone wants to output instruction outside
10721 basic block explicitly). Often the CFG may be better viewed as
10722 integral part of instruction chain, than structure built on the top of
10723 it. However, in principle the control flow graph for the `tree'
10724 representation is _not_ an integral part of the representation, in that
10725 a function tree may be expanded without first building a flow graph
10726 for the `tree' representation at all. This happens when compiling
10727 without any `tree' optimization enabled. When the `tree' optimizations
10728 are enabled and the instruction stream is rewritten in SSA form, the
10729 CFG is very tightly coupled with the instruction stream. In
10730 particular, statement insertion and removal has to be done with care.
10731 In fact, the whole `tree' representation can not be easily used or
10732 maintained without proper maintenance of the CFG simultaneously.
10734 In the RTL representation, each instruction has a `BLOCK_FOR_INSN'
10735 value that represents pointer to the basic block that contains the
10736 instruction. In the `tree' representation, the function `bb_for_stmt'
10737 returns a pointer to the basic block containing the queried statement.
10739 When changes need to be applied to a function in its `tree'
10740 representation, "block statement iterators" should be used. These
10741 iterators provide an integrated abstraction of the flow graph and the
10742 instruction stream. Block statement iterators iterators are
10743 constructed using the `block_stmt_iterator' data structure and several
10744 modifier are available, including the following:
10747 This function initializes a `block_stmt_iterator' that points to
10748 the first non-empty statement in a basic block.
10751 This function initializes a `block_stmt_iterator' that points to
10752 the last statement in a basic block.
10755 This predicate is `true' if a `block_stmt_iterator' represents the
10756 end of a basic block.
10759 This function takes a `block_stmt_iterator' and makes it point to
10763 This function takes a `block_stmt_iterator' and makes it point to
10767 This function inserts a statement after the `block_stmt_iterator'
10768 passed in. The final parameter determines whether the statement
10769 iterator is updated to point to the newly inserted statement, or
10770 left pointing to the original statement.
10772 `bsi_insert_before'
10773 This function inserts a statement before the `block_stmt_iterator'
10774 passed in. The final parameter determines whether the statement
10775 iterator is updated to point to the newly inserted statement, or
10776 left pointing to the original statement.
10779 This function removes the `block_stmt_iterator' passed in and
10780 rechains the remaining statements in a basic block, if any.
10782 In the RTL representation, the macros `BB_HEAD' and `BB_END' may be
10783 used to get the head and end `rtx' of a basic block. No abstract
10784 iterators are defined for traversing the insn chain, but you can just
10785 use `NEXT_INSN' and `PREV_INSN' instead. See *Note Insns::.
10787 Usually a code manipulating pass simplifies the instruction stream and
10788 the flow of control, possibly eliminating some edges. This may for
10789 example happen when a conditional jump is replaced with an
10790 unconditional jump, but also when simplifying possibly trapping
10791 instruction to non-trapping while compiling Java. Updating of edges is
10792 not transparent and each optimization pass is required to do so
10793 manually. However only few cases occur in practice. The pass may call
10794 `purge_dead_edges' on a given basic block to remove superfluous edges,
10797 Another common scenario is redirection of branch instructions, but
10798 this is best modeled as redirection of edges in the control flow graph
10799 and thus use of `redirect_edge_and_branch' is preferred over more low
10800 level functions, such as `redirect_jump' that operate on RTL chain
10801 only. The CFG hooks defined in `cfghooks.h' should provide the
10802 complete API required for manipulating and maintaining the CFG.
10804 It is also possible that a pass has to insert control flow instruction
10805 into the middle of a basic block, thus creating an entry point in the
10806 middle of the basic block, which is impossible by definition: The block
10807 must be split to make sure it only has one entry point, i.e. the head
10808 of the basic block. The CFG hook `split_block' may be used when an
10809 instruction in the middle of a basic block has to become the target of
10810 a jump or branch instruction.
10812 For a global optimizer, a common operation is to split edges in the
10813 flow graph and insert instructions on them. In the RTL representation,
10814 this can be easily done using the `insert_insn_on_edge' function that
10815 emits an instruction "on the edge", caching it for a later
10816 `commit_edge_insertions' call that will take care of moving the
10817 inserted instructions off the edge into the instruction stream
10818 contained in a basic block. This includes the creation of new basic
10819 blocks where needed. In the `tree' representation, the equivalent
10820 functions are `bsi_insert_on_edge' which inserts a block statement
10821 iterator on an edge, and `bsi_commit_edge_inserts' which flushes the
10822 instruction to actual instruction stream.
10824 While debugging the optimization pass, an `verify_flow_info' function
10825 may be useful to find bugs in the control flow graph updating code.
10827 Note that at present, the representation of control flow in the `tree'
10828 representation is discarded before expanding to RTL. Long term the CFG
10829 should be maintained and "expanded" to the RTL representation along
10830 with the function `tree' itself.
10833 File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow
10835 12.5 Liveness information
10836 =========================
10838 Liveness information is useful to determine whether some register is
10839 "live" at given point of program, i.e. that it contains a value that
10840 may be used at a later point in the program. This information is used,
10841 for instance, during register allocation, as the pseudo registers only
10842 need to be assigned to a unique hard register or to a stack slot if
10843 they are live. The hard registers and stack slots may be freely reused
10844 for other values when a register is dead.
10846 The liveness information is stored partly in the RTL instruction
10847 stream and partly in the flow graph. Local information is stored in
10848 the instruction stream: Each instruction may contain `REG_DEAD' notes
10849 representing that the value of a given register is no longer needed, or
10850 `REG_UNUSED' notes representing that the value computed by the
10851 instruction is never used. The second is useful for instructions
10852 computing multiple values at once.
10854 Global liveness information is stored in the control flow graph. Each
10855 basic block contains two bitmaps, `global_live_at_start' and
10856 `global_live_at_end' representing liveness of each register at the
10857 entry and exit of the basic block. The file `flow.c' contains
10858 functions to compute liveness of each register at any given place in
10859 the instruction stream using this information.
10861 Liveness is expensive to compute and thus it is desirable to keep it
10862 up to date during code modifying passes. This can be easily
10863 accomplished using the `flags' field of a basic block. Functions
10864 modifying the instruction stream automatically set the `BB_DIRTY' flag
10865 of a modifies basic block, so the pass may simply use`clear_bb_flags'
10866 before doing any modifications and then ask the data flow module to
10867 have liveness updated via the `update_life_info_in_dirty_blocks'
10870 This scheme works reliably as long as no control flow graph
10871 transformations are done. The task of updating liveness after control
10872 flow graph changes is more difficult as normal iterative data flow
10873 analysis may produce invalid results or get into an infinite cycle when
10874 the initial solution is not below the desired one. Only simple
10875 transformations, like splitting basic blocks or inserting on edges, are
10876 safe, as functions to implement them already know how to update
10877 liveness information locally.
10880 File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Tree SSA, Up: Top
10882 13 Machine Descriptions
10883 ***********************
10885 A machine description has two parts: a file of instruction patterns
10886 (`.md' file) and a C header file of macro definitions.
10888 The `.md' file for a target machine contains a pattern for each
10889 instruction that the target machine supports (or at least each
10890 instruction that is worth telling the compiler about). It may also
10891 contain comments. A semicolon causes the rest of the line to be a
10892 comment, unless the semicolon is inside a quoted string.
10894 See the next chapter for information on the C header file.
10898 * Overview:: How the machine description is used.
10899 * Patterns:: How to write instruction patterns.
10900 * Example:: An explained example of a `define_insn' pattern.
10901 * RTL Template:: The RTL template defines what insns match a pattern.
10902 * Output Template:: The output template says how to make assembler code
10904 * Output Statement:: For more generality, write C code to output
10905 the assembler code.
10906 * Predicates:: Controlling what kinds of operands can be used
10908 * Constraints:: Fine-tuning operand selection.
10909 * Standard Names:: Names mark patterns to use for code generation.
10910 * Pattern Ordering:: When the order of patterns makes a difference.
10911 * Dependent Patterns:: Having one pattern may make you need another.
10912 * Jump Patterns:: Special considerations for patterns for jump insns.
10913 * Looping Patterns:: How to define patterns for special looping insns.
10914 * Insn Canonicalizations::Canonicalization of Instructions
10915 * Expander Definitions::Generating a sequence of several RTL insns
10916 for a standard operation.
10917 * Insn Splitting:: Splitting Instructions into Multiple Instructions.
10918 * Including Patterns:: Including Patterns in Machine Descriptions.
10919 * Peephole Definitions::Defining machine-specific peephole optimizations.
10920 * Insn Attributes:: Specifying the value of attributes for generated insns.
10921 * Conditional Execution::Generating `define_insn' patterns for
10923 * Constant Definitions::Defining symbolic constants that can be used in the
10925 * Macros:: Using macros to generate patterns from a template.
10928 File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc
10930 13.1 Overview of How the Machine Description is Used
10931 ====================================================
10933 There are three main conversions that happen in the compiler:
10935 1. The front end reads the source code and builds a parse tree.
10937 2. The parse tree is used to generate an RTL insn list based on named
10938 instruction patterns.
10940 3. The insn list is matched against the RTL templates to produce
10944 For the generate pass, only the names of the insns matter, from either
10945 a named `define_insn' or a `define_expand'. The compiler will choose
10946 the pattern with the right name and apply the operands according to the
10947 documentation later in this chapter, without regard for the RTL
10948 template or operand constraints. Note that the names the compiler looks
10949 for are hard-coded in the compiler--it will ignore unnamed patterns and
10950 patterns with names it doesn't know about, but if you don't provide a
10951 named pattern it needs, it will abort.
10953 If a `define_insn' is used, the template given is inserted into the
10954 insn list. If a `define_expand' is used, one of three things happens,
10955 based on the condition logic. The condition logic may manually create
10956 new insns for the insn list, say via `emit_insn()', and invoke `DONE'.
10957 For certain named patterns, it may invoke `FAIL' to tell the compiler
10958 to use an alternate way of performing that task. If it invokes neither
10959 `DONE' nor `FAIL', the template given in the pattern is inserted, as if
10960 the `define_expand' were a `define_insn'.
10962 Once the insn list is generated, various optimization passes convert,
10963 replace, and rearrange the insns in the insn list. This is where the
10964 `define_split' and `define_peephole' patterns get used, for example.
10966 Finally, the insn list's RTL is matched up with the RTL templates in
10967 the `define_insn' patterns, and those patterns are used to emit the
10968 final assembly code. For this purpose, each named `define_insn' acts
10969 like it's unnamed, since the names are ignored.
10972 File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc
10974 13.2 Everything about Instruction Patterns
10975 ==========================================
10977 Each instruction pattern contains an incomplete RTL expression, with
10978 pieces to be filled in later, operand constraints that restrict how the
10979 pieces can be filled in, and an output pattern or C code to generate
10980 the assembler output, all wrapped up in a `define_insn' expression.
10982 A `define_insn' is an RTL expression containing four or five operands:
10984 1. An optional name. The presence of a name indicate that this
10985 instruction pattern can perform a certain standard job for the
10986 RTL-generation pass of the compiler. This pass knows certain
10987 names and will use the instruction patterns with those names, if
10988 the names are defined in the machine description.
10990 The absence of a name is indicated by writing an empty string
10991 where the name should go. Nameless instruction patterns are never
10992 used for generating RTL code, but they may permit several simpler
10993 insns to be combined later on.
10995 Names that are not thus known and used in RTL-generation have no
10996 effect; they are equivalent to no name at all.
10998 For the purpose of debugging the compiler, you may also specify a
10999 name beginning with the `*' character. Such a name is used only
11000 for identifying the instruction in RTL dumps; it is entirely
11001 equivalent to having a nameless pattern for all other purposes.
11003 2. The "RTL template" (*note RTL Template::) is a vector of incomplete
11004 RTL expressions which show what the instruction should look like.
11005 It is incomplete because it may contain `match_operand',
11006 `match_operator', and `match_dup' expressions that stand for
11007 operands of the instruction.
11009 If the vector has only one element, that element is the template
11010 for the instruction pattern. If the vector has multiple elements,
11011 then the instruction pattern is a `parallel' expression containing
11012 the elements described.
11014 3. A condition. This is a string which contains a C expression that
11015 is the final test to decide whether an insn body matches this
11018 For a named pattern, the condition (if present) may not depend on
11019 the data in the insn being matched, but only the
11020 target-machine-type flags. The compiler needs to test these
11021 conditions during initialization in order to learn exactly which
11022 named instructions are available in a particular run.
11024 For nameless patterns, the condition is applied only when matching
11025 an individual insn, and only after the insn has matched the
11026 pattern's recognition template. The insn's operands may be found
11027 in the vector `operands'. For an insn where the condition has
11028 once matched, it can't be used to control register allocation, for
11029 example by excluding certain hard registers or hard register
11032 4. The "output template": a string that says how to output matching
11033 insns as assembler code. `%' in this string specifies where to
11034 substitute the value of an operand. *Note Output Template::.
11036 When simple substitution isn't general enough, you can specify a
11037 piece of C code to compute the output. *Note Output Statement::.
11039 5. Optionally, a vector containing the values of attributes for insns
11040 matching this pattern. *Note Insn Attributes::.
11043 File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc
11045 13.3 Example of `define_insn'
11046 =============================
11048 Here is an actual example of an instruction pattern, for the
11051 (define_insn "tstsi"
11053 (match_operand:SI 0 "general_operand" "rm"))]
11057 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
11058 return \"tstl %0\";
11059 return \"cmpl #0,%0\";
11062 This can also be written using braced strings:
11064 (define_insn "tstsi"
11066 (match_operand:SI 0 "general_operand" "rm"))]
11069 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
11071 return "cmpl #0,%0";
11074 This is an instruction that sets the condition codes based on the
11075 value of a general operand. It has no condition, so any insn whose RTL
11076 description has the form shown may be handled according to this
11077 pattern. The name `tstsi' means "test a `SImode' value" and tells the
11078 RTL generation pass that, when it is necessary to test such a value, an
11079 insn to do so can be constructed using this pattern.
11081 The output control string is a piece of C code which chooses which
11082 output template to return based on the kind of operand and the specific
11083 type of CPU for which code is being generated.
11085 `"rm"' is an operand constraint. Its meaning is explained below.
11088 File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc
11093 The RTL template is used to define which insns match the particular
11094 pattern and how to find their operands. For named patterns, the RTL
11095 template also says how to construct an insn from specified operands.
11097 Construction involves substituting specified operands into a copy of
11098 the template. Matching involves determining the values that serve as
11099 the operands in the insn being matched. Both of these activities are
11100 controlled by special expression types that direct matching and
11101 substitution of the operands.
11103 `(match_operand:M N PREDICATE CONSTRAINT)'
11104 This expression is a placeholder for operand number N of the insn.
11105 When constructing an insn, operand number N will be substituted
11106 at this point. When matching an insn, whatever appears at this
11107 position in the insn will be taken as operand number N; but it
11108 must satisfy PREDICATE or this instruction pattern will not match
11111 Operand numbers must be chosen consecutively counting from zero in
11112 each instruction pattern. There may be only one `match_operand'
11113 expression in the pattern for each operand number. Usually
11114 operands are numbered in the order of appearance in `match_operand'
11115 expressions. In the case of a `define_expand', any operand numbers
11116 used only in `match_dup' expressions have higher values than all
11117 other operand numbers.
11119 PREDICATE is a string that is the name of a function that accepts
11120 two arguments, an expression and a machine mode. *Note
11121 Predicates::. During matching, the function will be called with
11122 the putative operand as the expression and M as the mode argument
11123 (if M is not specified, `VOIDmode' will be used, which normally
11124 causes PREDICATE to accept any mode). If it returns zero, this
11125 instruction pattern fails to match. PREDICATE may be an empty
11126 string; then it means no test is to be done on the operand, so
11127 anything which occurs in this position is valid.
11129 Most of the time, PREDICATE will reject modes other than M--but
11130 not always. For example, the predicate `address_operand' uses M
11131 as the mode of memory ref that the address should be valid for.
11132 Many predicates accept `const_int' nodes even though their mode is
11135 CONSTRAINT controls reloading and the choice of the best register
11136 class to use for a value, as explained later (*note Constraints::).
11137 If the constraint would be an empty string, it can be omitted.
11139 People are often unclear on the difference between the constraint
11140 and the predicate. The predicate helps decide whether a given
11141 insn matches the pattern. The constraint plays no role in this
11142 decision; instead, it controls various decisions in the case of an
11143 insn which does match.
11145 `(match_scratch:M N CONSTRAINT)'
11146 This expression is also a placeholder for operand number N and
11147 indicates that operand must be a `scratch' or `reg' expression.
11149 When matching patterns, this is equivalent to
11151 (match_operand:M N "scratch_operand" PRED)
11153 but, when generating RTL, it produces a (`scratch':M) expression.
11155 If the last few expressions in a `parallel' are `clobber'
11156 expressions whose operands are either a hard register or
11157 `match_scratch', the combiner can add or delete them when
11158 necessary. *Note Side Effects::.
11161 This expression is also a placeholder for operand number N. It is
11162 used when the operand needs to appear more than once in the insn.
11164 In construction, `match_dup' acts just like `match_operand': the
11165 operand is substituted into the insn being constructed. But in
11166 matching, `match_dup' behaves differently. It assumes that operand
11167 number N has already been determined by a `match_operand'
11168 appearing earlier in the recognition template, and it matches only
11169 an identical-looking expression.
11171 Note that `match_dup' should not be used to tell the compiler that
11172 a particular register is being used for two operands (example:
11173 `add' that adds one register to another; the second register is
11174 both an input operand and the output operand). Use a matching
11175 constraint (*note Simple Constraints::) for those. `match_dup' is
11176 for the cases where one operand is used in two places in the
11177 template, such as an instruction that computes both a quotient and
11178 a remainder, where the opcode takes two input operands but the RTL
11179 template has to refer to each of those twice; once for the
11180 quotient pattern and once for the remainder pattern.
11182 `(match_operator:M N PREDICATE [OPERANDS...])'
11183 This pattern is a kind of placeholder for a variable RTL expression
11186 When constructing an insn, it stands for an RTL expression whose
11187 expression code is taken from that of operand N, and whose
11188 operands are constructed from the patterns OPERANDS.
11190 When matching an expression, it matches an expression if the
11191 function PREDICATE returns nonzero on that expression _and_ the
11192 patterns OPERANDS match the operands of the expression.
11194 Suppose that the function `commutative_operator' is defined as
11195 follows, to match any expression whose operator is one of the
11196 commutative arithmetic operators of RTL and whose mode is MODE:
11199 commutative_integer_operator (x, mode)
11201 enum machine_mode mode;
11203 enum rtx_code code = GET_CODE (x);
11204 if (GET_MODE (x) != mode)
11206 return (GET_RTX_CLASS (code) == RTX_COMM_ARITH
11207 || code == EQ || code == NE);
11210 Then the following pattern will match any RTL expression consisting
11211 of a commutative operator applied to two general operands:
11213 (match_operator:SI 3 "commutative_operator"
11214 [(match_operand:SI 1 "general_operand" "g")
11215 (match_operand:SI 2 "general_operand" "g")])
11217 Here the vector `[OPERANDS...]' contains two patterns because the
11218 expressions to be matched all contain two operands.
11220 When this pattern does match, the two operands of the commutative
11221 operator are recorded as operands 1 and 2 of the insn. (This is
11222 done by the two instances of `match_operand'.) Operand 3 of the
11223 insn will be the entire commutative expression: use `GET_CODE
11224 (operands[3])' to see which commutative operator was used.
11226 The machine mode M of `match_operator' works like that of
11227 `match_operand': it is passed as the second argument to the
11228 predicate function, and that function is solely responsible for
11229 deciding whether the expression to be matched "has" that mode.
11231 When constructing an insn, argument 3 of the gen-function will
11232 specify the operation (i.e. the expression code) for the
11233 expression to be made. It should be an RTL expression, whose
11234 expression code is copied into a new expression whose operands are
11235 arguments 1 and 2 of the gen-function. The subexpressions of
11236 argument 3 are not used; only its expression code matters.
11238 When `match_operator' is used in a pattern for matching an insn,
11239 it usually best if the operand number of the `match_operator' is
11240 higher than that of the actual operands of the insn. This improves
11241 register allocation because the register allocator often looks at
11242 operands 1 and 2 of insns to see if it can do register tying.
11244 There is no way to specify constraints in `match_operator'. The
11245 operand of the insn which corresponds to the `match_operator'
11246 never has any constraints because it is never reloaded as a whole.
11247 However, if parts of its OPERANDS are matched by `match_operand'
11248 patterns, those parts may have constraints of their own.
11250 `(match_op_dup:M N[OPERANDS...])'
11251 Like `match_dup', except that it applies to operators instead of
11252 operands. When constructing an insn, operand number N will be
11253 substituted at this point. But in matching, `match_op_dup' behaves
11254 differently. It assumes that operand number N has already been
11255 determined by a `match_operator' appearing earlier in the
11256 recognition template, and it matches only an identical-looking
11259 `(match_parallel N PREDICATE [SUBPAT...])'
11260 This pattern is a placeholder for an insn that consists of a
11261 `parallel' expression with a variable number of elements. This
11262 expression should only appear at the top level of an insn pattern.
11264 When constructing an insn, operand number N will be substituted at
11265 this point. When matching an insn, it matches if the body of the
11266 insn is a `parallel' expression with at least as many elements as
11267 the vector of SUBPAT expressions in the `match_parallel', if each
11268 SUBPAT matches the corresponding element of the `parallel', _and_
11269 the function PREDICATE returns nonzero on the `parallel' that is
11270 the body of the insn. It is the responsibility of the predicate
11271 to validate elements of the `parallel' beyond those listed in the
11274 A typical use of `match_parallel' is to match load and store
11275 multiple expressions, which can contain a variable number of
11276 elements in a `parallel'. For example,
11279 [(match_parallel 0 "load_multiple_operation"
11280 [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
11281 (match_operand:SI 2 "memory_operand" "m"))
11283 (clobber (reg:SI 179))])]
11287 This example comes from `a29k.md'. The function
11288 `load_multiple_operation' is defined in `a29k.c' and checks that
11289 subsequent elements in the `parallel' are the same as the `set' in
11290 the pattern, except that they are referencing subsequent registers
11291 and memory locations.
11293 An insn that matches this pattern might look like:
11296 [(set (reg:SI 20) (mem:SI (reg:SI 100)))
11298 (clobber (reg:SI 179))
11300 (mem:SI (plus:SI (reg:SI 100)
11303 (mem:SI (plus:SI (reg:SI 100)
11306 `(match_par_dup N [SUBPAT...])'
11307 Like `match_op_dup', but for `match_parallel' instead of
11312 File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc
11314 13.5 Output Templates and Operand Substitution
11315 ==============================================
11317 The "output template" is a string which specifies how to output the
11318 assembler code for an instruction pattern. Most of the template is a
11319 fixed string which is output literally. The character `%' is used to
11320 specify where to substitute an operand; it can also be used to identify
11321 places where different variants of the assembler require different
11324 In the simplest case, a `%' followed by a digit N says to output
11325 operand N at that point in the string.
11327 `%' followed by a letter and a digit says to output an operand in an
11328 alternate fashion. Four letters have standard, built-in meanings
11329 described below. The machine description macro `PRINT_OPERAND' can
11330 define additional letters with nonstandard meanings.
11332 `%cDIGIT' can be used to substitute an operand that is a constant
11333 value without the syntax that normally indicates an immediate operand.
11335 `%nDIGIT' is like `%cDIGIT' except that the value of the constant is
11336 negated before printing.
11338 `%aDIGIT' can be used to substitute an operand as if it were a memory
11339 reference, with the actual operand treated as the address. This may be
11340 useful when outputting a "load address" instruction, because often the
11341 assembler syntax for such an instruction requires you to write the
11342 operand as if it were a memory reference.
11344 `%lDIGIT' is used to substitute a `label_ref' into a jump instruction.
11346 `%=' outputs a number which is unique to each instruction in the
11347 entire compilation. This is useful for making local labels to be
11348 referred to more than once in a single template that generates multiple
11349 assembler instructions.
11351 `%' followed by a punctuation character specifies a substitution that
11352 does not use an operand. Only one case is standard: `%%' outputs a `%'
11353 into the assembler code. Other nonstandard cases can be defined in the
11354 `PRINT_OPERAND' macro. You must also define which punctuation
11355 characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro.
11357 The template may generate multiple assembler instructions. Write the
11358 text for the instructions, with `\;' between them.
11360 When the RTL contains two operands which are required by constraint to
11361 match each other, the output template must refer only to the
11362 lower-numbered operand. Matching operands are not always identical,
11363 and the rest of the compiler arranges to put the proper RTL expression
11364 for printing into the lower-numbered operand.
11366 One use of nonstandard letters or punctuation following `%' is to
11367 distinguish between different assembler languages for the same machine;
11368 for example, Motorola syntax versus MIT syntax for the 68000. Motorola
11369 syntax requires periods in most opcode names, while MIT syntax does
11370 not. For example, the opcode `movel' in MIT syntax is `move.l' in
11371 Motorola syntax. The same file of patterns is used for both kinds of
11372 output syntax, but the character sequence `%.' is used in each place
11373 where Motorola syntax wants a period. The `PRINT_OPERAND' macro for
11374 Motorola syntax defines the sequence to output a period; the macro for
11375 MIT syntax defines it to do nothing.
11377 As a special case, a template consisting of the single character `#'
11378 instructs the compiler to first split the insn, and then output the
11379 resulting instructions separately. This helps eliminate redundancy in
11380 the output templates. If you have a `define_insn' that needs to emit
11381 multiple assembler instructions, and there is an matching `define_split'
11382 already defined, then you can simply use `#' as the output template
11383 instead of writing an output template that emits the multiple assembler
11386 If the macro `ASSEMBLER_DIALECT' is defined, you can use construct of
11387 the form `{option0|option1|option2}' in the templates. These describe
11388 multiple variants of assembler language syntax. *Note Instruction
11392 File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc
11394 13.6 C Statements for Assembler Output
11395 ======================================
11397 Often a single fixed template string cannot produce correct and
11398 efficient assembler code for all the cases that are recognized by a
11399 single instruction pattern. For example, the opcodes may depend on the
11400 kinds of operands; or some unfortunate combinations of operands may
11401 require extra machine instructions.
11403 If the output control string starts with a `@', then it is actually a
11404 series of templates, each on a separate line. (Blank lines and leading
11405 spaces and tabs are ignored.) The templates correspond to the
11406 pattern's constraint alternatives (*note Multi-Alternative::). For
11407 example, if a target machine has a two-address add instruction `addr'
11408 to add into a register and another `addm' to add a register to memory,
11409 you might write this pattern:
11411 (define_insn "addsi3"
11412 [(set (match_operand:SI 0 "general_operand" "=r,m")
11413 (plus:SI (match_operand:SI 1 "general_operand" "0,0")
11414 (match_operand:SI 2 "general_operand" "g,r")))]
11420 If the output control string starts with a `*', then it is not an
11421 output template but rather a piece of C program that should compute a
11422 template. It should execute a `return' statement to return the
11423 template-string you want. Most such templates use C string literals,
11424 which require doublequote characters to delimit them. To include these
11425 doublequote characters in the string, prefix each one with `\'.
11427 If the output control string is written as a brace block instead of a
11428 double-quoted string, it is automatically assumed to be C code. In that
11429 case, it is not necessary to put in a leading asterisk, or to escape the
11430 doublequotes surrounding C string literals.
11432 The operands may be found in the array `operands', whose C data type
11435 It is very common to select different ways of generating assembler code
11436 based on whether an immediate operand is within a certain range. Be
11437 careful when doing this, because the result of `INTVAL' is an integer
11438 on the host machine. If the host machine has more bits in an `int'
11439 than the target machine has in the mode in which the constant will be
11440 used, then some of the bits you get from `INTVAL' will be superfluous.
11441 For proper results, you must carefully disregard the values of those
11444 It is possible to output an assembler instruction and then go on to
11445 output or compute more of them, using the subroutine `output_asm_insn'.
11446 This receives two arguments: a template-string and a vector of
11447 operands. The vector may be `operands', or it may be another array of
11448 `rtx' that you declare locally and initialize yourself.
11450 When an insn pattern has multiple alternatives in its constraints,
11451 often the appearance of the assembler code is determined mostly by
11452 which alternative was matched. When this is so, the C code can test
11453 the variable `which_alternative', which is the ordinal number of the
11454 alternative that was actually satisfied (0 for the first, 1 for the
11455 second alternative, etc.).
11457 For example, suppose there are two opcodes for storing zero, `clrreg'
11458 for registers and `clrmem' for memory locations. Here is how a pattern
11459 could use `which_alternative' to choose between them:
11462 [(set (match_operand:SI 0 "general_operand" "=r,m")
11466 return (which_alternative == 0
11467 ? "clrreg %0" : "clrmem %0");
11470 The example above, where the assembler code to generate was _solely_
11471 determined by the alternative, could also have been specified as
11472 follows, having the output control string start with a `@':
11475 [(set (match_operand:SI 0 "general_operand" "=r,m")
11483 File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc
11488 A predicate determines whether a `match_operand' or `match_operator'
11489 expression matches, and therefore whether the surrounding instruction
11490 pattern will be used for that combination of operands. GCC has a
11491 number of machine-independent predicates, and you can define
11492 machine-specific predicates as needed. By convention, predicates used
11493 with `match_operand' have names that end in `_operand', and those used
11494 with `match_operator' have names that end in `_operator'.
11496 All predicates are Boolean functions (in the mathematical sense) of
11497 two arguments: the RTL expression that is being considered at that
11498 position in the instruction pattern, and the machine mode that the
11499 `match_operand' or `match_operator' specifies. In this section, the
11500 first argument is called OP and the second argument MODE. Predicates
11501 can be called from C as ordinary two-argument functions; this can be
11502 useful in output templates or other machine-specific code.
11504 Operand predicates can allow operands that are not actually acceptable
11505 to the hardware, as long as the constraints give reload the ability to
11506 fix them up (*note Constraints::). However, GCC will usually generate
11507 better code if the predicates specify the requirements of the machine
11508 instructions as closely as possible. Reload cannot fix up operands
11509 that must be constants ("immediate operands"); you must use a predicate
11510 that allows only constants, or else enforce the requirement in the
11513 Most predicates handle their MODE argument in a uniform manner. If
11514 MODE is `VOIDmode' (unspecified), then OP can have any mode. If MODE
11515 is anything else, then OP must have the same mode, unless OP is a
11516 `CONST_INT' or integer `CONST_DOUBLE'. These RTL expressions always
11517 have `VOIDmode', so it would be counterproductive to check that their
11518 mode matches. Instead, predicates that accept `CONST_INT' and/or
11519 integer `CONST_DOUBLE' check that the value stored in the constant will
11520 fit in the requested mode.
11522 Predicates with this behavior are called "normal". `genrecog' can
11523 optimize the instruction recognizer based on knowledge of how normal
11524 predicates treat modes. It can also diagnose certain kinds of common
11525 errors in the use of normal predicates; for instance, it is almost
11526 always an error to use a normal predicate without specifying a mode.
11528 Predicates that do something different with their MODE argument are
11529 called "special". The generic predicates `address_operand' and
11530 `pmode_register_operand' are special predicates. `genrecog' does not
11531 do any optimizations or diagnosis when special predicates are used.
11535 * Machine-Independent Predicates:: Predicates available to all back ends.
11536 * Defining Predicates:: How to write machine-specific predicate
11540 File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates
11542 13.7.1 Machine-Independent Predicates
11543 -------------------------------------
11545 These are the generic predicates available to all back ends. They are
11546 defined in `recog.c'. The first category of predicates allow only
11547 constant, or "immediate", operands.
11549 -- Function: immediate_operand
11550 This predicate allows any sort of constant that fits in MODE. It
11551 is an appropriate choice for instructions that take operands that
11554 -- Function: const_int_operand
11555 This predicate allows any `CONST_INT' expression that fits in
11556 MODE. It is an appropriate choice for an immediate operand that
11557 does not allow a symbol or label.
11559 -- Function: const_double_operand
11560 This predicate accepts any `CONST_DOUBLE' expression that has
11561 exactly MODE. If MODE is `VOIDmode', it will also accept
11562 `CONST_INT'. It is intended for immediate floating point
11565 The second category of predicates allow only some kind of machine
11568 -- Function: register_operand
11569 This predicate allows any `REG' or `SUBREG' expression that is
11570 valid for MODE. It is often suitable for arithmetic instruction
11571 operands on a RISC machine.
11573 -- Function: pmode_register_operand
11574 This is a slight variant on `register_operand' which works around
11575 a limitation in the machine-description reader.
11577 (match_operand N "pmode_register_operand" CONSTRAINT)
11581 (match_operand:P N "register_operand" CONSTRAINT)
11583 would mean, if the machine-description reader accepted `:P' mode
11584 suffixes. Unfortunately, it cannot, because `Pmode' is an alias
11585 for some other mode, and might vary with machine-specific options.
11588 -- Function: scratch_operand
11589 This predicate allows hard registers and `SCRATCH' expressions,
11590 but not pseudo-registers. It is used internally by
11591 `match_scratch'; it should not be used directly.
11593 The third category of predicates allow only some kind of memory
11596 -- Function: memory_operand
11597 This predicate allows any valid reference to a quantity of mode
11598 MODE in memory, as determined by the weak form of
11599 `GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::).
11601 -- Function: address_operand
11602 This predicate is a little unusual; it allows any operand that is a
11603 valid expression for the _address_ of a quantity of mode MODE,
11604 again determined by the weak form of `GO_IF_LEGITIMATE_ADDRESS'.
11605 To first order, if `(mem:MODE (EXP))' is acceptable to
11606 `memory_operand', then EXP is acceptable to `address_operand'.
11607 Note that EXP does not necessarily have the mode MODE.
11609 -- Function: indirect_operand
11610 This is a stricter form of `memory_operand' which allows only
11611 memory references with a `general_operand' as the address
11612 expression. New uses of this predicate are discouraged, because
11613 `general_operand' is very permissive, so it's hard to tell what an
11614 `indirect_operand' does or does not allow. If a target has
11615 different requirements for memory operands for different
11616 instructions, it is better to define target-specific predicates
11617 which enforce the hardware's requirements explicitly.
11619 -- Function: push_operand
11620 This predicate allows a memory reference suitable for pushing a
11621 value onto the stack. This will be a `MEM' which refers to
11622 `stack_pointer_rtx', with a side-effect in its address expression
11623 (*note Incdec::); which one is determined by the `STACK_PUSH_CODE'
11624 macro (*note Frame Layout::).
11626 -- Function: pop_operand
11627 This predicate allows a memory reference suitable for popping a
11628 value off the stack. Again, this will be a `MEM' referring to
11629 `stack_pointer_rtx', with a side-effect in its address expression.
11630 However, this time `STACK_POP_CODE' is expected.
11632 The fourth category of predicates allow some combination of the above
11635 -- Function: nonmemory_operand
11636 This predicate allows any immediate or register operand valid for
11639 -- Function: nonimmediate_operand
11640 This predicate allows any register or memory operand valid for
11643 -- Function: general_operand
11644 This predicate allows any immediate, register, or memory operand
11647 Finally, there is one generic operator predicate.
11649 -- Function: comparison_operator
11650 This predicate matches any expression which performs an arithmetic
11651 comparison in MODE; that is, `COMPARISON_P' is true for the
11655 File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates
11657 13.7.2 Defining Machine-Specific Predicates
11658 -------------------------------------------
11660 Many machines have requirements for their operands that cannot be
11661 expressed precisely using the generic predicates. You can define
11662 additional predicates using `define_predicate' and
11663 `define_special_predicate' expressions. These expressions have three
11666 * The name of the predicate, as it will be referred to in
11667 `match_operand' or `match_operator' expressions.
11669 * An RTL expression which evaluates to true if the predicate allows
11670 the operand OP, false if it does not. This expression can only use
11671 the following RTL codes:
11674 When written inside a predicate expression, a `MATCH_OPERAND'
11675 expression evaluates to true if the predicate it names would
11676 allow OP. The operand number and constraint are ignored.
11677 Due to limitations in `genrecog', you can only refer to
11678 generic predicates and predicates that have already been
11682 This expression has one operand, a string constant containing
11683 a comma-separated list of RTX code names (in lower case). It
11684 evaluates to true if OP has any of the listed codes.
11687 This expression has one operand, a string constant containing
11688 a C expression. The predicate's arguments, OP and MODE, are
11689 available with those names in the C expression. The
11690 `MATCH_TEST' evaluates to true if the C expression evaluates
11691 to a nonzero value. `MATCH_TEST' expressions must not have
11698 The basic `MATCH_' expressions can be combined using these
11699 logical operators, which have the semantics of the C operators
11700 `&&', `||', `!', and `? :' respectively.
11702 * An optional block of C code, which should execute `return true' if
11703 the predicate is found to match and `return false' if it does not.
11704 It must not have any side effects. The predicate arguments, OP
11705 and MODE, are available with those names.
11707 If a code block is present in a predicate definition, then the RTL
11708 expression must evaluate to true _and_ the code block must execute
11709 `return true' for the predicate to allow the operand. The RTL
11710 expression is evaluated first; do not re-check anything in the
11711 code block that was checked in the RTL expression.
11713 The program `genrecog' scans `define_predicate' and
11714 `define_special_predicate' expressions to determine which RTX codes are
11715 possibly allowed. You should always make this explicit in the RTL
11716 predicate expression, using `MATCH_OPERAND' and `MATCH_CODE'.
11718 Here is an example of a simple predicate definition, from the IA64
11719 machine description:
11721 ;; True if OP is a `SYMBOL_REF' which refers to the sdata section.
11722 (define_predicate "small_addr_symbolic_operand"
11723 (and (match_code "symbol_ref")
11724 (match_test "SYMBOL_REF_SMALL_ADDR_P (op)")))
11726 And here is another, showing the use of the C block.
11728 ;; True if OP is a register operand that is (or could be) a GR reg.
11729 (define_predicate "gr_register_operand"
11730 (match_operand 0 "register_operand")
11732 unsigned int regno;
11733 if (GET_CODE (op) == SUBREG)
11734 op = SUBREG_REG (op);
11736 regno = REGNO (op);
11737 return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno));
11740 Predicates written with `define_predicate' automatically include a
11741 test that MODE is `VOIDmode', or OP has the same mode as MODE, or OP is
11742 a `CONST_INT' or `CONST_DOUBLE'. They do _not_ check specifically for
11743 integer `CONST_DOUBLE', nor do they test that the value of either kind
11744 of constant fits in the requested mode. This is because
11745 target-specific predicates that take constants usually have to do more
11746 stringent value checks anyway. If you need the exact same treatment of
11747 `CONST_INT' or `CONST_DOUBLE' that the generic predicates provide, use
11748 a `MATCH_OPERAND' subexpression to call `const_int_operand',
11749 `const_double_operand', or `immediate_operand'.
11751 Predicates written with `define_special_predicate' do not get any
11752 automatic mode checks, and are treated as having special mode handling
11755 The program `genpreds' is responsible for generating code to test
11756 predicates. It also writes a header file containing function
11757 declarations for all machine-specific predicates. It is not necessary
11758 to declare these predicates in `CPU-protos.h'.
11761 File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc
11763 13.8 Operand Constraints
11764 ========================
11766 Each `match_operand' in an instruction pattern can specify constraints
11767 for the operands allowed. The constraints allow you to fine-tune
11768 matching within the set of operands allowed by the predicate.
11770 Constraints can say whether an operand may be in a register, and which
11771 kinds of register; whether the operand can be a memory reference, and
11772 which kinds of address; whether the operand may be an immediate
11773 constant, and which possible values it may have. Constraints can also
11774 require two operands to match.
11778 * Simple Constraints:: Basic use of constraints.
11779 * Multi-Alternative:: When an insn has two alternative constraint-patterns.
11780 * Class Preferences:: Constraints guide which hard register to put things in.
11781 * Modifiers:: More precise control over effects of constraints.
11782 * Machine Constraints:: Existing constraints for some particular machines.
11785 File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints
11787 13.8.1 Simple Constraints
11788 -------------------------
11790 The simplest kind of constraint is a string full of letters, each of
11791 which describes one kind of operand that is permitted. Here are the
11792 letters that are allowed:
11795 Whitespace characters are ignored and can be inserted at any
11796 position except the first. This enables each alternative for
11797 different operands to be visually aligned in the machine
11798 description even if they have different number of constraints and
11802 A memory operand is allowed, with any kind of address that the
11803 machine supports in general.
11806 A memory operand is allowed, but only if the address is
11807 "offsettable". This means that adding a small integer (actually,
11808 the width in bytes of the operand, as determined by its machine
11809 mode) may be added to the address and the result is also a valid
11812 For example, an address which is constant is offsettable; so is an
11813 address that is the sum of a register and a constant (as long as a
11814 slightly larger constant is also within the range of
11815 address-offsets supported by the machine); but an autoincrement or
11816 autodecrement address is not offsettable. More complicated
11817 indirect/indexed addresses may or may not be offsettable depending
11818 on the other addressing modes that the machine supports.
11820 Note that in an output operand which can be matched by another
11821 operand, the constraint letter `o' is valid only when accompanied
11822 by both `<' (if the target machine has predecrement addressing)
11823 and `>' (if the target machine has preincrement addressing).
11826 A memory operand that is not offsettable. In other words,
11827 anything that would fit the `m' constraint but not the `o'
11831 A memory operand with autodecrement addressing (either
11832 predecrement or postdecrement) is allowed.
11835 A memory operand with autoincrement addressing (either
11836 preincrement or postincrement) is allowed.
11839 A register operand is allowed provided that it is in a general
11843 An immediate integer operand (one with constant value) is allowed.
11844 This includes symbolic constants whose values will be known only at
11845 assembly time or later.
11848 An immediate integer operand with a known numeric value is allowed.
11849 Many systems cannot support assembly-time constants for operands
11850 less than a word wide. Constraints for these operands should use
11851 `n' rather than `i'.
11853 `I', `J', `K', ... `P'
11854 Other letters in the range `I' through `P' may be defined in a
11855 machine-dependent fashion to permit immediate integer operands with
11856 explicit integer values in specified ranges. For example, on the
11857 68000, `I' is defined to stand for the range of values 1 to 8.
11858 This is the range permitted as a shift count in the shift
11862 An immediate floating operand (expression code `const_double') is
11863 allowed, but only if the target floating point format is the same
11864 as that of the host machine (on which the compiler is running).
11867 An immediate floating operand (expression code `const_double' or
11868 `const_vector') is allowed.
11871 `G' and `H' may be defined in a machine-dependent fashion to
11872 permit immediate floating operands in particular ranges of values.
11875 An immediate integer operand whose value is not an explicit
11876 integer is allowed.
11878 This might appear strange; if an insn allows a constant operand
11879 with a value not known at compile time, it certainly must allow
11880 any known value. So why use `s' instead of `i'? Sometimes it
11881 allows better code to be generated.
11883 For example, on the 68000 in a fullword instruction it is possible
11884 to use an immediate operand; but if the immediate value is between
11885 -128 and 127, better code results from loading the value into a
11886 register and using the register. This is because the load into
11887 the register can be done with a `moveq' instruction. We arrange
11888 for this to happen by defining the letter `K' to mean "any integer
11889 outside the range -128 to 127", and then specifying `Ks' in the
11890 operand constraints.
11893 Any register, memory or immediate integer operand is allowed,
11894 except for registers that are not general registers.
11897 Any operand whatsoever is allowed, even if it does not satisfy
11898 `general_operand'. This is normally used in the constraint of a
11899 `match_scratch' when certain alternatives will not actually
11900 require a scratch register.
11902 `0', `1', `2', ... `9'
11903 An operand that matches the specified operand number is allowed.
11904 If a digit is used together with letters within the same
11905 alternative, the digit should come last.
11907 This number is allowed to be more than a single digit. If multiple
11908 digits are encountered consecutively, they are interpreted as a
11909 single decimal integer. There is scant chance for ambiguity,
11910 since to-date it has never been desirable that `10' be interpreted
11911 as matching either operand 1 _or_ operand 0. Should this be
11912 desired, one can use multiple alternatives instead.
11914 This is called a "matching constraint" and what it really means is
11915 that the assembler has only a single operand that fills two roles
11916 considered separate in the RTL insn. For example, an add insn has
11917 two input operands and one output operand in the RTL, but on most
11918 CISC machines an add instruction really has only two operands, one
11919 of them an input-output operand:
11923 Matching constraints are used in these circumstances. More
11924 precisely, the two operands that match must include one input-only
11925 operand and one output-only operand. Moreover, the digit must be a
11926 smaller number than the number of the operand that uses it in the
11929 For operands to match in a particular case usually means that they
11930 are identical-looking RTL expressions. But in a few special cases
11931 specific kinds of dissimilarity are allowed. For example, `*x' as
11932 an input operand will match `*x++' as an output operand. For
11933 proper results in such cases, the output template should always
11934 use the output-operand's number when printing the operand.
11937 An operand that is a valid memory address is allowed. This is for
11938 "load address" and "push address" instructions.
11940 `p' in the constraint must be accompanied by `address_operand' as
11941 the predicate in the `match_operand'. This predicate interprets
11942 the mode specified in the `match_operand' as the mode of the memory
11943 reference for which the address would be valid.
11946 Other letters can be defined in machine-dependent fashion to stand
11947 for particular classes of registers or other arbitrary operand
11948 types. `d', `a' and `f' are defined on the 68000/68020 to stand
11949 for data, address and floating point registers.
11951 The machine description macro `REG_CLASS_FROM_LETTER' has first
11952 cut at the otherwise unused letters. If it evaluates to `NO_REGS',
11953 then `EXTRA_CONSTRAINT' is evaluated.
11955 A typical use for `EXTRA_CONSTRAINT' would be to distinguish
11956 certain types of memory references that affect other insn operands.
11958 In order to have valid assembler code, each operand must satisfy its
11959 constraint. But a failure to do so does not prevent the pattern from
11960 applying to an insn. Instead, it directs the compiler to modify the
11961 code so that the constraint will be satisfied. Usually this is done by
11962 copying an operand into a register.
11964 Contrast, therefore, the two instruction patterns that follow:
11967 [(set (match_operand:SI 0 "general_operand" "=r")
11968 (plus:SI (match_dup 0)
11969 (match_operand:SI 1 "general_operand" "r")))]
11973 which has two operands, one of which must appear in two places, and
11976 [(set (match_operand:SI 0 "general_operand" "=r")
11977 (plus:SI (match_operand:SI 1 "general_operand" "0")
11978 (match_operand:SI 2 "general_operand" "r")))]
11982 which has three operands, two of which are required by a constraint to
11983 be identical. If we are considering an insn of the form
11987 (plus:SI (reg:SI 6) (reg:SI 109)))
11990 the first pattern would not apply at all, because this insn does not
11991 contain two identical subexpressions in the right place. The pattern
11992 would say, "That does not look like an add instruction; try other
11993 patterns". The second pattern would say, "Yes, that's an add
11994 instruction, but there is something wrong with it". It would direct
11995 the reload pass of the compiler to generate additional insns to make
11996 the constraint true. The results might look like this:
11999 (set (reg:SI 3) (reg:SI 6))
12004 (plus:SI (reg:SI 3) (reg:SI 109)))
12007 It is up to you to make sure that each operand, in each pattern, has
12008 constraints that can handle any RTL expression that could be present for
12009 that operand. (When multiple alternatives are in use, each pattern
12010 must, for each possible combination of operand expressions, have at
12011 least one alternative which can handle that combination of operands.)
12012 The constraints don't need to _allow_ any possible operand--when this is
12013 the case, they do not constrain--but they must at least point the way to
12014 reloading any possible operand so that it will fit.
12016 * If the constraint accepts whatever operands the predicate permits,
12017 there is no problem: reloading is never necessary for this operand.
12019 For example, an operand whose constraints permit everything except
12020 registers is safe provided its predicate rejects registers.
12022 An operand whose predicate accepts only constant values is safe
12023 provided its constraints include the letter `i'. If any possible
12024 constant value is accepted, then nothing less than `i' will do; if
12025 the predicate is more selective, then the constraints may also be
12028 * Any operand expression can be reloaded by copying it into a
12029 register. So if an operand's constraints allow some kind of
12030 register, it is certain to be safe. It need not permit all
12031 classes of registers; the compiler knows how to copy a register
12032 into another register of the proper class in order to make an
12035 * A nonoffsettable memory reference can be reloaded by copying the
12036 address into a register. So if the constraint uses the letter
12037 `o', all memory references are taken care of.
12039 * A constant operand can be reloaded by allocating space in memory to
12040 hold it as preinitialized data. Then the memory reference can be
12041 used in place of the constant. So if the constraint uses the
12042 letters `o' or `m', constant operands are not a problem.
12044 * If the constraint permits a constant and a pseudo register used in
12045 an insn was not allocated to a hard register and is equivalent to
12046 a constant, the register will be replaced with the constant. If
12047 the predicate does not permit a constant and the insn is
12048 re-recognized for some reason, the compiler will crash. Thus the
12049 predicate must always recognize any objects allowed by the
12052 If the operand's predicate can recognize registers, but the constraint
12053 does not permit them, it can make the compiler crash. When this
12054 operand happens to be a register, the reload pass will be stymied,
12055 because it does not know how to copy a register temporarily into memory.
12057 If the predicate accepts a unary operator, the constraint applies to
12058 the operand. For example, the MIPS processor at ISA level 3 supports an
12059 instruction which adds two registers in `SImode' to produce a `DImode'
12060 result, but only if the registers are correctly sign extended. This
12061 predicate for the input operands accepts a `sign_extend' of an `SImode'
12062 register. Write the constraint to indicate the type of register that
12063 is required for the operand of the `sign_extend'.
12066 File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints
12068 13.8.2 Multiple Alternative Constraints
12069 ---------------------------------------
12071 Sometimes a single instruction has multiple alternative sets of possible
12072 operands. For example, on the 68000, a logical-or instruction can
12073 combine register or an immediate value into memory, or it can combine
12074 any kind of operand into a register; but it cannot combine one memory
12075 location into another.
12077 These constraints are represented as multiple alternatives. An
12078 alternative can be described by a series of letters for each operand.
12079 The overall constraint for an operand is made from the letters for this
12080 operand from the first alternative, a comma, the letters for this
12081 operand from the second alternative, a comma, and so on until the last
12082 alternative. Here is how it is done for fullword logical-or on the
12085 (define_insn "iorsi3"
12086 [(set (match_operand:SI 0 "general_operand" "=m,d")
12087 (ior:SI (match_operand:SI 1 "general_operand" "%0,0")
12088 (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
12091 The first alternative has `m' (memory) for operand 0, `0' for operand
12092 1 (meaning it must match operand 0), and `dKs' for operand 2. The
12093 second alternative has `d' (data register) for operand 0, `0' for
12094 operand 1, and `dmKs' for operand 2. The `=' and `%' in the
12095 constraints apply to all the alternatives; their meaning is explained
12096 in the next section (*note Class Preferences::).
12098 If all the operands fit any one alternative, the instruction is valid.
12099 Otherwise, for each alternative, the compiler counts how many
12100 instructions must be added to copy the operands so that that
12101 alternative applies. The alternative requiring the least copying is
12102 chosen. If two alternatives need the same amount of copying, the one
12103 that comes first is chosen. These choices can be altered with the `?'
12104 and `!' characters:
12107 Disparage slightly the alternative that the `?' appears in, as a
12108 choice when no alternative applies exactly. The compiler regards
12109 this alternative as one unit more costly for each `?' that appears
12113 Disparage severely the alternative that the `!' appears in. This
12114 alternative can still be used if it fits without reloading, but if
12115 reloading is needed, some other alternative will be used.
12117 When an insn pattern has multiple alternatives in its constraints,
12118 often the appearance of the assembler code is determined mostly by which
12119 alternative was matched. When this is so, the C code for writing the
12120 assembler code can use the variable `which_alternative', which is the
12121 ordinal number of the alternative that was actually satisfied (0 for
12122 the first, 1 for the second alternative, etc.). *Note Output
12126 File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints
12128 13.8.3 Register Class Preferences
12129 ---------------------------------
12131 The operand constraints have another function: they enable the compiler
12132 to decide which kind of hardware register a pseudo register is best
12133 allocated to. The compiler examines the constraints that apply to the
12134 insns that use the pseudo register, looking for the machine-dependent
12135 letters such as `d' and `a' that specify classes of registers. The
12136 pseudo register is put in whichever class gets the most "votes". The
12137 constraint letters `g' and `r' also vote: they vote in favor of a
12138 general register. The machine description says which registers are
12139 considered general.
12141 Of course, on some machines all registers are equivalent, and no
12142 register classes are defined. Then none of this complexity is relevant.
12145 File: gccint.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints
12147 13.8.4 Constraint Modifier Characters
12148 -------------------------------------
12150 Here are constraint modifier characters.
12153 Means that this operand is write-only for this instruction: the
12154 previous value is discarded and replaced by output data.
12157 Means that this operand is both read and written by the
12160 When the compiler fixes up the operands to satisfy the constraints,
12161 it needs to know which operands are inputs to the instruction and
12162 which are outputs from it. `=' identifies an output; `+'
12163 identifies an operand that is both input and output; all other
12164 operands are assumed to be input only.
12166 If you specify `=' or `+' in a constraint, you put it in the first
12167 character of the constraint string.
12170 Means (in a particular alternative) that this operand is an
12171 "earlyclobber" operand, which is modified before the instruction is
12172 finished using the input operands. Therefore, this operand may
12173 not lie in a register that is used as an input operand or as part
12174 of any memory address.
12176 `&' applies only to the alternative in which it is written. In
12177 constraints with multiple alternatives, sometimes one alternative
12178 requires `&' while others do not. See, for example, the `movdf'
12181 An input operand can be tied to an earlyclobber operand if its only
12182 use as an input occurs before the early result is written. Adding
12183 alternatives of this form often allows GCC to produce better code
12184 when only some of the inputs can be affected by the earlyclobber.
12185 See, for example, the `mulsi3' insn of the ARM.
12187 `&' does not obviate the need to write `='.
12190 Declares the instruction to be commutative for this operand and the
12191 following operand. This means that the compiler may interchange
12192 the two operands if that is the cheapest way to make all operands
12193 fit the constraints. This is often used in patterns for addition
12194 instructions that really have only two operands: the result must
12195 go in one of the arguments. Here for example, is how the 68000
12196 halfword-add instruction is defined:
12198 (define_insn "addhi3"
12199 [(set (match_operand:HI 0 "general_operand" "=m,r")
12200 (plus:HI (match_operand:HI 1 "general_operand" "%0,0")
12201 (match_operand:HI 2 "general_operand" "di,g")))]
12203 GCC can only handle one commutative pair in an asm; if you use
12204 more, the compiler may fail. Note that you need not use the
12205 modifier if the two alternatives are strictly identical; this
12206 would only waste time in the reload pass. The modifier is not
12207 operational after register allocation, so the result of
12208 `define_peephole2' and `define_split's performed after reload
12209 cannot rely on `%' to make the intended insn match.
12212 Says that all following characters, up to the next comma, are to be
12213 ignored as a constraint. They are significant only for choosing
12214 register preferences.
12217 Says that the following character should be ignored when choosing
12218 register preferences. `*' has no effect on the meaning of the
12219 constraint as a constraint, and no effect on reloading.
12221 Here is an example: the 68000 has an instruction to sign-extend a
12222 halfword in a data register, and can also sign-extend a value by
12223 copying it into an address register. While either kind of
12224 register is acceptable, the constraints on an address-register
12225 destination are less strict, so it is best if register allocation
12226 makes an address register its goal. Therefore, `*' is used so
12227 that the `d' constraint letter (for data register) is ignored when
12228 computing register preferences.
12230 (define_insn "extendhisi2"
12231 [(set (match_operand:SI 0 "general_operand" "=*d,a")
12233 (match_operand:HI 1 "general_operand" "0,g")))]
12237 File: gccint.info, Node: Machine Constraints, Prev: Modifiers, Up: Constraints
12239 13.8.5 Constraints for Particular Machines
12240 ------------------------------------------
12242 Whenever possible, you should use the general-purpose constraint letters
12243 in `asm' arguments, since they will convey meaning more readily to
12244 people reading your code. Failing that, use the constraint letters
12245 that usually have very similar meanings across architectures. The most
12246 commonly used constraints are `m' and `r' (for memory and
12247 general-purpose registers respectively; *note Simple Constraints::), and
12248 `I', usually the letter indicating the most common immediate-constant
12251 For each machine architecture, the `config/MACHINE/MACHINE.h' file
12252 defines additional constraints. These constraints are used by the
12253 compiler itself for instruction generation, as well as for `asm'
12254 statements; therefore, some of the constraints are not particularly
12255 interesting for `asm'. The constraints are defined through these
12258 `REG_CLASS_FROM_LETTER'
12259 Register class constraints (usually lowercase).
12261 `CONST_OK_FOR_LETTER_P'
12262 Immediate constant constraints, for non-floating point constants of
12263 word size or smaller precision (usually uppercase).
12265 `CONST_DOUBLE_OK_FOR_LETTER_P'
12266 Immediate constant constraints, for all floating point constants
12267 and for constants of greater than word size precision (usually
12271 Special cases of registers or memory. This macro is not required,
12272 and is only defined for some machines.
12274 Inspecting these macro definitions in the compiler source for your
12275 machine is the best way to be certain you have the right constraints.
12276 However, here is a summary of the machine-dependent constraints
12277 available on some particular machines.
12279 _ARM family--`arm.h'_
12282 Floating-point register
12285 VFP floating-point register
12288 One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0,
12292 Floating-point constant that would satisfy the constraint `F'
12296 Integer that is valid as an immediate operand in a data
12297 processing instruction. That is, an integer in the range 0
12298 to 255 rotated by a multiple of 2
12301 Integer in the range -4095 to 4095
12304 Integer that satisfies constraint `I' when inverted (ones
12308 Integer that satisfies constraint `I' when negated (twos
12312 Integer in the range 0 to 32
12315 A memory reference where the exact address is in a single
12316 register (``m'' is preferable for `asm' statements)
12319 An item in the constant pool
12322 A symbol in the text segment of the current file
12325 A memory reference suitable for VFP load/store insns
12326 (reg+constant offset)
12329 A memory reference suitable for iWMMXt load/store
12333 A memory reference suitable for the ARMv4 ldrsb instruction.
12335 _AVR family--`avr.h'_
12338 Registers from r0 to r15
12341 Registers from r16 to r23
12344 Registers from r16 to r31
12347 Registers from r24 to r31. These registers can be used in
12351 Pointer register (r26-r31)
12354 Base pointer register (r28-r31)
12357 Stack pointer register (SPH:SPL)
12360 Temporary register r0
12363 Register pair X (r27:r26)
12366 Register pair Y (r29:r28)
12369 Register pair Z (r31:r30)
12372 Constant greater than -1, less than 64
12375 Constant greater than -64, less than 1
12384 Constant that fits in 8 bits
12387 Constant integer -1
12390 Constant integer 8, 16, or 24
12396 A floating point constant 0.0
12398 _CRX Architecture--`crx.h'_
12401 Registers from r0 to r14 (registers without stack pointer)
12404 Register r16 (64-bit accumulator lo register)
12407 Register r17 (64-bit accumulator hi register)
12410 Register pair r16-r17. (64-bit accumulator lo-hi pair)
12413 Constant that fits in 3 bits
12416 Constant that fits in 4 bits
12419 Constant that fits in 5 bits
12422 Constant that is one of -1, 4, -4, 7, 8, 12, 16, 20, 32, 48
12425 Floating point constant that is legal for store immediate
12427 _PowerPC and IBM RS6000--`rs6000.h'_
12430 Address base register
12433 Floating point register
12439 `MQ', `CTR', or `LINK' register
12451 `CR' register (condition register) number 0
12454 `CR' register (condition register)
12457 `FPMEM' stack memory for FPR-GPR transfers
12460 Signed 16-bit constant
12463 Unsigned 16-bit constant shifted left 16 bits (use `L'
12464 instead for `SImode' constants)
12467 Unsigned 16-bit constant
12470 Signed 16-bit constant shifted left 16 bits
12473 Constant larger than 31
12482 Constant whose negation is a signed 16-bit constant
12485 Floating point constant that can be loaded into a register
12486 with one instruction per word
12489 Memory operand that is an offset from a register (`m' is
12490 preferable for `asm' statements)
12496 Constant suitable as a 64-bit mask operand
12499 Constant suitable as a 32-bit mask operand
12502 System V Release 4 small data area reference
12504 _MorphoTech family--`mt.h'_
12507 Constant for an arithmetic insn (16-bit signed integer).
12513 Constant for a logical insn (16-bit zero-extended integer).
12516 A constant that can be loaded with `lui' (i.e. the bottom 16
12520 A constant that takes two words to load (i.e. not matched by
12524 Negative 16-bit constants other than -65536.
12527 A 15-bit signed integer constant.
12530 A positive 16-bit constant.
12532 _Intel 386--`i386.h'_
12535 `a', `b', `c', or `d' register for the i386. For x86-64 it
12536 is equivalent to `r' class (for 8-bit instructions that do
12537 not use upper halves).
12540 `a', `b', `c', or `d' register (for 8-bit instructions, that
12541 do use upper halves).
12544 Legacy register--equivalent to `r' class in i386 mode. (for
12545 non-8-bit registers used together with 8-bit upper halves in
12546 a single instruction)
12549 Specifies the `a' or `d' registers. This is primarily useful
12550 for 64-bit integer values (when in 32-bit mode) intended to
12551 be returned with the `d' register holding the most
12552 significant bits and the `a' register holding the least
12556 Floating point register
12559 First (top of stack) floating point register
12562 Second floating point register
12574 Specifies constant that can be easily constructed in SSE
12575 register without loading it from memory.
12593 Constant in range 0 to 31 (for 32-bit shifts)
12596 Constant in range 0 to 63 (for 64-bit shifts)
12605 0, 1, 2, or 3 (shifts for `lea' instruction)
12608 Constant in range 0 to 255 (for `out' instruction)
12611 Constant in range 0 to `0xffffffff' or symbolic reference
12612 known to fit specified range. (for using immediates in zero
12613 extending 32-bit to 64-bit x86-64 instructions)
12616 Constant in range -2147483648 to 2147483647 or symbolic
12617 reference known to fit specified range. (for using
12618 immediates in 64-bit x86-64 instructions)
12621 Standard 80387 floating point constant
12623 _Intel IA-64--`ia64.h'_
12626 General register `r0' to `r3' for `addl' instruction
12632 Predicate register (`c' as in "conditional")
12635 Application register residing in M-unit
12638 Application register residing in I-unit
12641 Floating-point register
12644 Memory operand. Remember that `m' allows postincrement and
12645 postdecrement which require printing with `%Pn' on IA-64.
12646 Use `S' to disallow postincrement and postdecrement.
12649 Floating-point constant 0.0 or 1.0
12652 14-bit signed integer constant
12655 22-bit signed integer constant
12658 8-bit signed integer constant for logical instructions
12661 8-bit adjusted signed integer constant for compare pseudo-ops
12664 6-bit unsigned integer constant for shift counts
12667 9-bit signed integer constant for load and store
12674 0 or -1 for `dep' instruction
12677 Non-volatile memory for floating-point loads and stores
12680 Integer constant in the range 1 to 4 for `shladd' instruction
12683 Memory operand except postincrement and postdecrement
12688 Register in the class `ACC_REGS' (`acc0' to `acc7').
12691 Register in the class `EVEN_ACC_REGS' (`acc0' to `acc7').
12694 Register in the class `CC_REGS' (`fcc0' to `fcc3' and `icc0'
12698 Register in the class `GPR_REGS' (`gr0' to `gr63').
12701 Register in the class `EVEN_REGS' (`gr0' to `gr63'). Odd
12702 registers are excluded not in the class but through the use
12703 of a machine mode larger than 4 bytes.
12706 Register in the class `FPR_REGS' (`fr0' to `fr63').
12709 Register in the class `FEVEN_REGS' (`fr0' to `fr63'). Odd
12710 registers are excluded not in the class but through the use
12711 of a machine mode larger than 4 bytes.
12714 Register in the class `LR_REG' (the `lr' register).
12717 Register in the class `QUAD_REGS' (`gr2' to `gr63').
12718 Register numbers not divisible by 4 are excluded not in the
12719 class but through the use of a machine mode larger than 8
12723 Register in the class `ICC_REGS' (`icc0' to `icc3').
12726 Register in the class `FCC_REGS' (`fcc0' to `fcc3').
12729 Register in the class `ICR_REGS' (`cc4' to `cc7').
12732 Register in the class `FCR_REGS' (`cc0' to `cc3').
12735 Register in the class `QUAD_FPR_REGS' (`fr0' to `fr63').
12736 Register numbers not divisible by 4 are excluded not in the
12737 class but through the use of a machine mode larger than 8
12741 Register in the class `SPR_REGS' (`lcr' and `lr').
12744 Register in the class `QUAD_ACC_REGS' (`acc0' to `acc7').
12747 Register in the class `ACCG_REGS' (`accg0' to `accg7').
12750 Register in the class `CR_REGS' (`cc0' to `cc7').
12753 Floating point constant zero
12756 6-bit signed integer constant
12759 10-bit signed integer constant
12762 16-bit signed integer constant
12765 16-bit unsigned integer constant
12768 12-bit signed integer constant that is negative--i.e. in the
12769 range of -2048 to -1
12775 12-bit signed integer constant that is greater than
12776 zero--i.e. in the range of 1 to 2047.
12779 _Blackfin family--`bfin.h'_
12788 A call clobbered P register.
12791 Even-numbered D register
12794 Odd-numbered D register
12797 Accumulator register.
12800 Even-numbered accumulator register.
12803 Odd-numbered accumulator register.
12815 Registers used for circular buffering, i.e. I, B, or L
12822 Any D, P, B, M, I or L register.
12825 Additional registers typically used only in prologues and
12826 epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and
12830 Any register except accumulators or CC.
12833 Signed 16 bit integer (in the range -32768 to 32767)
12836 Unsigned 16 bit integer (in the range 0 to 65535)
12839 Signed 7 bit integer (in the range -64 to 63)
12842 Unsigned 7 bit integer (in the range 0 to 127)
12845 Unsigned 5 bit integer (in the range 0 to 31)
12848 Signed 4 bit integer (in the range -8 to 7)
12851 Signed 3 bit integer (in the range -3 to 4)
12854 Unsigned 3 bit integer (in the range 0 to 7)
12857 Constant N, where N is a single-digit constant in the range 0
12867 An integer constant with exactly a single bit set.
12870 An integer constant with all bits set except exactly one.
12882 `$sp', `$fb', `$sb'.
12885 Any control register, when they're 16 bits wide (nothing if control
12886 registers are 24 bits wide)
12889 Any control register, when they're 24 bits wide.
12895 $r0, $r1, $r2, $r3.
12898 $r0 or $r2, or $r2r0 for 32 bit values.
12901 $r1 or $r3, or $r3r1 for 32 bit values.
12904 A register that can hold a 64 bit value.
12907 $r0 or $r1 (registers with addressable high/low bytes)
12916 Address registers when they're 16 bits wide.
12919 Address registers when they're 24 bits wide.
12922 Registers that can hold QI values.
12925 Registers that can be used with displacements ($a0, $a1, $sb).
12928 Registers that can hold 32 bit values.
12931 Registers that can hold 16 bit values.
12934 Registers chat can hold 16 bit values, including all control
12938 $r0 through R1, plus $a0 and $a1.
12941 The flags register.
12944 The memory-based pseudo-registers $mem0 through $mem15.
12947 Registers that can hold pointers (16 bit registers for r8c, m16c;
12948 24 bit registers for m32cm, m32c).
12951 Matches multiple registers in a PARALLEL to form a larger register.
12952 Used to match function return values.
12967 -8 ... -1 or 1 ... 8
12970 -16 ... -1 or 1 ... 16
12973 -8 ... -1 or 1 ... 8
12979 An 8 bit value with exactly one bit set.
12982 A 16 bit value with exactly one bit set.
12985 The common src/dest memory addressing modes.
12988 Memory addressed using $a0 or $a1.
12991 Memory addressed with immediate addresses.
12994 Memory addressed using the stack pointer ($sp).
12997 Memory addressed using the frame base register ($fb).
13000 Memory addressed using the small base register ($sb).
13008 General-purpose integer register
13011 Floating-point register (if available)
13020 `Hi' or `Lo' register
13023 General-purpose integer register
13026 Floating-point status register
13029 Signed 16-bit constant (for arithmetic instructions)
13035 Zero-extended 16-bit constant (for logic instructions)
13038 Constant with low 16 bits zero (can be loaded with `lui')
13041 32-bit constant which requires two instructions to load (a
13042 constant which is not `I', `K', or `L')
13045 Negative 16-bit constant
13051 Positive 16-bit constant
13054 Floating point zero
13057 Memory reference that can be loaded with more than one
13058 instruction (`m' is preferable for `asm' statements)
13061 Memory reference that can be loaded with one instruction (`m'
13062 is preferable for `asm' statements)
13065 Memory reference in external OSF/rose PIC format (`m' is
13066 preferable for `asm' statements)
13068 _Motorola 680x0--`m68k.h'_
13077 68881 floating-point register, if available
13080 Integer in the range 1 to 8
13083 16-bit signed number
13086 Signed number whose magnitude is greater than 0x80
13089 Integer in the range -8 to -1
13092 Signed number whose magnitude is greater than 0x100
13095 Floating point constant that is not a 68881 constant
13097 _Motorola 68HC11 & 68HC12 families--`m68hc11.h'_
13112 Temporary soft register _.tmp
13115 A soft register _.d1 to _.d31
13118 Stack pointer register
13127 Pseudo register `z' (replaced by `x' or `y' at the end)
13130 An address register: x, y or z
13133 An address register: x or y
13136 Register pair (x:d) to form a 32-bit value
13139 Constants in the range -65536 to 65535
13142 Constants whose 16-bit low part is zero
13145 Constant integer 1 or -1
13148 Constant integer 16
13151 Constants in the range -8 to 2
13157 Floating-point register on the SPARC-V8 architecture and
13158 lower floating-point register on the SPARC-V9 architecture.
13161 Floating-point register. It is equivalent to `f' on the
13162 SPARC-V8 architecture and contains both lower and upper
13163 floating-point registers on the SPARC-V9 architecture.
13166 Floating-point condition code register.
13169 Lower floating-point register. It is only valid on the
13170 SPARC-V9 architecture when the Visual Instruction Set is
13174 Floating-point register. It is only valid on the SPARC-V9
13175 architecture when the Visual Instruction Set is available.
13178 64-bit global or out register for the SPARC-V8+ architecture.
13181 Signed 13-bit constant
13187 32-bit constant with the low 12 bits clear (a constant that
13188 can be loaded with the `sethi' instruction)
13191 A constant in the range supported by `movcc' instructions
13194 A constant in the range supported by `movrcc' instructions
13197 Same as `K', except that it verifies that bits that are not
13198 in the lower 32-bit range are all zero. Must be used instead
13199 of `K' for modes wider than `SImode'
13205 Floating-point zero
13208 Signed 13-bit constant, sign-extended to 32 or 64 bits
13211 Floating-point constant whose integral representation can be
13212 moved into an integer register using a single sethi
13216 Floating-point constant whose integral representation can be
13217 moved into an integer register using a single mov instruction
13220 Floating-point constant whose integral representation can be
13221 moved into an integer register using a high/lo_sum
13222 instruction sequence
13225 Memory address aligned to an 8-byte boundary
13231 Memory address for `e' constraint registers
13237 _TMS320C3x/C4x--`c4x.h'_
13240 Auxiliary (address) register (ar0-ar7)
13243 Stack pointer register (sp)
13246 Standard (32-bit) precision integer register
13249 Extended (40-bit) precision register (r0-r11)
13252 Block count register (bk)
13255 Extended (40-bit) precision low register (r0-r7)
13258 Extended (40-bit) precision register (r0-r1)
13261 Extended (40-bit) precision register (r2-r3)
13264 Repeat count register (rc)
13267 Index register (ir0-ir1)
13270 Status (condition code) register (st)
13273 Data page register (dp)
13276 Floating-point zero
13279 Immediate 16-bit floating-point constant
13282 Signed 16-bit constant
13285 Signed 8-bit constant
13288 Signed 5-bit constant
13291 Unsigned 16-bit constant
13294 Unsigned 8-bit constant
13297 Ones complement of unsigned 16-bit constant
13300 High 16-bit constant (32-bit constant with 16 LSBs zero)
13303 Indirect memory reference with signed 8-bit or index register
13307 Indirect memory reference with unsigned 5-bit displacement
13310 Indirect memory reference with 1 bit or index register
13314 Direct memory reference
13320 _S/390 and zSeries--`s390.h'_
13323 Address register (general purpose register except r0)
13326 Condition code register
13329 Data register (arbitrary general purpose register)
13332 Floating-point register
13335 Unsigned 8-bit constant (0-255)
13338 Unsigned 12-bit constant (0-4095)
13341 Signed 16-bit constant (-32768-32767)
13344 Value appropriate as displacement.
13346 for short displacement
13348 `(-524288..524287)'
13349 for long displacement
13352 Constant integer with a value of 0x7fffffff.
13355 Multiple letter constraint followed by 4 parameter letters.
13357 number of the part counting from most to least
13364 mode of the containing operand
13367 value of the other parts (F--all bits set)
13368 The constraint matches if the specified part of a constant
13369 has a value different from it's other parts.
13372 Memory reference without index register and with short
13376 Memory reference with index register and short displacement.
13379 Memory reference without index register but with long
13383 Memory reference with index register and long displacement.
13386 Pointer with short displacement.
13389 Pointer with long displacement.
13392 Shift count operand.
13395 _Xstormy16--`stormy16.h'_
13410 Registers r0 through r7.
13413 Registers r0 and r1.
13416 The carry register.
13419 Registers r8 and r9.
13422 A constant between 0 and 3 inclusive.
13425 A constant that has exactly one bit set.
13428 A constant that has exactly one bit clear.
13431 A constant between 0 and 255 inclusive.
13434 A constant between -255 and 0 inclusive.
13437 A constant between -3 and 0 inclusive.
13440 A constant between 1 and 4 inclusive.
13443 A constant between -4 and -1 inclusive.
13446 A memory reference that is a stack push.
13449 A memory reference that is a stack pop.
13452 A memory reference that refers to a constant address of known
13456 The register indicated by Rx (not implemented yet).
13459 A constant that is not between 2 and 15 inclusive.
13465 _Xtensa--`xtensa.h'_
13468 General-purpose 32-bit register
13471 One-bit boolean register
13474 MAC16 40-bit accumulator register
13477 Signed 12-bit integer constant, for use in MOVI instructions
13480 Signed 8-bit integer constant, for use in ADDI instructions
13483 Integer constant valid for BccI instructions
13486 Unsigned constant valid for BccUI instructions
13491 File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc
13493 13.9 Standard Pattern Names For Generation
13494 ==========================================
13496 Here is a table of the instruction names that are meaningful in the RTL
13497 generation pass of the compiler. Giving one of these names to an
13498 instruction pattern tells the RTL generation pass that it can use the
13499 pattern to accomplish a certain task.
13502 Here M stands for a two-letter machine mode name, in lowercase.
13503 This instruction pattern moves data with that machine mode from
13504 operand 1 to operand 0. For example, `movsi' moves full-word data.
13506 If operand 0 is a `subreg' with mode M of a register whose own
13507 mode is wider than M, the effect of this instruction is to store
13508 the specified value in the part of the register that corresponds
13509 to mode M. Bits outside of M, but which are within the same
13510 target word as the `subreg' are undefined. Bits which are outside
13511 the target word are left unchanged.
13513 This class of patterns is special in several ways. First of all,
13514 each of these names up to and including full word size _must_ be
13515 defined, because there is no other way to copy a datum from one
13516 place to another. If there are patterns accepting operands in
13517 larger modes, `movM' must be defined for integer modes of those
13520 Second, these patterns are not used solely in the RTL generation
13521 pass. Even the reload pass can generate move insns to copy values
13522 from stack slots into temporary registers. When it does so, one
13523 of the operands is a hard register and the other is an operand
13524 that can need to be reloaded into a register.
13526 Therefore, when given such a pair of operands, the pattern must
13527 generate RTL which needs no reloading and needs no temporary
13528 registers--no registers other than the operands. For example, if
13529 you support the pattern with a `define_expand', then in such a
13530 case the `define_expand' mustn't call `force_reg' or any other such
13531 function which might generate new pseudo registers.
13533 This requirement exists even for subword modes on a RISC machine
13534 where fetching those modes from memory normally requires several
13535 insns and some temporary registers.
13537 During reload a memory reference with an invalid address may be
13538 passed as an operand. Such an address will be replaced with a
13539 valid address later in the reload pass. In this case, nothing may
13540 be done with the address except to use it as it stands. If it is
13541 copied, it will not be replaced with a valid address. No attempt
13542 should be made to make such an address into a valid address and no
13543 routine (such as `change_address') that will do so may be called.
13544 Note that `general_operand' will fail when applied to such an
13547 The global variable `reload_in_progress' (which must be explicitly
13548 declared if required) can be used to determine whether such special
13549 handling is required.
13551 The variety of operands that have reloads depends on the rest of
13552 the machine description, but typically on a RISC machine these can
13553 only be pseudo registers that did not get hard registers, while on
13554 other machines explicit memory references will get optional
13557 If a scratch register is required to move an object to or from
13558 memory, it can be allocated using `gen_reg_rtx' prior to life
13561 If there are cases which need scratch registers during or after
13562 reload, you must define `SECONDARY_INPUT_RELOAD_CLASS' and/or
13563 `SECONDARY_OUTPUT_RELOAD_CLASS' to detect them, and provide
13564 patterns `reload_inM' or `reload_outM' to handle them. *Note
13565 Register Classes::.
13567 The global variable `no_new_pseudos' can be used to determine if it
13568 is unsafe to create new pseudo registers. If this variable is
13569 nonzero, then it is unsafe to call `gen_reg_rtx' to allocate a new
13572 The constraints on a `movM' must permit moving any hard register
13573 to any other hard register provided that `HARD_REGNO_MODE_OK'
13574 permits mode M in both registers and `REGISTER_MOVE_COST' applied
13575 to their classes returns a value of 2.
13577 It is obligatory to support floating point `movM' instructions
13578 into and out of any registers that can hold fixed point values,
13579 because unions and structures (which have modes `SImode' or
13580 `DImode') can be in those registers and they may have floating
13583 There may also be a need to support fixed point `movM'
13584 instructions in and out of floating point registers.
13585 Unfortunately, I have forgotten why this was so, and I don't know
13586 whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed
13587 point values in floating point registers, then the constraints of
13588 the fixed point `movM' instructions must be designed to avoid ever
13589 trying to reload into a floating point register.
13593 Like `movM', but used when a scratch register is required to move
13594 between operand 0 and operand 1. Operand 2 describes the scratch
13595 register. See the discussion of the `SECONDARY_RELOAD_CLASS'
13596 macro in *note Register Classes::.
13598 There are special restrictions on the form of the `match_operand's
13599 used in these patterns. First, only the predicate for the reload
13600 operand is examined, i.e., `reload_in' examines operand 1, but not
13601 the predicates for operand 0 or 2. Second, there may be only one
13602 alternative in the constraints. Third, only a single register
13603 class letter may be used for the constraint; subsequent constraint
13604 letters are ignored. As a special exception, an empty constraint
13605 string matches the `ALL_REGS' register class. This may relieve
13606 ports of the burden of defining an `ALL_REGS' constraint letter
13607 just for these patterns.
13610 Like `movM' except that if operand 0 is a `subreg' with mode M of
13611 a register whose natural mode is wider, the `movstrictM'
13612 instruction is guaranteed not to alter any of the register except
13613 the part which belongs to mode M.
13616 This variant of a move pattern is designed to load or store a value
13617 from a memory address that is not naturally aligned for its mode.
13618 For a store, the memory will be in operand 0; for a load, the
13619 memory will be in operand 1. The other operand is guaranteed not
13620 to be a memory, so that it's easy to tell whether this is a load
13623 This pattern is used by the autovectorizer, and when expanding a
13624 `MISALIGNED_INDIRECT_REF' expression.
13627 Load several consecutive memory locations into consecutive
13628 registers. Operand 0 is the first of the consecutive registers,
13629 operand 1 is the first memory location, and operand 2 is a
13630 constant: the number of consecutive registers.
13632 Define this only if the target machine really has such an
13633 instruction; do not define this if the most efficient way of
13634 loading consecutive registers from memory is to do them one at a
13637 On some machines, there are restrictions as to which consecutive
13638 registers can be stored into memory, such as particular starting or
13639 ending register numbers or only a range of valid counts. For those
13640 machines, use a `define_expand' (*note Expander Definitions::) and
13641 make the pattern fail if the restrictions are not met.
13643 Write the generated insn as a `parallel' with elements being a
13644 `set' of one register from the appropriate memory location (you may
13645 also need `use' or `clobber' elements). Use a `match_parallel'
13646 (*note RTL Template::) to recognize the insn. See `rs6000.md' for
13647 examples of the use of this insn pattern.
13650 Similar to `load_multiple', but store several consecutive registers
13651 into consecutive memory locations. Operand 0 is the first of the
13652 consecutive memory locations, operand 1 is the first register, and
13653 operand 2 is a constant: the number of consecutive registers.
13656 Set given field in the vector value. Operand 0 is the vector to
13657 modify, operand 1 is new value of field and operand 2 specify the
13661 Extract given field from the vector value. Operand 1 is the
13662 vector, operand 2 specify field index and operand 0 place to store
13666 Initialize the vector to given values. Operand 0 is the vector to
13667 initialize and operand 1 is parallel containing values for
13671 Output a push instruction. Operand 0 is value to push. Used only
13672 when `PUSH_ROUNDING' is defined. For historical reason, this
13673 pattern may be missing and in such case an `mov' expander is used
13674 instead, with a `MEM' expression forming the push operation. The
13675 `mov' expander method is deprecated.
13678 Add operand 2 and operand 1, storing the result in operand 0. All
13679 operands must have mode M. This can be used even on two-address
13680 machines, by means of constraints requiring operands 1 and 0 to be
13687 `andM3', `iorM3', `xorM3'
13688 Similar, for other arithmetic operations.
13691 Signed minimum and maximum operations. When used with floating
13692 point, if both operands are zeros, or if either operand is `NaN',
13693 then it is unspecified which of the two operands is returned as
13696 `reduc_smin_M', `reduc_smax_M'
13697 Find the signed minimum/maximum of the elements of a vector. The
13698 vector is operand 1, and the scalar result is stored in the least
13699 significant bits of operand 0 (also a vector). The output and
13700 input vector should have the same modes.
13702 `reduc_umin_M', `reduc_umax_M'
13703 Find the unsigned minimum/maximum of the elements of a vector. The
13704 vector is operand 1, and the scalar result is stored in the least
13705 significant bits of operand 0 (also a vector). The output and
13706 input vector should have the same modes.
13709 Compute the sum of the signed elements of a vector. The vector is
13710 operand 1, and the scalar result is stored in the least
13711 significant bits of operand 0 (also a vector). The output and
13712 input vector should have the same modes.
13715 Compute the sum of the unsigned elements of a vector. The vector
13716 is operand 1, and the scalar result is stored in the least
13717 significant bits of operand 0 (also a vector). The output and
13718 input vector should have the same modes.
13720 `vec_shl_M', `vec_shr_M'
13721 Whole vector left/right shift in bits. Operand 1 is a vector to
13722 be shifted. Operand 2 is an integer shift amount in bits.
13723 Operand 0 is where the resulting shifted vector is stored. The
13724 output and input vectors should have the same modes.
13727 Multiply operands 1 and 2, which have mode `HImode', and store a
13728 `SImode' product in operand 0.
13730 `mulqihi3', `mulsidi3'
13731 Similar widening-multiplication instructions of other widths.
13733 `umulqihi3', `umulhisi3', `umulsidi3'
13734 Similar widening-multiplication instructions that do unsigned
13738 Perform a signed multiplication of operands 1 and 2, which have
13739 mode M, and store the most significant half of the product in
13740 operand 0. The least significant half of the product is discarded.
13743 Similar, but the multiplication is unsigned.
13746 Signed division that produces both a quotient and a remainder.
13747 Operand 1 is divided by operand 2 to produce a quotient stored in
13748 operand 0 and a remainder stored in operand 3.
13750 For machines with an instruction that produces both a quotient and
13751 a remainder, provide a pattern for `divmodM4' but do not provide
13752 patterns for `divM3' and `modM3'. This allows optimization in the
13753 relatively common case when both the quotient and remainder are
13756 If an instruction that just produces a quotient or just a remainder
13757 exists and is more efficient than the instruction that produces
13758 both, write the output routine of `divmodM4' to call
13759 `find_reg_note' and look for a `REG_UNUSED' note on the quotient
13760 or remainder and generate the appropriate instruction.
13763 Similar, but does unsigned division.
13766 Arithmetic-shift operand 1 left by a number of bits specified by
13767 operand 2, and store the result in operand 0. Here M is the mode
13768 of operand 0 and operand 1; operand 2's mode is specified by the
13769 instruction pattern, and the compiler will convert the operand to
13770 that mode before generating the instruction. The meaning of
13771 out-of-range shift counts can optionally be specified by
13772 `TARGET_SHIFT_TRUNCATION_MASK'. *Note
13773 TARGET_SHIFT_TRUNCATION_MASK::.
13775 `ashrM3', `lshrM3', `rotlM3', `rotrM3'
13776 Other shift and rotate instructions, analogous to the `ashlM3'
13780 Negate operand 1 and store the result in operand 0.
13783 Store the absolute value of operand 1 into operand 0.
13786 Store the square root of operand 1 into operand 0.
13788 The `sqrt' built-in function of C always uses the mode which
13789 corresponds to the C data type `double' and the `sqrtf' built-in
13790 function uses the mode which corresponds to the C data type
13794 Store the cosine of operand 1 into operand 0.
13796 The `cos' built-in function of C always uses the mode which
13797 corresponds to the C data type `double' and the `cosf' built-in
13798 function uses the mode which corresponds to the C data type
13802 Store the sine of operand 1 into operand 0.
13804 The `sin' built-in function of C always uses the mode which
13805 corresponds to the C data type `double' and the `sinf' built-in
13806 function uses the mode which corresponds to the C data type
13810 Store the exponential of operand 1 into operand 0.
13812 The `exp' built-in function of C always uses the mode which
13813 corresponds to the C data type `double' and the `expf' built-in
13814 function uses the mode which corresponds to the C data type
13818 Store the natural logarithm of operand 1 into operand 0.
13820 The `log' built-in function of C always uses the mode which
13821 corresponds to the C data type `double' and the `logf' built-in
13822 function uses the mode which corresponds to the C data type
13826 Store the value of operand 1 raised to the exponent operand 2 into
13829 The `pow' built-in function of C always uses the mode which
13830 corresponds to the C data type `double' and the `powf' built-in
13831 function uses the mode which corresponds to the C data type
13835 Store the arc tangent (inverse tangent) of operand 1 divided by
13836 operand 2 into operand 0, using the signs of both arguments to
13837 determine the quadrant of the result.
13839 The `atan2' built-in function of C always uses the mode which
13840 corresponds to the C data type `double' and the `atan2f' built-in
13841 function uses the mode which corresponds to the C data type
13845 Store the largest integral value not greater than argument.
13847 The `floor' built-in function of C always uses the mode which
13848 corresponds to the C data type `double' and the `floorf' built-in
13849 function uses the mode which corresponds to the C data type
13853 Store the argument rounded to integer towards zero.
13855 The `trunc' built-in function of C always uses the mode which
13856 corresponds to the C data type `double' and the `truncf' built-in
13857 function uses the mode which corresponds to the C data type
13861 Store the argument rounded to integer away from zero.
13863 The `round' built-in function of C always uses the mode which
13864 corresponds to the C data type `double' and the `roundf' built-in
13865 function uses the mode which corresponds to the C data type
13869 Store the argument rounded to integer away from zero.
13871 The `ceil' built-in function of C always uses the mode which
13872 corresponds to the C data type `double' and the `ceilf' built-in
13873 function uses the mode which corresponds to the C data type
13877 Store the argument rounded according to the default rounding mode
13879 The `nearbyint' built-in function of C always uses the mode which
13880 corresponds to the C data type `double' and the `nearbyintf'
13881 built-in function uses the mode which corresponds to the C data
13885 Store the argument rounded according to the default rounding mode
13886 and raise the inexact exception when the result differs in value
13889 The `rint' built-in function of C always uses the mode which
13890 corresponds to the C data type `double' and the `rintf' built-in
13891 function uses the mode which corresponds to the C data type
13895 Store a value with the magnitude of operand 1 and the sign of
13896 operand 2 into operand 0.
13898 The `copysign' built-in function of C always uses the mode which
13899 corresponds to the C data type `double' and the `copysignf'
13900 built-in function uses the mode which corresponds to the C data
13904 Store into operand 0 one plus the index of the least significant
13905 1-bit of operand 1. If operand 1 is zero, store zero. M is the
13906 mode of operand 0; operand 1's mode is specified by the instruction
13907 pattern, and the compiler will convert the operand to that mode
13908 before generating the instruction.
13910 The `ffs' built-in function of C always uses the mode which
13911 corresponds to the C data type `int'.
13914 Store into operand 0 the number of leading 0-bits in X, starting
13915 at the most significant bit position. If X is 0, the result is
13916 undefined. M is the mode of operand 0; operand 1's mode is
13917 specified by the instruction pattern, and the compiler will
13918 convert the operand to that mode before generating the instruction.
13921 Store into operand 0 the number of trailing 0-bits in X, starting
13922 at the least significant bit position. If X is 0, the result is
13923 undefined. M is the mode of operand 0; operand 1's mode is
13924 specified by the instruction pattern, and the compiler will
13925 convert the operand to that mode before generating the instruction.
13928 Store into operand 0 the number of 1-bits in X. M is the mode of
13929 operand 0; operand 1's mode is specified by the instruction
13930 pattern, and the compiler will convert the operand to that mode
13931 before generating the instruction.
13934 Store into operand 0 the parity of X, i.e. the number of 1-bits in
13935 X modulo 2. M is the mode of operand 0; operand 1's mode is
13936 specified by the instruction pattern, and the compiler will convert
13937 the operand to that mode before generating the instruction.
13940 Store the bitwise-complement of operand 1 into operand 0.
13943 Compare operand 0 and operand 1, and set the condition codes. The
13944 RTL pattern should look like this:
13946 (set (cc0) (compare (match_operand:M 0 ...)
13947 (match_operand:M 1 ...)))
13950 Compare operand 0 against zero, and set the condition codes. The
13951 RTL pattern should look like this:
13953 (set (cc0) (match_operand:M 0 ...))
13955 `tstM' patterns should not be defined for machines that do not use
13956 `(cc0)'. Doing so would confuse the optimizer since it would no
13957 longer be clear which `set' operations were comparisons. The
13958 `cmpM' patterns should be used instead.
13961 Block move instruction. The destination and source blocks of
13962 memory are the first two operands, and both are `mem:BLK's with an
13963 address in mode `Pmode'.
13965 The number of bytes to move is the third operand, in mode M.
13966 Usually, you specify `word_mode' for M. However, if you can
13967 generate better code knowing the range of valid lengths is smaller
13968 than those representable in a full word, you should provide a
13969 pattern with a mode corresponding to the range of values you can
13970 handle efficiently (e.g., `QImode' for values in the range 0-127;
13971 note we avoid numbers that appear negative) and also a pattern
13974 The fourth operand is the known shared alignment of the source and
13975 destination, in the form of a `const_int' rtx. Thus, if the
13976 compiler knows that both source and destination are word-aligned,
13977 it may provide the value 4 for this operand.
13979 Descriptions of multiple `movmemM' patterns can only be beneficial
13980 if the patterns for smaller modes have fewer restrictions on their
13981 first, second and fourth operands. Note that the mode M in
13982 `movmemM' does not impose any restriction on the mode of
13983 individually moved data units in the block.
13985 These patterns need not give special consideration to the
13986 possibility that the source and destination strings might overlap.
13989 String copy instruction, with `stpcpy' semantics. Operand 0 is an
13990 output operand in mode `Pmode'. The addresses of the destination
13991 and source strings are operands 1 and 2, and both are `mem:BLK's
13992 with addresses in mode `Pmode'. The execution of the expansion of
13993 this pattern should store in operand 0 the address in which the
13994 `NUL' terminator was stored in the destination string.
13997 Block set instruction. The destination string is the first
13998 operand, given as a `mem:BLK' whose address is in mode `Pmode'.
13999 The number of bytes to set is the second operand, in mode M. The
14000 value to initialize the memory with is the third operand. Targets
14001 that only support the clearing of memory should reject any value
14002 that is not the constant 0. See `movmemM' for a discussion of the
14005 The fourth operand is the known alignment of the destination, in
14006 the form of a `const_int' rtx. Thus, if the compiler knows that
14007 the destination is word-aligned, it may provide the value 4 for
14010 The use for multiple `setmemM' is as for `movmemM'.
14013 String compare instruction, with five operands. Operand 0 is the
14014 output; it has mode M. The remaining four operands are like the
14015 operands of `movmemM'. The two memory blocks specified are
14016 compared byte by byte in lexicographic order starting at the
14017 beginning of each string. The instruction is not allowed to
14018 prefetch more than one byte at a time since either string may end
14019 in the first byte and reading past that may access an invalid page
14020 or segment and cause a fault. The effect of the instruction is to
14021 store a value in operand 0 whose sign indicates the result of the
14025 String compare instruction, without known maximum length. Operand
14026 0 is the output; it has mode M. The second and third operand are
14027 the blocks of memory to be compared; both are `mem:BLK' with an
14028 address in mode `Pmode'.
14030 The fourth operand is the known shared alignment of the source and
14031 destination, in the form of a `const_int' rtx. Thus, if the
14032 compiler knows that both source and destination are word-aligned,
14033 it may provide the value 4 for this operand.
14035 The two memory blocks specified are compared byte by byte in
14036 lexicographic order starting at the beginning of each string. The
14037 instruction is not allowed to prefetch more than one byte at a
14038 time since either string may end in the first byte and reading
14039 past that may access an invalid page or segment and cause a fault.
14040 The effect of the instruction is to store a value in operand 0
14041 whose sign indicates the result of the comparison.
14044 Block compare instruction, with five operands like the operands of
14045 `cmpstrM'. The two memory blocks specified are compared byte by
14046 byte in lexicographic order starting at the beginning of each
14047 block. Unlike `cmpstrM' the instruction can prefetch any bytes in
14048 the two memory blocks. The effect of the instruction is to store
14049 a value in operand 0 whose sign indicates the result of the
14053 Compute the length of a string, with three operands. Operand 0 is
14054 the result (of mode M), operand 1 is a `mem' referring to the
14055 first character of the string, operand 2 is the character to
14056 search for (normally zero), and operand 3 is a constant describing
14057 the known alignment of the beginning of the string.
14060 Convert signed integer operand 1 (valid for fixed point mode M) to
14061 floating point mode N and store in operand 0 (which has mode N).
14064 Convert unsigned integer operand 1 (valid for fixed point mode M)
14065 to floating point mode N and store in operand 0 (which has mode N).
14068 Convert operand 1 (valid for floating point mode M) to fixed point
14069 mode N as a signed number and store in operand 0 (which has mode
14070 N). This instruction's result is defined only when the value of
14071 operand 1 is an integer.
14073 If the machine description defines this pattern, it also needs to
14074 define the `ftrunc' pattern.
14077 Convert operand 1 (valid for floating point mode M) to fixed point
14078 mode N as an unsigned number and store in operand 0 (which has
14079 mode N). This instruction's result is defined only when the value
14080 of operand 1 is an integer.
14083 Convert operand 1 (valid for floating point mode M) to an integer
14084 value, still represented in floating point mode M, and store it in
14085 operand 0 (valid for floating point mode M).
14088 Like `fixMN2' but works for any floating point value of mode M by
14089 converting the value to an integer.
14092 Like `fixunsMN2' but works for any floating point value of mode M
14093 by converting the value to an integer.
14096 Truncate operand 1 (valid for mode M) to mode N and store in
14097 operand 0 (which has mode N). Both modes must be fixed point or
14098 both floating point.
14101 Sign-extend operand 1 (valid for mode M) to mode N and store in
14102 operand 0 (which has mode N). Both modes must be fixed point or
14103 both floating point.
14106 Zero-extend operand 1 (valid for mode M) to mode N and store in
14107 operand 0 (which has mode N). Both modes must be fixed point.
14110 Extract a bit-field from operand 1 (a register or memory operand),
14111 where operand 2 specifies the width in bits and operand 3 the
14112 starting bit, and store it in operand 0. Operand 0 must have mode
14113 `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode';
14114 often `word_mode' is allowed only for registers. Operands 2 and 3
14115 must be valid for `word_mode'.
14117 The RTL generation pass generates this instruction only with
14118 constants for operands 2 and 3 and the constant is never zero for
14121 The bit-field value is sign-extended to a full word integer before
14122 it is stored in operand 0.
14125 Like `extv' except that the bit-field value is zero-extended.
14128 Store operand 3 (which must be valid for `word_mode') into a
14129 bit-field in operand 0, where operand 1 specifies the width in
14130 bits and operand 2 the starting bit. Operand 0 may have mode
14131 `byte_mode' or `word_mode'; often `word_mode' is allowed only for
14132 registers. Operands 1 and 2 must be valid for `word_mode'.
14134 The RTL generation pass generates this instruction only with
14135 constants for operands 1 and 2 and the constant is never zero for
14139 Conditionally move operand 2 or operand 3 into operand 0 according
14140 to the comparison in operand 1. If the comparison is true,
14141 operand 2 is moved into operand 0, otherwise operand 3 is moved.
14143 The mode of the operands being compared need not be the same as
14144 the operands being moved. Some machines, sparc64 for example,
14145 have instructions that conditionally move an integer value based
14146 on the floating point condition codes and vice versa.
14148 If the machine does not have conditional move instructions, do not
14149 define these patterns.
14152 Similar to `movMODEcc' but for conditional addition. Conditionally
14153 move operand 2 or (operands 2 + operand 3) into operand 0
14154 according to the comparison in operand 1. If the comparison is
14155 true, operand 2 is moved into operand 0, otherwise (operand 2 +
14156 operand 3) is moved.
14159 Store zero or nonzero in the operand according to the condition
14160 codes. Value stored is nonzero iff the condition COND is true.
14161 COND is the name of a comparison operation expression code, such
14162 as `eq', `lt' or `leu'.
14164 You specify the mode that the operand must have when you write the
14165 `match_operand' expression. The compiler automatically sees which
14166 mode you have used and supplies an operand of that mode.
14168 The value stored for a true condition must have 1 as its low bit,
14169 or else must be negative. Otherwise the instruction is not
14170 suitable and you should omit it from the machine description. You
14171 describe to the compiler exactly which value is stored by defining
14172 the macro `STORE_FLAG_VALUE' (*note Misc::). If a description
14173 cannot be found that can be used for all the `sCOND' patterns, you
14174 should omit those operations from the machine description.
14176 These operations may fail, but should do so only in relatively
14177 uncommon cases; if they would fail for common cases involving
14178 integer comparisons, it is best to omit these patterns.
14180 If these operations are omitted, the compiler will usually
14181 generate code that copies the constant one to the target and
14182 branches around an assignment of zero to the target. If this code
14183 is more efficient than the potential instructions used for the
14184 `sCOND' pattern followed by those required to convert the result
14185 into a 1 or a zero in `SImode', you should omit the `sCOND'
14186 operations from the machine description.
14189 Conditional branch instruction. Operand 0 is a `label_ref' that
14190 refers to the label to jump to. Jump if the condition codes meet
14193 Some machines do not follow the model assumed here where a
14194 comparison instruction is followed by a conditional branch
14195 instruction. In that case, the `cmpM' (and `tstM') patterns should
14196 simply store the operands away and generate all the required insns
14197 in a `define_expand' (*note Expander Definitions::) for the
14198 conditional branch operations. All calls to expand `bCOND'
14199 patterns are immediately preceded by calls to expand either a
14200 `cmpM' pattern or a `tstM' pattern.
14202 Machines that use a pseudo register for the condition code value,
14203 or where the mode used for the comparison depends on the condition
14204 being tested, should also use the above mechanism. *Note Jump
14207 The above discussion also applies to the `movMODEcc' and `sCOND'
14211 Conditional branch instruction combined with a compare instruction.
14212 Operand 0 is a comparison operator. Operand 1 and operand 2 are
14213 the first and second operands of the comparison, respectively.
14214 Operand 3 is a `label_ref' that refers to the label to jump to.
14217 A jump inside a function; an unconditional branch. Operand 0 is
14218 the `label_ref' of the label to jump to. This pattern name is
14219 mandatory on all machines.
14222 Subroutine call instruction returning no value. Operand 0 is the
14223 function to call; operand 1 is the number of bytes of arguments
14224 pushed as a `const_int'; operand 2 is the number of registers used
14227 On most machines, operand 2 is not actually stored into the RTL
14228 pattern. It is supplied for the sake of some RISC machines which
14229 need to put this information into the assembler code; they can put
14230 it in the RTL instead of operand 1.
14232 Operand 0 should be a `mem' RTX whose address is the address of the
14233 function. Note, however, that this address can be a `symbol_ref'
14234 expression even if it would not be a legitimate memory address on
14235 the target machine. If it is also not a valid argument for a call
14236 instruction, the pattern for this operation should be a
14237 `define_expand' (*note Expander Definitions::) that places the
14238 address into a register and uses that register in the call
14242 Subroutine call instruction returning a value. Operand 0 is the
14243 hard register in which the value is returned. There are three more
14244 operands, the same as the three operands of the `call' instruction
14245 (but with numbers increased by one).
14247 Subroutines that return `BLKmode' objects use the `call' insn.
14249 `call_pop', `call_value_pop'
14250 Similar to `call' and `call_value', except used if defined and if
14251 `RETURN_POPS_ARGS' is nonzero. They should emit a `parallel' that
14252 contains both the function call and a `set' to indicate the
14253 adjustment made to the frame pointer.
14255 For machines where `RETURN_POPS_ARGS' can be nonzero, the use of
14256 these patterns increases the number of functions for which the
14257 frame pointer can be eliminated, if desired.
14260 Subroutine call instruction returning a value of any type.
14261 Operand 0 is the function to call; operand 1 is a memory location
14262 where the result of calling the function is to be stored; operand
14263 2 is a `parallel' expression where each element is a `set'
14264 expression that indicates the saving of a function return value
14265 into the result block.
14267 This instruction pattern should be defined to support
14268 `__builtin_apply' on machines where special instructions are needed
14269 to call a subroutine with arbitrary arguments or to save the value
14270 returned. This instruction pattern is required on machines that
14271 have multiple registers that can hold a return value (i.e.
14272 `FUNCTION_VALUE_REGNO_P' is true for more than one register).
14275 Subroutine return instruction. This instruction pattern name
14276 should be defined only if a single instruction can do all the work
14277 of returning from a function.
14279 Like the `movM' patterns, this pattern is also used after the RTL
14280 generation phase. In this case it is to support machines where
14281 multiple instructions are usually needed to return from a
14282 function, but some class of functions only requires one
14283 instruction to implement a return. Normally, the applicable
14284 functions are those which do not need to save any registers or
14285 allocate stack space.
14287 For such machines, the condition specified in this pattern should
14288 only be true when `reload_completed' is nonzero and the function's
14289 epilogue would only be a single instruction. For machines with
14290 register windows, the routine `leaf_function_p' may be used to
14291 determine if a register window push is required.
14293 Machines that have conditional return instructions should define
14298 (if_then_else (match_operator
14299 0 "comparison_operator"
14300 [(cc0) (const_int 0)])
14306 where CONDITION would normally be the same condition specified on
14307 the named `return' pattern.
14310 Untyped subroutine return instruction. This instruction pattern
14311 should be defined to support `__builtin_return' on machines where
14312 special instructions are needed to return a value of any type.
14314 Operand 0 is a memory location where the result of calling a
14315 function with `__builtin_apply' is stored; operand 1 is a
14316 `parallel' expression where each element is a `set' expression
14317 that indicates the restoring of a function return value from the
14321 No-op instruction. This instruction pattern name should always be
14322 defined to output a no-op in assembler code. `(const_int 0)' will
14323 do as an RTL pattern.
14326 An instruction to jump to an address which is operand zero. This
14327 pattern name is mandatory on all machines.
14330 Instruction to jump through a dispatch table, including bounds
14331 checking. This instruction takes five operands:
14333 1. The index to dispatch on, which has mode `SImode'.
14335 2. The lower bound for indices in the table, an integer constant.
14337 3. The total range of indices in the table--the largest index
14338 minus the smallest one (both inclusive).
14340 4. A label that precedes the table itself.
14342 5. A label to jump to if the index has a value outside the
14345 The table is a `addr_vec' or `addr_diff_vec' inside of a
14346 `jump_insn'. The number of elements in the table is one plus the
14347 difference between the upper bound and the lower bound.
14350 Instruction to jump to a variable address. This is a low-level
14351 capability which can be used to implement a dispatch table when
14352 there is no `casesi' pattern.
14354 This pattern requires two operands: the address or offset, and a
14355 label which should immediately precede the jump table. If the
14356 macro `CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then
14357 the first operand is an offset which counts from the address of
14358 the table; otherwise, it is an absolute address to jump to. In
14359 either case, the first operand has mode `Pmode'.
14361 The `tablejump' insn is always the last insn before the jump table
14362 it uses. Its assembler code normally has no need to use the
14363 second operand, but you should incorporate it in the RTL pattern so
14364 that the jump optimizer will not delete the table as unreachable
14367 `decrement_and_branch_until_zero'
14368 Conditional branch instruction that decrements a register and
14369 jumps if the register is nonzero. Operand 0 is the register to
14370 decrement and test; operand 1 is the label to jump to if the
14371 register is nonzero. *Note Looping Patterns::.
14373 This optional instruction pattern is only used by the combiner,
14374 typically for loops reversed by the loop optimizer when strength
14375 reduction is enabled.
14378 Conditional branch instruction that decrements a register and
14379 jumps if the register is nonzero. This instruction takes five
14380 operands: Operand 0 is the register to decrement and test; operand
14381 1 is the number of loop iterations as a `const_int' or
14382 `const0_rtx' if this cannot be determined until run-time; operand
14383 2 is the actual or estimated maximum number of iterations as a
14384 `const_int'; operand 3 is the number of enclosed loops as a
14385 `const_int' (an innermost loop has a value of 1); operand 4 is the
14386 label to jump to if the register is nonzero. *Note Looping
14389 This optional instruction pattern should be defined for machines
14390 with low-overhead looping instructions as the loop optimizer will
14391 try to modify suitable loops to utilize it. If nested
14392 low-overhead looping is not supported, use a `define_expand'
14393 (*note Expander Definitions::) and make the pattern fail if
14394 operand 3 is not `const1_rtx'. Similarly, if the actual or
14395 estimated maximum number of iterations is too large for this
14396 instruction, make it fail.
14399 Companion instruction to `doloop_end' required for machines that
14400 need to perform some initialization, such as loading special
14401 registers used by a low-overhead looping instruction. If
14402 initialization insns do not always need to be emitted, use a
14403 `define_expand' (*note Expander Definitions::) and make it fail.
14405 `canonicalize_funcptr_for_compare'
14406 Canonicalize the function pointer in operand 1 and store the result
14409 Operand 0 is always a `reg' and has mode `Pmode'; operand 1 may be
14410 a `reg', `mem', `symbol_ref', `const_int', etc and also has mode
14413 Canonicalization of a function pointer usually involves computing
14414 the address of the function which would be called if the function
14415 pointer were used in an indirect call.
14417 Only define this pattern if function pointers on the target machine
14418 can have different values but still call the same function when
14419 used in an indirect call.
14422 `save_stack_function'
14423 `save_stack_nonlocal'
14424 `restore_stack_block'
14425 `restore_stack_function'
14426 `restore_stack_nonlocal'
14427 Most machines save and restore the stack pointer by copying it to
14428 or from an object of mode `Pmode'. Do not define these patterns on
14431 Some machines require special handling for stack pointer saves and
14432 restores. On those machines, define the patterns corresponding to
14433 the non-standard cases by using a `define_expand' (*note Expander
14434 Definitions::) that produces the required insns. The three types
14435 of saves and restores are:
14437 1. `save_stack_block' saves the stack pointer at the start of a
14438 block that allocates a variable-sized object, and
14439 `restore_stack_block' restores the stack pointer when the
14442 2. `save_stack_function' and `restore_stack_function' do a
14443 similar job for the outermost block of a function and are
14444 used when the function allocates variable-sized objects or
14445 calls `alloca'. Only the epilogue uses the restored stack
14446 pointer, allowing a simpler save or restore sequence on some
14449 3. `save_stack_nonlocal' is used in functions that contain labels
14450 branched to by nested functions. It saves the stack pointer
14451 in such a way that the inner function can use
14452 `restore_stack_nonlocal' to restore the stack pointer. The
14453 compiler generates code to restore the frame and argument
14454 pointer registers, but some machines require saving and
14455 restoring additional data such as register window information
14456 or stack backchains. Place insns in these patterns to save
14457 and restore any such required data.
14459 When saving the stack pointer, operand 0 is the save area and
14460 operand 1 is the stack pointer. The mode used to allocate the
14461 save area defaults to `Pmode' but you can override that choice by
14462 defining the `STACK_SAVEAREA_MODE' macro (*note Storage Layout::).
14463 You must specify an integral mode, or `VOIDmode' if no save area
14464 is needed for a particular type of save (either because no save is
14465 needed or because a machine-specific save area can be used).
14466 Operand 0 is the stack pointer and operand 1 is the save area for
14467 restore operations. If `save_stack_block' is defined, operand 0
14468 must not be `VOIDmode' since these saves can be arbitrarily nested.
14470 A save area is a `mem' that is at a constant offset from
14471 `virtual_stack_vars_rtx' when the stack pointer is saved for use by
14472 nonlocal gotos and a `reg' in the other two cases.
14475 Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 1
14476 from the stack pointer to create space for dynamically allocated
14479 Store the resultant pointer to this space into operand 0. If you
14480 are allocating space from the main stack, do this by emitting a
14481 move insn to copy `virtual_stack_dynamic_rtx' to operand 0. If
14482 you are allocating the space elsewhere, generate code to copy the
14483 location of the space to operand 0. In the latter case, you must
14484 ensure this space gets freed when the corresponding space on the
14485 main stack is free.
14487 Do not define this pattern if all that must be done is the
14488 subtraction. Some machines require other operations such as stack
14489 probes or maintaining the back chain. Define this pattern to emit
14490 those operations in addition to updating the stack pointer.
14493 If stack checking cannot be done on your system by probing the
14494 stack with a load or store instruction (*note Stack Checking::),
14495 define this pattern to perform the needed check and signaling an
14496 error if the stack has overflowed. The single operand is the
14497 location in the stack furthest from the current stack pointer that
14498 you need to validate. Normally, on machines where this pattern is
14499 needed, you would obtain the stack limit from a global or
14500 thread-specific variable or register.
14503 Emit code to generate a non-local goto, e.g., a jump from one
14504 function to a label in an outer function. This pattern has four
14505 arguments, each representing a value to be used in the jump. The
14506 first argument is to be loaded into the frame pointer, the second
14507 is the address to branch to (code to dispatch to the actual label),
14508 the third is the address of a location where the stack is saved,
14509 and the last is the address of the label, to be placed in the
14510 location for the incoming static chain.
14512 On most machines you need not define this pattern, since GCC will
14513 already generate the correct code, which is to load the frame
14514 pointer and static chain, restore the stack (using the
14515 `restore_stack_nonlocal' pattern, if defined), and jump indirectly
14516 to the dispatcher. You need only define this pattern if this code
14517 will not work on your machine.
14519 `nonlocal_goto_receiver'
14520 This pattern, if defined, contains code needed at the target of a
14521 nonlocal goto after the code already generated by GCC. You will
14522 not normally need to define this pattern. A typical reason why
14523 you might need this pattern is if some value, such as a pointer to
14524 a global table, must be restored when the frame pointer is
14525 restored. Note that a nonlocal goto only occurs within a
14526 unit-of-translation, so a global table pointer that is shared by
14527 all functions of a given module need not be restored. There are
14530 `exception_receiver'
14531 This pattern, if defined, contains code needed at the site of an
14532 exception handler that isn't needed at the site of a nonlocal
14533 goto. You will not normally need to define this pattern. A
14534 typical reason why you might need this pattern is if some value,
14535 such as a pointer to a global table, must be restored after
14536 control flow is branched to the handler of an exception. There
14539 `builtin_setjmp_setup'
14540 This pattern, if defined, contains additional code needed to
14541 initialize the `jmp_buf'. You will not normally need to define
14542 this pattern. A typical reason why you might need this pattern is
14543 if some value, such as a pointer to a global table, must be
14544 restored. Though it is preferred that the pointer value be
14545 recalculated if possible (given the address of a label for
14546 instance). The single argument is a pointer to the `jmp_buf'.
14547 Note that the buffer is five words long and that the first three
14548 are normally used by the generic mechanism.
14550 `builtin_setjmp_receiver'
14551 This pattern, if defined, contains code needed at the site of an
14552 built-in setjmp that isn't needed at the site of a nonlocal goto.
14553 You will not normally need to define this pattern. A typical
14554 reason why you might need this pattern is if some value, such as a
14555 pointer to a global table, must be restored. It takes one
14556 argument, which is the label to which builtin_longjmp transfered
14557 control; this pattern may be emitted at a small offset from that
14561 This pattern, if defined, performs the entire action of the
14562 longjmp. You will not normally need to define this pattern unless
14563 you also define `builtin_setjmp_setup'. The single argument is a
14564 pointer to the `jmp_buf'.
14567 This pattern, if defined, affects the way `__builtin_eh_return',
14568 and thence the call frame exception handling library routines, are
14569 built. It is intended to handle non-trivial actions needed along
14570 the abnormal return path.
14572 The address of the exception handler to which the function should
14573 return is passed as operand to this pattern. It will normally
14574 need to copied by the pattern to some special register or memory
14575 location. If the pattern needs to determine the location of the
14576 target call frame in order to do so, it may use
14577 `EH_RETURN_STACKADJ_RTX', if defined; it will have already been
14580 If this pattern is not defined, the default action will be to
14581 simply copy the return address to `EH_RETURN_HANDLER_RTX'. Either
14582 that macro or this pattern needs to be defined if call frame
14583 exception handling is to be used.
14586 This pattern, if defined, emits RTL for entry to a function. The
14587 function entry is responsible for setting up the stack frame,
14588 initializing the frame pointer register, saving callee saved
14591 Using a prologue pattern is generally preferred over defining
14592 `TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the
14595 The `prologue' pattern is particularly useful for targets which
14596 perform instruction scheduling.
14599 This pattern emits RTL for exit from a function. The function
14600 exit is responsible for deallocating the stack frame, restoring
14601 callee saved registers and emitting the return instruction.
14603 Using an epilogue pattern is generally preferred over defining
14604 `TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the
14607 The `epilogue' pattern is particularly useful for targets which
14608 perform instruction scheduling or which have delay slots for their
14609 return instruction.
14612 This pattern, if defined, emits RTL for exit from a function
14613 without the final branch back to the calling function. This
14614 pattern will be emitted before any sibling call (aka tail call)
14617 The `sibcall_epilogue' pattern must not clobber any arguments used
14618 for parameter passing or any stack slots for arguments passed to
14619 the current function.
14622 This pattern, if defined, signals an error, typically by causing
14623 some kind of signal to be raised. Among other places, it is used
14624 by the Java front end to signal `invalid array index' exceptions.
14627 Conditional trap instruction. Operand 0 is a piece of RTL which
14628 performs a comparison. Operand 1 is the trap code, an integer.
14630 A typical `conditional_trap' pattern looks like
14632 (define_insn "conditional_trap"
14633 [(trap_if (match_operator 0 "trap_operator"
14634 [(cc0) (const_int 0)])
14635 (match_operand 1 "const_int_operand" "i"))]
14640 This pattern, if defined, emits code for a non-faulting data
14641 prefetch instruction. Operand 0 is the address of the memory to
14642 prefetch. Operand 1 is a constant 1 if the prefetch is preparing
14643 for a write to the memory address, or a constant 0 otherwise.
14644 Operand 2 is the expected degree of temporal locality of the data
14645 and is a value between 0 and 3, inclusive; 0 means that the data
14646 has no temporal locality, so it need not be left in the cache
14647 after the access; 3 means that the data has a high degree of
14648 temporal locality and should be left in all levels of cache
14649 possible; 1 and 2 mean, respectively, a low or moderate degree of
14652 Targets that do not support write prefetches or locality hints can
14653 ignore the values of operands 1 and 2.
14656 If the target memory model is not fully synchronous, then this
14657 pattern should be defined to an instruction that orders both loads
14658 and stores before the instruction with respect to loads and stores
14659 after the instruction. This pattern has no operands.
14661 `sync_compare_and_swapMODE'
14662 This pattern, if defined, emits code for an atomic compare-and-swap
14663 operation. Operand 1 is the memory on which the atomic operation
14664 is performed. Operand 2 is the "old" value to be compared against
14665 the current contents of the memory location. Operand 3 is the
14666 "new" value to store in the memory if the compare succeeds.
14667 Operand 0 is the result of the operation; it should contain the
14668 contents of the memory before the operation. If the compare
14669 succeeds, this should obviously be a copy of operand 2.
14671 This pattern must show that both operand 0 and operand 1 are
14674 This pattern must issue any memory barrier instructions such that
14675 all memory operations before the atomic operation occur before the
14676 atomic operation and all memory operations after the atomic
14677 operation occur after the atomic operation.
14679 `sync_compare_and_swap_ccMODE'
14680 This pattern is just like `sync_compare_and_swapMODE', except it
14681 should act as if compare part of the compare-and-swap were issued
14682 via `cmpM'. This comparison will only be used with `EQ' and `NE'
14683 branches and `setcc' operations.
14685 Some targets do expose the success or failure of the
14686 compare-and-swap operation via the status flags. Ideally we
14687 wouldn't need a separate named pattern in order to take advantage
14688 of this, but the combine pass does not handle patterns with
14689 multiple sets, which is required by definition for
14690 `sync_compare_and_swapMODE'.
14692 `sync_addMODE', `sync_subMODE'
14693 `sync_iorMODE', `sync_andMODE'
14694 `sync_xorMODE', `sync_nandMODE'
14695 These patterns emit code for an atomic operation on memory.
14696 Operand 0 is the memory on which the atomic operation is performed.
14697 Operand 1 is the second operand to the binary operator.
14699 The "nand" operation is `~op0 & op1'.
14701 This pattern must issue any memory barrier instructions such that
14702 all memory operations before the atomic operation occur before the
14703 atomic operation and all memory operations after the atomic
14704 operation occur after the atomic operation.
14706 If these patterns are not defined, the operation will be
14707 constructed from a compare-and-swap operation, if defined.
14709 `sync_old_addMODE', `sync_old_subMODE'
14710 `sync_old_iorMODE', `sync_old_andMODE'
14711 `sync_old_xorMODE', `sync_old_nandMODE'
14712 These patterns are emit code for an atomic operation on memory,
14713 and return the value that the memory contained before the
14714 operation. Operand 0 is the result value, operand 1 is the memory
14715 on which the atomic operation is performed, and operand 2 is the
14716 second operand to the binary operator.
14718 This pattern must issue any memory barrier instructions such that
14719 all memory operations before the atomic operation occur before the
14720 atomic operation and all memory operations after the atomic
14721 operation occur after the atomic operation.
14723 If these patterns are not defined, the operation will be
14724 constructed from a compare-and-swap operation, if defined.
14726 `sync_new_addMODE', `sync_new_subMODE'
14727 `sync_new_iorMODE', `sync_new_andMODE'
14728 `sync_new_xorMODE', `sync_new_nandMODE'
14729 These patterns are like their `sync_old_OP' counterparts, except
14730 that they return the value that exists in the memory location
14731 after the operation, rather than before the operation.
14733 `sync_lock_test_and_setMODE'
14734 This pattern takes two forms, based on the capabilities of the
14735 target. In either case, operand 0 is the result of the operand,
14736 operand 1 is the memory on which the atomic operation is
14737 performed, and operand 2 is the value to set in the lock.
14739 In the ideal case, this operation is an atomic exchange operation,
14740 in which the previous value in memory operand is copied into the
14741 result operand, and the value operand is stored in the memory
14744 For less capable targets, any value operand that is not the
14745 constant 1 should be rejected with `FAIL'. In this case the
14746 target may use an atomic test-and-set bit operation. The result
14747 operand should contain 1 if the bit was previously set and 0 if
14748 the bit was previously clear. The true contents of the memory
14749 operand are implementation defined.
14751 This pattern must issue any memory barrier instructions such that
14752 the pattern as a whole acts as an acquire barrier, that is all
14753 memory operations after the pattern do not occur until the lock is
14756 If this pattern is not defined, the operation will be constructed
14757 from a compare-and-swap operation, if defined.
14759 `sync_lock_releaseMODE'
14760 This pattern, if defined, releases a lock set by
14761 `sync_lock_test_and_setMODE'. Operand 0 is the memory that
14762 contains the lock; operand 1 is the value to store in the lock.
14764 If the target doesn't implement full semantics for
14765 `sync_lock_test_and_setMODE', any value operand which is not the
14766 constant 0 should be rejected with `FAIL', and the true contents
14767 of the memory operand are implementation defined.
14769 This pattern must issue any memory barrier instructions such that
14770 the pattern as a whole acts as a release barrier, that is the lock
14771 is released only after all previous memory operations have
14774 If this pattern is not defined, then a `memory_barrier' pattern
14775 will be emitted, followed by a store of the value to the memory
14778 `stack_protect_set'
14779 This pattern, if defined, moves a `Pmode' value from the memory in
14780 operand 1 to the memory in operand 0 without leaving the value in
14781 a register afterward. This is to avoid leaking the value some
14782 place that an attacker might use to rewrite the stack guard slot
14783 after having clobbered it.
14785 If this pattern is not defined, then a plain move pattern is
14788 `stack_protect_test'
14789 This pattern, if defined, compares a `Pmode' value from the memory
14790 in operand 1 with the memory in operand 0 without leaving the
14791 value in a register afterward and branches to operand 2 if the
14792 values weren't equal.
14794 If this pattern is not defined, then a plain compare pattern and
14795 conditional branch pattern is used.
14799 File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc
14801 13.10 When the Order of Patterns Matters
14802 ========================================
14804 Sometimes an insn can match more than one instruction pattern. Then the
14805 pattern that appears first in the machine description is the one used.
14806 Therefore, more specific patterns (patterns that will match fewer
14807 things) and faster instructions (those that will produce better code
14808 when they do match) should usually go first in the description.
14810 In some cases the effect of ordering the patterns can be used to hide
14811 a pattern when it is not valid. For example, the 68000 has an
14812 instruction for converting a fullword to floating point and another for
14813 converting a byte to floating point. An instruction converting an
14814 integer to floating point could match either one. We put the pattern
14815 to convert the fullword first to make sure that one will be used rather
14816 than the other. (Otherwise a large integer might be generated as a
14817 single-byte immediate quantity, which would not work.) Instead of
14818 using this pattern ordering it would be possible to make the pattern
14819 for convert-a-byte smart enough to deal properly with any constant
14823 File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc
14825 13.11 Interdependence of Patterns
14826 =================================
14828 Every machine description must have a named pattern for each of the
14829 conditional branch names `bCOND'. The recognition template must always
14833 (if_then_else (COND (cc0) (const_int 0))
14834 (label_ref (match_operand 0 "" ""))
14837 In addition, every machine description must have an anonymous pattern
14838 for each of the possible reverse-conditional branches. Their templates
14842 (if_then_else (COND (cc0) (const_int 0))
14844 (label_ref (match_operand 0 "" ""))))
14846 They are necessary because jump optimization can turn direct-conditional
14847 branches into reverse-conditional branches.
14849 It is often convenient to use the `match_operator' construct to reduce
14850 the number of patterns that must be specified for branches. For
14855 (if_then_else (match_operator 0 "comparison_operator"
14856 [(cc0) (const_int 0)])
14858 (label_ref (match_operand 1 "" ""))))]
14862 In some cases machines support instructions identical except for the
14863 machine mode of one or more operands. For example, there may be
14864 "sign-extend halfword" and "sign-extend byte" instructions whose
14867 (set (match_operand:SI 0 ...)
14868 (extend:SI (match_operand:HI 1 ...)))
14870 (set (match_operand:SI 0 ...)
14871 (extend:SI (match_operand:QI 1 ...)))
14873 Constant integers do not specify a machine mode, so an instruction to
14874 extend a constant value could match either pattern. The pattern it
14875 actually will match is the one that appears first in the file. For
14876 correct results, this must be the one for the widest possible mode
14877 (`HImode', here). If the pattern matches the `QImode' instruction, the
14878 results will be incorrect if the constant value does not actually fit
14881 Such instructions to extend constants are rarely generated because
14882 they are optimized away, but they do occasionally happen in nonoptimized
14885 If a constraint in a pattern allows a constant, the reload pass may
14886 replace a register with a constant permitted by the constraint in some
14887 cases. Similarly for memory references. Because of this substitution,
14888 you should not provide separate patterns for increment and decrement
14889 instructions. Instead, they should be generated from the same pattern
14890 that supports register-register add insns by examining the operands and
14891 generating the appropriate machine instruction.
14894 File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc
14896 13.12 Defining Jump Instruction Patterns
14897 ========================================
14899 For most machines, GCC assumes that the machine has a condition code.
14900 A comparison insn sets the condition code, recording the results of both
14901 signed and unsigned comparison of the given operands. A separate branch
14902 insn tests the condition code and branches or not according its value.
14903 The branch insns come in distinct signed and unsigned flavors. Many
14904 common machines, such as the VAX, the 68000 and the 32000, work this
14907 Some machines have distinct signed and unsigned compare instructions,
14908 and only one set of conditional branch instructions. The easiest way
14909 to handle these machines is to treat them just like the others until
14910 the final stage where assembly code is written. At this time, when
14911 outputting code for the compare instruction, peek ahead at the
14912 following branch using `next_cc0_user (insn)'. (The variable `insn'
14913 refers to the insn being output, in the output-writing code in an
14914 instruction pattern.) If the RTL says that is an unsigned branch,
14915 output an unsigned compare; otherwise output a signed compare. When
14916 the branch itself is output, you can treat signed and unsigned branches
14919 The reason you can do this is that GCC always generates a pair of
14920 consecutive RTL insns, possibly separated by `note' insns, one to set
14921 the condition code and one to test it, and keeps the pair inviolate
14924 To go with this technique, you must define the machine-description
14925 macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no
14926 compare instruction is superfluous.
14928 Some machines have compare-and-branch instructions and no condition
14929 code. A similar technique works for them. When it is time to "output"
14930 a compare instruction, record its operands in two static variables.
14931 When outputting the branch-on-condition-code instruction that follows,
14932 actually output a compare-and-branch instruction that uses the
14933 remembered operands.
14935 It also works to define patterns for compare-and-branch instructions.
14936 In optimizing compilation, the pair of compare and branch instructions
14937 will be combined according to these patterns. But this does not happen
14938 if optimization is not requested. So you must use one of the solutions
14939 above in addition to any special patterns you define.
14941 In many RISC machines, most instructions do not affect the condition
14942 code and there may not even be a separate condition code register. On
14943 these machines, the restriction that the definition and use of the
14944 condition code be adjacent insns is not necessary and can prevent
14945 important optimizations. For example, on the IBM RS/6000, there is a
14946 delay for taken branches unless the condition code register is set three
14947 instructions earlier than the conditional branch. The instruction
14948 scheduler cannot perform this optimization if it is not permitted to
14949 separate the definition and use of the condition code register.
14951 On these machines, do not use `(cc0)', but instead use a register to
14952 represent the condition code. If there is a specific condition code
14953 register in the machine, use a hard register. If the condition code or
14954 comparison result can be placed in any general register, or if there are
14955 multiple condition registers, use a pseudo register.
14957 On some machines, the type of branch instruction generated may depend
14958 on the way the condition code was produced; for example, on the 68k and
14959 SPARC, setting the condition code directly from an add or subtract
14960 instruction does not clear the overflow bit the way that a test
14961 instruction does, so a different branch instruction must be used for
14962 some conditional branches. For machines that use `(cc0)', the set and
14963 use of the condition code must be adjacent (separated only by `note'
14964 insns) allowing flags in `cc_status' to be used. (*Note Condition
14965 Code::.) Also, the comparison and branch insns can be located from
14966 each other by using the functions `prev_cc0_setter' and `next_cc0_user'.
14968 However, this is not true on machines that do not use `(cc0)'. On
14969 those machines, no assumptions can be made about the adjacency of the
14970 compare and branch insns and the above methods cannot be used. Instead,
14971 we use the machine mode of the condition code register to record
14972 different formats of the condition code register.
14974 Registers used to store the condition code value should have a mode
14975 that is in class `MODE_CC'. Normally, it will be `CCmode'. If
14976 additional modes are required (as for the add example mentioned above in
14977 the SPARC), define them in `MACHINE-modes.def' (*note Condition
14978 Code::). Also define `SELECT_CC_MODE' to choose a mode given an
14979 operand of a compare.
14981 If it is known during RTL generation that a different mode will be
14982 required (for example, if the machine has separate compare instructions
14983 for signed and unsigned quantities, like most IBM processors), they can
14984 be specified at that time.
14986 If the cases that require different modes would be made by instruction
14987 combination, the macro `SELECT_CC_MODE' determines which machine mode
14988 should be used for the comparison result. The patterns should be
14989 written using that mode. To support the case of the add on the SPARC
14990 discussed above, we have the pattern
14993 [(set (reg:CC_NOOV 0)
14995 (plus:SI (match_operand:SI 0 "register_operand" "%r")
14996 (match_operand:SI 1 "arith_operand" "rI"))
15001 The `SELECT_CC_MODE' macro on the SPARC returns `CC_NOOVmode' for
15002 comparisons whose argument is a `plus'.
15005 File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc
15007 13.13 Defining Looping Instruction Patterns
15008 ===========================================
15010 Some machines have special jump instructions that can be utilized to
15011 make loops more efficient. A common example is the 68000 `dbra'
15012 instruction which performs a decrement of a register and a branch if the
15013 result was greater than zero. Other machines, in particular digital
15014 signal processors (DSPs), have special block repeat instructions to
15015 provide low-overhead loop support. For example, the TI TMS320C3x/C4x
15016 DSPs have a block repeat instruction that loads special registers to
15017 mark the top and end of a loop and to count the number of loop
15018 iterations. This avoids the need for fetching and executing a
15019 `dbra'-like instruction and avoids pipeline stalls associated with the
15022 GCC has three special named patterns to support low overhead looping.
15023 They are `decrement_and_branch_until_zero', `doloop_begin', and
15024 `doloop_end'. The first pattern, `decrement_and_branch_until_zero', is
15025 not emitted during RTL generation but may be emitted during the
15026 instruction combination phase. This requires the assistance of the
15027 loop optimizer, using information collected during strength reduction,
15028 to reverse a loop to count down to zero. Some targets also require the
15029 loop optimizer to add a `REG_NONNEG' note to indicate that the
15030 iteration count is always positive. This is needed if the target
15031 performs a signed loop termination test. For example, the 68000 uses a
15032 pattern similar to the following for its `dbra' instruction:
15034 (define_insn "decrement_and_branch_until_zero"
15037 (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am")
15040 (label_ref (match_operand 1 "" ""))
15043 (plus:SI (match_dup 0)
15045 "find_reg_note (insn, REG_NONNEG, 0)"
15048 Note that since the insn is both a jump insn and has an output, it must
15049 deal with its own reloads, hence the `m' constraints. Also note that
15050 since this insn is generated by the instruction combination phase
15051 combining two sequential insns together into an implicit parallel insn,
15052 the iteration counter needs to be biased by the same amount as the
15053 decrement operation, in this case -1. Note that the following similar
15054 pattern will not be matched by the combiner.
15056 (define_insn "decrement_and_branch_until_zero"
15059 (ge (match_operand:SI 0 "general_operand" "+d*am")
15061 (label_ref (match_operand 1 "" ""))
15064 (plus:SI (match_dup 0)
15066 "find_reg_note (insn, REG_NONNEG, 0)"
15069 The other two special looping patterns, `doloop_begin' and
15070 `doloop_end', are emitted by the loop optimizer for certain
15071 well-behaved loops with a finite number of loop iterations using
15072 information collected during strength reduction.
15074 The `doloop_end' pattern describes the actual looping instruction (or
15075 the implicit looping operation) and the `doloop_begin' pattern is an
15076 optional companion pattern that can be used for initialization needed
15077 for some low-overhead looping instructions.
15079 Note that some machines require the actual looping instruction to be
15080 emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting
15081 the true RTL for a looping instruction at the top of the loop can cause
15082 problems with flow analysis. So instead, a dummy `doloop' insn is
15083 emitted at the end of the loop. The machine dependent reorg pass checks
15084 for the presence of this `doloop' insn and then searches back to the
15085 top of the loop, where it inserts the true looping insn (provided there
15086 are no instructions in the loop which would cause problems). Any
15087 additional labels can be emitted at this point. In addition, if the
15088 desired special iteration counter register was not allocated, this
15089 machine dependent reorg pass could emit a traditional compare and jump
15092 The essential difference between the `decrement_and_branch_until_zero'
15093 and the `doloop_end' patterns is that the loop optimizer allocates an
15094 additional pseudo register for the latter as an iteration counter.
15095 This pseudo register cannot be used within the loop (i.e., general
15096 induction variables cannot be derived from it), however, in many cases
15097 the loop induction variable may become redundant and removed by the
15101 File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc
15103 13.14 Canonicalization of Instructions
15104 ======================================
15106 There are often cases where multiple RTL expressions could represent an
15107 operation performed by a single machine instruction. This situation is
15108 most commonly encountered with logical, branch, and multiply-accumulate
15109 instructions. In such cases, the compiler attempts to convert these
15110 multiple RTL expressions into a single canonical form to reduce the
15111 number of insn patterns required.
15113 In addition to algebraic simplifications, following canonicalizations
15116 * For commutative and comparison operators, a constant is always
15117 made the second operand. If a machine only supports a constant as
15118 the second operand, only patterns that match a constant in the
15119 second operand need be supplied.
15121 * For associative operators, a sequence of operators will always
15122 chain to the left; for instance, only the left operand of an
15123 integer `plus' can itself be a `plus'. `and', `ior', `xor',
15124 `plus', `mult', `smin', `smax', `umin', and `umax' are associative
15125 when applied to integers, and sometimes to floating-point.
15127 * For these operators, if only one operand is a `neg', `not',
15128 `mult', `plus', or `minus' expression, it will be the first
15131 * In combinations of `neg', `mult', `plus', and `minus', the `neg'
15132 operations (if any) will be moved inside the operations as far as
15133 possible. For instance, `(neg (mult A B))' is canonicalized as
15134 `(mult (neg A) B)', but `(plus (mult (neg A) B) C)' is
15135 canonicalized as `(minus A (mult B C))'.
15137 * For the `compare' operator, a constant is always the second operand
15138 on machines where `cc0' is used (*note Jump Patterns::). On other
15139 machines, there are rare cases where the compiler might want to
15140 construct a `compare' with a constant as the first operand.
15141 However, these cases are not common enough for it to be worthwhile
15142 to provide a pattern matching a constant as the first operand
15143 unless the machine actually has such an instruction.
15145 An operand of `neg', `not', `mult', `plus', or `minus' is made the
15146 first operand under the same conditions as above.
15148 * `(minus X (const_int N))' is converted to `(plus X (const_int
15151 * Within address computations (i.e., inside `mem'), a left shift is
15152 converted into the appropriate multiplication by a power of two.
15154 * De Morgan's Law is used to move bitwise negation inside a bitwise
15155 logical-and or logical-or operation. If this results in only one
15156 operand being a `not' expression, it will be the first one.
15158 A machine that has an instruction that performs a bitwise
15159 logical-and of one operand with the bitwise negation of the other
15160 should specify the pattern for that instruction as
15163 [(set (match_operand:M 0 ...)
15164 (and:M (not:M (match_operand:M 1 ...))
15165 (match_operand:M 2 ...)))]
15169 Similarly, a pattern for a "NAND" instruction should be written
15172 [(set (match_operand:M 0 ...)
15173 (ior:M (not:M (match_operand:M 1 ...))
15174 (not:M (match_operand:M 2 ...))))]
15178 In both cases, it is not necessary to include patterns for the many
15179 logically equivalent RTL expressions.
15181 * The only possible RTL expressions involving both bitwise
15182 exclusive-or and bitwise negation are `(xor:M X Y)' and `(not:M
15185 * The sum of three items, one of which is a constant, will only
15188 (plus:M (plus:M X Y) CONSTANT)
15190 * On machines that do not use `cc0', `(compare X (const_int 0))'
15191 will be converted to X.
15193 * Equality comparisons of a group of bits (usually a single bit)
15194 with zero will be written using `zero_extract' rather than the
15195 equivalent `and' or `sign_extract' operations.
15199 File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc
15201 13.15 Defining RTL Sequences for Code Generation
15202 ================================================
15204 On some target machines, some standard pattern names for RTL generation
15205 cannot be handled with single insn, but a sequence of RTL insns can
15206 represent them. For these target machines, you can write a
15207 `define_expand' to specify how to generate the sequence of RTL.
15209 A `define_expand' is an RTL expression that looks almost like a
15210 `define_insn'; but, unlike the latter, a `define_expand' is used only
15211 for RTL generation and it can produce more than one RTL insn.
15213 A `define_expand' RTX has four operands:
15215 * The name. Each `define_expand' must have a name, since the only
15216 use for it is to refer to it by name.
15218 * The RTL template. This is a vector of RTL expressions representing
15219 a sequence of separate instructions. Unlike `define_insn', there
15220 is no implicit surrounding `PARALLEL'.
15222 * The condition, a string containing a C expression. This
15223 expression is used to express how the availability of this pattern
15224 depends on subclasses of target machine, selected by command-line
15225 options when GCC is run. This is just like the condition of a
15226 `define_insn' that has a standard name. Therefore, the condition
15227 (if present) may not depend on the data in the insn being matched,
15228 but only the target-machine-type flags. The compiler needs to
15229 test these conditions during initialization in order to learn
15230 exactly which named instructions are available in a particular run.
15232 * The preparation statements, a string containing zero or more C
15233 statements which are to be executed before RTL code is generated
15234 from the RTL template.
15236 Usually these statements prepare temporary registers for use as
15237 internal operands in the RTL template, but they can also generate
15238 RTL insns directly by calling routines such as `emit_insn', etc.
15239 Any such insns precede the ones that come from the RTL template.
15241 Every RTL insn emitted by a `define_expand' must match some
15242 `define_insn' in the machine description. Otherwise, the compiler will
15243 crash when trying to generate code for the insn or trying to optimize
15246 The RTL template, in addition to controlling generation of RTL insns,
15247 also describes the operands that need to be specified when this pattern
15248 is used. In particular, it gives a predicate for each operand.
15250 A true operand, which needs to be specified in order to generate RTL
15251 from the pattern, should be described with a `match_operand' in its
15252 first occurrence in the RTL template. This enters information on the
15253 operand's predicate into the tables that record such things. GCC uses
15254 the information to preload the operand into a register if that is
15255 required for valid RTL code. If the operand is referred to more than
15256 once, subsequent references should use `match_dup'.
15258 The RTL template may also refer to internal "operands" which are
15259 temporary registers or labels used only within the sequence made by the
15260 `define_expand'. Internal operands are substituted into the RTL
15261 template with `match_dup', never with `match_operand'. The values of
15262 the internal operands are not passed in as arguments by the compiler
15263 when it requests use of this pattern. Instead, they are computed
15264 within the pattern, in the preparation statements. These statements
15265 compute the values and store them into the appropriate elements of
15266 `operands' so that `match_dup' can find them.
15268 There are two special macros defined for use in the preparation
15269 statements: `DONE' and `FAIL'. Use them with a following semicolon, as
15273 Use the `DONE' macro to end RTL generation for the pattern. The
15274 only RTL insns resulting from the pattern on this occasion will be
15275 those already emitted by explicit calls to `emit_insn' within the
15276 preparation statements; the RTL template will not be generated.
15279 Make the pattern fail on this occasion. When a pattern fails, it
15280 means that the pattern was not truly available. The calling
15281 routines in the compiler will try other strategies for code
15282 generation using other patterns.
15284 Failure is currently supported only for binary (addition,
15285 multiplication, shifting, etc.) and bit-field (`extv', `extzv',
15286 and `insv') operations.
15288 If the preparation falls through (invokes neither `DONE' nor `FAIL'),
15289 then the `define_expand' acts like a `define_insn' in that the RTL
15290 template is used to generate the insn.
15292 The RTL template is not used for matching, only for generating the
15293 initial insn list. If the preparation statement always invokes `DONE'
15294 or `FAIL', the RTL template may be reduced to a simple list of
15295 operands, such as this example:
15297 (define_expand "addsi3"
15298 [(match_operand:SI 0 "register_operand" "")
15299 (match_operand:SI 1 "register_operand" "")
15300 (match_operand:SI 2 "register_operand" "")]
15304 handle_add (operands[0], operands[1], operands[2]);
15308 Here is an example, the definition of left-shift for the SPUR chip:
15310 (define_expand "ashlsi3"
15311 [(set (match_operand:SI 0 "register_operand" "")
15313 (match_operand:SI 1 "register_operand" "")
15314 (match_operand:SI 2 "nonmemory_operand" "")))]
15319 if (GET_CODE (operands[2]) != CONST_INT
15320 || (unsigned) INTVAL (operands[2]) > 3)
15324 This example uses `define_expand' so that it can generate an RTL insn
15325 for shifting when the shift-count is in the supported range of 0 to 3
15326 but fail in other cases where machine insns aren't available. When it
15327 fails, the compiler tries another strategy using different patterns
15328 (such as, a library call).
15330 If the compiler were able to handle nontrivial condition-strings in
15331 patterns with names, then it would be possible to use a `define_insn'
15332 in that case. Here is another case (zero-extension on the 68000) which
15333 makes more use of the power of `define_expand':
15335 (define_expand "zero_extendhisi2"
15336 [(set (match_operand:SI 0 "general_operand" "")
15338 (set (strict_low_part
15342 (match_operand:HI 1 "general_operand" ""))]
15344 "operands[1] = make_safe_from (operands[1], operands[0]);")
15346 Here two RTL insns are generated, one to clear the entire output operand
15347 and the other to copy the input operand into its low half. This
15348 sequence is incorrect if the input operand refers to [the old value of]
15349 the output operand, so the preparation statement makes sure this isn't
15350 so. The function `make_safe_from' copies the `operands[1]' into a
15351 temporary register if it refers to `operands[0]'. It does this by
15352 emitting another RTL insn.
15354 Finally, a third example shows the use of an internal operand.
15355 Zero-extension on the SPUR chip is done by `and'-ing the result against
15356 a halfword mask. But this mask cannot be represented by a `const_int'
15357 because the constant value is too large to be legitimate on this
15358 machine. So it must be copied into a register with `force_reg' and
15359 then the register used in the `and'.
15361 (define_expand "zero_extendhisi2"
15362 [(set (match_operand:SI 0 "register_operand" "")
15364 (match_operand:HI 1 "register_operand" "")
15369 = force_reg (SImode, GEN_INT (65535)); ")
15371 _Note:_ If the `define_expand' is used to serve a standard binary or
15372 unary arithmetic operation or a bit-field operation, then the last insn
15373 it generates must not be a `code_label', `barrier' or `note'. It must
15374 be an `insn', `jump_insn' or `call_insn'. If you don't need a real insn
15375 at the end, emit an insn to copy the result of the operation into
15376 itself. Such an insn will generate no code, but it can avoid problems
15380 File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc
15382 13.16 Defining How to Split Instructions
15383 ========================================
15385 There are two cases where you should specify how to split a pattern
15386 into multiple insns. On machines that have instructions requiring
15387 delay slots (*note Delay Slots::) or that have instructions whose
15388 output is not available for multiple cycles (*note Processor pipeline
15389 description::), the compiler phases that optimize these cases need to
15390 be able to move insns into one-instruction delay slots. However, some
15391 insns may generate more than one machine instruction. These insns
15392 cannot be placed into a delay slot.
15394 Often you can rewrite the single insn as a list of individual insns,
15395 each corresponding to one machine instruction. The disadvantage of
15396 doing so is that it will cause the compilation to be slower and require
15397 more space. If the resulting insns are too complex, it may also
15398 suppress some optimizations. The compiler splits the insn if there is a
15399 reason to believe that it might improve instruction or delay slot
15402 The insn combiner phase also splits putative insns. If three insns are
15403 merged into one insn with a complex expression that cannot be matched by
15404 some `define_insn' pattern, the combiner phase attempts to split the
15405 complex pattern into two insns that are recognized. Usually it can
15406 break the complex pattern into two patterns by splitting out some
15407 subexpression. However, in some other cases, such as performing an
15408 addition of a large constant in two insns on a RISC machine, the way to
15409 split the addition into two insns is machine-dependent.
15411 The `define_split' definition tells the compiler how to split a
15412 complex insn into several simpler insns. It looks like this:
15417 [NEW-INSN-PATTERN-1
15420 "PREPARATION-STATEMENTS")
15422 INSN-PATTERN is a pattern that needs to be split and CONDITION is the
15423 final condition to be tested, as in a `define_insn'. When an insn
15424 matching INSN-PATTERN and satisfying CONDITION is found, it is replaced
15425 in the insn list with the insns given by NEW-INSN-PATTERN-1,
15426 NEW-INSN-PATTERN-2, etc.
15428 The PREPARATION-STATEMENTS are similar to those statements that are
15429 specified for `define_expand' (*note Expander Definitions::) and are
15430 executed before the new RTL is generated to prepare for the generated
15431 code or emit some insns whose pattern is not fixed. Unlike those in
15432 `define_expand', however, these statements must not generate any new
15433 pseudo-registers. Once reload has completed, they also must not
15434 allocate any space in the stack frame.
15436 Patterns are matched against INSN-PATTERN in two different
15437 circumstances. If an insn needs to be split for delay slot scheduling
15438 or insn scheduling, the insn is already known to be valid, which means
15439 that it must have been matched by some `define_insn' and, if
15440 `reload_completed' is nonzero, is known to satisfy the constraints of
15441 that `define_insn'. In that case, the new insn patterns must also be
15442 insns that are matched by some `define_insn' and, if `reload_completed'
15443 is nonzero, must also satisfy the constraints of those definitions.
15445 As an example of this usage of `define_split', consider the following
15446 example from `a29k.md', which splits a `sign_extend' from `HImode' to
15447 `SImode' into a pair of shift insns:
15450 [(set (match_operand:SI 0 "gen_reg_operand" "")
15451 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))]
15453 [(set (match_dup 0)
15454 (ashift:SI (match_dup 1)
15457 (ashiftrt:SI (match_dup 0)
15460 { operands[1] = gen_lowpart (SImode, operands[1]); }")
15462 When the combiner phase tries to split an insn pattern, it is always
15463 the case that the pattern is _not_ matched by any `define_insn'. The
15464 combiner pass first tries to split a single `set' expression and then
15465 the same `set' expression inside a `parallel', but followed by a
15466 `clobber' of a pseudo-reg to use as a scratch register. In these
15467 cases, the combiner expects exactly two new insn patterns to be
15468 generated. It will verify that these patterns match some `define_insn'
15469 definitions, so you need not do this test in the `define_split' (of
15470 course, there is no point in writing a `define_split' that will never
15471 produce insns that match).
15473 Here is an example of this use of `define_split', taken from
15477 [(set (match_operand:SI 0 "gen_reg_operand" "")
15478 (plus:SI (match_operand:SI 1 "gen_reg_operand" "")
15479 (match_operand:SI 2 "non_add_cint_operand" "")))]
15481 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3)))
15482 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))]
15485 int low = INTVAL (operands[2]) & 0xffff;
15486 int high = (unsigned) INTVAL (operands[2]) >> 16;
15489 high++, low |= 0xffff0000;
15491 operands[3] = GEN_INT (high << 16);
15492 operands[4] = GEN_INT (low);
15495 Here the predicate `non_add_cint_operand' matches any `const_int' that
15496 is _not_ a valid operand of a single add insn. The add with the
15497 smaller displacement is written so that it can be substituted into the
15498 address of a subsequent operation.
15500 An example that uses a scratch register, from the same file, generates
15501 an equality comparison of a register and a large constant:
15504 [(set (match_operand:CC 0 "cc_reg_operand" "")
15505 (compare:CC (match_operand:SI 1 "gen_reg_operand" "")
15506 (match_operand:SI 2 "non_short_cint_operand" "")))
15507 (clobber (match_operand:SI 3 "gen_reg_operand" ""))]
15508 "find_single_use (operands[0], insn, 0)
15509 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ
15510 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)"
15511 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4)))
15512 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))]
15515 /* Get the constant we are comparing against, C, and see what it
15516 looks like sign-extended to 16 bits. Then see what constant
15517 could be XOR'ed with C to get the sign-extended value. */
15519 int c = INTVAL (operands[2]);
15520 int sextc = (c << 16) >> 16;
15521 int xorv = c ^ sextc;
15523 operands[4] = GEN_INT (xorv);
15524 operands[5] = GEN_INT (sextc);
15527 To avoid confusion, don't write a single `define_split' that accepts
15528 some insns that match some `define_insn' as well as some insns that
15529 don't. Instead, write two separate `define_split' definitions, one for
15530 the insns that are valid and one for the insns that are not valid.
15532 The splitter is allowed to split jump instructions into sequence of
15533 jumps or create new jumps in while splitting non-jump instructions. As
15534 the central flowgraph and branch prediction information needs to be
15535 updated, several restriction apply.
15537 Splitting of jump instruction into sequence that over by another jump
15538 instruction is always valid, as compiler expect identical behavior of
15539 new jump. When new sequence contains multiple jump instructions or new
15540 labels, more assistance is needed. Splitter is required to create only
15541 unconditional jumps, or simple conditional jump instructions.
15542 Additionally it must attach a `REG_BR_PROB' note to each conditional
15543 jump. A global variable `split_branch_probability' holds the
15544 probability of the original branch in case it was an simple conditional
15545 jump, -1 otherwise. To simplify recomputing of edge frequencies, the
15546 new sequence is required to have only forward jumps to the newly
15549 For the common case where the pattern of a define_split exactly
15550 matches the pattern of a define_insn, use `define_insn_and_split'. It
15553 (define_insn_and_split
15558 [NEW-INSN-PATTERN-1
15561 "PREPARATION-STATEMENTS"
15564 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used
15565 as in `define_insn'. The NEW-INSN-PATTERN vector and the
15566 PREPARATION-STATEMENTS are used as in a `define_split'. The
15567 SPLIT-CONDITION is also used as in `define_split', with the additional
15568 behavior that if the condition starts with `&&', the condition used for
15569 the split will be the constructed as a logical "and" of the split
15570 condition with the insn condition. For example, from i386.md:
15572 (define_insn_and_split "zero_extendhisi2_and"
15573 [(set (match_operand:SI 0 "register_operand" "=r")
15574 (zero_extend:SI (match_operand:HI 1 "register_operand" "0")))
15575 (clobber (reg:CC 17))]
15576 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size"
15578 "&& reload_completed"
15579 [(parallel [(set (match_dup 0)
15580 (and:SI (match_dup 0) (const_int 65535)))
15581 (clobber (reg:CC 17))])]
15583 [(set_attr "type" "alu1")])
15585 In this case, the actual split condition will be
15586 `TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'.
15588 The `define_insn_and_split' construction provides exactly the same
15589 functionality as two separate `define_insn' and `define_split'
15590 patterns. It exists for compactness, and as a maintenance tool to
15591 prevent having to ensure the two patterns' templates match.
15594 File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc
15596 13.17 Including Patterns in Machine Descriptions.
15597 =================================================
15599 The `include' pattern tells the compiler tools where to look for
15600 patterns that are in files other than in the file `.md'. This is used
15601 only at build time and there is no preprocessing allowed.
15612 (include "filestuff")
15614 Where PATHNAME is a string that specifies the location of the file,
15615 specifies the include file to be in `gcc/config/target/filestuff'. The
15616 directory `gcc/config/target' is regarded as the default directory.
15618 Machine descriptions may be split up into smaller more manageable
15619 subsections and placed into subdirectories.
15624 (include "BOGUS/filestuff")
15626 the include file is specified to be in
15627 `gcc/config/TARGET/BOGUS/filestuff'.
15629 Specifying an absolute path for the include file such as;
15631 (include "/u2/BOGUS/filestuff")
15632 is permitted but is not encouraged.
15634 13.17.1 RTL Generation Tool Options for Directory Search
15635 --------------------------------------------------------
15637 The `-IDIR' option specifies directories to search for machine
15638 descriptions. For example:
15641 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md
15643 Add the directory DIR to the head of the list of directories to be
15644 searched for header files. This can be used to override a system
15645 machine definition file, substituting your own version, since these
15646 directories are searched before the default machine description file
15647 directories. If you use more than one `-I' option, the directories are
15648 scanned in left-to-right order; the standard default directory come
15652 File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc
15654 13.18 Machine-Specific Peephole Optimizers
15655 ==========================================
15657 In addition to instruction patterns the `md' file may contain
15658 definitions of machine-specific peephole optimizations.
15660 The combiner does not notice certain peephole optimizations when the
15661 data flow in the program does not suggest that it should try them. For
15662 example, sometimes two consecutive insns related in purpose can be
15663 combined even though the second one does not appear to use a register
15664 computed in the first one. A machine-specific peephole optimizer can
15665 detect such opportunities.
15667 There are two forms of peephole definitions that may be used. The
15668 original `define_peephole' is run at assembly output time to match
15669 insns and substitute assembly text. Use of `define_peephole' is
15672 A newer `define_peephole2' matches insns and substitutes new insns.
15673 The `peephole2' pass is run after register allocation but before
15674 scheduling, which may result in much better code for targets that do
15679 * define_peephole:: RTL to Text Peephole Optimizers
15680 * define_peephole2:: RTL to RTL Peephole Optimizers
15683 File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions
15685 13.18.1 RTL to Text Peephole Optimizers
15686 ---------------------------------------
15688 A definition looks like this:
15696 "OPTIONAL-INSN-ATTRIBUTES")
15698 The last string operand may be omitted if you are not using any
15699 machine-specific information in this machine description. If present,
15700 it must obey the same rules as in a `define_insn'.
15702 In this skeleton, INSN-PATTERN-1 and so on are patterns to match
15703 consecutive insns. The optimization applies to a sequence of insns when
15704 INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next,
15707 Each of the insns matched by a peephole must also match a
15708 `define_insn'. Peepholes are checked only at the last stage just
15709 before code generation, and only optionally. Therefore, any insn which
15710 would match a peephole but no `define_insn' will cause a crash in code
15711 generation in an unoptimized compilation, or at various optimization
15714 The operands of the insns are matched with `match_operands',
15715 `match_operator', and `match_dup', as usual. What is not usual is that
15716 the operand numbers apply to all the insn patterns in the definition.
15717 So, you can check for identical operands in two insns by using
15718 `match_operand' in one insn and `match_dup' in the other.
15720 The operand constraints used in `match_operand' patterns do not have
15721 any direct effect on the applicability of the peephole, but they will
15722 be validated afterward, so make sure your constraints are general enough
15723 to apply whenever the peephole matches. If the peephole matches but
15724 the constraints are not satisfied, the compiler will crash.
15726 It is safe to omit constraints in all the operands of the peephole; or
15727 you can write constraints which serve as a double-check on the criteria
15730 Once a sequence of insns matches the patterns, the CONDITION is
15731 checked. This is a C expression which makes the final decision whether
15732 to perform the optimization (we do so if the expression is nonzero). If
15733 CONDITION is omitted (in other words, the string is empty) then the
15734 optimization is applied to every sequence of insns that matches the
15737 The defined peephole optimizations are applied after register
15738 allocation is complete. Therefore, the peephole definition can check
15739 which operands have ended up in which kinds of registers, just by
15740 looking at the operands.
15742 The way to refer to the operands in CONDITION is to write
15743 `operands[I]' for operand number I (as matched by `(match_operand I
15744 ...)'). Use the variable `insn' to refer to the last of the insns
15745 being matched; use `prev_active_insn' to find the preceding insns.
15747 When optimizing computations with intermediate results, you can use
15748 CONDITION to match only when the intermediate results are not used
15749 elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where INSN
15750 is the insn in which you expect the value to be used for the last time
15751 (from the value of `insn', together with use of `prev_nonnote_insn'),
15752 and OP is the intermediate value (from `operands[I]').
15754 Applying the optimization means replacing the sequence of insns with
15755 one new insn. The TEMPLATE controls ultimate output of assembler code
15756 for this combined insn. It works exactly like the template of a
15757 `define_insn'. Operand numbers in this template are the same ones used
15758 in matching the original sequence of insns.
15760 The result of a defined peephole optimizer does not need to match any
15761 of the insn patterns in the machine description; it does not even have
15762 an opportunity to match them. The peephole optimizer definition itself
15763 serves as the insn pattern to control how the insn is output.
15765 Defined peephole optimizers are run as assembler code is being output,
15766 so the insns they produce are never combined or rearranged in any way.
15768 Here is an example, taken from the 68000 machine description:
15771 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4)))
15772 (set (match_operand:DF 0 "register_operand" "=f")
15773 (match_operand:DF 1 "register_operand" "ad"))]
15774 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
15777 xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1);
15779 output_asm_insn ("move.l %1,(sp)", xoperands);
15780 output_asm_insn ("move.l %1,-(sp)", operands);
15781 return "fmove.d (sp)+,%0";
15783 output_asm_insn ("movel %1,sp@", xoperands);
15784 output_asm_insn ("movel %1,sp@-", operands);
15785 return "fmoved sp@+,%0";
15789 The effect of this optimization is to change
15804 INSN-PATTERN-1 and so on look _almost_ like the second operand of
15805 `define_insn'. There is one important difference: the second operand
15806 of `define_insn' consists of one or more RTX's enclosed in square
15807 brackets. Usually, there is only one: then the same action can be
15808 written as an element of a `define_peephole'. But when there are
15809 multiple actions in a `define_insn', they are implicitly enclosed in a
15810 `parallel'. Then you must explicitly write the `parallel', and the
15811 square brackets within it, in the `define_peephole'. Thus, if an insn
15812 pattern looks like this,
15814 (define_insn "divmodsi4"
15815 [(set (match_operand:SI 0 "general_operand" "=d")
15816 (div:SI (match_operand:SI 1 "general_operand" "0")
15817 (match_operand:SI 2 "general_operand" "dmsK")))
15818 (set (match_operand:SI 3 "general_operand" "=d")
15819 (mod:SI (match_dup 1) (match_dup 2)))]
15821 "divsl%.l %2,%3:%0")
15823 then the way to mention this insn in a peephole is as follows:
15828 [(set (match_operand:SI 0 "general_operand" "=d")
15829 (div:SI (match_operand:SI 1 "general_operand" "0")
15830 (match_operand:SI 2 "general_operand" "dmsK")))
15831 (set (match_operand:SI 3 "general_operand" "=d")
15832 (mod:SI (match_dup 1) (match_dup 2)))])
15837 File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions
15839 13.18.2 RTL to RTL Peephole Optimizers
15840 --------------------------------------
15842 The `define_peephole2' definition tells the compiler how to substitute
15843 one sequence of instructions for another sequence, what additional
15844 scratch registers may be needed and what their lifetimes must be.
15851 [NEW-INSN-PATTERN-1
15854 "PREPARATION-STATEMENTS")
15856 The definition is almost identical to `define_split' (*note Insn
15857 Splitting::) except that the pattern to match is not a single
15858 instruction, but a sequence of instructions.
15860 It is possible to request additional scratch registers for use in the
15861 output template. If appropriate registers are not free, the pattern
15862 will simply not match.
15864 Scratch registers are requested with a `match_scratch' pattern at the
15865 top level of the input pattern. The allocated register (initially) will
15866 be dead at the point requested within the original sequence. If the
15867 scratch is used at more than a single point, a `match_dup' pattern at
15868 the top level of the input pattern marks the last position in the input
15869 sequence at which the register must be available.
15871 Here is an example from the IA-32 machine description:
15874 [(match_scratch:SI 2 "r")
15875 (parallel [(set (match_operand:SI 0 "register_operand" "")
15876 (match_operator:SI 3 "arith_or_logical_operator"
15878 (match_operand:SI 1 "memory_operand" "")]))
15879 (clobber (reg:CC 17))])]
15880 "! optimize_size && ! TARGET_READ_MODIFY"
15881 [(set (match_dup 2) (match_dup 1))
15882 (parallel [(set (match_dup 0)
15883 (match_op_dup 3 [(match_dup 0) (match_dup 2)]))
15884 (clobber (reg:CC 17))])]
15887 This pattern tries to split a load from its use in the hopes that we'll
15888 be able to schedule around the memory load latency. It allocates a
15889 single `SImode' register of class `GENERAL_REGS' (`"r"') that needs to
15890 be live only at the point just before the arithmetic.
15892 A real example requiring extended scratch lifetimes is harder to come
15893 by, so here's a silly made-up example:
15896 [(match_scratch:SI 4 "r")
15897 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" ""))
15898 (set (match_operand:SI 2 "" "") (match_dup 1))
15900 (set (match_operand:SI 3 "" "") (match_dup 1))]
15901 "/* determine 1 does not overlap 0 and 2 */"
15902 [(set (match_dup 4) (match_dup 1))
15903 (set (match_dup 0) (match_dup 4))
15904 (set (match_dup 2) (match_dup 4))]
15905 (set (match_dup 3) (match_dup 4))]
15908 If we had not added the `(match_dup 4)' in the middle of the input
15909 sequence, it might have been the case that the register we chose at the
15910 beginning of the sequence is killed by the first or second `set'.
15913 File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc
15915 13.19 Instruction Attributes
15916 ============================
15918 In addition to describing the instruction supported by the target
15919 machine, the `md' file also defines a group of "attributes" and a set of
15920 values for each. Every generated insn is assigned a value for each
15921 attribute. One possible attribute would be the effect that the insn
15922 has on the machine's condition code. This attribute can then be used
15923 by `NOTICE_UPDATE_CC' to track the condition codes.
15927 * Defining Attributes:: Specifying attributes and their values.
15928 * Expressions:: Valid expressions for attribute values.
15929 * Tagging Insns:: Assigning attribute values to insns.
15930 * Attr Example:: An example of assigning attributes.
15931 * Insn Lengths:: Computing the length of insns.
15932 * Constant Attributes:: Defining attributes that are constant.
15933 * Delay Slots:: Defining delay slots required for a machine.
15934 * Processor pipeline description:: Specifying information for insn scheduling.
15937 File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes
15939 13.19.1 Defining Attributes and their Values
15940 --------------------------------------------
15942 The `define_attr' expression is used to define each attribute required
15943 by the target machine. It looks like:
15945 (define_attr NAME LIST-OF-VALUES DEFAULT)
15947 NAME is a string specifying the name of the attribute being defined.
15949 LIST-OF-VALUES is either a string that specifies a comma-separated
15950 list of values that can be assigned to the attribute, or a null string
15951 to indicate that the attribute takes numeric values.
15953 DEFAULT is an attribute expression that gives the value of this
15954 attribute for insns that match patterns whose definition does not
15955 include an explicit value for this attribute. *Note Attr Example::,
15956 for more information on the handling of defaults. *Note Constant
15957 Attributes::, for information on attributes that do not depend on any
15960 For each defined attribute, a number of definitions are written to the
15961 `insn-attr.h' file. For cases where an explicit set of values is
15962 specified for an attribute, the following are defined:
15964 * A `#define' is written for the symbol `HAVE_ATTR_NAME'.
15966 * An enumerated class is defined for `attr_NAME' with elements of
15967 the form `UPPER-NAME_UPPER-VALUE' where the attribute name and
15968 value are first converted to uppercase.
15970 * A function `get_attr_NAME' is defined that is passed an insn and
15971 returns the attribute value for that insn.
15973 For example, if the following is present in the `md' file:
15975 (define_attr "type" "branch,fp,load,store,arith" ...)
15977 the following lines will be written to the file `insn-attr.h'.
15979 #define HAVE_ATTR_type
15980 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD,
15981 TYPE_STORE, TYPE_ARITH};
15982 extern enum attr_type get_attr_type ();
15984 If the attribute takes numeric values, no `enum' type will be defined
15985 and the function to obtain the attribute's value will return `int'.
15988 File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes
15990 13.19.2 Attribute Expressions
15991 -----------------------------
15993 RTL expressions used to define attributes use the codes described above
15994 plus a few specific to attribute definitions, to be discussed below.
15995 Attribute value expressions must have one of the following forms:
15998 The integer I specifies the value of a numeric attribute. I must
16001 The value of a numeric attribute can be specified either with a
16002 `const_int', or as an integer represented as a string in
16003 `const_string', `eq_attr' (see below), `attr', `symbol_ref',
16004 simple arithmetic expressions, and `set_attr' overrides on
16005 specific instructions (*note Tagging Insns::).
16007 `(const_string VALUE)'
16008 The string VALUE specifies a constant attribute value. If VALUE
16009 is specified as `"*"', it means that the default value of the
16010 attribute is to be used for the insn containing this expression.
16011 `"*"' obviously cannot be used in the DEFAULT expression of a
16014 If the attribute whose value is being specified is numeric, VALUE
16015 must be a string containing a non-negative integer (normally
16016 `const_int' would be used in this case). Otherwise, it must
16017 contain one of the valid values for the attribute.
16019 `(if_then_else TEST TRUE-VALUE FALSE-VALUE)'
16020 TEST specifies an attribute test, whose format is defined below.
16021 The value of this expression is TRUE-VALUE if TEST is true,
16022 otherwise it is FALSE-VALUE.
16024 `(cond [TEST1 VALUE1 ...] DEFAULT)'
16025 The first operand of this expression is a vector containing an even
16026 number of expressions and consisting of pairs of TEST and VALUE
16027 expressions. The value of the `cond' expression is that of the
16028 VALUE corresponding to the first true TEST expression. If none of
16029 the TEST expressions are true, the value of the `cond' expression
16030 is that of the DEFAULT expression.
16032 TEST expressions can have one of the following forms:
16035 This test is true if I is nonzero and false otherwise.
16038 `(ior TEST1 TEST2)'
16039 `(and TEST1 TEST2)'
16040 These tests are true if the indicated logical function is true.
16042 `(match_operand:M N PRED CONSTRAINTS)'
16043 This test is true if operand N of the insn whose attribute value
16044 is being determined has mode M (this part of the test is ignored
16045 if M is `VOIDmode') and the function specified by the string PRED
16046 returns a nonzero value when passed operand N and mode M (this
16047 part of the test is ignored if PRED is the null string).
16049 The CONSTRAINTS operand is ignored and should be the null string.
16051 `(le ARITH1 ARITH2)'
16052 `(leu ARITH1 ARITH2)'
16053 `(lt ARITH1 ARITH2)'
16054 `(ltu ARITH1 ARITH2)'
16055 `(gt ARITH1 ARITH2)'
16056 `(gtu ARITH1 ARITH2)'
16057 `(ge ARITH1 ARITH2)'
16058 `(geu ARITH1 ARITH2)'
16059 `(ne ARITH1 ARITH2)'
16060 `(eq ARITH1 ARITH2)'
16061 These tests are true if the indicated comparison of the two
16062 arithmetic expressions is true. Arithmetic expressions are formed
16063 with `plus', `minus', `mult', `div', `mod', `abs', `neg', `and',
16064 `ior', `xor', `not', `ashift', `lshiftrt', and `ashiftrt'
16067 `const_int' and `symbol_ref' are always valid terms (*note Insn
16068 Lengths::,for additional forms). `symbol_ref' is a string
16069 denoting a C expression that yields an `int' when evaluated by the
16070 `get_attr_...' routine. It should normally be a global variable.
16072 `(eq_attr NAME VALUE)'
16073 NAME is a string specifying the name of an attribute.
16075 VALUE is a string that is either a valid value for attribute NAME,
16076 a comma-separated list of values, or `!' followed by a value or
16077 list. If VALUE does not begin with a `!', this test is true if
16078 the value of the NAME attribute of the current insn is in the list
16079 specified by VALUE. If VALUE begins with a `!', this test is true
16080 if the attribute's value is _not_ in the specified list.
16084 (eq_attr "type" "load,store")
16088 (ior (eq_attr "type" "load") (eq_attr "type" "store"))
16090 If NAME specifies an attribute of `alternative', it refers to the
16091 value of the compiler variable `which_alternative' (*note Output
16092 Statement::) and the values must be small integers. For example,
16094 (eq_attr "alternative" "2,3")
16098 (ior (eq (symbol_ref "which_alternative") (const_int 2))
16099 (eq (symbol_ref "which_alternative") (const_int 3)))
16101 Note that, for most attributes, an `eq_attr' test is simplified in
16102 cases where the value of the attribute being tested is known for
16103 all insns matching a particular pattern. This is by far the most
16107 The value of an `attr_flag' expression is true if the flag
16108 specified by NAME is true for the `insn' currently being scheduled.
16110 NAME is a string specifying one of a fixed set of flags to test.
16111 Test the flags `forward' and `backward' to determine the direction
16112 of a conditional branch. Test the flags `very_likely', `likely',
16113 `very_unlikely', and `unlikely' to determine if a conditional
16114 branch is expected to be taken.
16116 If the `very_likely' flag is true, then the `likely' flag is also
16117 true. Likewise for the `very_unlikely' and `unlikely' flags.
16119 This example describes a conditional branch delay slot which can
16120 be nullified for forward branches that are taken (annul-true) or
16121 for backward branches which are not taken (annul-false).
16123 (define_delay (eq_attr "type" "cbranch")
16124 [(eq_attr "in_branch_delay" "true")
16125 (and (eq_attr "in_branch_delay" "true")
16126 (attr_flag "forward"))
16127 (and (eq_attr "in_branch_delay" "true")
16128 (attr_flag "backward"))])
16130 The `forward' and `backward' flags are false if the current `insn'
16131 being scheduled is not a conditional branch.
16133 The `very_likely' and `likely' flags are true if the `insn' being
16134 scheduled is not a conditional branch. The `very_unlikely' and
16135 `unlikely' flags are false if the `insn' being scheduled is not a
16136 conditional branch.
16138 `attr_flag' is only used during delay slot scheduling and has no
16139 meaning to other passes of the compiler.
16142 The value of another attribute is returned. This is most useful
16143 for numeric attributes, as `eq_attr' and `attr_flag' produce more
16144 efficient code for non-numeric attributes.
16147 File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes
16149 13.19.3 Assigning Attribute Values to Insns
16150 -------------------------------------------
16152 The value assigned to an attribute of an insn is primarily determined by
16153 which pattern is matched by that insn (or which `define_peephole'
16154 generated it). Every `define_insn' and `define_peephole' can have an
16155 optional last argument to specify the values of attributes for matching
16156 insns. The value of any attribute not specified in a particular insn
16157 is set to the default value for that attribute, as specified in its
16158 `define_attr'. Extensive use of default values for attributes permits
16159 the specification of the values for only one or two attributes in the
16160 definition of most insn patterns, as seen in the example in the next
16163 The optional last argument of `define_insn' and `define_peephole' is a
16164 vector of expressions, each of which defines the value for a single
16165 attribute. The most general way of assigning an attribute's value is
16166 to use a `set' expression whose first operand is an `attr' expression
16167 giving the name of the attribute being set. The second operand of the
16168 `set' is an attribute expression (*note Expressions::) giving the value
16171 When the attribute value depends on the `alternative' attribute (i.e.,
16172 which is the applicable alternative in the constraint of the insn), the
16173 `set_attr_alternative' expression can be used. It allows the
16174 specification of a vector of attribute expressions, one for each
16177 When the generality of arbitrary attribute expressions is not required,
16178 the simpler `set_attr' expression can be used, which allows specifying
16179 a string giving either a single attribute value or a list of attribute
16180 values, one for each alternative.
16182 The form of each of the above specifications is shown below. In each
16183 case, NAME is a string specifying the attribute to be set.
16185 `(set_attr NAME VALUE-STRING)'
16186 VALUE-STRING is either a string giving the desired attribute value,
16187 or a string containing a comma-separated list giving the values for
16188 succeeding alternatives. The number of elements must match the
16189 number of alternatives in the constraint of the insn pattern.
16191 Note that it may be useful to specify `*' for some alternative, in
16192 which case the attribute will assume its default value for insns
16193 matching that alternative.
16195 `(set_attr_alternative NAME [VALUE1 VALUE2 ...])'
16196 Depending on the alternative of the insn, the value will be one of
16197 the specified values. This is a shorthand for using a `cond' with
16198 tests on the `alternative' attribute.
16200 `(set (attr NAME) VALUE)'
16201 The first operand of this `set' must be the special RTL expression
16202 `attr', whose sole operand is a string giving the name of the
16203 attribute being set. VALUE is the value of the attribute.
16205 The following shows three different ways of representing the same
16206 attribute value specification:
16208 (set_attr "type" "load,store,arith")
16210 (set_attr_alternative "type"
16211 [(const_string "load") (const_string "store")
16212 (const_string "arith")])
16215 (cond [(eq_attr "alternative" "1") (const_string "load")
16216 (eq_attr "alternative" "2") (const_string "store")]
16217 (const_string "arith")))
16219 The `define_asm_attributes' expression provides a mechanism to specify
16220 the attributes assigned to insns produced from an `asm' statement. It
16223 (define_asm_attributes [ATTR-SETS])
16225 where ATTR-SETS is specified the same as for both the `define_insn' and
16226 the `define_peephole' expressions.
16228 These values will typically be the "worst case" attribute values. For
16229 example, they might indicate that the condition code will be clobbered.
16231 A specification for a `length' attribute is handled specially. The
16232 way to compute the length of an `asm' insn is to multiply the length
16233 specified in the expression `define_asm_attributes' by the number of
16234 machine instructions specified in the `asm' statement, determined by
16235 counting the number of semicolons and newlines in the string.
16236 Therefore, the value of the `length' attribute specified in a
16237 `define_asm_attributes' should be the maximum possible length of a
16238 single machine instruction.
16241 File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes
16243 13.19.4 Example of Attribute Specifications
16244 -------------------------------------------
16246 The judicious use of defaulting is important in the efficient use of
16247 insn attributes. Typically, insns are divided into "types" and an
16248 attribute, customarily called `type', is used to represent this value.
16249 This attribute is normally used only to define the default value for
16250 other attributes. An example will clarify this usage.
16252 Assume we have a RISC machine with a condition code and in which only
16253 full-word operations are performed in registers. Let us assume that we
16254 can divide all insns into loads, stores, (integer) arithmetic
16255 operations, floating point operations, and branches.
16257 Here we will concern ourselves with determining the effect of an insn
16258 on the condition code and will limit ourselves to the following possible
16259 effects: The condition code can be set unpredictably (clobbered), not
16260 be changed, be set to agree with the results of the operation, or only
16261 changed if the item previously set into the condition code has been
16264 Here is part of a sample `md' file for such a machine:
16266 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith"))
16268 (define_attr "cc" "clobber,unchanged,set,change0"
16269 (cond [(eq_attr "type" "load")
16270 (const_string "change0")
16271 (eq_attr "type" "store,branch")
16272 (const_string "unchanged")
16273 (eq_attr "type" "arith")
16274 (if_then_else (match_operand:SI 0 "" "")
16275 (const_string "set")
16276 (const_string "clobber"))]
16277 (const_string "clobber")))
16280 [(set (match_operand:SI 0 "general_operand" "=r,r,m")
16281 (match_operand:SI 1 "general_operand" "r,m,r"))]
16287 [(set_attr "type" "arith,load,store")])
16289 Note that we assume in the above example that arithmetic operations
16290 performed on quantities smaller than a machine word clobber the
16291 condition code since they will set the condition code to a value
16292 corresponding to the full-word result.
16295 File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes
16297 13.19.5 Computing the Length of an Insn
16298 ---------------------------------------
16300 For many machines, multiple types of branch instructions are provided,
16301 each for different length branch displacements. In most cases, the
16302 assembler will choose the correct instruction to use. However, when
16303 the assembler cannot do so, GCC can when a special attribute, the
16304 `length' attribute, is defined. This attribute must be defined to have
16305 numeric values by specifying a null string in its `define_attr'.
16307 In the case of the `length' attribute, two additional forms of
16308 arithmetic terms are allowed in test expressions:
16311 This refers to the address of operand N of the current insn, which
16312 must be a `label_ref'.
16315 This refers to the address of the _current_ insn. It might have
16316 been more consistent with other usage to make this the address of
16317 the _next_ insn but this would be confusing because the length of
16318 the current insn is to be computed.
16320 For normal insns, the length will be determined by value of the
16321 `length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn
16322 patterns, the length is computed as the number of vectors multiplied by
16323 the size of each vector.
16325 Lengths are measured in addressable storage units (bytes).
16327 The following macros can be used to refine the length computation:
16329 `ADJUST_INSN_LENGTH (INSN, LENGTH)'
16330 If defined, modifies the length assigned to instruction INSN as a
16331 function of the context in which it is used. LENGTH is an lvalue
16332 that contains the initially computed length of the insn and should
16333 be updated with the correct length of the insn.
16335 This macro will normally not be required. A case in which it is
16336 required is the ROMP. On this machine, the size of an `addr_vec'
16337 insn must be increased by two to compensate for the fact that
16338 alignment may be required.
16340 The routine that returns `get_attr_length' (the value of the `length'
16341 attribute) can be used by the output routine to determine the form of
16342 the branch instruction to be written, as the example below illustrates.
16344 As an example of the specification of variable-length branches,
16345 consider the IBM 360. If we adopt the convention that a register will
16346 be set to the starting address of a function, we can jump to labels
16347 within 4k of the start using a four-byte instruction. Otherwise, we
16348 need a six-byte sequence to load the address from memory and then
16351 On such a machine, a pattern for a branch instruction might be
16352 specified as follows:
16354 (define_insn "jump"
16356 (label_ref (match_operand 0 "" "")))]
16359 return (get_attr_length (insn) == 4
16360 ? "b %l0" : "l r15,=a(%l0); br r15");
16362 [(set (attr "length")
16363 (if_then_else (lt (match_dup 0) (const_int 4096))
16368 File: gccint.info, Node: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes
16370 13.19.6 Constant Attributes
16371 ---------------------------
16373 A special form of `define_attr', where the expression for the default
16374 value is a `const' expression, indicates an attribute that is constant
16375 for a given run of the compiler. Constant attributes may be used to
16376 specify which variety of processor is used. For example,
16378 (define_attr "cpu" "m88100,m88110,m88000"
16380 (cond [(symbol_ref "TARGET_88100") (const_string "m88100")
16381 (symbol_ref "TARGET_88110") (const_string "m88110")]
16382 (const_string "m88000"))))
16384 (define_attr "memory" "fast,slow"
16386 (if_then_else (symbol_ref "TARGET_FAST_MEM")
16387 (const_string "fast")
16388 (const_string "slow"))))
16390 The routine generated for constant attributes has no parameters as it
16391 does not depend on any particular insn. RTL expressions used to define
16392 the value of a constant attribute may use the `symbol_ref' form, but
16393 may not use either the `match_operand' form or `eq_attr' forms
16394 involving insn attributes.
16397 File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Constant Attributes, Up: Insn Attributes
16399 13.19.7 Delay Slot Scheduling
16400 -----------------------------
16402 The insn attribute mechanism can be used to specify the requirements for
16403 delay slots, if any, on a target machine. An instruction is said to
16404 require a "delay slot" if some instructions that are physically after
16405 the instruction are executed as if they were located before it.
16406 Classic examples are branch and call instructions, which often execute
16407 the following instruction before the branch or call is performed.
16409 On some machines, conditional branch instructions can optionally
16410 "annul" instructions in the delay slot. This means that the
16411 instruction will not be executed for certain branch outcomes. Both
16412 instructions that annul if the branch is true and instructions that
16413 annul if the branch is false are supported.
16415 Delay slot scheduling differs from instruction scheduling in that
16416 determining whether an instruction needs a delay slot is dependent only
16417 on the type of instruction being generated, not on data flow between the
16418 instructions. See the next section for a discussion of data-dependent
16419 instruction scheduling.
16421 The requirement of an insn needing one or more delay slots is indicated
16422 via the `define_delay' expression. It has the following form:
16425 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1
16426 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2
16429 TEST is an attribute test that indicates whether this `define_delay'
16430 applies to a particular insn. If so, the number of required delay
16431 slots is determined by the length of the vector specified as the second
16432 argument. An insn placed in delay slot N must satisfy attribute test
16433 DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns
16434 may be annulled if the branch is true. Similarly, ANNUL-FALSE-N
16435 specifies which insns in the delay slot may be annulled if the branch
16436 is false. If annulling is not supported for that delay slot, `(nil)'
16439 For example, in the common case where branch and call insns require a
16440 single delay slot, which may contain any insn other than a branch or
16441 call, the following would be placed in the `md' file:
16443 (define_delay (eq_attr "type" "branch,call")
16444 [(eq_attr "type" "!branch,call") (nil) (nil)])
16446 Multiple `define_delay' expressions may be specified. In this case,
16447 each such expression specifies different delay slot requirements and
16448 there must be no insn for which tests in two `define_delay' expressions
16451 For example, if we have a machine that requires one delay slot for
16452 branches but two for calls, no delay slot can contain a branch or call
16453 insn, and any valid insn in the delay slot for the branch can be
16454 annulled if the branch is true, we might represent this as follows:
16456 (define_delay (eq_attr "type" "branch")
16457 [(eq_attr "type" "!branch,call")
16458 (eq_attr "type" "!branch,call")
16461 (define_delay (eq_attr "type" "call")
16462 [(eq_attr "type" "!branch,call") (nil) (nil)
16463 (eq_attr "type" "!branch,call") (nil) (nil)])
16466 File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes
16468 13.19.8 Specifying processor pipeline description
16469 -------------------------------------------------
16471 To achieve better performance, most modern processors (super-pipelined,
16472 superscalar RISC, and VLIW processors) have many "functional units" on
16473 which several instructions can be executed simultaneously. An
16474 instruction starts execution if its issue conditions are satisfied. If
16475 not, the instruction is stalled until its conditions are satisfied.
16476 Such "interlock (pipeline) delay" causes interruption of the fetching
16477 of successor instructions (or demands nop instructions, e.g. for some
16480 There are two major kinds of interlock delays in modern processors.
16481 The first one is a data dependence delay determining "instruction
16482 latency time". The instruction execution is not started until all
16483 source data have been evaluated by prior instructions (there are more
16484 complex cases when the instruction execution starts even when the data
16485 are not available but will be ready in given time after the instruction
16486 execution start). Taking the data dependence delays into account is
16487 simple. The data dependence (true, output, and anti-dependence) delay
16488 between two instructions is given by a constant. In most cases this
16489 approach is adequate. The second kind of interlock delays is a
16490 reservation delay. The reservation delay means that two instructions
16491 under execution will be in need of shared processors resources, i.e.
16492 buses, internal registers, and/or functional units, which are reserved
16493 for some time. Taking this kind of delay into account is complex
16494 especially for modern RISC processors.
16496 The task of exploiting more processor parallelism is solved by an
16497 instruction scheduler. For a better solution to this problem, the
16498 instruction scheduler has to have an adequate description of the
16499 processor parallelism (or "pipeline description"). GCC machine
16500 descriptions describe processor parallelism and functional unit
16501 reservations for groups of instructions with the aid of "regular
16504 The GCC instruction scheduler uses a "pipeline hazard recognizer" to
16505 figure out the possibility of the instruction issue by the processor on
16506 a given simulated processor cycle. The pipeline hazard recognizer is
16507 automatically generated from the processor pipeline description. The
16508 pipeline hazard recognizer generated from the machine description is
16509 based on a deterministic finite state automaton (DFA): the instruction
16510 issue is possible if there is a transition from one automaton state to
16511 another one. This algorithm is very fast, and furthermore, its speed
16512 is not dependent on processor complexity(1).
16514 The rest of this section describes the directives that constitute an
16515 automaton-based processor pipeline description. The order of these
16516 constructions within the machine description file is not important.
16518 The following optional construction describes names of automata
16519 generated and used for the pipeline hazards recognition. Sometimes the
16520 generated finite state automaton used by the pipeline hazard recognizer
16521 is large. If we use more than one automaton and bind functional units
16522 to the automata, the total size of the automata is usually less than
16523 the size of the single automaton. If there is no one such
16524 construction, only one finite state automaton is generated.
16526 (define_automaton AUTOMATA-NAMES)
16528 AUTOMATA-NAMES is a string giving names of the automata. The names
16529 are separated by commas. All the automata should have unique names.
16530 The automaton name is used in the constructions `define_cpu_unit' and
16531 `define_query_cpu_unit'.
16533 Each processor functional unit used in the description of instruction
16534 reservations should be described by the following construction.
16536 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME])
16538 UNIT-NAMES is a string giving the names of the functional units
16539 separated by commas. Don't use name `nothing', it is reserved for
16542 AUTOMATON-NAME is a string giving the name of the automaton with which
16543 the unit is bound. The automaton should be described in construction
16544 `define_automaton'. You should give "automaton-name", if there is a
16547 The assignment of units to automata are constrained by the uses of the
16548 units in insn reservations. The most important constraint is: if a
16549 unit reservation is present on a particular cycle of an alternative for
16550 an insn reservation, then some unit from the same automaton must be
16551 present on the same cycle for the other alternatives of the insn
16552 reservation. The rest of the constraints are mentioned in the
16553 description of the subsequent constructions.
16555 The following construction describes CPU functional units analogously
16556 to `define_cpu_unit'. The reservation of such units can be queried for
16557 an automaton state. The instruction scheduler never queries
16558 reservation of functional units for given automaton state. So as a
16559 rule, you don't need this construction. This construction could be
16560 used for future code generation goals (e.g. to generate VLIW insn
16563 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME])
16565 UNIT-NAMES is a string giving names of the functional units separated
16568 AUTOMATON-NAME is a string giving the name of the automaton with which
16571 The following construction is the major one to describe pipeline
16572 characteristics of an instruction.
16574 (define_insn_reservation INSN-NAME DEFAULT_LATENCY
16577 DEFAULT_LATENCY is a number giving latency time of the instruction.
16578 There is an important difference between the old description and the
16579 automaton based pipeline description. The latency time is used for all
16580 dependencies when we use the old description. In the automaton based
16581 pipeline description, the given latency time is only used for true
16582 dependencies. The cost of anti-dependencies is always zero and the
16583 cost of output dependencies is the difference between latency times of
16584 the producing and consuming insns (if the difference is negative, the
16585 cost is considered to be zero). You can always change the default
16586 costs for any description by using the target hook
16587 `TARGET_SCHED_ADJUST_COST' (*note Scheduling::).
16589 INSN-NAME is a string giving the internal name of the insn. The
16590 internal names are used in constructions `define_bypass' and in the
16591 automaton description file generated for debugging. The internal name
16592 has nothing in common with the names in `define_insn'. It is a good
16593 practice to use insn classes described in the processor manual.
16595 CONDITION defines what RTL insns are described by this construction.
16596 You should remember that you will be in trouble if CONDITION for two or
16597 more different `define_insn_reservation' constructions is TRUE for an
16598 insn. In this case what reservation will be used for the insn is not
16599 defined. Such cases are not checked during generation of the pipeline
16600 hazards recognizer because in general recognizing that two conditions
16601 may have the same value is quite difficult (especially if the conditions
16602 contain `symbol_ref'). It is also not checked during the pipeline
16603 hazard recognizer work because it would slow down the recognizer
16606 REGEXP is a string describing the reservation of the cpu's functional
16607 units by the instruction. The reservations are described by a regular
16608 expression according to the following syntax:
16610 regexp = regexp "," oneof
16613 oneof = oneof "|" allof
16616 allof = allof "+" repeat
16619 repeat = element "*" number
16622 element = cpu_function_unit_name
16628 * `,' is used for describing the start of the next cycle in the
16631 * `|' is used for describing a reservation described by the first
16632 regular expression *or* a reservation described by the second
16633 regular expression *or* etc.
16635 * `+' is used for describing a reservation described by the first
16636 regular expression *and* a reservation described by the second
16637 regular expression *and* etc.
16639 * `*' is used for convenience and simply means a sequence in which
16640 the regular expression are repeated NUMBER times with cycle
16641 advancing (see `,').
16643 * `cpu_function_unit_name' denotes reservation of the named
16646 * `reservation_name' -- see description of construction
16647 `define_reservation'.
16649 * `nothing' denotes no unit reservations.
16651 Sometimes unit reservations for different insns contain common parts.
16652 In such case, you can simplify the pipeline description by describing
16653 the common part by the following construction
16655 (define_reservation RESERVATION-NAME REGEXP)
16657 RESERVATION-NAME is a string giving name of REGEXP. Functional unit
16658 names and reservation names are in the same name space. So the
16659 reservation names should be different from the functional unit names
16660 and can not be the reserved name `nothing'.
16662 The following construction is used to describe exceptions in the
16663 latency time for given instruction pair. This is so called bypasses.
16665 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES
16668 NUMBER defines when the result generated by the instructions given in
16669 string OUT_INSN_NAMES will be ready for the instructions given in
16670 string IN_INSN_NAMES. The instructions in the string are separated by
16673 GUARD is an optional string giving the name of a C function which
16674 defines an additional guard for the bypass. The function will get the
16675 two insns as parameters. If the function returns zero the bypass will
16676 be ignored for this case. The additional guard is necessary to
16677 recognize complicated bypasses, e.g. when the consumer is only an
16678 address of insn `store' (not a stored value).
16680 The following five constructions are usually used to describe VLIW
16681 processors, or more precisely, to describe a placement of small
16682 instructions into VLIW instruction slots. They can be used for RISC
16685 (exclusion_set UNIT-NAMES UNIT-NAMES)
16686 (presence_set UNIT-NAMES PATTERNS)
16687 (final_presence_set UNIT-NAMES PATTERNS)
16688 (absence_set UNIT-NAMES PATTERNS)
16689 (final_absence_set UNIT-NAMES PATTERNS)
16691 UNIT-NAMES is a string giving names of functional units separated by
16694 PATTERNS is a string giving patterns of functional units separated by
16695 comma. Currently pattern is one unit or units separated by
16698 The first construction (`exclusion_set') means that each functional
16699 unit in the first string can not be reserved simultaneously with a unit
16700 whose name is in the second string and vice versa. For example, the
16701 construction is useful for describing processors (e.g. some SPARC
16702 processors) with a fully pipelined floating point functional unit which
16703 can execute simultaneously only single floating point insns or only
16704 double floating point insns.
16706 The second construction (`presence_set') means that each functional
16707 unit in the first string can not be reserved unless at least one of
16708 pattern of units whose names are in the second string is reserved.
16709 This is an asymmetric relation. For example, it is useful for
16710 description that VLIW `slot1' is reserved after `slot0' reservation.
16711 We could describe it by the following construction
16713 (presence_set "slot1" "slot0")
16715 Or `slot1' is reserved only after `slot0' and unit `b0' reservation.
16716 In this case we could write
16718 (presence_set "slot1" "slot0 b0")
16720 The third construction (`final_presence_set') is analogous to
16721 `presence_set'. The difference between them is when checking is done.
16722 When an instruction is issued in given automaton state reflecting all
16723 current and planned unit reservations, the automaton state is changed.
16724 The first state is a source state, the second one is a result state.
16725 Checking for `presence_set' is done on the source state reservation,
16726 checking for `final_presence_set' is done on the result reservation.
16727 This construction is useful to describe a reservation which is actually
16728 two subsequent reservations. For example, if we use
16730 (presence_set "slot1" "slot0")
16732 the following insn will be never issued (because `slot1' requires
16733 `slot0' which is absent in the source state).
16735 (define_reservation "insn_and_nop" "slot0 + slot1")
16737 but it can be issued if we use analogous `final_presence_set'.
16739 The forth construction (`absence_set') means that each functional unit
16740 in the first string can be reserved only if each pattern of units whose
16741 names are in the second string is not reserved. This is an asymmetric
16742 relation (actually `exclusion_set' is analogous to this one but it is
16743 symmetric). For example, it is useful for description that VLIW
16744 `slot0' can not be reserved after `slot1' or `slot2' reservation. We
16745 could describe it by the following construction
16747 (absence_set "slot2" "slot0, slot1")
16749 Or `slot2' can not be reserved if `slot0' and unit `b0' are reserved
16750 or `slot1' and unit `b1' are reserved. In this case we could write
16752 (absence_set "slot2" "slot0 b0, slot1 b1")
16754 All functional units mentioned in a set should belong to the same
16757 The last construction (`final_absence_set') is analogous to
16758 `absence_set' but checking is done on the result (state) reservation.
16759 See comments for `final_presence_set'.
16761 You can control the generator of the pipeline hazard recognizer with
16762 the following construction.
16764 (automata_option OPTIONS)
16766 OPTIONS is a string giving options which affect the generated code.
16767 Currently there are the following options:
16769 * "no-minimization" makes no minimization of the automaton. This is
16770 only worth to do when we are debugging the description and need to
16771 look more accurately at reservations of states.
16773 * "time" means printing additional time statistics about generation
16776 * "v" means a generation of the file describing the result automata.
16777 The file has suffix `.dfa' and can be used for the description
16778 verification and debugging.
16780 * "w" means a generation of warning instead of error for
16781 non-critical errors.
16783 * "ndfa" makes nondeterministic finite state automata. This affects
16784 the treatment of operator `|' in the regular expressions. The
16785 usual treatment of the operator is to try the first alternative
16786 and, if the reservation is not possible, the second alternative.
16787 The nondeterministic treatment means trying all alternatives, some
16788 of them may be rejected by reservations in the subsequent insns.
16790 * "progress" means output of a progress bar showing how many states
16791 were generated so far for automaton being processed. This is
16792 useful during debugging a DFA description. If you see too many
16793 generated states, you could interrupt the generator of the pipeline
16794 hazard recognizer and try to figure out a reason for generation of
16795 the huge automaton.
16797 As an example, consider a superscalar RISC machine which can issue
16798 three insns (two integer insns and one floating point insn) on the
16799 cycle but can finish only two insns. To describe this, we define the
16800 following functional units.
16802 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline")
16803 (define_cpu_unit "port0, port1")
16805 All simple integer insns can be executed in any integer pipeline and
16806 their result is ready in two cycles. The simple integer insns are
16807 issued into the first pipeline unless it is reserved, otherwise they
16808 are issued into the second pipeline. Integer division and
16809 multiplication insns can be executed only in the second integer
16810 pipeline and their results are ready correspondingly in 8 and 4 cycles.
16811 The integer division is not pipelined, i.e. the subsequent integer
16812 division insn can not be issued until the current division insn
16813 finished. Floating point insns are fully pipelined and their results
16814 are ready in 3 cycles. Where the result of a floating point insn is
16815 used by an integer insn, an additional delay of one cycle is incurred.
16816 To describe all of this we could specify
16818 (define_cpu_unit "div")
16820 (define_insn_reservation "simple" 2 (eq_attr "type" "int")
16821 "(i0_pipeline | i1_pipeline), (port0 | port1)")
16823 (define_insn_reservation "mult" 4 (eq_attr "type" "mult")
16824 "i1_pipeline, nothing*2, (port0 | port1)")
16826 (define_insn_reservation "div" 8 (eq_attr "type" "div")
16827 "i1_pipeline, div*7, div + (port0 | port1)")
16829 (define_insn_reservation "float" 3 (eq_attr "type" "float")
16830 "f_pipeline, nothing, (port0 | port1))
16832 (define_bypass 4 "float" "simple,mult,div")
16834 To simplify the description we could describe the following reservation
16836 (define_reservation "finish" "port0|port1")
16838 and use it in all `define_insn_reservation' as in the following
16841 (define_insn_reservation "simple" 2 (eq_attr "type" "int")
16842 "(i0_pipeline | i1_pipeline), finish")
16844 ---------- Footnotes ----------
16846 (1) However, the size of the automaton depends on processor
16847 complexity. To limit this effect, machine descriptions can split
16848 orthogonal parts of the machine description among several automata:
16849 but then, since each of these must be stepped independently, this
16850 does cause a small decrease in the algorithm's performance.
16853 File: gccint.info, Node: Conditional Execution, Next: Constant Definitions, Prev: Insn Attributes, Up: Machine Desc
16855 13.20 Conditional Execution
16856 ===========================
16858 A number of architectures provide for some form of conditional
16859 execution, or predication. The hallmark of this feature is the ability
16860 to nullify most of the instructions in the instruction set. When the
16861 instruction set is large and not entirely symmetric, it can be quite
16862 tedious to describe these forms directly in the `.md' file. An
16863 alternative is the `define_cond_exec' template.
16866 [PREDICATE-PATTERN]
16870 PREDICATE-PATTERN is the condition that must be true for the insn to
16871 be executed at runtime and should match a relational operator. One can
16872 use `match_operator' to match several relational operators at once.
16873 Any `match_operand' operands must have no more than one alternative.
16875 CONDITION is a C expression that must be true for the generated
16878 OUTPUT-TEMPLATE is a string similar to the `define_insn' output
16879 template (*note Output Template::), except that the `*' and `@' special
16880 cases do not apply. This is only useful if the assembly text for the
16881 predicate is a simple prefix to the main insn. In order to handle the
16882 general case, there is a global variable `current_insn_predicate' that
16883 will contain the entire predicate if the current insn is predicated,
16884 and will otherwise be `NULL'.
16886 When `define_cond_exec' is used, an implicit reference to the
16887 `predicable' instruction attribute is made. *Note Insn Attributes::.
16888 This attribute must be boolean (i.e. have exactly two elements in its
16889 LIST-OF-VALUES). Further, it must not be used with complex
16890 expressions. That is, the default and all uses in the insns must be a
16891 simple constant, not dependent on the alternative or anything else.
16893 For each `define_insn' for which the `predicable' attribute is true, a
16894 new `define_insn' pattern will be generated that matches a predicated
16895 version of the instruction. For example,
16897 (define_insn "addsi"
16898 [(set (match_operand:SI 0 "register_operand" "r")
16899 (plus:SI (match_operand:SI 1 "register_operand" "r")
16900 (match_operand:SI 2 "register_operand" "r")))]
16905 [(ne (match_operand:CC 0 "register_operand" "c")
16910 generates a new pattern
16914 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0))
16915 (set (match_operand:SI 0 "register_operand" "r")
16916 (plus:SI (match_operand:SI 1 "register_operand" "r")
16917 (match_operand:SI 2 "register_operand" "r"))))]
16918 "(TEST2) && (TEST1)"
16919 "(%3) add %2,%1,%0")
16922 File: gccint.info, Node: Constant Definitions, Next: Macros, Prev: Conditional Execution, Up: Machine Desc
16924 13.21 Constant Definitions
16925 ==========================
16927 Using literal constants inside instruction patterns reduces legibility
16928 and can be a maintenance problem.
16930 To overcome this problem, you may use the `define_constants'
16931 expression. It contains a vector of name-value pairs. From that point
16932 on, wherever any of the names appears in the MD file, it is as if the
16933 corresponding value had been written instead. You may use
16934 `define_constants' multiple times; each appearance adds more constants
16935 to the table. It is an error to redefine a constant with a different
16938 To come back to the a29k load multiple example, instead of
16941 [(match_parallel 0 "load_multiple_operation"
16942 [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
16943 (match_operand:SI 2 "memory_operand" "m"))
16945 (clobber (reg:SI 179))])]
16951 (define_constants [
16959 [(match_parallel 0 "load_multiple_operation"
16960 [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
16961 (match_operand:SI 2 "memory_operand" "m"))
16962 (use (reg:SI R_CR))
16963 (clobber (reg:SI R_CR))])]
16967 The constants that are defined with a define_constant are also output
16968 in the insn-codes.h header file as #defines.
16971 File: gccint.info, Node: Macros, Prev: Constant Definitions, Up: Machine Desc
16976 Ports often need to define similar patterns for more than one machine
16977 mode or for more than one rtx code. GCC provides some simple macro
16978 facilities to make this process easier.
16982 * Mode Macros:: Generating variations of patterns for different modes.
16983 * Code Macros:: Doing the same for codes.
16986 File: gccint.info, Node: Mode Macros, Next: Code Macros, Up: Macros
16988 13.22.1 Mode Macros
16989 -------------------
16991 Ports often need to define similar patterns for two or more different
16992 modes. For example:
16994 * If a processor has hardware support for both single and double
16995 floating-point arithmetic, the `SFmode' patterns tend to be very
16996 similar to the `DFmode' ones.
16998 * If a port uses `SImode' pointers in one configuration and `DImode'
16999 pointers in another, it will usually have very similar `SImode'
17000 and `DImode' patterns for manipulating pointers.
17002 Mode macros allow several patterns to be instantiated from one `.md'
17003 file template. They can be used with any type of rtx-based construct,
17004 such as a `define_insn', `define_split', or `define_peephole2'.
17008 * Defining Mode Macros:: Defining a new mode macro.
17009 * Substitutions:: Combining mode macros with substitutions
17010 * Examples:: Examples
17013 File: gccint.info, Node: Defining Mode Macros, Next: Substitutions, Up: Mode Macros
17015 13.22.1.1 Defining Mode Macros
17016 ..............................
17018 The syntax for defining a mode macro is:
17020 (define_mode_macro NAME [(MODE1 "COND1") ... (MODEN "CONDN")])
17022 This allows subsequent `.md' file constructs to use the mode suffix
17023 `:NAME'. Every construct that does so will be expanded N times, once
17024 with every use of `:NAME' replaced by `:MODE1', once with every use
17025 replaced by `:MODE2', and so on. In the expansion for a particular
17026 MODEI, every C condition will also require that CONDI be true.
17030 (define_mode_macro P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
17032 defines a new mode suffix `:P'. Every construct that uses `:P' will
17033 be expanded twice, once with every `:P' replaced by `:SI' and once with
17034 every `:P' replaced by `:DI'. The `:SI' version will only apply if
17035 `Pmode == SImode' and the `:DI' version will only apply if `Pmode ==
17038 As with other `.md' conditions, an empty string is treated as "always
17039 true". `(MODE "")' can also be abbreviated to `MODE'. For example:
17041 (define_mode_macro GPR [SI (DI "TARGET_64BIT")])
17043 means that the `:DI' expansion only applies if `TARGET_64BIT' but that
17044 the `:SI' expansion has no such constraint.
17046 Macros are applied in the order they are defined. This can be
17047 significant if two macros are used in a construct that requires
17048 substitutions. *Note Substitutions::.
17051 File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Macros, Up: Mode Macros
17053 13.22.1.2 Substitution in Mode Macros
17054 .....................................
17056 If an `.md' file construct uses mode macros, each version of the
17057 construct will often need slightly different strings or modes. For
17060 * When a `define_expand' defines several `addM3' patterns (*note
17061 Standard Names::), each expander will need to use the appropriate
17064 * When a `define_insn' defines several instruction patterns, each
17065 instruction will often use a different assembler mnemonic.
17067 * When a `define_insn' requires operands with different modes, using
17068 a macro for one of the operand modes usually requires a specific
17069 mode for the other operand(s).
17071 GCC supports such variations through a system of "mode attributes".
17072 There are two standard attributes: `mode', which is the name of the
17073 mode in lower case, and `MODE', which is the same thing in upper case.
17074 You can define other attributes using:
17076 (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")])
17078 where NAME is the name of the attribute and VALUEI is the value
17079 associated with MODEI.
17081 When GCC replaces some :MACRO with :MODE, it will scan each string and
17082 mode in the pattern for sequences of the form `<MACRO:ATTR>', where
17083 ATTR is the name of a mode attribute. If the attribute is defined for
17084 MODE, the whole `<...>' sequence will be replaced by the appropriate
17087 For example, suppose an `.md' file has:
17089 (define_mode_macro P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
17090 (define_mode_attr load [(SI "lw") (DI "ld")])
17092 If one of the patterns that uses `:P' contains the string
17093 `"<P:load>\t%0,%1"', the `SI' version of that pattern will use
17094 `"lw\t%0,%1"' and the `DI' version will use `"ld\t%0,%1"'.
17096 Here is an example of using an attribute for a mode:
17098 (define_mode_macro LONG [SI DI])
17099 (define_mode_attr SHORT [(SI "HI") (DI "SI")])
17101 (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...)
17103 The `MACRO:' prefix may be omitted, in which case the substitution
17104 will be attempted for every macro expansion.
17107 File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Macros
17109 13.22.1.3 Mode Macro Examples
17110 .............................
17112 Here is an example from the MIPS port. It defines the following modes
17113 and attributes (among others):
17115 (define_mode_macro GPR [SI (DI "TARGET_64BIT")])
17116 (define_mode_attr d [(SI "") (DI "d")])
17118 and uses the following template to define both `subsi3' and `subdi3':
17120 (define_insn "sub<mode>3"
17121 [(set (match_operand:GPR 0 "register_operand" "=d")
17122 (minus:GPR (match_operand:GPR 1 "register_operand" "d")
17123 (match_operand:GPR 2 "register_operand" "d")))]
17125 "<d>subu\t%0,%1,%2"
17126 [(set_attr "type" "arith")
17127 (set_attr "mode" "<MODE>")])
17129 This is exactly equivalent to:
17131 (define_insn "subsi3"
17132 [(set (match_operand:SI 0 "register_operand" "=d")
17133 (minus:SI (match_operand:SI 1 "register_operand" "d")
17134 (match_operand:SI 2 "register_operand" "d")))]
17137 [(set_attr "type" "arith")
17138 (set_attr "mode" "SI")])
17140 (define_insn "subdi3"
17141 [(set (match_operand:DI 0 "register_operand" "=d")
17142 (minus:DI (match_operand:DI 1 "register_operand" "d")
17143 (match_operand:DI 2 "register_operand" "d")))]
17146 [(set_attr "type" "arith")
17147 (set_attr "mode" "DI")])
17150 File: gccint.info, Node: Code Macros, Prev: Mode Macros, Up: Macros
17152 13.22.2 Code Macros
17153 -------------------
17155 Code macros operate in a similar way to mode macros. *Note Mode
17160 (define_code_macro NAME [(CODE1 "COND1") ... (CODEN "CONDN")])
17162 defines a pseudo rtx code NAME that can be instantiated as CODEI if
17163 condition CONDI is true. Each CODEI must have the same rtx format.
17164 *Note RTL Classes::.
17166 As with mode macros, each pattern that uses NAME will be expanded N
17167 times, once with all uses of NAME replaced by CODE1, once with all uses
17168 replaced by CODE2, and so on. *Note Defining Mode Macros::.
17170 It is possible to define attributes for codes as well as for modes.
17171 There are two standard code attributes: `code', the name of the code in
17172 lower case, and `CODE', the name of the code in upper case. Other
17173 attributes are defined using:
17175 (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")])
17177 Here's an example of code macros in action, taken from the MIPS port:
17179 (define_code_macro any_cond [unordered ordered unlt unge uneq ltgt unle ungt
17180 eq ne gt ge lt le gtu geu ltu leu])
17182 (define_expand "b<code>"
17184 (if_then_else (any_cond:CC (cc0)
17186 (label_ref (match_operand 0 ""))
17190 gen_conditional_branch (operands, <CODE>);
17194 This is equivalent to:
17196 (define_expand "bunordered"
17198 (if_then_else (unordered:CC (cc0)
17200 (label_ref (match_operand 0 ""))
17204 gen_conditional_branch (operands, UNORDERED);
17208 (define_expand "bordered"
17210 (if_then_else (ordered:CC (cc0)
17212 (label_ref (match_operand 0 ""))
17216 gen_conditional_branch (operands, ORDERED);
17223 File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top
17225 14 Target Description Macros and Functions
17226 ******************************************
17228 In addition to the file `MACHINE.md', a machine description includes a
17229 C header file conventionally given the name `MACHINE.h' and a C source
17230 file named `MACHINE.c'. The header file defines numerous macros that
17231 convey the information about the target machine that does not fit into
17232 the scheme of the `.md' file. The file `tm.h' should be a link to
17233 `MACHINE.h'. The header file `config.h' includes `tm.h' and most
17234 compiler source files include `config.h'. The source file defines a
17235 variable `targetm', which is a structure containing pointers to
17236 functions and data relating to the target machine. `MACHINE.c' should
17237 also contain their definitions, if they are not defined elsewhere in
17238 GCC, and other functions called through the macros defined in the `.h'
17243 * Target Structure:: The `targetm' variable.
17244 * Driver:: Controlling how the driver runs the compilation passes.
17245 * Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'.
17246 * Per-Function Data:: Defining data structures for per-function information.
17247 * Storage Layout:: Defining sizes and alignments of data.
17248 * Type Layout:: Defining sizes and properties of basic user data types.
17249 * Registers:: Naming and describing the hardware registers.
17250 * Register Classes:: Defining the classes of hardware registers.
17251 * Stack and Calling:: Defining which way the stack grows and by how much.
17252 * Varargs:: Defining the varargs macros.
17253 * Trampolines:: Code set up at run time to enter a nested function.
17254 * Library Calls:: Controlling how library routines are implicitly called.
17255 * Addressing Modes:: Defining addressing modes valid for memory operands.
17256 * Condition Code:: Defining how insns update the condition code.
17257 * Costs:: Defining relative costs of different operations.
17258 * Scheduling:: Adjusting the behavior of the instruction scheduler.
17259 * Sections:: Dividing storage into text, data, and other sections.
17260 * PIC:: Macros for position independent code.
17261 * Assembler Format:: Defining how to write insns and pseudo-ops to output.
17262 * Debugging Info:: Defining the format of debugging output.
17263 * Floating Point:: Handling floating point for cross-compilers.
17264 * Mode Switching:: Insertion of mode-switching instructions.
17265 * Target Attributes:: Defining target-specific uses of `__attribute__'.
17266 * MIPS Coprocessors:: MIPS coprocessor support and how to customize it.
17267 * PCH Target:: Validity checking for precompiled headers.
17268 * C++ ABI:: Controlling C++ ABI changes.
17269 * Misc:: Everything else.
17272 File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros
17274 14.1 The Global `targetm' Variable
17275 ==================================
17277 -- Variable: struct gcc_target targetm
17278 The target `.c' file must define the global `targetm' variable
17279 which contains pointers to functions and data relating to the
17280 target machine. The variable is declared in `target.h';
17281 `target-def.h' defines the macro `TARGET_INITIALIZER' which is
17282 used to initialize the variable, and macros for the default
17283 initializers for elements of the structure. The `.c' file should
17284 override those macros for which the default definition is
17285 inappropriate. For example:
17286 #include "target.h"
17287 #include "target-def.h"
17289 /* Initialize the GCC target structure. */
17291 #undef TARGET_COMP_TYPE_ATTRIBUTES
17292 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes
17294 struct gcc_target targetm = TARGET_INITIALIZER;
17296 Where a macro should be defined in the `.c' file in this manner to form
17297 part of the `targetm' structure, it is documented below as a "Target
17298 Hook" with a prototype. Many macros will change in future from being
17299 defined in the `.h' file to being part of the `targetm' structure.
17302 File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros
17304 14.2 Controlling the Compilation Driver, `gcc'
17305 ==============================================
17307 You can control the compilation driver.
17309 -- Macro: SWITCH_TAKES_ARG (CHAR)
17310 A C expression which determines whether the option `-CHAR' takes
17311 arguments. The value should be the number of arguments that
17312 option takes-zero, for many options.
17314 By default, this macro is defined as `DEFAULT_SWITCH_TAKES_ARG',
17315 which handles the standard options properly. You need not define
17316 `SWITCH_TAKES_ARG' unless you wish to add additional options which
17317 take arguments. Any redefinition should call
17318 `DEFAULT_SWITCH_TAKES_ARG' and then check for additional options.
17320 -- Macro: WORD_SWITCH_TAKES_ARG (NAME)
17321 A C expression which determines whether the option `-NAME' takes
17322 arguments. The value should be the number of arguments that
17323 option takes-zero, for many options. This macro rather than
17324 `SWITCH_TAKES_ARG' is used for multi-character option names.
17326 By default, this macro is defined as
17327 `DEFAULT_WORD_SWITCH_TAKES_ARG', which handles the standard options
17328 properly. You need not define `WORD_SWITCH_TAKES_ARG' unless you
17329 wish to add additional options which take arguments. Any
17330 redefinition should call `DEFAULT_WORD_SWITCH_TAKES_ARG' and then
17331 check for additional options.
17333 -- Macro: SWITCH_CURTAILS_COMPILATION (CHAR)
17334 A C expression which determines whether the option `-CHAR' stops
17335 compilation before the generation of an executable. The value is
17336 boolean, nonzero if the option does stop an executable from being
17337 generated, zero otherwise.
17339 By default, this macro is defined as
17340 `DEFAULT_SWITCH_CURTAILS_COMPILATION', which handles the standard
17341 options properly. You need not define
17342 `SWITCH_CURTAILS_COMPILATION' unless you wish to add additional
17343 options which affect the generation of an executable. Any
17344 redefinition should call `DEFAULT_SWITCH_CURTAILS_COMPILATION' and
17345 then check for additional options.
17347 -- Macro: SWITCHES_NEED_SPACES
17348 A string-valued C expression which enumerates the options for which
17349 the linker needs a space between the option and its argument.
17351 If this macro is not defined, the default value is `""'.
17353 -- Macro: TARGET_OPTION_TRANSLATE_TABLE
17354 If defined, a list of pairs of strings, the first of which is a
17355 potential command line target to the `gcc' driver program, and the
17356 second of which is a space-separated (tabs and other whitespace
17357 are not supported) list of options with which to replace the first
17358 option. The target defining this list is responsible for assuring
17359 that the results are valid. Replacement options may not be the
17360 `--opt' style, they must be the `-opt' style. It is the intention
17361 of this macro to provide a mechanism for substitution that affects
17362 the multilibs chosen, such as one option that enables many
17363 options, some of which select multilibs. Example nonsensical
17364 definition, where `-malt-abi', `-EB', and `-mspoo' cause different
17365 multilibs to be chosen:
17367 #define TARGET_OPTION_TRANSLATE_TABLE \
17368 { "-fast", "-march=fast-foo -malt-abi -I/usr/fast-foo" }, \
17369 { "-compat", "-EB -malign=4 -mspoo" }
17371 -- Macro: DRIVER_SELF_SPECS
17372 A list of specs for the driver itself. It should be a suitable
17373 initializer for an array of strings, with no surrounding braces.
17375 The driver applies these specs to its own command line between
17376 loading default `specs' files (but not command-line specified
17377 ones) and choosing the multilib directory or running any
17378 subcommands. It applies them in the order given, so each spec can
17379 depend on the options added by earlier ones. It is also possible
17380 to remove options using `%<OPTION' in the usual way.
17382 This macro can be useful when a port has several interdependent
17383 target options. It provides a way of standardizing the command
17384 line so that the other specs are easier to write.
17386 Do not define this macro if it does not need to do anything.
17388 -- Macro: OPTION_DEFAULT_SPECS
17389 A list of specs used to support configure-time default options
17390 (i.e. `--with' options) in the driver. It should be a suitable
17391 initializer for an array of structures, each containing two
17392 strings, without the outermost pair of surrounding braces.
17394 The first item in the pair is the name of the default. This must
17395 match the code in `config.gcc' for the target. The second item is
17396 a spec to apply if a default with this name was specified. The
17397 string `%(VALUE)' in the spec will be replaced by the value of the
17398 default everywhere it occurs.
17400 The driver will apply these specs to its own command line between
17401 loading default `specs' files and processing `DRIVER_SELF_SPECS',
17402 using the same mechanism as `DRIVER_SELF_SPECS'.
17404 Do not define this macro if it does not need to do anything.
17407 A C string constant that tells the GCC driver program options to
17408 pass to CPP. It can also specify how to translate options you
17409 give to GCC into options for GCC to pass to the CPP.
17411 Do not define this macro if it does not need to do anything.
17413 -- Macro: CPLUSPLUS_CPP_SPEC
17414 This macro is just like `CPP_SPEC', but is used for C++, rather
17415 than C. If you do not define this macro, then the value of
17416 `CPP_SPEC' (if any) will be used instead.
17419 A C string constant that tells the GCC driver program options to
17420 pass to `cc1', `cc1plus', `f771', and the other language front
17421 ends. It can also specify how to translate options you give to
17422 GCC into options for GCC to pass to front ends.
17424 Do not define this macro if it does not need to do anything.
17426 -- Macro: CC1PLUS_SPEC
17427 A C string constant that tells the GCC driver program options to
17428 pass to `cc1plus'. It can also specify how to translate options
17429 you give to GCC into options for GCC to pass to the `cc1plus'.
17431 Do not define this macro if it does not need to do anything. Note
17432 that everything defined in CC1_SPEC is already passed to `cc1plus'
17433 so there is no need to duplicate the contents of CC1_SPEC in
17437 A C string constant that tells the GCC driver program options to
17438 pass to the assembler. It can also specify how to translate
17439 options you give to GCC into options for GCC to pass to the
17440 assembler. See the file `sun3.h' for an example of this.
17442 Do not define this macro if it does not need to do anything.
17444 -- Macro: ASM_FINAL_SPEC
17445 A C string constant that tells the GCC driver program how to run
17446 any programs which cleanup after the normal assembler. Normally,
17447 this is not needed. See the file `mips.h' for an example of this.
17449 Do not define this macro if it does not need to do anything.
17451 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT
17452 Define this macro, with no value, if the driver should give the
17453 assembler an argument consisting of a single dash, `-', to
17454 instruct it to read from its standard input (which will be a pipe
17455 connected to the output of the compiler proper). This argument is
17456 given after any `-o' option specifying the name of the output file.
17458 If you do not define this macro, the assembler is assumed to read
17459 its standard input if given no non-option arguments. If your
17460 assembler cannot read standard input at all, use a `%{pipe:%e}'
17461 construct; see `mips.h' for instance.
17463 -- Macro: LINK_SPEC
17464 A C string constant that tells the GCC driver program options to
17465 pass to the linker. It can also specify how to translate options
17466 you give to GCC into options for GCC to pass to the linker.
17468 Do not define this macro if it does not need to do anything.
17471 Another C string constant used much like `LINK_SPEC'. The
17472 difference between the two is that `LIB_SPEC' is used at the end
17473 of the command given to the linker.
17475 If this macro is not defined, a default is provided that loads the
17476 standard C library from the usual place. See `gcc.c'.
17478 -- Macro: LIBGCC_SPEC
17479 Another C string constant that tells the GCC driver program how
17480 and when to place a reference to `libgcc.a' into the linker
17481 command line. This constant is placed both before and after the
17482 value of `LIB_SPEC'.
17484 If this macro is not defined, the GCC driver provides a default
17485 that passes the string `-lgcc' to the linker.
17487 -- Macro: REAL_LIBGCC_SPEC
17488 By default, if `ENABLE_SHARED_LIBGCC' is defined, the
17489 `LIBGCC_SPEC' is not directly used by the driver program but is
17490 instead modified to refer to different versions of `libgcc.a'
17491 depending on the values of the command line flags `-static',
17492 `-shared', `-static-libgcc', and `-shared-libgcc'. On targets
17493 where these modifications are inappropriate, define
17494 `REAL_LIBGCC_SPEC' instead. `REAL_LIBGCC_SPEC' tells the driver
17495 how to place a reference to `libgcc' on the link command line,
17496 but, unlike `LIBGCC_SPEC', it is used unmodified.
17498 -- Macro: USE_LD_AS_NEEDED
17499 A macro that controls the modifications to `LIBGCC_SPEC' mentioned
17500 in `REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that
17501 uses -as-needed and the shared libgcc in place of the static
17502 exception handler library, when linking without any of `-static',
17503 `-static-libgcc', or `-shared-libgcc'.
17505 -- Macro: LINK_EH_SPEC
17506 If defined, this C string constant is added to `LINK_SPEC'. When
17507 `USE_LD_AS_NEEDED' is zero or undefined, it also affects the
17508 modifications to `LIBGCC_SPEC' mentioned in `REAL_LIBGCC_SPEC'.
17510 -- Macro: STARTFILE_SPEC
17511 Another C string constant used much like `LINK_SPEC'. The
17512 difference between the two is that `STARTFILE_SPEC' is used at the
17513 very beginning of the command given to the linker.
17515 If this macro is not defined, a default is provided that loads the
17516 standard C startup file from the usual place. See `gcc.c'.
17518 -- Macro: ENDFILE_SPEC
17519 Another C string constant used much like `LINK_SPEC'. The
17520 difference between the two is that `ENDFILE_SPEC' is used at the
17521 very end of the command given to the linker.
17523 Do not define this macro if it does not need to do anything.
17525 -- Macro: THREAD_MODEL_SPEC
17526 GCC `-v' will print the thread model GCC was configured to use.
17527 However, this doesn't work on platforms that are multilibbed on
17528 thread models, such as AIX 4.3. On such platforms, define
17529 `THREAD_MODEL_SPEC' such that it evaluates to a string without
17530 blanks that names one of the recognized thread models. `%*', the
17531 default value of this macro, will expand to the value of
17532 `thread_file' set in `config.gcc'.
17534 -- Macro: SYSROOT_SUFFIX_SPEC
17535 Define this macro to add a suffix to the target sysroot when GCC is
17536 configured with a sysroot. This will cause GCC to search for
17537 usr/lib, et al, within sysroot+suffix.
17539 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC
17540 Define this macro to add a headers_suffix to the target sysroot
17541 when GCC is configured with a sysroot. This will cause GCC to
17542 pass the updated sysroot+headers_suffix to CPP, causing it to
17543 search for usr/include, et al, within sysroot+headers_suffix.
17545 -- Macro: EXTRA_SPECS
17546 Define this macro to provide additional specifications to put in
17547 the `specs' file that can be used in various specifications like
17550 The definition should be an initializer for an array of structures,
17551 containing a string constant, that defines the specification name,
17552 and a string constant that provides the specification.
17554 Do not define this macro if it does not need to do anything.
17556 `EXTRA_SPECS' is useful when an architecture contains several
17557 related targets, which have various `..._SPECS' which are similar
17558 to each other, and the maintainer would like one central place to
17559 keep these definitions.
17561 For example, the PowerPC System V.4 targets use `EXTRA_SPECS' to
17562 define either `_CALL_SYSV' when the System V calling sequence is
17563 used or `_CALL_AIX' when the older AIX-based calling sequence is
17566 The `config/rs6000/rs6000.h' target file defines:
17568 #define EXTRA_SPECS \
17569 { "cpp_sysv_default", CPP_SYSV_DEFAULT },
17571 #define CPP_SYS_DEFAULT ""
17573 The `config/rs6000/sysv.h' target file defines:
17576 "%{posix: -D_POSIX_SOURCE } \
17577 %{mcall-sysv: -D_CALL_SYSV } \
17578 %{!mcall-sysv: %(cpp_sysv_default) } \
17579 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}"
17581 #undef CPP_SYSV_DEFAULT
17582 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV"
17584 while the `config/rs6000/eabiaix.h' target file defines
17585 `CPP_SYSV_DEFAULT' as:
17587 #undef CPP_SYSV_DEFAULT
17588 #define CPP_SYSV_DEFAULT "-D_CALL_AIX"
17590 -- Macro: LINK_LIBGCC_SPECIAL_1
17591 Define this macro if the driver program should find the library
17592 `libgcc.a'. If you do not define this macro, the driver program
17593 will pass the argument `-lgcc' to tell the linker to do the search.
17595 -- Macro: LINK_GCC_C_SEQUENCE_SPEC
17596 The sequence in which libgcc and libc are specified to the linker.
17597 By default this is `%G %L %G'.
17599 -- Macro: LINK_COMMAND_SPEC
17600 A C string constant giving the complete command line need to
17601 execute the linker. When you do this, you will need to update
17602 your port each time a change is made to the link command line
17603 within `gcc.c'. Therefore, define this macro only if you need to
17604 completely redefine the command line for invoking the linker and
17605 there is no other way to accomplish the effect you need.
17606 Overriding this macro may be avoidable by overriding
17607 `LINK_GCC_C_SEQUENCE_SPEC' instead.
17609 -- Macro: LINK_ELIMINATE_DUPLICATE_LDIRECTORIES
17610 A nonzero value causes `collect2' to remove duplicate
17611 `-LDIRECTORY' search directories from linking commands. Do not
17612 give it a nonzero value if removing duplicate search directories
17613 changes the linker's semantics.
17615 -- Macro: MULTILIB_DEFAULTS
17616 Define this macro as a C expression for the initializer of an
17617 array of string to tell the driver program which options are
17618 defaults for this target and thus do not need to be handled
17619 specially when using `MULTILIB_OPTIONS'.
17621 Do not define this macro if `MULTILIB_OPTIONS' is not defined in
17622 the target makefile fragment or if none of the options listed in
17623 `MULTILIB_OPTIONS' are set by default. *Note Target Fragment::.
17625 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR
17626 Define this macro to tell `gcc' that it should only translate a
17627 `-B' prefix into a `-L' linker option if the prefix indicates an
17628 absolute file name.
17630 -- Macro: MD_EXEC_PREFIX
17631 If defined, this macro is an additional prefix to try after
17632 `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the
17633 `-b' option is used, or the compiler is built as a cross compiler.
17634 If you define `MD_EXEC_PREFIX', then be sure to add it to the
17635 list of directories used to find the assembler in `configure.in'.
17637 -- Macro: STANDARD_STARTFILE_PREFIX
17638 Define this macro as a C string constant if you wish to override
17639 the standard choice of `libdir' as the default prefix to try when
17640 searching for startup files such as `crt0.o'.
17641 `STANDARD_STARTFILE_PREFIX' is not searched when the compiler is
17642 built as a cross compiler.
17644 -- Macro: STANDARD_STARTFILE_PREFIX_1
17645 Define this macro as a C string constant if you wish to override
17646 the standard choice of `/lib' as a prefix to try after the default
17647 prefix when searching for startup files such as `crt0.o'.
17648 `STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is
17649 built as a cross compiler.
17651 -- Macro: STANDARD_STARTFILE_PREFIX_2
17652 Define this macro as a C string constant if you wish to override
17653 the standard choice of `/lib' as yet another prefix to try after
17654 the default prefix when searching for startup files such as
17655 `crt0.o'. `STANDARD_STARTFILE_PREFIX_2' is not searched when the
17656 compiler is built as a cross compiler.
17658 -- Macro: MD_STARTFILE_PREFIX
17659 If defined, this macro supplies an additional prefix to try after
17660 the standard prefixes. `MD_EXEC_PREFIX' is not searched when the
17661 `-b' option is used, or when the compiler is built as a cross
17664 -- Macro: MD_STARTFILE_PREFIX_1
17665 If defined, this macro supplies yet another prefix to try after the
17666 standard prefixes. It is not searched when the `-b' option is
17667 used, or when the compiler is built as a cross compiler.
17669 -- Macro: INIT_ENVIRONMENT
17670 Define this macro as a C string constant if you wish to set
17671 environment variables for programs called by the driver, such as
17672 the assembler and loader. The driver passes the value of this
17673 macro to `putenv' to initialize the necessary environment
17676 -- Macro: LOCAL_INCLUDE_DIR
17677 Define this macro as a C string constant if you wish to override
17678 the standard choice of `/usr/local/include' as the default prefix
17679 to try when searching for local header files. `LOCAL_INCLUDE_DIR'
17680 comes before `SYSTEM_INCLUDE_DIR' in the search order.
17682 Cross compilers do not search either `/usr/local/include' or its
17685 -- Macro: MODIFY_TARGET_NAME
17686 Define this macro if you wish to define command-line switches that
17687 modify the default target name.
17689 For each switch, you can include a string to be appended to the
17690 first part of the configuration name or a string to be deleted
17691 from the configuration name, if present. The definition should be
17692 an initializer for an array of structures. Each array element
17693 should have three elements: the switch name (a string constant,
17694 including the initial dash), one of the enumeration codes `ADD' or
17695 `DELETE' to indicate whether the string should be inserted or
17696 deleted, and the string to be inserted or deleted (a string
17699 For example, on a machine where `64' at the end of the
17700 configuration name denotes a 64-bit target and you want the `-32'
17701 and `-64' switches to select between 32- and 64-bit targets, you
17704 #define MODIFY_TARGET_NAME \
17705 { { "-32", DELETE, "64"}, \
17706 {"-64", ADD, "64"}}
17708 -- Macro: SYSTEM_INCLUDE_DIR
17709 Define this macro as a C string constant if you wish to specify a
17710 system-specific directory to search for header files before the
17711 standard directory. `SYSTEM_INCLUDE_DIR' comes before
17712 `STANDARD_INCLUDE_DIR' in the search order.
17714 Cross compilers do not use this macro and do not search the
17715 directory specified.
17717 -- Macro: STANDARD_INCLUDE_DIR
17718 Define this macro as a C string constant if you wish to override
17719 the standard choice of `/usr/include' as the default prefix to try
17720 when searching for header files.
17722 Cross compilers ignore this macro and do not search either
17723 `/usr/include' or its replacement.
17725 -- Macro: STANDARD_INCLUDE_COMPONENT
17726 The "component" corresponding to `STANDARD_INCLUDE_DIR'. See
17727 `INCLUDE_DEFAULTS', below, for the description of components. If
17728 you do not define this macro, no component is used.
17730 -- Macro: INCLUDE_DEFAULTS
17731 Define this macro if you wish to override the entire default
17732 search path for include files. For a native compiler, the default
17733 search path usually consists of `GCC_INCLUDE_DIR',
17734 `LOCAL_INCLUDE_DIR', `SYSTEM_INCLUDE_DIR',
17735 `GPLUSPLUS_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition,
17736 `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are defined
17737 automatically by `Makefile', and specify private search areas for
17738 GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used only for C++
17741 The definition should be an initializer for an array of structures.
17742 Each array element should have four elements: the directory name (a
17743 string constant), the component name (also a string constant), a
17744 flag for C++-only directories, and a flag showing that the
17745 includes in the directory don't need to be wrapped in `extern `C''
17746 when compiling C++. Mark the end of the array with a null element.
17748 The component name denotes what GNU package the include file is
17749 part of, if any, in all uppercase letters. For example, it might
17750 be `GCC' or `BINUTILS'. If the package is part of a
17751 vendor-supplied operating system, code the component name as `0'.
17753 For example, here is the definition used for VAX/VMS:
17755 #define INCLUDE_DEFAULTS \
17757 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \
17758 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \
17759 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \
17764 Here is the order of prefixes tried for exec files:
17766 1. Any prefixes specified by the user with `-B'.
17768 2. The environment variable `GCC_EXEC_PREFIX', if any.
17770 3. The directories specified by the environment variable
17773 4. The macro `STANDARD_EXEC_PREFIX'.
17775 5. `/usr/lib/gcc/'.
17777 6. The macro `MD_EXEC_PREFIX', if any.
17779 Here is the order of prefixes tried for startfiles:
17781 1. Any prefixes specified by the user with `-B'.
17783 2. The environment variable `GCC_EXEC_PREFIX', if any.
17785 3. The directories specified by the environment variable
17786 `LIBRARY_PATH' (or port-specific name; native only, cross
17787 compilers do not use this).
17789 4. The macro `STANDARD_EXEC_PREFIX'.
17791 5. `/usr/lib/gcc/'.
17793 6. The macro `MD_EXEC_PREFIX', if any.
17795 7. The macro `MD_STARTFILE_PREFIX', if any.
17797 8. The macro `STANDARD_STARTFILE_PREFIX'.
17804 File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros
17806 14.3 Run-time Target Specification
17807 ==================================
17809 Here are run-time target specifications.
17811 -- Macro: TARGET_CPU_CPP_BUILTINS ()
17812 This function-like macro expands to a block of code that defines
17813 built-in preprocessor macros and assertions for the target cpu,
17814 using the functions `builtin_define', `builtin_define_std' and
17815 `builtin_assert'. When the front end calls this macro it provides
17816 a trailing semicolon, and since it has finished command line
17817 option processing your code can use those results freely.
17819 `builtin_assert' takes a string in the form you pass to the
17820 command-line option `-A', such as `cpu=mips', and creates the
17821 assertion. `builtin_define' takes a string in the form accepted
17822 by option `-D' and unconditionally defines the macro.
17824 `builtin_define_std' takes a string representing the name of an
17825 object-like macro. If it doesn't lie in the user's namespace,
17826 `builtin_define_std' defines it unconditionally. Otherwise, it
17827 defines a version with two leading underscores, and another version
17828 with two leading and trailing underscores, and defines the original
17829 only if an ISO standard was not requested on the command line. For
17830 example, passing `unix' defines `__unix', `__unix__' and possibly
17831 `unix'; passing `_mips' defines `__mips', `__mips__' and possibly
17832 `_mips', and passing `_ABI64' defines only `_ABI64'.
17834 You can also test for the C dialect being compiled. The variable
17835 `c_language' is set to one of `clk_c', `clk_cplusplus' or
17836 `clk_objective_c'. Note that if we are preprocessing assembler,
17837 this variable will be `clk_c' but the function-like macro
17838 `preprocessing_asm_p()' will return true, so you might want to
17839 check for that first. If you need to check for strict ANSI, the
17840 variable `flag_iso' can be used. The function-like macro
17841 `preprocessing_trad_p()' can be used to check for traditional
17844 -- Macro: TARGET_OS_CPP_BUILTINS ()
17845 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional
17846 and is used for the target operating system instead.
17848 -- Macro: TARGET_OBJFMT_CPP_BUILTINS ()
17849 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional
17850 and is used for the target object format. `elfos.h' uses this
17851 macro to define `__ELF__', so you probably do not need to define
17854 -- Variable: extern int target_flags
17855 This variable is declared in `options.h', which is included before
17856 any target-specific headers.
17858 -- Variable: Target Hook int TARGET_DEFAULT_TARGET_FLAGS
17859 This variable specifies the initial value of `target_flags'. Its
17860 default setting is 0.
17862 -- Target Hook: bool TARGET_HANDLE_OPTION (size_t CODE, const char
17864 This hook is called whenever the user specifies one of the
17865 target-specific options described by the `.opt' definition files
17866 (*note Options::). It has the opportunity to do some
17867 option-specific processing and should return true if the option is
17868 valid. The default definition does nothing but return true.
17870 CODE specifies the `OPT_NAME' enumeration value associated with
17871 the selected option; NAME is just a rendering of the option name
17872 in which non-alphanumeric characters are replaced by underscores.
17873 ARG specifies the string argument and is null if no argument was
17874 given. If the option is flagged as a `UInteger' (*note Option
17875 properties::), VALUE is the numeric value of the argument.
17876 Otherwise VALUE is 1 if the positive form of the option was used
17877 and 0 if the "no-" form was.
17879 -- Macro: TARGET_VERSION
17880 This macro is a C statement to print on `stderr' a string
17881 describing the particular machine description choice. Every
17882 machine description should define `TARGET_VERSION'. For example:
17885 #define TARGET_VERSION \
17886 fprintf (stderr, " (68k, Motorola syntax)");
17888 #define TARGET_VERSION \
17889 fprintf (stderr, " (68k, MIT syntax)");
17892 -- Macro: OVERRIDE_OPTIONS
17893 Sometimes certain combinations of command options do not make
17894 sense on a particular target machine. You can define a macro
17895 `OVERRIDE_OPTIONS' to take account of this. This macro, if
17896 defined, is executed once just after all the command options have
17899 Don't use this macro to turn on various extra optimizations for
17900 `-O'. That is what `OPTIMIZATION_OPTIONS' is for.
17902 -- Macro: OPTIMIZATION_OPTIONS (LEVEL, SIZE)
17903 Some machines may desire to change what optimizations are
17904 performed for various optimization levels. This macro, if
17905 defined, is executed once just after the optimization level is
17906 determined and before the remainder of the command options have
17907 been parsed. Values set in this macro are used as the default
17908 values for the other command line options.
17910 LEVEL is the optimization level specified; 2 if `-O2' is
17911 specified, 1 if `-O' is specified, and 0 if neither is specified.
17913 SIZE is nonzero if `-Os' is specified and zero otherwise.
17915 You should not use this macro to change options that are not
17916 machine-specific. These should uniformly selected by the same
17917 optimization level on all supported machines. Use this macro to
17918 enable machine-specific optimizations.
17920 *Do not examine `write_symbols' in this macro!* The debugging
17921 options are not supposed to alter the generated code.
17923 -- Macro: CAN_DEBUG_WITHOUT_FP
17924 Define this macro if debugging can be performed even without a
17925 frame pointer. If this macro is defined, GCC will turn on the
17926 `-fomit-frame-pointer' option whenever `-O' is specified.
17929 File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros
17931 14.4 Defining data structures for per-function information.
17932 ===========================================================
17934 If the target needs to store information on a per-function basis, GCC
17935 provides a macro and a couple of variables to allow this. Note, just
17936 using statics to store the information is a bad idea, since GCC supports
17937 nested functions, so you can be halfway through encoding one function
17938 when another one comes along.
17940 GCC defines a data structure called `struct function' which contains
17941 all of the data specific to an individual function. This structure
17942 contains a field called `machine' whose type is `struct
17943 machine_function *', which can be used by targets to point to their own
17946 If a target needs per-function specific data it should define the type
17947 `struct machine_function' and also the macro `INIT_EXPANDERS'. This
17948 macro should be used to initialize the function pointer
17949 `init_machine_status'. This pointer is explained below.
17951 One typical use of per-function, target specific data is to create an
17952 RTX to hold the register containing the function's return address. This
17953 RTX can then be used to implement the `__builtin_return_address'
17954 function, for level 0.
17956 Note--earlier implementations of GCC used a single data area to hold
17957 all of the per-function information. Thus when processing of a nested
17958 function began the old per-function data had to be pushed onto a stack,
17959 and when the processing was finished, it had to be popped off the
17960 stack. GCC used to provide function pointers called
17961 `save_machine_status' and `restore_machine_status' to handle the saving
17962 and restoring of the target specific information. Since the single
17963 data area approach is no longer used, these pointers are no longer
17966 -- Macro: INIT_EXPANDERS
17967 Macro called to initialize any target specific information. This
17968 macro is called once per function, before generation of any RTL
17969 has begun. The intention of this macro is to allow the
17970 initialization of the function pointer `init_machine_status'.
17972 -- Variable: void (*)(struct function *) init_machine_status
17973 If this function pointer is non-`NULL' it will be called once per
17974 function, before function compilation starts, in order to allow the
17975 target to perform any target specific initialization of the
17976 `struct function' structure. It is intended that this would be
17977 used to initialize the `machine' of that structure.
17979 `struct machine_function' structures are expected to be freed by
17980 GC. Generally, any memory that they reference must be allocated
17981 by using `ggc_alloc', including the structure itself.
17984 File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros
17986 14.5 Storage Layout
17987 ===================
17989 Note that the definitions of the macros in this table which are sizes or
17990 alignments measured in bits do not need to be constant. They can be C
17991 expressions that refer to static variables, such as the `target_flags'.
17992 *Note Run-time Target::.
17994 -- Macro: BITS_BIG_ENDIAN
17995 Define this macro to have the value 1 if the most significant bit
17996 in a byte has the lowest number; otherwise define it to have the
17997 value zero. This means that bit-field instructions count from the
17998 most significant bit. If the machine has no bit-field
17999 instructions, then this must still be defined, but it doesn't
18000 matter which value it is defined to. This macro need not be a
18003 This macro does not affect the way structure fields are packed into
18004 bytes or words; that is controlled by `BYTES_BIG_ENDIAN'.
18006 -- Macro: BYTES_BIG_ENDIAN
18007 Define this macro to have the value 1 if the most significant byte
18008 in a word has the lowest number. This macro need not be a
18011 -- Macro: WORDS_BIG_ENDIAN
18012 Define this macro to have the value 1 if, in a multiword object,
18013 the most significant word has the lowest number. This applies to
18014 both memory locations and registers; GCC fundamentally assumes
18015 that the order of words in memory is the same as the order in
18016 registers. This macro need not be a constant.
18018 -- Macro: LIBGCC2_WORDS_BIG_ENDIAN
18019 Define this macro if `WORDS_BIG_ENDIAN' is not constant. This
18020 must be a constant value with the same meaning as
18021 `WORDS_BIG_ENDIAN', which will be used only when compiling
18022 `libgcc2.c'. Typically the value will be set based on
18023 preprocessor defines.
18025 -- Macro: FLOAT_WORDS_BIG_ENDIAN
18026 Define this macro to have the value 1 if `DFmode', `XFmode' or
18027 `TFmode' floating point numbers are stored in memory with the word
18028 containing the sign bit at the lowest address; otherwise define it
18029 to have the value 0. This macro need not be a constant.
18031 You need not define this macro if the ordering is the same as for
18032 multi-word integers.
18034 -- Macro: BITS_PER_UNIT
18035 Define this macro to be the number of bits in an addressable
18036 storage unit (byte). If you do not define this macro the default
18039 -- Macro: BITS_PER_WORD
18040 Number of bits in a word. If you do not define this macro, the
18041 default is `BITS_PER_UNIT * UNITS_PER_WORD'.
18043 -- Macro: MAX_BITS_PER_WORD
18044 Maximum number of bits in a word. If this is undefined, the
18045 default is `BITS_PER_WORD'. Otherwise, it is the constant value
18046 that is the largest value that `BITS_PER_WORD' can have at
18049 -- Macro: UNITS_PER_WORD
18050 Number of storage units in a word; normally the size of a
18051 general-purpose register, a power of two from 1 or 8.
18053 -- Macro: MIN_UNITS_PER_WORD
18054 Minimum number of units in a word. If this is undefined, the
18055 default is `UNITS_PER_WORD'. Otherwise, it is the constant value
18056 that is the smallest value that `UNITS_PER_WORD' can have at
18059 -- Macro: UNITS_PER_SIMD_WORD
18060 Number of units in the vectors that the vectorizer can produce.
18061 The default is equal to `UNITS_PER_WORD', because the vectorizer
18062 can do some transformations even in absence of specialized SIMD
18065 -- Macro: POINTER_SIZE
18066 Width of a pointer, in bits. You must specify a value no wider
18067 than the width of `Pmode'. If it is not equal to the width of
18068 `Pmode', you must define `POINTERS_EXTEND_UNSIGNED'. If you do
18069 not specify a value the default is `BITS_PER_WORD'.
18071 -- Macro: POINTERS_EXTEND_UNSIGNED
18072 A C expression whose value is greater than zero if pointers that
18073 need to be extended from being `POINTER_SIZE' bits wide to `Pmode'
18074 are to be zero-extended and zero if they are to be sign-extended.
18075 If the value is less then zero then there must be an "ptr_extend"
18076 instruction that extends a pointer from `POINTER_SIZE' to `Pmode'.
18078 You need not define this macro if the `POINTER_SIZE' is equal to
18079 the width of `Pmode'.
18081 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE)
18082 A macro to update M and UNSIGNEDP when an object whose type is
18083 TYPE and which has the specified mode and signedness is to be
18084 stored in a register. This macro is only called when TYPE is a
18087 On most RISC machines, which only have operations that operate on
18088 a full register, define this macro to set M to `word_mode' if M is
18089 an integer mode narrower than `BITS_PER_WORD'. In most cases,
18090 only integer modes should be widened because wider-precision
18091 floating-point operations are usually more expensive than their
18092 narrower counterparts.
18094 For most machines, the macro definition does not change UNSIGNEDP.
18095 However, some machines, have instructions that preferentially
18096 handle either signed or unsigned quantities of certain modes. For
18097 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add
18098 instructions sign-extend the result to 64 bits. On such machines,
18099 set UNSIGNEDP according to which kind of extension is more
18102 Do not define this macro if it would never modify M.
18104 -- Macro: PROMOTE_FUNCTION_MODE
18105 Like `PROMOTE_MODE', but is applied to outgoing function arguments
18106 or function return values, as specified by
18107 `TARGET_PROMOTE_FUNCTION_ARGS' and
18108 `TARGET_PROMOTE_FUNCTION_RETURN', respectively.
18110 The default is `PROMOTE_MODE'.
18112 -- Target Hook: bool TARGET_PROMOTE_FUNCTION_ARGS (tree FNTYPE)
18113 This target hook should return `true' if the promotion described by
18114 `PROMOTE_FUNCTION_MODE' should be done for outgoing function
18117 -- Target Hook: bool TARGET_PROMOTE_FUNCTION_RETURN (tree FNTYPE)
18118 This target hook should return `true' if the promotion described by
18119 `PROMOTE_FUNCTION_MODE' should be done for the return value of
18122 If this target hook returns `true', `FUNCTION_VALUE' must perform
18123 the same promotions done by `PROMOTE_FUNCTION_MODE'.
18125 -- Macro: PARM_BOUNDARY
18126 Normal alignment required for function parameters on the stack, in
18127 bits. All stack parameters receive at least this much alignment
18128 regardless of data type. On most machines, this is the same as the
18129 size of an integer.
18131 -- Macro: STACK_BOUNDARY
18132 Define this macro to the minimum alignment enforced by hardware
18133 for the stack pointer on this machine. The definition is a C
18134 expression for the desired alignment (measured in bits). This
18135 value is used as a default if `PREFERRED_STACK_BOUNDARY' is not
18136 defined. On most machines, this should be the same as
18139 -- Macro: PREFERRED_STACK_BOUNDARY
18140 Define this macro if you wish to preserve a certain alignment for
18141 the stack pointer, greater than what the hardware enforces. The
18142 definition is a C expression for the desired alignment (measured
18143 in bits). This macro must evaluate to a value equal to or larger
18144 than `STACK_BOUNDARY'.
18146 -- Macro: FUNCTION_BOUNDARY
18147 Alignment required for a function entry point, in bits.
18149 -- Macro: BIGGEST_ALIGNMENT
18150 Biggest alignment that any data type can require on this machine,
18153 -- Macro: MINIMUM_ATOMIC_ALIGNMENT
18154 If defined, the smallest alignment, in bits, that can be given to
18155 an object that can be referenced in one operation, without
18156 disturbing any nearby object. Normally, this is `BITS_PER_UNIT',
18157 but may be larger on machines that don't have byte or half-word
18160 -- Macro: BIGGEST_FIELD_ALIGNMENT
18161 Biggest alignment that any structure or union field can require on
18162 this machine, in bits. If defined, this overrides
18163 `BIGGEST_ALIGNMENT' for structure and union fields only, unless
18164 the field alignment has been set by the `__attribute__ ((aligned
18167 -- Macro: ADJUST_FIELD_ALIGN (FIELD, COMPUTED)
18168 An expression for the alignment of a structure field FIELD if the
18169 alignment computed in the usual way (including applying of
18170 `BIGGEST_ALIGNMENT' and `BIGGEST_FIELD_ALIGNMENT' to the
18171 alignment) is COMPUTED. It overrides alignment only if the field
18172 alignment has not been set by the `__attribute__ ((aligned (N)))'
18175 -- Macro: MAX_OFILE_ALIGNMENT
18176 Biggest alignment supported by the object file format of this
18177 machine. Use this macro to limit the alignment which can be
18178 specified using the `__attribute__ ((aligned (N)))' construct. If
18179 not defined, the default value is `BIGGEST_ALIGNMENT'.
18181 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN)
18182 If defined, a C expression to compute the alignment for a variable
18183 in the static store. TYPE is the data type, and BASIC-ALIGN is
18184 the alignment that the object would ordinarily have. The value of
18185 this macro is used instead of that alignment to align the object.
18187 If this macro is not defined, then BASIC-ALIGN is used.
18189 One use of this macro is to increase alignment of medium-size data
18190 to make it all fit in fewer cache lines. Another is to cause
18191 character arrays to be word-aligned so that `strcpy' calls that
18192 copy constants to character arrays can be done inline.
18194 -- Macro: CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN)
18195 If defined, a C expression to compute the alignment given to a
18196 constant that is being placed in memory. CONSTANT is the constant
18197 and BASIC-ALIGN is the alignment that the object would ordinarily
18198 have. The value of this macro is used instead of that alignment to
18201 If this macro is not defined, then BASIC-ALIGN is used.
18203 The typical use of this macro is to increase alignment for string
18204 constants to be word aligned so that `strcpy' calls that copy
18205 constants can be done inline.
18207 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN)
18208 If defined, a C expression to compute the alignment for a variable
18209 in the local store. TYPE is the data type, and BASIC-ALIGN is the
18210 alignment that the object would ordinarily have. The value of this
18211 macro is used instead of that alignment to align the object.
18213 If this macro is not defined, then BASIC-ALIGN is used.
18215 One use of this macro is to increase alignment of medium-size data
18216 to make it all fit in fewer cache lines.
18218 -- Macro: EMPTY_FIELD_BOUNDARY
18219 Alignment in bits to be given to a structure bit-field that
18220 follows an empty field such as `int : 0;'.
18222 If `PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro.
18224 -- Macro: STRUCTURE_SIZE_BOUNDARY
18225 Number of bits which any structure or union's size must be a
18226 multiple of. Each structure or union's size is rounded up to a
18229 If you do not define this macro, the default is the same as
18232 -- Macro: STRICT_ALIGNMENT
18233 Define this macro to be the value 1 if instructions will fail to
18234 work if given data not on the nominal alignment. If instructions
18235 will merely go slower in that case, define this macro as 0.
18237 -- Macro: PCC_BITFIELD_TYPE_MATTERS
18238 Define this if you wish to imitate the way many other C compilers
18239 handle alignment of bit-fields and the structures that contain
18242 The behavior is that the type written for a named bit-field (`int',
18243 `short', or other integer type) imposes an alignment for the entire
18244 structure, as if the structure really did contain an ordinary
18245 field of that type. In addition, the bit-field is placed within
18246 the structure so that it would fit within such a field, not
18247 crossing a boundary for it.
18249 Thus, on most machines, a named bit-field whose type is written as
18250 `int' would not cross a four-byte boundary, and would force
18251 four-byte alignment for the whole structure. (The alignment used
18252 may not be four bytes; it is controlled by the other alignment
18255 An unnamed bit-field will not affect the alignment of the
18256 containing structure.
18258 If the macro is defined, its definition should be a C expression;
18259 a nonzero value for the expression enables this behavior.
18261 Note that if this macro is not defined, or its value is zero, some
18262 bit-fields may cross more than one alignment boundary. The
18263 compiler can support such references if there are `insv', `extv',
18264 and `extzv' insns that can directly reference memory.
18266 The other known way of making bit-fields work is to define
18267 `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then
18268 every structure can be accessed with fullwords.
18270 Unless the machine has bit-field instructions or you define
18271 `STRUCTURE_SIZE_BOUNDARY' that way, you must define
18272 `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value.
18274 If your aim is to make GCC use the same conventions for laying out
18275 bit-fields as are used by another compiler, here is how to
18276 investigate what the other compiler does. Compile and run this
18295 printf ("Size of foo1 is %d\n",
18296 sizeof (struct foo1));
18297 printf ("Size of foo2 is %d\n",
18298 sizeof (struct foo2));
18302 If this prints 2 and 5, then the compiler's behavior is what you
18303 would get from `PCC_BITFIELD_TYPE_MATTERS'.
18305 -- Macro: BITFIELD_NBYTES_LIMITED
18306 Like `PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited
18307 to aligning a bit-field within the structure.
18309 -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELDS (void)
18310 When `PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine
18311 whether unnamed bitfields affect the alignment of the containing
18312 structure. The hook should return true if the structure should
18313 inherit the alignment requirements of an unnamed bitfield's type.
18315 -- Macro: MEMBER_TYPE_FORCES_BLK (FIELD, MODE)
18316 Return 1 if a structure or array containing FIELD should be
18317 accessed using `BLKMODE'.
18319 If FIELD is the only field in the structure, MODE is its mode,
18320 otherwise MODE is VOIDmode. MODE is provided in the case where
18321 structures of one field would require the structure's mode to
18322 retain the field's mode.
18324 Normally, this is not needed. See the file `c4x.h' for an example
18325 of how to use this macro to prevent a structure having a floating
18326 point field from being accessed in an integer mode.
18328 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED)
18329 Define this macro as an expression for the alignment of a type
18330 (given by TYPE as a tree node) if the alignment computed in the
18331 usual way is COMPUTED and the alignment explicitly specified was
18334 The default is to use SPECIFIED if it is larger; otherwise, use
18335 the smaller of COMPUTED and `BIGGEST_ALIGNMENT'
18337 -- Macro: MAX_FIXED_MODE_SIZE
18338 An integer expression for the size in bits of the largest integer
18339 machine mode that should actually be used. All integer machine
18340 modes of this size or smaller can be used for structures and
18341 unions with the appropriate sizes. If this macro is undefined,
18342 `GET_MODE_BITSIZE (DImode)' is assumed.
18344 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL)
18345 If defined, an expression of type `enum machine_mode' that
18346 specifies the mode of the save area operand of a
18347 `save_stack_LEVEL' named pattern (*note Standard Names::).
18348 SAVE_LEVEL is one of `SAVE_BLOCK', `SAVE_FUNCTION', or
18349 `SAVE_NONLOCAL' and selects which of the three named patterns is
18350 having its mode specified.
18352 You need not define this macro if it always returns `Pmode'. You
18353 would most commonly define this macro if the `save_stack_LEVEL'
18354 patterns need to support both a 32- and a 64-bit mode.
18356 -- Macro: STACK_SIZE_MODE
18357 If defined, an expression of type `enum machine_mode' that
18358 specifies the mode of the size increment operand of an
18359 `allocate_stack' named pattern (*note Standard Names::).
18361 You need not define this macro if it always returns `word_mode'.
18362 You would most commonly define this macro if the `allocate_stack'
18363 pattern needs to support both a 32- and a 64-bit mode.
18365 -- Macro: TARGET_FLOAT_FORMAT
18366 A code distinguishing the floating point format of the target
18367 machine. There are four defined values:
18369 `IEEE_FLOAT_FORMAT'
18370 This code indicates IEEE floating point. It is the default;
18371 there is no need to define `TARGET_FLOAT_FORMAT' when the
18375 This code indicates the "F float" (for `float') and "D float"
18376 or "G float" formats (for `double') used on the VAX and
18380 This code indicates the format used on the IBM System/370.
18383 This code indicates the format used on the TMS320C3x/C4x.
18385 If your target uses a floating point format other than these, you
18386 must define a new NAME_FLOAT_FORMAT code for it, and add support
18387 for it to `real.c'.
18389 The ordering of the component words of floating point values
18390 stored in memory is controlled by `FLOAT_WORDS_BIG_ENDIAN'.
18392 -- Macro: MODE_HAS_NANS (MODE)
18393 When defined, this macro should be true if MODE has a NaN
18394 representation. The compiler assumes that NaNs are not equal to
18395 anything (including themselves) and that addition, subtraction,
18396 multiplication and division all return NaNs when one operand is
18399 By default, this macro is true if MODE is a floating-point mode
18400 and the target floating-point format is IEEE.
18402 -- Macro: MODE_HAS_INFINITIES (MODE)
18403 This macro should be true if MODE can represent infinity. At
18404 present, the compiler uses this macro to decide whether `x - x' is
18405 always defined. By default, the macro is true when MODE is a
18406 floating-point mode and the target format is IEEE.
18408 -- Macro: MODE_HAS_SIGNED_ZEROS (MODE)
18409 True if MODE distinguishes between positive and negative zero.
18410 The rules are expected to follow the IEEE standard:
18412 * `x + x' has the same sign as `x'.
18414 * If the sum of two values with opposite sign is zero, the
18415 result is positive for all rounding modes expect towards
18416 -infinity, for which it is negative.
18418 * The sign of a product or quotient is negative when exactly one
18419 of the operands is negative.
18421 The default definition is true if MODE is a floating-point mode
18422 and the target format is IEEE.
18424 -- Macro: MODE_HAS_SIGN_DEPENDENT_ROUNDING (MODE)
18425 If defined, this macro should be true for MODE if it has at least
18426 one rounding mode in which `x' and `-x' can be rounded to numbers
18427 of different magnitude. Two such modes are towards -infinity and
18430 The default definition of this macro is true if MODE is a
18431 floating-point mode and the target format is IEEE.
18433 -- Macro: ROUND_TOWARDS_ZERO
18434 If defined, this macro should be true if the prevailing rounding
18435 mode is towards zero. A true value has the following effects:
18437 * `MODE_HAS_SIGN_DEPENDENT_ROUNDING' will be false for all
18440 * `libgcc.a''s floating-point emulator will round towards zero
18441 rather than towards nearest.
18443 * The compiler's floating-point emulator will round towards
18444 zero after doing arithmetic, and when converting from the
18445 internal float format to the target format.
18447 The macro does not affect the parsing of string literals. When the
18448 primary rounding mode is towards zero, library functions like
18449 `strtod' might still round towards nearest, and the compiler's
18450 parser should behave like the target's `strtod' where possible.
18452 Not defining this macro is equivalent to returning zero.
18454 -- Macro: LARGEST_EXPONENT_IS_NORMAL (SIZE)
18455 This macro should return true if floats with SIZE bits do not have
18456 a NaN or infinity representation, but use the largest exponent for
18457 normal numbers instead.
18459 Defining this macro to true for SIZE causes `MODE_HAS_NANS' and
18460 `MODE_HAS_INFINITIES' to be false for SIZE-bit modes. It also
18461 affects the way `libgcc.a' and `real.c' emulate floating-point
18464 The default definition of this macro returns false for all sizes.
18466 -- Target Hook: bool TARGET_VECTOR_OPAQUE_P (tree TYPE)
18467 This target hook should return `true' a vector is opaque. That
18468 is, if no cast is needed when copying a vector value of type TYPE
18469 into another vector lvalue of the same size. Vector opaque types
18470 cannot be initialized. The default is that there are no such
18473 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (tree RECORD_TYPE)
18474 This target hook returns `true' if bit-fields in the given
18475 RECORD_TYPE are to be laid out following the rules of Microsoft
18476 Visual C/C++, namely: (i) a bit-field won't share the same storage
18477 unit with the previous bit-field if their underlying types have
18478 different sizes, and the bit-field will be aligned to the highest
18479 alignment of the underlying types of itself and of the previous
18480 bit-field; (ii) a zero-sized bit-field will affect the alignment of
18481 the whole enclosing structure, even if it is unnamed; except that
18482 (iii) a zero-sized bit-field will be disregarded unless it follows
18483 another bit-field of nonzero size. If this hook returns `true',
18484 other macros that control bit-field layout are ignored.
18486 When a bit-field is inserted into a packed record, the whole size
18487 of the underlying type is used by one or more same-size adjacent
18488 bit-fields (that is, if its long:3, 32 bits is used in the record,
18489 and any additional adjacent long bit-fields are packed into the
18490 same chunk of 32 bits. However, if the size changes, a new field
18491 of that size is allocated). In an unpacked record, this is the
18492 same as using alignment, but not equivalent when packing.
18494 If both MS bit-fields and `__attribute__((packed))' are used, the
18495 latter will take precedence. If `__attribute__((packed))' is used
18496 on a single field when MS bit-fields are in use, it will take
18497 precedence for that field, but the alignment of the rest of the
18498 structure may affect its placement.
18500 -- Target Hook: const char * TARGET_MANGLE_FUNDAMENTAL_TYPE (tree TYPE)
18501 If your target defines any fundamental types, define this hook to
18502 return the appropriate encoding for these types as part of a C++
18503 mangled name. The TYPE argument is the tree structure
18504 representing the type to be mangled. The hook may be applied to
18505 trees which are not target-specific fundamental types; it should
18506 return `NULL' for all such types, as well as arguments it does not
18507 recognize. If the return value is not `NULL', it must point to a
18508 statically-allocated string constant.
18510 Target-specific fundamental types might be new fundamental types or
18511 qualified versions of ordinary fundamental types. Encode new
18512 fundamental types as `u N NAME', where NAME is the name used for
18513 the type in source code, and N is the length of NAME in decimal.
18514 Encode qualified versions of ordinary types as `U N NAME CODE',
18515 where NAME is the name used for the type qualifier in source code,
18516 N is the length of NAME as above, and CODE is the code used to
18517 represent the unqualified version of this type. (See
18518 `write_builtin_type' in `cp/mangle.c' for the list of codes.) In
18519 both cases the spaces are for clarity; do not include any spaces
18522 The default version of this hook always returns `NULL', which is
18523 appropriate for a target that does not define any new fundamental
18527 File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros
18529 14.6 Layout of Source Language Data Types
18530 =========================================
18532 These macros define the sizes and other characteristics of the standard
18533 basic data types used in programs being compiled. Unlike the macros in
18534 the previous section, these apply to specific features of C and related
18535 languages, rather than to fundamental aspects of storage layout.
18537 -- Macro: INT_TYPE_SIZE
18538 A C expression for the size in bits of the type `int' on the
18539 target machine. If you don't define this, the default is one word.
18541 -- Macro: SHORT_TYPE_SIZE
18542 A C expression for the size in bits of the type `short' on the
18543 target machine. If you don't define this, the default is half a
18544 word. (If this would be less than one storage unit, it is rounded
18547 -- Macro: LONG_TYPE_SIZE
18548 A C expression for the size in bits of the type `long' on the
18549 target machine. If you don't define this, the default is one word.
18551 -- Macro: ADA_LONG_TYPE_SIZE
18552 On some machines, the size used for the Ada equivalent of the type
18553 `long' by a native Ada compiler differs from that used by C. In
18554 that situation, define this macro to be a C expression to be used
18555 for the size of that type. If you don't define this, the default
18556 is the value of `LONG_TYPE_SIZE'.
18558 -- Macro: LONG_LONG_TYPE_SIZE
18559 A C expression for the size in bits of the type `long long' on the
18560 target machine. If you don't define this, the default is two
18561 words. If you want to support GNU Ada on your machine, the value
18562 of this macro must be at least 64.
18564 -- Macro: CHAR_TYPE_SIZE
18565 A C expression for the size in bits of the type `char' on the
18566 target machine. If you don't define this, the default is
18569 -- Macro: BOOL_TYPE_SIZE
18570 A C expression for the size in bits of the C++ type `bool' and C99
18571 type `_Bool' on the target machine. If you don't define this, and
18572 you probably shouldn't, the default is `CHAR_TYPE_SIZE'.
18574 -- Macro: FLOAT_TYPE_SIZE
18575 A C expression for the size in bits of the type `float' on the
18576 target machine. If you don't define this, the default is one word.
18578 -- Macro: DOUBLE_TYPE_SIZE
18579 A C expression for the size in bits of the type `double' on the
18580 target machine. If you don't define this, the default is two
18583 -- Macro: LONG_DOUBLE_TYPE_SIZE
18584 A C expression for the size in bits of the type `long double' on
18585 the target machine. If you don't define this, the default is two
18588 -- Macro: LIBGCC2_LONG_DOUBLE_TYPE_SIZE
18589 Define this macro if `LONG_DOUBLE_TYPE_SIZE' is not constant or if
18590 you want routines in `libgcc2.a' for a size other than
18591 `LONG_DOUBLE_TYPE_SIZE'. If you don't define this, the default is
18592 `LONG_DOUBLE_TYPE_SIZE'.
18594 -- Macro: LIBGCC2_HAS_DF_MODE
18595 Define this macro if neither `LIBGCC2_DOUBLE_TYPE_SIZE' nor
18596 `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is `DFmode' but you want `DFmode'
18597 routines in `libgcc2.a' anyway. If you don't define this and
18598 either `LIBGCC2_DOUBLE_TYPE_SIZE' or
18599 `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 64 then the default is 1,
18602 -- Macro: LIBGCC2_HAS_XF_MODE
18603 Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not
18604 `XFmode' but you want `XFmode' routines in `libgcc2.a' anyway. If
18605 you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 80
18606 then the default is 1, otherwise it is 0.
18608 -- Macro: LIBGCC2_HAS_TF_MODE
18609 Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not
18610 `TFmode' but you want `TFmode' routines in `libgcc2.a' anyway. If
18611 you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 128
18612 then the default is 1, otherwise it is 0.
18614 -- Macro: TARGET_FLT_EVAL_METHOD
18615 A C expression for the value for `FLT_EVAL_METHOD' in `float.h',
18616 assuming, if applicable, that the floating-point control word is
18617 in its default state. If you do not define this macro the value of
18618 `FLT_EVAL_METHOD' will be zero.
18620 -- Macro: WIDEST_HARDWARE_FP_SIZE
18621 A C expression for the size in bits of the widest floating-point
18622 format supported by the hardware. If you define this macro, you
18623 must specify a value less than or equal to the value of
18624 `LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the
18625 value of `LONG_DOUBLE_TYPE_SIZE' is the default.
18627 -- Macro: DEFAULT_SIGNED_CHAR
18628 An expression whose value is 1 or 0, according to whether the type
18629 `char' should be signed or unsigned by default. The user can
18630 always override this default with the options `-fsigned-char' and
18633 -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void)
18634 This target hook should return true if the compiler should give an
18635 `enum' type only as many bytes as it takes to represent the range
18636 of possible values of that type. It should return false if all
18637 `enum' types should be allocated like `int'.
18639 The default is to return false.
18641 -- Macro: SIZE_TYPE
18642 A C expression for a string describing the name of the data type
18643 to use for size values. The typedef name `size_t' is defined
18644 using the contents of the string.
18646 The string can contain more than one keyword. If so, separate
18647 them with spaces, and write first any length keyword, then
18648 `unsigned' if appropriate, and finally `int'. The string must
18649 exactly match one of the data type names defined in the function
18650 `init_decl_processing' in the file `c-decl.c'. You may not omit
18651 `int' or change the order--that would cause the compiler to crash
18654 If you don't define this macro, the default is `"long unsigned
18657 -- Macro: PTRDIFF_TYPE
18658 A C expression for a string describing the name of the data type
18659 to use for the result of subtracting two pointers. The typedef
18660 name `ptrdiff_t' is defined using the contents of the string. See
18661 `SIZE_TYPE' above for more information.
18663 If you don't define this macro, the default is `"long int"'.
18665 -- Macro: WCHAR_TYPE
18666 A C expression for a string describing the name of the data type
18667 to use for wide characters. The typedef name `wchar_t' is defined
18668 using the contents of the string. See `SIZE_TYPE' above for more
18671 If you don't define this macro, the default is `"int"'.
18673 -- Macro: WCHAR_TYPE_SIZE
18674 A C expression for the size in bits of the data type for wide
18675 characters. This is used in `cpp', which cannot make use of
18678 -- Macro: WINT_TYPE
18679 A C expression for a string describing the name of the data type to
18680 use for wide characters passed to `printf' and returned from
18681 `getwc'. The typedef name `wint_t' is defined using the contents
18682 of the string. See `SIZE_TYPE' above for more information.
18684 If you don't define this macro, the default is `"unsigned int"'.
18686 -- Macro: INTMAX_TYPE
18687 A C expression for a string describing the name of the data type
18688 that can represent any value of any standard or extended signed
18689 integer type. The typedef name `intmax_t' is defined using the
18690 contents of the string. See `SIZE_TYPE' above for more
18693 If you don't define this macro, the default is the first of
18694 `"int"', `"long int"', or `"long long int"' that has as much
18695 precision as `long long int'.
18697 -- Macro: UINTMAX_TYPE
18698 A C expression for a string describing the name of the data type
18699 that can represent any value of any standard or extended unsigned
18700 integer type. The typedef name `uintmax_t' is defined using the
18701 contents of the string. See `SIZE_TYPE' above for more
18704 If you don't define this macro, the default is the first of
18705 `"unsigned int"', `"long unsigned int"', or `"long long unsigned
18706 int"' that has as much precision as `long long unsigned int'.
18708 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION
18709 The C++ compiler represents a pointer-to-member-function with a
18710 struct that looks like:
18715 ptrdiff_t vtable_index;
18720 The C++ compiler must use one bit to indicate whether the function
18721 that will be called through a pointer-to-member-function is
18722 virtual. Normally, we assume that the low-order bit of a function
18723 pointer must always be zero. Then, by ensuring that the
18724 vtable_index is odd, we can distinguish which variant of the union
18725 is in use. But, on some platforms function pointers can be odd,
18726 and so this doesn't work. In that case, we use the low-order bit
18727 of the `delta' field, and shift the remainder of the `delta' field
18730 GCC will automatically make the right selection about where to
18731 store this bit using the `FUNCTION_BOUNDARY' setting for your
18732 platform. However, some platforms such as ARM/Thumb have
18733 `FUNCTION_BOUNDARY' set such that functions always start at even
18734 addresses, but the lowest bit of pointers to functions indicate
18735 whether the function at that address is in ARM or Thumb mode. If
18736 this is the case of your architecture, you should define this
18737 macro to `ptrmemfunc_vbit_in_delta'.
18739 In general, you should not have to define this macro. On
18740 architectures in which function addresses are always even,
18741 according to `FUNCTION_BOUNDARY', GCC will automatically define
18742 this macro to `ptrmemfunc_vbit_in_pfn'.
18744 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS
18745 Normally, the C++ compiler uses function pointers in vtables. This
18746 macro allows the target to change to use "function descriptors"
18747 instead. Function descriptors are found on targets for whom a
18748 function pointer is actually a small data structure. Normally the
18749 data structure consists of the actual code address plus a data
18750 pointer to which the function's data is relative.
18752 If vtables are used, the value of this macro should be the number
18753 of words that the function descriptor occupies.
18755 -- Macro: TARGET_VTABLE_ENTRY_ALIGN
18756 By default, the vtable entries are void pointers, the so the
18757 alignment is the same as pointer alignment. The value of this
18758 macro specifies the alignment of the vtable entry in bits. It
18759 should be defined only when special alignment is necessary. */
18761 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE
18762 There are a few non-descriptor entries in the vtable at offsets
18763 below zero. If these entries must be padded (say, to preserve the
18764 alignment specified by `TARGET_VTABLE_ENTRY_ALIGN'), set this to
18765 the number of words in each data entry.
18768 File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros
18770 14.7 Register Usage
18771 ===================
18773 This section explains how to describe what registers the target machine
18774 has, and how (in general) they can be used.
18776 The description of which registers a specific instruction can use is
18777 done with register classes; see *Note Register Classes::. For
18778 information on using registers to access a stack frame, see *Note Frame
18779 Registers::. For passing values in registers, see *Note Register
18780 Arguments::. For returning values in registers, see *Note Scalar
18785 * Register Basics:: Number and kinds of registers.
18786 * Allocation Order:: Order in which registers are allocated.
18787 * Values in Registers:: What kinds of values each reg can hold.
18788 * Leaf Functions:: Renumbering registers for leaf functions.
18789 * Stack Registers:: Handling a register stack such as 80387.
18792 File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers
18794 14.7.1 Basic Characteristics of Registers
18795 -----------------------------------------
18797 Registers have various characteristics.
18799 -- Macro: FIRST_PSEUDO_REGISTER
18800 Number of hardware registers known to the compiler. They receive
18801 numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first
18802 pseudo register's number really is assigned the number
18803 `FIRST_PSEUDO_REGISTER'.
18805 -- Macro: FIXED_REGISTERS
18806 An initializer that says which registers are used for fixed
18807 purposes all throughout the compiled code and are therefore not
18808 available for general allocation. These would include the stack
18809 pointer, the frame pointer (except on machines where that can be
18810 used as a general register when no frame pointer is needed), the
18811 program counter on machines where that is considered one of the
18812 addressable registers, and any other numbered register with a
18815 This information is expressed as a sequence of numbers, separated
18816 by commas and surrounded by braces. The Nth number is 1 if
18817 register N is fixed, 0 otherwise.
18819 The table initialized from this macro, and the table initialized by
18820 the following one, may be overridden at run time either
18821 automatically, by the actions of the macro
18822 `CONDITIONAL_REGISTER_USAGE', or by the user with the command
18823 options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'.
18825 -- Macro: CALL_USED_REGISTERS
18826 Like `FIXED_REGISTERS' but has 1 for each register that is
18827 clobbered (in general) by function calls as well as for fixed
18828 registers. This macro therefore identifies the registers that are
18829 not available for general allocation of values that must live
18830 across function calls.
18832 If a register has 0 in `CALL_USED_REGISTERS', the compiler
18833 automatically saves it on function entry and restores it on
18834 function exit, if the register is used within the function.
18836 -- Macro: CALL_REALLY_USED_REGISTERS
18837 Like `CALL_USED_REGISTERS' except this macro doesn't require that
18838 the entire set of `FIXED_REGISTERS' be included.
18839 (`CALL_USED_REGISTERS' must be a superset of `FIXED_REGISTERS').
18840 This macro is optional. If not specified, it defaults to the value
18841 of `CALL_USED_REGISTERS'.
18843 -- Macro: HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE)
18844 A C expression that is nonzero if it is not permissible to store a
18845 value of mode MODE in hard register number REGNO across a call
18846 without some part of it being clobbered. For most machines this
18847 macro need not be defined. It is only required for machines that
18848 do not preserve the entire contents of a register across a call.
18850 -- Macro: CONDITIONAL_REGISTER_USAGE
18851 Zero or more C statements that may conditionally modify five
18852 variables `fixed_regs', `call_used_regs', `global_regs',
18853 `reg_names', and `reg_class_contents', to take into account any
18854 dependence of these register sets on target flags. The first three
18855 of these are of type `char []' (interpreted as Boolean vectors).
18856 `global_regs' is a `const char *[]', and `reg_class_contents' is a
18857 `HARD_REG_SET'. Before the macro is called, `fixed_regs',
18858 `call_used_regs', `reg_class_contents', and `reg_names' have been
18859 initialized from `FIXED_REGISTERS', `CALL_USED_REGISTERS',
18860 `REG_CLASS_CONTENTS', and `REGISTER_NAMES', respectively.
18861 `global_regs' has been cleared, and any `-ffixed-REG',
18862 `-fcall-used-REG' and `-fcall-saved-REG' command options have been
18865 You need not define this macro if it has no work to do.
18867 If the usage of an entire class of registers depends on the target
18868 flags, you may indicate this to GCC by using this macro to modify
18869 `fixed_regs' and `call_used_regs' to 1 for each of the registers
18870 in the classes which should not be used by GCC. Also define the
18871 macro `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' to
18872 return `NO_REGS' if it is called with a letter for a class that
18875 (However, if this class is not included in `GENERAL_REGS' and all
18876 of the insn patterns whose constraints permit this class are
18877 controlled by target switches, then GCC will automatically avoid
18878 using these registers when the target switches are opposed to
18881 -- Macro: INCOMING_REGNO (OUT)
18882 Define this macro if the target machine has register windows.
18883 This C expression returns the register number as seen by the
18884 called function corresponding to the register number OUT as seen
18885 by the calling function. Return OUT if register number OUT is not
18886 an outbound register.
18888 -- Macro: OUTGOING_REGNO (IN)
18889 Define this macro if the target machine has register windows.
18890 This C expression returns the register number as seen by the
18891 calling function corresponding to the register number IN as seen
18892 by the called function. Return IN if register number IN is not an
18895 -- Macro: LOCAL_REGNO (REGNO)
18896 Define this macro if the target machine has register windows.
18897 This C expression returns true if the register is call-saved but
18898 is in the register window. Unlike most call-saved registers, such
18899 registers need not be explicitly restored on function exit or
18900 during non-local gotos.
18902 -- Macro: PC_REGNUM
18903 If the program counter has a register number, define this as that
18904 register number. Otherwise, do not define it.
18907 File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers
18909 14.7.2 Order of Allocation of Registers
18910 ---------------------------------------
18912 Registers are allocated in order.
18914 -- Macro: REG_ALLOC_ORDER
18915 If defined, an initializer for a vector of integers, containing the
18916 numbers of hard registers in the order in which GCC should prefer
18917 to use them (from most preferred to least).
18919 If this macro is not defined, registers are used lowest numbered
18920 first (all else being equal).
18922 One use of this macro is on machines where the highest numbered
18923 registers must always be saved and the save-multiple-registers
18924 instruction supports only sequences of consecutive registers. On
18925 such machines, define `REG_ALLOC_ORDER' to be an initializer that
18926 lists the highest numbered allocable register first.
18928 -- Macro: ORDER_REGS_FOR_LOCAL_ALLOC
18929 A C statement (sans semicolon) to choose the order in which to
18930 allocate hard registers for pseudo-registers local to a basic
18933 Store the desired register order in the array `reg_alloc_order'.
18934 Element 0 should be the register to allocate first; element 1, the
18935 next register; and so on.
18937 The macro body should not assume anything about the contents of
18938 `reg_alloc_order' before execution of the macro.
18940 On most machines, it is not necessary to define this macro.
18943 File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers
18945 14.7.3 How Values Fit in Registers
18946 ----------------------------------
18948 This section discusses the macros that describe which kinds of values
18949 (specifically, which machine modes) each register can hold, and how many
18950 consecutive registers are needed for a given mode.
18952 -- Macro: HARD_REGNO_NREGS (REGNO, MODE)
18953 A C expression for the number of consecutive hard registers,
18954 starting at register number REGNO, required to hold a value of mode
18957 On a machine where all registers are exactly one word, a suitable
18958 definition of this macro is
18960 #define HARD_REGNO_NREGS(REGNO, MODE) \
18961 ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
18964 -- Macro: REGMODE_NATURAL_SIZE (MODE)
18965 Define this macro if the natural size of registers that hold values
18966 of mode MODE is not the word size. It is a C expression that
18967 should give the natural size in bytes for the specified mode. It
18968 is used by the register allocator to try to optimize its results.
18969 This happens for example on SPARC 64-bit where the natural size of
18970 floating-point registers is still 32-bit.
18972 -- Macro: HARD_REGNO_MODE_OK (REGNO, MODE)
18973 A C expression that is nonzero if it is permissible to store a
18974 value of mode MODE in hard register number REGNO (or in several
18975 registers starting with that one). For a machine where all
18976 registers are equivalent, a suitable definition is
18978 #define HARD_REGNO_MODE_OK(REGNO, MODE) 1
18980 You need not include code to check for the numbers of fixed
18981 registers, because the allocation mechanism considers them to be
18984 On some machines, double-precision values must be kept in even/odd
18985 register pairs. You can implement that by defining this macro to
18986 reject odd register numbers for such modes.
18988 The minimum requirement for a mode to be OK in a register is that
18989 the `movMODE' instruction pattern support moves between the
18990 register and other hard register in the same class and that moving
18991 a value into the register and back out not alter it.
18993 Since the same instruction used to move `word_mode' will work for
18994 all narrower integer modes, it is not necessary on any machine for
18995 `HARD_REGNO_MODE_OK' to distinguish between these modes, provided
18996 you define patterns `movhi', etc., to take advantage of this. This
18997 is useful because of the interaction between `HARD_REGNO_MODE_OK'
18998 and `MODES_TIEABLE_P'; it is very desirable for all integer modes
19001 Many machines have special registers for floating point arithmetic.
19002 Often people assume that floating point machine modes are allowed
19003 only in floating point registers. This is not true. Any
19004 registers that can hold integers can safely _hold_ a floating
19005 point machine mode, whether or not floating arithmetic can be done
19006 on it in those registers. Integer move instructions can be used
19007 to move the values.
19009 On some machines, though, the converse is true: fixed-point machine
19010 modes may not go in floating registers. This is true if the
19011 floating registers normalize any value stored in them, because
19012 storing a non-floating value there would garble it. In this case,
19013 `HARD_REGNO_MODE_OK' should reject fixed-point machine modes in
19014 floating registers. But if the floating registers do not
19015 automatically normalize, if you can store any bit pattern in one
19016 and retrieve it unchanged without a trap, then any machine mode
19017 may go in a floating register, so you can define this macro to say
19020 The primary significance of special floating registers is rather
19021 that they are the registers acceptable in floating point arithmetic
19022 instructions. However, this is of no concern to
19023 `HARD_REGNO_MODE_OK'. You handle it by writing the proper
19024 constraints for those instructions.
19026 On some machines, the floating registers are especially slow to
19027 access, so that it is better to store a value in a stack frame
19028 than in such a register if floating point arithmetic is not being
19029 done. As long as the floating registers are not in class
19030 `GENERAL_REGS', they will not be used unless some pattern's
19031 constraint asks for one.
19033 -- Macro: HARD_REGNO_RENAME_OK (FROM, TO)
19034 A C expression that is nonzero if it is OK to rename a hard
19035 register FROM to another hard register TO.
19037 One common use of this macro is to prevent renaming of a register
19038 to another register that is not saved by a prologue in an interrupt
19041 The default is always nonzero.
19043 -- Macro: MODES_TIEABLE_P (MODE1, MODE2)
19044 A C expression that is nonzero if a value of mode MODE1 is
19045 accessible in mode MODE2 without copying.
19047 If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R,
19048 MODE2)' are always the same for any R, then `MODES_TIEABLE_P
19049 (MODE1, MODE2)' should be nonzero. If they differ for any R, you
19050 should define this macro to return zero unless some other
19051 mechanism ensures the accessibility of the value in a narrower
19054 You should define this macro to return nonzero in as many cases as
19055 possible since doing so will allow GCC to perform better register
19058 -- Macro: AVOID_CCMODE_COPIES
19059 Define this macro if the compiler should avoid copies to/from
19060 `CCmode' registers. You should only define this macro if support
19061 for copying to/from `CCmode' is incomplete.
19064 File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers
19066 14.7.4 Handling Leaf Functions
19067 ------------------------------
19069 On some machines, a leaf function (i.e., one which makes no calls) can
19070 run more efficiently if it does not make its own register window.
19071 Often this means it is required to receive its arguments in the
19072 registers where they are passed by the caller, instead of the registers
19073 where they would normally arrive.
19075 The special treatment for leaf functions generally applies only when
19076 other conditions are met; for example, often they may use only those
19077 registers for its own variables and temporaries. We use the term "leaf
19078 function" to mean a function that is suitable for this special
19079 handling, so that functions with no calls are not necessarily "leaf
19082 GCC assigns register numbers before it knows whether the function is
19083 suitable for leaf function treatment. So it needs to renumber the
19084 registers in order to output a leaf function. The following macros
19087 -- Macro: LEAF_REGISTERS
19088 Name of a char vector, indexed by hard register number, which
19089 contains 1 for a register that is allowable in a candidate for leaf
19090 function treatment.
19092 If leaf function treatment involves renumbering the registers,
19093 then the registers marked here should be the ones before
19094 renumbering--those that GCC would ordinarily allocate. The
19095 registers which will actually be used in the assembler code, after
19096 renumbering, should not be marked with 1 in this vector.
19098 Define this macro only if the target machine offers a way to
19099 optimize the treatment of leaf functions.
19101 -- Macro: LEAF_REG_REMAP (REGNO)
19102 A C expression whose value is the register number to which REGNO
19103 should be renumbered, when a function is treated as a leaf
19106 If REGNO is a register number which should not appear in a leaf
19107 function before renumbering, then the expression should yield -1,
19108 which will cause the compiler to abort.
19110 Define this macro only if the target machine offers a way to
19111 optimize the treatment of leaf functions, and registers need to be
19112 renumbered to do this.
19114 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' must
19115 usually treat leaf functions specially. They can test the C variable
19116 `current_function_is_leaf' which is nonzero for leaf functions.
19117 `current_function_is_leaf' is set prior to local register allocation
19118 and is valid for the remaining compiler passes. They can also test the
19119 C variable `current_function_uses_only_leaf_regs' which is nonzero for
19120 leaf functions which only use leaf registers.
19121 `current_function_uses_only_leaf_regs' is valid after all passes that
19122 modify the instructions have been run and is only useful if
19123 `LEAF_REGISTERS' is defined.
19126 File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers
19128 14.7.5 Registers That Form a Stack
19129 ----------------------------------
19131 There are special features to handle computers where some of the
19132 "registers" form a stack. Stack registers are normally written by
19133 pushing onto the stack, and are numbered relative to the top of the
19136 Currently, GCC can only handle one group of stack-like registers, and
19137 they must be consecutively numbered. Furthermore, the existing support
19138 for stack-like registers is specific to the 80387 floating point
19139 coprocessor. If you have a new architecture that uses stack-like
19140 registers, you will need to do substantial work on `reg-stack.c' and
19141 write your machine description to cooperate with it, as well as
19142 defining these macros.
19144 -- Macro: STACK_REGS
19145 Define this if the machine has any stack-like registers.
19147 -- Macro: FIRST_STACK_REG
19148 The number of the first stack-like register. This one is the top
19151 -- Macro: LAST_STACK_REG
19152 The number of the last stack-like register. This one is the
19153 bottom of the stack.
19156 File: gccint.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros
19158 14.8 Register Classes
19159 =====================
19161 On many machines, the numbered registers are not all equivalent. For
19162 example, certain registers may not be allowed for indexed addressing;
19163 certain registers may not be allowed in some instructions. These
19164 machine restrictions are described to the compiler using "register
19167 You define a number of register classes, giving each one a name and
19168 saying which of the registers belong to it. Then you can specify
19169 register classes that are allowed as operands to particular instruction
19172 In general, each register will belong to several classes. In fact, one
19173 class must be named `ALL_REGS' and contain all the registers. Another
19174 class must be named `NO_REGS' and contain no registers. Often the
19175 union of two classes will be another class; however, this is not
19178 One of the classes must be named `GENERAL_REGS'. There is nothing
19179 terribly special about the name, but the operand constraint letters `r'
19180 and `g' specify this class. If `GENERAL_REGS' is the same as
19181 `ALL_REGS', just define it as a macro which expands to `ALL_REGS'.
19183 Order the classes so that if class X is contained in class Y then X
19184 has a lower class number than Y.
19186 The way classes other than `GENERAL_REGS' are specified in operand
19187 constraints is through machine-dependent operand constraint letters.
19188 You can define such letters to correspond to various classes, then use
19189 them in operand constraints.
19191 You should define a class for the union of two classes whenever some
19192 instruction allows both classes. For example, if an instruction allows
19193 either a floating point (coprocessor) register or a general register
19194 for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS'
19195 which includes both of them. Otherwise you will get suboptimal code.
19197 You must also specify certain redundant information about the register
19198 classes: for each class, which classes contain it and which ones are
19199 contained in it; for each pair of classes, the largest class contained
19202 When a value occupying several consecutive registers is expected in a
19203 certain class, all the registers used must belong to that class.
19204 Therefore, register classes cannot be used to enforce a requirement for
19205 a register pair to start with an even-numbered register. The way to
19206 specify this requirement is with `HARD_REGNO_MODE_OK'.
19208 Register classes used for input-operands of bitwise-and or shift
19209 instructions have a special requirement: each such class must have, for
19210 each fixed-point machine mode, a subclass whose registers can transfer
19211 that mode to or from memory. For example, on some machines, the
19212 operations for single-byte values (`QImode') are limited to certain
19213 registers. When this is so, each register class that is used in a
19214 bitwise-and or shift instruction must have a subclass consisting of
19215 registers from which single-byte values can be loaded or stored. This
19216 is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to
19219 -- Data type: enum reg_class
19220 An enumerated type that must be defined with all the register
19221 class names as enumerated values. `NO_REGS' must be first.
19222 `ALL_REGS' must be the last register class, followed by one more
19223 enumerated value, `LIM_REG_CLASSES', which is not a register class
19224 but rather tells how many classes there are.
19226 Each register class has a number, which is the value of casting
19227 the class name to type `int'. The number serves as an index in
19228 many of the tables described below.
19230 -- Macro: N_REG_CLASSES
19231 The number of distinct register classes, defined as follows:
19233 #define N_REG_CLASSES (int) LIM_REG_CLASSES
19235 -- Macro: REG_CLASS_NAMES
19236 An initializer containing the names of the register classes as C
19237 string constants. These names are used in writing some of the
19240 -- Macro: REG_CLASS_CONTENTS
19241 An initializer containing the contents of the register classes, as
19242 integers which are bit masks. The Nth integer specifies the
19243 contents of class N. The way the integer MASK is interpreted is
19244 that register R is in the class if `MASK & (1 << R)' is 1.
19246 When the machine has more than 32 registers, an integer does not
19247 suffice. Then the integers are replaced by sub-initializers,
19248 braced groupings containing several integers. Each
19249 sub-initializer must be suitable as an initializer for the type
19250 `HARD_REG_SET' which is defined in `hard-reg-set.h'. In this
19251 situation, the first integer in each sub-initializer corresponds to
19252 registers 0 through 31, the second integer to registers 32 through
19255 -- Macro: REGNO_REG_CLASS (REGNO)
19256 A C expression whose value is a register class containing hard
19257 register REGNO. In general there is more than one such class;
19258 choose a class which is "minimal", meaning that no smaller class
19259 also contains the register.
19261 -- Macro: BASE_REG_CLASS
19262 A macro whose definition is the name of the class to which a valid
19263 base register must belong. A base register is one used in an
19264 address which is the register value plus a displacement.
19266 -- Macro: MODE_BASE_REG_CLASS (MODE)
19267 This is a variation of the `BASE_REG_CLASS' macro which allows the
19268 selection of a base register in a mode dependent manner. If MODE
19269 is VOIDmode then it should return the same value as
19272 -- Macro: MODE_BASE_REG_REG_CLASS (MODE)
19273 A C expression whose value is the register class to which a valid
19274 base register must belong in order to be used in a base plus index
19275 register address. You should define this macro if base plus index
19276 addresses have different requirements than other base register
19279 -- Macro: INDEX_REG_CLASS
19280 A macro whose definition is the name of the class to which a valid
19281 index register must belong. An index register is one used in an
19282 address where its value is either multiplied by a scale factor or
19283 added to another register (as well as added to a displacement).
19285 -- Macro: CONSTRAINT_LEN (CHAR, STR)
19286 For the constraint at the start of STR, which starts with the
19287 letter C, return the length. This allows you to have register
19288 class / constant / extra constraints that are longer than a single
19289 letter; you don't need to define this macro if you can do with
19290 single-letter constraints only. The definition of this macro
19291 should use DEFAULT_CONSTRAINT_LEN for all the characters that you
19292 don't want to handle specially. There are some sanity checks in
19293 genoutput.c that check the constraint lengths for the md file, so
19294 you can also use this macro to help you while you are
19295 transitioning from a byzantine single-letter-constraint scheme:
19296 when you return a negative length for a constraint you want to
19297 re-use, genoutput will complain about every instance where it is
19298 used in the md file.
19300 -- Macro: REG_CLASS_FROM_LETTER (CHAR)
19301 A C expression which defines the machine-dependent operand
19302 constraint letters for register classes. If CHAR is such a
19303 letter, the value should be the register class corresponding to
19304 it. Otherwise, the value should be `NO_REGS'. The register
19305 letter `r', corresponding to class `GENERAL_REGS', will not be
19306 passed to this macro; you do not need to handle it.
19308 -- Macro: REG_CLASS_FROM_CONSTRAINT (CHAR, STR)
19309 Like `REG_CLASS_FROM_LETTER', but you also get the constraint
19310 string passed in STR, so that you can use suffixes to distinguish
19311 between different variants.
19313 -- Macro: REGNO_OK_FOR_BASE_P (NUM)
19314 A C expression which is nonzero if register number NUM is suitable
19315 for use as a base register in operand addresses. It may be either
19316 a suitable hard register or a pseudo register that has been
19317 allocated such a hard register.
19319 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE)
19320 A C expression that is just like `REGNO_OK_FOR_BASE_P', except that
19321 that expression may examine the mode of the memory reference in
19322 MODE. You should define this macro if the mode of the memory
19323 reference affects whether a register may be used as a base
19324 register. If you define this macro, the compiler will use it
19325 instead of `REGNO_OK_FOR_BASE_P'.
19327 -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE)
19328 A C expression which is nonzero if register number NUM is suitable
19329 for use as a base register in base plus index operand addresses,
19330 accessing memory in mode MODE. It may be either a suitable hard
19331 register or a pseudo register that has been allocated such a hard
19332 register. You should define this macro if base plus index
19333 addresses have different requirements than other base register
19336 -- Macro: REGNO_OK_FOR_INDEX_P (NUM)
19337 A C expression which is nonzero if register number NUM is suitable
19338 for use as an index register in operand addresses. It may be
19339 either a suitable hard register or a pseudo register that has been
19340 allocated such a hard register.
19342 The difference between an index register and a base register is
19343 that the index register may be scaled. If an address involves the
19344 sum of two registers, neither one of them scaled, then either one
19345 may be labeled the "base" and the other the "index"; but whichever
19346 labeling is used must fit the machine's constraints of which
19347 registers may serve in each capacity. The compiler will try both
19348 labelings, looking for one that is valid, and will reload one or
19349 both registers only if neither labeling works.
19351 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS)
19352 A C expression that places additional restrictions on the register
19353 class to use when it is necessary to copy value X into a register
19354 in class CLASS. The value is a register class; perhaps CLASS, or
19355 perhaps another, smaller class. On many machines, the following
19356 definition is safe:
19358 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
19360 Sometimes returning a more restrictive class makes better code.
19361 For example, on the 68000, when X is an integer constant that is
19362 in range for a `moveq' instruction, the value of this macro is
19363 always `DATA_REGS' as long as CLASS includes the data registers.
19364 Requiring a data register guarantees that a `moveq' will be used.
19366 One case where `PREFERRED_RELOAD_CLASS' must not return CLASS is
19367 if X is a legitimate constant which cannot be loaded into some
19368 register class. By returning `NO_REGS' you can force X into a
19369 memory location. For example, rs6000 can load immediate values
19370 into general-purpose registers, but does not have an instruction
19371 for loading an immediate value into a floating-point register, so
19372 `PREFERRED_RELOAD_CLASS' returns `NO_REGS' when X is a
19373 floating-point constant. If the constant can't be loaded into any
19374 kind of register, code generation will be better if
19375 `LEGITIMATE_CONSTANT_P' makes the constant illegitimate instead of
19376 using `PREFERRED_RELOAD_CLASS'.
19378 -- Macro: PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS)
19379 Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of
19380 input reloads. If you don't define this macro, the default is to
19381 use CLASS, unchanged.
19383 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS)
19384 A C expression that places additional restrictions on the register
19385 class to use when it is necessary to be able to hold a value of
19386 mode MODE in a reload register for which class CLASS would
19387 ordinarily be used.
19389 Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when
19390 there are certain modes that simply can't go in certain reload
19393 The value is a register class; perhaps CLASS, or perhaps another,
19396 Don't define this macro unless the target machine has limitations
19397 which require the macro to do something nontrivial.
19399 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X)
19400 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)
19401 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)
19402 Many machines have some registers that cannot be copied directly
19403 to or from memory or even from other types of registers. An
19404 example is the `MQ' register, which on most machines, can only be
19405 copied to or from general registers, but not memory. Some
19406 machines allow copying all registers to and from memory, but
19407 require a scratch register for stores to some memory locations
19408 (e.g., those with symbolic address on the RT, and those with
19409 certain symbolic address on the SPARC when compiling PIC). In
19410 some cases, both an intermediate and a scratch register are
19413 You should define these macros to indicate to the reload phase
19414 that it may need to allocate at least one register for a reload in
19415 addition to the register to contain the data. Specifically, if
19416 copying X to a register CLASS in MODE requires an intermediate
19417 register, you should define `SECONDARY_INPUT_RELOAD_CLASS' to
19418 return the largest register class all of whose registers can be
19419 used as intermediate registers or scratch registers.
19421 If copying a register CLASS in MODE to X requires an intermediate
19422 or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' should be
19423 defined to return the largest register class required. If the
19424 requirements for input and output reloads are the same, the macro
19425 `SECONDARY_RELOAD_CLASS' should be used instead of defining both
19426 macros identically.
19428 The values returned by these macros are often `GENERAL_REGS'.
19429 Return `NO_REGS' if no spare register is needed; i.e., if X can be
19430 directly copied to or from a register of CLASS in MODE without
19431 requiring a scratch register. Do not define this macro if it
19432 would always return `NO_REGS'.
19434 If a scratch register is required (either with or without an
19435 intermediate register), you should define patterns for
19436 `reload_inM' or `reload_outM', as required (*note Standard
19437 Names::. These patterns, which will normally be implemented with
19438 a `define_expand', should be similar to the `movM' patterns,
19439 except that operand 2 is the scratch register.
19441 Define constraints for the reload register and scratch register
19442 that contain a single register class. If the original reload
19443 register (whose class is CLASS) can meet the constraint given in
19444 the pattern, the value returned by these macros is used for the
19445 class of the scratch register. Otherwise, two additional reload
19446 registers are required. Their classes are obtained from the
19447 constraints in the insn pattern.
19449 X might be a pseudo-register or a `subreg' of a pseudo-register,
19450 which could either be in a hard register or in memory. Use
19451 `true_regnum' to find out; it will return -1 if the pseudo is in
19452 memory and the hard register number if it is in a register.
19454 These macros should not be used in the case where a particular
19455 class of registers can only be copied to memory and not to another
19456 class of registers. In that case, secondary reload registers are
19457 not needed and would not be helpful. Instead, a stack location
19458 must be used to perform the copy and the `movM' pattern should use
19459 memory as an intermediate storage. This case often occurs between
19460 floating-point and general registers.
19462 -- Macro: SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M)
19463 Certain machines have the property that some registers cannot be
19464 copied to some other registers without using memory. Define this
19465 macro on those machines to be a C expression that is nonzero if
19466 objects of mode M in registers of CLASS1 can only be copied to
19467 registers of class CLASS2 by storing a register of CLASS1 into
19468 memory and loading that memory location into a register of CLASS2.
19470 Do not define this macro if its value would always be zero.
19472 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE)
19473 Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler
19474 allocates a stack slot for a memory location needed for register
19475 copies. If this macro is defined, the compiler instead uses the
19476 memory location defined by this macro.
19478 Do not define this macro if you do not define
19479 `SECONDARY_MEMORY_NEEDED'.
19481 -- Macro: SECONDARY_MEMORY_NEEDED_MODE (MODE)
19482 When the compiler needs a secondary memory location to copy
19483 between two registers of mode MODE, it normally allocates
19484 sufficient memory to hold a quantity of `BITS_PER_WORD' bits and
19485 performs the store and load operations in a mode that many bits
19486 wide and whose class is the same as that of MODE.
19488 This is right thing to do on most machines because it ensures that
19489 all bits of the register are copied and prevents accesses to the
19490 registers in a narrower mode, which some machines prohibit for
19491 floating-point registers.
19493 However, this default behavior is not correct on some machines,
19494 such as the DEC Alpha, that store short integers in floating-point
19495 registers differently than in integer registers. On those
19496 machines, the default widening will not work correctly and you
19497 must define this macro to suppress that widening in some cases.
19498 See the file `alpha.h' for details.
19500 Do not define this macro if you do not define
19501 `SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is
19502 `BITS_PER_WORD' bits wide is correct for your machine.
19504 -- Macro: SMALL_REGISTER_CLASSES
19505 On some machines, it is risky to let hard registers live across
19506 arbitrary insns. Typically, these machines have instructions that
19507 require values to be in specific registers (like an accumulator),
19508 and reload will fail if the required hard register is used for
19509 another purpose across such an insn.
19511 Define `SMALL_REGISTER_CLASSES' to be an expression with a nonzero
19512 value on these machines. When this macro has a nonzero value, the
19513 compiler will try to minimize the lifetime of hard registers.
19515 It is always safe to define this macro with a nonzero value, but
19516 if you unnecessarily define it, you will reduce the amount of
19517 optimizations that can be performed in some cases. If you do not
19518 define this macro with a nonzero value when it is required, the
19519 compiler will run out of spill registers and print a fatal error
19520 message. For most machines, you should not define this macro at
19523 -- Macro: CLASS_LIKELY_SPILLED_P (CLASS)
19524 A C expression whose value is nonzero if pseudos that have been
19525 assigned to registers of class CLASS would likely be spilled
19526 because registers of CLASS are needed for spill registers.
19528 The default value of this macro returns 1 if CLASS has exactly one
19529 register and zero otherwise. On most machines, this default
19530 should be used. Only define this macro to some other expression
19531 if pseudos allocated by `local-alloc.c' end up in memory because
19532 their hard registers were needed for spill registers. If this
19533 macro returns nonzero for those classes, those pseudos will only
19534 be allocated by `global.c', which knows how to reallocate the
19535 pseudo to another register. If there would not be another
19536 register available for reallocation, you should not change the
19537 definition of this macro since the only effect of such a
19538 definition would be to slow down register allocation.
19540 -- Macro: CLASS_MAX_NREGS (CLASS, MODE)
19541 A C expression for the maximum number of consecutive registers of
19542 class CLASS needed to hold a value of mode MODE.
19544 This is closely related to the macro `HARD_REGNO_NREGS'. In fact,
19545 the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be
19546 the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all
19547 REGNO values in the class CLASS.
19549 This macro helps control the handling of multiple-word values in
19552 -- Macro: CANNOT_CHANGE_MODE_CLASS (FROM, TO, CLASS)
19553 If defined, a C expression that returns nonzero for a CLASS for
19554 which a change from mode FROM to mode TO is invalid.
19556 For the example, loading 32-bit integer or floating-point objects
19557 into floating-point registers on the Alpha extends them to 64 bits.
19558 Therefore loading a 64-bit object and then storing it as a 32-bit
19559 object does not store the low-order 32 bits, as would be the case
19560 for a normal register. Therefore, `alpha.h' defines
19561 `CANNOT_CHANGE_MODE_CLASS' as below:
19563 #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \
19564 (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \
19565 ? reg_classes_intersect_p (FLOAT_REGS, (CLASS)) : 0)
19567 Three other special macros describe which operands fit which constraint
19570 -- Macro: CONST_OK_FOR_LETTER_P (VALUE, C)
19571 A C expression that defines the machine-dependent operand
19572 constraint letters (`I', `J', `K', ... `P') that specify
19573 particular ranges of integer values. If C is one of those
19574 letters, the expression should check that VALUE, an integer, is in
19575 the appropriate range and return 1 if so, 0 otherwise. If C is
19576 not one of those letters, the value should be 0 regardless of
19579 -- Macro: CONST_OK_FOR_CONSTRAINT_P (VALUE, C, STR)
19580 Like `CONST_OK_FOR_LETTER_P', but you also get the constraint
19581 string passed in STR, so that you can use suffixes to distinguish
19582 between different variants.
19584 -- Macro: CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)
19585 A C expression that defines the machine-dependent operand
19586 constraint letters that specify particular ranges of
19587 `const_double' values (`G' or `H').
19589 If C is one of those letters, the expression should check that
19590 VALUE, an RTX of code `const_double', is in the appropriate range
19591 and return 1 if so, 0 otherwise. If C is not one of those
19592 letters, the value should be 0 regardless of VALUE.
19594 `const_double' is used for all floating-point constants and for
19595 `DImode' fixed-point constants. A given letter can accept either
19596 or both kinds of values. It can use `GET_MODE' to distinguish
19597 between these kinds.
19599 -- Macro: CONST_DOUBLE_OK_FOR_CONSTRAINT_P (VALUE, C, STR)
19600 Like `CONST_DOUBLE_OK_FOR_LETTER_P', but you also get the
19601 constraint string passed in STR, so that you can use suffixes to
19602 distinguish between different variants.
19604 -- Macro: EXTRA_CONSTRAINT (VALUE, C)
19605 A C expression that defines the optional machine-dependent
19606 constraint letters that can be used to segregate specific types of
19607 operands, usually memory references, for the target machine. Any
19608 letter that is not elsewhere defined and not matched by
19609 `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' may be used.
19610 Normally this macro will not be defined.
19612 If it is required for a particular target machine, it should
19613 return 1 if VALUE corresponds to the operand type represented by
19614 the constraint letter C. If C is not defined as an extra
19615 constraint, the value returned should be 0 regardless of VALUE.
19617 For example, on the ROMP, load instructions cannot have their
19618 output in r0 if the memory reference contains a symbolic address.
19619 Constraint letter `Q' is defined as representing a memory address
19620 that does _not_ contain a symbolic address. An alternative is
19621 specified with a `Q' constraint on the input and `r' on the
19622 output. The next alternative specifies `m' on the input and a
19623 register class that does not include r0 on the output.
19625 -- Macro: EXTRA_CONSTRAINT_STR (VALUE, C, STR)
19626 Like `EXTRA_CONSTRAINT', but you also get the constraint string
19627 passed in STR, so that you can use suffixes to distinguish between
19628 different variants.
19630 -- Macro: EXTRA_MEMORY_CONSTRAINT (C, STR)
19631 A C expression that defines the optional machine-dependent
19632 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT',
19633 that should be treated like memory constraints by the reload pass.
19635 It should return 1 if the operand type represented by the
19636 constraint at the start of STR, the first letter of which is the
19637 letter C, comprises a subset of all memory references including
19638 all those whose address is simply a base register. This allows
19639 the reload pass to reload an operand, if it does not directly
19640 correspond to the operand type of C, by copying its address into a
19643 For example, on the S/390, some instructions do not accept
19644 arbitrary memory references, but only those that do not make use
19645 of an index register. The constraint letter `Q' is defined via
19646 `EXTRA_CONSTRAINT' as representing a memory address of this type.
19647 If the letter `Q' is marked as `EXTRA_MEMORY_CONSTRAINT', a `Q'
19648 constraint can handle any memory operand, because the reload pass
19649 knows it can be reloaded by copying the memory address into a base
19650 register if required. This is analogous to the way a `o'
19651 constraint can handle any memory operand.
19653 -- Macro: EXTRA_ADDRESS_CONSTRAINT (C, STR)
19654 A C expression that defines the optional machine-dependent
19655 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT' /
19656 `EXTRA_CONSTRAINT_STR', that should be treated like address
19657 constraints by the reload pass.
19659 It should return 1 if the operand type represented by the
19660 constraint at the start of STR, which starts with the letter C,
19661 comprises a subset of all memory addresses including all those
19662 that consist of just a base register. This allows the reload pass
19663 to reload an operand, if it does not directly correspond to the
19664 operand type of STR, by copying it into a base register.
19666 Any constraint marked as `EXTRA_ADDRESS_CONSTRAINT' can only be
19667 used with the `address_operand' predicate. It is treated
19668 analogously to the `p' constraint.
19671 File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros
19673 14.9 Stack Layout and Calling Conventions
19674 =========================================
19676 This describes the stack layout and calling conventions.
19681 * Exception Handling::
19683 * Frame Registers::
19685 * Stack Arguments::
19686 * Register Arguments::
19688 * Aggregate Return::
19693 * Stack Smashing Protection::
19696 File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling
19698 14.9.1 Basic Stack Layout
19699 -------------------------
19701 Here is the basic stack layout.
19703 -- Macro: STACK_GROWS_DOWNWARD
19704 Define this macro if pushing a word onto the stack moves the stack
19705 pointer to a smaller address.
19707 When we say, "define this macro if ...", it means that the
19708 compiler checks this macro only with `#ifdef' so the precise
19709 definition used does not matter.
19711 -- Macro: STACK_PUSH_CODE
19712 This macro defines the operation used when something is pushed on
19713 the stack. In RTL, a push operation will be `(set (mem
19714 (STACK_PUSH_CODE (reg sp))) ...)'
19716 The choices are `PRE_DEC', `POST_DEC', `PRE_INC', and `POST_INC'.
19717 Which of these is correct depends on the stack direction and on
19718 whether the stack pointer points to the last item on the stack or
19719 whether it points to the space for the next item on the stack.
19721 The default is `PRE_DEC' when `STACK_GROWS_DOWNWARD' is defined,
19722 which is almost always right, and `PRE_INC' otherwise, which is
19725 -- Macro: FRAME_GROWS_DOWNWARD
19726 Define this macro to nonzero value if the addresses of local
19727 variable slots are at negative offsets from the frame pointer.
19729 -- Macro: ARGS_GROW_DOWNWARD
19730 Define this macro if successive arguments to a function occupy
19731 decreasing addresses on the stack.
19733 -- Macro: STARTING_FRAME_OFFSET
19734 Offset from the frame pointer to the first local variable slot to
19737 If `FRAME_GROWS_DOWNWARD', find the next slot's offset by
19738 subtracting the first slot's length from `STARTING_FRAME_OFFSET'.
19739 Otherwise, it is found by adding the length of the first slot to
19740 the value `STARTING_FRAME_OFFSET'.
19742 -- Macro: STACK_ALIGNMENT_NEEDED
19743 Define to zero to disable final alignment of the stack during
19744 reload. The nonzero default for this macro is suitable for most
19747 On ports where `STARTING_FRAME_OFFSET' is nonzero or where there
19748 is a register save block following the local block that doesn't
19749 require alignment to `STACK_BOUNDARY', it may be beneficial to
19750 disable stack alignment and do it in the backend.
19752 -- Macro: STACK_POINTER_OFFSET
19753 Offset from the stack pointer register to the first location at
19754 which outgoing arguments are placed. If not specified, the
19755 default value of zero is used. This is the proper value for most
19758 If `ARGS_GROW_DOWNWARD', this is the offset to the location above
19759 the first location at which outgoing arguments are placed.
19761 -- Macro: FIRST_PARM_OFFSET (FUNDECL)
19762 Offset from the argument pointer register to the first argument's
19763 address. On some machines it may depend on the data type of the
19766 If `ARGS_GROW_DOWNWARD', this is the offset to the location above
19767 the first argument's address.
19769 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL)
19770 Offset from the stack pointer register to an item dynamically
19771 allocated on the stack, e.g., by `alloca'.
19773 The default value for this macro is `STACK_POINTER_OFFSET' plus the
19774 length of the outgoing arguments. The default is correct for most
19775 machines. See `function.c' for details.
19777 -- Macro: INITIAL_FRAME_ADDRESS_RTX
19778 A C expression whose value is RTL representing the address of the
19779 initial stack frame. This address is passed to `RETURN_ADDR_RTX'
19780 and `DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a
19781 reasonable default value will be used. Define this macro in order
19782 to make frame pointer elimination work in the presence of
19783 `__builtin_frame_address (count)' and `__builtin_return_address
19784 (count)' for `count' not equal to zero.
19786 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)
19787 A C expression whose value is RTL representing the address in a
19788 stack frame where the pointer to the caller's frame is stored.
19789 Assume that FRAMEADDR is an RTL expression for the address of the
19790 stack frame itself.
19792 If you don't define this macro, the default is to return the value
19793 of FRAMEADDR--that is, the stack frame address is also the address
19794 of the stack word that points to the previous frame.
19796 -- Macro: SETUP_FRAME_ADDRESSES
19797 If defined, a C expression that produces the machine-specific code
19798 to setup the stack so that arbitrary frames can be accessed. For
19799 example, on the SPARC, we must flush all of the register windows
19800 to the stack before we can access arbitrary stack frames. You
19801 will seldom need to define this macro.
19803 -- Target Hook: bool TARGET_BUILTIN_SETJMP_FRAME_VALUE ()
19804 This target hook should return an rtx that is used to store the
19805 address of the current frame into the built in `setjmp' buffer.
19806 The default value, `virtual_stack_vars_rtx', is correct for most
19807 machines. One reason you may need to define this target hook is if
19808 `hard_frame_pointer_rtx' is the appropriate value on your machine.
19810 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR)
19811 A C expression whose value is RTL representing the value of the
19812 return address for the frame COUNT steps up from the current
19813 frame, after the prologue. FRAMEADDR is the frame pointer of the
19814 COUNT frame, or the frame pointer of the COUNT - 1 frame if
19815 `RETURN_ADDR_IN_PREVIOUS_FRAME' is defined.
19817 The value of the expression must always be the correct address when
19818 COUNT is zero, but may be `NULL_RTX' if there is not way to
19819 determine the return address of other frames.
19821 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME
19822 Define this if the return address of a particular stack frame is
19823 accessed from the frame pointer of the previous stack frame.
19825 -- Macro: INCOMING_RETURN_ADDR_RTX
19826 A C expression whose value is RTL representing the location of the
19827 incoming return address at the beginning of any function, before
19828 the prologue. This RTL is either a `REG', indicating that the
19829 return value is saved in `REG', or a `MEM' representing a location
19832 You only need to define this macro if you want to support call
19833 frame debugging information like that provided by DWARF 2.
19835 If this RTL is a `REG', you should also define
19836 `DWARF_FRAME_RETURN_COLUMN' to `DWARF_FRAME_REGNUM (REGNO)'.
19838 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN
19839 A C expression whose value is an integer giving a DWARF 2 column
19840 number that may be used as an alternate return column. This should
19841 be defined only if `DWARF_FRAME_RETURN_COLUMN' is set to a general
19842 register, but an alternate column needs to be used for signal
19845 -- Macro: DWARF_ZERO_REG
19846 A C expression whose value is an integer giving a DWARF 2 register
19847 number that is considered to always have the value zero. This
19848 should only be defined if the target has an architected zero
19849 register, and someone decided it was a good idea to use that
19850 register number to terminate the stack backtrace. New ports
19853 -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char
19854 *LABEL, rtx PATTERN, int INDEX)
19855 This target hook allows the backend to emit frame-related insns
19856 that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame
19857 debugging info engine will invoke it on insns of the form
19858 (set (reg) (unspec [...] UNSPEC_INDEX))
19860 (set (reg) (unspec_volatile [...] UNSPECV_INDEX)).
19861 to let the backend emit the call frame instructions. LABEL is the
19862 CFI label attached to the insn, PATTERN is the pattern of the insn
19863 and INDEX is `UNSPEC_INDEX' or `UNSPECV_INDEX'.
19865 -- Macro: INCOMING_FRAME_SP_OFFSET
19866 A C expression whose value is an integer giving the offset, in
19867 bytes, from the value of the stack pointer register to the top of
19868 the stack frame at the beginning of any function, before the
19869 prologue. The top of the frame is defined to be the value of the
19870 stack pointer in the previous frame, just before the call
19873 You only need to define this macro if you want to support call
19874 frame debugging information like that provided by DWARF 2.
19876 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL)
19877 A C expression whose value is an integer giving the offset, in
19878 bytes, from the argument pointer to the canonical frame address
19879 (cfa). The final value should coincide with that calculated by
19880 `INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable
19881 during virtual register instantiation.
19883 The default value for this macro is `FIRST_PARM_OFFSET (fundecl)',
19884 which is correct for most machines; in general, the arguments are
19885 found immediately before the stack frame. Note that this is not
19886 the case on some targets that save registers into the caller's
19887 frame, such as SPARC and rs6000, and so such targets need to
19890 You only need to define this macro if the default is incorrect,
19891 and you want to support call frame debugging information like that
19892 provided by DWARF 2.
19894 -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL)
19895 If defined, a C expression whose value is an integer giving the
19896 offset in bytes from the frame pointer to the canonical frame
19897 address (cfa). The final value should conincide with that
19898 calculated by `INCOMING_FRAME_SP_OFFSET'.
19900 Normally the CFA is calculated as an offset from the argument
19901 pointer, via `ARG_POINTER_CFA_OFFSET', but if the argument pointer
19902 is variable due to the ABI, this may not be possible. If this
19903 macro is defined, it imples that the virtual register
19904 instantiation should be based on the frame pointer instead of the
19905 argument pointer. Only one of `FRAME_POINTER_CFA_OFFSET' and
19906 `ARG_POINTER_CFA_OFFSET' should be defined.
19909 File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling
19911 14.9.2 Exception Handling Support
19912 ---------------------------------
19914 -- Macro: EH_RETURN_DATA_REGNO (N)
19915 A C expression whose value is the Nth register number used for
19916 data by exception handlers, or `INVALID_REGNUM' if fewer than N
19917 registers are usable.
19919 The exception handling library routines communicate with the
19920 exception handlers via a set of agreed upon registers. Ideally
19921 these registers should be call-clobbered; it is possible to use
19922 call-saved registers, but may negatively impact code size. The
19923 target must support at least 2 data registers, but should define 4
19924 if there are enough free registers.
19926 You must define this macro if you want to support call frame
19927 exception handling like that provided by DWARF 2.
19929 -- Macro: EH_RETURN_STACKADJ_RTX
19930 A C expression whose value is RTL representing a location in which
19931 to store a stack adjustment to be applied before function return.
19932 This is used to unwind the stack to an exception handler's call
19933 frame. It will be assigned zero on code paths that return
19936 Typically this is a call-clobbered hard register that is otherwise
19937 untouched by the epilogue, but could also be a stack slot.
19939 Do not define this macro if the stack pointer is saved and restored
19940 by the regular prolog and epilog code in the call frame itself; in
19941 this case, the exception handling library routines will update the
19942 stack location to be restored in place. Otherwise, you must define
19943 this macro if you want to support call frame exception handling
19944 like that provided by DWARF 2.
19946 -- Macro: EH_RETURN_HANDLER_RTX
19947 A C expression whose value is RTL representing a location in which
19948 to store the address of an exception handler to which we should
19949 return. It will not be assigned on code paths that return
19952 Typically this is the location in the call frame at which the
19953 normal return address is stored. For targets that return by
19954 popping an address off the stack, this might be a memory address
19955 just below the _target_ call frame rather than inside the current
19956 call frame. If defined, `EH_RETURN_STACKADJ_RTX' will have already
19957 been assigned, so it may be used to calculate the location of the
19960 Some targets have more complex requirements than storing to an
19961 address calculable during initial code generation. In that case
19962 the `eh_return' instruction pattern should be used instead.
19964 If you want to support call frame exception handling, you must
19965 define either this macro or the `eh_return' instruction pattern.
19967 -- Macro: RETURN_ADDR_OFFSET
19968 If defined, an integer-valued C expression for which rtl will be
19969 generated to add it to the exception handler address before it is
19970 searched in the exception handling tables, and to subtract it
19971 again from the address before using it to return to the exception
19974 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL)
19975 This macro chooses the encoding of pointers embedded in the
19976 exception handling sections. If at all possible, this should be
19977 defined such that the exception handling section will not require
19978 dynamic relocations, and so may be read-only.
19980 CODE is 0 for data, 1 for code labels, 2 for function pointers.
19981 GLOBAL is true if the symbol may be affected by dynamic
19982 relocations. The macro should return a combination of the
19983 `DW_EH_PE_*' defines as found in `dwarf2.h'.
19985 If this macro is not defined, pointers will not be encoded but
19986 represented directly.
19988 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE,
19990 This macro allows the target to emit whatever special magic is
19991 required to represent the encoding chosen by
19992 `ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of
19993 pc-relative and indirect encodings; this must be defined if the
19994 target uses text-relative or data-relative encodings.
19996 This is a C statement that branches to DONE if the format was
19997 handled. ENCODING is the format chosen, SIZE is the number of
19998 bytes that the format occupies, ADDR is the `SYMBOL_REF' to be
20001 -- Macro: MD_UNWIND_SUPPORT
20002 A string specifying a file to be #include'd in unwind-dw2.c. The
20003 file so included typically defines `MD_FALLBACK_FRAME_STATE_FOR'.
20005 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS)
20006 This macro allows the target to add cpu and operating system
20007 specific code to the call-frame unwinder for use when there is no
20008 unwind data available. The most common reason to implement this
20009 macro is to unwind through signal frames.
20011 This macro is called from `uw_frame_state_for' in `unwind-dw2.c'
20012 and `unwind-ia64.c'. CONTEXT is an `_Unwind_Context'; FS is an
20013 `_Unwind_FrameState'. Examine `context->ra' for the address of
20014 the code being executed and `context->cfa' for the stack pointer
20015 value. If the frame can be decoded, the register save addresses
20016 should be updated in FS and the macro should evaluate to
20017 `_URC_NO_REASON'. If the frame cannot be decoded, the macro should
20018 evaluate to `_URC_END_OF_STACK'.
20020 For proper signal handling in Java this macro is accompanied by
20021 `MAKE_THROW_FRAME', defined in `libjava/include/*-signal.h'
20024 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS)
20025 This macro allows the target to add operating system specific code
20026 to the call-frame unwinder to handle the IA-64 `.unwabi' unwinding
20027 directive, usually used for signal or interrupt frames.
20029 This macro is called from `uw_update_context' in `unwind-ia64.c'.
20030 CONTEXT is an `_Unwind_Context'; FS is an `_Unwind_FrameState'.
20031 Examine `fs->unwabi' for the abi and context in the `.unwabi'
20032 directive. If the `.unwabi' directive can be handled, the
20033 register save addresses should be updated in FS.
20035 -- Macro: TARGET_USES_WEAK_UNWIND_INFO
20036 A C expression that evaluates to true if the target requires unwind
20037 info to be given comdat linkage. Define it to be `1' if comdat
20038 linkage is necessary. The default is `0'.
20041 File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling
20043 14.9.3 Specifying How Stack Checking is Done
20044 --------------------------------------------
20046 GCC will check that stack references are within the boundaries of the
20047 stack, if the `-fstack-check' is specified, in one of three ways:
20049 1. If the value of the `STACK_CHECK_BUILTIN' macro is nonzero, GCC
20050 will assume that you have arranged for stack checking to be done at
20051 appropriate places in the configuration files, e.g., in
20052 `TARGET_ASM_FUNCTION_PROLOGUE'. GCC will do not other special
20055 2. If `STACK_CHECK_BUILTIN' is zero and you defined a named pattern
20056 called `check_stack' in your `md' file, GCC will call that pattern
20057 with one argument which is the address to compare the stack value
20058 against. You must arrange for this pattern to report an error if
20059 the stack pointer is out of range.
20061 3. If neither of the above are true, GCC will generate code to
20062 periodically "probe" the stack pointer using the values of the
20063 macros defined below.
20065 Normally, you will use the default values of these macros, so GCC will
20066 use the third approach.
20068 -- Macro: STACK_CHECK_BUILTIN
20069 A nonzero value if stack checking is done by the configuration
20070 files in a machine-dependent manner. You should define this macro
20071 if stack checking is require by the ABI of your machine or if you
20072 would like to have to stack checking in some more efficient way
20073 than GCC's portable approach. The default value of this macro is
20076 -- Macro: STACK_CHECK_PROBE_INTERVAL
20077 An integer representing the interval at which GCC must generate
20078 stack probe instructions. You will normally define this macro to
20079 be no larger than the size of the "guard pages" at the end of a
20080 stack area. The default value of 4096 is suitable for most
20083 -- Macro: STACK_CHECK_PROBE_LOAD
20084 A integer which is nonzero if GCC should perform the stack probe
20085 as a load instruction and zero if GCC should use a store
20086 instruction. The default is zero, which is the most efficient
20087 choice on most systems.
20089 -- Macro: STACK_CHECK_PROTECT
20090 The number of bytes of stack needed to recover from a stack
20091 overflow, for languages where such a recovery is supported. The
20092 default value of 75 words should be adequate for most machines.
20094 -- Macro: STACK_CHECK_MAX_FRAME_SIZE
20095 The maximum size of a stack frame, in bytes. GCC will generate
20096 probe instructions in non-leaf functions to ensure at least this
20097 many bytes of stack are available. If a stack frame is larger
20098 than this size, stack checking will not be reliable and GCC will
20099 issue a warning. The default is chosen so that GCC only generates
20100 one instruction on most systems. You should normally not change
20101 the default value of this macro.
20103 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE
20104 GCC uses this value to generate the above warning message. It
20105 represents the amount of fixed frame used by a function, not
20106 including space for any callee-saved registers, temporaries and
20107 user variables. You need only specify an upper bound for this
20108 amount and will normally use the default of four words.
20110 -- Macro: STACK_CHECK_MAX_VAR_SIZE
20111 The maximum size, in bytes, of an object that GCC will place in the
20112 fixed area of the stack frame when the user specifies
20113 `-fstack-check'. GCC computed the default from the values of the
20114 above macros and you will normally not need to override that
20118 File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling
20120 14.9.4 Registers That Address the Stack Frame
20121 ---------------------------------------------
20123 This discusses registers that address the stack frame.
20125 -- Macro: STACK_POINTER_REGNUM
20126 The register number of the stack pointer register, which must also
20127 be a fixed register according to `FIXED_REGISTERS'. On most
20128 machines, the hardware determines which register this is.
20130 -- Macro: FRAME_POINTER_REGNUM
20131 The register number of the frame pointer register, which is used to
20132 access automatic variables in the stack frame. On some machines,
20133 the hardware determines which register this is. On other
20134 machines, you can choose any register you wish for this purpose.
20136 -- Macro: HARD_FRAME_POINTER_REGNUM
20137 On some machines the offset between the frame pointer and starting
20138 offset of the automatic variables is not known until after register
20139 allocation has been done (for example, because the saved registers
20140 are between these two locations). On those machines, define
20141 `FRAME_POINTER_REGNUM' the number of a special, fixed register to
20142 be used internally until the offset is known, and define
20143 `HARD_FRAME_POINTER_REGNUM' to be the actual hard register number
20144 used for the frame pointer.
20146 You should define this macro only in the very rare circumstances
20147 when it is not possible to calculate the offset between the frame
20148 pointer and the automatic variables until after register
20149 allocation has been completed. When this macro is defined, you
20150 must also indicate in your definition of `ELIMINABLE_REGS' how to
20151 eliminate `FRAME_POINTER_REGNUM' into either
20152 `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'.
20154 Do not define this macro if it would be the same as
20155 `FRAME_POINTER_REGNUM'.
20157 -- Macro: ARG_POINTER_REGNUM
20158 The register number of the arg pointer register, which is used to
20159 access the function's argument list. On some machines, this is
20160 the same as the frame pointer register. On some machines, the
20161 hardware determines which register this is. On other machines,
20162 you can choose any register you wish for this purpose. If this is
20163 not the same register as the frame pointer register, then you must
20164 mark it as a fixed register according to `FIXED_REGISTERS', or
20165 arrange to be able to eliminate it (*note Elimination::).
20167 -- Macro: RETURN_ADDRESS_POINTER_REGNUM
20168 The register number of the return address pointer register, which
20169 is used to access the current function's return address from the
20170 stack. On some machines, the return address is not at a fixed
20171 offset from the frame pointer or stack pointer or argument
20172 pointer. This register can be defined to point to the return
20173 address on the stack, and then be converted by `ELIMINABLE_REGS'
20174 into either the frame pointer or stack pointer.
20176 Do not define this macro unless there is no other way to get the
20177 return address from the stack.
20179 -- Macro: STATIC_CHAIN_REGNUM
20180 -- Macro: STATIC_CHAIN_INCOMING_REGNUM
20181 Register numbers used for passing a function's static chain
20182 pointer. If register windows are used, the register number as
20183 seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM',
20184 while the register number as seen by the calling function is
20185 `STATIC_CHAIN_REGNUM'. If these registers are the same,
20186 `STATIC_CHAIN_INCOMING_REGNUM' need not be defined.
20188 The static chain register need not be a fixed register.
20190 If the static chain is passed in memory, these macros should not be
20191 defined; instead, the next two macros should be defined.
20193 -- Macro: STATIC_CHAIN
20194 -- Macro: STATIC_CHAIN_INCOMING
20195 If the static chain is passed in memory, these macros provide rtx
20196 giving `mem' expressions that denote where they are stored.
20197 `STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as
20198 seen by the calling and called functions, respectively. Often the
20199 former will be at an offset from the stack pointer and the latter
20200 at an offset from the frame pointer.
20202 The variables `stack_pointer_rtx', `frame_pointer_rtx', and
20203 `arg_pointer_rtx' will have been initialized prior to the use of
20204 these macros and should be used to refer to those items.
20206 If the static chain is passed in a register, the two previous
20207 macros should be defined instead.
20209 -- Macro: DWARF_FRAME_REGISTERS
20210 This macro specifies the maximum number of hard registers that can
20211 be saved in a call frame. This is used to size data structures
20212 used in DWARF2 exception handling.
20214 Prior to GCC 3.0, this macro was needed in order to establish a
20215 stable exception handling ABI in the face of adding new hard
20216 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is
20217 insulated from changes in the number of hard registers.
20218 Nevertheless, this macro can still be used to reduce the runtime
20219 memory requirements of the exception handling routines, which can
20220 be substantial if the ISA contains a lot of registers that are not
20223 If this macro is not defined, it defaults to
20224 `FIRST_PSEUDO_REGISTER'.
20226 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS
20227 This macro is similar to `DWARF_FRAME_REGISTERS', but is provided
20228 for backward compatibility in pre GCC 3.0 compiled code.
20230 If this macro is not defined, it defaults to
20231 `DWARF_FRAME_REGISTERS'.
20233 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO)
20234 Define this macro if the target's representation for dwarf
20235 registers is different than the internal representation for unwind
20236 column. Given a dwarf register, this macro should return the
20237 internal unwind column number to use instead.
20239 See the PowerPC's SPE target for an example.
20241 -- Macro: DWARF_FRAME_REGNUM (REGNO)
20242 Define this macro if the target's representation for dwarf
20243 registers used in .eh_frame or .debug_frame is different from that
20244 used in other debug info sections. Given a GCC hard register
20245 number, this macro should return the .eh_frame register number.
20246 The default is `DBX_REGISTER_NUMBER (REGNO)'.
20249 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH)
20250 Define this macro to map register numbers held in the call frame
20251 info that GCC has collected using `DWARF_FRAME_REGNUM' to those
20252 that should be output in .debug_frame (`FOR_EH' is zero) and
20253 .eh_frame (`FOR_EH' is nonzero). The default is to return `REGNO'.
20257 File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling
20259 14.9.5 Eliminating Frame Pointer and Arg Pointer
20260 ------------------------------------------------
20262 This is about eliminating the frame pointer and arg pointer.
20264 -- Macro: FRAME_POINTER_REQUIRED
20265 A C expression which is nonzero if a function must have and use a
20266 frame pointer. This expression is evaluated in the reload pass.
20267 If its value is nonzero the function will have a frame pointer.
20269 The expression can in principle examine the current function and
20270 decide according to the facts, but on most machines the constant 0
20271 or the constant 1 suffices. Use 0 when the machine allows code to
20272 be generated with no frame pointer, and doing so saves some time
20273 or space. Use 1 when there is no possible advantage to avoiding a
20276 In certain cases, the compiler does not know how to produce valid
20277 code without a frame pointer. The compiler recognizes those cases
20278 and automatically gives the function a frame pointer regardless of
20279 what `FRAME_POINTER_REQUIRED' says. You don't need to worry about
20282 In a function that does not require a frame pointer, the frame
20283 pointer register can be allocated for ordinary usage, unless you
20284 mark it as a fixed register. See `FIXED_REGISTERS' for more
20287 -- Macro: INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)
20288 A C statement to store in the variable DEPTH-VAR the difference
20289 between the frame pointer and the stack pointer values immediately
20290 after the function prologue. The value would be computed from
20291 information such as the result of `get_frame_size ()' and the
20292 tables of registers `regs_ever_live' and `call_used_regs'.
20294 If `ELIMINABLE_REGS' is defined, this macro will be not be used and
20295 need not be defined. Otherwise, it must be defined even if
20296 `FRAME_POINTER_REQUIRED' is defined to always be true; in that
20297 case, you may set DEPTH-VAR to anything.
20299 -- Macro: ELIMINABLE_REGS
20300 If defined, this macro specifies a table of register pairs used to
20301 eliminate unneeded registers that point into the stack frame. If
20302 it is not defined, the only elimination attempted by the compiler
20303 is to replace references to the frame pointer with references to
20306 The definition of this macro is a list of structure
20307 initializations, each of which specifies an original and
20308 replacement register.
20310 On some machines, the position of the argument pointer is not
20311 known until the compilation is completed. In such a case, a
20312 separate hard register must be used for the argument pointer.
20313 This register can be eliminated by replacing it with either the
20314 frame pointer or the argument pointer, depending on whether or not
20315 the frame pointer has been eliminated.
20317 In this case, you might specify:
20318 #define ELIMINABLE_REGS \
20319 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
20320 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
20321 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
20323 Note that the elimination of the argument pointer with the stack
20324 pointer is specified first since that is the preferred elimination.
20326 -- Macro: CAN_ELIMINATE (FROM-REG, TO-REG)
20327 A C expression that returns nonzero if the compiler is allowed to
20328 try to replace register number FROM-REG with register number
20329 TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is
20330 defined, and will usually be the constant 1, since most of the
20331 cases preventing register elimination are things that the compiler
20332 already knows about.
20334 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)
20335 This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It
20336 specifies the initial difference between the specified pair of
20337 registers. This macro must be defined if `ELIMINABLE_REGS' is
20341 File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling
20343 14.9.6 Passing Function Arguments on the Stack
20344 ----------------------------------------------
20346 The macros in this section control how arguments are passed on the
20347 stack. See the following section for other macros that control passing
20348 certain arguments in registers.
20350 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (tree FNTYPE)
20351 This target hook returns `true' if an argument declared in a
20352 prototype as an integral type smaller than `int' should actually be
20353 passed as an `int'. In addition to avoiding errors in certain
20354 cases of mismatch, it also makes for better code on certain
20355 machines. The default is to not promote prototypes.
20357 -- Macro: PUSH_ARGS
20358 A C expression. If nonzero, push insns will be used to pass
20359 outgoing arguments. If the target machine does not have a push
20360 instruction, set it to zero. That directs GCC to use an alternate
20361 strategy: to allocate the entire argument block and then store the
20362 arguments into it. When `PUSH_ARGS' is nonzero, `PUSH_ROUNDING'
20363 must be defined too.
20365 -- Macro: PUSH_ARGS_REVERSED
20366 A C expression. If nonzero, function arguments will be evaluated
20367 from last to first, rather than from first to last. If this macro
20368 is not defined, it defaults to `PUSH_ARGS' on targets where the
20369 stack and args grow in opposite directions, and 0 otherwise.
20371 -- Macro: PUSH_ROUNDING (NPUSHED)
20372 A C expression that is the number of bytes actually pushed onto the
20373 stack when an instruction attempts to push NPUSHED bytes.
20375 On some machines, the definition
20377 #define PUSH_ROUNDING(BYTES) (BYTES)
20379 will suffice. But on other machines, instructions that appear to
20380 push one byte actually push two bytes in an attempt to maintain
20381 alignment. Then the definition should be
20383 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
20385 -- Macro: ACCUMULATE_OUTGOING_ARGS
20386 A C expression. If nonzero, the maximum amount of space required
20387 for outgoing arguments will be computed and placed into the
20388 variable `current_function_outgoing_args_size'. No space will be
20389 pushed onto the stack for each call; instead, the function
20390 prologue should increase the stack frame size by this amount.
20392 Setting both `PUSH_ARGS' and `ACCUMULATE_OUTGOING_ARGS' is not
20395 -- Macro: REG_PARM_STACK_SPACE (FNDECL)
20396 Define this macro if functions should assume that stack space has
20397 been allocated for arguments even when their values are passed in
20400 The value of this macro is the size, in bytes, of the area
20401 reserved for arguments passed in registers for the function
20402 represented by FNDECL, which can be zero if GCC is calling a
20405 This space can be allocated by the caller, or be a part of the
20406 machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says
20409 -- Macro: OUTGOING_REG_PARM_STACK_SPACE
20410 Define this if it is the responsibility of the caller to allocate
20411 the area reserved for arguments passed in registers.
20413 If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls
20414 whether the space for these arguments counts in the value of
20415 `current_function_outgoing_args_size'.
20417 -- Macro: STACK_PARMS_IN_REG_PARM_AREA
20418 Define this macro if `REG_PARM_STACK_SPACE' is defined, but the
20419 stack parameters don't skip the area specified by it.
20421 Normally, when a parameter is not passed in registers, it is
20422 placed on the stack beyond the `REG_PARM_STACK_SPACE' area.
20423 Defining this macro suppresses this behavior and causes the
20424 parameter to be passed on the stack in its natural location.
20426 -- Macro: RETURN_POPS_ARGS (FUNDECL, FUNTYPE, STACK-SIZE)
20427 A C expression that should indicate the number of bytes of its own
20428 arguments that a function pops on returning, or 0 if the function
20429 pops no arguments and the caller must therefore pop them all after
20430 the function returns.
20432 FUNDECL is a C variable whose value is a tree node that describes
20433 the function in question. Normally it is a node of type
20434 `FUNCTION_DECL' that describes the declaration of the function.
20435 From this you can obtain the `DECL_ATTRIBUTES' of the function.
20437 FUNTYPE is a C variable whose value is a tree node that describes
20438 the function in question. Normally it is a node of type
20439 `FUNCTION_TYPE' that describes the data type of the function.
20440 From this it is possible to obtain the data types of the value and
20441 arguments (if known).
20443 When a call to a library function is being considered, FUNDECL
20444 will contain an identifier node for the library function. Thus, if
20445 you need to distinguish among various library functions, you can
20446 do so by their names. Note that "library function" in this
20447 context means a function used to perform arithmetic, whose name is
20448 known specially in the compiler and was not mentioned in the C
20449 code being compiled.
20451 STACK-SIZE is the number of bytes of arguments passed on the
20452 stack. If a variable number of bytes is passed, it is zero, and
20453 argument popping will always be the responsibility of the calling
20456 On the VAX, all functions always pop their arguments, so the
20457 definition of this macro is STACK-SIZE. On the 68000, using the
20458 standard calling convention, no functions pop their arguments, so
20459 the value of the macro is always 0 in this case. But an
20460 alternative calling convention is available in which functions
20461 that take a fixed number of arguments pop them but other functions
20462 (such as `printf') pop nothing (the caller pops all). When this
20463 convention is in use, FUNTYPE is examined to determine whether a
20464 function takes a fixed number of arguments.
20466 -- Macro: CALL_POPS_ARGS (CUM)
20467 A C expression that should indicate the number of bytes a call
20468 sequence pops off the stack. It is added to the value of
20469 `RETURN_POPS_ARGS' when compiling a function call.
20471 CUM is the variable in which all arguments to the called function
20472 have been accumulated.
20474 On certain architectures, such as the SH5, a call trampoline is
20475 used that pops certain registers off the stack, depending on the
20476 arguments that have been passed to the function. Since this is a
20477 property of the call site, not of the called function,
20478 `RETURN_POPS_ARGS' is not appropriate.
20481 File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling
20483 14.9.7 Passing Arguments in Registers
20484 -------------------------------------
20486 This section describes the macros which let you control how various
20487 types of arguments are passed in registers or how they are arranged in
20490 -- Macro: FUNCTION_ARG (CUM, MODE, TYPE, NAMED)
20491 A C expression that controls whether a function argument is passed
20492 in a register, and which register.
20494 The arguments are CUM, which summarizes all the previous
20495 arguments; MODE, the machine mode of the argument; TYPE, the data
20496 type of the argument as a tree node or 0 if that is not known
20497 (which happens for C support library functions); and NAMED, which
20498 is 1 for an ordinary argument and 0 for nameless arguments that
20499 correspond to `...' in the called function's prototype. TYPE can
20500 be an incomplete type if a syntax error has previously occurred.
20502 The value of the expression is usually either a `reg' RTX for the
20503 hard register in which to pass the argument, or zero to pass the
20504 argument on the stack.
20506 For machines like the VAX and 68000, where normally all arguments
20507 are pushed, zero suffices as a definition.
20509 The value of the expression can also be a `parallel' RTX. This is
20510 used when an argument is passed in multiple locations. The mode
20511 of the `parallel' should be the mode of the entire argument. The
20512 `parallel' holds any number of `expr_list' pairs; each one
20513 describes where part of the argument is passed. In each
20514 `expr_list' the first operand must be a `reg' RTX for the hard
20515 register in which to pass this part of the argument, and the mode
20516 of the register RTX indicates how large this part of the argument
20517 is. The second operand of the `expr_list' is a `const_int' which
20518 gives the offset in bytes into the entire argument of where this
20519 part starts. As a special exception the first `expr_list' in the
20520 `parallel' RTX may have a first operand of zero. This indicates
20521 that the entire argument is also stored on the stack.
20523 The last time this macro is called, it is called with `MODE ==
20524 VOIDmode', and its result is passed to the `call' or `call_value'
20525 pattern as operands 2 and 3 respectively.
20527 The usual way to make the ISO library `stdarg.h' work on a machine
20528 where some arguments are usually passed in registers, is to cause
20529 nameless arguments to be passed on the stack instead. This is done
20530 by making `FUNCTION_ARG' return 0 whenever NAMED is 0.
20532 You may use the hook `targetm.calls.must_pass_in_stack' in the
20533 definition of this macro to determine if this argument is of a
20534 type that must be passed in the stack. If `REG_PARM_STACK_SPACE'
20535 is not defined and `FUNCTION_ARG' returns nonzero for such an
20536 argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is
20537 defined, the argument will be computed in the stack and then
20538 loaded into a register.
20540 -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (enum machine_mode
20542 This target hook should return `true' if we should not pass TYPE
20543 solely in registers. The file `expr.h' defines a definition that
20544 is usually appropriate, refer to `expr.h' for additional
20547 -- Macro: FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)
20548 Define this macro if the target machine has "register windows", so
20549 that the register in which a function sees an arguments is not
20550 necessarily the same as the one in which the caller passed the
20553 For such machines, `FUNCTION_ARG' computes the register in which
20554 the caller passes the value, and `FUNCTION_INCOMING_ARG' should be
20555 defined in a similar fashion to tell the function being called
20556 where the arguments will arrive.
20558 If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
20561 -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (CUMULATIVE_ARGS *CUM,
20562 enum machine_mode MODE, tree TYPE, bool NAMED)
20563 This target hook returns the number of bytes at the beginning of an
20564 argument that must be put in registers. The value must be zero for
20565 arguments that are passed entirely in registers or that are
20566 entirely pushed on the stack.
20568 On some machines, certain arguments must be passed partially in
20569 registers and partially in memory. On these machines, typically
20570 the first few words of arguments are passed in registers, and the
20571 rest on the stack. If a multi-word argument (a `double' or a
20572 structure) crosses that boundary, its first few words must be
20573 passed in registers and the rest must be pushed. This macro tells
20574 the compiler when this occurs, and how many bytes should go in
20577 `FUNCTION_ARG' for these arguments should return the first
20578 register to be used by the caller for this argument; likewise
20579 `FUNCTION_INCOMING_ARG', for the called function.
20581 -- Target Hook: bool TARGET_PASS_BY_REFERENCE (CUMULATIVE_ARGS *CUM,
20582 enum machine_mode MODE, tree TYPE, bool NAMED)
20583 This target hook should return `true' if an argument at the
20584 position indicated by CUM should be passed by reference. This
20585 predicate is queried after target independent reasons for being
20586 passed by reference, such as `TREE_ADDRESSABLE (type)'.
20588 If the hook returns true, a copy of that argument is made in
20589 memory and a pointer to the argument is passed instead of the
20590 argument itself. The pointer is passed in whatever way is
20591 appropriate for passing a pointer to that type.
20593 -- Target Hook: bool TARGET_CALLEE_COPIES (CUMULATIVE_ARGS *CUM, enum
20594 machine_mode MODE, tree TYPE, bool NAMED)
20595 The function argument described by the parameters to this hook is
20596 known to be passed by reference. The hook should return true if
20597 the function argument should be copied by the callee instead of
20598 copied by the caller.
20600 For any argument for which the hook returns true, if it can be
20601 determined that the argument is not modified, then a copy need not
20604 The default version of this hook always returns false.
20606 -- Macro: CUMULATIVE_ARGS
20607 A C type for declaring a variable that is used as the first
20608 argument of `FUNCTION_ARG' and other related values. For some
20609 target machines, the type `int' suffices and can hold the number
20610 of bytes of argument so far.
20612 There is no need to record in `CUMULATIVE_ARGS' anything about the
20613 arguments that have been passed on the stack. The compiler has
20614 other variables to keep track of that. For target machines on
20615 which all arguments are passed on the stack, there is no need to
20616 store anything in `CUMULATIVE_ARGS'; however, the data structure
20617 must exist and should not be empty, so use `int'.
20619 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL,
20621 A C statement (sans semicolon) for initializing the variable CUM
20622 for the state at the beginning of the argument list. The variable
20623 has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node
20624 for the data type of the function which will receive the args, or
20625 0 if the args are to a compiler support library function. For
20626 direct calls that are not libcalls, FNDECL contain the declaration
20627 node of the function. FNDECL is also set when
20628 `INIT_CUMULATIVE_ARGS' is used to find arguments for the function
20629 being compiled. N_NAMED_ARGS is set to the number of named
20630 arguments, including a structure return address if it is passed as
20631 a parameter, when making a call. When processing incoming
20632 arguments, N_NAMED_ARGS is set to -1.
20634 When processing a call to a compiler support library function,
20635 LIBNAME identifies which one. It is a `symbol_ref' rtx which
20636 contains the name of the function, as a string. LIBNAME is 0 when
20637 an ordinary C function call is being processed. Thus, each time
20638 this macro is called, either LIBNAME or FNTYPE is nonzero, but
20639 never both of them at once.
20641 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME)
20642 Like `INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls,
20643 it gets a `MODE' argument instead of FNTYPE, that would be `NULL'.
20644 INDIRECT would always be zero, too. If this macro is not
20645 defined, `INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is
20648 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)
20649 Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of
20650 finding the arguments for the function being compiled. If this
20651 macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead.
20653 The value passed for LIBNAME is always 0, since library routines
20654 with special calling conventions are never compiled with GCC. The
20655 argument LIBNAME exists for symmetry with `INIT_CUMULATIVE_ARGS'.
20657 -- Macro: FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)
20658 A C statement (sans semicolon) to update the summarizer variable
20659 CUM to advance past an argument in the argument list. The values
20660 MODE, TYPE and NAMED describe that argument. Once this is done,
20661 the variable CUM is suitable for analyzing the _following_
20662 argument with `FUNCTION_ARG', etc.
20664 This macro need not do anything if the argument in question was
20665 passed on the stack. The compiler knows how to track the amount
20666 of stack space used for arguments without any special help.
20668 -- Macro: FUNCTION_ARG_PADDING (MODE, TYPE)
20669 If defined, a C expression which determines whether, and in which
20670 direction, to pad out an argument with extra space. The value
20671 should be of type `enum direction': either `upward' to pad above
20672 the argument, `downward' to pad below, or `none' to inhibit
20675 The _amount_ of padding is always just enough to reach the next
20676 multiple of `FUNCTION_ARG_BOUNDARY'; this macro does not control
20679 This macro has a default definition which is right for most
20680 systems. For little-endian machines, the default is to pad
20681 upward. For big-endian machines, the default is to pad downward
20682 for an argument of constant size shorter than an `int', and upward
20685 -- Macro: PAD_VARARGS_DOWN
20686 If defined, a C expression which determines whether the default
20687 implementation of va_arg will attempt to pad down before reading
20688 the next argument, if that argument is smaller than its aligned
20689 space as controlled by `PARM_BOUNDARY'. If this macro is not
20690 defined, all such arguments are padded down if `BYTES_BIG_ENDIAN'
20693 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST)
20694 Specify padding for the last element of a block move between
20695 registers and memory. FIRST is nonzero if this is the only
20696 element. Defining this macro allows better control of register
20697 function parameters on big-endian machines, without using
20698 `PARALLEL' rtl. In particular, `MUST_PASS_IN_STACK' need not test
20699 padding and mode of types in registers, as there is no longer a
20700 "wrong" part of a register; For example, a three byte aggregate
20701 may be passed in the high part of a register if so required.
20703 -- Macro: FUNCTION_ARG_BOUNDARY (MODE, TYPE)
20704 If defined, a C expression that gives the alignment boundary, in
20705 bits, of an argument with the specified mode and type. If it is
20706 not defined, `PARM_BOUNDARY' is used for all arguments.
20708 -- Macro: FUNCTION_ARG_REGNO_P (REGNO)
20709 A C expression that is nonzero if REGNO is the number of a hard
20710 register in which function arguments are sometimes passed. This
20711 does _not_ include implicit arguments such as the static chain and
20712 the structure-value address. On many machines, no registers can be
20713 used for this purpose since all function arguments are pushed on
20716 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (tree TYPE)
20717 This hook should return true if parameter of type TYPE are passed
20718 as two scalar parameters. By default, GCC will attempt to pack
20719 complex arguments into the target's word size. Some ABIs require
20720 complex arguments to be split and treated as their individual
20721 components. For example, on AIX64, complex floats should be
20722 passed in a pair of floating point registers, even though a
20723 complex float would fit in one 64-bit floating point register.
20725 The default value of this hook is `NULL', which is treated as
20728 -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void)
20729 This hook returns a type node for `va_list' for the target. The
20730 default version of the hook returns `void*'.
20732 -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree
20733 TYPE, tree *PRE_P, tree *POST_P)
20734 This hook performs target-specific gimplification of
20735 `VA_ARG_EXPR'. The first two parameters correspond to the
20736 arguments to `va_arg'; the latter two are as in
20737 `gimplify.c:gimplify_expr'.
20739 -- Target Hook: bool TARGET_VALID_POINTER_MODE (enum machine_mode MODE)
20740 Define this to return nonzero if the port can handle pointers with
20741 machine mode MODE. The default version of this hook returns true
20742 for both `ptr_mode' and `Pmode'.
20744 -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (enum machine_mode
20746 Define this to return nonzero if the port is prepared to handle
20747 insns involving scalar mode MODE. For a scalar mode to be
20748 considered supported, all the basic arithmetic and comparisons
20751 The default version of this hook returns true for any mode
20752 required to handle the basic C types (as defined by the port).
20753 Included here are the double-word arithmetic supported by the code
20756 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (enum machine_mode
20758 Define this to return nonzero if the port is prepared to handle
20759 insns involving vector mode MODE. At the very least, it must have
20760 move patterns for this mode.
20763 File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling
20765 14.9.8 How Scalar Function Values Are Returned
20766 ----------------------------------------------
20768 This section discusses the macros that control returning scalars as
20769 values--values that can fit in registers.
20771 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC)
20772 A C expression to create an RTX representing the place where a
20773 function returns a value of data type VALTYPE. VALTYPE is a tree
20774 node representing a data type. Write `TYPE_MODE (VALTYPE)' to get
20775 the machine mode used to represent that type. On many machines,
20776 only the mode is relevant. (Actually, on most machines, scalar
20777 values are returned in the same place regardless of mode).
20779 The value of the expression is usually a `reg' RTX for the hard
20780 register where the return value is stored. The value can also be a
20781 `parallel' RTX, if the return value is in multiple places. See
20782 `FUNCTION_ARG' for an explanation of the `parallel' form.
20784 If `TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply
20785 the same promotion rules specified in `PROMOTE_MODE' if VALTYPE is
20788 If the precise function being called is known, FUNC is a tree node
20789 (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
20790 makes it possible to use a different value-returning convention
20791 for specific functions when all their calls are known.
20793 `FUNCTION_VALUE' is not used for return vales with aggregate data
20794 types, because these are returned in another way. See
20795 `TARGET_STRUCT_VALUE_RTX' and related macros, below.
20797 -- Macro: FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)
20798 Define this macro if the target machine has "register windows" so
20799 that the register in which a function returns its value is not the
20800 same as the one in which the caller sees the value.
20802 For such machines, `FUNCTION_VALUE' computes the register in which
20803 the caller will see the value. `FUNCTION_OUTGOING_VALUE' should be
20804 defined in a similar fashion to tell the function where to put the
20807 If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE'
20808 serves both purposes.
20810 `FUNCTION_OUTGOING_VALUE' is not used for return vales with
20811 aggregate data types, because these are returned in another way.
20812 See `TARGET_STRUCT_VALUE_RTX' and related macros, below.
20814 -- Macro: LIBCALL_VALUE (MODE)
20815 A C expression to create an RTX representing the place where a
20816 library function returns a value of mode MODE. If the precise
20817 function being called is known, FUNC is a tree node
20818 (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
20819 makes it possible to use a different value-returning convention
20820 for specific functions when all their calls are known.
20822 Note that "library function" in this context means a compiler
20823 support routine, used to perform arithmetic, whose name is known
20824 specially by the compiler and was not mentioned in the C code being
20827 The definition of `LIBRARY_VALUE' need not be concerned aggregate
20828 data types, because none of the library functions returns such
20831 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO)
20832 A C expression that is nonzero if REGNO is the number of a hard
20833 register in which the values of called function may come back.
20835 A register whose use for returning values is limited to serving as
20836 the second of a pair (for a value of type `double', say) need not
20837 be recognized by this macro. So for most machines, this definition
20840 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
20842 If the machine has register windows, so that the caller and the
20843 called function use different registers for the return value, this
20844 macro should recognize only the caller's register numbers.
20846 -- Macro: APPLY_RESULT_SIZE
20847 Define this macro if `untyped_call' and `untyped_return' need more
20848 space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and
20849 restoring an arbitrary return value.
20851 -- Target Hook: bool TARGET_RETURN_IN_MSB (tree TYPE)
20852 This hook should return true if values of type TYPE are returned
20853 at the most significant end of a register (in other words, if they
20854 are padded at the least significant end). You can assume that TYPE
20855 is returned in a register; the caller is required to check this.
20857 Note that the register provided by `FUNCTION_VALUE' must be able
20858 to hold the complete return value. For example, if a 1-, 2- or
20859 3-byte structure is returned at the most significant end of a
20860 4-byte register, `FUNCTION_VALUE' should provide an `SImode' rtx.
20863 File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling
20865 14.9.9 How Large Values Are Returned
20866 ------------------------------------
20868 When a function value's mode is `BLKmode' (and in some other cases),
20869 the value is not returned according to `FUNCTION_VALUE' (*note Scalar
20870 Return::). Instead, the caller passes the address of a block of memory
20871 in which the value should be stored. This address is called the
20872 "structure value address".
20874 This section describes how to control returning structure values in
20877 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (tree TYPE, tree FNTYPE)
20878 This target hook should return a nonzero value to say to return the
20879 function value in memory, just as large structures are always
20880 returned. Here TYPE will be the data type of the value, and FNTYPE
20881 will be the type of the function doing the returning, or `NULL' for
20884 Note that values of mode `BLKmode' must be explicitly handled by
20885 this function. Also, the option `-fpcc-struct-return' takes
20886 effect regardless of this macro. On most systems, it is possible
20887 to leave the hook undefined; this causes a default definition to
20888 be used, whose value is the constant 1 for `BLKmode' values, and 0
20891 Do not use this hook to indicate that structures and unions should
20892 always be returned in memory. You should instead use
20893 `DEFAULT_PCC_STRUCT_RETURN' to indicate this.
20895 -- Macro: DEFAULT_PCC_STRUCT_RETURN
20896 Define this macro to be 1 if all structure and union return values
20897 must be in memory. Since this results in slower code, this should
20898 be defined only if needed for compatibility with other compilers
20899 or with an ABI. If you define this macro to be 0, then the
20900 conventions used for structure and union return values are decided
20901 by the `TARGET_RETURN_IN_MEMORY' target hook.
20903 If not defined, this defaults to the value 1.
20905 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING)
20906 This target hook should return the location of the structure value
20907 address (normally a `mem' or `reg'), or 0 if the address is passed
20908 as an "invisible" first argument. Note that FNDECL may be `NULL',
20909 for libcalls. You do not need to define this target hook if the
20910 address is always passed as an "invisible" first argument.
20912 On some architectures the place where the structure value address
20913 is found by the called function is not the same place that the
20914 caller put it. This can be due to register windows, or it could
20915 be because the function prologue moves it to a different place.
20916 INCOMING is `true' when the location is needed in the context of
20917 the called function, and `false' in the context of the caller.
20919 If INCOMING is `true' and the address is to be found on the stack,
20920 return a `mem' which refers to the frame pointer.
20922 -- Macro: PCC_STATIC_STRUCT_RETURN
20923 Define this macro if the usual system convention on the target
20924 machine for returning structures and unions is for the called
20925 function to return the address of a static variable containing the
20928 Do not define this if the usual system convention is for the
20929 caller to pass an address to the subroutine.
20931 This macro has effect in `-fpcc-struct-return' mode, but it does
20932 nothing when you use `-freg-struct-return' mode.
20935 File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling
20937 14.9.10 Caller-Saves Register Allocation
20938 ----------------------------------------
20940 If you enable it, GCC can save registers around function calls. This
20941 makes it possible to use call-clobbered registers to hold variables that
20942 must live across calls.
20944 -- Macro: CALLER_SAVE_PROFITABLE (REFS, CALLS)
20945 A C expression to determine whether it is worthwhile to consider
20946 placing a pseudo-register in a call-clobbered hard register and
20947 saving and restoring it around each function call. The expression
20948 should be 1 when this is worth doing, and 0 otherwise.
20950 If you don't define this macro, a default is used which is good on
20951 most machines: `4 * CALLS < REFS'.
20953 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS)
20954 A C expression specifying which mode is required for saving NREGS
20955 of a pseudo-register in call-clobbered hard register REGNO. If
20956 REGNO is unsuitable for caller save, `VOIDmode' should be
20957 returned. For most machines this macro need not be defined since
20958 GCC will select the smallest suitable mode.
20961 File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling
20963 14.9.11 Function Entry and Exit
20964 -------------------------------
20966 This section describes the macros that output function entry
20967 ("prologue") and exit ("epilogue") code.
20969 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE,
20970 HOST_WIDE_INT SIZE)
20971 If defined, a function that outputs the assembler code for entry
20972 to a function. The prologue is responsible for setting up the
20973 stack frame, initializing the frame pointer register, saving
20974 registers that must be saved, and allocating SIZE additional bytes
20975 of storage for the local variables. SIZE is an integer. FILE is
20976 a stdio stream to which the assembler code should be output.
20978 The label for the beginning of the function need not be output by
20979 this macro. That has already been done when the macro is run.
20981 To determine which registers to save, the macro can refer to the
20982 array `regs_ever_live': element R is nonzero if hard register R is
20983 used anywhere within the function. This implies the function
20984 prologue should save register R, provided it is not one of the
20985 call-used registers. (`TARGET_ASM_FUNCTION_EPILOGUE' must
20986 likewise use `regs_ever_live'.)
20988 On machines that have "register windows", the function entry code
20989 does not save on the stack the registers that are in the windows,
20990 even if they are supposed to be preserved by function calls;
20991 instead it takes appropriate steps to "push" the register stack,
20992 if any non-call-used registers are used in the function.
20994 On machines where functions may or may not have frame-pointers, the
20995 function entry code must vary accordingly; it must set up the frame
20996 pointer if one is wanted, and not otherwise. To determine whether
20997 a frame pointer is in wanted, the macro can refer to the variable
20998 `frame_pointer_needed'. The variable's value will be 1 at run
20999 time in a function that needs a frame pointer. *Note
21002 The function entry code is responsible for allocating any stack
21003 space required for the function. This stack space consists of the
21004 regions listed below. In most cases, these regions are allocated
21005 in the order listed, with the last listed region closest to the
21006 top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is
21007 defined, and the highest address if it is not defined). You can
21008 use a different order for a machine if doing so is more convenient
21009 or required for compatibility reasons. Except in cases where
21010 required by standard or by a debugger, there is no reason why the
21011 stack layout used by GCC need agree with that used by other
21012 compilers for a machine.
21014 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE)
21015 If defined, a function that outputs assembler code at the end of a
21016 prologue. This should be used when the function prologue is being
21017 emitted as RTL, and you have some extra assembler that needs to be
21018 emitted. *Note prologue instruction pattern::.
21020 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE)
21021 If defined, a function that outputs assembler code at the start of
21022 an epilogue. This should be used when the function epilogue is
21023 being emitted as RTL, and you have some extra assembler that needs
21024 to be emitted. *Note epilogue instruction pattern::.
21026 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE,
21027 HOST_WIDE_INT SIZE)
21028 If defined, a function that outputs the assembler code for exit
21029 from a function. The epilogue is responsible for restoring the
21030 saved registers and stack pointer to their values when the
21031 function was called, and returning control to the caller. This
21032 macro takes the same arguments as the macro
21033 `TARGET_ASM_FUNCTION_PROLOGUE', and the registers to restore are
21034 determined from `regs_ever_live' and `CALL_USED_REGISTERS' in the
21037 On some machines, there is a single instruction that does all the
21038 work of returning from the function. On these machines, give that
21039 instruction the name `return' and do not define the macro
21040 `TARGET_ASM_FUNCTION_EPILOGUE' at all.
21042 Do not define a pattern named `return' if you want the
21043 `TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target
21044 switches to control whether return instructions or epilogues are
21045 used, define a `return' pattern with a validity condition that
21046 tests the target switches appropriately. If the `return'
21047 pattern's validity condition is false, epilogues will be used.
21049 On machines where functions may or may not have frame-pointers, the
21050 function exit code must vary accordingly. Sometimes the code for
21051 these two cases is completely different. To determine whether a
21052 frame pointer is wanted, the macro can refer to the variable
21053 `frame_pointer_needed'. The variable's value will be 1 when
21054 compiling a function that needs a frame pointer.
21056 Normally, `TARGET_ASM_FUNCTION_PROLOGUE' and
21057 `TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially.
21058 The C variable `current_function_is_leaf' is nonzero for such a
21059 function. *Note Leaf Functions::.
21061 On some machines, some functions pop their arguments on exit while
21062 others leave that for the caller to do. For example, the 68020
21063 when given `-mrtd' pops arguments in functions that take a fixed
21064 number of arguments.
21066 Your definition of the macro `RETURN_POPS_ARGS' decides which
21067 functions pop their own arguments. `TARGET_ASM_FUNCTION_EPILOGUE'
21068 needs to know what was decided. The variable that is called
21069 `current_function_pops_args' is the number of bytes of its
21070 arguments that a function should pop. *Note Scalar Return::.
21072 * A region of `current_function_pretend_args_size' bytes of
21073 uninitialized space just underneath the first argument arriving on
21074 the stack. (This may not be at the very start of the allocated
21075 stack region if the calling sequence has pushed anything else
21076 since pushing the stack arguments. But usually, on such machines,
21077 nothing else has been pushed yet, because the function prologue
21078 itself does all the pushing.) This region is used on machines
21079 where an argument may be passed partly in registers and partly in
21080 memory, and, in some cases to support the features in `<stdarg.h>'.
21082 * An area of memory used to save certain registers used by the
21083 function. The size of this area, which may also include space for
21084 such things as the return address and pointers to previous stack
21085 frames, is machine-specific and usually depends on which registers
21086 have been used in the function. Machines with register windows
21087 often do not require a save area.
21089 * A region of at least SIZE bytes, possibly rounded up to an
21090 allocation boundary, to contain the local variables of the
21091 function. On some machines, this region and the save area may
21092 occur in the opposite order, with the save area closer to the top
21095 * Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a region of
21096 `current_function_outgoing_args_size' bytes to be used for outgoing
21097 argument lists of the function. *Note Stack Arguments::.
21099 -- Macro: EXIT_IGNORE_STACK
21100 Define this macro as a C expression that is nonzero if the return
21101 instruction or the function epilogue ignores the value of the stack
21102 pointer; in other words, if it is safe to delete an instruction to
21103 adjust the stack pointer before a return from the function. The
21106 Note that this macro's value is relevant only for functions for
21107 which frame pointers are maintained. It is never safe to delete a
21108 final stack adjustment in a function that has no frame pointer,
21109 and the compiler knows this regardless of `EXIT_IGNORE_STACK'.
21111 -- Macro: EPILOGUE_USES (REGNO)
21112 Define this macro as a C expression that is nonzero for registers
21113 that are used by the epilogue or the `return' pattern. The stack
21114 and frame pointer registers are already be assumed to be used as
21117 -- Macro: EH_USES (REGNO)
21118 Define this macro as a C expression that is nonzero for registers
21119 that are used by the exception handling mechanism, and so should
21120 be considered live on entry to an exception edge.
21122 -- Macro: DELAY_SLOTS_FOR_EPILOGUE
21123 Define this macro if the function epilogue contains delay slots to
21124 which instructions from the rest of the function can be "moved".
21125 The definition should be a C expression whose value is an integer
21126 representing the number of delay slots there.
21128 -- Macro: ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)
21129 A C expression that returns 1 if INSN can be placed in delay slot
21130 number N of the epilogue.
21132 The argument N is an integer which identifies the delay slot now
21133 being considered (since different slots may have different rules of
21134 eligibility). It is never negative and is always less than the
21135 number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE'
21136 returns). If you reject a particular insn for a given delay slot,
21137 in principle, it may be reconsidered for a subsequent delay slot.
21138 Also, other insns may (at least in principle) be considered for
21139 the so far unfilled delay slot.
21141 The insns accepted to fill the epilogue delay slots are put in an
21142 RTL list made with `insn_list' objects, stored in the variable
21143 `current_function_epilogue_delay_list'. The insn for the first
21144 delay slot comes first in the list. Your definition of the macro
21145 `TARGET_ASM_FUNCTION_EPILOGUE' should fill the delay slots by
21146 outputting the insns in this list, usually by calling
21149 You need not define this macro if you did not define
21150 `DELAY_SLOTS_FOR_EPILOGUE'.
21152 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree
21153 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT
21154 VCALL_OFFSET, tree FUNCTION)
21155 A function that outputs the assembler code for a thunk function,
21156 used to implement C++ virtual function calls with multiple
21157 inheritance. The thunk acts as a wrapper around a virtual
21158 function, adjusting the implicit object parameter before handing
21159 control off to the real function.
21161 First, emit code to add the integer DELTA to the location that
21162 contains the incoming first argument. Assume that this argument
21163 contains a pointer, and is the one used to pass the `this' pointer
21164 in C++. This is the incoming argument _before_ the function
21165 prologue, e.g. `%o0' on a sparc. The addition must preserve the
21166 values of all other incoming arguments.
21168 Then, if VCALL_OFFSET is nonzero, an additional adjustment should
21169 be made after adding `delta'. In particular, if P is the adjusted
21170 pointer, the following adjustment should be made:
21172 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)]
21174 After the additions, emit code to jump to FUNCTION, which is a
21175 `FUNCTION_DECL'. This is a direct pure jump, not a call, and does
21176 not touch the return address. Hence returning from FUNCTION will
21177 return to whoever called the current `thunk'.
21179 The effect must be as if FUNCTION had been called directly with
21180 the adjusted first argument. This macro is responsible for
21181 emitting all of the code for a thunk function;
21182 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE'
21185 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already
21186 been extracted from it.) It might possibly be useful on some
21187 targets, but probably not.
21189 If you do not define this macro, the target-independent code in
21190 the C++ front end will generate a less efficient heavyweight thunk
21191 that calls FUNCTION instead of jumping to it. The generic
21192 approach does not support varargs.
21194 -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (tree
21195 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT
21196 VCALL_OFFSET, tree FUNCTION)
21197 A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would
21198 be able to output the assembler code for the thunk function
21199 specified by the arguments it is passed, and false otherwise. In
21200 the latter case, the generic approach will be used by the C++
21201 front end, with the limitations previously exposed.
21204 File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling
21206 14.9.12 Generating Code for Profiling
21207 -------------------------------------
21209 These macros will help you generate code for profiling.
21211 -- Macro: FUNCTION_PROFILER (FILE, LABELNO)
21212 A C statement or compound statement to output to FILE some
21213 assembler code to call the profiling subroutine `mcount'.
21215 The details of how `mcount' expects to be called are determined by
21216 your operating system environment, not by GCC. To figure them out,
21217 compile a small program for profiling using the system's installed
21218 C compiler and look at the assembler code that results.
21220 Older implementations of `mcount' expect the address of a counter
21221 variable to be loaded into some register. The name of this
21222 variable is `LP' followed by the number LABELNO, so you would
21223 generate the name using `LP%d' in a `fprintf'.
21225 -- Macro: PROFILE_HOOK
21226 A C statement or compound statement to output to FILE some assembly
21227 code to call the profiling subroutine `mcount' even the target does
21228 not support profiling.
21230 -- Macro: NO_PROFILE_COUNTERS
21231 Define this macro if the `mcount' subroutine on your system does
21232 not need a counter variable allocated for each function. This is
21233 true for almost all modern implementations. If you define this
21234 macro, you must not use the LABELNO argument to
21235 `FUNCTION_PROFILER'.
21237 -- Macro: PROFILE_BEFORE_PROLOGUE
21238 Define this macro if the code for function profiling should come
21239 before the function prologue. Normally, the profiling code comes
21243 File: gccint.info, Node: Tail Calls, Next: Stack Smashing Protection, Prev: Profiling, Up: Stack and Calling
21245 14.9.13 Permitting tail calls
21246 -----------------------------
21248 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree
21250 True if it is ok to do sibling call optimization for the specified
21251 call expression EXP. DECL will be the called function, or `NULL'
21252 if this is an indirect call.
21254 It is not uncommon for limitations of calling conventions to
21255 prevent tail calls to functions outside the current unit of
21256 translation, or during PIC compilation. The hook is used to
21257 enforce these restrictions, as the `sibcall' md pattern can not
21258 fail, or fall over to a "normal" call. The criteria for
21259 successful sibling call optimization may vary greatly between
21260 different architectures.
21263 File: gccint.info, Node: Stack Smashing Protection, Prev: Tail Calls, Up: Stack and Calling
21265 14.9.14 Stack smashing protection
21266 ---------------------------------
21268 -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void)
21269 This hook returns a `DECL' node for the external variable to use
21270 for the stack protection guard. This variable is initialized by
21271 the runtime to some random value and is used to initialize the
21272 guard value that is placed at the top of the local stack frame.
21273 The type of this variable must be `ptr_type_node'.
21275 The default version of this hook creates a variable called
21276 `__stack_chk_guard', which is normally defined in `libgcc2.c'.
21278 -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void)
21279 This hook returns a tree expression that alerts the runtime that
21280 the stack protect guard variable has been modified. This
21281 expression should involve a call to a `noreturn' function.
21283 The default version of this hook invokes a function called
21284 `__stack_chk_fail', taking no arguments. This function is
21285 normally defined in `libgcc2.c'.
21288 File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros
21290 14.10 Implementing the Varargs Macros
21291 =====================================
21293 GCC comes with an implementation of `<varargs.h>' and `<stdarg.h>' that
21294 work without change on machines that pass arguments on the stack.
21295 Other machines require their own implementations of varargs, and the
21296 two machine independent header files must have conditionals to include
21299 ISO `<stdarg.h>' differs from traditional `<varargs.h>' mainly in the
21300 calling convention for `va_start'. The traditional implementation
21301 takes just one argument, which is the variable in which to store the
21302 argument pointer. The ISO implementation of `va_start' takes an
21303 additional second argument. The user is supposed to write the last
21304 named argument of the function here.
21306 However, `va_start' should not use this argument. The way to find the
21307 end of the named arguments is with the built-in functions described
21310 -- Macro: __builtin_saveregs ()
21311 Use this built-in function to save the argument registers in
21312 memory so that the varargs mechanism can access them. Both ISO
21313 and traditional versions of `va_start' must use
21314 `__builtin_saveregs', unless you use
21315 `TARGET_SETUP_INCOMING_VARARGS' (see below) instead.
21317 On some machines, `__builtin_saveregs' is open-coded under the
21318 control of the target hook `TARGET_EXPAND_BUILTIN_SAVEREGS'. On
21319 other machines, it calls a routine written in assembler language,
21320 found in `libgcc2.c'.
21322 Code generated for the call to `__builtin_saveregs' appears at the
21323 beginning of the function, as opposed to where the call to
21324 `__builtin_saveregs' is written, regardless of what the code is.
21325 This is because the registers must be saved before the function
21326 starts to use them for its own purposes.
21328 -- Macro: __builtin_args_info (CATEGORY)
21329 Use this built-in function to find the first anonymous arguments in
21332 In general, a machine may have several categories of registers
21333 used for arguments, each for a particular category of data types.
21334 (For example, on some machines, floating-point registers are used
21335 for floating-point arguments while other arguments are passed in
21336 the general registers.) To make non-varargs functions use the
21337 proper calling convention, you have defined the `CUMULATIVE_ARGS'
21338 data type to record how many registers in each category have been
21341 `__builtin_args_info' accesses the same data structure of type
21342 `CUMULATIVE_ARGS' after the ordinary argument layout is finished
21343 with it, with CATEGORY specifying which word to access. Thus, the
21344 value indicates the first unused register in a given category.
21346 Normally, you would use `__builtin_args_info' in the implementation
21347 of `va_start', accessing each category just once and storing the
21348 value in the `va_list' object. This is because `va_list' will
21349 have to update the values, and there is no way to alter the values
21350 accessed by `__builtin_args_info'.
21352 -- Macro: __builtin_next_arg (LASTARG)
21353 This is the equivalent of `__builtin_args_info', for stack
21354 arguments. It returns the address of the first anonymous stack
21355 argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns
21356 the address of the location above the first anonymous stack
21357 argument. Use it in `va_start' to initialize the pointer for
21358 fetching arguments from the stack. Also use it in `va_start' to
21359 verify that the second parameter LASTARG is the last named argument
21360 of the current function.
21362 -- Macro: __builtin_classify_type (OBJECT)
21363 Since each machine has its own conventions for which data types are
21364 passed in which kind of register, your implementation of `va_arg'
21365 has to embody these conventions. The easiest way to categorize the
21366 specified data type is to use `__builtin_classify_type' together
21367 with `sizeof' and `__alignof__'.
21369 `__builtin_classify_type' ignores the value of OBJECT, considering
21370 only its data type. It returns an integer describing what kind of
21371 type that is--integer, floating, pointer, structure, and so on.
21373 The file `typeclass.h' defines an enumeration that you can use to
21374 interpret the values of `__builtin_classify_type'.
21376 These machine description macros help implement varargs:
21378 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void)
21379 If defined, this hook produces the machine-specific code for a
21380 call to `__builtin_saveregs'. This code will be moved to the very
21381 beginning of the function, before any parameter access are made.
21382 The return value of this function should be an RTX that contains
21383 the value to use as the return of `__builtin_saveregs'.
21385 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (CUMULATIVE_ARGS
21386 *ARGS_SO_FAR, enum machine_mode MODE, tree TYPE, int
21387 *PRETEND_ARGS_SIZE, int SECOND_TIME)
21388 This target hook offers an alternative to using
21389 `__builtin_saveregs' and defining the hook
21390 `TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous
21391 register arguments into the stack so that all the arguments appear
21392 to have been passed consecutively on the stack. Once this is
21393 done, you can use the standard implementation of varargs that
21394 works for machines that pass all their arguments on the stack.
21396 The argument ARGS_SO_FAR points to the `CUMULATIVE_ARGS' data
21397 structure, containing the values that are obtained after
21398 processing the named arguments. The arguments MODE and TYPE
21399 describe the last named argument--its machine mode and its data
21400 type as a tree node.
21402 The target hook should do two things: first, push onto the stack
21403 all the argument registers _not_ used for the named arguments, and
21404 second, store the size of the data thus pushed into the
21405 `int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value
21406 that you store here will serve as additional offset for setting up
21409 Because you must generate code to push the anonymous arguments at
21410 compile time without knowing their data types,
21411 `TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that
21412 have just a single category of argument register and use it
21413 uniformly for all data types.
21415 If the argument SECOND_TIME is nonzero, it means that the
21416 arguments of the function are being analyzed for the second time.
21417 This happens for an inline function, which is not actually
21418 compiled until the end of the source file. The hook
21419 `TARGET_SETUP_INCOMING_VARARGS' should not generate any
21420 instructions in this case.
21422 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (CUMULATIVE_ARGS
21424 Define this hook to return `true' if the location where a function
21425 argument is passed depends on whether or not it is a named
21428 This hook controls how the NAMED argument to `FUNCTION_ARG' is set
21429 for varargs and stdarg functions. If this hook returns `true',
21430 the NAMED argument is always true for named arguments, and false
21431 for unnamed arguments. If it returns `false', but
21432 `TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns `true', then all
21433 arguments are treated as named. Otherwise, all named arguments
21434 except the last are treated as named.
21436 You need not define this hook if it always returns zero.
21438 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED
21439 If you need to conditionally change ABIs so that one works with
21440 `TARGET_SETUP_INCOMING_VARARGS', but the other works like neither
21441 `TARGET_SETUP_INCOMING_VARARGS' nor
21442 `TARGET_STRICT_ARGUMENT_NAMING' was defined, then define this hook
21443 to return `true' if `TARGET_SETUP_INCOMING_VARARGS' is used,
21444 `false' otherwise. Otherwise, you should not define this hook.
21447 File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros
21449 14.11 Trampolines for Nested Functions
21450 ======================================
21452 A "trampoline" is a small piece of code that is created at run time
21453 when the address of a nested function is taken. It normally resides on
21454 the stack, in the stack frame of the containing function. These macros
21455 tell GCC how to generate code to allocate and initialize a trampoline.
21457 The instructions in the trampoline must do two things: load a constant
21458 address into the static chain register, and jump to the real address of
21459 the nested function. On CISC machines such as the m68k, this requires
21460 two instructions, a move immediate and a jump. Then the two addresses
21461 exist in the trampoline as word-long immediate operands. On RISC
21462 machines, it is often necessary to load each address into a register in
21463 two parts. Then pieces of each address form separate immediate
21466 The code generated to initialize the trampoline must store the variable
21467 parts--the static chain value and the function address--into the
21468 immediate operands of the instructions. On a CISC machine, this is
21469 simply a matter of copying each address to a memory reference at the
21470 proper offset from the start of the trampoline. On a RISC machine, it
21471 may be necessary to take out pieces of the address and store them
21474 -- Macro: TRAMPOLINE_TEMPLATE (FILE)
21475 A C statement to output, on the stream FILE, assembler code for a
21476 block of data that contains the constant parts of a trampoline.
21477 This code should not include a label--the label is taken care of
21480 If you do not define this macro, it means no template is needed
21481 for the target. Do not define this macro on systems where the
21482 block move code to copy the trampoline into place would be larger
21483 than the code to generate it on the spot.
21485 -- Macro: TRAMPOLINE_SECTION
21486 The name of a subroutine to switch to the section in which the
21487 trampoline template is to be placed (*note Sections::). The
21488 default is a value of `readonly_data_section', which places the
21489 trampoline in the section containing read-only data.
21491 -- Macro: TRAMPOLINE_SIZE
21492 A C expression for the size in bytes of the trampoline, as an
21495 -- Macro: TRAMPOLINE_ALIGNMENT
21496 Alignment required for trampolines, in bits.
21498 If you don't define this macro, the value of `BIGGEST_ALIGNMENT'
21499 is used for aligning trampolines.
21501 -- Macro: INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)
21502 A C statement to initialize the variable parts of a trampoline.
21503 ADDR is an RTX for the address of the trampoline; FNADDR is an RTX
21504 for the address of the nested function; STATIC_CHAIN is an RTX for
21505 the static chain value that should be passed to the function when
21508 -- Macro: TRAMPOLINE_ADJUST_ADDRESS (ADDR)
21509 A C statement that should perform any machine-specific adjustment
21510 in the address of the trampoline. Its argument contains the
21511 address that was passed to `INITIALIZE_TRAMPOLINE'. In case the
21512 address to be used for a function call should be different from
21513 the address in which the template was stored, the different
21514 address should be assigned to ADDR. If this macro is not defined,
21515 ADDR will be used for function calls.
21517 If this macro is not defined, by default the trampoline is
21518 allocated as a stack slot. This default is right for most
21519 machines. The exceptions are machines where it is impossible to
21520 execute instructions in the stack area. On such machines, you may
21521 have to implement a separate stack, using this macro in
21522 conjunction with `TARGET_ASM_FUNCTION_PROLOGUE' and
21523 `TARGET_ASM_FUNCTION_EPILOGUE'.
21525 FP points to a data structure, a `struct function', which
21526 describes the compilation status of the immediate containing
21527 function of the function which the trampoline is for. The stack
21528 slot for the trampoline is in the stack frame of this containing
21529 function. Other allocation strategies probably must do something
21530 analogous with this information.
21532 Implementing trampolines is difficult on many machines because they
21533 have separate instruction and data caches. Writing into a stack
21534 location fails to clear the memory in the instruction cache, so when
21535 the program jumps to that location, it executes the old contents.
21537 Here are two possible solutions. One is to clear the relevant parts of
21538 the instruction cache whenever a trampoline is set up. The other is to
21539 make all trampolines identical, by having them jump to a standard
21540 subroutine. The former technique makes trampoline execution faster; the
21541 latter makes initialization faster.
21543 To clear the instruction cache when a trampoline is initialized, define
21544 the following macro.
21546 -- Macro: CLEAR_INSN_CACHE (BEG, END)
21547 If defined, expands to a C expression clearing the _instruction
21548 cache_ in the specified interval. The definition of this macro
21549 would typically be a series of `asm' statements. Both BEG and END
21550 are both pointer expressions.
21552 The operating system may also require the stack to be made executable
21553 before calling the trampoline. To implement this requirement, define
21554 the following macro.
21556 -- Macro: ENABLE_EXECUTE_STACK
21557 Define this macro if certain operations must be performed before
21558 executing code located on the stack. The macro should expand to a
21559 series of C file-scope constructs (e.g. functions) and provide a
21560 unique entry point named `__enable_execute_stack'. The target is
21561 responsible for emitting calls to the entry point in the code, for
21562 example from the `INITIALIZE_TRAMPOLINE' macro.
21564 To use a standard subroutine, define the following macro. In addition,
21565 you must make sure that the instructions in a trampoline fill an entire
21566 cache line with identical instructions, or else ensure that the
21567 beginning of the trampoline code is always aligned at the same point in
21568 its cache line. Look in `m68k.h' as a guide.
21570 -- Macro: TRANSFER_FROM_TRAMPOLINE
21571 Define this macro if trampolines need a special subroutine to do
21572 their work. The macro should expand to a series of `asm'
21573 statements which will be compiled with GCC. They go in a library
21574 function named `__transfer_from_trampoline'.
21576 If you need to avoid executing the ordinary prologue code of a
21577 compiled C function when you jump to the subroutine, you can do so
21578 by placing a special label of your own in the assembler code. Use
21579 one `asm' statement to generate an assembler label, and another to
21580 make the label global. Then trampolines can use that label to
21581 jump directly to your special assembler code.
21584 File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros
21586 14.12 Implicit Calls to Library Routines
21587 ========================================
21589 Here is an explanation of implicit calls to library routines.
21591 -- Macro: DECLARE_LIBRARY_RENAMES
21592 This macro, if defined, should expand to a piece of C code that
21593 will get expanded when compiling functions for libgcc.a. It can
21594 be used to provide alternate names for GCC's internal library
21595 functions if there are ABI-mandated names that the compiler should
21598 -- Target Hook: void TARGET_INIT_LIBFUNCS (void)
21599 This hook should declare additional library routines or rename
21600 existing ones, using the functions `set_optab_libfunc' and
21601 `init_one_libfunc' defined in `optabs.c'. `init_optabs' calls
21602 this macro after initializing all the normal library routines.
21604 The default is to do nothing. Most ports don't need to define
21607 -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON)
21608 This macro should return `true' if the library routine that
21609 implements the floating point comparison operator COMPARISON in
21610 mode MODE will return a boolean, and FALSE if it will return a
21613 GCC's own floating point libraries return tristates from the
21614 comparison operators, so the default returns false always. Most
21615 ports don't need to define this macro.
21617 -- Macro: TARGET_LIB_INT_CMP_BIASED
21618 This macro should evaluate to `true' if the integer comparison
21619 functions (like `__cmpdi2') return 0 to indicate that the first
21620 operand is smaller than the second, 1 to indicate that they are
21621 equal, and 2 to indicate that the first operand is greater than
21622 the second. If this macro evaluates to `false' the comparison
21623 functions return -1, 0, and 1 instead of 0, 1, and 2. If the
21624 target uses the routines in `libgcc.a', you do not need to define
21627 -- Macro: US_SOFTWARE_GOFAST
21628 Define this macro if your system C library uses the US Software
21629 GOFAST library to provide floating point emulation.
21631 In addition to defining this macro, your architecture must set
21632 `TARGET_INIT_LIBFUNCS' to `gofast_maybe_init_libfuncs', or else
21633 call that function from its version of that hook. It is defined
21634 in `config/gofast.h', which must be included by your
21635 architecture's `CPU.c' file. See `sparc/sparc.c' for an example.
21637 If this macro is defined, the
21638 `TARGET_FLOAT_LIB_COMPARE_RETURNS_BOOL' target hook must return
21639 false for `SFmode' and `DFmode' comparisons.
21641 -- Macro: TARGET_EDOM
21642 The value of `EDOM' on the target machine, as a C integer constant
21643 expression. If you don't define this macro, GCC does not attempt
21644 to deposit the value of `EDOM' into `errno' directly. Look in
21645 `/usr/include/errno.h' to find the value of `EDOM' on your system.
21647 If you do not define `TARGET_EDOM', then compiled code reports
21648 domain errors by calling the library function and letting it
21649 report the error. If mathematical functions on your system use
21650 `matherr' when there is an error, then you should leave
21651 `TARGET_EDOM' undefined so that `matherr' is used normally.
21653 -- Macro: GEN_ERRNO_RTX
21654 Define this macro as a C expression to create an rtl expression
21655 that refers to the global "variable" `errno'. (On certain systems,
21656 `errno' may not actually be a variable.) If you don't define this
21657 macro, a reasonable default is used.
21659 -- Macro: TARGET_C99_FUNCTIONS
21660 When this macro is nonzero, GCC will implicitly optimize `sin'
21661 calls into `sinf' and similarly for other functions defined by C99
21662 standard. The default is nonzero that should be proper value for
21663 most modern systems, however number of existing systems lacks
21664 support for these functions in the runtime so they needs this
21665 macro to be redefined to 0.
21667 -- Macro: NEXT_OBJC_RUNTIME
21668 Define this macro to generate code for Objective-C message sending
21669 using the calling convention of the NeXT system. This calling
21670 convention involves passing the object, the selector and the
21671 method arguments all at once to the method-lookup library function.
21673 The default calling convention passes just the object and the
21674 selector to the lookup function, which returns a pointer to the
21678 File: gccint.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros
21680 14.13 Addressing Modes
21681 ======================
21683 This is about addressing modes.
21685 -- Macro: HAVE_PRE_INCREMENT
21686 -- Macro: HAVE_PRE_DECREMENT
21687 -- Macro: HAVE_POST_INCREMENT
21688 -- Macro: HAVE_POST_DECREMENT
21689 A C expression that is nonzero if the machine supports
21690 pre-increment, pre-decrement, post-increment, or post-decrement
21691 addressing respectively.
21693 -- Macro: HAVE_PRE_MODIFY_DISP
21694 -- Macro: HAVE_POST_MODIFY_DISP
21695 A C expression that is nonzero if the machine supports pre- or
21696 post-address side-effect generation involving constants other than
21697 the size of the memory operand.
21699 -- Macro: HAVE_PRE_MODIFY_REG
21700 -- Macro: HAVE_POST_MODIFY_REG
21701 A C expression that is nonzero if the machine supports pre- or
21702 post-address side-effect generation involving a register
21705 -- Macro: CONSTANT_ADDRESS_P (X)
21706 A C expression that is 1 if the RTX X is a constant which is a
21707 valid address. On most machines, this can be defined as
21708 `CONSTANT_P (X)', but a few machines are more restrictive in which
21709 constant addresses are supported.
21711 -- Macro: CONSTANT_P (X)
21712 `CONSTANT_P', which is defined by target-independent code, accepts
21713 integer-values expressions whose values are not explicitly known,
21714 such as `symbol_ref', `label_ref', and `high' expressions and
21715 `const' arithmetic expressions, in addition to `const_int' and
21716 `const_double' expressions.
21718 -- Macro: MAX_REGS_PER_ADDRESS
21719 A number, the maximum number of registers that can appear in a
21720 valid memory address. Note that it is up to you to specify a
21721 value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS'
21724 -- Macro: GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)
21725 A C compound statement with a conditional `goto LABEL;' executed
21726 if X (an RTX) is a legitimate memory address on the target machine
21727 for a memory operand of mode MODE.
21729 It usually pays to define several simpler macros to serve as
21730 subroutines for this one. Otherwise it may be too complicated to
21733 This macro must exist in two variants: a strict variant and a
21734 non-strict one. The strict variant is used in the reload pass. It
21735 must be defined so that any pseudo-register that has not been
21736 allocated a hard register is considered a memory reference. In
21737 contexts where some kind of register is required, a pseudo-register
21738 with no hard register must be rejected.
21740 The non-strict variant is used in other passes. It must be
21741 defined to accept all pseudo-registers in every context where some
21742 kind of register is required.
21744 Compiler source files that want to use the strict variant of this
21745 macro define the macro `REG_OK_STRICT'. You should use an `#ifdef
21746 REG_OK_STRICT' conditional to define the strict variant in that
21747 case and the non-strict variant otherwise.
21749 Subroutines to check for acceptable registers for various purposes
21750 (one for base registers, one for index registers, and so on) are
21751 typically among the subroutines used to define
21752 `GO_IF_LEGITIMATE_ADDRESS'. Then only these subroutine macros
21753 need have two variants; the higher levels of macros may be the
21754 same whether strict or not.
21756 Normally, constant addresses which are the sum of a `symbol_ref'
21757 and an integer are stored inside a `const' RTX to mark them as
21758 constant. Therefore, there is no need to recognize such sums
21759 specifically as legitimate addresses. Normally you would simply
21760 recognize any `const' as legitimate.
21762 Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant
21763 sums that are not marked with `const'. It assumes that a naked
21764 `plus' indicates indexing. If so, then you _must_ reject such
21765 naked constant sums as illegitimate addresses, so that none of
21766 them will be given to `PRINT_OPERAND_ADDRESS'.
21768 On some machines, whether a symbolic address is legitimate depends
21769 on the section that the address refers to. On these machines,
21770 define the target hook `TARGET_ENCODE_SECTION_INFO' to store the
21771 information into the `symbol_ref', and then check for it here.
21772 When you see a `const', you will have to look inside it to find the
21773 `symbol_ref' in order to determine the section. *Note Assembler
21776 -- Macro: REG_OK_FOR_BASE_P (X)
21777 A C expression that is nonzero if X (assumed to be a `reg' RTX) is
21778 valid for use as a base register. For hard registers, it should
21779 always accept those which the hardware permits and reject the
21780 others. Whether the macro accepts or rejects pseudo registers
21781 must be controlled by `REG_OK_STRICT' as described above. This
21782 usually requires two variant definitions, of which `REG_OK_STRICT'
21783 controls the one actually used.
21785 -- Macro: REG_MODE_OK_FOR_BASE_P (X, MODE)
21786 A C expression that is just like `REG_OK_FOR_BASE_P', except that
21787 that expression may examine the mode of the memory reference in
21788 MODE. You should define this macro if the mode of the memory
21789 reference affects whether a register may be used as a base
21790 register. If you define this macro, the compiler will use it
21791 instead of `REG_OK_FOR_BASE_P'.
21793 -- Macro: REG_MODE_OK_FOR_REG_BASE_P (X, MODE)
21794 A C expression which is nonzero if X (assumed to be a `reg' RTX)
21795 is suitable for use as a base register in base plus index operand
21796 addresses, accessing memory in mode MODE. It may be either a
21797 suitable hard register or a pseudo register that has been
21798 allocated such a hard register. You should define this macro if
21799 base plus index addresses have different requirements than other
21800 base register uses.
21802 -- Macro: REG_OK_FOR_INDEX_P (X)
21803 A C expression that is nonzero if X (assumed to be a `reg' RTX) is
21804 valid for use as an index register.
21806 The difference between an index register and a base register is
21807 that the index register may be scaled. If an address involves the
21808 sum of two registers, neither one of them scaled, then either one
21809 may be labeled the "base" and the other the "index"; but whichever
21810 labeling is used must fit the machine's constraints of which
21811 registers may serve in each capacity. The compiler will try both
21812 labelings, looking for one that is valid, and will reload one or
21813 both registers only if neither labeling works.
21815 -- Macro: FIND_BASE_TERM (X)
21816 A C expression to determine the base term of address X. This
21817 macro is used in only one place: `find_base_term' in alias.c.
21819 It is always safe for this macro to not be defined. It exists so
21820 that alias analysis can understand machine-dependent addresses.
21822 The typical use of this macro is to handle addresses containing a
21823 label_ref or symbol_ref within an UNSPEC.
21825 -- Macro: LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)
21826 A C compound statement that attempts to replace X with a valid
21827 memory address for an operand of mode MODE. WIN will be a C
21828 statement label elsewhere in the code; the macro definition may use
21830 GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
21832 to avoid further processing if the address has become legitimate.
21834 X will always be the result of a call to `break_out_memory_refs',
21835 and OLDX will be the operand that was given to that function to
21838 The code generated by this macro should not alter the substructure
21839 of X. If it transforms X into a more legitimate form, it should
21840 assign X (which will always be a C variable) a new value.
21842 It is not necessary for this macro to come up with a legitimate
21843 address. The compiler has standard ways of doing so in all cases.
21844 In fact, it is safe to omit this macro. But often a
21845 machine-dependent strategy can generate better code.
21847 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS,
21849 A C compound statement that attempts to replace X, which is an
21850 address that needs reloading, with a valid memory address for an
21851 operand of mode MODE. WIN will be a C statement label elsewhere
21852 in the code. It is not necessary to define this macro, but it
21853 might be useful for performance reasons.
21855 For example, on the i386, it is sometimes possible to use a single
21856 reload register instead of two by reloading a sum of two pseudo
21857 registers into a register. On the other hand, for number of RISC
21858 processors offsets are limited so that often an intermediate
21859 address needs to be generated in order to address a stack slot.
21860 By defining `LEGITIMIZE_RELOAD_ADDRESS' appropriately, the
21861 intermediate addresses generated for adjacent some stack slots can
21862 be made identical, and thus be shared.
21864 _Note_: This macro should be used with caution. It is necessary
21865 to know something of how reload works in order to effectively use
21866 this, and it is quite easy to produce macros that build in too
21867 much knowledge of reload internals.
21869 _Note_: This macro must be able to reload an address created by a
21870 previous invocation of this macro. If it fails to handle such
21871 addresses then the compiler may generate incorrect code or abort.
21873 The macro definition should use `push_reload' to indicate parts
21874 that need reloading; OPNUM, TYPE and IND_LEVELS are usually
21875 suitable to be passed unaltered to `push_reload'.
21877 The code generated by this macro must not alter the substructure of
21878 X. If it transforms X into a more legitimate form, it should
21879 assign X (which will always be a C variable) a new value. This
21880 also applies to parts that you change indirectly by calling
21883 The macro definition may use `strict_memory_address_p' to test if
21884 the address has become legitimate.
21886 If you want to change only a part of X, one standard way of doing
21887 this is to use `copy_rtx'. Note, however, that is unshares only a
21888 single level of rtl. Thus, if the part to be changed is not at the
21889 top level, you'll need to replace first the top level. It is not
21890 necessary for this macro to come up with a legitimate address;
21891 but often a machine-dependent strategy can generate better code.
21893 -- Macro: GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)
21894 A C statement or compound statement with a conditional `goto
21895 LABEL;' executed if memory address X (an RTX) can have different
21896 meanings depending on the machine mode of the memory reference it
21897 is used for or if the address is valid for some modes but not
21900 Autoincrement and autodecrement addresses typically have
21901 mode-dependent effects because the amount of the increment or
21902 decrement is the size of the operand being addressed. Some
21903 machines have other mode-dependent addresses. Many RISC machines
21904 have no mode-dependent addresses.
21906 You may assume that ADDR is a valid address for the machine.
21908 -- Macro: LEGITIMATE_CONSTANT_P (X)
21909 A C expression that is nonzero if X is a legitimate constant for
21910 an immediate operand on the target machine. You can assume that X
21911 satisfies `CONSTANT_P', so you need not check this. In fact, `1'
21912 is a suitable definition for this macro on machines where anything
21913 `CONSTANT_P' is valid.
21915 -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X)
21916 This hook is used to undo the possibly obfuscating effects of the
21917 `LEGITIMIZE_ADDRESS' and `LEGITIMIZE_RELOAD_ADDRESS' target
21918 macros. Some backend implementations of these macros wrap symbol
21919 references inside an `UNSPEC' rtx to represent PIC or similar
21920 addressing modes. This target hook allows GCC's optimizers to
21921 understand the semantics of these opaque `UNSPEC's by converting
21922 them back into their original form.
21924 -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (rtx X)
21925 This hook should return true if X is of a form that cannot (or
21926 should not) be spilled to the constant pool. The default version
21927 of this hook returns false.
21929 The primary reason to define this hook is to prevent reload from
21930 deciding that a non-legitimate constant would be better reloaded
21931 from the constant pool instead of spilling and reloading a register
21932 holding the constant. This restriction is often true of addresses
21933 of TLS symbols for various targets.
21935 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void)
21936 This hook should return the DECL of a function F that given an
21937 address ADDR as an argument returns a mask M that can be used to
21938 extract from two vectors the relevant data that resides in ADDR in
21939 case ADDR is not properly aligned.
21941 The autovectrizer, when vectorizing a load operation from an
21942 address ADDR that may be unaligned, will generate two vector loads
21943 from the two aligned addresses around ADDR. It then generates a
21944 `REALIGN_LOAD' operation to extract the relevant data from the two
21945 loaded vectors. The first two arguments to `REALIGN_LOAD', V1 and
21946 V2, are the two vectors, each of size VS, and the third argument,
21947 OFF, defines how the data will be extracted from these two
21948 vectors: if OFF is 0, then the returned vector is V2; otherwise,
21949 the returned vector is composed from the last VS-OFF elements of
21950 V1 concatenated to the first OFF elements of V2.
21952 If this hook is defined, the autovectorizer will generate a call
21953 to F (using the DECL tree that this hook returns) and will use the
21954 return value of F as the argument OFF to `REALIGN_LOAD'.
21955 Therefore, the mask M returned by F should comply with the
21956 semantics expected by `REALIGN_LOAD' described above. If this
21957 hook is not defined, then ADDR will be used as the argument OFF to
21958 `REALIGN_LOAD', in which case the low log2(VS)-1 bits of ADDR will
21962 File: gccint.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Target Macros
21964 14.14 Condition Code Status
21965 ===========================
21967 This describes the condition code status.
21969 The file `conditions.h' defines a variable `cc_status' to describe how
21970 the condition code was computed (in case the interpretation of the
21971 condition code depends on the instruction that it was set by). This
21972 variable contains the RTL expressions on which the condition code is
21973 currently based, and several standard flags.
21975 Sometimes additional machine-specific flags must be defined in the
21976 machine description header file. It can also add additional
21977 machine-specific information by defining `CC_STATUS_MDEP'.
21979 -- Macro: CC_STATUS_MDEP
21980 C code for a data type which is used for declaring the `mdep'
21981 component of `cc_status'. It defaults to `int'.
21983 This macro is not used on machines that do not use `cc0'.
21985 -- Macro: CC_STATUS_MDEP_INIT
21986 A C expression to initialize the `mdep' field to "empty". The
21987 default definition does nothing, since most machines don't use the
21988 field anyway. If you want to use the field, you should probably
21989 define this macro to initialize it.
21991 This macro is not used on machines that do not use `cc0'.
21993 -- Macro: NOTICE_UPDATE_CC (EXP, INSN)
21994 A C compound statement to set the components of `cc_status'
21995 appropriately for an insn INSN whose body is EXP. It is this
21996 macro's responsibility to recognize insns that set the condition
21997 code as a byproduct of other activity as well as those that
21998 explicitly set `(cc0)'.
22000 This macro is not used on machines that do not use `cc0'.
22002 If there are insns that do not set the condition code but do alter
22003 other machine registers, this macro must check to see whether they
22004 invalidate the expressions that the condition code is recorded as
22005 reflecting. For example, on the 68000, insns that store in address
22006 registers do not set the condition code, which means that usually
22007 `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns.
22008 But suppose that the previous insn set the condition code based
22009 on location `a4@(102)' and the current insn stores a new value in
22010 `a4'. Although the condition code is not changed by this, it will
22011 no longer be true that it reflects the contents of `a4@(102)'.
22012 Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case
22013 to say that nothing is known about the condition code value.
22015 The definition of `NOTICE_UPDATE_CC' must be prepared to deal with
22016 the results of peephole optimization: insns whose patterns are
22017 `parallel' RTXs containing various `reg', `mem' or constants which
22018 are just the operands. The RTL structure of these insns is not
22019 sufficient to indicate what the insns actually do. What
22020 `NOTICE_UPDATE_CC' should do when it sees one is just to run
22023 A possible definition of `NOTICE_UPDATE_CC' is to call a function
22024 that looks at an attribute (*note Insn Attributes::) named, for
22025 example, `cc'. This avoids having detailed information about
22026 patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'.
22028 -- Macro: SELECT_CC_MODE (OP, X, Y)
22029 Returns a mode from class `MODE_CC' to be used when comparison
22030 operation code OP is applied to rtx X and Y. For example, on the
22031 SPARC, `SELECT_CC_MODE' is defined as (see *note Jump Patterns::
22032 for a description of the reason for this definition)
22034 #define SELECT_CC_MODE(OP,X,Y) \
22035 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \
22036 ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \
22037 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \
22038 || GET_CODE (X) == NEG) \
22039 ? CC_NOOVmode : CCmode))
22041 You should define this macro if and only if you define extra CC
22042 modes in `MACHINE-modes.def'.
22044 -- Macro: CANONICALIZE_COMPARISON (CODE, OP0, OP1)
22045 On some machines not all possible comparisons are defined, but you
22046 can convert an invalid comparison into a valid one. For example,
22047 the Alpha does not have a `GT' comparison, but you can use an `LT'
22048 comparison instead and swap the order of the operands.
22050 On such machines, define this macro to be a C statement to do any
22051 required conversions. CODE is the initial comparison code and OP0
22052 and OP1 are the left and right operands of the comparison,
22053 respectively. You should modify CODE, OP0, and OP1 as required.
22055 GCC will not assume that the comparison resulting from this macro
22056 is valid but will see if the resulting insn matches a pattern in
22059 You need not define this macro if it would never change the
22060 comparison code or operands.
22062 -- Macro: REVERSIBLE_CC_MODE (MODE)
22063 A C expression whose value is one if it is always safe to reverse a
22064 comparison whose mode is MODE. If `SELECT_CC_MODE' can ever
22065 return MODE for a floating-point inequality comparison, then
22066 `REVERSIBLE_CC_MODE (MODE)' must be zero.
22068 You need not define this macro if it would always returns zero or
22069 if the floating-point format is anything other than
22070 `IEEE_FLOAT_FORMAT'. For example, here is the definition used on
22071 the SPARC, where floating-point inequality comparisons are always
22074 #define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode)
22076 -- Macro: REVERSE_CONDITION (CODE, MODE)
22077 A C expression whose value is reversed condition code of the CODE
22078 for comparison done in CC_MODE MODE. The macro is used only in
22079 case `REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in
22080 case machine has some non-standard way how to reverse certain
22081 conditionals. For instance in case all floating point conditions
22082 are non-trapping, compiler may freely convert unordered compares
22083 to ordered one. Then definition may look like:
22085 #define REVERSE_CONDITION(CODE, MODE) \
22086 ((MODE) != CCFPmode ? reverse_condition (CODE) \
22087 : reverse_condition_maybe_unordered (CODE))
22089 -- Macro: REVERSE_CONDEXEC_PREDICATES_P (OP1, OP2)
22090 A C expression that returns true if the conditional execution
22091 predicate OP1, a comparison operation, is the inverse of OP2 and
22092 vice versa. Define this to return 0 if the target has conditional
22093 execution predicates that cannot be reversed safely. There is no
22094 need to validate that the arguments of op1 and op2 are the same,
22095 this is done separately. If no expansion is specified, this macro
22096 is defined as follows:
22098 #define REVERSE_CONDEXEC_PREDICATES_P (x, y) \
22099 (GET_CODE ((x)) == reversed_comparison_code ((y), NULL))
22101 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int *,
22103 On targets which do not use `(cc0)', and which use a hard register
22104 rather than a pseudo-register to hold condition codes, the regular
22105 CSE passes are often not able to identify cases in which the hard
22106 register is set to a common value. Use this hook to enable a
22107 small pass which optimizes such cases. This hook should return
22108 true to enable this pass, and it should set the integers to which
22109 its arguments point to the hard register numbers used for
22110 condition codes. When there is only one such register, as is true
22111 on most systems, the integer pointed to by the second argument
22112 should be set to `INVALID_REGNUM'.
22114 The default version of this hook returns false.
22116 -- Target Hook: enum machine_mode TARGET_CC_MODES_COMPATIBLE (enum
22117 machine_mode, enum machine_mode)
22118 On targets which use multiple condition code modes in class
22119 `MODE_CC', it is sometimes the case that a comparison can be
22120 validly done in more than one mode. On such a system, define this
22121 target hook to take two mode arguments and to return a mode in
22122 which both comparisons may be validly done. If there is no such
22123 mode, return `VOIDmode'.
22125 The default version of this hook checks whether the modes are the
22126 same. If they are, it returns that mode. If they are different,
22127 it returns `VOIDmode'.
22130 File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros
22132 14.15 Describing Relative Costs of Operations
22133 =============================================
22135 These macros let you describe the relative speed of various operations
22136 on the target machine.
22138 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO)
22139 A C expression for the cost of moving data of mode MODE from a
22140 register in class FROM to one in class TO. The classes are
22141 expressed using the enumeration values such as `GENERAL_REGS'. A
22142 value of 2 is the default; other values are interpreted relative to
22145 It is not required that the cost always equal 2 when FROM is the
22146 same as TO; on some machines it is expensive to move between
22147 registers if they are not general registers.
22149 If reload sees an insn consisting of a single `set' between two
22150 hard registers, and if `REGISTER_MOVE_COST' applied to their
22151 classes returns a value of 2, reload does not check to ensure that
22152 the constraints of the insn are met. Setting a cost of other than
22153 2 will allow reload to verify that the constraints are met. You
22154 should do this if the `movM' pattern's constraints do not allow
22157 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN)
22158 A C expression for the cost of moving data of mode MODE between a
22159 register of class CLASS and memory; IN is zero if the value is to
22160 be written to memory, nonzero if it is to be read in. This cost
22161 is relative to those in `REGISTER_MOVE_COST'. If moving between
22162 registers and memory is more expensive than between two registers,
22163 you should define this macro to express the relative cost.
22165 If you do not define this macro, GCC uses a default cost of 4 plus
22166 the cost of copying via a secondary reload register, if one is
22167 needed. If your machine requires a secondary reload register to
22168 copy between memory and a register of CLASS but the reload
22169 mechanism is more complex than copying via an intermediate, define
22170 this macro to reflect the actual cost of the move.
22172 GCC defines the function `memory_move_secondary_cost' if secondary
22173 reloads are needed. It computes the costs due to copying via a
22174 secondary register. If your machine copies from memory using a
22175 secondary register in the conventional way but the default base
22176 value of 4 is not correct for your machine, define this macro to
22177 add some other value to the result of that function. The
22178 arguments to that function are the same as to this macro.
22180 -- Macro: BRANCH_COST
22181 A C expression for the cost of a branch instruction. A value of 1
22182 is the default; other values are interpreted relative to that.
22184 Here are additional macros which do not specify precise relative costs,
22185 but only that certain actions are more expensive than GCC would
22188 -- Macro: SLOW_BYTE_ACCESS
22189 Define this macro as a C expression which is nonzero if accessing
22190 less than a word of memory (i.e. a `char' or a `short') is no
22191 faster than accessing a word of memory, i.e., if such access
22192 require more than one instruction or if there is no difference in
22193 cost between byte and (aligned) word loads.
22195 When this macro is not defined, the compiler will access a field by
22196 finding the smallest containing object; when it is defined, a
22197 fullword load will be used if alignment permits. Unless bytes
22198 accesses are faster than word accesses, using word accesses is
22199 preferable since it may eliminate subsequent memory access if
22200 subsequent accesses occur to other fields in the same word of the
22201 structure, but to different bytes.
22203 -- Macro: SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT)
22204 Define this macro to be the value 1 if memory accesses described
22205 by the MODE and ALIGNMENT parameters have a cost many times greater
22206 than aligned accesses, for example if they are emulated in a trap
22209 When this macro is nonzero, the compiler will act as if
22210 `STRICT_ALIGNMENT' were nonzero when generating code for block
22211 moves. This can cause significantly more instructions to be
22212 produced. Therefore, do not set this macro nonzero if unaligned
22213 accesses only add a cycle or two to the time for a memory access.
22215 If the value of this macro is always zero, it need not be defined.
22216 If this macro is defined, it should produce a nonzero value when
22217 `STRICT_ALIGNMENT' is nonzero.
22219 -- Macro: MOVE_RATIO
22220 The threshold of number of scalar memory-to-memory move insns,
22221 _below_ which a sequence of insns should be generated instead of a
22222 string move insn or a library call. Increasing the value will
22223 always make code faster, but eventually incurs high cost in
22224 increased code size.
22226 Note that on machines where the corresponding move insn is a
22227 `define_expand' that emits a sequence of insns, this macro counts
22228 the number of such sequences.
22230 If you don't define this, a reasonable default is used.
22232 -- Macro: MOVE_BY_PIECES_P (SIZE, ALIGNMENT)
22233 A C expression used to determine whether `move_by_pieces' will be
22234 used to copy a chunk of memory, or whether some other block move
22235 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns'
22236 returns less than `MOVE_RATIO'.
22238 -- Macro: MOVE_MAX_PIECES
22239 A C expression used by `move_by_pieces' to determine the largest
22240 unit a load or store used to copy memory is. Defaults to
22243 -- Macro: CLEAR_RATIO
22244 The threshold of number of scalar move insns, _below_ which a
22245 sequence of insns should be generated to clear memory instead of a
22246 string clear insn or a library call. Increasing the value will
22247 always make code faster, but eventually incurs high cost in
22248 increased code size.
22250 If you don't define this, a reasonable default is used.
22252 -- Macro: CLEAR_BY_PIECES_P (SIZE, ALIGNMENT)
22253 A C expression used to determine whether `clear_by_pieces' will be
22254 used to clear a chunk of memory, or whether some other block clear
22255 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns'
22256 returns less than `CLEAR_RATIO'.
22258 -- Macro: STORE_BY_PIECES_P (SIZE, ALIGNMENT)
22259 A C expression used to determine whether `store_by_pieces' will be
22260 used to set a chunk of memory to a constant value, or whether some
22261 other mechanism will be used. Used by `__builtin_memset' when
22262 storing values other than constant zero and by `__builtin_strcpy'
22263 when when called with a constant source string. Defaults to 1 if
22264 `move_by_pieces_ninsns' returns less than `MOVE_RATIO'.
22266 -- Macro: USE_LOAD_POST_INCREMENT (MODE)
22267 A C expression used to determine whether a load postincrement is a
22268 good thing to use for a given mode. Defaults to the value of
22269 `HAVE_POST_INCREMENT'.
22271 -- Macro: USE_LOAD_POST_DECREMENT (MODE)
22272 A C expression used to determine whether a load postdecrement is a
22273 good thing to use for a given mode. Defaults to the value of
22274 `HAVE_POST_DECREMENT'.
22276 -- Macro: USE_LOAD_PRE_INCREMENT (MODE)
22277 A C expression used to determine whether a load preincrement is a
22278 good thing to use for a given mode. Defaults to the value of
22279 `HAVE_PRE_INCREMENT'.
22281 -- Macro: USE_LOAD_PRE_DECREMENT (MODE)
22282 A C expression used to determine whether a load predecrement is a
22283 good thing to use for a given mode. Defaults to the value of
22284 `HAVE_PRE_DECREMENT'.
22286 -- Macro: USE_STORE_POST_INCREMENT (MODE)
22287 A C expression used to determine whether a store postincrement is
22288 a good thing to use for a given mode. Defaults to the value of
22289 `HAVE_POST_INCREMENT'.
22291 -- Macro: USE_STORE_POST_DECREMENT (MODE)
22292 A C expression used to determine whether a store postdecrement is
22293 a good thing to use for a given mode. Defaults to the value of
22294 `HAVE_POST_DECREMENT'.
22296 -- Macro: USE_STORE_PRE_INCREMENT (MODE)
22297 This macro is used to determine whether a store preincrement is a
22298 good thing to use for a given mode. Defaults to the value of
22299 `HAVE_PRE_INCREMENT'.
22301 -- Macro: USE_STORE_PRE_DECREMENT (MODE)
22302 This macro is used to determine whether a store predecrement is a
22303 good thing to use for a given mode. Defaults to the value of
22304 `HAVE_PRE_DECREMENT'.
22306 -- Macro: NO_FUNCTION_CSE
22307 Define this macro if it is as good or better to call a constant
22308 function address than to call an address kept in a register.
22310 -- Macro: RANGE_TEST_NON_SHORT_CIRCUIT
22311 Define this macro if a non-short-circuit operation produced by
22312 `fold_range_test ()' is optimal. This macro defaults to true if
22313 `BRANCH_COST' is greater than or equal to the value 2.
22315 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, int CODE, int
22316 OUTER_CODE, int *TOTAL)
22317 This target hook describes the relative costs of RTL expressions.
22319 The cost may depend on the precise form of the expression, which is
22320 available for examination in X, and the rtx code of the expression
22321 in which it is contained, found in OUTER_CODE. CODE is the
22322 expression code--redundant, since it can be obtained with
22325 In implementing this hook, you can use the construct
22326 `COSTS_N_INSNS (N)' to specify a cost equal to N fast instructions.
22328 On entry to the hook, `*TOTAL' contains a default estimate for the
22329 cost of the expression. The hook should modify this value as
22330 necessary. Traditionally, the default costs are `COSTS_N_INSNS
22331 (5)' for multiplications, `COSTS_N_INSNS (7)' for division and
22332 modulus operations, and `COSTS_N_INSNS (1)' for all other
22335 When optimizing for code size, i.e. when `optimize_size' is
22336 nonzero, this target hook should be used to estimate the relative
22337 size cost of an expression, again relative to `COSTS_N_INSNS'.
22339 The hook returns true when all subexpressions of X have been
22340 processed, and false when `rtx_cost' should recurse.
22342 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS)
22343 This hook computes the cost of an addressing mode that contains
22344 ADDRESS. If not defined, the cost is computed from the ADDRESS
22345 expression and the `TARGET_RTX_COST' hook.
22347 For most CISC machines, the default cost is a good approximation
22348 of the true cost of the addressing mode. However, on RISC
22349 machines, all instructions normally have the same length and
22350 execution time. Hence all addresses will have equal costs.
22352 In cases where more than one form of an address is known, the form
22353 with the lowest cost will be used. If multiple forms have the
22354 same, lowest, cost, the one that is the most complex will be used.
22356 For example, suppose an address that is equal to the sum of a
22357 register and a constant is used twice in the same basic block.
22358 When this macro is not defined, the address will be computed in a
22359 register and memory references will be indirect through that
22360 register. On machines where the cost of the addressing mode
22361 containing the sum is no higher than that of a simple indirect
22362 reference, this will produce an additional instruction and
22363 possibly require an additional register. Proper specification of
22364 this macro eliminates this overhead for such machines.
22366 This hook is never called with an invalid address.
22368 On machines where an address involving more than one register is as
22369 cheap as an address computation involving only one register,
22370 defining `TARGET_ADDRESS_COST' to reflect this can cause two
22371 registers to be live over a region of code where only one would
22372 have been if `TARGET_ADDRESS_COST' were not defined in that
22373 manner. This effect should be considered in the definition of
22374 this macro. Equivalent costs should probably only be given to
22375 addresses with different numbers of registers on machines with
22379 File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros
22381 14.16 Adjusting the Instruction Scheduler
22382 =========================================
22384 The instruction scheduler may need a fair amount of machine-specific
22385 adjustment in order to produce good code. GCC provides several target
22386 hooks for this purpose. It is usually enough to define just a few of
22387 them: try the first ones in this list first.
22389 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void)
22390 This hook returns the maximum number of instructions that can ever
22391 issue at the same time on the target machine. The default is one.
22392 Although the insn scheduler can define itself the possibility of
22393 issue an insn on the same cycle, the value can serve as an
22394 additional constraint to issue insns on the same simulated
22395 processor cycle (see hooks `TARGET_SCHED_REORDER' and
22396 `TARGET_SCHED_REORDER2'). This value must be constant over the
22397 entire compilation. If you need it to vary depending on what the
22398 instructions are, you must use `TARGET_SCHED_VARIABLE_ISSUE'.
22400 You could define this hook to return the value of the macro
22401 `MAX_DFA_ISSUE_RATE'.
22403 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int
22404 VERBOSE, rtx INSN, int MORE)
22405 This hook is executed by the scheduler after it has scheduled an
22406 insn from the ready list. It should return the number of insns
22407 which can still be issued in the current cycle. The default is
22408 `MORE - 1' for insns other than `CLOBBER' and `USE', which
22409 normally are not counted against the issue rate. You should
22410 define this hook if some insns take more machine resources than
22411 others, so that fewer insns can follow them in the same cycle.
22412 FILE is either a null pointer, or a stdio stream to write any
22413 debug output to. VERBOSE is the verbose level provided by
22414 `-fsched-verbose-N'. INSN is the instruction that was scheduled.
22416 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx INSN, rtx LINK, rtx
22417 DEP_INSN, int COST)
22418 This function corrects the value of COST based on the relationship
22419 between INSN and DEP_INSN through the dependence LINK. It should
22420 return the new value. The default is to make no adjustment to
22421 COST. This can be used for example to specify to the scheduler
22422 using the traditional pipeline description that an output- or
22423 anti-dependence does not incur the same cost as a data-dependence.
22424 If the scheduler using the automaton based pipeline description,
22425 the cost of anti-dependence is zero and the cost of
22426 output-dependence is maximum of one and the difference of latency
22427 times of the first and the second insns. If these values are not
22428 acceptable, you could use the hook to modify them too. See also
22429 *note Processor pipeline description::.
22431 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx INSN, int
22433 This hook adjusts the integer scheduling priority PRIORITY of
22434 INSN. It should return the new priority. Reduce the priority to
22435 execute INSN earlier, increase the priority to execute INSN later.
22436 Do not define this hook if you do not need to adjust the
22437 scheduling priorities of insns.
22439 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, rtx
22440 *READY, int *N_READYP, int CLOCK)
22441 This hook is executed by the scheduler after it has scheduled the
22442 ready list, to allow the machine description to reorder it (for
22443 example to combine two small instructions together on `VLIW'
22444 machines). FILE is either a null pointer, or a stdio stream to
22445 write any debug output to. VERBOSE is the verbose level provided
22446 by `-fsched-verbose-N'. READY is a pointer to the ready list of
22447 instructions that are ready to be scheduled. N_READYP is a
22448 pointer to the number of elements in the ready list. The scheduler
22449 reads the ready list in reverse order, starting with
22450 READY[*N_READYP-1] and going to READY[0]. CLOCK is the timer tick
22451 of the scheduler. You may modify the ready list and the number of
22452 ready insns. The return value is the number of insns that can
22453 issue this cycle; normally this is just `issue_rate'. See also
22454 `TARGET_SCHED_REORDER2'.
22456 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE,
22457 rtx *READY, int *N_READY, CLOCK)
22458 Like `TARGET_SCHED_REORDER', but called at a different time. That
22459 function is called whenever the scheduler starts a new cycle.
22460 This one is called once per iteration over a cycle, immediately
22461 after `TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list
22462 and return the number of insns to be scheduled in the same cycle.
22463 Defining this hook can be useful if there are frequent situations
22464 where scheduling one insn causes other insns to become ready in
22465 the same cycle. These other insns can then be taken into account
22468 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK (rtx
22470 This hook is called after evaluation forward dependencies of insns
22471 in chain given by two parameter values (HEAD and TAIL
22472 correspondingly) but before insns scheduling of the insn chain.
22473 For example, it can be used for better insn classification if it
22474 requires analysis of dependencies. This hook can use backward and
22475 forward dependencies of the insn scheduler because they are already
22478 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int
22480 This hook is executed by the scheduler at the beginning of each
22481 block of instructions that are to be scheduled. FILE is either a
22482 null pointer, or a stdio stream to write any debug output to.
22483 VERBOSE is the verbose level provided by `-fsched-verbose-N'.
22484 MAX_READY is the maximum number of insns in the current scheduling
22485 region that can be live at the same time. This can be used to
22486 allocate scratch space if it is needed, e.g. by
22487 `TARGET_SCHED_REORDER'.
22489 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE)
22490 This hook is executed by the scheduler at the end of each block of
22491 instructions that are to be scheduled. It can be used to perform
22492 cleanup of any actions done by the other scheduling hooks. FILE
22493 is either a null pointer, or a stdio stream to write any debug
22494 output to. VERBOSE is the verbose level provided by
22495 `-fsched-verbose-N'.
22497 -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int
22498 VERBOSE, int OLD_MAX_UID)
22499 This hook is executed by the scheduler after function level
22500 initializations. FILE is either a null pointer, or a stdio stream
22501 to write any debug output to. VERBOSE is the verbose level
22502 provided by `-fsched-verbose-N'. OLD_MAX_UID is the maximum insn
22503 uid when scheduling begins.
22505 -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int
22507 This is the cleanup hook corresponding to
22508 `TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a
22509 stdio stream to write any debug output to. VERBOSE is the verbose
22510 level provided by `-fsched-verbose-N'.
22512 -- Target Hook: int TARGET_SCHED_DFA_PRE_CYCLE_INSN (void)
22513 The hook returns an RTL insn. The automaton state used in the
22514 pipeline hazard recognizer is changed as if the insn were scheduled
22515 when the new simulated processor cycle starts. Usage of the hook
22516 may simplify the automaton pipeline description for some VLIW
22517 processors. If the hook is defined, it is used only for the
22518 automaton based pipeline description. The default is not to
22519 change the state when the new simulated processor cycle starts.
22521 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void)
22522 The hook can be used to initialize data used by the previous hook.
22524 -- Target Hook: int TARGET_SCHED_DFA_POST_CYCLE_INSN (void)
22525 The hook is analogous to `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used
22526 to changed the state as if the insn were scheduled when the new
22527 simulated processor cycle finishes.
22529 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void)
22530 The hook is analogous to `TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but
22531 used to initialize data used by the previous hook.
22533 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD
22535 This hook controls better choosing an insn from the ready insn
22536 queue for the DFA-based insn scheduler. Usually the scheduler
22537 chooses the first insn from the queue. If the hook returns a
22538 positive value, an additional scheduler code tries all
22539 permutations of `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD
22540 ()' subsequent ready insns to choose an insn whose issue will
22541 result in maximal number of issued insns on the same cycle. For
22542 the VLIW processor, the code could actually solve the problem of
22543 packing simple insns into the VLIW insn. Of course, if the rules
22544 of VLIW packing are described in the automaton.
22546 This code also could be used for superscalar RISC processors. Let
22547 us consider a superscalar RISC processor with 3 pipelines. Some
22548 insns can be executed in pipelines A or B, some insns can be
22549 executed only in pipelines B or C, and one insn can be executed in
22550 pipeline B. The processor may issue the 1st insn into A and the
22551 2nd one into B. In this case, the 3rd insn will wait for freeing B
22552 until the next cycle. If the scheduler issues the 3rd insn the
22553 first, the processor could issue all 3 insns per cycle.
22555 Actually this code demonstrates advantages of the automaton based
22556 pipeline hazard recognizer. We try quickly and easy many insn
22557 schedules to choose the best one.
22559 The default is no multipass scheduling.
22561 -- Target Hook: int
22562 TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD (rtx)
22563 This hook controls what insns from the ready insn queue will be
22564 considered for the multipass insn scheduling. If the hook returns
22565 zero for insn passed as the parameter, the insn will be not chosen
22568 The default is that any ready insns can be chosen to be issued.
22570 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *, int, rtx, int,
22572 This hook is called by the insn scheduler before issuing insn
22573 passed as the third parameter on given cycle. If the hook returns
22574 nonzero, the insn is not issued on given processors cycle.
22575 Instead of that, the processor cycle is advanced. If the value
22576 passed through the last parameter is zero, the insn ready queue is
22577 not sorted on the new cycle start as usually. The first parameter
22578 passes file for debugging output. The second one passes the
22579 scheduler verbose level of the debugging output. The forth and
22580 the fifth parameter values are correspondingly processor cycle on
22581 which the previous insn has been issued and the current processor
22584 -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (rtx INSN1, rtx
22585 INSN2, rtx DEP_LINK, int DEP_COST, int DISTANCE)
22586 This hook is used to define which dependences are considered
22587 costly by the target, so costly that it is not advisable to
22588 schedule the insns that are involved in the dependence too close
22589 to one another. The parameters to this hook are as follows: The
22590 second parameter INSN2 is dependent upon the first parameter
22591 INSN1. The dependence between INSN1 and INSN2 is represented by
22592 the third parameter DEP_LINK. The fourth parameter COST is the
22593 cost of the dependence, and the fifth parameter DISTANCE is the
22594 distance in cycles between the two insns. The hook returns `true'
22595 if considering the distance between the two insns the dependence
22596 between them is considered costly by the target, and `false'
22599 Defining this hook can be useful in multiple-issue out-of-order
22600 machines, where (a) it's practically hopeless to predict the
22601 actual data/resource delays, however: (b) there's a better chance
22602 to predict the actual grouping that will be formed, and (c)
22603 correctly emulating the grouping can be very important. In such
22604 targets one may want to allow issuing dependent insns closer to
22605 one another--i.e., closer than the dependence distance; however,
22606 not in cases of "costly dependences", which this hooks allows to
22609 Macros in the following table are generated by the program `genattr'
22610 and can be useful for writing the hooks.
22612 -- Macro: MAX_DFA_ISSUE_RATE
22613 The macro definition is generated in the automaton based pipeline
22614 description interface. Its value is calculated from the automaton
22615 based pipeline description and is equal to maximal number of all
22616 insns described in constructions `define_insn_reservation' which
22617 can be issued on the same processor cycle.
22620 File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros
22622 14.17 Dividing the Output into Sections (Texts, Data, ...)
22623 ==========================================================
22625 An object file is divided into sections containing different types of
22626 data. In the most common case, there are three sections: the "text
22627 section", which holds instructions and read-only data; the "data
22628 section", which holds initialized writable data; and the "bss section",
22629 which holds uninitialized data. Some systems have other kinds of
22632 The compiler must tell the assembler when to switch sections. These
22633 macros control what commands to output to tell the assembler this. You
22634 can also define additional sections.
22636 -- Macro: TEXT_SECTION_ASM_OP
22637 A C expression whose value is a string, including spacing,
22638 containing the assembler operation that should precede
22639 instructions and read-only data. Normally `"\t.text"' is right.
22641 -- Macro: HOT_TEXT_SECTION_NAME
22642 If defined, a C string constant for the name of the section
22643 containing most frequently executed functions of the program. If
22644 not defined, GCC will provide a default definition if the target
22645 supports named sections.
22647 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME
22648 If defined, a C string constant for the name of the section
22649 containing unlikely executed functions in the program.
22651 -- Macro: DATA_SECTION_ASM_OP
22652 A C expression whose value is a string, including spacing,
22653 containing the assembler operation to identify the following data
22654 as writable initialized data. Normally `"\t.data"' is right.
22656 -- Macro: READONLY_DATA_SECTION_ASM_OP
22657 A C expression whose value is a string, including spacing,
22658 containing the assembler operation to identify the following data
22659 as read-only initialized data.
22661 -- Macro: READONLY_DATA_SECTION
22662 A macro naming a function to call to switch to the proper section
22663 for read-only data. The default is to use
22664 `READONLY_DATA_SECTION_ASM_OP' if defined, else fall back to
22667 The most common definition will be `data_section', if the target
22668 does not have a special read-only data section, and does not put
22669 data in the text section.
22671 -- Macro: BSS_SECTION_ASM_OP
22672 If defined, a C expression whose value is a string, including
22673 spacing, containing the assembler operation to identify the
22674 following data as uninitialized global data. If not defined, and
22675 neither `ASM_OUTPUT_BSS' nor `ASM_OUTPUT_ALIGNED_BSS' are defined,
22676 uninitialized global data will be output in the data section if
22677 `-fno-common' is passed, otherwise `ASM_OUTPUT_COMMON' will be
22680 -- Macro: INIT_SECTION_ASM_OP
22681 If defined, a C expression whose value is a string, including
22682 spacing, containing the assembler operation to identify the
22683 following data as initialization code. If not defined, GCC will
22684 assume such a section does not exist.
22686 -- Macro: FINI_SECTION_ASM_OP
22687 If defined, a C expression whose value is a string, including
22688 spacing, containing the assembler operation to identify the
22689 following data as finalization code. If not defined, GCC will
22690 assume such a section does not exist.
22692 -- Macro: INIT_ARRAY_SECTION_ASM_OP
22693 If defined, a C expression whose value is a string, including
22694 spacing, containing the assembler operation to identify the
22695 following data as part of the `.init_array' (or equivalent)
22696 section. If not defined, GCC will assume such a section does not
22697 exist. Do not define both this macro and `INIT_SECTION_ASM_OP'.
22699 -- Macro: FINI_ARRAY_SECTION_ASM_OP
22700 If defined, a C expression whose value is a string, including
22701 spacing, containing the assembler operation to identify the
22702 following data as part of the `.fini_array' (or equivalent)
22703 section. If not defined, GCC will assume such a section does not
22704 exist. Do not define both this macro and `FINI_SECTION_ASM_OP'.
22706 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION)
22707 If defined, an ASM statement that switches to a different section
22708 via SECTION_OP, calls FUNCTION, and switches back to the text
22709 section. This is used in `crtstuff.c' if `INIT_SECTION_ASM_OP' or
22710 `FINI_SECTION_ASM_OP' to calls to initialization and finalization
22711 functions from the init and fini sections. By default, this macro
22712 uses a simple function call. Some ports need hand-crafted
22713 assembly code to avoid dependencies on registers initialized in
22714 the function prologue or to ensure that constant pools don't end
22715 up too far way in the text section.
22717 -- Macro: FORCE_CODE_SECTION_ALIGN
22718 If defined, an ASM statement that aligns a code section to some
22719 arbitrary boundary. This is used to force all fragments of the
22720 `.init' and `.fini' sections to have to same alignment and thus
22721 prevent the linker from having to add any padding.
22723 -- Macro: EXTRA_SECTIONS
22724 A list of names for sections other than the standard two, which are
22725 `in_text' and `in_data'. You need not define this macro on a
22726 system with no other sections (that GCC needs to use).
22728 -- Macro: EXTRA_SECTION_FUNCTIONS
22729 One or more functions to be defined in `varasm.c'. These
22730 functions should do jobs analogous to those of `text_section' and
22731 `data_section', for your additional sections. Do not define this
22732 macro if you do not define `EXTRA_SECTIONS'.
22734 -- Macro: JUMP_TABLES_IN_TEXT_SECTION
22735 Define this macro to be an expression with a nonzero value if jump
22736 tables (for `tablejump' insns) should be output in the text
22737 section, along with the assembler instructions. Otherwise, the
22738 readonly data section is used.
22740 This macro is irrelevant if there is no separate readonly data
22743 -- Target Hook: void TARGET_ASM_SELECT_SECTION (tree EXP, int RELOC,
22744 unsigned HOST_WIDE_INT ALIGN)
22745 Switches to the appropriate section for output of EXP. You can
22746 assume that EXP is either a `VAR_DECL' node or a constant of some
22747 sort. RELOC indicates whether the initial value of EXP requires
22748 link-time relocations. Bit 0 is set when variable contains local
22749 relocations only, while bit 1 is set for global relocations.
22750 Select the section by calling `data_section' or one of the
22751 alternatives for other sections. ALIGN is the constant alignment
22754 The default version of this function takes care of putting
22755 read-only variables in `readonly_data_section'.
22757 See also USE_SELECT_SECTION_FOR_FUNCTIONS.
22759 -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS
22760 Define this macro if you wish TARGET_ASM_SELECT_SECTION to be
22761 called for `FUNCTION_DECL's as well as for variables and constants.
22763 In the case of a `FUNCTION_DECL', RELOC will be zero if the
22764 function has been determined to be likely to be called, and
22765 nonzero if it is unlikely to be called.
22767 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC)
22768 Build up a unique section name, expressed as a `STRING_CST' node,
22769 and assign it to `DECL_SECTION_NAME (DECL)'. As with
22770 `TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial
22771 value of EXP requires link-time relocations.
22773 The default version of this function appends the symbol name to the
22774 ELF section name that would normally be used for the symbol. For
22775 example, the function `foo' would be placed in `.text.foo'.
22776 Whatever the actual target object format, this is often good
22779 -- Target Hook: void TARGET_ASM_FUNCTION_RODATA_SECTION (tree DECL)
22780 Switches to a readonly data section associated with
22781 `DECL_SECTION_NAME (DECL)'. The default version of this function
22782 switches to `.gnu.linkonce.r.name' section if function's section
22783 is `.gnu.linkonce.t.name', to `.rodata.name' if function is in
22784 `.text.name' section and otherwise switches to the normal readonly
22787 -- Target Hook: void TARGET_ASM_SELECT_RTX_SECTION (enum machine_mode
22788 MODE, rtx X, unsigned HOST_WIDE_INT ALIGN)
22789 Switches to the appropriate section for output of constant pool
22790 entry X in MODE. You can assume that X is some kind of constant
22791 in RTL. The argument MODE is redundant except in the case of a
22792 `const_int' rtx. Select the section by calling
22793 `readonly_data_section' or one of the alternatives for other
22794 sections. ALIGN is the constant alignment in bits.
22796 The default version of this function takes care of putting symbolic
22797 constants in `flag_pic' mode in `data_section' and everything else
22798 in `readonly_data_section'.
22800 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL,
22802 Define this hook if references to a symbol or a constant must be
22803 treated differently depending on something about the variable or
22804 function named by the symbol (such as what section it is in).
22806 The hook is executed immediately after rtl has been created for
22807 DECL, which may be a variable or function declaration or an entry
22808 in the constant pool. In either case, RTL is the rtl in question.
22809 Do _not_ use `DECL_RTL (DECL)' in this hook; that field may not
22810 have been initialized yet.
22812 In the case of a constant, it is safe to assume that the rtl is a
22813 `mem' whose address is a `symbol_ref'. Most decls will also have
22814 this form, but that is not guaranteed. Global register variables,
22815 for instance, will have a `reg' for their rtl. (Normally the
22816 right thing to do with such unusual rtl is leave it alone.)
22818 The NEW_DECL_P argument will be true if this is the first time
22819 that `TARGET_ENCODE_SECTION_INFO' has been invoked on this decl.
22820 It will be false for subsequent invocations, which will happen for
22821 duplicate declarations. Whether or not anything must be done for
22822 the duplicate declaration depends on whether the hook examines
22823 `DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is
22824 called for a constant.
22826 The usual thing for this hook to do is to record flags in the
22827 `symbol_ref', using `SYMBOL_REF_FLAG' or `SYMBOL_REF_FLAGS'.
22828 Historically, the name string was modified if it was necessary to
22829 encode more than one bit of information, but this practice is now
22830 discouraged; use `SYMBOL_REF_FLAGS'.
22832 The default definition of this hook, `default_encode_section_info'
22833 in `varasm.c', sets a number of commonly-useful bits in
22834 `SYMBOL_REF_FLAGS'. Check whether the default does what you need
22835 before overriding it.
22837 -- Target Hook: const char *TARGET_STRIP_NAME_ENCODING (const char
22839 Decode NAME and return the real name part, sans the characters
22840 that `TARGET_ENCODE_SECTION_INFO' may have added.
22842 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (tree EXP)
22843 Returns true if EXP should be placed into a "small data" section.
22844 The default version of this hook always returns false.
22846 -- Variable: Target Hook bool TARGET_HAVE_SRODATA_SECTION
22847 Contains the value true if the target places read-only "small
22848 data" into a separate section. The default value is false.
22850 -- Target Hook: bool TARGET_BINDS_LOCAL_P (tree EXP)
22851 Returns true if EXP names an object for which name resolution
22852 rules must resolve to the current "module" (dynamic shared library
22853 or executable image).
22855 The default version of this hook implements the name resolution
22856 rules for ELF, which has a looser model of global name binding
22857 than other currently supported object file formats.
22859 -- Variable: Target Hook bool TARGET_HAVE_TLS
22860 Contains the value true if the target supports thread-local
22861 storage. The default value is false.
22864 File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros
22866 14.18 Position Independent Code
22867 ===============================
22869 This section describes macros that help implement generation of position
22870 independent code. Simply defining these macros is not enough to
22871 generate valid PIC; you must also add support to the macros
22872 `GO_IF_LEGITIMATE_ADDRESS' and `PRINT_OPERAND_ADDRESS', as well as
22873 `LEGITIMIZE_ADDRESS'. You must modify the definition of `movsi' to do
22874 something appropriate when the source operand contains a symbolic
22875 address. You may also need to alter the handling of switch statements
22876 so that they use relative addresses.
22878 -- Macro: PIC_OFFSET_TABLE_REGNUM
22879 The register number of the register used to address a table of
22880 static data addresses in memory. In some cases this register is
22881 defined by a processor's "application binary interface" (ABI).
22882 When this macro is defined, RTL is generated for this register
22883 once, as with the stack pointer and frame pointer registers. If
22884 this macro is not defined, it is up to the machine-dependent files
22885 to allocate such a register (if necessary). Note that this
22886 register must be fixed when in use (e.g. when `flag_pic' is true).
22888 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED
22889 Define this macro if the register defined by
22890 `PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. Do not define
22891 this macro if `PIC_OFFSET_TABLE_REGNUM' is not defined.
22893 -- Macro: LEGITIMATE_PIC_OPERAND_P (X)
22894 A C expression that is nonzero if X is a legitimate immediate
22895 operand on the target machine when generating position independent
22896 code. You can assume that X satisfies `CONSTANT_P', so you need
22897 not check this. You can also assume FLAG_PIC is true, so you need
22898 not check it either. You need not define this macro if all
22899 constants (including `SYMBOL_REF') can be immediate operands when
22900 generating position independent code.
22903 File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros
22905 14.19 Defining the Output Assembler Language
22906 ============================================
22908 This section describes macros whose principal purpose is to describe how
22909 to write instructions in assembler language--rather than what the
22914 * File Framework:: Structural information for the assembler file.
22915 * Data Output:: Output of constants (numbers, strings, addresses).
22916 * Uninitialized Data:: Output of uninitialized variables.
22917 * Label Output:: Output and generation of labels.
22918 * Initialization:: General principles of initialization
22919 and termination routines.
22920 * Macros for Initialization::
22921 Specific macros that control the handling of
22922 initialization and termination routines.
22923 * Instruction Output:: Output of actual instructions.
22924 * Dispatch Tables:: Output of jump tables.
22925 * Exception Region Output:: Output of exception region code.
22926 * Alignment Output:: Pseudo ops for alignment and skipping data.
22929 File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format
22931 14.19.1 The Overall Framework of an Assembler File
22932 --------------------------------------------------
22934 This describes the overall framework of an assembly file.
22936 -- Target Hook: void TARGET_ASM_FILE_START ()
22937 Output to `asm_out_file' any text which the assembler expects to
22938 find at the beginning of a file. The default behavior is
22939 controlled by two flags, documented below. Unless your target's
22940 assembler is quite unusual, if you override the default, you
22941 should call `default_file_start' at some point in your target
22942 hook. This lets other target files rely on these variables.
22944 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF
22945 If this flag is true, the text of the macro `ASM_APP_OFF' will be
22946 printed as the very first line in the assembly file, unless
22947 `-fverbose-asm' is in effect. (If that macro has been defined to
22948 the empty string, this variable has no effect.) With the normal
22949 definition of `ASM_APP_OFF', the effect is to notify the GNU
22950 assembler that it need not bother stripping comments or extra
22951 whitespace from its input. This allows it to work a bit faster.
22953 The default is false. You should not set it to true unless you
22954 have verified that your port does not generate any extra
22955 whitespace or comments that will cause GAS to issue errors in
22958 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE
22959 If this flag is true, `output_file_directive' will be called for
22960 the primary source file, immediately after printing `ASM_APP_OFF'
22961 (if that is enabled). Most ELF assemblers expect this to be done.
22962 The default is false.
22964 -- Target Hook: void TARGET_ASM_FILE_END ()
22965 Output to `asm_out_file' any text which the assembler expects to
22966 find at the end of a file. The default is to output nothing.
22968 -- Function: void file_end_indicate_exec_stack ()
22969 Some systems use a common convention, the `.note.GNU-stack'
22970 special section, to indicate whether or not an object file relies
22971 on the stack being executable. If your system uses this
22972 convention, you should define `TARGET_ASM_FILE_END' to this
22973 function. If you need to do other things in that hook, have your
22974 hook function call this function.
22976 -- Macro: ASM_COMMENT_START
22977 A C string constant describing how to begin a comment in the target
22978 assembler language. The compiler assumes that the comment will
22979 end at the end of the line.
22981 -- Macro: ASM_APP_ON
22982 A C string constant for text to be output before each `asm'
22983 statement or group of consecutive ones. Normally this is
22984 `"#APP"', which is a comment that has no effect on most assemblers
22985 but tells the GNU assembler that it must check the lines that
22986 follow for all valid assembler constructs.
22988 -- Macro: ASM_APP_OFF
22989 A C string constant for text to be output after each `asm'
22990 statement or group of consecutive ones. Normally this is
22991 `"#NO_APP"', which tells the GNU assembler to resume making the
22992 time-saving assumptions that are valid for ordinary compiler
22995 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME)
22996 A C statement to output COFF information or DWARF debugging
22997 information which indicates that filename NAME is the current
22998 source file to the stdio stream STREAM.
23000 This macro need not be defined if the standard form of output for
23001 the file format in use is appropriate.
23003 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING)
23004 A C statement to output the string STRING to the stdio stream
23005 STREAM. If you do not call the function `output_quoted_string' in
23006 your config files, GCC will only call it to output filenames to
23007 the assembler source. So you can use it to canonicalize the format
23008 of the filename using this macro.
23010 -- Macro: ASM_OUTPUT_IDENT (STREAM, STRING)
23011 A C statement to output something to the assembler file to handle a
23012 `#ident' directive containing the text STRING. If this macro is
23013 not defined, nothing is output for a `#ident' directive.
23015 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME,
23016 unsigned int FLAGS, unsigned int ALIGN)
23017 Output assembly directives to switch to section NAME. The section
23018 should have attributes as specified by FLAGS, which is a bit mask
23019 of the `SECTION_*' flags defined in `output.h'. If ALIGN is
23020 nonzero, it contains an alignment in bytes to be used for the
23021 section, otherwise some target default should be used. Only
23022 targets that must specify an alignment within the section
23023 directive need pay attention to ALIGN - we will still use
23024 `ASM_OUTPUT_ALIGN'.
23026 -- Target Hook: bool TARGET_HAVE_NAMED_SECTIONS
23027 This flag is true if the target supports
23028 `TARGET_ASM_NAMED_SECTION'.
23030 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL,
23031 const char *NAME, int RELOC)
23032 Choose a set of section attributes for use by
23033 `TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a
23034 section name, and whether or not the declaration's initializer may
23035 contain runtime relocations. DECL may be null, in which case
23036 read-write data should be assumed.
23038 The default version if this function handles choosing code vs data,
23039 read-only vs read-write data, and `flag_pic'. You should only
23040 need to override this if your target has special flags that might
23041 be set via `__attribute__'.
23044 File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format
23046 14.19.2 Output of Data
23047 ----------------------
23049 -- Target Hook: const char * TARGET_ASM_BYTE_OP
23050 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP
23051 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP
23052 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP
23053 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP
23054 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP
23055 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP
23056 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP
23057 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP
23058 These hooks specify assembly directives for creating certain kinds
23059 of integer object. The `TARGET_ASM_BYTE_OP' directive creates a
23060 byte-sized object, the `TARGET_ASM_ALIGNED_HI_OP' one creates an
23061 aligned two-byte object, and so on. Any of the hooks may be
23062 `NULL', indicating that no suitable directive is available.
23064 The compiler will print these strings at the start of a new line,
23065 followed immediately by the object's initial value. In most cases,
23066 the string should contain a tab, a pseudo-op, and then another tab.
23068 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int
23070 The `assemble_integer' function uses this hook to output an
23071 integer object. X is the object's value, SIZE is its size in
23072 bytes and ALIGNED_P indicates whether it is aligned. The function
23073 should return `true' if it was able to output the object. If it
23074 returns false, `assemble_integer' will try to split the object
23075 into smaller parts.
23077 The default implementation of this hook will use the
23078 `TARGET_ASM_BYTE_OP' family of strings, returning `false' when the
23079 relevant string is `NULL'.
23081 -- Macro: OUTPUT_ADDR_CONST_EXTRA (STREAM, X, FAIL)
23082 A C statement to recognize RTX patterns that `output_addr_const'
23083 can't deal with, and output assembly code to STREAM corresponding
23084 to the pattern X. This may be used to allow machine-dependent
23085 `UNSPEC's to appear within constants.
23087 If `OUTPUT_ADDR_CONST_EXTRA' fails to recognize a pattern, it must
23088 `goto fail', so that a standard error message is printed. If it
23089 prints an error message itself, by calling, for example,
23090 `output_operand_lossage', it may just complete normally.
23092 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN)
23093 A C statement to output to the stdio stream STREAM an assembler
23094 instruction to assemble a string constant containing the LEN bytes
23095 at PTR. PTR will be a C expression of type `char *' and LEN a C
23096 expression of type `int'.
23098 If the assembler has a `.ascii' pseudo-op as found in the Berkeley
23099 Unix assembler, do not define the macro `ASM_OUTPUT_ASCII'.
23101 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N)
23102 A C statement to output word N of a function descriptor for DECL.
23103 This must be defined if `TARGET_VTABLE_USES_DESCRIPTORS' is
23104 defined, and is otherwise unused.
23106 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION
23107 You may define this macro as a C expression. You should define the
23108 expression to have a nonzero value if GCC should output the
23109 constant pool for a function before the code for the function, or
23110 a zero value if GCC should output the constant pool after the
23111 function. If you do not define this macro, the usual case, GCC
23112 will output the constant pool before the function.
23114 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE)
23115 A C statement to output assembler commands to define the start of
23116 the constant pool for a function. FUNNAME is a string giving the
23117 name of the function. Should the return type of the function be
23118 required, it can be obtained via FUNDECL. SIZE is the size, in
23119 bytes, of the constant pool that will be written immediately after
23122 If no constant-pool prefix is required, the usual case, this macro
23123 need not be defined.
23125 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN,
23127 A C statement (with or without semicolon) to output a constant in
23128 the constant pool, if it needs special treatment. (This macro
23129 need not do anything for RTL expressions that can be output
23132 The argument FILE is the standard I/O stream to output the
23133 assembler code on. X is the RTL expression for the constant to
23134 output, and MODE is the machine mode (in case X is a `const_int').
23135 ALIGN is the required alignment for the value X; you should
23136 output an assembler directive to force this much alignment.
23138 The argument LABELNO is a number to use in an internal label for
23139 the address of this pool entry. The definition of this macro is
23140 responsible for outputting the label definition at the proper
23141 place. Here is how to do this:
23143 `(*targetm.asm_out.internal_label)' (FILE, "LC", LABELNO);
23145 When you output a pool entry specially, you should end with a
23146 `goto' to the label JUMPTO. This will prevent the same pool entry
23147 from being output a second time in the usual manner.
23149 You need not define this macro if it would do nothing.
23151 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE)
23152 A C statement to output assembler commands to at the end of the
23153 constant pool for a function. FUNNAME is a string giving the name
23154 of the function. Should the return type of the function be
23155 required, you can obtain it via FUNDECL. SIZE is the size, in
23156 bytes, of the constant pool that GCC wrote immediately before this
23159 If no constant-pool epilogue is required, the usual case, you need
23160 not define this macro.
23162 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C)
23163 Define this macro as a C expression which is nonzero if C is used
23164 as a logical line separator by the assembler.
23166 If you do not define this macro, the default is that only the
23167 character `;' is treated as a logical line separator.
23169 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN
23170 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN
23171 These target hooks are C string constants, describing the syntax
23172 in the assembler for grouping arithmetic expressions. If not
23173 overridden, they default to normal parentheses, which is correct
23174 for most assemblers.
23176 These macros are provided by `real.h' for writing the definitions of
23177 `ASM_OUTPUT_DOUBLE' and the like:
23179 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L)
23180 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L)
23181 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L)
23182 These translate X, of type `REAL_VALUE_TYPE', to the target's
23183 floating point representation, and store its bit pattern in the
23184 variable L. For `REAL_VALUE_TO_TARGET_SINGLE', this variable
23185 should be a simple `long int'. For the others, it should be an
23186 array of `long int'. The number of elements in this array is
23187 determined by the size of the desired target floating point data
23188 type: 32 bits of it go in each `long int' array element. Each
23189 array element holds 32 bits of the result, even if `long int' is
23190 wider than 32 bits on the host machine.
23192 The array element values are designed so that you can print them
23193 out using `fprintf' in the order they should appear in the target
23197 File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format
23199 14.19.3 Output of Uninitialized Variables
23200 -----------------------------------------
23202 Each of the macros in this section is used to do the whole job of
23203 outputting a single uninitialized variable.
23205 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED)
23206 A C statement (sans semicolon) to output to the stdio stream
23207 STREAM the assembler definition of a common-label named NAME whose
23208 size is SIZE bytes. The variable ROUNDED is the size rounded up
23209 to whatever alignment the caller wants.
23211 Use the expression `assemble_name (STREAM, NAME)' to output the
23212 name itself; before and after that, output the additional
23213 assembler syntax for defining the name, and a newline.
23215 This macro controls how the assembler definitions of uninitialized
23216 common global variables are output.
23218 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT)
23219 Like `ASM_OUTPUT_COMMON' except takes the required alignment as a
23220 separate, explicit argument. If you define this macro, it is used
23221 in place of `ASM_OUTPUT_COMMON', and gives you more flexibility in
23222 handling the required alignment of the variable. The alignment is
23223 specified as the number of bits.
23225 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE,
23227 Like `ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable
23228 to be output, if there is one, or `NULL_TREE' if there is no
23229 corresponding variable. If you define this macro, GCC will use it
23230 in place of both `ASM_OUTPUT_COMMON' and
23231 `ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to
23232 see the variable's decl in order to chose what to output.
23234 -- Macro: ASM_OUTPUT_SHARED_COMMON (STREAM, NAME, SIZE, ROUNDED)
23235 If defined, it is similar to `ASM_OUTPUT_COMMON', except that it
23236 is used when NAME is shared. If not defined, `ASM_OUTPUT_COMMON'
23239 -- Macro: ASM_OUTPUT_BSS (STREAM, DECL, NAME, SIZE, ROUNDED)
23240 A C statement (sans semicolon) to output to the stdio stream
23241 STREAM the assembler definition of uninitialized global DECL named
23242 NAME whose size is SIZE bytes. The variable ROUNDED is the size
23243 rounded up to whatever alignment the caller wants.
23245 Try to use function `asm_output_bss' defined in `varasm.c' when
23246 defining this macro. If unable, use the expression `assemble_name
23247 (STREAM, NAME)' to output the name itself; before and after that,
23248 output the additional assembler syntax for defining the name, and
23251 This macro controls how the assembler definitions of uninitialized
23252 global variables are output. This macro exists to properly
23253 support languages like C++ which do not have `common' data.
23254 However, this macro currently is not defined for all targets. If
23255 this macro and `ASM_OUTPUT_ALIGNED_BSS' are not defined then
23256 `ASM_OUTPUT_COMMON' or `ASM_OUTPUT_ALIGNED_COMMON' or
23257 `ASM_OUTPUT_ALIGNED_DECL_COMMON' is used.
23259 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT)
23260 Like `ASM_OUTPUT_BSS' except takes the required alignment as a
23261 separate, explicit argument. If you define this macro, it is used
23262 in place of `ASM_OUTPUT_BSS', and gives you more flexibility in
23263 handling the required alignment of the variable. The alignment is
23264 specified as the number of bits.
23266 Try to use function `asm_output_aligned_bss' defined in file
23267 `varasm.c' when defining this macro.
23269 -- Macro: ASM_OUTPUT_SHARED_BSS (STREAM, DECL, NAME, SIZE, ROUNDED)
23270 If defined, it is similar to `ASM_OUTPUT_BSS', except that it is
23271 used when NAME is shared. If not defined, `ASM_OUTPUT_BSS' will
23274 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED)
23275 A C statement (sans semicolon) to output to the stdio stream
23276 STREAM the assembler definition of a local-common-label named NAME
23277 whose size is SIZE bytes. The variable ROUNDED is the size
23278 rounded up to whatever alignment the caller wants.
23280 Use the expression `assemble_name (STREAM, NAME)' to output the
23281 name itself; before and after that, output the additional
23282 assembler syntax for defining the name, and a newline.
23284 This macro controls how the assembler definitions of uninitialized
23285 static variables are output.
23287 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT)
23288 Like `ASM_OUTPUT_LOCAL' except takes the required alignment as a
23289 separate, explicit argument. If you define this macro, it is used
23290 in place of `ASM_OUTPUT_LOCAL', and gives you more flexibility in
23291 handling the required alignment of the variable. The alignment is
23292 specified as the number of bits.
23294 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE,
23296 Like `ASM_OUTPUT_ALIGNED_DECL' except that DECL of the variable to
23297 be output, if there is one, or `NULL_TREE' if there is no
23298 corresponding variable. If you define this macro, GCC will use it
23299 in place of both `ASM_OUTPUT_DECL' and `ASM_OUTPUT_ALIGNED_DECL'.
23300 Define this macro when you need to see the variable's decl in
23301 order to chose what to output.
23303 -- Macro: ASM_OUTPUT_SHARED_LOCAL (STREAM, NAME, SIZE, ROUNDED)
23304 If defined, it is similar to `ASM_OUTPUT_LOCAL', except that it is
23305 used when NAME is shared. If not defined, `ASM_OUTPUT_LOCAL' will
23309 File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format
23311 14.19.4 Output and Generation of Labels
23312 ---------------------------------------
23314 This is about outputting labels.
23316 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME)
23317 A C statement (sans semicolon) to output to the stdio stream
23318 STREAM the assembler definition of a label named NAME. Use the
23319 expression `assemble_name (STREAM, NAME)' to output the name
23320 itself; before and after that, output the additional assembler
23321 syntax for defining the name, and a newline. A default definition
23322 of this macro is provided which is correct for most systems.
23324 -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME)
23325 Identical to `ASM_OUTPUT_LABEL', except that NAME is known to
23326 refer to a compiler-generated label. The default definition uses
23327 `assemble_name_raw', which is like `assemble_name' except that it
23330 -- Macro: SIZE_ASM_OP
23331 A C string containing the appropriate assembler directive to
23332 specify the size of a symbol, without any arguments. On systems
23333 that use ELF, the default (in `config/elfos.h') is `"\t.size\t"';
23334 on other systems, the default is not to define this macro.
23336 Define this macro only if it is correct to use the default
23337 definitions of `ASM_OUTPUT_SIZE_DIRECTIVE' and
23338 `ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own
23339 custom definitions of those macros, or if you do not need explicit
23340 symbol sizes at all, do not define this macro.
23342 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE)
23343 A C statement (sans semicolon) to output to the stdio stream
23344 STREAM a directive telling the assembler that the size of the
23345 symbol NAME is SIZE. SIZE is a `HOST_WIDE_INT'. If you define
23346 `SIZE_ASM_OP', a default definition of this macro is provided.
23348 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME)
23349 A C statement (sans semicolon) to output to the stdio stream
23350 STREAM a directive telling the assembler to calculate the size of
23351 the symbol NAME by subtracting its address from the current
23354 If you define `SIZE_ASM_OP', a default definition of this macro is
23355 provided. The default assumes that the assembler recognizes a
23356 special `.' symbol as referring to the current address, and can
23357 calculate the difference between this and another symbol. If your
23358 assembler does not recognize `.' or cannot do calculations with
23359 it, you will need to redefine `ASM_OUTPUT_MEASURED_SIZE' to use
23360 some other technique.
23362 -- Macro: TYPE_ASM_OP
23363 A C string containing the appropriate assembler directive to
23364 specify the type of a symbol, without any arguments. On systems
23365 that use ELF, the default (in `config/elfos.h') is `"\t.type\t"';
23366 on other systems, the default is not to define this macro.
23368 Define this macro only if it is correct to use the default
23369 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you
23370 need your own custom definition of this macro, or if you do not
23371 need explicit symbol types at all, do not define this macro.
23373 -- Macro: TYPE_OPERAND_FMT
23374 A C string which specifies (using `printf' syntax) the format of
23375 the second operand to `TYPE_ASM_OP'. On systems that use ELF, the
23376 default (in `config/elfos.h') is `"@%s"'; on other systems, the
23377 default is not to define this macro.
23379 Define this macro only if it is correct to use the default
23380 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you
23381 need your own custom definition of this macro, or if you do not
23382 need explicit symbol types at all, do not define this macro.
23384 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE)
23385 A C statement (sans semicolon) to output to the stdio stream
23386 STREAM a directive telling the assembler that the type of the
23387 symbol NAME is TYPE. TYPE is a C string; currently, that string
23388 is always either `"function"' or `"object"', but you should not
23391 If you define `TYPE_ASM_OP' and `TYPE_OPERAND_FMT', a default
23392 definition of this macro is provided.
23394 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL)
23395 A C statement (sans semicolon) to output to the stdio stream
23396 STREAM any text necessary for declaring the name NAME of a
23397 function which is being defined. This macro is responsible for
23398 outputting the label definition (perhaps using
23399 `ASM_OUTPUT_LABEL'). The argument DECL is the `FUNCTION_DECL'
23400 tree node representing the function.
23402 If this macro is not defined, then the function name is defined in
23403 the usual manner as a label (by means of `ASM_OUTPUT_LABEL').
23405 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition
23408 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL)
23409 A C statement (sans semicolon) to output to the stdio stream
23410 STREAM any text necessary for declaring the size of a function
23411 which is being defined. The argument NAME is the name of the
23412 function. The argument DECL is the `FUNCTION_DECL' tree node
23413 representing the function.
23415 If this macro is not defined, then the function size is not
23418 You may wish to use `ASM_OUTPUT_MEASURED_SIZE' in the definition
23421 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL)
23422 A C statement (sans semicolon) to output to the stdio stream
23423 STREAM any text necessary for declaring the name NAME of an
23424 initialized variable which is being defined. This macro must
23425 output the label definition (perhaps using `ASM_OUTPUT_LABEL').
23426 The argument DECL is the `VAR_DECL' tree node representing the
23429 If this macro is not defined, then the variable name is defined in
23430 the usual manner as a label (by means of `ASM_OUTPUT_LABEL').
23432 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' and/or
23433 `ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro.
23435 -- Macro: ASM_DECLARE_CONSTANT_NAME (STREAM, NAME, EXP, SIZE)
23436 A C statement (sans semicolon) to output to the stdio stream
23437 STREAM any text necessary for declaring the name NAME of a
23438 constant which is being defined. This macro is responsible for
23439 outputting the label definition (perhaps using
23440 `ASM_OUTPUT_LABEL'). The argument EXP is the value of the
23441 constant, and SIZE is the size of the constant in bytes. NAME
23442 will be an internal label.
23444 If this macro is not defined, then the NAME is defined in the
23445 usual manner as a label (by means of `ASM_OUTPUT_LABEL').
23447 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition
23450 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME)
23451 A C statement (sans semicolon) to output to the stdio stream
23452 STREAM any text necessary for claiming a register REGNO for a
23453 global variable DECL with name NAME.
23455 If you don't define this macro, that is equivalent to defining it
23458 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND)
23459 A C statement (sans semicolon) to finish up declaring a variable
23460 name once the compiler has processed its initializer fully and
23461 thus has had a chance to determine the size of an array when
23462 controlled by an initializer. This is used on systems where it's
23463 necessary to declare something about the size of the object.
23465 If you don't define this macro, that is equivalent to defining it
23468 You may wish to use `ASM_OUTPUT_SIZE_DIRECTIVE' and/or
23469 `ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro.
23471 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const
23473 This target hook is a function to output to the stdio stream
23474 STREAM some commands that will make the label NAME global; that
23475 is, available for reference from other files.
23477 The default implementation relies on a proper definition of
23480 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME)
23481 A C statement (sans semicolon) to output to the stdio stream
23482 STREAM some commands that will make the label NAME weak; that is,
23483 available for reference from other files but only used if no other
23484 definition is available. Use the expression `assemble_name
23485 (STREAM, NAME)' to output the name itself; before and after that,
23486 output the additional assembler syntax for making that name weak,
23489 If you don't define this macro or `ASM_WEAKEN_DECL', GCC will not
23490 support weak symbols and you should not define the `SUPPORTS_WEAK'
23493 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE)
23494 Combines (and replaces) the function of `ASM_WEAKEN_LABEL' and
23495 `ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function
23496 or variable decl. If VALUE is not `NULL', this C statement should
23497 output to the stdio stream STREAM assembler code which defines
23498 (equates) the weak symbol NAME to have the value VALUE. If VALUE
23499 is `NULL', it should output commands to make NAME weak.
23501 -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE)
23502 Outputs a directive that enables NAME to be used to refer to
23503 symbol VALUE with weak-symbol semantics. `decl' is the
23504 declaration of `name'.
23506 -- Macro: SUPPORTS_WEAK
23507 A C expression which evaluates to true if the target supports weak
23510 If you don't define this macro, `defaults.h' provides a default
23511 definition. If either `ASM_WEAKEN_LABEL' or `ASM_WEAKEN_DECL' is
23512 defined, the default definition is `1'; otherwise, it is `0'.
23513 Define this macro if you want to control weak symbol support with
23514 a compiler flag such as `-melf'.
23516 -- Macro: MAKE_DECL_ONE_ONLY (DECL)
23517 A C statement (sans semicolon) to mark DECL to be emitted as a
23518 public symbol such that extra copies in multiple translation units
23519 will be discarded by the linker. Define this macro if your object
23520 file format provides support for this concept, such as the `COMDAT'
23521 section flags in the Microsoft Windows PE/COFF format, and this
23522 support requires changes to DECL, such as putting it in a separate
23525 -- Macro: SUPPORTS_ONE_ONLY
23526 A C expression which evaluates to true if the target supports
23527 one-only semantics.
23529 If you don't define this macro, `varasm.c' provides a default
23530 definition. If `MAKE_DECL_ONE_ONLY' is defined, the default
23531 definition is `1'; otherwise, it is `0'. Define this macro if you
23532 want to control one-only symbol support with a compiler flag, or if
23533 setting the `DECL_ONE_ONLY' flag is enough to mark a declaration to
23534 be emitted as one-only.
23536 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, const
23538 This target hook is a function to output to ASM_OUT_FILE some
23539 commands that will make the symbol(s) associated with DECL have
23540 hidden, protected or internal visibility as specified by
23543 -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC
23544 A C expression that evaluates to true if the target's linker
23545 expects that weak symbols do not appear in a static archive's
23546 table of contents. The default is `0'.
23548 Leaving weak symbols out of an archive's table of contents means
23549 that, if a symbol will only have a definition in one translation
23550 unit and will have undefined references from other translation
23551 units, that symbol should not be weak. Defining this macro to be
23552 nonzero will thus have the effect that certain symbols that would
23553 normally be weak (explicit template instantiations, and vtables
23554 for polymorphic classes with noninline key methods) will instead
23557 The C++ ABI requires this macro to be zero. Define this macro for
23558 targets where full C++ ABI compliance is impossible and where
23559 linker restrictions require weak symbols to be left out of a
23560 static archive's table of contents.
23562 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME)
23563 A C statement (sans semicolon) to output to the stdio stream
23564 STREAM any text necessary for declaring the name of an external
23565 symbol named NAME which is referenced in this compilation but not
23566 defined. The value of DECL is the tree node for the declaration.
23568 This macro need not be defined if it does not need to output
23569 anything. The GNU assembler and most Unix assemblers don't
23572 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF)
23573 This target hook is a function to output to ASM_OUT_FILE an
23574 assembler pseudo-op to declare a library function name external.
23575 The name of the library function is given by SYMREF, which is a
23578 -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (tree DECL)
23579 This target hook is a function to output to ASM_OUT_FILE an
23580 assembler directive to annotate used symbol. Darwin target use
23581 .no_dead_code_strip directive.
23583 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME)
23584 A C statement (sans semicolon) to output to the stdio stream
23585 STREAM a reference in assembler syntax to a label named NAME.
23586 This should add `_' to the front of the name, if that is customary
23587 on your operating system, as it is in most Berkeley Unix systems.
23588 This macro is used in `assemble_name'.
23590 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM)
23591 A C statement (sans semicolon) to output a reference to
23592 `SYMBOL_REF' SYM. If not defined, `assemble_name' will be used to
23593 output the name of the symbol. This macro may be used to modify
23594 the way a symbol is referenced depending on information encoded by
23595 `TARGET_ENCODE_SECTION_INFO'.
23597 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF)
23598 A C statement (sans semicolon) to output a reference to BUF, the
23599 result of `ASM_GENERATE_INTERNAL_LABEL'. If not defined,
23600 `assemble_name' will be used to output the name of the symbol.
23601 This macro is not used by `output_asm_label', or the `%l'
23602 specifier that calls it; the intention is that this macro should
23603 be set when it is necessary to output a label differently when its
23604 address is being taken.
23606 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const
23607 char *PREFIX, unsigned long LABELNO)
23608 A function to output to the stdio stream STREAM a label whose name
23609 is made from the string PREFIX and the number LABELNO.
23611 It is absolutely essential that these labels be distinct from the
23612 labels used for user-level functions and variables. Otherwise,
23613 certain programs will have name conflicts with internal labels.
23615 It is desirable to exclude internal labels from the symbol table
23616 of the object file. Most assemblers have a naming convention for
23617 labels that should be excluded; on many systems, the letter `L' at
23618 the beginning of a label has this effect. You should find out what
23619 convention your system uses, and follow it.
23621 The default version of this function utilizes
23622 `ASM_GENERATE_INTERNAL_LABEL'.
23624 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM)
23625 A C statement to output to the stdio stream STREAM a debug info
23626 label whose name is made from the string PREFIX and the number
23627 NUM. This is useful for VLIW targets, where debug info labels may
23628 need to be treated differently than branch target labels. On some
23629 systems, branch target labels must be at the beginning of
23630 instruction bundles, but debug info labels can occur in the middle
23631 of instruction bundles.
23633 If this macro is not defined, then
23634 `(*targetm.asm_out.internal_label)' will be used.
23636 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM)
23637 A C statement to store into the string STRING a label whose name
23638 is made from the string PREFIX and the number NUM.
23640 This string, when output subsequently by `assemble_name', should
23641 produce the output that `(*targetm.asm_out.internal_label)' would
23642 produce with the same PREFIX and NUM.
23644 If the string begins with `*', then `assemble_name' will output
23645 the rest of the string unchanged. It is often convenient for
23646 `ASM_GENERATE_INTERNAL_LABEL' to use `*' in this way. If the
23647 string doesn't start with `*', then `ASM_OUTPUT_LABELREF' gets to
23648 output the string, and may change it. (Of course,
23649 `ASM_OUTPUT_LABELREF' is also part of your machine description, so
23650 you should know what it does on your machine.)
23652 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER)
23653 A C expression to assign to OUTVAR (which is a variable of type
23654 `char *') a newly allocated string made from the string NAME and
23655 the number NUMBER, with some suitable punctuation added. Use
23656 `alloca' to get space for the string.
23658 The string will be used as an argument to `ASM_OUTPUT_LABELREF' to
23659 produce an assembler label for an internal static variable whose
23660 name is NAME. Therefore, the string must be such as to result in
23661 valid assembler code. The argument NUMBER is different each time
23662 this macro is executed; it prevents conflicts between
23663 similarly-named internal static variables in different scopes.
23665 Ideally this string should not be a valid C identifier, to prevent
23666 any conflict with the user's own symbols. Most assemblers allow
23667 periods or percent signs in assembler symbols; putting at least
23668 one of these between the name and the number will suffice.
23670 If this macro is not defined, a default definition will be provided
23671 which is correct for most systems.
23673 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE)
23674 A C statement to output to the stdio stream STREAM assembler code
23675 which defines (equates) the symbol NAME to have the value VALUE.
23677 If `SET_ASM_OP' is defined, a default definition is provided which
23678 is correct for most systems.
23680 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME,
23682 A C statement to output to the stdio stream STREAM assembler code
23683 which defines (equates) the symbol whose tree node is DECL_OF_NAME
23684 to have the value of the tree node DECL_OF_VALUE. This macro will
23685 be used in preference to `ASM_OUTPUT_DEF' if it is defined and if
23686 the tree nodes are available.
23688 If `SET_ASM_OP' is defined, a default definition is provided which
23689 is correct for most systems.
23691 -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE)
23692 A C statement that evaluates to true if the assembler code which
23693 defines (equates) the symbol whose tree node is DECL_OF_NAME to
23694 have the value of the tree node DECL_OF_VALUE should be emitted
23695 near the end of the current compilation unit. The default is to
23696 not defer output of defines. This macro affects defines output by
23697 `ASM_OUTPUT_DEF' and `ASM_OUTPUT_DEF_FROM_DECLS'.
23699 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE)
23700 A C statement to output to the stdio stream STREAM assembler code
23701 which defines (equates) the weak symbol NAME to have the value
23702 VALUE. If VALUE is `NULL', it defines NAME as an undefined weak
23705 Define this macro if the target only supports weak aliases; define
23706 `ASM_OUTPUT_DEF' instead if possible.
23708 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME,
23710 Define this macro to override the default assembler names used for
23711 Objective-C methods.
23713 The default name is a unique method number followed by the name of
23714 the class (e.g. `_1_Foo'). For methods in categories, the name of
23715 the category is also included in the assembler name (e.g.
23718 These names are safe on most systems, but make debugging difficult
23719 since the method's selector is not present in the name.
23720 Therefore, particular systems define other ways of computing names.
23722 BUF is an expression of type `char *' which gives you a buffer in
23723 which to store the name; its length is as long as CLASS_NAME,
23724 CAT_NAME and SEL_NAME put together, plus 50 characters extra.
23726 The argument IS_INST specifies whether the method is an instance
23727 method or a class method; CLASS_NAME is the name of the class;
23728 CAT_NAME is the name of the category (or `NULL' if the method is
23729 not in a category); and SEL_NAME is the name of the selector.
23731 On systems where the assembler can handle quoted names, you can
23732 use this macro to provide more human-readable names.
23734 -- Macro: ASM_DECLARE_CLASS_REFERENCE (STREAM, NAME)
23735 A C statement (sans semicolon) to output to the stdio stream
23736 STREAM commands to declare that the label NAME is an Objective-C
23737 class reference. This is only needed for targets whose linkers
23738 have special support for NeXT-style runtimes.
23740 -- Macro: ASM_DECLARE_UNRESOLVED_REFERENCE (STREAM, NAME)
23741 A C statement (sans semicolon) to output to the stdio stream
23742 STREAM commands to declare that the label NAME is an unresolved
23743 Objective-C class reference. This is only needed for targets
23744 whose linkers have special support for NeXT-style runtimes.
23747 File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format
23749 14.19.5 How Initialization Functions Are Handled
23750 ------------------------------------------------
23752 The compiled code for certain languages includes "constructors" (also
23753 called "initialization routines")--functions to initialize data in the
23754 program when the program is started. These functions need to be called
23755 before the program is "started"--that is to say, before `main' is
23758 Compiling some languages generates "destructors" (also called
23759 "termination routines") that should be called when the program
23762 To make the initialization and termination functions work, the compiler
23763 must output something in the assembler code to cause those functions to
23764 be called at the appropriate time. When you port the compiler to a new
23765 system, you need to specify how to do this.
23767 There are two major ways that GCC currently supports the execution of
23768 initialization and termination functions. Each way has two variants.
23769 Much of the structure is common to all four variations.
23771 The linker must build two lists of these functions--a list of
23772 initialization functions, called `__CTOR_LIST__', and a list of
23773 termination functions, called `__DTOR_LIST__'.
23775 Each list always begins with an ignored function pointer (which may
23776 hold 0, -1, or a count of the function pointers after it, depending on
23777 the environment). This is followed by a series of zero or more function
23778 pointers to constructors (or destructors), followed by a function
23779 pointer containing zero.
23781 Depending on the operating system and its executable file format,
23782 either `crtstuff.c' or `libgcc2.c' traverses these lists at startup
23783 time and exit time. Constructors are called in reverse order of the
23784 list; destructors in forward order.
23786 The best way to handle static constructors works only for object file
23787 formats which provide arbitrarily-named sections. A section is set
23788 aside for a list of constructors, and another for a list of destructors.
23789 Traditionally these are called `.ctors' and `.dtors'. Each object file
23790 that defines an initialization function also puts a word in the
23791 constructor section to point to that function. The linker accumulates
23792 all these words into one contiguous `.ctors' section. Termination
23793 functions are handled similarly.
23795 This method will be chosen as the default by `target-def.h' if
23796 `TARGET_ASM_NAMED_SECTION' is defined. A target that does not support
23797 arbitrary sections, but does support special designated constructor and
23798 destructor sections may define `CTORS_SECTION_ASM_OP' and
23799 `DTORS_SECTION_ASM_OP' to achieve the same effect.
23801 When arbitrary sections are available, there are two variants,
23802 depending upon how the code in `crtstuff.c' is called. On systems that
23803 support a ".init" section which is executed at program startup, parts
23804 of `crtstuff.c' are compiled into that section. The program is linked
23805 by the `gcc' driver like this:
23807 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o
23809 The prologue of a function (`__init') appears in the `.init' section
23810 of `crti.o'; the epilogue appears in `crtn.o'. Likewise for the
23811 function `__fini' in the ".fini" section. Normally these files are
23812 provided by the operating system or by the GNU C library, but are
23813 provided by GCC for a few targets.
23815 The objects `crtbegin.o' and `crtend.o' are (for most targets)
23816 compiled from `crtstuff.c'. They contain, among other things, code
23817 fragments within the `.init' and `.fini' sections that branch to
23818 routines in the `.text' section. The linker will pull all parts of a
23819 section together, which results in a complete `__init' function that
23820 invokes the routines we need at startup.
23822 To use this variant, you must define the `INIT_SECTION_ASM_OP' macro
23825 If no init section is available, when GCC compiles any function called
23826 `main' (or more accurately, any function designated as a program entry
23827 point by the language front end calling `expand_main_function'), it
23828 inserts a procedure call to `__main' as the first executable code after
23829 the function prologue. The `__main' function is defined in `libgcc2.c'
23830 and runs the global constructors.
23832 In file formats that don't support arbitrary sections, there are again
23833 two variants. In the simplest variant, the GNU linker (GNU `ld') and
23834 an `a.out' format must be used. In this case, `TARGET_ASM_CONSTRUCTOR'
23835 is defined to produce a `.stabs' entry of type `N_SETT', referencing
23836 the name `__CTOR_LIST__', and with the address of the void function
23837 containing the initialization code as its value. The GNU linker
23838 recognizes this as a request to add the value to a "set"; the values
23839 are accumulated, and are eventually placed in the executable as a
23840 vector in the format described above, with a leading (ignored) count
23841 and a trailing zero element. `TARGET_ASM_DESTRUCTOR' is handled
23842 similarly. Since no init section is available, the absence of
23843 `INIT_SECTION_ASM_OP' causes the compilation of `main' to call `__main'
23844 as above, starting the initialization process.
23846 The last variant uses neither arbitrary sections nor the GNU linker.
23847 This is preferable when you want to do dynamic linking and when using
23848 file formats which the GNU linker does not support, such as `ECOFF'. In
23849 this case, `TARGET_HAVE_CTORS_DTORS' is false, initialization and
23850 termination functions are recognized simply by their names. This
23851 requires an extra program in the linkage step, called `collect2'. This
23852 program pretends to be the linker, for use with GCC; it does its job by
23853 running the ordinary linker, but also arranges to include the vectors of
23854 initialization and termination functions. These functions are called
23855 via `__main' as described above. In order to use this method,
23856 `use_collect2' must be defined in the target in `config.gcc'.
23858 The following section describes the specific macros that control and
23859 customize the handling of initialization and termination functions.
23862 File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format
23864 14.19.6 Macros Controlling Initialization Routines
23865 --------------------------------------------------
23867 Here are the macros that control how the compiler handles initialization
23868 and termination functions:
23870 -- Macro: INIT_SECTION_ASM_OP
23871 If defined, a C string constant, including spacing, for the
23872 assembler operation to identify the following data as
23873 initialization code. If not defined, GCC will assume such a
23874 section does not exist. When you are using special sections for
23875 initialization and termination functions, this macro also controls
23876 how `crtstuff.c' and `libgcc2.c' arrange to run the initialization
23879 -- Macro: HAS_INIT_SECTION
23880 If defined, `main' will not call `__main' as described above.
23881 This macro should be defined for systems that control start-up code
23882 on a symbol-by-symbol basis, such as OSF/1, and should not be
23883 defined explicitly for systems that support `INIT_SECTION_ASM_OP'.
23885 -- Macro: LD_INIT_SWITCH
23886 If defined, a C string constant for a switch that tells the linker
23887 that the following symbol is an initialization routine.
23889 -- Macro: LD_FINI_SWITCH
23890 If defined, a C string constant for a switch that tells the linker
23891 that the following symbol is a finalization routine.
23893 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC)
23894 If defined, a C statement that will write a function that can be
23895 automatically called when a shared library is loaded. The function
23896 should call FUNC, which takes no arguments. If not defined, and
23897 the object format requires an explicit initialization function,
23898 then a function called `_GLOBAL__DI' will be generated.
23900 This function and the following one are used by collect2 when
23901 linking a shared library that needs constructors or destructors,
23902 or has DWARF2 exception tables embedded in the code.
23904 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC)
23905 If defined, a C statement that will write a function that can be
23906 automatically called when a shared library is unloaded. The
23907 function should call FUNC, which takes no arguments. If not
23908 defined, and the object format requires an explicit finalization
23909 function, then a function called `_GLOBAL__DD' will be generated.
23911 -- Macro: INVOKE__main
23912 If defined, `main' will call `__main' despite the presence of
23913 `INIT_SECTION_ASM_OP'. This macro should be defined for systems
23914 where the init section is not actually run automatically, but is
23915 still useful for collecting the lists of constructors and
23918 -- Macro: SUPPORTS_INIT_PRIORITY
23919 If nonzero, the C++ `init_priority' attribute is supported and the
23920 compiler should emit instructions to control the order of
23921 initialization of objects. If zero, the compiler will issue an
23922 error message upon encountering an `init_priority' attribute.
23924 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS
23925 This value is true if the target supports some "native" method of
23926 collecting constructors and destructors to be run at startup and
23927 exit. It is false if we must use `collect2'.
23929 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY)
23930 If defined, a function that outputs assembler code to arrange to
23931 call the function referenced by SYMBOL at initialization time.
23933 Assume that SYMBOL is a `SYMBOL_REF' for a function taking no
23934 arguments and with no return value. If the target supports
23935 initialization priorities, PRIORITY is a value between 0 and
23936 `MAX_INIT_PRIORITY'; otherwise it must be `DEFAULT_INIT_PRIORITY'.
23938 If this macro is not defined by the target, a suitable default will
23939 be chosen if (1) the target supports arbitrary section names, (2)
23940 the target defines `CTORS_SECTION_ASM_OP', or (3) `USE_COLLECT2'
23943 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY)
23944 This is like `TARGET_ASM_CONSTRUCTOR' but used for termination
23945 functions rather than initialization functions.
23947 If `TARGET_HAVE_CTORS_DTORS' is true, the initialization routine
23948 generated for the generated object file will have static linkage.
23950 If your system uses `collect2' as the means of processing
23951 constructors, then that program normally uses `nm' to scan an object
23952 file for constructor functions to be called.
23954 On certain kinds of systems, you can define this macro to make
23955 `collect2' work faster (and, in some cases, make it work at all):
23957 -- Macro: OBJECT_FORMAT_COFF
23958 Define this macro if the system uses COFF (Common Object File
23959 Format) object files, so that `collect2' can assume this format
23960 and scan object files directly for dynamic constructor/destructor
23963 This macro is effective only in a native compiler; `collect2' as
23964 part of a cross compiler always uses `nm' for the target machine.
23966 -- Macro: REAL_NM_FILE_NAME
23967 Define this macro as a C string constant containing the file name
23968 to use to execute `nm'. The default is to search the path
23971 If your system supports shared libraries and has a program to list
23972 the dynamic dependencies of a given library or executable, you can
23973 define these macros to enable support for running initialization
23974 and termination functions in shared libraries:
23976 -- Macro: LDD_SUFFIX
23977 Define this macro to a C string constant containing the name of
23978 the program which lists dynamic dependencies, like `"ldd"' under
23981 -- Macro: PARSE_LDD_OUTPUT (PTR)
23982 Define this macro to be C code that extracts filenames from the
23983 output of the program denoted by `LDD_SUFFIX'. PTR is a variable
23984 of type `char *' that points to the beginning of a line of output
23985 from `LDD_SUFFIX'. If the line lists a dynamic dependency, the
23986 code must advance PTR to the beginning of the filename on that
23987 line. Otherwise, it must set PTR to `NULL'.
23990 File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format
23992 14.19.7 Output of Assembler Instructions
23993 ----------------------------------------
23995 This describes assembler instruction output.
23997 -- Macro: REGISTER_NAMES
23998 A C initializer containing the assembler's names for the machine
23999 registers, each one as a C string constant. This is what
24000 translates register numbers in the compiler into assembler
24003 -- Macro: ADDITIONAL_REGISTER_NAMES
24004 If defined, a C initializer for an array of structures containing
24005 a name and a register number. This macro defines additional names
24006 for hard registers, thus allowing the `asm' option in declarations
24007 to refer to registers using alternate names.
24009 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR)
24010 Define this macro if you are using an unusual assembler that
24011 requires different names for the machine instructions.
24013 The definition is a C statement or statements which output an
24014 assembler instruction opcode to the stdio stream STREAM. The
24015 macro-operand PTR is a variable of type `char *' which points to
24016 the opcode name in its "internal" form--the form that is written
24017 in the machine description. The definition should output the
24018 opcode name to STREAM, performing any translation you desire, and
24019 increment the variable PTR to point at the end of the opcode so
24020 that it will not be output twice.
24022 In fact, your macro definition may process less than the entire
24023 opcode name, or more than the opcode name; but if you want to
24024 process text that includes `%'-sequences to substitute operands,
24025 you must take care of the substitution yourself. Just be sure to
24026 increment PTR over whatever text should not be output normally.
24028 If you need to look at the operand values, they can be found as the
24029 elements of `recog_data.operand'.
24031 If the macro definition does nothing, the instruction is output in
24034 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS)
24035 If defined, a C statement to be executed just prior to the output
24036 of assembler code for INSN, to modify the extracted operands so
24037 they will be output differently.
24039 Here the argument OPVEC is the vector containing the operands
24040 extracted from INSN, and NOPERANDS is the number of elements of
24041 the vector which contain meaningful data for this insn. The
24042 contents of this vector are what will be used to convert the insn
24043 template into assembler code, so you can change the assembler
24044 output by changing the contents of the vector.
24046 This macro is useful when various assembler syntaxes share a single
24047 file of instruction patterns; by defining this macro differently,
24048 you can cause a large class of instructions to be output
24049 differently (such as with rearranged operands). Naturally,
24050 variations in assembler syntax affecting individual insn patterns
24051 ought to be handled by writing conditional output routines in
24054 If this macro is not defined, it is equivalent to a null statement.
24056 -- Macro: PRINT_OPERAND (STREAM, X, CODE)
24057 A C compound statement to output to stdio stream STREAM the
24058 assembler syntax for an instruction operand X. X is an RTL
24061 CODE is a value that can be used to specify one of several ways of
24062 printing the operand. It is used when identical operands must be
24063 printed differently depending on the context. CODE comes from the
24064 `%' specification that was used to request printing of the
24065 operand. If the specification was just `%DIGIT' then CODE is 0;
24066 if the specification was `%LTR DIGIT' then CODE is the ASCII code
24069 If X is a register, this macro should print the register's name.
24070 The names can be found in an array `reg_names' whose type is `char
24071 *[]'. `reg_names' is initialized from `REGISTER_NAMES'.
24073 When the machine description has a specification `%PUNCT' (a `%'
24074 followed by a punctuation character), this macro is called with a
24075 null pointer for X and the punctuation character for CODE.
24077 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE)
24078 A C expression which evaluates to true if CODE is a valid
24079 punctuation character for use in the `PRINT_OPERAND' macro. If
24080 `PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no
24081 punctuation characters (except for the standard one, `%') are used
24084 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X)
24085 A C compound statement to output to stdio stream STREAM the
24086 assembler syntax for an instruction operand that is a memory
24087 reference whose address is X. X is an RTL expression.
24089 On some machines, the syntax for a symbolic address depends on the
24090 section that the address refers to. On these machines, define the
24091 hook `TARGET_ENCODE_SECTION_INFO' to store the information into the
24092 `symbol_ref', and then check for it here. *Note Assembler
24095 -- Macro: DBR_OUTPUT_SEQEND (FILE)
24096 A C statement, to be executed after all slot-filler instructions
24097 have been output. If necessary, call `dbr_sequence_length' to
24098 determine the number of slots filled in a sequence (zero if not
24099 currently outputting a sequence), to decide how many no-ops to
24100 output, or whatever.
24102 Don't define this macro if it has nothing to do, but it is helpful
24103 in reading assembly output if the extent of the delay sequence is
24104 made explicit (e.g. with white space).
24106 Note that output routines for instructions with delay slots must be
24107 prepared to deal with not being output as part of a sequence (i.e. when
24108 the scheduling pass is not run, or when no slot fillers could be
24109 found.) The variable `final_sequence' is null when not processing a
24110 sequence, otherwise it contains the `sequence' rtx being output.
24112 -- Macro: REGISTER_PREFIX
24113 -- Macro: LOCAL_LABEL_PREFIX
24114 -- Macro: USER_LABEL_PREFIX
24115 -- Macro: IMMEDIATE_PREFIX
24116 If defined, C string expressions to be used for the `%R', `%L',
24117 `%U', and `%I' options of `asm_fprintf' (see `final.c'). These
24118 are useful when a single `md' file must support multiple assembler
24119 formats. In that case, the various `tm.h' files can define these
24120 macros differently.
24122 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT)
24123 If defined this macro should expand to a series of `case'
24124 statements which will be parsed inside the `switch' statement of
24125 the `asm_fprintf' function. This allows targets to define extra
24126 printf formats which may useful when generating their assembler
24127 statements. Note that uppercase letters are reserved for future
24128 generic extensions to asm_fprintf, and so are not available to
24129 target specific code. The output file is given by the parameter
24130 FILE. The varargs input pointer is ARGPTR and the rest of the
24131 format string, starting the character after the one that is being
24132 switched upon, is pointed to by FORMAT.
24134 -- Macro: ASSEMBLER_DIALECT
24135 If your target supports multiple dialects of assembler language
24136 (such as different opcodes), define this macro as a C expression
24137 that gives the numeric index of the assembler language dialect to
24138 use, with zero as the first variant.
24140 If this macro is defined, you may use constructs of the form
24141 `{option0|option1|option2...}'
24142 in the output templates of patterns (*note Output Template::) or
24143 in the first argument of `asm_fprintf'. This construct outputs
24144 `option0', `option1', `option2', etc., if the value of
24145 `ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters
24146 within these strings retain their usual meaning. If there are
24147 fewer alternatives within the braces than the value of
24148 `ASSEMBLER_DIALECT', the construct outputs nothing.
24150 If you do not define this macro, the characters `{', `|' and `}'
24151 do not have any special meaning when used in templates or operands
24154 Define the macros `REGISTER_PREFIX', `LOCAL_LABEL_PREFIX',
24155 `USER_LABEL_PREFIX' and `IMMEDIATE_PREFIX' if you can express the
24156 variations in assembler language syntax with that mechanism.
24157 Define `ASSEMBLER_DIALECT' and use the `{option0|option1}' syntax
24158 if the syntax variant are larger and involve such things as
24159 different opcodes or operand order.
24161 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO)
24162 A C expression to output to STREAM some assembler code which will
24163 push hard register number REGNO onto the stack. The code need not
24164 be optimal, since this macro is used only when profiling.
24166 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO)
24167 A C expression to output to STREAM some assembler code which will
24168 pop hard register number REGNO off of the stack. The code need
24169 not be optimal, since this macro is used only when profiling.
24172 File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format
24174 14.19.8 Output of Dispatch Tables
24175 ---------------------------------
24177 This concerns dispatch tables.
24179 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL)
24180 A C statement to output to the stdio stream STREAM an assembler
24181 pseudo-instruction to generate a difference between two labels.
24182 VALUE and REL are the numbers of two internal labels. The
24183 definitions of these labels are output using
24184 `(*targetm.asm_out.internal_label)', and they must be printed in
24185 the same way here. For example,
24187 fprintf (STREAM, "\t.word L%d-L%d\n",
24190 You must provide this macro on machines where the addresses in a
24191 dispatch table are relative to the table's own address. If
24192 defined, GCC will also use this macro on all machines when
24193 producing PIC. BODY is the body of the `ADDR_DIFF_VEC'; it is
24194 provided so that the mode and flags can be read.
24196 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE)
24197 This macro should be provided on machines where the addresses in a
24198 dispatch table are absolute.
24200 The definition should be a C statement to output to the stdio
24201 stream STREAM an assembler pseudo-instruction to generate a
24202 reference to a label. VALUE is the number of an internal label
24203 whose definition is output using
24204 `(*targetm.asm_out.internal_label)'. For example,
24206 fprintf (STREAM, "\t.word L%d\n", VALUE)
24208 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE)
24209 Define this if the label before a jump-table needs to be output
24210 specially. The first three arguments are the same as for
24211 `(*targetm.asm_out.internal_label)'; the fourth argument is the
24212 jump-table which follows (a `jump_insn' containing an `addr_vec'
24213 or `addr_diff_vec').
24215 This feature is used on system V to output a `swbeg' statement for
24218 If this macro is not defined, these labels are output with
24219 `(*targetm.asm_out.internal_label)'.
24221 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE)
24222 Define this if something special must be output at the end of a
24223 jump-table. The definition should be a C statement to be executed
24224 after the assembler code for the table is written. It should write
24225 the appropriate code to stdio stream STREAM. The argument TABLE
24226 is the jump-table insn, and NUM is the label-number of the
24229 If this macro is not defined, nothing special is output at the end
24232 -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (STREAM, DECL,
24234 This target hook emits a label at the beginning of each FDE. It
24235 should be defined on targets where FDEs need special labels, and it
24236 should write the appropriate label, for the FDE associated with the
24237 function declaration DECL, to the stdio stream STREAM. The third
24238 argument, FOR_EH, is a boolean: true if this is for an exception
24239 table. The fourth argument, EMPTY, is a boolean: true if this is
24240 a placeholder label for an omitted FDE.
24242 The default is that FDEs are not given nonlocal labels.
24244 -- Taget Hook: void TARGET_UNWIND_EMIT (FILE * STREAM, rtx INSN)
24245 This target hook emits and assembly directives required to unwind
24246 the given instruction. This is only used when TARGET_UNWIND_INFO
24250 File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format
24252 14.19.9 Assembler Commands for Exception Regions
24253 ------------------------------------------------
24255 This describes commands marking the start and the end of an exception
24258 -- Macro: EH_FRAME_SECTION_NAME
24259 If defined, a C string constant for the name of the section
24260 containing exception handling frame unwind information. If not
24261 defined, GCC will provide a default definition if the target
24262 supports named sections. `crtstuff.c' uses this macro to switch
24263 to the appropriate section.
24265 You should define this symbol if your target supports DWARF 2 frame
24266 unwind information and the default definition does not work.
24268 -- Macro: EH_FRAME_IN_DATA_SECTION
24269 If defined, DWARF 2 frame unwind information will be placed in the
24270 data section even though the target supports named sections. This
24271 might be necessary, for instance, if the system linker does garbage
24272 collection and sections cannot be marked as not to be collected.
24274 Do not define this macro unless `TARGET_ASM_NAMED_SECTION' is also
24277 -- Macro: EH_TABLES_CAN_BE_READ_ONLY
24278 Define this macro to 1 if your target is such that no frame unwind
24279 information encoding used with non-PIC code will ever require a
24280 runtime relocation, but the linker may not support merging
24281 read-only and read-write sections into a single read-write section.
24283 -- Macro: MASK_RETURN_ADDR
24284 An rtx used to mask the return address found via
24285 `RETURN_ADDR_RTX', so that it does not contain any extraneous set
24288 -- Macro: DWARF2_UNWIND_INFO
24289 Define this macro to 0 if your target supports DWARF 2 frame unwind
24290 information, but it does not yet work with exception handling.
24291 Otherwise, if your target supports this information (if it defines
24292 `INCOMING_RETURN_ADDR_RTX' and either `UNALIGNED_INT_ASM_OP' or
24293 `OBJECT_FORMAT_ELF'), GCC will provide a default definition of 1.
24295 If `TARGET_UNWIND_INFO' is defined, the target specific unwinder
24296 will be used in all cases. Defining this macro will enable the
24297 generation of DWARF 2 frame debugging information.
24299 If `TARGET_UNWIND_INFO' is not defined, and this macro is defined
24300 to 1, the DWARF 2 unwinder will be the default exception handling
24301 mechanism; otherwise, `setjmp'/`longjmp' will be used by default.
24303 -- Macro: TARGET_UNWIND_INFO
24304 Define this macro if your target has ABI specified unwind tables.
24305 Usually these will be output by `TARGET_UNWIND_EMIT'.
24307 -- Variable: Target Hook bool TARGET_UNWID_TABLES_DEFAULT
24308 This variable should be set to `true' if the target ABI requires
24309 unwinding tables even when exceptions are not used.
24311 -- Macro: MUST_USE_SJLJ_EXCEPTIONS
24312 This macro need only be defined if `DWARF2_UNWIND_INFO' is
24313 runtime-variable. In that case, `except.h' cannot correctly
24314 determine the corresponding definition of
24315 `MUST_USE_SJLJ_EXCEPTIONS', so the target must provide it directly.
24317 -- Macro: DWARF_CIE_DATA_ALIGNMENT
24318 This macro need only be defined if the target might save registers
24319 in the function prologue at an offset to the stack pointer that is
24320 not aligned to `UNITS_PER_WORD'. The definition should be the
24321 negative minimum alignment if `STACK_GROWS_DOWNWARD' is defined,
24322 and the positive minimum alignment otherwise. *Note SDB and
24323 DWARF::. Only applicable if the target supports DWARF 2 frame
24324 unwind information.
24326 -- Target Hook: void TARGET_ASM_EXCEPTION_SECTION ()
24327 If defined, a function that switches to the section in which the
24328 main exception table is to be placed (*note Sections::). The
24329 default is a function that switches to a section named
24330 `.gcc_except_table' on machines that support named sections via
24331 `TARGET_ASM_NAMED_SECTION', otherwise if `-fpic' or `-fPIC' is in
24332 effect, the `data_section', otherwise the `readonly_data_section'.
24334 -- Target Hook: void TARGET_ASM_EH_FRAME_SECTION ()
24335 If defined, a function that switches to the section in which the
24336 DWARF 2 frame unwind information to be placed (*note Sections::).
24337 The default is a function that outputs a standard GAS section
24338 directive, if `EH_FRAME_SECTION_NAME' is defined, or else a data
24339 section directive followed by a synthetic label.
24341 -- Variable: Target Hook bool TARGET_TERMINATE_DW2_EH_FRAME_INFO
24342 Contains the value true if the target should add a zero word onto
24343 the end of a Dwarf-2 frame info section when used for exception
24344 handling. Default value is false if `EH_FRAME_SECTION_NAME' is
24345 defined, and true otherwise.
24347 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG)
24348 Given a register, this hook should return a parallel of registers
24349 to represent where to find the register pieces. Define this hook
24350 if the register and its mode are represented in Dwarf in
24351 non-contiguous locations, or if the register should be represented
24352 in more than one register in Dwarf. Otherwise, this hook should
24353 return `NULL_RTX'. If not defined, the default is to return
24356 -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM)
24357 This hook is used to output a reference from a frame unwinding
24358 table to the type_info object identified by SYM. It should return
24359 `true' if the reference was output. Returning `false' will cause
24360 the reference to be output using the normal Dwarf2 routines.
24362 -- Target Hook: bool TARGET_ARM_EABI_UNWINDER
24363 This hook should be set to `true' on targets that use an ARM EABI
24364 based unwinding library, and `false' on other targets. This
24365 effects the format of unwinding tables, and how the unwinder in
24366 entered after running a cleanup. The default is `false'.
24369 File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format
24371 14.19.10 Assembler Commands for Alignment
24372 -----------------------------------------
24374 This describes commands for alignment.
24376 -- Macro: JUMP_ALIGN (LABEL)
24377 The alignment (log base 2) to put in front of LABEL, which is a
24378 common destination of jumps and has no fallthru incoming edge.
24380 This macro need not be defined if you don't want any special
24381 alignment to be done at such a time. Most machine descriptions do
24382 not currently define the macro.
24384 Unless it's necessary to inspect the LABEL parameter, it is better
24385 to set the variable ALIGN_JUMPS in the target's
24386 `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's
24387 selection in ALIGN_JUMPS in a `JUMP_ALIGN' implementation.
24389 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL)
24390 The alignment (log base 2) to put in front of LABEL, which follows
24393 This macro need not be defined if you don't want any special
24394 alignment to be done at such a time. Most machine descriptions do
24395 not currently define the macro.
24397 -- Macro: LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP
24398 The maximum number of bytes to skip when applying
24399 `LABEL_ALIGN_AFTER_BARRIER'. This works only if
24400 `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined.
24402 -- Macro: LOOP_ALIGN (LABEL)
24403 The alignment (log base 2) to put in front of LABEL, which follows
24404 a `NOTE_INSN_LOOP_BEG' note.
24406 This macro need not be defined if you don't want any special
24407 alignment to be done at such a time. Most machine descriptions do
24408 not currently define the macro.
24410 Unless it's necessary to inspect the LABEL parameter, it is better
24411 to set the variable `align_loops' in the target's
24412 `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's
24413 selection in `align_loops' in a `LOOP_ALIGN' implementation.
24415 -- Macro: LOOP_ALIGN_MAX_SKIP
24416 The maximum number of bytes to skip when applying `LOOP_ALIGN'.
24417 This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined.
24419 -- Macro: LABEL_ALIGN (LABEL)
24420 The alignment (log base 2) to put in front of LABEL. If
24421 `LABEL_ALIGN_AFTER_BARRIER' / `LOOP_ALIGN' specify a different
24422 alignment, the maximum of the specified values is used.
24424 Unless it's necessary to inspect the LABEL parameter, it is better
24425 to set the variable `align_labels' in the target's
24426 `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's
24427 selection in `align_labels' in a `LABEL_ALIGN' implementation.
24429 -- Macro: LABEL_ALIGN_MAX_SKIP
24430 The maximum number of bytes to skip when applying `LABEL_ALIGN'.
24431 This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined.
24433 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES)
24434 A C statement to output to the stdio stream STREAM an assembler
24435 instruction to advance the location counter by NBYTES bytes.
24436 Those bytes should be zero when loaded. NBYTES will be a C
24437 expression of type `int'.
24439 -- Macro: ASM_NO_SKIP_IN_TEXT
24440 Define this macro if `ASM_OUTPUT_SKIP' should not be used in the
24441 text section because it fails to put zeros in the bytes that are
24442 skipped. This is true on many Unix systems, where the pseudo-op
24443 to skip bytes produces no-op instructions rather than zeros when
24444 used in the text section.
24446 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER)
24447 A C statement to output to the stdio stream STREAM an assembler
24448 command to advance the location counter to a multiple of 2 to the
24449 POWER bytes. POWER will be a C expression of type `int'.
24451 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER)
24452 Like `ASM_OUTPUT_ALIGN', except that the "nop" instruction is used
24453 for padding, if necessary.
24455 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP)
24456 A C statement to output to the stdio stream STREAM an assembler
24457 command to advance the location counter to a multiple of 2 to the
24458 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to
24459 satisfy the alignment request. POWER and MAX_SKIP will be a C
24460 expression of type `int'.
24463 File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros
24465 14.20 Controlling Debugging Information Format
24466 ==============================================
24468 This describes how to specify debugging information.
24472 * All Debuggers:: Macros that affect all debugging formats uniformly.
24473 * DBX Options:: Macros enabling specific options in DBX format.
24474 * DBX Hooks:: Hook macros for varying DBX format.
24475 * File Names and DBX:: Macros controlling output of file names in DBX format.
24476 * SDB and DWARF:: Macros for SDB (COFF) and DWARF formats.
24477 * VMS Debug:: Macros for VMS debug format.
24480 File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info
24482 14.20.1 Macros Affecting All Debugging Formats
24483 ----------------------------------------------
24485 These macros affect all debugging formats.
24487 -- Macro: DBX_REGISTER_NUMBER (REGNO)
24488 A C expression that returns the DBX register number for the
24489 compiler register number REGNO. In the default macro provided,
24490 the value of this expression will be REGNO itself. But sometimes
24491 there are some registers that the compiler knows about and DBX
24492 does not, or vice versa. In such cases, some register may need to
24493 have one number in the compiler and another for DBX.
24495 If two registers have consecutive numbers inside GCC, and they can
24496 be used as a pair to hold a multiword value, then they _must_ have
24497 consecutive numbers after renumbering with `DBX_REGISTER_NUMBER'.
24498 Otherwise, debuggers will be unable to access such a pair, because
24499 they expect register pairs to be consecutive in their own
24502 If you find yourself defining `DBX_REGISTER_NUMBER' in way that
24503 does not preserve register pairs, then what you must do instead is
24504 redefine the actual register numbering scheme.
24506 -- Macro: DEBUGGER_AUTO_OFFSET (X)
24507 A C expression that returns the integer offset value for an
24508 automatic variable having address X (an RTL expression). The
24509 default computation assumes that X is based on the frame-pointer
24510 and gives the offset from the frame-pointer. This is required for
24511 targets that produce debugging output for DBX or COFF-style
24512 debugging output for SDB and allow the frame-pointer to be
24513 eliminated when the `-g' options is used.
24515 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X)
24516 A C expression that returns the integer offset value for an
24517 argument having address X (an RTL expression). The nominal offset
24520 -- Macro: PREFERRED_DEBUGGING_TYPE
24521 A C expression that returns the type of debugging output GCC should
24522 produce when the user specifies just `-g'. Define this if you
24523 have arranged for GCC to support more than one format of debugging
24524 output. Currently, the allowable values are `DBX_DEBUG',
24525 `SDB_DEBUG', `DWARF_DEBUG', `DWARF2_DEBUG', `XCOFF_DEBUG',
24526 `VMS_DEBUG', and `VMS_AND_DWARF2_DEBUG'.
24528 When the user specifies `-ggdb', GCC normally also uses the value
24529 of this macro to select the debugging output format, but with two
24530 exceptions. If `DWARF2_DEBUGGING_INFO' is defined, GCC uses the
24531 value `DWARF2_DEBUG'. Otherwise, if `DBX_DEBUGGING_INFO' is
24532 defined, GCC uses `DBX_DEBUG'.
24534 The value of this macro only affects the default debugging output;
24535 the user can always get a specific type of output by using
24536 `-gstabs', `-gcoff', `-gdwarf-2', `-gxcoff', or `-gvms'.
24539 File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info
24541 14.20.2 Specific Options for DBX Output
24542 ---------------------------------------
24544 These are specific options for DBX output.
24546 -- Macro: DBX_DEBUGGING_INFO
24547 Define this macro if GCC should produce debugging output for DBX
24548 in response to the `-g' option.
24550 -- Macro: XCOFF_DEBUGGING_INFO
24551 Define this macro if GCC should produce XCOFF format debugging
24552 output in response to the `-g' option. This is a variant of DBX
24555 -- Macro: DEFAULT_GDB_EXTENSIONS
24556 Define this macro to control whether GCC should by default generate
24557 GDB's extended version of DBX debugging information (assuming
24558 DBX-format debugging information is enabled at all). If you don't
24559 define the macro, the default is 1: always generate the extended
24560 information if there is any occasion to.
24562 -- Macro: DEBUG_SYMS_TEXT
24563 Define this macro if all `.stabs' commands should be output while
24564 in the text section.
24566 -- Macro: ASM_STABS_OP
24567 A C string constant, including spacing, naming the assembler
24568 pseudo op to use instead of `"\t.stabs\t"' to define an ordinary
24569 debugging symbol. If you don't define this macro, `"\t.stabs\t"'
24570 is used. This macro applies only to DBX debugging information
24573 -- Macro: ASM_STABD_OP
24574 A C string constant, including spacing, naming the assembler
24575 pseudo op to use instead of `"\t.stabd\t"' to define a debugging
24576 symbol whose value is the current location. If you don't define
24577 this macro, `"\t.stabd\t"' is used. This macro applies only to
24578 DBX debugging information format.
24580 -- Macro: ASM_STABN_OP
24581 A C string constant, including spacing, naming the assembler
24582 pseudo op to use instead of `"\t.stabn\t"' to define a debugging
24583 symbol with no name. If you don't define this macro,
24584 `"\t.stabn\t"' is used. This macro applies only to DBX debugging
24585 information format.
24587 -- Macro: DBX_NO_XREFS
24588 Define this macro if DBX on your system does not support the
24589 construct `xsTAGNAME'. On some systems, this construct is used to
24590 describe a forward reference to a structure named TAGNAME. On
24591 other systems, this construct is not supported at all.
24593 -- Macro: DBX_CONTIN_LENGTH
24594 A symbol name in DBX-format debugging information is normally
24595 continued (split into two separate `.stabs' directives) when it
24596 exceeds a certain length (by default, 80 characters). On some
24597 operating systems, DBX requires this splitting; on others,
24598 splitting must not be done. You can inhibit splitting by defining
24599 this macro with the value zero. You can override the default
24600 splitting-length by defining this macro as an expression for the
24603 -- Macro: DBX_CONTIN_CHAR
24604 Normally continuation is indicated by adding a `\' character to
24605 the end of a `.stabs' string when a continuation follows. To use
24606 a different character instead, define this macro as a character
24607 constant for the character you want to use. Do not define this
24608 macro if backslash is correct for your system.
24610 -- Macro: DBX_STATIC_STAB_DATA_SECTION
24611 Define this macro if it is necessary to go to the data section
24612 before outputting the `.stabs' pseudo-op for a non-global static
24615 -- Macro: DBX_TYPE_DECL_STABS_CODE
24616 The value to use in the "code" field of the `.stabs' directive for
24617 a typedef. The default is `N_LSYM'.
24619 -- Macro: DBX_STATIC_CONST_VAR_CODE
24620 The value to use in the "code" field of the `.stabs' directive for
24621 a static variable located in the text section. DBX format does not
24622 provide any "right" way to do this. The default is `N_FUN'.
24624 -- Macro: DBX_REGPARM_STABS_CODE
24625 The value to use in the "code" field of the `.stabs' directive for
24626 a parameter passed in registers. DBX format does not provide any
24627 "right" way to do this. The default is `N_RSYM'.
24629 -- Macro: DBX_REGPARM_STABS_LETTER
24630 The letter to use in DBX symbol data to identify a symbol as a
24631 parameter passed in registers. DBX format does not customarily
24632 provide any way to do this. The default is `'P''.
24634 -- Macro: DBX_FUNCTION_FIRST
24635 Define this macro if the DBX information for a function and its
24636 arguments should precede the assembler code for the function.
24637 Normally, in DBX format, the debugging information entirely
24638 follows the assembler code.
24640 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE
24641 Define this macro, with value 1, if the value of a symbol
24642 describing the scope of a block (`N_LBRAC' or `N_RBRAC') should be
24643 relative to the start of the enclosing function. Normally, GCC
24644 uses an absolute address.
24646 -- Macro: DBX_LINES_FUNCTION_RELATIVE
24647 Define this macro, with value 1, if the value of a symbol
24648 indicating the current line number (`N_SLINE') should be relative
24649 to the start of the enclosing function. Normally, GCC uses an
24652 -- Macro: DBX_USE_BINCL
24653 Define this macro if GCC should generate `N_BINCL' and `N_EINCL'
24654 stabs for included header files, as on Sun systems. This macro
24655 also directs GCC to output a type number as a pair of a file
24656 number and a type number within the file. Normally, GCC does not
24657 generate `N_BINCL' or `N_EINCL' stabs, and it outputs a single
24658 number for a type number.
24661 File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info
24663 14.20.3 Open-Ended Hooks for DBX Format
24664 ---------------------------------------
24666 These are hooks for DBX format.
24668 -- Macro: DBX_OUTPUT_LBRAC (STREAM, NAME)
24669 Define this macro to say how to output to STREAM the debugging
24670 information for the start of a scope level for variable names. The
24671 argument NAME is the name of an assembler symbol (for use with
24672 `assemble_name') whose value is the address where the scope begins.
24674 -- Macro: DBX_OUTPUT_RBRAC (STREAM, NAME)
24675 Like `DBX_OUTPUT_LBRAC', but for the end of a scope level.
24677 -- Macro: DBX_OUTPUT_NFUN (STREAM, LSCOPE_LABEL, DECL)
24678 Define this macro if the target machine requires special handling
24679 to output an `N_FUN' entry for the function DECL.
24681 -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER)
24682 A C statement to output DBX debugging information before code for
24683 line number LINE of the current source file to the stdio stream
24684 STREAM. COUNTER is the number of time the macro was invoked,
24685 including the current invocation; it is intended to generate
24686 unique labels in the assembly output.
24688 This macro should not be defined if the default output is correct,
24689 or if it can be made correct by defining
24690 `DBX_LINES_FUNCTION_RELATIVE'.
24692 -- Macro: NO_DBX_FUNCTION_END
24693 Some stabs encapsulation formats (in particular ECOFF), cannot
24694 handle the `.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx
24695 extension construct. On those machines, define this macro to turn
24696 this feature off without disturbing the rest of the gdb extensions.
24698 -- Macro: NO_DBX_BNSYM_ENSYM
24699 Some assemblers cannot handle the `.stabd BNSYM/ENSYM,0,0' gdb dbx
24700 extension construct. On those machines, define this macro to turn
24701 this feature off without disturbing the rest of the gdb extensions.
24704 File: gccint.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info
24706 14.20.4 File Names in DBX Format
24707 --------------------------------
24709 This describes file names in DBX format.
24711 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME)
24712 A C statement to output DBX debugging information to the stdio
24713 stream STREAM, which indicates that file NAME is the main source
24714 file--the file specified as the input file for compilation. This
24715 macro is called only once, at the beginning of compilation.
24717 This macro need not be defined if the standard form of output for
24718 DBX debugging information is appropriate.
24720 It may be necessary to refer to a label equal to the beginning of
24721 the text section. You can use `assemble_name (stream,
24722 ltext_label_name)' to do so. If you do this, you must also set
24723 the variable USED_LTEXT_LABEL_NAME to `true'.
24725 -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY
24726 Define this macro, with value 1, if GCC should not emit an
24727 indication of the current directory for compilation and current
24728 source language at the beginning of the file.
24730 -- Macro: NO_DBX_GCC_MARKER
24731 Define this macro, with value 1, if GCC should not emit an
24732 indication that this object file was compiled by GCC. The default
24733 is to emit an `N_OPT' stab at the beginning of every source file,
24734 with `gcc2_compiled.' for the string and value 0.
24736 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME)
24737 A C statement to output DBX debugging information at the end of
24738 compilation of the main source file NAME. Output should be
24739 written to the stdio stream STREAM.
24741 If you don't define this macro, nothing special is output at the
24742 end of compilation, which is correct for most machines.
24744 -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END
24745 Define this macro _instead of_ defining
24746 `DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at
24747 the end of compilation is a `N_SO' stab with an empty string,
24748 whose value is the highest absolute text address in the file.
24751 File: gccint.info, Node: SDB and DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info
24753 14.20.5 Macros for SDB and DWARF Output
24754 ---------------------------------------
24756 Here are macros for SDB and DWARF output.
24758 -- Macro: SDB_DEBUGGING_INFO
24759 Define this macro if GCC should produce COFF-style debugging output
24760 for SDB in response to the `-g' option.
24762 -- Macro: DWARF2_DEBUGGING_INFO
24763 Define this macro if GCC should produce dwarf version 2 format
24764 debugging output in response to the `-g' option.
24766 -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (tree
24768 Define this to enable the dwarf attribute
24769 `DW_AT_calling_convention' to be emitted for each function.
24770 Instead of an integer return the enum value for the `DW_CC_'
24773 To support optional call frame debugging information, you must also
24774 define `INCOMING_RETURN_ADDR_RTX' and either set
24775 `RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the
24776 prologue, or call `dwarf2out_def_cfa' and `dwarf2out_reg_save' as
24777 appropriate from `TARGET_ASM_FUNCTION_PROLOGUE' if you don't.
24779 -- Macro: DWARF2_FRAME_INFO
24780 Define this macro to a nonzero value if GCC should always output
24781 Dwarf 2 frame information. If `DWARF2_UNWIND_INFO' (*note
24782 Exception Region Output:: is nonzero, GCC will output this
24783 information not matter how you define `DWARF2_FRAME_INFO'.
24785 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO
24786 Define this macro to be a nonzero value if the assembler can
24787 generate Dwarf 2 line debug info sections. This will result in
24788 much more compact line number tables, and hence is desirable if it
24791 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2)
24792 A C statement to issue assembly directives that create a difference
24793 between the two given labels, using an integer of the given size.
24795 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL)
24796 A C statement to issue assembly directives that create a
24797 section-relative reference to the given label, using an integer of
24800 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL)
24801 A C statement to issue assembly directives that create a
24802 self-relative reference to the given label, using an integer of
24805 -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int
24807 If defined, this target hook is a function which outputs a
24808 DTP-relative reference to the given TLS symbol of the specified
24811 -- Macro: PUT_SDB_...
24812 Define these macros to override the assembler syntax for the
24813 special SDB assembler directives. See `sdbout.c' for a list of
24814 these macros and their arguments. If the standard syntax is used,
24815 you need not define them yourself.
24817 -- Macro: SDB_DELIM
24818 Some assemblers do not support a semicolon as a delimiter, even
24819 between SDB assembler directives. In that case, define this macro
24820 to be the delimiter to use (usually `\n'). It is not necessary to
24821 define a new set of `PUT_SDB_OP' macros if this is the only change
24824 -- Macro: SDB_ALLOW_UNKNOWN_REFERENCES
24825 Define this macro to allow references to unknown structure, union,
24826 or enumeration tags to be emitted. Standard COFF does not allow
24827 handling of unknown references, MIPS ECOFF has support for it.
24829 -- Macro: SDB_ALLOW_FORWARD_REFERENCES
24830 Define this macro to allow references to structure, union, or
24831 enumeration tags that have not yet been seen to be handled. Some
24832 assemblers choke if forward tags are used, while some require it.
24834 -- Macro: SDB_OUTPUT_SOURCE_LINE (STREAM, LINE)
24835 A C statement to output SDB debugging information before code for
24836 line number LINE of the current source file to the stdio stream
24837 STREAM. The default is to emit an `.ln' directive.
24840 File: gccint.info, Node: VMS Debug, Prev: SDB and DWARF, Up: Debugging Info
24842 14.20.6 Macros for VMS Debug Format
24843 -----------------------------------
24845 Here are macros for VMS debug format.
24847 -- Macro: VMS_DEBUGGING_INFO
24848 Define this macro if GCC should produce debugging output for VMS
24849 in response to the `-g' option. The default behavior for VMS is
24850 to generate minimal debug info for a traceback in the absence of
24851 `-g' unless explicitly overridden with `-g0'. This behavior is
24852 controlled by `OPTIMIZATION_OPTIONS' and `OVERRIDE_OPTIONS'.
24855 File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros
24857 14.21 Cross Compilation and Floating Point
24858 ==========================================
24860 While all modern machines use twos-complement representation for
24861 integers, there are a variety of representations for floating point
24862 numbers. This means that in a cross-compiler the representation of
24863 floating point numbers in the compiled program may be different from
24864 that used in the machine doing the compilation.
24866 Because different representation systems may offer different amounts of
24867 range and precision, all floating point constants must be represented in
24868 the target machine's format. Therefore, the cross compiler cannot
24869 safely use the host machine's floating point arithmetic; it must emulate
24870 the target's arithmetic. To ensure consistency, GCC always uses
24871 emulation to work with floating point values, even when the host and
24872 target floating point formats are identical.
24874 The following macros are provided by `real.h' for the compiler to use.
24875 All parts of the compiler which generate or optimize floating-point
24876 calculations must use these macros. They may evaluate their operands
24877 more than once, so operands must not have side effects.
24879 -- Macro: REAL_VALUE_TYPE
24880 The C data type to be used to hold a floating point value in the
24881 target machine's format. Typically this is a `struct' containing
24882 an array of `HOST_WIDE_INT', but all code should treat it as an
24885 -- Macro: int REAL_VALUES_EQUAL (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
24886 Compares for equality the two values, X and Y. If the target
24887 floating point format supports negative zeroes and/or NaNs,
24888 `REAL_VALUES_EQUAL (-0.0, 0.0)' is true, and `REAL_VALUES_EQUAL
24889 (NaN, NaN)' is false.
24891 -- Macro: int REAL_VALUES_LESS (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
24892 Tests whether X is less than Y.
24894 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X)
24895 Truncates X to a signed integer, rounding toward zero.
24897 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX
24898 (REAL_VALUE_TYPE X)
24899 Truncates X to an unsigned integer, rounding toward zero. If X is
24900 negative, returns zero.
24902 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, enum
24904 Converts STRING into a floating point number in the target
24905 machine's representation for mode MODE. This routine can handle
24906 both decimal and hexadecimal floating point constants, using the
24907 syntax defined by the C language for both.
24909 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X)
24910 Returns 1 if X is negative (including negative zero), 0 otherwise.
24912 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X)
24913 Determines whether X represents infinity (positive or negative).
24915 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X)
24916 Determines whether X represents a "NaN" (not-a-number).
24918 -- Macro: void REAL_ARITHMETIC (REAL_VALUE_TYPE OUTPUT, enum tree_code
24919 CODE, REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
24920 Calculates an arithmetic operation on the two floating point values
24921 X and Y, storing the result in OUTPUT (which must be a variable).
24923 The operation to be performed is specified by CODE. Only the
24924 following codes are supported: `PLUS_EXPR', `MINUS_EXPR',
24925 `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'.
24927 If `REAL_ARITHMETIC' is asked to evaluate division by zero and the
24928 target's floating point format cannot represent infinity, it will
24929 call `abort'. Callers should check for this situation first, using
24930 `MODE_HAS_INFINITIES'. *Note Storage Layout::.
24932 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X)
24933 Returns the negative of the floating point value X.
24935 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X)
24936 Returns the absolute value of X.
24938 -- Macro: REAL_VALUE_TYPE REAL_VALUE_TRUNCATE (REAL_VALUE_TYPE MODE,
24939 enum machine_mode X)
24940 Truncates the floating point value X to fit in MODE. The return
24941 value is still a full-size `REAL_VALUE_TYPE', but it has an
24942 appropriate bit pattern to be output asa floating constant whose
24943 precision accords with mode MODE.
24945 -- Macro: void REAL_VALUE_TO_INT (HOST_WIDE_INT LOW, HOST_WIDE_INT
24946 HIGH, REAL_VALUE_TYPE X)
24947 Converts a floating point value X into a double-precision integer
24948 which is then stored into LOW and HIGH. If the value is not
24949 integral, it is truncated.
24951 -- Macro: void REAL_VALUE_FROM_INT (REAL_VALUE_TYPE X, HOST_WIDE_INT
24952 LOW, HOST_WIDE_INT HIGH, enum machine_mode MODE)
24953 Converts a double-precision integer found in LOW and HIGH, into a
24954 floating point value which is then stored into X. The value is
24955 truncated to fit in mode MODE.
24958 File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros
24960 14.22 Mode Switching Instructions
24961 =================================
24963 The following macros control mode switching optimizations:
24965 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY)
24966 Define this macro if the port needs extra instructions inserted
24967 for mode switching in an optimizing compilation.
24969 For an example, the SH4 can perform both single and double
24970 precision floating point operations, but to perform a single
24971 precision operation, the FPSCR PR bit has to be cleared, while for
24972 a double precision operation, this bit has to be set. Changing
24973 the PR bit requires a general purpose register as a scratch
24974 register, hence these FPSCR sets have to be inserted before
24975 reload, i.e. you can't put this into instruction emitting or
24976 `TARGET_MACHINE_DEPENDENT_REORG'.
24978 You can have multiple entities that are mode-switched, and select
24979 at run time which entities actually need it.
24980 `OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY
24981 that needs mode-switching. If you define this macro, you also
24982 have to define `NUM_MODES_FOR_MODE_SWITCHING', `MODE_NEEDED',
24983 `MODE_PRIORITY_TO_MODE' and `EMIT_MODE_SET'. `MODE_AFTER',
24984 `MODE_ENTRY', and `MODE_EXIT' are optional.
24986 -- Macro: NUM_MODES_FOR_MODE_SWITCHING
24987 If you define `OPTIMIZE_MODE_SWITCHING', you have to define this as
24988 initializer for an array of integers. Each initializer element N
24989 refers to an entity that needs mode switching, and specifies the
24990 number of different modes that might need to be set for this
24991 entity. The position of the initializer in the
24992 initializer--starting counting at zero--determines the integer
24993 that is used to refer to the mode-switched entity in question. In
24994 macros that take mode arguments / yield a mode result, modes are
24995 represented as numbers 0 ... N - 1. N is used to specify that no
24996 mode switch is needed / supplied.
24998 -- Macro: MODE_NEEDED (ENTITY, INSN)
24999 ENTITY is an integer specifying a mode-switched entity. If
25000 `OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to
25001 return an integer value not larger than the corresponding element
25002 in `NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY
25003 must be switched into prior to the execution of INSN.
25005 -- Macro: MODE_AFTER (MODE, INSN)
25006 If this macro is defined, it is evaluated for every INSN during
25007 mode switching. It determines the mode that an insn results in (if
25008 different from the incoming mode).
25010 -- Macro: MODE_ENTRY (ENTITY)
25011 If this macro is defined, it is evaluated for every ENTITY that
25012 needs mode switching. It should evaluate to an integer, which is
25013 a mode that ENTITY is assumed to be switched to at function entry.
25014 If `MODE_ENTRY' is defined then `MODE_EXIT' must be defined.
25016 -- Macro: MODE_EXIT (ENTITY)
25017 If this macro is defined, it is evaluated for every ENTITY that
25018 needs mode switching. It should evaluate to an integer, which is
25019 a mode that ENTITY is assumed to be switched to at function exit.
25020 If `MODE_EXIT' is defined then `MODE_ENTRY' must be defined.
25022 -- Macro: MODE_PRIORITY_TO_MODE (ENTITY, N)
25023 This macro specifies the order in which modes for ENTITY are
25024 processed. 0 is the highest priority,
25025 `NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value
25026 of the macro should be an integer designating a mode for ENTITY.
25027 For any fixed ENTITY, `mode_priority_to_mode' (ENTITY, N) shall be
25028 a bijection in 0 ... `num_modes_for_mode_switching[ENTITY] - 1'.
25030 -- Macro: EMIT_MODE_SET (ENTITY, MODE, HARD_REGS_LIVE)
25031 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE
25032 is the set of hard registers live at the point where the insn(s)
25033 are to be inserted.
25036 File: gccint.info, Node: Target Attributes, Next: MIPS Coprocessors, Prev: Mode Switching, Up: Target Macros
25038 14.23 Defining target-specific uses of `__attribute__'
25039 ======================================================
25041 Target-specific attributes may be defined for functions, data and types.
25042 These are described using the following target hooks; they also need to
25043 be documented in `extend.texi'.
25045 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE
25046 If defined, this target hook points to an array of `struct
25047 attribute_spec' (defined in `tree.h') specifying the machine
25048 specific attributes for this target and some of the restrictions
25049 on the entities to which these attributes are applied and the
25050 arguments they take.
25052 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (tree TYPE1, tree
25054 If defined, this target hook is a function which returns zero if
25055 the attributes on TYPE1 and TYPE2 are incompatible, one if they
25056 are compatible, and two if they are nearly compatible (which
25057 causes a warning to be generated). If this is not defined,
25058 machine-specific attributes are supposed always to be compatible.
25060 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE)
25061 If defined, this target hook is a function which assigns default
25062 attributes to newly defined TYPE.
25064 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree
25066 Define this target hook if the merging of type attributes needs
25067 special handling. If defined, the result is a list of the combined
25068 `TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that
25069 `comptypes' has already been called and returned 1. This function
25070 may call `merge_attributes' to handle machine-independent merging.
25072 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree
25074 Define this target hook if the merging of decl attributes needs
25075 special handling. If defined, the result is a list of the combined
25076 `DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate
25077 declaration of OLDDECL. Examples of when this is needed are when
25078 one attribute overrides another, or when an attribute is nullified
25079 by a subsequent definition. This function may call
25080 `merge_attributes' to handle machine-independent merging.
25082 If the only target-specific handling you require is `dllimport'
25083 for Microsoft Windows targets, you should define the macro
25084 `TARGET_DLLIMPORT_DECL_ATTRIBUTES' to `1'. The compiler will then
25085 define a function called `merge_dllimport_decl_attributes' which
25086 can then be defined as the expansion of
25087 `TARGET_MERGE_DECL_ATTRIBUTES'. You can also add
25088 `handle_dll_attribute' in the attribute table for your port to
25089 perform initial processing of the `dllimport' and `dllexport'
25090 attributes. This is done in `i386/cygwin.h' and `i386/i386.c',
25093 -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (tree DECL)
25094 DECL is a variable or function with `__attribute__((dllimport))'
25095 specified. Use this hook if the target needs to add extra
25096 validation checks to `handle_dll_attribute'.
25098 -- Macro: TARGET_DECLSPEC
25099 Define this macro to a nonzero value if you want to treat
25100 `__declspec(X)' as equivalent to `__attribute((X))'. By default,
25101 this behavior is enabled only for targets that define
25102 `TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of
25103 `__declspec' is via a built-in macro, but you should not rely on
25104 this implementation detail.
25106 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree
25108 Define this target hook if you want to be able to add attributes
25109 to a decl when it is being created. This is normally useful for
25110 back ends which wish to implement a pragma by using the attributes
25111 which correspond to the pragma's effect. The NODE argument is the
25112 decl which is being created. The ATTR_PTR argument is a pointer
25113 to the attribute list for this decl. The list itself should not
25114 be modified, since it may be shared with other decls, but
25115 attributes may be chained on the head of the list and `*ATTR_PTR'
25116 modified to point to the new attributes, or a copy of the list may
25117 be made if further changes are needed.
25119 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (tree
25121 This target hook returns `true' if it is ok to inline FNDECL into
25122 the current function, despite its having target-specific
25123 attributes, `false' otherwise. By default, if a function has a
25124 target specific attribute attached to it, it will not be inlined.
25127 File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Target Attributes, Up: Target Macros
25129 14.24 Defining coprocessor specifics for MIPS targets.
25130 ======================================================
25132 The MIPS specification allows MIPS implementations to have as many as 4
25133 coprocessors, each with as many as 32 private registers. GCC supports
25134 accessing these registers and transferring values between the registers
25135 and memory using asm-ized variables. For example:
25137 register unsigned int cp0count asm ("c0r1");
25142 ("c0r1" is the default name of register 1 in coprocessor 0; alternate
25143 names may be added as described below, or the default names may be
25144 overridden entirely in `SUBTARGET_CONDITIONAL_REGISTER_USAGE'.)
25146 Coprocessor registers are assumed to be epilogue-used; sets to them
25147 will be preserved even if it does not appear that the register is used
25148 again later in the function.
25150 Another note: according to the MIPS spec, coprocessor 1 (if present) is
25151 the FPU. One accesses COP1 registers through standard mips
25152 floating-point support; they are not included in this mechanism.
25154 There is one macro used in defining the MIPS coprocessor interface
25155 which you may want to override in subtargets; it is described below.
25157 -- Macro: ALL_COP_ADDITIONAL_REGISTER_NAMES
25158 A comma-separated list (with leading comma) of pairs describing the
25159 alternate names of coprocessor registers. The format of each
25161 { ALTERNATENAME, REGISTER_NUMBER}
25165 File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros
25167 14.25 Parameters for Precompiled Header Validity Checking
25168 =========================================================
25170 -- Target Hook: void *TARGET_GET_PCH_VALIDITY (size_t *SZ)
25171 This hook returns the data needed by `TARGET_PCH_VALID_P' and sets
25172 `*SZ' to the size of the data in bytes.
25174 -- Target Hook: const char *TARGET_PCH_VALID_P (const void *DATA,
25176 This hook checks whether the options used to create a PCH file are
25177 compatible with the current settings. It returns `NULL' if so and
25178 a suitable error message if not. Error messages will be presented
25179 to the user and must be localized using `_(MSG)'.
25181 DATA is the data that was returned by `TARGET_GET_PCH_VALIDITY'
25182 when the PCH file was created and SZ is the size of that data in
25183 bytes. It's safe to assume that the data was created by the same
25184 version of the compiler, so no format checking is needed.
25186 The default definition of `default_pch_valid_p' should be suitable
25189 -- Target Hook: const char *TARGET_CHECK_PCH_TARGET_FLAGS (int
25191 If this hook is nonnull, the default implementation of
25192 `TARGET_PCH_VALID_P' will use it to check for compatible values of
25193 `target_flags'. PCH_FLAGS specifies the value that `target_flags'
25194 had when the PCH file was created. The return value is the same
25195 as for `TARGET_PCH_VALID_P'.
25198 File: gccint.info, Node: C++ ABI, Next: Misc, Prev: PCH Target, Up: Target Macros
25200 14.26 C++ ABI parameters
25201 ========================
25203 -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void)
25204 Define this hook to override the integer type used for guard
25205 variables. These are used to implement one-time construction of
25206 static objects. The default is long_long_integer_type_node.
25208 -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void)
25209 This hook determines how guard variables are used. It should
25210 return `false' (the default) if first byte should be used. A
25211 return value of `true' indicates the least significant bit should
25214 -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE)
25215 This hook returns the size of the cookie to use when allocating an
25216 array whose elements have the indicated TYPE. Assumes that it is
25217 already known that a cookie is needed. The default is `max(sizeof
25218 (size_t), alignof(type))', as defined in section 2.7 of the
25219 IA64/Generic C++ ABI.
25221 -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void)
25222 This hook should return `true' if the element size should be
25223 stored in array cookies. The default is to return `false'.
25225 -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int
25227 If defined by a backend this hook allows the decision made to
25228 export class TYPE to be overruled. Upon entry IMPORT_EXPORT will
25229 contain 1 if the class is going to be exported, -1 if it is going
25230 to be imported and 0 otherwise. This function should return the
25231 modified value and perform any other actions necessary to support
25232 the backend's targeted operating system.
25234 -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void)
25235 This hook should return `true' if constructors and destructors
25236 return the address of the object created/destroyed. The default
25237 is to return `false'.
25239 -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void)
25240 This hook returns true if the key method for a class (i.e., the
25241 method which, if defined in the current translation unit, causes
25242 the virtual table to be emitted) may be an inline function. Under
25243 the standard Itanium C++ ABI the key method may be an inline
25244 function so long as the function is not declared inline in the
25245 class definition. Under some variants of the ABI, an inline
25246 function can never be the key method. The default is to return
25249 -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree
25251 DECL is a virtual table, virtual table table, typeinfo object, or
25252 other similar implicit class data object that will be emitted with
25253 external linkage in this translation unit. No ELF visibility has
25254 been explicitly specified. If the target needs to specify a
25255 visibility other than that of the containing class, use this hook
25256 to set `DECL_VISIBILITY' and `DECL_VISIBILITY_SPECIFIED'.
25258 -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void)
25259 This hook returns true (the default) if virtual tables and other
25260 similar implicit class data objects are always COMDAT if they have
25261 external linkage. If this hook returns false, then class data for
25262 classes whose virtual table will be emitted in only one translation
25263 unit will not be COMDAT.
25265 -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void)
25266 This hook returns true if `__aeabi_atexit' (as defined by the ARM
25267 EABI) should be used to register static destructors when
25268 `-fuse-cxa-atexit' is in effect. The default is to return false
25269 to use `__cxa_atexit'.
25271 -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE)
25272 TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has
25273 just been defined. Use this hook to make adjustments to the class
25274 (eg, tweak visibility or perform any other required target
25278 File: gccint.info, Node: Misc, Prev: C++ ABI, Up: Target Macros
25280 14.27 Miscellaneous Parameters
25281 ==============================
25283 Here are several miscellaneous parameters.
25285 -- Macro: HAS_LONG_COND_BRANCH
25286 Define this boolean macro to indicate whether or not your
25287 architecture has conditional branches that can span all of memory.
25288 It is used in conjunction with an optimization that partitions
25289 hot and cold basic blocks into separate sections of the
25290 executable. If this macro is set to false, gcc will convert any
25291 conditional branches that attempt to cross between sections into
25292 unconditional branches or indirect jumps.
25294 -- Macro: HAS_LONG_UNCOND_BRANCH
25295 Define this boolean macro to indicate whether or not your
25296 architecture has unconditional branches that can span all of
25297 memory. It is used in conjunction with an optimization that
25298 partitions hot and cold basic blocks into separate sections of the
25299 executable. If this macro is set to false, gcc will convert any
25300 unconditional branches that attempt to cross between sections into
25303 -- Macro: CASE_VECTOR_MODE
25304 An alias for a machine mode name. This is the machine mode that
25305 elements of a jump-table should have.
25307 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY)
25308 Optional: return the preferred mode for an `addr_diff_vec' when
25309 the minimum and maximum offset are known. If you define this, it
25310 enables extra code in branch shortening to deal with
25311 `addr_diff_vec'. To make this work, you also have to define
25312 `INSN_ALIGN' and make the alignment for `addr_diff_vec' explicit.
25313 The BODY argument is provided so that the offset_unsigned and scale
25314 flags can be updated.
25316 -- Macro: CASE_VECTOR_PC_RELATIVE
25317 Define this macro to be a C expression to indicate when jump-tables
25318 should contain relative addresses. You need not define this macro
25319 if jump-tables never contain relative addresses, or jump-tables
25320 should contain relative addresses only when `-fPIC' or `-fPIC' is
25323 -- Macro: CASE_VALUES_THRESHOLD
25324 Define this to be the smallest number of different values for
25325 which it is best to use a jump-table instead of a tree of
25326 conditional branches. The default is four for machines with a
25327 `casesi' instruction and five otherwise. This is best for most
25330 -- Macro: CASE_USE_BIT_TESTS
25331 Define this macro to be a C expression to indicate whether C switch
25332 statements may be implemented by a sequence of bit tests. This is
25333 advantageous on processors that can efficiently implement left
25334 shift of 1 by the number of bits held in a register, but
25335 inappropriate on targets that would require a loop. By default,
25336 this macro returns `true' if the target defines an `ashlsi3'
25337 pattern, and `false' otherwise.
25339 -- Macro: WORD_REGISTER_OPERATIONS
25340 Define this macro if operations between registers with integral
25341 mode smaller than a word are always performed on the entire
25342 register. Most RISC machines have this property and most CISC
25345 -- Macro: LOAD_EXTEND_OP (MEM_MODE)
25346 Define this macro to be a C expression indicating when insns that
25347 read memory in MEM_MODE, an integral mode narrower than a word,
25348 set the bits outside of MEM_MODE to be either the sign-extension
25349 or the zero-extension of the data read. Return `SIGN_EXTEND' for
25350 values of MEM_MODE for which the insn sign-extends, `ZERO_EXTEND'
25351 for which it zero-extends, and `UNKNOWN' for other modes.
25353 This macro is not called with MEM_MODE non-integral or with a width
25354 greater than or equal to `BITS_PER_WORD', so you may return any
25355 value in this case. Do not define this macro if it would always
25356 return `UNKNOWN'. On machines where this macro is defined, you
25357 will normally define it as the constant `SIGN_EXTEND' or
25360 You may return a non-`UNKNOWN' value even if for some hard
25361 registers the sign extension is not performed, if for the
25362 `REGNO_REG_CLASS' of these hard registers
25363 `CANNOT_CHANGE_MODE_CLASS' returns nonzero when the FROM mode is
25364 MEM_MODE and the TO mode is any integral mode larger than this but
25365 not larger than `word_mode'.
25367 You must return `UNKNOWN' if for some hard registers that allow
25368 this mode, `CANNOT_CHANGE_MODE_CLASS' says that they cannot change
25369 to `word_mode', but that they can change to another integral mode
25370 that is larger then MEM_MODE but still smaller than `word_mode'.
25372 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND
25373 Define this macro if loading short immediate values into registers
25376 -- Macro: FIXUNS_TRUNC_LIKE_FIX_TRUNC
25377 Define this macro if the same instructions that convert a floating
25378 point number to a signed fixed point number also convert validly
25379 to an unsigned one.
25381 -- Target Hook: int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL (enum
25383 When `-ffast-math' is in effect, GCC tries to optimize divisions
25384 by the same divisor, by turning them into multiplications by the
25385 reciprocal. This target hook specifies the minimum number of
25386 divisions that should be there for GCC to perform the optimization
25387 for a variable of mode MODE. The default implementation returns 3
25388 if the machine has an instruction for the division, and 2 if it
25392 The maximum number of bytes that a single instruction can move
25393 quickly between memory and registers or between two memory
25396 -- Macro: MAX_MOVE_MAX
25397 The maximum number of bytes that a single instruction can move
25398 quickly between memory and registers or between two memory
25399 locations. If this is undefined, the default is `MOVE_MAX'.
25400 Otherwise, it is the constant value that is the largest value that
25401 `MOVE_MAX' can have at run-time.
25403 -- Macro: SHIFT_COUNT_TRUNCATED
25404 A C expression that is nonzero if on this machine the number of
25405 bits actually used for the count of a shift operation is equal to
25406 the number of bits needed to represent the size of the object
25407 being shifted. When this macro is nonzero, the compiler will
25408 assume that it is safe to omit a sign-extend, zero-extend, and
25409 certain bitwise `and' instructions that truncates the count of a
25410 shift operation. On machines that have instructions that act on
25411 bit-fields at variable positions, which may include `bit test'
25412 instructions, a nonzero `SHIFT_COUNT_TRUNCATED' also enables
25413 deletion of truncations of the values that serve as arguments to
25414 bit-field instructions.
25416 If both types of instructions truncate the count (for shifts) and
25417 position (for bit-field operations), or if no variable-position
25418 bit-field instructions exist, you should define this macro.
25420 However, on some machines, such as the 80386 and the 680x0,
25421 truncation only applies to shift operations and not the (real or
25422 pretended) bit-field operations. Define `SHIFT_COUNT_TRUNCATED'
25423 to be zero on such machines. Instead, add patterns to the `md'
25424 file that include the implied truncation of the shift instructions.
25426 You need not define this macro if it would always have the value
25429 -- Target Hook: int TARGET_SHIFT_TRUNCATION_MASK (enum machine_mode
25431 This function describes how the standard shift patterns for MODE
25432 deal with shifts by negative amounts or by more than the width of
25433 the mode. *Note shift patterns::.
25435 On many machines, the shift patterns will apply a mask M to the
25436 shift count, meaning that a fixed-width shift of X by Y is
25437 equivalent to an arbitrary-width shift of X by Y & M. If this is
25438 true for mode MODE, the function should return M, otherwise it
25439 should return 0. A return value of 0 indicates that no particular
25440 behavior is guaranteed.
25442 Note that, unlike `SHIFT_COUNT_TRUNCATED', this function does
25443 _not_ apply to general shift rtxes; it applies only to instructions
25444 that are generated by the named shift patterns.
25446 The default implementation of this function returns
25447 `GET_MODE_BITSIZE (MODE) - 1' if `SHIFT_COUNT_TRUNCATED' and 0
25448 otherwise. This definition is always safe, but if
25449 `SHIFT_COUNT_TRUNCATED' is false, and some shift patterns
25450 nevertheless truncate the shift count, you may get better code by
25453 -- Macro: TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)
25454 A C expression which is nonzero if on this machine it is safe to
25455 "convert" an integer of INPREC bits to one of OUTPREC bits (where
25456 OUTPREC is smaller than INPREC) by merely operating on it as if it
25457 had only OUTPREC bits.
25459 On many machines, this expression can be 1.
25461 When `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for
25462 modes for which `MODES_TIEABLE_P' is 0, suboptimal code can result.
25463 If this is the case, making `TRULY_NOOP_TRUNCATION' return 0 in
25464 such cases may improve things.
25466 -- Macro: STORE_FLAG_VALUE
25467 A C expression describing the value returned by a comparison
25468 operator with an integral mode and stored by a store-flag
25469 instruction (`sCOND') when the condition is true. This
25470 description must apply to _all_ the `sCOND' patterns and all the
25471 comparison operators whose results have a `MODE_INT' mode.
25473 A value of 1 or -1 means that the instruction implementing the
25474 comparison operator returns exactly 1 or -1 when the comparison is
25475 true and 0 when the comparison is false. Otherwise, the value
25476 indicates which bits of the result are guaranteed to be 1 when the
25477 comparison is true. This value is interpreted in the mode of the
25478 comparison operation, which is given by the mode of the first
25479 operand in the `sCOND' pattern. Either the low bit or the sign
25480 bit of `STORE_FLAG_VALUE' be on. Presently, only those bits are
25481 used by the compiler.
25483 If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will
25484 generate code that depends only on the specified bits. It can also
25485 replace comparison operators with equivalent operations if they
25486 cause the required bits to be set, even if the remaining bits are
25487 undefined. For example, on a machine whose comparison operators
25488 return an `SImode' value and where `STORE_FLAG_VALUE' is defined as
25489 `0x80000000', saying that just the sign bit is relevant, the
25492 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0))
25494 can be converted to
25496 (ashift:SI X (const_int N))
25498 where N is the appropriate shift count to move the bit being
25499 tested into the sign bit.
25501 There is no way to describe a machine that always sets the
25502 low-order bit for a true value, but does not guarantee the value
25503 of any other bits, but we do not know of any machine that has such
25504 an instruction. If you are trying to port GCC to such a machine,
25505 include an instruction to perform a logical-and of the result with
25506 1 in the pattern for the comparison operators and let us know at
25509 Often, a machine will have multiple instructions that obtain a
25510 value from a comparison (or the condition codes). Here are rules
25511 to guide the choice of value for `STORE_FLAG_VALUE', and hence the
25512 instructions to be used:
25514 * Use the shortest sequence that yields a valid definition for
25515 `STORE_FLAG_VALUE'. It is more efficient for the compiler to
25516 "normalize" the value (convert it to, e.g., 1 or 0) than for
25517 the comparison operators to do so because there may be
25518 opportunities to combine the normalization with other
25521 * For equal-length sequences, use a value of 1 or -1, with -1
25522 being slightly preferred on machines with expensive jumps and
25523 1 preferred on other machines.
25525 * As a second choice, choose a value of `0x80000001' if
25526 instructions exist that set both the sign and low-order bits
25527 but do not define the others.
25529 * Otherwise, use a value of `0x80000000'.
25531 Many machines can produce both the value chosen for
25532 `STORE_FLAG_VALUE' and its negation in the same number of
25533 instructions. On those machines, you should also define a pattern
25534 for those cases, e.g., one matching
25536 (set A (neg:M (ne:M B C)))
25538 Some machines can also perform `and' or `plus' operations on
25539 condition code values with less instructions than the corresponding
25540 `sCOND' insn followed by `and' or `plus'. On those machines,
25541 define the appropriate patterns. Use the names `incscc' and
25542 `decscc', respectively, for the patterns which perform `plus' or
25543 `minus' operations on condition code values. See `rs6000.md' for
25544 some examples. The GNU Superoptizer can be used to find such
25545 instruction sequences on other machines.
25547 If this macro is not defined, the default value, 1, is used. You
25548 need not define `STORE_FLAG_VALUE' if the machine has no store-flag
25549 instructions, or if the value generated by these instructions is 1.
25551 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE)
25552 A C expression that gives a nonzero `REAL_VALUE_TYPE' value that is
25553 returned when comparison operators with floating-point results are
25554 true. Define this macro on machines that have comparison
25555 operations that return floating-point values. If there are no
25556 such operations, do not define this macro.
25558 -- Macro: VECTOR_STORE_FLAG_VALUE (MODE)
25559 A C expression that gives a rtx representing the nonzero true
25560 element for vector comparisons. The returned rtx should be valid
25561 for the inner mode of MODE which is guaranteed to be a vector
25562 mode. Define this macro on machines that have vector comparison
25563 operations that return a vector result. If there are no such
25564 operations, do not define this macro. Typically, this macro is
25565 defined as `const1_rtx' or `constm1_rtx'. This macro may return
25566 `NULL_RTX' to prevent the compiler optimizing such vector
25567 comparison operations for the given mode.
25569 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
25570 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
25571 A C expression that evaluates to true if the architecture defines
25572 a value for `clz' or `ctz' with a zero operand. If so, VALUE
25573 should be set to this value. If this macro is not defined, the
25574 value of `clz' or `ctz' is assumed to be undefined.
25576 This macro must be defined if the target's expansion for `ffs'
25577 relies on a particular value to get correct results. Otherwise it
25578 is not necessary, though it may be used to optimize some corner
25581 Note that regardless of this macro the "definedness" of `clz' and
25582 `ctz' at zero do _not_ extend to the builtin functions visible to
25583 the user. Thus one may be free to adjust the value at will to
25584 match the target expansion of these operations without fear of
25588 An alias for the machine mode for pointers. On most machines,
25589 define this to be the integer mode corresponding to the width of a
25590 hardware pointer; `SImode' on 32-bit machine or `DImode' on 64-bit
25591 machines. On some machines you must define this to be one of the
25592 partial integer modes, such as `PSImode'.
25594 The width of `Pmode' must be at least as large as the value of
25595 `POINTER_SIZE'. If it is not equal, you must define the macro
25596 `POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to
25599 -- Macro: FUNCTION_MODE
25600 An alias for the machine mode used for memory references to
25601 functions being called, in `call' RTL expressions. On most
25602 machines this should be `QImode'.
25604 -- Macro: STDC_0_IN_SYSTEM_HEADERS
25605 In normal operation, the preprocessor expands `__STDC__' to the
25606 constant 1, to signify that GCC conforms to ISO Standard C. On
25607 some hosts, like Solaris, the system compiler uses a different
25608 convention, where `__STDC__' is normally 0, but is 1 if the user
25609 specifies strict conformance to the C Standard.
25611 Defining `STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host
25612 convention when processing system header files, but when
25613 processing user files `__STDC__' will always expand to 1.
25615 -- Macro: NO_IMPLICIT_EXTERN_C
25616 Define this macro if the system header files support C++ as well
25617 as C. This macro inhibits the usual method of using system header
25618 files in C++, which is to pretend that the file's contents are
25619 enclosed in `extern "C" {...}'.
25621 -- Macro: REGISTER_TARGET_PRAGMAS ()
25622 Define this macro if you want to implement any target-specific
25623 pragmas. If defined, it is a C expression which makes a series of
25624 calls to `c_register_pragma' or `c_register_pragma_with_expansion'
25625 for each pragma. The macro may also do any setup required for the
25628 The primary reason to define this macro is to provide
25629 compatibility with other compilers for the same target. In
25630 general, we discourage definition of target-specific pragmas for
25633 If the pragma can be implemented by attributes then you should
25634 consider defining the target hook `TARGET_INSERT_ATTRIBUTES' as
25637 Preprocessor macros that appear on pragma lines are not expanded.
25638 All `#pragma' directives that do not match any registered pragma
25639 are silently ignored, unless the user specifies
25640 `-Wunknown-pragmas'.
25642 -- Function: void c_register_pragma (const char *SPACE, const char
25643 *NAME, void (*CALLBACK) (struct cpp_reader *))
25644 -- Function: void c_register_pragma_with_expansion (const char *SPACE,
25645 const char *NAME, void (*CALLBACK) (struct cpp_reader *))
25646 Each call to `c_register_pragma' or
25647 `c_register_pragma_with_expansion' establishes one pragma. The
25648 CALLBACK routine will be called when the preprocessor encounters a
25651 #pragma [SPACE] NAME ...
25653 SPACE is the case-sensitive namespace of the pragma, or `NULL' to
25654 put the pragma in the global namespace. The callback routine
25655 receives PFILE as its first argument, which can be passed on to
25656 cpplib's functions if necessary. You can lex tokens after the
25657 NAME by calling `c_lex'. Tokens that are not read by the callback
25658 will be silently ignored. The end of the line is indicated by a
25659 token of type `CPP_EOF'. Macro expansion occurs on the arguments
25660 of pragmas registered with `c_register_pragma_with_expansion' but
25661 not on the arguments of pragmas registered with
25662 `c_register_pragma'.
25664 For an example use of this routine, see `c4x.h' and the callback
25665 routines defined in `c4x-c.c'.
25667 Note that the use of `c_lex' is specific to the C and C++
25668 compilers. It will not work in the Java or Fortran compilers, or
25669 any other language compilers for that matter. Thus if `c_lex' is
25670 going to be called from target-specific code, it must only be done
25671 so when building the C and C++ compilers. This can be done by
25672 defining the variables `c_target_objs' and `cxx_target_objs' in the
25673 target entry in the `config.gcc' file. These variables should name
25674 the target-specific, language-specific object file which contains
25675 the code that uses `c_lex'. Note it will also be necessary to add
25676 a rule to the makefile fragment pointed to by `tmake_file' that
25677 shows how to build this object file.
25679 -- Macro: HANDLE_SYSV_PRAGMA
25680 Define this macro (to a value of 1) if you want the System V style
25681 pragmas `#pragma pack(<n>)' and `#pragma weak <name> [=<value>]'
25682 to be supported by gcc.
25684 The pack pragma specifies the maximum alignment (in bytes) of
25685 fields within a structure, in much the same way as the
25686 `__aligned__' and `__packed__' `__attribute__'s do. A pack value
25687 of zero resets the behavior to the default.
25689 A subtlety for Microsoft Visual C/C++ style bit-field packing
25690 (e.g. -mms-bitfields) for targets that support it: When a
25691 bit-field is inserted into a packed record, the whole size of the
25692 underlying type is used by one or more same-size adjacent
25693 bit-fields (that is, if its long:3, 32 bits is used in the record,
25694 and any additional adjacent long bit-fields are packed into the
25695 same chunk of 32 bits. However, if the size changes, a new field
25696 of that size is allocated).
25698 If both MS bit-fields and `__attribute__((packed))' are used, the
25699 latter will take precedence. If `__attribute__((packed))' is used
25700 on a single field when MS bit-fields are in use, it will take
25701 precedence for that field, but the alignment of the rest of the
25702 structure may affect its placement.
25704 The weak pragma only works if `SUPPORTS_WEAK' and
25705 `ASM_WEAKEN_LABEL' are defined. If enabled it allows the creation
25706 of specifically named weak labels, optionally with a value.
25708 -- Macro: HANDLE_PRAGMA_PACK_PUSH_POP
25709 Define this macro (to a value of 1) if you want to support the
25710 Win32 style pragmas `#pragma pack(push[,N])' and `#pragma
25711 pack(pop)'. The `pack(push,[N])' pragma specifies the maximum
25712 alignment (in bytes) of fields within a structure, in much the
25713 same way as the `__aligned__' and `__packed__' `__attribute__'s
25714 do. A pack value of zero resets the behavior to the default.
25715 Successive invocations of this pragma cause the previous values to
25716 be stacked, so that invocations of `#pragma pack(pop)' will return
25717 to the previous value.
25719 -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION
25720 Define this macro, as well as `HANDLE_SYSV_PRAGMA', if macros
25721 should be expanded in the arguments of `#pragma pack'.
25723 -- Macro: TARGET_DEFAULT_PACK_STRUCT
25724 If your target requires a structure packing default other than 0
25725 (meaning the machine default), define this macro to the necessary
25726 value (in bytes). This must be a value that would also valid to
25727 be used with `#pragma pack()' (that is, a small power of two).
25729 -- Macro: DOLLARS_IN_IDENTIFIERS
25730 Define this macro to control use of the character `$' in
25731 identifier names for the C family of languages. 0 means `$' is
25732 not allowed by default; 1 means it is allowed. 1 is the default;
25733 there is no need to define this macro in that case.
25735 -- Macro: NO_DOLLAR_IN_LABEL
25736 Define this macro if the assembler does not accept the character
25737 `$' in label names. By default constructors and destructors in
25738 G++ have `$' in the identifiers. If this macro is defined, `.' is
25741 -- Macro: NO_DOT_IN_LABEL
25742 Define this macro if the assembler does not accept the character
25743 `.' in label names. By default constructors and destructors in G++
25744 have names that use `.'. If this macro is defined, these names
25745 are rewritten to avoid `.'.
25747 -- Macro: INSN_SETS_ARE_DELAYED (INSN)
25748 Define this macro as a C expression that is nonzero if it is safe
25749 for the delay slot scheduler to place instructions in the delay
25750 slot of INSN, even if they appear to use a resource set or
25751 clobbered in INSN. INSN is always a `jump_insn' or an `insn'; GCC
25752 knows that every `call_insn' has this behavior. On machines where
25753 some `insn' or `jump_insn' is really a function call and hence has
25754 this behavior, you should define this macro.
25756 You need not define this macro if it would always return zero.
25758 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN)
25759 Define this macro as a C expression that is nonzero if it is safe
25760 for the delay slot scheduler to place instructions in the delay
25761 slot of INSN, even if they appear to set or clobber a resource
25762 referenced in INSN. INSN is always a `jump_insn' or an `insn'.
25763 On machines where some `insn' or `jump_insn' is really a function
25764 call and its operands are registers whose use is actually in the
25765 subroutine it calls, you should define this macro. Doing so
25766 allows the delay slot scheduler to move instructions which copy
25767 arguments into the argument registers into the delay slot of INSN.
25769 You need not define this macro if it would always return zero.
25771 -- Macro: MULTIPLE_SYMBOL_SPACES
25772 Define this macro as a C expression that is nonzero if, in some
25773 cases, global symbols from one translation unit may not be bound
25774 to undefined symbols in another translation unit without user
25775 intervention. For instance, under Microsoft Windows symbols must
25776 be explicitly imported from shared libraries (DLLs).
25778 You need not define this macro if it would always evaluate to zero.
25780 -- Target Hook: tree TARGET_MD_ASM_CLOBBERS (tree OUTPUTS, tree
25781 INPUTS, tree CLOBBERS)
25782 This target hook should add to CLOBBERS `STRING_CST' trees for any
25783 hard regs the port wishes to automatically clobber for an asm. It
25784 should return the result of the last `tree_cons' used to add a
25785 clobber. The OUTPUTS, INPUTS and CLOBBER lists are the
25786 corresponding parameters to the asm and may be inspected to avoid
25787 clobbering a register that is an input or output of the asm. You
25788 can use `tree_overlaps_hard_reg_set', declared in `tree.h', to test
25789 for overlap with regards to asm-declared registers.
25791 -- Macro: MATH_LIBRARY
25792 Define this macro as a C string constant for the linker argument
25793 to link in the system math library, or `""' if the target does not
25794 have a separate math library.
25796 You need only define this macro if the default of `"-lm"' is wrong.
25798 -- Macro: LIBRARY_PATH_ENV
25799 Define this macro as a C string constant for the environment
25800 variable that specifies where the linker should look for libraries.
25802 You need only define this macro if the default of `"LIBRARY_PATH"'
25805 -- Macro: TARGET_POSIX_IO
25806 Define this macro if the target supports the following POSIX file
25807 functions, access, mkdir and file locking with fcntl / F_SETLKW.
25808 Defining `TARGET_POSIX_IO' will enable the test coverage code to
25809 use file locking when exiting a program, which avoids race
25810 conditions if the program has forked. It will also create
25811 directories at run-time for cross-profiling.
25813 -- Macro: MAX_CONDITIONAL_EXECUTE
25814 A C expression for the maximum number of instructions to execute
25815 via conditional execution instructions instead of a branch. A
25816 value of `BRANCH_COST'+1 is the default if the machine does not
25817 use cc0, and 1 if it does use cc0.
25819 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR)
25820 Used if the target needs to perform machine-dependent
25821 modifications on the conditionals used for turning basic blocks
25822 into conditionally executed code. CE_INFO points to a data
25823 structure, `struct ce_if_block', which contains information about
25824 the currently processed blocks. TRUE_EXPR and FALSE_EXPR are the
25825 tests that are used for converting the then-block and the
25826 else-block, respectively. Set either TRUE_EXPR or FALSE_EXPR to a
25827 null pointer if the tests cannot be converted.
25829 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR,
25831 Like `IFCVT_MODIFY_TESTS', but used when converting more
25832 complicated if-statements into conditions combined by `and' and
25833 `or' operations. BB contains the basic block that contains the
25834 test that is currently being processed and about to be turned into
25837 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN)
25838 A C expression to modify the PATTERN of an INSN that is to be
25839 converted to conditional execution format. CE_INFO points to a
25840 data structure, `struct ce_if_block', which contains information
25841 about the currently processed blocks.
25843 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO)
25844 A C expression to perform any final machine dependent
25845 modifications in converting code to conditional execution. The
25846 involved basic blocks can be found in the `struct ce_if_block'
25847 structure that is pointed to by CE_INFO.
25849 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO)
25850 A C expression to cancel any machine dependent modifications in
25851 converting code to conditional execution. The involved basic
25852 blocks can be found in the `struct ce_if_block' structure that is
25853 pointed to by CE_INFO.
25855 -- Macro: IFCVT_INIT_EXTRA_FIELDS (CE_INFO)
25856 A C expression to initialize any extra fields in a `struct
25857 ce_if_block' structure, which are defined by the
25858 `IFCVT_EXTRA_FIELDS' macro.
25860 -- Macro: IFCVT_EXTRA_FIELDS
25861 If defined, it should expand to a set of field declarations that
25862 will be added to the `struct ce_if_block' structure. These should
25863 be initialized by the `IFCVT_INIT_EXTRA_FIELDS' macro.
25865 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG ()
25866 If non-null, this hook performs a target-specific pass over the
25867 instruction stream. The compiler will run it at all optimization
25868 levels, just before the point at which it normally does
25869 delayed-branch scheduling.
25871 The exact purpose of the hook varies from target to target. Some
25872 use it to do transformations that are necessary for correctness,
25873 such as laying out in-function constant pools or avoiding hardware
25874 hazards. Others use it as an opportunity to do some
25875 machine-dependent optimizations.
25877 You need not implement the hook if it has nothing to do. The
25878 default definition is null.
25880 -- Target Hook: void TARGET_INIT_BUILTINS ()
25881 Define this hook if you have any machine-specific built-in
25882 functions that need to be defined. It should be a function that
25883 performs the necessary setup.
25885 Machine specific built-in functions can be useful to expand
25886 special machine instructions that would otherwise not normally be
25887 generated because they have no equivalent in the source language
25888 (for example, SIMD vector instructions or prefetch instructions).
25890 To create a built-in function, call the function
25891 `lang_hooks.builtin_function' which is defined by the language
25892 front end. You can use any type nodes set up by
25893 `build_common_tree_nodes' and `build_common_tree_nodes_2'; only
25894 language front ends that use those two functions will call
25895 `TARGET_INIT_BUILTINS'.
25897 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx
25898 SUBTARGET, enum machine_mode MODE, int IGNORE)
25899 Expand a call to a machine specific built-in function that was set
25900 up by `TARGET_INIT_BUILTINS'. EXP is the expression for the
25901 function call; the result should go to TARGET if that is
25902 convenient, and have mode MODE if that is convenient. SUBTARGET
25903 may be used as the target for computing one of EXP's operands.
25904 IGNORE is nonzero if the value is to be ignored. This function
25905 should return the result of the call to the built-in function.
25907 -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (tree FNDECL,
25909 Select a replacement for a machine specific built-in function that
25910 was set up by `TARGET_INIT_BUILTINS'. This is done _before_
25911 regular type checking, and so allows the target to implement a
25912 crude form of function overloading. FNDECL is the declaration of
25913 the built-in function. ARGLIST is the list of arguments passed to
25914 the built-in function. The result is a complete expression that
25915 implements the operation, usually another `CALL_EXPR'.
25917 -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, tree ARGLIST,
25919 Fold a call to a machine specific built-in function that was set
25920 up by `TARGET_INIT_BUILTINS'. FNDECL is the declaration of the
25921 built-in function. ARGLIST is the list of arguments passed to the
25922 built-in function. The result is another tree containing a
25923 simplified expression for the call's result. If IGNORE is true
25924 the value will be ignored.
25926 -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (rtx INSN)
25927 Take an instruction in INSN and return NULL if it is valid within a
25928 low-overhead loop, otherwise return a string why doloop could not
25931 Many targets use special registers for low-overhead looping. For
25932 any instruction that clobbers these this function should return a
25933 string indicating the reason why the doloop could not be applied.
25934 By default, the RTL loop optimizer does not use a present doloop
25935 pattern for loops containing function calls or branch on table
25938 -- Macro: MD_CAN_REDIRECT_BRANCH (BRANCH1, BRANCH2)
25939 Take a branch insn in BRANCH1 and another in BRANCH2. Return true
25940 if redirecting BRANCH1 to the destination of BRANCH2 is possible.
25942 On some targets, branches may have a limited range. Optimizing the
25943 filling of delay slots can result in branches being redirected,
25944 and this may in turn cause a branch offset to overflow.
25946 -- Target Hook: bool TARGET_COMMUTATIVE_P (rtx X, OUTER_CODE)
25947 This target hook returns `true' if X is considered to be
25948 commutative. Usually, this is just COMMUTATIVE_P (X), but the HP
25949 PA doesn't consider PLUS to be commutative inside a MEM.
25950 OUTER_CODE is the rtx code of the enclosing rtl, if known,
25951 otherwise it is UNKNOWN.
25953 -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG)
25954 When the initial value of a hard register has been copied in a
25955 pseudo register, it is often not necessary to actually allocate
25956 another register to this pseudo register, because the original
25957 hard register or a stack slot it has been saved into can be used.
25958 `TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register
25959 allocation once for each hard register that had its initial value
25960 copied by using `get_func_hard_reg_initial_val' or
25961 `get_hard_reg_initial_val'. Possible values are `NULL_RTX', if
25962 you don't want to do any special allocation, a `REG' rtx--that
25963 would typically be the hard register itself, if it is known not to
25964 be clobbered--or a `MEM'. If you are returning a `MEM', this is
25965 only a hint for the allocator; it might decide to use another
25966 register anyways. You may use `current_function_leaf_function' in
25967 the hook, functions that use `REG_N_SETS', to determine if the hard
25968 register in question will not be clobbered. The default value of
25969 this hook is `NULL', which disables any special allocation.
25971 -- Macro: TARGET_OBJECT_SUFFIX
25972 Define this macro to be a C string representing the suffix for
25973 object files on your target machine. If you do not define this
25974 macro, GCC will use `.o' as the suffix for object files.
25976 -- Macro: TARGET_EXECUTABLE_SUFFIX
25977 Define this macro to be a C string representing the suffix to be
25978 automatically added to executable files on your target machine.
25979 If you do not define this macro, GCC will use the null string as
25980 the suffix for executable files.
25982 -- Macro: COLLECT_EXPORT_LIST
25983 If defined, `collect2' will scan the individual object files
25984 specified on its command line and create an export list for the
25985 linker. Define this macro for systems like AIX, where the linker
25986 discards object files that are not referenced from `main' and uses
25989 -- Macro: MODIFY_JNI_METHOD_CALL (MDECL)
25990 Define this macro to a C expression representing a variant of the
25991 method call MDECL, if Java Native Interface (JNI) methods must be
25992 invoked differently from other methods on your target. For
25993 example, on 32-bit Microsoft Windows, JNI methods must be invoked
25994 using the `stdcall' calling convention and this macro is then
25995 defined as this expression:
25997 build_type_attribute_variant (MDECL,
25999 (get_identifier ("stdcall"),
26002 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void)
26003 This target hook returns `true' past the point in which new jump
26004 instructions could be created. On machines that require a
26005 register for every jump such as the SHmedia ISA of SH5, this point
26006 would typically be reload, so this target hook should be defined
26007 to a function such as:
26010 cannot_modify_jumps_past_reload_p ()
26012 return (reload_completed || reload_in_progress);
26015 -- Target Hook: int TARGET_BRANCH_TARGET_REGISTER_CLASS (void)
26016 This target hook returns a register class for which branch target
26017 register optimizations should be applied. All registers in this
26018 class should be usable interchangeably. After reload, registers
26019 in this class will be re-allocated and loads will be hoisted out
26020 of loops and be subjected to inter-block scheduling.
26022 -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool
26023 AFTER_PROLOGUE_EPILOGUE_GEN)
26024 Branch target register optimization will by default exclude
26025 callee-saved registers that are not already live during the
26026 current function; if this target hook returns true, they will be
26027 included. The target code must than make sure that all target
26028 registers in the class returned by
26029 `TARGET_BRANCH_TARGET_REGISTER_CLASS' that might need saving are
26030 saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates if prologues and
26031 epilogues have already been generated. Note, even if you only
26032 return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, you still
26033 are likely to have to make special provisions in
26034 `INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved
26037 -- Macro: POWI_MAX_MULTS
26038 If defined, this macro is interpreted as a signed integer C
26039 expression that specifies the maximum number of floating point
26040 multiplications that should be emitted when expanding
26041 exponentiation by an integer constant inline. When this value is
26042 defined, exponentiation requiring more than this number of
26043 multiplications is implemented by calling the system library's
26044 `pow', `powf' or `powl' routines. The default value places no
26045 upper bound on the multiplication count.
26047 -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char
26048 *IPREFIX, int STDINC)
26049 This target hook should register any extra include files for the
26050 target. The parameter STDINC indicates if normal include files
26051 are present. The parameter SYSROOT is the system root directory.
26052 The parameter IPREFIX is the prefix for the gcc directory.
26054 -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const
26055 char *IPREFIX, int STDINC)
26056 This target hook should register any extra include files for the
26057 target before any standard headers. The parameter STDINC
26058 indicates if normal include files are present. The parameter
26059 SYSROOT is the system root directory. The parameter IPREFIX is
26060 the prefix for the gcc directory.
26062 -- Macro: void TARGET_OPTF (char *PATH)
26063 This target hook should register special include paths for the
26064 target. The parameter PATH is the include to register. On Darwin
26065 systems, this is used for Framework includes, which have semantics
26066 that are different from `-I'.
26068 -- Target Hook: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL)
26069 This target hook returns `true' if it is safe to use a local alias
26070 for a virtual function FNDECL when constructing thunks, `false'
26071 otherwise. By default, the hook returns `true' for all functions,
26072 if a target supports aliases (i.e. defines `ASM_OUTPUT_DEF'),
26075 -- Macro: TARGET_FORMAT_TYPES
26076 If defined, this macro is the name of a global variable containing
26077 target-specific format checking information for the `-Wformat'
26078 option. The default is to have no target-specific format checks.
26080 -- Macro: TARGET_N_FORMAT_TYPES
26081 If defined, this macro is the number of entries in
26082 `TARGET_FORMAT_TYPES'.
26084 -- Target Hook: bool TARGET_RELAXED_ORDERING
26085 If set to `true', means that the target's memory model does not
26086 guarantee that loads which do not depend on one another will access
26087 main memory in the order of the instruction stream; if ordering is
26088 important, an explicit memory barrier must be used. This is true
26089 of many recent processors which implement a policy of "relaxed,"
26090 "weak," or "release" memory consistency, such as Alpha, PowerPC,
26091 and ia64. The default is `false'.
26093 -- Target Hook: const char *TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN
26094 (tree TYPELIST, tree FUNCDECL, tree VAL)
26095 If defined, this macro returns the diagnostic message when it is
26096 illegal to pass argument VAL to function FUNCDECL with prototype
26099 -- Target Hook: const char * TARGET_INVALID_CONVERSION (tree FROMTYPE,
26101 If defined, this macro returns the diagnostic message when it is
26102 invalid to convert from FROMTYPE to TOTYPE, or `NULL' if validity
26103 should be determined by the front end.
26105 -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, tree
26107 If defined, this macro returns the diagnostic message when it is
26108 invalid to apply operation OP (where unary plus is denoted by
26109 `CONVERT_EXPR') to an operand of type TYPE, or `NULL' if validity
26110 should be determined by the front end.
26112 -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, tree
26114 If defined, this macro returns the diagnostic message when it is
26115 invalid to apply operation OP to operands of types TYPE1 and
26116 TYPE2, or `NULL' if validity should be determined by the front end.
26118 -- Macro: TARGET_USE_JCR_SECTION
26119 This macro determines whether to use the JCR section to register
26120 Java classes. By default, TARGET_USE_JCR_SECTION is defined to 1
26121 if both SUPPORTS_WEAK and TARGET_HAVE_NAMED_SECTIONS are true,
26125 File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top
26127 15 Host Configuration
26128 *********************
26130 Most details about the machine and system on which the compiler is
26131 actually running are detected by the `configure' script. Some things
26132 are impossible for `configure' to detect; these are described in two
26133 ways, either by macros defined in a file named `xm-MACHINE.h' or by
26134 hook functions in the file specified by the OUT_HOST_HOOK_OBJ variable
26135 in `config.gcc'. (The intention is that very few hosts will need a
26136 header file but nearly every fully supported host will need to override
26139 If you need to define only a few macros, and they have simple
26140 definitions, consider using the `xm_defines' variable in your
26141 `config.gcc' entry instead of creating a host configuration header.
26142 *Note System Config::.
26146 * Host Common:: Things every host probably needs implemented.
26147 * Filesystem:: Your host can't have the letter `a' in filenames?
26148 * Host Misc:: Rare configuration options for hosts.
26151 File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config
26156 Some things are just not portable, even between similar operating
26157 systems, and are too difficult for autoconf to detect. They get
26158 implemented using hook functions in the file specified by the
26159 HOST_HOOK_OBJ variable in `config.gcc'.
26161 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void)
26162 This host hook is used to set up handling for extra signals. The
26163 most common thing to do in this hook is to detect stack overflow.
26165 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int
26167 This host hook returns the address of some space that is likely to
26168 be free in some subsequent invocation of the compiler. We intend
26169 to load the PCH data at this address such that the data need not
26170 be relocated. The area should be able to hold SIZE bytes. If the
26171 host uses `mmap', FD is an open file descriptor that can be used
26174 -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS,
26175 size_t SIZE, int FD, size_t OFFSET)
26176 This host hook is called when a PCH file is about to be loaded.
26177 We want to load SIZE bytes from FD at OFFSET into memory at
26178 ADDRESS. The given address will be the result of a previous
26179 invocation of `HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we
26180 couldn't allocate SIZE bytes at ADDRESS. Return 0 if the memory
26181 is allocated but the data is not loaded. Return 1 if the hook has
26182 performed everything.
26184 If the implementation uses reserved address space, free any
26185 reserved space beyond SIZE, regardless of the return value. If no
26186 PCH will be loaded, this hook may be called with SIZE zero, in
26187 which case all reserved address space should be freed.
26189 Do not try to handle values of ADDRESS that could not have been
26190 returned by this executable; just return -1. Such values usually
26191 indicate an out-of-date PCH file (built by some other GCC
26192 executable), and such a PCH file won't work.
26194 -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void);
26195 This host hook returns the alignment required for allocating
26196 virtual memory. Usually this is the same as getpagesize, but on
26197 some hosts the alignment for reserving memory differs from the
26198 pagesize for committing memory.
26201 File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config
26203 15.2 Host Filesystem
26204 ====================
26206 GCC needs to know a number of things about the semantics of the host
26207 machine's filesystem. Filesystems with Unix and MS-DOS semantics are
26208 automatically detected. For other systems, you can define the
26209 following macros in `xm-MACHINE.h'.
26211 `HAVE_DOS_BASED_FILE_SYSTEM'
26212 This macro is automatically defined by `system.h' if the host file
26213 system obeys the semantics defined by MS-DOS instead of Unix. DOS
26214 file systems are case insensitive, file specifications may begin
26215 with a drive letter, and both forward slash and backslash (`/' and
26216 `\') are directory separators.
26220 If defined, these macros expand to character constants specifying
26221 separators for directory names within a file specification.
26222 `system.h' will automatically give them appropriate values on Unix
26223 and MS-DOS file systems. If your file system is neither of these,
26224 define one or both appropriately in `xm-MACHINE.h'.
26226 However, operating systems like VMS, where constructing a pathname
26227 is more complicated than just stringing together directory names
26228 separated by a special character, should not define either of these
26232 If defined, this macro should expand to a character constant
26233 specifying the separator for elements of search paths. The default
26234 value is a colon (`:'). DOS-based systems usually, but not
26235 always, use semicolon (`;').
26238 Define this macro if the host system is VMS.
26240 `HOST_OBJECT_SUFFIX'
26241 Define this macro to be a C string representing the suffix for
26242 object files on your host machine. If you do not define this
26243 macro, GCC will use `.o' as the suffix for object files.
26245 `HOST_EXECUTABLE_SUFFIX'
26246 Define this macro to be a C string representing the suffix for
26247 executable files on your host machine. If you do not define this
26248 macro, GCC will use the null string as the suffix for executable
26252 A pathname defined by the host operating system, which can be
26253 opened as a file and written to, but all the information written
26254 is discarded. This is commonly known as a "bit bucket" or "null
26255 device". If you do not define this macro, GCC will use
26256 `/dev/null' as the bit bucket. If the host does not support a bit
26257 bucket, define this macro to an invalid filename.
26259 `UPDATE_PATH_HOST_CANONICALIZE (PATH)'
26260 If defined, a C statement (sans semicolon) that performs
26261 host-dependent canonicalization when a path used in a compilation
26262 driver or preprocessor is canonicalized. PATH is a malloc-ed path
26263 to be canonicalized. If the C statement does canonicalize PATH
26264 into a different buffer, the old path should be freed and the new
26265 buffer should have been allocated with malloc.
26268 Define this macro to be a C string representing the format to use
26269 for constructing the index part of debugging dump file names. The
26270 resultant string must fit in fifteen bytes. The full filename
26271 will be the concatenation of: the prefix of the assembler file
26272 name, the string resulting from applying this format to an index
26273 number, and a string unique to each dump file kind, e.g. `rtl'.
26275 If you do not define this macro, GCC will use `.%02d.'. You should
26276 define this macro if using the default will create an invalid file
26279 `DELETE_IF_ORDINARY'
26280 Define this macro to be a C statement (sans semicolon) that
26281 performs host-dependent removal of ordinary temp files in the
26282 compilation driver.
26284 If you do not define this macro, GCC will use the default version.
26285 You should define this macro if the default version does not
26286 reliably remove the temp file as, for example, on VMS which allows
26287 multiple versions of a file.
26289 `HOST_LACKS_INODE_NUMBERS'
26290 Define this macro if the host filesystem does not report
26291 meaningful inode numbers in struct stat.
26294 File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config
26300 A C expression for the status code to be returned when the compiler
26301 exits after serious errors. The default is the system-provided
26302 macro `EXIT_FAILURE', or `1' if the system doesn't define that
26303 macro. Define this macro only if these defaults are incorrect.
26305 `SUCCESS_EXIT_CODE'
26306 A C expression for the status code to be returned when the compiler
26307 exits without serious errors. (Warnings are not serious errors.)
26308 The default is the system-provided macro `EXIT_SUCCESS', or `0' if
26309 the system doesn't define that macro. Define this macro only if
26310 these defaults are incorrect.
26313 Define this macro if GCC should use the C implementation of
26314 `alloca' provided by `libiberty.a'. This only affects how some
26315 parts of the compiler itself allocate memory. It does not change
26318 When GCC is built with a compiler other than itself, the C `alloca'
26319 is always used. This is because most other implementations have
26320 serious bugs. You should define this macro only on a system where
26321 no stack-based `alloca' can possibly work. For instance, if a
26322 system has a small limit on the size of the stack, GCC's builtin
26323 `alloca' will not work reliably.
26325 `COLLECT2_HOST_INITIALIZATION'
26326 If defined, a C statement (sans semicolon) that performs
26327 host-dependent initialization when `collect2' is being initialized.
26329 `GCC_DRIVER_HOST_INITIALIZATION'
26330 If defined, a C statement (sans semicolon) that performs
26331 host-dependent initialization when a compilation driver is being
26335 Define this macro if the host system has a small limit on the total
26336 size of an argument vector. This causes the driver to take more
26337 care not to pass unnecessary arguments to subprocesses.
26339 `HOST_LONG_LONG_FORMAT'
26340 If defined, the string used to indicate an argument of type `long
26341 long' to functions like `printf'. The default value is `"ll"'.
26343 In addition, if `configure' generates an incorrect definition of any
26344 of the macros in `auto-host.h', you can override that definition in a
26345 host configuration header. If you need to do this, first see if it is
26346 possible to fix `configure'.
26349 File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top
26351 16 Makefile Fragments
26352 *********************
26354 When you configure GCC using the `configure' script, it will construct
26355 the file `Makefile' from the template file `Makefile.in'. When it does
26356 this, it can incorporate makefile fragments from the `config'
26357 directory. These are used to set Makefile parameters that are not
26358 amenable to being calculated by autoconf. The list of fragments to
26359 incorporate is set by `config.gcc' (and occasionally `config.build' and
26360 `config.host'); *Note System Config::.
26362 Fragments are named either `t-TARGET' or `x-HOST', depending on
26363 whether they are relevant to configuring GCC to produce code for a
26364 particular target, or to configuring GCC to run on a particular host.
26365 Here TARGET and HOST are mnemonics which usually have some relationship
26366 to the canonical system name, but no formal connection.
26368 If these files do not exist, it means nothing needs to be added for a
26369 given target or host. Most targets need a few `t-TARGET' fragments,
26370 but needing `x-HOST' fragments is rare.
26374 * Target Fragment:: Writing `t-TARGET' files.
26375 * Host Fragment:: Writing `x-HOST' files.
26378 File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments
26380 16.1 Target Makefile Fragments
26381 ==============================
26383 Target makefile fragments can set these Makefile variables.
26386 Compiler flags to use when compiling `libgcc2.c'.
26389 A list of source file names to be compiled or assembled and
26390 inserted into `libgcc.a'.
26392 `Floating Point Emulation'
26393 To have GCC include software floating point libraries in `libgcc.a'
26394 define `FPBIT' and `DPBIT' along with a few rules as follows:
26395 # We want fine grained libraries, so use the new code
26396 # to build the floating point emulation libraries.
26401 fp-bit.c: $(srcdir)/config/fp-bit.c
26402 echo '#define FLOAT' > fp-bit.c
26403 cat $(srcdir)/config/fp-bit.c >> fp-bit.c
26405 dp-bit.c: $(srcdir)/config/fp-bit.c
26406 cat $(srcdir)/config/fp-bit.c > dp-bit.c
26408 You may need to provide additional #defines at the beginning of
26409 `fp-bit.c' and `dp-bit.c' to control target endianness and other
26412 `CRTSTUFF_T_CFLAGS'
26413 Special flags used when compiling `crtstuff.c'. *Note
26416 `CRTSTUFF_T_CFLAGS_S'
26417 Special flags used when compiling `crtstuff.c' for shared linking.
26418 Used if you use `crtbeginS.o' and `crtendS.o' in `EXTRA-PARTS'.
26419 *Note Initialization::.
26422 For some targets, invoking GCC in different ways produces objects
26423 that can not be linked together. For example, for some targets GCC
26424 produces both big and little endian code. For these targets, you
26425 must arrange for multiple versions of `libgcc.a' to be compiled,
26426 one for each set of incompatible options. When GCC invokes the
26427 linker, it arranges to link in the right version of `libgcc.a',
26428 based on the command line options used.
26430 The `MULTILIB_OPTIONS' macro lists the set of options for which
26431 special versions of `libgcc.a' must be built. Write options that
26432 are mutually incompatible side by side, separated by a slash.
26433 Write options that may be used together separated by a space. The
26434 build procedure will build all combinations of compatible options.
26436 For example, if you set `MULTILIB_OPTIONS' to `m68000/m68020
26437 msoft-float', `Makefile' will build special versions of `libgcc.a'
26438 using the following sets of options: `-m68000', `-m68020',
26439 `-msoft-float', `-m68000 -msoft-float', and `-m68020 -msoft-float'.
26441 `MULTILIB_DIRNAMES'
26442 If `MULTILIB_OPTIONS' is used, this variable specifies the
26443 directory names that should be used to hold the various libraries.
26444 Write one element in `MULTILIB_DIRNAMES' for each element in
26445 `MULTILIB_OPTIONS'. If `MULTILIB_DIRNAMES' is not used, the
26446 default value will be `MULTILIB_OPTIONS', with all slashes treated
26449 For example, if `MULTILIB_OPTIONS' is set to `m68000/m68020
26450 msoft-float', then the default value of `MULTILIB_DIRNAMES' is
26451 `m68000 m68020 msoft-float'. You may specify a different value if
26452 you desire a different set of directory names.
26455 Sometimes the same option may be written in two different ways.
26456 If an option is listed in `MULTILIB_OPTIONS', GCC needs to know
26457 about any synonyms. In that case, set `MULTILIB_MATCHES' to a
26458 list of items of the form `option=option' to describe all relevant
26459 synonyms. For example, `m68000=mc68000 m68020=mc68020'.
26461 `MULTILIB_EXCEPTIONS'
26462 Sometimes when there are multiple sets of `MULTILIB_OPTIONS' being
26463 specified, there are combinations that should not be built. In
26464 that case, set `MULTILIB_EXCEPTIONS' to be all of the switch
26465 exceptions in shell case syntax that should not be built.
26467 For example the ARM processor cannot execute both hardware floating
26468 point instructions and the reduced size THUMB instructions at the
26469 same time, so there is no need to build libraries with both of
26470 these options enabled. Therefore `MULTILIB_EXCEPTIONS' is set to:
26471 *mthumb/*mhard-float*
26473 `MULTILIB_EXTRA_OPTS'
26474 Sometimes it is desirable that when building multiple versions of
26475 `libgcc.a' certain options should always be passed on to the
26476 compiler. In that case, set `MULTILIB_EXTRA_OPTS' to be the list
26477 of options to be used for all builds. If you set this, you should
26478 probably set `CRTSTUFF_T_CFLAGS' to a dash followed by it.
26480 `NATIVE_SYSTEM_HEADER_DIR'
26481 If the default location for system headers is not `/usr/include',
26482 you must set this to the directory containing the headers. This
26483 value should match the value of the `SYSTEM_INCLUDE_DIR' macro.
26486 Unfortunately, setting `MULTILIB_EXTRA_OPTS' is not enough, since
26487 it does not affect the build of target libraries, at least not the
26488 build of the default multilib. One possible work-around is to use
26489 `DRIVER_SELF_SPECS' to bring options from the `specs' file as if
26490 they had been passed in the compiler driver command line.
26491 However, you don't want to be adding these options after the
26492 toolchain is installed, so you can instead tweak the `specs' file
26493 that will be used during the toolchain build, while you still
26494 install the original, built-in `specs'. The trick is to set
26495 `SPECS' to some other filename (say `specs.install'), that will
26496 then be created out of the built-in specs, and introduce a
26497 `Makefile' rule to generate the `specs' file that's going to be
26498 used at build time out of your `specs.install'.
26501 File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments
26503 16.2 Host Makefile Fragments
26504 ============================
26506 The use of `x-HOST' fragments is discouraged. You should do so only if
26507 there is no other mechanism to get the behavior desired. Host
26508 fragments should never forcibly override variables set by the configure
26509 script, as they may have been adjusted by the user.
26511 Variables provided for host fragments to set include:
26515 These are extra flags to pass to the C compiler and preprocessor,
26516 respectively. They are used both when building GCC, and when
26517 compiling things with the just-built GCC.
26520 These are extra flags to use when building the compiler. They are
26521 not used when compiling `libgcc.a'. However, they _are_ used when
26522 recompiling the compiler with itself in later stages of a
26526 Flags to be passed to the linker when recompiling the compiler with
26527 itself in later stages of a bootstrap. You might need to use this
26528 if, for instance, one of the front ends needs more text space than
26529 the linker provides by default.
26532 A list of additional programs required to use the compiler on this
26533 host, which should be compiled with GCC and installed alongside
26534 the front ends. If you set this variable, you must also provide
26535 rules to build the extra programs.
26539 File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top
26544 GCC uses a utility called `collect2' on nearly all systems to arrange
26545 to call various initialization functions at start time.
26547 The program `collect2' works by linking the program once and looking
26548 through the linker output file for symbols with particular names
26549 indicating they are constructor functions. If it finds any, it creates
26550 a new temporary `.c' file containing a table of them, compiles it, and
26551 links the program a second time including that file.
26553 The actual calls to the constructors are carried out by a subroutine
26554 called `__main', which is called (automatically) at the beginning of
26555 the body of `main' (provided `main' was compiled with GNU CC). Calling
26556 `__main' is necessary, even when compiling C code, to allow linking C
26557 and C++ object code together. (If you use `-nostdlib', you get an
26558 unresolved reference to `__main', since it's defined in the standard
26559 GCC library. Include `-lgcc' at the end of your compiler command line
26560 to resolve this reference.)
26562 The program `collect2' is installed as `ld' in the directory where the
26563 passes of the compiler are installed. When `collect2' needs to find
26564 the _real_ `ld', it tries the following file names:
26566 * `real-ld' in the directories listed in the compiler's search
26569 * `real-ld' in the directories listed in the environment variable
26572 * The file specified in the `REAL_LD_FILE_NAME' configuration macro,
26575 * `ld' in the compiler's search directories, except that `collect2'
26576 will not execute itself recursively.
26580 "The compiler's search directories" means all the directories where
26581 `gcc' searches for passes of the compiler. This includes directories
26582 that you specify with `-B'.
26584 Cross-compilers search a little differently:
26586 * `real-ld' in the compiler's search directories.
26588 * `TARGET-real-ld' in `PATH'.
26590 * The file specified in the `REAL_LD_FILE_NAME' configuration macro,
26593 * `ld' in the compiler's search directories.
26595 * `TARGET-ld' in `PATH'.
26597 `collect2' explicitly avoids running `ld' using the file name under
26598 which `collect2' itself was invoked. In fact, it remembers up a list
26599 of such names--in case one copy of `collect2' finds another copy (or
26600 version) of `collect2' installed as `ld' in a second place in the
26603 `collect2' searches for the utilities `nm' and `strip' using the same
26604 algorithm as above for `ld'.
26607 File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top
26609 18 Standard Header File Directories
26610 ***********************************
26612 `GCC_INCLUDE_DIR' means the same thing for native and cross. It is
26613 where GCC stores its private include files, and also where GCC stores
26614 the fixed include files. A cross compiled GCC runs `fixincludes' on
26615 the header files in `$(tooldir)/include'. (If the cross compilation
26616 header files need to be fixed, they must be installed before GCC is
26617 built. If the cross compilation header files are already suitable for
26618 GCC, nothing special need be done).
26620 `GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It
26621 is where `g++' looks first for header files. The C++ library installs
26622 only target independent header files in that directory.
26624 `LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't
26625 install anything there. It is normally `/usr/local/include'. This is
26626 where local additions to a packaged system should place header files.
26628 `CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't
26629 install anything there.
26631 `TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is
26632 the place for other packages to install header files that GCC will use.
26633 For a cross-compiler, this is the equivalent of `/usr/include'. When
26634 you build a cross-compiler, `fixincludes' processes any header files in
26638 File: gccint.info, Node: Type Information, Next: Funding, Prev: Header Dirs, Up: Top
26640 19 Memory Management and Type Information
26641 *****************************************
26643 GCC uses some fairly sophisticated memory management techniques, which
26644 involve determining information about GCC's data structures from GCC's
26645 source code and using this information to perform garbage collection and
26646 implement precompiled headers.
26648 A full C parser would be too complicated for this task, so a limited
26649 subset of C is interpreted and special markers are used to determine
26650 what parts of the source to look at. All `struct' and `union'
26651 declarations that define data structures that are allocated under
26652 control of the garbage collector must be marked. All global variables
26653 that hold pointers to garbage-collected memory must also be marked.
26654 Finally, all global variables that need to be saved and restored by a
26655 precompiled header must be marked. (The precompiled header mechanism
26656 can only save static variables if they're scalar. Complex data
26657 structures must be allocated in garbage-collected memory to be saved in
26658 a precompiled header.)
26660 The full format of a marker is
26661 GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...))
26662 but in most cases no options are needed. The outer double parentheses
26663 are still necessary, though: `GTY(())'. Markers can appear:
26665 * In a structure definition, before the open brace;
26667 * In a global variable declaration, after the keyword `static' or
26670 * In a structure field definition, before the name of the field.
26672 Here are some examples of marking simple data structures and globals.
26679 typedef struct TAG GTY(())
26684 static GTY(()) struct TAG *LIST; /* points to GC memory */
26685 static GTY(()) int COUNTER; /* save counter in a PCH */
26687 The parser understands simple typedefs such as `typedef struct TAG
26688 *NAME;' and `typedef int NAME;'. These don't need to be marked.
26692 * GTY Options:: What goes inside a `GTY(())'.
26693 * GGC Roots:: Making global variables GGC roots.
26694 * Files:: How the generated files work.
26697 File: gccint.info, Node: GTY Options, Next: GGC Roots, Up: Type Information
26699 19.1 The Inside of a `GTY(())'
26700 ==============================
26702 Sometimes the C code is not enough to fully describe the type
26703 structure. Extra information can be provided with `GTY' options and
26704 additional markers. Some options take a parameter, which may be either
26705 a string or a type name, depending on the parameter. If an option
26706 takes no parameter, it is acceptable either to omit the parameter
26707 entirely, or to provide an empty string as a parameter. For example,
26708 `GTY ((skip))' and `GTY ((skip ("")))' are equivalent.
26710 When the parameter is a string, often it is a fragment of C code. Four
26711 special escapes may be used in these strings, to refer to pieces of the
26712 data structure being marked:
26715 The current structure.
26718 The structure that immediately contains the current structure.
26721 The outermost structure that contains the current structure.
26724 A partial expression of the form `[i1][i2]...' that indexes the
26725 array item currently being marked.
26727 For instance, suppose that you have a structure of the form
26734 and `b' is a variable of type `struct B'. When marking `b.foo[11]',
26735 `%h' would expand to `b.foo[11]', `%0' and `%1' would both expand to
26736 `b', and `%a' would expand to `[11]'.
26738 As in ordinary C, adjacent strings will be concatenated; this is
26739 helpful when you have a complicated expression.
26740 GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE"
26741 " ? TYPE_NEXT_VARIANT (&%h.generic)"
26742 " : TREE_CHAIN (&%h.generic)")))
26744 The available options are:
26746 `length ("EXPRESSION")'
26747 There are two places the type machinery will need to be explicitly
26748 told the length of an array. The first case is when a structure
26749 ends in a variable-length array, like this:
26750 struct rtvec_def GTY(()) {
26751 int num_elem; /* number of elements */
26752 rtx GTY ((length ("%h.num_elem"))) elem[1];
26755 In this case, the `length' option is used to override the specified
26756 array length (which should usually be `1'). The parameter of the
26757 option is a fragment of C code that calculates the length.
26759 The second case is when a structure or a global variable contains a
26760 pointer to an array, like this:
26762 GTY ((length ("%h.regno_pointer_align_length"))) regno_decl;
26763 In this case, `regno_decl' has been allocated by writing something
26766 ggc_alloc (x->regno_pointer_align_length * sizeof (tree));
26767 and the `length' provides the length of the field.
26769 This second use of `length' also works on global variables, like:
26770 static GTY((length ("reg_base_value_size")))
26771 rtx *reg_base_value;
26774 If `skip' is applied to a field, the type machinery will ignore it.
26775 This is somewhat dangerous; the only safe use is in a union when
26776 one field really isn't ever used.
26778 `desc ("EXPRESSION")'
26781 The type machinery needs to be told which field of a `union' is
26782 currently active. This is done by giving each field a constant
26783 `tag' value, and then specifying a discriminator using `desc'.
26784 The value of the expression given by `desc' is compared against
26785 each `tag' value, each of which should be different. If no `tag'
26786 is matched, the field marked with `default' is used if there is
26787 one, otherwise no field in the union will be marked.
26789 In the `desc' option, the "current structure" is the union that it
26790 discriminates. Use `%1' to mean the structure containing it.
26791 There are no escapes available to the `tag' option, since it is a
26795 struct tree_binding GTY(())
26797 struct tree_common common;
26798 union tree_binding_u {
26799 tree GTY ((tag ("0"))) scope;
26800 struct cp_binding_level * GTY ((tag ("1"))) level;
26801 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope;
26805 In this example, the value of BINDING_HAS_LEVEL_P when applied to a
26806 `struct tree_binding *' is presumed to be 0 or 1. If 1, the type
26807 mechanism will treat the field `level' as being present and if 0,
26808 will treat the field `scope' as being present.
26812 Sometimes it's convenient to define some data structure to work on
26813 generic pointers (that is, `PTR') and then use it with a specific
26814 type. `param_is' specifies the real type pointed to, and
26815 `use_param' says where in the generic data structure that type
26818 For instance, to have a `htab_t' that points to trees, one would
26819 write the definition of `htab_t' like this:
26820 typedef struct GTY(()) {
26822 void ** GTY ((use_param, ...)) entries;
26825 and then declare variables like this:
26826 static htab_t GTY ((param_is (union tree_node))) ict;
26830 In more complicated cases, the data structure might need to work on
26831 several different types, which might not necessarily all be
26832 pointers. For this, `param1_is' through `param9_is' may be used to
26833 specify the real type of a field identified by `use_param1' through
26837 When a structure contains another structure that is parameterized,
26838 there's no need to do anything special, the inner structure
26839 inherits the parameters of the outer one. When a structure
26840 contains a pointer to a parameterized structure, the type
26841 machinery won't automatically detect this (it could, it just
26842 doesn't yet), so it's necessary to tell it that the pointed-to
26843 structure should use the same parameters as the outer structure.
26844 This is done by marking the pointer with the `use_params' option.
26847 `deletable', when applied to a global variable, indicates that when
26848 garbage collection runs, there's no need to mark anything pointed
26849 to by this variable, it can just be set to `NULL' instead. This
26850 is used to keep a list of free structures around for re-use.
26852 `if_marked ("EXPRESSION")'
26853 Suppose you want some kinds of object to be unique, and so you put
26854 them in a hash table. If garbage collection marks the hash table,
26855 these objects will never be freed, even if the last other
26856 reference to them goes away. GGC has special handling to deal
26857 with this: if you use the `if_marked' option on a global hash
26858 table, GGC will call the routine whose name is the parameter to
26859 the option on each hash table entry. If the routine returns
26860 nonzero, the hash table entry will be marked as usual. If the
26861 routine returns zero, the hash table entry will be deleted.
26863 The routine `ggc_marked_p' can be used to determine if an element
26864 has been marked already; in fact, the usual case is to use
26865 `if_marked ("ggc_marked_p")'.
26868 When applied to a field, `maybe_undef' indicates that it's OK if
26869 the structure that this fields points to is never defined, so long
26870 as this field is always `NULL'. This is used to avoid requiring
26871 backends to define certain optional structures. It doesn't work
26872 with language frontends.
26874 `nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")'
26875 The type machinery expects all pointers to point to the start of an
26876 object. Sometimes for abstraction purposes it's convenient to have
26877 a pointer which points inside an object. So long as it's possible
26878 to convert the original object to and from the pointer, such
26879 pointers can still be used. TYPE is the type of the original
26880 object, the TO EXPRESSION returns the pointer given the original
26881 object, and the FROM EXPRESSION returns the original object given
26882 the pointer. The pointer will be available using the `%h' escape.
26884 `chain_next ("EXPRESSION")'
26885 `chain_prev ("EXPRESSION")'
26886 It's helpful for the type machinery to know if objects are often
26887 chained together in long lists; this lets it generate code that
26888 uses less stack space by iterating along the list instead of
26889 recursing down it. `chain_next' is an expression for the next
26890 item in the list, `chain_prev' is an expression for the previous
26891 item. For singly linked lists, use only `chain_next'; for doubly
26892 linked lists, use both. The machinery requires that taking the
26893 next item of the previous item gives the original item.
26895 `reorder ("FUNCTION NAME")'
26896 Some data structures depend on the relative ordering of pointers.
26897 If the precompiled header machinery needs to change that ordering,
26898 it will call the function referenced by the `reorder' option,
26899 before changing the pointers in the object that's pointed to by
26900 the field the option applies to. The function must take four
26901 arguments, with the signature
26902 `void *, void *, gt_pointer_operator, void *'. The first
26903 parameter is a pointer to the structure that contains the object
26904 being updated, or the object itself if there is no containing
26905 structure. The second parameter is a cookie that should be
26906 ignored. The third parameter is a routine that, given a pointer,
26907 will update it to its correct new value. The fourth parameter is
26908 a cookie that must be passed to the second parameter.
26910 PCH cannot handle data structures that depend on the absolute
26911 values of pointers. `reorder' functions can be expensive. When
26912 possible, it is better to depend on properties of the data, like
26913 an ID number or the hash of a string instead.
26916 The `special' option is used to mark types that have to be dealt
26917 with by special case machinery. The parameter is the name of the
26918 special case. See `gengtype.c' for further details. Avoid adding
26919 new special cases unless there is no other alternative.
26922 File: gccint.info, Node: GGC Roots, Next: Files, Prev: GTY Options, Up: Type Information
26924 19.2 Marking Roots for the Garbage Collector
26925 ============================================
26927 In addition to keeping track of types, the type machinery also locates
26928 the global variables ("roots") that the garbage collector starts at.
26929 Roots must be declared using one of the following syntaxes:
26931 * `extern GTY(([OPTIONS])) TYPE NAME;'
26933 * `static GTY(([OPTIONS])) TYPE NAME;'
26935 * `GTY(([OPTIONS])) TYPE NAME;'
26936 is _not_ accepted. There should be an `extern' declaration of such a
26937 variable in a header somewhere--mark that, not the definition. Or, if
26938 the variable is only used in one file, make it `static'.
26941 File: gccint.info, Node: Files, Prev: GGC Roots, Up: Type Information
26943 19.3 Source Files Containing Type Information
26944 =============================================
26946 Whenever you add `GTY' markers to a source file that previously had
26947 none, or create a new source file containing `GTY' markers, there are
26948 three things you need to do:
26950 1. You need to add the file to the list of source files the type
26951 machinery scans. There are four cases:
26953 a. For a back-end file, this is usually done automatically; if
26954 not, you should add it to `target_gtfiles' in the appropriate
26955 port's entries in `config.gcc'.
26957 b. For files shared by all front ends, add the filename to the
26958 `GTFILES' variable in `Makefile.in'.
26960 c. For files that are part of one front end, add the filename to
26961 the `gtfiles' variable defined in the appropriate
26962 `config-lang.in'. For C, the file is `c-config-lang.in'.
26964 d. For files that are part of some but not all front ends, add
26965 the filename to the `gtfiles' variable of _all_ the front ends
26968 2. If the file was a header file, you'll need to check that it's
26969 included in the right place to be visible to the generated files.
26970 For a back-end header file, this should be done automatically.
26971 For a front-end header file, it needs to be included by the same
26972 file that includes `gtype-LANG.h'. For other header files, it
26973 needs to be included in `gtype-desc.c', which is a generated file,
26974 so add it to `ifiles' in `open_base_file' in `gengtype.c'.
26976 For source files that aren't header files, the machinery will
26977 generate a header file that should be included in the source file
26978 you just changed. The file will be called `gt-PATH.h' where PATH
26979 is the pathname relative to the `gcc' directory with slashes
26980 replaced by -, so for example the header file to be included in
26981 `cp/parser.c' is called `gt-cp-parser.c'. The generated header
26982 file should be included after everything else in the source file.
26983 Don't forget to mention this file as a dependency in the
26986 3. If a new `gt-PATH.h' file is needed, you need to arrange to add a
26987 `Makefile' rule that will ensure this file can be built. This is
26988 done by making it a dependency of `s-gtype', like this:
26989 gt-path.h : s-gtype ; @true
26991 For language frontends, there is another file that needs to be included
26992 somewhere. It will be called `gtype-LANG.h', where LANG is the name of
26993 the subdirectory the language is contained in. It will need `Makefile'
26994 rules just like the other generated files.
26997 File: gccint.info, Node: Funding, Next: GNU Project, Prev: Type Information, Up: Top
26999 Funding Free Software
27000 *********************
27002 If you want to have more free software a few years from now, it makes
27003 sense for you to help encourage people to contribute funds for its
27004 development. The most effective approach known is to encourage
27005 commercial redistributors to donate.
27007 Users of free software systems can boost the pace of development by
27008 encouraging for-a-fee distributors to donate part of their selling price
27009 to free software developers--the Free Software Foundation, and others.
27011 The way to convince distributors to do this is to demand it and expect
27012 it from them. So when you compare distributors, judge them partly by
27013 how much they give to free software development. Show distributors
27014 they must compete to be the one who gives the most.
27016 To make this approach work, you must insist on numbers that you can
27017 compare, such as, "We will donate ten dollars to the Frobnitz project
27018 for each disk sold." Don't be satisfied with a vague promise, such as
27019 "A portion of the profits are donated," since it doesn't give a basis
27022 Even a precise fraction "of the profits from this disk" is not very
27023 meaningful, since creative accounting and unrelated business decisions
27024 can greatly alter what fraction of the sales price counts as profit.
27025 If the price you pay is $50, ten percent of the profit is probably less
27026 than a dollar; it might be a few cents, or nothing at all.
27028 Some redistributors do development work themselves. This is useful
27029 too; but to keep everyone honest, you need to inquire how much they do,
27030 and what kind. Some kinds of development make much more long-term
27031 difference than others. For example, maintaining a separate version of
27032 a program contributes very little; maintaining the standard version of a
27033 program for the whole community contributes much. Easy new ports
27034 contribute little, since someone else would surely do them; difficult
27035 ports such as adding a new CPU to the GNU Compiler Collection
27036 contribute more; major new features or packages contribute the most.
27038 By establishing the idea that supporting further development is "the
27039 proper thing to do" when distributing free software for a fee, we can
27040 assure a steady flow of resources into making more free software.
27042 Copyright (C) 1994 Free Software Foundation, Inc.
27043 Verbatim copying and redistribution of this section is permitted
27044 without royalty; alteration is not permitted.
27047 File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top
27049 The GNU Project and GNU/Linux
27050 *****************************
27052 The GNU Project was launched in 1984 to develop a complete Unix-like
27053 operating system which is free software: the GNU system. (GNU is a
27054 recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".)
27055 Variants of the GNU operating system, which use the kernel Linux, are
27056 now widely used; though these systems are often referred to as "Linux",
27057 they are more accurately called GNU/Linux systems.
27059 For more information, see:
27060 `http://www.gnu.org/'
27061 `http://www.gnu.org/gnu/linux-and-gnu.html'
27064 File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top
27066 GNU GENERAL PUBLIC LICENSE
27067 **************************
27069 Version 2, June 1991
27071 Copyright (C) 1989, 1991 Free Software Foundation, Inc.
27072 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
27074 Everyone is permitted to copy and distribute verbatim copies
27075 of this license document, but changing it is not allowed.
27080 The licenses for most software are designed to take away your freedom
27081 to share and change it. By contrast, the GNU General Public License is
27082 intended to guarantee your freedom to share and change free
27083 software--to make sure the software is free for all its users. This
27084 General Public License applies to most of the Free Software
27085 Foundation's software and to any other program whose authors commit to
27086 using it. (Some other Free Software Foundation software is covered by
27087 the GNU Library General Public License instead.) You can apply it to
27088 your programs, too.
27090 When we speak of free software, we are referring to freedom, not
27091 price. Our General Public Licenses are designed to make sure that you
27092 have the freedom to distribute copies of free software (and charge for
27093 this service if you wish), that you receive source code or can get it
27094 if you want it, that you can change the software or use pieces of it in
27095 new free programs; and that you know you can do these things.
27097 To protect your rights, we need to make restrictions that forbid
27098 anyone to deny you these rights or to ask you to surrender the rights.
27099 These restrictions translate to certain responsibilities for you if you
27100 distribute copies of the software, or if you modify it.
27102 For example, if you distribute copies of such a program, whether
27103 gratis or for a fee, you must give the recipients all the rights that
27104 you have. You must make sure that they, too, receive or can get the
27105 source code. And you must show them these terms so they know their
27108 We protect your rights with two steps: (1) copyright the software, and
27109 (2) offer you this license which gives you legal permission to copy,
27110 distribute and/or modify the software.
27112 Also, for each author's protection and ours, we want to make certain
27113 that everyone understands that there is no warranty for this free
27114 software. If the software is modified by someone else and passed on, we
27115 want its recipients to know that what they have is not the original, so
27116 that any problems introduced by others will not reflect on the original
27117 authors' reputations.
27119 Finally, any free program is threatened constantly by software
27120 patents. We wish to avoid the danger that redistributors of a free
27121 program will individually obtain patent licenses, in effect making the
27122 program proprietary. To prevent this, we have made it clear that any
27123 patent must be licensed for everyone's free use or not licensed at all.
27125 The precise terms and conditions for copying, distribution and
27126 modification follow.
27128 TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
27129 0. This License applies to any program or other work which contains a
27130 notice placed by the copyright holder saying it may be distributed
27131 under the terms of this General Public License. The "Program",
27132 below, refers to any such program or work, and a "work based on
27133 the Program" means either the Program or any derivative work under
27134 copyright law: that is to say, a work containing the Program or a
27135 portion of it, either verbatim or with modifications and/or
27136 translated into another language. (Hereinafter, translation is
27137 included without limitation in the term "modification".) Each
27138 licensee is addressed as "you".
27140 Activities other than copying, distribution and modification are
27141 not covered by this License; they are outside its scope. The act
27142 of running the Program is not restricted, and the output from the
27143 Program is covered only if its contents constitute a work based on
27144 the Program (independent of having been made by running the
27145 Program). Whether that is true depends on what the Program does.
27147 1. You may copy and distribute verbatim copies of the Program's
27148 source code as you receive it, in any medium, provided that you
27149 conspicuously and appropriately publish on each copy an appropriate
27150 copyright notice and disclaimer of warranty; keep intact all the
27151 notices that refer to this License and to the absence of any
27152 warranty; and give any other recipients of the Program a copy of
27153 this License along with the Program.
27155 You may charge a fee for the physical act of transferring a copy,
27156 and you may at your option offer warranty protection in exchange
27159 2. You may modify your copy or copies of the Program or any portion
27160 of it, thus forming a work based on the Program, and copy and
27161 distribute such modifications or work under the terms of Section 1
27162 above, provided that you also meet all of these conditions:
27164 a. You must cause the modified files to carry prominent notices
27165 stating that you changed the files and the date of any change.
27167 b. You must cause any work that you distribute or publish, that
27168 in whole or in part contains or is derived from the Program
27169 or any part thereof, to be licensed as a whole at no charge
27170 to all third parties under the terms of this License.
27172 c. If the modified program normally reads commands interactively
27173 when run, you must cause it, when started running for such
27174 interactive use in the most ordinary way, to print or display
27175 an announcement including an appropriate copyright notice and
27176 a notice that there is no warranty (or else, saying that you
27177 provide a warranty) and that users may redistribute the
27178 program under these conditions, and telling the user how to
27179 view a copy of this License. (Exception: if the Program
27180 itself is interactive but does not normally print such an
27181 announcement, your work based on the Program is not required
27182 to print an announcement.)
27184 These requirements apply to the modified work as a whole. If
27185 identifiable sections of that work are not derived from the
27186 Program, and can be reasonably considered independent and separate
27187 works in themselves, then this License, and its terms, do not
27188 apply to those sections when you distribute them as separate
27189 works. But when you distribute the same sections as part of a
27190 whole which is a work based on the Program, the distribution of
27191 the whole must be on the terms of this License, whose permissions
27192 for other licensees extend to the entire whole, and thus to each
27193 and every part regardless of who wrote it.
27195 Thus, it is not the intent of this section to claim rights or
27196 contest your rights to work written entirely by you; rather, the
27197 intent is to exercise the right to control the distribution of
27198 derivative or collective works based on the Program.
27200 In addition, mere aggregation of another work not based on the
27201 Program with the Program (or with a work based on the Program) on
27202 a volume of a storage or distribution medium does not bring the
27203 other work under the scope of this License.
27205 3. You may copy and distribute the Program (or a work based on it,
27206 under Section 2) in object code or executable form under the terms
27207 of Sections 1 and 2 above provided that you also do one of the
27210 a. Accompany it with the complete corresponding machine-readable
27211 source code, which must be distributed under the terms of
27212 Sections 1 and 2 above on a medium customarily used for
27213 software interchange; or,
27215 b. Accompany it with a written offer, valid for at least three
27216 years, to give any third party, for a charge no more than your
27217 cost of physically performing source distribution, a complete
27218 machine-readable copy of the corresponding source code, to be
27219 distributed under the terms of Sections 1 and 2 above on a
27220 medium customarily used for software interchange; or,
27222 c. Accompany it with the information you received as to the offer
27223 to distribute corresponding source code. (This alternative is
27224 allowed only for noncommercial distribution and only if you
27225 received the program in object code or executable form with
27226 such an offer, in accord with Subsection b above.)
27228 The source code for a work means the preferred form of the work for
27229 making modifications to it. For an executable work, complete
27230 source code means all the source code for all modules it contains,
27231 plus any associated interface definition files, plus the scripts
27232 used to control compilation and installation of the executable.
27233 However, as a special exception, the source code distributed need
27234 not include anything that is normally distributed (in either
27235 source or binary form) with the major components (compiler,
27236 kernel, and so on) of the operating system on which the executable
27237 runs, unless that component itself accompanies the executable.
27239 If distribution of executable or object code is made by offering
27240 access to copy from a designated place, then offering equivalent
27241 access to copy the source code from the same place counts as
27242 distribution of the source code, even though third parties are not
27243 compelled to copy the source along with the object code.
27245 4. You may not copy, modify, sublicense, or distribute the Program
27246 except as expressly provided under this License. Any attempt
27247 otherwise to copy, modify, sublicense or distribute the Program is
27248 void, and will automatically terminate your rights under this
27249 License. However, parties who have received copies, or rights,
27250 from you under this License will not have their licenses
27251 terminated so long as such parties remain in full compliance.
27253 5. You are not required to accept this License, since you have not
27254 signed it. However, nothing else grants you permission to modify
27255 or distribute the Program or its derivative works. These actions
27256 are prohibited by law if you do not accept this License.
27257 Therefore, by modifying or distributing the Program (or any work
27258 based on the Program), you indicate your acceptance of this
27259 License to do so, and all its terms and conditions for copying,
27260 distributing or modifying the Program or works based on it.
27262 6. Each time you redistribute the Program (or any work based on the
27263 Program), the recipient automatically receives a license from the
27264 original licensor to copy, distribute or modify the Program
27265 subject to these terms and conditions. You may not impose any
27266 further restrictions on the recipients' exercise of the rights
27267 granted herein. You are not responsible for enforcing compliance
27268 by third parties to this License.
27270 7. If, as a consequence of a court judgment or allegation of patent
27271 infringement or for any other reason (not limited to patent
27272 issues), conditions are imposed on you (whether by court order,
27273 agreement or otherwise) that contradict the conditions of this
27274 License, they do not excuse you from the conditions of this
27275 License. If you cannot distribute so as to satisfy simultaneously
27276 your obligations under this License and any other pertinent
27277 obligations, then as a consequence you may not distribute the
27278 Program at all. For example, if a patent license would not permit
27279 royalty-free redistribution of the Program by all those who
27280 receive copies directly or indirectly through you, then the only
27281 way you could satisfy both it and this License would be to refrain
27282 entirely from distribution of the Program.
27284 If any portion of this section is held invalid or unenforceable
27285 under any particular circumstance, the balance of the section is
27286 intended to apply and the section as a whole is intended to apply
27287 in other circumstances.
27289 It is not the purpose of this section to induce you to infringe any
27290 patents or other property right claims or to contest validity of
27291 any such claims; this section has the sole purpose of protecting
27292 the integrity of the free software distribution system, which is
27293 implemented by public license practices. Many people have made
27294 generous contributions to the wide range of software distributed
27295 through that system in reliance on consistent application of that
27296 system; it is up to the author/donor to decide if he or she is
27297 willing to distribute software through any other system and a
27298 licensee cannot impose that choice.
27300 This section is intended to make thoroughly clear what is believed
27301 to be a consequence of the rest of this License.
27303 8. If the distribution and/or use of the Program is restricted in
27304 certain countries either by patents or by copyrighted interfaces,
27305 the original copyright holder who places the Program under this
27306 License may add an explicit geographical distribution limitation
27307 excluding those countries, so that distribution is permitted only
27308 in or among countries not thus excluded. In such case, this
27309 License incorporates the limitation as if written in the body of
27312 9. The Free Software Foundation may publish revised and/or new
27313 versions of the General Public License from time to time. Such
27314 new versions will be similar in spirit to the present version, but
27315 may differ in detail to address new problems or concerns.
27317 Each version is given a distinguishing version number. If the
27318 Program specifies a version number of this License which applies
27319 to it and "any later version", you have the option of following
27320 the terms and conditions either of that version or of any later
27321 version published by the Free Software Foundation. If the Program
27322 does not specify a version number of this License, you may choose
27323 any version ever published by the Free Software Foundation.
27325 10. If you wish to incorporate parts of the Program into other free
27326 programs whose distribution conditions are different, write to the
27327 author to ask for permission. For software which is copyrighted
27328 by the Free Software Foundation, write to the Free Software
27329 Foundation; we sometimes make exceptions for this. Our decision
27330 will be guided by the two goals of preserving the free status of
27331 all derivatives of our free software and of promoting the sharing
27332 and reuse of software generally.
27335 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
27336 WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
27337 LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
27338 HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT
27339 WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT
27340 NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
27341 FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE
27342 QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
27343 PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
27344 SERVICING, REPAIR OR CORRECTION.
27346 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
27347 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
27348 MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE
27349 LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
27350 INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
27351 INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
27352 DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU
27353 OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
27354 OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN
27355 ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
27357 END OF TERMS AND CONDITIONS
27358 Appendix: How to Apply These Terms to Your New Programs
27359 =======================================================
27361 If you develop a new program, and you want it to be of the greatest
27362 possible use to the public, the best way to achieve this is to make it
27363 free software which everyone can redistribute and change under these
27366 To do so, attach the following notices to the program. It is safest
27367 to attach them to the start of each source file to most effectively
27368 convey the exclusion of warranty; and each file should have at least
27369 the "copyright" line and a pointer to where the full notice is found.
27371 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
27372 Copyright (C) YEAR NAME OF AUTHOR
27374 This program is free software; you can redistribute it and/or modify
27375 it under the terms of the GNU General Public License as published by
27376 the Free Software Foundation; either version 2 of the License, or
27377 (at your option) any later version.
27379 This program is distributed in the hope that it will be useful,
27380 but WITHOUT ANY WARRANTY; without even the implied warranty of
27381 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
27382 GNU General Public License for more details.
27384 You should have received a copy of the GNU General Public License
27385 along with this program; if not, write to the Free Software
27386 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
27388 Also add information on how to contact you by electronic and paper
27391 If the program is interactive, make it output a short notice like this
27392 when it starts in an interactive mode:
27394 Gnomovision version 69, Copyright (C) YEAR NAME OF AUTHOR
27395 Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
27397 This is free software, and you are welcome to redistribute it
27398 under certain conditions; type `show c' for details.
27400 The hypothetical commands `show w' and `show c' should show the
27401 appropriate parts of the General Public License. Of course, the
27402 commands you use may be called something other than `show w' and `show
27403 c'; they could even be mouse-clicks or menu items--whatever suits your
27406 You should also get your employer (if you work as a programmer) or your
27407 school, if any, to sign a "copyright disclaimer" for the program, if
27408 necessary. Here is a sample; alter the names:
27410 Yoyodyne, Inc., hereby disclaims all copyright interest in the program
27411 `Gnomovision' (which makes passes at compilers) written by James Hacker.
27413 SIGNATURE OF TY COON, 1 April 1989
27414 Ty Coon, President of Vice
27416 This General Public License does not permit incorporating your program
27417 into proprietary programs. If your program is a subroutine library,
27418 you may consider it more useful to permit linking proprietary
27419 applications with the library. If this is what you want to do, use the
27420 GNU Library General Public License instead of this License.
27423 File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top
27425 GNU Free Documentation License
27426 ******************************
27428 Version 1.2, November 2002
27430 Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
27431 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
27433 Everyone is permitted to copy and distribute verbatim copies
27434 of this license document, but changing it is not allowed.
27438 The purpose of this License is to make a manual, textbook, or other
27439 functional and useful document "free" in the sense of freedom: to
27440 assure everyone the effective freedom to copy and redistribute it,
27441 with or without modifying it, either commercially or
27442 noncommercially. Secondarily, this License preserves for the
27443 author and publisher a way to get credit for their work, while not
27444 being considered responsible for modifications made by others.
27446 This License is a kind of "copyleft", which means that derivative
27447 works of the document must themselves be free in the same sense.
27448 It complements the GNU General Public License, which is a copyleft
27449 license designed for free software.
27451 We have designed this License in order to use it for manuals for
27452 free software, because free software needs free documentation: a
27453 free program should come with manuals providing the same freedoms
27454 that the software does. But this License is not limited to
27455 software manuals; it can be used for any textual work, regardless
27456 of subject matter or whether it is published as a printed book.
27457 We recommend this License principally for works whose purpose is
27458 instruction or reference.
27460 1. APPLICABILITY AND DEFINITIONS
27462 This License applies to any manual or other work, in any medium,
27463 that contains a notice placed by the copyright holder saying it
27464 can be distributed under the terms of this License. Such a notice
27465 grants a world-wide, royalty-free license, unlimited in duration,
27466 to use that work under the conditions stated herein. The
27467 "Document", below, refers to any such manual or work. Any member
27468 of the public is a licensee, and is addressed as "you". You
27469 accept the license if you copy, modify or distribute the work in a
27470 way requiring permission under copyright law.
27472 A "Modified Version" of the Document means any work containing the
27473 Document or a portion of it, either copied verbatim, or with
27474 modifications and/or translated into another language.
27476 A "Secondary Section" is a named appendix or a front-matter section
27477 of the Document that deals exclusively with the relationship of the
27478 publishers or authors of the Document to the Document's overall
27479 subject (or to related matters) and contains nothing that could
27480 fall directly within that overall subject. (Thus, if the Document
27481 is in part a textbook of mathematics, a Secondary Section may not
27482 explain any mathematics.) The relationship could be a matter of
27483 historical connection with the subject or with related matters, or
27484 of legal, commercial, philosophical, ethical or political position
27487 The "Invariant Sections" are certain Secondary Sections whose
27488 titles are designated, as being those of Invariant Sections, in
27489 the notice that says that the Document is released under this
27490 License. If a section does not fit the above definition of
27491 Secondary then it is not allowed to be designated as Invariant.
27492 The Document may contain zero Invariant Sections. If the Document
27493 does not identify any Invariant Sections then there are none.
27495 The "Cover Texts" are certain short passages of text that are
27496 listed, as Front-Cover Texts or Back-Cover Texts, in the notice
27497 that says that the Document is released under this License. A
27498 Front-Cover Text may be at most 5 words, and a Back-Cover Text may
27499 be at most 25 words.
27501 A "Transparent" copy of the Document means a machine-readable copy,
27502 represented in a format whose specification is available to the
27503 general public, that is suitable for revising the document
27504 straightforwardly with generic text editors or (for images
27505 composed of pixels) generic paint programs or (for drawings) some
27506 widely available drawing editor, and that is suitable for input to
27507 text formatters or for automatic translation to a variety of
27508 formats suitable for input to text formatters. A copy made in an
27509 otherwise Transparent file format whose markup, or absence of
27510 markup, has been arranged to thwart or discourage subsequent
27511 modification by readers is not Transparent. An image format is
27512 not Transparent if used for any substantial amount of text. A
27513 copy that is not "Transparent" is called "Opaque".
27515 Examples of suitable formats for Transparent copies include plain
27516 ASCII without markup, Texinfo input format, LaTeX input format,
27517 SGML or XML using a publicly available DTD, and
27518 standard-conforming simple HTML, PostScript or PDF designed for
27519 human modification. Examples of transparent image formats include
27520 PNG, XCF and JPG. Opaque formats include proprietary formats that
27521 can be read and edited only by proprietary word processors, SGML or
27522 XML for which the DTD and/or processing tools are not generally
27523 available, and the machine-generated HTML, PostScript or PDF
27524 produced by some word processors for output purposes only.
27526 The "Title Page" means, for a printed book, the title page itself,
27527 plus such following pages as are needed to hold, legibly, the
27528 material this License requires to appear in the title page. For
27529 works in formats which do not have any title page as such, "Title
27530 Page" means the text near the most prominent appearance of the
27531 work's title, preceding the beginning of the body of the text.
27533 A section "Entitled XYZ" means a named subunit of the Document
27534 whose title either is precisely XYZ or contains XYZ in parentheses
27535 following text that translates XYZ in another language. (Here XYZ
27536 stands for a specific section name mentioned below, such as
27537 "Acknowledgements", "Dedications", "Endorsements", or "History".)
27538 To "Preserve the Title" of such a section when you modify the
27539 Document means that it remains a section "Entitled XYZ" according
27540 to this definition.
27542 The Document may include Warranty Disclaimers next to the notice
27543 which states that this License applies to the Document. These
27544 Warranty Disclaimers are considered to be included by reference in
27545 this License, but only as regards disclaiming warranties: any other
27546 implication that these Warranty Disclaimers may have is void and
27547 has no effect on the meaning of this License.
27549 2. VERBATIM COPYING
27551 You may copy and distribute the Document in any medium, either
27552 commercially or noncommercially, provided that this License, the
27553 copyright notices, and the license notice saying this License
27554 applies to the Document are reproduced in all copies, and that you
27555 add no other conditions whatsoever to those of this License. You
27556 may not use technical measures to obstruct or control the reading
27557 or further copying of the copies you make or distribute. However,
27558 you may accept compensation in exchange for copies. If you
27559 distribute a large enough number of copies you must also follow
27560 the conditions in section 3.
27562 You may also lend copies, under the same conditions stated above,
27563 and you may publicly display copies.
27565 3. COPYING IN QUANTITY
27567 If you publish printed copies (or copies in media that commonly
27568 have printed covers) of the Document, numbering more than 100, and
27569 the Document's license notice requires Cover Texts, you must
27570 enclose the copies in covers that carry, clearly and legibly, all
27571 these Cover Texts: Front-Cover Texts on the front cover, and
27572 Back-Cover Texts on the back cover. Both covers must also clearly
27573 and legibly identify you as the publisher of these copies. The
27574 front cover must present the full title with all words of the
27575 title equally prominent and visible. You may add other material
27576 on the covers in addition. Copying with changes limited to the
27577 covers, as long as they preserve the title of the Document and
27578 satisfy these conditions, can be treated as verbatim copying in
27581 If the required texts for either cover are too voluminous to fit
27582 legibly, you should put the first ones listed (as many as fit
27583 reasonably) on the actual cover, and continue the rest onto
27586 If you publish or distribute Opaque copies of the Document
27587 numbering more than 100, you must either include a
27588 machine-readable Transparent copy along with each Opaque copy, or
27589 state in or with each Opaque copy a computer-network location from
27590 which the general network-using public has access to download
27591 using public-standard network protocols a complete Transparent
27592 copy of the Document, free of added material. If you use the
27593 latter option, you must take reasonably prudent steps, when you
27594 begin distribution of Opaque copies in quantity, to ensure that
27595 this Transparent copy will remain thus accessible at the stated
27596 location until at least one year after the last time you
27597 distribute an Opaque copy (directly or through your agents or
27598 retailers) of that edition to the public.
27600 It is requested, but not required, that you contact the authors of
27601 the Document well before redistributing any large number of
27602 copies, to give them a chance to provide you with an updated
27603 version of the Document.
27607 You may copy and distribute a Modified Version of the Document
27608 under the conditions of sections 2 and 3 above, provided that you
27609 release the Modified Version under precisely this License, with
27610 the Modified Version filling the role of the Document, thus
27611 licensing distribution and modification of the Modified Version to
27612 whoever possesses a copy of it. In addition, you must do these
27613 things in the Modified Version:
27615 A. Use in the Title Page (and on the covers, if any) a title
27616 distinct from that of the Document, and from those of
27617 previous versions (which should, if there were any, be listed
27618 in the History section of the Document). You may use the
27619 same title as a previous version if the original publisher of
27620 that version gives permission.
27622 B. List on the Title Page, as authors, one or more persons or
27623 entities responsible for authorship of the modifications in
27624 the Modified Version, together with at least five of the
27625 principal authors of the Document (all of its principal
27626 authors, if it has fewer than five), unless they release you
27627 from this requirement.
27629 C. State on the Title page the name of the publisher of the
27630 Modified Version, as the publisher.
27632 D. Preserve all the copyright notices of the Document.
27634 E. Add an appropriate copyright notice for your modifications
27635 adjacent to the other copyright notices.
27637 F. Include, immediately after the copyright notices, a license
27638 notice giving the public permission to use the Modified
27639 Version under the terms of this License, in the form shown in
27640 the Addendum below.
27642 G. Preserve in that license notice the full lists of Invariant
27643 Sections and required Cover Texts given in the Document's
27646 H. Include an unaltered copy of this License.
27648 I. Preserve the section Entitled "History", Preserve its Title,
27649 and add to it an item stating at least the title, year, new
27650 authors, and publisher of the Modified Version as given on
27651 the Title Page. If there is no section Entitled "History" in
27652 the Document, create one stating the title, year, authors,
27653 and publisher of the Document as given on its Title Page,
27654 then add an item describing the Modified Version as stated in
27655 the previous sentence.
27657 J. Preserve the network location, if any, given in the Document
27658 for public access to a Transparent copy of the Document, and
27659 likewise the network locations given in the Document for
27660 previous versions it was based on. These may be placed in
27661 the "History" section. You may omit a network location for a
27662 work that was published at least four years before the
27663 Document itself, or if the original publisher of the version
27664 it refers to gives permission.
27666 K. For any section Entitled "Acknowledgements" or "Dedications",
27667 Preserve the Title of the section, and preserve in the
27668 section all the substance and tone of each of the contributor
27669 acknowledgements and/or dedications given therein.
27671 L. Preserve all the Invariant Sections of the Document,
27672 unaltered in their text and in their titles. Section numbers
27673 or the equivalent are not considered part of the section
27676 M. Delete any section Entitled "Endorsements". Such a section
27677 may not be included in the Modified Version.
27679 N. Do not retitle any existing section to be Entitled
27680 "Endorsements" or to conflict in title with any Invariant
27683 O. Preserve any Warranty Disclaimers.
27685 If the Modified Version includes new front-matter sections or
27686 appendices that qualify as Secondary Sections and contain no
27687 material copied from the Document, you may at your option
27688 designate some or all of these sections as invariant. To do this,
27689 add their titles to the list of Invariant Sections in the Modified
27690 Version's license notice. These titles must be distinct from any
27691 other section titles.
27693 You may add a section Entitled "Endorsements", provided it contains
27694 nothing but endorsements of your Modified Version by various
27695 parties--for example, statements of peer review or that the text
27696 has been approved by an organization as the authoritative
27697 definition of a standard.
27699 You may add a passage of up to five words as a Front-Cover Text,
27700 and a passage of up to 25 words as a Back-Cover Text, to the end
27701 of the list of Cover Texts in the Modified Version. Only one
27702 passage of Front-Cover Text and one of Back-Cover Text may be
27703 added by (or through arrangements made by) any one entity. If the
27704 Document already includes a cover text for the same cover,
27705 previously added by you or by arrangement made by the same entity
27706 you are acting on behalf of, you may not add another; but you may
27707 replace the old one, on explicit permission from the previous
27708 publisher that added the old one.
27710 The author(s) and publisher(s) of the Document do not by this
27711 License give permission to use their names for publicity for or to
27712 assert or imply endorsement of any Modified Version.
27714 5. COMBINING DOCUMENTS
27716 You may combine the Document with other documents released under
27717 this License, under the terms defined in section 4 above for
27718 modified versions, provided that you include in the combination
27719 all of the Invariant Sections of all of the original documents,
27720 unmodified, and list them all as Invariant Sections of your
27721 combined work in its license notice, and that you preserve all
27722 their Warranty Disclaimers.
27724 The combined work need only contain one copy of this License, and
27725 multiple identical Invariant Sections may be replaced with a single
27726 copy. If there are multiple Invariant Sections with the same name
27727 but different contents, make the title of each such section unique
27728 by adding at the end of it, in parentheses, the name of the
27729 original author or publisher of that section if known, or else a
27730 unique number. Make the same adjustment to the section titles in
27731 the list of Invariant Sections in the license notice of the
27734 In the combination, you must combine any sections Entitled
27735 "History" in the various original documents, forming one section
27736 Entitled "History"; likewise combine any sections Entitled
27737 "Acknowledgements", and any sections Entitled "Dedications". You
27738 must delete all sections Entitled "Endorsements."
27740 6. COLLECTIONS OF DOCUMENTS
27742 You may make a collection consisting of the Document and other
27743 documents released under this License, and replace the individual
27744 copies of this License in the various documents with a single copy
27745 that is included in the collection, provided that you follow the
27746 rules of this License for verbatim copying of each of the
27747 documents in all other respects.
27749 You may extract a single document from such a collection, and
27750 distribute it individually under this License, provided you insert
27751 a copy of this License into the extracted document, and follow
27752 this License in all other respects regarding verbatim copying of
27755 7. AGGREGATION WITH INDEPENDENT WORKS
27757 A compilation of the Document or its derivatives with other
27758 separate and independent documents or works, in or on a volume of
27759 a storage or distribution medium, is called an "aggregate" if the
27760 copyright resulting from the compilation is not used to limit the
27761 legal rights of the compilation's users beyond what the individual
27762 works permit. When the Document is included in an aggregate, this
27763 License does not apply to the other works in the aggregate which
27764 are not themselves derivative works of the Document.
27766 If the Cover Text requirement of section 3 is applicable to these
27767 copies of the Document, then if the Document is less than one half
27768 of the entire aggregate, the Document's Cover Texts may be placed
27769 on covers that bracket the Document within the aggregate, or the
27770 electronic equivalent of covers if the Document is in electronic
27771 form. Otherwise they must appear on printed covers that bracket
27772 the whole aggregate.
27776 Translation is considered a kind of modification, so you may
27777 distribute translations of the Document under the terms of section
27778 4. Replacing Invariant Sections with translations requires special
27779 permission from their copyright holders, but you may include
27780 translations of some or all Invariant Sections in addition to the
27781 original versions of these Invariant Sections. You may include a
27782 translation of this License, and all the license notices in the
27783 Document, and any Warranty Disclaimers, provided that you also
27784 include the original English version of this License and the
27785 original versions of those notices and disclaimers. In case of a
27786 disagreement between the translation and the original version of
27787 this License or a notice or disclaimer, the original version will
27790 If a section in the Document is Entitled "Acknowledgements",
27791 "Dedications", or "History", the requirement (section 4) to
27792 Preserve its Title (section 1) will typically require changing the
27797 You may not copy, modify, sublicense, or distribute the Document
27798 except as expressly provided for under this License. Any other
27799 attempt to copy, modify, sublicense or distribute the Document is
27800 void, and will automatically terminate your rights under this
27801 License. However, parties who have received copies, or rights,
27802 from you under this License will not have their licenses
27803 terminated so long as such parties remain in full compliance.
27805 10. FUTURE REVISIONS OF THIS LICENSE
27807 The Free Software Foundation may publish new, revised versions of
27808 the GNU Free Documentation License from time to time. Such new
27809 versions will be similar in spirit to the present version, but may
27810 differ in detail to address new problems or concerns. See
27811 `http://www.gnu.org/copyleft/'.
27813 Each version of the License is given a distinguishing version
27814 number. If the Document specifies that a particular numbered
27815 version of this License "or any later version" applies to it, you
27816 have the option of following the terms and conditions either of
27817 that specified version or of any later version that has been
27818 published (not as a draft) by the Free Software Foundation. If
27819 the Document does not specify a version number of this License,
27820 you may choose any version ever published (not as a draft) by the
27821 Free Software Foundation.
27823 ADDENDUM: How to use this License for your documents
27824 ====================================================
27826 To use this License in a document you have written, include a copy of
27827 the License in the document and put the following copyright and license
27828 notices just after the title page:
27830 Copyright (C) YEAR YOUR NAME.
27831 Permission is granted to copy, distribute and/or modify this document
27832 under the terms of the GNU Free Documentation License, Version 1.2
27833 or any later version published by the Free Software Foundation;
27834 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
27835 Texts. A copy of the license is included in the section entitled ``GNU
27836 Free Documentation License''.
27838 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
27839 replace the "with...Texts." line with this:
27841 with the Invariant Sections being LIST THEIR TITLES, with
27842 the Front-Cover Texts being LIST, and with the Back-Cover Texts
27845 If you have Invariant Sections without Cover Texts, or some other
27846 combination of the three, merge those two alternatives to suit the
27849 If your document contains nontrivial examples of program code, we
27850 recommend releasing these examples in parallel under your choice of
27851 free software license, such as the GNU General Public License, to
27852 permit their use in free software.
27855 File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top
27857 Contributors to GCC
27858 *******************
27860 The GCC project would like to thank its many contributors. Without
27861 them the project would not have been nearly as successful as it has
27862 been. Any omissions in this list are accidental. Feel free to contact
27863 <law@redhat.com> or <gerald@pfeifer.com> if you have been left out or
27864 some of your contributions are not listed. Please keep this list in
27865 alphabetical order.
27867 * Analog Devices helped implement the support for complex data types
27870 * John David Anglin for threading-related fixes and improvements to
27871 libstdc++-v3, and the HP-UX port.
27873 * James van Artsdalen wrote the code that makes efficient use of the
27874 Intel 80387 register stack.
27876 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta
27879 * Alasdair Baird for various bug fixes.
27881 * Giovanni Bajo for analyzing lots of complicated C++ problem
27884 * Peter Barada for his work to improve code generation for new
27887 * Gerald Baumgartner added the signature extension to the C++ front
27890 * Godmar Back for his Java improvements and encouragement.
27892 * Scott Bambrough for help porting the Java compiler.
27894 * Wolfgang Bangerth for processing tons of bug reports.
27896 * Jon Beniston for his Microsoft Windows port of Java.
27898 * Daniel Berlin for better DWARF2 support, faster/better
27899 optimizations, improved alias analysis, plus migrating GCC to
27902 * Geoff Berry for his Java object serialization work and various
27905 * Eric Blake for helping to make GCJ and libgcj conform to the
27908 * Janne Blomqvist for contributions to gfortran.
27910 * Segher Boessenkool for various fixes.
27912 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and
27915 * Neil Booth for work on cpplib, lang hooks, debug hooks and other
27916 miscellaneous clean-ups.
27918 * Steven Bosscher for integrating the gfortran front end into GCC
27919 and for contributing to the tree-ssa branch.
27921 * Eric Botcazou for fixing middle- and backend bugs left and right.
27923 * Per Bothner for his direction via the steering committee and
27924 various improvements to the infrastructure for supporting new
27925 languages. Chill front end implementation. Initial
27926 implementations of cpplib, fix-header, config.guess, libio, and
27927 past C++ library (libg++) maintainer. Dreaming up, designing and
27928 implementing much of GCJ.
27930 * Devon Bowen helped port GCC to the Tahoe.
27932 * Don Bowman for mips-vxworks contributions.
27934 * Dave Brolley for work on cpplib and Chill.
27936 * Paul Brook for work on the ARM architecture and maintaining
27939 * Robert Brown implemented the support for Encore 32000 systems.
27941 * Christian Bruel for improvements to local store elimination.
27943 * Herman A.J. ten Brugge for various fixes.
27945 * Joerg Brunsmann for Java compiler hacking and help with the GCJ
27948 * Joe Buck for his direction via the steering committee.
27950 * Craig Burley for leadership of the G77 Fortran effort.
27952 * Stephan Buys for contributing Doxygen notes for libstdc++.
27954 * Paolo Carlini for libstdc++ work: lots of efficiency improvements
27955 to the C++ strings, streambufs and formatted I/O, hard detective
27956 work on the frustrating localization issues, and keeping up with
27957 the problem reports.
27959 * John Carr for his alias work, SPARC hacking, infrastructure
27960 improvements, previous contributions to the steering committee,
27961 loop optimizations, etc.
27963 * Stephane Carrez for 68HC11 and 68HC12 ports.
27965 * Steve Chamberlain for support for the Renesas SH and H8 processors
27966 and the PicoJava processor, and for GCJ config fixes.
27968 * Glenn Chambers for help with the GCJ FAQ.
27970 * John-Marc Chandonia for various libgcj patches.
27972 * Scott Christley for his Objective-C contributions.
27974 * Eric Christopher for his Java porting help and clean-ups.
27976 * Branko Cibej for more warning contributions.
27978 * The GNU Classpath project for all of their merged runtime code.
27980 * Nick Clifton for arm, mcore, fr30, v850, m32r work, `--help', and
27981 other random hacking.
27983 * Michael Cook for libstdc++ cleanup patches to reduce warnings.
27985 * R. Kelley Cook for making GCC buildable from a read-only directory
27986 as well as other miscellaneous build process and documentation
27989 * Ralf Corsepius for SH testing and minor bugfixing.
27991 * Stan Cox for care and feeding of the x86 port and lots of behind
27992 the scenes hacking.
27994 * Alex Crain provided changes for the 3b1.
27996 * Ian Dall for major improvements to the NS32k port.
27998 * Paul Dale for his work to add uClinux platform support to the m68k
28001 * Dario Dariol contributed the four varieties of sample programs
28002 that print a copy of their source.
28004 * Russell Davidson for fstream and stringstream fixes in libstdc++.
28006 * Bud Davis for work on the G77 and gfortran compilers.
28008 * Mo DeJong for GCJ and libgcj bug fixes.
28010 * DJ Delorie for the DJGPP port, build and libiberty maintenance,
28011 various bug fixes, and the M32C port.
28013 * Arnaud Desitter for helping to debug gfortran.
28015 * Gabriel Dos Reis for contributions to G++, contributions and
28016 maintenance of GCC diagnostics infrastructure, libstdc++-v3,
28017 including `valarray<>', `complex<>', maintaining the numerics
28018 library (including that pesky `<limits>' :-) and keeping
28019 up-to-date anything to do with numbers.
28021 * Ulrich Drepper for his work on glibc, testing of GCC using glibc,
28022 ISO C99 support, CFG dumping support, etc., plus support of the
28023 C++ runtime libraries including for all kinds of C interface
28024 issues, contributing and maintaining `complex<>', sanity checking
28025 and disbursement, configuration architecture, libio maintenance,
28026 and early math work.
28028 * Zdenek Dvorak for a new loop unroller and various fixes.
28030 * Richard Earnshaw for his ongoing work with the ARM.
28032 * David Edelsohn for his direction via the steering committee,
28033 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa
28034 loop changes, doing the entire AIX port of libstdc++ with his bare
28035 hands, and for ensuring GCC properly keeps working on AIX.
28037 * Kevin Ediger for the floating point formatting of num_put::do_put
28040 * Phil Edwards for libstdc++ work including configuration hackery,
28041 documentation maintainer, chief breaker of the web pages, the
28042 occasional iostream bug fix, and work on shared library symbol
28045 * Paul Eggert for random hacking all over GCC.
28047 * Mark Elbrecht for various DJGPP improvements, and for libstdc++
28048 configuration support for locales and fstream-related fixes.
28050 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and
28053 * Christian Ehrhardt for dealing with bug reports.
28055 * Ben Elliston for his work to move the Objective-C runtime into its
28056 own subdirectory and for his work on autoconf.
28058 * Marc Espie for OpenBSD support.
28060 * Doug Evans for much of the global optimization framework, arc,
28061 m32r, and SPARC work.
28063 * Christopher Faylor for his work on the Cygwin port and for caring
28064 and feeding the gcc.gnu.org box and saving its users tons of spam.
28066 * Fred Fish for BeOS support and Ada fixes.
28068 * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ.
28070 * Peter Gerwinski for various bug fixes and the Pascal front end.
28072 * Kaveh R. Ghazi for his direction via the steering committee,
28073 amazing work to make `-W -Wall -W* -Werror' useful, and
28074 continuously testing GCC on a plethora of platforms. Kaveh
28075 extends his gratitude to the CAIP Center at Rutgers University for
28076 providing him with computing resources to work on Free Software
28077 since the late 1980s.
28079 * John Gilmore for a donation to the FSF earmarked improving GNU
28082 * Judy Goldberg for c++ contributions.
28084 * Torbjorn Granlund for various fixes and the c-torture testsuite,
28085 multiply- and divide-by-constant optimization, improved long long
28086 support, improved leaf function register allocation, and his
28087 direction via the steering committee.
28089 * Anthony Green for his `-Os' contributions and Java front end work.
28091 * Stu Grossman for gdb hacking, allowing GCJ developers to debug
28094 * Michael K. Gschwind contributed the port to the PDP-11.
28096 * Ron Guilmette implemented the `protoize' and `unprotoize' tools,
28097 the support for Dwarf symbolic debugging information, and much of
28098 the support for System V Release 4. He has also worked heavily on
28099 the Intel 386 and 860 support.
28101 * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload
28104 * Bruno Haible for improvements in the runtime overhead for EH, new
28105 warnings and assorted bug fixes.
28107 * Andrew Haley for his amazing Java compiler and library efforts.
28109 * Chris Hanson assisted in making GCC work on HP-UX for the 9000
28112 * Michael Hayes for various thankless work he's done trying to get
28113 the c30/c40 ports functional. Lots of loop and unroll
28114 improvements and fixes.
28116 * Dara Hazeghi for wading through myriads of target-specific bug
28119 * Kate Hedstrom for staking the G77 folks with an initial testsuite.
28121 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64
28122 work, loop opts, and generally fixing lots of old problems we've
28123 ignored for years, flow rewrite and lots of further stuff,
28124 including reviewing tons of patches.
28126 * Aldy Hernandez for working on the PowerPC port, SIMD support, and
28129 * Nobuyuki Hikichi of Software Research Associates, Tokyo,
28130 contributed the support for the Sony NEWS machine.
28132 * Kazu Hirata for caring and feeding the Renesas H8/300 port and
28135 * Katherine Holcomb for work on gfortran.
28137 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots
28138 of testing and bug fixing, particularly of GCC configury code.
28140 * Steve Holmgren for MachTen patches.
28142 * Jan Hubicka for his x86 port improvements.
28144 * Falk Hueffner for working on C and optimization bug reports.
28146 * Bernardo Innocenti for his m68k work, including merging of
28147 ColdFire improvements and uClinux support.
28149 * Christian Iseli for various bug fixes.
28151 * Kamil Iskra for general m68k hacking.
28153 * Lee Iverson for random fixes and MIPS testing.
28155 * Andreas Jaeger for testing and benchmarking of GCC and various bug
28158 * Jakub Jelinek for his SPARC work and sibling call optimizations as
28159 well as lots of bug fixes and test cases, and for improving the
28162 * Janis Johnson for ia64 testing and fixes, her quality improvement
28163 sidetracks, and web page maintenance.
28165 * Kean Johnston for SCO OpenServer support and various fixes.
28167 * Tim Josling for the sample language treelang based originally on
28168 Richard Kenner's "toy" language.
28170 * Nicolai Josuttis for additional libstdc++ documentation.
28172 * Klaus Kaempf for his ongoing work to make alpha-vms a viable
28175 * Steven G. Kargl for work on gfortran.
28177 * David Kashtan of SRI adapted GCC to VMS.
28179 * Ryszard Kabatek for many, many libstdc++ bug fixes and
28180 optimizations of strings, especially member functions, and for
28183 * Geoffrey Keating for his ongoing work to make the PPC work for
28184 GNU/Linux and his automatic regression tester.
28186 * Brendan Kehoe for his ongoing work with G++ and for a lot of early
28187 work in just about every part of libstdc++.
28189 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the
28192 * Richard Kenner of the New York University Ultracomputer Research
28193 Laboratory wrote the machine descriptions for the AMD 29000, the
28194 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the
28195 support for instruction attributes. He also made changes to
28196 better support RISC processors including changes to common
28197 subexpression elimination, strength reduction, function calling
28198 sequence handling, and condition code support, in addition to
28199 generalizing the code for frame pointer elimination and delay slot
28200 scheduling. Richard Kenner was also the head maintainer of GCC
28203 * Mumit Khan for various contributions to the Cygwin and Mingw32
28204 ports and maintaining binary releases for Microsoft Windows hosts,
28205 and for massive libstdc++ porting work to Cygwin/Mingw32.
28207 * Robin Kirkham for cpu32 support.
28209 * Mark Klein for PA improvements.
28211 * Thomas Koenig for various bug fixes.
28213 * Bruce Korb for the new and improved fixincludes code.
28215 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3
28218 * Charles LaBrec contributed the support for the Integrated Solutions
28221 * Asher Langton and Mike Kumbera for contributing Cray pointer
28222 support to gfortran, and for other gfortran improvements.
28224 * Jeff Law for his direction via the steering committee,
28225 coordinating the entire egcs project and GCC 2.95, rolling out
28226 snapshots and releases, handling merges from GCC2, reviewing tons
28227 of patches that might have fallen through the cracks else, and
28228 random but extensive hacking.
28230 * Marc Lehmann for his direction via the steering committee and
28231 helping with analysis and improvements of x86 performance.
28233 * Victor Leikehman for work on gfortran.
28235 * Ted Lemon wrote parts of the RTL reader and printer.
28237 * Kriang Lerdsuwanakij for C++ improvements including template as
28238 template parameter support, and many C++ fixes.
28240 * Warren Levy for tremendous work on libgcj (Java Runtime Library)
28241 and random work on the Java front end.
28243 * Alain Lichnewsky ported GCC to the MIPS CPU.
28245 * Oskar Liljeblad for hacking on AWT and his many Java bug reports
28248 * Robert Lipe for OpenServer support, new testsuites, testing, etc.
28250 * Weiwen Liu for testing and various bug fixes.
28252 * Dave Love for his ongoing work with the Fortran front end and
28255 * Martin von Lo"wis for internal consistency checking infrastructure,
28256 various C++ improvements including namespace support, and tons of
28257 assistance with libstdc++/compiler merges.
28259 * H.J. Lu for his previous contributions to the steering committee,
28260 many x86 bug reports, prototype patches, and keeping the GNU/Linux
28263 * Greg McGary for random fixes and (someday) bounded pointers.
28265 * Andrew MacLeod for his ongoing work in building a real EH system,
28266 various code generation improvements, work on the global
28269 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC
28270 hacking improvements to compile-time performance, overall
28271 knowledge and direction in the area of instruction scheduling, and
28272 design and implementation of the automaton based instruction
28275 * Bob Manson for his behind the scenes work on dejagnu.
28277 * Philip Martin for lots of libstdc++ string and vector iterator
28278 fixes and improvements, and string clean up and testsuites.
28280 * All of the Mauve project contributors, for Java test code.
28282 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements.
28284 * Adam Megacz for his work on the Microsoft Windows port of GCJ.
28286 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS,
28287 powerpc, haifa, ECOFF debug support, and other assorted hacking.
28289 * Jason Merrill for his direction via the steering committee and
28290 leading the G++ effort.
28292 * David Miller for his direction via the steering committee, lots of
28293 SPARC work, improvements in jump.c and interfacing with the Linux
28296 * Gary Miller ported GCC to Charles River Data Systems machines.
28298 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning
28299 the entire libstdc++ testsuite namespace-compatible.
28301 * Mark Mitchell for his direction via the steering committee,
28302 mountains of C++ work, load/store hoisting out of loops, alias
28303 analysis improvements, ISO C `restrict' support, and serving as
28304 release manager for GCC 3.x.
28306 * Alan Modra for various GNU/Linux bits and testing.
28308 * Toon Moene for his direction via the steering committee, Fortran
28309 maintenance, and his ongoing work to make us make Fortran run fast.
28311 * Jason Molenda for major help in the care and feeding of all the
28312 services on the gcc.gnu.org (formerly egcs.cygnus.com)
28313 machine--mail, web services, ftp services, etc etc. Doing all
28314 this work on scrap paper and the backs of envelopes would have
28317 * Catherine Moore for fixing various ugly problems we have sent her
28318 way, including the haifa bug which was killing the Alpha & PowerPC
28321 * Mike Moreton for his various Java patches.
28323 * David Mosberger-Tang for various Alpha improvements, and for the
28324 initial IA-64 port.
28326 * Stephen Moshier contributed the floating point emulator that
28327 assists in cross-compilation and permits support for floating
28328 point numbers wider than 64 bits and for ISO C99 support.
28330 * Bill Moyer for his behind the scenes work on various issues.
28332 * Philippe De Muyter for his work on the m68k port.
28334 * Joseph S. Myers for his work on the PDP-11 port, format checking
28335 and ISO C99 support, and continuous emphasis on (and contributions
28338 * Nathan Myers for his work on libstdc++-v3: architecture and
28339 authorship through the first three snapshots, including
28340 implementation of locale infrastructure, string, shadow C headers,
28341 and the initial project documentation (DESIGN, CHECKLIST, and so
28342 forth). Later, more work on MT-safe string and shadow headers.
28344 * Felix Natter for documentation on porting libstdc++.
28346 * Nathanael Nerode for cleaning up the configuration/build process.
28348 * NeXT, Inc. donated the front end that supports the Objective-C
28351 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to
28352 the search engine setup, various documentation fixes and other
28355 * Geoff Noer for his work on getting cygwin native builds working.
28357 * Diego Novillo for his SPEC performance tracking web pages and
28358 assorted fixes in the middle end and various back ends.
28360 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64,
28361 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and
28362 related infrastructure improvements.
28364 * Alexandre Oliva for various build infrastructure improvements,
28365 scripts and amazing testing work, including keeping libtool issues
28368 * Stefan Olsson for work on mt_alloc.
28370 * Melissa O'Neill for various NeXT fixes.
28372 * Rainer Orth for random MIPS work, including improvements to GCC's
28373 o32 ABI support, improvements to dejagnu's MIPS support, Java
28374 configuration clean-ups and porting work, etc.
28376 * Hartmut Penner for work on the s390 port.
28378 * Paul Petersen wrote the machine description for the Alliant FX/8.
28380 * Alexandre Petit-Bianco for implementing much of the Java compiler
28381 and continued Java maintainership.
28383 * Matthias Pfaller for major improvements to the NS32k port.
28385 * Gerald Pfeifer for his direction via the steering committee,
28386 pointing out lots of problems we need to solve, maintenance of the
28387 web pages, and taking care of documentation maintenance in general.
28389 * Andrew Pinski for processing bug reports by the dozen.
28391 * Ovidiu Predescu for his work on the Objective-C front end and
28394 * Jerry Quinn for major performance improvements in C++ formatted
28397 * Ken Raeburn for various improvements to checker, MIPS ports and
28398 various cleanups in the compiler.
28400 * Rolf W. Rasmussen for hacking on AWT.
28402 * David Reese of Sun Microsystems contributed to the Solaris on
28405 * Volker Reichelt for keeping up with the problem reports.
28407 * Joern Rennecke for maintaining the sh port, loop, regmove & reload
28410 * Loren J. Rittle for improvements to libstdc++-v3 including the
28411 FreeBSD port, threading fixes, thread-related configury changes,
28412 critical threading documentation, and solutions to really tricky
28413 I/O problems, as well as keeping GCC properly working on FreeBSD
28414 and continuous testing.
28416 * Craig Rodrigues for processing tons of bug reports.
28418 * Ola Ro"nnerup for work on mt_alloc.
28420 * Gavin Romig-Koch for lots of behind the scenes MIPS work.
28422 * David Ronis inspired and encouraged Craig to rewrite the G77
28423 documentation in texinfo format by contributing a first pass at a
28424 translation of the old `g77-0.5.16/f/DOC' file.
28426 * Ken Rose for fixes to GCC's delay slot filling code.
28428 * Paul Rubin wrote most of the preprocessor.
28430 * Pe'tur Runo'lfsson for major performance improvements in C++
28431 formatted I/O and large file support in C++ filebuf.
28433 * Chip Salzenberg for libstdc++ patches and improvements to locales,
28434 traits, Makefiles, libio, libtool hackery, and "long long" support.
28436 * Juha Sarlin for improvements to the H8 code generator.
28438 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series
28441 * Roger Sayle for improvements to constant folding and GCC's RTL
28442 optimizers as well as for fixing numerous bugs.
28444 * Bradley Schatz for his work on the GCJ FAQ.
28446 * Peter Schauer wrote the code to allow debugging to work on the
28449 * William Schelter did most of the work on the Intel 80386 support.
28451 * Tobias Schlu"ter for work on gfortran.
28453 * Bernd Schmidt for various code generation improvements and major
28454 work in the reload pass as well a serving as release manager for
28457 * Peter Schmid for constant testing of libstdc++--especially
28458 application testing, going above and beyond what was requested for
28459 the release criteria--and libstdc++ header file tweaks.
28461 * Jason Schroeder for jcf-dump patches.
28463 * Andreas Schwab for his work on the m68k port.
28465 * Lars Segerlund for work on gfortran.
28467 * Joel Sherrill for his direction via the steering committee, RTEMS
28468 contributions and RTEMS testing.
28470 * Nathan Sidwell for many C++ fixes/improvements.
28472 * Jeffrey Siegal for helping RMS with the original design of GCC,
28473 some code which handles the parse tree and RTL data structures,
28474 constant folding and help with the original VAX & m68k ports.
28476 * Kenny Simpson for prompting libstdc++ fixes due to defect reports
28477 from the LWG (thereby keeping GCC in line with updates from the
28480 * Franz Sirl for his ongoing work with making the PPC port stable
28483 * Andrey Slepuhin for assorted AIX hacking.
28485 * Christopher Smith did the port for Convex machines.
28487 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports.
28489 * Randy Smith finished the Sun FPA support.
28491 * Scott Snyder for queue, iterator, istream, and string fixes and
28492 libstdc++ testsuite entries. Also for providing the patch to G77
28493 to add rudimentary support for `INTEGER*1', `INTEGER*2', and
28496 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique.
28498 * Richard Stallman, for writing the original GCC and launching the
28501 * Jan Stein of the Chalmers Computer Society provided support for
28502 Genix, as well as part of the 32000 machine description.
28504 * Nigel Stephens for various mips16 related fixes/improvements.
28506 * Jonathan Stone wrote the machine description for the Pyramid
28509 * Graham Stott for various infrastructure improvements.
28511 * John Stracke for his Java HTTP protocol fixes.
28513 * Mike Stump for his Elxsi port, G++ contributions over the years
28514 and more recently his vxworks contributions
28516 * Jeff Sturm for Java porting help, bug fixes, and encouragement.
28518 * Shigeya Suzuki for this fixes for the bsdi platforms.
28520 * Ian Lance Taylor for his mips16 work, general configury hacking,
28523 * Holger Teutsch provided the support for the Clipper CPU.
28525 * Gary Thomas for his ongoing work to make the PPC work for
28528 * Philipp Thomas for random bug fixes throughout the compiler
28530 * Jason Thorpe for thread support in libstdc++ on NetBSD.
28532 * Kresten Krab Thorup wrote the run time support for the Objective-C
28533 language and the fantastic Java bytecode interpreter.
28535 * Michael Tiemann for random bug fixes, the first instruction
28536 scheduler, initial C++ support, function integration, NS32k, SPARC
28537 and M88k machine description work, delay slot scheduling.
28539 * Andreas Tobler for his work porting libgcj to Darwin.
28541 * Teemu Torma for thread safe exception handling support.
28543 * Leonard Tower wrote parts of the parser, RTL generator, and RTL
28544 definitions, and of the VAX machine description.
28546 * Tom Tromey for internationalization support and for his many Java
28547 contributions and libgcj maintainership.
28549 * Lassi Tuura for improvements to config.guess to determine HP
28552 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes.
28554 * Andy Vaught for the design and initial implementation of the
28555 gfortran front end.
28557 * Brent Verner for work with the libstdc++ cshadow files and their
28558 associated configure steps.
28560 * Todd Vierling for contributions for NetBSD ports.
28562 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML
28565 * Dean Wakerley for converting the install documentation from HTML
28566 to texinfo in time for GCC 3.0.
28568 * Krister Walfridsson for random bug fixes.
28570 * Feng Wang for contributions to gfortran.
28572 * Stephen M. Webb for time and effort on making libstdc++ shadow
28573 files work with the tricky Solaris 8+ headers, and for pushing the
28574 build-time header tree.
28576 * John Wehle for various improvements for the x86 code generator,
28577 related infrastructure improvements to help x86 code generation,
28578 value range propagation and other work, WE32k port.
28580 * Ulrich Weigand for work on the s390 port.
28582 * Zack Weinberg for major work on cpplib and various other bug fixes.
28584 * Matt Welsh for help with Linux Threads support in GCJ.
28586 * Urban Widmark for help fixing java.io.
28588 * Mark Wielaard for new Java library code and his work integrating
28591 * Dale Wiles helped port GCC to the Tahoe.
28593 * Bob Wilson from Tensilica, Inc. for the Xtensa port.
28595 * Jim Wilson for his direction via the steering committee, tackling
28596 hard problems in various places that nobody else wanted to work
28597 on, strength reduction and other loop optimizations.
28599 * Paul Woegerer and Tal Agmon for the CRX port.
28601 * Carlo Wood for various fixes.
28603 * Tom Wood for work on the m88k port.
28605 * Canqun Yang for work on gfortran.
28607 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine
28608 description for the Tron architecture (specifically, the Gmicro).
28610 * Kevin Zachmann helped port GCC to the Tahoe.
28612 * Ayal Zaks for Swing Modulo Scheduling (SMS).
28614 * Xiaoqiang Zhang for work on gfortran.
28616 * Gilles Zunino for help porting Java to Irix.
28619 The following people are recognized for their contributions to GNAT,
28620 the Ada front end of GCC:
28623 * Romain Berrendonner
28673 * Hristian Kirtchev
28716 The following people are recognized for their contributions of new
28717 features, bug reports, testing and integration of classpath/libgcj for
28719 * Lillian Angel for `JTree' implementation and lots Free Swing
28720 additions and bugfixes.
28722 * Wolfgang Baer for `GapContent' bugfixes.
28724 * Anthony Balkissoon for `JList', Free Swing 1.5 updates and mouse
28725 event fixes, lots of Free Swing work including `JTable' editing.
28727 * Stuart Ballard for RMI constant fixes.
28729 * Goffredo Baroncelli for `HTTPURLConnection' fixes.
28731 * Gary Benson for `MessageFormat' fixes.
28733 * Daniel Bonniot for `Serialization' fixes.
28735 * Chris Burdess for lots of gnu.xml and http protocol fixes, `StAX'
28736 and `DOM xml:id' support.
28738 * Ka-Hing Cheung for `TreePath' and `TreeSelection' fixes.
28740 * Archie Cobbs for build fixes, VM interface updates,
28741 `URLClassLoader' updates.
28743 * Kelley Cook for build fixes.
28745 * Martin Cordova for Suggestions for better `SocketTimeoutException'.
28747 * David Daney for `BitSet' bugfixes, `HttpURLConnection' rewrite and
28750 * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo
28751 2D support. Lots of imageio framework additions, lots of AWT and
28752 Free Swing bugfixes.
28754 * Jeroen Frijters for `ClassLoader' and nio cleanups, serialization
28755 fixes, better `Proxy' support, bugfixes and IKVM integration.
28757 * Santiago Gala for `AccessControlContext' fixes.
28759 * Nicolas Geoffray for `VMClassLoader' and `AccessController'
28762 * David Gilbert for `basic' and `metal' icon and plaf support and
28763 lots of documenting, Lots of Free Swing and metal theme additions.
28764 `MetalIconFactory' implementation.
28766 * Anthony Green for `MIDI' framework, `ALSA' and `DSSI' providers.
28768 * Andrew Haley for `Serialization' and `URLClassLoader' fixes, gcj
28771 * Kim Ho for `JFileChooser' implementation.
28773 * Andrew John Hughes for `Locale' and net fixes, URI RFC2986
28774 updates, `Serialization' fixes, `Properties' XML support and
28775 generic branch work, VMIntegration guide update.
28777 * Bastiaan Huisman for `TimeZone' bugfixing.
28779 * Andreas Jaeger for mprec updates.
28781 * Paul Jenner for better `-Werror' support.
28783 * Ito Kazumitsu for `NetworkInterface' implementation and updates.
28785 * Roman Kennke for `BoxLayout', `GrayFilter' and `SplitPane', plus
28786 bugfixes all over. Lots of Free Swing work including styled text.
28788 * Simon Kitching for `String' cleanups and optimization suggestions.
28790 * Michael Koch for configuration fixes, `Locale' updates, bug and
28793 * Guilhem Lavaux for configuration, thread and channel fixes and
28794 Kaffe integration. JCL native `Pointer' updates. Logger bugfixes.
28796 * David Lichteblau for JCL support library global/local reference
28799 * Aaron Luchko for JDWP updates and documentation fixes.
28801 * Ziga Mahkovec for `Graphics2D' upgraded to Cairo 0.5 and new regex
28804 * Sven de Marothy for BMP imageio support, CSS and `TextLayout'
28805 fixes. `GtkImage' rewrite, 2D, awt, free swing and date/time fixes
28806 and implementing the Qt4 peers.
28808 * Casey Marshall for crypto algorithm fixes, `FileChannel' lock,
28809 `SystemLogger' and `FileHandler' rotate implementations, NIO
28810 `FileChannel.map' support, security and policy updates.
28812 * Bryce McKinlay for RMI work.
28814 * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus
28815 testing and documenting.
28817 * Kalle Olavi Niemitalo for build fixes.
28819 * Rainer Orth for build fixes.
28821 * Andrew Overholt for `File' locking fixes.
28823 * Ingo Proetel for `Image', `Logger' and `URLClassLoader' updates.
28825 * Olga Rodimina for `MenuSelectionManager' implemenation.
28827 * Jan Roehrich for `BasicTreeUI' and `JTree' fixes.
28829 * Julian Scheid for documentation updates and gjdoc support.
28831 * Christian Schlichtherle for zip fixes and cleanups.
28833 * Robert Schuster for documentation updates and beans fixes,
28834 `TreeNode' enumerations and `ActionCommand' and various fixes, XML
28835 and URL, AWT and Free Swing bugfixes.
28837 * Keith Seitz for lots of JDWP work.
28839 * Christian Thalinger for 64-bit cleanups, Configuration and VM
28840 interface fixes and `CACAO' integration, `fdlibm' updates.
28842 * Gael Thomas for `VMClassLoader' boot packages support sugestions.
28844 * Andreas Tobler for Darwin and Solaris testing and fixing, `Qt4'
28845 support for Darwin/OS X, `Graphics2D' support, `gtk+' updates.
28847 * Dalibor Topic for better `DEBUG' support, build cleanups and Kaffe
28848 integration. `Qt4' build infrastructure, `SHA1PRNG' and
28849 `GdkPixbugDecoder' updates.
28851 * Tom Tromey for Eclipse integration, generics work, lots of bugfixes
28852 and gcj integration including coordinating The Big Merge.
28854 * Mark Wielaard for bugfixes, packaging and release management,
28855 `Clipboard' implementation, system call interrupts and network
28856 timeouts and `GdkPixpufDecoder' fixes.
28859 In addition to the above, all of which also contributed time and
28860 energy in testing GCC, we would like to thank the following for their
28861 contributions to testing:
28863 * Michael Abd-El-Malek
28873 * David Billinghurst
28877 * Stephane Bortzmeyer
28887 * Bradford Castalia
28907 * Charles-Antoine Gauthier
28929 * Kevin B. Hendricks
28933 * Christian Joensson
28941 * Anand Krishnaswamy
28943 * A. O. V. Le Blanc
29007 * Pedro A. M. Vazquez
29017 And finally we'd like to thank everyone who uses the compiler, submits
29018 bug reports and generally reminds us why we're doing this work in the
29022 File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top
29027 GCC's command line options are indexed here without any initial `-' or
29028 `--'. Where an option has both positive and negative forms (such as
29029 `-fOPTION' and `-fno-OPTION'), relevant entries in the manual are
29030 indexed under the most appropriate form; it may sometimes be useful to
29031 look up both forms.
29036 * msoft-float: Soft float library routines.
29040 File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top
29048 * ! in constraint: Multi-Alternative. (line 47)
29049 * # in constraint: Modifiers. (line 67)
29050 * # in template: Output Template. (line 66)
29051 * #pragma: Misc. (line 344)
29052 * % in constraint: Modifiers. (line 45)
29053 * % in GTY option: GTY Options. (line 18)
29054 * % in template: Output Template. (line 6)
29055 * & in constraint: Modifiers. (line 25)
29056 * (nil): RTL Objects. (line 73)
29057 * *: Host Common. (line 17)
29058 * * in constraint: Modifiers. (line 72)
29059 * * in template: Output Statement. (line 29)
29060 * *TARGET_GET_PCH_VALIDITY: PCH Target. (line 7)
29061 * + in constraint: Modifiers. (line 12)
29062 * /c in RTL dump: Flags. (line 224)
29063 * /f in RTL dump: Flags. (line 229)
29064 * /i in RTL dump: Flags. (line 280)
29065 * /j in RTL dump: Flags. (line 293)
29066 * /s in RTL dump: Flags. (line 244)
29067 * /u in RTL dump: Flags. (line 303)
29068 * /v in RTL dump: Flags. (line 335)
29069 * 0 in constraint: Simple Constraints. (line 118)
29070 * < in constraint: Simple Constraints. (line 46)
29071 * = in constraint: Modifiers. (line 8)
29072 * > in constraint: Simple Constraints. (line 50)
29073 * ? in constraint: Multi-Alternative. (line 41)
29074 * \: Output Template. (line 46)
29075 * __absvdi2: Integer library routines.
29077 * __absvsi2: Integer library routines.
29079 * __adddf3: Soft float library routines.
29081 * __addsf3: Soft float library routines.
29083 * __addtf3: Soft float library routines.
29085 * __addvdi3: Integer library routines.
29087 * __addvsi3: Integer library routines.
29089 * __addxf3: Soft float library routines.
29091 * __ashldi3: Integer library routines.
29093 * __ashlsi3: Integer library routines.
29095 * __ashlti3: Integer library routines.
29097 * __ashrdi3: Integer library routines.
29099 * __ashrsi3: Integer library routines.
29101 * __ashrti3: Integer library routines.
29103 * __builtin_args_info: Varargs. (line 42)
29104 * __builtin_classify_type: Varargs. (line 76)
29105 * __builtin_next_arg: Varargs. (line 66)
29106 * __builtin_saveregs: Varargs. (line 24)
29107 * __clear_cache: Miscellaneous routines.
29109 * __clzdi2: Integer library routines.
29111 * __clzsi2: Integer library routines.
29113 * __clzti2: Integer library routines.
29115 * __cmpdf2: Soft float library routines.
29117 * __cmpdi2: Integer library routines.
29119 * __cmpsf2: Soft float library routines.
29121 * __cmptf2: Soft float library routines.
29123 * __cmpti2: Integer library routines.
29125 * __CTOR_LIST__: Initialization. (line 25)
29126 * __ctzdi2: Integer library routines.
29128 * __ctzsi2: Integer library routines.
29130 * __ctzti2: Integer library routines.
29132 * __divdf3: Soft float library routines.
29134 * __divdi3: Integer library routines.
29136 * __divsf3: Soft float library routines.
29138 * __divsi3: Integer library routines.
29140 * __divtf3: Soft float library routines.
29142 * __divti3: Integer library routines.
29144 * __divxf3: Soft float library routines.
29146 * __DTOR_LIST__: Initialization. (line 25)
29147 * __eqdf2: Soft float library routines.
29149 * __eqsf2: Soft float library routines.
29151 * __eqtf2: Soft float library routines.
29153 * __extenddftf2: Soft float library routines.
29155 * __extenddfxf2: Soft float library routines.
29157 * __extendsfdf2: Soft float library routines.
29159 * __extendsftf2: Soft float library routines.
29161 * __extendsfxf2: Soft float library routines.
29163 * __ffsdi2: Integer library routines.
29165 * __ffsti2: Integer library routines.
29167 * __fixdfdi: Soft float library routines.
29169 * __fixdfsi: Soft float library routines.
29171 * __fixdfti: Soft float library routines.
29173 * __fixsfdi: Soft float library routines.
29175 * __fixsfsi: Soft float library routines.
29177 * __fixsfti: Soft float library routines.
29179 * __fixtfdi: Soft float library routines.
29181 * __fixtfsi: Soft float library routines.
29183 * __fixtfti: Soft float library routines.
29185 * __fixunsdfdi: Soft float library routines.
29187 * __fixunsdfsi: Soft float library routines.
29189 * __fixunsdfti: Soft float library routines.
29191 * __fixunssfdi: Soft float library routines.
29193 * __fixunssfsi: Soft float library routines.
29195 * __fixunssfti: Soft float library routines.
29197 * __fixunstfdi: Soft float library routines.
29199 * __fixunstfsi: Soft float library routines.
29201 * __fixunstfti: Soft float library routines.
29203 * __fixunsxfdi: Soft float library routines.
29205 * __fixunsxfsi: Soft float library routines.
29207 * __fixunsxfti: Soft float library routines.
29209 * __fixxfdi: Soft float library routines.
29211 * __fixxfsi: Soft float library routines.
29213 * __fixxfti: Soft float library routines.
29215 * __floatdidf: Soft float library routines.
29217 * __floatdisf: Soft float library routines.
29219 * __floatditf: Soft float library routines.
29221 * __floatdixf: Soft float library routines.
29223 * __floatsidf: Soft float library routines.
29225 * __floatsisf: Soft float library routines.
29227 * __floatsitf: Soft float library routines.
29229 * __floatsixf: Soft float library routines.
29231 * __floattidf: Soft float library routines.
29233 * __floattisf: Soft float library routines.
29235 * __floattitf: Soft float library routines.
29237 * __floattixf: Soft float library routines.
29239 * __gedf2: Soft float library routines.
29241 * __gesf2: Soft float library routines.
29243 * __getf2: Soft float library routines.
29245 * __gtdf2: Soft float library routines.
29247 * __gtsf2: Soft float library routines.
29249 * __gttf2: Soft float library routines.
29251 * __ledf2: Soft float library routines.
29253 * __lesf2: Soft float library routines.
29255 * __letf2: Soft float library routines.
29257 * __lshrdi3: Integer library routines.
29259 * __lshrsi3: Integer library routines.
29261 * __lshrti3: Integer library routines.
29263 * __ltdf2: Soft float library routines.
29265 * __ltsf2: Soft float library routines.
29267 * __lttf2: Soft float library routines.
29269 * __main: Collect2. (line 15)
29270 * __moddi3: Integer library routines.
29272 * __modsi3: Integer library routines.
29274 * __modti3: Integer library routines.
29276 * __muldf3: Soft float library routines.
29278 * __muldi3: Integer library routines.
29280 * __mulsf3: Soft float library routines.
29282 * __mulsi3: Integer library routines.
29284 * __multf3: Soft float library routines.
29286 * __multi3: Integer library routines.
29288 * __mulvdi3: Integer library routines.
29290 * __mulvsi3: Integer library routines.
29292 * __mulxf3: Soft float library routines.
29294 * __nedf2: Soft float library routines.
29296 * __negdf2: Soft float library routines.
29298 * __negdi2: Integer library routines.
29300 * __negsf2: Soft float library routines.
29302 * __negtf2: Soft float library routines.
29304 * __negti2: Integer library routines.
29306 * __negvdi2: Integer library routines.
29308 * __negvsi2: Integer library routines.
29310 * __negxf2: Soft float library routines.
29312 * __nesf2: Soft float library routines.
29314 * __netf2: Soft float library routines.
29316 * __paritydi2: Integer library routines.
29318 * __paritysi2: Integer library routines.
29320 * __parityti2: Integer library routines.
29322 * __popcountdi2: Integer library routines.
29324 * __popcountsi2: Integer library routines.
29326 * __popcountti2: Integer library routines.
29328 * __subdf3: Soft float library routines.
29330 * __subsf3: Soft float library routines.
29332 * __subtf3: Soft float library routines.
29334 * __subvdi3: Integer library routines.
29336 * __subvsi3: Integer library routines.
29338 * __subxf3: Soft float library routines.
29340 * __truncdfsf2: Soft float library routines.
29342 * __trunctfdf2: Soft float library routines.
29344 * __trunctfsf2: Soft float library routines.
29346 * __truncxfdf2: Soft float library routines.
29348 * __truncxfsf2: Soft float library routines.
29350 * __ucmpdi2: Integer library routines.
29352 * __ucmpti2: Integer library routines.
29354 * __udivdi3: Integer library routines.
29356 * __udivmoddi3: Integer library routines.
29358 * __udivsi3: Integer library routines.
29360 * __udivti3: Integer library routines.
29362 * __umoddi3: Integer library routines.
29364 * __umodsi3: Integer library routines.
29366 * __umodti3: Integer library routines.
29368 * __unorddf2: Soft float library routines.
29370 * __unordsf2: Soft float library routines.
29372 * __unordtf2: Soft float library routines.
29374 * abort: Portability. (line 21)
29375 * abs: Arithmetic. (line 169)
29376 * abs and attributes: Expressions. (line 64)
29377 * ABS_EXPR: Expression trees. (line 6)
29378 * absence_set: Processor pipeline description.
29380 * absM2 instruction pattern: Standard Names. (line 292)
29381 * absolute value: Arithmetic. (line 169)
29382 * access to operands: Accessors. (line 6)
29383 * access to special operands: Special Accessors. (line 6)
29384 * accessors: Accessors. (line 6)
29385 * ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 46)
29386 * ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 135)
29387 * ADA_LONG_TYPE_SIZE: Type Layout. (line 26)
29388 * ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 15)
29389 * addM3 instruction pattern: Standard Names. (line 187)
29390 * addMODEcc instruction pattern: Standard Names. (line 661)
29391 * addr_diff_vec: Side Effects. (line 299)
29392 * addr_diff_vec, length of: Insn Lengths. (line 26)
29393 * ADDR_EXPR: Expression trees. (line 6)
29394 * addr_vec: Side Effects. (line 294)
29395 * addr_vec, length of: Insn Lengths. (line 26)
29396 * address constraints: Simple Constraints. (line 152)
29397 * address_operand <1>: Simple Constraints. (line 156)
29398 * address_operand: Machine-Independent Predicates.
29400 * addressing modes: Addressing Modes. (line 6)
29401 * addressof: Regs and Memory. (line 260)
29402 * ADJUST_FIELD_ALIGN: Storage Layout. (line 185)
29403 * ADJUST_INSN_LENGTH: Insn Lengths. (line 35)
29404 * AGGR_INIT_EXPR: Expression trees. (line 6)
29405 * aggregates as return values: Aggregate Return. (line 6)
29406 * alias: Alias analysis. (line 6)
29407 * ALL_COP_ADDITIONAL_REGISTER_NAMES: MIPS Coprocessors. (line 32)
29408 * ALL_REGS: Register Classes. (line 17)
29409 * allocate_stack instruction pattern: Standard Names. (line 984)
29410 * alternate entry points: Insns. (line 145)
29411 * and: Arithmetic. (line 136)
29412 * and and attributes: Expressions. (line 50)
29413 * and, canonicalization of: Insn Canonicalizations.
29415 * andM3 instruction pattern: Standard Names. (line 193)
29416 * annotations: Annotations. (line 6)
29417 * APPLY_RESULT_SIZE: Scalar Return. (line 85)
29418 * ARG_POINTER_CFA_OFFSET: Frame Layout. (line 182)
29419 * ARG_POINTER_REGNUM: Frame Registers. (line 41)
29420 * ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65)
29421 * arg_pointer_rtx: Frame Registers. (line 85)
29422 * ARGS_GROW_DOWNWARD: Frame Layout. (line 35)
29423 * argument passing: Interface. (line 36)
29424 * arguments in registers: Register Arguments. (line 6)
29425 * arguments on stack: Stack Arguments. (line 6)
29426 * arithmetic library: Soft float library routines.
29428 * arithmetic shift: Arithmetic. (line 151)
29429 * arithmetic, in RTL: Arithmetic. (line 6)
29430 * ARITHMETIC_TYPE_P: Types. (line 76)
29431 * array: Types. (line 6)
29432 * ARRAY_RANGE_REF: Expression trees. (line 6)
29433 * ARRAY_REF: Expression trees. (line 6)
29434 * ARRAY_TYPE: Types. (line 6)
29435 * AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 151)
29436 * ashift: Arithmetic. (line 151)
29437 * ashift and attributes: Expressions. (line 64)
29438 * ashiftrt: Arithmetic. (line 159)
29439 * ashiftrt and attributes: Expressions. (line 64)
29440 * ashlM3 instruction pattern: Standard Names. (line 275)
29441 * ashrM3 instruction pattern: Standard Names. (line 285)
29442 * ASM_APP_OFF: File Framework. (line 61)
29443 * ASM_APP_ON: File Framework. (line 54)
29444 * ASM_COMMENT_START: File Framework. (line 49)
29445 * ASM_DECLARE_CLASS_REFERENCE: Label Output. (line 427)
29446 * ASM_DECLARE_CONSTANT_NAME: Label Output. (line 128)
29447 * ASM_DECLARE_FUNCTION_NAME: Label Output. (line 87)
29448 * ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 101)
29449 * ASM_DECLARE_OBJECT_NAME: Label Output. (line 114)
29450 * ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 143)
29451 * ASM_DECLARE_UNRESOLVED_REFERENCE: Label Output. (line 433)
29452 * ASM_FINAL_SPEC: Driver. (line 144)
29453 * ASM_FINISH_DECLARE_OBJECT: Label Output. (line 151)
29454 * ASM_FORMAT_PRIVATE_NAME: Label Output. (line 345)
29455 * asm_fprintf: Instruction Output. (line 123)
29456 * ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 134)
29457 * ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 329)
29458 * asm_input: Side Effects. (line 281)
29459 * asm_input and /v: Flags. (line 84)
29460 * ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 82)
29461 * ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 72)
29462 * asm_noperands: Insns. (line 277)
29463 * asm_operands and /v: Flags. (line 84)
29464 * asm_operands, RTL sharing: Sharing. (line 45)
29465 * asm_operands, usage: Assembler. (line 6)
29466 * ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 9)
29467 * ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 26)
29468 * ASM_OUTPUT_ALIGN: Alignment Output. (line 79)
29469 * ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 84)
29470 * ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 64)
29471 * ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 23)
29472 * ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 31)
29473 * ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 100)
29474 * ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 92)
29475 * ASM_OUTPUT_ASCII: Data Output. (line 50)
29476 * ASM_OUTPUT_BSS: Uninitialized Data. (line 44)
29477 * ASM_OUTPUT_CASE_END: Dispatch Tables. (line 51)
29478 * ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 38)
29479 * ASM_OUTPUT_COMMON: Uninitialized Data. (line 10)
29480 * ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 317)
29481 * ASM_OUTPUT_DEF: Label Output. (line 366)
29482 * ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 374)
29483 * ASM_OUTPUT_DWARF_DELTA: SDB and DWARF. (line 42)
29484 * ASM_OUTPUT_DWARF_OFFSET: SDB and DWARF. (line 46)
29485 * ASM_OUTPUT_DWARF_PCREL: SDB and DWARF. (line 51)
29486 * ASM_OUTPUT_EXTERNAL: Label Output. (line 255)
29487 * ASM_OUTPUT_FDESC: Data Output. (line 59)
29488 * ASM_OUTPUT_IDENT: File Framework. (line 83)
29489 * ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 17)
29490 * ASM_OUTPUT_LABEL: Label Output. (line 9)
29491 * ASM_OUTPUT_LABEL_REF: Label Output. (line 290)
29492 * ASM_OUTPUT_LABELREF: Label Output. (line 276)
29493 * ASM_OUTPUT_LOCAL: Uninitialized Data. (line 79)
29494 * ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 88)
29495 * ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 41)
29496 * ASM_OUTPUT_OPCODE: Instruction Output. (line 21)
29497 * ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 109)
29498 * ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 72)
29499 * ASM_OUTPUT_REG_POP: Instruction Output. (line 178)
29500 * ASM_OUTPUT_REG_PUSH: Instruction Output. (line 173)
29501 * ASM_OUTPUT_SHARED_BSS: Uninitialized Data. (line 74)
29502 * ASM_OUTPUT_SHARED_COMMON: Uninitialized Data. (line 39)
29503 * ASM_OUTPUT_SHARED_LOCAL: Uninitialized Data. (line 108)
29504 * ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 35)
29505 * ASM_OUTPUT_SKIP: Alignment Output. (line 66)
29506 * ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 68)
29507 * ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 84)
29508 * ASM_OUTPUT_SYMBOL_REF: Label Output. (line 283)
29509 * ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 77)
29510 * ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 392)
29511 * ASM_OUTPUT_WEAKREF: Label Output. (line 194)
29512 * ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 67)
29513 * ASM_SPEC: Driver. (line 136)
29514 * ASM_STABD_OP: DBX Options. (line 36)
29515 * ASM_STABN_OP: DBX Options. (line 43)
29516 * ASM_STABS_OP: DBX Options. (line 29)
29517 * ASM_WEAKEN_DECL: Label Output. (line 186)
29518 * ASM_WEAKEN_LABEL: Label Output. (line 173)
29519 * assemble_name: Label Output. (line 8)
29520 * assemble_name_raw: Label Output. (line 16)
29521 * assembler format: File Framework. (line 6)
29522 * assembler instructions in RTL: Assembler. (line 6)
29523 * ASSEMBLER_DIALECT: Instruction Output. (line 146)
29524 * assigning attribute values to insns: Tagging Insns. (line 6)
29525 * assignment operator: Function Basics. (line 6)
29526 * asterisk in template: Output Statement. (line 29)
29527 * atan2M3 instruction pattern: Standard Names. (line 344)
29528 * attr <1>: Tagging Insns. (line 54)
29529 * attr: Expressions. (line 154)
29530 * attr_flag: Expressions. (line 119)
29531 * attribute expressions: Expressions. (line 6)
29532 * attribute specifications: Attr Example. (line 6)
29533 * attribute specifications example: Attr Example. (line 6)
29534 * attributes: Attributes. (line 6)
29535 * attributes, defining: Defining Attributes.
29537 * attributes, target-specific: Target Attributes. (line 6)
29538 * autoincrement addressing, availability: Portability. (line 21)
29539 * autoincrement/decrement addressing: Simple Constraints. (line 28)
29540 * automata_option: Processor pipeline description.
29542 * automaton based pipeline description: Processor pipeline description.
29544 * automaton based scheduler: Processor pipeline description.
29546 * AVOID_CCMODE_COPIES: Values in Registers.
29548 * backslash: Output Template. (line 46)
29549 * barrier: Insns. (line 165)
29550 * barrier and /f: Flags. (line 111)
29551 * barrier and /i: Flags. (line 138)
29552 * barrier and /v: Flags. (line 29)
29553 * BASE_REG_CLASS: Register Classes. (line 107)
29554 * basic block: Basic Blocks. (line 6)
29555 * basic-block.h: Control Flow. (line 6)
29556 * BASIC_BLOCK: Basic Blocks. (line 19)
29557 * basic_block: Basic Blocks. (line 6)
29558 * BB_DIRTY, clear_bb_flags, update_life_info_in_dirty_blocks: Liveness information.
29560 * BB_HEAD, BB_END: Maintaining the CFG.
29562 * bCOND instruction pattern: Standard Names. (line 698)
29563 * BIGGEST_ALIGNMENT: Storage Layout. (line 167)
29564 * BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 178)
29565 * BImode: Machine Modes. (line 22)
29566 * BIND_EXPR: Expression trees. (line 6)
29567 * BINFO_TYPE: Classes. (line 6)
29568 * bit-fields: Bit-Fields. (line 6)
29569 * BIT_AND_EXPR: Expression trees. (line 6)
29570 * BIT_IOR_EXPR: Expression trees. (line 6)
29571 * BIT_NOT_EXPR: Expression trees. (line 6)
29572 * BIT_XOR_EXPR: Expression trees. (line 6)
29573 * BITFIELD_NBYTES_LIMITED: Storage Layout. (line 323)
29574 * BITS_BIG_ENDIAN: Storage Layout. (line 12)
29575 * BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8)
29576 * BITS_PER_UNIT: Storage Layout. (line 52)
29577 * BITS_PER_WORD: Storage Layout. (line 57)
29578 * bitwise complement: Arithmetic. (line 132)
29579 * bitwise exclusive-or: Arithmetic. (line 146)
29580 * bitwise inclusive-or: Arithmetic. (line 141)
29581 * bitwise logical-and: Arithmetic. (line 136)
29582 * BLKmode: Machine Modes. (line 97)
29583 * BLKmode, and function return values: Calls. (line 23)
29584 * block statement iterators <1>: Maintaining the CFG.
29586 * block statement iterators: Basic Blocks. (line 68)
29587 * BLOCK_FOR_INSN, bb_for_stmt: Maintaining the CFG.
29589 * BLOCK_REG_PADDING: Register Arguments. (line 214)
29590 * Blocks: Blocks. (line 6)
29591 * bool <1>: Exception Region Output.
29593 * bool: Sections. (line 228)
29594 * BOOL_TYPE_SIZE: Type Layout. (line 44)
29595 * BOOLEAN_TYPE: Types. (line 6)
29596 * branch prediction: Profile information.
29598 * BRANCH_COST: Costs. (line 52)
29599 * break_out_memory_refs: Addressing Modes. (line 157)
29600 * BREAK_STMT: Function Bodies. (line 6)
29601 * bsi_commit_edge_inserts: Maintaining the CFG.
29603 * bsi_end_p: Maintaining the CFG.
29605 * bsi_insert_after: Maintaining the CFG.
29607 * bsi_insert_before: Maintaining the CFG.
29609 * bsi_insert_on_edge: Maintaining the CFG.
29611 * bsi_last: Maintaining the CFG.
29613 * bsi_next: Maintaining the CFG.
29615 * bsi_prev: Maintaining the CFG.
29617 * bsi_remove: Maintaining the CFG.
29619 * bsi_start: Maintaining the CFG.
29621 * BSS_SECTION_ASM_OP: Sections. (line 53)
29622 * btruncM2 instruction pattern: Standard Names. (line 362)
29623 * builtin_longjmp instruction pattern: Standard Names. (line 1070)
29624 * builtin_setjmp_receiver instruction pattern: Standard Names.
29626 * builtin_setjmp_setup instruction pattern: Standard Names. (line 1049)
29627 * byte_mode: Machine Modes. (line 222)
29628 * BYTES_BIG_ENDIAN: Storage Layout. (line 24)
29629 * BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 136)
29630 * C statements for assembler output: Output Statement. (line 6)
29631 * C/C++ Internal Representation: Trees. (line 6)
29632 * C4X_FLOAT_FORMAT: Storage Layout. (line 399)
29633 * C99 math functions, implicit usage: Library Calls. (line 76)
29634 * c_register_pragma: Misc. (line 367)
29635 * c_register_pragma_with_expansion: Misc. (line 369)
29636 * call <1>: Side Effects. (line 86)
29637 * call: Flags. (line 224)
29638 * call instruction pattern: Standard Names. (line 731)
29639 * call usage: Calls. (line 10)
29640 * call, in mem: Flags. (line 89)
29641 * call-clobbered register: Register Basics. (line 35)
29642 * call-saved register: Register Basics. (line 35)
29643 * call-used register: Register Basics. (line 35)
29644 * CALL_EXPR: Expression trees. (line 6)
29645 * call_insn: Insns. (line 93)
29646 * call_insn and /f: Flags. (line 111)
29647 * call_insn and /i: Flags. (line 138)
29648 * call_insn and /j: Flags. (line 169)
29649 * call_insn and /s: Flags. (line 34)
29650 * call_insn and /u: Flags. (line 19)
29651 * call_insn and /v: Flags. (line 29)
29652 * CALL_INSN_FUNCTION_USAGE: Insns. (line 99)
29653 * call_pop instruction pattern: Standard Names. (line 759)
29654 * CALL_POPS_ARGS: Stack Arguments. (line 127)
29655 * CALL_REALLY_USED_REGISTERS: Register Basics. (line 46)
29656 * CALL_USED_REGISTERS: Register Basics. (line 35)
29657 * call_used_regs: Register Basics. (line 59)
29658 * call_value instruction pattern: Standard Names. (line 751)
29659 * call_value_pop instruction pattern: Standard Names. (line 759)
29660 * CALLER_SAVE_PROFITABLE: Caller Saves. (line 11)
29661 * calling conventions: Stack and Calling. (line 6)
29662 * calling functions in RTL: Calls. (line 6)
29663 * CAN_DEBUG_WITHOUT_FP: Run-time Target. (line 121)
29664 * CAN_ELIMINATE: Elimination. (line 71)
29665 * can_fallthru: Basic Blocks. (line 57)
29666 * canadian: Configure Terms. (line 6)
29667 * CANNOT_CHANGE_MODE_CLASS: Register Classes. (line 398)
29668 * canonicalization of instructions: Insn Canonicalizations.
29670 * CANONICALIZE_COMPARISON: Condition Code. (line 84)
29671 * canonicalize_funcptr_for_compare instruction pattern: Standard Names.
29673 * CASE_USE_BIT_TESTS: Misc. (line 54)
29674 * CASE_VALUES_THRESHOLD: Misc. (line 47)
29675 * CASE_VECTOR_MODE: Misc. (line 27)
29676 * CASE_VECTOR_PC_RELATIVE: Misc. (line 40)
29677 * CASE_VECTOR_SHORTEN_MODE: Misc. (line 31)
29678 * casesi instruction pattern: Standard Names. (line 839)
29679 * cbranchMODE4 instruction pattern: Standard Names. (line 720)
29680 * cc0: Regs and Memory. (line 182)
29681 * cc0, RTL sharing: Sharing. (line 27)
29682 * cc0_rtx: Regs and Memory. (line 208)
29683 * CC1_SPEC: Driver. (line 118)
29684 * CC1PLUS_SPEC: Driver. (line 126)
29685 * cc_status: Condition Code. (line 8)
29686 * CC_STATUS_MDEP: Condition Code. (line 19)
29687 * CC_STATUS_MDEP_INIT: Condition Code. (line 25)
29688 * CCmode: Machine Modes. (line 90)
29689 * CDImode: Machine Modes. (line 116)
29690 * CEIL_DIV_EXPR: Expression trees. (line 6)
29691 * CEIL_MOD_EXPR: Expression trees. (line 6)
29692 * ceilM2 instruction pattern: Standard Names. (line 378)
29693 * CFG, Control Flow Graph: Control Flow. (line 6)
29694 * cfghooks.h: Maintaining the CFG.
29696 * cgraph_finalize_function: Parsing pass. (line 52)
29697 * chain_next: GTY Options. (line 188)
29698 * chain_prev: GTY Options. (line 188)
29699 * change_address: Standard Names. (line 47)
29700 * char <1>: Misc. (line 650)
29701 * char <2>: PCH Target. (line 12)
29702 * char: Sections. (line 220)
29703 * CHAR_TYPE_SIZE: Type Layout. (line 39)
29704 * check_stack instruction pattern: Standard Names. (line 1002)
29705 * CHImode: Machine Modes. (line 116)
29706 * class: Classes. (line 6)
29707 * class definitions, register: Register Classes. (line 6)
29708 * class preference constraints: Class Preferences. (line 6)
29709 * CLASS_LIKELY_SPILLED_P: Register Classes. (line 369)
29710 * CLASS_MAX_NREGS: Register Classes. (line 386)
29711 * CLASS_TYPE_P: Types. (line 80)
29712 * classes of RTX codes: RTL Classes. (line 6)
29713 * CLASSTYPE_DECLARED_CLASS: Classes. (line 6)
29714 * CLASSTYPE_HAS_MUTABLE: Classes. (line 80)
29715 * CLASSTYPE_NON_POD_P: Classes. (line 85)
29716 * CLEANUP_DECL: Function Bodies. (line 6)
29717 * CLEANUP_EXPR: Function Bodies. (line 6)
29718 * CLEANUP_POINT_EXPR: Expression trees. (line 6)
29719 * CLEANUP_STMT: Function Bodies. (line 6)
29720 * Cleanups: Cleanups. (line 6)
29721 * CLEAR_BY_PIECES_P: Costs. (line 124)
29722 * CLEAR_INSN_CACHE: Trampolines. (line 101)
29723 * CLEAR_RATIO: Costs. (line 115)
29724 * clobber: Side Effects. (line 100)
29725 * clz: Arithmetic. (line 182)
29726 * CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 293)
29727 * clzM2 instruction pattern: Standard Names. (line 423)
29728 * cmpM instruction pattern: Standard Names. (line 452)
29729 * cmpmemM instruction pattern: Standard Names. (line 553)
29730 * cmpstrM instruction pattern: Standard Names. (line 534)
29731 * cmpstrnM instruction pattern: Standard Names. (line 522)
29732 * code generation RTL sequences: Expander Definitions.
29734 * code macros in .md files: Code Macros. (line 6)
29735 * code_label: Insns. (line 124)
29736 * code_label and /i: Flags. (line 49)
29737 * code_label and /v: Flags. (line 29)
29738 * CODE_LABEL_NUMBER: Insns. (line 124)
29739 * codes, RTL expression: RTL Objects. (line 47)
29740 * COImode: Machine Modes. (line 116)
29741 * COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32)
29742 * COLLECT_EXPORT_LIST: Misc. (line 706)
29743 * COLLECT_SHARED_FINI_FUNC: Macros for Initialization.
29745 * COLLECT_SHARED_INIT_FUNC: Macros for Initialization.
29747 * combiner pass: Regs and Memory. (line 148)
29748 * commit_edge_insertions: Maintaining the CFG.
29750 * compare: Arithmetic. (line 43)
29751 * compare, canonicalization of: Insn Canonicalizations.
29753 * comparison_operator: Machine-Independent Predicates.
29755 * compiler passes and files: Passes. (line 6)
29756 * complement, bitwise: Arithmetic. (line 132)
29757 * COMPLEX_CST: Expression trees. (line 6)
29758 * COMPLEX_EXPR: Expression trees. (line 6)
29759 * COMPLEX_TYPE: Types. (line 6)
29760 * COMPONENT_REF: Expression trees. (line 6)
29761 * Compound Expressions: Compound Expressions.
29763 * Compound Lvalues: Compound Lvalues. (line 6)
29764 * COMPOUND_EXPR: Expression trees. (line 6)
29765 * COMPOUND_LITERAL_EXPR: Expression trees. (line 6)
29766 * COMPOUND_LITERAL_EXPR_DECL: Expression trees. (line 565)
29767 * COMPOUND_LITERAL_EXPR_DECL_STMT: Expression trees. (line 565)
29768 * computed jump: Edges. (line 128)
29769 * computing the length of an insn: Insn Lengths. (line 6)
29770 * cond: Comparisons. (line 90)
29771 * cond and attributes: Expressions. (line 37)
29772 * cond_exec: Side Effects. (line 245)
29773 * COND_EXPR: Expression trees. (line 6)
29774 * condition code register: Regs and Memory. (line 182)
29775 * condition code status: Condition Code. (line 6)
29776 * condition codes: Comparisons. (line 20)
29777 * conditional execution: Conditional Execution.
29779 * Conditional Expressions: Conditional Expressions.
29781 * CONDITIONAL_REGISTER_USAGE: Register Basics. (line 60)
29782 * conditional_trap instruction pattern: Standard Names. (line 1136)
29783 * conditions, in patterns: Patterns. (line 43)
29784 * configuration file <1>: Host Misc. (line 6)
29785 * configuration file: Filesystem. (line 6)
29786 * configure terms: Configure Terms. (line 6)
29787 * CONJ_EXPR: Expression trees. (line 6)
29788 * const and /i: Flags. (line 138)
29789 * CONST0_RTX: Constants. (line 73)
29790 * const0_rtx: Constants. (line 16)
29791 * CONST1_RTX: Constants. (line 73)
29792 * const1_rtx: Constants. (line 16)
29793 * CONST2_RTX: Constants. (line 73)
29794 * const2_rtx: Constants. (line 16)
29795 * CONST_DECL: Declarations. (line 6)
29796 * const_double: Constants. (line 32)
29797 * const_double, RTL sharing: Sharing. (line 29)
29798 * CONST_DOUBLE_CHAIN: Constants. (line 51)
29799 * CONST_DOUBLE_LOW: Constants. (line 60)
29800 * CONST_DOUBLE_MEM: Constants. (line 51)
29801 * CONST_DOUBLE_OK_FOR_CONSTRAINT_P: Register Classes. (line 445)
29802 * CONST_DOUBLE_OK_FOR_LETTER_P: Register Classes. (line 430)
29803 * const_double_operand: Machine-Independent Predicates.
29805 * const_int: Constants. (line 8)
29806 * const_int and attribute tests: Expressions. (line 47)
29807 * const_int and attributes: Expressions. (line 10)
29808 * const_int, RTL sharing: Sharing. (line 23)
29809 * const_int_operand: Machine-Independent Predicates.
29811 * CONST_OK_FOR_CONSTRAINT_P: Register Classes. (line 425)
29812 * CONST_OK_FOR_LETTER_P: Register Classes. (line 416)
29813 * CONST_OR_PURE_CALL_P: Flags. (line 19)
29814 * const_string: Constants. (line 82)
29815 * const_string and attributes: Expressions. (line 20)
29816 * const_true_rtx: Constants. (line 26)
29817 * const_vector: Constants. (line 39)
29818 * const_vector, RTL sharing: Sharing. (line 32)
29819 * constant attributes: Constant Attributes.
29821 * constant definitions: Constant Definitions.
29823 * CONSTANT_ADDRESS_P: Addressing Modes. (line 29)
29824 * CONSTANT_ALIGNMENT: Storage Layout. (line 212)
29825 * CONSTANT_P: Addressing Modes. (line 35)
29826 * CONSTANT_POOL_ADDRESS_P: Flags. (line 10)
29827 * CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 64)
29828 * constants in constraints: Simple Constraints. (line 58)
29829 * constm1_rtx: Constants. (line 16)
29830 * constraint modifier characters: Modifiers. (line 6)
29831 * constraint, matching: Simple Constraints. (line 130)
29832 * CONSTRAINT_LEN: Register Classes. (line 131)
29833 * constraints: Constraints. (line 6)
29834 * constraints, machine specific: Machine Constraints.
29836 * CONSTRUCTOR: Expression trees. (line 6)
29837 * constructor: Function Basics. (line 6)
29838 * constructors, automatic calls: Collect2. (line 15)
29839 * constructors, output of: Initialization. (line 6)
29840 * container: Containers. (line 6)
29841 * CONTINUE_STMT: Function Bodies. (line 6)
29842 * contributors: Contributors. (line 6)
29843 * controlling register usage: Register Basics. (line 76)
29844 * controlling the compilation driver: Driver. (line 6)
29845 * conventions, run-time: Interface. (line 6)
29846 * conversions: Conversions. (line 6)
29847 * CONVERT_EXPR: Expression trees. (line 6)
29848 * copy constructor: Function Basics. (line 6)
29849 * copy_rtx: Addressing Modes. (line 209)
29850 * copy_rtx_if_shared: Sharing. (line 64)
29851 * copysignM3 instruction pattern: Standard Names. (line 404)
29852 * cosM2 instruction pattern: Standard Names. (line 303)
29853 * costs of instructions: Costs. (line 6)
29854 * CP_INTEGRAL_TYPE: Types. (line 72)
29855 * cp_namespace_decls: Namespaces. (line 44)
29856 * CP_TYPE_CONST_NON_VOLATILE_P: Types. (line 45)
29857 * CP_TYPE_CONST_P: Types. (line 36)
29858 * CP_TYPE_QUALS: Types. (line 6)
29859 * CP_TYPE_RESTRICT_P: Types. (line 42)
29860 * CP_TYPE_VOLATILE_P: Types. (line 39)
29861 * CPLUSPLUS_CPP_SPEC: Driver. (line 113)
29862 * CPP_SPEC: Driver. (line 106)
29863 * CQImode: Machine Modes. (line 116)
29864 * cross compilation and floating point: Floating Point. (line 6)
29865 * CRT_CALL_STATIC_FUNCTION: Sections. (line 88)
29866 * CRTSTUFF_T_CFLAGS: Target Fragment. (line 35)
29867 * CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 39)
29868 * CSImode: Machine Modes. (line 116)
29869 * CTImode: Machine Modes. (line 116)
29870 * ctz: Arithmetic. (line 190)
29871 * CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 294)
29872 * ctzM2 instruction pattern: Standard Names. (line 430)
29873 * CUMULATIVE_ARGS: Register Arguments. (line 127)
29874 * current_function_epilogue_delay_list: Function Entry. (line 181)
29875 * current_function_is_leaf: Leaf Functions. (line 51)
29876 * current_function_outgoing_args_size: Stack Arguments. (line 45)
29877 * current_function_pops_args: Function Entry. (line 106)
29878 * current_function_pretend_args_size: Function Entry. (line 112)
29879 * current_function_uses_only_leaf_regs: Leaf Functions. (line 51)
29880 * current_insn_predicate: Conditional Execution.
29882 * data bypass: Processor pipeline description.
29884 * data dependence delays: Processor pipeline description.
29886 * data structures: Per-Function Data. (line 6)
29887 * DATA_ALIGNMENT: Storage Layout. (line 199)
29888 * data_section: Sections. (line 109)
29889 * DATA_SECTION_ASM_OP: Sections. (line 33)
29890 * DBR_OUTPUT_SEQEND: Instruction Output. (line 107)
29891 * dbr_sequence_length: Instruction Output. (line 106)
29892 * DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 103)
29893 * DBX_CONTIN_CHAR: DBX Options. (line 66)
29894 * DBX_CONTIN_LENGTH: DBX Options. (line 56)
29895 * DBX_DEBUGGING_INFO: DBX Options. (line 9)
29896 * DBX_FUNCTION_FIRST: DBX Options. (line 97)
29897 * DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 109)
29898 * DBX_NO_XREFS: DBX Options. (line 50)
29899 * DBX_OUTPUT_LBRAC: DBX Hooks. (line 9)
29900 * DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 34)
29901 * DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 9)
29902 * DBX_OUTPUT_NFUN: DBX Hooks. (line 18)
29903 * DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX.
29905 * DBX_OUTPUT_RBRAC: DBX Hooks. (line 15)
29906 * DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 22)
29907 * DBX_REGISTER_NUMBER: All Debuggers. (line 9)
29908 * DBX_REGPARM_STABS_CODE: DBX Options. (line 87)
29909 * DBX_REGPARM_STABS_LETTER: DBX Options. (line 92)
29910 * DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 82)
29911 * DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 73)
29912 * DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 78)
29913 * DBX_USE_BINCL: DBX Options. (line 115)
29914 * DCmode: Machine Modes. (line 111)
29915 * De Morgan's law: Insn Canonicalizations.
29917 * dead_or_set_p: define_peephole. (line 65)
29918 * DEBUG_SYMS_TEXT: DBX Options. (line 25)
29919 * DEBUGGER_ARG_OFFSET: All Debuggers. (line 37)
29920 * DEBUGGER_AUTO_OFFSET: All Debuggers. (line 28)
29921 * DECL_ALIGN: Declarations. (line 6)
29922 * DECL_ANTICIPATED: Function Basics. (line 48)
29923 * DECL_ARGUMENTS: Function Basics. (line 163)
29924 * DECL_ARRAY_DELETE_OPERATOR_P: Function Basics. (line 184)
29925 * DECL_ARTIFICIAL <1>: Function Basics. (line 6)
29926 * DECL_ARTIFICIAL: Working with declarations.
29928 * DECL_ASSEMBLER_NAME: Function Basics. (line 6)
29929 * DECL_ATTRIBUTES: Attributes. (line 22)
29930 * DECL_BASE_CONSTRUCTOR_P: Function Basics. (line 94)
29931 * DECL_CLASS_SCOPE_P: Working with declarations.
29933 * DECL_COMPLETE_CONSTRUCTOR_P: Function Basics. (line 90)
29934 * DECL_COMPLETE_DESTRUCTOR_P: Function Basics. (line 104)
29935 * DECL_CONST_MEMFUNC_P: Function Basics. (line 77)
29936 * DECL_CONSTRUCTOR_P: Function Basics. (line 6)
29937 * DECL_CONTEXT: Namespaces. (line 26)
29938 * DECL_CONV_FN_P: Function Basics. (line 6)
29939 * DECL_COPY_CONSTRUCTOR_P: Function Basics. (line 98)
29940 * DECL_DESTRUCTOR_P: Function Basics. (line 6)
29941 * DECL_EXTERN_C_FUNCTION_P: Function Basics. (line 52)
29942 * DECL_EXTERNAL <1>: Function Basics. (line 38)
29943 * DECL_EXTERNAL: Declarations. (line 6)
29944 * DECL_FUNCTION_MEMBER_P: Function Basics. (line 6)
29945 * DECL_FUNCTION_SCOPE_P: Working with declarations.
29947 * DECL_GLOBAL_CTOR_P: Function Basics. (line 6)
29948 * DECL_GLOBAL_DTOR_P: Function Basics. (line 6)
29949 * DECL_INITIAL: Declarations. (line 6)
29950 * DECL_LINKONCE_P: Function Basics. (line 6)
29951 * DECL_LOCAL_FUNCTION_P: Function Basics. (line 44)
29952 * DECL_MAIN_P: Function Basics. (line 7)
29953 * DECL_NAME <1>: Function Basics. (line 6)
29954 * DECL_NAME <2>: Working with declarations.
29956 * DECL_NAME: Namespaces. (line 15)
29957 * DECL_NAMESPACE_ALIAS: Namespaces. (line 30)
29958 * DECL_NAMESPACE_SCOPE_P: Working with declarations.
29960 * DECL_NAMESPACE_STD_P: Namespaces. (line 40)
29961 * DECL_NON_THUNK_FUNCTION_P: Function Basics. (line 144)
29962 * DECL_NONCONVERTING_P: Function Basics. (line 86)
29963 * DECL_NONSTATIC_MEMBER_FUNCTION_P: Function Basics. (line 74)
29964 * DECL_OVERLOADED_OPERATOR_P: Function Basics. (line 6)
29965 * DECL_RESULT: Function Basics. (line 168)
29966 * DECL_SIZE: Declarations. (line 6)
29967 * DECL_STATIC_FUNCTION_P: Function Basics. (line 71)
29968 * DECL_STMT: Function Bodies. (line 6)
29969 * DECL_STMT_DECL: Function Bodies. (line 6)
29970 * DECL_THUNK_P: Function Basics. (line 122)
29971 * DECL_VOLATILE_MEMFUNC_P: Function Basics. (line 80)
29972 * declaration: Declarations. (line 6)
29973 * declarations, RTL: RTL Declarations. (line 6)
29974 * DECLARE_LIBRARY_RENAMES: Library Calls. (line 9)
29975 * decrement_and_branch_until_zero instruction pattern: Standard Names.
29977 * default: GTY Options. (line 82)
29978 * default_file_start: File Framework. (line 9)
29979 * DEFAULT_GDB_EXTENSIONS: DBX Options. (line 18)
29980 * DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 34)
29981 * DEFAULT_SIGNED_CHAR: Type Layout. (line 102)
29982 * define_asm_attributes: Tagging Insns. (line 73)
29983 * define_attr: Defining Attributes.
29985 * define_automaton: Processor pipeline description.
29987 * define_bypass: Processor pipeline description.
29989 * define_code_attr: Code Macros. (line 6)
29990 * define_code_macro: Code Macros. (line 6)
29991 * define_cond_exec: Conditional Execution.
29993 * define_constants: Constant Definitions.
29995 * define_cpu_unit: Processor pipeline description.
29997 * define_delay: Delay Slots. (line 25)
29998 * define_expand: Expander Definitions.
30000 * define_insn: Patterns. (line 6)
30001 * define_insn example: Example. (line 6)
30002 * define_insn_and_split: Insn Splitting. (line 170)
30003 * define_insn_reservation: Processor pipeline description.
30005 * define_mode_attr: Substitutions. (line 6)
30006 * define_mode_macro: Defining Mode Macros.
30008 * define_peephole: define_peephole. (line 6)
30009 * define_peephole2: define_peephole2. (line 6)
30010 * define_predicate: Defining Predicates.
30012 * define_query_cpu_unit: Processor pipeline description.
30014 * define_reservation: Processor pipeline description.
30016 * define_special_predicate: Defining Predicates.
30018 * define_split: Insn Splitting. (line 32)
30019 * defining attributes and their values: Defining Attributes.
30021 * defining jump instruction patterns: Jump Patterns. (line 6)
30022 * defining looping instruction patterns: Looping Patterns. (line 6)
30023 * defining peephole optimizers: Peephole Definitions.
30025 * defining predicates: Defining Predicates.
30027 * defining RTL sequences for code generation: Expander Definitions.
30029 * delay slots, defining: Delay Slots. (line 6)
30030 * DELAY_SLOTS_FOR_EPILOGUE: Function Entry. (line 163)
30031 * deletable: GTY Options. (line 150)
30032 * DELETE_IF_ORDINARY: Filesystem. (line 79)
30033 * Dependent Patterns: Dependent Patterns. (line 6)
30034 * desc: GTY Options. (line 82)
30035 * destructor: Function Basics. (line 6)
30036 * destructors, output of: Initialization. (line 6)
30037 * deterministic finite state automaton: Processor pipeline description.
30039 * DFmode: Machine Modes. (line 73)
30040 * digits in constraint: Simple Constraints. (line 118)
30041 * DImode: Machine Modes. (line 45)
30042 * DIR_SEPARATOR: Filesystem. (line 18)
30043 * DIR_SEPARATOR_2: Filesystem. (line 19)
30044 * directory options .md: Including Patterns. (line 44)
30045 * disabling certain registers: Register Basics. (line 76)
30046 * dispatch table: Dispatch Tables. (line 8)
30047 * div: Arithmetic. (line 100)
30048 * div and attributes: Expressions. (line 64)
30049 * division: Arithmetic. (line 100)
30050 * divM3 instruction pattern: Standard Names. (line 193)
30051 * divmodM4 instruction pattern: Standard Names. (line 255)
30052 * DO_BODY: Function Bodies. (line 6)
30053 * DO_COND: Function Bodies. (line 6)
30054 * DO_STMT: Function Bodies. (line 6)
30055 * DOLLARS_IN_IDENTIFIERS: Misc. (line 453)
30056 * doloop_begin instruction pattern: Standard Names. (line 908)
30057 * doloop_end instruction pattern: Standard Names. (line 887)
30058 * DONE: Expander Definitions.
30060 * DOUBLE_TYPE_SIZE: Type Layout. (line 53)
30061 * driver: Driver. (line 6)
30062 * DRIVER_SELF_SPECS: Driver. (line 71)
30063 * DUMPFILE_FORMAT: Filesystem. (line 67)
30064 * DWARF2_ASM_LINE_DEBUG_INFO: SDB and DWARF. (line 36)
30065 * DWARF2_DEBUGGING_INFO: SDB and DWARF. (line 13)
30066 * DWARF2_FRAME_INFO: SDB and DWARF. (line 30)
30067 * DWARF2_FRAME_REG_OUT: Frame Registers. (line 133)
30068 * DWARF2_UNWIND_INFO: Exception Region Output.
30070 * DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 144)
30071 * DWARF_CIE_DATA_ALIGNMENT: Exception Region Output.
30073 * DWARF_FRAME_REGISTERS: Frame Registers. (line 93)
30074 * DWARF_FRAME_REGNUM: Frame Registers. (line 125)
30075 * DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 117)
30076 * DWARF_ZERO_REG: Frame Layout. (line 151)
30077 * DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 92)
30078 * E in constraint: Simple Constraints. (line 77)
30079 * earlyclobber operand: Modifiers. (line 25)
30080 * edge: Edges. (line 6)
30081 * edge in the flow graph: Edges. (line 6)
30082 * edge iterators: Edges. (line 15)
30083 * edge splitting: Maintaining the CFG.
30085 * EDGE_ABNORMAL: Edges. (line 128)
30086 * EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 171)
30087 * EDGE_ABNORMAL, EDGE_EH: Edges. (line 96)
30088 * EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 122)
30089 * EDGE_FALLTHRU, force_nonfallthru: Edges. (line 86)
30090 * EDOM, implicit usage: Library Calls. (line 58)
30091 * EH_FRAME_IN_DATA_SECTION: Exception Region Output.
30093 * EH_FRAME_SECTION_NAME: Exception Region Output.
30095 * eh_return instruction pattern: Standard Names. (line 1076)
30096 * EH_RETURN_DATA_REGNO: Exception Handling. (line 7)
30097 * EH_RETURN_HANDLER_RTX: Exception Handling. (line 39)
30098 * EH_RETURN_STACKADJ_RTX: Exception Handling. (line 22)
30099 * EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output.
30101 * EH_USES: Function Entry. (line 158)
30102 * ei_edge: Edges. (line 43)
30103 * ei_end_p: Edges. (line 27)
30104 * ei_last: Edges. (line 23)
30105 * ei_next: Edges. (line 35)
30106 * ei_one_before_end_p: Edges. (line 31)
30107 * ei_prev: Edges. (line 39)
30108 * ei_safe_safe: Edges. (line 47)
30109 * ei_start: Edges. (line 19)
30110 * ELIGIBLE_FOR_EPILOGUE_DELAY: Function Entry. (line 169)
30111 * ELIMINABLE_REGS: Elimination. (line 44)
30112 * ELSE_CLAUSE: Function Bodies. (line 6)
30113 * EMIT_MODE_SET: Mode Switching. (line 74)
30114 * Empty Statements: Empty Statements. (line 6)
30115 * EMPTY_CLASS_EXPR: Function Bodies. (line 6)
30116 * EMPTY_FIELD_BOUNDARY: Storage Layout. (line 236)
30117 * ENABLE_EXECUTE_STACK: Trampolines. (line 111)
30118 * ENDFILE_SPEC: Driver. (line 218)
30119 * endianness: Portability. (line 21)
30120 * ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 28)
30121 * enum machine_mode: Machine Modes. (line 6)
30122 * enum reg_class: Register Classes. (line 65)
30123 * ENUMERAL_TYPE: Types. (line 6)
30124 * epilogue: Function Entry. (line 6)
30125 * epilogue instruction pattern: Standard Names. (line 1108)
30126 * EPILOGUE_USES: Function Entry. (line 152)
30127 * eq: Comparisons. (line 52)
30128 * eq and attributes: Expressions. (line 64)
30129 * eq_attr: Expressions. (line 85)
30130 * EQ_EXPR: Expression trees. (line 6)
30131 * equal: Comparisons. (line 52)
30132 * errno, implicit usage: Library Calls. (line 70)
30133 * EXACT_DIV_EXPR: Expression trees. (line 6)
30134 * examining SSA_NAMEs: SSA. (line 189)
30135 * exception handling <1>: Exception Handling. (line 6)
30136 * exception handling: Edges. (line 96)
30137 * exception_receiver instruction pattern: Standard Names. (line 1040)
30138 * exclamation point: Multi-Alternative. (line 47)
30139 * exclusion_set: Processor pipeline description.
30141 * exclusive-or, bitwise: Arithmetic. (line 146)
30142 * EXIT_EXPR: Expression trees. (line 6)
30143 * EXIT_IGNORE_STACK: Function Entry. (line 140)
30144 * expander definitions: Expander Definitions.
30146 * expM2 instruction pattern: Standard Names. (line 319)
30147 * expr_list: Insns. (line 545)
30148 * EXPR_STMT: Function Bodies. (line 6)
30149 * EXPR_STMT_EXPR: Function Bodies. (line 6)
30150 * expression: Expression trees. (line 6)
30151 * expression codes: RTL Objects. (line 47)
30152 * extendMN2 instruction pattern: Standard Names. (line 610)
30153 * extensible constraints: Simple Constraints. (line 161)
30154 * EXTRA_ADDRESS_CONSTRAINT: Register Classes. (line 499)
30155 * EXTRA_CONSTRAINT: Register Classes. (line 450)
30156 * EXTRA_CONSTRAINT_STR: Register Classes. (line 471)
30157 * EXTRA_MEMORY_CONSTRAINT: Register Classes. (line 476)
30158 * EXTRA_SECTION_FUNCTIONS: Sections. (line 110)
30159 * EXTRA_SECTIONS: Sections. (line 105)
30160 * EXTRA_SPECS: Driver. (line 245)
30161 * extv instruction pattern: Standard Names. (line 619)
30162 * extzv instruction pattern: Standard Names. (line 634)
30163 * F in constraint: Simple Constraints. (line 82)
30164 * FAIL: Expander Definitions.
30166 * fall-thru: Edges. (line 69)
30167 * FATAL_EXIT_CODE: Host Misc. (line 6)
30168 * FDL, GNU Free Documentation License: GNU Free Documentation License.
30170 * features, optional, in system conventions: Run-time Target.
30172 * ffs: Arithmetic. (line 176)
30173 * ffsM2 instruction pattern: Standard Names. (line 413)
30174 * FIELD_DECL: Declarations. (line 6)
30175 * file_end_indicate_exec_stack: File Framework. (line 41)
30176 * files and passes of the compiler: Passes. (line 6)
30177 * files, generated: Files. (line 6)
30178 * final_absence_set: Processor pipeline description.
30180 * FINAL_PRESCAN_INSN: Instruction Output. (line 46)
30181 * final_presence_set: Processor pipeline description.
30183 * final_scan_insn: Function Entry. (line 181)
30184 * final_sequence: Instruction Output. (line 117)
30185 * FIND_BASE_TERM: Addressing Modes. (line 139)
30186 * FINI_ARRAY_SECTION_ASM_OP: Sections. (line 81)
30187 * FINI_SECTION_ASM_OP: Sections. (line 68)
30188 * finite state automaton minimization: Processor pipeline description.
30190 * FIRST_PARM_OFFSET: Frame Layout. (line 67)
30191 * FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65)
30192 * FIRST_PSEUDO_REGISTER: Register Basics. (line 9)
30193 * FIRST_STACK_REG: Stack Registers. (line 23)
30194 * FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51)
30195 * fix: Conversions. (line 66)
30196 * FIX_TRUNC_EXPR: Expression trees. (line 6)
30197 * fix_truncMN2 instruction pattern: Standard Names. (line 597)
30198 * fixed register: Register Basics. (line 15)
30199 * FIXED_REGISTERS: Register Basics. (line 15)
30200 * fixed_regs: Register Basics. (line 59)
30201 * fixMN2 instruction pattern: Standard Names. (line 577)
30202 * FIXUNS_TRUNC_LIKE_FIX_TRUNC: Misc. (line 100)
30203 * fixuns_truncMN2 instruction pattern: Standard Names. (line 601)
30204 * fixunsMN2 instruction pattern: Standard Names. (line 586)
30205 * flags in RTL expression: Flags. (line 6)
30206 * float: Conversions. (line 58)
30207 * FLOAT_EXPR: Expression trees. (line 6)
30208 * float_extend: Conversions. (line 33)
30209 * FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 25)
30210 * FLOAT_STORE_FLAG_VALUE: Misc. (line 275)
30211 * float_truncate: Conversions. (line 53)
30212 * FLOAT_TYPE_SIZE: Type Layout. (line 49)
30213 * FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 43)
30214 * FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory.
30216 * floating point and cross compilation: Floating Point. (line 6)
30217 * Floating Point Emulation: Target Fragment. (line 15)
30218 * floating point emulation library, US Software GOFAST: Library Calls.
30220 * floatMN2 instruction pattern: Standard Names. (line 569)
30221 * floatunsMN2 instruction pattern: Standard Names. (line 573)
30222 * FLOOR_DIV_EXPR: Expression trees. (line 6)
30223 * FLOOR_MOD_EXPR: Expression trees. (line 6)
30224 * floorM2 instruction pattern: Standard Names. (line 354)
30225 * flow-insensitive alias analysis: Alias analysis. (line 6)
30226 * flow-sensitive alias analysis: Alias analysis. (line 6)
30227 * FOR_BODY: Function Bodies. (line 6)
30228 * FOR_COND: Function Bodies. (line 6)
30229 * FOR_EXPR: Function Bodies. (line 6)
30230 * FOR_INIT_STMT: Function Bodies. (line 6)
30231 * FOR_STMT: Function Bodies. (line 6)
30232 * FORCE_CODE_SECTION_ALIGN: Sections. (line 99)
30233 * force_reg: Standard Names. (line 36)
30234 * frame layout: Frame Layout. (line 6)
30235 * FRAME_GROWS_DOWNWARD: Frame Layout. (line 31)
30236 * FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory.
30238 * FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 200)
30239 * frame_pointer_needed: Function Entry. (line 34)
30240 * FRAME_POINTER_REGNUM: Frame Registers. (line 14)
30241 * FRAME_POINTER_REGNUM and virtual registers: Regs and Memory.
30243 * FRAME_POINTER_REQUIRED: Elimination. (line 9)
30244 * frame_pointer_rtx: Frame Registers. (line 85)
30245 * frame_related: Flags. (line 229)
30246 * frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags.
30248 * frame_related, in mem: Flags. (line 75)
30249 * frame_related, in reg: Flags. (line 98)
30250 * frame_related, in symbol_ref: Flags. (line 173)
30251 * frequency, count, BB_FREQ_BASE: Profile information.
30253 * ftruncM2 instruction pattern: Standard Names. (line 592)
30254 * function: Functions. (line 6)
30255 * function body: Function Bodies. (line 6)
30256 * function call conventions: Interface. (line 6)
30257 * function entry and exit: Function Entry. (line 6)
30258 * function entry point, alternate function entry point: Edges.
30260 * function-call insns: Calls. (line 6)
30261 * FUNCTION_ARG: Register Arguments. (line 11)
30262 * FUNCTION_ARG_ADVANCE: Register Arguments. (line 178)
30263 * FUNCTION_ARG_BOUNDARY: Register Arguments. (line 224)
30264 * FUNCTION_ARG_PADDING: Register Arguments. (line 189)
30265 * FUNCTION_ARG_REGNO_P: Register Arguments. (line 229)
30266 * FUNCTION_BOUNDARY: Storage Layout. (line 164)
30267 * FUNCTION_DECL: Functions. (line 6)
30268 * FUNCTION_INCOMING_ARG: Register Arguments. (line 68)
30269 * FUNCTION_MODE: Misc. (line 323)
30270 * FUNCTION_OUTGOING_VALUE: Scalar Return. (line 36)
30271 * FUNCTION_PROFILER: Profiling. (line 9)
30272 * FUNCTION_TYPE: Types. (line 6)
30273 * FUNCTION_VALUE: Scalar Return. (line 10)
30274 * FUNCTION_VALUE_REGNO_P: Scalar Return. (line 70)
30275 * functions, leaf: Leaf Functions. (line 6)
30276 * fundamental type: Types. (line 6)
30277 * g in constraint: Simple Constraints. (line 108)
30278 * G in constraint: Simple Constraints. (line 86)
30279 * GCC and portability: Portability. (line 6)
30280 * GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36)
30281 * gcov_type: Profile information.
30283 * ge: Comparisons. (line 72)
30284 * ge and attributes: Expressions. (line 64)
30285 * GE_EXPR: Expression trees. (line 6)
30286 * GEN_ERRNO_RTX: Library Calls. (line 71)
30287 * gencodes: RTL passes. (line 18)
30288 * general_operand: Machine-Independent Predicates.
30290 * GENERAL_REGS: Register Classes. (line 23)
30291 * generated files: Files. (line 6)
30292 * generating assembler output: Output Statement. (line 6)
30293 * generating insns: RTL Template. (line 6)
30294 * GENERIC <1>: GENERIC. (line 6)
30295 * GENERIC <2>: Gimplification pass.
30297 * GENERIC: Parsing pass. (line 6)
30298 * generic predicates: Machine-Independent Predicates.
30300 * genflags: RTL passes. (line 18)
30301 * get_attr: Expressions. (line 80)
30302 * get_attr_length: Insn Lengths. (line 46)
30303 * GET_CLASS_NARROWEST_MODE: Machine Modes. (line 219)
30304 * GET_CODE: RTL Objects. (line 47)
30305 * get_frame_size: Elimination. (line 31)
30306 * get_insns: Insns. (line 34)
30307 * get_last_insn: Insns. (line 34)
30308 * GET_MODE: Machine Modes. (line 174)
30309 * GET_MODE_ALIGNMENT: Machine Modes. (line 206)
30310 * GET_MODE_BITSIZE: Machine Modes. (line 198)
30311 * GET_MODE_CLASS: Machine Modes. (line 188)
30312 * GET_MODE_MASK: Machine Modes. (line 201)
30313 * GET_MODE_NAME: Machine Modes. (line 185)
30314 * GET_MODE_NUNITS: Machine Modes. (line 215)
30315 * GET_MODE_SIZE: Machine Modes. (line 195)
30316 * GET_MODE_UNIT_SIZE: Machine Modes. (line 209)
30317 * GET_MODE_WIDER_MODE: Machine Modes. (line 191)
30318 * GET_RTX_CLASS: RTL Classes. (line 6)
30319 * GET_RTX_FORMAT: RTL Classes. (line 130)
30320 * GET_RTX_LENGTH: RTL Classes. (line 127)
30321 * geu: Comparisons. (line 72)
30322 * geu and attributes: Expressions. (line 64)
30323 * GGC: Type Information. (line 6)
30324 * GIMPLE <1>: GIMPLE. (line 6)
30325 * GIMPLE <2>: Gimplification pass.
30327 * GIMPLE: Parsing pass. (line 14)
30328 * GIMPLE Example: GIMPLE Example. (line 6)
30329 * GIMPLE Exception Handling: GIMPLE Exception Handling.
30331 * GIMPLE Expressions: GIMPLE Expressions. (line 6)
30332 * gimplification <1>: Interfaces. (line 6)
30333 * gimplification <2>: Gimplification pass.
30335 * gimplification: Parsing pass. (line 14)
30336 * gimplifier: Parsing pass. (line 14)
30337 * gimplify_expr: Gimplification pass.
30339 * gimplify_function_tree: Gimplification pass.
30341 * GLOBAL_INIT_PRIORITY: Function Basics. (line 6)
30342 * global_live_at_start, global_live_at_end: Liveness information.
30344 * global_regs: Register Basics. (line 59)
30345 * GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 48)
30346 * GO_IF_MODE_DEPENDENT_ADDRESS: Addressing Modes. (line 217)
30347 * GOFAST, floating point emulation library: Library Calls. (line 44)
30348 * gofast_maybe_init_libfuncs: Library Calls. (line 44)
30349 * greater than: Comparisons. (line 60)
30350 * gt: Comparisons. (line 60)
30351 * gt and attributes: Expressions. (line 64)
30352 * GT_EXPR: Expression trees. (line 6)
30353 * gtu: Comparisons. (line 64)
30354 * gtu and attributes: Expressions. (line 64)
30355 * GTY: Type Information. (line 6)
30356 * H in constraint: Simple Constraints. (line 86)
30357 * HANDLE_PRAGMA_PACK_PUSH_POP: Misc. (line 432)
30358 * HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 443)
30359 * HANDLE_SYSV_PRAGMA: Misc. (line 403)
30360 * HANDLER: Function Bodies. (line 6)
30361 * HANDLER_BODY: Function Bodies. (line 6)
30362 * HANDLER_PARMS: Function Bodies. (line 6)
30363 * hard registers: Regs and Memory. (line 9)
30364 * HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 20)
30365 * HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 53)
30366 * HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 20)
30367 * HARD_REGNO_MODE_OK: Values in Registers.
30369 * HARD_REGNO_NREGS: Values in Registers.
30371 * HARD_REGNO_RENAME_OK: Values in Registers.
30373 * HAS_INIT_SECTION: Macros for Initialization.
30375 * HAS_LONG_COND_BRANCH: Misc. (line 9)
30376 * HAS_LONG_UNCOND_BRANCH: Misc. (line 18)
30377 * HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11)
30378 * HAVE_POST_DECREMENT: Addressing Modes. (line 12)
30379 * HAVE_POST_INCREMENT: Addressing Modes. (line 11)
30380 * HAVE_POST_MODIFY_DISP: Addressing Modes. (line 18)
30381 * HAVE_POST_MODIFY_REG: Addressing Modes. (line 24)
30382 * HAVE_PRE_DECREMENT: Addressing Modes. (line 10)
30383 * HAVE_PRE_INCREMENT: Addressing Modes. (line 9)
30384 * HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 17)
30385 * HAVE_PRE_MODIFY_REG: Addressing Modes. (line 23)
30386 * HCmode: Machine Modes. (line 111)
30387 * HFmode: Machine Modes. (line 58)
30388 * high: Constants. (line 120)
30389 * HImode: Machine Modes. (line 29)
30390 * HImode, in insn: Insns. (line 242)
30391 * host configuration: Host Config. (line 6)
30392 * host functions: Host Common. (line 6)
30393 * host hooks: Host Common. (line 6)
30394 * host makefile fragment: Host Fragment. (line 6)
30395 * HOST_BIT_BUCKET: Filesystem. (line 51)
30396 * HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45)
30397 * HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 12)
30398 * HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 45)
30399 * HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 26)
30400 * HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89)
30401 * HOST_LONG_LONG_FORMAT: Host Misc. (line 46)
30402 * HOST_OBJECT_SUFFIX: Filesystem. (line 40)
30403 * HOT_TEXT_SECTION_NAME: Sections. (line 23)
30404 * I in constraint: Simple Constraints. (line 69)
30405 * i in constraint: Simple Constraints. (line 58)
30406 * IBM_FLOAT_FORMAT: Storage Layout. (line 396)
30407 * identifier: Identifiers. (line 6)
30408 * IDENTIFIER_LENGTH: Identifiers. (line 20)
30409 * IDENTIFIER_NODE: Identifiers. (line 6)
30410 * IDENTIFIER_OPNAME_P: Identifiers. (line 25)
30411 * IDENTIFIER_POINTER: Identifiers. (line 15)
30412 * IDENTIFIER_TYPENAME_P: Identifiers. (line 31)
30413 * IEEE_FLOAT_FORMAT: Storage Layout. (line 386)
30414 * IF_COND: Function Bodies. (line 6)
30415 * if_marked: GTY Options. (line 156)
30416 * IF_STMT: Function Bodies. (line 6)
30417 * if_then_else: Comparisons. (line 80)
30418 * if_then_else and attributes: Expressions. (line 32)
30419 * if_then_else usage: Side Effects. (line 56)
30420 * IFCVT_EXTRA_FIELDS: Misc. (line 584)
30421 * IFCVT_INIT_EXTRA_FIELDS: Misc. (line 579)
30422 * IFCVT_MODIFY_CANCEL: Misc. (line 573)
30423 * IFCVT_MODIFY_FINAL: Misc. (line 567)
30424 * IFCVT_MODIFY_INSN: Misc. (line 561)
30425 * IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 554)
30426 * IFCVT_MODIFY_TESTS: Misc. (line 543)
30427 * IMAGPART_EXPR: Expression trees. (line 6)
30428 * Immediate Uses: Statement Operands. (line 291)
30429 * immediate_operand: Machine-Independent Predicates.
30431 * IMMEDIATE_PREFIX: Instruction Output. (line 127)
30432 * in_data: Sections. (line 104)
30433 * in_struct: Flags. (line 244)
30434 * in_struct, in code_label and note: Flags. (line 49)
30435 * in_struct, in insn and jump_insn and call_insn: Flags. (line 34)
30436 * in_struct, in insn, jump_insn and call_insn: Flags. (line 156)
30437 * in_struct, in label_ref: Flags. (line 44)
30438 * in_struct, in mem: Flags. (line 60)
30439 * in_struct, in subreg: Flags. (line 195)
30440 * in_text: Sections. (line 104)
30441 * include: Including Patterns. (line 6)
30442 * INCLUDE_DEFAULTS: Driver. (line 430)
30443 * inclusive-or, bitwise: Arithmetic. (line 141)
30444 * INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 171)
30445 * INCOMING_REGNO: Register Basics. (line 91)
30446 * INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 131)
30447 * INDEX_REG_CLASS: Register Classes. (line 125)
30448 * indirect_jump instruction pattern: Standard Names. (line 835)
30449 * indirect_operand: Machine-Independent Predicates.
30451 * INDIRECT_REF: Expression trees. (line 6)
30452 * INIT_ARRAY_SECTION_ASM_OP: Sections. (line 74)
30453 * INIT_CUMULATIVE_ARGS: Register Arguments. (line 141)
30454 * INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 169)
30455 * INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 162)
30456 * INIT_ENVIRONMENT: Driver. (line 369)
30457 * INIT_EXPANDERS: Per-Function Data. (line 39)
30458 * INIT_EXPR: Expression trees. (line 6)
30459 * init_machine_status: Per-Function Data. (line 45)
30460 * init_one_libfunc: Library Calls. (line 15)
30461 * INIT_SECTION_ASM_OP <1>: Macros for Initialization.
30463 * INIT_SECTION_ASM_OP: Sections. (line 62)
30464 * INITIAL_ELIMINATION_OFFSET: Elimination. (line 79)
30465 * INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 83)
30466 * INITIAL_FRAME_POINTER_OFFSET: Elimination. (line 32)
30467 * initialization routines: Initialization. (line 6)
30468 * INITIALIZE_TRAMPOLINE: Trampolines. (line 56)
30469 * inlining: Target Attributes. (line 86)
30470 * insert_insn_on_edge: Maintaining the CFG.
30472 * insn: Insns. (line 63)
30473 * insn and /f: Flags. (line 111)
30474 * insn and /i: Flags. (line 138)
30475 * insn and /j: Flags. (line 165)
30476 * insn and /s: Flags. (line 34)
30477 * insn and /u: Flags. (line 24)
30478 * insn and /v: Flags. (line 29)
30479 * insn attributes: Insn Attributes. (line 6)
30480 * insn canonicalization: Insn Canonicalizations.
30482 * insn includes: Including Patterns. (line 6)
30483 * insn lengths, computing: Insn Lengths. (line 6)
30484 * insn splitting: Insn Splitting. (line 6)
30485 * insn-attr.h: Defining Attributes.
30487 * INSN_ANNULLED_BRANCH_P: Flags. (line 24)
30488 * INSN_CODE: Insns. (line 268)
30489 * INSN_DELETED_P: Flags. (line 29)
30490 * INSN_FROM_TARGET_P: Flags. (line 34)
30491 * insn_list: Insns. (line 545)
30492 * insn_list and /i: Flags. (line 138)
30493 * INSN_REFERENCES_ARE_DELAYED: Misc. (line 482)
30494 * INSN_SETS_ARE_DELAYED: Misc. (line 471)
30495 * INSN_UID: Insns. (line 23)
30496 * insns: Insns. (line 6)
30497 * insns, generating: RTL Template. (line 6)
30498 * insns, recognizing: RTL Template. (line 6)
30499 * instruction attributes: Insn Attributes. (line 6)
30500 * instruction latency time: Processor pipeline description.
30502 * instruction patterns: Patterns. (line 6)
30503 * instruction splitting: Insn Splitting. (line 6)
30504 * insv instruction pattern: Standard Names. (line 637)
30505 * int: Run-time Target. (line 56)
30506 * INT_TYPE_SIZE: Type Layout. (line 12)
30507 * INTEGER_CST: Expression trees. (line 6)
30508 * INTEGER_TYPE: Types. (line 6)
30509 * integrated: Flags. (line 280)
30510 * integrated, in insn, call_insn, jump_insn, barrier, code_label, insn_list, const, and note: Flags.
30512 * integrated, in reg: Flags. (line 93)
30513 * integrated, in symbol_ref: Flags. (line 210)
30514 * Interdependence of Patterns: Dependent Patterns. (line 6)
30515 * interfacing to GCC output: Interface. (line 6)
30516 * interlock delays: Processor pipeline description.
30518 * intermediate representation lowering: Parsing pass. (line 14)
30519 * INTMAX_TYPE: Type Layout. (line 161)
30520 * introduction: Top. (line 6)
30521 * INVOKE__main: Macros for Initialization.
30523 * ior: Arithmetic. (line 141)
30524 * ior and attributes: Expressions. (line 50)
30525 * ior, canonicalization of: Insn Canonicalizations.
30527 * iorM3 instruction pattern: Standard Names. (line 193)
30528 * IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 120)
30529 * jump: Flags. (line 293)
30530 * jump instruction pattern: Standard Names. (line 726)
30531 * jump instruction patterns: Jump Patterns. (line 6)
30532 * jump instructions and set: Side Effects. (line 56)
30533 * jump, in call_insn: Flags. (line 169)
30534 * jump, in insn: Flags. (line 165)
30535 * jump, in mem: Flags. (line 69)
30536 * JUMP_ALIGN: Alignment Output. (line 9)
30537 * jump_insn: Insns. (line 73)
30538 * jump_insn and /f: Flags. (line 111)
30539 * jump_insn and /i: Flags. (line 138)
30540 * jump_insn and /s: Flags. (line 34)
30541 * jump_insn and /u: Flags. (line 24)
30542 * jump_insn and /v: Flags. (line 29)
30543 * JUMP_LABEL: Insns. (line 79)
30544 * JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 116)
30545 * Jumps: Jumps. (line 6)
30546 * LABEL_ALIGN: Alignment Output. (line 52)
30547 * LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 22)
30548 * LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output. (line 30)
30549 * LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 62)
30550 * LABEL_ALT_ENTRY_P: Insns. (line 145)
30551 * LABEL_ALTERNATE_NAME: Edges. (line 180)
30552 * LABEL_DECL: Declarations. (line 6)
30553 * LABEL_KIND: Insns. (line 145)
30554 * LABEL_NUSES: Insns. (line 141)
30555 * LABEL_OUTSIDE_LOOP_P: Flags. (line 44)
30556 * LABEL_PRESERVE_P: Flags. (line 49)
30557 * label_ref: Constants. (line 97)
30558 * label_ref and /s: Flags. (line 44)
30559 * label_ref and /v: Flags. (line 55)
30560 * label_ref, RTL sharing: Sharing. (line 35)
30561 * LABEL_REF_NONLOCAL_P: Flags. (line 55)
30562 * lang_hooks.gimplify_expr: Gimplification pass.
30564 * lang_hooks.parse_file: Parsing pass. (line 6)
30565 * language-independent intermediate representation: Parsing pass.
30567 * large return values: Aggregate Return. (line 6)
30568 * LARGEST_EXPONENT_IS_NORMAL: Storage Layout. (line 472)
30569 * LAST_STACK_REG: Stack Registers. (line 27)
30570 * LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51)
30571 * LD_FINI_SWITCH: Macros for Initialization.
30573 * LD_INIT_SWITCH: Macros for Initialization.
30575 * LDD_SUFFIX: Macros for Initialization.
30577 * le: Comparisons. (line 76)
30578 * le and attributes: Expressions. (line 64)
30579 * LE_EXPR: Expression trees. (line 6)
30580 * leaf functions: Leaf Functions. (line 6)
30581 * leaf_function_p: Standard Names. (line 797)
30582 * LEAF_REG_REMAP: Leaf Functions. (line 39)
30583 * LEAF_REGISTERS: Leaf Functions. (line 25)
30584 * left rotate: Arithmetic. (line 164)
30585 * left shift: Arithmetic. (line 151)
30586 * LEGITIMATE_CONSTANT_P: Addressing Modes. (line 232)
30587 * LEGITIMATE_PIC_OPERAND_P: PIC. (line 31)
30588 * LEGITIMIZE_ADDRESS: Addressing Modes. (line 149)
30589 * LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 172)
30590 * length: GTY Options. (line 50)
30591 * less than: Comparisons. (line 68)
30592 * less than or equal: Comparisons. (line 76)
30593 * leu: Comparisons. (line 76)
30594 * leu and attributes: Expressions. (line 64)
30595 * LIB2FUNCS_EXTRA: Target Fragment. (line 11)
30596 * LIB_SPEC: Driver. (line 170)
30597 * LIBCALL_VALUE: Scalar Return. (line 53)
30598 * libgcc.a: Library Calls. (line 6)
30599 * LIBGCC2_CFLAGS: Target Fragment. (line 8)
30600 * LIBGCC2_HAS_DF_MODE: Type Layout. (line 69)
30601 * LIBGCC2_HAS_TF_MODE: Type Layout. (line 83)
30602 * LIBGCC2_HAS_XF_MODE: Type Layout. (line 77)
30603 * LIBGCC2_LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 63)
30604 * LIBGCC2_WORDS_BIG_ENDIAN: Storage Layout. (line 36)
30605 * LIBGCC_SPEC: Driver. (line 178)
30606 * library subroutine names: Library Calls. (line 6)
30607 * LIBRARY_PATH_ENV: Misc. (line 522)
30608 * LIMIT_RELOAD_CLASS: Register Classes. (line 229)
30609 * LINK_COMMAND_SPEC: Driver. (line 299)
30610 * LINK_EH_SPEC: Driver. (line 205)
30611 * LINK_ELIMINATE_DUPLICATE_LDIRECTORIES: Driver. (line 309)
30612 * LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 295)
30613 * LINK_LIBGCC_SPECIAL_1: Driver. (line 290)
30614 * LINK_SPEC: Driver. (line 163)
30615 * linkage: Function Basics. (line 6)
30616 * list: Containers. (line 6)
30617 * Liveness representation: Liveness information.
30619 * lo_sum: Arithmetic. (line 24)
30620 * load address instruction: Simple Constraints. (line 152)
30621 * LOAD_EXTEND_OP: Misc. (line 69)
30622 * load_multiple instruction pattern: Standard Names. (line 136)
30623 * LOCAL_ALIGNMENT: Storage Layout. (line 225)
30624 * LOCAL_CLASS_P: Classes. (line 68)
30625 * LOCAL_INCLUDE_DIR: Driver. (line 376)
30626 * LOCAL_LABEL_PREFIX: Instruction Output. (line 125)
30627 * LOCAL_REGNO: Register Basics. (line 105)
30628 * LOG_LINKS: Insns. (line 287)
30629 * Logical Operators: Logical Operators. (line 6)
30630 * logical-and, bitwise: Arithmetic. (line 136)
30631 * logM2 instruction pattern: Standard Names. (line 327)
30632 * LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 58)
30633 * LONG_LONG_TYPE_SIZE: Type Layout. (line 33)
30634 * LONG_TYPE_SIZE: Type Layout. (line 22)
30635 * longjmp and automatic variables: Interface. (line 52)
30636 * LOOP_ALIGN: Alignment Output. (line 35)
30637 * LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 48)
30638 * LOOP_EXPR: Expression trees. (line 6)
30639 * looping instruction patterns: Looping Patterns. (line 6)
30640 * Loops: Loops. (line 6)
30641 * lowering, language-dependent intermediate representation: Parsing pass.
30643 * LSHIFT_EXPR: Expression trees. (line 6)
30644 * lshiftrt: Arithmetic. (line 159)
30645 * lshiftrt and attributes: Expressions. (line 64)
30646 * lshrM3 instruction pattern: Standard Names. (line 285)
30647 * lt: Comparisons. (line 68)
30648 * lt and attributes: Expressions. (line 64)
30649 * LT_EXPR: Expression trees. (line 6)
30650 * LTGT_EXPR: Expression trees. (line 6)
30651 * ltu: Comparisons. (line 68)
30652 * m in constraint: Simple Constraints. (line 17)
30653 * machine attributes: Target Attributes. (line 6)
30654 * machine description macros: Target Macros. (line 6)
30655 * machine descriptions: Machine Desc. (line 6)
30656 * machine mode conversions: Conversions. (line 6)
30657 * machine modes: Machine Modes. (line 6)
30658 * machine specific constraints: Machine Constraints.
30660 * machine-independent predicates: Machine-Independent Predicates.
30662 * machine_mode: Condition Code. (line 157)
30663 * macros in .md files: Macros. (line 6)
30664 * macros, target description: Target Macros. (line 6)
30665 * MAKE_DECL_ONE_ONLY: Label Output. (line 209)
30666 * make_safe_from: Expander Definitions.
30668 * makefile fragment: Fragments. (line 6)
30669 * makefile targets: Makefile. (line 6)
30670 * marking roots: GGC Roots. (line 6)
30671 * MASK_RETURN_ADDR: Exception Region Output.
30673 * match_dup <1>: define_peephole2. (line 28)
30674 * match_dup: RTL Template. (line 73)
30675 * match_dup and attributes: Insn Lengths. (line 16)
30676 * match_op_dup: RTL Template. (line 163)
30677 * match_operand: RTL Template. (line 16)
30678 * match_operand and attributes: Expressions. (line 55)
30679 * match_operator: RTL Template. (line 95)
30680 * match_par_dup: RTL Template. (line 219)
30681 * match_parallel: RTL Template. (line 172)
30682 * match_scratch <1>: define_peephole2. (line 28)
30683 * match_scratch: RTL Template. (line 58)
30684 * matching constraint: Simple Constraints. (line 130)
30685 * matching operands: Output Template. (line 49)
30686 * math library: Soft float library routines.
30688 * math, in RTL: Arithmetic. (line 6)
30689 * MATH_LIBRARY: Misc. (line 515)
30690 * matherr: Library Calls. (line 58)
30691 * MAX_BITS_PER_WORD: Storage Layout. (line 61)
30692 * MAX_CONDITIONAL_EXECUTE: Misc. (line 537)
30693 * MAX_DFA_ISSUE_RATE: Scheduling. (line 235)
30694 * MAX_FIXED_MODE_SIZE: Storage Layout. (line 355)
30695 * MAX_MOVE_MAX: Misc. (line 120)
30696 * MAX_OFILE_ALIGNMENT: Storage Layout. (line 193)
30697 * MAX_REGS_PER_ADDRESS: Addressing Modes. (line 42)
30698 * maxM3 instruction pattern: Standard Names. (line 200)
30699 * may_trap_p, tree_could_trap_p: Edges. (line 115)
30700 * maybe_undef: GTY Options. (line 171)
30701 * mcount: Profiling. (line 12)
30702 * MD_CAN_REDIRECT_BRANCH: Misc. (line 662)
30703 * MD_EXEC_PREFIX: Driver. (line 330)
30704 * MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 98)
30705 * MD_HANDLE_UNWABI: Exception Handling. (line 117)
30706 * MD_STARTFILE_PREFIX: Driver. (line 358)
30707 * MD_STARTFILE_PREFIX_1: Driver. (line 364)
30708 * MD_UNWIND_SUPPORT: Exception Handling. (line 94)
30709 * mem: Regs and Memory. (line 249)
30710 * mem and /c: Flags. (line 89)
30711 * mem and /f: Flags. (line 75)
30712 * mem and /j: Flags. (line 69)
30713 * mem and /s: Flags. (line 60)
30714 * mem and /u: Flags. (line 142)
30715 * mem and /v: Flags. (line 84)
30716 * mem, RTL sharing: Sharing. (line 40)
30717 * MEM_ALIAS_SET: Special Accessors. (line 9)
30718 * MEM_ALIGN: Special Accessors. (line 36)
30719 * MEM_EXPR: Special Accessors. (line 20)
30720 * MEM_IN_STRUCT_P: Flags. (line 60)
30721 * MEM_KEEP_ALIAS_SET_P: Flags. (line 69)
30722 * MEM_NOTRAP_P: Flags. (line 89)
30723 * MEM_OFFSET: Special Accessors. (line 28)
30724 * MEM_READONLY_P: Flags. (line 142)
30725 * MEM_SCALAR_P: Flags. (line 75)
30726 * MEM_SIZE: Special Accessors. (line 31)
30727 * MEM_VOLATILE_P: Flags. (line 84)
30728 * MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 333)
30729 * memory reference, nonoffsettable: Simple Constraints. (line 251)
30730 * memory references in constraints: Simple Constraints. (line 17)
30731 * memory_barrier instruction pattern: Standard Names. (line 1165)
30732 * MEMORY_MOVE_COST: Costs. (line 29)
30733 * memory_operand: Machine-Independent Predicates.
30735 * METHOD_TYPE: Types. (line 6)
30736 * MIN_UNITS_PER_WORD: Storage Layout. (line 71)
30737 * MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 171)
30738 * minM3 instruction pattern: Standard Names. (line 200)
30739 * minus: Arithmetic. (line 36)
30740 * minus and attributes: Expressions. (line 64)
30741 * minus, canonicalization of: Insn Canonicalizations.
30743 * MINUS_EXPR: Expression trees. (line 6)
30744 * MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6)
30745 * mod: Arithmetic. (line 114)
30746 * mod and attributes: Expressions. (line 64)
30747 * mode classes: Machine Modes. (line 133)
30748 * mode macros in .md files: Mode Macros. (line 6)
30749 * mode switching: Mode Switching. (line 6)
30750 * MODE_AFTER: Mode Switching. (line 49)
30751 * MODE_BASE_REG_CLASS: Register Classes. (line 112)
30752 * MODE_BASE_REG_REG_CLASS: Register Classes. (line 118)
30753 * MODE_CC: Machine Modes. (line 162)
30754 * MODE_COMPLEX_FLOAT: Machine Modes. (line 154)
30755 * MODE_COMPLEX_INT: Machine Modes. (line 151)
30756 * MODE_ENTRY: Mode Switching. (line 54)
30757 * MODE_EXIT: Mode Switching. (line 60)
30758 * MODE_FLOAT: Machine Modes. (line 147)
30759 * MODE_FUNCTION: Machine Modes. (line 158)
30760 * MODE_HAS_INFINITIES: Storage Layout. (line 420)
30761 * MODE_HAS_NANS: Storage Layout. (line 410)
30762 * MODE_HAS_SIGN_DEPENDENT_ROUNDING: Storage Layout. (line 442)
30763 * MODE_HAS_SIGNED_ZEROS: Storage Layout. (line 426)
30764 * MODE_INT: Machine Modes. (line 139)
30765 * MODE_NEEDED: Mode Switching. (line 42)
30766 * MODE_PARTIAL_INT: Machine Modes. (line 143)
30767 * MODE_PRIORITY_TO_MODE: Mode Switching. (line 66)
30768 * MODE_RANDOM: Machine Modes. (line 167)
30769 * MODES_TIEABLE_P: Values in Registers.
30771 * modifiers in constraints: Modifiers. (line 6)
30772 * MODIFY_EXPR: Expression trees. (line 6)
30773 * MODIFY_JNI_METHOD_CALL: Misc. (line 713)
30774 * MODIFY_TARGET_NAME: Driver. (line 385)
30775 * modM3 instruction pattern: Standard Names. (line 193)
30776 * modulo scheduling: RTL passes. (line 136)
30777 * MOVE_BY_PIECES_P: Costs. (line 104)
30778 * MOVE_MAX: Misc. (line 115)
30779 * MOVE_MAX_PIECES: Costs. (line 110)
30780 * MOVE_RATIO: Costs. (line 91)
30781 * movM instruction pattern: Standard Names. (line 11)
30782 * movmemM instruction pattern: Standard Names. (line 470)
30783 * movmisalignM instruction pattern: Standard Names. (line 125)
30784 * movMODEcc instruction pattern: Standard Names. (line 648)
30785 * movstr instruction pattern: Standard Names. (line 498)
30786 * movstrictM instruction pattern: Standard Names. (line 119)
30787 * mulhisi3 instruction pattern: Standard Names. (line 236)
30788 * mulM3 instruction pattern: Standard Names. (line 193)
30789 * mulqihi3 instruction pattern: Standard Names. (line 240)
30790 * mulsidi3 instruction pattern: Standard Names. (line 240)
30791 * mult: Arithmetic. (line 85)
30792 * mult and attributes: Expressions. (line 64)
30793 * mult, canonicalization of: Insn Canonicalizations.
30795 * MULT_EXPR: Expression trees. (line 6)
30796 * MULTILIB_DEFAULTS: Driver. (line 315)
30797 * MULTILIB_DIRNAMES: Target Fragment. (line 64)
30798 * MULTILIB_EXCEPTIONS: Target Fragment. (line 84)
30799 * MULTILIB_EXTRA_OPTS: Target Fragment. (line 96)
30800 * MULTILIB_MATCHES: Target Fragment. (line 77)
30801 * MULTILIB_OPTIONS: Target Fragment. (line 44)
30802 * multiple alternative constraints: Multi-Alternative. (line 6)
30803 * MULTIPLE_SYMBOL_SPACES: Misc. (line 495)
30804 * multiplication: Arithmetic. (line 85)
30805 * MUST_USE_SJLJ_EXCEPTIONS: Exception Region Output.
30807 * n in constraint: Simple Constraints. (line 63)
30808 * N_REG_CLASSES: Register Classes. (line 76)
30809 * name: Identifiers. (line 6)
30810 * named patterns and conditions: Patterns. (line 47)
30811 * names, pattern: Standard Names. (line 6)
30812 * namespace: Namespaces. (line 6)
30813 * namespace, class, scope: Scopes. (line 6)
30814 * NAMESPACE_DECL <1>: Declarations. (line 6)
30815 * NAMESPACE_DECL: Namespaces. (line 6)
30816 * NATIVE_SYSTEM_HEADER_DIR: Target Fragment. (line 103)
30817 * ne: Comparisons. (line 56)
30818 * ne and attributes: Expressions. (line 64)
30819 * NE_EXPR: Expression trees. (line 6)
30820 * nearbyintM2 instruction pattern: Standard Names. (line 386)
30821 * neg: Arithmetic. (line 81)
30822 * neg and attributes: Expressions. (line 64)
30823 * neg, canonicalization of: Insn Canonicalizations.
30825 * NEGATE_EXPR: Expression trees. (line 6)
30826 * negM2 instruction pattern: Standard Names. (line 289)
30827 * nested functions, trampolines for: Trampolines. (line 6)
30828 * nested_ptr: GTY Options. (line 178)
30829 * next_bb, prev_bb, FOR_EACH_BB: Basic Blocks. (line 10)
30830 * next_cc0_user: Jump Patterns. (line 64)
30831 * NEXT_INSN: Insns. (line 30)
30832 * NEXT_OBJC_RUNTIME: Library Calls. (line 85)
30833 * nil: RTL Objects. (line 73)
30834 * NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 39)
30835 * NO_DBX_FUNCTION_END: DBX Hooks. (line 33)
30836 * NO_DBX_GCC_MARKER: File Names and DBX. (line 28)
30837 * NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 23)
30838 * NO_DOLLAR_IN_LABEL: Misc. (line 459)
30839 * NO_DOT_IN_LABEL: Misc. (line 465)
30840 * NO_FUNCTION_CSE: Costs. (line 178)
30841 * NO_IMPLICIT_EXTERN_C: Misc. (line 339)
30842 * no_new_pseudos: Standard Names. (line 77)
30843 * NO_PROFILE_COUNTERS: Profiling. (line 28)
30844 * NO_REGS: Register Classes. (line 17)
30845 * NON_LVALUE_EXPR: Expression trees. (line 6)
30846 * nondeterministic finite state automaton: Processor pipeline description.
30848 * nonimmediate_operand: Machine-Independent Predicates.
30850 * nonlocal goto handler: Edges. (line 171)
30851 * nonlocal_goto instruction pattern: Standard Names. (line 1012)
30852 * nonlocal_goto_receiver instruction pattern: Standard Names.
30854 * nonmemory_operand: Machine-Independent Predicates.
30856 * nonoffsettable memory reference: Simple Constraints. (line 251)
30857 * nop instruction pattern: Standard Names. (line 830)
30858 * NOP_EXPR: Expression trees. (line 6)
30859 * normal predicates: Predicates. (line 31)
30860 * not: Arithmetic. (line 132)
30861 * not and attributes: Expressions. (line 50)
30862 * not equal: Comparisons. (line 56)
30863 * not, canonicalization of: Insn Canonicalizations.
30865 * note: Insns. (line 173)
30866 * note and /i: Flags. (line 49)
30867 * note and /v: Flags. (line 29)
30868 * NOTE_INSN_BASIC_BLOCK, CODE_LABEL, notes: Basic Blocks. (line 41)
30869 * NOTE_INSN_BLOCK_BEG: Insns. (line 198)
30870 * NOTE_INSN_BLOCK_END: Insns. (line 198)
30871 * NOTE_INSN_DELETED: Insns. (line 188)
30872 * NOTE_INSN_DELETED_LABEL: Insns. (line 193)
30873 * NOTE_INSN_EH_REGION_BEG: Insns. (line 204)
30874 * NOTE_INSN_EH_REGION_END: Insns. (line 204)
30875 * NOTE_INSN_FUNCTION_BEG: Insns. (line 228)
30876 * NOTE_INSN_FUNCTION_END: Insns. (line 232)
30877 * NOTE_INSN_LOOP_BEG: Insns. (line 212)
30878 * NOTE_INSN_LOOP_CONT: Insns. (line 218)
30879 * NOTE_INSN_LOOP_END: Insns. (line 212)
30880 * NOTE_INSN_LOOP_VTOP: Insns. (line 222)
30881 * NOTE_LINE_NUMBER: Insns. (line 173)
30882 * NOTE_SOURCE_FILE: Insns. (line 173)
30883 * NOTICE_UPDATE_CC: Condition Code. (line 33)
30884 * NUM_MACHINE_MODES: Machine Modes. (line 180)
30885 * NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30)
30886 * o in constraint: Simple Constraints. (line 21)
30887 * OBJC_GEN_METHOD_LABEL: Label Output. (line 402)
30888 * OBJECT_FORMAT_COFF: Macros for Initialization.
30890 * OFFSET_TYPE: Types. (line 6)
30891 * offsettable address: Simple Constraints. (line 21)
30892 * OImode: Machine Modes. (line 51)
30893 * one_cmplM2 instruction pattern: Standard Names. (line 449)
30894 * operand access: Accessors. (line 6)
30895 * Operand Access Routines: Statement Operands. (line 119)
30896 * operand constraints: Constraints. (line 6)
30897 * Operand Iterators: Statement Operands. (line 119)
30898 * operand predicates: Predicates. (line 6)
30899 * operand substitution: Output Template. (line 6)
30900 * operands <1>: Patterns. (line 53)
30901 * operands: Statement Operands. (line 6)
30902 * operator predicates: Predicates. (line 6)
30903 * Optimization infrastructure for GIMPLE: Tree SSA. (line 6)
30904 * OPTIMIZATION_OPTIONS: Run-time Target. (line 100)
30905 * OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 9)
30906 * option specification files: Options. (line 6)
30907 * OPTION_DEFAULT_SPECS: Driver. (line 88)
30908 * optional hardware or system features: Run-time Target. (line 59)
30909 * options, directory search: Including Patterns. (line 44)
30910 * opts.sh: Options. (line 6)
30911 * order of register allocation: Allocation Order. (line 6)
30912 * ORDER_REGS_FOR_LOCAL_ALLOC: Allocation Order. (line 23)
30913 * ORDERED_EXPR: Expression trees. (line 6)
30914 * Ordering of Patterns: Pattern Ordering. (line 6)
30915 * ORIGINAL_REGNO: Special Accessors. (line 40)
30916 * other register constraints: Simple Constraints. (line 161)
30917 * OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 70)
30918 * OUTGOING_REGNO: Register Basics. (line 98)
30919 * output of assembler code: File Framework. (line 6)
30920 * output statements: Output Statement. (line 6)
30921 * output templates: Output Template. (line 6)
30922 * OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 39)
30923 * output_asm_insn: Output Statement. (line 53)
30924 * OUTPUT_QUOTED_STRING: File Framework. (line 76)
30925 * OVERLOAD: Functions. (line 6)
30926 * OVERRIDE_OPTIONS: Run-time Target. (line 90)
30927 * OVL_CURRENT: Functions. (line 6)
30928 * OVL_NEXT: Functions. (line 6)
30929 * p in constraint: Simple Constraints. (line 152)
30930 * PAD_VARARGS_DOWN: Register Arguments. (line 206)
30931 * parallel: Side Effects. (line 201)
30932 * param_is: GTY Options. (line 114)
30933 * parameters, c++ abi: C++ ABI. (line 6)
30934 * parameters, miscellaneous: Misc. (line 6)
30935 * parameters, precompiled headers: PCH Target. (line 6)
30936 * paramN_is: GTY Options. (line 132)
30937 * parity: Arithmetic. (line 202)
30938 * parityM2 instruction pattern: Standard Names. (line 443)
30939 * PARM_BOUNDARY: Storage Layout. (line 143)
30940 * PARM_DECL: Declarations. (line 6)
30941 * PARSE_LDD_OUTPUT: Macros for Initialization.
30943 * passes and files of the compiler: Passes. (line 6)
30944 * passing arguments: Interface. (line 36)
30945 * PATH_SEPARATOR: Filesystem. (line 31)
30946 * PATTERN: Insns. (line 258)
30947 * pattern conditions: Patterns. (line 43)
30948 * pattern names: Standard Names. (line 6)
30949 * Pattern Ordering: Pattern Ordering. (line 6)
30950 * patterns: Patterns. (line 6)
30951 * pc: Regs and Memory. (line 236)
30952 * pc and attributes: Insn Lengths. (line 20)
30953 * pc, RTL sharing: Sharing. (line 25)
30954 * PC_REGNUM: Register Basics. (line 112)
30955 * pc_rtx: Regs and Memory. (line 241)
30956 * PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 255)
30957 * PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 61)
30958 * PDImode: Machine Modes. (line 40)
30959 * peephole optimization, RTL representation: Side Effects. (line 235)
30960 * peephole optimizer definitions: Peephole Definitions.
30962 * per-function data: Per-Function Data. (line 6)
30963 * percent sign: Output Template. (line 6)
30964 * PHI_ARG_DEF: SSA. (line 71)
30965 * PHI_ARG_EDGE: SSA. (line 68)
30966 * PHI_ARG_ELT: SSA. (line 63)
30967 * PHI_NUM_ARGS: SSA. (line 59)
30968 * PHI_RESULT: SSA. (line 56)
30969 * PIC: PIC. (line 6)
30970 * PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 26)
30971 * PIC_OFFSET_TABLE_REGNUM: PIC. (line 16)
30972 * pipeline hazard recognizer: Processor pipeline description.
30974 * plus: Arithmetic. (line 14)
30975 * plus and attributes: Expressions. (line 64)
30976 * plus, canonicalization of: Insn Canonicalizations.
30978 * PLUS_EXPR: Expression trees. (line 6)
30979 * Pmode: Misc. (line 311)
30980 * pmode_register_operand: Machine-Independent Predicates.
30982 * pointer: Types. (line 6)
30983 * POINTER_SIZE: Storage Layout. (line 83)
30984 * POINTER_TYPE: Types. (line 6)
30985 * POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 89)
30986 * pop_operand: Machine-Independent Predicates.
30988 * popcount: Arithmetic. (line 198)
30989 * popcountM2 instruction pattern: Standard Names. (line 437)
30990 * portability: Portability. (line 6)
30991 * position independent code: PIC. (line 6)
30992 * post_dec: Incdec. (line 25)
30993 * post_inc: Incdec. (line 30)
30994 * post_modify: Incdec. (line 33)
30995 * POSTDECREMENT_EXPR: Expression trees. (line 6)
30996 * POSTINCREMENT_EXPR: Expression trees. (line 6)
30997 * POWI_MAX_MULTS: Misc. (line 761)
30998 * powM3 instruction pattern: Standard Names. (line 335)
30999 * pragma: Misc. (line 344)
31000 * pre_dec: Incdec. (line 8)
31001 * PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 110)
31002 * pre_inc: Incdec. (line 22)
31003 * pre_modify: Incdec. (line 51)
31004 * PREDECREMENT_EXPR: Expression trees. (line 6)
31005 * predefined macros: Run-time Target. (line 6)
31006 * predicates: Predicates. (line 6)
31007 * predicates and machine modes: Predicates. (line 31)
31008 * predication: Conditional Execution.
31010 * predict.def: Profile information.
31012 * PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 42)
31013 * PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 224)
31014 * PREFERRED_RELOAD_CLASS: Register Classes. (line 197)
31015 * PREFERRED_STACK_BOUNDARY: Storage Layout. (line 157)
31016 * prefetch: Side Effects. (line 309)
31017 * prefetch instruction pattern: Standard Names. (line 1149)
31018 * PREINCREMENT_EXPR: Expression trees. (line 6)
31019 * presence_set: Processor pipeline description.
31021 * preserving SSA form: SSA. (line 76)
31022 * prev_active_insn: define_peephole. (line 60)
31023 * prev_cc0_setter: Jump Patterns. (line 64)
31024 * PREV_INSN: Insns. (line 26)
31025 * PRINT_OPERAND: Instruction Output. (line 68)
31026 * PRINT_OPERAND_ADDRESS: Instruction Output. (line 96)
31027 * PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 89)
31028 * processor functional units: Processor pipeline description.
31030 * processor pipeline description: Processor pipeline description.
31032 * product: Arithmetic. (line 85)
31033 * profile feedback: Profile information.
31035 * profile representation: Profile information.
31037 * PROFILE_BEFORE_PROLOGUE: Profiling. (line 35)
31038 * PROFILE_HOOK: Profiling. (line 23)
31039 * profiling, code generation: Profiling. (line 6)
31040 * program counter: Regs and Memory. (line 237)
31041 * prologue: Function Entry. (line 6)
31042 * prologue instruction pattern: Standard Names. (line 1095)
31043 * PROMOTE_FUNCTION_MODE: Storage Layout. (line 122)
31044 * PROMOTE_MODE: Storage Layout. (line 99)
31045 * pseudo registers: Regs and Memory. (line 9)
31046 * PSImode: Machine Modes. (line 32)
31047 * PTRDIFF_TYPE: Type Layout. (line 132)
31048 * PTRMEM_CST: Expression trees. (line 6)
31049 * PTRMEM_CST_CLASS: Expression trees. (line 6)
31050 * PTRMEM_CST_MEMBER: Expression trees. (line 6)
31051 * purge_dead_edges <1>: Maintaining the CFG.
31053 * purge_dead_edges: Edges. (line 104)
31054 * push address instruction: Simple Constraints. (line 152)
31055 * PUSH_ARGS: Stack Arguments. (line 18)
31056 * PUSH_ARGS_REVERSED: Stack Arguments. (line 26)
31057 * push_operand: Machine-Independent Predicates.
31059 * push_reload: Addressing Modes. (line 196)
31060 * PUSH_ROUNDING: Stack Arguments. (line 32)
31061 * pushM1 instruction pattern: Standard Names. (line 180)
31062 * PUT_CODE: RTL Objects. (line 47)
31063 * PUT_MODE: Machine Modes. (line 177)
31064 * PUT_REG_NOTE_KIND: Insns. (line 324)
31065 * PUT_SDB_: SDB and DWARF. (line 62)
31066 * QCmode: Machine Modes. (line 111)
31067 * QFmode: Machine Modes. (line 54)
31068 * QImode: Machine Modes. (line 25)
31069 * QImode, in insn: Insns. (line 242)
31070 * qualified type: Types. (line 6)
31071 * querying function unit reservations: Processor pipeline description.
31073 * question mark: Multi-Alternative. (line 41)
31074 * quotient: Arithmetic. (line 100)
31075 * r in constraint: Simple Constraints. (line 54)
31076 * RANGE_TEST_NON_SHORT_CIRCUIT: Costs. (line 182)
31077 * RDIV_EXPR: Expression trees. (line 6)
31078 * READONLY_DATA_SECTION: Sections. (line 43)
31079 * READONLY_DATA_SECTION_ASM_OP: Sections. (line 38)
31080 * real operands: Statement Operands. (line 6)
31081 * REAL_ARITHMETIC: Floating Point. (line 66)
31082 * REAL_CST: Expression trees. (line 6)
31083 * REAL_LIBGCC_SPEC: Driver. (line 187)
31084 * REAL_NM_FILE_NAME: Macros for Initialization.
31086 * REAL_TYPE: Types. (line 6)
31087 * REAL_VALUE_ABS: Floating Point. (line 82)
31088 * REAL_VALUE_ATOF: Floating Point. (line 50)
31089 * REAL_VALUE_FIX: Floating Point. (line 41)
31090 * REAL_VALUE_FROM_INT: Floating Point. (line 99)
31091 * REAL_VALUE_ISINF: Floating Point. (line 59)
31092 * REAL_VALUE_ISNAN: Floating Point. (line 62)
31093 * REAL_VALUE_NEGATE: Floating Point. (line 79)
31094 * REAL_VALUE_NEGATIVE: Floating Point. (line 56)
31095 * REAL_VALUE_TO_INT: Floating Point. (line 93)
31096 * REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 138)
31097 * REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 139)
31098 * REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 137)
31099 * REAL_VALUE_TRUNCATE: Floating Point. (line 86)
31100 * REAL_VALUE_TYPE: Floating Point. (line 26)
31101 * REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 45)
31102 * REAL_VALUES_EQUAL: Floating Point. (line 32)
31103 * REAL_VALUES_LESS: Floating Point. (line 38)
31104 * REALPART_EXPR: Expression trees. (line 6)
31105 * recog_data.operand: Instruction Output. (line 39)
31106 * recognizing insns: RTL Template. (line 6)
31107 * RECORD_TYPE <1>: Classes. (line 6)
31108 * RECORD_TYPE: Types. (line 6)
31109 * redirect_edge_and_branch: Profile information.
31111 * redirect_edge_and_branch, redirect_jump: Maintaining the CFG.
31113 * reduc_smax_M instruction pattern: Standard Names. (line 206)
31114 * reduc_smin_M instruction pattern: Standard Names. (line 206)
31115 * reduc_splus_M instruction pattern: Standard Names. (line 218)
31116 * reduc_umax_M instruction pattern: Standard Names. (line 212)
31117 * reduc_umin_M instruction pattern: Standard Names. (line 212)
31118 * reduc_uplus_M instruction pattern: Standard Names. (line 224)
31119 * reference: Types. (line 6)
31120 * REFERENCE_TYPE: Types. (line 6)
31121 * reg: Regs and Memory. (line 9)
31122 * reg and /f: Flags. (line 98)
31123 * reg and /i: Flags. (line 93)
31124 * reg and /v: Flags. (line 102)
31125 * reg, RTL sharing: Sharing. (line 17)
31126 * REG_ALLOC_ORDER: Allocation Order. (line 9)
31127 * REG_BR_PRED: Insns. (line 531)
31128 * REG_BR_PROB: Insns. (line 525)
31129 * REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information.
31131 * REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information.
31133 * REG_CC_SETTER: Insns. (line 500)
31134 * REG_CC_USER: Insns. (line 500)
31135 * REG_CLASS_CONTENTS: Register Classes. (line 86)
31136 * reg_class_contents: Register Basics. (line 59)
31137 * REG_CLASS_FROM_CONSTRAINT: Register Classes. (line 154)
31138 * REG_CLASS_FROM_LETTER: Register Classes. (line 146)
31139 * REG_CLASS_NAMES: Register Classes. (line 81)
31140 * REG_CROSSING_JUMP: Insns. (line 389)
31141 * REG_DEAD: Insns. (line 335)
31142 * REG_DEAD, REG_UNUSED: Liveness information.
31144 * REG_DEP_ANTI: Insns. (line 515)
31145 * REG_DEP_OUTPUT: Insns. (line 518)
31146 * REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 110)
31147 * REG_EQUAL: Insns. (line 405)
31148 * REG_EQUIV: Insns. (line 405)
31149 * REG_EXPR: Special Accessors. (line 46)
31150 * REG_FRAME_RELATED_EXPR: Insns. (line 537)
31151 * REG_FUNCTION_VALUE_P: Flags. (line 93)
31152 * REG_INC: Insns. (line 351)
31153 * REG_LABEL: Insns. (line 381)
31154 * reg_label and /v: Flags. (line 55)
31155 * REG_LIBCALL: Insns. (line 493)
31156 * REG_MODE_OK_FOR_BASE_P: Addressing Modes. (line 109)
31157 * REG_MODE_OK_FOR_REG_BASE_P: Addressing Modes. (line 117)
31158 * reg_names <1>: Instruction Output. (line 80)
31159 * reg_names: Register Basics. (line 59)
31160 * REG_NO_CONFLICT: Insns. (line 365)
31161 * REG_NONNEG: Insns. (line 357)
31162 * REG_NOTE_KIND: Insns. (line 324)
31163 * REG_NOTES: Insns. (line 292)
31164 * REG_OFFSET: Special Accessors. (line 50)
31165 * REG_OK_FOR_BASE_P: Addressing Modes. (line 100)
31166 * REG_OK_FOR_INDEX_P: Addressing Modes. (line 126)
31167 * REG_OK_STRICT: Addressing Modes. (line 67)
31168 * REG_PARM_STACK_SPACE: Stack Arguments. (line 56)
31169 * REG_PARM_STACK_SPACE, and FUNCTION_ARG: Register Arguments.
31171 * REG_POINTER: Flags. (line 98)
31172 * REG_RETVAL: Insns. (line 477)
31173 * REG_SETJMP: Insns. (line 399)
31174 * REG_UNUSED: Insns. (line 344)
31175 * REG_USERVAR_P: Flags. (line 102)
31176 * register allocation order: Allocation Order. (line 6)
31177 * register class definitions: Register Classes. (line 6)
31178 * register class preference constraints: Class Preferences. (line 6)
31179 * register pairs: Values in Registers.
31181 * Register Transfer Language (RTL): RTL. (line 6)
31182 * register usage: Registers. (line 6)
31183 * REGISTER_MOVE_COST: Costs. (line 10)
31184 * REGISTER_NAMES: Instruction Output. (line 9)
31185 * register_operand: Machine-Independent Predicates.
31187 * REGISTER_PREFIX: Instruction Output. (line 124)
31188 * REGISTER_TARGET_PRAGMAS: Misc. (line 345)
31189 * registers arguments: Register Arguments. (line 6)
31190 * registers in constraints: Simple Constraints. (line 54)
31191 * REGMODE_NATURAL_SIZE: Values in Registers.
31193 * REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 165)
31194 * REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 173)
31195 * REGNO_OK_FOR_BASE_P: Register Classes. (line 159)
31196 * REGNO_OK_FOR_INDEX_P: Register Classes. (line 182)
31197 * REGNO_REG_CLASS: Register Classes. (line 101)
31198 * regs_ever_live: Function Entry. (line 21)
31199 * regular expressions: Processor pipeline description.
31201 * relative costs: Costs. (line 6)
31202 * RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 325)
31203 * reload pass: Regs and Memory. (line 148)
31204 * reload_completed: Standard Names. (line 797)
31205 * reload_in instruction pattern: Standard Names. (line 101)
31206 * reload_in_progress: Standard Names. (line 57)
31207 * reload_out instruction pattern: Standard Names. (line 101)
31208 * reloading: RTL passes. (line 177)
31209 * remainder: Arithmetic. (line 114)
31210 * reorder: GTY Options. (line 199)
31211 * representation of RTL: RTL. (line 6)
31212 * reservation delays: Processor pipeline description.
31214 * rest_of_decl_compilation: Parsing pass. (line 52)
31215 * rest_of_type_compilation: Parsing pass. (line 52)
31216 * restore_stack_block instruction pattern: Standard Names. (line 931)
31217 * restore_stack_function instruction pattern: Standard Names.
31219 * restore_stack_nonlocal instruction pattern: Standard Names.
31221 * RESULT_DECL: Declarations. (line 6)
31222 * return: Side Effects. (line 72)
31223 * return instruction pattern: Standard Names. (line 784)
31224 * return values in registers: Scalar Return. (line 6)
31225 * RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 127)
31226 * RETURN_ADDR_OFFSET: Exception Handling. (line 60)
31227 * RETURN_ADDR_RTX: Frame Layout. (line 116)
31228 * RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 51)
31229 * RETURN_EXPR: Function Bodies. (line 6)
31230 * RETURN_INIT: Function Bodies. (line 6)
31231 * RETURN_POPS_ARGS: Stack Arguments. (line 87)
31232 * RETURN_STMT: Function Bodies. (line 6)
31233 * returning aggregate values: Aggregate Return. (line 6)
31234 * returning structures and unions: Interface. (line 10)
31235 * reverse probability: Profile information.
31237 * REVERSE_CONDEXEC_PREDICATES_P: Condition Code. (line 129)
31238 * REVERSE_CONDITION: Condition Code. (line 116)
31239 * REVERSIBLE_CC_MODE: Condition Code. (line 102)
31240 * right rotate: Arithmetic. (line 164)
31241 * right shift: Arithmetic. (line 159)
31242 * rintM2 instruction pattern: Standard Names. (line 394)
31243 * RISC: Processor pipeline description.
31245 * roots, marking: GGC Roots. (line 6)
31246 * rotate: Arithmetic. (line 164)
31247 * rotatert: Arithmetic. (line 164)
31248 * rotlM3 instruction pattern: Standard Names. (line 285)
31249 * rotrM3 instruction pattern: Standard Names. (line 285)
31250 * Rough GIMPLE Grammar: Rough GIMPLE Grammar.
31252 * ROUND_DIV_EXPR: Expression trees. (line 6)
31253 * ROUND_MOD_EXPR: Expression trees. (line 6)
31254 * ROUND_TOWARDS_ZERO: Storage Layout. (line 451)
31255 * ROUND_TYPE_ALIGN: Storage Layout. (line 346)
31256 * roundM2 instruction pattern: Standard Names. (line 370)
31257 * RSHIFT_EXPR: Expression trees. (line 6)
31258 * RTL addition: Arithmetic. (line 14)
31259 * RTL addition with signed saturation: Arithmetic. (line 14)
31260 * RTL addition with unsigned saturation: Arithmetic. (line 14)
31261 * RTL classes: RTL Classes. (line 6)
31262 * RTL comparison: Arithmetic. (line 43)
31263 * RTL comparison operations: Comparisons. (line 6)
31264 * RTL constant expression types: Constants. (line 6)
31265 * RTL constants: Constants. (line 6)
31266 * RTL declarations: RTL Declarations. (line 6)
31267 * RTL difference: Arithmetic. (line 36)
31268 * RTL expression: RTL Objects. (line 6)
31269 * RTL expressions for arithmetic: Arithmetic. (line 6)
31270 * RTL format: RTL Classes. (line 71)
31271 * RTL format characters: RTL Classes. (line 76)
31272 * RTL function-call insns: Calls. (line 6)
31273 * RTL insn template: RTL Template. (line 6)
31274 * RTL integers: RTL Objects. (line 6)
31275 * RTL memory expressions: Regs and Memory. (line 6)
31276 * RTL object types: RTL Objects. (line 6)
31277 * RTL postdecrement: Incdec. (line 6)
31278 * RTL postincrement: Incdec. (line 6)
31279 * RTL predecrement: Incdec. (line 6)
31280 * RTL preincrement: Incdec. (line 6)
31281 * RTL register expressions: Regs and Memory. (line 6)
31282 * RTL representation: RTL. (line 6)
31283 * RTL side effect expressions: Side Effects. (line 6)
31284 * RTL strings: RTL Objects. (line 6)
31285 * RTL structure sharing assumptions: Sharing. (line 6)
31286 * RTL subtraction: Arithmetic. (line 36)
31287 * RTL subtraction with signed saturation: Arithmetic. (line 36)
31288 * RTL subtraction with unsigned saturation: Arithmetic. (line 36)
31289 * RTL sum: Arithmetic. (line 14)
31290 * RTL vectors: RTL Objects. (line 6)
31291 * RTX (See RTL): RTL Objects. (line 6)
31292 * RTX codes, classes of: RTL Classes. (line 6)
31293 * RTX_FRAME_RELATED_P: Flags. (line 111)
31294 * run-time conventions: Interface. (line 6)
31295 * run-time target specification: Run-time Target. (line 6)
31296 * s in constraint: Simple Constraints. (line 90)
31297 * same_type_p: Types. (line 102)
31298 * SAVE_EXPR: Expression trees. (line 6)
31299 * save_stack_block instruction pattern: Standard Names. (line 931)
31300 * save_stack_function instruction pattern: Standard Names. (line 931)
31301 * save_stack_nonlocal instruction pattern: Standard Names. (line 931)
31302 * scalars, returned as values: Scalar Return. (line 6)
31303 * SCHED_GROUP_P: Flags. (line 156)
31304 * SCmode: Machine Modes. (line 111)
31305 * sCOND instruction pattern: Standard Names. (line 668)
31306 * scratch: Regs and Memory. (line 173)
31307 * scratch operands: Regs and Memory. (line 173)
31308 * scratch, RTL sharing: Sharing. (line 35)
31309 * scratch_operand: Machine-Independent Predicates.
31311 * SDB_ALLOW_FORWARD_REFERENCES: SDB and DWARF. (line 80)
31312 * SDB_ALLOW_UNKNOWN_REFERENCES: SDB and DWARF. (line 75)
31313 * SDB_DEBUGGING_INFO: SDB and DWARF. (line 9)
31314 * SDB_DELIM: SDB and DWARF. (line 68)
31315 * SDB_OUTPUT_SOURCE_LINE: SDB and DWARF. (line 85)
31316 * search options: Including Patterns. (line 44)
31317 * SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 246)
31318 * SECONDARY_MEMORY_NEEDED: Register Classes. (line 308)
31319 * SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 327)
31320 * SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 318)
31321 * SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 247)
31322 * SECONDARY_RELOAD_CLASS: Register Classes. (line 245)
31323 * SELECT_CC_MODE: Condition Code. (line 68)
31324 * Selection Statements: Selection Statements.
31326 * sequence: Side Effects. (line 251)
31327 * set: Side Effects. (line 15)
31328 * set and /f: Flags. (line 111)
31329 * SET_ASM_OP: Label Output. (line 369)
31330 * set_attr: Tagging Insns. (line 31)
31331 * set_attr_alternative: Tagging Insns. (line 49)
31332 * SET_DEST: Side Effects. (line 69)
31333 * SET_IS_RETURN_P: Flags. (line 165)
31334 * SET_LABEL_KIND: Insns. (line 145)
31335 * set_optab_libfunc: Library Calls. (line 15)
31336 * SET_SRC: Side Effects. (line 69)
31337 * setmemM instruction pattern: Standard Names. (line 506)
31338 * SETUP_FRAME_ADDRESSES: Frame Layout. (line 102)
31339 * SFmode: Machine Modes. (line 66)
31340 * sharing of RTL components: Sharing. (line 6)
31341 * shift: Arithmetic. (line 151)
31342 * SHIFT_COUNT_TRUNCATED: Misc. (line 127)
31343 * SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 96)
31344 * SHORT_TYPE_SIZE: Type Layout. (line 16)
31345 * sibcall_epilogue instruction pattern: Standard Names. (line 1121)
31346 * sibling call: Edges. (line 122)
31347 * SIBLING_CALL_P: Flags. (line 169)
31348 * sign_extend: Conversions. (line 23)
31349 * sign_extract: Bit-Fields. (line 8)
31350 * sign_extract, canonicalization of: Insn Canonicalizations.
31352 * signed division: Arithmetic. (line 100)
31353 * signed maximum: Arithmetic. (line 119)
31354 * signed minimum: Arithmetic. (line 119)
31355 * SImode: Machine Modes. (line 37)
31356 * simple constraints: Simple Constraints. (line 6)
31357 * sinM2 instruction pattern: Standard Names. (line 311)
31358 * SIZE_ASM_OP: Label Output. (line 23)
31359 * SIZE_TYPE: Type Layout. (line 116)
31360 * skip: GTY Options. (line 77)
31361 * SLOW_BYTE_ACCESS: Costs. (line 60)
31362 * SLOW_UNALIGNED_ACCESS: Costs. (line 75)
31363 * SMALL_ARG_MAX: Host Misc. (line 41)
31364 * SMALL_REGISTER_CLASSES: Register Classes. (line 350)
31365 * smax: Arithmetic. (line 119)
31366 * smin: Arithmetic. (line 119)
31367 * sms, swing, software pipelining: RTL passes. (line 136)
31368 * smulM3_highpart instruction pattern: Standard Names. (line 247)
31369 * soft float library: Soft float library routines.
31371 * special: GTY Options. (line 219)
31372 * special predicates: Predicates. (line 31)
31373 * SPECS: Target Fragment. (line 108)
31374 * speed of instructions: Costs. (line 6)
31375 * split_block: Maintaining the CFG.
31377 * splitting instructions: Insn Splitting. (line 6)
31378 * sqrt: Arithmetic. (line 172)
31379 * sqrtM2 instruction pattern: Standard Names. (line 295)
31380 * square root: Arithmetic. (line 172)
31381 * ss_minus: Arithmetic. (line 36)
31382 * ss_plus: Arithmetic. (line 14)
31383 * ss_truncate: Conversions. (line 43)
31384 * SSA: SSA. (line 6)
31385 * SSA_NAME_DEF_STMT: SSA. (line 192)
31386 * SSA_NAME_VERSION: SSA. (line 197)
31387 * stack arguments: Stack Arguments. (line 6)
31388 * stack frame layout: Frame Layout. (line 6)
31389 * stack smashing protection: Stack Smashing Protection.
31391 * STACK_ALIGNMENT_NEEDED: Frame Layout. (line 48)
31392 * STACK_BOUNDARY: Storage Layout. (line 149)
31393 * STACK_CHECK_BUILTIN: Stack Checking. (line 29)
31394 * STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 64)
31395 * STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 55)
31396 * STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 71)
31397 * STACK_CHECK_PROBE_INTERVAL: Stack Checking. (line 37)
31398 * STACK_CHECK_PROBE_LOAD: Stack Checking. (line 44)
31399 * STACK_CHECK_PROTECT: Stack Checking. (line 50)
31400 * STACK_DYNAMIC_OFFSET: Frame Layout. (line 75)
31401 * STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory.
31403 * STACK_GROWS_DOWNWARD: Frame Layout. (line 9)
31404 * STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 78)
31405 * STACK_POINTER_OFFSET: Frame Layout. (line 58)
31406 * STACK_POINTER_OFFSET and virtual registers: Regs and Memory.
31408 * STACK_POINTER_REGNUM: Frame Registers. (line 9)
31409 * STACK_POINTER_REGNUM and virtual registers: Regs and Memory.
31411 * stack_pointer_rtx: Frame Registers. (line 85)
31412 * stack_protect_set instruction pattern: Standard Names. (line 1288)
31413 * stack_protect_test instruction pattern: Standard Names. (line 1298)
31414 * STACK_PUSH_CODE: Frame Layout. (line 17)
31415 * STACK_REGS: Stack Registers. (line 20)
31416 * STACK_SAVEAREA_MODE: Storage Layout. (line 362)
31417 * STACK_SIZE_MODE: Storage Layout. (line 374)
31418 * standard pattern names: Standard Names. (line 6)
31419 * STANDARD_INCLUDE_COMPONENT: Driver. (line 425)
31420 * STANDARD_INCLUDE_DIR: Driver. (line 417)
31421 * STANDARD_STARTFILE_PREFIX: Driver. (line 337)
31422 * STANDARD_STARTFILE_PREFIX_1: Driver. (line 344)
31423 * STANDARD_STARTFILE_PREFIX_2: Driver. (line 351)
31424 * STARTFILE_SPEC: Driver. (line 210)
31425 * STARTING_FRAME_OFFSET: Frame Layout. (line 39)
31426 * STARTING_FRAME_OFFSET and virtual registers: Regs and Memory.
31428 * Statement Sequences: Statement Sequences.
31430 * Statements: Statements. (line 6)
31431 * statements: Function Bodies. (line 6)
31432 * Static profile estimation: Profile information.
31434 * static single assignment: SSA. (line 6)
31435 * STATIC_CHAIN: Frame Registers. (line 77)
31436 * STATIC_CHAIN_INCOMING: Frame Registers. (line 78)
31437 * STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 64)
31438 * STATIC_CHAIN_REGNUM: Frame Registers. (line 63)
31439 * stdarg.h and register arguments: Register Arguments. (line 47)
31440 * STDC_0_IN_SYSTEM_HEADERS: Misc. (line 328)
31441 * STMT_EXPR: Expression trees. (line 6)
31442 * STMT_IS_FULL_EXPR_P: Function Bodies. (line 22)
31443 * storage layout: Storage Layout. (line 6)
31444 * STORE_BY_PIECES_P: Costs. (line 130)
31445 * STORE_FLAG_VALUE: Misc. (line 190)
31446 * store_multiple instruction pattern: Standard Names. (line 159)
31447 * strcpy: Storage Layout. (line 206)
31448 * STRICT_ALIGNMENT: Storage Layout. (line 250)
31449 * strict_low_part: RTL Declarations. (line 9)
31450 * strict_memory_address_p: Addressing Modes. (line 206)
31451 * STRING_CST: Expression trees. (line 6)
31452 * STRING_POOL_ADDRESS_P: Flags. (line 173)
31453 * strlenM instruction pattern: Standard Names. (line 562)
31454 * structure value address: Aggregate Return. (line 6)
31455 * STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 242)
31456 * structures, returning: Interface. (line 10)
31457 * subM3 instruction pattern: Standard Names. (line 193)
31458 * SUBOBJECT: Function Bodies. (line 6)
31459 * SUBOBJECT_CLEANUP: Function Bodies. (line 6)
31460 * subreg: Regs and Memory. (line 97)
31461 * subreg and /s: Flags. (line 195)
31462 * subreg and /u: Flags. (line 188)
31463 * subreg and /u and /v: Flags. (line 178)
31464 * subreg, in strict_low_part: RTL Declarations. (line 9)
31465 * subreg, special reload handling: Regs and Memory. (line 148)
31466 * SUBREG_BYTE: Regs and Memory. (line 169)
31467 * SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 178)
31468 * SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 188)
31469 * SUBREG_PROMOTED_VAR_P: Flags. (line 195)
31470 * SUBREG_REG: Regs and Memory. (line 169)
31471 * SUCCESS_EXIT_CODE: Host Misc. (line 12)
31472 * SUPPORTS_INIT_PRIORITY: Macros for Initialization.
31474 * SUPPORTS_ONE_ONLY: Label Output. (line 218)
31475 * SUPPORTS_WEAK: Label Output. (line 199)
31476 * SWITCH_BODY: Function Bodies. (line 6)
31477 * SWITCH_COND: Function Bodies. (line 6)
31478 * SWITCH_CURTAILS_COMPILATION: Driver. (line 33)
31479 * SWITCH_STMT: Function Bodies. (line 6)
31480 * SWITCH_TAKES_ARG: Driver. (line 9)
31481 * SWITCHES_NEED_SPACES: Driver. (line 47)
31482 * SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 80)
31483 * SYMBOL_FLAG_FUNCTION: Special Accessors. (line 73)
31484 * SYMBOL_FLAG_LOCAL: Special Accessors. (line 76)
31485 * SYMBOL_FLAG_SMALL: Special Accessors. (line 85)
31486 * SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 89)
31487 * symbol_ref: Constants. (line 87)
31488 * symbol_ref and /f: Flags. (line 173)
31489 * symbol_ref and /i: Flags. (line 210)
31490 * symbol_ref and /u: Flags. (line 10)
31491 * symbol_ref and /v: Flags. (line 214)
31492 * symbol_ref, RTL sharing: Sharing. (line 20)
31493 * SYMBOL_REF_DECL: Special Accessors. (line 55)
31494 * SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 80)
31495 * SYMBOL_REF_FLAG: Flags. (line 214)
31496 * SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 207)
31497 * SYMBOL_REF_FLAGS: Special Accessors. (line 67)
31498 * SYMBOL_REF_FUNCTION_P: Special Accessors. (line 73)
31499 * SYMBOL_REF_LOCAL_P: Special Accessors. (line 76)
31500 * SYMBOL_REF_SMALL_P: Special Accessors. (line 85)
31501 * SYMBOL_REF_TLS_MODEL: Special Accessors. (line 89)
31502 * SYMBOL_REF_USED: Flags. (line 205)
31503 * SYMBOL_REF_WEAK: Flags. (line 210)
31504 * symbolic label: Sharing. (line 20)
31505 * sync_addMODE instruction pattern: Standard Names. (line 1202)
31506 * sync_andMODE instruction pattern: Standard Names. (line 1202)
31507 * sync_compare_and_swap_ccMODE instruction pattern: Standard Names.
31509 * sync_compare_and_swapMODE instruction pattern: Standard Names.
31511 * sync_iorMODE instruction pattern: Standard Names. (line 1202)
31512 * sync_lock_releaseMODE instruction pattern: Standard Names. (line 1269)
31513 * sync_lock_test_and_setMODE instruction pattern: Standard Names.
31515 * sync_nandMODE instruction pattern: Standard Names. (line 1202)
31516 * sync_new_addMODE instruction pattern: Standard Names. (line 1236)
31517 * sync_new_andMODE instruction pattern: Standard Names. (line 1236)
31518 * sync_new_iorMODE instruction pattern: Standard Names. (line 1236)
31519 * sync_new_nandMODE instruction pattern: Standard Names. (line 1236)
31520 * sync_new_subMODE instruction pattern: Standard Names. (line 1236)
31521 * sync_new_xorMODE instruction pattern: Standard Names. (line 1236)
31522 * sync_old_addMODE instruction pattern: Standard Names. (line 1219)
31523 * sync_old_andMODE instruction pattern: Standard Names. (line 1219)
31524 * sync_old_iorMODE instruction pattern: Standard Names. (line 1219)
31525 * sync_old_nandMODE instruction pattern: Standard Names. (line 1219)
31526 * sync_old_subMODE instruction pattern: Standard Names. (line 1219)
31527 * sync_old_xorMODE instruction pattern: Standard Names. (line 1219)
31528 * sync_subMODE instruction pattern: Standard Names. (line 1202)
31529 * sync_xorMODE instruction pattern: Standard Names. (line 1202)
31530 * SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 239)
31531 * SYSROOT_SUFFIX_SPEC: Driver. (line 234)
31532 * SYSTEM_INCLUDE_DIR: Driver. (line 408)
31533 * t-TARGET: Target Fragment. (line 6)
31534 * table jump: Basic Blocks. (line 57)
31535 * tablejump instruction pattern: Standard Names. (line 859)
31536 * tag: GTY Options. (line 82)
31537 * tagging insns: Tagging Insns. (line 6)
31538 * tail calls: Tail Calls. (line 6)
31539 * target attributes: Target Attributes. (line 6)
31540 * target description macros: Target Macros. (line 6)
31541 * target functions: Target Structure. (line 6)
31542 * target hooks: Target Structure. (line 6)
31543 * target makefile fragment: Target Fragment. (line 6)
31544 * target specifications: Run-time Target. (line 6)
31545 * TARGET_ADDRESS_COST: Costs. (line 214)
31546 * TARGET_ALIGN_ANON_BITFIELDS: Storage Layout. (line 327)
31547 * TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 677)
31548 * TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 83)
31549 * TARGET_ARM_EABI_UNWINDER: Exception Region Output.
31551 * TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 10)
31552 * TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 8)
31553 * TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 9)
31554 * TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 11)
31555 * TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 230)
31556 * TARGET_ASM_BYTE_OP: Data Output. (line 7)
31557 * TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 237)
31558 * TARGET_ASM_CLOSE_PAREN: Data Output. (line 128)
31559 * TARGET_ASM_CONSTRUCTOR: Macros for Initialization.
31561 * TARGET_ASM_DESTRUCTOR: Macros for Initialization.
31563 * TARGET_ASM_EH_FRAME_SECTION: Exception Region Output.
31565 * TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 63)
31566 * TARGET_ASM_EXCEPTION_SECTION: Exception Region Output.
31568 * TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 265)
31569 * TARGET_ASM_FILE_END: File Framework. (line 37)
31570 * TARGET_ASM_FILE_START: File Framework. (line 9)
31571 * TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 17)
31572 * TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 31)
31573 * TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 61)
31574 * TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 55)
31575 * TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 68)
31576 * TARGET_ASM_FUNCTION_EPILOGUE and trampolines: Trampolines. (line 71)
31577 * TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 11)
31578 * TARGET_ASM_FUNCTION_PROLOGUE and trampolines: Trampolines. (line 71)
31579 * TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 161)
31580 * TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 165)
31581 * TARGET_ASM_INTEGER: Data Output. (line 27)
31582 * TARGET_ASM_INTERNAL_LABEL: Label Output. (line 300)
31583 * TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 271)
31584 * TARGET_ASM_NAMED_SECTION: File Framework. (line 89)
31585 * TARGET_ASM_OPEN_PAREN: Data Output. (line 127)
31586 * TARGET_ASM_OUTPUT_DWARF_DTPREL: SDB and DWARF. (line 57)
31587 * TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 195)
31588 * TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 170)
31589 * TARGET_ASM_SELECT_SECTION: Sections. (line 126)
31590 * TARGET_ASM_TTYPE: Exception Region Output.
31592 * TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 14)
31593 * TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 12)
31594 * TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 13)
31595 * TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 15)
31596 * TARGET_ASM_UNIQUE_SECTION: Sections. (line 149)
31597 * TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 11)
31598 * TARGET_BINDS_LOCAL_P: Sections. (line 232)
31599 * TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 747)
31600 * TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 739)
31601 * TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 249)
31602 * TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 109)
31603 * TARGET_C99_FUNCTIONS: Library Calls. (line 77)
31604 * TARGET_CALLEE_COPIES: Register Arguments. (line 115)
31605 * TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 248)
31606 * TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 726)
31607 * TARGET_COMMUTATIVE_P: Misc. (line 670)
31608 * TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 19)
31609 * TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 9)
31610 * TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 75)
31611 * TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 38)
31612 * TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 62)
31613 * TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 25)
31614 * TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 54)
31615 * TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 18)
31616 * TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 12)
31617 * TARGET_CXX_GUARD_TYPE: C++ ABI. (line 7)
31618 * TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 30)
31619 * TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 43)
31620 * TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 69)
31621 * TARGET_DECLSPEC: Target Attributes. (line 64)
31622 * TARGET_DEFAULT_PACK_STRUCT: Misc. (line 447)
31623 * TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 108)
31624 * TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 384)
31625 * TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 239)
31626 * TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 47)
31627 * TARGET_DWARF_CALLING_CONVENTION: SDB and DWARF. (line 18)
31628 * TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 160)
31629 * TARGET_DWARF_REGISTER_SPAN: Exception Region Output.
31631 * TARGET_EDOM: Library Calls. (line 59)
31632 * TARGET_ENCODE_SECTION_INFO: Sections. (line 183)
31633 * TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes.
31635 * TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 100)
31636 * TARGET_EXECUTABLE_SUFFIX: Misc. (line 700)
31637 * TARGET_EXPAND_BUILTIN: Misc. (line 622)
31638 * TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 92)
31639 * TARGET_EXPR: Expression trees. (line 6)
31640 * TARGET_EXTRA_INCLUDES: Misc. (line 772)
31641 * TARGET_EXTRA_PRE_INCLUDES: Misc. (line 779)
31642 * TARGET_FIXED_CONDITION_CODE_REGS: Condition Code. (line 142)
31643 * target_flags: Run-time Target. (line 52)
31644 * TARGET_FLOAT_FORMAT: Storage Layout. (line 383)
31645 * TARGET_FLT_EVAL_METHOD: Type Layout. (line 89)
31646 * TARGET_FOLD_BUILTIN: Misc. (line 642)
31647 * TARGET_FORMAT_TYPES: Misc. (line 799)
31648 * TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 86)
31649 * TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 8)
31650 * TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 254)
31651 * TARGET_HANDLE_OPTION: Run-time Target. (line 61)
31652 * TARGET_HAVE_CTORS_DTORS: Macros for Initialization.
31654 * TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 99)
31655 * TARGET_IN_SMALL_DATA_P: Sections. (line 224)
31656 * TARGET_INIT_BUILTINS: Misc. (line 604)
31657 * TARGET_INIT_LIBFUNCS: Library Calls. (line 16)
31658 * TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 73)
31659 * TARGET_INVALID_BINARY_OP: Misc. (line 837)
31660 * TARGET_INVALID_CONVERSION: Misc. (line 824)
31661 * TARGET_INVALID_UNARY_OP: Misc. (line 830)
31662 * TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 35)
31663 * TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 589)
31664 * TARGET_MANGLE_FUNDAMENTAL_TYPE: Storage Layout. (line 518)
31665 * TARGET_MD_ASM_CLOBBERS: Misc. (line 505)
31666 * TARGET_MEM_REF: Expression trees. (line 6)
31667 * TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 39)
31668 * TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 31)
31669 * TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 106)
31670 * TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 491)
31671 * TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 62)
31672 * TARGET_MUST_PASS_IN_STACK, and FUNCTION_ARG: Register Arguments.
31674 * TARGET_N_FORMAT_TYPES: Misc. (line 804)
31675 * TARGET_OBJECT_SUFFIX: Misc. (line 695)
31676 * TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 46)
31677 * TARGET_OPTF: Misc. (line 786)
31678 * TARGET_OPTION_TRANSLATE_TABLE: Driver. (line 53)
31679 * TARGET_OS_CPP_BUILTINS: Run-time Target. (line 42)
31680 * TARGET_PASS_BY_REFERENCE: Register Arguments. (line 103)
31681 * TARGET_POSIX_IO: Misc. (line 529)
31682 * TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 152)
31683 * TARGET_PROMOTE_FUNCTION_ARGS: Storage Layout. (line 130)
31684 * TARGET_PROMOTE_FUNCTION_RETURN: Storage Layout. (line 135)
31685 * TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 11)
31686 * TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 183)
31687 * TARGET_RELAXED_ORDERING: Misc. (line 808)
31688 * TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 632)
31689 * TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 16)
31690 * TARGET_RETURN_IN_MSB: Scalar Return. (line 90)
31691 * TARGET_RTX_COSTS: Costs. (line 188)
31692 * TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 266)
31693 * TARGET_SCHED_ADJUST_COST: Scheduling. (line 40)
31694 * TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 55)
31695 * TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 92)
31696 * TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 194)
31697 * TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 147)
31698 * TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 135)
31699 * TARGET_SCHED_FINISH: Scheduling. (line 112)
31700 * TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 129)
31701 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling.
31703 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling.
31705 * TARGET_SCHED_INIT: Scheduling. (line 102)
31706 * TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 152)
31707 * TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 144)
31708 * TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 121)
31709 * TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 208)
31710 * TARGET_SCHED_ISSUE_RATE: Scheduling. (line 12)
31711 * TARGET_SCHED_REORDER: Scheduling. (line 63)
31712 * TARGET_SCHED_REORDER2: Scheduling. (line 80)
31713 * TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 27)
31714 * TARGET_SECTION_TYPE_FLAGS: File Framework. (line 104)
31715 * TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 26)
31716 * TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 101)
31717 * TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 154)
31718 * TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 237)
31719 * TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection.
31721 * TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection.
31723 * TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 137)
31724 * TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 44)
31725 * TARGET_UNWIND_EMIT: Dispatch Tables. (line 74)
31726 * TARGET_UNWIND_INFO: Exception Region Output.
31728 * TARGET_USE_JCR_SECTION: Misc. (line 842)
31729 * TARGET_USE_LOCAL_THUNK_ALIAS_P: Misc. (line 792)
31730 * TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 128)
31731 * TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 59)
31732 * TARGET_VALID_POINTER_MODE: Register Arguments. (line 260)
31733 * TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 278)
31734 * TARGET_VECTOR_OPAQUE_P: Storage Layout. (line 484)
31735 * TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 259)
31736 * TARGET_VERSION: Run-time Target. (line 77)
31737 * TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 236)
31738 * TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 230)
31739 * TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 219)
31740 * TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 236)
31741 * targetm: Target Structure. (line 7)
31742 * targets, makefile: Makefile. (line 6)
31743 * TCmode: Machine Modes. (line 111)
31744 * TEMPLATE_DECL: Declarations. (line 6)
31745 * Temporaries: Temporaries. (line 6)
31746 * termination routines: Initialization. (line 6)
31747 * text_section: Sections. (line 109)
31748 * TEXT_SECTION_ASM_OP: Sections. (line 18)
31749 * TFmode: Machine Modes. (line 85)
31750 * THEN_CLAUSE: Function Bodies. (line 6)
31751 * THREAD_MODEL_SPEC: Driver. (line 225)
31752 * THROW_EXPR: Expression trees. (line 6)
31753 * THUNK_DECL: Declarations. (line 6)
31754 * THUNK_DELTA: Declarations. (line 6)
31755 * TImode: Machine Modes. (line 48)
31756 * TImode, in insn: Insns. (line 242)
31757 * tm.h macros: Target Macros. (line 6)
31758 * TQFmode: Machine Modes. (line 62)
31759 * TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 63)
31760 * TRAMPOLINE_ALIGNMENT: Trampolines. (line 50)
31761 * TRAMPOLINE_SECTION: Trampolines. (line 40)
31762 * TRAMPOLINE_SIZE: Trampolines. (line 46)
31763 * TRAMPOLINE_TEMPLATE: Trampolines. (line 29)
31764 * trampolines for nested functions: Trampolines. (line 6)
31765 * TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 125)
31766 * trap instruction pattern: Standard Names. (line 1131)
31767 * tree <1>: Macros and Functions.
31769 * tree: Tree overview. (line 6)
31770 * Tree SSA: Tree SSA. (line 6)
31771 * TREE_CODE: Tree overview. (line 6)
31772 * TREE_FILENAME: Working with declarations.
31774 * tree_int_cst_equal: Expression trees. (line 6)
31775 * TREE_INT_CST_HIGH: Expression trees. (line 6)
31776 * TREE_INT_CST_LOW: Expression trees. (line 6)
31777 * tree_int_cst_lt: Expression trees. (line 6)
31778 * TREE_LINENO: Working with declarations.
31780 * TREE_LIST: Containers. (line 6)
31781 * TREE_OPERAND: Expression trees. (line 6)
31782 * TREE_PUBLIC: Function Basics. (line 6)
31783 * TREE_PURPOSE: Containers. (line 6)
31784 * TREE_STRING_LENGTH: Expression trees. (line 6)
31785 * TREE_STRING_POINTER: Expression trees. (line 6)
31786 * TREE_TYPE <1>: Expression trees. (line 6)
31787 * TREE_TYPE <2>: Function Basics. (line 171)
31788 * TREE_TYPE <3>: Working with declarations.
31790 * TREE_TYPE: Types. (line 6)
31791 * TREE_VALUE: Containers. (line 6)
31792 * TREE_VEC: Containers. (line 6)
31793 * TREE_VEC_ELT: Containers. (line 6)
31794 * TREE_VEC_LENGTH: Containers. (line 6)
31795 * Trees: Trees. (line 6)
31796 * TRULY_NOOP_TRUNCATION: Misc. (line 177)
31797 * TRUNC_DIV_EXPR: Expression trees. (line 6)
31798 * TRUNC_MOD_EXPR: Expression trees. (line 6)
31799 * truncate: Conversions. (line 38)
31800 * truncMN2 instruction pattern: Standard Names. (line 605)
31801 * TRUTH_AND_EXPR: Expression trees. (line 6)
31802 * TRUTH_ANDIF_EXPR: Expression trees. (line 6)
31803 * TRUTH_NOT_EXPR: Expression trees. (line 6)
31804 * TRUTH_OR_EXPR: Expression trees. (line 6)
31805 * TRUTH_ORIF_EXPR: Expression trees. (line 6)
31806 * TRUTH_XOR_EXPR: Expression trees. (line 6)
31807 * TRY_BLOCK: Function Bodies. (line 6)
31808 * TRY_HANDLERS: Function Bodies. (line 6)
31809 * TRY_STMTS: Function Bodies. (line 6)
31810 * tstM instruction pattern: Standard Names. (line 459)
31811 * type: Types. (line 6)
31812 * type declaration: Declarations. (line 6)
31813 * TYPE_ALIGN: Types. (line 6)
31814 * TYPE_ARG_TYPES: Types. (line 6)
31815 * TYPE_ASM_OP: Label Output. (line 55)
31816 * TYPE_ATTRIBUTES: Attributes. (line 25)
31817 * TYPE_BINFO: Classes. (line 6)
31818 * TYPE_BUILT_IN: Types. (line 83)
31819 * TYPE_CONTEXT: Types. (line 6)
31820 * TYPE_DECL: Declarations. (line 6)
31821 * TYPE_FIELDS <1>: Classes. (line 6)
31822 * TYPE_FIELDS: Types. (line 6)
31823 * TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 91)
31824 * TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 76)
31825 * TYPE_HAS_MUTABLE_P: Classes. (line 81)
31826 * TYPE_HAS_NEW_OPERATOR: Classes. (line 88)
31827 * TYPE_MAIN_VARIANT: Types. (line 6)
31828 * TYPE_MAX_VALUE: Types. (line 6)
31829 * TYPE_METHOD_BASETYPE: Types. (line 6)
31830 * TYPE_METHODS: Classes. (line 6)
31831 * TYPE_MIN_VALUE: Types. (line 6)
31832 * TYPE_NAME: Types. (line 6)
31833 * TYPE_NOTHROW_P: Function Basics. (line 180)
31834 * TYPE_OFFSET_BASETYPE: Types. (line 6)
31835 * TYPE_OPERAND_FMT: Label Output. (line 66)
31836 * TYPE_OVERLOADS_ARRAY_REF: Classes. (line 99)
31837 * TYPE_OVERLOADS_ARROW: Classes. (line 102)
31838 * TYPE_OVERLOADS_CALL_EXPR: Classes. (line 95)
31839 * TYPE_POLYMORPHIC_P: Classes. (line 72)
31840 * TYPE_PRECISION: Types. (line 6)
31841 * TYPE_PTR_P: Types. (line 89)
31842 * TYPE_PTRFN_P: Types. (line 93)
31843 * TYPE_PTRMEM_P: Types. (line 6)
31844 * TYPE_PTROB_P: Types. (line 96)
31845 * TYPE_PTROBV_P: Types. (line 6)
31846 * TYPE_QUAL_CONST: Types. (line 6)
31847 * TYPE_QUAL_RESTRICT: Types. (line 6)
31848 * TYPE_QUAL_VOLATILE: Types. (line 6)
31849 * TYPE_RAISES_EXCEPTIONS: Function Basics. (line 175)
31850 * TYPE_SIZE: Types. (line 6)
31851 * TYPE_UNQUALIFIED: Types. (line 6)
31852 * TYPE_VFIELD: Classes. (line 6)
31853 * TYPENAME_TYPE: Types. (line 6)
31854 * TYPENAME_TYPE_FULLNAME: Types. (line 6)
31855 * TYPEOF_TYPE: Types. (line 6)
31856 * udiv: Arithmetic. (line 111)
31857 * udivM3 instruction pattern: Standard Names. (line 193)
31858 * udivmodM4 instruction pattern: Standard Names. (line 272)
31859 * UINTMAX_TYPE: Type Layout. (line 172)
31860 * umax: Arithmetic. (line 127)
31861 * umaxM3 instruction pattern: Standard Names. (line 193)
31862 * umin: Arithmetic. (line 127)
31863 * uminM3 instruction pattern: Standard Names. (line 193)
31864 * umod: Arithmetic. (line 114)
31865 * umodM3 instruction pattern: Standard Names. (line 193)
31866 * umulhisi3 instruction pattern: Standard Names. (line 243)
31867 * umulM3_highpart instruction pattern: Standard Names. (line 252)
31868 * umulqihi3 instruction pattern: Standard Names. (line 243)
31869 * umulsidi3 instruction pattern: Standard Names. (line 243)
31870 * unchanging: Flags. (line 303)
31871 * unchanging, in call_insn: Flags. (line 19)
31872 * unchanging, in jump_insn, call_insn and insn: Flags. (line 24)
31873 * unchanging, in mem: Flags. (line 142)
31874 * unchanging, in subreg: Flags. (line 178)
31875 * unchanging, in symbol_ref: Flags. (line 10)
31876 * UNEQ_EXPR: Expression trees. (line 6)
31877 * UNGE_EXPR: Expression trees. (line 6)
31878 * UNGT_EXPR: Expression trees. (line 6)
31879 * UNION_TYPE <1>: Classes. (line 6)
31880 * UNION_TYPE: Types. (line 6)
31881 * unions, returning: Interface. (line 10)
31882 * UNITS_PER_SIMD_WORD: Storage Layout. (line 77)
31883 * UNITS_PER_WORD: Storage Layout. (line 67)
31884 * UNKNOWN_TYPE: Types. (line 6)
31885 * UNLE_EXPR: Expression trees. (line 6)
31886 * UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 29)
31887 * UNLT_EXPR: Expression trees. (line 6)
31888 * UNORDERED_EXPR: Expression trees. (line 6)
31889 * unshare_all_rtl: Sharing. (line 58)
31890 * unsigned division: Arithmetic. (line 111)
31891 * unsigned greater than: Comparisons. (line 64)
31892 * unsigned less than: Comparisons. (line 68)
31893 * unsigned minimum and maximum: Arithmetic. (line 127)
31894 * unsigned_fix: Conversions. (line 72)
31895 * unsigned_float: Conversions. (line 62)
31896 * unspec: Side Effects. (line 284)
31897 * unspec_volatile: Side Effects. (line 284)
31898 * untyped_call instruction pattern: Standard Names. (line 769)
31899 * untyped_return instruction pattern: Standard Names. (line 819)
31900 * UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59)
31901 * update_ssa: SSA. (line 76)
31902 * update_stmt: Statement Operands. (line 6)
31903 * US Software GOFAST, floating point emulation library: Library Calls.
31905 * us_minus: Arithmetic. (line 36)
31906 * us_plus: Arithmetic. (line 14)
31907 * US_SOFTWARE_GOFAST: Library Calls. (line 45)
31908 * us_truncate: Conversions. (line 48)
31909 * use: Side Effects. (line 159)
31910 * USE_C_ALLOCA: Host Misc. (line 19)
31911 * USE_LD_AS_NEEDED: Driver. (line 198)
31912 * USE_LOAD_POST_DECREMENT: Costs. (line 143)
31913 * USE_LOAD_POST_INCREMENT: Costs. (line 138)
31914 * USE_LOAD_PRE_DECREMENT: Costs. (line 153)
31915 * USE_LOAD_PRE_INCREMENT: Costs. (line 148)
31916 * use_param: GTY Options. (line 114)
31917 * use_paramN: GTY Options. (line 132)
31918 * use_params: GTY Options. (line 140)
31919 * USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 141)
31920 * USE_STORE_POST_DECREMENT: Costs. (line 163)
31921 * USE_STORE_POST_INCREMENT: Costs. (line 158)
31922 * USE_STORE_PRE_DECREMENT: Costs. (line 173)
31923 * USE_STORE_PRE_INCREMENT: Costs. (line 168)
31924 * used: Flags. (line 321)
31925 * used, in symbol_ref: Flags. (line 205)
31926 * USER_LABEL_PREFIX: Instruction Output. (line 126)
31927 * USING_DECL: Declarations. (line 6)
31928 * USING_STMT: Function Bodies. (line 6)
31929 * V in constraint: Simple Constraints. (line 41)
31930 * VA_ARG_EXPR: Expression trees. (line 6)
31931 * values, returned by functions: Scalar Return. (line 6)
31932 * VAR_DECL <1>: Expression trees. (line 6)
31933 * VAR_DECL: Declarations. (line 6)
31934 * varargs implementation: Varargs. (line 6)
31935 * variable: Declarations. (line 6)
31936 * VAX_FLOAT_FORMAT: Storage Layout. (line 391)
31937 * vec_concat: Vector Operations. (line 25)
31938 * vec_duplicate: Vector Operations. (line 30)
31939 * vec_extractM instruction pattern: Standard Names. (line 170)
31940 * vec_initM instruction pattern: Standard Names. (line 175)
31941 * vec_merge: Vector Operations. (line 11)
31942 * vec_select: Vector Operations. (line 19)
31943 * vec_setM instruction pattern: Standard Names. (line 165)
31944 * vec_shl_M instruction pattern: Standard Names. (line 230)
31945 * vec_shr_M instruction pattern: Standard Names. (line 230)
31946 * vector: Containers. (line 6)
31947 * vector operations: Vector Operations. (line 6)
31948 * VECTOR_CST: Expression trees. (line 6)
31949 * VECTOR_STORE_FLAG_VALUE: Misc. (line 282)
31950 * virtual operands: Statement Operands. (line 6)
31951 * VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59)
31952 * VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87)
31953 * VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78)
31954 * VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69)
31955 * VLIW: Processor pipeline description.
31957 * VMS: Filesystem. (line 37)
31958 * VMS_DEBUGGING_INFO: VMS Debug. (line 9)
31959 * VOID_TYPE: Types. (line 6)
31960 * VOIDmode: Machine Modes. (line 104)
31961 * volatil: Flags. (line 335)
31962 * volatil, in insn, call_insn, jump_insn, code_label, barrier, and note: Flags.
31964 * volatil, in label_ref and reg_label: Flags. (line 55)
31965 * volatil, in mem, asm_operands, and asm_input: Flags. (line 84)
31966 * volatil, in reg: Flags. (line 102)
31967 * volatil, in subreg: Flags. (line 178)
31968 * volatil, in symbol_ref: Flags. (line 214)
31969 * volatile memory references: Flags. (line 336)
31970 * voting between constraint alternatives: Class Preferences. (line 6)
31971 * walk_dominator_tree: SSA. (line 227)
31972 * walk_use_def_chains: SSA. (line 203)
31973 * WCHAR_TYPE: Type Layout. (line 140)
31974 * WCHAR_TYPE_SIZE: Type Layout. (line 148)
31975 * which_alternative: Output Statement. (line 59)
31976 * WHILE_BODY: Function Bodies. (line 6)
31977 * WHILE_COND: Function Bodies. (line 6)
31978 * WHILE_STMT: Function Bodies. (line 6)
31979 * WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 95)
31980 * WINT_TYPE: Type Layout. (line 153)
31981 * word_mode: Machine Modes. (line 222)
31982 * WORD_REGISTER_OPERATIONS: Misc. (line 63)
31983 * WORD_SWITCH_TAKES_ARG: Driver. (line 20)
31984 * WORDS_BIG_ENDIAN: Storage Layout. (line 29)
31985 * WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 132)
31986 * X in constraint: Simple Constraints. (line 112)
31987 * x-HOST: Host Fragment. (line 6)
31988 * XCmode: Machine Modes. (line 111)
31989 * XCOFF_DEBUGGING_INFO: DBX Options. (line 13)
31990 * XEXP: Accessors. (line 6)
31991 * XFmode: Machine Modes. (line 79)
31992 * XINT: Accessors. (line 6)
31993 * xm-MACHINE.h <1>: Host Misc. (line 6)
31994 * xm-MACHINE.h: Filesystem. (line 6)
31995 * xor: Arithmetic. (line 146)
31996 * xor, canonicalization of: Insn Canonicalizations.
31998 * xorM3 instruction pattern: Standard Names. (line 193)
31999 * XSTR: Accessors. (line 6)
32000 * XVEC: Accessors. (line 41)
32001 * XVECEXP: Accessors. (line 48)
32002 * XVECLEN: Accessors. (line 44)
32003 * XWINT: Accessors. (line 6)
32004 * zero_extend: Conversions. (line 28)
32005 * zero_extendMN2 instruction pattern: Standard Names. (line 615)
32006 * zero_extract: Bit-Fields. (line 30)
32007 * zero_extract, canonicalization of: Insn Canonicalizations.
32014 Node: Contributing
\7f4888
32015 Node: Portability
\7f5629
32016 Node: Interface
\7f7417
32017 Node: Libgcc
\7f10457
32018 Node: Integer library routines
\7f12203
32019 Node: Soft float library routines
\7f18888
32020 Node: Exception handling routines
\7f28346
32021 Node: Miscellaneous routines
\7f29441
32022 Node: Languages
\7f29824
32023 Node: Source Tree
\7f31371
32024 Node: Configure Terms
\7f31990
32025 Node: Top Level
\7f34948
32026 Node: gcc Directory
\7f37296
32027 Node: Subdirectories
\7f38265
32028 Node: Configuration
\7f40603
32029 Node: Config Fragments
\7f41323
32030 Node: System Config
\7f42667
32031 Node: Configuration Files
\7f43603
32032 Node: Build
\7f46289
32033 Node: Makefile
\7f46701
32034 Node: Library Files
\7f50939
32035 Node: Headers
\7f51501
32036 Node: Documentation
\7f53480
32037 Node: Texinfo Manuals
\7f54330
32038 Node: Man Page Generation
\7f56512
32039 Node: Miscellaneous Docs
\7f58427
32040 Node: Front End
\7f59782
32041 Node: Front End Directory
\7f63549
32042 Node: Front End Config
\7f68898
32043 Node: Back End
\7f71816
32044 Node: Testsuites
\7f75490
32045 Node: Test Idioms
\7f76282
32046 Node: Test Directives
\7f79682
32047 Node: Ada Tests
\7f89309
32048 Node: C Tests
\7f90601
32049 Node: libgcj Tests
\7f94956
32050 Node: gcov Testing
\7f96376
32051 Node: profopt Testing
\7f99360
32052 Node: compat Testing
\7f100803
32053 Node: Options
\7f105025
32054 Node: Option file format
\7f105466
32055 Node: Option properties
\7f108016
32056 Node: Passes
\7f113482
32057 Node: Parsing pass
\7f114217
32058 Node: Gimplification pass
\7f117745
32059 Node: Pass manager
\7f119572
32060 Node: Tree-SSA passes
\7f120900
32061 Node: RTL passes
\7f136675
32062 Node: Trees
\7f148348
32063 Node: Deficiencies
\7f151074
32064 Node: Tree overview
\7f151311
32065 Node: Macros and Functions
\7f155434
32066 Node: Identifiers
\7f155580
32067 Node: Containers
\7f157105
32068 Node: Types
\7f158260
32069 Node: Scopes
\7f170868
32070 Node: Namespaces
\7f171630
32071 Node: Classes
\7f174442
32072 Node: Declarations
\7f179199
32073 Node: Working with declarations
\7f179694
32074 Node: Internal structure
\7f185566
32075 Node: Current structure hierarchy
\7f185948
32076 Node: Adding new DECL node types
\7f188040
32077 Node: Functions
\7f192111
32078 Node: Function Basics
\7f194514
32079 Node: Function Bodies
\7f201679
32080 Node: Attributes
\7f213655
32081 Node: Expression trees
\7f214896
32082 Node: Tree SSA
\7f245046
32083 Node: GENERIC
\7f246903
32084 Node: GIMPLE
\7f248513
32085 Node: Interfaces
\7f249804
32086 Node: Temporaries
\7f251682
32087 Ref: Temporaries-Footnote-1
\7f253002
32088 Node: GIMPLE Expressions
\7f253065
32089 Node: Compound Expressions
\7f253837
32090 Node: Compound Lvalues
\7f254085
32091 Node: Conditional Expressions
\7f254865
32092 Node: Logical Operators
\7f255542
32093 Node: Statements
\7f256035
32094 Node: Blocks
\7f256743
32095 Node: Statement Sequences
\7f258160
32096 Node: Empty Statements
\7f258497
32097 Node: Loops
\7f259075
32098 Node: Selection Statements
\7f259319
32099 Node: Jumps
\7f260172
32100 Node: Cleanups
\7f260817
32101 Node: GIMPLE Exception Handling
\7f262608
32102 Node: GIMPLE Example
\7f264487
32103 Node: Rough GIMPLE Grammar
\7f265898
32104 Node: Annotations
\7f271154
32105 Node: Statement Operands
\7f271820
32107 Node: Alias analysis
\7f297786
32109 Node: RTL Objects
\7f307057
32110 Node: RTL Classes
\7f310931
32111 Node: Accessors
\7f315883
32112 Node: Special Accessors
\7f318277
32113 Node: Flags
\7f322147
32114 Node: Machine Modes
\7f337601
32115 Node: Constants
\7f346326
32116 Node: Regs and Memory
\7f352581
32117 Node: Arithmetic
\7f365655
32118 Node: Comparisons
\7f373788
32119 Node: Bit-Fields
\7f378080
32120 Node: Vector Operations
\7f379632
32121 Node: Conversions
\7f381258
32122 Node: RTL Declarations
\7f384573
32123 Node: Side Effects
\7f385394
32124 Node: Incdec
\7f401510
32125 Node: Assembler
\7f404850
32126 Node: Insns
\7f406382
32127 Node: Calls
\7f432209
32128 Node: Sharing
\7f434802
32129 Node: Reading RTL
\7f437912
32130 Node: Control Flow
\7f438902
32131 Node: Basic Blocks
\7f439873
32132 Node: Edges
\7f444441
32133 Node: Profile information
\7f453003
32134 Node: Maintaining the CFG
\7f457689
32135 Node: Liveness information
\7f464581
32136 Node: Machine Desc
\7f467001
32137 Node: Overview
\7f469456
32138 Node: Patterns
\7f471497
32139 Node: Example
\7f474935
32140 Node: RTL Template
\7f476370
32141 Node: Output Template
\7f487025
32142 Node: Output Statement
\7f490991
32143 Node: Predicates
\7f494953
32144 Node: Machine-Independent Predicates
\7f497871
32145 Node: Defining Predicates
\7f502503
32146 Node: Constraints
\7f507152
32147 Node: Simple Constraints
\7f508181
32148 Node: Multi-Alternative
\7f520569
32149 Node: Class Preferences
\7f523410
32150 Node: Modifiers
\7f524302
32151 Node: Machine Constraints
\7f528428
32152 Node: Standard Names
\7f554566
32153 Ref: shift patterns
\7f567160
32154 Ref: prologue instruction pattern
\7f604238
32155 Ref: epilogue instruction pattern
\7f604731
32156 Node: Pattern Ordering
\7f613754
32157 Node: Dependent Patterns
\7f614990
32158 Node: Jump Patterns
\7f617804
32159 Node: Looping Patterns
\7f623500
32160 Node: Insn Canonicalizations
\7f628102
32161 Node: Expander Definitions
\7f632264
32162 Node: Insn Splitting
\7f640382
32163 Node: Including Patterns
\7f649978
32164 Node: Peephole Definitions
\7f651758
32165 Node: define_peephole
\7f653011
32166 Node: define_peephole2
\7f659342
32167 Node: Insn Attributes
\7f662409
32168 Node: Defining Attributes
\7f663515
32169 Node: Expressions
\7f665532
32170 Node: Tagging Insns
\7f672134
32171 Node: Attr Example
\7f676487
32172 Node: Insn Lengths
\7f678861
32173 Node: Constant Attributes
\7f681920
32174 Node: Delay Slots
\7f683089
32175 Node: Processor pipeline description
\7f686313
32176 Ref: Processor pipeline description-Footnote-1
\7f703555
32177 Node: Conditional Execution
\7f703885
32178 Node: Constant Definitions
\7f706738
32179 Node: Macros
\7f708330
32180 Node: Mode Macros
\7f708759
32181 Node: Defining Mode Macros
\7f709698
32182 Node: Substitutions
\7f711162
32183 Node: Examples
\7f713366
32184 Node: Code Macros
\7f714802
32185 Node: Target Macros
\7f717017
32186 Node: Target Structure
\7f719823
32187 Node: Driver
\7f721092
32188 Node: Run-time Target
\7f743352
32189 Node: Per-Function Data
\7f749287
32190 Node: Storage Layout
\7f752050
32191 Node: Type Layout
\7f776333
32192 Node: Registers
\7f787209
32193 Node: Register Basics
\7f788132
32194 Node: Allocation Order
\7f793699
32195 Node: Values in Registers
\7f795144
32196 Node: Leaf Functions
\7f800820
32197 Node: Stack Registers
\7f803678
32198 Node: Register Classes
\7f804794
32199 Node: Stack and Calling
\7f830967
32200 Node: Frame Layout
\7f831500
32201 Node: Exception Handling
\7f841399
32202 Node: Stack Checking
\7f847747
32203 Node: Frame Registers
\7f851376
32204 Node: Elimination
\7f857980
32205 Node: Stack Arguments
\7f862009
32206 Node: Register Arguments
\7f868584
32207 Node: Scalar Return
\7f882811
32208 Node: Aggregate Return
\7f887582
32209 Node: Caller Saves
\7f891033
32210 Node: Function Entry
\7f892209
32211 Node: Profiling
\7f904825
32212 Node: Tail Calls
\7f906481
32213 Node: Stack Smashing Protection
\7f907347
32214 Node: Varargs
\7f908457
32215 Node: Trampolines
\7f916417
32216 Node: Library Calls
\7f923192
32217 Node: Addressing Modes
\7f927612
32218 Node: Condition Code
\7f941662
32219 Node: Costs
\7f949949
32220 Node: Scheduling
\7f961949
32221 Node: Sections
\7f975004
32223 Node: Assembler Format
\7f988842
32224 Node: File Framework
\7f989921
32225 Node: Data Output
\7f995484
32226 Node: Uninitialized Data
\7f1002915
32227 Node: Label Output
\7f1008447
32228 Node: Initialization
\7f1029736
32229 Node: Macros for Initialization
\7f1035698
32230 Node: Instruction Output
\7f1041761
32231 Node: Dispatch Tables
\7f1050755
32232 Node: Exception Region Output
\7f1054240
32233 Node: Alignment Output
\7f1060118
32234 Node: Debugging Info
\7f1064262
32235 Node: All Debuggers
\7f1064932
32236 Node: DBX Options
\7f1067787
32237 Node: DBX Hooks
\7f1073236
32238 Node: File Names and DBX
\7f1075162
32239 Node: SDB and DWARF
\7f1077273
32240 Node: VMS Debug
\7f1081208
32241 Node: Floating Point
\7f1081778
32242 Node: Mode Switching
\7f1086600
32243 Node: Target Attributes
\7f1090526
32244 Node: MIPS Coprocessors
\7f1095268
32245 Node: PCH Target
\7f1096842
32246 Node: C++ ABI
\7f1098363
32247 Node: Misc
\7f1102335
32248 Ref: TARGET_SHIFT_TRUNCATION_MASK
\7f1109706
32249 Node: Host Config
\7f1144615
32250 Node: Host Common
\7f1145675
32251 Node: Filesystem
\7f1148054
32252 Node: Host Misc
\7f1152169
32253 Node: Fragments
\7f1154529
32254 Node: Target Fragment
\7f1155724
32255 Node: Host Fragment
\7f1161390
32256 Node: Collect2
\7f1162832
32257 Node: Header Dirs
\7f1165375
32258 Node: Type Information
\7f1166798
32259 Node: GTY Options
\7f1168986
32260 Node: GGC Roots
\7f1179120
32261 Node: Files
\7f1179840
32262 Node: Funding
\7f1182504
32263 Node: GNU Project
\7f1185000
32264 Node: Copying
\7f1185649
32265 Node: GNU Free Documentation License
\7f1204829
32266 Node: Contributors
\7f1227238
32267 Node: Option Index
\7f1262805
32268 Node: Concept Index
\7f1263390