1 This is doc/gccint.info, produced by makeinfo version 4.8 from 2 ../../../toolchain/android-toolchain/gcc-4.2.1/gcc/doc/gccint.texi. 3 4 Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 5 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc. 6 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". 14 15 (a) The FSF's Front-Cover Text is: 16 17 A GNU Manual 18 19 (b) The FSF's Back-Cover Text is: 20 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. 24 25 INFO-DIR-SECTION Software development 26 START-INFO-DIR-ENTRY 27 * gccint: (gccint). Internals of the GNU Compiler Collection. 28 END-INFO-DIR-ENTRY 29 This file documents the internals of the GNU compilers. 30 31 Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 32 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc. 33 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". 41 42 (a) The FSF's Front-Cover Text is: 43 44 A GNU Manual 45 46 (b) The FSF's Back-Cover Text is: 47 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. 51 52 53 54 File: gccint.info, Node: Top, Next: Contributing, Up: (DIR) 55 56 Introduction 57 ************ 58 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.2.1. 62 The use of the GNU compilers is documented in a separate manual. *Note 63 Introduction: (gcc)Top. 64 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 73 GCC. 74 75 Additional tutorial information is linked to from 76 `http://gcc.gnu.org/readings.html'. 77 78 * Menu: 79 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 * Loop Analysis and Representation:: Analysis and representation of loops 93 * Machine Desc:: How to write machine description instruction patterns. 94 * Target Macros:: How to write the machine description C macros and functions. 95 * Host Config:: Writing the `xm-MACHINE.h' file. 96 * Fragments:: Writing the `t-TARGET' and `x-HOST' files. 97 * Collect2:: How `collect2' works; how it finds `ld'. 98 * Header Dirs:: Understanding the standard header file directories. 99 * Type Information:: GCC's memory management; generating type information. 100 101 * Funding:: How to help assure funding for free software. 102 * GNU Project:: The GNU Project and GNU/Linux. 103 104 * Copying:: GNU General Public License says 105 how you can copy and share GCC. 106 * GNU Free Documentation License:: How you can copy and share this manual. 107 * Contributors:: People who have contributed to GCC. 108 109 * Option Index:: Index to command line options. 110 * Concept Index:: Index of concepts and symbol names. 111 112 113 File: gccint.info, Node: Contributing, Next: Portability, Prev: Top, Up: Top 114 115 1 Contributing to GCC Development 116 ********************************* 117 118 If you would like to help pretest GCC releases to assure they work well, 119 current development sources are available by SVN (see 120 `http://gcc.gnu.org/svn.html'). Source and binary snapshots are also 121 available for FTP; see `http://gcc.gnu.org/snapshots.html'. 122 123 If you would like to work on improvements to GCC, please read the 124 advice at these URLs: 125 126 `http://gcc.gnu.org/contribute.html' 127 `http://gcc.gnu.org/contributewhy.html' 128 129 for information on how to make useful contributions and avoid 130 duplication of effort. Suggested projects are listed at 131 `http://gcc.gnu.org/projects/'. 132 133 134 File: gccint.info, Node: Portability, Next: Interface, Prev: Contributing, Up: Top 135 136 2 GCC and Portability 137 ********************* 138 139 GCC itself aims to be portable to any machine where `int' is at least a 140 32-bit type. It aims to target machines with a flat (non-segmented) 141 byte addressed data address space (the code address space can be 142 separate). Target ABIs may have 8, 16, 32 or 64-bit `int' type. `char' 143 can be wider than 8 bits. 144 145 GCC gets most of the information about the target machine from a 146 machine description which gives an algebraic formula for each of the 147 machine's instructions. This is a very clean way to describe the 148 target. But when the compiler needs information that is difficult to 149 express in this fashion, ad-hoc parameters have been defined for 150 machine descriptions. The purpose of portability is to reduce the 151 total work needed on the compiler; it was not of interest for its own 152 sake. 153 154 GCC does not contain machine dependent code, but it does contain code 155 that depends on machine parameters such as endianness (whether the most 156 significant byte has the highest or lowest address of the bytes in a 157 word) and the availability of autoincrement addressing. In the 158 RTL-generation pass, it is often necessary to have multiple strategies 159 for generating code for a particular kind of syntax tree, strategies 160 that are usable for different combinations of parameters. Often, not 161 all possible cases have been addressed, but only the common ones or 162 only the ones that have been encountered. As a result, a new target 163 may require additional strategies. You will know if this happens 164 because the compiler will call `abort'. Fortunately, the new 165 strategies can be added in a machine-independent fashion, and will 166 affect only the target machines that need them. 167 168 169 File: gccint.info, Node: Interface, Next: Libgcc, Prev: Portability, Up: Top 170 171 3 Interfacing to GCC Output 172 *************************** 173 174 GCC is normally configured to use the same function calling convention 175 normally in use on the target system. This is done with the 176 machine-description macros described (*note Target Macros::). 177 178 However, returning of structure and union values is done differently on 179 some target machines. As a result, functions compiled with PCC 180 returning such types cannot be called from code compiled with GCC, and 181 vice versa. This does not cause trouble often because few Unix library 182 routines return structures or unions. 183 184 GCC code returns structures and unions that are 1, 2, 4 or 8 bytes 185 long in the same registers used for `int' or `double' return values. 186 (GCC typically allocates variables of such types in registers also.) 187 Structures and unions of other sizes are returned by storing them into 188 an address passed by the caller (usually in a register). The target 189 hook `TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address. 190 191 By contrast, PCC on most target machines returns structures and unions 192 of any size by copying the data into an area of static storage, and then 193 returning the address of that storage as if it were a pointer value. 194 The caller must copy the data from that memory area to the place where 195 the value is wanted. This is slower than the method used by GCC, and 196 fails to be reentrant. 197 198 On some target machines, such as RISC machines and the 80386, the 199 standard system convention is to pass to the subroutine the address of 200 where to return the value. On these machines, GCC has been configured 201 to be compatible with the standard compiler, when this method is used. 202 It may not be compatible for structures of 1, 2, 4 or 8 bytes. 203 204 GCC uses the system's standard convention for passing arguments. On 205 some machines, the first few arguments are passed in registers; in 206 others, all are passed on the stack. It would be possible to use 207 registers for argument passing on any machine, and this would probably 208 result in a significant speedup. But the result would be complete 209 incompatibility with code that follows the standard convention. So this 210 change is practical only if you are switching to GCC as the sole C 211 compiler for the system. We may implement register argument passing on 212 certain machines once we have a complete GNU system so that we can 213 compile the libraries with GCC. 214 215 On some machines (particularly the SPARC), certain types of arguments 216 are passed "by invisible reference". This means that the value is 217 stored in memory, and the address of the memory location is passed to 218 the subroutine. 219 220 If you use `longjmp', beware of automatic variables. ISO C says that 221 automatic variables that are not declared `volatile' have undefined 222 values after a `longjmp'. And this is all GCC promises to do, because 223 it is very difficult to restore register variables correctly, and one 224 of GCC's features is that it can put variables in registers without 225 your asking it to. 226 227 228 File: gccint.info, Node: Libgcc, Next: Languages, Prev: Interface, Up: Top 229 230 4 The GCC low-level runtime library 231 *********************************** 232 233 GCC provides a low-level runtime library, `libgcc.a' or `libgcc_s.so.1' 234 on some platforms. GCC generates calls to routines in this library 235 automatically, whenever it needs to perform some operation that is too 236 complicated to emit inline code for. 237 238 Most of the routines in `libgcc' handle arithmetic operations that the 239 target processor cannot perform directly. This includes integer 240 multiply and divide on some machines, and all floating-point operations 241 on other machines. `libgcc' also includes routines for exception 242 handling, and a handful of miscellaneous operations. 243 244 Some of these routines can be defined in mostly machine-independent C. 245 Others must be hand-written in assembly language for each processor 246 that needs them. 247 248 GCC will also generate calls to C library routines, such as `memcpy' 249 and `memset', in some cases. The set of routines that GCC may possibly 250 use is documented in *Note Other Builtins: (gcc)Other Builtins. 251 252 These routines take arguments and return values of a specific machine 253 mode, not a specific C type. *Note Machine Modes::, for an explanation 254 of this concept. For illustrative purposes, in this chapter the 255 floating point type `float' is assumed to correspond to `SFmode'; 256 `double' to `DFmode'; and `long double' to both `TFmode' and `XFmode'. 257 Similarly, the integer types `int' and `unsigned int' correspond to 258 `SImode'; `long' and `unsigned long' to `DImode'; and `long long' and 259 `unsigned long long' to `TImode'. 260 261 * Menu: 262 263 * Integer library routines:: 264 * Soft float library routines:: 265 * Decimal float library routines:: 266 * Exception handling routines:: 267 * Miscellaneous routines:: 268 269 270 File: gccint.info, Node: Integer library routines, Next: Soft float library routines, Up: Libgcc 271 272 4.1 Routines for integer arithmetic 273 =================================== 274 275 The integer arithmetic routines are used on platforms that don't provide 276 hardware support for arithmetic operations on some modes. 277 278 4.1.1 Arithmetic functions 279 -------------------------- 280 281 -- Runtime Function: int __ashlsi3 (int A, int B) 282 -- Runtime Function: long __ashldi3 (long A, int B) 283 -- Runtime Function: long long __ashlti3 (long long A, int B) 284 These functions return the result of shifting A left by B bits. 285 286 -- Runtime Function: int __ashrsi3 (int A, int B) 287 -- Runtime Function: long __ashrdi3 (long A, int B) 288 -- Runtime Function: long long __ashrti3 (long long A, int B) 289 These functions return the result of arithmetically shifting A 290 right by B bits. 291 292 -- Runtime Function: int __divsi3 (int A, int B) 293 -- Runtime Function: long __divdi3 (long A, long B) 294 -- Runtime Function: long long __divti3 (long long A, long long B) 295 These functions return the quotient of the signed division of A and 296 B. 297 298 -- Runtime Function: int __lshrsi3 (int A, int B) 299 -- Runtime Function: long __lshrdi3 (long A, int B) 300 -- Runtime Function: long long __lshrti3 (long long A, int B) 301 These functions return the result of logically shifting A right by 302 B bits. 303 304 -- Runtime Function: int __modsi3 (int A, int B) 305 -- Runtime Function: long __moddi3 (long A, long B) 306 -- Runtime Function: long long __modti3 (long long A, long long B) 307 These functions return the remainder of the signed division of A 308 and B. 309 310 -- Runtime Function: int __mulsi3 (int A, int B) 311 -- Runtime Function: long __muldi3 (long A, long B) 312 -- Runtime Function: long long __multi3 (long long A, long long B) 313 These functions return the product of A and B. 314 315 -- Runtime Function: long __negdi2 (long A) 316 -- Runtime Function: long long __negti2 (long long A) 317 These functions return the negation of A. 318 319 -- Runtime Function: unsigned int __udivsi3 (unsigned int A, unsigned 320 int B) 321 -- Runtime Function: unsigned long __udivdi3 (unsigned long A, 322 unsigned long B) 323 -- Runtime Function: unsigned long long __udivti3 (unsigned long long 324 A, unsigned long long B) 325 These functions return the quotient of the unsigned division of A 326 and B. 327 328 -- Runtime Function: unsigned long __udivmoddi3 (unsigned long A, 329 unsigned long B, unsigned long *C) 330 -- Runtime Function: unsigned long long __udivti3 (unsigned long long 331 A, unsigned long long B, unsigned long long *C) 332 These functions calculate both the quotient and remainder of the 333 unsigned division of A and B. The return value is the quotient, 334 and the remainder is placed in variable pointed to by C. 335 336 -- Runtime Function: unsigned int __umodsi3 (unsigned int A, unsigned 337 int B) 338 -- Runtime Function: unsigned long __umoddi3 (unsigned long A, 339 unsigned long B) 340 -- Runtime Function: unsigned long long __umodti3 (unsigned long long 341 A, unsigned long long B) 342 These functions return the remainder of the unsigned division of A 343 and B. 344 345 4.1.2 Comparison functions 346 -------------------------- 347 348 The following functions implement integral comparisons. These functions 349 implement a low-level compare, upon which the higher level comparison 350 operators (such as less than and greater than or equal to) can be 351 constructed. The returned values lie in the range zero to two, to allow 352 the high-level operators to be implemented by testing the returned 353 result using either signed or unsigned comparison. 354 355 -- Runtime Function: int __cmpdi2 (long A, long B) 356 -- Runtime Function: int __cmpti2 (long long A, long long B) 357 These functions perform a signed comparison of A and B. If A is 358 less than B, they return 0; if A is greater than B, they return 2; 359 and if A and B are equal they return 1. 360 361 -- Runtime Function: int __ucmpdi2 (unsigned long A, unsigned long B) 362 -- Runtime Function: int __ucmpti2 (unsigned long long A, unsigned 363 long long B) 364 These functions perform an unsigned comparison of A and B. If A 365 is less than B, they return 0; if A is greater than B, they return 366 2; and if A and B are equal they return 1. 367 368 4.1.3 Trapping arithmetic functions 369 ----------------------------------- 370 371 The following functions implement trapping arithmetic. These functions 372 call the libc function `abort' upon signed arithmetic overflow. 373 374 -- Runtime Function: int __absvsi2 (int A) 375 -- Runtime Function: long __absvdi2 (long A) 376 These functions return the absolute value of A. 377 378 -- Runtime Function: int __addvsi3 (int A, int B) 379 -- Runtime Function: long __addvdi3 (long A, long B) 380 These functions return the sum of A and B; that is `A + B'. 381 382 -- Runtime Function: int __mulvsi3 (int A, int B) 383 -- Runtime Function: long __mulvdi3 (long A, long B) 384 The functions return the product of A and B; that is `A * B'. 385 386 -- Runtime Function: int __negvsi2 (int A) 387 -- Runtime Function: long __negvdi2 (long A) 388 These functions return the negation of A; that is `-A'. 389 390 -- Runtime Function: int __subvsi3 (int A, int B) 391 -- Runtime Function: long __subvdi3 (long A, long B) 392 These functions return the difference between B and A; that is `A 393 - B'. 394 395 4.1.4 Bit operations 396 -------------------- 397 398 -- Runtime Function: int __clzsi2 (int A) 399 -- Runtime Function: int __clzdi2 (long A) 400 -- Runtime Function: int __clzti2 (long long A) 401 These functions return the number of leading 0-bits in A, starting 402 at the most significant bit position. If A is zero, the result is 403 undefined. 404 405 -- Runtime Function: int __ctzsi2 (int A) 406 -- Runtime Function: int __ctzdi2 (long A) 407 -- Runtime Function: int __ctzti2 (long long A) 408 These functions return the number of trailing 0-bits in A, starting 409 at the least significant bit position. If A is zero, the result is 410 undefined. 411 412 -- Runtime Function: int __ffsdi2 (long A) 413 -- Runtime Function: int __ffsti2 (long long A) 414 These functions return the index of the least significant 1-bit in 415 A, or the value zero if A is zero. The least significant bit is 416 index one. 417 418 -- Runtime Function: int __paritysi2 (int A) 419 -- Runtime Function: int __paritydi2 (long A) 420 -- Runtime Function: int __parityti2 (long long A) 421 These functions return the value zero if the number of bits set in 422 A is even, and the value one otherwise. 423 424 -- Runtime Function: int __popcountsi2 (int A) 425 -- Runtime Function: int __popcountdi2 (long A) 426 -- Runtime Function: int __popcountti2 (long long A) 427 These functions return the number of bits set in A. 428 429 430 File: gccint.info, Node: Soft float library routines, Next: Decimal float library routines, Prev: Integer library routines, Up: Libgcc 431 432 4.2 Routines for floating point emulation 433 ========================================= 434 435 The software floating point library is used on machines which do not 436 have hardware support for floating point. It is also used whenever 437 `-msoft-float' is used to disable generation of floating point 438 instructions. (Not all targets support this switch.) 439 440 For compatibility with other compilers, the floating point emulation 441 routines can be renamed with the `DECLARE_LIBRARY_RENAMES' macro (*note 442 Library Calls::). In this section, the default names are used. 443 444 Presently the library does not support `XFmode', which is used for 445 `long double' on some architectures. 446 447 4.2.1 Arithmetic functions 448 -------------------------- 449 450 -- Runtime Function: float __addsf3 (float A, float B) 451 -- Runtime Function: double __adddf3 (double A, double B) 452 -- Runtime Function: long double __addtf3 (long double A, long double 453 B) 454 -- Runtime Function: long double __addxf3 (long double A, long double 455 B) 456 These functions return the sum of A and B. 457 458 -- Runtime Function: float __subsf3 (float A, float B) 459 -- Runtime Function: double __subdf3 (double A, double B) 460 -- Runtime Function: long double __subtf3 (long double A, long double 461 B) 462 -- Runtime Function: long double __subxf3 (long double A, long double 463 B) 464 These functions return the difference between B and A; that is, 465 A - B. 466 467 -- Runtime Function: float __mulsf3 (float A, float B) 468 -- Runtime Function: double __muldf3 (double A, double B) 469 -- Runtime Function: long double __multf3 (long double A, long double 470 B) 471 -- Runtime Function: long double __mulxf3 (long double A, long double 472 B) 473 These functions return the product of A and B. 474 475 -- Runtime Function: float __divsf3 (float A, float B) 476 -- Runtime Function: double __divdf3 (double A, double B) 477 -- Runtime Function: long double __divtf3 (long double A, long double 478 B) 479 -- Runtime Function: long double __divxf3 (long double A, long double 480 B) 481 These functions return the quotient of A and B; that is, A / B. 482 483 -- Runtime Function: float __negsf2 (float A) 484 -- Runtime Function: double __negdf2 (double A) 485 -- Runtime Function: long double __negtf2 (long double A) 486 -- Runtime Function: long double __negxf2 (long double A) 487 These functions return the negation of A. They simply flip the 488 sign bit, so they can produce negative zero and negative NaN. 489 490 4.2.2 Conversion functions 491 -------------------------- 492 493 -- Runtime Function: double __extendsfdf2 (float A) 494 -- Runtime Function: long double __extendsftf2 (float A) 495 -- Runtime Function: long double __extendsfxf2 (float A) 496 -- Runtime Function: long double __extenddftf2 (double A) 497 -- Runtime Function: long double __extenddfxf2 (double A) 498 These functions extend A to the wider mode of their return type. 499 500 -- Runtime Function: double __truncxfdf2 (long double A) 501 -- Runtime Function: double __trunctfdf2 (long double A) 502 -- Runtime Function: float __truncxfsf2 (long double A) 503 -- Runtime Function: float __trunctfsf2 (long double A) 504 -- Runtime Function: float __truncdfsf2 (double A) 505 These functions truncate A to the narrower mode of their return 506 type, rounding toward zero. 507 508 -- Runtime Function: int __fixsfsi (float A) 509 -- Runtime Function: int __fixdfsi (double A) 510 -- Runtime Function: int __fixtfsi (long double A) 511 -- Runtime Function: int __fixxfsi (long double A) 512 These functions convert A to a signed integer, rounding toward 513 zero. 514 515 -- Runtime Function: long __fixsfdi (float A) 516 -- Runtime Function: long __fixdfdi (double A) 517 -- Runtime Function: long __fixtfdi (long double A) 518 -- Runtime Function: long __fixxfdi (long double A) 519 These functions convert A to a signed long, rounding toward zero. 520 521 -- Runtime Function: long long __fixsfti (float A) 522 -- Runtime Function: long long __fixdfti (double A) 523 -- Runtime Function: long long __fixtfti (long double A) 524 -- Runtime Function: long long __fixxfti (long double A) 525 These functions convert A to a signed long long, rounding toward 526 zero. 527 528 -- Runtime Function: unsigned int __fixunssfsi (float A) 529 -- Runtime Function: unsigned int __fixunsdfsi (double A) 530 -- Runtime Function: unsigned int __fixunstfsi (long double A) 531 -- Runtime Function: unsigned int __fixunsxfsi (long double A) 532 These functions convert A to an unsigned integer, rounding toward 533 zero. Negative values all become zero. 534 535 -- Runtime Function: unsigned long __fixunssfdi (float A) 536 -- Runtime Function: unsigned long __fixunsdfdi (double A) 537 -- Runtime Function: unsigned long __fixunstfdi (long double A) 538 -- Runtime Function: unsigned long __fixunsxfdi (long double A) 539 These functions convert A to an unsigned long, rounding toward 540 zero. Negative values all become zero. 541 542 -- Runtime Function: unsigned long long __fixunssfti (float A) 543 -- Runtime Function: unsigned long long __fixunsdfti (double A) 544 -- Runtime Function: unsigned long long __fixunstfti (long double A) 545 -- Runtime Function: unsigned long long __fixunsxfti (long double A) 546 These functions convert A to an unsigned long long, rounding 547 toward zero. Negative values all become zero. 548 549 -- Runtime Function: float __floatsisf (int I) 550 -- Runtime Function: double __floatsidf (int I) 551 -- Runtime Function: long double __floatsitf (int I) 552 -- Runtime Function: long double __floatsixf (int I) 553 These functions convert I, a signed integer, to floating point. 554 555 -- Runtime Function: float __floatdisf (long I) 556 -- Runtime Function: double __floatdidf (long I) 557 -- Runtime Function: long double __floatditf (long I) 558 -- Runtime Function: long double __floatdixf (long I) 559 These functions convert I, a signed long, to floating point. 560 561 -- Runtime Function: float __floattisf (long long I) 562 -- Runtime Function: double __floattidf (long long I) 563 -- Runtime Function: long double __floattitf (long long I) 564 -- Runtime Function: long double __floattixf (long long I) 565 These functions convert I, a signed long long, to floating point. 566 567 -- Runtime Function: float __floatunsisf (unsigned int I) 568 -- Runtime Function: double __floatunsidf (unsigned int I) 569 -- Runtime Function: long double __floatunsitf (unsigned int I) 570 -- Runtime Function: long double __floatunsixf (unsigned int I) 571 These functions convert I, an unsigned integer, to floating point. 572 573 -- Runtime Function: float __floatundisf (unsigned long I) 574 -- Runtime Function: double __floatundidf (unsigned long I) 575 -- Runtime Function: long double __floatunditf (unsigned long I) 576 -- Runtime Function: long double __floatundixf (unsigned long I) 577 These functions convert I, an unsigned long, to floating point. 578 579 -- Runtime Function: float __floatuntisf (unsigned long long I) 580 -- Runtime Function: double __floatuntidf (unsigned long long I) 581 -- Runtime Function: long double __floatuntitf (unsigned long long I) 582 -- Runtime Function: long double __floatuntixf (unsigned long long I) 583 These functions convert I, an unsigned long long, to floating 584 point. 585 586 4.2.3 Comparison functions 587 -------------------------- 588 589 There are two sets of basic comparison functions. 590 591 -- Runtime Function: int __cmpsf2 (float A, float B) 592 -- Runtime Function: int __cmpdf2 (double A, double B) 593 -- Runtime Function: int __cmptf2 (long double A, long double B) 594 These functions calculate a <=> b. That is, if A is less than B, 595 they return -1; if A is greater than B, they return 1; and if A 596 and B are equal they return 0. If either argument is NaN they 597 return 1, but you should not rely on this; if NaN is a 598 possibility, use one of the higher-level comparison functions. 599 600 -- Runtime Function: int __unordsf2 (float A, float B) 601 -- Runtime Function: int __unorddf2 (double A, double B) 602 -- Runtime Function: int __unordtf2 (long double A, long double B) 603 These functions return a nonzero value if either argument is NaN, 604 otherwise 0. 605 606 There is also a complete group of higher level functions which 607 correspond directly to comparison operators. They implement the ISO C 608 semantics for floating-point comparisons, taking NaN into account. Pay 609 careful attention to the return values defined for each set. Under the 610 hood, all of these routines are implemented as 611 612 if (__unordXf2 (a, b)) 613 return E; 614 return __cmpXf2 (a, b); 615 616 where E is a constant chosen to give the proper behavior for NaN. 617 Thus, the meaning of the return value is different for each set. Do 618 not rely on this implementation; only the semantics documented below 619 are guaranteed. 620 621 -- Runtime Function: int __eqsf2 (float A, float B) 622 -- Runtime Function: int __eqdf2 (double A, double B) 623 -- Runtime Function: int __eqtf2 (long double A, long double B) 624 These functions return zero if neither argument is NaN, and A and 625 B are equal. 626 627 -- Runtime Function: int __nesf2 (float A, float B) 628 -- Runtime Function: int __nedf2 (double A, double B) 629 -- Runtime Function: int __netf2 (long double A, long double B) 630 These functions return a nonzero value if either argument is NaN, 631 or if A and B are unequal. 632 633 -- Runtime Function: int __gesf2 (float A, float B) 634 -- Runtime Function: int __gedf2 (double A, double B) 635 -- Runtime Function: int __getf2 (long double A, long double B) 636 These functions return a value greater than or equal to zero if 637 neither argument is NaN, and A is greater than or equal to B. 638 639 -- Runtime Function: int __ltsf2 (float A, float B) 640 -- Runtime Function: int __ltdf2 (double A, double B) 641 -- Runtime Function: int __lttf2 (long double A, long double B) 642 These functions return a value less than zero if neither argument 643 is NaN, and A is strictly less than B. 644 645 -- Runtime Function: int __lesf2 (float A, float B) 646 -- Runtime Function: int __ledf2 (double A, double B) 647 -- Runtime Function: int __letf2 (long double A, long double B) 648 These functions return a value less than or equal to zero if 649 neither argument is NaN, and A is less than or equal to B. 650 651 -- Runtime Function: int __gtsf2 (float A, float B) 652 -- Runtime Function: int __gtdf2 (double A, double B) 653 -- Runtime Function: int __gttf2 (long double A, long double B) 654 These functions return a value greater than zero if neither 655 argument is NaN, and A is strictly greater than B. 656 657 4.2.4 Other floating-point functions 658 ------------------------------------ 659 660 -- Runtime Function: float __powisf2 (float A, int B) 661 -- Runtime Function: double __powidf2 (double A, int B) 662 -- Runtime Function: long double __powitf2 (long double A, int B) 663 -- Runtime Function: long double __powixf2 (long double A, int B) 664 These functions convert raise A to the power B. 665 666 -- Runtime Function: complex float __mulsc3 (float A, float B, float 667 C, float D) 668 -- Runtime Function: complex double __muldc3 (double A, double B, 669 double C, double D) 670 -- Runtime Function: complex long double __multc3 (long double A, long 671 double B, long double C, long double D) 672 -- Runtime Function: complex long double __mulxc3 (long double A, long 673 double B, long double C, long double D) 674 These functions return the product of A + iB and C + iD, following 675 the rules of C99 Annex G. 676 677 -- Runtime Function: complex float __divsc3 (float A, float B, float 678 C, float D) 679 -- Runtime Function: complex double __divdc3 (double A, double B, 680 double C, double D) 681 -- Runtime Function: complex long double __divtc3 (long double A, long 682 double B, long double C, long double D) 683 -- Runtime Function: complex long double __divxc3 (long double A, long 684 double B, long double C, long double D) 685 These functions return the quotient of A + iB and C + iD (i.e., (A 686 + iB) / (C + iD)), following the rules of C99 Annex G. 687 688 689 File: gccint.info, Node: Decimal float library routines, Next: Exception handling routines, Prev: Soft float library routines, Up: Libgcc 690 691 4.3 Routines for decimal floating point emulation 692 ================================================= 693 694 The software decimal floating point library implements IEEE 754R 695 decimal floating point arithmetic and is only activated on selected 696 targets. 697 698 4.3.1 Arithmetic functions 699 -------------------------- 700 701 -- Runtime Function: _Decimal32 __addsd3 (_Decimal32 A, _Decimal32 B) 702 -- Runtime Function: _Decimal64 __adddd3 (_Decimal64 A, _Decimal64 B) 703 -- Runtime Function: _Decimal128 __addtd3 (_Decimal128 A, _Decimal128 704 B) 705 These functions return the sum of A and B. 706 707 -- Runtime Function: _Decimal32 __subsd3 (_Decimal32 A, _Decimal32 B) 708 -- Runtime Function: _Decimal64 __subdd3 (_Decimal64 A, _Decimal64 B) 709 -- Runtime Function: _Decimal128 __subtd3 (_Decimal128 A, _Decimal128 710 B) 711 These functions return the difference between B and A; that is, 712 A - B. 713 714 -- Runtime Function: _Decimal32 __mulsd3 (_Decimal32 A, _Decimal32 B) 715 -- Runtime Function: _Decimal64 __muldd3 (_Decimal64 A, _Decimal64 B) 716 -- Runtime Function: _Decimal128 __multd3 (_Decimal128 A, _Decimal128 717 B) 718 These functions return the product of A and B. 719 720 -- Runtime Function: _Decimal32 __divsd3 (_Decimal32 A, _Decimal32 B) 721 -- Runtime Function: _Decimal64 __divdd3 (_Decimal64 A, _Decimal64 B) 722 -- Runtime Function: _Decimal128 __divtd3 (_Decimal128 A, _Decimal128 723 B) 724 These functions return the quotient of A and B; that is, A / B. 725 726 -- Runtime Function: _Decimal32 __negsd2 (_Decimal32 A) 727 -- Runtime Function: _Decimal64 __negdd2 (_Decimal64 A) 728 -- Runtime Function: _Decimal128 __negtd2 (_Decimal128 A) 729 These functions return the negation of A. They simply flip the 730 sign bit, so they can produce negative zero and negative NaN. 731 732 4.3.2 Conversion functions 733 -------------------------- 734 735 -- Runtime Function: _Decimal64 __extendsddd2 (_Decimal32 A) 736 -- Runtime Function: _Decimal128 __extendsdtd2 (_Decimal32 A) 737 -- Runtime Function: _Decimal128 __extendddtd2 (_Decimal64 A) 738 -- Runtime Function: _Decimal32 __extendsfsd (float A) 739 -- Runtime Function: double __extendsddf (_Decimal32 A) 740 -- Runtime Function: long double __extendsdxf (_Decimal32 A) 741 -- Runtime Function: _Decimal64 __extendsfdd (float A) 742 -- Runtime Function: _Decimal64 __extenddfdd (double A) 743 -- Runtime Function: long double __extendddxf (_Decimal64 A) 744 -- Runtime Function: _Decimal128 __extendsftd (float A) 745 -- Runtime Function: _Decimal128 __extenddftd (double A) 746 -- Runtime Function: _Decimal128 __extendxftd (long double A) 747 These functions extend A to the wider mode of their return type. 748 749 -- Runtime Function: _Decimal32 __truncddsd2 (_Decimal64 A) 750 -- Runtime Function: _Decimal32 __trunctdsd2 (_Decimal128 A) 751 -- Runtime Function: _Decimal64 __trunctddd2 (_Decimal128 A) 752 -- Runtime Function: float __truncsdsf (_Decimal32 A) 753 -- Runtime Function: _Decimal32 __truncdfsd (double A) 754 -- Runtime Function: _Decimal32 __truncxfsd (long double A) 755 -- Runtime Function: float __truncddsf (_Decimal64 A) 756 -- Runtime Function: double __truncdddf (_Decimal64 A) 757 -- Runtime Function: _Decimal64 __truncxfdd (long double A) 758 -- Runtime Function: float __trunctdsf (_Decimal128 A) 759 -- Runtime Function: double __trunctddf (_Decimal128 A) 760 -- Runtime Function: long double __trunctdxf (_Decimal128 A) 761 These functions truncate A to the narrower mode of their return 762 type. 763 764 -- Runtime Function: int __fixsdsi (_Decimal32 A) 765 -- Runtime Function: int __fixddsi (_Decimal64 A) 766 -- Runtime Function: int __fixtdsi (_Decimal128 A) 767 These functions convert A to a signed integer. 768 769 -- Runtime Function: long __fixsddi (_Decimal32 A) 770 -- Runtime Function: long __fixdddi (_Decimal64 A) 771 -- Runtime Function: long __fixtddi (_Decimal128 A) 772 These functions convert A to a signed long. 773 774 -- Runtime Function: unsigned int __fixunssdsi (_Decimal32 A) 775 -- Runtime Function: unsigned int __fixunsddsi (_Decimal64 A) 776 -- Runtime Function: unsigned int __fixunstdsi (_Decimal128 A) 777 These functions convert A to an unsigned integer. Negative values 778 all become zero. 779 780 -- Runtime Function: unsigned long __fixunssddi (_Decimal32 A) 781 -- Runtime Function: unsigned long __fixunsdddi (_Decimal64 A) 782 -- Runtime Function: unsigned long __fixunstddi (_Decimal128 A) 783 These functions convert A to an unsigned long. Negative values 784 all become zero. 785 786 -- Runtime Function: _Decimal32 __floatsisd (int I) 787 -- Runtime Function: _Decimal64 __floatsidd (int I) 788 -- Runtime Function: _Decimal128 __floatsitd (int I) 789 These functions convert I, a signed integer, to decimal floating 790 point. 791 792 -- Runtime Function: _Decimal32 __floatdisd (long I) 793 -- Runtime Function: _Decimal64 __floatdidd (long I) 794 -- Runtime Function: _Decimal128 __floatditd (long I) 795 These functions convert I, a signed long, to decimal floating 796 point. 797 798 -- Runtime Function: _Decimal32 __floatunssisd (unsigned int I) 799 -- Runtime Function: _Decimal64 __floatunssidd (unsigned int I) 800 -- Runtime Function: _Decimal128 __floatunssitd (unsigned int I) 801 These functions convert I, an unsigned integer, to decimal 802 floating point. 803 804 -- Runtime Function: _Decimal32 __floatunsdisd (unsigned long I) 805 -- Runtime Function: _Decimal64 __floatunsdidd (unsigned long I) 806 -- Runtime Function: _Decimal128 __floatunsditd (unsigned long I) 807 These functions convert I, an unsigned long, to decimal floating 808 point. 809 810 4.3.3 Comparison functions 811 -------------------------- 812 813 -- Runtime Function: int __unordsd2 (_Decimal32 A, _Decimal32 B) 814 -- Runtime Function: int __unorddd2 (_Decimal64 A, _Decimal64 B) 815 -- Runtime Function: int __unordtd2 (_Decimal128 A, _Decimal128 B) 816 These functions return a nonzero value if either argument is NaN, 817 otherwise 0. 818 819 There is also a complete group of higher level functions which 820 correspond directly to comparison operators. They implement the ISO C 821 semantics for floating-point comparisons, taking NaN into account. Pay 822 careful attention to the return values defined for each set. Under the 823 hood, all of these routines are implemented as 824 825 if (__unordXd2 (a, b)) 826 return E; 827 return __cmpXd2 (a, b); 828 829 where E is a constant chosen to give the proper behavior for NaN. 830 Thus, the meaning of the return value is different for each set. Do 831 not rely on this implementation; only the semantics documented below 832 are guaranteed. 833 834 -- Runtime Function: int __eqsd2 (_Decimal32 A, _Decimal32 B) 835 -- Runtime Function: int __eqdd2 (_Decimal64 A, _Decimal64 B) 836 -- Runtime Function: int __eqtd2 (_Decimal128 A, _Decimal128 B) 837 These functions return zero if neither argument is NaN, and A and 838 B are equal. 839 840 -- Runtime Function: int __nesd2 (_Decimal32 A, _Decimal32 B) 841 -- Runtime Function: int __nedd2 (_Decimal64 A, _Decimal64 B) 842 -- Runtime Function: int __netd2 (_Decimal128 A, _Decimal128 B) 843 These functions return a nonzero value if either argument is NaN, 844 or if A and B are unequal. 845 846 -- Runtime Function: int __gesd2 (_Decimal32 A, _Decimal32 B) 847 -- Runtime Function: int __gedd2 (_Decimal64 A, _Decimal64 B) 848 -- Runtime Function: int __getd2 (_Decimal128 A, _Decimal128 B) 849 These functions return a value greater than or equal to zero if 850 neither argument is NaN, and A is greater than or equal to B. 851 852 -- Runtime Function: int __ltsd2 (_Decimal32 A, _Decimal32 B) 853 -- Runtime Function: int __ltdd2 (_Decimal64 A, _Decimal64 B) 854 -- Runtime Function: int __lttd2 (_Decimal128 A, _Decimal128 B) 855 These functions return a value less than zero if neither argument 856 is NaN, and A is strictly less than B. 857 858 -- Runtime Function: int __lesd2 (_Decimal32 A, _Decimal32 B) 859 -- Runtime Function: int __ledd2 (_Decimal64 A, _Decimal64 B) 860 -- Runtime Function: int __letd2 (_Decimal128 A, _Decimal128 B) 861 These functions return a value less than or equal to zero if 862 neither argument is NaN, and A is less than or equal to B. 863 864 -- Runtime Function: int __gtsd2 (_Decimal32 A, _Decimal32 B) 865 -- Runtime Function: int __gtdd2 (_Decimal64 A, _Decimal64 B) 866 -- Runtime Function: int __gttd2 (_Decimal128 A, _Decimal128 B) 867 These functions return a value greater than zero if neither 868 argument is NaN, and A is strictly greater than B. 869 870 871 File: gccint.info, Node: Exception handling routines, Next: Miscellaneous routines, Prev: Decimal float library routines, Up: Libgcc 872 873 4.4 Language-independent routines for exception handling 874 ======================================================== 875 876 document me! 877 878 _Unwind_DeleteException 879 _Unwind_Find_FDE 880 _Unwind_ForcedUnwind 881 _Unwind_GetGR 882 _Unwind_GetIP 883 _Unwind_GetLanguageSpecificData 884 _Unwind_GetRegionStart 885 _Unwind_GetTextRelBase 886 _Unwind_GetDataRelBase 887 _Unwind_RaiseException 888 _Unwind_Resume 889 _Unwind_SetGR 890 _Unwind_SetIP 891 _Unwind_FindEnclosingFunction 892 _Unwind_SjLj_Register 893 _Unwind_SjLj_Unregister 894 _Unwind_SjLj_RaiseException 895 _Unwind_SjLj_ForcedUnwind 896 _Unwind_SjLj_Resume 897 __deregister_frame 898 __deregister_frame_info 899 __deregister_frame_info_bases 900 __register_frame 901 __register_frame_info 902 __register_frame_info_bases 903 __register_frame_info_table 904 __register_frame_info_table_bases 905 __register_frame_table 906 907 908 File: gccint.info, Node: Miscellaneous routines, Prev: Exception handling routines, Up: Libgcc 909 910 4.5 Miscellaneous runtime library routines 911 ========================================== 912 913 4.5.1 Cache control functions 914 ----------------------------- 915 916 -- Runtime Function: void __clear_cache (char *BEG, char *END) 917 This function clears the instruction cache between BEG and END. 918 919 920 File: gccint.info, Node: Languages, Next: Source Tree, Prev: Libgcc, Up: Top 921 922 5 Language Front Ends in GCC 923 **************************** 924 925 The interface to front ends for languages in GCC, and in particular the 926 `tree' structure (*note Trees::), was initially designed for C, and 927 many aspects of it are still somewhat biased towards C and C-like 928 languages. It is, however, reasonably well suited to other procedural 929 languages, and front ends for many such languages have been written for 930 GCC. 931 932 Writing a compiler as a front end for GCC, rather than compiling 933 directly to assembler or generating C code which is then compiled by 934 GCC, has several advantages: 935 936 * GCC front ends benefit from the support for many different target 937 machines already present in GCC. 938 939 * GCC front ends benefit from all the optimizations in GCC. Some of 940 these, such as alias analysis, may work better when GCC is 941 compiling directly from source code then when it is compiling from 942 generated C code. 943 944 * Better debugging information is generated when compiling directly 945 from source code than when going via intermediate generated C code. 946 947 Because of the advantages of writing a compiler as a GCC front end, 948 GCC front ends have also been created for languages very different from 949 those for which GCC was designed, such as the declarative 950 logic/functional language Mercury. For these reasons, it may also be 951 useful to implement compilers created for specialized purposes (for 952 example, as part of a research project) as GCC front ends. 953 954 955 File: gccint.info, Node: Source Tree, Next: Options, Prev: Languages, Up: Top 956 957 6 Source Tree Structure and Build System 958 **************************************** 959 960 This chapter describes the structure of the GCC source tree, and how 961 GCC is built. The user documentation for building and installing GCC 962 is in a separate manual (`http://gcc.gnu.org/install/'), with which it 963 is presumed that you are familiar. 964 965 * Menu: 966 967 * Configure Terms:: Configuration terminology and history. 968 * Top Level:: The top level source directory. 969 * gcc Directory:: The `gcc' subdirectory. 970 * Testsuites:: The GCC testsuites. 971 972 973 File: gccint.info, Node: Configure Terms, Next: Top Level, Up: Source Tree 974 975 6.1 Configure Terms and History 976 =============================== 977 978 The configure and build process has a long and colorful history, and can 979 be confusing to anyone who doesn't know why things are the way they are. 980 While there are other documents which describe the configuration process 981 in detail, here are a few things that everyone working on GCC should 982 know. 983 984 There are three system names that the build knows about: the machine 985 you are building on ("build"), the machine that you are building for 986 ("host"), and the machine that GCC will produce code for ("target"). 987 When you configure GCC, you specify these with `--build=', `--host=', 988 and `--target='. 989 990 Specifying the host without specifying the build should be avoided, as 991 `configure' may (and once did) assume that the host you specify is also 992 the build, which may not be true. 993 994 If build, host, and target are all the same, this is called a 995 "native". If build and host are the same but target is different, this 996 is called a "cross". If build, host, and target are all different this 997 is called a "canadian" (for obscure reasons dealing with Canada's 998 political party and the background of the person working on the build 999 at that time). If host and target are the same, but build is 1000 different, you are using a cross-compiler to build a native for a 1001 different system. Some people call this a "host-x-host", "crossed 1002 native", or "cross-built native". If build and target are the same, 1003 but host is different, you are using a cross compiler to build a cross 1004 compiler that produces code for the machine you're building on. This 1005 is rare, so there is no common way of describing it. There is a 1006 proposal to call this a "crossback". 1007 1008 If build and host are the same, the GCC you are building will also be 1009 used to build the target libraries (like `libstdc++'). If build and 1010 host are different, you must have already build and installed a cross 1011 compiler that will be used to build the target libraries (if you 1012 configured with `--target=foo-bar', this compiler will be called 1013 `foo-bar-gcc'). 1014 1015 In the case of target libraries, the machine you're building for is the 1016 machine you specified with `--target'. So, build is the machine you're 1017 building on (no change there), host is the machine you're building for 1018 (the target libraries are built for the target, so host is the target 1019 you specified), and target doesn't apply (because you're not building a 1020 compiler, you're building libraries). The configure/make process will 1021 adjust these variables as needed. It also sets `$with_cross_host' to 1022 the original `--host' value in case you need it. 1023 1024 The `libiberty' support library is built up to three times: once for 1025 the host, once for the target (even if they are the same), and once for 1026 the build if build and host are different. This allows it to be used 1027 by all programs which are generated in the course of the build process. 1028 1029 1030 File: gccint.info, Node: Top Level, Next: gcc Directory, Prev: Configure Terms, Up: Source Tree 1031 1032 6.2 Top Level Source Directory 1033 ============================== 1034 1035 The top level source directory in a GCC distribution contains several 1036 files and directories that are shared with other software distributions 1037 such as that of GNU Binutils. It also contains several subdirectories 1038 that contain parts of GCC and its runtime libraries: 1039 1040 `boehm-gc' 1041 The Boehm conservative garbage collector, used as part of the Java 1042 runtime library. 1043 1044 `contrib' 1045 Contributed scripts that may be found useful in conjunction with 1046 GCC. One of these, `contrib/texi2pod.pl', is used to generate man 1047 pages from Texinfo manuals as part of the GCC build process. 1048 1049 `fastjar' 1050 An implementation of the `jar' command, used with the Java front 1051 end. 1052 1053 `gcc' 1054 The main sources of GCC itself (except for runtime libraries), 1055 including optimizers, support for different target architectures, 1056 language front ends, and testsuites. *Note The `gcc' 1057 Subdirectory: gcc Directory, for details. 1058 1059 `include' 1060 Headers for the `libiberty' library. 1061 1062 `libada' 1063 The Ada runtime library. 1064 1065 `libcpp' 1066 The C preprocessor library. 1067 1068 `libgfortran' 1069 The Fortran runtime library. 1070 1071 `libffi' 1072 The `libffi' library, used as part of the Java runtime library. 1073 1074 `libiberty' 1075 The `libiberty' library, used for portability and for some 1076 generally useful data structures and algorithms. *Note 1077 Introduction: (libiberty)Top, for more information about this 1078 library. 1079 1080 `libjava' 1081 The Java runtime library. 1082 1083 `libmudflap' 1084 The `libmudflap' library, used for instrumenting pointer and array 1085 dereferencing operations. 1086 1087 `libobjc' 1088 The Objective-C and Objective-C++ runtime library. 1089 1090 `libstdc++-v3' 1091 The C++ runtime library. 1092 1093 `maintainer-scripts' 1094 Scripts used by the `gccadmin' account on `gcc.gnu.org'. 1095 1096 `zlib' 1097 The `zlib' compression library, used by the Java front end and as 1098 part of the Java runtime library. 1099 1100 The build system in the top level directory, including how recursion 1101 into subdirectories works and how building runtime libraries for 1102 multilibs is handled, is documented in a separate manual, included with 1103 GNU Binutils. *Note GNU configure and build system: (configure)Top, 1104 for details. 1105 1106 1107 File: gccint.info, Node: gcc Directory, Next: Testsuites, Prev: Top Level, Up: Source Tree 1108 1109 6.3 The `gcc' Subdirectory 1110 ========================== 1111 1112 The `gcc' directory contains many files that are part of the C sources 1113 of GCC, other files used as part of the configuration and build 1114 process, and subdirectories including documentation and a testsuite. 1115 The files that are sources of GCC are documented in a separate chapter. 1116 *Note Passes and Files of the Compiler: Passes. 1117 1118 * Menu: 1119 1120 * Subdirectories:: Subdirectories of `gcc'. 1121 * Configuration:: The configuration process, and the files it uses. 1122 * Build:: The build system in the `gcc' directory. 1123 * Makefile:: Targets in `gcc/Makefile'. 1124 * Library Files:: Library source files and headers under `gcc/'. 1125 * Headers:: Headers installed by GCC. 1126 * Documentation:: Building documentation in GCC. 1127 * Front End:: Anatomy of a language front end. 1128 * Back End:: Anatomy of a target back end. 1129 1130 1131 File: gccint.info, Node: Subdirectories, Next: Configuration, Up: gcc Directory 1132 1133 6.3.1 Subdirectories of `gcc' 1134 ----------------------------- 1135 1136 The `gcc' directory contains the following subdirectories: 1137 1138 `LANGUAGE' 1139 Subdirectories for various languages. Directories containing a 1140 file `config-lang.in' are language subdirectories. The contents of 1141 the subdirectories `cp' (for C++), `objc' (for Objective-C) and 1142 `objcp' (for Objective-C++) are documented in this manual (*note 1143 Passes and Files of the Compiler: Passes.); those for other 1144 languages are not. *Note Anatomy of a Language Front End: Front 1145 End, for details of the files in these directories. 1146 1147 `config' 1148 Configuration files for supported architectures and operating 1149 systems. *Note Anatomy of a Target Back End: Back End, for 1150 details of the files in this directory. 1151 1152 `doc' 1153 Texinfo documentation for GCC, together with automatically 1154 generated man pages and support for converting the installation 1155 manual to HTML. *Note Documentation::. 1156 1157 `fixinc' 1158 The support for fixing system headers to work with GCC. See 1159 `fixinc/README' for more information. The headers fixed by this 1160 mechanism are installed in `LIBSUBDIR/include'. Along with those 1161 headers, `README-fixinc' is also installed, as 1162 `LIBSUBDIR/include/README'. 1163 1164 `ginclude' 1165 System headers installed by GCC, mainly those required by the C 1166 standard of freestanding implementations. *Note Headers Installed 1167 by GCC: Headers, for details of when these and other headers are 1168 installed. 1169 1170 `intl' 1171 GNU `libintl', from GNU `gettext', for systems which do not 1172 include it in libc. Properly, this directory should be at top 1173 level, parallel to the `gcc' directory. 1174 1175 `po' 1176 Message catalogs with translations of messages produced by GCC into 1177 various languages, `LANGUAGE.po'. This directory also contains 1178 `gcc.pot', the template for these message catalogues, `exgettext', 1179 a wrapper around `gettext' to extract the messages from the GCC 1180 sources and create `gcc.pot', which is run by `make gcc.pot', and 1181 `EXCLUDES', a list of files from which messages should not be 1182 extracted. 1183 1184 `testsuite' 1185 The GCC testsuites (except for those for runtime libraries). 1186 *Note Testsuites::. 1187 1188 1189 File: gccint.info, Node: Configuration, Next: Build, Prev: Subdirectories, Up: gcc Directory 1190 1191 6.3.2 Configuration in the `gcc' Directory 1192 ------------------------------------------ 1193 1194 The `gcc' directory is configured with an Autoconf-generated script 1195 `configure'. The `configure' script is generated from `configure.ac' 1196 and `aclocal.m4'. From the files `configure.ac' and `acconfig.h', 1197 Autoheader generates the file `config.in'. The file `cstamp-h.in' is 1198 used as a timestamp. 1199 1200 * Menu: 1201 1202 * Config Fragments:: Scripts used by `configure'. 1203 * System Config:: The `config.build', `config.host', and 1204 `config.gcc' files. 1205 * Configuration Files:: Files created by running `configure'. 1206 1207 1208 File: gccint.info, Node: Config Fragments, Next: System Config, Up: Configuration 1209 1210 6.3.2.1 Scripts Used by `configure' 1211 ................................... 1212 1213 `configure' uses some other scripts to help in its work: 1214 1215 * The standard GNU `config.sub' and `config.guess' files, kept in 1216 the top level directory, are used. FIXME: when is the 1217 `config.guess' file in the `gcc' directory (that just calls the 1218 top level one) used? 1219 1220 * The file `config.gcc' is used to handle configuration specific to 1221 the particular target machine. The file `config.build' is used to 1222 handle configuration specific to the particular build machine. 1223 The file `config.host' is used to handle configuration specific to 1224 the particular host machine. (In general, these should only be 1225 used for features that cannot reasonably be tested in Autoconf 1226 feature tests.) *Note The `config.build'; `config.host'; and 1227 `config.gcc' Files: System Config, for details of the contents of 1228 these files. 1229 1230 * Each language subdirectory has a file `LANGUAGE/config-lang.in' 1231 that is used for front-end-specific configuration. *Note The 1232 Front End `config-lang.in' File: Front End Config, for details of 1233 this file. 1234 1235 * A helper script `configure.frag' is used as part of creating the 1236 output of `configure'. 1237 1238 1239 File: gccint.info, Node: System Config, Next: Configuration Files, Prev: Config Fragments, Up: Configuration 1240 1241 6.3.2.2 The `config.build'; `config.host'; and `config.gcc' Files 1242 ................................................................. 1243 1244 The `config.build' file contains specific rules for particular systems 1245 which GCC is built on. This should be used as rarely as possible, as 1246 the behavior of the build system can always be detected by autoconf. 1247 1248 The `config.host' file contains specific rules for particular systems 1249 which GCC will run on. This is rarely needed. 1250 1251 The `config.gcc' file contains specific rules for particular systems 1252 which GCC will generate code for. This is usually needed. 1253 1254 Each file has a list of the shell variables it sets, with 1255 descriptions, at the top of the file. 1256 1257 FIXME: document the contents of these files, and what variables should 1258 be set to control build, host and target configuration. 1259 1260 1261 File: gccint.info, Node: Configuration Files, Prev: System Config, Up: Configuration 1262 1263 6.3.2.3 Files Created by `configure' 1264 .................................... 1265 1266 Here we spell out what files will be set up by `configure' in the `gcc' 1267 directory. Some other files are created as temporary files in the 1268 configuration process, and are not used in the subsequent build; these 1269 are not documented. 1270 1271 * `Makefile' is constructed from `Makefile.in', together with the 1272 host and target fragments (*note Makefile Fragments: Fragments.) 1273 `t-TARGET' and `x-HOST' from `config', if any, and language 1274 Makefile fragments `LANGUAGE/Make-lang.in'. 1275 1276 * `auto-host.h' contains information about the host machine 1277 determined by `configure'. If the host machine is different from 1278 the build machine, then `auto-build.h' is also created, containing 1279 such information about the build machine. 1280 1281 * `config.status' is a script that may be run to recreate the 1282 current configuration. 1283 1284 * `configargs.h' is a header containing details of the arguments 1285 passed to `configure' to configure GCC, and of the thread model 1286 used. 1287 1288 * `cstamp-h' is used as a timestamp. 1289 1290 * `fixinc/Makefile' is constructed from `fixinc/Makefile.in'. 1291 1292 * `gccbug', a script for reporting bugs in GCC, is constructed from 1293 `gccbug.in'. 1294 1295 * `intl/Makefile' is constructed from `intl/Makefile.in'. 1296 1297 * `mklibgcc', a shell script to create a Makefile to build libgcc, 1298 is constructed from `mklibgcc.in'. 1299 1300 * If a language `config-lang.in' file (*note The Front End 1301 `config-lang.in' File: Front End Config.) sets `outputs', then the 1302 files listed in `outputs' there are also generated. 1303 1304 The following configuration headers are created from the Makefile, 1305 using `mkconfig.sh', rather than directly by `configure'. `config.h', 1306 `bconfig.h' and `tconfig.h' all contain the `xm-MACHINE.h' header, if 1307 any, appropriate to the host, build and target machines respectively, 1308 the configuration headers for the target, and some definitions; for the 1309 host and build machines, these include the autoconfigured headers 1310 generated by `configure'. The other configuration headers are 1311 determined by `config.gcc'. They also contain the typedefs for `rtx', 1312 `rtvec' and `tree'. 1313 1314 * `config.h', for use in programs that run on the host machine. 1315 1316 * `bconfig.h', for use in programs that run on the build machine. 1317 1318 * `tconfig.h', for use in programs and libraries for the target 1319 machine. 1320 1321 * `tm_p.h', which includes the header `MACHINE-protos.h' that 1322 contains prototypes for functions in the target `.c' file. FIXME: 1323 why is such a separate header necessary? 1324 1325 1326 File: gccint.info, Node: Build, Next: Makefile, Prev: Configuration, Up: gcc Directory 1327 1328 6.3.3 Build System in the `gcc' Directory 1329 ----------------------------------------- 1330 1331 FIXME: describe the build system, including what is built in what 1332 stages. Also list the various source files that are used in the build 1333 process but aren't source files of GCC itself and so aren't documented 1334 below (*note Passes::). 1335 1336 1337 File: gccint.info, Node: Makefile, Next: Library Files, Prev: Build, Up: gcc Directory 1338 1339 6.3.4 Makefile Targets 1340 ---------------------- 1341 1342 These targets are available from the `gcc' directory: 1343 1344 `all' 1345 This is the default target. Depending on what your 1346 build/host/target configuration is, it coordinates all the things 1347 that need to be built. 1348 1349 `doc' 1350 Produce info-formatted documentation and man pages. Essentially it 1351 calls `make man' and `make info'. 1352 1353 `dvi' 1354 Produce DVI-formatted documentation. 1355 1356 `pdf' 1357 Produce PDF-formatted documentation. 1358 1359 `html' 1360 Produce HTML-formatted documentation. 1361 1362 `man' 1363 Generate man pages. 1364 1365 `info' 1366 Generate info-formatted pages. 1367 1368 `mostlyclean' 1369 Delete the files made while building the compiler. 1370 1371 `clean' 1372 That, and all the other files built by `make all'. 1373 1374 `distclean' 1375 That, and all the files created by `configure'. 1376 1377 `maintainer-clean' 1378 Distclean plus any file that can be generated from other files. 1379 Note that additional tools may be required beyond what is normally 1380 needed to build gcc. 1381 1382 `srcextra' 1383 Generates files in the source directory that do not exist in CVS 1384 but should go into a release tarball. One example is 1385 `gcc/java/parse.c' which is generated from the CVS source file 1386 `gcc/java/parse.y'. 1387 1388 `srcinfo' 1389 `srcman' 1390 Copies the info-formatted and manpage documentation into the source 1391 directory usually for the purpose of generating a release tarball. 1392 1393 `install' 1394 Installs gcc. 1395 1396 `uninstall' 1397 Deletes installed files. 1398 1399 `check' 1400 Run the testsuite. This creates a `testsuite' subdirectory that 1401 has various `.sum' and `.log' files containing the results of the 1402 testing. You can run subsets with, for example, `make check-gcc'. 1403 You can specify specific tests by setting RUNTESTFLAGS to be the 1404 name of the `.exp' file, optionally followed by (for some tests) 1405 an equals and a file wildcard, like: 1406 1407 make check-gcc RUNTESTFLAGS="execute.exp=19980413-*" 1408 1409 Note that running the testsuite may require additional tools be 1410 installed, such as TCL or dejagnu. 1411 1412 The toplevel tree from which you start GCC compilation is not the GCC 1413 directory, but rather a complex Makefile that coordinates the various 1414 steps of the build, including bootstrapping the compiler and using the 1415 new compiler to build target libraries. 1416 1417 When GCC is configured for a native configuration, the default action 1418 for `make' is to do a full three-stage bootstrap. This means that GCC 1419 is built three times--once with the native compiler, once with the 1420 native-built compiler it just built, and once with the compiler it 1421 built the second time. In theory, the last two should produce the same 1422 results, which `make compare' can check. Each stage is configured 1423 separately and compiled into a separate directory, to minimize problems 1424 due to ABI incompatibilities between the native compiler and GCC. 1425 1426 If you do a change, rebuilding will also start from the first stage 1427 and "bubble" up the change through the three stages. Each stage is 1428 taken from its build directory (if it had been built previously), 1429 rebuilt, and copied to its subdirectory. This will allow you to, for 1430 example, continue a bootstrap after fixing a bug which causes the 1431 stage2 build to crash. It does not provide as good coverage of the 1432 compiler as bootstrapping from scratch, but it ensures that the new 1433 code is syntactically correct (e.g. that you did not use GCC extensions 1434 by mistake), and avoids spurious bootstrap comparison failures(1). 1435 1436 Other targets available from the top level include: 1437 1438 `bootstrap-lean' 1439 Like `bootstrap', except that the various stages are removed once 1440 they're no longer needed. This saves disk space. 1441 1442 `bootstrap2' 1443 `bootstrap2-lean' 1444 Performs only the first two stages of bootstrap. Unlike a 1445 three-stage bootstrap, this does not perform a comparison to test 1446 that the compiler is running properly. Note that the disk space 1447 required by a "lean" bootstrap is approximately independent of the 1448 number of stages. 1449 1450 `stageN-bubble (N = 1...4)' 1451 Rebuild all the stages up to N, with the appropriate flags, 1452 "bubbling" the changes as described above. 1453 1454 `all-stageN (N = 1...4)' 1455 Assuming that stage N has already been built, rebuild it with the 1456 appropriate flags. This is rarely needed. 1457 1458 `cleanstrap' 1459 Remove everything (`make clean') and rebuilds (`make bootstrap'). 1460 1461 `compare' 1462 Compares the results of stages 2 and 3. This ensures that the 1463 compiler is running properly, since it should produce the same 1464 object files regardless of how it itself was compiled. 1465 1466 `profiledbootstrap' 1467 Builds a compiler with profiling feedback information. For more 1468 information, see *Note Building with profile feedback: 1469 (gccinstall)Building. 1470 1471 `restrap' 1472 Restart a bootstrap, so that everything that was not built with 1473 the system compiler is rebuilt. 1474 1475 `stageN-start (N = 1...4)' 1476 For each package that is bootstrapped, rename directories so that, 1477 for example, `gcc' points to the stageN GCC, compiled with the 1478 stageN-1 GCC(2). 1479 1480 You will invoke this target if you need to test or debug the 1481 stageN GCC. If you only need to execute GCC (but you need not run 1482 `make' either to rebuild it or to run test suites), you should be 1483 able to work directly in the `stageN-gcc' directory. This makes 1484 it easier to debug multiple stages in parallel. 1485 1486 `stage' 1487 For each package that is bootstrapped, relocate its build directory 1488 to indicate its stage. For example, if the `gcc' directory points 1489 to the stage2 GCC, after invoking this target it will be renamed 1490 to `stage2-gcc'. 1491 1492 1493 If you wish to use non-default GCC flags when compiling the stage2 and 1494 stage3 compilers, set `BOOT_CFLAGS' on the command line when doing 1495 `make'. 1496 1497 Usually, the first stage only builds the languages that the compiler 1498 is written in: typically, C and maybe Ada. If you are debugging a 1499 miscompilation of a different stage2 front-end (for example, of the 1500 Fortran front-end), you may want to have front-ends for other languages 1501 in the first stage as well. To do so, set `STAGE1_LANGUAGES' on the 1502 command line when doing `make'. 1503 1504 For example, in the aforementioned scenario of debugging a Fortran 1505 front-end miscompilation caused by the stage1 compiler, you may need a 1506 command like 1507 1508 make stage2-bubble STAGE1_LANGUAGES=c,fortran 1509 1510 Alternatively, you can use per-language targets to build and test 1511 languages that are not enabled by default in stage1. For example, 1512 `make f951' will build a Fortran compiler even in the stage1 build 1513 directory. 1514 1515 ---------- Footnotes ---------- 1516 1517 (1) Except if the compiler was buggy and miscompiled some of the 1518 files that were not modified. In this case, it's best to use `make 1519 restrap'. 1520 1521 (2) Customarily, the system compiler is also termed the `stage0' GCC. 1522 1523 1524 File: gccint.info, Node: Library Files, Next: Headers, Prev: Makefile, Up: gcc Directory 1525 1526 6.3.5 Library Source Files and Headers under the `gcc' Directory 1527 ---------------------------------------------------------------- 1528 1529 FIXME: list here, with explanation, all the C source files and headers 1530 under the `gcc' directory that aren't built into the GCC executable but 1531 rather are part of runtime libraries and object files, such as 1532 `crtstuff.c' and `unwind-dw2.c'. *Note Headers Installed by GCC: 1533 Headers, for more information about the `ginclude' directory. 1534 1535 1536 File: gccint.info, Node: Headers, Next: Documentation, Prev: Library Files, Up: gcc Directory 1537 1538 6.3.6 Headers Installed by GCC 1539 ------------------------------ 1540 1541 In general, GCC expects the system C library to provide most of the 1542 headers to be used with it. However, GCC will fix those headers if 1543 necessary to make them work with GCC, and will install some headers 1544 required of freestanding implementations. These headers are installed 1545 in `LIBSUBDIR/include'. Headers for non-C runtime libraries are also 1546 installed by GCC; these are not documented here. (FIXME: document them 1547 somewhere.) 1548 1549 Several of the headers GCC installs are in the `ginclude' directory. 1550 These headers, `iso646.h', `stdarg.h', `stdbool.h', and `stddef.h', are 1551 installed in `LIBSUBDIR/include', unless the target Makefile fragment 1552 (*note Target Fragment::) overrides this by setting `USER_H'. 1553 1554 In addition to these headers and those generated by fixing system 1555 headers to work with GCC, some other headers may also be installed in 1556 `LIBSUBDIR/include'. `config.gcc' may set `extra_headers'; this 1557 specifies additional headers under `config' to be installed on some 1558 systems. 1559 1560 GCC installs its own version of `<float.h>', from `ginclude/float.h'. 1561 This is done to cope with command-line options that change the 1562 representation of floating point numbers. 1563 1564 GCC also installs its own version of `<limits.h>'; this is generated 1565 from `glimits.h', together with `limitx.h' and `limity.h' if the system 1566 also has its own version of `<limits.h>'. (GCC provides its own header 1567 because it is required of ISO C freestanding implementations, but needs 1568 to include the system header from its own header as well because other 1569 standards such as POSIX specify additional values to be defined in 1570 `<limits.h>'.) The system's `<limits.h>' header is used via 1571 `LIBSUBDIR/include/syslimits.h', which is copied from `gsyslimits.h' if 1572 it does not need fixing to work with GCC; if it needs fixing, 1573 `syslimits.h' is the fixed copy. 1574 1575 1576 File: gccint.info, Node: Documentation, Next: Front End, Prev: Headers, Up: gcc Directory 1577 1578 6.3.7 Building Documentation 1579 ---------------------------- 1580 1581 The main GCC documentation is in the form of manuals in Texinfo format. 1582 These are installed in Info format; DVI versions may be generated by 1583 `make dvi', PDF versions by `make pdf', and HTML versions by `make 1584 html'. In addition, some man pages are generated from the Texinfo 1585 manuals, there are some other text files with miscellaneous 1586 documentation, and runtime libraries have their own documentation 1587 outside the `gcc' directory. FIXME: document the documentation for 1588 runtime libraries somewhere. 1589 1590 * Menu: 1591 1592 * Texinfo Manuals:: GCC manuals in Texinfo format. 1593 * Man Page Generation:: Generating man pages from Texinfo manuals. 1594 * Miscellaneous Docs:: Miscellaneous text files with documentation. 1595 1596 1597 File: gccint.info, Node: Texinfo Manuals, Next: Man Page Generation, Up: Documentation 1598 1599 6.3.7.1 Texinfo Manuals 1600 ....................... 1601 1602 The manuals for GCC as a whole, and the C and C++ front ends, are in 1603 files `doc/*.texi'. Other front ends have their own manuals in files 1604 `LANGUAGE/*.texi'. Common files `doc/include/*.texi' are provided 1605 which may be included in multiple manuals; the following files are in 1606 `doc/include': 1607 1608 `fdl.texi' 1609 The GNU Free Documentation License. 1610 1611 `funding.texi' 1612 The section "Funding Free Software". 1613 1614 `gcc-common.texi' 1615 Common definitions for manuals. 1616 1617 `gpl.texi' 1618 The GNU General Public License. 1619 1620 `texinfo.tex' 1621 A copy of `texinfo.tex' known to work with the GCC manuals. 1622 1623 DVI-formatted manuals are generated by `make dvi', which uses 1624 `texi2dvi' (via the Makefile macro `$(TEXI2DVI)'). PDF-formatted 1625 manuals are generated by `make pdf', which uses `texi2pdf' (via the 1626 Makefile macro `$(TEXI2PDF)'). HTML formatted manuals are generated by 1627 `make html'. Info manuals are generated by `make info' (which is run 1628 as part of a bootstrap); this generates the manuals in the source 1629 directory, using `makeinfo' via the Makefile macro `$(MAKEINFO)', and 1630 they are included in release distributions. 1631 1632 Manuals are also provided on the GCC web site, in both HTML and 1633 PostScript forms. This is done via the script 1634 `maintainer-scripts/update_web_docs'. Each manual to be provided 1635 online must be listed in the definition of `MANUALS' in that file; a 1636 file `NAME.texi' must only appear once in the source tree, and the 1637 output manual must have the same name as the source file. (However, 1638 other Texinfo files, included in manuals but not themselves the root 1639 files of manuals, may have names that appear more than once in the 1640 source tree.) The manual file `NAME.texi' should only include other 1641 files in its own directory or in `doc/include'. HTML manuals will be 1642 generated by `makeinfo --html', PostScript manuals by `texi2dvi' and 1643 `dvips', and PDF manuals by `texi2pdf'. All Texinfo files that are 1644 parts of manuals must be checked into CVS, even if they are generated 1645 files, for the generation of online manuals to work. 1646 1647 The installation manual, `doc/install.texi', is also provided on the 1648 GCC web site. The HTML version is generated by the script 1649 `doc/install.texi2html'. 1650 1651 1652 File: gccint.info, Node: Man Page Generation, Next: Miscellaneous Docs, Prev: Texinfo Manuals, Up: Documentation 1653 1654 6.3.7.2 Man Page Generation 1655 ........................... 1656 1657 Because of user demand, in addition to full Texinfo manuals, man pages 1658 are provided which contain extracts from those manuals. These man 1659 pages are generated from the Texinfo manuals using 1660 `contrib/texi2pod.pl' and `pod2man'. (The man page for `g++', 1661 `cp/g++.1', just contains a `.so' reference to `gcc.1', but all the 1662 other man pages are generated from Texinfo manuals.) 1663 1664 Because many systems may not have the necessary tools installed to 1665 generate the man pages, they are only generated if the `configure' 1666 script detects that recent enough tools are installed, and the 1667 Makefiles allow generating man pages to fail without aborting the 1668 build. Man pages are also included in release distributions. They are 1669 generated in the source directory. 1670 1671 Magic comments in Texinfo files starting `@c man' control what parts 1672 of a Texinfo file go into a man page. Only a subset of Texinfo is 1673 supported by `texi2pod.pl', and it may be necessary to add support for 1674 more Texinfo features to this script when generating new man pages. To 1675 improve the man page output, some special Texinfo macros are provided 1676 in `doc/include/gcc-common.texi' which `texi2pod.pl' understands: 1677 1678 `@gcctabopt' 1679 Use in the form `@table @gcctabopt' for tables of options, where 1680 for printed output the effect of `@code' is better than that of 1681 `@option' but for man page output a different effect is wanted. 1682 1683 `@gccoptlist' 1684 Use for summary lists of options in manuals. 1685 1686 `@gol' 1687 Use at the end of each line inside `@gccoptlist'. This is 1688 necessary to avoid problems with differences in how the 1689 `@gccoptlist' macro is handled by different Texinfo formatters. 1690 1691 FIXME: describe the `texi2pod.pl' input language and magic comments in 1692 more detail. 1693 1694 1695 File: gccint.info, Node: Miscellaneous Docs, Prev: Man Page Generation, Up: Documentation 1696 1697 6.3.7.3 Miscellaneous Documentation 1698 ................................... 1699 1700 In addition to the formal documentation that is installed by GCC, there 1701 are several other text files with miscellaneous documentation: 1702 1703 `ABOUT-GCC-NLS' 1704 Notes on GCC's Native Language Support. FIXME: this should be 1705 part of this manual rather than a separate file. 1706 1707 `ABOUT-NLS' 1708 Notes on the Free Translation Project. 1709 1710 `COPYING' 1711 The GNU General Public License. 1712 1713 `COPYING.LIB' 1714 The GNU Lesser General Public License. 1715 1716 `*ChangeLog*' 1717 `*/ChangeLog*' 1718 Change log files for various parts of GCC. 1719 1720 `LANGUAGES' 1721 Details of a few changes to the GCC front-end interface. FIXME: 1722 the information in this file should be part of general 1723 documentation of the front-end interface in this manual. 1724 1725 `ONEWS' 1726 Information about new features in old versions of GCC. (For recent 1727 versions, the information is on the GCC web site.) 1728 1729 `README.Portability' 1730 Information about portability issues when writing code in GCC. 1731 FIXME: why isn't this part of this manual or of the GCC Coding 1732 Conventions? 1733 1734 `SERVICE' 1735 A pointer to the GNU Service Directory. 1736 1737 FIXME: document such files in subdirectories, at least `config', `cp', 1738 `objc', `testsuite'. 1739 1740 1741 File: gccint.info, Node: Front End, Next: Back End, Prev: Documentation, Up: gcc Directory 1742 1743 6.3.8 Anatomy of a Language Front End 1744 ------------------------------------- 1745 1746 A front end for a language in GCC has the following parts: 1747 1748 * A directory `LANGUAGE' under `gcc' containing source files for 1749 that front end. *Note The Front End `LANGUAGE' Directory: Front 1750 End Directory, for details. 1751 1752 * A mention of the language in the list of supported languages in 1753 `gcc/doc/install.texi'. 1754 1755 * A mention of the name under which the language's runtime library is 1756 recognized by `--enable-shared=PACKAGE' in the documentation of 1757 that option in `gcc/doc/install.texi'. 1758 1759 * A mention of any special prerequisites for building the front end 1760 in the documentation of prerequisites in `gcc/doc/install.texi'. 1761 1762 * Details of contributors to that front end in 1763 `gcc/doc/contrib.texi'. If the details are in that front end's 1764 own manual then there should be a link to that manual's list in 1765 `contrib.texi'. 1766 1767 * Information about support for that language in 1768 `gcc/doc/frontends.texi'. 1769 1770 * Information about standards for that language, and the front end's 1771 support for them, in `gcc/doc/standards.texi'. This may be a link 1772 to such information in the front end's own manual. 1773 1774 * Details of source file suffixes for that language and `-x LANG' 1775 options supported, in `gcc/doc/invoke.texi'. 1776 1777 * Entries in `default_compilers' in `gcc.c' for source file suffixes 1778 for that language. 1779 1780 * Preferably testsuites, which may be under `gcc/testsuite' or 1781 runtime library directories. FIXME: document somewhere how to 1782 write testsuite harnesses. 1783 1784 * Probably a runtime library for the language, outside the `gcc' 1785 directory. FIXME: document this further. 1786 1787 * Details of the directories of any runtime libraries in 1788 `gcc/doc/sourcebuild.texi'. 1789 1790 If the front end is added to the official GCC CVS repository, the 1791 following are also necessary: 1792 1793 * At least one Bugzilla component for bugs in that front end and 1794 runtime libraries. This category needs to be mentioned in 1795 `gcc/gccbug.in', as well as being added to the Bugzilla database. 1796 1797 * Normally, one or more maintainers of that front end listed in 1798 `MAINTAINERS'. 1799 1800 * Mentions on the GCC web site in `index.html' and `frontends.html', 1801 with any relevant links on `readings.html'. (Front ends that are 1802 not an official part of GCC may also be listed on 1803 `frontends.html', with relevant links.) 1804 1805 * A news item on `index.html', and possibly an announcement on the 1806 <gcc-announce (a] gcc.gnu.org> mailing list. 1807 1808 * The front end's manuals should be mentioned in 1809 `maintainer-scripts/update_web_docs' (*note Texinfo Manuals::) and 1810 the online manuals should be linked to from 1811 `onlinedocs/index.html'. 1812 1813 * Any old releases or CVS repositories of the front end, before its 1814 inclusion in GCC, should be made available on the GCC FTP site 1815 `ftp://gcc.gnu.org/pub/gcc/old-releases/'. 1816 1817 * The release and snapshot script `maintainer-scripts/gcc_release' 1818 should be updated to generate appropriate tarballs for this front 1819 end. The associated `maintainer-scripts/snapshot-README' and 1820 `maintainer-scripts/snapshot-index.html' files should be updated 1821 to list the tarballs and diffs for this front end. 1822 1823 * If this front end includes its own version files that include the 1824 current date, `maintainer-scripts/update_version' should be 1825 updated accordingly. 1826 1827 * `CVSROOT/modules' in the GCC CVS repository should be updated. 1828 1829 * Menu: 1830 1831 * Front End Directory:: The front end `LANGUAGE' directory. 1832 * Front End Config:: The front end `config-lang.in' file. 1833 1834 1835 File: gccint.info, Node: Front End Directory, Next: Front End Config, Up: Front End 1836 1837 6.3.8.1 The Front End `LANGUAGE' Directory 1838 .......................................... 1839 1840 A front end `LANGUAGE' directory contains the source files of that 1841 front end (but not of any runtime libraries, which should be outside 1842 the `gcc' directory). This includes documentation, and possibly some 1843 subsidiary programs build alongside the front end. Certain files are 1844 special and other parts of the compiler depend on their names: 1845 1846 `config-lang.in' 1847 This file is required in all language subdirectories. *Note The 1848 Front End `config-lang.in' File: Front End Config, for details of 1849 its contents 1850 1851 `Make-lang.in' 1852 This file is required in all language subdirectories. It contains 1853 targets `LANG.HOOK' (where `LANG' is the setting of `language' in 1854 `config-lang.in') for the following values of `HOOK', and any 1855 other Makefile rules required to build those targets (which may if 1856 necessary use other Makefiles specified in `outputs' in 1857 `config-lang.in', although this is deprecated). It also adds any 1858 testsuite targets that can use the standard rule in 1859 `gcc/Makefile.in' to the variable `lang_checks'. 1860 1861 `all.cross' 1862 `start.encap' 1863 `rest.encap' 1864 FIXME: exactly what goes in each of these targets? 1865 1866 `tags' 1867 Build an `etags' `TAGS' file in the language subdirectory in 1868 the source tree. 1869 1870 `info' 1871 Build info documentation for the front end, in the build 1872 directory. This target is only called by `make bootstrap' if 1873 a suitable version of `makeinfo' is available, so does not 1874 need to check for this, and should fail if an error occurs. 1875 1876 `dvi' 1877 Build DVI documentation for the front end, in the build 1878 directory. This should be done using `$(TEXI2DVI)', with 1879 appropriate `-I' arguments pointing to directories of 1880 included files. 1881 1882 `pdf' 1883 Build PDF documentation for the front end, in the build 1884 directory. This should be done using `$(TEXI2PDF)', with 1885 appropriate `-I' arguments pointing to directories of 1886 included files. 1887 1888 `html' 1889 Build HTML documentation for the front end, in the build 1890 directory. 1891 1892 `man' 1893 Build generated man pages for the front end from Texinfo 1894 manuals (*note Man Page Generation::), in the build 1895 directory. This target is only called if the necessary tools 1896 are available, but should ignore errors so as not to stop the 1897 build if errors occur; man pages are optional and the tools 1898 involved may be installed in a broken way. 1899 1900 `install-common' 1901 Install everything that is part of the front end, apart from 1902 the compiler executables listed in `compilers' in 1903 `config-lang.in'. 1904 1905 `install-info' 1906 Install info documentation for the front end, if it is 1907 present in the source directory. This target should have 1908 dependencies on info files that should be installed. 1909 1910 `install-man' 1911 Install man pages for the front end. This target should 1912 ignore errors. 1913 1914 `srcextra' 1915 Copies its dependencies into the source directory. This 1916 generally should be used for generated files such as Bison 1917 output files which are not present in CVS, but should be 1918 included in any release tarballs. This target will be 1919 executed during a bootstrap if 1920 `--enable-generated-files-in-srcdir' was specified as a 1921 `configure' option. 1922 1923 `srcinfo' 1924 `srcman' 1925 Copies its dependencies into the source directory. These 1926 targets will be executed during a bootstrap if 1927 `--enable-generated-files-in-srcdir' was specified as a 1928 `configure' option. 1929 1930 `uninstall' 1931 Uninstall files installed by installing the compiler. This is 1932 currently documented not to be supported, so the hook need 1933 not do anything. 1934 1935 `mostlyclean' 1936 `clean' 1937 `distclean' 1938 `maintainer-clean' 1939 The language parts of the standard GNU `*clean' targets. 1940 *Note Standard Targets for Users: (standards)Standard 1941 Targets, for details of the standard targets. For GCC, 1942 `maintainer-clean' should delete all generated files in the 1943 source directory that are not checked into CVS, but should 1944 not delete anything checked into CVS. 1945 1946 `stage1' 1947 `stage2' 1948 `stage3' 1949 `stage4' 1950 `stageprofile' 1951 `stagefeedback' 1952 Move to the stage directory files not included in 1953 `stagestuff' in `config-lang.in' or otherwise moved by the 1954 main `Makefile'. 1955 1956 `lang.opt' 1957 This file registers the set of switches that the front end accepts 1958 on the command line, and their `--help' text. *Note Options::. 1959 1960 `lang-specs.h' 1961 This file provides entries for `default_compilers' in `gcc.c' 1962 which override the default of giving an error that a compiler for 1963 that language is not installed. 1964 1965 `LANGUAGE-tree.def' 1966 This file, which need not exist, defines any language-specific tree 1967 codes. 1968 1969 1970 File: gccint.info, Node: Front End Config, Prev: Front End Directory, Up: Front End 1971 1972 6.3.8.2 The Front End `config-lang.in' File 1973 ........................................... 1974 1975 Each language subdirectory contains a `config-lang.in' file. In 1976 addition the main directory contains `c-config-lang.in', which contains 1977 limited information for the C language. This file is a shell script 1978 that may define some variables describing the language: 1979 1980 `language' 1981 This definition must be present, and gives the name of the language 1982 for some purposes such as arguments to `--enable-languages'. 1983 1984 `lang_requires' 1985 If defined, this variable lists (space-separated) language front 1986 ends other than C that this front end requires to be enabled (with 1987 the names given being their `language' settings). For example, the 1988 Java front end depends on the C++ front end, so sets 1989 `lang_requires=c++'. 1990 1991 `subdir_requires' 1992 If defined, this variable lists (space-separated) front end 1993 directories other than C that this front end requires to be 1994 present. For example, the Objective-C++ front end uses source 1995 files from the C++ and Objective-C front ends, so sets 1996 `subdir_requires="cp objc"'. 1997 1998 `target_libs' 1999 If defined, this variable lists (space-separated) targets in the 2000 top level `Makefile' to build the runtime libraries for this 2001 language, such as `target-libobjc'. 2002 2003 `lang_dirs' 2004 If defined, this variable lists (space-separated) top level 2005 directories (parallel to `gcc'), apart from the runtime libraries, 2006 that should not be configured if this front end is not built. 2007 2008 `build_by_default' 2009 If defined to `no', this language front end is not built unless 2010 enabled in a `--enable-languages' argument. Otherwise, front ends 2011 are built by default, subject to any special logic in 2012 `configure.ac' (as is present to disable the Ada front end if the 2013 Ada compiler is not already installed). 2014 2015 `boot_language' 2016 If defined to `yes', this front end is built in stage 1 of the 2017 bootstrap. This is only relevant to front ends written in their 2018 own languages. 2019 2020 `compilers' 2021 If defined, a space-separated list of compiler executables that 2022 will be run by the driver. The names here will each end with 2023 `\$(exeext)'. 2024 2025 `stagestuff' 2026 If defined, a space-separated list of files that should be moved to 2027 the `stageN' directories in each stage of bootstrap. 2028 2029 `outputs' 2030 If defined, a space-separated list of files that should be 2031 generated by `configure' substituting values in them. This 2032 mechanism can be used to create a file `LANGUAGE/Makefile' from 2033 `LANGUAGE/Makefile.in', but this is deprecated, building 2034 everything from the single `gcc/Makefile' is preferred. 2035 2036 `gtfiles' 2037 If defined, a space-separated list of files that should be scanned 2038 by gengtype.c to generate the garbage collection tables and 2039 routines for this language. This excludes the files that are 2040 common to all front ends. *Note Type Information::. 2041 2042 `need_gmp' 2043 If defined to `yes', this frontend requires the GMP library. 2044 Enables configure tests for GMP, which set `GMPLIBS' and `GMPINC' 2045 appropriately. 2046 2047 2048 2049 File: gccint.info, Node: Back End, Prev: Front End, Up: gcc Directory 2050 2051 6.3.9 Anatomy of a Target Back End 2052 ---------------------------------- 2053 2054 A back end for a target architecture in GCC has the following parts: 2055 2056 * A directory `MACHINE' under `gcc/config', containing a machine 2057 description `MACHINE.md' file (*note Machine Descriptions: Machine 2058 Desc.), header files `MACHINE.h' and `MACHINE-protos.h' and a 2059 source file `MACHINE.c' (*note Target Description Macros and 2060 Functions: Target Macros.), possibly a target Makefile fragment 2061 `t-MACHINE' (*note The Target Makefile Fragment: Target 2062 Fragment.), and maybe some other files. The names of these files 2063 may be changed from the defaults given by explicit specifications 2064 in `config.gcc'. 2065 2066 * If necessary, a file `MACHINE-modes.def' in the `MACHINE' 2067 directory, containing additional machine modes to represent 2068 condition codes. *Note Condition Code::, for further details. 2069 2070 * An optional `MACHINE.opt' file in the `MACHINE' directory, 2071 containing a list of target-specific options. You can also add 2072 other option files using the `extra_options' variable in 2073 `config.gcc'. *Note Options::. 2074 2075 * Entries in `config.gcc' (*note The `config.gcc' File: System 2076 Config.) for the systems with this target architecture. 2077 2078 * Documentation in `gcc/doc/invoke.texi' for any command-line 2079 options supported by this target (*note Run-time Target 2080 Specification: Run-time Target.). This means both entries in the 2081 summary table of options and details of the individual options. 2082 2083 * Documentation in `gcc/doc/extend.texi' for any target-specific 2084 attributes supported (*note Defining target-specific uses of 2085 `__attribute__': Target Attributes.), including where the same 2086 attribute is already supported on some targets, which are 2087 enumerated in the manual. 2088 2089 * Documentation in `gcc/doc/extend.texi' for any target-specific 2090 pragmas supported. 2091 2092 * Documentation in `gcc/doc/extend.texi' of any target-specific 2093 built-in functions supported. 2094 2095 * Documentation in `gcc/doc/extend.texi' of any target-specific 2096 format checking styles supported. 2097 2098 * Documentation in `gcc/doc/md.texi' of any target-specific 2099 constraint letters (*note Constraints for Particular Machines: 2100 Machine Constraints.). 2101 2102 * A note in `gcc/doc/contrib.texi' under the person or people who 2103 contributed the target support. 2104 2105 * Entries in `gcc/doc/install.texi' for all target triplets 2106 supported with this target architecture, giving details of any 2107 special notes about installation for this target, or saying that 2108 there are no special notes if there are none. 2109 2110 * Possibly other support outside the `gcc' directory for runtime 2111 libraries. FIXME: reference docs for this. The libstdc++ porting 2112 manual needs to be installed as info for this to work, or to be a 2113 chapter of this manual. 2114 2115 If the back end is added to the official GCC CVS repository, the 2116 following are also necessary: 2117 2118 * An entry for the target architecture in `readings.html' on the GCC 2119 web site, with any relevant links. 2120 2121 * Details of the properties of the back end and target architecture 2122 in `backends.html' on the GCC web site. 2123 2124 * A news item about the contribution of support for that target 2125 architecture, in `index.html' on the GCC web site. 2126 2127 * Normally, one or more maintainers of that target listed in 2128 `MAINTAINERS'. Some existing architectures may be unmaintained, 2129 but it would be unusual to add support for a target that does not 2130 have a maintainer when support is added. 2131 2132 2133 File: gccint.info, Node: Testsuites, Prev: gcc Directory, Up: Source Tree 2134 2135 6.4 Testsuites 2136 ============== 2137 2138 GCC contains several testsuites to help maintain compiler quality. 2139 Most of the runtime libraries and language front ends in GCC have 2140 testsuites. Currently only the C language testsuites are documented 2141 here; FIXME: document the others. 2142 2143 * Menu: 2144 2145 * Test Idioms:: Idioms used in testsuite code. 2146 * Test Directives:: Directives used within DejaGnu tests. 2147 * Ada Tests:: The Ada language testsuites. 2148 * C Tests:: The C language testsuites. 2149 * libgcj Tests:: The Java library testsuites. 2150 * gcov Testing:: Support for testing gcov. 2151 * profopt Testing:: Support for testing profile-directed optimizations. 2152 * compat Testing:: Support for testing binary compatibility. 2153 2154 2155 File: gccint.info, Node: Test Idioms, Next: Test Directives, Up: Testsuites 2156 2157 6.4.1 Idioms Used in Testsuite Code 2158 ----------------------------------- 2159 2160 In general, C testcases have a trailing `-N.c', starting with `-1.c', 2161 in case other testcases with similar names are added later. If the 2162 test is a test of some well-defined feature, it should have a name 2163 referring to that feature such as `FEATURE-1.c'. If it does not test a 2164 well-defined feature but just happens to exercise a bug somewhere in 2165 the compiler, and a bug report has been filed for this bug in the GCC 2166 bug database, `prBUG-NUMBER-1.c' is the appropriate form of name. 2167 Otherwise (for miscellaneous bugs not filed in the GCC bug database), 2168 and previously more generally, test cases are named after the date on 2169 which they were added. This allows people to tell at a glance whether 2170 a test failure is because of a recently found bug that has not yet been 2171 fixed, or whether it may be a regression, but does not give any other 2172 information about the bug or where discussion of it may be found. Some 2173 other language testsuites follow similar conventions. 2174 2175 In the `gcc.dg' testsuite, it is often necessary to test that an error 2176 is indeed a hard error and not just a warning--for example, where it is 2177 a constraint violation in the C standard, which must become an error 2178 with `-pedantic-errors'. The following idiom, where the first line 2179 shown is line LINE of the file and the line that generates the error, 2180 is used for this: 2181 2182 /* { dg-bogus "warning" "warning in place of error" } */ 2183 /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */ 2184 2185 It may be necessary to check that an expression is an integer constant 2186 expression and has a certain value. To check that `E' has value `V', 2187 an idiom similar to the following is used: 2188 2189 char x[((E) == (V) ? 1 : -1)]; 2190 2191 In `gcc.dg' tests, `__typeof__' is sometimes used to make assertions 2192 about the types of expressions. See, for example, 2193 `gcc.dg/c99-condexpr-1.c'. The more subtle uses depend on the exact 2194 rules for the types of conditional expressions in the C standard; see, 2195 for example, `gcc.dg/c99-intconst-1.c'. 2196 2197 It is useful to be able to test that optimizations are being made 2198 properly. This cannot be done in all cases, but it can be done where 2199 the optimization will lead to code being optimized away (for example, 2200 where flow analysis or alias analysis should show that certain code 2201 cannot be called) or to functions not being called because they have 2202 been expanded as built-in functions. Such tests go in 2203 `gcc.c-torture/execute'. Where code should be optimized away, a call 2204 to a nonexistent function such as `link_failure ()' may be inserted; a 2205 definition 2206 2207 #ifndef __OPTIMIZE__ 2208 void 2209 link_failure (void) 2210 { 2211 abort (); 2212 } 2213 #endif 2214 2215 will also be needed so that linking still succeeds when the test is run 2216 without optimization. When all calls to a built-in function should 2217 have been optimized and no calls to the non-built-in version of the 2218 function should remain, that function may be defined as `static' to 2219 call `abort ()' (although redeclaring a function as static may not work 2220 on all targets). 2221 2222 All testcases must be portable. Target-specific testcases must have 2223 appropriate code to avoid causing failures on unsupported systems; 2224 unfortunately, the mechanisms for this differ by directory. 2225 2226 FIXME: discuss non-C testsuites here. 2227 2228 2229 File: gccint.info, Node: Test Directives, Next: Ada Tests, Prev: Test Idioms, Up: Testsuites 2230 2231 6.4.2 Directives used within DejaGnu tests 2232 ------------------------------------------ 2233 2234 Test directives appear within comments in a test source file and begin 2235 with `dg-'. Some of these are defined within DejaGnu and others are 2236 local to the GCC testsuite. 2237 2238 The order in which test directives appear in a test can be important: 2239 directives local to GCC sometimes override information used by the 2240 DejaGnu directives, which know nothing about the GCC directives, so the 2241 DejaGnu directives must precede GCC directives. 2242 2243 Several test directives include selectors which are usually preceded by 2244 the keyword `target' or `xfail'. A selector is: one or more target 2245 triplets, possibly including wildcard characters; a single 2246 effective-target keyword; or a logical expression. Depending on the 2247 context, the selector specifies whether a test is skipped and reported 2248 as unsupported or is expected to fail. Use `*-*-*' to match any target. 2249 Effective-target keywords are defined in `target-supports.exp' in the 2250 GCC testsuite. 2251 2252 A selector expression appears within curly braces and uses a single 2253 logical operator: one of `!', `&&', or `||'. An operand is another 2254 selector expression, an effective-target keyword, a single target 2255 triplet, or a list of target triplets within quotes or curly braces. 2256 For example: 2257 2258 { target { ! "hppa*-*-* ia64*-*-*" } } 2259 { target { powerpc*-*-* && lp64 } } 2260 { xfail { lp64 || vect_no_align } } 2261 2262 `{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }' 2263 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 2264 is executed. It is one of: 2265 2266 `preprocess' 2267 Compile with `-E' to run only the preprocessor. 2268 2269 `assemble' 2270 Compile with `-S' to produce an assembly code file. 2271 2272 `compile' 2273 Compile with `-c' to produce a relocatable object file. 2274 2275 `link' 2276 Compile, assemble, and link to produce an executable file. 2277 2278 `run' 2279 Produce and run an executable file, which is expected to 2280 return an exit code of 0. 2281 2282 The default is `compile'. That can be overridden for a set of 2283 tests by redefining `dg-do-what-default' within the `.exp' file 2284 for those tests. 2285 2286 If the directive includes the optional `{ target SELECTOR }' then 2287 the test is skipped unless the target system is included in the 2288 list of target triplets or matches the effective-target keyword. 2289 2290 If the directive includes the optional `{ xfail SELECTOR }' and 2291 the selector is met then the test is expected to fail. For `dg-do 2292 run', execution is expected to fail but compilation is expected to 2293 pass. 2294 2295 `{ dg-options OPTIONS [{ target SELECTOR }] }' 2296 This DejaGnu directive provides a list of compiler options, to be 2297 used if the target system matches SELECTOR, that replace the 2298 default options used for this set of tests. 2299 2300 `{ dg-skip-if COMMENT { SELECTOR } { INCLUDE-OPTS } { EXCLUDE-OPTS } }' 2301 Skip the test if the test system is included in SELECTOR and if 2302 each of the options in INCLUDE-OPTS is in the set of options with 2303 which the test would be compiled and if none of the options in 2304 EXCLUDE-OPTS is in the set of options with which the test would be 2305 compiled. 2306 2307 Use `"*"' for an empty INCLUDE-OPTS list and `""' for an empty 2308 EXCLUDE-OPTS list. 2309 2310 `{ dg-xfail-if COMMENT { SELECTOR } { INCLUDE-OPTS } { EXCLUDE-OPTS } }' 2311 Expect the test to fail if the conditions (which are the same as 2312 for `dg-skip-if') are met. 2313 2314 `{ dg-require-SUPPORT args }' 2315 Skip the test if the target does not provide the required support; 2316 see `gcc-dg.exp' in the GCC testsuite for the actual directives. 2317 These directives must appear after any `dg-do' directive in the 2318 test. They require at least one argument, which can be an empty 2319 string if the specific procedure does not examine the argument. 2320 2321 `{ dg-require-effective-target KEYWORD }' 2322 Skip the test if the test target, including current multilib flags, 2323 is not covered by the effective-target keyword. This directive 2324 must appear after any `dg-do' directive in the test. 2325 2326 `{ dg-shouldfail COMMENT { SELECTOR } { INCLUDE-OPTS } { EXCLUDE-OPTS } }' 2327 Expect the test executable to return a nonzero exit status if the 2328 conditions (which are the same as for `dg-skip-if') are met. 2329 2330 `{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 2331 This DejaGnu directive appears on a source line that is expected 2332 to get an error message, or else specifies the source line 2333 associated with the message. If there is no message for that line 2334 or if the text of that message is not matched by REGEXP then the 2335 check fails and COMMENT is included in the `FAIL' message. The 2336 check does not look for the string `"error"' unless it is part of 2337 REGEXP. 2338 2339 `{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 2340 This DejaGnu directive appears on a source line that is expected 2341 to get a warning message, or else specifies the source line 2342 associated with the message. If there is no message for that line 2343 or if the text of that message is not matched by REGEXP then the 2344 check fails and COMMENT is included in the `FAIL' message. The 2345 check does not look for the string `"warning"' unless it is part 2346 of REGEXP. 2347 2348 `{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 2349 This DejaGnu directive appears on a source line that should not 2350 get a message matching REGEXP, or else specifies the source line 2351 associated with the bogus message. It is usually used with `xfail' 2352 to indicate that the message is a known problem for a particular 2353 set of targets. 2354 2355 `{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }' 2356 This DejaGnu directive indicates that the test is expected to fail 2357 due to compiler messages that are not handled by `dg-error', 2358 `dg-warning' or `dg-bogus'. 2359 2360 `{ dg-output REGEXP [{ target/xfail SELECTOR }] }' 2361 This DejaGnu directive compares REGEXP to the combined output that 2362 the test executable writes to `stdout' and `stderr'. 2363 2364 `{ dg-prune-output REGEXP }' 2365 Prune messages matching REGEXP from test output. 2366 2367 `{ dg-additional-files "FILELIST" }' 2368 Specify additional files, other than source files, that must be 2369 copied to the system where the compiler runs. 2370 2371 `{ dg-additional-sources "FILELIST" }' 2372 Specify additional source files to appear in the compile line 2373 following the main test file. 2374 2375 `{ dg-final { LOCAL-DIRECTIVE } }' 2376 This DejaGnu directive is placed within a comment anywhere in the 2377 source file and is processed after the test has been compiled and 2378 run. Multiple `dg-final' commands are processed in the order in 2379 which they appear in the source file. 2380 2381 The GCC testsuite defines the following directives to be used 2382 within `dg-final'. 2383 2384 `cleanup-coverage-files' 2385 Removes coverage data files generated for this test. 2386 2387 `cleanup-repo-files' 2388 Removes files generated for this test for `-frepo'. 2389 2390 `cleanup-rtl-dump SUFFIX' 2391 Removes RTL dump files generated for this test. 2392 2393 `cleanup-tree-dump SUFFIX' 2394 Removes tree dump files matching SUFFIX which were generated 2395 for this test. 2396 2397 `cleanup-saved-temps' 2398 Removes files for the current test which were kept for 2399 `--save-temps'. 2400 2401 `scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]' 2402 Passes if REGEXP matches text in FILENAME. 2403 2404 `scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]' 2405 Passes if REGEXP does not match text in FILENAME. 2406 2407 `scan-hidden SYMBOL [{ target/xfail SELECTOR }]' 2408 Passes if SYMBOL is defined as a hidden symbol in the test's 2409 assembly output. 2410 2411 `scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]' 2412 Passes if SYMBOL is not defined as a hidden symbol in the 2413 test's assembly output. 2414 2415 `scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]' 2416 Passes if REGEX is matched exactly NUM times in the test's 2417 assembler output. 2418 2419 `scan-assembler REGEX [{ target/xfail SELECTOR }]' 2420 Passes if REGEX matches text in the test's assembler output. 2421 2422 `scan-assembler-not REGEX [{ target/xfail SELECTOR }]' 2423 Passes if REGEX does not match text in the test's assembler 2424 output. 2425 2426 `scan-assembler-dem REGEX [{ target/xfail SELECTOR }]' 2427 Passes if REGEX matches text in the test's demangled 2428 assembler output. 2429 2430 `scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]' 2431 Passes if REGEX does not match text in the test's demangled 2432 assembler output. 2433 2434 `scan-tree-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]' 2435 Passes if REGEX is found exactly NUM times in the dump file 2436 with suffix SUFFIX. 2437 2438 `scan-tree-dump REGEX SUFFIX [{ target/xfail SELECTOR }]' 2439 Passes if REGEX matches text in the dump file with suffix 2440 SUFFIX. 2441 2442 `scan-tree-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 2443 Passes if REGEX does not match text in the dump file with 2444 suffix SUFFIX. 2445 2446 `scan-tree-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]' 2447 Passes if REGEX matches demangled text in the dump file with 2448 suffix SUFFIX. 2449 2450 `scan-tree-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 2451 Passes if REGEX does not match demangled text in the dump 2452 file with suffix SUFFIX. 2453 2454 `output-exists [{ target/xfail SELECTOR }]' 2455 Passes if compiler output file exists. 2456 2457 `output-exists-not [{ target/xfail SELECTOR }]' 2458 Passes if compiler output file does not exist. 2459 2460 `run-gcov SOURCEFILE' 2461 Check line counts in `gcov' tests. 2462 2463 `run-gcov [branches] [calls] { OPTS SOURCEFILE }' 2464 Check branch and/or call counts, in addition to line counts, 2465 in `gcov' tests. 2466 2467 2468 File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites 2469 2470 6.4.3 Ada Language Testsuites 2471 ----------------------------- 2472 2473 The Ada testsuite includes executable tests from the ACATS 2.5 2474 testsuite, publicly available at 2475 `http://www.adaic.org/compilers/acats/2.5' 2476 2477 These tests are integrated in the GCC testsuite in the 2478 `gcc/testsuite/ada/acats' directory, and enabled automatically when 2479 running `make check', assuming the Ada language has been enabled when 2480 configuring GCC. 2481 2482 You can also run the Ada testsuite independently, using `make 2483 check-ada', or run a subset of the tests by specifying which chapter to 2484 run, e.g.: 2485 2486 $ make check-ada CHAPTERS="c3 c9" 2487 2488 The tests are organized by directory, each directory corresponding to 2489 a chapter of the Ada Reference Manual. So for example, c9 corresponds 2490 to chapter 9, which deals with tasking features of the language. 2491 2492 There is also an extra chapter called `gcc' containing a template for 2493 creating new executable tests. 2494 2495 The tests are run using two `sh' scripts: `run_acats' and 2496 `run_all.sh'. To run the tests using a simulator or a cross target, 2497 see the small customization section at the top of `run_all.sh'. 2498 2499 These tests are run using the build tree: they can be run without doing 2500 a `make install'. 2501 2502 2503 File: gccint.info, Node: C Tests, Next: libgcj Tests, Prev: Ada Tests, Up: Testsuites 2504 2505 6.4.4 C Language Testsuites 2506 --------------------------- 2507 2508 GCC contains the following C language testsuites, in the 2509 `gcc/testsuite' directory: 2510 2511 `gcc.dg' 2512 This contains tests of particular features of the C compiler, 2513 using the more modern `dg' harness. Correctness tests for various 2514 compiler features should go here if possible. 2515 2516 Magic comments determine whether the file is preprocessed, 2517 compiled, linked or run. In these tests, error and warning 2518 message texts are compared against expected texts or regular 2519 expressions given in comments. These tests are run with the 2520 options `-ansi -pedantic' unless other options are given in the 2521 test. Except as noted below they are not run with multiple 2522 optimization options. 2523 2524 `gcc.dg/compat' 2525 This subdirectory contains tests for binary compatibility using 2526 `compat.exp', which in turn uses the language-independent support 2527 (*note Support for testing binary compatibility: compat Testing.). 2528 2529 `gcc.dg/cpp' 2530 This subdirectory contains tests of the preprocessor. 2531 2532 `gcc.dg/debug' 2533 This subdirectory contains tests for debug formats. Tests in this 2534 subdirectory are run for each debug format that the compiler 2535 supports. 2536 2537 `gcc.dg/format' 2538 This subdirectory contains tests of the `-Wformat' format 2539 checking. Tests in this directory are run with and without 2540 `-DWIDE'. 2541 2542 `gcc.dg/noncompile' 2543 This subdirectory contains tests of code that should not compile 2544 and does not need any special compilation options. They are run 2545 with multiple optimization options, since sometimes invalid code 2546 crashes the compiler with optimization. 2547 2548 `gcc.dg/special' 2549 FIXME: describe this. 2550 2551 `gcc.c-torture' 2552 This contains particular code fragments which have historically 2553 broken easily. These tests are run with multiple optimization 2554 options, so tests for features which only break at some 2555 optimization levels belong here. This also contains tests to 2556 check that certain optimizations occur. It might be worthwhile to 2557 separate the correctness tests cleanly from the code quality 2558 tests, but it hasn't been done yet. 2559 2560 `gcc.c-torture/compat' 2561 FIXME: describe this. 2562 2563 This directory should probably not be used for new tests. 2564 2565 `gcc.c-torture/compile' 2566 This testsuite contains test cases that should compile, but do not 2567 need to link or run. These test cases are compiled with several 2568 different combinations of optimization options. All warnings are 2569 disabled for these test cases, so this directory is not suitable if 2570 you wish to test for the presence or absence of compiler warnings. 2571 While special options can be set, and tests disabled on specific 2572 platforms, by the use of `.x' files, mostly these test cases 2573 should not contain platform dependencies. FIXME: discuss how 2574 defines such as `NO_LABEL_VALUES' and `STACK_SIZE' are used. 2575 2576 `gcc.c-torture/execute' 2577 This testsuite contains test cases that should compile, link and 2578 run; otherwise the same comments as for `gcc.c-torture/compile' 2579 apply. 2580 2581 `gcc.c-torture/execute/ieee' 2582 This contains tests which are specific to IEEE floating point. 2583 2584 `gcc.c-torture/unsorted' 2585 FIXME: describe this. 2586 2587 This directory should probably not be used for new tests. 2588 2589 `gcc.c-torture/misc-tests' 2590 This directory contains C tests that require special handling. 2591 Some of these tests have individual expect files, and others share 2592 special-purpose expect files: 2593 2594 ``bprob*.c'' 2595 Test `-fbranch-probabilities' using `bprob.exp', which in 2596 turn uses the generic, language-independent framework (*note 2597 Support for testing profile-directed optimizations: profopt 2598 Testing.). 2599 2600 ``dg-*.c'' 2601 Test the testsuite itself using `dg-test.exp'. 2602 2603 ``gcov*.c'' 2604 Test `gcov' output using `gcov.exp', which in turn uses the 2605 language-independent support (*note Support for testing gcov: 2606 gcov Testing.). 2607 2608 ``i386-pf-*.c'' 2609 Test i386-specific support for data prefetch using 2610 `i386-prefetch.exp'. 2611 2612 2613 FIXME: merge in `testsuite/README.gcc' and discuss the format of test 2614 cases and magic comments more. 2615 2616 2617 File: gccint.info, Node: libgcj Tests, Next: gcov Testing, Prev: C Tests, Up: Testsuites 2618 2619 6.4.5 The Java library testsuites. 2620 ---------------------------------- 2621 2622 Runtime tests are executed via `make check' in the 2623 `TARGET/libjava/testsuite' directory in the build tree. Additional 2624 runtime tests can be checked into this testsuite. 2625 2626 Regression testing of the core packages in libgcj is also covered by 2627 the Mauve testsuite. The Mauve Project develops tests for the Java 2628 Class Libraries. These tests are run as part of libgcj testing by 2629 placing the Mauve tree within the libjava testsuite sources at 2630 `libjava/testsuite/libjava.mauve/mauve', or by specifying the location 2631 of that tree when invoking `make', as in `make MAUVEDIR=~/mauve check'. 2632 2633 To detect regressions, a mechanism in `mauve.exp' compares the 2634 failures for a test run against the list of expected failures in 2635 `libjava/testsuite/libjava.mauve/xfails' from the source hierarchy. 2636 Update this file when adding new failing tests to Mauve, or when fixing 2637 bugs in libgcj that had caused Mauve test failures. 2638 2639 The Jacks project provides a testsuite for Java compilers that can be 2640 used to test changes that affect the GCJ front end. This testsuite is 2641 run as part of Java testing by placing the Jacks tree within the libjava 2642 testsuite sources at `libjava/testsuite/libjava.jacks/jacks'. 2643 2644 We encourage developers to contribute test cases to Mauve and Jacks. 2645 2646 2647 File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: libgcj Tests, Up: Testsuites 2648 2649 6.4.6 Support for testing `gcov' 2650 -------------------------------- 2651 2652 Language-independent support for testing `gcov', and for checking that 2653 branch profiling produces expected values, is provided by the expect 2654 file `gcov.exp'. `gcov' tests also rely on procedures in `gcc.dg.exp' 2655 to compile and run the test program. A typical `gcov' test contains 2656 the following DejaGnu commands within comments: 2657 2658 { dg-options "-fprofile-arcs -ftest-coverage" } 2659 { dg-do run { target native } } 2660 { dg-final { run-gcov sourcefile } } 2661 2662 Checks of `gcov' output can include line counts, branch percentages, 2663 and call return percentages. All of these checks are requested via 2664 commands that appear in comments in the test's source file. Commands 2665 to check line counts are processed by default. Commands to check 2666 branch percentages and call return percentages are processed if the 2667 `run-gcov' command has arguments `branches' or `calls', respectively. 2668 For example, the following specifies checking both, as well as passing 2669 `-b' to `gcov': 2670 2671 { dg-final { run-gcov branches calls { -b sourcefile } } } 2672 2673 A line count command appears within a comment on the source line that 2674 is expected to get the specified count and has the form `count(CNT)'. 2675 A test should only check line counts for lines that will get the same 2676 count for any architecture. 2677 2678 Commands to check branch percentages (`branch') and call return 2679 percentages (`returns') are very similar to each other. A beginning 2680 command appears on or before the first of a range of lines that will 2681 report the percentage, and the ending command follows that range of 2682 lines. The beginning command can include a list of percentages, all of 2683 which are expected to be found within the range. A range is terminated 2684 by the next command of the same kind. A command `branch(end)' or 2685 `returns(end)' marks the end of a range without starting a new one. 2686 For example: 2687 2688 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */ 2689 /* branch(end) */ 2690 foo (i, j); 2691 2692 For a call return percentage, the value specified is the percentage of 2693 calls reported to return. For a branch percentage, the value is either 2694 the expected percentage or 100 minus that value, since the direction of 2695 a branch can differ depending on the target or the optimization level. 2696 2697 Not all branches and calls need to be checked. A test should not 2698 check for branches that might be optimized away or replaced with 2699 predicated instructions. Don't check for calls inserted by the 2700 compiler or ones that might be inlined or optimized away. 2701 2702 A single test can check for combinations of line counts, branch 2703 percentages, and call return percentages. The command to check a line 2704 count must appear on the line that will report that count, but commands 2705 to check branch percentages and call return percentages can bracket the 2706 lines that report them. 2707 2708 2709 File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites 2710 2711 6.4.7 Support for testing profile-directed optimizations 2712 -------------------------------------------------------- 2713 2714 The file `profopt.exp' provides language-independent support for 2715 checking correct execution of a test built with profile-directed 2716 optimization. This testing requires that a test program be built and 2717 executed twice. The first time it is compiled to generate profile 2718 data, and the second time it is compiled to use the data that was 2719 generated during the first execution. The second execution is to 2720 verify that the test produces the expected results. 2721 2722 To check that the optimization actually generated better code, a test 2723 can be built and run a third time with normal optimizations to verify 2724 that the performance is better with the profile-directed optimizations. 2725 `profopt.exp' has the beginnings of this kind of support. 2726 2727 `profopt.exp' provides generic support for profile-directed 2728 optimizations. Each set of tests that uses it provides information 2729 about a specific optimization: 2730 2731 `tool' 2732 tool being tested, e.g., `gcc' 2733 2734 `profile_option' 2735 options used to generate profile data 2736 2737 `feedback_option' 2738 options used to optimize using that profile data 2739 2740 `prof_ext' 2741 suffix of profile data files 2742 2743 `PROFOPT_OPTIONS' 2744 list of options with which to run each test, similar to the lists 2745 for torture tests 2746 2747 2748 File: gccint.info, Node: compat Testing, Prev: profopt Testing, Up: Testsuites 2749 2750 6.4.8 Support for testing binary compatibility 2751 ---------------------------------------------- 2752 2753 The file `compat.exp' provides language-independent support for binary 2754 compatibility testing. It supports testing interoperability of two 2755 compilers that follow the same ABI, or of multiple sets of compiler 2756 options that should not affect binary compatibility. It is intended to 2757 be used for testsuites that complement ABI testsuites. 2758 2759 A test supported by this framework has three parts, each in a separate 2760 source file: a main program and two pieces that interact with each 2761 other to split up the functionality being tested. 2762 2763 `TESTNAME_main.SUFFIX' 2764 Contains the main program, which calls a function in file 2765 `TESTNAME_x.SUFFIX'. 2766 2767 `TESTNAME_x.SUFFIX' 2768 Contains at least one call to a function in `TESTNAME_y.SUFFIX'. 2769 2770 `TESTNAME_y.SUFFIX' 2771 Shares data with, or gets arguments from, `TESTNAME_x.SUFFIX'. 2772 2773 Within each test, the main program and one functional piece are 2774 compiled by the GCC under test. The other piece can be compiled by an 2775 alternate compiler. If no alternate compiler is specified, then all 2776 three source files are all compiled by the GCC under test. You can 2777 specify pairs of sets of compiler options. The first element of such a 2778 pair specifies options used with the GCC under test, and the second 2779 element of the pair specifies options used with the alternate compiler. 2780 Each test is compiled with each pair of options. 2781 2782 `compat.exp' defines default pairs of compiler options. These can be 2783 overridden by defining the environment variable `COMPAT_OPTIONS' as: 2784 2785 COMPAT_OPTIONS="[list [list {TST1} {ALT1}] 2786 ...[list {TSTN} {ALTN}]]" 2787 2788 where TSTI and ALTI are lists of options, with TSTI used by the 2789 compiler under test and ALTI used by the alternate compiler. For 2790 example, with `[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]', 2791 the test is first built with `-g -O0' by the compiler under test and 2792 with `-O3' by the alternate compiler. The test is built a second time 2793 using `-fpic' by the compiler under test and `-fPIC -O2' by the 2794 alternate compiler. 2795 2796 An alternate compiler is specified by defining an environment variable 2797 to be the full pathname of an installed compiler; for C define 2798 `ALT_CC_UNDER_TEST', and for C++ define `ALT_CXX_UNDER_TEST'. These 2799 will be written to the `site.exp' file used by DejaGnu. The default is 2800 to build each test with the compiler under test using the first of each 2801 pair of compiler options from `COMPAT_OPTIONS'. When 2802 `ALT_CC_UNDER_TEST' or `ALT_CXX_UNDER_TEST' is `same', each test is 2803 built using the compiler under test but with combinations of the 2804 options from `COMPAT_OPTIONS'. 2805 2806 To run only the C++ compatibility suite using the compiler under test 2807 and another version of GCC using specific compiler options, do the 2808 following from `OBJDIR/gcc': 2809 2810 rm site.exp 2811 make -k \ 2812 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \ 2813 COMPAT_OPTIONS="lists as shown above" \ 2814 check-c++ \ 2815 RUNTESTFLAGS="compat.exp" 2816 2817 A test that fails when the source files are compiled with different 2818 compilers, but passes when the files are compiled with the same 2819 compiler, demonstrates incompatibility of the generated code or runtime 2820 support. A test that fails for the alternate compiler but passes for 2821 the compiler under test probably tests for a bug that was fixed in the 2822 compiler under test but is present in the alternate compiler. 2823 2824 The binary compatibility tests support a small number of test framework 2825 commands that appear within comments in a test file. 2826 2827 `dg-require-*' 2828 These commands can be used in `TESTNAME_main.SUFFIX' to skip the 2829 test if specific support is not available on the target. 2830 2831 `dg-options' 2832 The specified options are used for compiling this particular source 2833 file, appended to the options from `COMPAT_OPTIONS'. When this 2834 command appears in `TESTNAME_main.SUFFIX' the options are also 2835 used to link the test program. 2836 2837 `dg-xfail-if' 2838 This command can be used in a secondary source file to specify that 2839 compilation is expected to fail for particular options on 2840 particular targets. 2841 2842 2843 File: gccint.info, Node: Options, Next: Passes, Prev: Source Tree, Up: Top 2844 2845 7 Option specification files 2846 **************************** 2847 2848 Most GCC command-line options are described by special option 2849 definition files, the names of which conventionally end in `.opt'. 2850 This chapter describes the format of these files. 2851 2852 * Menu: 2853 2854 * Option file format:: The general layout of the files 2855 * Option properties:: Supported option properties 2856 2857 2858 File: gccint.info, Node: Option file format, Next: Option properties, Up: Options 2859 2860 7.1 Option file format 2861 ====================== 2862 2863 Option files are a simple list of records in which each field occupies 2864 its own line and in which the records themselves are separated by blank 2865 lines. Comments may appear on their own line anywhere within the file 2866 and are preceded by semicolons. Whitespace is allowed before the 2867 semicolon. 2868 2869 The files can contain the following types of record: 2870 2871 * A language definition record. These records have two fields: the 2872 string `Language' and the name of the language. Once a language 2873 has been declared in this way, it can be used as an option 2874 property. *Note Option properties::. 2875 2876 * An option definition record. These records have the following 2877 fields: 2878 2879 1. the name of the option, with the leading "-" removed 2880 2881 2. a space-separated list of option properties (*note Option 2882 properties::) 2883 2884 3. the help text to use for `--help' (omitted if the second field 2885 contains the `Undocumented' property). 2886 2887 By default, all options beginning with "f", "W" or "m" are 2888 implicitly assumed to take a "no-" form. This form should not be 2889 listed separately. If an option beginning with one of these 2890 letters does not have a "no-" form, you can use the 2891 `RejectNegative' property to reject it. 2892 2893 The help text is automatically line-wrapped before being displayed. 2894 Normally the name of the option is printed on the left-hand side of 2895 the output and the help text is printed on the right. However, if 2896 the help text contains a tab character, the text to the left of 2897 the tab is used instead of the option's name and the text to the 2898 right of the tab forms the help text. This allows you to 2899 elaborate on what type of argument the option takes. 2900 2901 * A target mask record. These records have one field of the form 2902 `Mask(X)'. The options-processing script will automatically 2903 allocate a bit in `target_flags' (*note Run-time Target::) for 2904 each mask name X and set the macro `MASK_X' to the appropriate 2905 bitmask. It will also declare a `TARGET_X' macro that has the 2906 value 1 when bit `MASK_X' is set and 0 otherwise. 2907 2908 They are primarily intended to declare target masks that are not 2909 associated with user options, either because these masks represent 2910 internal switches or because the options are not available on all 2911 configurations and yet the masks always need to be defined. 2912 2913 2914 File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options 2915 2916 7.2 Option properties 2917 ===================== 2918 2919 The second field of an option record can specify the following 2920 properties: 2921 2922 `Common' 2923 The option is available for all languages and targets. 2924 2925 `Target' 2926 The option is available for all languages but is target-specific. 2927 2928 `LANGUAGE' 2929 The option is available when compiling for the given language. 2930 2931 It is possible to specify several different languages for the same 2932 option. Each LANGUAGE must have been declared by an earlier 2933 `Language' record. *Note Option file format::. 2934 2935 `RejectNegative' 2936 The option does not have a "no-" form. All options beginning with 2937 "f", "W" or "m" are assumed to have a "no-" form unless this 2938 property is used. 2939 2940 `Negative(OTHERNAME)' 2941 The option will turn off another option OTHERNAME, which is the 2942 the option name with the leading "-" removed. This chain action 2943 will propagate through the `Negative' property of the option to be 2944 turned off. 2945 2946 `Joined' 2947 `Separate' 2948 The option takes a mandatory argument. `Joined' indicates that 2949 the option and argument can be included in the same `argv' entry 2950 (as with `-mflush-func=NAME', for example). `Separate' indicates 2951 that the option and argument can be separate `argv' entries (as 2952 with `-o'). An option is allowed to have both of these properties. 2953 2954 `JoinedOrMissing' 2955 The option takes an optional argument. If the argument is given, 2956 it will be part of the same `argv' entry as the option itself. 2957 2958 This property cannot be used alongside `Joined' or `Separate'. 2959 2960 `UInteger' 2961 The option's argument is a non-negative integer. The option parser 2962 will check and convert the argument before passing it to the 2963 relevant option handler. 2964 2965 `Var(VAR)' 2966 The state of this option should be stored in variable VAR. The 2967 way that the state is stored depends on the type of option: 2968 2969 * If the option uses the `Mask' or `InverseMask' properties, 2970 VAR is the integer variable that contains the mask. 2971 2972 * If the option is a normal on/off switch, VAR is an integer 2973 variable that is nonzero when the option is enabled. The 2974 options parser will set the variable to 1 when the positive 2975 form of the option is used and 0 when the "no-" form is used. 2976 2977 * If the option takes an argument and has the `UInteger' 2978 property, VAR is an integer variable that stores the value of 2979 the argument. 2980 2981 * Otherwise, if the option takes an argument, VAR is a pointer 2982 to the argument string. The pointer will be null if the 2983 argument is optional and wasn't given. 2984 2985 The option-processing script will usually declare VAR in 2986 `options.c' and leave it to be zero-initialized at start-up time. 2987 You can modify this behavior using `VarExists' and `Init'. 2988 2989 `Var(VAR, SET)' 2990 The option controls an integer variable VAR and is active when VAR 2991 equals SET. The option parser will set VAR to SET when the 2992 positive form of the option is used and `!SET' when the "no-" form 2993 is used. 2994 2995 VAR is declared in the same way as for the single-argument form 2996 described above. 2997 2998 `VarExists' 2999 The variable specified by the `Var' property already exists. No 3000 definition should be added to `options.c' in response to this 3001 option record. 3002 3003 You should use this property only if the variable is declared 3004 outside `options.c'. 3005 3006 `Init(VALUE)' 3007 The variable specified by the `Var' property should be statically 3008 initialized to VALUE. 3009 3010 `Mask(NAME)' 3011 The option is associated with a bit in the `target_flags' variable 3012 (*note Run-time Target::) and is active when that bit is set. You 3013 may also specify `Var' to select a variable other than 3014 `target_flags'. 3015 3016 The options-processing script will automatically allocate a unique 3017 bit for the option. If the option is attached to `target_flags', 3018 the script will set the macro `MASK_NAME' to the appropriate 3019 bitmask. It will also declare a `TARGET_NAME' macro that has the 3020 value 1 when the option is active and 0 otherwise. If you use 3021 `Var' to attach the option to a different variable, the associated 3022 macros are called `OPTION_MASK_NAME' and `OPTION_NAME' 3023 respectively. 3024 3025 You can disable automatic bit allocation using `MaskExists'. 3026 3027 `InverseMask(OTHERNAME)' 3028 `InverseMask(OTHERNAME, THISNAME)' 3029 The option is the inverse of another option that has the 3030 `Mask(OTHERNAME)' property. If THISNAME is given, the 3031 options-processing script will declare a `TARGET_THISNAME' macro 3032 that is 1 when the option is active and 0 otherwise. 3033 3034 `MaskExists' 3035 The mask specified by the `Mask' property already exists. No 3036 `MASK' or `TARGET' definitions should be added to `options.h' in 3037 response to this option record. 3038 3039 The main purpose of this property is to support synonymous options. 3040 The first option should use `Mask(NAME)' and the others should use 3041 `Mask(NAME) MaskExists'. 3042 3043 `Report' 3044 The state of the option should be printed by `-fverbose-asm'. 3045 3046 `Undocumented' 3047 The option is deliberately missing documentation and should not be 3048 included in the `--help' output. 3049 3050 `Condition(COND)' 3051 The option should only be accepted if preprocessor condition COND 3052 is true. Note that any C declarations associated with the option 3053 will be present even if COND is false; COND simply controls 3054 whether the option is accepted and whether it is printed in the 3055 `--help' output. 3056 3057 3058 File: gccint.info, Node: Passes, Next: Trees, Prev: Options, Up: Top 3059 3060 8 Passes and Files of the Compiler 3061 ********************************** 3062 3063 This chapter is dedicated to giving an overview of the optimization and 3064 code generation passes of the compiler. In the process, it describes 3065 some of the language front end interface, though this description is no 3066 where near complete. 3067 3068 * Menu: 3069 3070 * Parsing pass:: The language front end turns text into bits. 3071 * Gimplification pass:: The bits are turned into something we can optimize. 3072 * Pass manager:: Sequencing the optimization passes. 3073 * Tree-SSA passes:: Optimizations on a high-level representation. 3074 * RTL passes:: Optimizations on a low-level representation. 3075 3076 3077 File: gccint.info, Node: Parsing pass, Next: Gimplification pass, Up: Passes 3078 3079 8.1 Parsing pass 3080 ================ 3081 3082 The language front end is invoked only once, via 3083 `lang_hooks.parse_file', to parse the entire input. The language front 3084 end may use any intermediate language representation deemed 3085 appropriate. The C front end uses GENERIC trees (CROSSREF), plus a 3086 double handful of language specific tree codes defined in 3087 `c-common.def'. The Fortran front end uses a completely different 3088 private representation. 3089 3090 At some point the front end must translate the representation used in 3091 the front end to a representation understood by the language-independent 3092 portions of the compiler. Current practice takes one of two forms. 3093 The C front end manually invokes the gimplifier (CROSSREF) on each 3094 function, and uses the gimplifier callbacks to convert the 3095 language-specific tree nodes directly to GIMPLE (CROSSREF) before 3096 passing the function off to be compiled. The Fortran front end 3097 converts from a private representation to GENERIC, which is later 3098 lowered to GIMPLE when the function is compiled. Which route to choose 3099 probably depends on how well GENERIC (plus extensions) can be made to 3100 match up with the source language and necessary parsing data structures. 3101 3102 BUG: Gimplification must occur before nested function lowering, and 3103 nested function lowering must be done by the front end before passing 3104 the data off to cgraph. 3105 3106 TODO: Cgraph should control nested function lowering. It would only 3107 be invoked when it is certain that the outer-most function is used. 3108 3109 TODO: Cgraph needs a gimplify_function callback. It should be invoked 3110 when (1) it is certain that the function is used, (2) warning flags 3111 specified by the user require some amount of compilation in order to 3112 honor, (3) the language indicates that semantic analysis is not 3113 complete until gimplification occurs. Hum... this sounds overly 3114 complicated. Perhaps we should just have the front end gimplify 3115 always; in most cases it's only one function call. 3116 3117 The front end needs to pass all function definitions and top level 3118 declarations off to the middle-end so that they can be compiled and 3119 emitted to the object file. For a simple procedural language, it is 3120 usually most convenient to do this as each top level declaration or 3121 definition is seen. There is also a distinction to be made between 3122 generating functional code and generating complete debug information. 3123 The only thing that is absolutely required for functional code is that 3124 function and data _definitions_ be passed to the middle-end. For 3125 complete debug information, function, data and type declarations should 3126 all be passed as well. 3127 3128 In any case, the front end needs each complete top-level function or 3129 data declaration, and each data definition should be passed to 3130 `rest_of_decl_compilation'. Each complete type definition should be 3131 passed to `rest_of_type_compilation'. Each function definition should 3132 be passed to `cgraph_finalize_function'. 3133 3134 TODO: I know rest_of_compilation currently has all sorts of 3135 rtl-generation semantics. I plan to move all code generation bits 3136 (both tree and rtl) to compile_function. Should we hide cgraph from 3137 the front ends and move back to rest_of_compilation as the official 3138 interface? Possibly we should rename all three interfaces such that 3139 the names match in some meaningful way and that is more descriptive 3140 than "rest_of". 3141 3142 The middle-end will, at its option, emit the function and data 3143 definitions immediately or queue them for later processing. 3144 3145 3146 File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Parsing pass, Up: Passes 3147 3148 8.2 Gimplification pass 3149 ======================= 3150 3151 "Gimplification" is a whimsical term for the process of converting the 3152 intermediate representation of a function into the GIMPLE language 3153 (CROSSREF). The term stuck, and so words like "gimplification", 3154 "gimplify", "gimplifier" and the like are sprinkled throughout this 3155 section of code. 3156 3157 While a front end may certainly choose to generate GIMPLE directly if 3158 it chooses, this can be a moderately complex process unless the 3159 intermediate language used by the front end is already fairly simple. 3160 Usually it is easier to generate GENERIC trees plus extensions and let 3161 the language-independent gimplifier do most of the work. 3162 3163 The main entry point to this pass is `gimplify_function_tree' located 3164 in `gimplify.c'. From here we process the entire function gimplifying 3165 each statement in turn. The main workhorse for this pass is 3166 `gimplify_expr'. Approximately everything passes through here at least 3167 once, and it is from here that we invoke the `lang_hooks.gimplify_expr' 3168 callback. 3169 3170 The callback should examine the expression in question and return 3171 `GS_UNHANDLED' if the expression is not a language specific construct 3172 that requires attention. Otherwise it should alter the expression in 3173 some way to such that forward progress is made toward producing valid 3174 GIMPLE. If the callback is certain that the transformation is complete 3175 and the expression is valid GIMPLE, it should return `GS_ALL_DONE'. 3176 Otherwise it should return `GS_OK', which will cause the expression to 3177 be processed again. If the callback encounters an error during the 3178 transformation (because the front end is relying on the gimplification 3179 process to finish semantic checks), it should return `GS_ERROR'. 3180 3181 3182 File: gccint.info, Node: Pass manager, Next: Tree-SSA passes, Prev: Gimplification pass, Up: Passes 3183 3184 8.3 Pass manager 3185 ================ 3186 3187 The pass manager is located in `passes.c', `tree-optimize.c' and 3188 `tree-pass.h'. Its job is to run all of the individual passes in the 3189 correct order, and take care of standard bookkeeping that applies to 3190 every pass. 3191 3192 The theory of operation is that each pass defines a structure that 3193 represents everything we need to know about that pass--when it should 3194 be run, how it should be run, what intermediate language form or 3195 on-the-side data structures it needs. We register the pass to be run 3196 in some particular order, and the pass manager arranges for everything 3197 to happen in the correct order. 3198 3199 The actuality doesn't completely live up to the theory at present. 3200 Command-line switches and `timevar_id_t' enumerations must still be 3201 defined elsewhere. The pass manager validates constraints but does not 3202 attempt to (re-)generate data structures or lower intermediate language 3203 form based on the requirements of the next pass. Nevertheless, what is 3204 present is useful, and a far sight better than nothing at all. 3205 3206 TODO: describe the global variables set up by the pass manager, and a 3207 brief description of how a new pass should use it. I need to look at 3208 what info rtl passes use first... 3209 3210 3211 File: gccint.info, Node: Tree-SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes 3212 3213 8.4 Tree-SSA passes 3214 =================== 3215 3216 The following briefly describes the tree optimization passes that are 3217 run after gimplification and what source files they are located in. 3218 3219 * Remove useless statements 3220 3221 This pass is an extremely simple sweep across the gimple code in 3222 which we identify obviously dead code and remove it. Here we do 3223 things like simplify `if' statements with constant conditions, 3224 remove exception handling constructs surrounding code that 3225 obviously cannot throw, remove lexical bindings that contain no 3226 variables, and other assorted simplistic cleanups. The idea is to 3227 get rid of the obvious stuff quickly rather than wait until later 3228 when it's more work to get rid of it. This pass is located in 3229 `tree-cfg.c' and described by `pass_remove_useless_stmts'. 3230 3231 * Mudflap declaration registration 3232 3233 If mudflap (*note -fmudflap -fmudflapth -fmudflapir: (gcc)Optimize 3234 Options.) is enabled, we generate code to register some variable 3235 declarations with the mudflap runtime. Specifically, the runtime 3236 tracks the lifetimes of those variable declarations that have 3237 their addresses taken, or whose bounds are unknown at compile time 3238 (`extern'). This pass generates new exception handling constructs 3239 (`try'/`finally'), and so must run before those are lowered. In 3240 addition, the pass enqueues declarations of static variables whose 3241 lifetimes extend to the entire program. The pass is located in 3242 `tree-mudflap.c' and is described by `pass_mudflap_1'. 3243 3244 * OpenMP lowering 3245 3246 If OpenMP generation (`-fopenmp') is enabled, this pass lowers 3247 OpenMP constructs into GIMPLE. 3248 3249 Lowering of OpenMP constructs involves creating replacement 3250 expressions for local variables that have been mapped using data 3251 sharing clauses, exposing the control flow of most synchronization 3252 directives and adding region markers to facilitate the creation of 3253 the control flow graph. The pass is located in `omp-low.c' and is 3254 described by `pass_lower_omp'. 3255 3256 * OpenMP expansion 3257 3258 If OpenMP generation (`-fopenmp') is enabled, this pass expands 3259 parallel regions into their own functions to be invoked by the 3260 thread library. The pass is located in `omp-low.c' and is 3261 described by `pass_expand_omp'. 3262 3263 * Lower control flow 3264 3265 This pass flattens `if' statements (`COND_EXPR') and moves lexical 3266 bindings (`BIND_EXPR') out of line. After this pass, all `if' 3267 statements will have exactly two `goto' statements in its `then' 3268 and `else' arms. Lexical binding information for each statement 3269 will be found in `TREE_BLOCK' rather than being inferred from its 3270 position under a `BIND_EXPR'. This pass is found in 3271 `gimple-low.c' and is described by `pass_lower_cf'. 3272 3273 * Lower exception handling control flow 3274 3275 This pass decomposes high-level exception handling constructs 3276 (`TRY_FINALLY_EXPR' and `TRY_CATCH_EXPR') into a form that 3277 explicitly represents the control flow involved. After this pass, 3278 `lookup_stmt_eh_region' will return a non-negative number for any 3279 statement that may have EH control flow semantics; examine 3280 `tree_can_throw_internal' or `tree_can_throw_external' for exact 3281 semantics. Exact control flow may be extracted from 3282 `foreach_reachable_handler'. The EH region nesting tree is defined 3283 in `except.h' and built in `except.c'. The lowering pass itself 3284 is in `tree-eh.c' and is described by `pass_lower_eh'. 3285 3286 * Build the control flow graph 3287 3288 This pass decomposes a function into basic blocks and creates all 3289 of the edges that connect them. It is located in `tree-cfg.c' and 3290 is described by `pass_build_cfg'. 3291 3292 * Find all referenced variables 3293 3294 This pass walks the entire function and collects an array of all 3295 variables referenced in the function, `referenced_vars'. The 3296 index at which a variable is found in the array is used as a UID 3297 for the variable within this function. This data is needed by the 3298 SSA rewriting routines. The pass is located in `tree-dfa.c' and 3299 is described by `pass_referenced_vars'. 3300 3301 * Enter static single assignment form 3302 3303 This pass rewrites the function such that it is in SSA form. After 3304 this pass, all `is_gimple_reg' variables will be referenced by 3305 `SSA_NAME', and all occurrences of other variables will be 3306 annotated with `VDEFS' and `VUSES'; PHI nodes will have been 3307 inserted as necessary for each basic block. This pass is located 3308 in `tree-ssa.c' and is described by `pass_build_ssa'. 3309 3310 * Warn for uninitialized variables 3311 3312 This pass scans the function for uses of `SSA_NAME's that are fed 3313 by default definition. For non-parameter variables, such uses are 3314 uninitialized. The pass is run twice, before and after 3315 optimization. In the first pass we only warn for uses that are 3316 positively uninitialized; in the second pass we warn for uses that 3317 are possibly uninitialized. The pass is located in `tree-ssa.c' 3318 and is defined by `pass_early_warn_uninitialized' and 3319 `pass_late_warn_uninitialized'. 3320 3321 * Dead code elimination 3322 3323 This pass scans the function for statements without side effects 3324 whose result is unused. It does not do memory life analysis, so 3325 any value that is stored in memory is considered used. The pass 3326 is run multiple times throughout the optimization process. It is 3327 located in `tree-ssa-dce.c' and is described by `pass_dce'. 3328 3329 * Dominator optimizations 3330 3331 This pass performs trivial dominator-based copy and constant 3332 propagation, expression simplification, and jump threading. It is 3333 run multiple times throughout the optimization process. It it 3334 located in `tree-ssa-dom.c' and is described by `pass_dominator'. 3335 3336 * Redundant PHI elimination 3337 3338 This pass removes PHI nodes for which all of the arguments are the 3339 same value, excluding feedback. Such degenerate forms are 3340 typically created by removing unreachable code. The pass is run 3341 multiple times throughout the optimization process. It is located 3342 in `tree-ssa.c' and is described by `pass_redundant_phi'.o 3343 3344 * Forward propagation of single-use variables 3345 3346 This pass attempts to remove redundant computation by substituting 3347 variables that are used once into the expression that uses them and 3348 seeing if the result can be simplified. It is located in 3349 `tree-ssa-forwprop.c' and is described by `pass_forwprop'. 3350 3351 * Copy Renaming 3352 3353 This pass attempts to change the name of compiler temporaries 3354 involved in copy operations such that SSA->normal can coalesce the 3355 copy away. When compiler temporaries are copies of user 3356 variables, it also renames the compiler temporary to the user 3357 variable resulting in better use of user symbols. It is located 3358 in `tree-ssa-copyrename.c' and is described by `pass_copyrename'. 3359 3360 * PHI node optimizations 3361 3362 This pass recognizes forms of PHI inputs that can be represented as 3363 conditional expressions and rewrites them into straight line code. 3364 It is located in `tree-ssa-phiopt.c' and is described by 3365 `pass_phiopt'. 3366 3367 * May-alias optimization 3368 3369 This pass performs a flow sensitive SSA-based points-to analysis. 3370 The resulting may-alias, must-alias, and escape analysis 3371 information is used to promote variables from in-memory 3372 addressable objects to non-aliased variables that can be renamed 3373 into SSA form. We also update the `VDEF'/`VUSE' memory tags for 3374 non-renameable aggregates so that we get fewer false kills. The 3375 pass is located in `tree-ssa-alias.c' and is described by 3376 `pass_may_alias'. 3377 3378 Interprocedural points-to information is located in 3379 `tree-ssa-structalias.c' and described by `pass_ipa_pta'. 3380 3381 * Profiling 3382 3383 This pass rewrites the function in order to collect runtime block 3384 and value profiling data. Such data may be fed back into the 3385 compiler on a subsequent run so as to allow optimization based on 3386 expected execution frequencies. The pass is located in 3387 `predict.c' and is described by `pass_profile'. 3388 3389 * Lower complex arithmetic 3390 3391 This pass rewrites complex arithmetic operations into their 3392 component scalar arithmetic operations. The pass is located in 3393 `tree-complex.c' and is described by `pass_lower_complex'. 3394 3395 * Scalar replacement of aggregates 3396 3397 This pass rewrites suitable non-aliased local aggregate variables 3398 into a set of scalar variables. The resulting scalar variables are 3399 rewritten into SSA form, which allows subsequent optimization 3400 passes to do a significantly better job with them. The pass is 3401 located in `tree-sra.c' and is described by `pass_sra'. 3402 3403 * Dead store elimination 3404 3405 This pass eliminates stores to memory that are subsequently 3406 overwritten by another store, without any intervening loads. The 3407 pass is located in `tree-ssa-dse.c' and is described by `pass_dse'. 3408 3409 * Tail recursion elimination 3410 3411 This pass transforms tail recursion into a loop. It is located in 3412 `tree-tailcall.c' and is described by `pass_tail_recursion'. 3413 3414 * Forward store motion 3415 3416 This pass sinks stores and assignments down the flowgraph closer 3417 to it's use point. The pass is located in `tree-ssa-sink.c' and is 3418 described by `pass_sink_code'. 3419 3420 * Partial redundancy elimination 3421 3422 This pass eliminates partially redundant computations, as well as 3423 performing load motion. The pass is located in `tree-ssa-pre.c' 3424 and is described by `pass_pre'. 3425 3426 Just before partial redundancy elimination, if 3427 `-funsafe-math-optimizations' is on, GCC tries to convert 3428 divisions to multiplications by the reciprocal. The pass is 3429 located in `tree-ssa-math-opts.c' and is described by 3430 `pass_cse_reciprocal'. 3431 3432 * Full redundancy elimination 3433 3434 This is a simpler form of PRE that only eliminate redundancies that 3435 occur an all paths. It is located in `tree-ssa-pre.c' and 3436 described by `pass_fre'. 3437 3438 * Loop optimization 3439 3440 The main driver of the pass is placed in `tree-ssa-loop.c' and 3441 described by `pass_loop'. 3442 3443 The optimizations performed by this pass are: 3444 3445 Loop invariant motion. This pass moves only invariants that would 3446 be hard to handle on rtl level (function calls, operations that 3447 expand to nontrivial sequences of insns). With `-funswitch-loops' 3448 it also moves operands of conditions that are invariant out of the 3449 loop, so that we can use just trivial invariantness analysis in 3450 loop unswitching. The pass also includes store motion. The pass 3451 is implemented in `tree-ssa-loop-im.c'. 3452 3453 Canonical induction variable creation. This pass creates a simple 3454 counter for number of iterations of the loop and replaces the exit 3455 condition of the loop using it, in case when a complicated 3456 analysis is necessary to determine the number of iterations. 3457 Later optimizations then may determine the number easily. The 3458 pass is implemented in `tree-ssa-loop-ivcanon.c'. 3459 3460 Induction variable optimizations. This pass performs standard 3461 induction variable optimizations, including strength reduction, 3462 induction variable merging and induction variable elimination. 3463 The pass is implemented in `tree-ssa-loop-ivopts.c'. 3464 3465 Loop unswitching. This pass moves the conditional jumps that are 3466 invariant out of the loops. To achieve this, a duplicate of the 3467 loop is created for each possible outcome of conditional jump(s). 3468 The pass is implemented in `tree-ssa-loop-unswitch.c'. This pass 3469 should eventually replace the rtl-level loop unswitching in 3470 `loop-unswitch.c', but currently the rtl-level pass is not 3471 completely redundant yet due to deficiencies in tree level alias 3472 analysis. 3473 3474 The optimizations also use various utility functions contained in 3475 `tree-ssa-loop-manip.c', `cfgloop.c', `cfgloopanal.c' and 3476 `cfgloopmanip.c'. 3477 3478 Vectorization. This pass transforms loops to operate on vector 3479 types instead of scalar types. Data parallelism across loop 3480 iterations is exploited to group data elements from consecutive 3481 iterations into a vector and operate on them in parallel. 3482 Depending on available target support the loop is conceptually 3483 unrolled by a factor `VF' (vectorization factor), which is the 3484 number of elements operated upon in parallel in each iteration, 3485 and the `VF' copies of each scalar operation are fused to form a 3486 vector operation. Additional loop transformations such as peeling 3487 and versioning may take place to align the number of iterations, 3488 and to align the memory accesses in the loop. The pass is 3489 implemented in `tree-vectorizer.c' (the main driver and general 3490 utilities), `tree-vect-analyze.c' and `tree-vect-transform.c'. 3491 Analysis of data references is in `tree-data-ref.c'. 3492 3493 * Tree level if-conversion for vectorizer 3494 3495 This pass applies if-conversion to simple loops to help vectorizer. 3496 We identify if convertible loops, if-convert statements and merge 3497 basic blocks in one big block. The idea is to present loop in such 3498 form so that vectorizer can have one to one mapping between 3499 statements and available vector operations. This patch 3500 re-introduces COND_EXPR at GIMPLE level. This pass is located in 3501 `tree-if-conv.c' and is described by `pass_if_conversion'. 3502 3503 * Conditional constant propagation 3504 3505 This pass relaxes a lattice of values in order to identify those 3506 that must be constant even in the presence of conditional branches. 3507 The pass is located in `tree-ssa-ccp.c' and is described by 3508 `pass_ccp'. 3509 3510 A related pass that works on memory loads and stores, and not just 3511 register values, is located in `tree-ssa-ccp.c' and described by 3512 `pass_store_ccp'. 3513 3514 * Conditional copy propagation 3515 3516 This is similar to constant propagation but the lattice of values 3517 is the "copy-of" relation. It eliminates redundant copies from the 3518 code. The pass is located in `tree-ssa-copy.c' and described by 3519 `pass_copy_prop'. 3520 3521 A related pass that works on memory copies, and not just register 3522 copies, is located in `tree-ssa-copy.c' and described by 3523 `pass_store_copy_prop'. 3524 3525 * Value range propagation 3526 3527 This transformation is similar to constant propagation but instead 3528 of propagating single constant values, it propagates known value 3529 ranges. The implementation is based on Patterson's range 3530 propagation algorithm (Accurate Static Branch Prediction by Value 3531 Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to 3532 Patterson's algorithm, this implementation does not propagate 3533 branch probabilities nor it uses more than a single range per SSA 3534 name. This means that the current implementation cannot be used 3535 for branch prediction (though adapting it would not be difficult). 3536 The pass is located in `tree-vrp.c' and is described by 3537 `pass_vrp'. 3538 3539 * Folding built-in functions 3540 3541 This pass simplifies built-in functions, as applicable, with 3542 constant arguments or with inferrable string lengths. It is 3543 located in `tree-ssa-ccp.c' and is described by 3544 `pass_fold_builtins'. 3545 3546 * Split critical edges 3547 3548 This pass identifies critical edges and inserts empty basic blocks 3549 such that the edge is no longer critical. The pass is located in 3550 `tree-cfg.c' and is described by `pass_split_crit_edges'. 3551 3552 * Control dependence dead code elimination 3553 3554 This pass is a stronger form of dead code elimination that can 3555 eliminate unnecessary control flow statements. It is located in 3556 `tree-ssa-dce.c' and is described by `pass_cd_dce'. 3557 3558 * Tail call elimination 3559 3560 This pass identifies function calls that may be rewritten into 3561 jumps. No code transformation is actually applied here, but the 3562 data and control flow problem is solved. The code transformation 3563 requires target support, and so is delayed until RTL. In the 3564 meantime `CALL_EXPR_TAILCALL' is set indicating the possibility. 3565 The pass is located in `tree-tailcall.c' and is described by 3566 `pass_tail_calls'. The RTL transformation is handled by 3567 `fixup_tail_calls' in `calls.c'. 3568 3569 * Warn for function return without value 3570 3571 For non-void functions, this pass locates return statements that do 3572 not specify a value and issues a warning. Such a statement may 3573 have been injected by falling off the end of the function. This 3574 pass is run last so that we have as much time as possible to prove 3575 that the statement is not reachable. It is located in 3576 `tree-cfg.c' and is described by `pass_warn_function_return'. 3577 3578 * Mudflap statement annotation 3579 3580 If mudflap is enabled, we rewrite some memory accesses with code to 3581 validate that the memory access is correct. In particular, 3582 expressions involving pointer dereferences (`INDIRECT_REF', 3583 `ARRAY_REF', etc.) are replaced by code that checks the selected 3584 address range against the mudflap runtime's database of valid 3585 regions. This check includes an inline lookup into a 3586 direct-mapped cache, based on shift/mask operations of the pointer 3587 value, with a fallback function call into the runtime. The pass 3588 is located in `tree-mudflap.c' and is described by 3589 `pass_mudflap_2'. 3590 3591 * Leave static single assignment form 3592 3593 This pass rewrites the function such that it is in normal form. At 3594 the same time, we eliminate as many single-use temporaries as 3595 possible, so the intermediate language is no longer GIMPLE, but 3596 GENERIC. The pass is located in `tree-outof-ssa.c' and is 3597 described by `pass_del_ssa'. 3598 3599 * Merge PHI nodes that feed into one another 3600 3601 This is part of the CFG cleanup passes. It attempts to join PHI 3602 nodes from a forwarder CFG block into another block with PHI 3603 nodes. The pass is located in `tree-cfgcleanup.c' and is 3604 described by `pass_merge_phi'. 3605 3606 * Return value optimization 3607 3608 If a function always returns the same local variable, and that 3609 local variable is an aggregate type, then the variable is replaced 3610 with the return value for the function (i.e., the function's 3611 DECL_RESULT). This is equivalent to the C++ named return value 3612 optimization applied to GIMPLE. The pass is located in 3613 `tree-nrv.c' and is described by `pass_nrv'. 3614 3615 * Return slot optimization 3616 3617 If a function returns a memory object and is called as `var = 3618 foo()', this pass tries to change the call so that the address of 3619 `var' is sent to the caller to avoid an extra memory copy. This 3620 pass is located in `tree-nrv.c' and is described by 3621 `pass_return_slot'. 3622 3623 * Optimize calls to `__builtin_object_size' 3624 3625 This is a propagation pass similar to CCP that tries to remove 3626 calls to `__builtin_object_size' when the size of the object can be 3627 computed at compile-time. This pass is located in 3628 `tree-object-size.c' and is described by `pass_object_sizes'. 3629 3630 * Loop invariant motion 3631 3632 This pass removes expensive loop-invariant computations out of 3633 loops. The pass is located in `tree-ssa-loop.c' and described by 3634 `pass_lim'. 3635 3636 * Loop nest optimizations 3637 3638 This is a family of loop transformations that works on loop nests. 3639 It includes loop interchange, scaling, skewing and reversal and 3640 they are all geared to the optimization of data locality in array 3641 traversals and the removal of dependencies that hamper 3642 optimizations such as loop parallelization and vectorization. The 3643 pass is located in `tree-loop-linear.c' and described by 3644 `pass_linear_transform'. 3645 3646 * Removal of empty loops 3647 3648 This pass removes loops with no code in them. The pass is located 3649 in `tree-ssa-loop-ivcanon.c' and described by `pass_empty_loop'. 3650 3651 * Unrolling of small loops 3652 3653 This pass completely unrolls loops with few iterations. The pass 3654 is located in `tree-ssa-loop-ivcanon.c' and described by 3655 `pass_complete_unroll'. 3656 3657 * Array prefetching 3658 3659 This pass issues prefetch instructions for array references inside 3660 loops. The pass is located in `tree-ssa-loop-prefetch.c' and 3661 described by `pass_loop_prefetch'. 3662 3663 * Reassociation 3664 3665 This pass rewrites arithmetic expressions to enable optimizations 3666 that operate on them, like redundancy elimination and 3667 vectorization. The pass is located in `tree-ssa-reassoc.c' and 3668 described by `pass_reassoc'. 3669 3670 * Optimization of `stdarg' functions 3671 3672 This pass tries to avoid the saving of register arguments into the 3673 stack on entry to `stdarg' functions. If the function doesn't use 3674 any `va_start' macros, no registers need to be saved. If 3675 `va_start' macros are used, the `va_list' variables don't escape 3676 the function, it is only necessary to save registers that will be 3677 used in `va_arg' macros. For instance, if `va_arg' is only used 3678 with integral types in the function, floating point registers 3679 don't need to be saved. This pass is located in `tree-stdarg.c' 3680 and described by `pass_stdarg'. 3681 3682 3683 3684 File: gccint.info, Node: RTL passes, Prev: Tree-SSA passes, Up: Passes 3685 3686 8.5 RTL passes 3687 ============== 3688 3689 The following briefly describes the rtl generation and optimization 3690 passes that are run after tree optimization. 3691 3692 * RTL generation 3693 3694 The source files for RTL generation include `stmt.c', `calls.c', 3695 `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and 3696 `emit-rtl.c'. Also, the file `insn-emit.c', generated from the 3697 machine description by the program `genemit', is used in this 3698 pass. The header file `expr.h' is used for communication within 3699 this pass. 3700 3701 The header files `insn-flags.h' and `insn-codes.h', generated from 3702 the machine description by the programs `genflags' and `gencodes', 3703 tell this pass which standard names are available for use and 3704 which patterns correspond to them. 3705 3706 * Generate exception handling landing pads 3707 3708 This pass generates the glue that handles communication between the 3709 exception handling library routines and the exception handlers 3710 within the function. Entry points in the function that are 3711 invoked by the exception handling library are called "landing 3712 pads". The code for this pass is located within `except.c'. 3713 3714 * Cleanup control flow graph 3715 3716 This pass removes unreachable code, simplifies jumps to next, 3717 jumps to jump, jumps across jumps, etc. The pass is run multiple 3718 times. For historical reasons, it is occasionally referred to as 3719 the "jump optimization pass". The bulk of the code for this pass 3720 is in `cfgcleanup.c', and there are support routines in `cfgrtl.c' 3721 and `jump.c'. 3722 3723 * Common subexpression elimination 3724 3725 This pass removes redundant computation within basic blocks, and 3726 optimizes addressing modes based on cost. The pass is run twice. 3727 The source is located in `cse.c'. 3728 3729 * Global common subexpression elimination. 3730 3731 This pass performs two different types of GCSE depending on 3732 whether you are optimizing for size or not (LCM based GCSE tends 3733 to increase code size for a gain in speed, while Morel-Renvoise 3734 based GCSE does not). When optimizing for size, GCSE is done 3735 using Morel-Renvoise Partial Redundancy Elimination, with the 3736 exception that it does not try to move invariants out of 3737 loops--that is left to the loop optimization pass. If MR PRE 3738 GCSE is done, code hoisting (aka unification) is also done, as 3739 well as load motion. If you are optimizing for speed, LCM (lazy 3740 code motion) based GCSE is done. LCM is based on the work of 3741 Knoop, Ruthing, and Steffen. LCM based GCSE also does loop 3742 invariant code motion. We also perform load and store motion when 3743 optimizing for speed. Regardless of which type of GCSE is used, 3744 the GCSE pass also performs global constant and copy propagation. 3745 The source file for this pass is `gcse.c', and the LCM routines 3746 are in `lcm.c'. 3747 3748 * Loop optimization 3749 3750 This pass performs several loop related optimizations. The source 3751 files `cfgloopanal.c' and `cfgloopmanip.c' contain generic loop 3752 analysis and manipulation code. Initialization and finalization 3753 of loop structures is handled by `loop-init.c'. A loop invariant 3754 motion pass is implemented in `loop-invariant.c'. Basic block 3755 level optimizations--unrolling, peeling and unswitching loops-- 3756 are implemented in `loop-unswitch.c' and `loop-unroll.c'. 3757 Replacing of the exit condition of loops by special 3758 machine-dependent instructions is handled by `loop-doloop.c'. 3759 3760 * Jump bypassing 3761 3762 This pass is an aggressive form of GCSE that transforms the control 3763 flow graph of a function by propagating constants into conditional 3764 branch instructions. The source file for this pass is `gcse.c'. 3765 3766 * If conversion 3767 3768 This pass attempts to replace conditional branches and surrounding 3769 assignments with arithmetic, boolean value producing comparison 3770 instructions, and conditional move instructions. In the very last 3771 invocation after reload, it will generate predicated instructions 3772 when supported by the target. The pass is located in `ifcvt.c'. 3773 3774 * Web construction 3775 3776 This pass splits independent uses of each pseudo-register. This 3777 can improve effect of the other transformation, such as CSE or 3778 register allocation. Its source files are `web.c'. 3779 3780 * Life analysis 3781 3782 This pass computes which pseudo-registers are live at each point in 3783 the program, and makes the first instruction that uses a value 3784 point at the instruction that computed the value. It then deletes 3785 computations whose results are never used, and combines memory 3786 references with add or subtract instructions to make autoincrement 3787 or autodecrement addressing. The pass is located in `flow.c'. 3788 3789 * Instruction combination 3790 3791 This pass attempts to combine groups of two or three instructions 3792 that are related by data flow into single instructions. It 3793 combines the RTL expressions for the instructions by substitution, 3794 simplifies the result using algebra, and then attempts to match 3795 the result against the machine description. The pass is located 3796 in `combine.c'. 3797 3798 * Register movement 3799 3800 This pass looks for cases where matching constraints would force an 3801 instruction to need a reload, and this reload would be a 3802 register-to-register move. It then attempts to change the 3803 registers used by the instruction to avoid the move instruction. 3804 The pass is located in `regmove.c'. 3805 3806 * Optimize mode switching 3807 3808 This pass looks for instructions that require the processor to be 3809 in a specific "mode" and minimizes the number of mode changes 3810 required to satisfy all users. What these modes are, and what 3811 they apply to are completely target-specific. The source is 3812 located in `mode-switching.c'. 3813 3814 * Modulo scheduling 3815 3816 This pass looks at innermost loops and reorders their instructions 3817 by overlapping different iterations. Modulo scheduling is 3818 performed immediately before instruction scheduling. The pass is 3819 located in (`modulo-sched.c'). 3820 3821 * Instruction scheduling 3822 3823 This pass looks for instructions whose output will not be 3824 available by the time that it is used in subsequent instructions. 3825 Memory loads and floating point instructions often have this 3826 behavior on RISC machines. It re-orders instructions within a 3827 basic block to try to separate the definition and use of items 3828 that otherwise would cause pipeline stalls. This pass is 3829 performed twice, before and after register allocation. The pass 3830 is located in `haifa-sched.c', `sched-deps.c', `sched-ebb.c', 3831 `sched-rgn.c' and `sched-vis.c'. 3832 3833 * Register allocation 3834 3835 These passes make sure that all occurrences of pseudo registers are 3836 eliminated, either by allocating them to a hard register, replacing 3837 them by an equivalent expression (e.g. a constant) or by placing 3838 them on the stack. This is done in several subpasses: 3839 3840 * Register class preferencing. The RTL code is scanned to find 3841 out which register class is best for each pseudo register. 3842 The source file is `regclass.c'. 3843 3844 * Local register allocation. This pass allocates hard 3845 registers to pseudo registers that are used only within one 3846 basic block. Because the basic block is linear, it can use 3847 fast and powerful techniques to do a decent job. The source 3848 is located in `local-alloc.c'. 3849 3850 * Global register allocation. This pass allocates hard 3851 registers for the remaining pseudo registers (those whose 3852 life spans are not contained in one basic block). The pass 3853 is located in `global.c'. 3854 3855 * Reloading. This pass renumbers pseudo registers with the 3856 hardware registers numbers they were allocated. Pseudo 3857 registers that did not get hard registers are replaced with 3858 stack slots. Then it finds instructions that are invalid 3859 because a value has failed to end up in a register, or has 3860 ended up in a register of the wrong kind. It fixes up these 3861 instructions by reloading the problematical values 3862 temporarily into registers. Additional instructions are 3863 generated to do the copying. 3864 3865 The reload pass also optionally eliminates the frame pointer 3866 and inserts instructions to save and restore call-clobbered 3867 registers around calls. 3868 3869 Source files are `reload.c' and `reload1.c', plus the header 3870 `reload.h' used for communication between them. 3871 3872 * Basic block reordering 3873 3874 This pass implements profile guided code positioning. If profile 3875 information is not available, various types of static analysis are 3876 performed to make the predictions normally coming from the profile 3877 feedback (IE execution frequency, branch probability, etc). It is 3878 implemented in the file `bb-reorder.c', and the various prediction 3879 routines are in `predict.c'. 3880 3881 * Variable tracking 3882 3883 This pass computes where the variables are stored at each position 3884 in code and generates notes describing the variable locations to 3885 RTL code. The location lists are then generated according to these 3886 notes to debug information if the debugging information format 3887 supports location lists. 3888 3889 * Delayed branch scheduling 3890 3891 This optional pass attempts to find instructions that can go into 3892 the delay slots of other instructions, usually jumps and calls. 3893 The source file name is `reorg.c'. 3894 3895 * Branch shortening 3896 3897 On many RISC machines, branch instructions have a limited range. 3898 Thus, longer sequences of instructions must be used for long 3899 branches. In this pass, the compiler figures out what how far 3900 each instruction will be from each other instruction, and 3901 therefore whether the usual instructions, or the longer sequences, 3902 must be used for each branch. 3903 3904 * Register-to-stack conversion 3905 3906 Conversion from usage of some hard registers to usage of a register 3907 stack may be done at this point. Currently, this is supported only 3908 for the floating-point registers of the Intel 80387 coprocessor. 3909 The source file name is `reg-stack.c'. 3910 3911 * Final 3912 3913 This pass outputs the assembler code for the function. The source 3914 files are `final.c' plus `insn-output.c'; the latter is generated 3915 automatically from the machine description by the tool `genoutput'. 3916 The header file `conditions.h' is used for communication between 3917 these files. If mudflap is enabled, the queue of deferred 3918 declarations and any addressed constants (e.g., string literals) 3919 is processed by `mudflap_finish_file' into a synthetic constructor 3920 function containing calls into the mudflap runtime. 3921 3922 * Debugging information output 3923 3924 This is run after final because it must output the stack slot 3925 offsets for pseudo registers that did not get hard registers. 3926 Source files are `dbxout.c' for DBX symbol table format, 3927 `sdbout.c' for SDB symbol table format, `dwarfout.c' for DWARF 3928 symbol table format, files `dwarf2out.c' and `dwarf2asm.c' for 3929 DWARF2 symbol table format, and `vmsdbgout.c' for VMS debug symbol 3930 table format. 3931 3932 3933 3934 File: gccint.info, Node: Trees, Next: RTL, Prev: Passes, Up: Top 3935 3936 9 Trees: The intermediate representation used by the C and C++ front ends 3937 ************************************************************************* 3938 3939 This chapter documents the internal representation used by GCC to 3940 represent C and C++ source programs. When presented with a C or C++ 3941 source program, GCC parses the program, performs semantic analysis 3942 (including the generation of error messages), and then produces the 3943 internal representation described here. This representation contains a 3944 complete representation for the entire translation unit provided as 3945 input to the front end. This representation is then typically processed 3946 by a code-generator in order to produce machine code, but could also be 3947 used in the creation of source browsers, intelligent editors, automatic 3948 documentation generators, interpreters, and any other programs needing 3949 the ability to process C or C++ code. 3950 3951 This chapter explains the internal representation. In particular, it 3952 documents the internal representation for C and C++ source constructs, 3953 and the macros, functions, and variables that can be used to access 3954 these constructs. The C++ representation is largely a superset of the 3955 representation used in the C front end. There is only one construct 3956 used in C that does not appear in the C++ front end and that is the GNU 3957 "nested function" extension. Many of the macros documented here do not 3958 apply in C because the corresponding language constructs do not appear 3959 in C. 3960 3961 If you are developing a "back end", be it is a code-generator or some 3962 other tool, that uses this representation, you may occasionally find 3963 that you need to ask questions not easily answered by the functions and 3964 macros available here. If that situation occurs, it is quite likely 3965 that GCC already supports the functionality you desire, but that the 3966 interface is simply not documented here. In that case, you should ask 3967 the GCC maintainers (via mail to <gcc (a] gcc.gnu.org>) about documenting 3968 the functionality you require. Similarly, if you find yourself writing 3969 functions that do not deal directly with your back end, but instead 3970 might be useful to other people using the GCC front end, you should 3971 submit your patches for inclusion in GCC. 3972 3973 * Menu: 3974 3975 * Deficiencies:: Topics net yet covered in this document. 3976 * Tree overview:: All about `tree's. 3977 * Types:: Fundamental and aggregate types. 3978 * Scopes:: Namespaces and classes. 3979 * Functions:: Overloading, function bodies, and linkage. 3980 * Declarations:: Type declarations and variables. 3981 * Attributes:: Declaration and type attributes. 3982 * Expression trees:: From `typeid' to `throw'. 3983 3984 3985 File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: Trees 3986 3987 9.1 Deficiencies 3988 ================ 3989 3990 There are many places in which this document is incomplet and incorrekt. 3991 It is, as of yet, only _preliminary_ documentation. 3992 3993 3994 File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: Trees 3995 3996 9.2 Overview 3997 ============ 3998 3999 The central data structure used by the internal representation is the 4000 `tree'. These nodes, while all of the C type `tree', are of many 4001 varieties. A `tree' is a pointer type, but the object to which it 4002 points may be of a variety of types. From this point forward, we will 4003 refer to trees in ordinary type, rather than in `this font', except 4004 when talking about the actual C type `tree'. 4005 4006 You can tell what kind of node a particular tree is by using the 4007 `TREE_CODE' macro. Many, many macros take trees as input and return 4008 trees as output. However, most macros require a certain kind of tree 4009 node as input. In other words, there is a type-system for trees, but 4010 it is not reflected in the C type-system. 4011 4012 For safety, it is useful to configure GCC with `--enable-checking'. 4013 Although this results in a significant performance penalty (since all 4014 tree types are checked at run-time), and is therefore inappropriate in a 4015 release version, it is extremely helpful during the development process. 4016 4017 Many macros behave as predicates. Many, although not all, of these 4018 predicates end in `_P'. Do not rely on the result type of these macros 4019 being of any particular type. You may, however, rely on the fact that 4020 the type can be compared to `0', so that statements like 4021 if (TEST_P (t) && !TEST_P (y)) 4022 x = 1; 4023 and 4024 int i = (TEST_P (t) != 0); 4025 are legal. Macros that return `int' values now may be changed to 4026 return `tree' values, or other pointers in the future. Even those that 4027 continue to return `int' may return multiple nonzero codes where 4028 previously they returned only zero and one. Therefore, you should not 4029 write code like 4030 if (TEST_P (t) == 1) 4031 as this code is not guaranteed to work correctly in the future. 4032 4033 You should not take the address of values returned by the macros or 4034 functions described here. In particular, no guarantee is given that the 4035 values are lvalues. 4036 4037 In general, the names of macros are all in uppercase, while the names 4038 of functions are entirely in lowercase. There are rare exceptions to 4039 this rule. You should assume that any macro or function whose name is 4040 made up entirely of uppercase letters may evaluate its arguments more 4041 than once. You may assume that a macro or function whose name is made 4042 up entirely of lowercase letters will evaluate its arguments only once. 4043 4044 The `error_mark_node' is a special tree. Its tree code is 4045 `ERROR_MARK', but since there is only ever one node with that code, the 4046 usual practice is to compare the tree against `error_mark_node'. (This 4047 test is just a test for pointer equality.) If an error has occurred 4048 during front-end processing the flag `errorcount' will be set. If the 4049 front end has encountered code it cannot handle, it will issue a 4050 message to the user and set `sorrycount'. When these flags are set, 4051 any macro or function which normally returns a tree of a particular 4052 kind may instead return the `error_mark_node'. Thus, if you intend to 4053 do any processing of erroneous code, you must be prepared to deal with 4054 the `error_mark_node'. 4055 4056 Occasionally, a particular tree slot (like an operand to an expression, 4057 or a particular field in a declaration) will be referred to as 4058 "reserved for the back end". These slots are used to store RTL when 4059 the tree is converted to RTL for use by the GCC back end. However, if 4060 that process is not taking place (e.g., if the front end is being hooked 4061 up to an intelligent editor), then those slots may be used by the back 4062 end presently in use. 4063 4064 If you encounter situations that do not match this documentation, such 4065 as tree nodes of types not mentioned here, or macros documented to 4066 return entities of a particular kind that instead return entities of 4067 some different kind, you have found a bug, either in the front end or in 4068 the documentation. Please report these bugs as you would any other bug. 4069 4070 * Menu: 4071 4072 * Macros and Functions::Macros and functions that can be used with all trees. 4073 * Identifiers:: The names of things. 4074 * Containers:: Lists and vectors. 4075 4076 4077 File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview 4078 4079 9.2.1 Trees 4080 ----------- 4081 4082 This section is not here yet. 4083 4084 4085 File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview 4086 4087 9.2.2 Identifiers 4088 ----------------- 4089 4090 An `IDENTIFIER_NODE' represents a slightly more general concept that 4091 the standard C or C++ concept of identifier. In particular, an 4092 `IDENTIFIER_NODE' may contain a `$', or other extraordinary characters. 4093 4094 There are never two distinct `IDENTIFIER_NODE's representing the same 4095 identifier. Therefore, you may use pointer equality to compare 4096 `IDENTIFIER_NODE's, rather than using a routine like `strcmp'. 4097 4098 You can use the following macros to access identifiers: 4099 `IDENTIFIER_POINTER' 4100 The string represented by the identifier, represented as a 4101 `char*'. This string is always `NUL'-terminated, and contains no 4102 embedded `NUL' characters. 4103 4104 `IDENTIFIER_LENGTH' 4105 The length of the string returned by `IDENTIFIER_POINTER', not 4106 including the trailing `NUL'. This value of `IDENTIFIER_LENGTH 4107 (x)' is always the same as `strlen (IDENTIFIER_POINTER (x))'. 4108 4109 `IDENTIFIER_OPNAME_P' 4110 This predicate holds if the identifier represents the name of an 4111 overloaded operator. In this case, you should not depend on the 4112 contents of either the `IDENTIFIER_POINTER' or the 4113 `IDENTIFIER_LENGTH'. 4114 4115 `IDENTIFIER_TYPENAME_P' 4116 This predicate holds if the identifier represents the name of a 4117 user-defined conversion operator. In this case, the `TREE_TYPE' of 4118 the `IDENTIFIER_NODE' holds the type to which the conversion 4119 operator converts. 4120 4121 4122 4123 File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview 4124 4125 9.2.3 Containers 4126 ---------------- 4127 4128 Two common container data structures can be represented directly with 4129 tree nodes. A `TREE_LIST' is a singly linked list containing two trees 4130 per node. These are the `TREE_PURPOSE' and `TREE_VALUE' of each node. 4131 (Often, the `TREE_PURPOSE' contains some kind of tag, or additional 4132 information, while the `TREE_VALUE' contains the majority of the 4133 payload. In other cases, the `TREE_PURPOSE' is simply `NULL_TREE', 4134 while in still others both the `TREE_PURPOSE' and `TREE_VALUE' are of 4135 equal stature.) Given one `TREE_LIST' node, the next node is found by 4136 following the `TREE_CHAIN'. If the `TREE_CHAIN' is `NULL_TREE', then 4137 you have reached the end of the list. 4138 4139 A `TREE_VEC' is a simple vector. The `TREE_VEC_LENGTH' is an integer 4140 (not a tree) giving the number of nodes in the vector. The nodes 4141 themselves are accessed using the `TREE_VEC_ELT' macro, which takes two 4142 arguments. The first is the `TREE_VEC' in question; the second is an 4143 integer indicating which element in the vector is desired. The 4144 elements are indexed from zero. 4145 4146 4147 File: gccint.info, Node: Types, Next: Scopes, Prev: Tree overview, Up: Trees 4148 4149 9.3 Types 4150 ========= 4151 4152 All types have corresponding tree nodes. However, you should not assume 4153 that there is exactly one tree node corresponding to each type. There 4154 are often several nodes each of which correspond to the same type. 4155 4156 For the most part, different kinds of types have different tree codes. 4157 (For example, pointer types use a `POINTER_TYPE' code while arrays use 4158 an `ARRAY_TYPE' code.) However, pointers to member functions use the 4159 `RECORD_TYPE' code. Therefore, when writing a `switch' statement that 4160 depends on the code associated with a particular type, you should take 4161 care to handle pointers to member functions under the `RECORD_TYPE' 4162 case label. 4163 4164 In C++, an array type is not qualified; rather the type of the array 4165 elements is qualified. This situation is reflected in the intermediate 4166 representation. The macros described here will always examine the 4167 qualification of the underlying element type when applied to an array 4168 type. (If the element type is itself an array, then the recursion 4169 continues until a non-array type is found, and the qualification of this 4170 type is examined.) So, for example, `CP_TYPE_CONST_P' will hold of the 4171 type `const int ()[7]', denoting an array of seven `int's. 4172 4173 The following functions and macros deal with cv-qualification of types: 4174 `CP_TYPE_QUALS' 4175 This macro returns the set of type qualifiers applied to this type. 4176 This value is `TYPE_UNQUALIFIED' if no qualifiers have been 4177 applied. The `TYPE_QUAL_CONST' bit is set if the type is 4178 `const'-qualified. The `TYPE_QUAL_VOLATILE' bit is set if the 4179 type is `volatile'-qualified. The `TYPE_QUAL_RESTRICT' bit is set 4180 if the type is `restrict'-qualified. 4181 4182 `CP_TYPE_CONST_P' 4183 This macro holds if the type is `const'-qualified. 4184 4185 `CP_TYPE_VOLATILE_P' 4186 This macro holds if the type is `volatile'-qualified. 4187 4188 `CP_TYPE_RESTRICT_P' 4189 This macro holds if the type is `restrict'-qualified. 4190 4191 `CP_TYPE_CONST_NON_VOLATILE_P' 4192 This predicate holds for a type that is `const'-qualified, but 4193 _not_ `volatile'-qualified; other cv-qualifiers are ignored as 4194 well: only the `const'-ness is tested. 4195 4196 `TYPE_MAIN_VARIANT' 4197 This macro returns the unqualified version of a type. It may be 4198 applied to an unqualified type, but it is not always the identity 4199 function in that case. 4200 4201 A few other macros and functions are usable with all types: 4202 `TYPE_SIZE' 4203 The number of bits required to represent the type, represented as 4204 an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be 4205 `NULL_TREE'. 4206 4207 `TYPE_ALIGN' 4208 The alignment of the type, in bits, represented as an `int'. 4209 4210 `TYPE_NAME' 4211 This macro returns a declaration (in the form of a `TYPE_DECL') for 4212 the type. (Note this macro does _not_ return a `IDENTIFIER_NODE', 4213 as you might expect, given its name!) You can look at the 4214 `DECL_NAME' of the `TYPE_DECL' to obtain the actual name of the 4215 type. The `TYPE_NAME' will be `NULL_TREE' for a type that is not 4216 a built-in type, the result of a typedef, or a named class type. 4217 4218 `CP_INTEGRAL_TYPE' 4219 This predicate holds if the type is an integral type. Notice that 4220 in C++, enumerations are _not_ integral types. 4221 4222 `ARITHMETIC_TYPE_P' 4223 This predicate holds if the type is an integral type (in the C++ 4224 sense) or a floating point type. 4225 4226 `CLASS_TYPE_P' 4227 This predicate holds for a class-type. 4228 4229 `TYPE_BUILT_IN' 4230 This predicate holds for a built-in type. 4231 4232 `TYPE_PTRMEM_P' 4233 This predicate holds if the type is a pointer to data member. 4234 4235 `TYPE_PTR_P' 4236 This predicate holds if the type is a pointer type, and the 4237 pointee is not a data member. 4238 4239 `TYPE_PTRFN_P' 4240 This predicate holds for a pointer to function type. 4241 4242 `TYPE_PTROB_P' 4243 This predicate holds for a pointer to object type. Note however 4244 that it does not hold for the generic pointer to object type `void 4245 *'. You may use `TYPE_PTROBV_P' to test for a pointer to object 4246 type as well as `void *'. 4247 4248 `same_type_p' 4249 This predicate takes two types as input, and holds if they are the 4250 same type. For example, if one type is a `typedef' for the other, 4251 or both are `typedef's for the same type. This predicate also 4252 holds if the two trees given as input are simply copies of one 4253 another; i.e., there is no difference between them at the source 4254 level, but, for whatever reason, a duplicate has been made in the 4255 representation. You should never use `==' (pointer equality) to 4256 compare types; always use `same_type_p' instead. 4257 4258 Detailed below are the various kinds of types, and the macros that can 4259 be used to access them. Although other kinds of types are used 4260 elsewhere in G++, the types described here are the only ones that you 4261 will encounter while examining the intermediate representation. 4262 4263 `VOID_TYPE' 4264 Used to represent the `void' type. 4265 4266 `INTEGER_TYPE' 4267 Used to represent the various integral types, including `char', 4268 `short', `int', `long', and `long long'. This code is not used 4269 for enumeration types, nor for the `bool' type. The 4270 `TYPE_PRECISION' is the number of bits used in the representation, 4271 represented as an `unsigned int'. (Note that in the general case 4272 this is not the same value as `TYPE_SIZE'; suppose that there were 4273 a 24-bit integer type, but that alignment requirements for the ABI 4274 required 32-bit alignment. Then, `TYPE_SIZE' would be an 4275 `INTEGER_CST' for 32, while `TYPE_PRECISION' would be 24.) The 4276 integer type is unsigned if `TYPE_UNSIGNED' holds; otherwise, it 4277 is signed. 4278 4279 The `TYPE_MIN_VALUE' is an `INTEGER_CST' for the smallest integer 4280 that may be represented by this type. Similarly, the 4281 `TYPE_MAX_VALUE' is an `INTEGER_CST' for the largest integer that 4282 may be represented by this type. 4283 4284 `REAL_TYPE' 4285 Used to represent the `float', `double', and `long double' types. 4286 The number of bits in the floating-point representation is given 4287 by `TYPE_PRECISION', as in the `INTEGER_TYPE' case. 4288 4289 `COMPLEX_TYPE' 4290 Used to represent GCC built-in `__complex__' data types. The 4291 `TREE_TYPE' is the type of the real and imaginary parts. 4292 4293 `ENUMERAL_TYPE' 4294 Used to represent an enumeration type. The `TYPE_PRECISION' gives 4295 (as an `int'), the number of bits used to represent the type. If 4296 there are no negative enumeration constants, `TYPE_UNSIGNED' will 4297 hold. The minimum and maximum enumeration constants may be 4298 obtained with `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE', respectively; 4299 each of these macros returns an `INTEGER_CST'. 4300 4301 The actual enumeration constants themselves may be obtained by 4302 looking at the `TYPE_VALUES'. This macro will return a 4303 `TREE_LIST', containing the constants. The `TREE_PURPOSE' of each 4304 node will be an `IDENTIFIER_NODE' giving the name of the constant; 4305 the `TREE_VALUE' will be an `INTEGER_CST' giving the value 4306 assigned to that constant. These constants will appear in the 4307 order in which they were declared. The `TREE_TYPE' of each of 4308 these constants will be the type of enumeration type itself. 4309 4310 `BOOLEAN_TYPE' 4311 Used to represent the `bool' type. 4312 4313 `POINTER_TYPE' 4314 Used to represent pointer types, and pointer to data member types. 4315 The `TREE_TYPE' gives the type to which this type points. If the 4316 type is a pointer to data member type, then `TYPE_PTRMEM_P' will 4317 hold. For a pointer to data member type of the form `T X::*', 4318 `TYPE_PTRMEM_CLASS_TYPE' will be the type `X', while 4319 `TYPE_PTRMEM_POINTED_TO_TYPE' will be the type `T'. 4320 4321 `REFERENCE_TYPE' 4322 Used to represent reference types. The `TREE_TYPE' gives the type 4323 to which this type refers. 4324 4325 `FUNCTION_TYPE' 4326 Used to represent the type of non-member functions and of static 4327 member functions. The `TREE_TYPE' gives the return type of the 4328 function. The `TYPE_ARG_TYPES' are a `TREE_LIST' of the argument 4329 types. The `TREE_VALUE' of each node in this list is the type of 4330 the corresponding argument; the `TREE_PURPOSE' is an expression 4331 for the default argument value, if any. If the last node in the 4332 list is `void_list_node' (a `TREE_LIST' node whose `TREE_VALUE' is 4333 the `void_type_node'), then functions of this type do not take 4334 variable arguments. Otherwise, they do take a variable number of 4335 arguments. 4336 4337 Note that in C (but not in C++) a function declared like `void f()' 4338 is an unprototyped function taking a variable number of arguments; 4339 the `TYPE_ARG_TYPES' of such a function will be `NULL'. 4340 4341 `METHOD_TYPE' 4342 Used to represent the type of a non-static member function. Like a 4343 `FUNCTION_TYPE', the return type is given by the `TREE_TYPE'. The 4344 type of `*this', i.e., the class of which functions of this type 4345 are a member, is given by the `TYPE_METHOD_BASETYPE'. The 4346 `TYPE_ARG_TYPES' is the parameter list, as for a `FUNCTION_TYPE', 4347 and includes the `this' argument. 4348 4349 `ARRAY_TYPE' 4350 Used to represent array types. The `TREE_TYPE' gives the type of 4351 the elements in the array. If the array-bound is present in the 4352 type, the `TYPE_DOMAIN' is an `INTEGER_TYPE' whose 4353 `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE' will be the lower and upper 4354 bounds of the array, respectively. The `TYPE_MIN_VALUE' will 4355 always be an `INTEGER_CST' for zero, while the `TYPE_MAX_VALUE' 4356 will be one less than the number of elements in the array, i.e., 4357 the highest value which may be used to index an element in the 4358 array. 4359 4360 `RECORD_TYPE' 4361 Used to represent `struct' and `class' types, as well as pointers 4362 to member functions and similar constructs in other languages. 4363 `TYPE_FIELDS' contains the items contained in this type, each of 4364 which can be a `FIELD_DECL', `VAR_DECL', `CONST_DECL', or 4365 `TYPE_DECL'. You may not make any assumptions about the ordering 4366 of the fields in the type or whether one or more of them overlap. 4367 If `TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member 4368 type. In that case, the `TYPE_PTRMEMFUNC_FN_TYPE' is a 4369 `POINTER_TYPE' pointing to a `METHOD_TYPE'. The `METHOD_TYPE' is 4370 the type of a function pointed to by the pointer-to-member 4371 function. If `TYPE_PTRMEMFUNC_P' does not hold, this type is a 4372 class type. For more information, see *note Classes::. 4373 4374 `UNION_TYPE' 4375 Used to represent `union' types. Similar to `RECORD_TYPE' except 4376 that all `FIELD_DECL' nodes in `TYPE_FIELD' start at bit position 4377 zero. 4378 4379 `QUAL_UNION_TYPE' 4380 Used to represent part of a variant record in Ada. Similar to 4381 `UNION_TYPE' except that each `FIELD_DECL' has a `DECL_QUALIFIER' 4382 field, which contains a boolean expression that indicates whether 4383 the field is present in the object. The type will only have one 4384 field, so each field's `DECL_QUALIFIER' is only evaluated if none 4385 of the expressions in the previous fields in `TYPE_FIELDS' are 4386 nonzero. Normally these expressions will reference a field in the 4387 outer object using a `PLACEHOLDER_EXPR'. 4388 4389 `UNKNOWN_TYPE' 4390 This node is used to represent a type the knowledge of which is 4391 insufficient for a sound processing. 4392 4393 `OFFSET_TYPE' 4394 This node is used to represent a pointer-to-data member. For a 4395 data member `X::m' the `TYPE_OFFSET_BASETYPE' is `X' and the 4396 `TREE_TYPE' is the type of `m'. 4397 4398 `TYPENAME_TYPE' 4399 Used to represent a construct of the form `typename T::A'. The 4400 `TYPE_CONTEXT' is `T'; the `TYPE_NAME' is an `IDENTIFIER_NODE' for 4401 `A'. If the type is specified via a template-id, then 4402 `TYPENAME_TYPE_FULLNAME' yields a `TEMPLATE_ID_EXPR'. The 4403 `TREE_TYPE' is non-`NULL' if the node is implicitly generated in 4404 support for the implicit typename extension; in which case the 4405 `TREE_TYPE' is a type node for the base-class. 4406 4407 `TYPEOF_TYPE' 4408 Used to represent the `__typeof__' extension. The `TYPE_FIELDS' 4409 is the expression the type of which is being represented. 4410 4411 There are variables whose values represent some of the basic types. 4412 These include: 4413 `void_type_node' 4414 A node for `void'. 4415 4416 `integer_type_node' 4417 A node for `int'. 4418 4419 `unsigned_type_node.' 4420 A node for `unsigned int'. 4421 4422 `char_type_node.' 4423 A node for `char'. 4424 It may sometimes be useful to compare one of these variables with a 4425 type in hand, using `same_type_p'. 4426 4427 4428 File: gccint.info, Node: Scopes, Next: Functions, Prev: Types, Up: Trees 4429 4430 9.4 Scopes 4431 ========== 4432 4433 The root of the entire intermediate representation is the variable 4434 `global_namespace'. This is the namespace specified with `::' in C++ 4435 source code. All other namespaces, types, variables, functions, and so 4436 forth can be found starting with this namespace. 4437 4438 Besides namespaces, the other high-level scoping construct in C++ is 4439 the class. (Throughout this manual the term "class" is used to mean the 4440 types referred to in the ANSI/ISO C++ Standard as classes; these include 4441 types defined with the `class', `struct', and `union' keywords.) 4442 4443 * Menu: 4444 4445 * Namespaces:: Member functions, types, etc. 4446 * Classes:: Members, bases, friends, etc. 4447 4448 4449 File: gccint.info, Node: Namespaces, Next: Classes, Up: Scopes 4450 4451 9.4.1 Namespaces 4452 ---------------- 4453 4454 A namespace is represented by a `NAMESPACE_DECL' node. 4455 4456 However, except for the fact that it is distinguished as the root of 4457 the representation, the global namespace is no different from any other 4458 namespace. Thus, in what follows, we describe namespaces generally, 4459 rather than the global namespace in particular. 4460 4461 The following macros and functions can be used on a `NAMESPACE_DECL': 4462 4463 `DECL_NAME' 4464 This macro is used to obtain the `IDENTIFIER_NODE' corresponding to 4465 the unqualified name of the name of the namespace (*note 4466 Identifiers::). The name of the global namespace is `::', even 4467 though in C++ the global namespace is unnamed. However, you 4468 should use comparison with `global_namespace', rather than 4469 `DECL_NAME' to determine whether or not a namespace is the global 4470 one. An unnamed namespace will have a `DECL_NAME' equal to 4471 `anonymous_namespace_name'. Within a single translation unit, all 4472 unnamed namespaces will have the same name. 4473 4474 `DECL_CONTEXT' 4475 This macro returns the enclosing namespace. The `DECL_CONTEXT' for 4476 the `global_namespace' is `NULL_TREE'. 4477 4478 `DECL_NAMESPACE_ALIAS' 4479 If this declaration is for a namespace alias, then 4480 `DECL_NAMESPACE_ALIAS' is the namespace for which this one is an 4481 alias. 4482 4483 Do not attempt to use `cp_namespace_decls' for a namespace which is 4484 an alias. Instead, follow `DECL_NAMESPACE_ALIAS' links until you 4485 reach an ordinary, non-alias, namespace, and call 4486 `cp_namespace_decls' there. 4487 4488 `DECL_NAMESPACE_STD_P' 4489 This predicate holds if the namespace is the special `::std' 4490 namespace. 4491 4492 `cp_namespace_decls' 4493 This function will return the declarations contained in the 4494 namespace, including types, overloaded functions, other 4495 namespaces, and so forth. If there are no declarations, this 4496 function will return `NULL_TREE'. The declarations are connected 4497 through their `TREE_CHAIN' fields. 4498 4499 Although most entries on this list will be declarations, 4500 `TREE_LIST' nodes may also appear. In this case, the `TREE_VALUE' 4501 will be an `OVERLOAD'. The value of the `TREE_PURPOSE' is 4502 unspecified; back ends should ignore this value. As with the 4503 other kinds of declarations returned by `cp_namespace_decls', the 4504 `TREE_CHAIN' will point to the next declaration in this list. 4505 4506 For more information on the kinds of declarations that can occur 4507 on this list, *Note Declarations::. Some declarations will not 4508 appear on this list. In particular, no `FIELD_DECL', 4509 `LABEL_DECL', or `PARM_DECL' nodes will appear here. 4510 4511 This function cannot be used with namespaces that have 4512 `DECL_NAMESPACE_ALIAS' set. 4513 4514 4515 4516 File: gccint.info, Node: Classes, Prev: Namespaces, Up: Scopes 4517 4518 9.4.2 Classes 4519 ------------- 4520 4521 A class type is represented by either a `RECORD_TYPE' or a 4522 `UNION_TYPE'. A class declared with the `union' tag is represented by 4523 a `UNION_TYPE', while classes declared with either the `struct' or the 4524 `class' tag are represented by `RECORD_TYPE's. You can use the 4525 `CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular 4526 type is a `class' as opposed to a `struct'. This macro will be true 4527 only for classes declared with the `class' tag. 4528 4529 Almost all non-function members are available on the `TYPE_FIELDS' 4530 list. Given one member, the next can be found by following the 4531 `TREE_CHAIN'. You should not depend in any way on the order in which 4532 fields appear on this list. All nodes on this list will be `DECL' 4533 nodes. A `FIELD_DECL' is used to represent a non-static data member, a 4534 `VAR_DECL' is used to represent a static data member, and a `TYPE_DECL' 4535 is used to represent a type. Note that the `CONST_DECL' for an 4536 enumeration constant will appear on this list, if the enumeration type 4537 was declared in the class. (Of course, the `TYPE_DECL' for the 4538 enumeration type will appear here as well.) There are no entries for 4539 base classes on this list. In particular, there is no `FIELD_DECL' for 4540 the "base-class portion" of an object. 4541 4542 The `TYPE_VFIELD' is a compiler-generated field used to point to 4543 virtual function tables. It may or may not appear on the `TYPE_FIELDS' 4544 list. However, back ends should handle the `TYPE_VFIELD' just like all 4545 the entries on the `TYPE_FIELDS' list. 4546 4547 The function members are available on the `TYPE_METHODS' list. Again, 4548 subsequent members are found by following the `TREE_CHAIN' field. If a 4549 function is overloaded, each of the overloaded functions appears; no 4550 `OVERLOAD' nodes appear on the `TYPE_METHODS' list. Implicitly 4551 declared functions (including default constructors, copy constructors, 4552 assignment operators, and destructors) will appear on this list as well. 4553 4554 Every class has an associated "binfo", which can be obtained with 4555 `TYPE_BINFO'. Binfos are used to represent base-classes. The binfo 4556 given by `TYPE_BINFO' is the degenerate case, whereby every class is 4557 considered to be its own base-class. The base binfos for a particular 4558 binfo are held in a vector, whose length is obtained with 4559 `BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with 4560 `BINFO_BASE_BINFO' and `BINFO_BASE_ITERATE'. To add a new binfo, use 4561 `BINFO_BASE_APPEND'. The vector of base binfos can be obtained with 4562 `BINFO_BASE_BINFOS', but normally you do not need to use that. The 4563 class type associated with a binfo is given by `BINFO_TYPE'. It is not 4564 always the case that `BINFO_TYPE (TYPE_BINFO (x))', because of typedefs 4565 and qualified types. Neither is it the case that `TYPE_BINFO 4566 (BINFO_TYPE (y))' is the same binfo as `y'. The reason is that if `y' 4567 is a binfo representing a base-class `B' of a derived class `D', then 4568 `BINFO_TYPE (y)' will be `B', and `TYPE_BINFO (BINFO_TYPE (y))' will be 4569 `B' as its own base-class, rather than as a base-class of `D'. 4570 4571 The access to a base type can be found with `BINFO_BASE_ACCESS'. This 4572 will produce `access_public_node', `access_private_node' or 4573 `access_protected_node'. If bases are always public, 4574 `BINFO_BASE_ACCESSES' may be `NULL'. 4575 4576 `BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited 4577 virtually or not. The other flags, `BINFO_MARKED_P' and `BINFO_FLAG_1' 4578 to `BINFO_FLAG_6' can be used for language specific use. 4579 4580 The following macros can be used on a tree node representing a 4581 class-type. 4582 4583 `LOCAL_CLASS_P' 4584 This predicate holds if the class is local class _i.e._ declared 4585 inside a function body. 4586 4587 `TYPE_POLYMORPHIC_P' 4588 This predicate holds if the class has at least one virtual function 4589 (declared or inherited). 4590 4591 `TYPE_HAS_DEFAULT_CONSTRUCTOR' 4592 This predicate holds whenever its argument represents a class-type 4593 with default constructor. 4594 4595 `CLASSTYPE_HAS_MUTABLE' 4596 `TYPE_HAS_MUTABLE_P' 4597 These predicates hold for a class-type having a mutable data 4598 member. 4599 4600 `CLASSTYPE_NON_POD_P' 4601 This predicate holds only for class-types that are not PODs. 4602 4603 `TYPE_HAS_NEW_OPERATOR' 4604 This predicate holds for a class-type that defines `operator new'. 4605 4606 `TYPE_HAS_ARRAY_NEW_OPERATOR' 4607 This predicate holds for a class-type for which `operator new[]' 4608 is defined. 4609 4610 `TYPE_OVERLOADS_CALL_EXPR' 4611 This predicate holds for class-type for which the function call 4612 `operator()' is overloaded. 4613 4614 `TYPE_OVERLOADS_ARRAY_REF' 4615 This predicate holds for a class-type that overloads `operator[]' 4616 4617 `TYPE_OVERLOADS_ARROW' 4618 This predicate holds for a class-type for which `operator->' is 4619 overloaded. 4620 4621 4622 4623 File: gccint.info, Node: Declarations, Next: Attributes, Prev: Functions, Up: Trees 4624 4625 9.5 Declarations 4626 ================ 4627 4628 This section covers the various kinds of declarations that appear in the 4629 internal representation, except for declarations of functions 4630 (represented by `FUNCTION_DECL' nodes), which are described in *Note 4631 Functions::. 4632 4633 * Menu: 4634 4635 * Working with declarations:: Macros and functions that work on 4636 declarations. 4637 * Internal structure:: How declaration nodes are represented. 4638 4639 4640 File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations 4641 4642 9.5.1 Working with declarations 4643 ------------------------------- 4644 4645 Some macros can be used with any kind of declaration. These include: 4646 `DECL_NAME' 4647 This macro returns an `IDENTIFIER_NODE' giving the name of the 4648 entity. 4649 4650 `TREE_TYPE' 4651 This macro returns the type of the entity declared. 4652 4653 `TREE_FILENAME' 4654 This macro returns the name of the file in which the entity was 4655 declared, as a `char*'. For an entity declared implicitly by the 4656 compiler (like `__builtin_memcpy'), this will be the string 4657 `"<internal>"'. 4658 4659 `TREE_LINENO' 4660 This macro returns the line number at which the entity was 4661 declared, as an `int'. 4662 4663 `DECL_ARTIFICIAL' 4664 This predicate holds if the declaration was implicitly generated 4665 by the compiler. For example, this predicate will hold of an 4666 implicitly declared member function, or of the `TYPE_DECL' 4667 implicitly generated for a class type. Recall that in C++ code 4668 like: 4669 struct S {}; 4670 is roughly equivalent to C code like: 4671 struct S {}; 4672 typedef struct S S; 4673 The implicitly generated `typedef' declaration is represented by a 4674 `TYPE_DECL' for which `DECL_ARTIFICIAL' holds. 4675 4676 `DECL_NAMESPACE_SCOPE_P' 4677 This predicate holds if the entity was declared at a namespace 4678 scope. 4679 4680 `DECL_CLASS_SCOPE_P' 4681 This predicate holds if the entity was declared at a class scope. 4682 4683 `DECL_FUNCTION_SCOPE_P' 4684 This predicate holds if the entity was declared inside a function 4685 body. 4686 4687 4688 The various kinds of declarations include: 4689 `LABEL_DECL' 4690 These nodes are used to represent labels in function bodies. For 4691 more information, see *Note Functions::. These nodes only appear 4692 in block scopes. 4693 4694 `CONST_DECL' 4695 These nodes are used to represent enumeration constants. The 4696 value of the constant is given by `DECL_INITIAL' which will be an 4697 `INTEGER_CST' with the same type as the `TREE_TYPE' of the 4698 `CONST_DECL', i.e., an `ENUMERAL_TYPE'. 4699 4700 `RESULT_DECL' 4701 These nodes represent the value returned by a function. When a 4702 value is assigned to a `RESULT_DECL', that indicates that the 4703 value should be returned, via bitwise copy, by the function. You 4704 can use `DECL_SIZE' and `DECL_ALIGN' on a `RESULT_DECL', just as 4705 with a `VAR_DECL'. 4706 4707 `TYPE_DECL' 4708 These nodes represent `typedef' declarations. The `TREE_TYPE' is 4709 the type declared to have the name given by `DECL_NAME'. In some 4710 cases, there is no associated name. 4711 4712 `VAR_DECL' 4713 These nodes represent variables with namespace or block scope, as 4714 well as static data members. The `DECL_SIZE' and `DECL_ALIGN' are 4715 analogous to `TYPE_SIZE' and `TYPE_ALIGN'. For a declaration, you 4716 should always use the `DECL_SIZE' and `DECL_ALIGN' rather than the 4717 `TYPE_SIZE' and `TYPE_ALIGN' given by the `TREE_TYPE', since 4718 special attributes may have been applied to the variable to give 4719 it a particular size and alignment. You may use the predicates 4720 `DECL_THIS_STATIC' or `DECL_THIS_EXTERN' to test whether the 4721 storage class specifiers `static' or `extern' were used to declare 4722 a variable. 4723 4724 If this variable is initialized (but does not require a 4725 constructor), the `DECL_INITIAL' will be an expression for the 4726 initializer. The initializer should be evaluated, and a bitwise 4727 copy into the variable performed. If the `DECL_INITIAL' is the 4728 `error_mark_node', there is an initializer, but it is given by an 4729 explicit statement later in the code; no bitwise copy is required. 4730 4731 GCC provides an extension that allows either automatic variables, 4732 or global variables, to be placed in particular registers. This 4733 extension is being used for a particular `VAR_DECL' if 4734 `DECL_REGISTER' holds for the `VAR_DECL', and if 4735 `DECL_ASSEMBLER_NAME' is not equal to `DECL_NAME'. In that case, 4736 `DECL_ASSEMBLER_NAME' is the name of the register into which the 4737 variable will be placed. 4738 4739 `PARM_DECL' 4740 Used to represent a parameter to a function. Treat these nodes 4741 similarly to `VAR_DECL' nodes. These nodes only appear in the 4742 `DECL_ARGUMENTS' for a `FUNCTION_DECL'. 4743 4744 The `DECL_ARG_TYPE' for a `PARM_DECL' is the type that will 4745 actually be used when a value is passed to this function. It may 4746 be a wider type than the `TREE_TYPE' of the parameter; for 4747 example, the ordinary type might be `short' while the 4748 `DECL_ARG_TYPE' is `int'. 4749 4750 `FIELD_DECL' 4751 These nodes represent non-static data members. The `DECL_SIZE' and 4752 `DECL_ALIGN' behave as for `VAR_DECL' nodes. The position of the 4753 field within the parent record is specified by a combination of 4754 three attributes. `DECL_FIELD_OFFSET' is the position, counting 4755 in bytes, of the `DECL_OFFSET_ALIGN'-bit sized word containing the 4756 bit of the field closest to the beginning of the structure. 4757 `DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the 4758 field within this word; this may be nonzero even for fields that 4759 are not bit-fields, since `DECL_OFFSET_ALIGN' may be greater than 4760 the natural alignment of the field's type. 4761 4762 If `DECL_C_BIT_FIELD' holds, this field is a bit-field. In a 4763 bit-field, `DECL_BIT_FIELD_TYPE' also contains the type that was 4764 originally specified for it, while DECL_TYPE may be a modified 4765 type with lesser precision, according to the size of the bit field. 4766 4767 `NAMESPACE_DECL' 4768 *Note Namespaces::. 4769 4770 `TEMPLATE_DECL' 4771 These nodes are used to represent class, function, and variable 4772 (static data member) templates. The 4773 `DECL_TEMPLATE_SPECIALIZATIONS' are a `TREE_LIST'. The 4774 `TREE_VALUE' of each node in the list is a `TEMPLATE_DECL's or 4775 `FUNCTION_DECL's representing specializations (including 4776 instantiations) of this template. Back ends can safely ignore 4777 `TEMPLATE_DECL's, but should examine `FUNCTION_DECL' nodes on the 4778 specializations list just as they would ordinary `FUNCTION_DECL' 4779 nodes. 4780 4781 For a class template, the `DECL_TEMPLATE_INSTANTIATIONS' list 4782 contains the instantiations. The `TREE_VALUE' of each node is an 4783 instantiation of the class. The `DECL_TEMPLATE_SPECIALIZATIONS' 4784 contains partial specializations of the class. 4785 4786 `USING_DECL' 4787 Back ends can safely ignore these nodes. 4788 4789 4790 4791 File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations 4792 4793 9.5.2 Internal structure 4794 ------------------------ 4795 4796 `DECL' nodes are represented internally as a hierarchy of structures. 4797 4798 * Menu: 4799 4800 * Current structure hierarchy:: The current DECL node structure 4801 hierarchy. 4802 * Adding new DECL node types:: How to add a new DECL node to a 4803 frontend. 4804 4805 4806 File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure 4807 4808 9.5.2.1 Current structure hierarchy 4809 ................................... 4810 4811 `struct tree_decl_minimal' 4812 This is the minimal structure to inherit from in order for common 4813 `DECL' macros to work. The fields it contains are a unique ID, 4814 source location, context, and name. 4815 4816 `struct tree_decl_common' 4817 This structure inherits from `struct tree_decl_minimal'. It 4818 contains fields that most `DECL' nodes need, such as a field to 4819 store alignment, machine mode, size, and attributes. 4820 4821 `struct tree_field_decl' 4822 This structure inherits from `struct tree_decl_common'. It is 4823 used to represent `FIELD_DECL'. 4824 4825 `struct tree_label_decl' 4826 This structure inherits from `struct tree_decl_common'. It is 4827 used to represent `LABEL_DECL'. 4828 4829 `struct tree_translation_unit_decl' 4830 This structure inherits from `struct tree_decl_common'. It is 4831 used to represent `TRANSLATION_UNIT_DECL'. 4832 4833 `struct tree_decl_with_rtl' 4834 This structure inherits from `struct tree_decl_common'. It 4835 contains a field to store the low-level RTL associated with a 4836 `DECL' node. 4837 4838 `struct tree_result_decl' 4839 This structure inherits from `struct tree_decl_with_rtl'. It is 4840 used to represent `RESULT_DECL'. 4841 4842 `struct tree_const_decl' 4843 This structure inherits from `struct tree_decl_with_rtl'. It is 4844 used to represent `CONST_DECL'. 4845 4846 `struct tree_parm_decl' 4847 This structure inherits from `struct tree_decl_with_rtl'. It is 4848 used to represent `PARM_DECL'. 4849 4850 `struct tree_decl_with_vis' 4851 This structure inherits from `struct tree_decl_with_rtl'. It 4852 contains fields necessary to store visibility information, as well 4853 as a section name and assembler name. 4854 4855 `struct tree_var_decl' 4856 This structure inherits from `struct tree_decl_with_vis'. It is 4857 used to represent `VAR_DECL'. 4858 4859 `struct tree_function_decl' 4860 This structure inherits from `struct tree_decl_with_vis'. It is 4861 used to represent `FUNCTION_DECL'. 4862 4863 4864 4865 File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure 4866 4867 9.5.2.2 Adding new DECL node types 4868 .................................. 4869 4870 Adding a new `DECL' tree consists of the following steps 4871 4872 Add a new tree code for the `DECL' node 4873 For language specific `DECL' nodes, there is a `.def' file in each 4874 frontend directory where the tree code should be added. For 4875 `DECL' nodes that are part of the middle-end, the code should be 4876 added to `tree.def'. 4877 4878 Create a new structure type for the `DECL' node 4879 These structures should inherit from one of the existing 4880 structures in the language hierarchy by using that structure as 4881 the first member. 4882 4883 struct tree_foo_decl 4884 { 4885 struct tree_decl_with_vis common; 4886 } 4887 4888 Would create a structure name `tree_foo_decl' that inherits from 4889 `struct tree_decl_with_vis'. 4890 4891 For language specific `DECL' nodes, this new structure type should 4892 go in the appropriate `.h' file. For `DECL' nodes that are part 4893 of the middle-end, the structure type should go in `tree.h'. 4894 4895 Add a member to the tree structure enumerator for the node 4896 For garbage collection and dynamic checking purposes, each `DECL' 4897 node structure type is required to have a unique enumerator value 4898 specified with it. For language specific `DECL' nodes, this new 4899 enumerator value should go in the appropriate `.def' file. For 4900 `DECL' nodes that are part of the middle-end, the enumerator 4901 values are specified in `treestruct.def'. 4902 4903 Update `union tree_node' 4904 In order to make your new structure type usable, it must be added 4905 to `union tree_node'. For language specific `DECL' nodes, a new 4906 entry should be added to the appropriate `.h' file of the form 4907 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl; 4908 For `DECL' nodes that are part of the middle-end, the additional 4909 member goes directly into `union tree_node' in `tree.h'. 4910 4911 Update dynamic checking info 4912 In order to be able to check whether accessing a named portion of 4913 `union tree_node' is legal, and whether a certain `DECL' node 4914 contains one of the enumerated `DECL' node structures in the 4915 hierarchy, a simple lookup table is used. This lookup table needs 4916 to be kept up to date with the tree structure hierarchy, or else 4917 checking and containment macros will fail inappropriately. 4918 4919 For language specific `DECL' nodes, their is an `init_ts' function 4920 in an appropriate `.c' file, which initializes the lookup table. 4921 Code setting up the table for new `DECL' nodes should be added 4922 there. For each `DECL' tree code and enumerator value 4923 representing a member of the inheritance hierarchy, the table 4924 should contain 1 if that tree code inherits (directly or 4925 indirectly) from that member. Thus, a `FOO_DECL' node derived 4926 from `struct decl_with_rtl', and enumerator value `TS_FOO_DECL', 4927 would be set up as follows 4928 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1; 4929 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1; 4930 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1; 4931 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1; 4932 4933 For `DECL' nodes that are part of the middle-end, the setup code 4934 goes into `tree.c'. 4935 4936 Add macros to access any new fields and flags 4937 Each added field or flag should have a macro that is used to access 4938 it, that performs appropriate checking to ensure only the right 4939 type of `DECL' nodes access the field. 4940 4941 These macros generally take the following form 4942 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname 4943 However, if the structure is simply a base class for further 4944 structures, something like the following should be used 4945 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT) 4946 #define BASE_STRUCT_FIELDNAME(NODE) \ 4947 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname 4948 4949 4950 4951 File: gccint.info, Node: Functions, Next: Declarations, Prev: Scopes, Up: Trees 4952 4953 9.6 Functions 4954 ============= 4955 4956 A function is represented by a `FUNCTION_DECL' node. A set of 4957 overloaded functions is sometimes represented by a `OVERLOAD' node. 4958 4959 An `OVERLOAD' node is not a declaration, so none of the `DECL_' macros 4960 should be used on an `OVERLOAD'. An `OVERLOAD' node is similar to a 4961 `TREE_LIST'. Use `OVL_CURRENT' to get the function associated with an 4962 `OVERLOAD' node; use `OVL_NEXT' to get the next `OVERLOAD' node in the 4963 list of overloaded functions. The macros `OVL_CURRENT' and `OVL_NEXT' 4964 are actually polymorphic; you can use them to work with `FUNCTION_DECL' 4965 nodes as well as with overloads. In the case of a `FUNCTION_DECL', 4966 `OVL_CURRENT' will always return the function itself, and `OVL_NEXT' 4967 will always be `NULL_TREE'. 4968 4969 To determine the scope of a function, you can use the `DECL_CONTEXT' 4970 macro. This macro will return the class (either a `RECORD_TYPE' or a 4971 `UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function 4972 is a member. For a virtual function, this macro returns the class in 4973 which the function was actually defined, not the base class in which 4974 the virtual declaration occurred. 4975 4976 If a friend function is defined in a class scope, the 4977 `DECL_FRIEND_CONTEXT' macro can be used to determine the class in which 4978 it was defined. For example, in 4979 class C { friend void f() {} }; 4980 the `DECL_CONTEXT' for `f' will be the `global_namespace', but the 4981 `DECL_FRIEND_CONTEXT' will be the `RECORD_TYPE' for `C'. 4982 4983 In C, the `DECL_CONTEXT' for a function maybe another function. This 4984 representation indicates that the GNU nested function extension is in 4985 use. For details on the semantics of nested functions, see the GCC 4986 Manual. The nested function can refer to local variables in its 4987 containing function. Such references are not explicitly marked in the 4988 tree structure; back ends must look at the `DECL_CONTEXT' for the 4989 referenced `VAR_DECL'. If the `DECL_CONTEXT' for the referenced 4990 `VAR_DECL' is not the same as the function currently being processed, 4991 and neither `DECL_EXTERNAL' nor `DECL_STATIC' hold, then the reference 4992 is to a local variable in a containing function, and the back end must 4993 take appropriate action. 4994 4995 * Menu: 4996 4997 * Function Basics:: Function names, linkage, and so forth. 4998 * Function Bodies:: The statements that make up a function body. 4999 5000 5001 File: gccint.info, Node: Function Basics, Next: Function Bodies, Up: Functions 5002 5003 9.6.1 Function Basics 5004 --------------------- 5005 5006 The following macros and functions can be used on a `FUNCTION_DECL': 5007 `DECL_MAIN_P' 5008 This predicate holds for a function that is the program entry point 5009 `::code'. 5010 5011 `DECL_NAME' 5012 This macro returns the unqualified name of the function, as an 5013 `IDENTIFIER_NODE'. For an instantiation of a function template, 5014 the `DECL_NAME' is the unqualified name of the template, not 5015 something like `f<int>'. The value of `DECL_NAME' is undefined 5016 when used on a constructor, destructor, overloaded operator, or 5017 type-conversion operator, or any function that is implicitly 5018 generated by the compiler. See below for macros that can be used 5019 to distinguish these cases. 5020 5021 `DECL_ASSEMBLER_NAME' 5022 This macro returns the mangled name of the function, also an 5023 `IDENTIFIER_NODE'. This name does not contain leading underscores 5024 on systems that prefix all identifiers with underscores. The 5025 mangled name is computed in the same way on all platforms; if 5026 special processing is required to deal with the object file format 5027 used on a particular platform, it is the responsibility of the 5028 back end to perform those modifications. (Of course, the back end 5029 should not modify `DECL_ASSEMBLER_NAME' itself.) 5030 5031 Using `DECL_ASSEMBLER_NAME' will cause additional memory to be 5032 allocated (for the mangled name of the entity) so it should be used 5033 only when emitting assembly code. It should not be used within the 5034 optimizers to determine whether or not two declarations are the 5035 same, even though some of the existing optimizers do use it in 5036 that way. These uses will be removed over time. 5037 5038 `DECL_EXTERNAL' 5039 This predicate holds if the function is undefined. 5040 5041 `TREE_PUBLIC' 5042 This predicate holds if the function has external linkage. 5043 5044 `DECL_LOCAL_FUNCTION_P' 5045 This predicate holds if the function was declared at block scope, 5046 even though it has a global scope. 5047 5048 `DECL_ANTICIPATED' 5049 This predicate holds if the function is a built-in function but its 5050 prototype is not yet explicitly declared. 5051 5052 `DECL_EXTERN_C_FUNCTION_P' 5053 This predicate holds if the function is declared as an ``extern 5054 "C"'' function. 5055 5056 `DECL_LINKONCE_P' 5057 This macro holds if multiple copies of this function may be 5058 emitted in various translation units. It is the responsibility of 5059 the linker to merge the various copies. Template instantiations 5060 are the most common example of functions for which 5061 `DECL_LINKONCE_P' holds; G++ instantiates needed templates in all 5062 translation units which require them, and then relies on the 5063 linker to remove duplicate instantiations. 5064 5065 FIXME: This macro is not yet implemented. 5066 5067 `DECL_FUNCTION_MEMBER_P' 5068 This macro holds if the function is a member of a class, rather 5069 than a member of a namespace. 5070 5071 `DECL_STATIC_FUNCTION_P' 5072 This predicate holds if the function a static member function. 5073 5074 `DECL_NONSTATIC_MEMBER_FUNCTION_P' 5075 This macro holds for a non-static member function. 5076 5077 `DECL_CONST_MEMFUNC_P' 5078 This predicate holds for a `const'-member function. 5079 5080 `DECL_VOLATILE_MEMFUNC_P' 5081 This predicate holds for a `volatile'-member function. 5082 5083 `DECL_CONSTRUCTOR_P' 5084 This macro holds if the function is a constructor. 5085 5086 `DECL_NONCONVERTING_P' 5087 This predicate holds if the constructor is a non-converting 5088 constructor. 5089 5090 `DECL_COMPLETE_CONSTRUCTOR_P' 5091 This predicate holds for a function which is a constructor for an 5092 object of a complete type. 5093 5094 `DECL_BASE_CONSTRUCTOR_P' 5095 This predicate holds for a function which is a constructor for a 5096 base class sub-object. 5097 5098 `DECL_COPY_CONSTRUCTOR_P' 5099 This predicate holds for a function which is a copy-constructor. 5100 5101 `DECL_DESTRUCTOR_P' 5102 This macro holds if the function is a destructor. 5103 5104 `DECL_COMPLETE_DESTRUCTOR_P' 5105 This predicate holds if the function is the destructor for an 5106 object a complete type. 5107 5108 `DECL_OVERLOADED_OPERATOR_P' 5109 This macro holds if the function is an overloaded operator. 5110 5111 `DECL_CONV_FN_P' 5112 This macro holds if the function is a type-conversion operator. 5113 5114 `DECL_GLOBAL_CTOR_P' 5115 This predicate holds if the function is a file-scope initialization 5116 function. 5117 5118 `DECL_GLOBAL_DTOR_P' 5119 This predicate holds if the function is a file-scope finalization 5120 function. 5121 5122 `DECL_THUNK_P' 5123 This predicate holds if the function is a thunk. 5124 5125 These functions represent stub code that adjusts the `this' pointer 5126 and then jumps to another function. When the jumped-to function 5127 returns, control is transferred directly to the caller, without 5128 returning to the thunk. The first parameter to the thunk is 5129 always the `this' pointer; the thunk should add `THUNK_DELTA' to 5130 this value. (The `THUNK_DELTA' is an `int', not an `INTEGER_CST'.) 5131 5132 Then, if `THUNK_VCALL_OFFSET' (an `INTEGER_CST') is nonzero the 5133 adjusted `this' pointer must be adjusted again. The complete 5134 calculation is given by the following pseudo-code: 5135 5136 this += THUNK_DELTA 5137 if (THUNK_VCALL_OFFSET) 5138 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] 5139 5140 Finally, the thunk should jump to the location given by 5141 `DECL_INITIAL'; this will always be an expression for the address 5142 of a function. 5143 5144 `DECL_NON_THUNK_FUNCTION_P' 5145 This predicate holds if the function is _not_ a thunk function. 5146 5147 `GLOBAL_INIT_PRIORITY' 5148 If either `DECL_GLOBAL_CTOR_P' or `DECL_GLOBAL_DTOR_P' holds, then 5149 this gives the initialization priority for the function. The 5150 linker will arrange that all functions for which 5151 `DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority 5152 before `main' is called. When the program exits, all functions for 5153 which `DECL_GLOBAL_DTOR_P' holds are run in the reverse order. 5154 5155 `DECL_ARTIFICIAL' 5156 This macro holds if the function was implicitly generated by the 5157 compiler, rather than explicitly declared. In addition to 5158 implicitly generated class member functions, this macro holds for 5159 the special functions created to implement static initialization 5160 and destruction, to compute run-time type information, and so 5161 forth. 5162 5163 `DECL_ARGUMENTS' 5164 This macro returns the `PARM_DECL' for the first argument to the 5165 function. Subsequent `PARM_DECL' nodes can be obtained by 5166 following the `TREE_CHAIN' links. 5167 5168 `DECL_RESULT' 5169 This macro returns the `RESULT_DECL' for the function. 5170 5171 `TREE_TYPE' 5172 This macro returns the `FUNCTION_TYPE' or `METHOD_TYPE' for the 5173 function. 5174 5175 `TYPE_RAISES_EXCEPTIONS' 5176 This macro returns the list of exceptions that a (member-)function 5177 can raise. The returned list, if non `NULL', is comprised of nodes 5178 whose `TREE_VALUE' represents a type. 5179 5180 `TYPE_NOTHROW_P' 5181 This predicate holds when the exception-specification of its 5182 arguments if of the form ``()''. 5183 5184 `DECL_ARRAY_DELETE_OPERATOR_P' 5185 This predicate holds if the function an overloaded `operator 5186 delete[]'. 5187 5188 5189 5190 File: gccint.info, Node: Function Bodies, Prev: Function Basics, Up: Functions 5191 5192 9.6.2 Function Bodies 5193 --------------------- 5194 5195 A function that has a definition in the current translation unit will 5196 have a non-`NULL' `DECL_INITIAL'. However, back ends should not make 5197 use of the particular value given by `DECL_INITIAL'. 5198 5199 The `DECL_SAVED_TREE' macro will give the complete body of the 5200 function. 5201 5202 9.6.2.1 Statements 5203 .................. 5204 5205 There are tree nodes corresponding to all of the source-level statement 5206 constructs, used within the C and C++ frontends. These are enumerated 5207 here, together with a list of the various macros that can be used to 5208 obtain information about them. There are a few macros that can be used 5209 with all statements: 5210 5211 `STMT_IS_FULL_EXPR_P' 5212 In C++, statements normally constitute "full expressions"; 5213 temporaries created during a statement are destroyed when the 5214 statement is complete. However, G++ sometimes represents 5215 expressions by statements; these statements will not have 5216 `STMT_IS_FULL_EXPR_P' set. Temporaries created during such 5217 statements should be destroyed when the innermost enclosing 5218 statement with `STMT_IS_FULL_EXPR_P' set is exited. 5219 5220 5221 Here is the list of the various statement nodes, and the macros used to 5222 access them. This documentation describes the use of these nodes in 5223 non-template functions (including instantiations of template functions). 5224 In template functions, the same nodes are used, but sometimes in 5225 slightly different ways. 5226 5227 Many of the statements have substatements. For example, a `while' 5228 loop will have a body, which is itself a statement. If the substatement 5229 is `NULL_TREE', it is considered equivalent to a statement consisting 5230 of a single `;', i.e., an expression statement in which the expression 5231 has been omitted. A substatement may in fact be a list of statements, 5232 connected via their `TREE_CHAIN's. So, you should always process the 5233 statement tree by looping over substatements, like this: 5234 void process_stmt (stmt) 5235 tree stmt; 5236 { 5237 while (stmt) 5238 { 5239 switch (TREE_CODE (stmt)) 5240 { 5241 case IF_STMT: 5242 process_stmt (THEN_CLAUSE (stmt)); 5243 /* More processing here. */ 5244 break; 5245 5246 ... 5247 } 5248 5249 stmt = TREE_CHAIN (stmt); 5250 } 5251 } 5252 In other words, while the `then' clause of an `if' statement in C++ 5253 can be only one statement (although that one statement may be a 5254 compound statement), the intermediate representation will sometimes use 5255 several statements chained together. 5256 5257 `ASM_EXPR' 5258 Used to represent an inline assembly statement. For an inline 5259 assembly statement like: 5260 asm ("mov x, y"); 5261 The `ASM_STRING' macro will return a `STRING_CST' node for `"mov 5262 x, y"'. If the original statement made use of the 5263 extended-assembly syntax, then `ASM_OUTPUTS', `ASM_INPUTS', and 5264 `ASM_CLOBBERS' will be the outputs, inputs, and clobbers for the 5265 statement, represented as `STRING_CST' nodes. The 5266 extended-assembly syntax looks like: 5267 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 5268 The first string is the `ASM_STRING', containing the instruction 5269 template. The next two strings are the output and inputs, 5270 respectively; this statement has no clobbers. As this example 5271 indicates, "plain" assembly statements are merely a special case 5272 of extended assembly statements; they have no cv-qualifiers, 5273 outputs, inputs, or clobbers. All of the strings will be 5274 `NUL'-terminated, and will contain no embedded `NUL'-characters. 5275 5276 If the assembly statement is declared `volatile', or if the 5277 statement was not an extended assembly statement, and is therefore 5278 implicitly volatile, then the predicate `ASM_VOLATILE_P' will hold 5279 of the `ASM_EXPR'. 5280 5281 `BREAK_STMT' 5282 Used to represent a `break' statement. There are no additional 5283 fields. 5284 5285 `CASE_LABEL_EXPR' 5286 Use to represent a `case' label, range of `case' labels, or a 5287 `default' label. If `CASE_LOW' is `NULL_TREE', then this is a 5288 `default' label. Otherwise, if `CASE_HIGH' is `NULL_TREE', then 5289 this is an ordinary `case' label. In this case, `CASE_LOW' is an 5290 expression giving the value of the label. Both `CASE_LOW' and 5291 `CASE_HIGH' are `INTEGER_CST' nodes. These values will have the 5292 same type as the condition expression in the switch statement. 5293 5294 Otherwise, if both `CASE_LOW' and `CASE_HIGH' are defined, the 5295 statement is a range of case labels. Such statements originate 5296 with the extension that allows users to write things of the form: 5297 case 2 ... 5: 5298 The first value will be `CASE_LOW', while the second will be 5299 `CASE_HIGH'. 5300 5301 `CLEANUP_STMT' 5302 Used to represent an action that should take place upon exit from 5303 the enclosing scope. Typically, these actions are calls to 5304 destructors for local objects, but back ends cannot rely on this 5305 fact. If these nodes are in fact representing such destructors, 5306 `CLEANUP_DECL' will be the `VAR_DECL' destroyed. Otherwise, 5307 `CLEANUP_DECL' will be `NULL_TREE'. In any case, the 5308 `CLEANUP_EXPR' is the expression to execute. The cleanups 5309 executed on exit from a scope should be run in the reverse order 5310 of the order in which the associated `CLEANUP_STMT's were 5311 encountered. 5312 5313 `CONTINUE_STMT' 5314 Used to represent a `continue' statement. There are no additional 5315 fields. 5316 5317 `CTOR_STMT' 5318 Used to mark the beginning (if `CTOR_BEGIN_P' holds) or end (if 5319 `CTOR_END_P' holds of the main body of a constructor. See also 5320 `SUBOBJECT' for more information on how to use these nodes. 5321 5322 `DECL_STMT' 5323 Used to represent a local declaration. The `DECL_STMT_DECL' macro 5324 can be used to obtain the entity declared. This declaration may 5325 be a `LABEL_DECL', indicating that the label declared is a local 5326 label. (As an extension, GCC allows the declaration of labels 5327 with scope.) In C, this declaration may be a `FUNCTION_DECL', 5328 indicating the use of the GCC nested function extension. For more 5329 information, *note Functions::. 5330 5331 `DO_STMT' 5332 Used to represent a `do' loop. The body of the loop is given by 5333 `DO_BODY' while the termination condition for the loop is given by 5334 `DO_COND'. The condition for a `do'-statement is always an 5335 expression. 5336 5337 `EMPTY_CLASS_EXPR' 5338 Used to represent a temporary object of a class with no data whose 5339 address is never taken. (All such objects are interchangeable.) 5340 The `TREE_TYPE' represents the type of the object. 5341 5342 `EXPR_STMT' 5343 Used to represent an expression statement. Use `EXPR_STMT_EXPR' to 5344 obtain the expression. 5345 5346 `FOR_STMT' 5347 Used to represent a `for' statement. The `FOR_INIT_STMT' is the 5348 initialization statement for the loop. The `FOR_COND' is the 5349 termination condition. The `FOR_EXPR' is the expression executed 5350 right before the `FOR_COND' on each loop iteration; often, this 5351 expression increments a counter. The body of the loop is given by 5352 `FOR_BODY'. Note that `FOR_INIT_STMT' and `FOR_BODY' return 5353 statements, while `FOR_COND' and `FOR_EXPR' return expressions. 5354 5355 `GOTO_EXPR' 5356 Used to represent a `goto' statement. The `GOTO_DESTINATION' will 5357 usually be a `LABEL_DECL'. However, if the "computed goto" 5358 extension has been used, the `GOTO_DESTINATION' will be an 5359 arbitrary expression indicating the destination. This expression 5360 will always have pointer type. 5361 5362 `HANDLER' 5363 Used to represent a C++ `catch' block. The `HANDLER_TYPE' is the 5364 type of exception that will be caught by this handler; it is equal 5365 (by pointer equality) to `NULL' if this handler is for all types. 5366 `HANDLER_PARMS' is the `DECL_STMT' for the catch parameter, and 5367 `HANDLER_BODY' is the code for the block itself. 5368 5369 `IF_STMT' 5370 Used to represent an `if' statement. The `IF_COND' is the 5371 expression. 5372 5373 If the condition is a `TREE_LIST', then the `TREE_PURPOSE' is a 5374 statement (usually a `DECL_STMT'). Each time the condition is 5375 evaluated, the statement should be executed. Then, the 5376 `TREE_VALUE' should be used as the conditional expression itself. 5377 This representation is used to handle C++ code like this: 5378 5379 if (int i = 7) ... 5380 5381 where there is a new local variable (or variables) declared within 5382 the condition. 5383 5384 The `THEN_CLAUSE' represents the statement given by the `then' 5385 condition, while the `ELSE_CLAUSE' represents the statement given 5386 by the `else' condition. 5387 5388 `LABEL_EXPR' 5389 Used to represent a label. The `LABEL_DECL' declared by this 5390 statement can be obtained with the `LABEL_EXPR_LABEL' macro. The 5391 `IDENTIFIER_NODE' giving the name of the label can be obtained from 5392 the `LABEL_DECL' with `DECL_NAME'. 5393 5394 `RETURN_STMT' 5395 Used to represent a `return' statement. The `RETURN_EXPR' is the 5396 expression returned; it will be `NULL_TREE' if the statement was 5397 just 5398 return; 5399 5400 `SUBOBJECT' 5401 In a constructor, these nodes are used to mark the point at which a 5402 subobject of `this' is fully constructed. If, after this point, an 5403 exception is thrown before a `CTOR_STMT' with `CTOR_END_P' set is 5404 encountered, the `SUBOBJECT_CLEANUP' must be executed. The 5405 cleanups must be executed in the reverse order in which they 5406 appear. 5407 5408 `SWITCH_STMT' 5409 Used to represent a `switch' statement. The `SWITCH_STMT_COND' is 5410 the expression on which the switch is occurring. See the 5411 documentation for an `IF_STMT' for more information on the 5412 representation used for the condition. The `SWITCH_STMT_BODY' is 5413 the body of the switch statement. The `SWITCH_STMT_TYPE' is the 5414 original type of switch expression as given in the source, before 5415 any compiler conversions. 5416 5417 `TRY_BLOCK' 5418 Used to represent a `try' block. The body of the try block is 5419 given by `TRY_STMTS'. Each of the catch blocks is a `HANDLER' 5420 node. The first handler is given by `TRY_HANDLERS'. Subsequent 5421 handlers are obtained by following the `TREE_CHAIN' link from one 5422 handler to the next. The body of the handler is given by 5423 `HANDLER_BODY'. 5424 5425 If `CLEANUP_P' holds of the `TRY_BLOCK', then the `TRY_HANDLERS' 5426 will not be a `HANDLER' node. Instead, it will be an expression 5427 that should be executed if an exception is thrown in the try 5428 block. It must rethrow the exception after executing that code. 5429 And, if an exception is thrown while the expression is executing, 5430 `terminate' must be called. 5431 5432 `USING_STMT' 5433 Used to represent a `using' directive. The namespace is given by 5434 `USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node 5435 is needed inside template functions, to implement using directives 5436 during instantiation. 5437 5438 `WHILE_STMT' 5439 Used to represent a `while' loop. The `WHILE_COND' is the 5440 termination condition for the loop. See the documentation for an 5441 `IF_STMT' for more information on the representation used for the 5442 condition. 5443 5444 The `WHILE_BODY' is the body of the loop. 5445 5446 5447 5448 File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: Trees 5449 5450 9.7 Attributes in trees 5451 ======================= 5452 5453 Attributes, as specified using the `__attribute__' keyword, are 5454 represented internally as a `TREE_LIST'. The `TREE_PURPOSE' is the 5455 name of the attribute, as an `IDENTIFIER_NODE'. The `TREE_VALUE' is a 5456 `TREE_LIST' of the arguments of the attribute, if any, or `NULL_TREE' 5457 if there are no arguments; the arguments are stored as the `TREE_VALUE' 5458 of successive entries in the list, and may be identifiers or 5459 expressions. The `TREE_CHAIN' of the attribute is the next attribute 5460 in a list of attributes applying to the same declaration or type, or 5461 `NULL_TREE' if there are no further attributes in the list. 5462 5463 Attributes may be attached to declarations and to types; these 5464 attributes may be accessed with the following macros. All attributes 5465 are stored in this way, and many also cause other changes to the 5466 declaration or type or to other internal compiler data structures. 5467 5468 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL) 5469 This macro returns the attributes on the declaration DECL. 5470 5471 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE) 5472 This macro returns the attributes on the type TYPE. 5473 5474 5475 File: gccint.info, Node: Expression trees, Prev: Attributes, Up: Trees 5476 5477 9.8 Expressions 5478 =============== 5479 5480 The internal representation for expressions is for the most part quite 5481 straightforward. However, there are a few facts that one must bear in 5482 mind. In particular, the expression "tree" is actually a directed 5483 acyclic graph. (For example there may be many references to the integer 5484 constant zero throughout the source program; many of these will be 5485 represented by the same expression node.) You should not rely on 5486 certain kinds of node being shared, nor should rely on certain kinds of 5487 nodes being unshared. 5488 5489 The following macros can be used with all expression nodes: 5490 5491 `TREE_TYPE' 5492 Returns the type of the expression. This value may not be 5493 precisely the same type that would be given the expression in the 5494 original program. 5495 5496 In what follows, some nodes that one might expect to always have type 5497 `bool' are documented to have either integral or boolean type. At some 5498 point in the future, the C front end may also make use of this same 5499 intermediate representation, and at this point these nodes will 5500 certainly have integral type. The previous sentence is not meant to 5501 imply that the C++ front end does not or will not give these nodes 5502 integral type. 5503 5504 Below, we list the various kinds of expression nodes. Except where 5505 noted otherwise, the operands to an expression are accessed using the 5506 `TREE_OPERAND' macro. For example, to access the first operand to a 5507 binary plus expression `expr', use: 5508 5509 TREE_OPERAND (expr, 0) 5510 As this example indicates, the operands are zero-indexed. 5511 5512 All the expressions starting with `OMP_' represent directives and 5513 clauses used by the OpenMP API `http://www.openmp.org/'. 5514 5515 The table below begins with constants, moves on to unary expressions, 5516 then proceeds to binary expressions, and concludes with various other 5517 kinds of expressions: 5518 5519 `INTEGER_CST' 5520 These nodes represent integer constants. Note that the type of 5521 these constants is obtained with `TREE_TYPE'; they are not always 5522 of type `int'. In particular, `char' constants are represented 5523 with `INTEGER_CST' nodes. The value of the integer constant `e' is 5524 given by 5525 ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT) 5526 + TREE_INST_CST_LOW (e)) 5527 HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms. 5528 Both `TREE_INT_CST_HIGH' and `TREE_INT_CST_LOW' return a 5529 `HOST_WIDE_INT'. The value of an `INTEGER_CST' is interpreted as 5530 a signed or unsigned quantity depending on the type of the 5531 constant. In general, the expression given above will overflow, 5532 so it should not be used to calculate the value of the constant. 5533 5534 The variable `integer_zero_node' is an integer constant with value 5535 zero. Similarly, `integer_one_node' is an integer constant with 5536 value one. The `size_zero_node' and `size_one_node' variables are 5537 analogous, but have type `size_t' rather than `int'. 5538 5539 The function `tree_int_cst_lt' is a predicate which holds if its 5540 first argument is less than its second. Both constants are 5541 assumed to have the same signedness (i.e., either both should be 5542 signed or both should be unsigned.) The full width of the 5543 constant is used when doing the comparison; the usual rules about 5544 promotions and conversions are ignored. Similarly, 5545 `tree_int_cst_equal' holds if the two constants are equal. The 5546 `tree_int_cst_sgn' function returns the sign of a constant. The 5547 value is `1', `0', or `-1' according on whether the constant is 5548 greater than, equal to, or less than zero. Again, the signedness 5549 of the constant's type is taken into account; an unsigned constant 5550 is never less than zero, no matter what its bit-pattern. 5551 5552 `REAL_CST' 5553 FIXME: Talk about how to obtain representations of this constant, 5554 do comparisons, and so forth. 5555 5556 `COMPLEX_CST' 5557 These nodes are used to represent complex number constants, that 5558 is a `__complex__' whose parts are constant nodes. The 5559 `TREE_REALPART' and `TREE_IMAGPART' return the real and the 5560 imaginary parts respectively. 5561 5562 `VECTOR_CST' 5563 These nodes are used to represent vector constants, whose parts are 5564 constant nodes. Each individual constant node is either an 5565 integer or a double constant node. The first operand is a 5566 `TREE_LIST' of the constant nodes and is accessed through 5567 `TREE_VECTOR_CST_ELTS'. 5568 5569 `STRING_CST' 5570 These nodes represent string-constants. The `TREE_STRING_LENGTH' 5571 returns the length of the string, as an `int'. The 5572 `TREE_STRING_POINTER' is a `char*' containing the string itself. 5573 The string may not be `NUL'-terminated, and it may contain 5574 embedded `NUL' characters. Therefore, the `TREE_STRING_LENGTH' 5575 includes the trailing `NUL' if it is present. 5576 5577 For wide string constants, the `TREE_STRING_LENGTH' is the number 5578 of bytes in the string, and the `TREE_STRING_POINTER' points to an 5579 array of the bytes of the string, as represented on the target 5580 system (that is, as integers in the target endianness). Wide and 5581 non-wide string constants are distinguished only by the `TREE_TYPE' 5582 of the `STRING_CST'. 5583 5584 FIXME: The formats of string constants are not well-defined when 5585 the target system bytes are not the same width as host system 5586 bytes. 5587 5588 `PTRMEM_CST' 5589 These nodes are used to represent pointer-to-member constants. The 5590 `PTRMEM_CST_CLASS' is the class type (either a `RECORD_TYPE' or 5591 `UNION_TYPE' within which the pointer points), and the 5592 `PTRMEM_CST_MEMBER' is the declaration for the pointed to object. 5593 Note that the `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is in 5594 general different from the `PTRMEM_CST_CLASS'. For example, given: 5595 struct B { int i; }; 5596 struct D : public B {}; 5597 int D::*dp = &D::i; 5598 The `PTRMEM_CST_CLASS' for `&D::i' is `D', even though the 5599 `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is `B', since `B::i' is 5600 a member of `B', not `D'. 5601 5602 `VAR_DECL' 5603 These nodes represent variables, including static data members. 5604 For more information, *note Declarations::. 5605 5606 `NEGATE_EXPR' 5607 These nodes represent unary negation of the single operand, for 5608 both integer and floating-point types. The type of negation can be 5609 determined by looking at the type of the expression. 5610 5611 The behavior of this operation on signed arithmetic overflow is 5612 controlled by the `flag_wrapv' and `flag_trapv' variables. 5613 5614 `ABS_EXPR' 5615 These nodes represent the absolute value of the single operand, for 5616 both integer and floating-point types. This is typically used to 5617 implement the `abs', `labs' and `llabs' builtins for integer 5618 types, and the `fabs', `fabsf' and `fabsl' builtins for floating 5619 point types. The type of abs operation can be determined by 5620 looking at the type of the expression. 5621 5622 This node is not used for complex types. To represent the modulus 5623 or complex abs of a complex value, use the `BUILT_IN_CABS', 5624 `BUILT_IN_CABSF' or `BUILT_IN_CABSL' builtins, as used to 5625 implement the C99 `cabs', `cabsf' and `cabsl' built-in functions. 5626 5627 `BIT_NOT_EXPR' 5628 These nodes represent bitwise complement, and will always have 5629 integral type. The only operand is the value to be complemented. 5630 5631 `TRUTH_NOT_EXPR' 5632 These nodes represent logical negation, and will always have 5633 integral (or boolean) type. The operand is the value being 5634 negated. The type of the operand and that of the result are 5635 always of `BOOLEAN_TYPE' or `INTEGER_TYPE'. 5636 5637 `PREDECREMENT_EXPR' 5638 `PREINCREMENT_EXPR' 5639 `POSTDECREMENT_EXPR' 5640 `POSTINCREMENT_EXPR' 5641 These nodes represent increment and decrement expressions. The 5642 value of the single operand is computed, and the operand 5643 incremented or decremented. In the case of `PREDECREMENT_EXPR' and 5644 `PREINCREMENT_EXPR', the value of the expression is the value 5645 resulting after the increment or decrement; in the case of 5646 `POSTDECREMENT_EXPR' and `POSTINCREMENT_EXPR' is the value before 5647 the increment or decrement occurs. The type of the operand, like 5648 that of the result, will be either integral, boolean, or 5649 floating-point. 5650 5651 `ADDR_EXPR' 5652 These nodes are used to represent the address of an object. (These 5653 expressions will always have pointer or reference type.) The 5654 operand may be another expression, or it may be a declaration. 5655 5656 As an extension, GCC allows users to take the address of a label. 5657 In this case, the operand of the `ADDR_EXPR' will be a 5658 `LABEL_DECL'. The type of such an expression is `void*'. 5659 5660 If the object addressed is not an lvalue, a temporary is created, 5661 and the address of the temporary is used. 5662 5663 `INDIRECT_REF' 5664 These nodes are used to represent the object pointed to by a 5665 pointer. The operand is the pointer being dereferenced; it will 5666 always have pointer or reference type. 5667 5668 `FIX_TRUNC_EXPR' 5669 These nodes represent conversion of a floating-point value to an 5670 integer. The single operand will have a floating-point type, while 5671 the complete expression will have an integral (or boolean) type. 5672 The operand is rounded towards zero. 5673 5674 `FLOAT_EXPR' 5675 These nodes represent conversion of an integral (or boolean) value 5676 to a floating-point value. The single operand will have integral 5677 type, while the complete expression will have a floating-point 5678 type. 5679 5680 FIXME: How is the operand supposed to be rounded? Is this 5681 dependent on `-mieee'? 5682 5683 `COMPLEX_EXPR' 5684 These nodes are used to represent complex numbers constructed from 5685 two expressions of the same (integer or real) type. The first 5686 operand is the real part and the second operand is the imaginary 5687 part. 5688 5689 `CONJ_EXPR' 5690 These nodes represent the conjugate of their operand. 5691 5692 `REALPART_EXPR' 5693 `IMAGPART_EXPR' 5694 These nodes represent respectively the real and the imaginary parts 5695 of complex numbers (their sole argument). 5696 5697 `NON_LVALUE_EXPR' 5698 These nodes indicate that their one and only operand is not an 5699 lvalue. A back end can treat these identically to the single 5700 operand. 5701 5702 `NOP_EXPR' 5703 These nodes are used to represent conversions that do not require 5704 any code-generation. For example, conversion of a `char*' to an 5705 `int*' does not require any code be generated; such a conversion is 5706 represented by a `NOP_EXPR'. The single operand is the expression 5707 to be converted. The conversion from a pointer to a reference is 5708 also represented with a `NOP_EXPR'. 5709 5710 `CONVERT_EXPR' 5711 These nodes are similar to `NOP_EXPR's, but are used in those 5712 situations where code may need to be generated. For example, if an 5713 `int*' is converted to an `int' code may need to be generated on 5714 some platforms. These nodes are never used for C++-specific 5715 conversions, like conversions between pointers to different 5716 classes in an inheritance hierarchy. Any adjustments that need to 5717 be made in such cases are always indicated explicitly. Similarly, 5718 a user-defined conversion is never represented by a 5719 `CONVERT_EXPR'; instead, the function calls are made explicit. 5720 5721 `THROW_EXPR' 5722 These nodes represent `throw' expressions. The single operand is 5723 an expression for the code that should be executed to throw the 5724 exception. However, there is one implicit action not represented 5725 in that expression; namely the call to `__throw'. This function 5726 takes no arguments. If `setjmp'/`longjmp' exceptions are used, the 5727 function `__sjthrow' is called instead. The normal GCC back end 5728 uses the function `emit_throw' to generate this code; you can 5729 examine this function to see what needs to be done. 5730 5731 `LSHIFT_EXPR' 5732 `RSHIFT_EXPR' 5733 These nodes represent left and right shifts, respectively. The 5734 first operand is the value to shift; it will always be of integral 5735 type. The second operand is an expression for the number of bits 5736 by which to shift. Right shift should be treated as arithmetic, 5737 i.e., the high-order bits should be zero-filled when the 5738 expression has unsigned type and filled with the sign bit when the 5739 expression has signed type. Note that the result is undefined if 5740 the second operand is larger than or equal to the first operand's 5741 type size. 5742 5743 `BIT_IOR_EXPR' 5744 `BIT_XOR_EXPR' 5745 `BIT_AND_EXPR' 5746 These nodes represent bitwise inclusive or, bitwise exclusive or, 5747 and bitwise and, respectively. Both operands will always have 5748 integral type. 5749 5750 `TRUTH_ANDIF_EXPR' 5751 `TRUTH_ORIF_EXPR' 5752 These nodes represent logical and and logical or, respectively. 5753 These operators are not strict; i.e., the second operand is 5754 evaluated only if the value of the expression is not determined by 5755 evaluation of the first operand. The type of the operands and 5756 that of the result are always of `BOOLEAN_TYPE' or `INTEGER_TYPE'. 5757 5758 `TRUTH_AND_EXPR' 5759 `TRUTH_OR_EXPR' 5760 `TRUTH_XOR_EXPR' 5761 These nodes represent logical and, logical or, and logical 5762 exclusive or. They are strict; both arguments are always 5763 evaluated. There are no corresponding operators in C or C++, but 5764 the front end will sometimes generate these expressions anyhow, if 5765 it can tell that strictness does not matter. The type of the 5766 operands and that of the result are always of `BOOLEAN_TYPE' or 5767 `INTEGER_TYPE'. 5768 5769 `PLUS_EXPR' 5770 `MINUS_EXPR' 5771 `MULT_EXPR' 5772 These nodes represent various binary arithmetic operations. 5773 Respectively, these operations are addition, subtraction (of the 5774 second operand from the first) and multiplication. Their operands 5775 may have either integral or floating type, but there will never be 5776 case in which one operand is of floating type and the other is of 5777 integral type. 5778 5779 The behavior of these operations on signed arithmetic overflow is 5780 controlled by the `flag_wrapv' and `flag_trapv' variables. 5781 5782 `RDIV_EXPR' 5783 This node represents a floating point division operation. 5784 5785 `TRUNC_DIV_EXPR' 5786 `FLOOR_DIV_EXPR' 5787 `CEIL_DIV_EXPR' 5788 `ROUND_DIV_EXPR' 5789 These nodes represent integer division operations that return an 5790 integer result. `TRUNC_DIV_EXPR' rounds towards zero, 5791 `FLOOR_DIV_EXPR' rounds towards negative infinity, `CEIL_DIV_EXPR' 5792 rounds towards positive infinity and `ROUND_DIV_EXPR' rounds to 5793 the closest integer. Integer division in C and C++ is truncating, 5794 i.e. `TRUNC_DIV_EXPR'. 5795 5796 The behavior of these operations on signed arithmetic overflow, 5797 when dividing the minimum signed integer by minus one, is 5798 controlled by the `flag_wrapv' and `flag_trapv' variables. 5799 5800 `TRUNC_MOD_EXPR' 5801 `FLOOR_MOD_EXPR' 5802 `CEIL_MOD_EXPR' 5803 `ROUND_MOD_EXPR' 5804 These nodes represent the integer remainder or modulus operation. 5805 The integer modulus of two operands `a' and `b' is defined as `a - 5806 (a/b)*b' where the division calculated using the corresponding 5807 division operator. Hence for `TRUNC_MOD_EXPR' this definition 5808 assumes division using truncation towards zero, i.e. 5809 `TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating 5810 division, i.e. `TRUNC_MOD_EXPR'. 5811 5812 `EXACT_DIV_EXPR' 5813 The `EXACT_DIV_EXPR' code is used to represent integer divisions 5814 where the numerator is known to be an exact multiple of the 5815 denominator. This allows the backend to choose between the faster 5816 of `TRUNC_DIV_EXPR', `CEIL_DIV_EXPR' and `FLOOR_DIV_EXPR' for the 5817 current target. 5818 5819 `ARRAY_REF' 5820 These nodes represent array accesses. The first operand is the 5821 array; the second is the index. To calculate the address of the 5822 memory accessed, you must scale the index by the size of the type 5823 of the array elements. The type of these expressions must be the 5824 type of a component of the array. The third and fourth operands 5825 are used after gimplification to represent the lower bound and 5826 component size but should not be used directly; call 5827 `array_ref_low_bound' and `array_ref_element_size' instead. 5828 5829 `ARRAY_RANGE_REF' 5830 These nodes represent access to a range (or "slice") of an array. 5831 The operands are the same as that for `ARRAY_REF' and have the same 5832 meanings. The type of these expressions must be an array whose 5833 component type is the same as that of the first operand. The 5834 range of that array type determines the amount of data these 5835 expressions access. 5836 5837 `TARGET_MEM_REF' 5838 These nodes represent memory accesses whose address directly map to 5839 an addressing mode of the target architecture. The first argument 5840 is `TMR_SYMBOL' and must be a `VAR_DECL' of an object with a fixed 5841 address. The second argument is `TMR_BASE' and the third one is 5842 `TMR_INDEX'. The fourth argument is `TMR_STEP' and must be an 5843 `INTEGER_CST'. The fifth argument is `TMR_OFFSET' and must be an 5844 `INTEGER_CST'. Any of the arguments may be NULL if the 5845 appropriate component does not appear in the address. Address of 5846 the `TARGET_MEM_REF' is determined in the following way. 5847 5848 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET 5849 5850 The sixth argument is the reference to the original memory access, 5851 which is preserved for the purposes of the RTL alias analysis. 5852 The seventh argument is a tag representing the results of tree 5853 level alias analysis. 5854 5855 `LT_EXPR' 5856 `LE_EXPR' 5857 `GT_EXPR' 5858 `GE_EXPR' 5859 `EQ_EXPR' 5860 `NE_EXPR' 5861 These nodes represent the less than, less than or equal to, greater 5862 than, greater than or equal to, equal, and not equal comparison 5863 operators. The first and second operand with either be both of 5864 integral type or both of floating type. The result type of these 5865 expressions will always be of integral or boolean type. These 5866 operations return the result type's zero value for false, and the 5867 result type's one value for true. 5868 5869 For floating point comparisons, if we honor IEEE NaNs and either 5870 operand is NaN, then `NE_EXPR' always returns true and the 5871 remaining operators always return false. On some targets, 5872 comparisons against an IEEE NaN, other than equality and 5873 inequality, may generate a floating point exception. 5874 5875 `ORDERED_EXPR' 5876 `UNORDERED_EXPR' 5877 These nodes represent non-trapping ordered and unordered comparison 5878 operators. These operations take two floating point operands and 5879 determine whether they are ordered or unordered relative to each 5880 other. If either operand is an IEEE NaN, their comparison is 5881 defined to be unordered, otherwise the comparison is defined to be 5882 ordered. The result type of these expressions will always be of 5883 integral or boolean type. These operations return the result 5884 type's zero value for false, and the result type's one value for 5885 true. 5886 5887 `UNLT_EXPR' 5888 `UNLE_EXPR' 5889 `UNGT_EXPR' 5890 `UNGE_EXPR' 5891 `UNEQ_EXPR' 5892 `LTGT_EXPR' 5893 These nodes represent the unordered comparison operators. These 5894 operations take two floating point operands and determine whether 5895 the operands are unordered or are less than, less than or equal to, 5896 greater than, greater than or equal to, or equal respectively. For 5897 example, `UNLT_EXPR' returns true if either operand is an IEEE NaN 5898 or the first operand is less than the second. With the possible 5899 exception of `LTGT_EXPR', all of these operations are guaranteed 5900 not to generate a floating point exception. The result type of 5901 these expressions will always be of integral or boolean type. 5902 These operations return the result type's zero value for false, 5903 and the result type's one value for true. 5904 5905 `MODIFY_EXPR' 5906 These nodes represent assignment. The left-hand side is the first 5907 operand; the right-hand side is the second operand. The left-hand 5908 side will be a `VAR_DECL', `INDIRECT_REF', `COMPONENT_REF', or 5909 other lvalue. 5910 5911 These nodes are used to represent not only assignment with `=' but 5912 also compound assignments (like `+='), by reduction to `=' 5913 assignment. In other words, the representation for `i += 3' looks 5914 just like that for `i = i + 3'. 5915 5916 `INIT_EXPR' 5917 These nodes are just like `MODIFY_EXPR', but are used only when a 5918 variable is initialized, rather than assigned to subsequently. 5919 This means that we can assume that the target of the 5920 initialization is not used in computing its own value; any 5921 reference to the lhs in computing the rhs is undefined. 5922 5923 `COMPONENT_REF' 5924 These nodes represent non-static data member accesses. The first 5925 operand is the object (rather than a pointer to it); the second 5926 operand is the `FIELD_DECL' for the data member. The third 5927 operand represents the byte offset of the field, but should not be 5928 used directly; call `component_ref_field_offset' instead. 5929 5930 `COMPOUND_EXPR' 5931 These nodes represent comma-expressions. The first operand is an 5932 expression whose value is computed and thrown away prior to the 5933 evaluation of the second operand. The value of the entire 5934 expression is the value of the second operand. 5935 5936 `COND_EXPR' 5937 These nodes represent `?:' expressions. The first operand is of 5938 boolean or integral type. If it evaluates to a nonzero value, the 5939 second operand should be evaluated, and returned as the value of 5940 the expression. Otherwise, the third operand is evaluated, and 5941 returned as the value of the expression. 5942 5943 The second operand must have the same type as the entire 5944 expression, unless it unconditionally throws an exception or calls 5945 a noreturn function, in which case it should have void type. The 5946 same constraints apply to the third operand. This allows array 5947 bounds checks to be represented conveniently as `(i >= 0 && i < 5948 10) ? i : abort()'. 5949 5950 As a GNU extension, the C language front-ends allow the second 5951 operand of the `?:' operator may be omitted in the source. For 5952 example, `x ? : 3' is equivalent to `x ? x : 3', assuming that `x' 5953 is an expression without side-effects. In the tree 5954 representation, however, the second operand is always present, 5955 possibly protected by `SAVE_EXPR' if the first argument does cause 5956 side-effects. 5957 5958 `CALL_EXPR' 5959 These nodes are used to represent calls to functions, including 5960 non-static member functions. The first operand is a pointer to the 5961 function to call; it is always an expression whose type is a 5962 `POINTER_TYPE'. The second argument is a `TREE_LIST'. The 5963 arguments to the call appear left-to-right in the list. The 5964 `TREE_VALUE' of each list node contains the expression 5965 corresponding to that argument. (The value of `TREE_PURPOSE' for 5966 these nodes is unspecified, and should be ignored.) For non-static 5967 member functions, there will be an operand corresponding to the 5968 `this' pointer. There will always be expressions corresponding to 5969 all of the arguments, even if the function is declared with default 5970 arguments and some arguments are not explicitly provided at the 5971 call sites. 5972 5973 `STMT_EXPR' 5974 These nodes are used to represent GCC's statement-expression 5975 extension. The statement-expression extension allows code like 5976 this: 5977 int f() { return ({ int j; j = 3; j + 7; }); } 5978 In other words, an sequence of statements may occur where a single 5979 expression would normally appear. The `STMT_EXPR' node represents 5980 such an expression. The `STMT_EXPR_STMT' gives the statement 5981 contained in the expression. The value of the expression is the 5982 value of the last sub-statement in the body. More precisely, the 5983 value is the value computed by the last statement nested inside 5984 `BIND_EXPR', `TRY_FINALLY_EXPR', or `TRY_CATCH_EXPR'. For 5985 example, in: 5986 ({ 3; }) 5987 the value is `3' while in: 5988 ({ if (x) { 3; } }) 5989 there is no value. If the `STMT_EXPR' does not yield a value, 5990 it's type will be `void'. 5991 5992 `BIND_EXPR' 5993 These nodes represent local blocks. The first operand is a list of 5994 variables, connected via their `TREE_CHAIN' field. These will 5995 never require cleanups. The scope of these variables is just the 5996 body of the `BIND_EXPR'. The body of the `BIND_EXPR' is the 5997 second operand. 5998 5999 `LOOP_EXPR' 6000 These nodes represent "infinite" loops. The `LOOP_EXPR_BODY' 6001 represents the body of the loop. It should be executed forever, 6002 unless an `EXIT_EXPR' is encountered. 6003 6004 `EXIT_EXPR' 6005 These nodes represent conditional exits from the nearest enclosing 6006 `LOOP_EXPR'. The single operand is the condition; if it is 6007 nonzero, then the loop should be exited. An `EXIT_EXPR' will only 6008 appear within a `LOOP_EXPR'. 6009 6010 `CLEANUP_POINT_EXPR' 6011 These nodes represent full-expressions. The single operand is an 6012 expression to evaluate. Any destructor calls engendered by the 6013 creation of temporaries during the evaluation of that expression 6014 should be performed immediately after the expression is evaluated. 6015 6016 `CONSTRUCTOR' 6017 These nodes represent the brace-enclosed initializers for a 6018 structure or array. The first operand is reserved for use by the 6019 back end. The second operand is a `TREE_LIST'. If the 6020 `TREE_TYPE' of the `CONSTRUCTOR' is a `RECORD_TYPE' or 6021 `UNION_TYPE', then the `TREE_PURPOSE' of each node in the 6022 `TREE_LIST' will be a `FIELD_DECL' and the `TREE_VALUE' of each 6023 node will be the expression used to initialize that field. 6024 6025 If the `TREE_TYPE' of the `CONSTRUCTOR' is an `ARRAY_TYPE', then 6026 the `TREE_PURPOSE' of each element in the `TREE_LIST' will be an 6027 `INTEGER_CST' or a `RANGE_EXPR' of two `INTEGER_CST's. A single 6028 `INTEGER_CST' indicates which element of the array (indexed from 6029 zero) is being assigned to. A `RANGE_EXPR' indicates an inclusive 6030 range of elements to initialize. In both cases the `TREE_VALUE' 6031 is the corresponding initializer. It is re-evaluated for each 6032 element of a `RANGE_EXPR'. If the `TREE_PURPOSE' is `NULL_TREE', 6033 then the initializer is for the next available array element. 6034 6035 In the front end, you should not depend on the fields appearing in 6036 any particular order. However, in the middle end, fields must 6037 appear in declaration order. You should not assume that all 6038 fields will be represented. Unrepresented fields will be set to 6039 zero. 6040 6041 `COMPOUND_LITERAL_EXPR' 6042 These nodes represent ISO C99 compound literals. The 6043 `COMPOUND_LITERAL_EXPR_DECL_STMT' is a `DECL_STMT' containing an 6044 anonymous `VAR_DECL' for the unnamed object represented by the 6045 compound literal; the `DECL_INITIAL' of that `VAR_DECL' is a 6046 `CONSTRUCTOR' representing the brace-enclosed list of initializers 6047 in the compound literal. That anonymous `VAR_DECL' can also be 6048 accessed directly by the `COMPOUND_LITERAL_EXPR_DECL' macro. 6049 6050 `SAVE_EXPR' 6051 A `SAVE_EXPR' represents an expression (possibly involving 6052 side-effects) that is used more than once. The side-effects should 6053 occur only the first time the expression is evaluated. Subsequent 6054 uses should just reuse the computed value. The first operand to 6055 the `SAVE_EXPR' is the expression to evaluate. The side-effects 6056 should be executed where the `SAVE_EXPR' is first encountered in a 6057 depth-first preorder traversal of the expression tree. 6058 6059 `TARGET_EXPR' 6060 A `TARGET_EXPR' represents a temporary object. The first operand 6061 is a `VAR_DECL' for the temporary variable. The second operand is 6062 the initializer for the temporary. The initializer is evaluated 6063 and, if non-void, copied (bitwise) into the temporary. If the 6064 initializer is void, that means that it will perform the 6065 initialization itself. 6066 6067 Often, a `TARGET_EXPR' occurs on the right-hand side of an 6068 assignment, or as the second operand to a comma-expression which is 6069 itself the right-hand side of an assignment, etc. In this case, 6070 we say that the `TARGET_EXPR' is "normal"; otherwise, we say it is 6071 "orphaned". For a normal `TARGET_EXPR' the temporary variable 6072 should be treated as an alias for the left-hand side of the 6073 assignment, rather than as a new temporary variable. 6074 6075 The third operand to the `TARGET_EXPR', if present, is a 6076 cleanup-expression (i.e., destructor call) for the temporary. If 6077 this expression is orphaned, then this expression must be executed 6078 when the statement containing this expression is complete. These 6079 cleanups must always be executed in the order opposite to that in 6080 which they were encountered. Note that if a temporary is created 6081 on one branch of a conditional operator (i.e., in the second or 6082 third operand to a `COND_EXPR'), the cleanup must be run only if 6083 that branch is actually executed. 6084 6085 See `STMT_IS_FULL_EXPR_P' for more information about running these 6086 cleanups. 6087 6088 `AGGR_INIT_EXPR' 6089 An `AGGR_INIT_EXPR' represents the initialization as the return 6090 value of a function call, or as the result of a constructor. An 6091 `AGGR_INIT_EXPR' will only appear as a full-expression, or as the 6092 second operand of a `TARGET_EXPR'. The first operand to the 6093 `AGGR_INIT_EXPR' is the address of a function to call, just as in 6094 a `CALL_EXPR'. The second operand are the arguments to pass that 6095 function, as a `TREE_LIST', again in a manner similar to that of a 6096 `CALL_EXPR'. 6097 6098 If `AGGR_INIT_VIA_CTOR_P' holds of the `AGGR_INIT_EXPR', then the 6099 initialization is via a constructor call. The address of the third 6100 operand of the `AGGR_INIT_EXPR', which is always a `VAR_DECL', is 6101 taken, and this value replaces the first argument in the argument 6102 list. 6103 6104 In either case, the expression is void. 6105 6106 `VA_ARG_EXPR' 6107 This node is used to implement support for the C/C++ variable 6108 argument-list mechanism. It represents expressions like `va_arg 6109 (ap, type)'. Its `TREE_TYPE' yields the tree representation for 6110 `type' and its sole argument yields the representation for `ap'. 6111 6112 `OMP_PARALLEL' 6113 Represents `#pragma omp parallel [clause1 ... clauseN]'. It has 6114 four operands: 6115 6116 Operand `OMP_PARALLEL_BODY' is valid while in GENERIC and High 6117 GIMPLE forms. It contains the body of code to be executed by all 6118 the threads. During GIMPLE lowering, this operand becomes `NULL' 6119 and the body is emitted linearly after `OMP_PARALLEL'. 6120 6121 Operand `OMP_PARALLEL_CLAUSES' is the list of clauses associated 6122 with the directive. 6123 6124 Operand `OMP_PARALLEL_FN' is created by `pass_lower_omp', it 6125 contains the `FUNCTION_DECL' for the function that will contain 6126 the body of the parallel region. 6127 6128 Operand `OMP_PARALLEL_DATA_ARG' is also created by 6129 `pass_lower_omp'. If there are shared variables to be communicated 6130 to the children threads, this operand will contain the `VAR_DECL' 6131 that contains all the shared values and variables. 6132 6133 `OMP_FOR' 6134 Represents `#pragma omp for [clause1 ... clauseN]'. It has 5 6135 operands: 6136 6137 Operand `OMP_FOR_BODY' contains the loop body. 6138 6139 Operand `OMP_FOR_CLAUSES' is the list of clauses associated with 6140 the directive. 6141 6142 Operand `OMP_FOR_INIT' is the loop initialization code of the form 6143 `VAR = N1'. 6144 6145 Operand `OMP_FOR_COND' is the loop conditional expression of the 6146 form `VAR {<,>,<=,>=} N2'. 6147 6148 Operand `OMP_FOR_INCR' is the loop index increment of the form 6149 `VAR {+=,-=} INCR'. 6150 6151 Operand `OMP_FOR_PRE_BODY' contains side-effect code from operands 6152 `OMP_FOR_INIT', `OMP_FOR_COND' and `OMP_FOR_INC'. These 6153 side-effects are part of the `OMP_FOR' block but must be evaluated 6154 before the start of loop body. 6155 6156 The loop index variable `VAR' must be a signed integer variable, 6157 which is implicitly private to each thread. Bounds `N1' and `N2' 6158 and the increment expression `INCR' are required to be loop 6159 invariant integer expressions that are evaluated without any 6160 synchronization. The evaluation order, frequency of evaluation and 6161 side-effects are unspecified by the standard. 6162 6163 `OMP_SECTIONS' 6164 Represents `#pragma omp sections [clause1 ... clauseN]'. 6165 6166 Operand `OMP_SECTIONS_BODY' contains the sections body, which in 6167 turn contains a set of `OMP_SECTION' nodes for each of the 6168 concurrent sections delimited by `#pragma omp section'. 6169 6170 Operand `OMP_SECTIONS_CLAUSES' is the list of clauses associated 6171 with the directive. 6172 6173 `OMP_SECTION' 6174 Section delimiter for `OMP_SECTIONS'. 6175 6176 `OMP_SINGLE' 6177 Represents `#pragma omp single'. 6178 6179 Operand `OMP_SINGLE_BODY' contains the body of code to be executed 6180 by a single thread. 6181 6182 Operand `OMP_SINGLE_CLAUSES' is the list of clauses associated 6183 with the directive. 6184 6185 `OMP_MASTER' 6186 Represents `#pragma omp master'. 6187 6188 Operand `OMP_MASTER_BODY' contains the body of code to be executed 6189 by the master thread. 6190 6191 `OMP_ORDERED' 6192 Represents `#pragma omp ordered'. 6193 6194 Operand `OMP_ORDERED_BODY' contains the body of code to be 6195 executed in the sequential order dictated by the loop index 6196 variable. 6197 6198 `OMP_CRITICAL' 6199 Represents `#pragma omp critical [name]'. 6200 6201 Operand `OMP_CRITICAL_BODY' is the critical section. 6202 6203 Operand `OMP_CRITICAL_NAME' is an optional identifier to label the 6204 critical section. 6205 6206 `OMP_RETURN' 6207 This does not represent any OpenMP directive, it is an artificial 6208 marker to indicate the end of the body of an OpenMP. It is used by 6209 the flow graph (`tree-cfg.c') and OpenMP region building code 6210 (`omp-low.c'). 6211 6212 `OMP_CONTINUE' 6213 Similarly, this instruction does not represent an OpenMP 6214 directive, it is used by `OMP_FOR' and `OMP_SECTIONS' to mark the 6215 place where the code needs to loop to the next iteration (in the 6216 case of `OMP_FOR') or the next section (in the case of 6217 `OMP_SECTIONS'). 6218 6219 In some cases, `OMP_CONTINUE' is placed right before `OMP_RETURN'. 6220 But if there are cleanups that need to occur right after the 6221 looping body, it will be emitted between `OMP_CONTINUE' and 6222 `OMP_RETURN'. 6223 6224 `OMP_ATOMIC' 6225 Represents `#pragma omp atomic'. 6226 6227 Operand 0 is the address at which the atomic operation is to be 6228 performed. 6229 6230 Operand 1 is the expression to evaluate. The gimplifier tries 6231 three alternative code generation strategies. Whenever possible, 6232 an atomic update built-in is used. If that fails, a 6233 compare-and-swap loop is attempted. If that also fails, a regular 6234 critical section around the expression is used. 6235 6236 `OMP_CLAUSE' 6237 Represents clauses associated with one of the `OMP_' directives. 6238 Clauses are represented by separate sub-codes defined in `tree.h'. 6239 Clauses codes can be one of: `OMP_CLAUSE_PRIVATE', 6240 `OMP_CLAUSE_SHARED', `OMP_CLAUSE_FIRSTPRIVATE', 6241 `OMP_CLAUSE_LASTPRIVATE', `OMP_CLAUSE_COPYIN', 6242 `OMP_CLAUSE_COPYPRIVATE', `OMP_CLAUSE_IF', 6243 `OMP_CLAUSE_NUM_THREADS', `OMP_CLAUSE_SCHEDULE', 6244 `OMP_CLAUSE_NOWAIT', `OMP_CLAUSE_ORDERED', `OMP_CLAUSE_DEFAULT', 6245 and `OMP_CLAUSE_REDUCTION'. Each code represents the 6246 corresponding OpenMP clause. 6247 6248 Clauses associated with the same directive are chained together 6249 via `OMP_CLAUSE_CHAIN'. Those clauses that accept a list of 6250 variables are restricted to exactly one, accessed with 6251 `OMP_CLAUSE_VAR'. Therefore, multiple variables under the same 6252 clause `C' need to be represented as multiple `C' clauses chained 6253 together. This facilitates adding new clauses during compilation. 6254 6255 6256 6257 File: gccint.info, Node: Tree SSA, Next: Loop Analysis and Representation, Prev: Control Flow, Up: Top 6258 6259 10 Analysis and Optimization of GIMPLE Trees 6260 ******************************************** 6261 6262 GCC uses three main intermediate languages to represent the program 6263 during compilation: GENERIC, GIMPLE and RTL. GENERIC is a 6264 language-independent representation generated by each front end. It is 6265 used to serve as an interface between the parser and optimizer. 6266 GENERIC is a common representation that is able to represent programs 6267 written in all the languages supported by GCC. 6268 6269 GIMPLE and RTL are used to optimize the program. GIMPLE is used for 6270 target and language independent optimizations (e.g., inlining, constant 6271 propagation, tail call elimination, redundancy elimination, etc). Much 6272 like GENERIC, GIMPLE is a language independent, tree based 6273 representation. However, it differs from GENERIC in that the GIMPLE 6274 grammar is more restrictive: expressions contain no more than 3 6275 operands (except function calls), it has no control flow structures and 6276 expressions with side-effects are only allowed on the right hand side 6277 of assignments. See the chapter describing GENERIC and GIMPLE for more 6278 details. 6279 6280 This chapter describes the data structures and functions used in the 6281 GIMPLE optimizers (also known as "tree optimizers" or "middle end"). 6282 In particular, it focuses on all the macros, data structures, functions 6283 and programming constructs needed to implement optimization passes for 6284 GIMPLE. 6285 6286 * Menu: 6287 6288 * GENERIC:: A high-level language-independent representation. 6289 * GIMPLE:: A lower-level factored tree representation. 6290 * Annotations:: Attributes for statements and variables. 6291 * Statement Operands:: Variables referenced by GIMPLE statements. 6292 * SSA:: Static Single Assignment representation. 6293 * Alias analysis:: Representing aliased loads and stores. 6294 6295 6296 File: gccint.info, Node: GENERIC, Next: GIMPLE, Up: Tree SSA 6297 6298 10.1 GENERIC 6299 ============ 6300 6301 The purpose of GENERIC is simply to provide a language-independent way 6302 of representing an entire function in trees. To this end, it was 6303 necessary to add a few new tree codes to the back end, but most 6304 everything was already there. If you can express it with the codes in 6305 `gcc/tree.def', it's GENERIC. 6306 6307 Early on, there was a great deal of debate about how to think about 6308 statements in a tree IL. In GENERIC, a statement is defined as any 6309 expression whose value, if any, is ignored. A statement will always 6310 have `TREE_SIDE_EFFECTS' set (or it will be discarded), but a 6311 non-statement expression may also have side effects. A `CALL_EXPR', 6312 for instance. 6313 6314 It would be possible for some local optimizations to work on the 6315 GENERIC form of a function; indeed, the adapted tree inliner works fine 6316 on GENERIC, but the current compiler performs inlining after lowering 6317 to GIMPLE (a restricted form described in the next section). Indeed, 6318 currently the frontends perform this lowering before handing off to 6319 `tree_rest_of_compilation', but this seems inelegant. 6320 6321 If necessary, a front end can use some language-dependent tree codes 6322 in its GENERIC representation, so long as it provides a hook for 6323 converting them to GIMPLE and doesn't expect them to work with any 6324 (hypothetical) optimizers that run before the conversion to GIMPLE. 6325 The intermediate representation used while parsing C and C++ looks very 6326 little like GENERIC, but the C and C++ gimplifier hooks are perfectly 6327 happy to take it as input and spit out GIMPLE. 6328 6329 6330 File: gccint.info, Node: GIMPLE, Next: Annotations, Prev: GENERIC, Up: Tree SSA 6331 6332 10.2 GIMPLE 6333 =========== 6334 6335 GIMPLE is a simplified subset of GENERIC for use in optimization. The 6336 particular subset chosen (and the name) was heavily influenced by the 6337 SIMPLE IL used by the McCAT compiler project at McGill University, 6338 though we have made some different choices. For one thing, SIMPLE 6339 doesn't support `goto'; a production compiler can't afford that kind of 6340 restriction. 6341 6342 GIMPLE retains much of the structure of the parse trees: lexical 6343 scopes are represented as containers, rather than markers. However, 6344 expressions are broken down into a 3-address form, using temporary 6345 variables to hold intermediate values. Also, control structures are 6346 lowered to gotos. 6347 6348 In GIMPLE no container node is ever used for its value; if a 6349 `COND_EXPR' or `BIND_EXPR' has a value, it is stored into a temporary 6350 within the controlled blocks, and that temporary is used in place of 6351 the container. 6352 6353 The compiler pass which lowers GENERIC to GIMPLE is referred to as the 6354 `gimplifier'. The gimplifier works recursively, replacing complex 6355 statements with sequences of simple statements. 6356 6357 * Menu: 6358 6359 * Interfaces:: 6360 * Temporaries:: 6361 * GIMPLE Expressions:: 6362 * Statements:: 6363 * GIMPLE Example:: 6364 * Rough GIMPLE Grammar:: 6365 6366 6367 File: gccint.info, Node: Interfaces, Next: Temporaries, Up: GIMPLE 6368 6369 10.2.1 Interfaces 6370 ----------------- 6371 6372 The tree representation of a function is stored in `DECL_SAVED_TREE'. 6373 It is lowered to GIMPLE by a call to `gimplify_function_tree'. 6374 6375 If a front end wants to include language-specific tree codes in the 6376 tree representation which it provides to the back end, it must provide a 6377 definition of `LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the 6378 front end trees to GIMPLE. Usually such a hook will involve much of 6379 the same code for expanding front end trees to RTL. This function can 6380 return fully lowered GIMPLE, or it can return GENERIC trees and let the 6381 main gimplifier lower them the rest of the way; this is often simpler. 6382 GIMPLE that is not fully lowered is known as "high GIMPLE" and consists 6383 of the IL before the pass `pass_lower_cf'. High GIMPLE still contains 6384 lexical scopes and nested expressions, while low GIMPLE exposes all of 6385 the implicit jumps for control expressions like `COND_EXPR'. 6386 6387 The C and C++ front ends currently convert directly from front end 6388 trees to GIMPLE, and hand that off to the back end rather than first 6389 converting to GENERIC. Their gimplifier hooks know about all the 6390 `_STMT' nodes and how to convert them to GENERIC forms. There was some 6391 work done on a genericization pass which would run first, but the 6392 existence of `STMT_EXPR' meant that in order to convert all of the C 6393 statements into GENERIC equivalents would involve walking the entire 6394 tree anyway, so it was simpler to lower all the way. This might change 6395 in the future if someone writes an optimization pass which would work 6396 better with higher-level trees, but currently the optimizers all expect 6397 GIMPLE. 6398 6399 A front end which wants to use the tree optimizers (and already has 6400 some sort of whole-function tree representation) only needs to provide 6401 a definition of `LANG_HOOKS_GIMPLIFY_EXPR', call 6402 `gimplify_function_tree' to lower to GIMPLE, and then hand off to 6403 `tree_rest_of_compilation' to compile and output the function. 6404 6405 You can tell the compiler to dump a C-like representation of the GIMPLE 6406 form with the flag `-fdump-tree-gimple'. 6407 6408 6409 File: gccint.info, Node: Temporaries, Next: GIMPLE Expressions, Prev: Interfaces, Up: GIMPLE 6410 6411 10.2.2 Temporaries 6412 ------------------ 6413 6414 When gimplification encounters a subexpression which is too complex, it 6415 creates a new temporary variable to hold the value of the subexpression, 6416 and adds a new statement to initialize it before the current statement. 6417 These special temporaries are known as `expression temporaries', and are 6418 allocated using `get_formal_tmp_var'. The compiler tries to always 6419 evaluate identical expressions into the same temporary, to simplify 6420 elimination of redundant calculations. 6421 6422 We can only use expression temporaries when we know that it will not be 6423 reevaluated before its value is used, and that it will not be otherwise 6424 modified(1). Other temporaries can be allocated using 6425 `get_initialized_tmp_var' or `create_tmp_var'. 6426 6427 Currently, an expression like `a = b + 5' is not reduced any further. 6428 We tried converting it to something like 6429 T1 = b + 5; 6430 a = T1; 6431 but this bloated the representation for minimal benefit. However, a 6432 variable which must live in memory cannot appear in an expression; its 6433 value is explicitly loaded into a temporary first. Similarly, storing 6434 the value of an expression to a memory variable goes through a 6435 temporary. 6436 6437 ---------- Footnotes ---------- 6438 6439 (1) These restrictions are derived from those in Morgan 4.8. 6440 6441 6442 File: gccint.info, Node: GIMPLE Expressions, Next: Statements, Prev: Temporaries, Up: GIMPLE 6443 6444 10.2.3 Expressions 6445 ------------------ 6446 6447 In general, expressions in GIMPLE consist of an operation and the 6448 appropriate number of simple operands; these operands must either be a 6449 GIMPLE rvalue (`is_gimple_val'), i.e. a constant or a register 6450 variable. More complex operands are factored out into temporaries, so 6451 that 6452 a = b + c + d 6453 becomes 6454 T1 = b + c; 6455 a = T1 + d; 6456 6457 The same rule holds for arguments to a `CALL_EXPR'. 6458 6459 The target of an assignment is usually a variable, but can also be an 6460 `INDIRECT_REF' or a compound lvalue as described below. 6461 6462 * Menu: 6463 6464 * Compound Expressions:: 6465 * Compound Lvalues:: 6466 * Conditional Expressions:: 6467 * Logical Operators:: 6468 6469 6470 File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: GIMPLE Expressions 6471 6472 10.2.3.1 Compound Expressions 6473 ............................. 6474 6475 The left-hand side of a C comma expression is simply moved into a 6476 separate statement. 6477 6478 6479 File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: GIMPLE Expressions 6480 6481 10.2.3.2 Compound Lvalues 6482 ......................... 6483 6484 Currently compound lvalues involving array and structure field 6485 references are not broken down; an expression like `a.b[2] = 42' is not 6486 reduced any further (though complex array subscripts are). This 6487 restriction is a workaround for limitations in later optimizers; if we 6488 were to convert this to 6489 6490 T1 = &a.b; 6491 T1[2] = 42; 6492 6493 alias analysis would not remember that the reference to `T1[2]' came 6494 by way of `a.b', so it would think that the assignment could alias 6495 another member of `a'; this broke `struct-alias-1.c'. Future optimizer 6496 improvements may make this limitation unnecessary. 6497 6498 6499 File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: GIMPLE Expressions 6500 6501 10.2.3.3 Conditional Expressions 6502 ................................ 6503 6504 A C `?:' expression is converted into an `if' statement with each 6505 branch assigning to the same temporary. So, 6506 6507 a = b ? c : d; 6508 becomes 6509 if (b) 6510 T1 = c; 6511 else 6512 T1 = d; 6513 a = T1; 6514 6515 Tree level if-conversion pass re-introduces `?:' expression, if 6516 appropriate. It is used to vectorize loops with conditions using 6517 vector conditional operations. 6518 6519 Note that in GIMPLE, `if' statements are also represented using 6520 `COND_EXPR', as described below. 6521 6522 6523 File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: GIMPLE Expressions 6524 6525 10.2.3.4 Logical Operators 6526 .......................... 6527 6528 Except when they appear in the condition operand of a `COND_EXPR', 6529 logical `and' and `or' operators are simplified as follows: `a = b && 6530 c' becomes 6531 6532 T1 = (bool)b; 6533 if (T1) 6534 T1 = (bool)c; 6535 a = T1; 6536 6537 Note that `T1' in this example cannot be an expression temporary, 6538 because it has two different assignments. 6539 6540 6541 File: gccint.info, Node: Statements, Next: GIMPLE Example, Prev: GIMPLE Expressions, Up: GIMPLE 6542 6543 10.2.4 Statements 6544 ----------------- 6545 6546 Most statements will be assignment statements, represented by 6547 `MODIFY_EXPR'. A `CALL_EXPR' whose value is ignored can also be a 6548 statement. No other C expressions can appear at statement level; a 6549 reference to a volatile object is converted into a `MODIFY_EXPR'. In 6550 GIMPLE form, type of `MODIFY_EXPR' is not meaningful. Instead, use type 6551 of LHS or RHS. 6552 6553 There are also several varieties of complex statements. 6554 6555 * Menu: 6556 6557 * Blocks:: 6558 * Statement Sequences:: 6559 * Empty Statements:: 6560 * Loops:: 6561 * Selection Statements:: 6562 * Jumps:: 6563 * Cleanups:: 6564 * GIMPLE Exception Handling:: 6565 6566 6567 File: gccint.info, Node: Blocks, Next: Statement Sequences, Up: Statements 6568 6569 10.2.4.1 Blocks 6570 ............... 6571 6572 Block scopes and the variables they declare in GENERIC and GIMPLE are 6573 expressed using the `BIND_EXPR' code, which in previous versions of GCC 6574 was primarily used for the C statement-expression extension. 6575 6576 Variables in a block are collected into `BIND_EXPR_VARS' in 6577 declaration order. Any runtime initialization is moved out of 6578 `DECL_INITIAL' and into a statement in the controlled block. When 6579 gimplifying from C or C++, this initialization replaces the `DECL_STMT'. 6580 6581 Variable-length arrays (VLAs) complicate this process, as their size 6582 often refers to variables initialized earlier in the block. To handle 6583 this, we currently split the block at that point, and move the VLA into 6584 a new, inner `BIND_EXPR'. This strategy may change in the future. 6585 6586 `DECL_SAVED_TREE' for a GIMPLE function will always be a `BIND_EXPR' 6587 which contains declarations for the temporary variables used in the 6588 function. 6589 6590 A C++ program will usually contain more `BIND_EXPR's than there are 6591 syntactic blocks in the source code, since several C++ constructs have 6592 implicit scopes associated with them. On the other hand, although the 6593 C++ front end uses pseudo-scopes to handle cleanups for objects with 6594 destructors, these don't translate into the GIMPLE form; multiple 6595 declarations at the same level use the same `BIND_EXPR'. 6596 6597 6598 File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements 6599 6600 10.2.4.2 Statement Sequences 6601 ............................ 6602 6603 Multiple statements at the same nesting level are collected into a 6604 `STATEMENT_LIST'. Statement lists are modified and traversed using the 6605 interface in `tree-iterator.h'. 6606 6607 6608 File: gccint.info, Node: Empty Statements, Next: Loops, Prev: Statement Sequences, Up: Statements 6609 6610 10.2.4.3 Empty Statements 6611 ......................... 6612 6613 Whenever possible, statements with no effect are discarded. But if they 6614 are nested within another construct which cannot be discarded for some 6615 reason, they are instead replaced with an empty statement, generated by 6616 `build_empty_stmt'. Initially, all empty statements were shared, after 6617 the pattern of the Java front end, but this caused a lot of trouble in 6618 practice. 6619 6620 An empty statement is represented as `(void)0'. 6621 6622 6623 File: gccint.info, Node: Loops, Next: Selection Statements, Prev: Empty Statements, Up: Statements 6624 6625 10.2.4.4 Loops 6626 .............. 6627 6628 At one time loops were expressed in GIMPLE using `LOOP_EXPR', but now 6629 they are lowered to explicit gotos. 6630 6631 6632 File: gccint.info, Node: Selection Statements, Next: Jumps, Prev: Loops, Up: Statements 6633 6634 10.2.4.5 Selection Statements 6635 ............................. 6636 6637 A simple selection statement, such as the C `if' statement, is 6638 expressed in GIMPLE using a void `COND_EXPR'. If only one branch is 6639 used, the other is filled with an empty statement. 6640 6641 Normally, the condition expression is reduced to a simple comparison. 6642 If it is a shortcut (`&&' or `||') expression, however, we try to break 6643 up the `if' into multiple `if's so that the implied shortcut is taken 6644 directly, much like the transformation done by `do_jump' in the RTL 6645 expander. 6646 6647 A `SWITCH_EXPR' in GIMPLE contains the condition and a `TREE_VEC' of 6648 `CASE_LABEL_EXPR's describing the case values and corresponding 6649 `LABEL_DECL's to jump to. The body of the `switch' is moved after the 6650 `SWITCH_EXPR'. 6651 6652 6653 File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Selection Statements, Up: Statements 6654 6655 10.2.4.6 Jumps 6656 .............. 6657 6658 Other jumps are expressed by either `GOTO_EXPR' or `RETURN_EXPR'. 6659 6660 The operand of a `GOTO_EXPR' must be either a label or a variable 6661 containing the address to jump to. 6662 6663 The operand of a `RETURN_EXPR' is either `NULL_TREE', `RESULT_DECL', 6664 or a `MODIFY_EXPR' which sets the return value. It would be nice to 6665 move the `MODIFY_EXPR' into a separate statement, but the special 6666 return semantics in `expand_return' make that difficult. It may still 6667 happen in the future, perhaps by moving most of that logic into 6668 `expand_assignment'. 6669 6670 6671 File: gccint.info, Node: Cleanups, Next: GIMPLE Exception Handling, Prev: Jumps, Up: Statements 6672 6673 10.2.4.7 Cleanups 6674 ................. 6675 6676 Destructors for local C++ objects and similar dynamic cleanups are 6677 represented in GIMPLE by a `TRY_FINALLY_EXPR'. `TRY_FINALLY_EXPR' has 6678 two operands, both of which are a sequence of statements to execute. 6679 The first sequence is executed. When it completes the second sequence 6680 is executed. 6681 6682 The first sequence may complete in the following ways: 6683 6684 1. Execute the last statement in the sequence and fall off the end. 6685 6686 2. Execute a goto statement (`GOTO_EXPR') to an ordinary label 6687 outside the sequence. 6688 6689 3. Execute a return statement (`RETURN_EXPR'). 6690 6691 4. Throw an exception. This is currently not explicitly represented 6692 in GIMPLE. 6693 6694 6695 The second sequence is not executed if the first sequence completes by 6696 calling `setjmp' or `exit' or any other function that does not return. 6697 The second sequence is also not executed if the first sequence 6698 completes via a non-local goto or a computed goto (in general the 6699 compiler does not know whether such a goto statement exits the first 6700 sequence or not, so we assume that it doesn't). 6701 6702 After the second sequence is executed, if it completes normally by 6703 falling off the end, execution continues wherever the first sequence 6704 would have continued, by falling off the end, or doing a goto, etc. 6705 6706 `TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs 6707 to appear on every edge out of the controlled block; this reduces the 6708 freedom to move code across these edges. Therefore, the EH lowering 6709 pass which runs before most of the optimization passes eliminates these 6710 expressions by explicitly adding the cleanup to each edge. Rethrowing 6711 the exception is represented using `RESX_EXPR'. 6712 6713 6714 File: gccint.info, Node: GIMPLE Exception Handling, Prev: Cleanups, Up: Statements 6715 6716 10.2.4.8 Exception Handling 6717 ........................... 6718 6719 Other exception handling constructs are represented using 6720 `TRY_CATCH_EXPR'. `TRY_CATCH_EXPR' has two operands. The first 6721 operand is a sequence of statements to execute. If executing these 6722 statements does not throw an exception, then the second operand is 6723 ignored. Otherwise, if an exception is thrown, then the second operand 6724 of the `TRY_CATCH_EXPR' is checked. The second operand may have the 6725 following forms: 6726 6727 1. A sequence of statements to execute. When an exception occurs, 6728 these statements are executed, and then the exception is rethrown. 6729 6730 2. A sequence of `CATCH_EXPR' expressions. Each `CATCH_EXPR' has a 6731 list of applicable exception types and handler code. If the 6732 thrown exception matches one of the caught types, the associated 6733 handler code is executed. If the handler code falls off the 6734 bottom, execution continues after the original `TRY_CATCH_EXPR'. 6735 6736 3. An `EH_FILTER_EXPR' expression. This has a list of permitted 6737 exception types, and code to handle a match failure. If the 6738 thrown exception does not match one of the allowed types, the 6739 associated match failure code is executed. If the thrown exception 6740 does match, it continues unwinding the stack looking for the next 6741 handler. 6742 6743 6744 Currently throwing an exception is not directly represented in GIMPLE, 6745 since it is implemented by calling a function. At some point in the 6746 future we will want to add some way to express that the call will throw 6747 an exception of a known type. 6748 6749 Just before running the optimizers, the compiler lowers the high-level 6750 EH constructs above into a set of `goto's, magic labels, and EH 6751 regions. Continuing to unwind at the end of a cleanup is represented 6752 with a `RESX_EXPR'. 6753 6754 6755 File: gccint.info, Node: GIMPLE Example, Next: Rough GIMPLE Grammar, Prev: Statements, Up: GIMPLE 6756 6757 10.2.5 GIMPLE Example 6758 --------------------- 6759 6760 struct A { A(); ~A(); }; 6761 6762 int i; 6763 int g(); 6764 void f() 6765 { 6766 A a; 6767 int j = (--i, i ? 0 : 1); 6768 6769 for (int x = 42; x > 0; --x) 6770 { 6771 i += g()*4 + 32; 6772 } 6773 } 6774 6775 becomes 6776 6777 void f() 6778 { 6779 int i.0; 6780 int T.1; 6781 int iftmp.2; 6782 int T.3; 6783 int T.4; 6784 int T.5; 6785 int T.6; 6786 6787 { 6788 struct A a; 6789 int j; 6790 6791 __comp_ctor (&a); 6792 try 6793 { 6794 i.0 = i; 6795 T.1 = i.0 - 1; 6796 i = T.1; 6797 i.0 = i; 6798 if (i.0 == 0) 6799 iftmp.2 = 1; 6800 else 6801 iftmp.2 = 0; 6802 j = iftmp.2; 6803 { 6804 int x; 6805 6806 x = 42; 6807 goto test; 6808 loop:; 6809 6810 T.3 = g (); 6811 T.4 = T.3 * 4; 6812 i.0 = i; 6813 T.5 = T.4 + i.0; 6814 T.6 = T.5 + 32; 6815 i = T.6; 6816 x = x - 1; 6817 6818 test:; 6819 if (x > 0) 6820 goto loop; 6821 else 6822 goto break_; 6823 break_:; 6824 } 6825 } 6826 finally 6827 { 6828 __comp_dtor (&a); 6829 } 6830 } 6831 } 6832 6833 6834 File: gccint.info, Node: Rough GIMPLE Grammar, Prev: GIMPLE Example, Up: GIMPLE 6835 6836 10.2.6 Rough GIMPLE Grammar 6837 --------------------------- 6838 6839 function : FUNCTION_DECL 6840 DECL_SAVED_TREE -> compound-stmt 6841 6842 compound-stmt: STATEMENT_LIST 6843 members -> stmt 6844 6845 stmt : block 6846 | if-stmt 6847 | switch-stmt 6848 | goto-stmt 6849 | return-stmt 6850 | resx-stmt 6851 | label-stmt 6852 | try-stmt 6853 | modify-stmt 6854 | call-stmt 6855 6856 block : BIND_EXPR 6857 BIND_EXPR_VARS -> chain of DECLs 6858 BIND_EXPR_BLOCK -> BLOCK 6859 BIND_EXPR_BODY -> compound-stmt 6860 6861 if-stmt : COND_EXPR 6862 op0 -> condition 6863 op1 -> compound-stmt 6864 op2 -> compound-stmt 6865 6866 switch-stmt : SWITCH_EXPR 6867 op0 -> val 6868 op1 -> NULL 6869 op2 -> TREE_VEC of CASE_LABEL_EXPRs 6870 The CASE_LABEL_EXPRs are sorted by CASE_LOW, 6871 and default is last. 6872 6873 goto-stmt : GOTO_EXPR 6874 op0 -> LABEL_DECL | val 6875 6876 return-stmt : RETURN_EXPR 6877 op0 -> return-value 6878 6879 return-value : NULL 6880 | RESULT_DECL 6881 | MODIFY_EXPR 6882 op0 -> RESULT_DECL 6883 op1 -> lhs 6884 6885 resx-stmt : RESX_EXPR 6886 6887 label-stmt : LABEL_EXPR 6888 op0 -> LABEL_DECL 6889 6890 try-stmt : TRY_CATCH_EXPR 6891 op0 -> compound-stmt 6892 op1 -> handler 6893 | TRY_FINALLY_EXPR 6894 op0 -> compound-stmt 6895 op1 -> compound-stmt 6896 6897 handler : catch-seq 6898 | EH_FILTER_EXPR 6899 | compound-stmt 6900 6901 catch-seq : STATEMENT_LIST 6902 members -> CATCH_EXPR 6903 6904 modify-stmt : MODIFY_EXPR 6905 op0 -> lhs 6906 op1 -> rhs 6907 6908 call-stmt : CALL_EXPR 6909 op0 -> val | OBJ_TYPE_REF 6910 op1 -> call-arg-list 6911 6912 call-arg-list: TREE_LIST 6913 members -> lhs | CONST 6914 6915 addr-expr-arg: ID 6916 | compref 6917 6918 addressable : addr-expr-arg 6919 | indirectref 6920 6921 with-size-arg: addressable 6922 | call-stmt 6923 6924 indirectref : INDIRECT_REF 6925 op0 -> val 6926 6927 lhs : addressable 6928 | bitfieldref 6929 | WITH_SIZE_EXPR 6930 op0 -> with-size-arg 6931 op1 -> val 6932 6933 min-lval : ID 6934 | indirectref 6935 6936 bitfieldref : BIT_FIELD_REF 6937 op0 -> inner-compref 6938 op1 -> CONST 6939 op2 -> var 6940 6941 compref : inner-compref 6942 | TARGET_MEM_REF 6943 op0 -> ID 6944 op1 -> val 6945 op2 -> val 6946 op3 -> CONST 6947 op4 -> CONST 6948 | REALPART_EXPR 6949 op0 -> inner-compref 6950 | IMAGPART_EXPR 6951 op0 -> inner-compref 6952 6953 inner-compref: min-lval 6954 | COMPONENT_REF 6955 op0 -> inner-compref 6956 op1 -> FIELD_DECL 6957 op2 -> val 6958 | ARRAY_REF 6959 op0 -> inner-compref 6960 op1 -> val 6961 op2 -> val 6962 op3 -> val 6963 | ARRAY_RANGE_REF 6964 op0 -> inner-compref 6965 op1 -> val 6966 op2 -> val 6967 op3 -> val 6968 | VIEW_CONVERT_EXPR 6969 op0 -> inner-compref 6970 6971 condition : val 6972 | RELOP 6973 op0 -> val 6974 op1 -> val 6975 6976 val : ID 6977 | CONST 6978 6979 rhs : lhs 6980 | CONST 6981 | call-stmt 6982 | ADDR_EXPR 6983 op0 -> addr-expr-arg 6984 | UNOP 6985 op0 -> val 6986 | BINOP 6987 op0 -> val 6988 op1 -> val 6989 | RELOP 6990 op0 -> val 6991 op1 -> val 6992 | COND_EXPR 6993 op0 -> condition 6994 op1 -> val 6995 op2 -> val 6996 6997 6998 File: gccint.info, Node: Annotations, Next: Statement Operands, Prev: GIMPLE, Up: Tree SSA 6999 7000 10.3 Annotations 7001 ================ 7002 7003 The optimizers need to associate attributes with statements and 7004 variables during the optimization process. For instance, we need to 7005 know what basic block a statement belongs to or whether a variable has 7006 aliases. All these attributes are stored in data structures called 7007 annotations which are then linked to the field `ann' in `struct 7008 tree_common'. 7009 7010 Presently, we define annotations for statements (`stmt_ann_t'), 7011 variables (`var_ann_t') and SSA names (`ssa_name_ann_t'). Annotations 7012 are defined and documented in `tree-flow.h'. 7013 7014 7015 File: gccint.info, Node: Statement Operands, Next: SSA, Prev: Annotations, Up: Tree SSA 7016 7017 10.4 Statement Operands 7018 ======================= 7019 7020 Almost every GIMPLE statement will contain a reference to a variable or 7021 memory location. Since statements come in different shapes and sizes, 7022 their operands are going to be located at various spots inside the 7023 statement's tree. To facilitate access to the statement's operands, 7024 they are organized into lists associated inside each statement's 7025 annotation. Each element in an operand list is a pointer to a 7026 `VAR_DECL', `PARM_DECL' or `SSA_NAME' tree node. This provides a very 7027 convenient way of examining and replacing operands. 7028 7029 Data flow analysis and optimization is done on all tree nodes 7030 representing variables. Any node for which `SSA_VAR_P' returns nonzero 7031 is considered when scanning statement operands. However, not all 7032 `SSA_VAR_P' variables are processed in the same way. For the purposes 7033 of optimization, we need to distinguish between references to local 7034 scalar variables and references to globals, statics, structures, 7035 arrays, aliased variables, etc. The reason is simple, the compiler can 7036 gather complete data flow information for a local scalar. On the other 7037 hand, a global variable may be modified by a function call, it may not 7038 be possible to keep track of all the elements of an array or the fields 7039 of a structure, etc. 7040 7041 The operand scanner gathers two kinds of operands: "real" and 7042 "virtual". An operand for which `is_gimple_reg' returns true is 7043 considered real, otherwise it is a virtual operand. We also 7044 distinguish between uses and definitions. An operand is used if its 7045 value is loaded by the statement (e.g., the operand at the RHS of an 7046 assignment). If the statement assigns a new value to the operand, the 7047 operand is considered a definition (e.g., the operand at the LHS of an 7048 assignment). 7049 7050 Virtual and real operands also have very different data flow 7051 properties. Real operands are unambiguous references to the full 7052 object that they represent. For instance, given 7053 7054 { 7055 int a, b; 7056 a = b 7057 } 7058 7059 Since `a' and `b' are non-aliased locals, the statement `a = b' will 7060 have one real definition and one real use because variable `b' is 7061 completely modified with the contents of variable `a'. Real definition 7062 are also known as "killing definitions". Similarly, the use of `a' 7063 reads all its bits. 7064 7065 In contrast, virtual operands are used with variables that can have a 7066 partial or ambiguous reference. This includes structures, arrays, 7067 globals, and aliased variables. In these cases, we have two types of 7068 definitions. For globals, structures, and arrays, we can determine from 7069 a statement whether a variable of these types has a killing definition. 7070 If the variable does, then the statement is marked as having a "must 7071 definition" of that variable. However, if a statement is only defining 7072 a part of the variable (i.e. a field in a structure), or if we know 7073 that a statement might define the variable but we cannot say for sure, 7074 then we mark that statement as having a "may definition". For 7075 instance, given 7076 7077 { 7078 int a, b, *p; 7079 7080 if (...) 7081 p = &a; 7082 else 7083 p = &b; 7084 *p = 5; 7085 return *p; 7086 } 7087 7088 The assignment `*p = 5' may be a definition of `a' or `b'. If we 7089 cannot determine statically where `p' is pointing to at the time of the 7090 store operation, we create virtual definitions to mark that statement 7091 as a potential definition site for `a' and `b'. Memory loads are 7092 similarly marked with virtual use operands. Virtual operands are shown 7093 in tree dumps right before the statement that contains them. To 7094 request a tree dump with virtual operands, use the `-vops' option to 7095 `-fdump-tree': 7096 7097 { 7098 int a, b, *p; 7099 7100 if (...) 7101 p = &a; 7102 else 7103 p = &b; 7104 # a = V_MAY_DEF <a> 7105 # b = V_MAY_DEF <b> 7106 *p = 5; 7107 7108 # VUSE <a> 7109 # VUSE <b> 7110 return *p; 7111 } 7112 7113 Notice that `V_MAY_DEF' operands have two copies of the referenced 7114 variable. This indicates that this is not a killing definition of that 7115 variable. In this case we refer to it as a "may definition" or 7116 "aliased store". The presence of the second copy of the variable in 7117 the `V_MAY_DEF' operand will become important when the function is 7118 converted into SSA form. This will be used to link all the non-killing 7119 definitions to prevent optimizations from making incorrect assumptions 7120 about them. 7121 7122 Operands are updated as soon as the statement is finished via a call 7123 to `update_stmt'. If statement elements are changed via `SET_USE' or 7124 `SET_DEF', then no further action is required (i.e., those macros take 7125 care of updating the statement). If changes are made by manipulating 7126 the statement's tree directly, then a call must be made to 7127 `update_stmt' when complete. Calling one of the `bsi_insert' routines 7128 or `bsi_replace' performs an implicit call to `update_stmt'. 7129 7130 10.4.1 Operand Iterators And Access Routines 7131 -------------------------------------------- 7132 7133 Operands are collected by `tree-ssa-operands.c'. They are stored 7134 inside each statement's annotation and can be accessed through either 7135 the operand iterators or an access routine. 7136 7137 The following access routines are available for examining operands: 7138 7139 1. `SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return 7140 NULL unless there is exactly one operand matching the specified 7141 flags. If there is exactly one operand, the operand is returned 7142 as either a `tree', `def_operand_p', or `use_operand_p'. 7143 7144 tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags); 7145 use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES); 7146 def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS); 7147 7148 2. `ZERO_SSA_OPERANDS': This macro returns true if there are no 7149 operands matching the specified flags. 7150 7151 if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS)) 7152 return; 7153 7154 3. `NUM_SSA_OPERANDS': This macro Returns the number of operands 7155 matching 'flags'. This actually executes a loop to perform the 7156 count, so only use this if it is really needed. 7157 7158 int count = NUM_SSA_OPERANDS (stmt, flags) 7159 7160 If you wish to iterate over some or all operands, use the 7161 `FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print 7162 all the operands for a statement: 7163 7164 void 7165 print_ops (tree stmt) 7166 { 7167 ssa_op_iter; 7168 tree var; 7169 7170 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS) 7171 print_generic_expr (stderr, var, TDF_SLIM); 7172 } 7173 7174 How to choose the appropriate iterator: 7175 7176 1. Determine whether you are need to see the operand pointers, or 7177 just the trees, and choose the appropriate macro: 7178 7179 Need Macro: 7180 ---- ------- 7181 use_operand_p FOR_EACH_SSA_USE_OPERAND 7182 def_operand_p FOR_EACH_SSA_DEF_OPERAND 7183 tree FOR_EACH_SSA_TREE_OPERAND 7184 7185 2. You need to declare a variable of the type you are interested 7186 in, and an ssa_op_iter structure which serves as the loop 7187 controlling variable. 7188 7189 3. Determine which operands you wish to use, and specify the flags of 7190 those you are interested in. They are documented in 7191 `tree-ssa-operands.h': 7192 7193 #define SSA_OP_USE 0x01 /* Real USE operands. */ 7194 #define SSA_OP_DEF 0x02 /* Real DEF operands. */ 7195 #define SSA_OP_VUSE 0x04 /* VUSE operands. */ 7196 #define SSA_OP_VMAYUSE 0x08 /* USE portion of V_MAY_DEFS. */ 7197 #define SSA_OP_VMAYDEF 0x10 /* DEF portion of V_MAY_DEFS. */ 7198 #define SSA_OP_VMUSTDEF 0x20 /* V_MUST_DEF definitions. */ 7199 7200 /* These are commonly grouped operand flags. */ 7201 #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE | SSA_OP_VMAYUSE) 7202 #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VMAYDEF | SSA_OP_VMUSTDEF) 7203 #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE) 7204 #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF) 7205 #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS) 7206 7207 So if you want to look at the use pointers for all the `USE' and 7208 `VUSE' operands, you would do something like: 7209 7210 use_operand_p use_p; 7211 ssa_op_iter iter; 7212 7213 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE)) 7214 { 7215 process_use_ptr (use_p); 7216 } 7217 7218 The `TREE' macro is basically the same as the `USE' and `DEF' macros, 7219 only with the use or def dereferenced via `USE_FROM_PTR (use_p)' and 7220 `DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use 7221 and defs flags can be mixed. 7222 7223 tree var; 7224 ssa_op_iter iter; 7225 7226 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE | SSA_OP_VMUSTDEF) 7227 { 7228 print_generic_expr (stderr, var, TDF_SLIM); 7229 } 7230 7231 `V_MAY_DEF's are broken into two flags, one for the `DEF' portion 7232 (`SSA_OP_VMAYDEF') and one for the USE portion (`SSA_OP_VMAYUSE'). If 7233 all you want to look at are the `V_MAY_DEF's together, there is a 7234 fourth iterator macro for this, which returns both a def_operand_p and 7235 a use_operand_p for each `V_MAY_DEF' in the statement. Note that you 7236 don't need any flags for this one. 7237 7238 use_operand_p use_p; 7239 def_operand_p def_p; 7240 ssa_op_iter iter; 7241 7242 FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter) 7243 { 7244 my_code; 7245 } 7246 7247 `V_MUST_DEF's are broken into two flags, one for the `DEF' portion 7248 (`SSA_OP_VMUSTDEF') and one for the kill portion (`SSA_OP_VMUSTKILL'). 7249 If all you want to look at are the `V_MUST_DEF's together, there is a 7250 fourth iterator macro for this, which returns both a def_operand_p and 7251 a use_operand_p for each `V_MUST_DEF' in the statement. Note that you 7252 don't need any flags for this one. 7253 7254 use_operand_p kill_p; 7255 def_operand_p def_p; 7256 ssa_op_iter iter; 7257 7258 FOR_EACH_SSA_MUSTDEF_OPERAND (def_p, kill_p, stmt, iter) 7259 { 7260 my_code; 7261 } 7262 7263 There are many examples in the code as well, as well as the 7264 documentation in `tree-ssa-operands.h'. 7265 7266 There are also a couple of variants on the stmt iterators regarding PHI 7267 nodes. 7268 7269 `FOR_EACH_PHI_ARG' Works exactly like `FOR_EACH_SSA_USE_OPERAND', 7270 except it works over `PHI' arguments instead of statement operands. 7271 7272 /* Look at every virtual PHI use. */ 7273 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES) 7274 { 7275 my_code; 7276 } 7277 7278 /* Look at every real PHI use. */ 7279 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES) 7280 my_code; 7281 7282 /* Look at every every PHI use. */ 7283 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES) 7284 my_code; 7285 7286 `FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like 7287 `FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a 7288 statement or a `PHI' node. These should be used when it is appropriate 7289 but they are not quite as efficient as the individual `FOR_EACH_PHI' 7290 and `FOR_EACH_SSA' routines. 7291 7292 FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags) 7293 { 7294 my_code; 7295 } 7296 7297 FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags) 7298 { 7299 my_code; 7300 } 7301 7302 10.4.2 Immediate Uses 7303 --------------------- 7304 7305 Immediate use information is now always available. Using the immediate 7306 use iterators, you may examine every use of any `SSA_NAME'. For 7307 instance, to change each use of `ssa_var' to `ssa_var2' and call 7308 fold_stmt on each stmt after that is done: 7309 7310 use_operand_p imm_use_p; 7311 imm_use_iterator iterator; 7312 tree ssa_var, stmt; 7313 7314 7315 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 7316 { 7317 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 7318 SET_USE (imm_use_p, ssa_var_2); 7319 fold_stmt (stmt); 7320 } 7321 7322 There are 2 iterators which can be used. `FOR_EACH_IMM_USE_FAST' is 7323 used when the immediate uses are not changed, i.e., you are looking at 7324 the uses, but not setting them. 7325 7326 If they do get changed, then care must be taken that things are not 7327 changed under the iterators, so use the `FOR_EACH_IMM_USE_STMT' and 7328 `FOR_EACH_IMM_USE_ON_STMT' iterators. They attempt to preserve the 7329 sanity of the use list by moving all the uses for a statement into a 7330 controlled position, and then iterating over those uses. Then the 7331 optimization can manipulate the stmt when all the uses have been 7332 processed. This is a little slower than the FAST version since it adds 7333 a placeholder element and must sort through the list a bit for each 7334 statement. This placeholder element must be also be removed if the 7335 loop is terminated early. The macro `BREAK_FROM_IMM_USE_SAFE' is 7336 provided to do this : 7337 7338 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 7339 { 7340 if (stmt == last_stmt) 7341 BREAK_FROM_SAFE_IMM_USE (iter); 7342 7343 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 7344 SET_USE (imm_use_p, ssa_var_2); 7345 fold_stmt (stmt); 7346 } 7347 7348 There are checks in `verify_ssa' which verify that the immediate use 7349 list is up to date, as well as checking that an optimization didn't 7350 break from the loop without using this macro. It is safe to simply 7351 'break'; from a `FOR_EACH_IMM_USE_FAST' traverse. 7352 7353 Some useful functions and macros: 7354 1. `has_zero_uses (ssa_var)' : Returns true if there are no uses of 7355 `ssa_var'. 7356 7357 2. `has_single_use (ssa_var)' : Returns true if there is only a 7358 single use of `ssa_var'. 7359 7360 3. `single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' : 7361 Returns true if there is only a single use of `ssa_var', and also 7362 returns the use pointer and statement it occurs in in the second 7363 and third parameters. 7364 7365 4. `num_imm_uses (ssa_var)' : Returns the number of immediate uses of 7366 `ssa_var'. It is better not to use this if possible since it simply 7367 utilizes a loop to count the uses. 7368 7369 5. `PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a `PHI' 7370 node, return the index number for the use. An assert is triggered 7371 if the use isn't located in a `PHI' node. 7372 7373 6. `USE_STMT (use_p)' : Return the statement a use occurs in. 7374 7375 Note that uses are not put into an immediate use list until their 7376 statement is actually inserted into the instruction stream via a 7377 `bsi_*' routine. 7378 7379 It is also still possible to utilize lazy updating of statements, but 7380 this should be used only when absolutely required. Both alias analysis 7381 and the dominator optimizations currently do this. 7382 7383 When lazy updating is being used, the immediate use information is out 7384 of date and cannot be used reliably. Lazy updating is achieved by 7385 simply marking statements modified via calls to `mark_stmt_modified' 7386 instead of `update_stmt'. When lazy updating is no longer required, 7387 all the modified statements must have `update_stmt' called in order to 7388 bring them up to date. This must be done before the optimization is 7389 finished, or `verify_ssa' will trigger an abort. 7390 7391 This is done with a simple loop over the instruction stream: 7392 block_stmt_iterator bsi; 7393 basic_block bb; 7394 FOR_EACH_BB (bb) 7395 { 7396 for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi)) 7397 update_stmt_if_modified (bsi_stmt (bsi)); 7398 } 7399 7400 7401 File: gccint.info, Node: SSA, Next: Alias analysis, Prev: Statement Operands, Up: Tree SSA 7402 7403 10.5 Static Single Assignment 7404 ============================= 7405 7406 Most of the tree optimizers rely on the data flow information provided 7407 by the Static Single Assignment (SSA) form. We implement the SSA form 7408 as described in `R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K. 7409 Zadeck. Efficiently Computing Static Single Assignment Form and the 7410 Control Dependence Graph. ACM Transactions on Programming Languages 7411 and Systems, 13(4):451-490, October 1991'. 7412 7413 The SSA form is based on the premise that program variables are 7414 assigned in exactly one location in the program. Multiple assignments 7415 to the same variable create new versions of that variable. Naturally, 7416 actual programs are seldom in SSA form initially because variables tend 7417 to be assigned multiple times. The compiler modifies the program 7418 representation so that every time a variable is assigned in the code, a 7419 new version of the variable is created. Different versions of the same 7420 variable are distinguished by subscripting the variable name with its 7421 version number. Variables used in the right-hand side of expressions 7422 are renamed so that their version number matches that of the most 7423 recent assignment. 7424 7425 We represent variable versions using `SSA_NAME' nodes. The renaming 7426 process in `tree-ssa.c' wraps every real and virtual operand with an 7427 `SSA_NAME' node which contains the version number and the statement 7428 that created the `SSA_NAME'. Only definitions and virtual definitions 7429 may create new `SSA_NAME' nodes. 7430 7431 Sometimes, flow of control makes it impossible to determine what is the 7432 most recent version of a variable. In these cases, the compiler 7433 inserts an artificial definition for that variable called "PHI 7434 function" or "PHI node". This new definition merges all the incoming 7435 versions of the variable to create a new name for it. For instance, 7436 7437 if (...) 7438 a_1 = 5; 7439 else if (...) 7440 a_2 = 2; 7441 else 7442 a_3 = 13; 7443 7444 # a_4 = PHI <a_1, a_2, a_3> 7445 return a_4; 7446 7447 Since it is not possible to determine which of the three branches will 7448 be taken at runtime, we don't know which of `a_1', `a_2' or `a_3' to 7449 use at the return statement. So, the SSA renamer creates a new version 7450 `a_4' which is assigned the result of "merging" `a_1', `a_2' and `a_3'. 7451 Hence, PHI nodes mean "one of these operands. I don't know which". 7452 7453 The following macros can be used to examine PHI nodes 7454 7455 -- Macro: PHI_RESULT (PHI) 7456 Returns the `SSA_NAME' created by PHI node PHI (i.e., PHI's LHS). 7457 7458 -- Macro: PHI_NUM_ARGS (PHI) 7459 Returns the number of arguments in PHI. This number is exactly 7460 the number of incoming edges to the basic block holding PHI. 7461 7462 -- Macro: PHI_ARG_ELT (PHI, I) 7463 Returns a tuple representing the Ith argument of PHI. Each 7464 element of this tuple contains an `SSA_NAME' VAR and the incoming 7465 edge through which VAR flows. 7466 7467 -- Macro: PHI_ARG_EDGE (PHI, I) 7468 Returns the incoming edge for the Ith argument of PHI. 7469 7470 -- Macro: PHI_ARG_DEF (PHI, I) 7471 Returns the `SSA_NAME' for the Ith argument of PHI. 7472 7473 10.5.1 Preserving the SSA form 7474 ------------------------------ 7475 7476 Some optimization passes make changes to the function that invalidate 7477 the SSA property. This can happen when a pass has added new symbols or 7478 changed the program so that variables that were previously aliased 7479 aren't anymore. Whenever something like this happens, the affected 7480 symbols must be renamed into SSA form again. Transformations that emit 7481 new code or replicate existing statements will also need to update the 7482 SSA form. 7483 7484 Since GCC implements two different SSA forms for register and virtual 7485 variables, keeping the SSA form up to date depends on whether you are 7486 updating register or virtual names. In both cases, the general idea 7487 behind incremental SSA updates is similar: when new SSA names are 7488 created, they typically are meant to replace other existing names in 7489 the program. 7490 7491 For instance, given the following code: 7492 7493 1 L0: 7494 2 x_1 = PHI (0, x_5) 7495 3 if (x_1 < 10) 7496 4 if (x_1 > 7) 7497 5 y_2 = 0 7498 6 else 7499 7 y_3 = x_1 + x_7 7500 8 endif 7501 9 x_5 = x_1 + 1 7502 10 goto L0; 7503 11 endif 7504 7505 Suppose that we insert new names `x_10' and `x_11' (lines `4' and `8'). 7506 7507 1 L0: 7508 2 x_1 = PHI (0, x_5) 7509 3 if (x_1 < 10) 7510 4 x_10 = ... 7511 5 if (x_1 > 7) 7512 6 y_2 = 0 7513 7 else 7514 8 x_11 = ... 7515 9 y_3 = x_1 + x_7 7516 10 endif 7517 11 x_5 = x_1 + 1 7518 12 goto L0; 7519 13 endif 7520 7521 We want to replace all the uses of `x_1' with the new definitions of 7522 `x_10' and `x_11'. Note that the only uses that should be replaced are 7523 those at lines `5', `9' and `11'. Also, the use of `x_7' at line `9' 7524 should _not_ be replaced (this is why we cannot just mark symbol `x' for 7525 renaming). 7526 7527 Additionally, we may need to insert a PHI node at line `11' because 7528 that is a merge point for `x_10' and `x_11'. So the use of `x_1' at 7529 line `11' will be replaced with the new PHI node. The insertion of PHI 7530 nodes is optional. They are not strictly necessary to preserve the SSA 7531 form, and depending on what the caller inserted, they may not even be 7532 useful for the optimizers. 7533 7534 Updating the SSA form is a two step process. First, the pass has to 7535 identify which names need to be updated and/or which symbols need to be 7536 renamed into SSA form for the first time. When new names are 7537 introduced to replace existing names in the program, the mapping 7538 between the old and the new names are registered by calling 7539 `register_new_name_mapping' (note that if your pass creates new code by 7540 duplicating basic blocks, the call to `tree_duplicate_bb' will set up 7541 the necessary mappings automatically). On the other hand, if your pass 7542 exposes a new symbol that should be put in SSA form for the first time, 7543 the new symbol should be registered with `mark_sym_for_renaming'. 7544 7545 After the replacement mappings have been registered and new symbols 7546 marked for renaming, a call to `update_ssa' makes the registered 7547 changes. This can be done with an explicit call or by creating `TODO' 7548 flags in the `tree_opt_pass' structure for your pass. There are 7549 several `TODO' flags that control the behavior of `update_ssa': 7550 7551 * `TODO_update_ssa'. Update the SSA form inserting PHI nodes 7552 for newly exposed symbols and virtual names marked for updating. 7553 When updating real names, only insert PHI nodes for a real 7554 name `O_j' in blocks reached by all the new and old 7555 definitions for `O_j'. If the iterated dominance frontier 7556 for `O_j' is not pruned, we may end up inserting PHI nodes 7557 in blocks that have one or more edges with no incoming 7558 definition for `O_j'. This would lead to uninitialized 7559 warnings for `O_j''s symbol. 7560 7561 * `TODO_update_ssa_no_phi'. Update the SSA form without 7562 inserting any new PHI nodes at all. This is used by passes that 7563 have either inserted all the PHI nodes themselves or passes 7564 that need only to patch use-def and def-def chains for 7565 virtuals (e.g., DCE). 7566 7567 * `TODO_update_ssa_full_phi'. Insert PHI nodes everywhere 7568 they are needed. No pruning of the IDF is done. This is used 7569 by passes that need the PHI nodes for `O_j' even if it 7570 means that some arguments will come from the default definition 7571 of `O_j''s symbol (e.g., `pass_linear_transform'). 7572 7573 WARNING: If you need to use this flag, chances are that your 7574 pass may be doing something wrong. Inserting PHI nodes for an 7575 old name where not all edges carry a new replacement may lead to 7576 silent codegen errors or spurious uninitialized warnings. 7577 7578 * `TODO_update_ssa_only_virtuals'. Passes that update the SSA 7579 form on their own may want to delegate the updating of 7580 virtual names to the generic updater. Since FUD chains are 7581 easier to maintain, this simplifies the work they need to do. 7582 NOTE: If this flag is used, any OLD->NEW mappings for real names 7583 are explicitly destroyed and only the symbols marked for 7584 renaming are processed. 7585 7586 10.5.2 Preserving the virtual SSA form 7587 -------------------------------------- 7588 7589 The virtual SSA form is harder to preserve than the non-virtual SSA form 7590 mainly because the set of virtual operands for a statement may change at 7591 what some would consider unexpected times. In general, any time you 7592 have modified a statement that has virtual operands, you should verify 7593 whether the list of virtual operands has changed, and if so, mark the 7594 newly exposed symbols by calling `mark_new_vars_to_rename'. 7595 7596 There is one additional caveat to preserving virtual SSA form. When 7597 the entire set of virtual operands may be eliminated due to better 7598 disambiguation, a bare SMT will be added to the list of virtual 7599 operands, to signify the non-visible aliases that the are still being 7600 referenced. If the set of bare SMT's may change, 7601 `TODO_update_smt_usage' should be added to the todo flags. 7602 7603 With the current pruning code, this can only occur when constants are 7604 propagated into array references that were previously non-constant, or 7605 address expressions are propagated into their uses. 7606 7607 10.5.3 Examining `SSA_NAME' nodes 7608 --------------------------------- 7609 7610 The following macros can be used to examine `SSA_NAME' nodes 7611 7612 -- Macro: SSA_NAME_DEF_STMT (VAR) 7613 Returns the statement S that creates the `SSA_NAME' VAR. If S is 7614 an empty statement (i.e., `IS_EMPTY_STMT (S)' returns `true'), it 7615 means that the first reference to this variable is a USE or a VUSE. 7616 7617 -- Macro: SSA_NAME_VERSION (VAR) 7618 Returns the version number of the `SSA_NAME' object VAR. 7619 7620 10.5.4 Walking use-def chains 7621 ----------------------------- 7622 7623 -- Tree SSA function: void walk_use_def_chains (VAR, FN, DATA) 7624 Walks use-def chains starting at the `SSA_NAME' node VAR. Calls 7625 function FN at each reaching definition found. Function FN takes 7626 three arguments: VAR, its defining statement (DEF_STMT) and a 7627 generic pointer to whatever state information that FN may want to 7628 maintain (DATA). Function FN is able to stop the walk by 7629 returning `true', otherwise in order to continue the walk, FN 7630 should return `false'. 7631 7632 Note, that if DEF_STMT is a `PHI' node, the semantics are slightly 7633 different. For each argument ARG of the PHI node, this function 7634 will: 7635 7636 1. Walk the use-def chains for ARG. 7637 7638 2. Call `FN (ARG, PHI, DATA)'. 7639 7640 Note how the first argument to FN is no longer the original 7641 variable VAR, but the PHI argument currently being examined. If 7642 FN wants to get at VAR, it should call `PHI_RESULT' (PHI). 7643 7644 10.5.5 Walking the dominator tree 7645 --------------------------------- 7646 7647 -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB) 7648 This function walks the dominator tree for the current CFG calling 7649 a set of callback functions defined in STRUCT DOM_WALK_DATA in 7650 `domwalk.h'. The call back functions you need to define give you 7651 hooks to execute custom code at various points during traversal: 7652 7653 1. Once to initialize any local data needed while processing 7654 BB and its children. This local data is pushed into an 7655 internal stack which is automatically pushed and popped as 7656 the walker traverses the dominator tree. 7657 7658 2. Once before traversing all the statements in the BB. 7659 7660 3. Once for every statement inside BB. 7661 7662 4. Once after traversing all the statements and before recursing 7663 into BB's dominator children. 7664 7665 5. It then recurses into all the dominator children of BB. 7666 7667 6. After recursing into all the dominator children of BB it 7668 can, optionally, traverse every statement in BB again 7669 (i.e., repeating steps 2 and 3). 7670 7671 7. Once after walking the statements in BB and BB's 7672 dominator children. At this stage, the block local data stack 7673 is popped. 7674 7675 7676 File: gccint.info, Node: Alias analysis, Prev: SSA, Up: Tree SSA 7677 7678 10.6 Alias analysis 7679 =================== 7680 7681 Alias analysis proceeds in 4 main phases: 7682 7683 1. Structural alias analysis. 7684 7685 This phase walks the types for structure variables, and determines 7686 which of the fields can overlap using offset and size of each 7687 field. For each field, a "subvariable" called a "Structure field 7688 tag" (SFT) is created, which represents that field as a separate 7689 variable. All accesses that could possibly overlap with a given 7690 field will have virtual operands for the SFT of that field. 7691 7692 struct foo 7693 { 7694 int a; 7695 int b; 7696 } 7697 struct foo temp; 7698 int bar (void) 7699 { 7700 int tmp1, tmp2, tmp3; 7701 SFT.0_2 = V_MUST_DEF <SFT.0_1> 7702 temp.a = 5; 7703 SFT.1_4 = V_MUST_DEF <SFT.1_3> 7704 temp.b = 6; 7705 7706 VUSE <SFT.1_4> 7707 tmp1_5 = temp.b; 7708 VUSE <SFT.0_2> 7709 tmp2_6 = temp.a; 7710 7711 tmp3_7 = tmp1_5 + tmp2_6; 7712 return tmp3_7; 7713 } 7714 7715 If you copy the symbol tag for a variable for some reason, you 7716 probably also want to copy the subvariables for that variable. 7717 7718 2. Points-to and escape analysis. 7719 7720 This phase walks the use-def chains in the SSA web looking for 7721 three things: 7722 7723 7724 7725 7726 * Assignments of the form `P_i = &VAR' 7727 7728 * Assignments of the form P_i = malloc() 7729 7730 * Pointers and ADDR_EXPR that escape the current function. 7731 7732 The concept of `escaping' is the same one used in the Java world. 7733 When a pointer or an ADDR_EXPR escapes, it means that it has been 7734 exposed outside of the current function. So, assignment to global 7735 variables, function arguments and returning a pointer are all 7736 escape sites. 7737 7738 This is where we are currently limited. Since not everything is 7739 renamed into SSA, we lose track of escape properties when a 7740 pointer is stashed inside a field in a structure, for instance. 7741 In those cases, we are assuming that the pointer does escape. 7742 7743 We use escape analysis to determine whether a variable is 7744 call-clobbered. Simply put, if an ADDR_EXPR escapes, then the 7745 variable is call-clobbered. If a pointer P_i escapes, then all 7746 the variables pointed-to by P_i (and its memory tag) also escape. 7747 7748 3. Compute flow-sensitive aliases 7749 7750 We have two classes of memory tags. Memory tags associated with 7751 the pointed-to data type of the pointers in the program. These 7752 tags are called "symbol memory tag" (SMT). The other class are 7753 those associated with SSA_NAMEs, called "name memory tag" (NMT). 7754 The basic idea is that when adding operands for an INDIRECT_REF 7755 *P_i, we will first check whether P_i has a name tag, if it does 7756 we use it, because that will have more precise aliasing 7757 information. Otherwise, we use the standard symbol tag. 7758 7759 In this phase, we go through all the pointers we found in 7760 points-to analysis and create alias sets for the name memory tags 7761 associated with each pointer P_i. If P_i escapes, we mark 7762 call-clobbered the variables it points to and its tag. 7763 7764 4. Compute flow-insensitive aliases 7765 7766 This pass will compare the alias set of every symbol memory tag and 7767 every addressable variable found in the program. Given a symbol 7768 memory tag SMT and an addressable variable V. If the alias sets 7769 of SMT and V conflict (as computed by may_alias_p), then V is 7770 marked as an alias tag and added to the alias set of SMT. 7771 7772 For instance, consider the following function: 7773 7774 foo (int i) 7775 { 7776 int *p, *q, a, b; 7777 7778 if (i > 10) 7779 p = &a; 7780 else 7781 q = &b; 7782 7783 *p = 3; 7784 *q = 5; 7785 a = b + 2; 7786 return *p; 7787 } 7788 7789 After aliasing analysis has finished, the symbol memory tag for 7790 pointer `p' will have two aliases, namely variables `a' and `b'. Every 7791 time pointer `p' is dereferenced, we want to mark the operation as a 7792 potential reference to `a' and `b'. 7793 7794 foo (int i) 7795 { 7796 int *p, a, b; 7797 7798 if (i_2 > 10) 7799 p_4 = &a; 7800 else 7801 p_6 = &b; 7802 # p_1 = PHI <p_4(1), p_6(2)>; 7803 7804 # a_7 = V_MAY_DEF <a_3>; 7805 # b_8 = V_MAY_DEF <b_5>; 7806 *p_1 = 3; 7807 7808 # a_9 = V_MAY_DEF <a_7> 7809 # VUSE <b_8> 7810 a_9 = b_8 + 2; 7811 7812 # VUSE <a_9>; 7813 # VUSE <b_8>; 7814 return *p_1; 7815 } 7816 7817 In certain cases, the list of may aliases for a pointer may grow too 7818 large. This may cause an explosion in the number of virtual operands 7819 inserted in the code. Resulting in increased memory consumption and 7820 compilation time. 7821 7822 When the number of virtual operands needed to represent aliased loads 7823 and stores grows too large (configurable with `--param 7824 max-aliased-vops'), alias sets are grouped to avoid severe compile-time 7825 slow downs and memory consumption. The alias grouping heuristic 7826 proceeds as follows: 7827 7828 1. Sort the list of pointers in decreasing number of contributed 7829 virtual operands. 7830 7831 2. Take the first pointer from the list and reverse the role of the 7832 memory tag and its aliases. Usually, whenever an aliased variable 7833 Vi is found to alias with a memory tag T, we add Vi to the 7834 may-aliases set for T. Meaning that after alias analysis, we will 7835 have: 7836 7837 may-aliases(T) = { V1, V2, V3, ..., Vn } 7838 7839 This means that every statement that references T, will get `n' 7840 virtual operands for each of the Vi tags. But, when alias 7841 grouping is enabled, we make T an alias tag and add it to the 7842 alias set of all the Vi variables: 7843 7844 may-aliases(V1) = { T } 7845 may-aliases(V2) = { T } 7846 ... 7847 may-aliases(Vn) = { T } 7848 7849 This has two effects: (a) statements referencing T will only get a 7850 single virtual operand, and, (b) all the variables Vi will now 7851 appear to alias each other. So, we lose alias precision to 7852 improve compile time. But, in theory, a program with such a high 7853 level of aliasing should not be very optimizable in the first 7854 place. 7855 7856 3. Since variables may be in the alias set of more than one memory 7857 tag, the grouping done in step (2) needs to be extended to all the 7858 memory tags that have a non-empty intersection with the 7859 may-aliases set of tag T. For instance, if we originally had 7860 these may-aliases sets: 7861 7862 may-aliases(T) = { V1, V2, V3 } 7863 may-aliases(R) = { V2, V4 } 7864 7865 In step (2) we would have reverted the aliases for T as: 7866 7867 may-aliases(V1) = { T } 7868 may-aliases(V2) = { T } 7869 may-aliases(V3) = { T } 7870 7871 But note that now V2 is no longer aliased with R. We could add R 7872 to may-aliases(V2), but we are in the process of grouping aliases 7873 to reduce virtual operands so what we do is add V4 to the grouping 7874 to obtain: 7875 7876 may-aliases(V1) = { T } 7877 may-aliases(V2) = { T } 7878 may-aliases(V3) = { T } 7879 may-aliases(V4) = { T } 7880 7881 4. If the total number of virtual operands due to aliasing is still 7882 above the threshold set by max-alias-vops, go back to (2). 7883 7884 7885 File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Tree SSA, Up: Top 7886 7887 11 Analysis and Representation of Loops 7888 *************************************** 7889 7890 GCC provides extensive infrastructure for work with natural loops, i.e., 7891 strongly connected components of CFG with only one entry block. This 7892 chapter describes representation of loops in GCC, both on GIMPLE and in 7893 RTL, as well as the interfaces to loop-related analyses (induction 7894 variable analysis and number of iterations analysis). 7895 7896 * Menu: 7897 7898 * Loop representation:: Representation and analysis of loops. 7899 * Loop querying:: Getting information about loops. 7900 * Loop manipulation:: Loop manipulation functions. 7901 * LCSSA:: Loop-closed SSA form. 7902 * Scalar evolutions:: Induction variables on GIMPLE. 7903 * loop-iv:: Induction variables on RTL. 7904 * Number of iterations:: Number of iterations analysis. 7905 * Dependency analysis:: Data dependency analysis. 7906 * Lambda:: Linear loop transformations framework. 7907 7908 7909 File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation 7910 7911 11.1 Loop representation 7912 ======================== 7913 7914 This chapter describes the representation of loops in GCC, and functions 7915 that can be used to build, modify and analyze this representation. Most 7916 of the interfaces and data structures are declared in `cfgloop.h'. At 7917 the moment, loop structures are analyzed and this information is 7918 updated only by the optimization passes that deal with loops, but some 7919 efforts are being made to make it available throughout most of the 7920 optimization passes. 7921 7922 In general, a natural loop has one entry block (header) and possibly 7923 several back edges (latches) leading to the header from the inside of 7924 the loop. Loops with several latches may appear if several loops share 7925 a single header, or if there is a branching in the middle of the loop. 7926 The representation of loops in GCC however allows only loops with a 7927 single latch. During loop analysis, headers of such loops are split and 7928 forwarder blocks are created in order to disambiguate their structures. 7929 A heuristic based on profile information is used to determine whether 7930 the latches correspond to sub-loops or to control flow in a single loop. 7931 This means that the analysis sometimes changes the CFG, and if you run 7932 it in the middle of an optimization pass, you must be able to deal with 7933 the new blocks. 7934 7935 Body of the loop is the set of blocks that are dominated by its header, 7936 and reachable from its latch against the direction of edges in CFG. The 7937 loops are organized in a containment hierarchy (tree) such that all the 7938 loops immediately contained inside loop L are the children of L in the 7939 tree. This tree is represented by the `struct loops' structure. The 7940 root of this tree is a fake loop that contains all blocks in the 7941 function. Each of the loops is represented in a `struct loop' 7942 structure. Each loop is assigned an index (`num' field of the `struct 7943 loop' structure), and the pointer to the loop is stored in the 7944 corresponding field of the `parray' field of the loops structure. 7945 Index of a sub-loop is always greater than the index of its super-loop. 7946 The indices do not have to be continuous, there may be empty (`NULL') 7947 entries in the `parray' created by deleting loops. The index of a loop 7948 never changes. The first unused index is stored in the `num' field of 7949 the loops structure. 7950 7951 Each basic block contains the reference to the innermost loop it 7952 belongs to (`loop_father'). For this reason, it is only possible to 7953 have one `struct loops' structure initialized at the same time for each 7954 CFG. It is recommended to use the global variable `current_loops' to 7955 contain the `struct loops' structure, especially if the loop structures 7956 are updated throughout several passes. Many of the loop manipulation 7957 functions assume that dominance information is up-to-date. 7958 7959 The loops are analyzed through `loop_optimizer_init' function. The 7960 argument of this function is a set of flags represented in an integer 7961 bitmask. These flags specify what other properties of the loop 7962 structures should be calculated/enforced and preserved later: 7963 7964 * `LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a 7965 way that each loop has only one entry edge, and additionally, the 7966 source block of this entry edge has only one successor. This 7967 creates a natural place where the code can be moved out of the 7968 loop, and ensures that the entry edge of the loop leads from its 7969 immediate super-loop. 7970 7971 * `LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force 7972 the latch block of each loop to have only one successor. This 7973 ensures that the latch of the loop does not belong to any of its 7974 sub-loops, and makes manipulation with the loops significantly 7975 easier. Most of the loop manipulation functions assume that the 7976 loops are in this shape. Note that with this flag, the "normal" 7977 loop without any control flow inside and with one exit consists of 7978 two basic blocks. 7979 7980 * `LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in 7981 the strongly connected components that are not natural loops (have 7982 more than one entry block) are marked with `BB_IRREDUCIBLE_LOOP' 7983 and `EDGE_IRREDUCIBLE_LOOP' flags. The flag is not set for blocks 7984 and edges that belong to natural loops that are in such an 7985 irreducible region (but it is set for the entry and exit edges of 7986 such a loop, if they lead to/from this region). 7987 7988 * `LOOPS_HAVE_MARKED_SINGLE_EXITS': If a loop has exactly one exit 7989 edge, this edge is stored in `single_exit' field of the loop 7990 structure. `NULL' is stored there otherwise. 7991 7992 These properties may also be computed/enforced later, using functions 7993 `create_preheaders', `force_single_succ_latches', 7994 `mark_irreducible_loops' and `mark_single_exit_loops'. 7995 7996 The memory occupied by the loops structures should be freed with 7997 `loop_optimizer_finalize' function. 7998 7999 The CFG manipulation functions in general do not update loop 8000 structures. Specialized versions that additionally do so are provided 8001 for the most common tasks. On GIMPLE, `cleanup_tree_cfg_loop' function 8002 can be used to cleanup CFG while updating the loops structures if 8003 `current_loops' is set. 8004 8005 8006 File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation 8007 8008 11.2 Loop querying 8009 ================== 8010 8011 The functions to query the information about loops are declared in 8012 `cfgloop.h'. Some of the information can be taken directly from the 8013 structures. `loop_father' field of each basic block contains the 8014 innermost loop to that the block belongs. The most useful fields of 8015 loop structure (that are kept up-to-date at all times) are: 8016 8017 * `header', `latch': Header and latch basic blocks of the loop. 8018 8019 * `num_nodes': Number of basic blocks in the loop (including the 8020 basic blocks of the sub-loops). 8021 8022 * `depth': The depth of the loop in the loops tree, i.e., the number 8023 of super-loops of the loop. 8024 8025 * `outer', `inner', `next': The super-loop, the first sub-loop, and 8026 the sibling of the loop in the loops tree. 8027 8028 * `single_exit': The exit edge of the loop, if the loop has exactly 8029 one exit and the loops were analyzed with 8030 LOOPS_HAVE_MARKED_SINGLE_EXITS. 8031 8032 There are other fields in the loop structures, many of them used only 8033 by some of the passes, or not updated during CFG changes; in general, 8034 they should not be accessed directly. 8035 8036 The most important functions to query loop structures are: 8037 8038 * `flow_loops_dump': Dumps the information about loops to a file. 8039 8040 * `verify_loop_structure': Checks consistency of the loop structures. 8041 8042 * `loop_latch_edge': Returns the latch edge of a loop. 8043 8044 * `loop_preheader_edge': If loops have preheaders, returns the 8045 preheader edge of a loop. 8046 8047 * `flow_loop_nested_p': Tests whether loop is a sub-loop of another 8048 loop. 8049 8050 * `flow_bb_inside_loop_p': Tests whether a basic block belongs to a 8051 loop (including its sub-loops). 8052 8053 * `find_common_loop': Finds the common super-loop of two loops. 8054 8055 * `superloop_at_depth': Returns the super-loop of a loop with the 8056 given depth. 8057 8058 * `tree_num_loop_insns', `num_loop_insns': Estimates the number of 8059 insns in the loop, on GIMPLE and on RTL. 8060 8061 * `loop_exit_edge_p': Tests whether edge is an exit from a loop. 8062 8063 * `mark_loop_exit_edges': Marks all exit edges of all loops with 8064 `EDGE_LOOP_EXIT' flag. 8065 8066 * `get_loop_body', `get_loop_body_in_dom_order', 8067 `get_loop_body_in_bfs_order': Enumerates the basic blocks in the 8068 loop in depth-first search order in reversed CFG, ordered by 8069 dominance relation, and breath-first search order, respectively. 8070 8071 * `get_loop_exit_edges': Enumerates the exit edges of a loop. 8072 8073 * `just_once_each_iteration_p': Returns true if the basic block is 8074 executed exactly once during each iteration of a loop (that is, it 8075 does not belong to a sub-loop, and it dominates the latch of the 8076 loop). 8077 8078 8079 File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation 8080 8081 11.3 Loop manipulation 8082 ====================== 8083 8084 The loops tree can be manipulated using the following functions: 8085 8086 * `flow_loop_tree_node_add': Adds a node to the tree. 8087 8088 * `flow_loop_tree_node_remove': Removes a node from the tree. 8089 8090 * `add_bb_to_loop': Adds a basic block to a loop. 8091 8092 * `remove_bb_from_loops': Removes a basic block from loops. 8093 8094 The specialized versions of several low-level CFG functions that also 8095 update loop structures are provided: 8096 8097 * `loop_split_edge_with': Splits an edge, and places a specified RTL 8098 code on it. On GIMPLE, the function can still be used, but the 8099 code must be NULL. 8100 8101 * `bsi_insert_on_edge_immediate_loop': Inserts code on edge, 8102 splitting it if necessary. Only works on GIMPLE. 8103 8104 * `remove_path': Removes an edge and all blocks it dominates. 8105 8106 * `loop_commit_inserts': Commits insertions scheduled on edges, and 8107 sets loops for the new blocks. This function can only be used on 8108 GIMPLE. 8109 8110 * `split_loop_exit_edge': Splits exit edge of the loop, ensuring 8111 that PHI node arguments remain in the loop (this ensures that 8112 loop-closed SSA form is preserved). Only useful on GIMPLE. 8113 8114 Finally, there are some higher-level loop transformations implemented. 8115 While some of them are written so that they should work on non-innermost 8116 loops, they are mostly untested in that case, and at the moment, they 8117 are only reliable for the innermost loops: 8118 8119 * `create_iv': Creates a new induction variable. Only works on 8120 GIMPLE. `standard_iv_increment_position' can be used to find a 8121 suitable place for the iv increment. 8122 8123 * `duplicate_loop_to_header_edge', 8124 `tree_duplicate_loop_to_header_edge': These functions (on RTL and 8125 on GIMPLE) duplicate the body of the loop prescribed number of 8126 times on one of the edges entering loop header, thus performing 8127 either loop unrolling or loop peeling. `can_duplicate_loop_p' 8128 (`can_unroll_loop_p' on GIMPLE) must be true for the duplicated 8129 loop. 8130 8131 * `loop_version', `tree_ssa_loop_version': These function create a 8132 copy of a loop, and a branch before them that selects one of them 8133 depending on the prescribed condition. This is useful for 8134 optimizations that need to verify some assumptions in runtime (one 8135 of the copies of the loop is usually left unchanged, while the 8136 other one is transformed in some way). 8137 8138 * `tree_unroll_loop': Unrolls the loop, including peeling the extra 8139 iterations to make the number of iterations divisible by unroll 8140 factor, updating the exit condition, and removing the exits that 8141 now cannot be taken. Works only on GIMPLE. 8142 8143 8144 File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation 8145 8146 11.4 Loop-closed SSA form 8147 ========================= 8148 8149 Throughout the loop optimizations on tree level, one extra condition is 8150 enforced on the SSA form: No SSA name is used outside of the loop in 8151 that it is defined. The SSA form satisfying this condition is called 8152 "loop-closed SSA form" - LCSSA. To enforce LCSSA, PHI nodes must be 8153 created at the exits of the loops for the SSA names that are used 8154 outside of them. Only the real operands (not virtual SSA names) are 8155 held in LCSSA, in order to save memory. 8156 8157 There are various benefits of LCSSA: 8158 8159 * Many optimizations (value range analysis, final value replacement) 8160 are interested in the values that are defined in the loop and used 8161 outside of it, i.e., exactly those for that we create new PHI 8162 nodes. 8163 8164 * In induction variable analysis, it is not necessary to specify the 8165 loop in that the analysis should be performed - the scalar 8166 evolution analysis always returns the results with respect to the 8167 loop in that the SSA name is defined. 8168 8169 * It makes updating of SSA form during loop transformations simpler. 8170 Without LCSSA, operations like loop unrolling may force creation 8171 of PHI nodes arbitrarily far from the loop, while in LCSSA, the 8172 SSA form can be updated locally. However, since we only keep real 8173 operands in LCSSA, we cannot use this advantage (we could have 8174 local updating of real operands, but it is not much more efficient 8175 than to use generic SSA form updating for it as well; the amount 8176 of changes to SSA is the same). 8177 8178 However, it also means LCSSA must be updated. This is usually 8179 straightforward, unless you create a new value in loop and use it 8180 outside, or unless you manipulate loop exit edges (functions are 8181 provided to make these manipulations simple). 8182 `rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA, 8183 and `verify_loop_closed_ssa' to check that the invariant of LCSSA is 8184 preserved. 8185 8186 8187 File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation 8188 8189 11.5 Scalar evolutions 8190 ====================== 8191 8192 Scalar evolutions (SCEV) are used to represent results of induction 8193 variable analysis on GIMPLE. They enable us to represent variables with 8194 complicated behavior in a simple and consistent way (we only use it to 8195 express values of polynomial induction variables, but it is possible to 8196 extend it). The interfaces to SCEV analysis are declared in 8197 `tree-scalar-evolution.h'. To use scalar evolutions analysis, 8198 `scev_initialize' must be used. To stop using SCEV, `scev_finalize' 8199 should be used. SCEV analysis caches results in order to save time and 8200 memory. This cache however is made invalid by most of the loop 8201 transformations, including removal of code. If such a transformation 8202 is performed, `scev_reset' must be called to clean the caches. 8203 8204 Given an SSA name, its behavior in loops can be analyzed using the 8205 `analyze_scalar_evolution' function. The returned SCEV however does 8206 not have to be fully analyzed and it may contain references to other 8207 SSA names defined in the loop. To resolve these (potentially 8208 recursive) references, `instantiate_parameters' or `resolve_mixers' 8209 functions must be used. `instantiate_parameters' is useful when you 8210 use the results of SCEV only for some analysis, and when you work with 8211 whole nest of loops at once. It will try replacing all SSA names by 8212 their SCEV in all loops, including the super-loops of the current loop, 8213 thus providing a complete information about the behavior of the 8214 variable in the loop nest. `resolve_mixers' is useful if you work with 8215 only one loop at a time, and if you possibly need to create code based 8216 on the value of the induction variable. It will only resolve the SSA 8217 names defined in the current loop, leaving the SSA names defined 8218 outside unchanged, even if their evolution in the outer loops is known. 8219 8220 The SCEV is a normal tree expression, except for the fact that it may 8221 contain several special tree nodes. One of them is `SCEV_NOT_KNOWN', 8222 used for SSA names whose value cannot be expressed. The other one is 8223 `POLYNOMIAL_CHREC'. Polynomial chrec has three arguments - base, step 8224 and loop (both base and step may contain further polynomial chrecs). 8225 Type of the expression and of base and step must be the same. A 8226 variable has evolution `POLYNOMIAL_CHREC(base, step, loop)' if it is 8227 (in the specified loop) equivalent to `x_1' in the following example 8228 8229 while (...) 8230 { 8231 x_1 = phi (base, x_2); 8232 x_2 = x_1 + step; 8233 } 8234 8235 Note that this includes the language restrictions on the operations. 8236 For example, if we compile C code and `x' has signed type, then the 8237 overflow in addition would cause undefined behavior, and we may assume 8238 that this does not happen. Hence, the value with this SCEV cannot 8239 overflow (which restricts the number of iterations of such a loop). 8240 8241 In many cases, one wants to restrict the attention just to affine 8242 induction variables. In this case, the extra expressive power of SCEV 8243 is not useful, and may complicate the optimizations. In this case, 8244 `simple_iv' function may be used to analyze a value - the result is a 8245 loop-invariant base and step. 8246 8247 8248 File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation 8249 8250 11.6 IV analysis on RTL 8251 ======================= 8252 8253 The induction variable on RTL is simple and only allows analysis of 8254 affine induction variables, and only in one loop at once. The interface 8255 is declared in `cfgloop.h'. Before analyzing induction variables in a 8256 loop L, `iv_analysis_loop_init' function must be called on L. After 8257 the analysis (possibly calling `iv_analysis_loop_init' for several 8258 loops) is finished, `iv_analysis_done' should be called. The following 8259 functions can be used to access the results of the analysis: 8260 8261 * `iv_analyze': Analyzes a single register used in the given insn. 8262 If no use of the register in this insn is found, the following 8263 insns are scanned, so that this function can be called on the insn 8264 returned by get_condition. 8265 8266 * `iv_analyze_result': Analyzes result of the assignment in the 8267 given insn. 8268 8269 * `iv_analyze_expr': Analyzes a more complicated expression. All 8270 its operands are analyzed by `iv_analyze', and hence they must be 8271 used in the specified insn or one of the following insns. 8272 8273 The description of the induction variable is provided in `struct 8274 rtx_iv'. In order to handle subregs, the representation is a bit 8275 complicated; if the value of the `extend' field is not `UNKNOWN', the 8276 value of the induction variable in the i-th iteration is 8277 8278 delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)), 8279 8280 with the following exception: if `first_special' is true, then the 8281 value in the first iteration (when `i' is zero) is `delta + mult * 8282 base'. However, if `extend' is equal to `UNKNOWN', then 8283 `first_special' must be false, `delta' 0, `mult' 1 and the value in the 8284 i-th iteration is 8285 8286 subreg_{mode} (base + i * step) 8287 8288 The function `get_iv_value' can be used to perform these calculations. 8289 8290 8291 File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation 8292 8293 11.7 Number of iterations analysis 8294 ================================== 8295 8296 Both on GIMPLE and on RTL, there are functions available to determine 8297 the number of iterations of a loop, with a similar interface. In many 8298 cases, it is not possible to determine number of iterations 8299 unconditionally - the determined number is correct only if some 8300 assumptions are satisfied. The analysis tries to verify these 8301 conditions using the information contained in the program; if it fails, 8302 the conditions are returned together with the result. The following 8303 information and conditions are provided by the analysis: 8304 8305 * `assumptions': If this condition is false, the rest of the 8306 information is invalid. 8307 8308 * `noloop_assumptions' on RTL, `may_be_zero' on GIMPLE: If this 8309 condition is true, the loop exits in the first iteration. 8310 8311 * `infinite': If this condition is true, the loop is infinite. This 8312 condition is only available on RTL. On GIMPLE, conditions for 8313 finiteness of the loop are included in `assumptions'. 8314 8315 * `niter_expr' on RTL, `niter' on GIMPLE: The expression that gives 8316 number of iterations. The number of iterations is defined as the 8317 number of executions of the loop latch. 8318 8319 Both on GIMPLE and on RTL, it necessary for the induction variable 8320 analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL). 8321 On GIMPLE, the results are stored to `struct tree_niter_desc' 8322 structure. Number of iterations before the loop is exited through a 8323 given exit can be determined using `number_of_iterations_exit' 8324 function. On RTL, the results are returned in `struct niter_desc' 8325 structure. The corresponding function is named `check_simple_exit'. 8326 There are also functions that pass through all the exits of a loop and 8327 try to find one with easy to determine number of iterations - 8328 `find_loop_niter' on GIMPLE and `find_simple_exit' on RTL. Finally, 8329 there are functions that provide the same information, but additionally 8330 cache it, so that repeated calls to number of iterations are not so 8331 costly - `number_of_iterations_in_loop' on GIMPLE and 8332 `get_simple_loop_desc' on RTL. 8333 8334 Note that some of these functions may behave slightly differently than 8335 others - some of them return only the expression for the number of 8336 iterations, and fail if there are some assumptions. The function 8337 `number_of_iterations_in_loop' works only for single-exit loops, and it 8338 returns the value for number of iterations higher by one with respect 8339 to all other functions (i.e., it returns number of executions of the 8340 exit statement, not of the loop latch). 8341 8342 8343 File: gccint.info, Node: Dependency analysis, Next: Lambda, Prev: Number of iterations, Up: Loop Analysis and Representation 8344 8345 11.8 Data Dependency Analysis 8346 ============================= 8347 8348 The code for the data dependence analysis can be found in 8349 `tree-data-ref.c' and its interface and data structures are described 8350 in `tree-data-ref.h'. The function that computes the data dependences 8351 for all the array and pointer references for a given loop is 8352 `compute_data_dependences_for_loop'. This function is currently used 8353 by the linear loop transform and the vectorization passes. Before 8354 calling this function, one has to allocate two vectors: a first vector 8355 will contain the set of data references that are contained in the 8356 analyzed loop body, and the second vector will contain the dependence 8357 relations between the data references. Thus if the vector of data 8358 references is of size `n', the vector containing the dependence 8359 relations will contain `n*n' elements. However if the analyzed loop 8360 contains side effects, such as calls that potentially can interfere 8361 with the data references in the current analyzed loop, the analysis 8362 stops while scanning the loop body for data references, and inserts a 8363 single `chrec_dont_know' in the dependence relation array. 8364 8365 The data references are discovered in a particular order during the 8366 scanning of the loop body: the loop body is analyzed in execution order, 8367 and the data references of each statement are pushed at the end of the 8368 data reference array. Two data references syntactically occur in the 8369 program in the same order as in the array of data references. This 8370 syntactic order is important in some classical data dependence tests, 8371 and mapping this order to the elements of this array avoids costly 8372 queries to the loop body representation. 8373 8374 Three types of data references are currently handled: ARRAY_REF, 8375 INDIRECT_REF and COMPONENT_REF. The data structure for the data 8376 reference is `data_reference', where `data_reference_p' is a name of a 8377 pointer to the data reference structure. The structure contains the 8378 following elements: 8379 8380 * `base_object_info': Provides information about the base object of 8381 the data reference and its access functions. These access functions 8382 represent the evolution of the data reference in the loop relative 8383 to its base, in keeping with the classical meaning of the data 8384 reference access function for the support of arrays. For example, 8385 for a reference `a.b[i][j]', the base object is `a.b' and the 8386 access functions, one for each array subscript, are: `{i_init, + 8387 i_step}_1, {j_init, +, j_step}_2'. 8388 8389 * `first_location_in_loop': Provides information about the first 8390 location accessed by the data reference in the loop and about the 8391 access function used to represent evolution relative to this 8392 location. This data is used to support pointers, and is not used 8393 for arrays (for which we have base objects). Pointer accesses are 8394 represented as a one-dimensional access that starts from the first 8395 location accessed in the loop. For example: 8396 8397 for1 i 8398 for2 j 8399 *((int *)p + i + j) = a[i][j]; 8400 8401 The access function of the pointer access is `{0, + 4B}_for2' 8402 relative to `p + i'. The access functions of the array are 8403 `{i_init, + i_step}_for1' and `{j_init, +, j_step}_for2' relative 8404 to `a'. 8405 8406 Usually, the object the pointer refers to is either unknown, or we 8407 can't prove that the access is confined to the boundaries of a 8408 certain object. 8409 8410 Two data references can be compared only if at least one of these 8411 two representations has all its fields filled for both data 8412 references. 8413 8414 The current strategy for data dependence tests is as follows: If 8415 both `a' and `b' are represented as arrays, compare 8416 `a.base_object' and `b.base_object'; if they are equal, apply 8417 dependence tests (use access functions based on base_objects). 8418 Else if both `a' and `b' are represented as pointers, compare 8419 `a.first_location' and `b.first_location'; if they are equal, 8420 apply dependence tests (use access functions based on first 8421 location). However, if `a' and `b' are represented differently, 8422 only try to prove that the bases are definitely different. 8423 8424 * Aliasing information. 8425 8426 * Alignment information. 8427 8428 The structure describing the relation between two data references is 8429 `data_dependence_relation' and the shorter name for a pointer to such a 8430 structure is `ddr_p'. This structure contains: 8431 8432 * a pointer to each data reference, 8433 8434 * a tree node `are_dependent' that is set to `chrec_known' if the 8435 analysis has proved that there is no dependence between these two 8436 data references, `chrec_dont_know' if the analysis was not able to 8437 determine any useful result and potentially there could exist a 8438 dependence between these data references, and `are_dependent' is 8439 set to `NULL_TREE' if there exist a dependence relation between the 8440 data references, and the description of this dependence relation is 8441 given in the `subscripts', `dir_vects', and `dist_vects' arrays, 8442 8443 * a boolean that determines whether the dependence relation can be 8444 represented by a classical distance vector, 8445 8446 * an array `subscripts' that contains a description of each 8447 subscript of the data references. Given two array accesses a 8448 subscript is the tuple composed of the access functions for a given 8449 dimension. For example, given `A[f1][f2][f3]' and 8450 `B[g1][g2][g3]', there are three subscripts: `(f1, g1), (f2, g2), 8451 (f3, g3)'. 8452 8453 * two arrays `dir_vects' and `dist_vects' that contain classical 8454 representations of the data dependences under the form of 8455 direction and distance dependence vectors, 8456 8457 * an array of loops `loop_nest' that contains the loops to which the 8458 distance and direction vectors refer to. 8459 8460 Several functions for pretty printing the information extracted by the 8461 data dependence analysis are available: `dump_ddrs' prints with a 8462 maximum verbosity the details of a data dependence relations array, 8463 `dump_dist_dir_vectors' prints only the classical distance and 8464 direction vectors for a data dependence relations array, and 8465 `dump_data_references' prints the details of the data references 8466 contained in a data reference array. 8467 8468 8469 File: gccint.info, Node: Lambda, Prev: Dependency analysis, Up: Loop Analysis and Representation 8470 8471 11.9 Linear loop transformations framework 8472 ========================================== 8473 8474 Lambda is a framework that allows transformations of loops using 8475 non-singular matrix based transformations of the iteration space and 8476 loop bounds. This allows compositions of skewing, scaling, interchange, 8477 and reversal transformations. These transformations are often used to 8478 improve cache behavior or remove inner loop dependencies to allow 8479 parallelization and vectorization to take place. 8480 8481 To perform these transformations, Lambda requires that the loopnest be 8482 converted into a internal form that can be matrix transformed easily. 8483 To do this conversion, the function `gcc_loopnest_to_lambda_loopnest' 8484 is provided. If the loop cannot be transformed using lambda, this 8485 function will return NULL. 8486 8487 Once a `lambda_loopnest' is obtained from the conversion function, it 8488 can be transformed by using `lambda_loopnest_transform', which takes a 8489 transformation matrix to apply. Note that it is up to the caller to 8490 verify that the transformation matrix is legal to apply to the loop 8491 (dependence respecting, etc). Lambda simply applies whatever matrix it 8492 is told to provide. It can be extended to make legal matrices out of 8493 any non-singular matrix, but this is not currently implemented. 8494 Legality of a matrix for a given loopnest can be verified using 8495 `lambda_transform_legal_p'. 8496 8497 Given a transformed loopnest, conversion back into gcc IR is done by 8498 `lambda_loopnest_to_gcc_loopnest'. This function will modify the loops 8499 so that they match the transformed loopnest. 8500 8501 8502 File: gccint.info, Node: RTL, Next: Control Flow, Prev: Trees, Up: Top 8503 8504 12 RTL Representation 8505 ********************* 8506 8507 Most of the work of the compiler is done on an intermediate 8508 representation called register transfer language. In this language, 8509 the instructions to be output are described, pretty much one by one, in 8510 an algebraic form that describes what the instruction does. 8511 8512 RTL is inspired by Lisp lists. It has both an internal form, made up 8513 of structures that point at other structures, and a textual form that 8514 is used in the machine description and in printed debugging dumps. The 8515 textual form uses nested parentheses to indicate the pointers in the 8516 internal form. 8517 8518 * Menu: 8519 8520 * RTL Objects:: Expressions vs vectors vs strings vs integers. 8521 * RTL Classes:: Categories of RTL expression objects, and their structure. 8522 * Accessors:: Macros to access expression operands or vector elts. 8523 * Special Accessors:: Macros to access specific annotations on RTL. 8524 * Flags:: Other flags in an RTL expression. 8525 * Machine Modes:: Describing the size and format of a datum. 8526 * Constants:: Expressions with constant values. 8527 * Regs and Memory:: Expressions representing register contents or memory. 8528 * Arithmetic:: Expressions representing arithmetic on other expressions. 8529 * Comparisons:: Expressions representing comparison of expressions. 8530 * Bit-Fields:: Expressions representing bit-fields in memory or reg. 8531 * Vector Operations:: Expressions involving vector datatypes. 8532 * Conversions:: Extending, truncating, floating or fixing. 8533 * RTL Declarations:: Declaring volatility, constancy, etc. 8534 * Side Effects:: Expressions for storing in registers, etc. 8535 * Incdec:: Embedded side-effects for autoincrement addressing. 8536 * Assembler:: Representing `asm' with operands. 8537 * Insns:: Expression types for entire insns. 8538 * Calls:: RTL representation of function call insns. 8539 * Sharing:: Some expressions are unique; others *must* be copied. 8540 * Reading RTL:: Reading textual RTL from a file. 8541 8542 8543 File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL 8544 8545 12.1 RTL Object Types 8546 ===================== 8547 8548 RTL uses five kinds of objects: expressions, integers, wide integers, 8549 strings and vectors. Expressions are the most important ones. An RTL 8550 expression ("RTX", for short) is a C structure, but it is usually 8551 referred to with a pointer; a type that is given the typedef name `rtx'. 8552 8553 An integer is simply an `int'; their written form uses decimal digits. 8554 A wide integer is an integral object whose type is `HOST_WIDE_INT'; 8555 their written form uses decimal digits. 8556 8557 A string is a sequence of characters. In core it is represented as a 8558 `char *' in usual C fashion, and it is written in C syntax as well. 8559 However, strings in RTL may never be null. If you write an empty 8560 string in a machine description, it is represented in core as a null 8561 pointer rather than as a pointer to a null character. In certain 8562 contexts, these null pointers instead of strings are valid. Within RTL 8563 code, strings are most commonly found inside `symbol_ref' expressions, 8564 but they appear in other contexts in the RTL expressions that make up 8565 machine descriptions. 8566 8567 In a machine description, strings are normally written with double 8568 quotes, as you would in C. However, strings in machine descriptions may 8569 extend over many lines, which is invalid C, and adjacent string 8570 constants are not concatenated as they are in C. Any string constant 8571 may be surrounded with a single set of parentheses. Sometimes this 8572 makes the machine description easier to read. 8573 8574 There is also a special syntax for strings, which can be useful when C 8575 code is embedded in a machine description. Wherever a string can 8576 appear, it is also valid to write a C-style brace block. The entire 8577 brace block, including the outermost pair of braces, is considered to be 8578 the string constant. Double quote characters inside the braces are not 8579 special. Therefore, if you write string constants in the C code, you 8580 need not escape each quote character with a backslash. 8581 8582 A vector contains an arbitrary number of pointers to expressions. The 8583 number of elements in the vector is explicitly present in the vector. 8584 The written form of a vector consists of square brackets (`[...]') 8585 surrounding the elements, in sequence and with whitespace separating 8586 them. Vectors of length zero are not created; null pointers are used 8587 instead. 8588 8589 Expressions are classified by "expression codes" (also called RTX 8590 codes). The expression code is a name defined in `rtl.def', which is 8591 also (in uppercase) a C enumeration constant. The possible expression 8592 codes and their meanings are machine-independent. The code of an RTX 8593 can be extracted with the macro `GET_CODE (X)' and altered with 8594 `PUT_CODE (X, NEWCODE)'. 8595 8596 The expression code determines how many operands the expression 8597 contains, and what kinds of objects they are. In RTL, unlike Lisp, you 8598 cannot tell by looking at an operand what kind of object it is. 8599 Instead, you must know from its context--from the expression code of 8600 the containing expression. For example, in an expression of code 8601 `subreg', the first operand is to be regarded as an expression and the 8602 second operand as an integer. In an expression of code `plus', there 8603 are two operands, both of which are to be regarded as expressions. In 8604 a `symbol_ref' expression, there is one operand, which is to be 8605 regarded as a string. 8606 8607 Expressions are written as parentheses containing the name of the 8608 expression type, its flags and machine mode if any, and then the 8609 operands of the expression (separated by spaces). 8610 8611 Expression code names in the `md' file are written in lowercase, but 8612 when they appear in C code they are written in uppercase. In this 8613 manual, they are shown as follows: `const_int'. 8614 8615 In a few contexts a null pointer is valid where an expression is 8616 normally wanted. The written form of this is `(nil)'. 8617 8618 8619 File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL 8620 8621 12.2 RTL Classes and Formats 8622 ============================ 8623 8624 The various expression codes are divided into several "classes", which 8625 are represented by single characters. You can determine the class of 8626 an RTX code with the macro `GET_RTX_CLASS (CODE)'. Currently, 8627 `rtl.def' defines these classes: 8628 8629 `RTX_OBJ' 8630 An RTX code that represents an actual object, such as a register 8631 (`REG') or a memory location (`MEM', `SYMBOL_REF'). `LO_SUM') is 8632 also included; instead, `SUBREG' and `STRICT_LOW_PART' are not in 8633 this class, but in class `x'. 8634 8635 `RTX_CONST_OBJ' 8636 An RTX code that represents a constant object. `HIGH' is also 8637 included in this class. 8638 8639 `RTX_COMPARE' 8640 An RTX code for a non-symmetric comparison, such as `GEU' or `LT'. 8641 8642 `RTX_COMM_COMPARE' 8643 An RTX code for a symmetric (commutative) comparison, such as `EQ' 8644 or `ORDERED'. 8645 8646 `RTX_UNARY' 8647 An RTX code for a unary arithmetic operation, such as `NEG', 8648 `NOT', or `ABS'. This category also includes value extension 8649 (sign or zero) and conversions between integer and floating point. 8650 8651 `RTX_COMM_ARITH' 8652 An RTX code for a commutative binary operation, such as `PLUS' or 8653 `AND'. `NE' and `EQ' are comparisons, so they have class `<'. 8654 8655 `RTX_BIN_ARITH' 8656 An RTX code for a non-commutative binary operation, such as 8657 `MINUS', `DIV', or `ASHIFTRT'. 8658 8659 `RTX_BITFIELD_OPS' 8660 An RTX code for a bit-field operation. Currently only 8661 `ZERO_EXTRACT' and `SIGN_EXTRACT'. These have three inputs and 8662 are lvalues (so they can be used for insertion as well). *Note 8663 Bit-Fields::. 8664 8665 `RTX_TERNARY' 8666 An RTX code for other three input operations. Currently only 8667 `IF_THEN_ELSE' and `VEC_MERGE'. 8668 8669 `RTX_INSN' 8670 An RTX code for an entire instruction: `INSN', `JUMP_INSN', and 8671 `CALL_INSN'. *Note Insns::. 8672 8673 `RTX_MATCH' 8674 An RTX code for something that matches in insns, such as 8675 `MATCH_DUP'. These only occur in machine descriptions. 8676 8677 `RTX_AUTOINC' 8678 An RTX code for an auto-increment addressing mode, such as 8679 `POST_INC'. 8680 8681 `RTX_EXTRA' 8682 All other RTX codes. This category includes the remaining codes 8683 used only in machine descriptions (`DEFINE_*', etc.). It also 8684 includes all the codes describing side effects (`SET', `USE', 8685 `CLOBBER', etc.) and the non-insns that may appear on an insn 8686 chain, such as `NOTE', `BARRIER', and `CODE_LABEL'. `SUBREG' is 8687 also part of this class. 8688 8689 For each expression code, `rtl.def' specifies the number of contained 8690 objects and their kinds using a sequence of characters called the 8691 "format" of the expression code. For example, the format of `subreg' 8692 is `ei'. 8693 8694 These are the most commonly used format characters: 8695 8696 `e' 8697 An expression (actually a pointer to an expression). 8698 8699 `i' 8700 An integer. 8701 8702 `w' 8703 A wide integer. 8704 8705 `s' 8706 A string. 8707 8708 `E' 8709 A vector of expressions. 8710 8711 A few other format characters are used occasionally: 8712 8713 `u' 8714 `u' is equivalent to `e' except that it is printed differently in 8715 debugging dumps. It is used for pointers to insns. 8716 8717 `n' 8718 `n' is equivalent to `i' except that it is printed differently in 8719 debugging dumps. It is used for the line number or code number of 8720 a `note' insn. 8721 8722 `S' 8723 `S' indicates a string which is optional. In the RTL objects in 8724 core, `S' is equivalent to `s', but when the object is read, from 8725 an `md' file, the string value of this operand may be omitted. An 8726 omitted string is taken to be the null string. 8727 8728 `V' 8729 `V' indicates a vector which is optional. In the RTL objects in 8730 core, `V' is equivalent to `E', but when the object is read from 8731 an `md' file, the vector value of this operand may be omitted. An 8732 omitted vector is effectively the same as a vector of no elements. 8733 8734 `B' 8735 `B' indicates a pointer to basic block structure. 8736 8737 `0' 8738 `0' means a slot whose contents do not fit any normal category. 8739 `0' slots are not printed at all in dumps, and are often used in 8740 special ways by small parts of the compiler. 8741 8742 There are macros to get the number of operands and the format of an 8743 expression code: 8744 8745 `GET_RTX_LENGTH (CODE)' 8746 Number of operands of an RTX of code CODE. 8747 8748 `GET_RTX_FORMAT (CODE)' 8749 The format of an RTX of code CODE, as a C string. 8750 8751 Some classes of RTX codes always have the same format. For example, it 8752 is safe to assume that all comparison operations have format `ee'. 8753 8754 `1' 8755 All codes of this class have format `e'. 8756 8757 `<' 8758 `c' 8759 `2' 8760 All codes of these classes have format `ee'. 8761 8762 `b' 8763 `3' 8764 All codes of these classes have format `eee'. 8765 8766 `i' 8767 All codes of this class have formats that begin with `iuueiee'. 8768 *Note Insns::. Note that not all RTL objects linked onto an insn 8769 chain are of class `i'. 8770 8771 `o' 8772 `m' 8773 `x' 8774 You can make no assumptions about the format of these codes. 8775 8776 8777 File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL 8778 8779 12.3 Access to Operands 8780 ======================= 8781 8782 Operands of expressions are accessed using the macros `XEXP', `XINT', 8783 `XWINT' and `XSTR'. Each of these macros takes two arguments: an 8784 expression-pointer (RTX) and an operand number (counting from zero). 8785 Thus, 8786 8787 XEXP (X, 2) 8788 8789 accesses operand 2 of expression X, as an expression. 8790 8791 XINT (X, 2) 8792 8793 accesses the same operand as an integer. `XSTR', used in the same 8794 fashion, would access it as a string. 8795 8796 Any operand can be accessed as an integer, as an expression or as a 8797 string. You must choose the correct method of access for the kind of 8798 value actually stored in the operand. You would do this based on the 8799 expression code of the containing expression. That is also how you 8800 would know how many operands there are. 8801 8802 For example, if X is a `subreg' expression, you know that it has two 8803 operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X, 8804 1)'. If you did `XINT (X, 0)', you would get the address of the 8805 expression operand but cast as an integer; that might occasionally be 8806 useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP 8807 (X, 1)' would also compile without error, and would return the second, 8808 integer operand cast as an expression pointer, which would probably 8809 result in a crash when accessed. Nothing stops you from writing `XEXP 8810 (X, 28)' either, but this will access memory past the end of the 8811 expression with unpredictable results. 8812 8813 Access to operands which are vectors is more complicated. You can use 8814 the macro `XVEC' to get the vector-pointer itself, or the macros 8815 `XVECEXP' and `XVECLEN' to access the elements and length of a vector. 8816 8817 `XVEC (EXP, IDX)' 8818 Access the vector-pointer which is operand number IDX in EXP. 8819 8820 `XVECLEN (EXP, IDX)' 8821 Access the length (number of elements) in the vector which is in 8822 operand number IDX in EXP. This value is an `int'. 8823 8824 `XVECEXP (EXP, IDX, ELTNUM)' 8825 Access element number ELTNUM in the vector which is in operand 8826 number IDX in EXP. This value is an RTX. 8827 8828 It is up to you to make sure that ELTNUM is not negative and is 8829 less than `XVECLEN (EXP, IDX)'. 8830 8831 All the macros defined in this section expand into lvalues and 8832 therefore can be used to assign the operands, lengths and vector 8833 elements as well as to access them. 8834 8835 8836 File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL 8837 8838 12.4 Access to Special Operands 8839 =============================== 8840 8841 Some RTL nodes have special annotations associated with them. 8842 8843 `MEM' 8844 8845 `MEM_ALIAS_SET (X)' 8846 If 0, X is not in any alias set, and may alias anything. 8847 Otherwise, X can only alias `MEM's in a conflicting alias 8848 set. This value is set in a language-dependent manner in the 8849 front-end, and should not be altered in the back-end. In 8850 some front-ends, these numbers may correspond in some way to 8851 types, or other language-level entities, but they need not, 8852 and the back-end makes no such assumptions. These set 8853 numbers are tested with `alias_sets_conflict_p'. 8854 8855 `MEM_EXPR (X)' 8856 If this register is known to hold the value of some user-level 8857 declaration, this is that tree node. It may also be a 8858 `COMPONENT_REF', in which case this is some field reference, 8859 and `TREE_OPERAND (X, 0)' contains the declaration, or 8860 another `COMPONENT_REF', or null if there is no compile-time 8861 object associated with the reference. 8862 8863 `MEM_OFFSET (X)' 8864 The offset from the start of `MEM_EXPR' as a `CONST_INT' rtx. 8865 8866 `MEM_SIZE (X)' 8867 The size in bytes of the memory reference as a `CONST_INT' 8868 rtx. This is mostly relevant for `BLKmode' references as 8869 otherwise the size is implied by the mode. 8870 8871 `MEM_ALIGN (X)' 8872 The known alignment in bits of the memory reference. 8873 8874 `REG' 8875 8876 `ORIGINAL_REGNO (X)' 8877 This field holds the number the register "originally" had; 8878 for a pseudo register turned into a hard reg this will hold 8879 the old pseudo register number. 8880 8881 `REG_EXPR (X)' 8882 If this register is known to hold the value of some user-level 8883 declaration, this is that tree node. 8884 8885 `REG_OFFSET (X)' 8886 If this register is known to hold the value of some user-level 8887 declaration, this is the offset into that logical storage. 8888 8889 `SYMBOL_REF' 8890 8891 `SYMBOL_REF_DECL (X)' 8892 If the `symbol_ref' X was created for a `VAR_DECL' or a 8893 `FUNCTION_DECL', that tree is recorded here. If this value is 8894 null, then X was created by back end code generation routines, 8895 and there is no associated front end symbol table entry. 8896 8897 `SYMBOL_REF_DECL' may also point to a tree of class `'c'', 8898 that is, some sort of constant. In this case, the 8899 `symbol_ref' is an entry in the per-file constant pool; 8900 again, there is no associated front end symbol table entry. 8901 8902 `SYMBOL_REF_CONSTANT (X)' 8903 If `CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant 8904 pool entry for X. It is null otherwise. 8905 8906 `SYMBOL_REF_DATA (X)' 8907 A field of opaque type used to store `SYMBOL_REF_DECL' or 8908 `SYMBOL_REF_CONSTANT'. 8909 8910 `SYMBOL_REF_FLAGS (X)' 8911 In a `symbol_ref', this is used to communicate various 8912 predicates about the symbol. Some of these are common enough 8913 to be computed by common code, some are specific to the 8914 target. The common bits are: 8915 8916 `SYMBOL_FLAG_FUNCTION' 8917 Set if the symbol refers to a function. 8918 8919 `SYMBOL_FLAG_LOCAL' 8920 Set if the symbol is local to this "module". See 8921 `TARGET_BINDS_LOCAL_P'. 8922 8923 `SYMBOL_FLAG_EXTERNAL' 8924 Set if this symbol is not defined in this translation 8925 unit. Note that this is not the inverse of 8926 `SYMBOL_FLAG_LOCAL'. 8927 8928 `SYMBOL_FLAG_SMALL' 8929 Set if the symbol is located in the small data section. 8930 See `TARGET_IN_SMALL_DATA_P'. 8931 8932 `SYMBOL_REF_TLS_MODEL (X)' 8933 This is a multi-bit field accessor that returns the 8934 `tls_model' to be used for a thread-local storage 8935 symbol. It returns zero for non-thread-local symbols. 8936 8937 `SYMBOL_FLAG_HAS_BLOCK_INFO' 8938 Set if the symbol has `SYMBOL_REF_BLOCK' and 8939 `SYMBOL_REF_BLOCK_OFFSET' fields. 8940 8941 `SYMBOL_FLAG_ANCHOR' 8942 Set if the symbol is used as a section anchor. "Section 8943 anchors" are symbols that have a known position within 8944 an `object_block' and that can be used to access nearby 8945 members of that block. They are used to implement 8946 `-fsection-anchors'. 8947 8948 If this flag is set, then `SYMBOL_FLAG_HAS_BLOCK_INFO' 8949 will be too. 8950 8951 Bits beginning with `SYMBOL_FLAG_MACH_DEP' are available for 8952 the target's use. 8953 8954 `SYMBOL_REF_BLOCK (X)' 8955 If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the `object_block' 8956 structure to which the symbol belongs, or `NULL' if it has not 8957 been assigned a block. 8958 8959 `SYMBOL_REF_BLOCK_OFFSET (X)' 8960 If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from 8961 the first object in `SYMBOL_REF_BLOCK (X)'. The value is negative 8962 if X has not yet been assigned to a block, or it has not been 8963 given an offset within that block. 8964 8965 8966 File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL 8967 8968 12.5 Flags in an RTL Expression 8969 =============================== 8970 8971 RTL expressions contain several flags (one-bit bit-fields) that are 8972 used in certain types of expression. Most often they are accessed with 8973 the following macros, which expand into lvalues. 8974 8975 `CONSTANT_POOL_ADDRESS_P (X)' 8976 Nonzero in a `symbol_ref' if it refers to part of the current 8977 function's constant pool. For most targets these addresses are in 8978 a `.rodata' section entirely separate from the function, but for 8979 some targets the addresses are close to the beginning of the 8980 function. In either case GCC assumes these addresses can be 8981 addressed directly, perhaps with the help of base registers. 8982 Stored in the `unchanging' field and printed as `/u'. 8983 8984 `CONST_OR_PURE_CALL_P (X)' 8985 In a `call_insn', `note', or an `expr_list' for notes, indicates 8986 that the insn represents a call to a const or pure function. 8987 Stored in the `unchanging' field and printed as `/u'. 8988 8989 `INSN_ANNULLED_BRANCH_P (X)' 8990 In a `jump_insn', `call_insn', or `insn' indicates that the branch 8991 is an annulling one. See the discussion under `sequence' below. 8992 Stored in the `unchanging' field and printed as `/u'. 8993 8994 `INSN_DELETED_P (X)' 8995 In an `insn', `call_insn', `jump_insn', `code_label', `barrier', 8996 or `note', nonzero if the insn has been deleted. Stored in the 8997 `volatil' field and printed as `/v'. 8998 8999 `INSN_FROM_TARGET_P (X)' 9000 In an `insn' or `jump_insn' or `call_insn' in a delay slot of a 9001 branch, indicates that the insn is from the target of the branch. 9002 If the branch insn has `INSN_ANNULLED_BRANCH_P' set, this insn 9003 will only be executed if the branch is taken. For annulled 9004 branches with `INSN_FROM_TARGET_P' clear, the insn will be 9005 executed only if the branch is not taken. When 9006 `INSN_ANNULLED_BRANCH_P' is not set, this insn will always be 9007 executed. Stored in the `in_struct' field and printed as `/s'. 9008 9009 `LABEL_PRESERVE_P (X)' 9010 In a `code_label' or `note', indicates that the label is 9011 referenced by code or data not visible to the RTL of a given 9012 function. Labels referenced by a non-local goto will have this 9013 bit set. Stored in the `in_struct' field and printed as `/s'. 9014 9015 `LABEL_REF_NONLOCAL_P (X)' 9016 In `label_ref' and `reg_label' expressions, nonzero if this is a 9017 reference to a non-local label. Stored in the `volatil' field and 9018 printed as `/v'. 9019 9020 `MEM_IN_STRUCT_P (X)' 9021 In `mem' expressions, nonzero for reference to an entire structure, 9022 union or array, or to a component of one. Zero for references to a 9023 scalar variable or through a pointer to a scalar. If both this 9024 flag and `MEM_SCALAR_P' are clear, then we don't know whether this 9025 `mem' is in a structure or not. Both flags should never be 9026 simultaneously set. Stored in the `in_struct' field and printed 9027 as `/s'. 9028 9029 `MEM_KEEP_ALIAS_SET_P (X)' 9030 In `mem' expressions, 1 if we should keep the alias set for this 9031 mem unchanged when we access a component. Set to 1, for example, 9032 when we are already in a non-addressable component of an aggregate. 9033 Stored in the `jump' field and printed as `/j'. 9034 9035 `MEM_SCALAR_P (X)' 9036 In `mem' expressions, nonzero for reference to a scalar known not 9037 to be a member of a structure, union, or array. Zero for such 9038 references and for indirections through pointers, even pointers 9039 pointing to scalar types. If both this flag and `MEM_IN_STRUCT_P' 9040 are clear, then we don't know whether this `mem' is in a structure 9041 or not. Both flags should never be simultaneously set. Stored in 9042 the `frame_related' field and printed as `/f'. 9043 9044 `MEM_VOLATILE_P (X)' 9045 In `mem', `asm_operands', and `asm_input' expressions, nonzero for 9046 volatile memory references. Stored in the `volatil' field and 9047 printed as `/v'. 9048 9049 `MEM_NOTRAP_P (X)' 9050 In `mem', nonzero for memory references that will not trap. 9051 Stored in the `call' field and printed as `/c'. 9052 9053 `REG_FUNCTION_VALUE_P (X)' 9054 Nonzero in a `reg' if it is the place in which this function's 9055 value is going to be returned. (This happens only in a hard 9056 register.) Stored in the `integrated' field and printed as `/i'. 9057 9058 `REG_POINTER (X)' 9059 Nonzero in a `reg' if the register holds a pointer. Stored in the 9060 `frame_related' field and printed as `/f'. 9061 9062 `REG_USERVAR_P (X)' 9063 In a `reg', nonzero if it corresponds to a variable present in the 9064 user's source code. Zero for temporaries generated internally by 9065 the compiler. Stored in the `volatil' field and printed as `/v'. 9066 9067 The same hard register may be used also for collecting the values 9068 of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero 9069 in this kind of use. 9070 9071 `RTX_FRAME_RELATED_P (X)' 9072 Nonzero in an `insn', `call_insn', `jump_insn', `barrier', or 9073 `set' which is part of a function prologue and sets the stack 9074 pointer, sets the frame pointer, or saves a register. This flag 9075 should also be set on an instruction that sets up a temporary 9076 register to use in place of the frame pointer. Stored in the 9077 `frame_related' field and printed as `/f'. 9078 9079 In particular, on RISC targets where there are limits on the sizes 9080 of immediate constants, it is sometimes impossible to reach the 9081 register save area directly from the stack pointer. In that case, 9082 a temporary register is used that is near enough to the register 9083 save area, and the Canonical Frame Address, i.e., DWARF2's logical 9084 frame pointer, register must (temporarily) be changed to be this 9085 temporary register. So, the instruction that sets this temporary 9086 register must be marked as `RTX_FRAME_RELATED_P'. 9087 9088 If the marked instruction is overly complex (defined in terms of 9089 what `dwarf2out_frame_debug_expr' can handle), you will also have 9090 to create a `REG_FRAME_RELATED_EXPR' note and attach it to the 9091 instruction. This note should contain a simple expression of the 9092 computation performed by this instruction, i.e., one that 9093 `dwarf2out_frame_debug_expr' can handle. 9094 9095 This flag is required for exception handling support on targets 9096 with RTL prologues. 9097 9098 `code_label', `insn_list', `const', or `note' if it resulted from 9099 an in-line function call. Stored in the `integrated' field and 9100 printed as `/i'. 9101 9102 `MEM_READONLY_P (X)' 9103 Nonzero in a `mem', if the memory is statically allocated and 9104 read-only. 9105 9106 Read-only in this context means never modified during the lifetime 9107 of the program, not necessarily in ROM or in write-disabled pages. 9108 A common example of the later is a shared library's global offset 9109 table. This table is initialized by the runtime loader, so the 9110 memory is technically writable, but after control is transfered 9111 from the runtime loader to the application, this memory will never 9112 be subsequently modified. 9113 9114 Stored in the `unchanging' field and printed as `/u'. 9115 9116 `SCHED_GROUP_P (X)' 9117 During instruction scheduling, in an `insn', `call_insn' or 9118 `jump_insn', indicates that the previous insn must be scheduled 9119 together with this insn. This is used to ensure that certain 9120 groups of instructions will not be split up by the instruction 9121 scheduling pass, for example, `use' insns before a `call_insn' may 9122 not be separated from the `call_insn'. Stored in the `in_struct' 9123 field and printed as `/s'. 9124 9125 `SET_IS_RETURN_P (X)' 9126 For a `set', nonzero if it is for a return. Stored in the `jump' 9127 field and printed as `/j'. 9128 9129 `SIBLING_CALL_P (X)' 9130 For a `call_insn', nonzero if the insn is a sibling call. Stored 9131 in the `jump' field and printed as `/j'. 9132 9133 `STRING_POOL_ADDRESS_P (X)' 9134 For a `symbol_ref' expression, nonzero if it addresses this 9135 function's string constant pool. Stored in the `frame_related' 9136 field and printed as `/f'. 9137 9138 `SUBREG_PROMOTED_UNSIGNED_P (X)' 9139 Returns a value greater then zero for a `subreg' that has 9140 `SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is 9141 kept zero-extended, zero if it is kept sign-extended, and less 9142 then zero if it is extended some other way via the `ptr_extend' 9143 instruction. Stored in the `unchanging' field and `volatil' 9144 field, printed as `/u' and `/v'. This macro may only be used to 9145 get the value it may not be used to change the value. Use 9146 `SUBREG_PROMOTED_UNSIGNED_SET' to change the value. 9147 9148 `SUBREG_PROMOTED_UNSIGNED_SET (X)' 9149 Set the `unchanging' and `volatil' fields in a `subreg' to reflect 9150 zero, sign, or other extension. If `volatil' is zero, then 9151 `unchanging' as nonzero means zero extension and as zero means 9152 sign extension. If `volatil' is nonzero then some other type of 9153 extension was done via the `ptr_extend' instruction. 9154 9155 `SUBREG_PROMOTED_VAR_P (X)' 9156 Nonzero in a `subreg' if it was made when accessing an object that 9157 was promoted to a wider mode in accord with the `PROMOTED_MODE' 9158 machine description macro (*note Storage Layout::). In this case, 9159 the mode of the `subreg' is the declared mode of the object and 9160 the mode of `SUBREG_REG' is the mode of the register that holds 9161 the object. Promoted variables are always either sign- or 9162 zero-extended to the wider mode on every assignment. Stored in 9163 the `in_struct' field and printed as `/s'. 9164 9165 `SYMBOL_REF_USED (X)' 9166 In a `symbol_ref', indicates that X has been used. This is 9167 normally only used to ensure that X is only declared external 9168 once. Stored in the `used' field. 9169 9170 `SYMBOL_REF_WEAK (X)' 9171 In a `symbol_ref', indicates that X has been declared weak. 9172 Stored in the `integrated' field and printed as `/i'. 9173 9174 `SYMBOL_REF_FLAG (X)' 9175 In a `symbol_ref', this is used as a flag for machine-specific 9176 purposes. Stored in the `volatil' field and printed as `/v'. 9177 9178 Most uses of `SYMBOL_REF_FLAG' are historic and may be subsumed by 9179 `SYMBOL_REF_FLAGS'. Certainly use of `SYMBOL_REF_FLAGS' is 9180 mandatory if the target requires more than one bit of storage. 9181 9182 These are the fields to which the above macros refer: 9183 9184 `call' 9185 In a `mem', 1 means that the memory reference will not trap. 9186 9187 In an RTL dump, this flag is represented as `/c'. 9188 9189 `frame_related' 9190 In an `insn' or `set' expression, 1 means that it is part of a 9191 function prologue and sets the stack pointer, sets the frame 9192 pointer, saves a register, or sets up a temporary register to use 9193 in place of the frame pointer. 9194 9195 In `reg' expressions, 1 means that the register holds a pointer. 9196 9197 In `symbol_ref' expressions, 1 means that the reference addresses 9198 this function's string constant pool. 9199 9200 In `mem' expressions, 1 means that the reference is to a scalar. 9201 9202 In an RTL dump, this flag is represented as `/f'. 9203 9204 `in_struct' 9205 In `mem' expressions, it is 1 if the memory datum referred to is 9206 all or part of a structure or array; 0 if it is (or might be) a 9207 scalar variable. A reference through a C pointer has 0 because 9208 the pointer might point to a scalar variable. This information 9209 allows the compiler to determine something about possible cases of 9210 aliasing. 9211 9212 In `reg' expressions, it is 1 if the register has its entire life 9213 contained within the test expression of some loop. 9214 9215 In `subreg' expressions, 1 means that the `subreg' is accessing an 9216 object that has had its mode promoted from a wider mode. 9217 9218 In `label_ref' expressions, 1 means that the referenced label is 9219 outside the innermost loop containing the insn in which the 9220 `label_ref' was found. 9221 9222 In `code_label' expressions, it is 1 if the label may never be 9223 deleted. This is used for labels which are the target of 9224 non-local gotos. Such a label that would have been deleted is 9225 replaced with a `note' of type `NOTE_INSN_DELETED_LABEL'. 9226 9227 In an `insn' during dead-code elimination, 1 means that the insn is 9228 dead code. 9229 9230 In an `insn' or `jump_insn' during reorg for an insn in the delay 9231 slot of a branch, 1 means that this insn is from the target of the 9232 branch. 9233 9234 In an `insn' during instruction scheduling, 1 means that this insn 9235 must be scheduled as part of a group together with the previous 9236 insn. 9237 9238 In an RTL dump, this flag is represented as `/s'. 9239 9240 `integrated' 9241 In an `insn', `insn_list', or `const', 1 means the RTL was 9242 produced by procedure integration. 9243 9244 In `reg' expressions, 1 means the register contains the value to 9245 be returned by the current function. On machines that pass 9246 parameters in registers, the same register number may be used for 9247 parameters as well, but this flag is not set on such uses. 9248 9249 In `symbol_ref' expressions, 1 means the referenced symbol is weak. 9250 9251 In an RTL dump, this flag is represented as `/i'. 9252 9253 `jump' 9254 In a `mem' expression, 1 means we should keep the alias set for 9255 this mem unchanged when we access a component. 9256 9257 In a `set', 1 means it is for a return. 9258 9259 In a `call_insn', 1 means it is a sibling call. 9260 9261 In an RTL dump, this flag is represented as `/j'. 9262 9263 `unchanging' 9264 In `reg' and `mem' expressions, 1 means that the value of the 9265 expression never changes. 9266 9267 In `subreg' expressions, it is 1 if the `subreg' references an 9268 unsigned object whose mode has been promoted to a wider mode. 9269 9270 In an `insn' or `jump_insn' in the delay slot of a branch 9271 instruction, 1 means an annulling branch should be used. 9272 9273 In a `symbol_ref' expression, 1 means that this symbol addresses 9274 something in the per-function constant pool. 9275 9276 In a `call_insn', `note', or an `expr_list' of notes, 1 means that 9277 this instruction is a call to a const or pure function. 9278 9279 In an RTL dump, this flag is represented as `/u'. 9280 9281 `used' 9282 This flag is used directly (without an access macro) at the end of 9283 RTL generation for a function, to count the number of times an 9284 expression appears in insns. Expressions that appear more than 9285 once are copied, according to the rules for shared structure 9286 (*note Sharing::). 9287 9288 For a `reg', it is used directly (without an access macro) by the 9289 leaf register renumbering code to ensure that each register is only 9290 renumbered once. 9291 9292 In a `symbol_ref', it indicates that an external declaration for 9293 the symbol has already been written. 9294 9295 `volatil' 9296 In a `mem', `asm_operands', or `asm_input' expression, it is 1 if 9297 the memory reference is volatile. Volatile memory references may 9298 not be deleted, reordered or combined. 9299 9300 In a `symbol_ref' expression, it is used for machine-specific 9301 purposes. 9302 9303 In a `reg' expression, it is 1 if the value is a user-level 9304 variable. 0 indicates an internal compiler temporary. 9305 9306 In an `insn', 1 means the insn has been deleted. 9307 9308 In `label_ref' and `reg_label' expressions, 1 means a reference to 9309 a non-local label. 9310 9311 In an RTL dump, this flag is represented as `/v'. 9312 9313 9314 File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 9315 9316 12.6 Machine Modes 9317 ================== 9318 9319 A machine mode describes a size of data object and the representation 9320 used for it. In the C code, machine modes are represented by an 9321 enumeration type, `enum machine_mode', defined in `machmode.def'. Each 9322 RTL expression has room for a machine mode and so do certain kinds of 9323 tree expressions (declarations and types, to be precise). 9324 9325 In debugging dumps and machine descriptions, the machine mode of an RTL 9326 expression is written after the expression code with a colon to separate 9327 them. The letters `mode' which appear at the end of each machine mode 9328 name are omitted. For example, `(reg:SI 38)' is a `reg' expression 9329 with machine mode `SImode'. If the mode is `VOIDmode', it is not 9330 written at all. 9331 9332 Here is a table of machine modes. The term "byte" below refers to an 9333 object of `BITS_PER_UNIT' bits (*note Storage Layout::). 9334 9335 `BImode' 9336 "Bit" mode represents a single bit, for predicate registers. 9337 9338 `QImode' 9339 "Quarter-Integer" mode represents a single byte treated as an 9340 integer. 9341 9342 `HImode' 9343 "Half-Integer" mode represents a two-byte integer. 9344 9345 `PSImode' 9346 "Partial Single Integer" mode represents an integer which occupies 9347 four bytes but which doesn't really use all four. On some 9348 machines, this is the right mode to use for pointers. 9349 9350 `SImode' 9351 "Single Integer" mode represents a four-byte integer. 9352 9353 `PDImode' 9354 "Partial Double Integer" mode represents an integer which occupies 9355 eight bytes but which doesn't really use all eight. On some 9356 machines, this is the right mode to use for certain pointers. 9357 9358 `DImode' 9359 "Double Integer" mode represents an eight-byte integer. 9360 9361 `TImode' 9362 "Tetra Integer" (?) mode represents a sixteen-byte integer. 9363 9364 `OImode' 9365 "Octa Integer" (?) mode represents a thirty-two-byte integer. 9366 9367 `QFmode' 9368 "Quarter-Floating" mode represents a quarter-precision (single 9369 byte) floating point number. 9370 9371 `HFmode' 9372 "Half-Floating" mode represents a half-precision (two byte) 9373 floating point number. 9374 9375 `TQFmode' 9376 "Three-Quarter-Floating" (?) mode represents a 9377 three-quarter-precision (three byte) floating point number. 9378 9379 `SFmode' 9380 "Single Floating" mode represents a four byte floating point 9381 number. In the common case, of a processor with IEEE arithmetic 9382 and 8-bit bytes, this is a single-precision IEEE floating point 9383 number; it can also be used for double-precision (on processors 9384 with 16-bit bytes) and single-precision VAX and IBM types. 9385 9386 `DFmode' 9387 "Double Floating" mode represents an eight byte floating point 9388 number. In the common case, of a processor with IEEE arithmetic 9389 and 8-bit bytes, this is a double-precision IEEE floating point 9390 number. 9391 9392 `XFmode' 9393 "Extended Floating" mode represents an IEEE extended floating point 9394 number. This mode only has 80 meaningful bits (ten bytes). Some 9395 processors require such numbers to be padded to twelve bytes, 9396 others to sixteen; this mode is used for either. 9397 9398 `SDmode' 9399 "Single Decimal Floating" mode represents a four byte decimal 9400 floating point number (as distinct from conventional binary 9401 floating point). 9402 9403 `DDmode' 9404 "Double Decimal Floating" mode represents an eight byte decimal 9405 floating point number. 9406 9407 `TDmode' 9408 "Tetra Decimal Floating" mode represents a sixteen byte decimal 9409 floating point number all 128 of whose bits are meaningful. 9410 9411 `TFmode' 9412 "Tetra Floating" mode represents a sixteen byte floating point 9413 number all 128 of whose bits are meaningful. One common use is the 9414 IEEE quad-precision format. 9415 9416 `CCmode' 9417 "Condition Code" mode represents the value of a condition code, 9418 which is a machine-specific set of bits used to represent the 9419 result of a comparison operation. Other machine-specific modes 9420 may also be used for the condition code. These modes are not used 9421 on machines that use `cc0' (see *note Condition Code::). 9422 9423 `BLKmode' 9424 "Block" mode represents values that are aggregates to which none of 9425 the other modes apply. In RTL, only memory references can have 9426 this mode, and only if they appear in string-move or vector 9427 instructions. On machines which have no such instructions, 9428 `BLKmode' will not appear in RTL. 9429 9430 `VOIDmode' 9431 Void mode means the absence of a mode or an unspecified mode. For 9432 example, RTL expressions of code `const_int' have mode `VOIDmode' 9433 because they can be taken to have whatever mode the context 9434 requires. In debugging dumps of RTL, `VOIDmode' is expressed by 9435 the absence of any mode. 9436 9437 `QCmode, HCmode, SCmode, DCmode, XCmode, TCmode' 9438 These modes stand for a complex number represented as a pair of 9439 floating point values. The floating point values are in `QFmode', 9440 `HFmode', `SFmode', `DFmode', `XFmode', and `TFmode', respectively. 9441 9442 `CQImode, CHImode, CSImode, CDImode, CTImode, COImode' 9443 These modes stand for a complex number represented as a pair of 9444 integer values. The integer values are in `QImode', `HImode', 9445 `SImode', `DImode', `TImode', and `OImode', respectively. 9446 9447 The machine description defines `Pmode' as a C macro which expands 9448 into the machine mode used for addresses. Normally this is the mode 9449 whose size is `BITS_PER_WORD', `SImode' on 32-bit machines. 9450 9451 The only modes which a machine description must support are `QImode', 9452 and the modes corresponding to `BITS_PER_WORD', `FLOAT_TYPE_SIZE' and 9453 `DOUBLE_TYPE_SIZE'. The compiler will attempt to use `DImode' for 9454 8-byte structures and unions, but this can be prevented by overriding 9455 the definition of `MAX_FIXED_MODE_SIZE'. Alternatively, you can have 9456 the compiler use `TImode' for 16-byte structures and unions. Likewise, 9457 you can arrange for the C type `short int' to avoid using `HImode'. 9458 9459 Very few explicit references to machine modes remain in the compiler 9460 and these few references will soon be removed. Instead, the machine 9461 modes are divided into mode classes. These are represented by the 9462 enumeration type `enum mode_class' defined in `machmode.h'. The 9463 possible mode classes are: 9464 9465 `MODE_INT' 9466 Integer modes. By default these are `BImode', `QImode', `HImode', 9467 `SImode', `DImode', `TImode', and `OImode'. 9468 9469 `MODE_PARTIAL_INT' 9470 The "partial integer" modes, `PQImode', `PHImode', `PSImode' and 9471 `PDImode'. 9472 9473 `MODE_FLOAT' 9474 Floating point modes. By default these are `QFmode', `HFmode', 9475 `TQFmode', `SFmode', `DFmode', `XFmode' and `TFmode'. 9476 9477 `MODE_DECIMAL_FLOAT' 9478 Decimal floating point modes. By default these are `SDmode', 9479 `DDmode' and `TDmode'. 9480 9481 `MODE_COMPLEX_INT' 9482 Complex integer modes. (These are not currently implemented). 9483 9484 `MODE_COMPLEX_FLOAT' 9485 Complex floating point modes. By default these are `QCmode', 9486 `HCmode', `SCmode', `DCmode', `XCmode', and `TCmode'. 9487 9488 `MODE_FUNCTION' 9489 Algol or Pascal function variables including a static chain. 9490 (These are not currently implemented). 9491 9492 `MODE_CC' 9493 Modes representing condition code values. These are `CCmode' plus 9494 any `CC_MODE' modes listed in the `MACHINE-modes.def'. *Note Jump 9495 Patterns::, also see *Note Condition Code::. 9496 9497 `MODE_RANDOM' 9498 This is a catchall mode class for modes which don't fit into the 9499 above classes. Currently `VOIDmode' and `BLKmode' are in 9500 `MODE_RANDOM'. 9501 9502 Here are some C macros that relate to machine modes: 9503 9504 `GET_MODE (X)' 9505 Returns the machine mode of the RTX X. 9506 9507 `PUT_MODE (X, NEWMODE)' 9508 Alters the machine mode of the RTX X to be NEWMODE. 9509 9510 `NUM_MACHINE_MODES' 9511 Stands for the number of machine modes available on the target 9512 machine. This is one greater than the largest numeric value of any 9513 machine mode. 9514 9515 `GET_MODE_NAME (M)' 9516 Returns the name of mode M as a string. 9517 9518 `GET_MODE_CLASS (M)' 9519 Returns the mode class of mode M. 9520 9521 `GET_MODE_WIDER_MODE (M)' 9522 Returns the next wider natural mode. For example, the expression 9523 `GET_MODE_WIDER_MODE (QImode)' returns `HImode'. 9524 9525 `GET_MODE_SIZE (M)' 9526 Returns the size in bytes of a datum of mode M. 9527 9528 `GET_MODE_BITSIZE (M)' 9529 Returns the size in bits of a datum of mode M. 9530 9531 `GET_MODE_MASK (M)' 9532 Returns a bitmask containing 1 for all bits in a word that fit 9533 within mode M. This macro can only be used for modes whose 9534 bitsize is less than or equal to `HOST_BITS_PER_INT'. 9535 9536 `GET_MODE_ALIGNMENT (M)' 9537 Return the required alignment, in bits, for an object of mode M. 9538 9539 `GET_MODE_UNIT_SIZE (M)' 9540 Returns the size in bytes of the subunits of a datum of mode M. 9541 This is the same as `GET_MODE_SIZE' except in the case of complex 9542 modes. For them, the unit size is the size of the real or 9543 imaginary part. 9544 9545 `GET_MODE_NUNITS (M)' 9546 Returns the number of units contained in a mode, i.e., 9547 `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'. 9548 9549 `GET_CLASS_NARROWEST_MODE (C)' 9550 Returns the narrowest mode in mode class C. 9551 9552 The global variables `byte_mode' and `word_mode' contain modes whose 9553 classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or 9554 `BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode' 9555 and `SImode', respectively. 9556 9557 9558 File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 9559 9560 12.7 Constant Expression Types 9561 ============================== 9562 9563 The simplest RTL expressions are those that represent constant values. 9564 9565 `(const_int I)' 9566 This type of expression represents the integer value I. I is 9567 customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)', 9568 which is equivalent to `XWINT (EXP, 0)'. 9569 9570 Constants generated for modes with fewer bits than `HOST_WIDE_INT' 9571 must be sign extended to full width (e.g., with `gen_int_mode'). 9572 9573 There is only one expression object for the integer value zero; it 9574 is the value of the variable `const0_rtx'. Likewise, the only 9575 expression for integer value one is found in `const1_rtx', the only 9576 expression for integer value two is found in `const2_rtx', and the 9577 only expression for integer value negative one is found in 9578 `constm1_rtx'. Any attempt to create an expression of code 9579 `const_int' and value zero, one, two or negative one will return 9580 `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as 9581 appropriate. 9582 9583 Similarly, there is only one object for the integer whose value is 9584 `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If 9585 `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will 9586 point to the same object. If `STORE_FLAG_VALUE' is -1, 9587 `const_true_rtx' and `constm1_rtx' will point to the same object. 9588 9589 `(const_double:M ADDR I0 I1 ...)' 9590 Represents either a floating-point constant of mode M or an 9591 integer constant too large to fit into `HOST_BITS_PER_WIDE_INT' 9592 bits but small enough to fit within twice that number of bits (GCC 9593 does not provide a mechanism to represent even larger constants). 9594 In the latter case, M will be `VOIDmode'. 9595 9596 `(const_vector:M [X0 X1 ...])' 9597 Represents a vector constant. The square brackets stand for the 9598 vector containing the constant elements. X0, X1 and so on are the 9599 `const_int' or `const_double' elements. 9600 9601 The number of units in a `const_vector' is obtained with the macro 9602 `CONST_VECTOR_NUNITS' as in `CONST_VECTOR_NUNITS (V)'. 9603 9604 Individual elements in a vector constant are accessed with the 9605 macro `CONST_VECTOR_ELT' as in `CONST_VECTOR_ELT (V, N)' where V 9606 is the vector constant and N is the element desired. 9607 9608 ADDR is used to contain the `mem' expression that corresponds to 9609 the location in memory that at which the constant can be found. If 9610 it has not been allocated a memory location, but is on the chain 9611 of all `const_double' expressions in this compilation (maintained 9612 using an undisplayed field), ADDR contains `const0_rtx'. If it is 9613 not on the chain, ADDR contains `cc0_rtx'. ADDR is customarily 9614 accessed with the macro `CONST_DOUBLE_MEM' and the chain field via 9615 `CONST_DOUBLE_CHAIN'. 9616 9617 If M is `VOIDmode', the bits of the value are stored in I0 and I1. 9618 I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and 9619 I1 with `CONST_DOUBLE_HIGH'. 9620 9621 If the constant is floating point (regardless of its precision), 9622 then the number of integers used to store the value depends on the 9623 size of `REAL_VALUE_TYPE' (*note Floating Point::). The integers 9624 represent a floating point number, but not precisely in the target 9625 machine's or host machine's floating point format. To convert 9626 them to the precise bit pattern used by the target machine, use 9627 the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data 9628 Output::). 9629 9630 The macro `CONST0_RTX (MODE)' refers to an expression with value 0 9631 in mode MODE. If mode MODE is of mode class `MODE_INT', it 9632 returns `const0_rtx'. If mode MODE is of mode class `MODE_FLOAT', 9633 it returns a `CONST_DOUBLE' expression in mode MODE. Otherwise, 9634 it returns a `CONST_VECTOR' expression in mode MODE. Similarly, 9635 the macro `CONST1_RTX (MODE)' refers to an expression with value 1 9636 in mode MODE and similarly for `CONST2_RTX'. The `CONST1_RTX' and 9637 `CONST2_RTX' macros are undefined for vector modes. 9638 9639 `(const_string STR)' 9640 Represents a constant string with value STR. Currently this is 9641 used only for insn attributes (*note Insn Attributes::) since 9642 constant strings in C are placed in memory. 9643 9644 `(symbol_ref:MODE SYMBOL)' 9645 Represents the value of an assembler label for data. SYMBOL is a 9646 string that describes the name of the assembler label. If it 9647 starts with a `*', the label is the rest of SYMBOL not including 9648 the `*'. Otherwise, the label is SYMBOL, usually prefixed with 9649 `_'. 9650 9651 The `symbol_ref' contains a mode, which is usually `Pmode'. 9652 Usually that is the only mode for which a symbol is directly valid. 9653 9654 `(label_ref:MODE LABEL)' 9655 Represents the value of an assembler label for code. It contains 9656 one operand, an expression, which must be a `code_label' or a 9657 `note' of type `NOTE_INSN_DELETED_LABEL' that appears in the 9658 instruction sequence to identify the place where the label should 9659 go. 9660 9661 The reason for using a distinct expression type for code label 9662 references is so that jump optimization can distinguish them. 9663 9664 The `label_ref' contains a mode, which is usually `Pmode'. 9665 Usually that is the only mode for which a label is directly valid. 9666 9667 `(const:M EXP)' 9668 Represents a constant that is the result of an assembly-time 9669 arithmetic computation. The operand, EXP, is an expression that 9670 contains only constants (`const_int', `symbol_ref' and `label_ref' 9671 expressions) combined with `plus' and `minus'. However, not all 9672 combinations are valid, since the assembler cannot do arbitrary 9673 arithmetic on relocatable symbols. 9674 9675 M should be `Pmode'. 9676 9677 `(high:M EXP)' 9678 Represents the high-order bits of EXP, usually a `symbol_ref'. 9679 The number of bits is machine-dependent and is normally the number 9680 of bits specified in an instruction that initializes the high 9681 order bits of a register. It is used with `lo_sum' to represent 9682 the typical two-instruction sequence used in RISC machines to 9683 reference a global memory location. 9684 9685 M should be `Pmode'. 9686 9687 9688 File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 9689 9690 12.8 Registers and Memory 9691 ========================= 9692 9693 Here are the RTL expression types for describing access to machine 9694 registers and to main memory. 9695 9696 `(reg:M N)' 9697 For small values of the integer N (those that are less than 9698 `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine 9699 register number N: a "hard register". For larger values of N, it 9700 stands for a temporary value or "pseudo register". The compiler's 9701 strategy is to generate code assuming an unlimited number of such 9702 pseudo registers, and later convert them into hard registers or 9703 into memory references. 9704 9705 M is the machine mode of the reference. It is necessary because 9706 machines can generally refer to each register in more than one 9707 mode. For example, a register may contain a full word but there 9708 may be instructions to refer to it as a half word or as a single 9709 byte, as well as instructions to refer to it as a floating point 9710 number of various precisions. 9711 9712 Even for a register that the machine can access in only one mode, 9713 the mode must always be specified. 9714 9715 The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine 9716 description, since the number of hard registers on the machine is 9717 an invariant characteristic of the machine. Note, however, that 9718 not all of the machine registers must be general registers. All 9719 the machine registers that can be used for storage of data are 9720 given hard register numbers, even those that can be used only in 9721 certain instructions or can hold only certain types of data. 9722 9723 A hard register may be accessed in various modes throughout one 9724 function, but each pseudo register is given a natural mode and is 9725 accessed only in that mode. When it is necessary to describe an 9726 access to a pseudo register using a nonnatural mode, a `subreg' 9727 expression is used. 9728 9729 A `reg' expression with a machine mode that specifies more than 9730 one word of data may actually stand for several consecutive 9731 registers. If in addition the register number specifies a 9732 hardware register, then it actually represents several consecutive 9733 hardware registers starting with the specified one. 9734 9735 Each pseudo register number used in a function's RTL code is 9736 represented by a unique `reg' expression. 9737 9738 Some pseudo register numbers, those within the range of 9739 `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear 9740 during the RTL generation phase and are eliminated before the 9741 optimization phases. These represent locations in the stack frame 9742 that cannot be determined until RTL generation for the function 9743 has been completed. The following virtual register numbers are 9744 defined: 9745 9746 `VIRTUAL_INCOMING_ARGS_REGNUM' 9747 This points to the first word of the incoming arguments 9748 passed on the stack. Normally these arguments are placed 9749 there by the caller, but the callee may have pushed some 9750 arguments that were previously passed in registers. 9751 9752 When RTL generation is complete, this virtual register is 9753 replaced by the sum of the register given by 9754 `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'. 9755 9756 `VIRTUAL_STACK_VARS_REGNUM' 9757 If `FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this 9758 points to immediately above the first variable on the stack. 9759 Otherwise, it points to the first variable on the stack. 9760 9761 `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the 9762 register given by `FRAME_POINTER_REGNUM' and the value 9763 `STARTING_FRAME_OFFSET'. 9764 9765 `VIRTUAL_STACK_DYNAMIC_REGNUM' 9766 This points to the location of dynamically allocated memory 9767 on the stack immediately after the stack pointer has been 9768 adjusted by the amount of memory desired. 9769 9770 This virtual register is replaced by the sum of the register 9771 given by `STACK_POINTER_REGNUM' and the value 9772 `STACK_DYNAMIC_OFFSET'. 9773 9774 `VIRTUAL_OUTGOING_ARGS_REGNUM' 9775 This points to the location in the stack at which outgoing 9776 arguments should be written when the stack is pre-pushed 9777 (arguments pushed using push insns should always use 9778 `STACK_POINTER_REGNUM'). 9779 9780 This virtual register is replaced by the sum of the register 9781 given by `STACK_POINTER_REGNUM' and the value 9782 `STACK_POINTER_OFFSET'. 9783 9784 `(subreg:M REG BYTENUM)' 9785 `subreg' expressions are used to refer to a register in a machine 9786 mode other than its natural one, or to refer to one register of a 9787 multi-part `reg' that actually refers to several registers. 9788 9789 Each pseudo-register has a natural mode. If it is necessary to 9790 operate on it in a different mode--for example, to perform a 9791 fullword move instruction on a pseudo-register that contains a 9792 single byte--the pseudo-register must be enclosed in a `subreg'. 9793 In such a case, BYTENUM is zero. 9794 9795 Usually M is at least as narrow as the mode of REG, in which case 9796 it is restricting consideration to only the bits of REG that are 9797 in M. 9798 9799 Sometimes M is wider than the mode of REG. These `subreg' 9800 expressions are often called "paradoxical". They are used in 9801 cases where we want to refer to an object in a wider mode but do 9802 not care what value the additional bits have. The reload pass 9803 ensures that paradoxical references are only made to hard 9804 registers. 9805 9806 The other use of `subreg' is to extract the individual registers of 9807 a multi-register value. Machine modes such as `DImode' and 9808 `TImode' can indicate values longer than a word, values which 9809 usually require two or more consecutive registers. To access one 9810 of the registers, use a `subreg' with mode `SImode' and a BYTENUM 9811 offset that says which register. 9812 9813 Storing in a non-paradoxical `subreg' has undefined results for 9814 bits belonging to the same word as the `subreg'. This laxity makes 9815 it easier to generate efficient code for such instructions. To 9816 represent an instruction that preserves all the bits outside of 9817 those in the `subreg', use `strict_low_part' around the `subreg'. 9818 9819 The compilation parameter `WORDS_BIG_ENDIAN', if set to 1, says 9820 that byte number zero is part of the most significant word; 9821 otherwise, it is part of the least significant word. 9822 9823 The compilation parameter `BYTES_BIG_ENDIAN', if set to 1, says 9824 that byte number zero is the most significant byte within a word; 9825 otherwise, it is the least significant byte within a word. 9826 9827 On a few targets, `FLOAT_WORDS_BIG_ENDIAN' disagrees with 9828 `WORDS_BIG_ENDIAN'. However, most parts of the compiler treat 9829 floating point values as if they had the same endianness as 9830 integer values. This works because they handle them solely as a 9831 collection of integer values, with no particular numerical value. 9832 Only real.c and the runtime libraries care about 9833 `FLOAT_WORDS_BIG_ENDIAN'. 9834 9835 Between the combiner pass and the reload pass, it is possible to 9836 have a paradoxical `subreg' which contains a `mem' instead of a 9837 `reg' as its first operand. After the reload pass, it is also 9838 possible to have a non-paradoxical `subreg' which contains a 9839 `mem'; this usually occurs when the `mem' is a stack slot which 9840 replaced a pseudo register. 9841 9842 Note that it is not valid to access a `DFmode' value in `SFmode' 9843 using a `subreg'. On some machines the most significant part of a 9844 `DFmode' value does not have the same format as a single-precision 9845 floating value. 9846 9847 It is also not valid to access a single word of a multi-word value 9848 in a hard register when less registers can hold the value than 9849 would be expected from its size. For example, some 32-bit 9850 machines have floating-point registers that can hold an entire 9851 `DFmode' value. If register 10 were such a register `(subreg:SI 9852 (reg:DF 10) 4)' would be invalid because there is no way to 9853 convert that reference to a single machine register. The reload 9854 pass prevents `subreg' expressions such as these from being formed. 9855 9856 The first operand of a `subreg' expression is customarily accessed 9857 with the `SUBREG_REG' macro and the second operand is customarily 9858 accessed with the `SUBREG_BYTE' macro. 9859 9860 `(scratch:M)' 9861 This represents a scratch register that will be required for the 9862 execution of a single instruction and not used subsequently. It is 9863 converted into a `reg' by either the local register allocator or 9864 the reload pass. 9865 9866 `scratch' is usually present inside a `clobber' operation (*note 9867 Side Effects::). 9868 9869 `(cc0)' 9870 This refers to the machine's condition code register. It has no 9871 operands and may not have a machine mode. There are two ways to 9872 use it: 9873 9874 * To stand for a complete set of condition code flags. This is 9875 best on most machines, where each comparison sets the entire 9876 series of flags. 9877 9878 With this technique, `(cc0)' may be validly used in only two 9879 contexts: as the destination of an assignment (in test and 9880 compare instructions) and in comparison operators comparing 9881 against zero (`const_int' with value zero; that is to say, 9882 `const0_rtx'). 9883 9884 * To stand for a single flag that is the result of a single 9885 condition. This is useful on machines that have only a 9886 single flag bit, and in which comparison instructions must 9887 specify the condition to test. 9888 9889 With this technique, `(cc0)' may be validly used in only two 9890 contexts: as the destination of an assignment (in test and 9891 compare instructions) where the source is a comparison 9892 operator, and as the first operand of `if_then_else' (in a 9893 conditional branch). 9894 9895 There is only one expression object of code `cc0'; it is the value 9896 of the variable `cc0_rtx'. Any attempt to create an expression of 9897 code `cc0' will return `cc0_rtx'. 9898 9899 Instructions can set the condition code implicitly. On many 9900 machines, nearly all instructions set the condition code based on 9901 the value that they compute or store. It is not necessary to 9902 record these actions explicitly in the RTL because the machine 9903 description includes a prescription for recognizing the 9904 instructions that do so (by means of the macro 9905 `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions 9906 whose sole purpose is to set the condition code, and instructions 9907 that use the condition code, need mention `(cc0)'. 9908 9909 On some machines, the condition code register is given a register 9910 number and a `reg' is used instead of `(cc0)'. This is usually the 9911 preferable approach if only a small subset of instructions modify 9912 the condition code. Other machines store condition codes in 9913 general registers; in such cases a pseudo register should be used. 9914 9915 Some machines, such as the SPARC and RS/6000, have two sets of 9916 arithmetic instructions, one that sets and one that does not set 9917 the condition code. This is best handled by normally generating 9918 the instruction that does not set the condition code, and making a 9919 pattern that both performs the arithmetic and sets the condition 9920 code register (which would not be `(cc0)' in this case). For 9921 examples, search for `addcc' and `andcc' in `sparc.md'. 9922 9923 `(pc)' 9924 This represents the machine's program counter. It has no operands 9925 and may not have a machine mode. `(pc)' may be validly used only 9926 in certain specific contexts in jump instructions. 9927 9928 There is only one expression object of code `pc'; it is the value 9929 of the variable `pc_rtx'. Any attempt to create an expression of 9930 code `pc' will return `pc_rtx'. 9931 9932 All instructions that do not jump alter the program counter 9933 implicitly by incrementing it, but there is no need to mention 9934 this in the RTL. 9935 9936 `(mem:M ADDR ALIAS)' 9937 This RTX represents a reference to main memory at an address 9938 represented by the expression ADDR. M specifies how large a unit 9939 of memory is accessed. ALIAS specifies an alias set for the 9940 reference. In general two items are in different alias sets if 9941 they cannot reference the same memory address. 9942 9943 The construct `(mem:BLK (scratch))' is considered to alias all 9944 other memories. Thus it may be used as a memory barrier in 9945 epilogue stack deallocation patterns. 9946 9947 `(addressof:M REG)' 9948 This RTX represents a request for the address of register REG. 9949 Its mode is always `Pmode'. If there are any `addressof' 9950 expressions left in the function after CSE, REG is forced into the 9951 stack and the `addressof' expression is replaced with a `plus' 9952 expression for the address of its stack slot. 9953 9954 9955 File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 9956 9957 12.9 RTL Expressions for Arithmetic 9958 =================================== 9959 9960 Unless otherwise specified, all the operands of arithmetic expressions 9961 must be valid for mode M. An operand is valid for mode M if it has 9962 mode M, or if it is a `const_int' or `const_double' and M is a mode of 9963 class `MODE_INT'. 9964 9965 For commutative binary operations, constants should be placed in the 9966 second operand. 9967 9968 `(plus:M X Y)' 9969 `(ss_plus:M X Y)' 9970 `(us_plus:M X Y)' 9971 These three expressions all represent the sum of the values 9972 represented by X and Y carried out in machine mode M. They differ 9973 in their behavior on overflow of integer modes. `plus' wraps 9974 round modulo the width of M; `ss_plus' saturates at the maximum 9975 signed value representable in M; `us_plus' saturates at the 9976 maximum unsigned value. 9977 9978 `(lo_sum:M X Y)' 9979 This expression represents the sum of X and the low-order bits of 9980 Y. It is used with `high' (*note Constants::) to represent the 9981 typical two-instruction sequence used in RISC machines to 9982 reference a global memory location. 9983 9984 The number of low order bits is machine-dependent but is normally 9985 the number of bits in a `Pmode' item minus the number of bits set 9986 by `high'. 9987 9988 M should be `Pmode'. 9989 9990 `(minus:M X Y)' 9991 `(ss_minus:M X Y)' 9992 `(us_minus:M X Y)' 9993 These three expressions represent the result of subtracting Y from 9994 X, carried out in mode M. Behavior on overflow is the same as for 9995 the three variants of `plus' (see above). 9996 9997 `(compare:M X Y)' 9998 Represents the result of subtracting Y from X for purposes of 9999 comparison. The result is computed without overflow, as if with 10000 infinite precision. 10001 10002 Of course, machines can't really subtract with infinite precision. 10003 However, they can pretend to do so when only the sign of the 10004 result will be used, which is the case when the result is stored 10005 in the condition code. And that is the _only_ way this kind of 10006 expression may validly be used: as a value to be stored in the 10007 condition codes, either `(cc0)' or a register. *Note 10008 Comparisons::. 10009 10010 The mode M is not related to the modes of X and Y, but instead is 10011 the mode of the condition code value. If `(cc0)' is used, it is 10012 `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often 10013 `CCmode'. *Note Condition Code::. If M is `VOIDmode' or 10014 `CCmode', the operation returns sufficient information (in an 10015 unspecified format) so that any comparison operator can be applied 10016 to the result of the `COMPARE' operation. For other modes in 10017 class `MODE_CC', the operation only returns a subset of this 10018 information. 10019 10020 Normally, X and Y must have the same mode. Otherwise, `compare' 10021 is valid only if the mode of X is in class `MODE_INT' and Y is a 10022 `const_int' or `const_double' with mode `VOIDmode'. The mode of X 10023 determines what mode the comparison is to be done in; thus it must 10024 not be `VOIDmode'. 10025 10026 If one of the operands is a constant, it should be placed in the 10027 second operand and the comparison code adjusted as appropriate. 10028 10029 A `compare' specifying two `VOIDmode' constants is not valid since 10030 there is no way to know in what mode the comparison is to be 10031 performed; the comparison must either be folded during the 10032 compilation or the first operand must be loaded into a register 10033 while its mode is still known. 10034 10035 `(neg:M X)' 10036 `(ss_neg:M X)' 10037 These two expressions represent the negation (subtraction from 10038 zero) of the value represented by X, carried out in mode M. They 10039 differ in the behavior on overflow of integer modes. In the case 10040 of `neg', the negation of the operand may be a number not 10041 representable in mode M, in which case it is truncated to M. 10042 `ss_neg' ensures that an out-of-bounds result saturates to the 10043 maximum or minimum representable value. 10044 10045 `(mult:M X Y)' 10046 Represents the signed product of the values represented by X and Y 10047 carried out in machine mode M. 10048 10049 Some machines support a multiplication that generates a product 10050 wider than the operands. Write the pattern for this as 10051 10052 (mult:M (sign_extend:M X) (sign_extend:M Y)) 10053 10054 where M is wider than the modes of X and Y, which need not be the 10055 same. 10056 10057 For unsigned widening multiplication, use the same idiom, but with 10058 `zero_extend' instead of `sign_extend'. 10059 10060 `(div:M X Y)' 10061 Represents the quotient in signed division of X by Y, carried out 10062 in machine mode M. If M is a floating point mode, it represents 10063 the exact quotient; otherwise, the integerized quotient. 10064 10065 Some machines have division instructions in which the operands and 10066 quotient widths are not all the same; you should represent such 10067 instructions using `truncate' and `sign_extend' as in, 10068 10069 (truncate:M1 (div:M2 X (sign_extend:M2 Y))) 10070 10071 `(udiv:M X Y)' 10072 Like `div' but represents unsigned division. 10073 10074 `(mod:M X Y)' 10075 `(umod:M X Y)' 10076 Like `div' and `udiv' but represent the remainder instead of the 10077 quotient. 10078 10079 `(smin:M X Y)' 10080 `(smax:M X Y)' 10081 Represents the smaller (for `smin') or larger (for `smax') of X 10082 and Y, interpreted as signed values in mode M. When used with 10083 floating point, if both operands are zeros, or if either operand 10084 is `NaN', then it is unspecified which of the two operands is 10085 returned as the result. 10086 10087 `(umin:M X Y)' 10088 `(umax:M X Y)' 10089 Like `smin' and `smax', but the values are interpreted as unsigned 10090 integers. 10091 10092 `(not:M X)' 10093 Represents the bitwise complement of the value represented by X, 10094 carried out in mode M, which must be a fixed-point machine mode. 10095 10096 `(and:M X Y)' 10097 Represents the bitwise logical-and of the values represented by X 10098 and Y, carried out in machine mode M, which must be a fixed-point 10099 machine mode. 10100 10101 `(ior:M X Y)' 10102 Represents the bitwise inclusive-or of the values represented by X 10103 and Y, carried out in machine mode M, which must be a fixed-point 10104 mode. 10105 10106 `(xor:M X Y)' 10107 Represents the bitwise exclusive-or of the values represented by X 10108 and Y, carried out in machine mode M, which must be a fixed-point 10109 mode. 10110 10111 `(ashift:M X C)' 10112 `(ss_ashift:M X C)' 10113 These two expressions represent the result of arithmetically 10114 shifting X left by C places. They differ in their behavior on 10115 overflow of integer modes. An `ashift' operation is a plain shift 10116 with no special behavior in case of a change in the sign bit; 10117 `ss_ashift' saturates to the minimum or maximum representable 10118 value if any of the bits shifted out differs from the final sign 10119 bit. 10120 10121 X have mode M, a fixed-point machine mode. C be a fixed-point 10122 mode or be a constant with mode `VOIDmode'; which mode is 10123 determined by the mode called for in the machine description entry 10124 for the left-shift instruction. For example, on the VAX, the mode 10125 of C is `QImode' regardless of M. 10126 10127 `(lshiftrt:M X C)' 10128 `(ashiftrt:M X C)' 10129 Like `ashift' but for right shift. Unlike the case for left shift, 10130 these two operations are distinct. 10131 10132 `(rotate:M X C)' 10133 `(rotatert:M X C)' 10134 Similar but represent left and right rotate. If C is a constant, 10135 use `rotate'. 10136 10137 `(abs:M X)' 10138 Represents the absolute value of X, computed in mode M. 10139 10140 `(sqrt:M X)' 10141 Represents the square root of X, computed in mode M. Most often M 10142 will be a floating point mode. 10143 10144 `(ffs:M X)' 10145 Represents one plus the index of the least significant 1-bit in X, 10146 represented as an integer of mode M. (The value is zero if X is 10147 zero.) The mode of X need not be M; depending on the target 10148 machine, various mode combinations may be valid. 10149 10150 `(clz:M X)' 10151 Represents the number of leading 0-bits in X, represented as an 10152 integer of mode M, starting at the most significant bit position. 10153 If X is zero, the value is determined by 10154 `CLZ_DEFINED_VALUE_AT_ZERO'. Note that this is one of the few 10155 expressions that is not invariant under widening. The mode of X 10156 will usually be an integer mode. 10157 10158 `(ctz:M X)' 10159 Represents the number of trailing 0-bits in X, represented as an 10160 integer of mode M, starting at the least significant bit position. 10161 If X is zero, the value is determined by 10162 `CTZ_DEFINED_VALUE_AT_ZERO'. Except for this case, `ctz(x)' is 10163 equivalent to `ffs(X) - 1'. The mode of X will usually be an 10164 integer mode. 10165 10166 `(popcount:M X)' 10167 Represents the number of 1-bits in X, represented as an integer of 10168 mode M. The mode of X will usually be an integer mode. 10169 10170 `(parity:M X)' 10171 Represents the number of 1-bits modulo 2 in X, represented as an 10172 integer of mode M. The mode of X will usually be an integer mode. 10173 10174 10175 File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL 10176 10177 12.10 Comparison Operations 10178 =========================== 10179 10180 Comparison operators test a relation on two operands and are considered 10181 to represent a machine-dependent nonzero value described by, but not 10182 necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::) if the relation 10183 holds, or zero if it does not, for comparison operators whose results 10184 have a `MODE_INT' mode, `FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the 10185 relation holds, or zero if it does not, for comparison operators that 10186 return floating-point values, and a vector of either 10187 `VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of 10188 zeros if it does not, for comparison operators that return vector 10189 results. The mode of the comparison operation is independent of the 10190 mode of the data being compared. If the comparison operation is being 10191 tested (e.g., the first operand of an `if_then_else'), the mode must be 10192 `VOIDmode'. 10193 10194 There are two ways that comparison operations may be used. The 10195 comparison operators may be used to compare the condition codes `(cc0)' 10196 against zero, as in `(eq (cc0) (const_int 0))'. Such a construct 10197 actually refers to the result of the preceding instruction in which the 10198 condition codes were set. The instruction setting the condition code 10199 must be adjacent to the instruction using the condition code; only 10200 `note' insns may separate them. 10201 10202 Alternatively, a comparison operation may directly compare two data 10203 objects. The mode of the comparison is determined by the operands; they 10204 must both be valid for a common machine mode. A comparison with both 10205 operands constant would be invalid as the machine mode could not be 10206 deduced from it, but such a comparison should never exist in RTL due to 10207 constant folding. 10208 10209 In the example above, if `(cc0)' were last set to `(compare X Y)', the 10210 comparison operation is identical to `(eq X Y)'. Usually only one style 10211 of comparisons is supported on a particular machine, but the combine 10212 pass will try to merge the operations to produce the `eq' shown in case 10213 it exists in the context of the particular insn involved. 10214 10215 Inequality comparisons come in two flavors, signed and unsigned. Thus, 10216 there are distinct expression codes `gt' and `gtu' for signed and 10217 unsigned greater-than. These can produce different results for the same 10218 pair of integer values: for example, 1 is signed greater-than -1 but not 10219 unsigned greater-than, because -1 when regarded as unsigned is actually 10220 `0xffffffff' which is greater than 1. 10221 10222 The signed comparisons are also used for floating point values. 10223 Floating point comparisons are distinguished by the machine modes of 10224 the operands. 10225 10226 `(eq:M X Y)' 10227 `STORE_FLAG_VALUE' if the values represented by X and Y are equal, 10228 otherwise 0. 10229 10230 `(ne:M X Y)' 10231 `STORE_FLAG_VALUE' if the values represented by X and Y are not 10232 equal, otherwise 0. 10233 10234 `(gt:M X Y)' 10235 `STORE_FLAG_VALUE' if the X is greater than Y. If they are 10236 fixed-point, the comparison is done in a signed sense. 10237 10238 `(gtu:M X Y)' 10239 Like `gt' but does unsigned comparison, on fixed-point numbers 10240 only. 10241 10242 `(lt:M X Y)' 10243 `(ltu:M X Y)' 10244 Like `gt' and `gtu' but test for "less than". 10245 10246 `(ge:M X Y)' 10247 `(geu:M X Y)' 10248 Like `gt' and `gtu' but test for "greater than or equal". 10249 10250 `(le:M X Y)' 10251 `(leu:M X Y)' 10252 Like `gt' and `gtu' but test for "less than or equal". 10253 10254 `(if_then_else COND THEN ELSE)' 10255 This is not a comparison operation but is listed here because it is 10256 always used in conjunction with a comparison operation. To be 10257 precise, COND is a comparison expression. This expression 10258 represents a choice, according to COND, between the value 10259 represented by THEN and the one represented by ELSE. 10260 10261 On most machines, `if_then_else' expressions are valid only to 10262 express conditional jumps. 10263 10264 `(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' 10265 Similar to `if_then_else', but more general. Each of TEST1, 10266 TEST2, ... is performed in turn. The result of this expression is 10267 the VALUE corresponding to the first nonzero test, or DEFAULT if 10268 none of the tests are nonzero expressions. 10269 10270 This is currently not valid for instruction patterns and is 10271 supported only for insn attributes. *Note Insn Attributes::. 10272 10273 10274 File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL 10275 10276 12.11 Bit-Fields 10277 ================ 10278 10279 Special expression codes exist to represent bit-field instructions. 10280 10281 `(sign_extract:M LOC SIZE POS)' 10282 This represents a reference to a sign-extended bit-field contained 10283 or starting in LOC (a memory or register reference). The bit-field 10284 is SIZE bits wide and starts at bit POS. The compilation option 10285 `BITS_BIG_ENDIAN' says which end of the memory unit POS counts 10286 from. 10287 10288 If LOC is in memory, its mode must be a single-byte integer mode. 10289 If LOC is in a register, the mode to use is specified by the 10290 operand of the `insv' or `extv' pattern (*note Standard Names::) 10291 and is usually a full-word integer mode, which is the default if 10292 none is specified. 10293 10294 The mode of POS is machine-specific and is also specified in the 10295 `insv' or `extv' pattern. 10296 10297 The mode M is the same as the mode that would be used for LOC if 10298 it were a register. 10299 10300 A `sign_extract' can not appear as an lvalue, or part thereof, in 10301 RTL. 10302 10303 `(zero_extract:M LOC SIZE POS)' 10304 Like `sign_extract' but refers to an unsigned or zero-extended 10305 bit-field. The same sequence of bits are extracted, but they are 10306 filled to an entire word with zeros instead of by sign-extension. 10307 10308 Unlike `sign_extract', this type of expressions can be lvalues in 10309 RTL; they may appear on the left side of an assignment, indicating 10310 insertion of a value into the specified bit-field. 10311 10312 10313 File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL 10314 10315 12.12 Vector Operations 10316 ======================= 10317 10318 All normal RTL expressions can be used with vector modes; they are 10319 interpreted as operating on each part of the vector independently. 10320 Additionally, there are a few new expressions to describe specific 10321 vector operations. 10322 10323 `(vec_merge:M VEC1 VEC2 ITEMS)' 10324 This describes a merge operation between two vectors. The result 10325 is a vector of mode M; its elements are selected from either VEC1 10326 or VEC2. Which elements are selected is described by ITEMS, which 10327 is a bit mask represented by a `const_int'; a zero bit indicates 10328 the corresponding element in the result vector is taken from VEC2 10329 while a set bit indicates it is taken from VEC1. 10330 10331 `(vec_select:M VEC1 SELECTION)' 10332 This describes an operation that selects parts of a vector. VEC1 10333 is the source vector, SELECTION is a `parallel' that contains a 10334 `const_int' for each of the subparts of the result vector, giving 10335 the number of the source subpart that should be stored into it. 10336 10337 `(vec_concat:M VEC1 VEC2)' 10338 Describes a vector concat operation. The result is a 10339 concatenation of the vectors VEC1 and VEC2; its length is the sum 10340 of the lengths of the two inputs. 10341 10342 `(vec_duplicate:M VEC)' 10343 This operation converts a small vector into a larger one by 10344 duplicating the input values. The output vector mode must have 10345 the same submodes as the input vector mode, and the number of 10346 output parts must be an integer multiple of the number of input 10347 parts. 10348 10349 10350 10351 File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL 10352 10353 12.13 Conversions 10354 ================= 10355 10356 All conversions between machine modes must be represented by explicit 10357 conversion operations. For example, an expression which is the sum of 10358 a byte and a full word cannot be written as `(plus:SI (reg:QI 34) 10359 (reg:SI 80))' because the `plus' operation requires two operands of the 10360 same machine mode. Therefore, the byte-sized operand is enclosed in a 10361 conversion operation, as in 10362 10363 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 10364 10365 The conversion operation is not a mere placeholder, because there may 10366 be more than one way of converting from a given starting mode to the 10367 desired final mode. The conversion operation code says how to do it. 10368 10369 For all conversion operations, X must not be `VOIDmode' because the 10370 mode in which to do the conversion would not be known. The conversion 10371 must either be done at compile-time or X must be placed into a register. 10372 10373 `(sign_extend:M X)' 10374 Represents the result of sign-extending the value X to machine 10375 mode M. M must be a fixed-point mode and X a fixed-point value of 10376 a mode narrower than M. 10377 10378 `(zero_extend:M X)' 10379 Represents the result of zero-extending the value X to machine 10380 mode M. M must be a fixed-point mode and X a fixed-point value of 10381 a mode narrower than M. 10382 10383 `(float_extend:M X)' 10384 Represents the result of extending the value X to machine mode M. 10385 M must be a floating point mode and X a floating point value of a 10386 mode narrower than M. 10387 10388 `(truncate:M X)' 10389 Represents the result of truncating the value X to machine mode M. 10390 M must be a fixed-point mode and X a fixed-point value of a mode 10391 wider than M. 10392 10393 `(ss_truncate:M X)' 10394 Represents the result of truncating the value X to machine mode M, 10395 using signed saturation in the case of overflow. Both M and the 10396 mode of X must be fixed-point modes. 10397 10398 `(us_truncate:M X)' 10399 Represents the result of truncating the value X to machine mode M, 10400 using unsigned saturation in the case of overflow. Both M and the 10401 mode of X must be fixed-point modes. 10402 10403 `(float_truncate:M X)' 10404 Represents the result of truncating the value X to machine mode M. 10405 M must be a floating point mode and X a floating point value of a 10406 mode wider than M. 10407 10408 `(float:M X)' 10409 Represents the result of converting fixed point value X, regarded 10410 as signed, to floating point mode M. 10411 10412 `(unsigned_float:M X)' 10413 Represents the result of converting fixed point value X, regarded 10414 as unsigned, to floating point mode M. 10415 10416 `(fix:M X)' 10417 When M is a fixed point mode, represents the result of converting 10418 floating point value X to mode M, regarded as signed. How 10419 rounding is done is not specified, so this operation may be used 10420 validly in compiling C code only for integer-valued operands. 10421 10422 `(unsigned_fix:M X)' 10423 Represents the result of converting floating point value X to 10424 fixed point mode M, regarded as unsigned. How rounding is done is 10425 not specified. 10426 10427 `(fix:M X)' 10428 When M is a floating point mode, represents the result of 10429 converting floating point value X (valid for mode M) to an 10430 integer, still represented in floating point mode M, by rounding 10431 towards zero. 10432 10433 10434 File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 10435 10436 12.14 Declarations 10437 ================== 10438 10439 Declaration expression codes do not represent arithmetic operations but 10440 rather state assertions about their operands. 10441 10442 `(strict_low_part (subreg:M (reg:N R) 0))' 10443 This expression code is used in only one context: as the 10444 destination operand of a `set' expression. In addition, the 10445 operand of this expression must be a non-paradoxical `subreg' 10446 expression. 10447 10448 The presence of `strict_low_part' says that the part of the 10449 register which is meaningful in mode N, but is not part of mode M, 10450 is not to be altered. Normally, an assignment to such a subreg is 10451 allowed to have undefined effects on the rest of the register when 10452 M is less than a word. 10453 10454 10455 File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL 10456 10457 12.15 Side Effect Expressions 10458 ============================= 10459 10460 The expression codes described so far represent values, not actions. 10461 But machine instructions never produce values; they are meaningful only 10462 for their side effects on the state of the machine. Special expression 10463 codes are used to represent side effects. 10464 10465 The body of an instruction is always one of these side effect codes; 10466 the codes described above, which represent values, appear only as the 10467 operands of these. 10468 10469 `(set LVAL X)' 10470 Represents the action of storing the value of X into the place 10471 represented by LVAL. LVAL must be an expression representing a 10472 place that can be stored in: `reg' (or `subreg', `strict_low_part' 10473 or `zero_extract'), `mem', `pc', `parallel', or `cc0'. 10474 10475 If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then 10476 X must be valid for that mode. 10477 10478 If LVAL is a `reg' whose machine mode is less than the full width 10479 of the register, then it means that the part of the register 10480 specified by the machine mode is given the specified value and the 10481 rest of the register receives an undefined value. Likewise, if 10482 LVAL is a `subreg' whose machine mode is narrower than the mode of 10483 the register, the rest of the register can be changed in an 10484 undefined way. 10485 10486 If LVAL is a `strict_low_part' of a subreg, then the part of the 10487 register specified by the machine mode of the `subreg' is given 10488 the value X and the rest of the register is not changed. 10489 10490 If LVAL is a `zero_extract', then the referenced part of the 10491 bit-field (a memory or register reference) specified by the 10492 `zero_extract' is given the value X and the rest of the bit-field 10493 is not changed. Note that `sign_extract' can not appear in LVAL. 10494 10495 If LVAL is `(cc0)', it has no machine mode, and X may be either a 10496 `compare' expression or a value that may have any mode. The 10497 latter case represents a "test" instruction. The expression `(set 10498 (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N) 10499 (const_int 0)))'. Use the former expression to save space during 10500 the compilation. 10501 10502 If LVAL is a `parallel', it is used to represent the case of a 10503 function returning a structure in multiple registers. Each element 10504 of the `parallel' is an `expr_list' whose first operand is a `reg' 10505 and whose second operand is a `const_int' representing the offset 10506 (in bytes) into the structure at which the data in that register 10507 corresponds. The first element may be null to indicate that the 10508 structure is also passed partly in memory. 10509 10510 If LVAL is `(pc)', we have a jump instruction, and the 10511 possibilities for X are very limited. It may be a `label_ref' 10512 expression (unconditional jump). It may be an `if_then_else' 10513 (conditional jump), in which case either the second or the third 10514 operand must be `(pc)' (for the case which does not jump) and the 10515 other of the two must be a `label_ref' (for the case which does 10516 jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may 10517 be a `reg' or a `mem'; these unusual patterns are used to 10518 represent jumps through branch tables. 10519 10520 If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not 10521 be `VOIDmode' and the mode of X must be valid for the mode of LVAL. 10522 10523 LVAL is customarily accessed with the `SET_DEST' macro and X with 10524 the `SET_SRC' macro. 10525 10526 `(return)' 10527 As the sole expression in a pattern, represents a return from the 10528 current function, on machines where this can be done with one 10529 instruction, such as VAXen. On machines where a multi-instruction 10530 "epilogue" must be executed in order to return from the function, 10531 returning is done by jumping to a label which precedes the 10532 epilogue, and the `return' expression code is never used. 10533 10534 Inside an `if_then_else' expression, represents the value to be 10535 placed in `pc' to return to the caller. 10536 10537 Note that an insn pattern of `(return)' is logically equivalent to 10538 `(set (pc) (return))', but the latter form is never used. 10539 10540 `(call FUNCTION NARGS)' 10541 Represents a function call. FUNCTION is a `mem' expression whose 10542 address is the address of the function to be called. NARGS is an 10543 expression which can be used for two purposes: on some machines it 10544 represents the number of bytes of stack argument; on others, it 10545 represents the number of argument registers. 10546 10547 Each machine has a standard machine mode which FUNCTION must have. 10548 The machine description defines macro `FUNCTION_MODE' to expand 10549 into the requisite mode name. The purpose of this mode is to 10550 specify what kind of addressing is allowed, on machines where the 10551 allowed kinds of addressing depend on the machine mode being 10552 addressed. 10553 10554 `(clobber X)' 10555 Represents the storing or possible storing of an unpredictable, 10556 undescribed value into X, which must be a `reg', `scratch', 10557 `parallel' or `mem' expression. 10558 10559 One place this is used is in string instructions that store 10560 standard values into particular hard registers. It may not be 10561 worth the trouble to describe the values that are stored, but it 10562 is essential to inform the compiler that the registers will be 10563 altered, lest it attempt to keep data in them across the string 10564 instruction. 10565 10566 If X is `(mem:BLK (const_int 0))' or `(mem:BLK (scratch))', it 10567 means that all memory locations must be presumed clobbered. If X 10568 is a `parallel', it has the same meaning as a `parallel' in a 10569 `set' expression. 10570 10571 Note that the machine description classifies certain hard 10572 registers as "call-clobbered". All function call instructions are 10573 assumed by default to clobber these registers, so there is no need 10574 to use `clobber' expressions to indicate this fact. Also, each 10575 function call is assumed to have the potential to alter any memory 10576 location, unless the function is declared `const'. 10577 10578 If the last group of expressions in a `parallel' are each a 10579 `clobber' expression whose arguments are `reg' or `match_scratch' 10580 (*note RTL Template::) expressions, the combiner phase can add the 10581 appropriate `clobber' expressions to an insn it has constructed 10582 when doing so will cause a pattern to be matched. 10583 10584 This feature can be used, for example, on a machine that whose 10585 multiply and add instructions don't use an MQ register but which 10586 has an add-accumulate instruction that does clobber the MQ 10587 register. Similarly, a combined instruction might require a 10588 temporary register while the constituent instructions might not. 10589 10590 When a `clobber' expression for a register appears inside a 10591 `parallel' with other side effects, the register allocator 10592 guarantees that the register is unoccupied both before and after 10593 that insn. However, the reload phase may allocate a register used 10594 for one of the inputs unless the `&' constraint is specified for 10595 the selected alternative (*note Modifiers::). You can clobber 10596 either a specific hard register, a pseudo register, or a `scratch' 10597 expression; in the latter two cases, GCC will allocate a hard 10598 register that is available there for use as a temporary. 10599 10600 For instructions that require a temporary register, you should use 10601 `scratch' instead of a pseudo-register because this will allow the 10602 combiner phase to add the `clobber' when required. You do this by 10603 coding (`clobber' (`match_scratch' ...)). If you do clobber a 10604 pseudo register, use one which appears nowhere else--generate a 10605 new one each time. Otherwise, you may confuse CSE. 10606 10607 There is one other known use for clobbering a pseudo register in a 10608 `parallel': when one of the input operands of the insn is also 10609 clobbered by the insn. In this case, using the same pseudo 10610 register in the clobber and elsewhere in the insn produces the 10611 expected results. 10612 10613 `(use X)' 10614 Represents the use of the value of X. It indicates that the value 10615 in X at this point in the program is needed, even though it may 10616 not be apparent why this is so. Therefore, the compiler will not 10617 attempt to delete previous instructions whose only effect is to 10618 store a value in X. X must be a `reg' expression. 10619 10620 In some situations, it may be tempting to add a `use' of a 10621 register in a `parallel' to describe a situation where the value 10622 of a special register will modify the behavior of the instruction. 10623 An hypothetical example might be a pattern for an addition that can 10624 either wrap around or use saturating addition depending on the 10625 value of a special control register: 10626 10627 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3) 10628 (reg:SI 4)] 0)) 10629 (use (reg:SI 1))]) 10630 10631 This will not work, several of the optimizers only look at 10632 expressions locally; it is very likely that if you have multiple 10633 insns with identical inputs to the `unspec', they will be 10634 optimized away even if register 1 changes in between. 10635 10636 This means that `use' can _only_ be used to describe that the 10637 register is live. You should think twice before adding `use' 10638 statements, more often you will want to use `unspec' instead. The 10639 `use' RTX is most commonly useful to describe that a fixed 10640 register is implicitly used in an insn. It is also safe to use in 10641 patterns where the compiler knows for other reasons that the result 10642 of the whole pattern is variable, such as `movmemM' or `call' 10643 patterns. 10644 10645 During the reload phase, an insn that has a `use' as pattern can 10646 carry a reg_equal note. These `use' insns will be deleted before 10647 the reload phase exits. 10648 10649 During the delayed branch scheduling phase, X may be an insn. 10650 This indicates that X previously was located at this place in the 10651 code and its data dependencies need to be taken into account. 10652 These `use' insns will be deleted before the delayed branch 10653 scheduling phase exits. 10654 10655 `(parallel [X0 X1 ...])' 10656 Represents several side effects performed in parallel. The square 10657 brackets stand for a vector; the operand of `parallel' is a vector 10658 of expressions. X0, X1 and so on are individual side effect 10659 expressions--expressions of code `set', `call', `return', 10660 `clobber' or `use'. 10661 10662 "In parallel" means that first all the values used in the 10663 individual side-effects are computed, and second all the actual 10664 side-effects are performed. For example, 10665 10666 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) 10667 (set (mem:SI (reg:SI 1)) (reg:SI 1))]) 10668 10669 says unambiguously that the values of hard register 1 and the 10670 memory location addressed by it are interchanged. In both places 10671 where `(reg:SI 1)' appears as a memory address it refers to the 10672 value in register 1 _before_ the execution of the insn. 10673 10674 It follows that it is _incorrect_ to use `parallel' and expect the 10675 result of one `set' to be available for the next one. For 10676 example, people sometimes attempt to represent a jump-if-zero 10677 instruction this way: 10678 10679 (parallel [(set (cc0) (reg:SI 34)) 10680 (set (pc) (if_then_else 10681 (eq (cc0) (const_int 0)) 10682 (label_ref ...) 10683 (pc)))]) 10684 10685 But this is incorrect, because it says that the jump condition 10686 depends on the condition code value _before_ this instruction, not 10687 on the new value that is set by this instruction. 10688 10689 Peephole optimization, which takes place together with final 10690 assembly code output, can produce insns whose patterns consist of 10691 a `parallel' whose elements are the operands needed to output the 10692 resulting assembler code--often `reg', `mem' or constant 10693 expressions. This would not be well-formed RTL at any other stage 10694 in compilation, but it is ok then because no further optimization 10695 remains to be done. However, the definition of the macro 10696 `NOTICE_UPDATE_CC', if any, must deal with such insns if you 10697 define any peephole optimizations. 10698 10699 `(cond_exec [COND EXPR])' 10700 Represents a conditionally executed expression. The EXPR is 10701 executed only if the COND is nonzero. The COND expression must 10702 not have side-effects, but the EXPR may very well have 10703 side-effects. 10704 10705 `(sequence [INSNS ...])' 10706 Represents a sequence of insns. Each of the INSNS that appears in 10707 the vector is suitable for appearing in the chain of insns, so it 10708 must be an `insn', `jump_insn', `call_insn', `code_label', 10709 `barrier' or `note'. 10710 10711 A `sequence' RTX is never placed in an actual insn during RTL 10712 generation. It represents the sequence of insns that result from a 10713 `define_expand' _before_ those insns are passed to `emit_insn' to 10714 insert them in the chain of insns. When actually inserted, the 10715 individual sub-insns are separated out and the `sequence' is 10716 forgotten. 10717 10718 After delay-slot scheduling is completed, an insn and all the 10719 insns that reside in its delay slots are grouped together into a 10720 `sequence'. The insn requiring the delay slot is the first insn 10721 in the vector; subsequent insns are to be placed in the delay slot. 10722 10723 `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to 10724 indicate that a branch insn should be used that will conditionally 10725 annul the effect of the insns in the delay slots. In such a case, 10726 `INSN_FROM_TARGET_P' indicates that the insn is from the target of 10727 the branch and should be executed only if the branch is taken; 10728 otherwise the insn should be executed only if the branch is not 10729 taken. *Note Delay Slots::. 10730 10731 These expression codes appear in place of a side effect, as the body of 10732 an insn, though strictly speaking they do not always describe side 10733 effects as such: 10734 10735 `(asm_input S)' 10736 Represents literal assembler code as described by the string S. 10737 10738 `(unspec [OPERANDS ...] INDEX)' 10739 `(unspec_volatile [OPERANDS ...] INDEX)' 10740 Represents a machine-specific operation on OPERANDS. INDEX 10741 selects between multiple machine-specific operations. 10742 `unspec_volatile' is used for volatile operations and operations 10743 that may trap; `unspec' is used for other operations. 10744 10745 These codes may appear inside a `pattern' of an insn, inside a 10746 `parallel', or inside an expression. 10747 10748 `(addr_vec:M [LR0 LR1 ...])' 10749 Represents a table of jump addresses. The vector elements LR0, 10750 etc., are `label_ref' expressions. The mode M specifies how much 10751 space is given to each address; normally M would be `Pmode'. 10752 10753 `(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)' 10754 Represents a table of jump addresses expressed as offsets from 10755 BASE. The vector elements LR0, etc., are `label_ref' expressions 10756 and so is BASE. The mode M specifies how much space is given to 10757 each address-difference. MIN and MAX are set up by branch 10758 shortening and hold a label with a minimum and a maximum address, 10759 respectively. FLAGS indicates the relative position of BASE, MIN 10760 and MAX to the containing insn and of MIN and MAX to BASE. See 10761 rtl.def for details. 10762 10763 `(prefetch:M ADDR RW LOCALITY)' 10764 Represents prefetch of memory at address ADDR. Operand RW is 1 if 10765 the prefetch is for data to be written, 0 otherwise; targets that 10766 do not support write prefetches should treat this as a normal 10767 prefetch. Operand LOCALITY specifies the amount of temporal 10768 locality; 0 if there is none or 1, 2, or 3 for increasing levels 10769 of temporal locality; targets that do not support locality hints 10770 should ignore this. 10771 10772 This insn is used to minimize cache-miss latency by moving data 10773 into a cache before it is accessed. It should use only 10774 non-faulting data prefetch instructions. 10775 10776 10777 File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 10778 10779 12.16 Embedded Side-Effects on Addresses 10780 ======================================== 10781 10782 Six special side-effect expression codes appear as memory addresses. 10783 10784 `(pre_dec:M X)' 10785 Represents the side effect of decrementing X by a standard amount 10786 and represents also the value that X has after being decremented. 10787 X must be a `reg' or `mem', but most machines allow only a `reg'. 10788 M must be the machine mode for pointers on the machine in use. 10789 The amount X is decremented by is the length in bytes of the 10790 machine mode of the containing memory reference of which this 10791 expression serves as the address. Here is an example of its use: 10792 10793 (mem:DF (pre_dec:SI (reg:SI 39))) 10794 10795 This says to decrement pseudo register 39 by the length of a 10796 `DFmode' value and use the result to address a `DFmode' value. 10797 10798 `(pre_inc:M X)' 10799 Similar, but specifies incrementing X instead of decrementing it. 10800 10801 `(post_dec:M X)' 10802 Represents the same side effect as `pre_dec' but a different 10803 value. The value represented here is the value X has before being 10804 decremented. 10805 10806 `(post_inc:M X)' 10807 Similar, but specifies incrementing X instead of decrementing it. 10808 10809 `(post_modify:M X Y)' 10810 Represents the side effect of setting X to Y and represents X 10811 before X is modified. X must be a `reg' or `mem', but most 10812 machines allow only a `reg'. M must be the machine mode for 10813 pointers on the machine in use. 10814 10815 The expression Y must be one of three forms: 10816 `(plus:M X Z)', `(minus:M X Z)', or `(plus:M X I)', 10817 where Z is an index register and I is a constant. 10818 10819 Here is an example of its use: 10820 10821 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42) 10822 (reg:SI 48)))) 10823 10824 This says to modify pseudo register 42 by adding the contents of 10825 pseudo register 48 to it, after the use of what ever 42 points to. 10826 10827 `(pre_modify:M X EXPR)' 10828 Similar except side effects happen before the use. 10829 10830 These embedded side effect expressions must be used with care. 10831 Instruction patterns may not use them. Until the `flow' pass of the 10832 compiler, they may occur only to represent pushes onto the stack. The 10833 `flow' pass finds cases where registers are incremented or decremented 10834 in one instruction and used as an address shortly before or after; 10835 these cases are then transformed to use pre- or post-increment or 10836 -decrement. 10837 10838 If a register used as the operand of these expressions is used in 10839 another address in an insn, the original value of the register is used. 10840 Uses of the register outside of an address are not permitted within the 10841 same insn as a use in an embedded side effect expression because such 10842 insns behave differently on different machines and hence must be treated 10843 as ambiguous and disallowed. 10844 10845 An instruction that can be represented with an embedded side effect 10846 could also be represented using `parallel' containing an additional 10847 `set' to describe how the address register is altered. This is not 10848 done because machines that allow these operations at all typically 10849 allow them wherever a memory address is called for. Describing them as 10850 additional parallel stores would require doubling the number of entries 10851 in the machine description. 10852 10853 10854 File: gccint.info, Node: Assembler, Next: Insns, Prev: Incdec, Up: RTL 10855 10856 12.17 Assembler Instructions as Expressions 10857 =========================================== 10858 10859 The RTX code `asm_operands' represents a value produced by a 10860 user-specified assembler instruction. It is used to represent an `asm' 10861 statement with arguments. An `asm' statement with a single output 10862 operand, like this: 10863 10864 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); 10865 10866 is represented using a single `asm_operands' RTX which represents the 10867 value that is stored in `outputvar': 10868 10869 (set RTX-FOR-OUTPUTVAR 10870 (asm_operands "foo %1,%2,%0" "a" 0 10871 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] 10872 [(asm_input:M1 "g") 10873 (asm_input:M2 "di")])) 10874 10875 Here the operands of the `asm_operands' RTX are the assembler template 10876 string, the output-operand's constraint, the index-number of the output 10877 operand among the output operands specified, a vector of input operand 10878 RTX's, and a vector of input-operand modes and constraints. The mode 10879 M1 is the mode of the sum `x+y'; M2 is that of `*z'. 10880 10881 When an `asm' statement has multiple output values, its insn has 10882 several such `set' RTX's inside of a `parallel'. Each `set' contains a 10883 `asm_operands'; all of these share the same assembler template and 10884 vectors, but each contains the constraint for the respective output 10885 operand. They are also distinguished by the output-operand index 10886 number, which is 0, 1, ... for successive output operands. 10887 10888 10889 File: gccint.info, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL 10890 10891 12.18 Insns 10892 =========== 10893 10894 The RTL representation of the code for a function is a doubly-linked 10895 chain of objects called "insns". Insns are expressions with special 10896 codes that are used for no other purpose. Some insns are actual 10897 instructions; others represent dispatch tables for `switch' statements; 10898 others represent labels to jump to or various sorts of declarative 10899 information. 10900 10901 In addition to its own specific data, each insn must have a unique 10902 id-number that distinguishes it from all other insns in the current 10903 function (after delayed branch scheduling, copies of an insn with the 10904 same id-number may be present in multiple places in a function, but 10905 these copies will always be identical and will only appear inside a 10906 `sequence'), and chain pointers to the preceding and following insns. 10907 These three fields occupy the same position in every insn, independent 10908 of the expression code of the insn. They could be accessed with `XEXP' 10909 and `XINT', but instead three special macros are always used: 10910 10911 `INSN_UID (I)' 10912 Accesses the unique id of insn I. 10913 10914 `PREV_INSN (I)' 10915 Accesses the chain pointer to the insn preceding I. If I is the 10916 first insn, this is a null pointer. 10917 10918 `NEXT_INSN (I)' 10919 Accesses the chain pointer to the insn following I. If I is the 10920 last insn, this is a null pointer. 10921 10922 The first insn in the chain is obtained by calling `get_insns'; the 10923 last insn is the result of calling `get_last_insn'. Within the chain 10924 delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must 10925 always correspond: if INSN is not the first insn, 10926 10927 NEXT_INSN (PREV_INSN (INSN)) == INSN 10928 10929 is always true and if INSN is not the last insn, 10930 10931 PREV_INSN (NEXT_INSN (INSN)) == INSN 10932 10933 is always true. 10934 10935 After delay slot scheduling, some of the insns in the chain might be 10936 `sequence' expressions, which contain a vector of insns. The value of 10937 `NEXT_INSN' in all but the last of these insns is the next insn in the 10938 vector; the value of `NEXT_INSN' of the last insn in the vector is the 10939 same as the value of `NEXT_INSN' for the `sequence' in which it is 10940 contained. Similar rules apply for `PREV_INSN'. 10941 10942 This means that the above invariants are not necessarily true for insns 10943 inside `sequence' expressions. Specifically, if INSN is the first insn 10944 in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn containing 10945 the `sequence' expression, as is the value of `PREV_INSN (NEXT_INSN 10946 (INSN))' if INSN is the last insn in the `sequence' expression. You 10947 can use these expressions to find the containing `sequence' expression. 10948 10949 Every insn has one of the following six expression codes: 10950 10951 `insn' 10952 The expression code `insn' is used for instructions that do not 10953 jump and do not do function calls. `sequence' expressions are 10954 always contained in insns with code `insn' even if one of those 10955 insns should jump or do function calls. 10956 10957 Insns with code `insn' have four additional fields beyond the three 10958 mandatory ones listed above. These four are described in a table 10959 below. 10960 10961 `jump_insn' 10962 The expression code `jump_insn' is used for instructions that may 10963 jump (or, more generally, may contain `label_ref' expressions). If 10964 there is an instruction to return from the current function, it is 10965 recorded as a `jump_insn'. 10966 10967 `jump_insn' insns have the same extra fields as `insn' insns, 10968 accessed in the same way and in addition contain a field 10969 `JUMP_LABEL' which is defined once jump optimization has completed. 10970 10971 For simple conditional and unconditional jumps, this field contains 10972 the `code_label' to which this insn will (possibly conditionally) 10973 branch. In a more complex jump, `JUMP_LABEL' records one of the 10974 labels that the insn refers to; the only way to find the others is 10975 to scan the entire body of the insn. In an `addr_vec', 10976 `JUMP_LABEL' is `NULL_RTX'. 10977 10978 Return insns count as jumps, but since they do not refer to any 10979 labels, their `JUMP_LABEL' is `NULL_RTX'. 10980 10981 `call_insn' 10982 The expression code `call_insn' is used for instructions that may 10983 do function calls. It is important to distinguish these 10984 instructions because they imply that certain registers and memory 10985 locations may be altered unpredictably. 10986 10987 `call_insn' insns have the same extra fields as `insn' insns, 10988 accessed in the same way and in addition contain a field 10989 `CALL_INSN_FUNCTION_USAGE', which contains a list (chain of 10990 `expr_list' expressions) containing `use' and `clobber' 10991 expressions that denote hard registers and `MEM's used or 10992 clobbered by the called function. 10993 10994 A `MEM' generally points to a stack slots in which arguments passed 10995 to the libcall by reference (*note TARGET_PASS_BY_REFERENCE: 10996 Register Arguments.) are stored. If the argument is caller-copied 10997 (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot 10998 will be mentioned in `CLOBBER' and `USE' entries; if it's 10999 callee-copied, only a `USE' will appear, and the `MEM' may point 11000 to addresses that are not stack slots. 11001 11002 `CLOBBER'ed registers in this list augment registers specified in 11003 `CALL_USED_REGISTERS' (*note Register Basics::). 11004 11005 `code_label' 11006 A `code_label' insn represents a label that a jump insn can jump 11007 to. It contains two special fields of data in addition to the 11008 three standard ones. `CODE_LABEL_NUMBER' is used to hold the 11009 "label number", a number that identifies this label uniquely among 11010 all the labels in the compilation (not just in the current 11011 function). Ultimately, the label is represented in the assembler 11012 output as an assembler label, usually of the form `LN' where N is 11013 the label number. 11014 11015 When a `code_label' appears in an RTL expression, it normally 11016 appears within a `label_ref' which represents the address of the 11017 label, as a number. 11018 11019 Besides as a `code_label', a label can also be represented as a 11020 `note' of type `NOTE_INSN_DELETED_LABEL'. 11021 11022 The field `LABEL_NUSES' is only defined once the jump optimization 11023 phase is completed. It contains the number of times this label is 11024 referenced in the current function. 11025 11026 The field `LABEL_KIND' differentiates four different types of 11027 labels: `LABEL_NORMAL', `LABEL_STATIC_ENTRY', 11028 `LABEL_GLOBAL_ENTRY', and `LABEL_WEAK_ENTRY'. The only labels 11029 that do not have type `LABEL_NORMAL' are "alternate entry points" 11030 to the current function. These may be static (visible only in the 11031 containing translation unit), global (exposed to all translation 11032 units), or weak (global, but can be overridden by another symbol 11033 with the same name). 11034 11035 Much of the compiler treats all four kinds of label identically. 11036 Some of it needs to know whether or not a label is an alternate 11037 entry point; for this purpose, the macro `LABEL_ALT_ENTRY_P' is 11038 provided. It is equivalent to testing whether `LABEL_KIND (label) 11039 == LABEL_NORMAL'. The only place that cares about the distinction 11040 between static, global, and weak alternate entry points, besides 11041 the front-end code that creates them, is the function 11042 `output_alternate_entry_point', in `final.c'. 11043 11044 To set the kind of a label, use the `SET_LABEL_KIND' macro. 11045 11046 `barrier' 11047 Barriers are placed in the instruction stream when control cannot 11048 flow past them. They are placed after unconditional jump 11049 instructions to indicate that the jumps are unconditional and 11050 after calls to `volatile' functions, which do not return (e.g., 11051 `exit'). They contain no information beyond the three standard 11052 fields. 11053 11054 `note' 11055 `note' insns are used to represent additional debugging and 11056 declarative information. They contain two nonstandard fields, an 11057 integer which is accessed with the macro `NOTE_LINE_NUMBER' and a 11058 string accessed with `NOTE_SOURCE_FILE'. 11059 11060 If `NOTE_LINE_NUMBER' is positive, the note represents the 11061 position of a source line and `NOTE_SOURCE_FILE' is the source 11062 file name that the line came from. These notes control generation 11063 of line number data in the assembler output. 11064 11065 Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a 11066 code with one of the following values (and `NOTE_SOURCE_FILE' must 11067 contain a null pointer): 11068 11069 `NOTE_INSN_DELETED' 11070 Such a note is completely ignorable. Some passes of the 11071 compiler delete insns by altering them into notes of this 11072 kind. 11073 11074 `NOTE_INSN_DELETED_LABEL' 11075 This marks what used to be a `code_label', but was not used 11076 for other purposes than taking its address and was 11077 transformed to mark that no code jumps to it. 11078 11079 `NOTE_INSN_BLOCK_BEG' 11080 `NOTE_INSN_BLOCK_END' 11081 These types of notes indicate the position of the beginning 11082 and end of a level of scoping of variable names. They 11083 control the output of debugging information. 11084 11085 `NOTE_INSN_EH_REGION_BEG' 11086 `NOTE_INSN_EH_REGION_END' 11087 These types of notes indicate the position of the beginning 11088 and end of a level of scoping for exception handling. 11089 `NOTE_BLOCK_NUMBER' identifies which `CODE_LABEL' or `note' 11090 of type `NOTE_INSN_DELETED_LABEL' is associated with the 11091 given region. 11092 11093 `NOTE_INSN_LOOP_BEG' 11094 `NOTE_INSN_LOOP_END' 11095 These types of notes indicate the position of the beginning 11096 and end of a `while' or `for' loop. They enable the loop 11097 optimizer to find loops quickly. 11098 11099 `NOTE_INSN_LOOP_CONT' 11100 Appears at the place in a loop that `continue' statements 11101 jump to. 11102 11103 `NOTE_INSN_LOOP_VTOP' 11104 This note indicates the place in a loop where the exit test 11105 begins for those loops in which the exit test has been 11106 duplicated. This position becomes another virtual start of 11107 the loop when considering loop invariants. 11108 11109 `NOTE_INSN_FUNCTION_BEG' 11110 Appears at the start of the function body, after the function 11111 prologue. 11112 11113 `NOTE_INSN_FUNCTION_END' 11114 Appears near the end of the function body, just before the 11115 label that `return' statements jump to (on machine where a 11116 single instruction does not suffice for returning). This 11117 note may be deleted by jump optimization. 11118 11119 11120 These codes are printed symbolically when they appear in debugging 11121 dumps. 11122 11123 The machine mode of an insn is normally `VOIDmode', but some phases 11124 use the mode for various purposes. 11125 11126 The common subexpression elimination pass sets the mode of an insn to 11127 `QImode' when it is the first insn in a block that has already been 11128 processed. 11129 11130 The second Haifa scheduling pass, for targets that can multiple issue, 11131 sets the mode of an insn to `TImode' when it is believed that the 11132 instruction begins an issue group. That is, when the instruction 11133 cannot issue simultaneously with the previous. This may be relied on 11134 by later passes, in particular machine-dependent reorg. 11135 11136 Here is a table of the extra fields of `insn', `jump_insn' and 11137 `call_insn' insns: 11138 11139 `PATTERN (I)' 11140 An expression for the side effect performed by this insn. This 11141 must be one of the following codes: `set', `call', `use', 11142 `clobber', `return', `asm_input', `asm_output', `addr_vec', 11143 `addr_diff_vec', `trap_if', `unspec', `unspec_volatile', 11144 `parallel', `cond_exec', or `sequence'. If it is a `parallel', 11145 each element of the `parallel' must be one these codes, except that 11146 `parallel' expressions cannot be nested and `addr_vec' and 11147 `addr_diff_vec' are not permitted inside a `parallel' expression. 11148 11149 `INSN_CODE (I)' 11150 An integer that says which pattern in the machine description 11151 matches this insn, or -1 if the matching has not yet been 11152 attempted. 11153 11154 Such matching is never attempted and this field remains -1 on an 11155 insn whose pattern consists of a single `use', `clobber', 11156 `asm_input', `addr_vec' or `addr_diff_vec' expression. 11157 11158 Matching is also never attempted on insns that result from an `asm' 11159 statement. These contain at least one `asm_operands' expression. 11160 The function `asm_noperands' returns a non-negative value for such 11161 insns. 11162 11163 In the debugging output, this field is printed as a number 11164 followed by a symbolic representation that locates the pattern in 11165 the `md' file as some small positive or negative offset from a 11166 named pattern. 11167 11168 `LOG_LINKS (I)' 11169 A list (chain of `insn_list' expressions) giving information about 11170 dependencies between instructions within a basic block. Neither a 11171 jump nor a label may come between the related insns. 11172 11173 `REG_NOTES (I)' 11174 A list (chain of `expr_list' and `insn_list' expressions) giving 11175 miscellaneous information about the insn. It is often information 11176 pertaining to the registers used in this insn. 11177 11178 The `LOG_LINKS' field of an insn is a chain of `insn_list' 11179 expressions. Each of these has two operands: the first is an insn, and 11180 the second is another `insn_list' expression (the next one in the 11181 chain). The last `insn_list' in the chain has a null pointer as second 11182 operand. The significant thing about the chain is which insns appear 11183 in it (as first operands of `insn_list' expressions). Their order is 11184 not significant. 11185 11186 This list is originally set up by the flow analysis pass; it is a null 11187 pointer until then. Flow only adds links for those data dependencies 11188 which can be used for instruction combination. For each insn, the flow 11189 analysis pass adds a link to insns which store into registers values 11190 that are used for the first time in this insn. The instruction 11191 scheduling pass adds extra links so that every dependence will be 11192 represented. Links represent data dependencies, antidependencies and 11193 output dependencies; the machine mode of the link distinguishes these 11194 three types: antidependencies have mode `REG_DEP_ANTI', output 11195 dependencies have mode `REG_DEP_OUTPUT', and data dependencies have 11196 mode `VOIDmode'. 11197 11198 The `REG_NOTES' field of an insn is a chain similar to the `LOG_LINKS' 11199 field but it includes `expr_list' expressions in addition to 11200 `insn_list' expressions. There are several kinds of register notes, 11201 which are distinguished by the machine mode, which in a register note 11202 is really understood as being an `enum reg_note'. The first operand OP 11203 of the note is data whose meaning depends on the kind of note. 11204 11205 The macro `REG_NOTE_KIND (X)' returns the kind of register note. Its 11206 counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' sets the 11207 register note type of X to be NEWKIND. 11208 11209 Register notes are of three classes: They may say something about an 11210 input to an insn, they may say something about an output of an insn, or 11211 they may create a linkage between two insns. There are also a set of 11212 values that are only used in `LOG_LINKS'. 11213 11214 These register notes annotate inputs to an insn: 11215 11216 `REG_DEAD' 11217 The value in OP dies in this insn; that is to say, altering the 11218 value immediately after this insn would not affect the future 11219 behavior of the program. 11220 11221 It does not follow that the register OP has no useful value after 11222 this insn since OP is not necessarily modified by this insn. 11223 Rather, no subsequent instruction uses the contents of OP. 11224 11225 `REG_UNUSED' 11226 The register OP being set by this insn will not be used in a 11227 subsequent insn. This differs from a `REG_DEAD' note, which 11228 indicates that the value in an input will not be used subsequently. 11229 These two notes are independent; both may be present for the same 11230 register. 11231 11232 `REG_INC' 11233 The register OP is incremented (or decremented; at this level 11234 there is no distinction) by an embedded side effect inside this 11235 insn. This means it appears in a `post_inc', `pre_inc', 11236 `post_dec' or `pre_dec' expression. 11237 11238 `REG_NONNEG' 11239 The register OP is known to have a nonnegative value when this 11240 insn is reached. This is used so that decrement and branch until 11241 zero instructions, such as the m68k dbra, can be matched. 11242 11243 The `REG_NONNEG' note is added to insns only if the machine 11244 description has a `decrement_and_branch_until_zero' pattern. 11245 11246 `REG_NO_CONFLICT' 11247 This insn does not cause a conflict between OP and the item being 11248 set by this insn even though it might appear that it does. In 11249 other words, if the destination register and OP could otherwise be 11250 assigned the same register, this insn does not prevent that 11251 assignment. 11252 11253 Insns with this note are usually part of a block that begins with a 11254 `clobber' insn specifying a multi-word pseudo register (which will 11255 be the output of the block), a group of insns that each set one 11256 word of the value and have the `REG_NO_CONFLICT' note attached, 11257 and a final insn that copies the output to itself with an attached 11258 `REG_EQUAL' note giving the expression being computed. This block 11259 is encapsulated with `REG_LIBCALL' and `REG_RETVAL' notes on the 11260 first and last insns, respectively. 11261 11262 `REG_LABEL' 11263 This insn uses OP, a `code_label' or a `note' of type 11264 `NOTE_INSN_DELETED_LABEL', but is not a `jump_insn', or it is a 11265 `jump_insn' that required the label to be held in a register. The 11266 presence of this note allows jump optimization to be aware that OP 11267 is, in fact, being used, and flow optimization to build an 11268 accurate flow graph. 11269 11270 `REG_CROSSING_JUMP' 11271 This insn is an branching instruction (either an unconditional 11272 jump or an indirect jump) which crosses between hot and cold 11273 sections, which could potentially be very far apart in the 11274 executable. The presence of this note indicates to other 11275 optimizations that this this branching instruction should not be 11276 "collapsed" into a simpler branching construct. It is used when 11277 the optimization to partition basic blocks into hot and cold 11278 sections is turned on. 11279 11280 `REG_SETJMP' 11281 Appears attached to each `CALL_INSN' to `setjmp' or a related 11282 function. 11283 11284 The following notes describe attributes of outputs of an insn: 11285 11286 `REG_EQUIV' 11287 `REG_EQUAL' 11288 This note is only valid on an insn that sets only one register and 11289 indicates that that register will be equal to OP at run time; the 11290 scope of this equivalence differs between the two types of notes. 11291 The value which the insn explicitly copies into the register may 11292 look different from OP, but they will be equal at run time. If the 11293 output of the single `set' is a `strict_low_part' expression, the 11294 note refers to the register that is contained in `SUBREG_REG' of 11295 the `subreg' expression. 11296 11297 For `REG_EQUIV', the register is equivalent to OP throughout the 11298 entire function, and could validly be replaced in all its 11299 occurrences by OP. ("Validly" here refers to the data flow of the 11300 program; simple replacement may make some insns invalid.) For 11301 example, when a constant is loaded into a register that is never 11302 assigned any other value, this kind of note is used. 11303 11304 When a parameter is copied into a pseudo-register at entry to a 11305 function, a note of this kind records that the register is 11306 equivalent to the stack slot where the parameter was passed. 11307 Although in this case the register may be set by other insns, it 11308 is still valid to replace the register by the stack slot 11309 throughout the function. 11310 11311 A `REG_EQUIV' note is also used on an instruction which copies a 11312 register parameter into a pseudo-register at entry to a function, 11313 if there is a stack slot where that parameter could be stored. 11314 Although other insns may set the pseudo-register, it is valid for 11315 the compiler to replace the pseudo-register by stack slot 11316 throughout the function, provided the compiler ensures that the 11317 stack slot is properly initialized by making the replacement in 11318 the initial copy instruction as well. This is used on machines 11319 for which the calling convention allocates stack space for 11320 register parameters. See `REG_PARM_STACK_SPACE' in *Note Stack 11321 Arguments::. 11322 11323 In the case of `REG_EQUAL', the register that is set by this insn 11324 will be equal to OP at run time at the end of this insn but not 11325 necessarily elsewhere in the function. In this case, OP is 11326 typically an arithmetic expression. For example, when a sequence 11327 of insns such as a library call is used to perform an arithmetic 11328 operation, this kind of note is attached to the insn that produces 11329 or copies the final value. 11330 11331 These two notes are used in different ways by the compiler passes. 11332 `REG_EQUAL' is used by passes prior to register allocation (such as 11333 common subexpression elimination and loop optimization) to tell 11334 them how to think of that value. `REG_EQUIV' notes are used by 11335 register allocation to indicate that there is an available 11336 substitute expression (either a constant or a `mem' expression for 11337 the location of a parameter on the stack) that may be used in 11338 place of a register if insufficient registers are available. 11339 11340 Except for stack homes for parameters, which are indicated by a 11341 `REG_EQUIV' note and are not useful to the early optimization 11342 passes and pseudo registers that are equivalent to a memory 11343 location throughout their entire life, which is not detected until 11344 later in the compilation, all equivalences are initially indicated 11345 by an attached `REG_EQUAL' note. In the early stages of register 11346 allocation, a `REG_EQUAL' note is changed into a `REG_EQUIV' note 11347 if OP is a constant and the insn represents the only set of its 11348 destination register. 11349 11350 Thus, compiler passes prior to register allocation need only check 11351 for `REG_EQUAL' notes and passes subsequent to register allocation 11352 need only check for `REG_EQUIV' notes. 11353 11354 These notes describe linkages between insns. They occur in pairs: one 11355 insn has one of a pair of notes that points to a second insn, which has 11356 the inverse note pointing back to the first insn. 11357 11358 `REG_RETVAL' 11359 This insn copies the value of a multi-insn sequence (for example, a 11360 library call), and OP is the first insn of the sequence (for a 11361 library call, the first insn that was generated to set up the 11362 arguments for the library call). 11363 11364 Loop optimization uses this note to treat such a sequence as a 11365 single operation for code motion purposes and flow analysis uses 11366 this note to delete such sequences whose results are dead. 11367 11368 A `REG_EQUAL' note will also usually be attached to this insn to 11369 provide the expression being computed by the sequence. 11370 11371 These notes will be deleted after reload, since they are no longer 11372 accurate or useful. 11373 11374 `REG_LIBCALL' 11375 This is the inverse of `REG_RETVAL': it is placed on the first 11376 insn of a multi-insn sequence, and it points to the last one. 11377 11378 These notes are deleted after reload, since they are no longer 11379 useful or accurate. 11380 11381 `REG_CC_SETTER' 11382 `REG_CC_USER' 11383 On machines that use `cc0', the insns which set and use `cc0' set 11384 and use `cc0' are adjacent. However, when branch delay slot 11385 filling is done, this may no longer be true. In this case a 11386 `REG_CC_USER' note will be placed on the insn setting `cc0' to 11387 point to the insn using `cc0' and a `REG_CC_SETTER' note will be 11388 placed on the insn using `cc0' to point to the insn setting `cc0'. 11389 11390 These values are only used in the `LOG_LINKS' field, and indicate the 11391 type of dependency that each link represents. Links which indicate a 11392 data dependence (a read after write dependence) do not use any code, 11393 they simply have mode `VOIDmode', and are printed without any 11394 descriptive text. 11395 11396 `REG_DEP_ANTI' 11397 This indicates an anti dependence (a write after read dependence). 11398 11399 `REG_DEP_OUTPUT' 11400 This indicates an output dependence (a write after write 11401 dependence). 11402 11403 These notes describe information gathered from gcov profile data. They 11404 are stored in the `REG_NOTES' field of an insn as an `expr_list'. 11405 11406 `REG_BR_PROB' 11407 This is used to specify the ratio of branches to non-branches of a 11408 branch insn according to the profile data. The value is stored as 11409 a value between 0 and REG_BR_PROB_BASE; larger values indicate a 11410 higher probability that the branch will be taken. 11411 11412 `REG_BR_PRED' 11413 These notes are found in JUMP insns after delayed branch scheduling 11414 has taken place. They indicate both the direction and the 11415 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_* 11416 values. 11417 11418 `REG_FRAME_RELATED_EXPR' 11419 This is used on an RTX_FRAME_RELATED_P insn wherein the attached 11420 expression is used in place of the actual insn pattern. This is 11421 done in cases where the pattern is either complex or misleading. 11422 11423 For convenience, the machine mode in an `insn_list' or `expr_list' is 11424 printed using these symbolic codes in debugging dumps. 11425 11426 The only difference between the expression codes `insn_list' and 11427 `expr_list' is that the first operand of an `insn_list' is assumed to 11428 be an insn and is printed in debugging dumps as the insn's unique id; 11429 the first operand of an `expr_list' is printed in the ordinary way as 11430 an expression. 11431 11432 11433 File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL 11434 11435 12.19 RTL Representation of Function-Call Insns 11436 =============================================== 11437 11438 Insns that call subroutines have the RTL expression code `call_insn'. 11439 These insns must satisfy special rules, and their bodies must use a 11440 special RTL expression code, `call'. 11441 11442 A `call' expression has two operands, as follows: 11443 11444 (call (mem:FM ADDR) NBYTES) 11445 11446 Here NBYTES is an operand that represents the number of bytes of 11447 argument data being passed to the subroutine, FM is a machine mode 11448 (which must equal as the definition of the `FUNCTION_MODE' macro in the 11449 machine description) and ADDR represents the address of the subroutine. 11450 11451 For a subroutine that returns no value, the `call' expression as shown 11452 above is the entire body of the insn, except that the insn might also 11453 contain `use' or `clobber' expressions. 11454 11455 For a subroutine that returns a value whose mode is not `BLKmode', the 11456 value is returned in a hard register. If this register's number is R, 11457 then the body of the call insn looks like this: 11458 11459 (set (reg:M R) 11460 (call (mem:FM ADDR) NBYTES)) 11461 11462 This RTL expression makes it clear (to the optimizer passes) that the 11463 appropriate register receives a useful value in this insn. 11464 11465 When a subroutine returns a `BLKmode' value, it is handled by passing 11466 to the subroutine the address of a place to store the value. So the 11467 call insn itself does not "return" any value, and it has the same RTL 11468 form as a call that returns nothing. 11469 11470 On some machines, the call instruction itself clobbers some register, 11471 for example to contain the return address. `call_insn' insns on these 11472 machines should have a body which is a `parallel' that contains both 11473 the `call' expression and `clobber' expressions that indicate which 11474 registers are destroyed. Similarly, if the call instruction requires 11475 some register other than the stack pointer that is not explicitly 11476 mentioned in its RTL, a `use' subexpression should mention that 11477 register. 11478 11479 Functions that are called are assumed to modify all registers listed in 11480 the configuration macro `CALL_USED_REGISTERS' (*note Register Basics::) 11481 and, with the exception of `const' functions and library calls, to 11482 modify all of memory. 11483 11484 Insns containing just `use' expressions directly precede the 11485 `call_insn' insn to indicate which registers contain inputs to the 11486 function. Similarly, if registers other than those in 11487 `CALL_USED_REGISTERS' are clobbered by the called function, insns 11488 containing a single `clobber' follow immediately after the call to 11489 indicate which registers. 11490 11491 11492 File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL 11493 11494 12.20 Structure Sharing Assumptions 11495 =================================== 11496 11497 The compiler assumes that certain kinds of RTL expressions are unique; 11498 there do not exist two distinct objects representing the same value. 11499 In other cases, it makes an opposite assumption: that no RTL expression 11500 object of a certain kind appears in more than one place in the 11501 containing structure. 11502 11503 These assumptions refer to a single function; except for the RTL 11504 objects that describe global variables and external functions, and a 11505 few standard objects such as small integer constants, no RTL objects 11506 are common to two functions. 11507 11508 * Each pseudo-register has only a single `reg' object to represent 11509 it, and therefore only a single machine mode. 11510 11511 * For any symbolic label, there is only one `symbol_ref' object 11512 referring to it. 11513 11514 * All `const_int' expressions with equal values are shared. 11515 11516 * There is only one `pc' expression. 11517 11518 * There is only one `cc0' expression. 11519 11520 * There is only one `const_double' expression with value 0 for each 11521 floating point mode. Likewise for values 1 and 2. 11522 11523 * There is only one `const_vector' expression with value 0 for each 11524 vector mode, be it an integer or a double constant vector. 11525 11526 * No `label_ref' or `scratch' appears in more than one place in the 11527 RTL structure; in other words, it is safe to do a tree-walk of all 11528 the insns in the function and assume that each time a `label_ref' 11529 or `scratch' is seen it is distinct from all others that are seen. 11530 11531 * Only one `mem' object is normally created for each static variable 11532 or stack slot, so these objects are frequently shared in all the 11533 places they appear. However, separate but equal objects for these 11534 variables are occasionally made. 11535 11536 * When a single `asm' statement has multiple output operands, a 11537 distinct `asm_operands' expression is made for each output operand. 11538 However, these all share the vector which contains the sequence of 11539 input operands. This sharing is used later on to test whether two 11540 `asm_operands' expressions come from the same statement, so all 11541 optimizations must carefully preserve the sharing if they copy the 11542 vector at all. 11543 11544 * No RTL object appears in more than one place in the RTL structure 11545 except as described above. Many passes of the compiler rely on 11546 this by assuming that they can modify RTL objects in place without 11547 unwanted side-effects on other insns. 11548 11549 * During initial RTL generation, shared structure is freely 11550 introduced. After all the RTL for a function has been generated, 11551 all shared structure is copied by `unshare_all_rtl' in 11552 `emit-rtl.c', after which the above rules are guaranteed to be 11553 followed. 11554 11555 * During the combiner pass, shared structure within an insn can exist 11556 temporarily. However, the shared structure is copied before the 11557 combiner is finished with the insn. This is done by calling 11558 `copy_rtx_if_shared', which is a subroutine of `unshare_all_rtl'. 11559 11560 11561 File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL 11562 11563 12.21 Reading RTL 11564 ================= 11565 11566 To read an RTL object from a file, call `read_rtx'. It takes one 11567 argument, a stdio stream, and returns a single RTL object. This routine 11568 is defined in `read-rtl.c'. It is not available in the compiler 11569 itself, only the various programs that generate the compiler back end 11570 from the machine description. 11571 11572 People frequently have the idea of using RTL stored as text in a file 11573 as an interface between a language front end and the bulk of GCC. This 11574 idea is not feasible. 11575 11576 GCC was designed to use RTL internally only. Correct RTL for a given 11577 program is very dependent on the particular target machine. And the RTL 11578 does not contain all the information about the program. 11579 11580 The proper way to interface GCC to a new language front end is with 11581 the "tree" data structure, described in the files `tree.h' and 11582 `tree.def'. The documentation for this structure (*note Trees::) is 11583 incomplete. 11584 11585 11586 File: gccint.info, Node: Control Flow, Next: Tree SSA, Prev: RTL, Up: Top 11587 11588 13 Control Flow Graph 11589 ********************* 11590 11591 A control flow graph (CFG) is a data structure built on top of the 11592 intermediate code representation (the RTL or `tree' instruction stream) 11593 abstracting the control flow behavior of a function that is being 11594 compiled. The CFG is a directed graph where the vertices represent 11595 basic blocks and edges represent possible transfer of control flow from 11596 one basic block to another. The data structures used to represent the 11597 control flow graph are defined in `basic-block.h'. 11598 11599 * Menu: 11600 11601 * Basic Blocks:: The definition and representation of basic blocks. 11602 * Edges:: Types of edges and their representation. 11603 * Profile information:: Representation of frequencies and probabilities. 11604 * Maintaining the CFG:: Keeping the control flow graph and up to date. 11605 * Liveness information:: Using and maintaining liveness information. 11606 11607 11608 File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow 11609 11610 13.1 Basic Blocks 11611 ================= 11612 11613 A basic block is a straight-line sequence of code with only one entry 11614 point and only one exit. In GCC, basic blocks are represented using 11615 the `basic_block' data type. 11616 11617 Two pointer members of the `basic_block' structure are the pointers 11618 `next_bb' and `prev_bb'. These are used to keep doubly linked chain of 11619 basic blocks in the same order as the underlying instruction stream. 11620 The chain of basic blocks is updated transparently by the provided API 11621 for manipulating the CFG. The macro `FOR_EACH_BB' can be used to visit 11622 all the basic blocks in lexicographical order. Dominator traversals 11623 are also possible using `walk_dominator_tree'. Given two basic blocks 11624 A and B, block A dominates block B if A is _always_ executed before B. 11625 11626 The `BASIC_BLOCK' array contains all basic blocks in an unspecified 11627 order. Each `basic_block' structure has a field that holds a unique 11628 integer identifier `index' that is the index of the block in the 11629 `BASIC_BLOCK' array. The total number of basic blocks in the function 11630 is `n_basic_blocks'. Both the basic block indices and the total number 11631 of basic blocks may vary during the compilation process, as passes 11632 reorder, create, duplicate, and destroy basic blocks. The index for 11633 any block should never be greater than `last_basic_block'. 11634 11635 Special basic blocks represent possible entry and exit points of a 11636 function. These blocks are called `ENTRY_BLOCK_PTR' and 11637 `EXIT_BLOCK_PTR'. These blocks do not contain any code, and are not 11638 elements of the `BASIC_BLOCK' array. Therefore they have been assigned 11639 unique, negative index numbers. 11640 11641 Each `basic_block' also contains pointers to the first instruction 11642 (the "head") and the last instruction (the "tail") or "end" of the 11643 instruction stream contained in a basic block. In fact, since the 11644 `basic_block' data type is used to represent blocks in both major 11645 intermediate representations of GCC (`tree' and RTL), there are 11646 pointers to the head and end of a basic block for both representations. 11647 11648 For RTL, these pointers are `rtx head, end'. In the RTL function 11649 representation, the head pointer always points either to a 11650 `NOTE_INSN_BASIC_BLOCK' or to a `CODE_LABEL', if present. In the RTL 11651 representation of a function, the instruction stream contains not only 11652 the "real" instructions, but also "notes". Any function that moves or 11653 duplicates the basic blocks needs to take care of updating of these 11654 notes. Many of these notes expect that the instruction stream consists 11655 of linear regions, making such updates difficult. The 11656 `NOTE_INSN_BASIC_BLOCK' note is the only kind of note that may appear 11657 in the instruction stream contained in a basic block. The instruction 11658 stream of a basic block always follows a `NOTE_INSN_BASIC_BLOCK', but 11659 zero or more `CODE_LABEL' nodes can precede the block note. A basic 11660 block ends by control flow instruction or last instruction before 11661 following `CODE_LABEL' or `NOTE_INSN_BASIC_BLOCK'. A `CODE_LABEL' 11662 cannot appear in the instruction stream of a basic block. 11663 11664 In addition to notes, the jump table vectors are also represented as 11665 "pseudo-instructions" inside the insn stream. These vectors never 11666 appear in the basic block and should always be placed just after the 11667 table jump instructions referencing them. After removing the 11668 table-jump it is often difficult to eliminate the code computing the 11669 address and referencing the vector, so cleaning up these vectors is 11670 postponed until after liveness analysis. Thus the jump table vectors 11671 may appear in the insn stream unreferenced and without any purpose. 11672 Before any edge is made "fall-thru", the existence of such construct in 11673 the way needs to be checked by calling `can_fallthru' function. 11674 11675 For the `tree' representation, the head and end of the basic block are 11676 being pointed to by the `stmt_list' field, but this special `tree' 11677 should never be referenced directly. Instead, at the tree level 11678 abstract containers and iterators are used to access statements and 11679 expressions in basic blocks. These iterators are called "block 11680 statement iterators" (BSIs). Grep for `^bsi' in the various `tree-*' 11681 files. The following snippet will pretty-print all the statements of 11682 the program in the GIMPLE representation. 11683 11684 FOR_EACH_BB (bb) 11685 { 11686 block_stmt_iterator si; 11687 11688 for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (&si)) 11689 { 11690 tree stmt = bsi_stmt (si); 11691 print_generic_stmt (stderr, stmt, 0); 11692 } 11693 } 11694 11695 11696 File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow 11697 11698 13.2 Edges 11699 ========== 11700 11701 Edges represent possible control flow transfers from the end of some 11702 basic block A to the head of another basic block B. We say that A is a 11703 predecessor of B, and B is a successor of A. Edges are represented in 11704 GCC with the `edge' data type. Each `edge' acts as a link between two 11705 basic blocks: the `src' member of an edge points to the predecessor 11706 basic block of the `dest' basic block. The members `preds' and `succs' 11707 of the `basic_block' data type point to type-safe vectors of edges to 11708 the predecessors and successors of the block. 11709 11710 When walking the edges in an edge vector, "edge iterators" should be 11711 used. Edge iterators are constructed using the `edge_iterator' data 11712 structure and several methods are available to operate on them: 11713 11714 `ei_start' 11715 This function initializes an `edge_iterator' that points to the 11716 first edge in a vector of edges. 11717 11718 `ei_last' 11719 This function initializes an `edge_iterator' that points to the 11720 last edge in a vector of edges. 11721 11722 `ei_end_p' 11723 This predicate is `true' if an `edge_iterator' represents the last 11724 edge in an edge vector. 11725 11726 `ei_one_before_end_p' 11727 This predicate is `true' if an `edge_iterator' represents the 11728 second last edge in an edge vector. 11729 11730 `ei_next' 11731 This function takes a pointer to an `edge_iterator' and makes it 11732 point to the next edge in the sequence. 11733 11734 `ei_prev' 11735 This function takes a pointer to an `edge_iterator' and makes it 11736 point to the previous edge in the sequence. 11737 11738 `ei_edge' 11739 This function returns the `edge' currently pointed to by an 11740 `edge_iterator'. 11741 11742 `ei_safe_safe' 11743 This function returns the `edge' currently pointed to by an 11744 `edge_iterator', but returns `NULL' if the iterator is pointing at 11745 the end of the sequence. This function has been provided for 11746 existing code makes the assumption that a `NULL' edge indicates 11747 the end of the sequence. 11748 11749 11750 The convenience macro `FOR_EACH_EDGE' can be used to visit all of the 11751 edges in a sequence of predecessor or successor edges. It must not be 11752 used when an element might be removed during the traversal, otherwise 11753 elements will be missed. Here is an example of how to use the macro: 11754 11755 edge e; 11756 edge_iterator ei; 11757 11758 FOR_EACH_EDGE (e, ei, bb->succs) 11759 { 11760 if (e->flags & EDGE_FALLTHRU) 11761 break; 11762 } 11763 11764 There are various reasons why control flow may transfer from one block 11765 to another. One possibility is that some instruction, for example a 11766 `CODE_LABEL', in a linearized instruction stream just always starts a 11767 new basic block. In this case a "fall-thru" edge links the basic block 11768 to the first following basic block. But there are several other 11769 reasons why edges may be created. The `flags' field of the `edge' data 11770 type is used to store information about the type of edge we are dealing 11771 with. Each edge is of one of the following types: 11772 11773 _jump_ 11774 No type flags are set for edges corresponding to jump instructions. 11775 These edges are used for unconditional or conditional jumps and in 11776 RTL also for table jumps. They are the easiest to manipulate as 11777 they may be freely redirected when the flow graph is not in SSA 11778 form. 11779 11780 _fall-thru_ 11781 Fall-thru edges are present in case where the basic block may 11782 continue execution to the following one without branching. These 11783 edges have the `EDGE_FALLTHRU' flag set. Unlike other types of 11784 edges, these edges must come into the basic block immediately 11785 following in the instruction stream. The function 11786 `force_nonfallthru' is available to insert an unconditional jump 11787 in the case that redirection is needed. Note that this may 11788 require creation of a new basic block. 11789 11790 _exception handling_ 11791 Exception handling edges represent possible control transfers from 11792 a trapping instruction to an exception handler. The definition of 11793 "trapping" varies. In C++, only function calls can throw, but for 11794 Java, exceptions like division by zero or segmentation fault are 11795 defined and thus each instruction possibly throwing this kind of 11796 exception needs to be handled as control flow instruction. 11797 Exception edges have the `EDGE_ABNORMAL' and `EDGE_EH' flags set. 11798 11799 When updating the instruction stream it is easy to change possibly 11800 trapping instruction to non-trapping, by simply removing the 11801 exception edge. The opposite conversion is difficult, but should 11802 not happen anyway. The edges can be eliminated via 11803 `purge_dead_edges' call. 11804 11805 In the RTL representation, the destination of an exception edge is 11806 specified by `REG_EH_REGION' note attached to the insn. In case 11807 of a trapping call the `EDGE_ABNORMAL_CALL' flag is set too. In 11808 the `tree' representation, this extra flag is not set. 11809 11810 In the RTL representation, the predicate `may_trap_p' may be used 11811 to check whether instruction still may trap or not. For the tree 11812 representation, the `tree_could_trap_p' predicate is available, 11813 but this predicate only checks for possible memory traps, as in 11814 dereferencing an invalid pointer location. 11815 11816 _sibling calls_ 11817 Sibling calls or tail calls terminate the function in a 11818 non-standard way and thus an edge to the exit must be present. 11819 `EDGE_SIBCALL' and `EDGE_ABNORMAL' are set in such case. These 11820 edges only exist in the RTL representation. 11821 11822 _computed jumps_ 11823 Computed jumps contain edges to all labels in the function 11824 referenced from the code. All those edges have `EDGE_ABNORMAL' 11825 flag set. The edges used to represent computed jumps often cause 11826 compile time performance problems, since functions consisting of 11827 many taken labels and many computed jumps may have _very_ dense 11828 flow graphs, so these edges need to be handled with special care. 11829 During the earlier stages of the compilation process, GCC tries to 11830 avoid such dense flow graphs by factoring computed jumps. For 11831 example, given the following series of jumps, 11832 11833 goto *x; 11834 [ ... ] 11835 11836 goto *x; 11837 [ ... ] 11838 11839 goto *x; 11840 [ ... ] 11841 11842 factoring the computed jumps results in the following code sequence 11843 which has a much simpler flow graph: 11844 11845 goto y; 11846 [ ... ] 11847 11848 goto y; 11849 [ ... ] 11850 11851 goto y; 11852 [ ... ] 11853 11854 y: 11855 goto *x; 11856 11857 However, the classic problem with this transformation is that it 11858 has a runtime cost in there resulting code: An extra jump. 11859 Therefore, the computed jumps are un-factored in the later passes 11860 of the compiler. Be aware of that when you work on passes in that 11861 area. There have been numerous examples already where the compile 11862 time for code with unfactored computed jumps caused some serious 11863 headaches. 11864 11865 _nonlocal goto handlers_ 11866 GCC allows nested functions to return into caller using a `goto' 11867 to a label passed to as an argument to the callee. The labels 11868 passed to nested functions contain special code to cleanup after 11869 function call. Such sections of code are referred to as "nonlocal 11870 goto receivers". If a function contains such nonlocal goto 11871 receivers, an edge from the call to the label is created with the 11872 `EDGE_ABNORMAL' and `EDGE_ABNORMAL_CALL' flags set. 11873 11874 _function entry points_ 11875 By definition, execution of function starts at basic block 0, so 11876 there is always an edge from the `ENTRY_BLOCK_PTR' to basic block 11877 0. There is no `tree' representation for alternate entry points at 11878 this moment. In RTL, alternate entry points are specified by 11879 `CODE_LABEL' with `LABEL_ALTERNATE_NAME' defined. This feature is 11880 currently used for multiple entry point prologues and is limited 11881 to post-reload passes only. This can be used by back-ends to emit 11882 alternate prologues for functions called from different contexts. 11883 In future full support for multiple entry functions defined by 11884 Fortran 90 needs to be implemented. 11885 11886 _function exits_ 11887 In the pre-reload representation a function terminates after the 11888 last instruction in the insn chain and no explicit return 11889 instructions are used. This corresponds to the fall-thru edge 11890 into exit block. After reload, optimal RTL epilogues are used 11891 that use explicit (conditional) return instructions that are 11892 represented by edges with no flags set. 11893 11894 11895 11896 File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow 11897 11898 13.3 Profile information 11899 ======================== 11900 11901 In many cases a compiler must make a choice whether to trade speed in 11902 one part of code for speed in another, or to trade code size for code 11903 speed. In such cases it is useful to know information about how often 11904 some given block will be executed. That is the purpose for maintaining 11905 profile within the flow graph. GCC can handle profile information 11906 obtained through "profile feedback", but it can also estimate branch 11907 probabilities based on statics and heuristics. 11908 11909 The feedback based profile is produced by compiling the program with 11910 instrumentation, executing it on a train run and reading the numbers of 11911 executions of basic blocks and edges back to the compiler while 11912 re-compiling the program to produce the final executable. This method 11913 provides very accurate information about where a program spends most of 11914 its time on the train run. Whether it matches the average run of 11915 course depends on the choice of train data set, but several studies 11916 have shown that the behavior of a program usually changes just 11917 marginally over different data sets. 11918 11919 When profile feedback is not available, the compiler may be asked to 11920 attempt to predict the behavior of each branch in the program using a 11921 set of heuristics (see `predict.def' for details) and compute estimated 11922 frequencies of each basic block by propagating the probabilities over 11923 the graph. 11924 11925 Each `basic_block' contains two integer fields to represent profile 11926 information: `frequency' and `count'. The `frequency' is an estimation 11927 how often is basic block executed within a function. It is represented 11928 as an integer scaled in the range from 0 to `BB_FREQ_BASE'. The most 11929 frequently executed basic block in function is initially set to 11930 `BB_FREQ_BASE' and the rest of frequencies are scaled accordingly. 11931 During optimization, the frequency of the most frequent basic block can 11932 both decrease (for instance by loop unrolling) or grow (for instance by 11933 cross-jumping optimization), so scaling sometimes has to be performed 11934 multiple times. 11935 11936 The `count' contains hard-counted numbers of execution measured during 11937 training runs and is nonzero only when profile feedback is available. 11938 This value is represented as the host's widest integer (typically a 64 11939 bit integer) of the special type `gcov_type'. 11940 11941 Most optimization passes can use only the frequency information of a 11942 basic block, but a few passes may want to know hard execution counts. 11943 The frequencies should always match the counts after scaling, however 11944 during updating of the profile information numerical error may 11945 accumulate into quite large errors. 11946 11947 Each edge also contains a branch probability field: an integer in the 11948 range from 0 to `REG_BR_PROB_BASE'. It represents probability of 11949 passing control from the end of the `src' basic block to the `dest' 11950 basic block, i.e. the probability that control will flow along this 11951 edge. The `EDGE_FREQUENCY' macro is available to compute how 11952 frequently a given edge is taken. There is a `count' field for each 11953 edge as well, representing same information as for a basic block. 11954 11955 The basic block frequencies are not represented in the instruction 11956 stream, but in the RTL representation the edge frequencies are 11957 represented for conditional jumps (via the `REG_BR_PROB' macro) since 11958 they are used when instructions are output to the assembly file and the 11959 flow graph is no longer maintained. 11960 11961 The probability that control flow arrives via a given edge to its 11962 destination basic block is called "reverse probability" and is not 11963 directly represented, but it may be easily computed from frequencies of 11964 basic blocks. 11965 11966 Updating profile information is a delicate task that can unfortunately 11967 not be easily integrated with the CFG manipulation API. Many of the 11968 functions and hooks to modify the CFG, such as 11969 `redirect_edge_and_branch', do not have enough information to easily 11970 update the profile, so updating it is in the majority of cases left up 11971 to the caller. It is difficult to uncover bugs in the profile updating 11972 code, because they manifest themselves only by producing worse code, 11973 and checking profile consistency is not possible because of numeric 11974 error accumulation. Hence special attention needs to be given to this 11975 issue in each pass that modifies the CFG. 11976 11977 It is important to point out that `REG_BR_PROB_BASE' and 11978 `BB_FREQ_BASE' are both set low enough to be possible to compute second 11979 power of any frequency or probability in the flow graph, it is not 11980 possible to even square the `count' field, as modern CPUs are fast 11981 enough to execute $2^32$ operations quickly. 11982 11983 11984 File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow 11985 11986 13.4 Maintaining the CFG 11987 ======================== 11988 11989 An important task of each compiler pass is to keep both the control 11990 flow graph and all profile information up-to-date. Reconstruction of 11991 the control flow graph after each pass is not an option, since it may be 11992 very expensive and lost profile information cannot be reconstructed at 11993 all. 11994 11995 GCC has two major intermediate representations, and both use the 11996 `basic_block' and `edge' data types to represent control flow. Both 11997 representations share as much of the CFG maintenance code as possible. 11998 For each representation, a set of "hooks" is defined so that each 11999 representation can provide its own implementation of CFG manipulation 12000 routines when necessary. These hooks are defined in `cfghooks.h'. 12001 There are hooks for almost all common CFG manipulations, including 12002 block splitting and merging, edge redirection and creating and deleting 12003 basic blocks. These hooks should provide everything you need to 12004 maintain and manipulate the CFG in both the RTL and `tree' 12005 representation. 12006 12007 At the moment, the basic block boundaries are maintained transparently 12008 when modifying instructions, so there rarely is a need to move them 12009 manually (such as in case someone wants to output instruction outside 12010 basic block explicitly). Often the CFG may be better viewed as 12011 integral part of instruction chain, than structure built on the top of 12012 it. However, in principle the control flow graph for the `tree' 12013 representation is _not_ an integral part of the representation, in that 12014 a function tree may be expanded without first building a flow graph 12015 for the `tree' representation at all. This happens when compiling 12016 without any `tree' optimization enabled. When the `tree' optimizations 12017 are enabled and the instruction stream is rewritten in SSA form, the 12018 CFG is very tightly coupled with the instruction stream. In 12019 particular, statement insertion and removal has to be done with care. 12020 In fact, the whole `tree' representation can not be easily used or 12021 maintained without proper maintenance of the CFG simultaneously. 12022 12023 In the RTL representation, each instruction has a `BLOCK_FOR_INSN' 12024 value that represents pointer to the basic block that contains the 12025 instruction. In the `tree' representation, the function `bb_for_stmt' 12026 returns a pointer to the basic block containing the queried statement. 12027 12028 When changes need to be applied to a function in its `tree' 12029 representation, "block statement iterators" should be used. These 12030 iterators provide an integrated abstraction of the flow graph and the 12031 instruction stream. Block statement iterators iterators are 12032 constructed using the `block_stmt_iterator' data structure and several 12033 modifier are available, including the following: 12034 12035 `bsi_start' 12036 This function initializes a `block_stmt_iterator' that points to 12037 the first non-empty statement in a basic block. 12038 12039 `bsi_last' 12040 This function initializes a `block_stmt_iterator' that points to 12041 the last statement in a basic block. 12042 12043 `bsi_end_p' 12044 This predicate is `true' if a `block_stmt_iterator' represents the 12045 end of a basic block. 12046 12047 `bsi_next' 12048 This function takes a `block_stmt_iterator' and makes it point to 12049 its successor. 12050 12051 `bsi_prev' 12052 This function takes a `block_stmt_iterator' and makes it point to 12053 its predecessor. 12054 12055 `bsi_insert_after' 12056 This function inserts a statement after the `block_stmt_iterator' 12057 passed in. The final parameter determines whether the statement 12058 iterator is updated to point to the newly inserted statement, or 12059 left pointing to the original statement. 12060 12061 `bsi_insert_before' 12062 This function inserts a statement before the `block_stmt_iterator' 12063 passed in. The final parameter determines whether the statement 12064 iterator is updated to point to the newly inserted statement, or 12065 left pointing to the original statement. 12066 12067 `bsi_remove' 12068 This function removes the `block_stmt_iterator' passed in and 12069 rechains the remaining statements in a basic block, if any. 12070 12071 In the RTL representation, the macros `BB_HEAD' and `BB_END' may be 12072 used to get the head and end `rtx' of a basic block. No abstract 12073 iterators are defined for traversing the insn chain, but you can just 12074 use `NEXT_INSN' and `PREV_INSN' instead. See *Note Insns::. 12075 12076 Usually a code manipulating pass simplifies the instruction stream and 12077 the flow of control, possibly eliminating some edges. This may for 12078 example happen when a conditional jump is replaced with an 12079 unconditional jump, but also when simplifying possibly trapping 12080 instruction to non-trapping while compiling Java. Updating of edges is 12081 not transparent and each optimization pass is required to do so 12082 manually. However only few cases occur in practice. The pass may call 12083 `purge_dead_edges' on a given basic block to remove superfluous edges, 12084 if any. 12085 12086 Another common scenario is redirection of branch instructions, but 12087 this is best modeled as redirection of edges in the control flow graph 12088 and thus use of `redirect_edge_and_branch' is preferred over more low 12089 level functions, such as `redirect_jump' that operate on RTL chain 12090 only. The CFG hooks defined in `cfghooks.h' should provide the 12091 complete API required for manipulating and maintaining the CFG. 12092 12093 It is also possible that a pass has to insert control flow instruction 12094 into the middle of a basic block, thus creating an entry point in the 12095 middle of the basic block, which is impossible by definition: The block 12096 must be split to make sure it only has one entry point, i.e. the head 12097 of the basic block. The CFG hook `split_block' may be used when an 12098 instruction in the middle of a basic block has to become the target of 12099 a jump or branch instruction. 12100 12101 For a global optimizer, a common operation is to split edges in the 12102 flow graph and insert instructions on them. In the RTL representation, 12103 this can be easily done using the `insert_insn_on_edge' function that 12104 emits an instruction "on the edge", caching it for a later 12105 `commit_edge_insertions' call that will take care of moving the 12106 inserted instructions off the edge into the instruction stream 12107 contained in a basic block. This includes the creation of new basic 12108 blocks where needed. In the `tree' representation, the equivalent 12109 functions are `bsi_insert_on_edge' which inserts a block statement 12110 iterator on an edge, and `bsi_commit_edge_inserts' which flushes the 12111 instruction to actual instruction stream. 12112 12113 While debugging the optimization pass, an `verify_flow_info' function 12114 may be useful to find bugs in the control flow graph updating code. 12115 12116 Note that at present, the representation of control flow in the `tree' 12117 representation is discarded before expanding to RTL. Long term the CFG 12118 should be maintained and "expanded" to the RTL representation along 12119 with the function `tree' itself. 12120 12121 12122 File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow 12123 12124 13.5 Liveness information 12125 ========================= 12126 12127 Liveness information is useful to determine whether some register is 12128 "live" at given point of program, i.e. that it contains a value that 12129 may be used at a later point in the program. This information is used, 12130 for instance, during register allocation, as the pseudo registers only 12131 need to be assigned to a unique hard register or to a stack slot if 12132 they are live. The hard registers and stack slots may be freely reused 12133 for other values when a register is dead. 12134 12135 The liveness information is stored partly in the RTL instruction 12136 stream and partly in the flow graph. Local information is stored in 12137 the instruction stream: Each instruction may contain `REG_DEAD' notes 12138 representing that the value of a given register is no longer needed, or 12139 `REG_UNUSED' notes representing that the value computed by the 12140 instruction is never used. The second is useful for instructions 12141 computing multiple values at once. 12142 12143 Global liveness information is stored in the control flow graph. Each 12144 basic block contains two bitmaps, `global_live_at_start' and 12145 `global_live_at_end' representing liveness of each register at the 12146 entry and exit of the basic block. The file `flow.c' contains 12147 functions to compute liveness of each register at any given place in 12148 the instruction stream using this information. 12149 12150 Liveness is expensive to compute and thus it is desirable to keep it 12151 up to date during code modifying passes. This can be easily 12152 accomplished using the `flags' field of a basic block. Functions 12153 modifying the instruction stream automatically set the `BB_DIRTY' flag 12154 of a modifies basic block, so the pass may simply use`clear_bb_flags' 12155 before doing any modifications and then ask the data flow module to 12156 have liveness updated via the `update_life_info_in_dirty_blocks' 12157 function. 12158 12159 This scheme works reliably as long as no control flow graph 12160 transformations are done. The task of updating liveness after control 12161 flow graph changes is more difficult as normal iterative data flow 12162 analysis may produce invalid results or get into an infinite cycle when 12163 the initial solution is not below the desired one. Only simple 12164 transformations, like splitting basic blocks or inserting on edges, are 12165 safe, as functions to implement them already know how to update 12166 liveness information locally. 12167 12168 12169 File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Loop Analysis and Representation, Up: Top 12170 12171 14 Machine Descriptions 12172 *********************** 12173 12174 A machine description has two parts: a file of instruction patterns 12175 (`.md' file) and a C header file of macro definitions. 12176 12177 The `.md' file for a target machine contains a pattern for each 12178 instruction that the target machine supports (or at least each 12179 instruction that is worth telling the compiler about). It may also 12180 contain comments. A semicolon causes the rest of the line to be a 12181 comment, unless the semicolon is inside a quoted string. 12182 12183 See the next chapter for information on the C header file. 12184 12185 * Menu: 12186 12187 * Overview:: How the machine description is used. 12188 * Patterns:: How to write instruction patterns. 12189 * Example:: An explained example of a `define_insn' pattern. 12190 * RTL Template:: The RTL template defines what insns match a pattern. 12191 * Output Template:: The output template says how to make assembler code 12192 from such an insn. 12193 * Output Statement:: For more generality, write C code to output 12194 the assembler code. 12195 * Predicates:: Controlling what kinds of operands can be used 12196 for an insn. 12197 * Constraints:: Fine-tuning operand selection. 12198 * Standard Names:: Names mark patterns to use for code generation. 12199 * Pattern Ordering:: When the order of patterns makes a difference. 12200 * Dependent Patterns:: Having one pattern may make you need another. 12201 * Jump Patterns:: Special considerations for patterns for jump insns. 12202 * Looping Patterns:: How to define patterns for special looping insns. 12203 * Insn Canonicalizations::Canonicalization of Instructions 12204 * Expander Definitions::Generating a sequence of several RTL insns 12205 for a standard operation. 12206 * Insn Splitting:: Splitting Instructions into Multiple Instructions. 12207 * Including Patterns:: Including Patterns in Machine Descriptions. 12208 * Peephole Definitions::Defining machine-specific peephole optimizations. 12209 * Insn Attributes:: Specifying the value of attributes for generated insns. 12210 * Conditional Execution::Generating `define_insn' patterns for 12211 predication. 12212 * Constant Definitions::Defining symbolic constants that can be used in the 12213 md file. 12214 * Macros:: Using macros to generate patterns from a template. 12215 12216 12217 File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc 12218 12219 14.1 Overview of How the Machine Description is Used 12220 ==================================================== 12221 12222 There are three main conversions that happen in the compiler: 12223 12224 1. The front end reads the source code and builds a parse tree. 12225 12226 2. The parse tree is used to generate an RTL insn list based on named 12227 instruction patterns. 12228 12229 3. The insn list is matched against the RTL templates to produce 12230 assembler code. 12231 12232 12233 For the generate pass, only the names of the insns matter, from either 12234 a named `define_insn' or a `define_expand'. The compiler will choose 12235 the pattern with the right name and apply the operands according to the 12236 documentation later in this chapter, without regard for the RTL 12237 template or operand constraints. Note that the names the compiler looks 12238 for are hard-coded in the compiler--it will ignore unnamed patterns and 12239 patterns with names it doesn't know about, but if you don't provide a 12240 named pattern it needs, it will abort. 12241 12242 If a `define_insn' is used, the template given is inserted into the 12243 insn list. If a `define_expand' is used, one of three things happens, 12244 based on the condition logic. The condition logic may manually create 12245 new insns for the insn list, say via `emit_insn()', and invoke `DONE'. 12246 For certain named patterns, it may invoke `FAIL' to tell the compiler 12247 to use an alternate way of performing that task. If it invokes neither 12248 `DONE' nor `FAIL', the template given in the pattern is inserted, as if 12249 the `define_expand' were a `define_insn'. 12250 12251 Once the insn list is generated, various optimization passes convert, 12252 replace, and rearrange the insns in the insn list. This is where the 12253 `define_split' and `define_peephole' patterns get used, for example. 12254 12255 Finally, the insn list's RTL is matched up with the RTL templates in 12256 the `define_insn' patterns, and those patterns are used to emit the 12257 final assembly code. For this purpose, each named `define_insn' acts 12258 like it's unnamed, since the names are ignored. 12259 12260 12261 File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc 12262 12263 14.2 Everything about Instruction Patterns 12264 ========================================== 12265 12266 Each instruction pattern contains an incomplete RTL expression, with 12267 pieces to be filled in later, operand constraints that restrict how the 12268 pieces can be filled in, and an output pattern or C code to generate 12269 the assembler output, all wrapped up in a `define_insn' expression. 12270 12271 A `define_insn' is an RTL expression containing four or five operands: 12272 12273 1. An optional name. The presence of a name indicate that this 12274 instruction pattern can perform a certain standard job for the 12275 RTL-generation pass of the compiler. This pass knows certain 12276 names and will use the instruction patterns with those names, if 12277 the names are defined in the machine description. 12278 12279 The absence of a name is indicated by writing an empty string 12280 where the name should go. Nameless instruction patterns are never 12281 used for generating RTL code, but they may permit several simpler 12282 insns to be combined later on. 12283 12284 Names that are not thus known and used in RTL-generation have no 12285 effect; they are equivalent to no name at all. 12286 12287 For the purpose of debugging the compiler, you may also specify a 12288 name beginning with the `*' character. Such a name is used only 12289 for identifying the instruction in RTL dumps; it is entirely 12290 equivalent to having a nameless pattern for all other purposes. 12291 12292 2. The "RTL template" (*note RTL Template::) is a vector of incomplete 12293 RTL expressions which show what the instruction should look like. 12294 It is incomplete because it may contain `match_operand', 12295 `match_operator', and `match_dup' expressions that stand for 12296 operands of the instruction. 12297 12298 If the vector has only one element, that element is the template 12299 for the instruction pattern. If the vector has multiple elements, 12300 then the instruction pattern is a `parallel' expression containing 12301 the elements described. 12302 12303 3. A condition. This is a string which contains a C expression that 12304 is the final test to decide whether an insn body matches this 12305 pattern. 12306 12307 For a named pattern, the condition (if present) may not depend on 12308 the data in the insn being matched, but only the 12309 target-machine-type flags. The compiler needs to test these 12310 conditions during initialization in order to learn exactly which 12311 named instructions are available in a particular run. 12312 12313 For nameless patterns, the condition is applied only when matching 12314 an individual insn, and only after the insn has matched the 12315 pattern's recognition template. The insn's operands may be found 12316 in the vector `operands'. For an insn where the condition has 12317 once matched, it can't be used to control register allocation, for 12318 example by excluding certain hard registers or hard register 12319 combinations. 12320 12321 4. The "output template": a string that says how to output matching 12322 insns as assembler code. `%' in this string specifies where to 12323 substitute the value of an operand. *Note Output Template::. 12324 12325 When simple substitution isn't general enough, you can specify a 12326 piece of C code to compute the output. *Note Output Statement::. 12327 12328 5. Optionally, a vector containing the values of attributes for insns 12329 matching this pattern. *Note Insn Attributes::. 12330 12331 12332 File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 12333 12334 14.3 Example of `define_insn' 12335 ============================= 12336 12337 Here is an actual example of an instruction pattern, for the 12338 68000/68020. 12339 12340 (define_insn "tstsi" 12341 [(set (cc0) 12342 (match_operand:SI 0 "general_operand" "rm"))] 12343 "" 12344 "* 12345 { 12346 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 12347 return \"tstl %0\"; 12348 return \"cmpl #0,%0\"; 12349 }") 12350 12351 This can also be written using braced strings: 12352 12353 (define_insn "tstsi" 12354 [(set (cc0) 12355 (match_operand:SI 0 "general_operand" "rm"))] 12356 "" 12357 { 12358 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 12359 return "tstl %0"; 12360 return "cmpl #0,%0"; 12361 }) 12362 12363 This is an instruction that sets the condition codes based on the 12364 value of a general operand. It has no condition, so any insn whose RTL 12365 description has the form shown may be handled according to this 12366 pattern. The name `tstsi' means "test a `SImode' value" and tells the 12367 RTL generation pass that, when it is necessary to test such a value, an 12368 insn to do so can be constructed using this pattern. 12369 12370 The output control string is a piece of C code which chooses which 12371 output template to return based on the kind of operand and the specific 12372 type of CPU for which code is being generated. 12373 12374 `"rm"' is an operand constraint. Its meaning is explained below. 12375 12376 12377 File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 12378 12379 14.4 RTL Template 12380 ================= 12381 12382 The RTL template is used to define which insns match the particular 12383 pattern and how to find their operands. For named patterns, the RTL 12384 template also says how to construct an insn from specified operands. 12385 12386 Construction involves substituting specified operands into a copy of 12387 the template. Matching involves determining the values that serve as 12388 the operands in the insn being matched. Both of these activities are 12389 controlled by special expression types that direct matching and 12390 substitution of the operands. 12391 12392 `(match_operand:M N PREDICATE CONSTRAINT)' 12393 This expression is a placeholder for operand number N of the insn. 12394 When constructing an insn, operand number N will be substituted 12395 at this point. When matching an insn, whatever appears at this 12396 position in the insn will be taken as operand number N; but it 12397 must satisfy PREDICATE or this instruction pattern will not match 12398 at all. 12399 12400 Operand numbers must be chosen consecutively counting from zero in 12401 each instruction pattern. There may be only one `match_operand' 12402 expression in the pattern for each operand number. Usually 12403 operands are numbered in the order of appearance in `match_operand' 12404 expressions. In the case of a `define_expand', any operand numbers 12405 used only in `match_dup' expressions have higher values than all 12406 other operand numbers. 12407 12408 PREDICATE is a string that is the name of a function that accepts 12409 two arguments, an expression and a machine mode. *Note 12410 Predicates::. During matching, the function will be called with 12411 the putative operand as the expression and M as the mode argument 12412 (if M is not specified, `VOIDmode' will be used, which normally 12413 causes PREDICATE to accept any mode). If it returns zero, this 12414 instruction pattern fails to match. PREDICATE may be an empty 12415 string; then it means no test is to be done on the operand, so 12416 anything which occurs in this position is valid. 12417 12418 Most of the time, PREDICATE will reject modes other than M--but 12419 not always. For example, the predicate `address_operand' uses M 12420 as the mode of memory ref that the address should be valid for. 12421 Many predicates accept `const_int' nodes even though their mode is 12422 `VOIDmode'. 12423 12424 CONSTRAINT controls reloading and the choice of the best register 12425 class to use for a value, as explained later (*note Constraints::). 12426 If the constraint would be an empty string, it can be omitted. 12427 12428 People are often unclear on the difference between the constraint 12429 and the predicate. The predicate helps decide whether a given 12430 insn matches the pattern. The constraint plays no role in this 12431 decision; instead, it controls various decisions in the case of an 12432 insn which does match. 12433 12434 `(match_scratch:M N CONSTRAINT)' 12435 This expression is also a placeholder for operand number N and 12436 indicates that operand must be a `scratch' or `reg' expression. 12437 12438 When matching patterns, this is equivalent to 12439 12440 (match_operand:M N "scratch_operand" PRED) 12441 12442 but, when generating RTL, it produces a (`scratch':M) expression. 12443 12444 If the last few expressions in a `parallel' are `clobber' 12445 expressions whose operands are either a hard register or 12446 `match_scratch', the combiner can add or delete them when 12447 necessary. *Note Side Effects::. 12448 12449 `(match_dup N)' 12450 This expression is also a placeholder for operand number N. It is 12451 used when the operand needs to appear more than once in the insn. 12452 12453 In construction, `match_dup' acts just like `match_operand': the 12454 operand is substituted into the insn being constructed. But in 12455 matching, `match_dup' behaves differently. It assumes that operand 12456 number N has already been determined by a `match_operand' 12457 appearing earlier in the recognition template, and it matches only 12458 an identical-looking expression. 12459 12460 Note that `match_dup' should not be used to tell the compiler that 12461 a particular register is being used for two operands (example: 12462 `add' that adds one register to another; the second register is 12463 both an input operand and the output operand). Use a matching 12464 constraint (*note Simple Constraints::) for those. `match_dup' is 12465 for the cases where one operand is used in two places in the 12466 template, such as an instruction that computes both a quotient and 12467 a remainder, where the opcode takes two input operands but the RTL 12468 template has to refer to each of those twice; once for the 12469 quotient pattern and once for the remainder pattern. 12470 12471 `(match_operator:M N PREDICATE [OPERANDS...])' 12472 This pattern is a kind of placeholder for a variable RTL expression 12473 code. 12474 12475 When constructing an insn, it stands for an RTL expression whose 12476 expression code is taken from that of operand N, and whose 12477 operands are constructed from the patterns OPERANDS. 12478 12479 When matching an expression, it matches an expression if the 12480 function PREDICATE returns nonzero on that expression _and_ the 12481 patterns OPERANDS match the operands of the expression. 12482 12483 Suppose that the function `commutative_operator' is defined as 12484 follows, to match any expression whose operator is one of the 12485 commutative arithmetic operators of RTL and whose mode is MODE: 12486 12487 int 12488 commutative_integer_operator (x, mode) 12489 rtx x; 12490 enum machine_mode mode; 12491 { 12492 enum rtx_code code = GET_CODE (x); 12493 if (GET_MODE (x) != mode) 12494 return 0; 12495 return (GET_RTX_CLASS (code) == RTX_COMM_ARITH 12496 || code == EQ || code == NE); 12497 } 12498 12499 Then the following pattern will match any RTL expression consisting 12500 of a commutative operator applied to two general operands: 12501 12502 (match_operator:SI 3 "commutative_operator" 12503 [(match_operand:SI 1 "general_operand" "g") 12504 (match_operand:SI 2 "general_operand" "g")]) 12505 12506 Here the vector `[OPERANDS...]' contains two patterns because the 12507 expressions to be matched all contain two operands. 12508 12509 When this pattern does match, the two operands of the commutative 12510 operator are recorded as operands 1 and 2 of the insn. (This is 12511 done by the two instances of `match_operand'.) Operand 3 of the 12512 insn will be the entire commutative expression: use `GET_CODE 12513 (operands[3])' to see which commutative operator was used. 12514 12515 The machine mode M of `match_operator' works like that of 12516 `match_operand': it is passed as the second argument to the 12517 predicate function, and that function is solely responsible for 12518 deciding whether the expression to be matched "has" that mode. 12519 12520 When constructing an insn, argument 3 of the gen-function will 12521 specify the operation (i.e. the expression code) for the 12522 expression to be made. It should be an RTL expression, whose 12523 expression code is copied into a new expression whose operands are 12524 arguments 1 and 2 of the gen-function. The subexpressions of 12525 argument 3 are not used; only its expression code matters. 12526 12527 When `match_operator' is used in a pattern for matching an insn, 12528 it usually best if the operand number of the `match_operator' is 12529 higher than that of the actual operands of the insn. This improves 12530 register allocation because the register allocator often looks at 12531 operands 1 and 2 of insns to see if it can do register tying. 12532 12533 There is no way to specify constraints in `match_operator'. The 12534 operand of the insn which corresponds to the `match_operator' 12535 never has any constraints because it is never reloaded as a whole. 12536 However, if parts of its OPERANDS are matched by `match_operand' 12537 patterns, those parts may have constraints of their own. 12538 12539 `(match_op_dup:M N[OPERANDS...])' 12540 Like `match_dup', except that it applies to operators instead of 12541 operands. When constructing an insn, operand number N will be 12542 substituted at this point. But in matching, `match_op_dup' behaves 12543 differently. It assumes that operand number N has already been 12544 determined by a `match_operator' appearing earlier in the 12545 recognition template, and it matches only an identical-looking 12546 expression. 12547 12548 `(match_parallel N PREDICATE [SUBPAT...])' 12549 This pattern is a placeholder for an insn that consists of a 12550 `parallel' expression with a variable number of elements. This 12551 expression should only appear at the top level of an insn pattern. 12552 12553 When constructing an insn, operand number N will be substituted at 12554 this point. When matching an insn, it matches if the body of the 12555 insn is a `parallel' expression with at least as many elements as 12556 the vector of SUBPAT expressions in the `match_parallel', if each 12557 SUBPAT matches the corresponding element of the `parallel', _and_ 12558 the function PREDICATE returns nonzero on the `parallel' that is 12559 the body of the insn. It is the responsibility of the predicate 12560 to validate elements of the `parallel' beyond those listed in the 12561 `match_parallel'. 12562 12563 A typical use of `match_parallel' is to match load and store 12564 multiple expressions, which can contain a variable number of 12565 elements in a `parallel'. For example, 12566 12567 (define_insn "" 12568 [(match_parallel 0 "load_multiple_operation" 12569 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 12570 (match_operand:SI 2 "memory_operand" "m")) 12571 (use (reg:SI 179)) 12572 (clobber (reg:SI 179))])] 12573 "" 12574 "loadm 0,0,%1,%2") 12575 12576 This example comes from `a29k.md'. The function 12577 `load_multiple_operation' is defined in `a29k.c' and checks that 12578 subsequent elements in the `parallel' are the same as the `set' in 12579 the pattern, except that they are referencing subsequent registers 12580 and memory locations. 12581 12582 An insn that matches this pattern might look like: 12583 12584 (parallel 12585 [(set (reg:SI 20) (mem:SI (reg:SI 100))) 12586 (use (reg:SI 179)) 12587 (clobber (reg:SI 179)) 12588 (set (reg:SI 21) 12589 (mem:SI (plus:SI (reg:SI 100) 12590 (const_int 4)))) 12591 (set (reg:SI 22) 12592 (mem:SI (plus:SI (reg:SI 100) 12593 (const_int 8))))]) 12594 12595 `(match_par_dup N [SUBPAT...])' 12596 Like `match_op_dup', but for `match_parallel' instead of 12597 `match_operator'. 12598 12599 12600 12601 File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 12602 12603 14.5 Output Templates and Operand Substitution 12604 ============================================== 12605 12606 The "output template" is a string which specifies how to output the 12607 assembler code for an instruction pattern. Most of the template is a 12608 fixed string which is output literally. The character `%' is used to 12609 specify where to substitute an operand; it can also be used to identify 12610 places where different variants of the assembler require different 12611 syntax. 12612 12613 In the simplest case, a `%' followed by a digit N says to output 12614 operand N at that point in the string. 12615 12616 `%' followed by a letter and a digit says to output an operand in an 12617 alternate fashion. Four letters have standard, built-in meanings 12618 described below. The machine description macro `PRINT_OPERAND' can 12619 define additional letters with nonstandard meanings. 12620 12621 `%cDIGIT' can be used to substitute an operand that is a constant 12622 value without the syntax that normally indicates an immediate operand. 12623 12624 `%nDIGIT' is like `%cDIGIT' except that the value of the constant is 12625 negated before printing. 12626 12627 `%aDIGIT' can be used to substitute an operand as if it were a memory 12628 reference, with the actual operand treated as the address. This may be 12629 useful when outputting a "load address" instruction, because often the 12630 assembler syntax for such an instruction requires you to write the 12631 operand as if it were a memory reference. 12632 12633 `%lDIGIT' is used to substitute a `label_ref' into a jump instruction. 12634 12635 `%=' outputs a number which is unique to each instruction in the 12636 entire compilation. This is useful for making local labels to be 12637 referred to more than once in a single template that generates multiple 12638 assembler instructions. 12639 12640 `%' followed by a punctuation character specifies a substitution that 12641 does not use an operand. Only one case is standard: `%%' outputs a `%' 12642 into the assembler code. Other nonstandard cases can be defined in the 12643 `PRINT_OPERAND' macro. You must also define which punctuation 12644 characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro. 12645 12646 The template may generate multiple assembler instructions. Write the 12647 text for the instructions, with `\;' between them. 12648 12649 When the RTL contains two operands which are required by constraint to 12650 match each other, the output template must refer only to the 12651 lower-numbered operand. Matching operands are not always identical, 12652 and the rest of the compiler arranges to put the proper RTL expression 12653 for printing into the lower-numbered operand. 12654 12655 One use of nonstandard letters or punctuation following `%' is to 12656 distinguish between different assembler languages for the same machine; 12657 for example, Motorola syntax versus MIT syntax for the 68000. Motorola 12658 syntax requires periods in most opcode names, while MIT syntax does 12659 not. For example, the opcode `movel' in MIT syntax is `move.l' in 12660 Motorola syntax. The same file of patterns is used for both kinds of 12661 output syntax, but the character sequence `%.' is used in each place 12662 where Motorola syntax wants a period. The `PRINT_OPERAND' macro for 12663 Motorola syntax defines the sequence to output a period; the macro for 12664 MIT syntax defines it to do nothing. 12665 12666 As a special case, a template consisting of the single character `#' 12667 instructs the compiler to first split the insn, and then output the 12668 resulting instructions separately. This helps eliminate redundancy in 12669 the output templates. If you have a `define_insn' that needs to emit 12670 multiple assembler instructions, and there is an matching `define_split' 12671 already defined, then you can simply use `#' as the output template 12672 instead of writing an output template that emits the multiple assembler 12673 instructions. 12674 12675 If the macro `ASSEMBLER_DIALECT' is defined, you can use construct of 12676 the form `{option0|option1|option2}' in the templates. These describe 12677 multiple variants of assembler language syntax. *Note Instruction 12678 Output::. 12679 12680 12681 File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc 12682 12683 14.6 C Statements for Assembler Output 12684 ====================================== 12685 12686 Often a single fixed template string cannot produce correct and 12687 efficient assembler code for all the cases that are recognized by a 12688 single instruction pattern. For example, the opcodes may depend on the 12689 kinds of operands; or some unfortunate combinations of operands may 12690 require extra machine instructions. 12691 12692 If the output control string starts with a `@', then it is actually a 12693 series of templates, each on a separate line. (Blank lines and leading 12694 spaces and tabs are ignored.) The templates correspond to the 12695 pattern's constraint alternatives (*note Multi-Alternative::). For 12696 example, if a target machine has a two-address add instruction `addr' 12697 to add into a register and another `addm' to add a register to memory, 12698 you might write this pattern: 12699 12700 (define_insn "addsi3" 12701 [(set (match_operand:SI 0 "general_operand" "=r,m") 12702 (plus:SI (match_operand:SI 1 "general_operand" "0,0") 12703 (match_operand:SI 2 "general_operand" "g,r")))] 12704 "" 12705 "@ 12706 addr %2,%0 12707 addm %2,%0") 12708 12709 If the output control string starts with a `*', then it is not an 12710 output template but rather a piece of C program that should compute a 12711 template. It should execute a `return' statement to return the 12712 template-string you want. Most such templates use C string literals, 12713 which require doublequote characters to delimit them. To include these 12714 doublequote characters in the string, prefix each one with `\'. 12715 12716 If the output control string is written as a brace block instead of a 12717 double-quoted string, it is automatically assumed to be C code. In that 12718 case, it is not necessary to put in a leading asterisk, or to escape the 12719 doublequotes surrounding C string literals. 12720 12721 The operands may be found in the array `operands', whose C data type 12722 is `rtx []'. 12723 12724 It is very common to select different ways of generating assembler code 12725 based on whether an immediate operand is within a certain range. Be 12726 careful when doing this, because the result of `INTVAL' is an integer 12727 on the host machine. If the host machine has more bits in an `int' 12728 than the target machine has in the mode in which the constant will be 12729 used, then some of the bits you get from `INTVAL' will be superfluous. 12730 For proper results, you must carefully disregard the values of those 12731 bits. 12732 12733 It is possible to output an assembler instruction and then go on to 12734 output or compute more of them, using the subroutine `output_asm_insn'. 12735 This receives two arguments: a template-string and a vector of 12736 operands. The vector may be `operands', or it may be another array of 12737 `rtx' that you declare locally and initialize yourself. 12738 12739 When an insn pattern has multiple alternatives in its constraints, 12740 often the appearance of the assembler code is determined mostly by 12741 which alternative was matched. When this is so, the C code can test 12742 the variable `which_alternative', which is the ordinal number of the 12743 alternative that was actually satisfied (0 for the first, 1 for the 12744 second alternative, etc.). 12745 12746 For example, suppose there are two opcodes for storing zero, `clrreg' 12747 for registers and `clrmem' for memory locations. Here is how a pattern 12748 could use `which_alternative' to choose between them: 12749 12750 (define_insn "" 12751 [(set (match_operand:SI 0 "general_operand" "=r,m") 12752 (const_int 0))] 12753 "" 12754 { 12755 return (which_alternative == 0 12756 ? "clrreg %0" : "clrmem %0"); 12757 }) 12758 12759 The example above, where the assembler code to generate was _solely_ 12760 determined by the alternative, could also have been specified as 12761 follows, having the output control string start with a `@': 12762 12763 (define_insn "" 12764 [(set (match_operand:SI 0 "general_operand" "=r,m") 12765 (const_int 0))] 12766 "" 12767 "@ 12768 clrreg %0 12769 clrmem %0") 12770 12771 12772 File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc 12773 12774 14.7 Predicates 12775 =============== 12776 12777 A predicate determines whether a `match_operand' or `match_operator' 12778 expression matches, and therefore whether the surrounding instruction 12779 pattern will be used for that combination of operands. GCC has a 12780 number of machine-independent predicates, and you can define 12781 machine-specific predicates as needed. By convention, predicates used 12782 with `match_operand' have names that end in `_operand', and those used 12783 with `match_operator' have names that end in `_operator'. 12784 12785 All predicates are Boolean functions (in the mathematical sense) of 12786 two arguments: the RTL expression that is being considered at that 12787 position in the instruction pattern, and the machine mode that the 12788 `match_operand' or `match_operator' specifies. In this section, the 12789 first argument is called OP and the second argument MODE. Predicates 12790 can be called from C as ordinary two-argument functions; this can be 12791 useful in output templates or other machine-specific code. 12792 12793 Operand predicates can allow operands that are not actually acceptable 12794 to the hardware, as long as the constraints give reload the ability to 12795 fix them up (*note Constraints::). However, GCC will usually generate 12796 better code if the predicates specify the requirements of the machine 12797 instructions as closely as possible. Reload cannot fix up operands 12798 that must be constants ("immediate operands"); you must use a predicate 12799 that allows only constants, or else enforce the requirement in the 12800 extra condition. 12801 12802 Most predicates handle their MODE argument in a uniform manner. If 12803 MODE is `VOIDmode' (unspecified), then OP can have any mode. If MODE 12804 is anything else, then OP must have the same mode, unless OP is a 12805 `CONST_INT' or integer `CONST_DOUBLE'. These RTL expressions always 12806 have `VOIDmode', so it would be counterproductive to check that their 12807 mode matches. Instead, predicates that accept `CONST_INT' and/or 12808 integer `CONST_DOUBLE' check that the value stored in the constant will 12809 fit in the requested mode. 12810 12811 Predicates with this behavior are called "normal". `genrecog' can 12812 optimize the instruction recognizer based on knowledge of how normal 12813 predicates treat modes. It can also diagnose certain kinds of common 12814 errors in the use of normal predicates; for instance, it is almost 12815 always an error to use a normal predicate without specifying a mode. 12816 12817 Predicates that do something different with their MODE argument are 12818 called "special". The generic predicates `address_operand' and 12819 `pmode_register_operand' are special predicates. `genrecog' does not 12820 do any optimizations or diagnosis when special predicates are used. 12821 12822 * Menu: 12823 12824 * Machine-Independent Predicates:: Predicates available to all back ends. 12825 * Defining Predicates:: How to write machine-specific predicate 12826 functions. 12827 12828 12829 File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates 12830 12831 14.7.1 Machine-Independent Predicates 12832 ------------------------------------- 12833 12834 These are the generic predicates available to all back ends. They are 12835 defined in `recog.c'. The first category of predicates allow only 12836 constant, or "immediate", operands. 12837 12838 -- Function: immediate_operand 12839 This predicate allows any sort of constant that fits in MODE. It 12840 is an appropriate choice for instructions that take operands that 12841 must be constant. 12842 12843 -- Function: const_int_operand 12844 This predicate allows any `CONST_INT' expression that fits in 12845 MODE. It is an appropriate choice for an immediate operand that 12846 does not allow a symbol or label. 12847 12848 -- Function: const_double_operand 12849 This predicate accepts any `CONST_DOUBLE' expression that has 12850 exactly MODE. If MODE is `VOIDmode', it will also accept 12851 `CONST_INT'. It is intended for immediate floating point 12852 constants. 12853 12854 The second category of predicates allow only some kind of machine 12855 register. 12856 12857 -- Function: register_operand 12858 This predicate allows any `REG' or `SUBREG' expression that is 12859 valid for MODE. It is often suitable for arithmetic instruction 12860 operands on a RISC machine. 12861 12862 -- Function: pmode_register_operand 12863 This is a slight variant on `register_operand' which works around 12864 a limitation in the machine-description reader. 12865 12866 (match_operand N "pmode_register_operand" CONSTRAINT) 12867 12868 means exactly what 12869 12870 (match_operand:P N "register_operand" CONSTRAINT) 12871 12872 would mean, if the machine-description reader accepted `:P' mode 12873 suffixes. Unfortunately, it cannot, because `Pmode' is an alias 12874 for some other mode, and might vary with machine-specific options. 12875 *Note Misc::. 12876 12877 -- Function: scratch_operand 12878 This predicate allows hard registers and `SCRATCH' expressions, 12879 but not pseudo-registers. It is used internally by 12880 `match_scratch'; it should not be used directly. 12881 12882 The third category of predicates allow only some kind of memory 12883 reference. 12884 12885 -- Function: memory_operand 12886 This predicate allows any valid reference to a quantity of mode 12887 MODE in memory, as determined by the weak form of 12888 `GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::). 12889 12890 -- Function: address_operand 12891 This predicate is a little unusual; it allows any operand that is a 12892 valid expression for the _address_ of a quantity of mode MODE, 12893 again determined by the weak form of `GO_IF_LEGITIMATE_ADDRESS'. 12894 To first order, if `(mem:MODE (EXP))' is acceptable to 12895 `memory_operand', then EXP is acceptable to `address_operand'. 12896 Note that EXP does not necessarily have the mode MODE. 12897 12898 -- Function: indirect_operand 12899 This is a stricter form of `memory_operand' which allows only 12900 memory references with a `general_operand' as the address 12901 expression. New uses of this predicate are discouraged, because 12902 `general_operand' is very permissive, so it's hard to tell what an 12903 `indirect_operand' does or does not allow. If a target has 12904 different requirements for memory operands for different 12905 instructions, it is better to define target-specific predicates 12906 which enforce the hardware's requirements explicitly. 12907 12908 -- Function: push_operand 12909 This predicate allows a memory reference suitable for pushing a 12910 value onto the stack. This will be a `MEM' which refers to 12911 `stack_pointer_rtx', with a side-effect in its address expression 12912 (*note Incdec::); which one is determined by the `STACK_PUSH_CODE' 12913 macro (*note Frame Layout::). 12914 12915 -- Function: pop_operand 12916 This predicate allows a memory reference suitable for popping a 12917 value off the stack. Again, this will be a `MEM' referring to 12918 `stack_pointer_rtx', with a side-effect in its address expression. 12919 However, this time `STACK_POP_CODE' is expected. 12920 12921 The fourth category of predicates allow some combination of the above 12922 operands. 12923 12924 -- Function: nonmemory_operand 12925 This predicate allows any immediate or register operand valid for 12926 MODE. 12927 12928 -- Function: nonimmediate_operand 12929 This predicate allows any register or memory operand valid for 12930 MODE. 12931 12932 -- Function: general_operand 12933 This predicate allows any immediate, register, or memory operand 12934 valid for MODE. 12935 12936 Finally, there is one generic operator predicate. 12937 12938 -- Function: comparison_operator 12939 This predicate matches any expression which performs an arithmetic 12940 comparison in MODE; that is, `COMPARISON_P' is true for the 12941 expression code. 12942 12943 12944 File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates 12945 12946 14.7.2 Defining Machine-Specific Predicates 12947 ------------------------------------------- 12948 12949 Many machines have requirements for their operands that cannot be 12950 expressed precisely using the generic predicates. You can define 12951 additional predicates using `define_predicate' and 12952 `define_special_predicate' expressions. These expressions have three 12953 operands: 12954 12955 * The name of the predicate, as it will be referred to in 12956 `match_operand' or `match_operator' expressions. 12957 12958 * An RTL expression which evaluates to true if the predicate allows 12959 the operand OP, false if it does not. This expression can only use 12960 the following RTL codes: 12961 12962 `MATCH_OPERAND' 12963 When written inside a predicate expression, a `MATCH_OPERAND' 12964 expression evaluates to true if the predicate it names would 12965 allow OP. The operand number and constraint are ignored. 12966 Due to limitations in `genrecog', you can only refer to 12967 generic predicates and predicates that have already been 12968 defined. 12969 12970 `MATCH_CODE' 12971 This expression evaluates to true if OP or a specified 12972 subexpression of OP has one of a given list of RTX codes. 12973 12974 The first operand of this expression is a string constant 12975 containing a comma-separated list of RTX code names (in lower 12976 case). These are the codes for which the `MATCH_CODE' will 12977 be true. 12978 12979 The second operand is a string constant which indicates what 12980 subexpression of OP to examine. If it is absent or the empty 12981 string, OP itself is examined. Otherwise, the string constant 12982 must be a sequence of digits and/or lowercase letters. Each 12983 character indicates a subexpression to extract from the 12984 current expression; for the first character this is OP, for 12985 the second and subsequent characters it is the result of the 12986 previous character. A digit N extracts `XEXP (E, N)'; a 12987 letter L extracts `XVECEXP (E, 0, N)' where N is the 12988 alphabetic ordinal of L (0 for `a', 1 for 'b', and so on). 12989 The `MATCH_CODE' then examines the RTX code of the 12990 subexpression extracted by the complete string. It is not 12991 possible to extract components of an `rtvec' that is not at 12992 position 0 within its RTX object. 12993 12994 `MATCH_TEST' 12995 This expression has one operand, a string constant containing 12996 a C expression. The predicate's arguments, OP and MODE, are 12997 available with those names in the C expression. The 12998 `MATCH_TEST' evaluates to true if the C expression evaluates 12999 to a nonzero value. `MATCH_TEST' expressions must not have 13000 side effects. 13001 13002 `AND' 13003 `IOR' 13004 `NOT' 13005 `IF_THEN_ELSE' 13006 The basic `MATCH_' expressions can be combined using these 13007 logical operators, which have the semantics of the C operators 13008 `&&', `||', `!', and `? :' respectively. As in Common Lisp, 13009 you may give an `AND' or `IOR' expression an arbitrary number 13010 of arguments; this has exactly the same effect as writing a 13011 chain of two-argument `AND' or `IOR' expressions. 13012 13013 * An optional block of C code, which should execute `return true' if 13014 the predicate is found to match and `return false' if it does not. 13015 It must not have any side effects. The predicate arguments, OP 13016 and MODE, are available with those names. 13017 13018 If a code block is present in a predicate definition, then the RTL 13019 expression must evaluate to true _and_ the code block must execute 13020 `return true' for the predicate to allow the operand. The RTL 13021 expression is evaluated first; do not re-check anything in the 13022 code block that was checked in the RTL expression. 13023 13024 The program `genrecog' scans `define_predicate' and 13025 `define_special_predicate' expressions to determine which RTX codes are 13026 possibly allowed. You should always make this explicit in the RTL 13027 predicate expression, using `MATCH_OPERAND' and `MATCH_CODE'. 13028 13029 Here is an example of a simple predicate definition, from the IA64 13030 machine description: 13031 13032 ;; True if OP is a `SYMBOL_REF' which refers to the sdata section. 13033 (define_predicate "small_addr_symbolic_operand" 13034 (and (match_code "symbol_ref") 13035 (match_test "SYMBOL_REF_SMALL_ADDR_P (op)"))) 13036 13037 And here is another, showing the use of the C block. 13038 13039 ;; True if OP is a register operand that is (or could be) a GR reg. 13040 (define_predicate "gr_register_operand" 13041 (match_operand 0 "register_operand") 13042 { 13043 unsigned int regno; 13044 if (GET_CODE (op) == SUBREG) 13045 op = SUBREG_REG (op); 13046 13047 regno = REGNO (op); 13048 return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno)); 13049 }) 13050 13051 Predicates written with `define_predicate' automatically include a 13052 test that MODE is `VOIDmode', or OP has the same mode as MODE, or OP is 13053 a `CONST_INT' or `CONST_DOUBLE'. They do _not_ check specifically for 13054 integer `CONST_DOUBLE', nor do they test that the value of either kind 13055 of constant fits in the requested mode. This is because 13056 target-specific predicates that take constants usually have to do more 13057 stringent value checks anyway. If you need the exact same treatment of 13058 `CONST_INT' or `CONST_DOUBLE' that the generic predicates provide, use 13059 a `MATCH_OPERAND' subexpression to call `const_int_operand', 13060 `const_double_operand', or `immediate_operand'. 13061 13062 Predicates written with `define_special_predicate' do not get any 13063 automatic mode checks, and are treated as having special mode handling 13064 by `genrecog'. 13065 13066 The program `genpreds' is responsible for generating code to test 13067 predicates. It also writes a header file containing function 13068 declarations for all machine-specific predicates. It is not necessary 13069 to declare these predicates in `CPU-protos.h'. 13070 13071 13072 File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc 13073 13074 14.8 Operand Constraints 13075 ======================== 13076 13077 Each `match_operand' in an instruction pattern can specify constraints 13078 for the operands allowed. The constraints allow you to fine-tune 13079 matching within the set of operands allowed by the predicate. 13080 13081 Constraints can say whether an operand may be in a register, and which 13082 kinds of register; whether the operand can be a memory reference, and 13083 which kinds of address; whether the operand may be an immediate 13084 constant, and which possible values it may have. Constraints can also 13085 require two operands to match. 13086 13087 * Menu: 13088 13089 * Simple Constraints:: Basic use of constraints. 13090 * Multi-Alternative:: When an insn has two alternative constraint-patterns. 13091 * Class Preferences:: Constraints guide which hard register to put things in. 13092 * Modifiers:: More precise control over effects of constraints. 13093 * Machine Constraints:: Existing constraints for some particular machines. 13094 * Define Constraints:: How to define machine-specific constraints. 13095 * C Constraint Interface:: How to test constraints from C code. 13096 13097 13098 File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints 13099 13100 14.8.1 Simple Constraints 13101 ------------------------- 13102 13103 The simplest kind of constraint is a string full of letters, each of 13104 which describes one kind of operand that is permitted. Here are the 13105 letters that are allowed: 13106 13107 whitespace 13108 Whitespace characters are ignored and can be inserted at any 13109 position except the first. This enables each alternative for 13110 different operands to be visually aligned in the machine 13111 description even if they have different number of constraints and 13112 modifiers. 13113 13114 `m' 13115 A memory operand is allowed, with any kind of address that the 13116 machine supports in general. 13117 13118 `o' 13119 A memory operand is allowed, but only if the address is 13120 "offsettable". This means that adding a small integer (actually, 13121 the width in bytes of the operand, as determined by its machine 13122 mode) may be added to the address and the result is also a valid 13123 memory address. 13124 13125 For example, an address which is constant is offsettable; so is an 13126 address that is the sum of a register and a constant (as long as a 13127 slightly larger constant is also within the range of 13128 address-offsets supported by the machine); but an autoincrement or 13129 autodecrement address is not offsettable. More complicated 13130 indirect/indexed addresses may or may not be offsettable depending 13131 on the other addressing modes that the machine supports. 13132 13133 Note that in an output operand which can be matched by another 13134 operand, the constraint letter `o' is valid only when accompanied 13135 by both `<' (if the target machine has predecrement addressing) 13136 and `>' (if the target machine has preincrement addressing). 13137 13138 `V' 13139 A memory operand that is not offsettable. In other words, 13140 anything that would fit the `m' constraint but not the `o' 13141 constraint. 13142 13143 `<' 13144 A memory operand with autodecrement addressing (either 13145 predecrement or postdecrement) is allowed. 13146 13147 `>' 13148 A memory operand with autoincrement addressing (either 13149 preincrement or postincrement) is allowed. 13150 13151 `r' 13152 A register operand is allowed provided that it is in a general 13153 register. 13154 13155 `i' 13156 An immediate integer operand (one with constant value) is allowed. 13157 This includes symbolic constants whose values will be known only at 13158 assembly time or later. 13159 13160 `n' 13161 An immediate integer operand with a known numeric value is allowed. 13162 Many systems cannot support assembly-time constants for operands 13163 less than a word wide. Constraints for these operands should use 13164 `n' rather than `i'. 13165 13166 `I', `J', `K', ... `P' 13167 Other letters in the range `I' through `P' may be defined in a 13168 machine-dependent fashion to permit immediate integer operands with 13169 explicit integer values in specified ranges. For example, on the 13170 68000, `I' is defined to stand for the range of values 1 to 8. 13171 This is the range permitted as a shift count in the shift 13172 instructions. 13173 13174 `E' 13175 An immediate floating operand (expression code `const_double') is 13176 allowed, but only if the target floating point format is the same 13177 as that of the host machine (on which the compiler is running). 13178 13179 `F' 13180 An immediate floating operand (expression code `const_double' or 13181 `const_vector') is allowed. 13182 13183 `G', `H' 13184 `G' and `H' may be defined in a machine-dependent fashion to 13185 permit immediate floating operands in particular ranges of values. 13186 13187 `s' 13188 An immediate integer operand whose value is not an explicit 13189 integer is allowed. 13190 13191 This might appear strange; if an insn allows a constant operand 13192 with a value not known at compile time, it certainly must allow 13193 any known value. So why use `s' instead of `i'? Sometimes it 13194 allows better code to be generated. 13195 13196 For example, on the 68000 in a fullword instruction it is possible 13197 to use an immediate operand; but if the immediate value is between 13198 -128 and 127, better code results from loading the value into a 13199 register and using the register. This is because the load into 13200 the register can be done with a `moveq' instruction. We arrange 13201 for this to happen by defining the letter `K' to mean "any integer 13202 outside the range -128 to 127", and then specifying `Ks' in the 13203 operand constraints. 13204 13205 `g' 13206 Any register, memory or immediate integer operand is allowed, 13207 except for registers that are not general registers. 13208 13209 `X' 13210 Any operand whatsoever is allowed, even if it does not satisfy 13211 `general_operand'. This is normally used in the constraint of a 13212 `match_scratch' when certain alternatives will not actually 13213 require a scratch register. 13214 13215 `0', `1', `2', ... `9' 13216 An operand that matches the specified operand number is allowed. 13217 If a digit is used together with letters within the same 13218 alternative, the digit should come last. 13219 13220 This number is allowed to be more than a single digit. If multiple 13221 digits are encountered consecutively, they are interpreted as a 13222 single decimal integer. There is scant chance for ambiguity, 13223 since to-date it has never been desirable that `10' be interpreted 13224 as matching either operand 1 _or_ operand 0. Should this be 13225 desired, one can use multiple alternatives instead. 13226 13227 This is called a "matching constraint" and what it really means is 13228 that the assembler has only a single operand that fills two roles 13229 considered separate in the RTL insn. For example, an add insn has 13230 two input operands and one output operand in the RTL, but on most 13231 CISC machines an add instruction really has only two operands, one 13232 of them an input-output operand: 13233 13234 addl #35,r12 13235 13236 Matching constraints are used in these circumstances. More 13237 precisely, the two operands that match must include one input-only 13238 operand and one output-only operand. Moreover, the digit must be a 13239 smaller number than the number of the operand that uses it in the 13240 constraint. 13241 13242 For operands to match in a particular case usually means that they 13243 are identical-looking RTL expressions. But in a few special cases 13244 specific kinds of dissimilarity are allowed. For example, `*x' as 13245 an input operand will match `*x++' as an output operand. For 13246 proper results in such cases, the output template should always 13247 use the output-operand's number when printing the operand. 13248 13249 `p' 13250 An operand that is a valid memory address is allowed. This is for 13251 "load address" and "push address" instructions. 13252 13253 `p' in the constraint must be accompanied by `address_operand' as 13254 the predicate in the `match_operand'. This predicate interprets 13255 the mode specified in the `match_operand' as the mode of the memory 13256 reference for which the address would be valid. 13257 13258 OTHER-LETTERS 13259 Other letters can be defined in machine-dependent fashion to stand 13260 for particular classes of registers or other arbitrary operand 13261 types. `d', `a' and `f' are defined on the 68000/68020 to stand 13262 for data, address and floating point registers. 13263 13264 In order to have valid assembler code, each operand must satisfy its 13265 constraint. But a failure to do so does not prevent the pattern from 13266 applying to an insn. Instead, it directs the compiler to modify the 13267 code so that the constraint will be satisfied. Usually this is done by 13268 copying an operand into a register. 13269 13270 Contrast, therefore, the two instruction patterns that follow: 13271 13272 (define_insn "" 13273 [(set (match_operand:SI 0 "general_operand" "=r") 13274 (plus:SI (match_dup 0) 13275 (match_operand:SI 1 "general_operand" "r")))] 13276 "" 13277 "...") 13278 13279 which has two operands, one of which must appear in two places, and 13280 13281 (define_insn "" 13282 [(set (match_operand:SI 0 "general_operand" "=r") 13283 (plus:SI (match_operand:SI 1 "general_operand" "0") 13284 (match_operand:SI 2 "general_operand" "r")))] 13285 "" 13286 "...") 13287 13288 which has three operands, two of which are required by a constraint to 13289 be identical. If we are considering an insn of the form 13290 13291 (insn N PREV NEXT 13292 (set (reg:SI 3) 13293 (plus:SI (reg:SI 6) (reg:SI 109))) 13294 ...) 13295 13296 the first pattern would not apply at all, because this insn does not 13297 contain two identical subexpressions in the right place. The pattern 13298 would say, "That does not look like an add instruction; try other 13299 patterns". The second pattern would say, "Yes, that's an add 13300 instruction, but there is something wrong with it". It would direct 13301 the reload pass of the compiler to generate additional insns to make 13302 the constraint true. The results might look like this: 13303 13304 (insn N2 PREV N 13305 (set (reg:SI 3) (reg:SI 6)) 13306 ...) 13307 13308 (insn N N2 NEXT 13309 (set (reg:SI 3) 13310 (plus:SI (reg:SI 3) (reg:SI 109))) 13311 ...) 13312 13313 It is up to you to make sure that each operand, in each pattern, has 13314 constraints that can handle any RTL expression that could be present for 13315 that operand. (When multiple alternatives are in use, each pattern 13316 must, for each possible combination of operand expressions, have at 13317 least one alternative which can handle that combination of operands.) 13318 The constraints don't need to _allow_ any possible operand--when this is 13319 the case, they do not constrain--but they must at least point the way to 13320 reloading any possible operand so that it will fit. 13321 13322 * If the constraint accepts whatever operands the predicate permits, 13323 there is no problem: reloading is never necessary for this operand. 13324 13325 For example, an operand whose constraints permit everything except 13326 registers is safe provided its predicate rejects registers. 13327 13328 An operand whose predicate accepts only constant values is safe 13329 provided its constraints include the letter `i'. If any possible 13330 constant value is accepted, then nothing less than `i' will do; if 13331 the predicate is more selective, then the constraints may also be 13332 more selective. 13333 13334 * Any operand expression can be reloaded by copying it into a 13335 register. So if an operand's constraints allow some kind of 13336 register, it is certain to be safe. It need not permit all 13337 classes of registers; the compiler knows how to copy a register 13338 into another register of the proper class in order to make an 13339 instruction valid. 13340 13341 * A nonoffsettable memory reference can be reloaded by copying the 13342 address into a register. So if the constraint uses the letter 13343 `o', all memory references are taken care of. 13344 13345 * A constant operand can be reloaded by allocating space in memory to 13346 hold it as preinitialized data. Then the memory reference can be 13347 used in place of the constant. So if the constraint uses the 13348 letters `o' or `m', constant operands are not a problem. 13349 13350 * If the constraint permits a constant and a pseudo register used in 13351 an insn was not allocated to a hard register and is equivalent to 13352 a constant, the register will be replaced with the constant. If 13353 the predicate does not permit a constant and the insn is 13354 re-recognized for some reason, the compiler will crash. Thus the 13355 predicate must always recognize any objects allowed by the 13356 constraint. 13357 13358 If the operand's predicate can recognize registers, but the constraint 13359 does not permit them, it can make the compiler crash. When this 13360 operand happens to be a register, the reload pass will be stymied, 13361 because it does not know how to copy a register temporarily into memory. 13362 13363 If the predicate accepts a unary operator, the constraint applies to 13364 the operand. For example, the MIPS processor at ISA level 3 supports an 13365 instruction which adds two registers in `SImode' to produce a `DImode' 13366 result, but only if the registers are correctly sign extended. This 13367 predicate for the input operands accepts a `sign_extend' of an `SImode' 13368 register. Write the constraint to indicate the type of register that 13369 is required for the operand of the `sign_extend'. 13370 13371 13372 File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints 13373 13374 14.8.2 Multiple Alternative Constraints 13375 --------------------------------------- 13376 13377 Sometimes a single instruction has multiple alternative sets of possible 13378 operands. For example, on the 68000, a logical-or instruction can 13379 combine register or an immediate value into memory, or it can combine 13380 any kind of operand into a register; but it cannot combine one memory 13381 location into another. 13382 13383 These constraints are represented as multiple alternatives. An 13384 alternative can be described by a series of letters for each operand. 13385 The overall constraint for an operand is made from the letters for this 13386 operand from the first alternative, a comma, the letters for this 13387 operand from the second alternative, a comma, and so on until the last 13388 alternative. Here is how it is done for fullword logical-or on the 13389 68000: 13390 13391 (define_insn "iorsi3" 13392 [(set (match_operand:SI 0 "general_operand" "=m,d") 13393 (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 13394 (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 13395 ...) 13396 13397 The first alternative has `m' (memory) for operand 0, `0' for operand 13398 1 (meaning it must match operand 0), and `dKs' for operand 2. The 13399 second alternative has `d' (data register) for operand 0, `0' for 13400 operand 1, and `dmKs' for operand 2. The `=' and `%' in the 13401 constraints apply to all the alternatives; their meaning is explained 13402 in the next section (*note Class Preferences::). 13403 13404 If all the operands fit any one alternative, the instruction is valid. 13405 Otherwise, for each alternative, the compiler counts how many 13406 instructions must be added to copy the operands so that that 13407 alternative applies. The alternative requiring the least copying is 13408 chosen. If two alternatives need the same amount of copying, the one 13409 that comes first is chosen. These choices can be altered with the `?' 13410 and `!' characters: 13411 13412 `?' 13413 Disparage slightly the alternative that the `?' appears in, as a 13414 choice when no alternative applies exactly. The compiler regards 13415 this alternative as one unit more costly for each `?' that appears 13416 in it. 13417 13418 `!' 13419 Disparage severely the alternative that the `!' appears in. This 13420 alternative can still be used if it fits without reloading, but if 13421 reloading is needed, some other alternative will be used. 13422 13423 When an insn pattern has multiple alternatives in its constraints, 13424 often the appearance of the assembler code is determined mostly by which 13425 alternative was matched. When this is so, the C code for writing the 13426 assembler code can use the variable `which_alternative', which is the 13427 ordinal number of the alternative that was actually satisfied (0 for 13428 the first, 1 for the second alternative, etc.). *Note Output 13429 Statement::. 13430 13431 13432 File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints 13433 13434 14.8.3 Register Class Preferences 13435 --------------------------------- 13436 13437 The operand constraints have another function: they enable the compiler 13438 to decide which kind of hardware register a pseudo register is best 13439 allocated to. The compiler examines the constraints that apply to the 13440 insns that use the pseudo register, looking for the machine-dependent 13441 letters such as `d' and `a' that specify classes of registers. The 13442 pseudo register is put in whichever class gets the most "votes". The 13443 constraint letters `g' and `r' also vote: they vote in favor of a 13444 general register. The machine description says which registers are 13445 considered general. 13446 13447 Of course, on some machines all registers are equivalent, and no 13448 register classes are defined. Then none of this complexity is relevant. 13449 13450 13451 File: gccint.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints 13452 13453 14.8.4 Constraint Modifier Characters 13454 ------------------------------------- 13455 13456 Here are constraint modifier characters. 13457 13458 `=' 13459 Means that this operand is write-only for this instruction: the 13460 previous value is discarded and replaced by output data. 13461 13462 `+' 13463 Means that this operand is both read and written by the 13464 instruction. 13465 13466 When the compiler fixes up the operands to satisfy the constraints, 13467 it needs to know which operands are inputs to the instruction and 13468 which are outputs from it. `=' identifies an output; `+' 13469 identifies an operand that is both input and output; all other 13470 operands are assumed to be input only. 13471 13472 If you specify `=' or `+' in a constraint, you put it in the first 13473 character of the constraint string. 13474 13475 `&' 13476 Means (in a particular alternative) that this operand is an 13477 "earlyclobber" operand, which is modified before the instruction is 13478 finished using the input operands. Therefore, this operand may 13479 not lie in a register that is used as an input operand or as part 13480 of any memory address. 13481 13482 `&' applies only to the alternative in which it is written. In 13483 constraints with multiple alternatives, sometimes one alternative 13484 requires `&' while others do not. See, for example, the `movdf' 13485 insn of the 68000. 13486 13487 An input operand can be tied to an earlyclobber operand if its only 13488 use as an input occurs before the early result is written. Adding 13489 alternatives of this form often allows GCC to produce better code 13490 when only some of the inputs can be affected by the earlyclobber. 13491 See, for example, the `mulsi3' insn of the ARM. 13492 13493 `&' does not obviate the need to write `='. 13494 13495 `%' 13496 Declares the instruction to be commutative for this operand and the 13497 following operand. This means that the compiler may interchange 13498 the two operands if that is the cheapest way to make all operands 13499 fit the constraints. This is often used in patterns for addition 13500 instructions that really have only two operands: the result must 13501 go in one of the arguments. Here for example, is how the 68000 13502 halfword-add instruction is defined: 13503 13504 (define_insn "addhi3" 13505 [(set (match_operand:HI 0 "general_operand" "=m,r") 13506 (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 13507 (match_operand:HI 2 "general_operand" "di,g")))] 13508 ...) 13509 GCC can only handle one commutative pair in an asm; if you use 13510 more, the compiler may fail. Note that you need not use the 13511 modifier if the two alternatives are strictly identical; this 13512 would only waste time in the reload pass. The modifier is not 13513 operational after register allocation, so the result of 13514 `define_peephole2' and `define_split's performed after reload 13515 cannot rely on `%' to make the intended insn match. 13516 13517 `#' 13518 Says that all following characters, up to the next comma, are to be 13519 ignored as a constraint. They are significant only for choosing 13520 register preferences. 13521 13522 `*' 13523 Says that the following character should be ignored when choosing 13524 register preferences. `*' has no effect on the meaning of the 13525 constraint as a constraint, and no effect on reloading. 13526 13527 Here is an example: the 68000 has an instruction to sign-extend a 13528 halfword in a data register, and can also sign-extend a value by 13529 copying it into an address register. While either kind of 13530 register is acceptable, the constraints on an address-register 13531 destination are less strict, so it is best if register allocation 13532 makes an address register its goal. Therefore, `*' is used so 13533 that the `d' constraint letter (for data register) is ignored when 13534 computing register preferences. 13535 13536 (define_insn "extendhisi2" 13537 [(set (match_operand:SI 0 "general_operand" "=*d,a") 13538 (sign_extend:SI 13539 (match_operand:HI 1 "general_operand" "0,g")))] 13540 ...) 13541 13542 13543 File: gccint.info, Node: Machine Constraints, Next: Define Constraints, Prev: Modifiers, Up: Constraints 13544 13545 14.8.5 Constraints for Particular Machines 13546 ------------------------------------------ 13547 13548 Whenever possible, you should use the general-purpose constraint letters 13549 in `asm' arguments, since they will convey meaning more readily to 13550 people reading your code. Failing that, use the constraint letters 13551 that usually have very similar meanings across architectures. The most 13552 commonly used constraints are `m' and `r' (for memory and 13553 general-purpose registers respectively; *note Simple Constraints::), and 13554 `I', usually the letter indicating the most common immediate-constant 13555 format. 13556 13557 Each architecture defines additional constraints. These constraints 13558 are used by the compiler itself for instruction generation, as well as 13559 for `asm' statements; therefore, some of the constraints are not 13560 particularly useful for `asm'. Here is a summary of some of the 13561 machine-dependent constraints available on some particular machines; it 13562 includes both constraints that are useful for `asm' and constraints 13563 that aren't. The compiler source file mentioned in the table heading 13564 for each architecture is the definitive reference for the meanings of 13565 that architecture's constraints. 13566 13567 _ARM family--`config/arm/arm.h'_ 13568 13569 `f' 13570 Floating-point register 13571 13572 `w' 13573 VFP floating-point register 13574 13575 `F' 13576 One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0, 13577 4.0, 5.0 or 10.0 13578 13579 `G' 13580 Floating-point constant that would satisfy the constraint `F' 13581 if it were negated 13582 13583 `I' 13584 Integer that is valid as an immediate operand in a data 13585 processing instruction. That is, an integer in the range 0 13586 to 255 rotated by a multiple of 2 13587 13588 `J' 13589 Integer in the range -4095 to 4095 13590 13591 `K' 13592 Integer that satisfies constraint `I' when inverted (ones 13593 complement) 13594 13595 `L' 13596 Integer that satisfies constraint `I' when negated (twos 13597 complement) 13598 13599 `M' 13600 Integer in the range 0 to 32 13601 13602 `Q' 13603 A memory reference where the exact address is in a single 13604 register (``m'' is preferable for `asm' statements) 13605 13606 `R' 13607 An item in the constant pool 13608 13609 `S' 13610 A symbol in the text segment of the current file 13611 13612 `Uv' 13613 A memory reference suitable for VFP load/store insns 13614 (reg+constant offset) 13615 13616 `Uy' 13617 A memory reference suitable for iWMMXt load/store 13618 instructions. 13619 13620 `Uq' 13621 A memory reference suitable for the ARMv4 ldrsb instruction. 13622 13623 _AVR family--`config/avr/constraints.md'_ 13624 13625 `l' 13626 Registers from r0 to r15 13627 13628 `a' 13629 Registers from r16 to r23 13630 13631 `d' 13632 Registers from r16 to r31 13633 13634 `w' 13635 Registers from r24 to r31. These registers can be used in 13636 `adiw' command 13637 13638 `e' 13639 Pointer register (r26-r31) 13640 13641 `b' 13642 Base pointer register (r28-r31) 13643 13644 `q' 13645 Stack pointer register (SPH:SPL) 13646 13647 `t' 13648 Temporary register r0 13649 13650 `x' 13651 Register pair X (r27:r26) 13652 13653 `y' 13654 Register pair Y (r29:r28) 13655 13656 `z' 13657 Register pair Z (r31:r30) 13658 13659 `I' 13660 Constant greater than -1, less than 64 13661 13662 `J' 13663 Constant greater than -64, less than 1 13664 13665 `K' 13666 Constant integer 2 13667 13668 `L' 13669 Constant integer 0 13670 13671 `M' 13672 Constant that fits in 8 bits 13673 13674 `N' 13675 Constant integer -1 13676 13677 `O' 13678 Constant integer 8, 16, or 24 13679 13680 `P' 13681 Constant integer 1 13682 13683 `G' 13684 A floating point constant 0.0 13685 13686 _CRX Architecture--`config/crx/crx.h'_ 13687 13688 `b' 13689 Registers from r0 to r14 (registers without stack pointer) 13690 13691 `l' 13692 Register r16 (64-bit accumulator lo register) 13693 13694 `h' 13695 Register r17 (64-bit accumulator hi register) 13696 13697 `k' 13698 Register pair r16-r17. (64-bit accumulator lo-hi pair) 13699 13700 `I' 13701 Constant that fits in 3 bits 13702 13703 `J' 13704 Constant that fits in 4 bits 13705 13706 `K' 13707 Constant that fits in 5 bits 13708 13709 `L' 13710 Constant that is one of -1, 4, -4, 7, 8, 12, 16, 20, 32, 48 13711 13712 `G' 13713 Floating point constant that is legal for store immediate 13714 13715 _PowerPC and IBM RS6000--`config/rs6000/rs6000.h'_ 13716 13717 `b' 13718 Address base register 13719 13720 `f' 13721 Floating point register 13722 13723 `v' 13724 Vector register 13725 13726 `h' 13727 `MQ', `CTR', or `LINK' register 13728 13729 `q' 13730 `MQ' register 13731 13732 `c' 13733 `CTR' register 13734 13735 `l' 13736 `LINK' register 13737 13738 `x' 13739 `CR' register (condition register) number 0 13740 13741 `y' 13742 `CR' register (condition register) 13743 13744 `z' 13745 `FPMEM' stack memory for FPR-GPR transfers 13746 13747 `I' 13748 Signed 16-bit constant 13749 13750 `J' 13751 Unsigned 16-bit constant shifted left 16 bits (use `L' 13752 instead for `SImode' constants) 13753 13754 `K' 13755 Unsigned 16-bit constant 13756 13757 `L' 13758 Signed 16-bit constant shifted left 16 bits 13759 13760 `M' 13761 Constant larger than 31 13762 13763 `N' 13764 Exact power of 2 13765 13766 `O' 13767 Zero 13768 13769 `P' 13770 Constant whose negation is a signed 16-bit constant 13771 13772 `G' 13773 Floating point constant that can be loaded into a register 13774 with one instruction per word 13775 13776 `Q' 13777 Memory operand that is an offset from a register (`m' is 13778 preferable for `asm' statements) 13779 13780 `R' 13781 AIX TOC entry 13782 13783 `S' 13784 Constant suitable as a 64-bit mask operand 13785 13786 `T' 13787 Constant suitable as a 32-bit mask operand 13788 13789 `U' 13790 System V Release 4 small data area reference 13791 13792 _MorphoTech family--`config/mt/mt.h'_ 13793 13794 `I' 13795 Constant for an arithmetic insn (16-bit signed integer). 13796 13797 `J' 13798 The constant 0. 13799 13800 `K' 13801 Constant for a logical insn (16-bit zero-extended integer). 13802 13803 `L' 13804 A constant that can be loaded with `lui' (i.e. the bottom 16 13805 bits are zero). 13806 13807 `M' 13808 A constant that takes two words to load (i.e. not matched by 13809 `I', `K', or `L'). 13810 13811 `N' 13812 Negative 16-bit constants other than -65536. 13813 13814 `O' 13815 A 15-bit signed integer constant. 13816 13817 `P' 13818 A positive 16-bit constant. 13819 13820 _Intel 386--`config/i386/constraints.md'_ 13821 13822 `R' 13823 Legacy register--the eight integer registers available on all 13824 i386 processors (`a', `b', `c', `d', `si', `di', `bp', `sp'). 13825 13826 `q' 13827 Any register accessible as `Rl'. In 32-bit mode, `a', `b', 13828 `c', and `d'; in 64-bit mode, any integer register. 13829 13830 `Q' 13831 Any register accessible as `Rh': `a', `b', `c', and `d'. 13832 13833 `l' 13834 Any register that can be used as the index in a base+index 13835 memory access: that is, any general register except the stack 13836 pointer. 13837 13838 `a' 13839 The `a' register. 13840 13841 `b' 13842 The `b' register. 13843 13844 `c' 13845 The `c' register. 13846 13847 `d' 13848 The `d' register. 13849 13850 `S' 13851 The `si' register. 13852 13853 `D' 13854 The `di' register. 13855 13856 `A' 13857 The `a' and `d' registers, as a pair (for instructions that 13858 return half the result in one and half in the other). 13859 13860 `f' 13861 Any 80387 floating-point (stack) register. 13862 13863 `t' 13864 Top of 80387 floating-point stack (`%st(0)'). 13865 13866 `u' 13867 Second from top of 80387 floating-point stack (`%st(1)'). 13868 13869 `y' 13870 Any MMX register. 13871 13872 `x' 13873 Any SSE register. 13874 13875 `Y' 13876 Any SSE2 register. 13877 13878 `I' 13879 Integer constant in the range 0 ... 31, for 32-bit shifts. 13880 13881 `J' 13882 Integer constant in the range 0 ... 63, for 64-bit shifts. 13883 13884 `K' 13885 Signed 8-bit integer constant. 13886 13887 `L' 13888 `0xFF' or `0xFFFF', for andsi as a zero-extending move. 13889 13890 `M' 13891 0, 1, 2, or 3 (shifts for the `lea' instruction). 13892 13893 `N' 13894 Unsigned 8-bit integer constant (for `in' and `out' 13895 instructions). 13896 13897 `O' 13898 Integer constant in the range 0 ... 127, for 128-bit shifts. 13899 13900 `G' 13901 Standard 80387 floating point constant. 13902 13903 `C' 13904 Standard SSE floating point constant. 13905 13906 `e' 13907 32-bit signed integer constant, or a symbolic reference known 13908 to fit that range (for immediate operands in sign-extending 13909 x86-64 instructions). 13910 13911 `Z' 13912 32-bit unsigned integer constant, or a symbolic reference 13913 known to fit that range (for immediate operands in 13914 zero-extending x86-64 instructions). 13915 13916 13917 _Intel IA-64--`config/ia64/ia64.h'_ 13918 13919 `a' 13920 General register `r0' to `r3' for `addl' instruction 13921 13922 `b' 13923 Branch register 13924 13925 `c' 13926 Predicate register (`c' as in "conditional") 13927 13928 `d' 13929 Application register residing in M-unit 13930 13931 `e' 13932 Application register residing in I-unit 13933 13934 `f' 13935 Floating-point register 13936 13937 `m' 13938 Memory operand. Remember that `m' allows postincrement and 13939 postdecrement which require printing with `%Pn' on IA-64. 13940 Use `S' to disallow postincrement and postdecrement. 13941 13942 `G' 13943 Floating-point constant 0.0 or 1.0 13944 13945 `I' 13946 14-bit signed integer constant 13947 13948 `J' 13949 22-bit signed integer constant 13950 13951 `K' 13952 8-bit signed integer constant for logical instructions 13953 13954 `L' 13955 8-bit adjusted signed integer constant for compare pseudo-ops 13956 13957 `M' 13958 6-bit unsigned integer constant for shift counts 13959 13960 `N' 13961 9-bit signed integer constant for load and store 13962 postincrements 13963 13964 `O' 13965 The constant zero 13966 13967 `P' 13968 0 or -1 for `dep' instruction 13969 13970 `Q' 13971 Non-volatile memory for floating-point loads and stores 13972 13973 `R' 13974 Integer constant in the range 1 to 4 for `shladd' instruction 13975 13976 `S' 13977 Memory operand except postincrement and postdecrement 13978 13979 _FRV--`config/frv/frv.h'_ 13980 13981 `a' 13982 Register in the class `ACC_REGS' (`acc0' to `acc7'). 13983 13984 `b' 13985 Register in the class `EVEN_ACC_REGS' (`acc0' to `acc7'). 13986 13987 `c' 13988 Register in the class `CC_REGS' (`fcc0' to `fcc3' and `icc0' 13989 to `icc3'). 13990 13991 `d' 13992 Register in the class `GPR_REGS' (`gr0' to `gr63'). 13993 13994 `e' 13995 Register in the class `EVEN_REGS' (`gr0' to `gr63'). Odd 13996 registers are excluded not in the class but through the use 13997 of a machine mode larger than 4 bytes. 13998 13999 `f' 14000 Register in the class `FPR_REGS' (`fr0' to `fr63'). 14001 14002 `h' 14003 Register in the class `FEVEN_REGS' (`fr0' to `fr63'). Odd 14004 registers are excluded not in the class but through the use 14005 of a machine mode larger than 4 bytes. 14006 14007 `l' 14008 Register in the class `LR_REG' (the `lr' register). 14009 14010 `q' 14011 Register in the class `QUAD_REGS' (`gr2' to `gr63'). 14012 Register numbers not divisible by 4 are excluded not in the 14013 class but through the use of a machine mode larger than 8 14014 bytes. 14015 14016 `t' 14017 Register in the class `ICC_REGS' (`icc0' to `icc3'). 14018 14019 `u' 14020 Register in the class `FCC_REGS' (`fcc0' to `fcc3'). 14021 14022 `v' 14023 Register in the class `ICR_REGS' (`cc4' to `cc7'). 14024 14025 `w' 14026 Register in the class `FCR_REGS' (`cc0' to `cc3'). 14027 14028 `x' 14029 Register in the class `QUAD_FPR_REGS' (`fr0' to `fr63'). 14030 Register numbers not divisible by 4 are excluded not in the 14031 class but through the use of a machine mode larger than 8 14032 bytes. 14033 14034 `z' 14035 Register in the class `SPR_REGS' (`lcr' and `lr'). 14036 14037 `A' 14038 Register in the class `QUAD_ACC_REGS' (`acc0' to `acc7'). 14039 14040 `B' 14041 Register in the class `ACCG_REGS' (`accg0' to `accg7'). 14042 14043 `C' 14044 Register in the class `CR_REGS' (`cc0' to `cc7'). 14045 14046 `G' 14047 Floating point constant zero 14048 14049 `I' 14050 6-bit signed integer constant 14051 14052 `J' 14053 10-bit signed integer constant 14054 14055 `L' 14056 16-bit signed integer constant 14057 14058 `M' 14059 16-bit unsigned integer constant 14060 14061 `N' 14062 12-bit signed integer constant that is negative--i.e. in the 14063 range of -2048 to -1 14064 14065 `O' 14066 Constant zero 14067 14068 `P' 14069 12-bit signed integer constant that is greater than 14070 zero--i.e. in the range of 1 to 2047. 14071 14072 14073 _Blackfin family--`config/bfin/bfin.h'_ 14074 14075 `a' 14076 P register 14077 14078 `d' 14079 D register 14080 14081 `z' 14082 A call clobbered P register. 14083 14084 `D' 14085 Even-numbered D register 14086 14087 `W' 14088 Odd-numbered D register 14089 14090 `e' 14091 Accumulator register. 14092 14093 `A' 14094 Even-numbered accumulator register. 14095 14096 `B' 14097 Odd-numbered accumulator register. 14098 14099 `b' 14100 I register 14101 14102 `v' 14103 B register 14104 14105 `f' 14106 M register 14107 14108 `c' 14109 Registers used for circular buffering, i.e. I, B, or L 14110 registers. 14111 14112 `C' 14113 The CC register. 14114 14115 `t' 14116 LT0 or LT1. 14117 14118 `k' 14119 LC0 or LC1. 14120 14121 `u' 14122 LB0 or LB1. 14123 14124 `x' 14125 Any D, P, B, M, I or L register. 14126 14127 `y' 14128 Additional registers typically used only in prologues and 14129 epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and 14130 USP. 14131 14132 `w' 14133 Any register except accumulators or CC. 14134 14135 `Ksh' 14136 Signed 16 bit integer (in the range -32768 to 32767) 14137 14138 `Kuh' 14139 Unsigned 16 bit integer (in the range 0 to 65535) 14140 14141 `Ks7' 14142 Signed 7 bit integer (in the range -64 to 63) 14143 14144 `Ku7' 14145 Unsigned 7 bit integer (in the range 0 to 127) 14146 14147 `Ku5' 14148 Unsigned 5 bit integer (in the range 0 to 31) 14149 14150 `Ks4' 14151 Signed 4 bit integer (in the range -8 to 7) 14152 14153 `Ks3' 14154 Signed 3 bit integer (in the range -3 to 4) 14155 14156 `Ku3' 14157 Unsigned 3 bit integer (in the range 0 to 7) 14158 14159 `PN' 14160 Constant N, where N is a single-digit constant in the range 0 14161 to 4. 14162 14163 `M1' 14164 Constant 255. 14165 14166 `M2' 14167 Constant 65535. 14168 14169 `J' 14170 An integer constant with exactly a single bit set. 14171 14172 `L' 14173 An integer constant with all bits set except exactly one. 14174 14175 `H' 14176 14177 `Q' 14178 Any SYMBOL_REF. 14179 14180 _M32C--`config/m32c/m32c.c'_ 14181 14182 `Rsp' 14183 `Rfb' 14184 `Rsb' 14185 `$sp', `$fb', `$sb'. 14186 14187 `Rcr' 14188 Any control register, when they're 16 bits wide (nothing if 14189 control registers are 24 bits wide) 14190 14191 `Rcl' 14192 Any control register, when they're 24 bits wide. 14193 14194 `R0w' 14195 `R1w' 14196 `R2w' 14197 `R3w' 14198 $r0, $r1, $r2, $r3. 14199 14200 `R02' 14201 $r0 or $r2, or $r2r0 for 32 bit values. 14202 14203 `R13' 14204 $r1 or $r3, or $r3r1 for 32 bit values. 14205 14206 `Rdi' 14207 A register that can hold a 64 bit value. 14208 14209 `Rhl' 14210 $r0 or $r1 (registers with addressable high/low bytes) 14211 14212 `R23' 14213 $r2 or $r3 14214 14215 `Raa' 14216 Address registers 14217 14218 `Raw' 14219 Address registers when they're 16 bits wide. 14220 14221 `Ral' 14222 Address registers when they're 24 bits wide. 14223 14224 `Rqi' 14225 Registers that can hold QI values. 14226 14227 `Rad' 14228 Registers that can be used with displacements ($a0, $a1, $sb). 14229 14230 `Rsi' 14231 Registers that can hold 32 bit values. 14232 14233 `Rhi' 14234 Registers that can hold 16 bit values. 14235 14236 `Rhc' 14237 Registers chat can hold 16 bit values, including all control 14238 registers. 14239 14240 `Rra' 14241 $r0 through R1, plus $a0 and $a1. 14242 14243 `Rfl' 14244 The flags register. 14245 14246 `Rmm' 14247 The memory-based pseudo-registers $mem0 through $mem15. 14248 14249 `Rpi' 14250 Registers that can hold pointers (16 bit registers for r8c, 14251 m16c; 24 bit registers for m32cm, m32c). 14252 14253 `Rpa' 14254 Matches multiple registers in a PARALLEL to form a larger 14255 register. Used to match function return values. 14256 14257 `Is3' 14258 -8 ... 7 14259 14260 `IS1' 14261 -128 ... 127 14262 14263 `IS2' 14264 -32768 ... 32767 14265 14266 `IU2' 14267 0 ... 65535 14268 14269 `In4' 14270 -8 ... -1 or 1 ... 8 14271 14272 `In5' 14273 -16 ... -1 or 1 ... 16 14274 14275 `In6' 14276 -32 ... -1 or 1 ... 32 14277 14278 `IM2' 14279 -65536 ... -1 14280 14281 `Ilb' 14282 An 8 bit value with exactly one bit set. 14283 14284 `Ilw' 14285 A 16 bit value with exactly one bit set. 14286 14287 `Sd' 14288 The common src/dest memory addressing modes. 14289 14290 `Sa' 14291 Memory addressed using $a0 or $a1. 14292 14293 `Si' 14294 Memory addressed with immediate addresses. 14295 14296 `Ss' 14297 Memory addressed using the stack pointer ($sp). 14298 14299 `Sf' 14300 Memory addressed using the frame base register ($fb). 14301 14302 `Ss' 14303 Memory addressed using the small base register ($sb). 14304 14305 `S1' 14306 $r1h 14307 14308 _MIPS--`config/mips/constraints.md'_ 14309 14310 `d' 14311 An address register. This is equivalent to `r' unless 14312 generating MIPS16 code. 14313 14314 `f' 14315 A floating-point register (if available). 14316 14317 `h' 14318 The `hi' register. 14319 14320 `l' 14321 The `lo' register. 14322 14323 `x' 14324 The `hi' and `lo' registers. 14325 14326 `c' 14327 A register suitable for use in an indirect jump. This will 14328 always be `$25' for `-mabicalls'. 14329 14330 `y' 14331 Equivalent to `r'; retained for backwards compatibility. 14332 14333 `z' 14334 A floating-point condition code register. 14335 14336 `I' 14337 A signed 16-bit constant (for arithmetic instructions). 14338 14339 `J' 14340 Integer zero. 14341 14342 `K' 14343 An unsigned 16-bit constant (for logic instructions). 14344 14345 `L' 14346 A signed 32-bit constant in which the lower 16 bits are zero. 14347 Such constants can be loaded using `lui'. 14348 14349 `M' 14350 A constant that cannot be loaded using `lui', `addiu' or 14351 `ori'. 14352 14353 `N' 14354 A constant in the range -65535 to -1 (inclusive). 14355 14356 `O' 14357 A signed 15-bit constant. 14358 14359 `P' 14360 A constant in the range 1 to 65535 (inclusive). 14361 14362 `G' 14363 Floating-point zero. 14364 14365 `R' 14366 An address that can be used in a non-macro load or store. 14367 14368 _Motorola 680x0--`config/m68k/m68k.h'_ 14369 14370 `a' 14371 Address register 14372 14373 `d' 14374 Data register 14375 14376 `f' 14377 68881 floating-point register, if available 14378 14379 `I' 14380 Integer in the range 1 to 8 14381 14382 `J' 14383 16-bit signed number 14384 14385 `K' 14386 Signed number whose magnitude is greater than 0x80 14387 14388 `L' 14389 Integer in the range -8 to -1 14390 14391 `M' 14392 Signed number whose magnitude is greater than 0x100 14393 14394 `G' 14395 Floating point constant that is not a 68881 constant 14396 14397 _Motorola 68HC11 & 68HC12 families--`config/m68hc11/m68hc11.h'_ 14398 14399 `a' 14400 Register `a' 14401 14402 `b' 14403 Register `b' 14404 14405 `d' 14406 Register `d' 14407 14408 `q' 14409 An 8-bit register 14410 14411 `t' 14412 Temporary soft register _.tmp 14413 14414 `u' 14415 A soft register _.d1 to _.d31 14416 14417 `w' 14418 Stack pointer register 14419 14420 `x' 14421 Register `x' 14422 14423 `y' 14424 Register `y' 14425 14426 `z' 14427 Pseudo register `z' (replaced by `x' or `y' at the end) 14428 14429 `A' 14430 An address register: x, y or z 14431 14432 `B' 14433 An address register: x or y 14434 14435 `D' 14436 Register pair (x:d) to form a 32-bit value 14437 14438 `L' 14439 Constants in the range -65536 to 65535 14440 14441 `M' 14442 Constants whose 16-bit low part is zero 14443 14444 `N' 14445 Constant integer 1 or -1 14446 14447 `O' 14448 Constant integer 16 14449 14450 `P' 14451 Constants in the range -8 to 2 14452 14453 14454 _SPARC--`config/sparc/sparc.h'_ 14455 14456 `f' 14457 Floating-point register on the SPARC-V8 architecture and 14458 lower floating-point register on the SPARC-V9 architecture. 14459 14460 `e' 14461 Floating-point register. It is equivalent to `f' on the 14462 SPARC-V8 architecture and contains both lower and upper 14463 floating-point registers on the SPARC-V9 architecture. 14464 14465 `c' 14466 Floating-point condition code register. 14467 14468 `d' 14469 Lower floating-point register. It is only valid on the 14470 SPARC-V9 architecture when the Visual Instruction Set is 14471 available. 14472 14473 `b' 14474 Floating-point register. It is only valid on the SPARC-V9 14475 architecture when the Visual Instruction Set is available. 14476 14477 `h' 14478 64-bit global or out register for the SPARC-V8+ architecture. 14479 14480 `I' 14481 Signed 13-bit constant 14482 14483 `J' 14484 Zero 14485 14486 `K' 14487 32-bit constant with the low 12 bits clear (a constant that 14488 can be loaded with the `sethi' instruction) 14489 14490 `L' 14491 A constant in the range supported by `movcc' instructions 14492 14493 `M' 14494 A constant in the range supported by `movrcc' instructions 14495 14496 `N' 14497 Same as `K', except that it verifies that bits that are not 14498 in the lower 32-bit range are all zero. Must be used instead 14499 of `K' for modes wider than `SImode' 14500 14501 `O' 14502 The constant 4096 14503 14504 `G' 14505 Floating-point zero 14506 14507 `H' 14508 Signed 13-bit constant, sign-extended to 32 or 64 bits 14509 14510 `Q' 14511 Floating-point constant whose integral representation can be 14512 moved into an integer register using a single sethi 14513 instruction 14514 14515 `R' 14516 Floating-point constant whose integral representation can be 14517 moved into an integer register using a single mov instruction 14518 14519 `S' 14520 Floating-point constant whose integral representation can be 14521 moved into an integer register using a high/lo_sum 14522 instruction sequence 14523 14524 `T' 14525 Memory address aligned to an 8-byte boundary 14526 14527 `U' 14528 Even register 14529 14530 `W' 14531 Memory address for `e' constraint registers 14532 14533 `Y' 14534 Vector zero 14535 14536 14537 _TMS320C3x/C4x--`config/c4x/c4x.h'_ 14538 14539 `a' 14540 Auxiliary (address) register (ar0-ar7) 14541 14542 `b' 14543 Stack pointer register (sp) 14544 14545 `c' 14546 Standard (32-bit) precision integer register 14547 14548 `f' 14549 Extended (40-bit) precision register (r0-r11) 14550 14551 `k' 14552 Block count register (bk) 14553 14554 `q' 14555 Extended (40-bit) precision low register (r0-r7) 14556 14557 `t' 14558 Extended (40-bit) precision register (r0-r1) 14559 14560 `u' 14561 Extended (40-bit) precision register (r2-r3) 14562 14563 `v' 14564 Repeat count register (rc) 14565 14566 `x' 14567 Index register (ir0-ir1) 14568 14569 `y' 14570 Status (condition code) register (st) 14571 14572 `z' 14573 Data page register (dp) 14574 14575 `G' 14576 Floating-point zero 14577 14578 `H' 14579 Immediate 16-bit floating-point constant 14580 14581 `I' 14582 Signed 16-bit constant 14583 14584 `J' 14585 Signed 8-bit constant 14586 14587 `K' 14588 Signed 5-bit constant 14589 14590 `L' 14591 Unsigned 16-bit constant 14592 14593 `M' 14594 Unsigned 8-bit constant 14595 14596 `N' 14597 Ones complement of unsigned 16-bit constant 14598 14599 `O' 14600 High 16-bit constant (32-bit constant with 16 LSBs zero) 14601 14602 `Q' 14603 Indirect memory reference with signed 8-bit or index register 14604 displacement 14605 14606 `R' 14607 Indirect memory reference with unsigned 5-bit displacement 14608 14609 `S' 14610 Indirect memory reference with 1 bit or index register 14611 displacement 14612 14613 `T' 14614 Direct memory reference 14615 14616 `U' 14617 Symbolic address 14618 14619 14620 _S/390 and zSeries--`config/s390/s390.h'_ 14621 14622 `a' 14623 Address register (general purpose register except r0) 14624 14625 `c' 14626 Condition code register 14627 14628 `d' 14629 Data register (arbitrary general purpose register) 14630 14631 `f' 14632 Floating-point register 14633 14634 `I' 14635 Unsigned 8-bit constant (0-255) 14636 14637 `J' 14638 Unsigned 12-bit constant (0-4095) 14639 14640 `K' 14641 Signed 16-bit constant (-32768-32767) 14642 14643 `L' 14644 Value appropriate as displacement. 14645 `(0..4095)' 14646 for short displacement 14647 14648 `(-524288..524287)' 14649 for long displacement 14650 14651 `M' 14652 Constant integer with a value of 0x7fffffff. 14653 14654 `N' 14655 Multiple letter constraint followed by 4 parameter letters. 14656 `0..9:' 14657 number of the part counting from most to least 14658 significant 14659 14660 `H,Q:' 14661 mode of the part 14662 14663 `D,S,H:' 14664 mode of the containing operand 14665 14666 `0,F:' 14667 value of the other parts (F--all bits set) 14668 The constraint matches if the specified part of a constant 14669 has a value different from it's other parts. 14670 14671 `Q' 14672 Memory reference without index register and with short 14673 displacement. 14674 14675 `R' 14676 Memory reference with index register and short displacement. 14677 14678 `S' 14679 Memory reference without index register but with long 14680 displacement. 14681 14682 `T' 14683 Memory reference with index register and long displacement. 14684 14685 `U' 14686 Pointer with short displacement. 14687 14688 `W' 14689 Pointer with long displacement. 14690 14691 `Y' 14692 Shift count operand. 14693 14694 14695 _Score family--`config/score/score.h'_ 14696 14697 `d' 14698 Registers from r0 to r32. 14699 14700 `e' 14701 Registers from r0 to r16. 14702 14703 `t' 14704 r8--r11 or r22--r27 registers. 14705 14706 `h' 14707 hi register. 14708 14709 `l' 14710 lo register. 14711 14712 `x' 14713 hi + lo register. 14714 14715 `q' 14716 cnt register. 14717 14718 `y' 14719 lcb register. 14720 14721 `z' 14722 scb register. 14723 14724 `a' 14725 cnt + lcb + scb register. 14726 14727 `c' 14728 cr0--cr15 register. 14729 14730 `b' 14731 cp1 registers. 14732 14733 `f' 14734 cp2 registers. 14735 14736 `i' 14737 cp3 registers. 14738 14739 `j' 14740 cp1 + cp2 + cp3 registers. 14741 14742 `I' 14743 High 16-bit constant (32-bit constant with 16 LSBs zero). 14744 14745 `J' 14746 Unsigned 5 bit integer (in the range 0 to 31). 14747 14748 `K' 14749 Unsigned 16 bit integer (in the range 0 to 65535). 14750 14751 `L' 14752 Signed 16 bit integer (in the range -32768 to 32767). 14753 14754 `M' 14755 Unsigned 14 bit integer (in the range 0 to 16383). 14756 14757 `N' 14758 Signed 14 bit integer (in the range -8192 to 8191). 14759 14760 `Z' 14761 Any SYMBOL_REF. 14762 14763 _Xstormy16--`config/stormy16/stormy16.h'_ 14764 14765 `a' 14766 Register r0. 14767 14768 `b' 14769 Register r1. 14770 14771 `c' 14772 Register r2. 14773 14774 `d' 14775 Register r8. 14776 14777 `e' 14778 Registers r0 through r7. 14779 14780 `t' 14781 Registers r0 and r1. 14782 14783 `y' 14784 The carry register. 14785 14786 `z' 14787 Registers r8 and r9. 14788 14789 `I' 14790 A constant between 0 and 3 inclusive. 14791 14792 `J' 14793 A constant that has exactly one bit set. 14794 14795 `K' 14796 A constant that has exactly one bit clear. 14797 14798 `L' 14799 A constant between 0 and 255 inclusive. 14800 14801 `M' 14802 A constant between -255 and 0 inclusive. 14803 14804 `N' 14805 A constant between -3 and 0 inclusive. 14806 14807 `O' 14808 A constant between 1 and 4 inclusive. 14809 14810 `P' 14811 A constant between -4 and -1 inclusive. 14812 14813 `Q' 14814 A memory reference that is a stack push. 14815 14816 `R' 14817 A memory reference that is a stack pop. 14818 14819 `S' 14820 A memory reference that refers to a constant address of known 14821 value. 14822 14823 `T' 14824 The register indicated by Rx (not implemented yet). 14825 14826 `U' 14827 A constant that is not between 2 and 15 inclusive. 14828 14829 `Z' 14830 The constant 0. 14831 14832 14833 _Xtensa--`config/xtensa/xtensa.h'_ 14834 14835 `a' 14836 General-purpose 32-bit register 14837 14838 `b' 14839 One-bit boolean register 14840 14841 `A' 14842 MAC16 40-bit accumulator register 14843 14844 `I' 14845 Signed 12-bit integer constant, for use in MOVI instructions 14846 14847 `J' 14848 Signed 8-bit integer constant, for use in ADDI instructions 14849 14850 `K' 14851 Integer constant valid for BccI instructions 14852 14853 `L' 14854 Unsigned constant valid for BccUI instructions 14855 14856 14857 14858 14859 File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Machine Constraints, Up: Constraints 14860 14861 14.8.6 Defining Machine-Specific Constraints 14862 -------------------------------------------- 14863 14864 Machine-specific constraints fall into two categories: register and 14865 non-register constraints. Within the latter category, constraints 14866 which allow subsets of all possible memory or address operands should 14867 be specially marked, to give `reload' more information. 14868 14869 Machine-specific constraints can be given names of arbitrary length, 14870 but they must be entirely composed of letters, digits, underscores 14871 (`_'), and angle brackets (`< >'). Like C identifiers, they must begin 14872 with a letter or underscore. 14873 14874 In order to avoid ambiguity in operand constraint strings, no 14875 constraint can have a name that begins with any other constraint's 14876 name. For example, if `x' is defined as a constraint name, `xy' may 14877 not be, and vice versa. As a consequence of this rule, no constraint 14878 may begin with one of the generic constraint letters: `E F V X g i m n 14879 o p r s'. 14880 14881 Register constraints correspond directly to register classes. *Note 14882 Register Classes::. There is thus not much flexibility in their 14883 definitions. 14884 14885 -- MD Expression: define_register_constraint name regclass docstring 14886 All three arguments are string constants. NAME is the name of the 14887 constraint, as it will appear in `match_operand' expressions. 14888 REGCLASS can be either the name of the corresponding register 14889 class (*note Register Classes::), or a C expression which 14890 evaluates to the appropriate register class. If it is an 14891 expression, it must have no side effects, and it cannot look at 14892 the operand. The usual use of expressions is to map some register 14893 constraints to `NO_REGS' when the register class is not available 14894 on a given subarchitecture. 14895 14896 DOCSTRING is a sentence documenting the meaning of the constraint. 14897 Docstrings are explained further below. 14898 14899 Non-register constraints are more like predicates: the constraint 14900 definition gives a Boolean expression which indicates whether the 14901 constraint matches. 14902 14903 -- MD Expression: define_constraint name docstring exp 14904 The NAME and DOCSTRING arguments are the same as for 14905 `define_register_constraint', but note that the docstring comes 14906 immediately after the name for these expressions. EXP is an RTL 14907 expression, obeying the same rules as the RTL expressions in 14908 predicate definitions. *Note Defining Predicates::, for details. 14909 If it evaluates true, the constraint matches; if it evaluates 14910 false, it doesn't. Constraint expressions should indicate which 14911 RTL codes they might match, just like predicate expressions. 14912 14913 `match_test' C expressions have access to the following variables: 14914 14915 OP 14916 The RTL object defining the operand. 14917 14918 MODE 14919 The machine mode of OP. 14920 14921 IVAL 14922 `INTVAL (OP)', if OP is a `const_int'. 14923 14924 HVAL 14925 `CONST_DOUBLE_HIGH (OP)', if OP is an integer `const_double'. 14926 14927 LVAL 14928 `CONST_DOUBLE_LOW (OP)', if OP is an integer `const_double'. 14929 14930 RVAL 14931 `CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point 14932 `const_double'. 14933 14934 The *VAL variables should only be used once another piece of the 14935 expression has verified that OP is the appropriate kind of RTL 14936 object. 14937 14938 Most non-register constraints should be defined with 14939 `define_constraint'. The remaining two definition expressions are only 14940 appropriate for constraints that should be handled specially by 14941 `reload' if they fail to match. 14942 14943 -- MD Expression: define_memory_constraint name docstring exp 14944 Use this expression for constraints that match a subset of all 14945 memory operands: that is, `reload' can make them match by 14946 converting the operand to the form `(mem (reg X))', where X is a 14947 base register (from the register class specified by 14948 `BASE_REG_CLASS', *note Register Classes::). 14949 14950 For example, on the S/390, some instructions do not accept 14951 arbitrary memory references, but only those that do not make use 14952 of an index register. The constraint letter `Q' is defined to 14953 represent a memory address of this type. If `Q' is defined with 14954 `define_memory_constraint', a `Q' constraint can handle any memory 14955 operand, because `reload' knows it can simply copy the memory 14956 address into a base register if required. This is analogous to 14957 the way a `o' constraint can handle any memory operand. 14958 14959 The syntax and semantics are otherwise identical to 14960 `define_constraint'. 14961 14962 -- MD Expression: define_address_constraint name docstring exp 14963 Use this expression for constraints that match a subset of all 14964 address operands: that is, `reload' can make the constraint match 14965 by converting the operand to the form `(reg X)', again with X a 14966 base register. 14967 14968 Constraints defined with `define_address_constraint' can only be 14969 used with the `address_operand' predicate, or machine-specific 14970 predicates that work the same way. They are treated analogously to 14971 the generic `p' constraint. 14972 14973 The syntax and semantics are otherwise identical to 14974 `define_constraint'. 14975 14976 For historical reasons, names beginning with the letters `G H' are 14977 reserved for constraints that match only `const_double's, and names 14978 beginning with the letters `I J K L M N O P' are reserved for 14979 constraints that match only `const_int's. This may change in the 14980 future. For the time being, constraints with these names must be 14981 written in a stylized form, so that `genpreds' can tell you did it 14982 correctly: 14983 14984 (define_constraint "[GHIJKLMNOP]..." 14985 "DOC..." 14986 (and (match_code "const_int") ; `const_double' for G/H 14987 CONDITION...)) ; usually a `match_test' 14988 14989 It is fine to use names beginning with other letters for constraints 14990 that match `const_double's or `const_int's. 14991 14992 Each docstring in a constraint definition should be one or more 14993 complete sentences, marked up in Texinfo format. _They are currently 14994 unused._ In the future they will be copied into the GCC manual, in 14995 *Note Machine Constraints::, replacing the hand-maintained tables 14996 currently found in that section. Also, in the future the compiler may 14997 use this to give more helpful diagnostics when poor choice of `asm' 14998 constraints causes a reload failure. 14999 15000 If you put the pseudo-Texinfo directive `@internal' at the beginning 15001 of a docstring, then (in the future) it will appear only in the 15002 internals manual's version of the machine-specific constraint tables. 15003 Use this for constraints that should not appear in `asm' statements. 15004 15005 15006 File: gccint.info, Node: C Constraint Interface, Prev: Define Constraints, Up: Constraints 15007 15008 14.8.7 Testing constraints from C 15009 --------------------------------- 15010 15011 It is occasionally useful to test a constraint from C code rather than 15012 implicitly via the constraint string in a `match_operand'. The 15013 generated file `tm_p.h' declares a few interfaces for working with 15014 machine-specific constraints. None of these interfaces work with the 15015 generic constraints described in *Note Simple Constraints::. This may 15016 change in the future. 15017 15018 *Warning:* `tm_p.h' may declare other functions that operate on 15019 constraints, besides the ones documented here. Do not use those 15020 functions from machine-dependent code. They exist to implement the old 15021 constraint interface that machine-independent components of the 15022 compiler still expect. They will change or disappear in the future. 15023 15024 Some valid constraint names are not valid C identifiers, so there is a 15025 mangling scheme for referring to them from C. Constraint names that do 15026 not contain angle brackets or underscores are left unchanged. 15027 Underscores are doubled, each `<' is replaced with `_l', and each `>' 15028 with `_g'. Here are some examples: 15029 15030 *Original* *Mangled* 15031 `x' `x' 15032 `P42x' `P42x' 15033 `P4_x' `P4__x' 15034 `P4>x' `P4_gx' 15035 `P4>>' `P4_g_g' 15036 `P4_g>' `P4__g_g' 15037 15038 Throughout this section, the variable C is either a constraint in the 15039 abstract sense, or a constant from `enum constraint_num'; the variable 15040 M is a mangled constraint name (usually as part of a larger identifier). 15041 15042 -- Enum: constraint_num 15043 For each machine-specific constraint, there is a corresponding 15044 enumeration constant: `CONSTRAINT_' plus the mangled name of the 15045 constraint. Functions that take an `enum constraint_num' as an 15046 argument expect one of these constants. 15047 15048 Machine-independent constraints do not have associated constants. 15049 This may change in the future. 15050 15051 -- Function: inline bool satisfies_constraint_M (rtx EXP) 15052 For each machine-specific, non-register constraint M, there is one 15053 of these functions; it returns `true' if EXP satisfies the 15054 constraint. These functions are only visible if `rtl.h' was 15055 included before `tm_p.h'. 15056 15057 -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num 15058 C) 15059 Like the `satisfies_constraint_M' functions, but the constraint to 15060 test is given as an argument, C. If C specifies a register 15061 constraint, this function will always return `false'. 15062 15063 -- Function: enum reg_class regclass_for_constraint (enum 15064 constraint_num C) 15065 Returns the register class associated with C. If C is not a 15066 register constraint, or those registers are not available for the 15067 currently selected subtarget, returns `NO_REGS'. 15068 15069 Here is an example use of `satisfies_constraint_M'. In peephole 15070 optimizations (*note Peephole Definitions::), operand constraint 15071 strings are ignored, so if there are relevant constraints, they must be 15072 tested in the C condition. In the example, the optimization is applied 15073 if operand 2 does _not_ satisfy the `K' constraint. (This is a 15074 simplified version of a peephole definition from the i386 machine 15075 description.) 15076 15077 (define_peephole2 15078 [(match_scratch:SI 3 "r") 15079 (set (match_operand:SI 0 "register_operand" "") 15080 (mult:SI (match_operand:SI 1 "memory_operand" "") 15081 (match_operand:SI 2 "immediate_operand" "")))] 15082 15083 "!satisfies_constraint_K (operands[2])" 15084 15085 [(set (match_dup 3) (match_dup 1)) 15086 (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))] 15087 15088 "") 15089 15090 15091 File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc 15092 15093 14.9 Standard Pattern Names For Generation 15094 ========================================== 15095 15096 Here is a table of the instruction names that are meaningful in the RTL 15097 generation pass of the compiler. Giving one of these names to an 15098 instruction pattern tells the RTL generation pass that it can use the 15099 pattern to accomplish a certain task. 15100 15101 `movM' 15102 Here M stands for a two-letter machine mode name, in lowercase. 15103 This instruction pattern moves data with that machine mode from 15104 operand 1 to operand 0. For example, `movsi' moves full-word data. 15105 15106 If operand 0 is a `subreg' with mode M of a register whose own 15107 mode is wider than M, the effect of this instruction is to store 15108 the specified value in the part of the register that corresponds 15109 to mode M. Bits outside of M, but which are within the same 15110 target word as the `subreg' are undefined. Bits which are outside 15111 the target word are left unchanged. 15112 15113 This class of patterns is special in several ways. First of all, 15114 each of these names up to and including full word size _must_ be 15115 defined, because there is no other way to copy a datum from one 15116 place to another. If there are patterns accepting operands in 15117 larger modes, `movM' must be defined for integer modes of those 15118 sizes. 15119 15120 Second, these patterns are not used solely in the RTL generation 15121 pass. Even the reload pass can generate move insns to copy values 15122 from stack slots into temporary registers. When it does so, one 15123 of the operands is a hard register and the other is an operand 15124 that can need to be reloaded into a register. 15125 15126 Therefore, when given such a pair of operands, the pattern must 15127 generate RTL which needs no reloading and needs no temporary 15128 registers--no registers other than the operands. For example, if 15129 you support the pattern with a `define_expand', then in such a 15130 case the `define_expand' mustn't call `force_reg' or any other such 15131 function which might generate new pseudo registers. 15132 15133 This requirement exists even for subword modes on a RISC machine 15134 where fetching those modes from memory normally requires several 15135 insns and some temporary registers. 15136 15137 During reload a memory reference with an invalid address may be 15138 passed as an operand. Such an address will be replaced with a 15139 valid address later in the reload pass. In this case, nothing may 15140 be done with the address except to use it as it stands. If it is 15141 copied, it will not be replaced with a valid address. No attempt 15142 should be made to make such an address into a valid address and no 15143 routine (such as `change_address') that will do so may be called. 15144 Note that `general_operand' will fail when applied to such an 15145 address. 15146 15147 The global variable `reload_in_progress' (which must be explicitly 15148 declared if required) can be used to determine whether such special 15149 handling is required. 15150 15151 The variety of operands that have reloads depends on the rest of 15152 the machine description, but typically on a RISC machine these can 15153 only be pseudo registers that did not get hard registers, while on 15154 other machines explicit memory references will get optional 15155 reloads. 15156 15157 If a scratch register is required to move an object to or from 15158 memory, it can be allocated using `gen_reg_rtx' prior to life 15159 analysis. 15160 15161 If there are cases which need scratch registers during or after 15162 reload, you must provide an appropriate secondary_reload target 15163 hook. 15164 15165 The global variable `no_new_pseudos' can be used to determine if it 15166 is unsafe to create new pseudo registers. If this variable is 15167 nonzero, then it is unsafe to call `gen_reg_rtx' to allocate a new 15168 pseudo. 15169 15170 The constraints on a `movM' must permit moving any hard register 15171 to any other hard register provided that `HARD_REGNO_MODE_OK' 15172 permits mode M in both registers and `REGISTER_MOVE_COST' applied 15173 to their classes returns a value of 2. 15174 15175 It is obligatory to support floating point `movM' instructions 15176 into and out of any registers that can hold fixed point values, 15177 because unions and structures (which have modes `SImode' or 15178 `DImode') can be in those registers and they may have floating 15179 point members. 15180 15181 There may also be a need to support fixed point `movM' 15182 instructions in and out of floating point registers. 15183 Unfortunately, I have forgotten why this was so, and I don't know 15184 whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed 15185 point values in floating point registers, then the constraints of 15186 the fixed point `movM' instructions must be designed to avoid ever 15187 trying to reload into a floating point register. 15188 15189 `reload_inM' 15190 `reload_outM' 15191 These named patterns have been obsoleted by the target hook 15192 `secondary_reload'. 15193 15194 Like `movM', but used when a scratch register is required to move 15195 between operand 0 and operand 1. Operand 2 describes the scratch 15196 register. See the discussion of the `SECONDARY_RELOAD_CLASS' 15197 macro in *note Register Classes::. 15198 15199 There are special restrictions on the form of the `match_operand's 15200 used in these patterns. First, only the predicate for the reload 15201 operand is examined, i.e., `reload_in' examines operand 1, but not 15202 the predicates for operand 0 or 2. Second, there may be only one 15203 alternative in the constraints. Third, only a single register 15204 class letter may be used for the constraint; subsequent constraint 15205 letters are ignored. As a special exception, an empty constraint 15206 string matches the `ALL_REGS' register class. This may relieve 15207 ports of the burden of defining an `ALL_REGS' constraint letter 15208 just for these patterns. 15209 15210 `movstrictM' 15211 Like `movM' except that if operand 0 is a `subreg' with mode M of 15212 a register whose natural mode is wider, the `movstrictM' 15213 instruction is guaranteed not to alter any of the register except 15214 the part which belongs to mode M. 15215 15216 `movmisalignM' 15217 This variant of a move pattern is designed to load or store a value 15218 from a memory address that is not naturally aligned for its mode. 15219 For a store, the memory will be in operand 0; for a load, the 15220 memory will be in operand 1. The other operand is guaranteed not 15221 to be a memory, so that it's easy to tell whether this is a load 15222 or store. 15223 15224 This pattern is used by the autovectorizer, and when expanding a 15225 `MISALIGNED_INDIRECT_REF' expression. 15226 15227 `load_multiple' 15228 Load several consecutive memory locations into consecutive 15229 registers. Operand 0 is the first of the consecutive registers, 15230 operand 1 is the first memory location, and operand 2 is a 15231 constant: the number of consecutive registers. 15232 15233 Define this only if the target machine really has such an 15234 instruction; do not define this if the most efficient way of 15235 loading consecutive registers from memory is to do them one at a 15236 time. 15237 15238 On some machines, there are restrictions as to which consecutive 15239 registers can be stored into memory, such as particular starting or 15240 ending register numbers or only a range of valid counts. For those 15241 machines, use a `define_expand' (*note Expander Definitions::) and 15242 make the pattern fail if the restrictions are not met. 15243 15244 Write the generated insn as a `parallel' with elements being a 15245 `set' of one register from the appropriate memory location (you may 15246 also need `use' or `clobber' elements). Use a `match_parallel' 15247 (*note RTL Template::) to recognize the insn. See `rs6000.md' for 15248 examples of the use of this insn pattern. 15249 15250 `store_multiple' 15251 Similar to `load_multiple', but store several consecutive registers 15252 into consecutive memory locations. Operand 0 is the first of the 15253 consecutive memory locations, operand 1 is the first register, and 15254 operand 2 is a constant: the number of consecutive registers. 15255 15256 `vec_setM' 15257 Set given field in the vector value. Operand 0 is the vector to 15258 modify, operand 1 is new value of field and operand 2 specify the 15259 field index. 15260 15261 `vec_extractM' 15262 Extract given field from the vector value. Operand 1 is the 15263 vector, operand 2 specify field index and operand 0 place to store 15264 value into. 15265 15266 `vec_initM' 15267 Initialize the vector to given values. Operand 0 is the vector to 15268 initialize and operand 1 is parallel containing values for 15269 individual fields. 15270 15271 `pushM1' 15272 Output a push instruction. Operand 0 is value to push. Used only 15273 when `PUSH_ROUNDING' is defined. For historical reason, this 15274 pattern may be missing and in such case an `mov' expander is used 15275 instead, with a `MEM' expression forming the push operation. The 15276 `mov' expander method is deprecated. 15277 15278 `addM3' 15279 Add operand 2 and operand 1, storing the result in operand 0. All 15280 operands must have mode M. This can be used even on two-address 15281 machines, by means of constraints requiring operands 1 and 0 to be 15282 the same location. 15283 15284 `subM3', `mulM3' 15285 `divM3', `udivM3' 15286 `modM3', `umodM3' 15287 `uminM3', `umaxM3' 15288 `andM3', `iorM3', `xorM3' 15289 Similar, for other arithmetic operations. 15290 15291 `sminM3', `smaxM3' 15292 Signed minimum and maximum operations. When used with floating 15293 point, if both operands are zeros, or if either operand is `NaN', 15294 then it is unspecified which of the two operands is returned as 15295 the result. 15296 15297 `reduc_smin_M', `reduc_smax_M' 15298 Find the signed minimum/maximum of the elements of a vector. The 15299 vector is operand 1, and the scalar result is stored in the least 15300 significant bits of operand 0 (also a vector). The output and 15301 input vector should have the same modes. 15302 15303 `reduc_umin_M', `reduc_umax_M' 15304 Find the unsigned minimum/maximum of the elements of a vector. The 15305 vector is operand 1, and the scalar result is stored in the least 15306 significant bits of operand 0 (also a vector). The output and 15307 input vector should have the same modes. 15308 15309 `reduc_splus_M' 15310 Compute the sum of the signed elements of a vector. The vector is 15311 operand 1, and the scalar result is stored in the least 15312 significant bits of operand 0 (also a vector). The output and 15313 input vector should have the same modes. 15314 15315 `reduc_uplus_M' 15316 Compute the sum of the unsigned elements of a vector. The vector 15317 is operand 1, and the scalar result is stored in the least 15318 significant bits of operand 0 (also a vector). The output and 15319 input vector should have the same modes. 15320 15321 `sdot_prodM' 15322 15323 `udot_prodM' 15324 Compute the sum of the products of two signed/unsigned elements. 15325 Operand 1 and operand 2 are of the same mode. Their product, which 15326 is of a wider mode, is computed and added to operand 3. Operand 3 15327 is of a mode equal or wider than the mode of the product. The 15328 result is placed in operand 0, which is of the same mode as 15329 operand 3. 15330 15331 `ssum_widenM3' 15332 15333 `usum_widenM3' 15334 Operands 0 and 2 are of the same mode, which is wider than the 15335 mode of operand 1. Add operand 1 to operand 2 and place the 15336 widened result in operand 0. (This is used express accumulation of 15337 elements into an accumulator of a wider mode.) 15338 15339 `vec_shl_M', `vec_shr_M' 15340 Whole vector left/right shift in bits. Operand 1 is a vector to 15341 be shifted. Operand 2 is an integer shift amount in bits. 15342 Operand 0 is where the resulting shifted vector is stored. The 15343 output and input vectors should have the same modes. 15344 15345 `mulhisi3' 15346 Multiply operands 1 and 2, which have mode `HImode', and store a 15347 `SImode' product in operand 0. 15348 15349 `mulqihi3', `mulsidi3' 15350 Similar widening-multiplication instructions of other widths. 15351 15352 `umulqihi3', `umulhisi3', `umulsidi3' 15353 Similar widening-multiplication instructions that do unsigned 15354 multiplication. 15355 15356 `usmulqihi3', `usmulhisi3', `usmulsidi3' 15357 Similar widening-multiplication instructions that interpret the 15358 first operand as unsigned and the second operand as signed, then 15359 do a signed multiplication. 15360 15361 `smulM3_highpart' 15362 Perform a signed multiplication of operands 1 and 2, which have 15363 mode M, and store the most significant half of the product in 15364 operand 0. The least significant half of the product is discarded. 15365 15366 `umulM3_highpart' 15367 Similar, but the multiplication is unsigned. 15368 15369 `divmodM4' 15370 Signed division that produces both a quotient and a remainder. 15371 Operand 1 is divided by operand 2 to produce a quotient stored in 15372 operand 0 and a remainder stored in operand 3. 15373 15374 For machines with an instruction that produces both a quotient and 15375 a remainder, provide a pattern for `divmodM4' but do not provide 15376 patterns for `divM3' and `modM3'. This allows optimization in the 15377 relatively common case when both the quotient and remainder are 15378 computed. 15379 15380 If an instruction that just produces a quotient or just a remainder 15381 exists and is more efficient than the instruction that produces 15382 both, write the output routine of `divmodM4' to call 15383 `find_reg_note' and look for a `REG_UNUSED' note on the quotient 15384 or remainder and generate the appropriate instruction. 15385 15386 `udivmodM4' 15387 Similar, but does unsigned division. 15388 15389 `ashlM3' 15390 Arithmetic-shift operand 1 left by a number of bits specified by 15391 operand 2, and store the result in operand 0. Here M is the mode 15392 of operand 0 and operand 1; operand 2's mode is specified by the 15393 instruction pattern, and the compiler will convert the operand to 15394 that mode before generating the instruction. The meaning of 15395 out-of-range shift counts can optionally be specified by 15396 `TARGET_SHIFT_TRUNCATION_MASK'. *Note 15397 TARGET_SHIFT_TRUNCATION_MASK::. 15398 15399 `ashrM3', `lshrM3', `rotlM3', `rotrM3' 15400 Other shift and rotate instructions, analogous to the `ashlM3' 15401 instructions. 15402 15403 `negM2' 15404 Negate operand 1 and store the result in operand 0. 15405 15406 `absM2' 15407 Store the absolute value of operand 1 into operand 0. 15408 15409 `sqrtM2' 15410 Store the square root of operand 1 into operand 0. 15411 15412 The `sqrt' built-in function of C always uses the mode which 15413 corresponds to the C data type `double' and the `sqrtf' built-in 15414 function uses the mode which corresponds to the C data type 15415 `float'. 15416 15417 `cosM2' 15418 Store the cosine of operand 1 into operand 0. 15419 15420 The `cos' built-in function of C always uses the mode which 15421 corresponds to the C data type `double' and the `cosf' built-in 15422 function uses the mode which corresponds to the C data type 15423 `float'. 15424 15425 `sinM2' 15426 Store the sine of operand 1 into operand 0. 15427 15428 The `sin' built-in function of C always uses the mode which 15429 corresponds to the C data type `double' and the `sinf' built-in 15430 function uses the mode which corresponds to the C data type 15431 `float'. 15432 15433 `expM2' 15434 Store the exponential of operand 1 into operand 0. 15435 15436 The `exp' built-in function of C always uses the mode which 15437 corresponds to the C data type `double' and the `expf' built-in 15438 function uses the mode which corresponds to the C data type 15439 `float'. 15440 15441 `logM2' 15442 Store the natural logarithm of operand 1 into operand 0. 15443 15444 The `log' built-in function of C always uses the mode which 15445 corresponds to the C data type `double' and the `logf' built-in 15446 function uses the mode which corresponds to the C data type 15447 `float'. 15448 15449 `powM3' 15450 Store the value of operand 1 raised to the exponent operand 2 into 15451 operand 0. 15452 15453 The `pow' built-in function of C always uses the mode which 15454 corresponds to the C data type `double' and the `powf' built-in 15455 function uses the mode which corresponds to the C data type 15456 `float'. 15457 15458 `atan2M3' 15459 Store the arc tangent (inverse tangent) of operand 1 divided by 15460 operand 2 into operand 0, using the signs of both arguments to 15461 determine the quadrant of the result. 15462 15463 The `atan2' built-in function of C always uses the mode which 15464 corresponds to the C data type `double' and the `atan2f' built-in 15465 function uses the mode which corresponds to the C data type 15466 `float'. 15467 15468 `floorM2' 15469 Store the largest integral value not greater than argument. 15470 15471 The `floor' built-in function of C always uses the mode which 15472 corresponds to the C data type `double' and the `floorf' built-in 15473 function uses the mode which corresponds to the C data type 15474 `float'. 15475 15476 `btruncM2' 15477 Store the argument rounded to integer towards zero. 15478 15479 The `trunc' built-in function of C always uses the mode which 15480 corresponds to the C data type `double' and the `truncf' built-in 15481 function uses the mode which corresponds to the C data type 15482 `float'. 15483 15484 `roundM2' 15485 Store the argument rounded to integer away from zero. 15486 15487 The `round' built-in function of C always uses the mode which 15488 corresponds to the C data type `double' and the `roundf' built-in 15489 function uses the mode which corresponds to the C data type 15490 `float'. 15491 15492 `ceilM2' 15493 Store the argument rounded to integer away from zero. 15494 15495 The `ceil' built-in function of C always uses the mode which 15496 corresponds to the C data type `double' and the `ceilf' built-in 15497 function uses the mode which corresponds to the C data type 15498 `float'. 15499 15500 `nearbyintM2' 15501 Store the argument rounded according to the default rounding mode 15502 15503 The `nearbyint' built-in function of C always uses the mode which 15504 corresponds to the C data type `double' and the `nearbyintf' 15505 built-in function uses the mode which corresponds to the C data 15506 type `float'. 15507 15508 `rintM2' 15509 Store the argument rounded according to the default rounding mode 15510 and raise the inexact exception when the result differs in value 15511 from the argument 15512 15513 The `rint' built-in function of C always uses the mode which 15514 corresponds to the C data type `double' and the `rintf' built-in 15515 function uses the mode which corresponds to the C data type 15516 `float'. 15517 15518 `copysignM3' 15519 Store a value with the magnitude of operand 1 and the sign of 15520 operand 2 into operand 0. 15521 15522 The `copysign' built-in function of C always uses the mode which 15523 corresponds to the C data type `double' and the `copysignf' 15524 built-in function uses the mode which corresponds to the C data 15525 type `float'. 15526 15527 `ffsM2' 15528 Store into operand 0 one plus the index of the least significant 15529 1-bit of operand 1. If operand 1 is zero, store zero. M is the 15530 mode of operand 0; operand 1's mode is specified by the instruction 15531 pattern, and the compiler will convert the operand to that mode 15532 before generating the instruction. 15533 15534 The `ffs' built-in function of C always uses the mode which 15535 corresponds to the C data type `int'. 15536 15537 `clzM2' 15538 Store into operand 0 the number of leading 0-bits in X, starting 15539 at the most significant bit position. If X is 0, the result is 15540 undefined. M is the mode of operand 0; operand 1's mode is 15541 specified by the instruction pattern, and the compiler will 15542 convert the operand to that mode before generating the instruction. 15543 15544 `ctzM2' 15545 Store into operand 0 the number of trailing 0-bits in X, starting 15546 at the least significant bit position. If X is 0, the result is 15547 undefined. M is the mode of operand 0; operand 1's mode is 15548 specified by the instruction pattern, and the compiler will 15549 convert the operand to that mode before generating the instruction. 15550 15551 `popcountM2' 15552 Store into operand 0 the number of 1-bits in X. M is the mode of 15553 operand 0; operand 1's mode is specified by the instruction 15554 pattern, and the compiler will convert the operand to that mode 15555 before generating the instruction. 15556 15557 `parityM2' 15558 Store into operand 0 the parity of X, i.e. the number of 1-bits in 15559 X modulo 2. M is the mode of operand 0; operand 1's mode is 15560 specified by the instruction pattern, and the compiler will convert 15561 the operand to that mode before generating the instruction. 15562 15563 `one_cmplM2' 15564 Store the bitwise-complement of operand 1 into operand 0. 15565 15566 `cmpM' 15567 Compare operand 0 and operand 1, and set the condition codes. The 15568 RTL pattern should look like this: 15569 15570 (set (cc0) (compare (match_operand:M 0 ...) 15571 (match_operand:M 1 ...))) 15572 15573 `tstM' 15574 Compare operand 0 against zero, and set the condition codes. The 15575 RTL pattern should look like this: 15576 15577 (set (cc0) (match_operand:M 0 ...)) 15578 15579 `tstM' patterns should not be defined for machines that do not use 15580 `(cc0)'. Doing so would confuse the optimizer since it would no 15581 longer be clear which `set' operations were comparisons. The 15582 `cmpM' patterns should be used instead. 15583 15584 `movmemM' 15585 Block move instruction. The destination and source blocks of 15586 memory are the first two operands, and both are `mem:BLK's with an 15587 address in mode `Pmode'. 15588 15589 The number of bytes to move is the third operand, in mode M. 15590 Usually, you specify `word_mode' for M. However, if you can 15591 generate better code knowing the range of valid lengths is smaller 15592 than those representable in a full word, you should provide a 15593 pattern with a mode corresponding to the range of values you can 15594 handle efficiently (e.g., `QImode' for values in the range 0-127; 15595 note we avoid numbers that appear negative) and also a pattern 15596 with `word_mode'. 15597 15598 The fourth operand is the known shared alignment of the source and 15599 destination, in the form of a `const_int' rtx. Thus, if the 15600 compiler knows that both source and destination are word-aligned, 15601 it may provide the value 4 for this operand. 15602 15603 Descriptions of multiple `movmemM' patterns can only be beneficial 15604 if the patterns for smaller modes have fewer restrictions on their 15605 first, second and fourth operands. Note that the mode M in 15606 `movmemM' does not impose any restriction on the mode of 15607 individually moved data units in the block. 15608 15609 These patterns need not give special consideration to the 15610 possibility that the source and destination strings might overlap. 15611 15612 `movstr' 15613 String copy instruction, with `stpcpy' semantics. Operand 0 is an 15614 output operand in mode `Pmode'. The addresses of the destination 15615 and source strings are operands 1 and 2, and both are `mem:BLK's 15616 with addresses in mode `Pmode'. The execution of the expansion of 15617 this pattern should store in operand 0 the address in which the 15618 `NUL' terminator was stored in the destination string. 15619 15620 `setmemM' 15621 Block set instruction. The destination string is the first 15622 operand, given as a `mem:BLK' whose address is in mode `Pmode'. 15623 The number of bytes to set is the second operand, in mode M. The 15624 value to initialize the memory with is the third operand. Targets 15625 that only support the clearing of memory should reject any value 15626 that is not the constant 0. See `movmemM' for a discussion of the 15627 choice of mode. 15628 15629 The fourth operand is the known alignment of the destination, in 15630 the form of a `const_int' rtx. Thus, if the compiler knows that 15631 the destination is word-aligned, it may provide the value 4 for 15632 this operand. 15633 15634 The use for multiple `setmemM' is as for `movmemM'. 15635 15636 `cmpstrnM' 15637 String compare instruction, with five operands. Operand 0 is the 15638 output; it has mode M. The remaining four operands are like the 15639 operands of `movmemM'. The two memory blocks specified are 15640 compared byte by byte in lexicographic order starting at the 15641 beginning of each string. The instruction is not allowed to 15642 prefetch more than one byte at a time since either string may end 15643 in the first byte and reading past that may access an invalid page 15644 or segment and cause a fault. The effect of the instruction is to 15645 store a value in operand 0 whose sign indicates the result of the 15646 comparison. 15647 15648 `cmpstrM' 15649 String compare instruction, without known maximum length. Operand 15650 0 is the output; it has mode M. The second and third operand are 15651 the blocks of memory to be compared; both are `mem:BLK' with an 15652 address in mode `Pmode'. 15653 15654 The fourth operand is the known shared alignment of the source and 15655 destination, in the form of a `const_int' rtx. Thus, if the 15656 compiler knows that both source and destination are word-aligned, 15657 it may provide the value 4 for this operand. 15658 15659 The two memory blocks specified are compared byte by byte in 15660 lexicographic order starting at the beginning of each string. The 15661 instruction is not allowed to prefetch more than one byte at a 15662 time since either string may end in the first byte and reading 15663 past that may access an invalid page or segment and cause a fault. 15664 The effect of the instruction is to store a value in operand 0 15665 whose sign indicates the result of the comparison. 15666 15667 `cmpmemM' 15668 Block compare instruction, with five operands like the operands of 15669 `cmpstrM'. The two memory blocks specified are compared byte by 15670 byte in lexicographic order starting at the beginning of each 15671 block. Unlike `cmpstrM' the instruction can prefetch any bytes in 15672 the two memory blocks. The effect of the instruction is to store 15673 a value in operand 0 whose sign indicates the result of the 15674 comparison. 15675 15676 `strlenM' 15677 Compute the length of a string, with three operands. Operand 0 is 15678 the result (of mode M), operand 1 is a `mem' referring to the 15679 first character of the string, operand 2 is the character to 15680 search for (normally zero), and operand 3 is a constant describing 15681 the known alignment of the beginning of the string. 15682 15683 `floatMN2' 15684 Convert signed integer operand 1 (valid for fixed point mode M) to 15685 floating point mode N and store in operand 0 (which has mode N). 15686 15687 `floatunsMN2' 15688 Convert unsigned integer operand 1 (valid for fixed point mode M) 15689 to floating point mode N and store in operand 0 (which has mode N). 15690 15691 `fixMN2' 15692 Convert operand 1 (valid for floating point mode M) to fixed point 15693 mode N as a signed number and store in operand 0 (which has mode 15694 N). This instruction's result is defined only when the value of 15695 operand 1 is an integer. 15696 15697 If the machine description defines this pattern, it also needs to 15698 define the `ftrunc' pattern. 15699 15700 `fixunsMN2' 15701 Convert operand 1 (valid for floating point mode M) to fixed point 15702 mode N as an unsigned number and store in operand 0 (which has 15703 mode N). This instruction's result is defined only when the value 15704 of operand 1 is an integer. 15705 15706 `ftruncM2' 15707 Convert operand 1 (valid for floating point mode M) to an integer 15708 value, still represented in floating point mode M, and store it in 15709 operand 0 (valid for floating point mode M). 15710 15711 `fix_truncMN2' 15712 Like `fixMN2' but works for any floating point value of mode M by 15713 converting the value to an integer. 15714 15715 `fixuns_truncMN2' 15716 Like `fixunsMN2' but works for any floating point value of mode M 15717 by converting the value to an integer. 15718 15719 `truncMN2' 15720 Truncate operand 1 (valid for mode M) to mode N and store in 15721 operand 0 (which has mode N). Both modes must be fixed point or 15722 both floating point. 15723 15724 `extendMN2' 15725 Sign-extend operand 1 (valid for mode M) to mode N and store in 15726 operand 0 (which has mode N). Both modes must be fixed point or 15727 both floating point. 15728 15729 `zero_extendMN2' 15730 Zero-extend operand 1 (valid for mode M) to mode N and store in 15731 operand 0 (which has mode N). Both modes must be fixed point. 15732 15733 `extv' 15734 Extract a bit-field from operand 1 (a register or memory operand), 15735 where operand 2 specifies the width in bits and operand 3 the 15736 starting bit, and store it in operand 0. Operand 0 must have mode 15737 `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode'; 15738 often `word_mode' is allowed only for registers. Operands 2 and 3 15739 must be valid for `word_mode'. 15740 15741 The RTL generation pass generates this instruction only with 15742 constants for operands 2 and 3 and the constant is never zero for 15743 operand 2. 15744 15745 The bit-field value is sign-extended to a full word integer before 15746 it is stored in operand 0. 15747 15748 `extzv' 15749 Like `extv' except that the bit-field value is zero-extended. 15750 15751 `insv' 15752 Store operand 3 (which must be valid for `word_mode') into a 15753 bit-field in operand 0, where operand 1 specifies the width in 15754 bits and operand 2 the starting bit. Operand 0 may have mode 15755 `byte_mode' or `word_mode'; often `word_mode' is allowed only for 15756 registers. Operands 1 and 2 must be valid for `word_mode'. 15757 15758 The RTL generation pass generates this instruction only with 15759 constants for operands 1 and 2 and the constant is never zero for 15760 operand 1. 15761 15762 `movMODEcc' 15763 Conditionally move operand 2 or operand 3 into operand 0 according 15764 to the comparison in operand 1. If the comparison is true, 15765 operand 2 is moved into operand 0, otherwise operand 3 is moved. 15766 15767 The mode of the operands being compared need not be the same as 15768 the operands being moved. Some machines, sparc64 for example, 15769 have instructions that conditionally move an integer value based 15770 on the floating point condition codes and vice versa. 15771 15772 If the machine does not have conditional move instructions, do not 15773 define these patterns. 15774 15775 `addMODEcc' 15776 Similar to `movMODEcc' but for conditional addition. Conditionally 15777 move operand 2 or (operands 2 + operand 3) into operand 0 15778 according to the comparison in operand 1. If the comparison is 15779 true, operand 2 is moved into operand 0, otherwise (operand 2 + 15780 operand 3) is moved. 15781 15782 `sCOND' 15783 Store zero or nonzero in the operand according to the condition 15784 codes. Value stored is nonzero iff the condition COND is true. 15785 COND is the name of a comparison operation expression code, such 15786 as `eq', `lt' or `leu'. 15787 15788 You specify the mode that the operand must have when you write the 15789 `match_operand' expression. The compiler automatically sees which 15790 mode you have used and supplies an operand of that mode. 15791 15792 The value stored for a true condition must have 1 as its low bit, 15793 or else must be negative. Otherwise the instruction is not 15794 suitable and you should omit it from the machine description. You 15795 describe to the compiler exactly which value is stored by defining 15796 the macro `STORE_FLAG_VALUE' (*note Misc::). If a description 15797 cannot be found that can be used for all the `sCOND' patterns, you 15798 should omit those operations from the machine description. 15799 15800 These operations may fail, but should do so only in relatively 15801 uncommon cases; if they would fail for common cases involving 15802 integer comparisons, it is best to omit these patterns. 15803 15804 If these operations are omitted, the compiler will usually 15805 generate code that copies the constant one to the target and 15806 branches around an assignment of zero to the target. If this code 15807 is more efficient than the potential instructions used for the 15808 `sCOND' pattern followed by those required to convert the result 15809 into a 1 or a zero in `SImode', you should omit the `sCOND' 15810 operations from the machine description. 15811 15812 `bCOND' 15813 Conditional branch instruction. Operand 0 is a `label_ref' that 15814 refers to the label to jump to. Jump if the condition codes meet 15815 condition COND. 15816 15817 Some machines do not follow the model assumed here where a 15818 comparison instruction is followed by a conditional branch 15819 instruction. In that case, the `cmpM' (and `tstM') patterns should 15820 simply store the operands away and generate all the required insns 15821 in a `define_expand' (*note Expander Definitions::) for the 15822 conditional branch operations. All calls to expand `bCOND' 15823 patterns are immediately preceded by calls to expand either a 15824 `cmpM' pattern or a `tstM' pattern. 15825 15826 Machines that use a pseudo register for the condition code value, 15827 or where the mode used for the comparison depends on the condition 15828 being tested, should also use the above mechanism. *Note Jump 15829 Patterns::. 15830 15831 The above discussion also applies to the `movMODEcc' and `sCOND' 15832 patterns. 15833 15834 `cbranchMODE4' 15835 Conditional branch instruction combined with a compare instruction. 15836 Operand 0 is a comparison operator. Operand 1 and operand 2 are 15837 the first and second operands of the comparison, respectively. 15838 Operand 3 is a `label_ref' that refers to the label to jump to. 15839 15840 `jump' 15841 A jump inside a function; an unconditional branch. Operand 0 is 15842 the `label_ref' of the label to jump to. This pattern name is 15843 mandatory on all machines. 15844 15845 `call' 15846 Subroutine call instruction returning no value. Operand 0 is the 15847 function to call; operand 1 is the number of bytes of arguments 15848 pushed as a `const_int'; operand 2 is the number of registers used 15849 as operands. 15850 15851 On most machines, operand 2 is not actually stored into the RTL 15852 pattern. It is supplied for the sake of some RISC machines which 15853 need to put this information into the assembler code; they can put 15854 it in the RTL instead of operand 1. 15855 15856 Operand 0 should be a `mem' RTX whose address is the address of the 15857 function. Note, however, that this address can be a `symbol_ref' 15858 expression even if it would not be a legitimate memory address on 15859 the target machine. If it is also not a valid argument for a call 15860 instruction, the pattern for this operation should be a 15861 `define_expand' (*note Expander Definitions::) that places the 15862 address into a register and uses that register in the call 15863 instruction. 15864 15865 `call_value' 15866 Subroutine call instruction returning a value. Operand 0 is the 15867 hard register in which the value is returned. There are three more 15868 operands, the same as the three operands of the `call' instruction 15869 (but with numbers increased by one). 15870 15871 Subroutines that return `BLKmode' objects use the `call' insn. 15872 15873 `call_pop', `call_value_pop' 15874 Similar to `call' and `call_value', except used if defined and if 15875 `RETURN_POPS_ARGS' is nonzero. They should emit a `parallel' that 15876 contains both the function call and a `set' to indicate the 15877 adjustment made to the frame pointer. 15878 15879 For machines where `RETURN_POPS_ARGS' can be nonzero, the use of 15880 these patterns increases the number of functions for which the 15881 frame pointer can be eliminated, if desired. 15882 15883 `untyped_call' 15884 Subroutine call instruction returning a value of any type. 15885 Operand 0 is the function to call; operand 1 is a memory location 15886 where the result of calling the function is to be stored; operand 15887 2 is a `parallel' expression where each element is a `set' 15888 expression that indicates the saving of a function return value 15889 into the result block. 15890 15891 This instruction pattern should be defined to support 15892 `__builtin_apply' on machines where special instructions are needed 15893 to call a subroutine with arbitrary arguments or to save the value 15894 returned. This instruction pattern is required on machines that 15895 have multiple registers that can hold a return value (i.e. 15896 `FUNCTION_VALUE_REGNO_P' is true for more than one register). 15897 15898 `return' 15899 Subroutine return instruction. This instruction pattern name 15900 should be defined only if a single instruction can do all the work 15901 of returning from a function. 15902 15903 Like the `movM' patterns, this pattern is also used after the RTL 15904 generation phase. In this case it is to support machines where 15905 multiple instructions are usually needed to return from a 15906 function, but some class of functions only requires one 15907 instruction to implement a return. Normally, the applicable 15908 functions are those which do not need to save any registers or 15909 allocate stack space. 15910 15911 For such machines, the condition specified in this pattern should 15912 only be true when `reload_completed' is nonzero and the function's 15913 epilogue would only be a single instruction. For machines with 15914 register windows, the routine `leaf_function_p' may be used to 15915 determine if a register window push is required. 15916 15917 Machines that have conditional return instructions should define 15918 patterns such as 15919 15920 (define_insn "" 15921 [(set (pc) 15922 (if_then_else (match_operator 15923 0 "comparison_operator" 15924 [(cc0) (const_int 0)]) 15925 (return) 15926 (pc)))] 15927 "CONDITION" 15928 "...") 15929 15930 where CONDITION would normally be the same condition specified on 15931 the named `return' pattern. 15932 15933 `untyped_return' 15934 Untyped subroutine return instruction. This instruction pattern 15935 should be defined to support `__builtin_return' on machines where 15936 special instructions are needed to return a value of any type. 15937 15938 Operand 0 is a memory location where the result of calling a 15939 function with `__builtin_apply' is stored; operand 1 is a 15940 `parallel' expression where each element is a `set' expression 15941 that indicates the restoring of a function return value from the 15942 result block. 15943 15944 `nop' 15945 No-op instruction. This instruction pattern name should always be 15946 defined to output a no-op in assembler code. `(const_int 0)' will 15947 do as an RTL pattern. 15948 15949 `indirect_jump' 15950 An instruction to jump to an address which is operand zero. This 15951 pattern name is mandatory on all machines. 15952 15953 `casesi' 15954 Instruction to jump through a dispatch table, including bounds 15955 checking. This instruction takes five operands: 15956 15957 1. The index to dispatch on, which has mode `SImode'. 15958 15959 2. The lower bound for indices in the table, an integer constant. 15960 15961 3. The total range of indices in the table--the largest index 15962 minus the smallest one (both inclusive). 15963 15964 4. A label that precedes the table itself. 15965 15966 5. A label to jump to if the index has a value outside the 15967 bounds. 15968 15969 The table is a `addr_vec' or `addr_diff_vec' inside of a 15970 `jump_insn'. The number of elements in the table is one plus the 15971 difference between the upper bound and the lower bound. 15972 15973 `tablejump' 15974 Instruction to jump to a variable address. This is a low-level 15975 capability which can be used to implement a dispatch table when 15976 there is no `casesi' pattern. 15977 15978 This pattern requires two operands: the address or offset, and a 15979 label which should immediately precede the jump table. If the 15980 macro `CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then 15981 the first operand is an offset which counts from the address of 15982 the table; otherwise, it is an absolute address to jump to. In 15983 either case, the first operand has mode `Pmode'. 15984 15985 The `tablejump' insn is always the last insn before the jump table 15986 it uses. Its assembler code normally has no need to use the 15987 second operand, but you should incorporate it in the RTL pattern so 15988 that the jump optimizer will not delete the table as unreachable 15989 code. 15990 15991 `decrement_and_branch_until_zero' 15992 Conditional branch instruction that decrements a register and 15993 jumps if the register is nonzero. Operand 0 is the register to 15994 decrement and test; operand 1 is the label to jump to if the 15995 register is nonzero. *Note Looping Patterns::. 15996 15997 This optional instruction pattern is only used by the combiner, 15998 typically for loops reversed by the loop optimizer when strength 15999 reduction is enabled. 16000 16001 `doloop_end' 16002 Conditional branch instruction that decrements a register and 16003 jumps if the register is nonzero. This instruction takes five 16004 operands: Operand 0 is the register to decrement and test; operand 16005 1 is the number of loop iterations as a `const_int' or 16006 `const0_rtx' if this cannot be determined until run-time; operand 16007 2 is the actual or estimated maximum number of iterations as a 16008 `const_int'; operand 3 is the number of enclosed loops as a 16009 `const_int' (an innermost loop has a value of 1); operand 4 is the 16010 label to jump to if the register is nonzero. *Note Looping 16011 Patterns::. 16012 16013 This optional instruction pattern should be defined for machines 16014 with low-overhead looping instructions as the loop optimizer will 16015 try to modify suitable loops to utilize it. If nested 16016 low-overhead looping is not supported, use a `define_expand' 16017 (*note Expander Definitions::) and make the pattern fail if 16018 operand 3 is not `const1_rtx'. Similarly, if the actual or 16019 estimated maximum number of iterations is too large for this 16020 instruction, make it fail. 16021 16022 `doloop_begin' 16023 Companion instruction to `doloop_end' required for machines that 16024 need to perform some initialization, such as loading special 16025 registers used by a low-overhead looping instruction. If 16026 initialization insns do not always need to be emitted, use a 16027 `define_expand' (*note Expander Definitions::) and make it fail. 16028 16029 `canonicalize_funcptr_for_compare' 16030 Canonicalize the function pointer in operand 1 and store the result 16031 into operand 0. 16032 16033 Operand 0 is always a `reg' and has mode `Pmode'; operand 1 may be 16034 a `reg', `mem', `symbol_ref', `const_int', etc and also has mode 16035 `Pmode'. 16036 16037 Canonicalization of a function pointer usually involves computing 16038 the address of the function which would be called if the function 16039 pointer were used in an indirect call. 16040 16041 Only define this pattern if function pointers on the target machine 16042 can have different values but still call the same function when 16043 used in an indirect call. 16044 16045 `save_stack_block' 16046 `save_stack_function' 16047 `save_stack_nonlocal' 16048 `restore_stack_block' 16049 `restore_stack_function' 16050 `restore_stack_nonlocal' 16051 Most machines save and restore the stack pointer by copying it to 16052 or from an object of mode `Pmode'. Do not define these patterns on 16053 such machines. 16054 16055 Some machines require special handling for stack pointer saves and 16056 restores. On those machines, define the patterns corresponding to 16057 the non-standard cases by using a `define_expand' (*note Expander 16058 Definitions::) that produces the required insns. The three types 16059 of saves and restores are: 16060 16061 1. `save_stack_block' saves the stack pointer at the start of a 16062 block that allocates a variable-sized object, and 16063 `restore_stack_block' restores the stack pointer when the 16064 block is exited. 16065 16066 2. `save_stack_function' and `restore_stack_function' do a 16067 similar job for the outermost block of a function and are 16068 used when the function allocates variable-sized objects or 16069 calls `alloca'. Only the epilogue uses the restored stack 16070 pointer, allowing a simpler save or restore sequence on some 16071 machines. 16072 16073 3. `save_stack_nonlocal' is used in functions that contain labels 16074 branched to by nested functions. It saves the stack pointer 16075 in such a way that the inner function can use 16076 `restore_stack_nonlocal' to restore the stack pointer. The 16077 compiler generates code to restore the frame and argument 16078 pointer registers, but some machines require saving and 16079 restoring additional data such as register window information 16080 or stack backchains. Place insns in these patterns to save 16081 and restore any such required data. 16082 16083 When saving the stack pointer, operand 0 is the save area and 16084 operand 1 is the stack pointer. The mode used to allocate the 16085 save area defaults to `Pmode' but you can override that choice by 16086 defining the `STACK_SAVEAREA_MODE' macro (*note Storage Layout::). 16087 You must specify an integral mode, or `VOIDmode' if no save area 16088 is needed for a particular type of save (either because no save is 16089 needed or because a machine-specific save area can be used). 16090 Operand 0 is the stack pointer and operand 1 is the save area for 16091 restore operations. If `save_stack_block' is defined, operand 0 16092 must not be `VOIDmode' since these saves can be arbitrarily nested. 16093 16094 A save area is a `mem' that is at a constant offset from 16095 `virtual_stack_vars_rtx' when the stack pointer is saved for use by 16096 nonlocal gotos and a `reg' in the other two cases. 16097 16098 `allocate_stack' 16099 Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 1 16100 from the stack pointer to create space for dynamically allocated 16101 data. 16102 16103 Store the resultant pointer to this space into operand 0. If you 16104 are allocating space from the main stack, do this by emitting a 16105 move insn to copy `virtual_stack_dynamic_rtx' to operand 0. If 16106 you are allocating the space elsewhere, generate code to copy the 16107 location of the space to operand 0. In the latter case, you must 16108 ensure this space gets freed when the corresponding space on the 16109 main stack is free. 16110 16111 Do not define this pattern if all that must be done is the 16112 subtraction. Some machines require other operations such as stack 16113 probes or maintaining the back chain. Define this pattern to emit 16114 those operations in addition to updating the stack pointer. 16115 16116 `check_stack' 16117 If stack checking cannot be done on your system by probing the 16118 stack with a load or store instruction (*note Stack Checking::), 16119 define this pattern to perform the needed check and signaling an 16120 error if the stack has overflowed. The single operand is the 16121 location in the stack furthest from the current stack pointer that 16122 you need to validate. Normally, on machines where this pattern is 16123 needed, you would obtain the stack limit from a global or 16124 thread-specific variable or register. 16125 16126 `nonlocal_goto' 16127 Emit code to generate a non-local goto, e.g., a jump from one 16128 function to a label in an outer function. This pattern has four 16129 arguments, each representing a value to be used in the jump. The 16130 first argument is to be loaded into the frame pointer, the second 16131 is the address to branch to (code to dispatch to the actual label), 16132 the third is the address of a location where the stack is saved, 16133 and the last is the address of the label, to be placed in the 16134 location for the incoming static chain. 16135 16136 On most machines you need not define this pattern, since GCC will 16137 already generate the correct code, which is to load the frame 16138 pointer and static chain, restore the stack (using the 16139 `restore_stack_nonlocal' pattern, if defined), and jump indirectly 16140 to the dispatcher. You need only define this pattern if this code 16141 will not work on your machine. 16142 16143 `nonlocal_goto_receiver' 16144 This pattern, if defined, contains code needed at the target of a 16145 nonlocal goto after the code already generated by GCC. You will 16146 not normally need to define this pattern. A typical reason why 16147 you might need this pattern is if some value, such as a pointer to 16148 a global table, must be restored when the frame pointer is 16149 restored. Note that a nonlocal goto only occurs within a 16150 unit-of-translation, so a global table pointer that is shared by 16151 all functions of a given module need not be restored. There are 16152 no arguments. 16153 16154 `exception_receiver' 16155 This pattern, if defined, contains code needed at the site of an 16156 exception handler that isn't needed at the site of a nonlocal 16157 goto. You will not normally need to define this pattern. A 16158 typical reason why you might need this pattern is if some value, 16159 such as a pointer to a global table, must be restored after 16160 control flow is branched to the handler of an exception. There 16161 are no arguments. 16162 16163 `builtin_setjmp_setup' 16164 This pattern, if defined, contains additional code needed to 16165 initialize the `jmp_buf'. You will not normally need to define 16166 this pattern. A typical reason why you might need this pattern is 16167 if some value, such as a pointer to a global table, must be 16168 restored. Though it is preferred that the pointer value be 16169 recalculated if possible (given the address of a label for 16170 instance). The single argument is a pointer to the `jmp_buf'. 16171 Note that the buffer is five words long and that the first three 16172 are normally used by the generic mechanism. 16173 16174 `builtin_setjmp_receiver' 16175 This pattern, if defined, contains code needed at the site of an 16176 built-in setjmp that isn't needed at the site of a nonlocal goto. 16177 You will not normally need to define this pattern. A typical 16178 reason why you might need this pattern is if some value, such as a 16179 pointer to a global table, must be restored. It takes one 16180 argument, which is the label to which builtin_longjmp transfered 16181 control; this pattern may be emitted at a small offset from that 16182 label. 16183 16184 `builtin_longjmp' 16185 This pattern, if defined, performs the entire action of the 16186 longjmp. You will not normally need to define this pattern unless 16187 you also define `builtin_setjmp_setup'. The single argument is a 16188 pointer to the `jmp_buf'. 16189 16190 `eh_return' 16191 This pattern, if defined, affects the way `__builtin_eh_return', 16192 and thence the call frame exception handling library routines, are 16193 built. It is intended to handle non-trivial actions needed along 16194 the abnormal return path. 16195 16196 The address of the exception handler to which the function should 16197 return is passed as operand to this pattern. It will normally 16198 need to copied by the pattern to some special register or memory 16199 location. If the pattern needs to determine the location of the 16200 target call frame in order to do so, it may use 16201 `EH_RETURN_STACKADJ_RTX', if defined; it will have already been 16202 assigned. 16203 16204 If this pattern is not defined, the default action will be to 16205 simply copy the return address to `EH_RETURN_HANDLER_RTX'. Either 16206 that macro or this pattern needs to be defined if call frame 16207 exception handling is to be used. 16208 16209 `prologue' 16210 This pattern, if defined, emits RTL for entry to a function. The 16211 function entry is responsible for setting up the stack frame, 16212 initializing the frame pointer register, saving callee saved 16213 registers, etc. 16214 16215 Using a prologue pattern is generally preferred over defining 16216 `TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the 16217 prologue. 16218 16219 The `prologue' pattern is particularly useful for targets which 16220 perform instruction scheduling. 16221 16222 `epilogue' 16223 This pattern emits RTL for exit from a function. The function 16224 exit is responsible for deallocating the stack frame, restoring 16225 callee saved registers and emitting the return instruction. 16226 16227 Using an epilogue pattern is generally preferred over defining 16228 `TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the 16229 epilogue. 16230 16231 The `epilogue' pattern is particularly useful for targets which 16232 perform instruction scheduling or which have delay slots for their 16233 return instruction. 16234 16235 `sibcall_epilogue' 16236 This pattern, if defined, emits RTL for exit from a function 16237 without the final branch back to the calling function. This 16238 pattern will be emitted before any sibling call (aka tail call) 16239 sites. 16240 16241 The `sibcall_epilogue' pattern must not clobber any arguments used 16242 for parameter passing or any stack slots for arguments passed to 16243 the current function. 16244 16245 `trap' 16246 This pattern, if defined, signals an error, typically by causing 16247 some kind of signal to be raised. Among other places, it is used 16248 by the Java front end to signal `invalid array index' exceptions. 16249 16250 `conditional_trap' 16251 Conditional trap instruction. Operand 0 is a piece of RTL which 16252 performs a comparison. Operand 1 is the trap code, an integer. 16253 16254 A typical `conditional_trap' pattern looks like 16255 16256 (define_insn "conditional_trap" 16257 [(trap_if (match_operator 0 "trap_operator" 16258 [(cc0) (const_int 0)]) 16259 (match_operand 1 "const_int_operand" "i"))] 16260 "" 16261 "...") 16262 16263 `prefetch' 16264 This pattern, if defined, emits code for a non-faulting data 16265 prefetch instruction. Operand 0 is the address of the memory to 16266 prefetch. Operand 1 is a constant 1 if the prefetch is preparing 16267 for a write to the memory address, or a constant 0 otherwise. 16268 Operand 2 is the expected degree of temporal locality of the data 16269 and is a value between 0 and 3, inclusive; 0 means that the data 16270 has no temporal locality, so it need not be left in the cache 16271 after the access; 3 means that the data has a high degree of 16272 temporal locality and should be left in all levels of cache 16273 possible; 1 and 2 mean, respectively, a low or moderate degree of 16274 temporal locality. 16275 16276 Targets that do not support write prefetches or locality hints can 16277 ignore the values of operands 1 and 2. 16278 16279 `memory_barrier' 16280 If the target memory model is not fully synchronous, then this 16281 pattern should be defined to an instruction that orders both loads 16282 and stores before the instruction with respect to loads and stores 16283 after the instruction. This pattern has no operands. 16284 16285 `sync_compare_and_swapMODE' 16286 This pattern, if defined, emits code for an atomic compare-and-swap 16287 operation. Operand 1 is the memory on which the atomic operation 16288 is performed. Operand 2 is the "old" value to be compared against 16289 the current contents of the memory location. Operand 3 is the 16290 "new" value to store in the memory if the compare succeeds. 16291 Operand 0 is the result of the operation; it should contain the 16292 contents of the memory before the operation. If the compare 16293 succeeds, this should obviously be a copy of operand 2. 16294 16295 This pattern must show that both operand 0 and operand 1 are 16296 modified. 16297 16298 This pattern must issue any memory barrier instructions such that 16299 all memory operations before the atomic operation occur before the 16300 atomic operation and all memory operations after the atomic 16301 operation occur after the atomic operation. 16302 16303 `sync_compare_and_swap_ccMODE' 16304 This pattern is just like `sync_compare_and_swapMODE', except it 16305 should act as if compare part of the compare-and-swap were issued 16306 via `cmpM'. This comparison will only be used with `EQ' and `NE' 16307 branches and `setcc' operations. 16308 16309 Some targets do expose the success or failure of the 16310 compare-and-swap operation via the status flags. Ideally we 16311 wouldn't need a separate named pattern in order to take advantage 16312 of this, but the combine pass does not handle patterns with 16313 multiple sets, which is required by definition for 16314 `sync_compare_and_swapMODE'. 16315 16316 `sync_addMODE', `sync_subMODE' 16317 `sync_iorMODE', `sync_andMODE' 16318 `sync_xorMODE', `sync_nandMODE' 16319 These patterns emit code for an atomic operation on memory. 16320 Operand 0 is the memory on which the atomic operation is performed. 16321 Operand 1 is the second operand to the binary operator. 16322 16323 The "nand" operation is `~op0 & op1'. 16324 16325 This pattern must issue any memory barrier instructions such that 16326 all memory operations before the atomic operation occur before the 16327 atomic operation and all memory operations after the atomic 16328 operation occur after the atomic operation. 16329 16330 If these patterns are not defined, the operation will be 16331 constructed from a compare-and-swap operation, if defined. 16332 16333 `sync_old_addMODE', `sync_old_subMODE' 16334 `sync_old_iorMODE', `sync_old_andMODE' 16335 `sync_old_xorMODE', `sync_old_nandMODE' 16336 These patterns are emit code for an atomic operation on memory, 16337 and return the value that the memory contained before the 16338 operation. Operand 0 is the result value, operand 1 is the memory 16339 on which the atomic operation is performed, and operand 2 is the 16340 second operand to the binary operator. 16341 16342 This pattern must issue any memory barrier instructions such that 16343 all memory operations before the atomic operation occur before the 16344 atomic operation and all memory operations after the atomic 16345 operation occur after the atomic operation. 16346 16347 If these patterns are not defined, the operation will be 16348 constructed from a compare-and-swap operation, if defined. 16349 16350 `sync_new_addMODE', `sync_new_subMODE' 16351 `sync_new_iorMODE', `sync_new_andMODE' 16352 `sync_new_xorMODE', `sync_new_nandMODE' 16353 These patterns are like their `sync_old_OP' counterparts, except 16354 that they return the value that exists in the memory location 16355 after the operation, rather than before the operation. 16356 16357 `sync_lock_test_and_setMODE' 16358 This pattern takes two forms, based on the capabilities of the 16359 target. In either case, operand 0 is the result of the operand, 16360 operand 1 is the memory on which the atomic operation is 16361 performed, and operand 2 is the value to set in the lock. 16362 16363 In the ideal case, this operation is an atomic exchange operation, 16364 in which the previous value in memory operand is copied into the 16365 result operand, and the value operand is stored in the memory 16366 operand. 16367 16368 For less capable targets, any value operand that is not the 16369 constant 1 should be rejected with `FAIL'. In this case the 16370 target may use an atomic test-and-set bit operation. The result 16371 operand should contain 1 if the bit was previously set and 0 if 16372 the bit was previously clear. The true contents of the memory 16373 operand are implementation defined. 16374 16375 This pattern must issue any memory barrier instructions such that 16376 the pattern as a whole acts as an acquire barrier, that is all 16377 memory operations after the pattern do not occur until the lock is 16378 acquired. 16379 16380 If this pattern is not defined, the operation will be constructed 16381 from a compare-and-swap operation, if defined. 16382 16383 `sync_lock_releaseMODE' 16384 This pattern, if defined, releases a lock set by 16385 `sync_lock_test_and_setMODE'. Operand 0 is the memory that 16386 contains the lock; operand 1 is the value to store in the lock. 16387 16388 If the target doesn't implement full semantics for 16389 `sync_lock_test_and_setMODE', any value operand which is not the 16390 constant 0 should be rejected with `FAIL', and the true contents 16391 of the memory operand are implementation defined. 16392 16393 This pattern must issue any memory barrier instructions such that 16394 the pattern as a whole acts as a release barrier, that is the lock 16395 is released only after all previous memory operations have 16396 completed. 16397 16398 If this pattern is not defined, then a `memory_barrier' pattern 16399 will be emitted, followed by a store of the value to the memory 16400 operand. 16401 16402 `stack_protect_set' 16403 This pattern, if defined, moves a `Pmode' value from the memory in 16404 operand 1 to the memory in operand 0 without leaving the value in 16405 a register afterward. This is to avoid leaking the value some 16406 place that an attacker might use to rewrite the stack guard slot 16407 after having clobbered it. 16408 16409 If this pattern is not defined, then a plain move pattern is 16410 generated. 16411 16412 `stack_protect_test' 16413 This pattern, if defined, compares a `Pmode' value from the memory 16414 in operand 1 with the memory in operand 0 without leaving the 16415 value in a register afterward and branches to operand 2 if the 16416 values weren't equal. 16417 16418 If this pattern is not defined, then a plain compare pattern and 16419 conditional branch pattern is used. 16420 16421 16422 16423 File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc 16424 16425 14.10 When the Order of Patterns Matters 16426 ======================================== 16427 16428 Sometimes an insn can match more than one instruction pattern. Then the 16429 pattern that appears first in the machine description is the one used. 16430 Therefore, more specific patterns (patterns that will match fewer 16431 things) and faster instructions (those that will produce better code 16432 when they do match) should usually go first in the description. 16433 16434 In some cases the effect of ordering the patterns can be used to hide 16435 a pattern when it is not valid. For example, the 68000 has an 16436 instruction for converting a fullword to floating point and another for 16437 converting a byte to floating point. An instruction converting an 16438 integer to floating point could match either one. We put the pattern 16439 to convert the fullword first to make sure that one will be used rather 16440 than the other. (Otherwise a large integer might be generated as a 16441 single-byte immediate quantity, which would not work.) Instead of 16442 using this pattern ordering it would be possible to make the pattern 16443 for convert-a-byte smart enough to deal properly with any constant 16444 value. 16445 16446 16447 File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc 16448 16449 14.11 Interdependence of Patterns 16450 ================================= 16451 16452 Every machine description must have a named pattern for each of the 16453 conditional branch names `bCOND'. The recognition template must always 16454 have the form 16455 16456 (set (pc) 16457 (if_then_else (COND (cc0) (const_int 0)) 16458 (label_ref (match_operand 0 "" "")) 16459 (pc))) 16460 16461 In addition, every machine description must have an anonymous pattern 16462 for each of the possible reverse-conditional branches. Their templates 16463 look like 16464 16465 (set (pc) 16466 (if_then_else (COND (cc0) (const_int 0)) 16467 (pc) 16468 (label_ref (match_operand 0 "" "")))) 16469 16470 They are necessary because jump optimization can turn direct-conditional 16471 branches into reverse-conditional branches. 16472 16473 It is often convenient to use the `match_operator' construct to reduce 16474 the number of patterns that must be specified for branches. For 16475 example, 16476 16477 (define_insn "" 16478 [(set (pc) 16479 (if_then_else (match_operator 0 "comparison_operator" 16480 [(cc0) (const_int 0)]) 16481 (pc) 16482 (label_ref (match_operand 1 "" ""))))] 16483 "CONDITION" 16484 "...") 16485 16486 In some cases machines support instructions identical except for the 16487 machine mode of one or more operands. For example, there may be 16488 "sign-extend halfword" and "sign-extend byte" instructions whose 16489 patterns are 16490 16491 (set (match_operand:SI 0 ...) 16492 (extend:SI (match_operand:HI 1 ...))) 16493 16494 (set (match_operand:SI 0 ...) 16495 (extend:SI (match_operand:QI 1 ...))) 16496 16497 Constant integers do not specify a machine mode, so an instruction to 16498 extend a constant value could match either pattern. The pattern it 16499 actually will match is the one that appears first in the file. For 16500 correct results, this must be the one for the widest possible mode 16501 (`HImode', here). If the pattern matches the `QImode' instruction, the 16502 results will be incorrect if the constant value does not actually fit 16503 that mode. 16504 16505 Such instructions to extend constants are rarely generated because 16506 they are optimized away, but they do occasionally happen in nonoptimized 16507 compilations. 16508 16509 If a constraint in a pattern allows a constant, the reload pass may 16510 replace a register with a constant permitted by the constraint in some 16511 cases. Similarly for memory references. Because of this substitution, 16512 you should not provide separate patterns for increment and decrement 16513 instructions. Instead, they should be generated from the same pattern 16514 that supports register-register add insns by examining the operands and 16515 generating the appropriate machine instruction. 16516 16517 16518 File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc 16519 16520 14.12 Defining Jump Instruction Patterns 16521 ======================================== 16522 16523 For most machines, GCC assumes that the machine has a condition code. 16524 A comparison insn sets the condition code, recording the results of both 16525 signed and unsigned comparison of the given operands. A separate branch 16526 insn tests the condition code and branches or not according its value. 16527 The branch insns come in distinct signed and unsigned flavors. Many 16528 common machines, such as the VAX, the 68000 and the 32000, work this 16529 way. 16530 16531 Some machines have distinct signed and unsigned compare instructions, 16532 and only one set of conditional branch instructions. The easiest way 16533 to handle these machines is to treat them just like the others until 16534 the final stage where assembly code is written. At this time, when 16535 outputting code for the compare instruction, peek ahead at the 16536 following branch using `next_cc0_user (insn)'. (The variable `insn' 16537 refers to the insn being output, in the output-writing code in an 16538 instruction pattern.) If the RTL says that is an unsigned branch, 16539 output an unsigned compare; otherwise output a signed compare. When 16540 the branch itself is output, you can treat signed and unsigned branches 16541 identically. 16542 16543 The reason you can do this is that GCC always generates a pair of 16544 consecutive RTL insns, possibly separated by `note' insns, one to set 16545 the condition code and one to test it, and keeps the pair inviolate 16546 until the end. 16547 16548 To go with this technique, you must define the machine-description 16549 macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no 16550 compare instruction is superfluous. 16551 16552 Some machines have compare-and-branch instructions and no condition 16553 code. A similar technique works for them. When it is time to "output" 16554 a compare instruction, record its operands in two static variables. 16555 When outputting the branch-on-condition-code instruction that follows, 16556 actually output a compare-and-branch instruction that uses the 16557 remembered operands. 16558 16559 It also works to define patterns for compare-and-branch instructions. 16560 In optimizing compilation, the pair of compare and branch instructions 16561 will be combined according to these patterns. But this does not happen 16562 if optimization is not requested. So you must use one of the solutions 16563 above in addition to any special patterns you define. 16564 16565 In many RISC machines, most instructions do not affect the condition 16566 code and there may not even be a separate condition code register. On 16567 these machines, the restriction that the definition and use of the 16568 condition code be adjacent insns is not necessary and can prevent 16569 important optimizations. For example, on the IBM RS/6000, there is a 16570 delay for taken branches unless the condition code register is set three 16571 instructions earlier than the conditional branch. The instruction 16572 scheduler cannot perform this optimization if it is not permitted to 16573 separate the definition and use of the condition code register. 16574 16575 On these machines, do not use `(cc0)', but instead use a register to 16576 represent the condition code. If there is a specific condition code 16577 register in the machine, use a hard register. If the condition code or 16578 comparison result can be placed in any general register, or if there are 16579 multiple condition registers, use a pseudo register. 16580 16581 On some machines, the type of branch instruction generated may depend 16582 on the way the condition code was produced; for example, on the 68k and 16583 SPARC, setting the condition code directly from an add or subtract 16584 instruction does not clear the overflow bit the way that a test 16585 instruction does, so a different branch instruction must be used for 16586 some conditional branches. For machines that use `(cc0)', the set and 16587 use of the condition code must be adjacent (separated only by `note' 16588 insns) allowing flags in `cc_status' to be used. (*Note Condition 16589 Code::.) Also, the comparison and branch insns can be located from 16590 each other by using the functions `prev_cc0_setter' and `next_cc0_user'. 16591 16592 However, this is not true on machines that do not use `(cc0)'. On 16593 those machines, no assumptions can be made about the adjacency of the 16594 compare and branch insns and the above methods cannot be used. Instead, 16595 we use the machine mode of the condition code register to record 16596 different formats of the condition code register. 16597 16598 Registers used to store the condition code value should have a mode 16599 that is in class `MODE_CC'. Normally, it will be `CCmode'. If 16600 additional modes are required (as for the add example mentioned above in 16601 the SPARC), define them in `MACHINE-modes.def' (*note Condition 16602 Code::). Also define `SELECT_CC_MODE' to choose a mode given an 16603 operand of a compare. 16604 16605 If it is known during RTL generation that a different mode will be 16606 required (for example, if the machine has separate compare instructions 16607 for signed and unsigned quantities, like most IBM processors), they can 16608 be specified at that time. 16609 16610 If the cases that require different modes would be made by instruction 16611 combination, the macro `SELECT_CC_MODE' determines which machine mode 16612 should be used for the comparison result. The patterns should be 16613 written using that mode. To support the case of the add on the SPARC 16614 discussed above, we have the pattern 16615 16616 (define_insn "" 16617 [(set (reg:CC_NOOV 0) 16618 (compare:CC_NOOV 16619 (plus:SI (match_operand:SI 0 "register_operand" "%r") 16620 (match_operand:SI 1 "arith_operand" "rI")) 16621 (const_int 0)))] 16622 "" 16623 "...") 16624 16625 The `SELECT_CC_MODE' macro on the SPARC returns `CC_NOOVmode' for 16626 comparisons whose argument is a `plus'. 16627 16628 16629 File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc 16630 16631 14.13 Defining Looping Instruction Patterns 16632 =========================================== 16633 16634 Some machines have special jump instructions that can be utilized to 16635 make loops more efficient. A common example is the 68000 `dbra' 16636 instruction which performs a decrement of a register and a branch if the 16637 result was greater than zero. Other machines, in particular digital 16638 signal processors (DSPs), have special block repeat instructions to 16639 provide low-overhead loop support. For example, the TI TMS320C3x/C4x 16640 DSPs have a block repeat instruction that loads special registers to 16641 mark the top and end of a loop and to count the number of loop 16642 iterations. This avoids the need for fetching and executing a 16643 `dbra'-like instruction and avoids pipeline stalls associated with the 16644 jump. 16645 16646 GCC has three special named patterns to support low overhead looping. 16647 They are `decrement_and_branch_until_zero', `doloop_begin', and 16648 `doloop_end'. The first pattern, `decrement_and_branch_until_zero', is 16649 not emitted during RTL generation but may be emitted during the 16650 instruction combination phase. This requires the assistance of the 16651 loop optimizer, using information collected during strength reduction, 16652 to reverse a loop to count down to zero. Some targets also require the 16653 loop optimizer to add a `REG_NONNEG' note to indicate that the 16654 iteration count is always positive. This is needed if the target 16655 performs a signed loop termination test. For example, the 68000 uses a 16656 pattern similar to the following for its `dbra' instruction: 16657 16658 (define_insn "decrement_and_branch_until_zero" 16659 [(set (pc) 16660 (if_then_else 16661 (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am") 16662 (const_int -1)) 16663 (const_int 0)) 16664 (label_ref (match_operand 1 "" "")) 16665 (pc))) 16666 (set (match_dup 0) 16667 (plus:SI (match_dup 0) 16668 (const_int -1)))] 16669 "find_reg_note (insn, REG_NONNEG, 0)" 16670 "...") 16671 16672 Note that since the insn is both a jump insn and has an output, it must 16673 deal with its own reloads, hence the `m' constraints. Also note that 16674 since this insn is generated by the instruction combination phase 16675 combining two sequential insns together into an implicit parallel insn, 16676 the iteration counter needs to be biased by the same amount as the 16677 decrement operation, in this case -1. Note that the following similar 16678 pattern will not be matched by the combiner. 16679 16680 (define_insn "decrement_and_branch_until_zero" 16681 [(set (pc) 16682 (if_then_else 16683 (ge (match_operand:SI 0 "general_operand" "+d*am") 16684 (const_int 1)) 16685 (label_ref (match_operand 1 "" "")) 16686 (pc))) 16687 (set (match_dup 0) 16688 (plus:SI (match_dup 0) 16689 (const_int -1)))] 16690 "find_reg_note (insn, REG_NONNEG, 0)" 16691 "...") 16692 16693 The other two special looping patterns, `doloop_begin' and 16694 `doloop_end', are emitted by the loop optimizer for certain 16695 well-behaved loops with a finite number of loop iterations using 16696 information collected during strength reduction. 16697 16698 The `doloop_end' pattern describes the actual looping instruction (or 16699 the implicit looping operation) and the `doloop_begin' pattern is an 16700 optional companion pattern that can be used for initialization needed 16701 for some low-overhead looping instructions. 16702 16703 Note that some machines require the actual looping instruction to be 16704 emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting 16705 the true RTL for a looping instruction at the top of the loop can cause 16706 problems with flow analysis. So instead, a dummy `doloop' insn is 16707 emitted at the end of the loop. The machine dependent reorg pass checks 16708 for the presence of this `doloop' insn and then searches back to the 16709 top of the loop, where it inserts the true looping insn (provided there 16710 are no instructions in the loop which would cause problems). Any 16711 additional labels can be emitted at this point. In addition, if the 16712 desired special iteration counter register was not allocated, this 16713 machine dependent reorg pass could emit a traditional compare and jump 16714 instruction pair. 16715 16716 The essential difference between the `decrement_and_branch_until_zero' 16717 and the `doloop_end' patterns is that the loop optimizer allocates an 16718 additional pseudo register for the latter as an iteration counter. 16719 This pseudo register cannot be used within the loop (i.e., general 16720 induction variables cannot be derived from it), however, in many cases 16721 the loop induction variable may become redundant and removed by the 16722 flow pass. 16723 16724 16725 File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc 16726 16727 14.14 Canonicalization of Instructions 16728 ====================================== 16729 16730 There are often cases where multiple RTL expressions could represent an 16731 operation performed by a single machine instruction. This situation is 16732 most commonly encountered with logical, branch, and multiply-accumulate 16733 instructions. In such cases, the compiler attempts to convert these 16734 multiple RTL expressions into a single canonical form to reduce the 16735 number of insn patterns required. 16736 16737 In addition to algebraic simplifications, following canonicalizations 16738 are performed: 16739 16740 * For commutative and comparison operators, a constant is always 16741 made the second operand. If a machine only supports a constant as 16742 the second operand, only patterns that match a constant in the 16743 second operand need be supplied. 16744 16745 * For associative operators, a sequence of operators will always 16746 chain to the left; for instance, only the left operand of an 16747 integer `plus' can itself be a `plus'. `and', `ior', `xor', 16748 `plus', `mult', `smin', `smax', `umin', and `umax' are associative 16749 when applied to integers, and sometimes to floating-point. 16750 16751 * For these operators, if only one operand is a `neg', `not', 16752 `mult', `plus', or `minus' expression, it will be the first 16753 operand. 16754 16755 * In combinations of `neg', `mult', `plus', and `minus', the `neg' 16756 operations (if any) will be moved inside the operations as far as 16757 possible. For instance, `(neg (mult A B))' is canonicalized as 16758 `(mult (neg A) B)', but `(plus (mult (neg A) B) C)' is 16759 canonicalized as `(minus A (mult B C))'. 16760 16761 * For the `compare' operator, a constant is always the second operand 16762 on machines where `cc0' is used (*note Jump Patterns::). On other 16763 machines, there are rare cases where the compiler might want to 16764 construct a `compare' with a constant as the first operand. 16765 However, these cases are not common enough for it to be worthwhile 16766 to provide a pattern matching a constant as the first operand 16767 unless the machine actually has such an instruction. 16768 16769 An operand of `neg', `not', `mult', `plus', or `minus' is made the 16770 first operand under the same conditions as above. 16771 16772 * `(minus X (const_int N))' is converted to `(plus X (const_int 16773 -N))'. 16774 16775 * Within address computations (i.e., inside `mem'), a left shift is 16776 converted into the appropriate multiplication by a power of two. 16777 16778 * De Morgan's Law is used to move bitwise negation inside a bitwise 16779 logical-and or logical-or operation. If this results in only one 16780 operand being a `not' expression, it will be the first one. 16781 16782 A machine that has an instruction that performs a bitwise 16783 logical-and of one operand with the bitwise negation of the other 16784 should specify the pattern for that instruction as 16785 16786 (define_insn "" 16787 [(set (match_operand:M 0 ...) 16788 (and:M (not:M (match_operand:M 1 ...)) 16789 (match_operand:M 2 ...)))] 16790 "..." 16791 "...") 16792 16793 Similarly, a pattern for a "NAND" instruction should be written 16794 16795 (define_insn "" 16796 [(set (match_operand:M 0 ...) 16797 (ior:M (not:M (match_operand:M 1 ...)) 16798 (not:M (match_operand:M 2 ...))))] 16799 "..." 16800 "...") 16801 16802 In both cases, it is not necessary to include patterns for the many 16803 logically equivalent RTL expressions. 16804 16805 * The only possible RTL expressions involving both bitwise 16806 exclusive-or and bitwise negation are `(xor:M X Y)' and `(not:M 16807 (xor:M X Y))'. 16808 16809 * The sum of three items, one of which is a constant, will only 16810 appear in the form 16811 16812 (plus:M (plus:M X Y) CONSTANT) 16813 16814 * On machines that do not use `cc0', `(compare X (const_int 0))' 16815 will be converted to X. 16816 16817 * Equality comparisons of a group of bits (usually a single bit) 16818 with zero will be written using `zero_extract' rather than the 16819 equivalent `and' or `sign_extract' operations. 16820 16821 16822 Further canonicalization rules are defined in the function 16823 `commutative_operand_precedence' in `gcc/rtlanal.c'. 16824 16825 16826 File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc 16827 16828 14.15 Defining RTL Sequences for Code Generation 16829 ================================================ 16830 16831 On some target machines, some standard pattern names for RTL generation 16832 cannot be handled with single insn, but a sequence of RTL insns can 16833 represent them. For these target machines, you can write a 16834 `define_expand' to specify how to generate the sequence of RTL. 16835 16836 A `define_expand' is an RTL expression that looks almost like a 16837 `define_insn'; but, unlike the latter, a `define_expand' is used only 16838 for RTL generation and it can produce more than one RTL insn. 16839 16840 A `define_expand' RTX has four operands: 16841 16842 * The name. Each `define_expand' must have a name, since the only 16843 use for it is to refer to it by name. 16844 16845 * The RTL template. This is a vector of RTL expressions representing 16846 a sequence of separate instructions. Unlike `define_insn', there 16847 is no implicit surrounding `PARALLEL'. 16848 16849 * The condition, a string containing a C expression. This 16850 expression is used to express how the availability of this pattern 16851 depends on subclasses of target machine, selected by command-line 16852 options when GCC is run. This is just like the condition of a 16853 `define_insn' that has a standard name. Therefore, the condition 16854 (if present) may not depend on the data in the insn being matched, 16855 but only the target-machine-type flags. The compiler needs to 16856 test these conditions during initialization in order to learn 16857 exactly which named instructions are available in a particular run. 16858 16859 * The preparation statements, a string containing zero or more C 16860 statements which are to be executed before RTL code is generated 16861 from the RTL template. 16862 16863 Usually these statements prepare temporary registers for use as 16864 internal operands in the RTL template, but they can also generate 16865 RTL insns directly by calling routines such as `emit_insn', etc. 16866 Any such insns precede the ones that come from the RTL template. 16867 16868 Every RTL insn emitted by a `define_expand' must match some 16869 `define_insn' in the machine description. Otherwise, the compiler will 16870 crash when trying to generate code for the insn or trying to optimize 16871 it. 16872 16873 The RTL template, in addition to controlling generation of RTL insns, 16874 also describes the operands that need to be specified when this pattern 16875 is used. In particular, it gives a predicate for each operand. 16876 16877 A true operand, which needs to be specified in order to generate RTL 16878 from the pattern, should be described with a `match_operand' in its 16879 first occurrence in the RTL template. This enters information on the 16880 operand's predicate into the tables that record such things. GCC uses 16881 the information to preload the operand into a register if that is 16882 required for valid RTL code. If the operand is referred to more than 16883 once, subsequent references should use `match_dup'. 16884 16885 The RTL template may also refer to internal "operands" which are 16886 temporary registers or labels used only within the sequence made by the 16887 `define_expand'. Internal operands are substituted into the RTL 16888 template with `match_dup', never with `match_operand'. The values of 16889 the internal operands are not passed in as arguments by the compiler 16890 when it requests use of this pattern. Instead, they are computed 16891 within the pattern, in the preparation statements. These statements 16892 compute the values and store them into the appropriate elements of 16893 `operands' so that `match_dup' can find them. 16894 16895 There are two special macros defined for use in the preparation 16896 statements: `DONE' and `FAIL'. Use them with a following semicolon, as 16897 a statement. 16898 16899 `DONE' 16900 Use the `DONE' macro to end RTL generation for the pattern. The 16901 only RTL insns resulting from the pattern on this occasion will be 16902 those already emitted by explicit calls to `emit_insn' within the 16903 preparation statements; the RTL template will not be generated. 16904 16905 `FAIL' 16906 Make the pattern fail on this occasion. When a pattern fails, it 16907 means that the pattern was not truly available. The calling 16908 routines in the compiler will try other strategies for code 16909 generation using other patterns. 16910 16911 Failure is currently supported only for binary (addition, 16912 multiplication, shifting, etc.) and bit-field (`extv', `extzv', 16913 and `insv') operations. 16914 16915 If the preparation falls through (invokes neither `DONE' nor `FAIL'), 16916 then the `define_expand' acts like a `define_insn' in that the RTL 16917 template is used to generate the insn. 16918 16919 The RTL template is not used for matching, only for generating the 16920 initial insn list. If the preparation statement always invokes `DONE' 16921 or `FAIL', the RTL template may be reduced to a simple list of 16922 operands, such as this example: 16923 16924 (define_expand "addsi3" 16925 [(match_operand:SI 0 "register_operand" "") 16926 (match_operand:SI 1 "register_operand" "") 16927 (match_operand:SI 2 "register_operand" "")] 16928 "" 16929 " 16930 { 16931 handle_add (operands[0], operands[1], operands[2]); 16932 DONE; 16933 }") 16934 16935 Here is an example, the definition of left-shift for the SPUR chip: 16936 16937 (define_expand "ashlsi3" 16938 [(set (match_operand:SI 0 "register_operand" "") 16939 (ashift:SI 16940 (match_operand:SI 1 "register_operand" "") 16941 (match_operand:SI 2 "nonmemory_operand" "")))] 16942 "" 16943 " 16944 16945 { 16946 if (GET_CODE (operands[2]) != CONST_INT 16947 || (unsigned) INTVAL (operands[2]) > 3) 16948 FAIL; 16949 }") 16950 16951 This example uses `define_expand' so that it can generate an RTL insn 16952 for shifting when the shift-count is in the supported range of 0 to 3 16953 but fail in other cases where machine insns aren't available. When it 16954 fails, the compiler tries another strategy using different patterns 16955 (such as, a library call). 16956 16957 If the compiler were able to handle nontrivial condition-strings in 16958 patterns with names, then it would be possible to use a `define_insn' 16959 in that case. Here is another case (zero-extension on the 68000) which 16960 makes more use of the power of `define_expand': 16961 16962 (define_expand "zero_extendhisi2" 16963 [(set (match_operand:SI 0 "general_operand" "") 16964 (const_int 0)) 16965 (set (strict_low_part 16966 (subreg:HI 16967 (match_dup 0) 16968 0)) 16969 (match_operand:HI 1 "general_operand" ""))] 16970 "" 16971 "operands[1] = make_safe_from (operands[1], operands[0]);") 16972 16973 Here two RTL insns are generated, one to clear the entire output operand 16974 and the other to copy the input operand into its low half. This 16975 sequence is incorrect if the input operand refers to [the old value of] 16976 the output operand, so the preparation statement makes sure this isn't 16977 so. The function `make_safe_from' copies the `operands[1]' into a 16978 temporary register if it refers to `operands[0]'. It does this by 16979 emitting another RTL insn. 16980 16981 Finally, a third example shows the use of an internal operand. 16982 Zero-extension on the SPUR chip is done by `and'-ing the result against 16983 a halfword mask. But this mask cannot be represented by a `const_int' 16984 because the constant value is too large to be legitimate on this 16985 machine. So it must be copied into a register with `force_reg' and 16986 then the register used in the `and'. 16987 16988 (define_expand "zero_extendhisi2" 16989 [(set (match_operand:SI 0 "register_operand" "") 16990 (and:SI (subreg:SI 16991 (match_operand:HI 1 "register_operand" "") 16992 0) 16993 (match_dup 2)))] 16994 "" 16995 "operands[2] 16996 = force_reg (SImode, GEN_INT (65535)); ") 16997 16998 _Note:_ If the `define_expand' is used to serve a standard binary or 16999 unary arithmetic operation or a bit-field operation, then the last insn 17000 it generates must not be a `code_label', `barrier' or `note'. It must 17001 be an `insn', `jump_insn' or `call_insn'. If you don't need a real insn 17002 at the end, emit an insn to copy the result of the operation into 17003 itself. Such an insn will generate no code, but it can avoid problems 17004 in the compiler. 17005 17006 17007 File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc 17008 17009 14.16 Defining How to Split Instructions 17010 ======================================== 17011 17012 There are two cases where you should specify how to split a pattern 17013 into multiple insns. On machines that have instructions requiring 17014 delay slots (*note Delay Slots::) or that have instructions whose 17015 output is not available for multiple cycles (*note Processor pipeline 17016 description::), the compiler phases that optimize these cases need to 17017 be able to move insns into one-instruction delay slots. However, some 17018 insns may generate more than one machine instruction. These insns 17019 cannot be placed into a delay slot. 17020 17021 Often you can rewrite the single insn as a list of individual insns, 17022 each corresponding to one machine instruction. The disadvantage of 17023 doing so is that it will cause the compilation to be slower and require 17024 more space. If the resulting insns are too complex, it may also 17025 suppress some optimizations. The compiler splits the insn if there is a 17026 reason to believe that it might improve instruction or delay slot 17027 scheduling. 17028 17029 The insn combiner phase also splits putative insns. If three insns are 17030 merged into one insn with a complex expression that cannot be matched by 17031 some `define_insn' pattern, the combiner phase attempts to split the 17032 complex pattern into two insns that are recognized. Usually it can 17033 break the complex pattern into two patterns by splitting out some 17034 subexpression. However, in some other cases, such as performing an 17035 addition of a large constant in two insns on a RISC machine, the way to 17036 split the addition into two insns is machine-dependent. 17037 17038 The `define_split' definition tells the compiler how to split a 17039 complex insn into several simpler insns. It looks like this: 17040 17041 (define_split 17042 [INSN-PATTERN] 17043 "CONDITION" 17044 [NEW-INSN-PATTERN-1 17045 NEW-INSN-PATTERN-2 17046 ...] 17047 "PREPARATION-STATEMENTS") 17048 17049 INSN-PATTERN is a pattern that needs to be split and CONDITION is the 17050 final condition to be tested, as in a `define_insn'. When an insn 17051 matching INSN-PATTERN and satisfying CONDITION is found, it is replaced 17052 in the insn list with the insns given by NEW-INSN-PATTERN-1, 17053 NEW-INSN-PATTERN-2, etc. 17054 17055 The PREPARATION-STATEMENTS are similar to those statements that are 17056 specified for `define_expand' (*note Expander Definitions::) and are 17057 executed before the new RTL is generated to prepare for the generated 17058 code or emit some insns whose pattern is not fixed. Unlike those in 17059 `define_expand', however, these statements must not generate any new 17060 pseudo-registers. Once reload has completed, they also must not 17061 allocate any space in the stack frame. 17062 17063 Patterns are matched against INSN-PATTERN in two different 17064 circumstances. If an insn needs to be split for delay slot scheduling 17065 or insn scheduling, the insn is already known to be valid, which means 17066 that it must have been matched by some `define_insn' and, if 17067 `reload_completed' is nonzero, is known to satisfy the constraints of 17068 that `define_insn'. In that case, the new insn patterns must also be 17069 insns that are matched by some `define_insn' and, if `reload_completed' 17070 is nonzero, must also satisfy the constraints of those definitions. 17071 17072 As an example of this usage of `define_split', consider the following 17073 example from `a29k.md', which splits a `sign_extend' from `HImode' to 17074 `SImode' into a pair of shift insns: 17075 17076 (define_split 17077 [(set (match_operand:SI 0 "gen_reg_operand" "") 17078 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 17079 "" 17080 [(set (match_dup 0) 17081 (ashift:SI (match_dup 1) 17082 (const_int 16))) 17083 (set (match_dup 0) 17084 (ashiftrt:SI (match_dup 0) 17085 (const_int 16)))] 17086 " 17087 { operands[1] = gen_lowpart (SImode, operands[1]); }") 17088 17089 When the combiner phase tries to split an insn pattern, it is always 17090 the case that the pattern is _not_ matched by any `define_insn'. The 17091 combiner pass first tries to split a single `set' expression and then 17092 the same `set' expression inside a `parallel', but followed by a 17093 `clobber' of a pseudo-reg to use as a scratch register. In these 17094 cases, the combiner expects exactly two new insn patterns to be 17095 generated. It will verify that these patterns match some `define_insn' 17096 definitions, so you need not do this test in the `define_split' (of 17097 course, there is no point in writing a `define_split' that will never 17098 produce insns that match). 17099 17100 Here is an example of this use of `define_split', taken from 17101 `rs6000.md': 17102 17103 (define_split 17104 [(set (match_operand:SI 0 "gen_reg_operand" "") 17105 (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 17106 (match_operand:SI 2 "non_add_cint_operand" "")))] 17107 "" 17108 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 17109 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 17110 " 17111 { 17112 int low = INTVAL (operands[2]) & 0xffff; 17113 int high = (unsigned) INTVAL (operands[2]) >> 16; 17114 17115 if (low & 0x8000) 17116 high++, low |= 0xffff0000; 17117 17118 operands[3] = GEN_INT (high << 16); 17119 operands[4] = GEN_INT (low); 17120 }") 17121 17122 Here the predicate `non_add_cint_operand' matches any `const_int' that 17123 is _not_ a valid operand of a single add insn. The add with the 17124 smaller displacement is written so that it can be substituted into the 17125 address of a subsequent operation. 17126 17127 An example that uses a scratch register, from the same file, generates 17128 an equality comparison of a register and a large constant: 17129 17130 (define_split 17131 [(set (match_operand:CC 0 "cc_reg_operand" "") 17132 (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 17133 (match_operand:SI 2 "non_short_cint_operand" ""))) 17134 (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 17135 "find_single_use (operands[0], insn, 0) 17136 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 17137 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 17138 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 17139 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 17140 " 17141 { 17142 /* Get the constant we are comparing against, C, and see what it 17143 looks like sign-extended to 16 bits. Then see what constant 17144 could be XOR'ed with C to get the sign-extended value. */ 17145 17146 int c = INTVAL (operands[2]); 17147 int sextc = (c << 16) >> 16; 17148 int xorv = c ^ sextc; 17149 17150 operands[4] = GEN_INT (xorv); 17151 operands[5] = GEN_INT (sextc); 17152 }") 17153 17154 To avoid confusion, don't write a single `define_split' that accepts 17155 some insns that match some `define_insn' as well as some insns that 17156 don't. Instead, write two separate `define_split' definitions, one for 17157 the insns that are valid and one for the insns that are not valid. 17158 17159 The splitter is allowed to split jump instructions into sequence of 17160 jumps or create new jumps in while splitting non-jump instructions. As 17161 the central flowgraph and branch prediction information needs to be 17162 updated, several restriction apply. 17163 17164 Splitting of jump instruction into sequence that over by another jump 17165 instruction is always valid, as compiler expect identical behavior of 17166 new jump. When new sequence contains multiple jump instructions or new 17167 labels, more assistance is needed. Splitter is required to create only 17168 unconditional jumps, or simple conditional jump instructions. 17169 Additionally it must attach a `REG_BR_PROB' note to each conditional 17170 jump. A global variable `split_branch_probability' holds the 17171 probability of the original branch in case it was an simple conditional 17172 jump, -1 otherwise. To simplify recomputing of edge frequencies, the 17173 new sequence is required to have only forward jumps to the newly 17174 created labels. 17175 17176 For the common case where the pattern of a define_split exactly 17177 matches the pattern of a define_insn, use `define_insn_and_split'. It 17178 looks like this: 17179 17180 (define_insn_and_split 17181 [INSN-PATTERN] 17182 "CONDITION" 17183 "OUTPUT-TEMPLATE" 17184 "SPLIT-CONDITION" 17185 [NEW-INSN-PATTERN-1 17186 NEW-INSN-PATTERN-2 17187 ...] 17188 "PREPARATION-STATEMENTS" 17189 [INSN-ATTRIBUTES]) 17190 17191 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used 17192 as in `define_insn'. The NEW-INSN-PATTERN vector and the 17193 PREPARATION-STATEMENTS are used as in a `define_split'. The 17194 SPLIT-CONDITION is also used as in `define_split', with the additional 17195 behavior that if the condition starts with `&&', the condition used for 17196 the split will be the constructed as a logical "and" of the split 17197 condition with the insn condition. For example, from i386.md: 17198 17199 (define_insn_and_split "zero_extendhisi2_and" 17200 [(set (match_operand:SI 0 "register_operand" "=r") 17201 (zero_extend:SI (match_operand:HI 1 "register_operand" "0"))) 17202 (clobber (reg:CC 17))] 17203 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size" 17204 "#" 17205 "&& reload_completed" 17206 [(parallel [(set (match_dup 0) 17207 (and:SI (match_dup 0) (const_int 65535))) 17208 (clobber (reg:CC 17))])] 17209 "" 17210 [(set_attr "type" "alu1")]) 17211 17212 In this case, the actual split condition will be 17213 `TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'. 17214 17215 The `define_insn_and_split' construction provides exactly the same 17216 functionality as two separate `define_insn' and `define_split' 17217 patterns. It exists for compactness, and as a maintenance tool to 17218 prevent having to ensure the two patterns' templates match. 17219 17220 17221 File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc 17222 17223 14.17 Including Patterns in Machine Descriptions. 17224 ================================================= 17225 17226 The `include' pattern tells the compiler tools where to look for 17227 patterns that are in files other than in the file `.md'. This is used 17228 only at build time and there is no preprocessing allowed. 17229 17230 It looks like: 17231 17232 17233 (include 17234 PATHNAME) 17235 17236 For example: 17237 17238 17239 (include "filestuff") 17240 17241 Where PATHNAME is a string that specifies the location of the file, 17242 specifies the include file to be in `gcc/config/target/filestuff'. The 17243 directory `gcc/config/target' is regarded as the default directory. 17244 17245 Machine descriptions may be split up into smaller more manageable 17246 subsections and placed into subdirectories. 17247 17248 By specifying: 17249 17250 17251 (include "BOGUS/filestuff") 17252 17253 the include file is specified to be in 17254 `gcc/config/TARGET/BOGUS/filestuff'. 17255 17256 Specifying an absolute path for the include file such as; 17257 17258 (include "/u2/BOGUS/filestuff") 17259 is permitted but is not encouraged. 17260 17261 14.17.1 RTL Generation Tool Options for Directory Search 17262 -------------------------------------------------------- 17263 17264 The `-IDIR' option specifies directories to search for machine 17265 descriptions. For example: 17266 17267 17268 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md 17269 17270 Add the directory DIR to the head of the list of directories to be 17271 searched for header files. This can be used to override a system 17272 machine definition file, substituting your own version, since these 17273 directories are searched before the default machine description file 17274 directories. If you use more than one `-I' option, the directories are 17275 scanned in left-to-right order; the standard default directory come 17276 after. 17277 17278 17279 File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc 17280 17281 14.18 Machine-Specific Peephole Optimizers 17282 ========================================== 17283 17284 In addition to instruction patterns the `md' file may contain 17285 definitions of machine-specific peephole optimizations. 17286 17287 The combiner does not notice certain peephole optimizations when the 17288 data flow in the program does not suggest that it should try them. For 17289 example, sometimes two consecutive insns related in purpose can be 17290 combined even though the second one does not appear to use a register 17291 computed in the first one. A machine-specific peephole optimizer can 17292 detect such opportunities. 17293 17294 There are two forms of peephole definitions that may be used. The 17295 original `define_peephole' is run at assembly output time to match 17296 insns and substitute assembly text. Use of `define_peephole' is 17297 deprecated. 17298 17299 A newer `define_peephole2' matches insns and substitutes new insns. 17300 The `peephole2' pass is run after register allocation but before 17301 scheduling, which may result in much better code for targets that do 17302 scheduling. 17303 17304 * Menu: 17305 17306 * define_peephole:: RTL to Text Peephole Optimizers 17307 * define_peephole2:: RTL to RTL Peephole Optimizers 17308 17309 17310 File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions 17311 17312 14.18.1 RTL to Text Peephole Optimizers 17313 --------------------------------------- 17314 17315 A definition looks like this: 17316 17317 (define_peephole 17318 [INSN-PATTERN-1 17319 INSN-PATTERN-2 17320 ...] 17321 "CONDITION" 17322 "TEMPLATE" 17323 "OPTIONAL-INSN-ATTRIBUTES") 17324 17325 The last string operand may be omitted if you are not using any 17326 machine-specific information in this machine description. If present, 17327 it must obey the same rules as in a `define_insn'. 17328 17329 In this skeleton, INSN-PATTERN-1 and so on are patterns to match 17330 consecutive insns. The optimization applies to a sequence of insns when 17331 INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, 17332 and so on. 17333 17334 Each of the insns matched by a peephole must also match a 17335 `define_insn'. Peepholes are checked only at the last stage just 17336 before code generation, and only optionally. Therefore, any insn which 17337 would match a peephole but no `define_insn' will cause a crash in code 17338 generation in an unoptimized compilation, or at various optimization 17339 stages. 17340 17341 The operands of the insns are matched with `match_operands', 17342 `match_operator', and `match_dup', as usual. What is not usual is that 17343 the operand numbers apply to all the insn patterns in the definition. 17344 So, you can check for identical operands in two insns by using 17345 `match_operand' in one insn and `match_dup' in the other. 17346 17347 The operand constraints used in `match_operand' patterns do not have 17348 any direct effect on the applicability of the peephole, but they will 17349 be validated afterward, so make sure your constraints are general enough 17350 to apply whenever the peephole matches. If the peephole matches but 17351 the constraints are not satisfied, the compiler will crash. 17352 17353 It is safe to omit constraints in all the operands of the peephole; or 17354 you can write constraints which serve as a double-check on the criteria 17355 previously tested. 17356 17357 Once a sequence of insns matches the patterns, the CONDITION is 17358 checked. This is a C expression which makes the final decision whether 17359 to perform the optimization (we do so if the expression is nonzero). If 17360 CONDITION is omitted (in other words, the string is empty) then the 17361 optimization is applied to every sequence of insns that matches the 17362 patterns. 17363 17364 The defined peephole optimizations are applied after register 17365 allocation is complete. Therefore, the peephole definition can check 17366 which operands have ended up in which kinds of registers, just by 17367 looking at the operands. 17368 17369 The way to refer to the operands in CONDITION is to write 17370 `operands[I]' for operand number I (as matched by `(match_operand I 17371 ...)'). Use the variable `insn' to refer to the last of the insns 17372 being matched; use `prev_active_insn' to find the preceding insns. 17373 17374 When optimizing computations with intermediate results, you can use 17375 CONDITION to match only when the intermediate results are not used 17376 elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where INSN 17377 is the insn in which you expect the value to be used for the last time 17378 (from the value of `insn', together with use of `prev_nonnote_insn'), 17379 and OP is the intermediate value (from `operands[I]'). 17380 17381 Applying the optimization means replacing the sequence of insns with 17382 one new insn. The TEMPLATE controls ultimate output of assembler code 17383 for this combined insn. It works exactly like the template of a 17384 `define_insn'. Operand numbers in this template are the same ones used 17385 in matching the original sequence of insns. 17386 17387 The result of a defined peephole optimizer does not need to match any 17388 of the insn patterns in the machine description; it does not even have 17389 an opportunity to match them. The peephole optimizer definition itself 17390 serves as the insn pattern to control how the insn is output. 17391 17392 Defined peephole optimizers are run as assembler code is being output, 17393 so the insns they produce are never combined or rearranged in any way. 17394 17395 Here is an example, taken from the 68000 machine description: 17396 17397 (define_peephole 17398 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) 17399 (set (match_operand:DF 0 "register_operand" "=f") 17400 (match_operand:DF 1 "register_operand" "ad"))] 17401 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" 17402 { 17403 rtx xoperands[2]; 17404 xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1); 17405 #ifdef MOTOROLA 17406 output_asm_insn ("move.l %1,(sp)", xoperands); 17407 output_asm_insn ("move.l %1,-(sp)", operands); 17408 return "fmove.d (sp)+,%0"; 17409 #else 17410 output_asm_insn ("movel %1,sp@", xoperands); 17411 output_asm_insn ("movel %1,sp@-", operands); 17412 return "fmoved sp@+,%0"; 17413 #endif 17414 }) 17415 17416 The effect of this optimization is to change 17417 17418 jbsr _foobar 17419 addql #4,sp 17420 movel d1,sp@- 17421 movel d0,sp@- 17422 fmoved sp@+,fp0 17423 17424 into 17425 17426 jbsr _foobar 17427 movel d1,sp@ 17428 movel d0,sp@- 17429 fmoved sp@+,fp0 17430 17431 INSN-PATTERN-1 and so on look _almost_ like the second operand of 17432 `define_insn'. There is one important difference: the second operand 17433 of `define_insn' consists of one or more RTX's enclosed in square 17434 brackets. Usually, there is only one: then the same action can be 17435 written as an element of a `define_peephole'. But when there are 17436 multiple actions in a `define_insn', they are implicitly enclosed in a 17437 `parallel'. Then you must explicitly write the `parallel', and the 17438 square brackets within it, in the `define_peephole'. Thus, if an insn 17439 pattern looks like this, 17440 17441 (define_insn "divmodsi4" 17442 [(set (match_operand:SI 0 "general_operand" "=d") 17443 (div:SI (match_operand:SI 1 "general_operand" "0") 17444 (match_operand:SI 2 "general_operand" "dmsK"))) 17445 (set (match_operand:SI 3 "general_operand" "=d") 17446 (mod:SI (match_dup 1) (match_dup 2)))] 17447 "TARGET_68020" 17448 "divsl%.l %2,%3:%0") 17449 17450 then the way to mention this insn in a peephole is as follows: 17451 17452 (define_peephole 17453 [... 17454 (parallel 17455 [(set (match_operand:SI 0 "general_operand" "=d") 17456 (div:SI (match_operand:SI 1 "general_operand" "0") 17457 (match_operand:SI 2 "general_operand" "dmsK"))) 17458 (set (match_operand:SI 3 "general_operand" "=d") 17459 (mod:SI (match_dup 1) (match_dup 2)))]) 17460 ...] 17461 ...) 17462 17463 17464 File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions 17465 17466 14.18.2 RTL to RTL Peephole Optimizers 17467 -------------------------------------- 17468 17469 The `define_peephole2' definition tells the compiler how to substitute 17470 one sequence of instructions for another sequence, what additional 17471 scratch registers may be needed and what their lifetimes must be. 17472 17473 (define_peephole2 17474 [INSN-PATTERN-1 17475 INSN-PATTERN-2 17476 ...] 17477 "CONDITION" 17478 [NEW-INSN-PATTERN-1 17479 NEW-INSN-PATTERN-2 17480 ...] 17481 "PREPARATION-STATEMENTS") 17482 17483 The definition is almost identical to `define_split' (*note Insn 17484 Splitting::) except that the pattern to match is not a single 17485 instruction, but a sequence of instructions. 17486 17487 It is possible to request additional scratch registers for use in the 17488 output template. If appropriate registers are not free, the pattern 17489 will simply not match. 17490 17491 Scratch registers are requested with a `match_scratch' pattern at the 17492 top level of the input pattern. The allocated register (initially) will 17493 be dead at the point requested within the original sequence. If the 17494 scratch is used at more than a single point, a `match_dup' pattern at 17495 the top level of the input pattern marks the last position in the input 17496 sequence at which the register must be available. 17497 17498 Here is an example from the IA-32 machine description: 17499 17500 (define_peephole2 17501 [(match_scratch:SI 2 "r") 17502 (parallel [(set (match_operand:SI 0 "register_operand" "") 17503 (match_operator:SI 3 "arith_or_logical_operator" 17504 [(match_dup 0) 17505 (match_operand:SI 1 "memory_operand" "")])) 17506 (clobber (reg:CC 17))])] 17507 "! optimize_size && ! TARGET_READ_MODIFY" 17508 [(set (match_dup 2) (match_dup 1)) 17509 (parallel [(set (match_dup 0) 17510 (match_op_dup 3 [(match_dup 0) (match_dup 2)])) 17511 (clobber (reg:CC 17))])] 17512 "") 17513 17514 This pattern tries to split a load from its use in the hopes that we'll 17515 be able to schedule around the memory load latency. It allocates a 17516 single `SImode' register of class `GENERAL_REGS' (`"r"') that needs to 17517 be live only at the point just before the arithmetic. 17518 17519 A real example requiring extended scratch lifetimes is harder to come 17520 by, so here's a silly made-up example: 17521 17522 (define_peephole2 17523 [(match_scratch:SI 4 "r") 17524 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) 17525 (set (match_operand:SI 2 "" "") (match_dup 1)) 17526 (match_dup 4) 17527 (set (match_operand:SI 3 "" "") (match_dup 1))] 17528 "/* determine 1 does not overlap 0 and 2 */" 17529 [(set (match_dup 4) (match_dup 1)) 17530 (set (match_dup 0) (match_dup 4)) 17531 (set (match_dup 2) (match_dup 4))] 17532 (set (match_dup 3) (match_dup 4))] 17533 "") 17534 17535 If we had not added the `(match_dup 4)' in the middle of the input 17536 sequence, it might have been the case that the register we chose at the 17537 beginning of the sequence is killed by the first or second `set'. 17538 17539 17540 File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc 17541 17542 14.19 Instruction Attributes 17543 ============================ 17544 17545 In addition to describing the instruction supported by the target 17546 machine, the `md' file also defines a group of "attributes" and a set of 17547 values for each. Every generated insn is assigned a value for each 17548 attribute. One possible attribute would be the effect that the insn 17549 has on the machine's condition code. This attribute can then be used 17550 by `NOTICE_UPDATE_CC' to track the condition codes. 17551 17552 * Menu: 17553 17554 * Defining Attributes:: Specifying attributes and their values. 17555 * Expressions:: Valid expressions for attribute values. 17556 * Tagging Insns:: Assigning attribute values to insns. 17557 * Attr Example:: An example of assigning attributes. 17558 * Insn Lengths:: Computing the length of insns. 17559 * Constant Attributes:: Defining attributes that are constant. 17560 * Delay Slots:: Defining delay slots required for a machine. 17561 * Processor pipeline description:: Specifying information for insn scheduling. 17562 17563 17564 File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes 17565 17566 14.19.1 Defining Attributes and their Values 17567 -------------------------------------------- 17568 17569 The `define_attr' expression is used to define each attribute required 17570 by the target machine. It looks like: 17571 17572 (define_attr NAME LIST-OF-VALUES DEFAULT) 17573 17574 NAME is a string specifying the name of the attribute being defined. 17575 17576 LIST-OF-VALUES is either a string that specifies a comma-separated 17577 list of values that can be assigned to the attribute, or a null string 17578 to indicate that the attribute takes numeric values. 17579 17580 DEFAULT is an attribute expression that gives the value of this 17581 attribute for insns that match patterns whose definition does not 17582 include an explicit value for this attribute. *Note Attr Example::, 17583 for more information on the handling of defaults. *Note Constant 17584 Attributes::, for information on attributes that do not depend on any 17585 particular insn. 17586 17587 For each defined attribute, a number of definitions are written to the 17588 `insn-attr.h' file. For cases where an explicit set of values is 17589 specified for an attribute, the following are defined: 17590 17591 * A `#define' is written for the symbol `HAVE_ATTR_NAME'. 17592 17593 * An enumerated class is defined for `attr_NAME' with elements of 17594 the form `UPPER-NAME_UPPER-VALUE' where the attribute name and 17595 value are first converted to uppercase. 17596 17597 * A function `get_attr_NAME' is defined that is passed an insn and 17598 returns the attribute value for that insn. 17599 17600 For example, if the following is present in the `md' file: 17601 17602 (define_attr "type" "branch,fp,load,store,arith" ...) 17603 17604 the following lines will be written to the file `insn-attr.h'. 17605 17606 #define HAVE_ATTR_type 17607 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 17608 TYPE_STORE, TYPE_ARITH}; 17609 extern enum attr_type get_attr_type (); 17610 17611 If the attribute takes numeric values, no `enum' type will be defined 17612 and the function to obtain the attribute's value will return `int'. 17613 17614 17615 File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes 17616 17617 14.19.2 Attribute Expressions 17618 ----------------------------- 17619 17620 RTL expressions used to define attributes use the codes described above 17621 plus a few specific to attribute definitions, to be discussed below. 17622 Attribute value expressions must have one of the following forms: 17623 17624 `(const_int I)' 17625 The integer I specifies the value of a numeric attribute. I must 17626 be non-negative. 17627 17628 The value of a numeric attribute can be specified either with a 17629 `const_int', or as an integer represented as a string in 17630 `const_string', `eq_attr' (see below), `attr', `symbol_ref', 17631 simple arithmetic expressions, and `set_attr' overrides on 17632 specific instructions (*note Tagging Insns::). 17633 17634 `(const_string VALUE)' 17635 The string VALUE specifies a constant attribute value. If VALUE 17636 is specified as `"*"', it means that the default value of the 17637 attribute is to be used for the insn containing this expression. 17638 `"*"' obviously cannot be used in the DEFAULT expression of a 17639 `define_attr'. 17640 17641 If the attribute whose value is being specified is numeric, VALUE 17642 must be a string containing a non-negative integer (normally 17643 `const_int' would be used in this case). Otherwise, it must 17644 contain one of the valid values for the attribute. 17645 17646 `(if_then_else TEST TRUE-VALUE FALSE-VALUE)' 17647 TEST specifies an attribute test, whose format is defined below. 17648 The value of this expression is TRUE-VALUE if TEST is true, 17649 otherwise it is FALSE-VALUE. 17650 17651 `(cond [TEST1 VALUE1 ...] DEFAULT)' 17652 The first operand of this expression is a vector containing an even 17653 number of expressions and consisting of pairs of TEST and VALUE 17654 expressions. The value of the `cond' expression is that of the 17655 VALUE corresponding to the first true TEST expression. If none of 17656 the TEST expressions are true, the value of the `cond' expression 17657 is that of the DEFAULT expression. 17658 17659 TEST expressions can have one of the following forms: 17660 17661 `(const_int I)' 17662 This test is true if I is nonzero and false otherwise. 17663 17664 `(not TEST)' 17665 `(ior TEST1 TEST2)' 17666 `(and TEST1 TEST2)' 17667 These tests are true if the indicated logical function is true. 17668 17669 `(match_operand:M N PRED CONSTRAINTS)' 17670 This test is true if operand N of the insn whose attribute value 17671 is being determined has mode M (this part of the test is ignored 17672 if M is `VOIDmode') and the function specified by the string PRED 17673 returns a nonzero value when passed operand N and mode M (this 17674 part of the test is ignored if PRED is the null string). 17675 17676 The CONSTRAINTS operand is ignored and should be the null string. 17677 17678 `(le ARITH1 ARITH2)' 17679 `(leu ARITH1 ARITH2)' 17680 `(lt ARITH1 ARITH2)' 17681 `(ltu ARITH1 ARITH2)' 17682 `(gt ARITH1 ARITH2)' 17683 `(gtu ARITH1 ARITH2)' 17684 `(ge ARITH1 ARITH2)' 17685 `(geu ARITH1 ARITH2)' 17686 `(ne ARITH1 ARITH2)' 17687 `(eq ARITH1 ARITH2)' 17688 These tests are true if the indicated comparison of the two 17689 arithmetic expressions is true. Arithmetic expressions are formed 17690 with `plus', `minus', `mult', `div', `mod', `abs', `neg', `and', 17691 `ior', `xor', `not', `ashift', `lshiftrt', and `ashiftrt' 17692 expressions. 17693 17694 `const_int' and `symbol_ref' are always valid terms (*note Insn 17695 Lengths::,for additional forms). `symbol_ref' is a string 17696 denoting a C expression that yields an `int' when evaluated by the 17697 `get_attr_...' routine. It should normally be a global variable. 17698 17699 `(eq_attr NAME VALUE)' 17700 NAME is a string specifying the name of an attribute. 17701 17702 VALUE is a string that is either a valid value for attribute NAME, 17703 a comma-separated list of values, or `!' followed by a value or 17704 list. If VALUE does not begin with a `!', this test is true if 17705 the value of the NAME attribute of the current insn is in the list 17706 specified by VALUE. If VALUE begins with a `!', this test is true 17707 if the attribute's value is _not_ in the specified list. 17708 17709 For example, 17710 17711 (eq_attr "type" "load,store") 17712 17713 is equivalent to 17714 17715 (ior (eq_attr "type" "load") (eq_attr "type" "store")) 17716 17717 If NAME specifies an attribute of `alternative', it refers to the 17718 value of the compiler variable `which_alternative' (*note Output 17719 Statement::) and the values must be small integers. For example, 17720 17721 (eq_attr "alternative" "2,3") 17722 17723 is equivalent to 17724 17725 (ior (eq (symbol_ref "which_alternative") (const_int 2)) 17726 (eq (symbol_ref "which_alternative") (const_int 3))) 17727 17728 Note that, for most attributes, an `eq_attr' test is simplified in 17729 cases where the value of the attribute being tested is known for 17730 all insns matching a particular pattern. This is by far the most 17731 common case. 17732 17733 `(attr_flag NAME)' 17734 The value of an `attr_flag' expression is true if the flag 17735 specified by NAME is true for the `insn' currently being scheduled. 17736 17737 NAME is a string specifying one of a fixed set of flags to test. 17738 Test the flags `forward' and `backward' to determine the direction 17739 of a conditional branch. Test the flags `very_likely', `likely', 17740 `very_unlikely', and `unlikely' to determine if a conditional 17741 branch is expected to be taken. 17742 17743 If the `very_likely' flag is true, then the `likely' flag is also 17744 true. Likewise for the `very_unlikely' and `unlikely' flags. 17745 17746 This example describes a conditional branch delay slot which can 17747 be nullified for forward branches that are taken (annul-true) or 17748 for backward branches which are not taken (annul-false). 17749 17750 (define_delay (eq_attr "type" "cbranch") 17751 [(eq_attr "in_branch_delay" "true") 17752 (and (eq_attr "in_branch_delay" "true") 17753 (attr_flag "forward")) 17754 (and (eq_attr "in_branch_delay" "true") 17755 (attr_flag "backward"))]) 17756 17757 The `forward' and `backward' flags are false if the current `insn' 17758 being scheduled is not a conditional branch. 17759 17760 The `very_likely' and `likely' flags are true if the `insn' being 17761 scheduled is not a conditional branch. The `very_unlikely' and 17762 `unlikely' flags are false if the `insn' being scheduled is not a 17763 conditional branch. 17764 17765 `attr_flag' is only used during delay slot scheduling and has no 17766 meaning to other passes of the compiler. 17767 17768 `(attr NAME)' 17769 The value of another attribute is returned. This is most useful 17770 for numeric attributes, as `eq_attr' and `attr_flag' produce more 17771 efficient code for non-numeric attributes. 17772 17773 17774 File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes 17775 17776 14.19.3 Assigning Attribute Values to Insns 17777 ------------------------------------------- 17778 17779 The value assigned to an attribute of an insn is primarily determined by 17780 which pattern is matched by that insn (or which `define_peephole' 17781 generated it). Every `define_insn' and `define_peephole' can have an 17782 optional last argument to specify the values of attributes for matching 17783 insns. The value of any attribute not specified in a particular insn 17784 is set to the default value for that attribute, as specified in its 17785 `define_attr'. Extensive use of default values for attributes permits 17786 the specification of the values for only one or two attributes in the 17787 definition of most insn patterns, as seen in the example in the next 17788 section. 17789 17790 The optional last argument of `define_insn' and `define_peephole' is a 17791 vector of expressions, each of which defines the value for a single 17792 attribute. The most general way of assigning an attribute's value is 17793 to use a `set' expression whose first operand is an `attr' expression 17794 giving the name of the attribute being set. The second operand of the 17795 `set' is an attribute expression (*note Expressions::) giving the value 17796 of the attribute. 17797 17798 When the attribute value depends on the `alternative' attribute (i.e., 17799 which is the applicable alternative in the constraint of the insn), the 17800 `set_attr_alternative' expression can be used. It allows the 17801 specification of a vector of attribute expressions, one for each 17802 alternative. 17803 17804 When the generality of arbitrary attribute expressions is not required, 17805 the simpler `set_attr' expression can be used, which allows specifying 17806 a string giving either a single attribute value or a list of attribute 17807 values, one for each alternative. 17808 17809 The form of each of the above specifications is shown below. In each 17810 case, NAME is a string specifying the attribute to be set. 17811 17812 `(set_attr NAME VALUE-STRING)' 17813 VALUE-STRING is either a string giving the desired attribute value, 17814 or a string containing a comma-separated list giving the values for 17815 succeeding alternatives. The number of elements must match the 17816 number of alternatives in the constraint of the insn pattern. 17817 17818 Note that it may be useful to specify `*' for some alternative, in 17819 which case the attribute will assume its default value for insns 17820 matching that alternative. 17821 17822 `(set_attr_alternative NAME [VALUE1 VALUE2 ...])' 17823 Depending on the alternative of the insn, the value will be one of 17824 the specified values. This is a shorthand for using a `cond' with 17825 tests on the `alternative' attribute. 17826 17827 `(set (attr NAME) VALUE)' 17828 The first operand of this `set' must be the special RTL expression 17829 `attr', whose sole operand is a string giving the name of the 17830 attribute being set. VALUE is the value of the attribute. 17831 17832 The following shows three different ways of representing the same 17833 attribute value specification: 17834 17835 (set_attr "type" "load,store,arith") 17836 17837 (set_attr_alternative "type" 17838 [(const_string "load") (const_string "store") 17839 (const_string "arith")]) 17840 17841 (set (attr "type") 17842 (cond [(eq_attr "alternative" "1") (const_string "load") 17843 (eq_attr "alternative" "2") (const_string "store")] 17844 (const_string "arith"))) 17845 17846 The `define_asm_attributes' expression provides a mechanism to specify 17847 the attributes assigned to insns produced from an `asm' statement. It 17848 has the form: 17849 17850 (define_asm_attributes [ATTR-SETS]) 17851 17852 where ATTR-SETS is specified the same as for both the `define_insn' and 17853 the `define_peephole' expressions. 17854 17855 These values will typically be the "worst case" attribute values. For 17856 example, they might indicate that the condition code will be clobbered. 17857 17858 A specification for a `length' attribute is handled specially. The 17859 way to compute the length of an `asm' insn is to multiply the length 17860 specified in the expression `define_asm_attributes' by the number of 17861 machine instructions specified in the `asm' statement, determined by 17862 counting the number of semicolons and newlines in the string. 17863 Therefore, the value of the `length' attribute specified in a 17864 `define_asm_attributes' should be the maximum possible length of a 17865 single machine instruction. 17866 17867 17868 File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes 17869 17870 14.19.4 Example of Attribute Specifications 17871 ------------------------------------------- 17872 17873 The judicious use of defaulting is important in the efficient use of 17874 insn attributes. Typically, insns are divided into "types" and an 17875 attribute, customarily called `type', is used to represent this value. 17876 This attribute is normally used only to define the default value for 17877 other attributes. An example will clarify this usage. 17878 17879 Assume we have a RISC machine with a condition code and in which only 17880 full-word operations are performed in registers. Let us assume that we 17881 can divide all insns into loads, stores, (integer) arithmetic 17882 operations, floating point operations, and branches. 17883 17884 Here we will concern ourselves with determining the effect of an insn 17885 on the condition code and will limit ourselves to the following possible 17886 effects: The condition code can be set unpredictably (clobbered), not 17887 be changed, be set to agree with the results of the operation, or only 17888 changed if the item previously set into the condition code has been 17889 modified. 17890 17891 Here is part of a sample `md' file for such a machine: 17892 17893 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 17894 17895 (define_attr "cc" "clobber,unchanged,set,change0" 17896 (cond [(eq_attr "type" "load") 17897 (const_string "change0") 17898 (eq_attr "type" "store,branch") 17899 (const_string "unchanged") 17900 (eq_attr "type" "arith") 17901 (if_then_else (match_operand:SI 0 "" "") 17902 (const_string "set") 17903 (const_string "clobber"))] 17904 (const_string "clobber"))) 17905 17906 (define_insn "" 17907 [(set (match_operand:SI 0 "general_operand" "=r,r,m") 17908 (match_operand:SI 1 "general_operand" "r,m,r"))] 17909 "" 17910 "@ 17911 move %0,%1 17912 load %0,%1 17913 store %0,%1" 17914 [(set_attr "type" "arith,load,store")]) 17915 17916 Note that we assume in the above example that arithmetic operations 17917 performed on quantities smaller than a machine word clobber the 17918 condition code since they will set the condition code to a value 17919 corresponding to the full-word result. 17920 17921 17922 File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes 17923 17924 14.19.5 Computing the Length of an Insn 17925 --------------------------------------- 17926 17927 For many machines, multiple types of branch instructions are provided, 17928 each for different length branch displacements. In most cases, the 17929 assembler will choose the correct instruction to use. However, when 17930 the assembler cannot do so, GCC can when a special attribute, the 17931 `length' attribute, is defined. This attribute must be defined to have 17932 numeric values by specifying a null string in its `define_attr'. 17933 17934 In the case of the `length' attribute, two additional forms of 17935 arithmetic terms are allowed in test expressions: 17936 17937 `(match_dup N)' 17938 This refers to the address of operand N of the current insn, which 17939 must be a `label_ref'. 17940 17941 `(pc)' 17942 This refers to the address of the _current_ insn. It might have 17943 been more consistent with other usage to make this the address of 17944 the _next_ insn but this would be confusing because the length of 17945 the current insn is to be computed. 17946 17947 For normal insns, the length will be determined by value of the 17948 `length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn 17949 patterns, the length is computed as the number of vectors multiplied by 17950 the size of each vector. 17951 17952 Lengths are measured in addressable storage units (bytes). 17953 17954 The following macros can be used to refine the length computation: 17955 17956 `ADJUST_INSN_LENGTH (INSN, LENGTH)' 17957 If defined, modifies the length assigned to instruction INSN as a 17958 function of the context in which it is used. LENGTH is an lvalue 17959 that contains the initially computed length of the insn and should 17960 be updated with the correct length of the insn. 17961 17962 This macro will normally not be required. A case in which it is 17963 required is the ROMP. On this machine, the size of an `addr_vec' 17964 insn must be increased by two to compensate for the fact that 17965 alignment may be required. 17966 17967 The routine that returns `get_attr_length' (the value of the `length' 17968 attribute) can be used by the output routine to determine the form of 17969 the branch instruction to be written, as the example below illustrates. 17970 17971 As an example of the specification of variable-length branches, 17972 consider the IBM 360. If we adopt the convention that a register will 17973 be set to the starting address of a function, we can jump to labels 17974 within 4k of the start using a four-byte instruction. Otherwise, we 17975 need a six-byte sequence to load the address from memory and then 17976 branch to it. 17977 17978 On such a machine, a pattern for a branch instruction might be 17979 specified as follows: 17980 17981 (define_insn "jump" 17982 [(set (pc) 17983 (label_ref (match_operand 0 "" "")))] 17984 "" 17985 { 17986 return (get_attr_length (insn) == 4 17987 ? "b %l0" : "l r15,=a(%l0); br r15"); 17988 } 17989 [(set (attr "length") 17990 (if_then_else (lt (match_dup 0) (const_int 4096)) 17991 (const_int 4) 17992 (const_int 6)))]) 17993 17994 17995 File: gccint.info, Node: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes 17996 17997 14.19.6 Constant Attributes 17998 --------------------------- 17999 18000 A special form of `define_attr', where the expression for the default 18001 value is a `const' expression, indicates an attribute that is constant 18002 for a given run of the compiler. Constant attributes may be used to 18003 specify which variety of processor is used. For example, 18004 18005 (define_attr "cpu" "m88100,m88110,m88000" 18006 (const 18007 (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 18008 (symbol_ref "TARGET_88110") (const_string "m88110")] 18009 (const_string "m88000")))) 18010 18011 (define_attr "memory" "fast,slow" 18012 (const 18013 (if_then_else (symbol_ref "TARGET_FAST_MEM") 18014 (const_string "fast") 18015 (const_string "slow")))) 18016 18017 The routine generated for constant attributes has no parameters as it 18018 does not depend on any particular insn. RTL expressions used to define 18019 the value of a constant attribute may use the `symbol_ref' form, but 18020 may not use either the `match_operand' form or `eq_attr' forms 18021 involving insn attributes. 18022 18023 18024 File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Constant Attributes, Up: Insn Attributes 18025 18026 14.19.7 Delay Slot Scheduling 18027 ----------------------------- 18028 18029 The insn attribute mechanism can be used to specify the requirements for 18030 delay slots, if any, on a target machine. An instruction is said to 18031 require a "delay slot" if some instructions that are physically after 18032 the instruction are executed as if they were located before it. 18033 Classic examples are branch and call instructions, which often execute 18034 the following instruction before the branch or call is performed. 18035 18036 On some machines, conditional branch instructions can optionally 18037 "annul" instructions in the delay slot. This means that the 18038 instruction will not be executed for certain branch outcomes. Both 18039 instructions that annul if the branch is true and instructions that 18040 annul if the branch is false are supported. 18041 18042 Delay slot scheduling differs from instruction scheduling in that 18043 determining whether an instruction needs a delay slot is dependent only 18044 on the type of instruction being generated, not on data flow between the 18045 instructions. See the next section for a discussion of data-dependent 18046 instruction scheduling. 18047 18048 The requirement of an insn needing one or more delay slots is indicated 18049 via the `define_delay' expression. It has the following form: 18050 18051 (define_delay TEST 18052 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 18053 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 18054 ...]) 18055 18056 TEST is an attribute test that indicates whether this `define_delay' 18057 applies to a particular insn. If so, the number of required delay 18058 slots is determined by the length of the vector specified as the second 18059 argument. An insn placed in delay slot N must satisfy attribute test 18060 DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns 18061 may be annulled if the branch is true. Similarly, ANNUL-FALSE-N 18062 specifies which insns in the delay slot may be annulled if the branch 18063 is false. If annulling is not supported for that delay slot, `(nil)' 18064 should be coded. 18065 18066 For example, in the common case where branch and call insns require a 18067 single delay slot, which may contain any insn other than a branch or 18068 call, the following would be placed in the `md' file: 18069 18070 (define_delay (eq_attr "type" "branch,call") 18071 [(eq_attr "type" "!branch,call") (nil) (nil)]) 18072 18073 Multiple `define_delay' expressions may be specified. In this case, 18074 each such expression specifies different delay slot requirements and 18075 there must be no insn for which tests in two `define_delay' expressions 18076 are both true. 18077 18078 For example, if we have a machine that requires one delay slot for 18079 branches but two for calls, no delay slot can contain a branch or call 18080 insn, and any valid insn in the delay slot for the branch can be 18081 annulled if the branch is true, we might represent this as follows: 18082 18083 (define_delay (eq_attr "type" "branch") 18084 [(eq_attr "type" "!branch,call") 18085 (eq_attr "type" "!branch,call") 18086 (nil)]) 18087 18088 (define_delay (eq_attr "type" "call") 18089 [(eq_attr "type" "!branch,call") (nil) (nil) 18090 (eq_attr "type" "!branch,call") (nil) (nil)]) 18091 18092 18093 File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes 18094 18095 14.19.8 Specifying processor pipeline description 18096 ------------------------------------------------- 18097 18098 To achieve better performance, most modern processors (super-pipelined, 18099 superscalar RISC, and VLIW processors) have many "functional units" on 18100 which several instructions can be executed simultaneously. An 18101 instruction starts execution if its issue conditions are satisfied. If 18102 not, the instruction is stalled until its conditions are satisfied. 18103 Such "interlock (pipeline) delay" causes interruption of the fetching 18104 of successor instructions (or demands nop instructions, e.g. for some 18105 MIPS processors). 18106 18107 There are two major kinds of interlock delays in modern processors. 18108 The first one is a data dependence delay determining "instruction 18109 latency time". The instruction execution is not started until all 18110 source data have been evaluated by prior instructions (there are more 18111 complex cases when the instruction execution starts even when the data 18112 are not available but will be ready in given time after the instruction 18113 execution start). Taking the data dependence delays into account is 18114 simple. The data dependence (true, output, and anti-dependence) delay 18115 between two instructions is given by a constant. In most cases this 18116 approach is adequate. The second kind of interlock delays is a 18117 reservation delay. The reservation delay means that two instructions 18118 under execution will be in need of shared processors resources, i.e. 18119 buses, internal registers, and/or functional units, which are reserved 18120 for some time. Taking this kind of delay into account is complex 18121 especially for modern RISC processors. 18122 18123 The task of exploiting more processor parallelism is solved by an 18124 instruction scheduler. For a better solution to this problem, the 18125 instruction scheduler has to have an adequate description of the 18126 processor parallelism (or "pipeline description"). GCC machine 18127 descriptions describe processor parallelism and functional unit 18128 reservations for groups of instructions with the aid of "regular 18129 expressions". 18130 18131 The GCC instruction scheduler uses a "pipeline hazard recognizer" to 18132 figure out the possibility of the instruction issue by the processor on 18133 a given simulated processor cycle. The pipeline hazard recognizer is 18134 automatically generated from the processor pipeline description. The 18135 pipeline hazard recognizer generated from the machine description is 18136 based on a deterministic finite state automaton (DFA): the instruction 18137 issue is possible if there is a transition from one automaton state to 18138 another one. This algorithm is very fast, and furthermore, its speed 18139 is not dependent on processor complexity(1). 18140 18141 The rest of this section describes the directives that constitute an 18142 automaton-based processor pipeline description. The order of these 18143 constructions within the machine description file is not important. 18144 18145 The following optional construction describes names of automata 18146 generated and used for the pipeline hazards recognition. Sometimes the 18147 generated finite state automaton used by the pipeline hazard recognizer 18148 is large. If we use more than one automaton and bind functional units 18149 to the automata, the total size of the automata is usually less than 18150 the size of the single automaton. If there is no one such 18151 construction, only one finite state automaton is generated. 18152 18153 (define_automaton AUTOMATA-NAMES) 18154 18155 AUTOMATA-NAMES is a string giving names of the automata. The names 18156 are separated by commas. All the automata should have unique names. 18157 The automaton name is used in the constructions `define_cpu_unit' and 18158 `define_query_cpu_unit'. 18159 18160 Each processor functional unit used in the description of instruction 18161 reservations should be described by the following construction. 18162 18163 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 18164 18165 UNIT-NAMES is a string giving the names of the functional units 18166 separated by commas. Don't use name `nothing', it is reserved for 18167 other goals. 18168 18169 AUTOMATON-NAME is a string giving the name of the automaton with which 18170 the unit is bound. The automaton should be described in construction 18171 `define_automaton'. You should give "automaton-name", if there is a 18172 defined automaton. 18173 18174 The assignment of units to automata are constrained by the uses of the 18175 units in insn reservations. The most important constraint is: if a 18176 unit reservation is present on a particular cycle of an alternative for 18177 an insn reservation, then some unit from the same automaton must be 18178 present on the same cycle for the other alternatives of the insn 18179 reservation. The rest of the constraints are mentioned in the 18180 description of the subsequent constructions. 18181 18182 The following construction describes CPU functional units analogously 18183 to `define_cpu_unit'. The reservation of such units can be queried for 18184 an automaton state. The instruction scheduler never queries 18185 reservation of functional units for given automaton state. So as a 18186 rule, you don't need this construction. This construction could be 18187 used for future code generation goals (e.g. to generate VLIW insn 18188 templates). 18189 18190 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 18191 18192 UNIT-NAMES is a string giving names of the functional units separated 18193 by commas. 18194 18195 AUTOMATON-NAME is a string giving the name of the automaton with which 18196 the unit is bound. 18197 18198 The following construction is the major one to describe pipeline 18199 characteristics of an instruction. 18200 18201 (define_insn_reservation INSN-NAME DEFAULT_LATENCY 18202 CONDITION REGEXP) 18203 18204 DEFAULT_LATENCY is a number giving latency time of the instruction. 18205 There is an important difference between the old description and the 18206 automaton based pipeline description. The latency time is used for all 18207 dependencies when we use the old description. In the automaton based 18208 pipeline description, the given latency time is only used for true 18209 dependencies. The cost of anti-dependencies is always zero and the 18210 cost of output dependencies is the difference between latency times of 18211 the producing and consuming insns (if the difference is negative, the 18212 cost is considered to be zero). You can always change the default 18213 costs for any description by using the target hook 18214 `TARGET_SCHED_ADJUST_COST' (*note Scheduling::). 18215 18216 INSN-NAME is a string giving the internal name of the insn. The 18217 internal names are used in constructions `define_bypass' and in the 18218 automaton description file generated for debugging. The internal name 18219 has nothing in common with the names in `define_insn'. It is a good 18220 practice to use insn classes described in the processor manual. 18221 18222 CONDITION defines what RTL insns are described by this construction. 18223 You should remember that you will be in trouble if CONDITION for two or 18224 more different `define_insn_reservation' constructions is TRUE for an 18225 insn. In this case what reservation will be used for the insn is not 18226 defined. Such cases are not checked during generation of the pipeline 18227 hazards recognizer because in general recognizing that two conditions 18228 may have the same value is quite difficult (especially if the conditions 18229 contain `symbol_ref'). It is also not checked during the pipeline 18230 hazard recognizer work because it would slow down the recognizer 18231 considerably. 18232 18233 REGEXP is a string describing the reservation of the cpu's functional 18234 units by the instruction. The reservations are described by a regular 18235 expression according to the following syntax: 18236 18237 regexp = regexp "," oneof 18238 | oneof 18239 18240 oneof = oneof "|" allof 18241 | allof 18242 18243 allof = allof "+" repeat 18244 | repeat 18245 18246 repeat = element "*" number 18247 | element 18248 18249 element = cpu_function_unit_name 18250 | reservation_name 18251 | result_name 18252 | "nothing" 18253 | "(" regexp ")" 18254 18255 * `,' is used for describing the start of the next cycle in the 18256 reservation. 18257 18258 * `|' is used for describing a reservation described by the first 18259 regular expression *or* a reservation described by the second 18260 regular expression *or* etc. 18261 18262 * `+' is used for describing a reservation described by the first 18263 regular expression *and* a reservation described by the second 18264 regular expression *and* etc. 18265 18266 * `*' is used for convenience and simply means a sequence in which 18267 the regular expression are repeated NUMBER times with cycle 18268 advancing (see `,'). 18269 18270 * `cpu_function_unit_name' denotes reservation of the named 18271 functional unit. 18272 18273 * `reservation_name' -- see description of construction 18274 `define_reservation'. 18275 18276 * `nothing' denotes no unit reservations. 18277 18278 Sometimes unit reservations for different insns contain common parts. 18279 In such case, you can simplify the pipeline description by describing 18280 the common part by the following construction 18281 18282 (define_reservation RESERVATION-NAME REGEXP) 18283 18284 RESERVATION-NAME is a string giving name of REGEXP. Functional unit 18285 names and reservation names are in the same name space. So the 18286 reservation names should be different from the functional unit names 18287 and can not be the reserved name `nothing'. 18288 18289 The following construction is used to describe exceptions in the 18290 latency time for given instruction pair. This is so called bypasses. 18291 18292 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES 18293 [GUARD]) 18294 18295 NUMBER defines when the result generated by the instructions given in 18296 string OUT_INSN_NAMES will be ready for the instructions given in 18297 string IN_INSN_NAMES. The instructions in the string are separated by 18298 commas. 18299 18300 GUARD is an optional string giving the name of a C function which 18301 defines an additional guard for the bypass. The function will get the 18302 two insns as parameters. If the function returns zero the bypass will 18303 be ignored for this case. The additional guard is necessary to 18304 recognize complicated bypasses, e.g. when the consumer is only an 18305 address of insn `store' (not a stored value). 18306 18307 The following five constructions are usually used to describe VLIW 18308 processors, or more precisely, to describe a placement of small 18309 instructions into VLIW instruction slots. They can be used for RISC 18310 processors, too. 18311 18312 (exclusion_set UNIT-NAMES UNIT-NAMES) 18313 (presence_set UNIT-NAMES PATTERNS) 18314 (final_presence_set UNIT-NAMES PATTERNS) 18315 (absence_set UNIT-NAMES PATTERNS) 18316 (final_absence_set UNIT-NAMES PATTERNS) 18317 18318 UNIT-NAMES is a string giving names of functional units separated by 18319 commas. 18320 18321 PATTERNS is a string giving patterns of functional units separated by 18322 comma. Currently pattern is one unit or units separated by 18323 white-spaces. 18324 18325 The first construction (`exclusion_set') means that each functional 18326 unit in the first string can not be reserved simultaneously with a unit 18327 whose name is in the second string and vice versa. For example, the 18328 construction is useful for describing processors (e.g. some SPARC 18329 processors) with a fully pipelined floating point functional unit which 18330 can execute simultaneously only single floating point insns or only 18331 double floating point insns. 18332 18333 The second construction (`presence_set') means that each functional 18334 unit in the first string can not be reserved unless at least one of 18335 pattern of units whose names are in the second string is reserved. 18336 This is an asymmetric relation. For example, it is useful for 18337 description that VLIW `slot1' is reserved after `slot0' reservation. 18338 We could describe it by the following construction 18339 18340 (presence_set "slot1" "slot0") 18341 18342 Or `slot1' is reserved only after `slot0' and unit `b0' reservation. 18343 In this case we could write 18344 18345 (presence_set "slot1" "slot0 b0") 18346 18347 The third construction (`final_presence_set') is analogous to 18348 `presence_set'. The difference between them is when checking is done. 18349 When an instruction is issued in given automaton state reflecting all 18350 current and planned unit reservations, the automaton state is changed. 18351 The first state is a source state, the second one is a result state. 18352 Checking for `presence_set' is done on the source state reservation, 18353 checking for `final_presence_set' is done on the result reservation. 18354 This construction is useful to describe a reservation which is actually 18355 two subsequent reservations. For example, if we use 18356 18357 (presence_set "slot1" "slot0") 18358 18359 the following insn will be never issued (because `slot1' requires 18360 `slot0' which is absent in the source state). 18361 18362 (define_reservation "insn_and_nop" "slot0 + slot1") 18363 18364 but it can be issued if we use analogous `final_presence_set'. 18365 18366 The forth construction (`absence_set') means that each functional unit 18367 in the first string can be reserved only if each pattern of units whose 18368 names are in the second string is not reserved. This is an asymmetric 18369 relation (actually `exclusion_set' is analogous to this one but it is 18370 symmetric). For example it might be useful in a VLIW description to 18371 say that `slot0' cannot be reserved after either `slot1' or `slot2' 18372 have been reserved. This can be described as: 18373 18374 (absence_set "slot0" "slot1, slot2") 18375 18376 Or `slot2' can not be reserved if `slot0' and unit `b0' are reserved 18377 or `slot1' and unit `b1' are reserved. In this case we could write 18378 18379 (absence_set "slot2" "slot0 b0, slot1 b1") 18380 18381 All functional units mentioned in a set should belong to the same 18382 automaton. 18383 18384 The last construction (`final_absence_set') is analogous to 18385 `absence_set' but checking is done on the result (state) reservation. 18386 See comments for `final_presence_set'. 18387 18388 You can control the generator of the pipeline hazard recognizer with 18389 the following construction. 18390 18391 (automata_option OPTIONS) 18392 18393 OPTIONS is a string giving options which affect the generated code. 18394 Currently there are the following options: 18395 18396 * "no-minimization" makes no minimization of the automaton. This is 18397 only worth to do when we are debugging the description and need to 18398 look more accurately at reservations of states. 18399 18400 * "time" means printing additional time statistics about generation 18401 of automata. 18402 18403 * "v" means a generation of the file describing the result automata. 18404 The file has suffix `.dfa' and can be used for the description 18405 verification and debugging. 18406 18407 * "w" means a generation of warning instead of error for 18408 non-critical errors. 18409 18410 * "ndfa" makes nondeterministic finite state automata. This affects 18411 the treatment of operator `|' in the regular expressions. The 18412 usual treatment of the operator is to try the first alternative 18413 and, if the reservation is not possible, the second alternative. 18414 The nondeterministic treatment means trying all alternatives, some 18415 of them may be rejected by reservations in the subsequent insns. 18416 18417 * "progress" means output of a progress bar showing how many states 18418 were generated so far for automaton being processed. This is 18419 useful during debugging a DFA description. If you see too many 18420 generated states, you could interrupt the generator of the pipeline 18421 hazard recognizer and try to figure out a reason for generation of 18422 the huge automaton. 18423 18424 As an example, consider a superscalar RISC machine which can issue 18425 three insns (two integer insns and one floating point insn) on the 18426 cycle but can finish only two insns. To describe this, we define the 18427 following functional units. 18428 18429 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") 18430 (define_cpu_unit "port0, port1") 18431 18432 All simple integer insns can be executed in any integer pipeline and 18433 their result is ready in two cycles. The simple integer insns are 18434 issued into the first pipeline unless it is reserved, otherwise they 18435 are issued into the second pipeline. Integer division and 18436 multiplication insns can be executed only in the second integer 18437 pipeline and their results are ready correspondingly in 8 and 4 cycles. 18438 The integer division is not pipelined, i.e. the subsequent integer 18439 division insn can not be issued until the current division insn 18440 finished. Floating point insns are fully pipelined and their results 18441 are ready in 3 cycles. Where the result of a floating point insn is 18442 used by an integer insn, an additional delay of one cycle is incurred. 18443 To describe all of this we could specify 18444 18445 (define_cpu_unit "div") 18446 18447 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 18448 "(i0_pipeline | i1_pipeline), (port0 | port1)") 18449 18450 (define_insn_reservation "mult" 4 (eq_attr "type" "mult") 18451 "i1_pipeline, nothing*2, (port0 | port1)") 18452 18453 (define_insn_reservation "div" 8 (eq_attr "type" "div") 18454 "i1_pipeline, div*7, div + (port0 | port1)") 18455 18456 (define_insn_reservation "float" 3 (eq_attr "type" "float") 18457 "f_pipeline, nothing, (port0 | port1)) 18458 18459 (define_bypass 4 "float" "simple,mult,div") 18460 18461 To simplify the description we could describe the following reservation 18462 18463 (define_reservation "finish" "port0|port1") 18464 18465 and use it in all `define_insn_reservation' as in the following 18466 construction 18467 18468 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 18469 "(i0_pipeline | i1_pipeline), finish") 18470 18471 ---------- Footnotes ---------- 18472 18473 (1) However, the size of the automaton depends on processor 18474 complexity. To limit this effect, machine descriptions can split 18475 orthogonal parts of the machine description among several automata: 18476 but then, since each of these must be stepped independently, this 18477 does cause a small decrease in the algorithm's performance. 18478 18479 18480 File: gccint.info, Node: Conditional Execution, Next: Constant Definitions, Prev: Insn Attributes, Up: Machine Desc 18481 18482 14.20 Conditional Execution 18483 =========================== 18484 18485 A number of architectures provide for some form of conditional 18486 execution, or predication. The hallmark of this feature is the ability 18487 to nullify most of the instructions in the instruction set. When the 18488 instruction set is large and not entirely symmetric, it can be quite 18489 tedious to describe these forms directly in the `.md' file. An 18490 alternative is the `define_cond_exec' template. 18491 18492 (define_cond_exec 18493 [PREDICATE-PATTERN] 18494 "CONDITION" 18495 "OUTPUT-TEMPLATE") 18496 18497 PREDICATE-PATTERN is the condition that must be true for the insn to 18498 be executed at runtime and should match a relational operator. One can 18499 use `match_operator' to match several relational operators at once. 18500 Any `match_operand' operands must have no more than one alternative. 18501 18502 CONDITION is a C expression that must be true for the generated 18503 pattern to match. 18504 18505 OUTPUT-TEMPLATE is a string similar to the `define_insn' output 18506 template (*note Output Template::), except that the `*' and `@' special 18507 cases do not apply. This is only useful if the assembly text for the 18508 predicate is a simple prefix to the main insn. In order to handle the 18509 general case, there is a global variable `current_insn_predicate' that 18510 will contain the entire predicate if the current insn is predicated, 18511 and will otherwise be `NULL'. 18512 18513 When `define_cond_exec' is used, an implicit reference to the 18514 `predicable' instruction attribute is made. *Note Insn Attributes::. 18515 This attribute must be boolean (i.e. have exactly two elements in its 18516 LIST-OF-VALUES). Further, it must not be used with complex 18517 expressions. That is, the default and all uses in the insns must be a 18518 simple constant, not dependent on the alternative or anything else. 18519 18520 For each `define_insn' for which the `predicable' attribute is true, a 18521 new `define_insn' pattern will be generated that matches a predicated 18522 version of the instruction. For example, 18523 18524 (define_insn "addsi" 18525 [(set (match_operand:SI 0 "register_operand" "r") 18526 (plus:SI (match_operand:SI 1 "register_operand" "r") 18527 (match_operand:SI 2 "register_operand" "r")))] 18528 "TEST1" 18529 "add %2,%1,%0") 18530 18531 (define_cond_exec 18532 [(ne (match_operand:CC 0 "register_operand" "c") 18533 (const_int 0))] 18534 "TEST2" 18535 "(%0)") 18536 18537 generates a new pattern 18538 18539 (define_insn "" 18540 [(cond_exec 18541 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0)) 18542 (set (match_operand:SI 0 "register_operand" "r") 18543 (plus:SI (match_operand:SI 1 "register_operand" "r") 18544 (match_operand:SI 2 "register_operand" "r"))))] 18545 "(TEST2) && (TEST1)" 18546 "(%3) add %2,%1,%0") 18547 18548 18549 File: gccint.info, Node: Constant Definitions, Next: Macros, Prev: Conditional Execution, Up: Machine Desc 18550 18551 14.21 Constant Definitions 18552 ========================== 18553 18554 Using literal constants inside instruction patterns reduces legibility 18555 and can be a maintenance problem. 18556 18557 To overcome this problem, you may use the `define_constants' 18558 expression. It contains a vector of name-value pairs. From that point 18559 on, wherever any of the names appears in the MD file, it is as if the 18560 corresponding value had been written instead. You may use 18561 `define_constants' multiple times; each appearance adds more constants 18562 to the table. It is an error to redefine a constant with a different 18563 value. 18564 18565 To come back to the a29k load multiple example, instead of 18566 18567 (define_insn "" 18568 [(match_parallel 0 "load_multiple_operation" 18569 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 18570 (match_operand:SI 2 "memory_operand" "m")) 18571 (use (reg:SI 179)) 18572 (clobber (reg:SI 179))])] 18573 "" 18574 "loadm 0,0,%1,%2") 18575 18576 You could write: 18577 18578 (define_constants [ 18579 (R_BP 177) 18580 (R_FC 178) 18581 (R_CR 179) 18582 (R_Q 180) 18583 ]) 18584 18585 (define_insn "" 18586 [(match_parallel 0 "load_multiple_operation" 18587 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 18588 (match_operand:SI 2 "memory_operand" "m")) 18589 (use (reg:SI R_CR)) 18590 (clobber (reg:SI R_CR))])] 18591 "" 18592 "loadm 0,0,%1,%2") 18593 18594 The constants that are defined with a define_constant are also output 18595 in the insn-codes.h header file as #defines. 18596 18597 18598 File: gccint.info, Node: Macros, Prev: Constant Definitions, Up: Machine Desc 18599 18600 14.22 Macros 18601 ============ 18602 18603 Ports often need to define similar patterns for more than one machine 18604 mode or for more than one rtx code. GCC provides some simple macro 18605 facilities to make this process easier. 18606 18607 * Menu: 18608 18609 * Mode Macros:: Generating variations of patterns for different modes. 18610 * Code Macros:: Doing the same for codes. 18611 18612 18613 File: gccint.info, Node: Mode Macros, Next: Code Macros, Up: Macros 18614 18615 14.22.1 Mode Macros 18616 ------------------- 18617 18618 Ports often need to define similar patterns for two or more different 18619 modes. For example: 18620 18621 * If a processor has hardware support for both single and double 18622 floating-point arithmetic, the `SFmode' patterns tend to be very 18623 similar to the `DFmode' ones. 18624 18625 * If a port uses `SImode' pointers in one configuration and `DImode' 18626 pointers in another, it will usually have very similar `SImode' 18627 and `DImode' patterns for manipulating pointers. 18628 18629 Mode macros allow several patterns to be instantiated from one `.md' 18630 file template. They can be used with any type of rtx-based construct, 18631 such as a `define_insn', `define_split', or `define_peephole2'. 18632 18633 * Menu: 18634 18635 * Defining Mode Macros:: Defining a new mode macro. 18636 * Substitutions:: Combining mode macros with substitutions 18637 * Examples:: Examples 18638 18639 18640 File: gccint.info, Node: Defining Mode Macros, Next: Substitutions, Up: Mode Macros 18641 18642 14.22.1.1 Defining Mode Macros 18643 .............................. 18644 18645 The syntax for defining a mode macro is: 18646 18647 (define_mode_macro NAME [(MODE1 "COND1") ... (MODEN "CONDN")]) 18648 18649 This allows subsequent `.md' file constructs to use the mode suffix 18650 `:NAME'. Every construct that does so will be expanded N times, once 18651 with every use of `:NAME' replaced by `:MODE1', once with every use 18652 replaced by `:MODE2', and so on. In the expansion for a particular 18653 MODEI, every C condition will also require that CONDI be true. 18654 18655 For example: 18656 18657 (define_mode_macro P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 18658 18659 defines a new mode suffix `:P'. Every construct that uses `:P' will 18660 be expanded twice, once with every `:P' replaced by `:SI' and once with 18661 every `:P' replaced by `:DI'. The `:SI' version will only apply if 18662 `Pmode == SImode' and the `:DI' version will only apply if `Pmode == 18663 DImode'. 18664 18665 As with other `.md' conditions, an empty string is treated as "always 18666 true". `(MODE "")' can also be abbreviated to `MODE'. For example: 18667 18668 (define_mode_macro GPR [SI (DI "TARGET_64BIT")]) 18669 18670 means that the `:DI' expansion only applies if `TARGET_64BIT' but that 18671 the `:SI' expansion has no such constraint. 18672 18673 Macros are applied in the order they are defined. This can be 18674 significant if two macros are used in a construct that requires 18675 substitutions. *Note Substitutions::. 18676 18677 18678 File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Macros, Up: Mode Macros 18679 18680 14.22.1.2 Substitution in Mode Macros 18681 ..................................... 18682 18683 If an `.md' file construct uses mode macros, each version of the 18684 construct will often need slightly different strings or modes. For 18685 example: 18686 18687 * When a `define_expand' defines several `addM3' patterns (*note 18688 Standard Names::), each expander will need to use the appropriate 18689 mode name for M. 18690 18691 * When a `define_insn' defines several instruction patterns, each 18692 instruction will often use a different assembler mnemonic. 18693 18694 * When a `define_insn' requires operands with different modes, using 18695 a macro for one of the operand modes usually requires a specific 18696 mode for the other operand(s). 18697 18698 GCC supports such variations through a system of "mode attributes". 18699 There are two standard attributes: `mode', which is the name of the 18700 mode in lower case, and `MODE', which is the same thing in upper case. 18701 You can define other attributes using: 18702 18703 (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")]) 18704 18705 where NAME is the name of the attribute and VALUEI is the value 18706 associated with MODEI. 18707 18708 When GCC replaces some :MACRO with :MODE, it will scan each string and 18709 mode in the pattern for sequences of the form `<MACRO:ATTR>', where 18710 ATTR is the name of a mode attribute. If the attribute is defined for 18711 MODE, the whole `<...>' sequence will be replaced by the appropriate 18712 attribute value. 18713 18714 For example, suppose an `.md' file has: 18715 18716 (define_mode_macro P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 18717 (define_mode_attr load [(SI "lw") (DI "ld")]) 18718 18719 If one of the patterns that uses `:P' contains the string 18720 `"<P:load>\t%0,%1"', the `SI' version of that pattern will use 18721 `"lw\t%0,%1"' and the `DI' version will use `"ld\t%0,%1"'. 18722 18723 Here is an example of using an attribute for a mode: 18724 18725 (define_mode_macro LONG [SI DI]) 18726 (define_mode_attr SHORT [(SI "HI") (DI "SI")]) 18727 (define_insn ... 18728 (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...) 18729 18730 The `MACRO:' prefix may be omitted, in which case the substitution 18731 will be attempted for every macro expansion. 18732 18733 18734 File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Macros 18735 18736 14.22.1.3 Mode Macro Examples 18737 ............................. 18738 18739 Here is an example from the MIPS port. It defines the following modes 18740 and attributes (among others): 18741 18742 (define_mode_macro GPR [SI (DI "TARGET_64BIT")]) 18743 (define_mode_attr d [(SI "") (DI "d")]) 18744 18745 and uses the following template to define both `subsi3' and `subdi3': 18746 18747 (define_insn "sub<mode>3" 18748 [(set (match_operand:GPR 0 "register_operand" "=d") 18749 (minus:GPR (match_operand:GPR 1 "register_operand" "d") 18750 (match_operand:GPR 2 "register_operand" "d")))] 18751 "" 18752 "<d>subu\t%0,%1,%2" 18753 [(set_attr "type" "arith") 18754 (set_attr "mode" "<MODE>")]) 18755 18756 This is exactly equivalent to: 18757 18758 (define_insn "subsi3" 18759 [(set (match_operand:SI 0 "register_operand" "=d") 18760 (minus:SI (match_operand:SI 1 "register_operand" "d") 18761 (match_operand:SI 2 "register_operand" "d")))] 18762 "" 18763 "subu\t%0,%1,%2" 18764 [(set_attr "type" "arith") 18765 (set_attr "mode" "SI")]) 18766 18767 (define_insn "subdi3" 18768 [(set (match_operand:DI 0 "register_operand" "=d") 18769 (minus:DI (match_operand:DI 1 "register_operand" "d") 18770 (match_operand:DI 2 "register_operand" "d")))] 18771 "" 18772 "dsubu\t%0,%1,%2" 18773 [(set_attr "type" "arith") 18774 (set_attr "mode" "DI")]) 18775 18776 18777 File: gccint.info, Node: Code Macros, Prev: Mode Macros, Up: Macros 18778 18779 14.22.2 Code Macros 18780 ------------------- 18781 18782 Code macros operate in a similar way to mode macros. *Note Mode 18783 Macros::. 18784 18785 The construct: 18786 18787 (define_code_macro NAME [(CODE1 "COND1") ... (CODEN "CONDN")]) 18788 18789 defines a pseudo rtx code NAME that can be instantiated as CODEI if 18790 condition CONDI is true. Each CODEI must have the same rtx format. 18791 *Note RTL Classes::. 18792 18793 As with mode macros, each pattern that uses NAME will be expanded N 18794 times, once with all uses of NAME replaced by CODE1, once with all uses 18795 replaced by CODE2, and so on. *Note Defining Mode Macros::. 18796 18797 It is possible to define attributes for codes as well as for modes. 18798 There are two standard code attributes: `code', the name of the code in 18799 lower case, and `CODE', the name of the code in upper case. Other 18800 attributes are defined using: 18801 18802 (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")]) 18803 18804 Here's an example of code macros in action, taken from the MIPS port: 18805 18806 (define_code_macro any_cond [unordered ordered unlt unge uneq ltgt unle ungt 18807 eq ne gt ge lt le gtu geu ltu leu]) 18808 18809 (define_expand "b<code>" 18810 [(set (pc) 18811 (if_then_else (any_cond:CC (cc0) 18812 (const_int 0)) 18813 (label_ref (match_operand 0 "")) 18814 (pc)))] 18815 "" 18816 { 18817 gen_conditional_branch (operands, <CODE>); 18818 DONE; 18819 }) 18820 18821 This is equivalent to: 18822 18823 (define_expand "bunordered" 18824 [(set (pc) 18825 (if_then_else (unordered:CC (cc0) 18826 (const_int 0)) 18827 (label_ref (match_operand 0 "")) 18828 (pc)))] 18829 "" 18830 { 18831 gen_conditional_branch (operands, UNORDERED); 18832 DONE; 18833 }) 18834 18835 (define_expand "bordered" 18836 [(set (pc) 18837 (if_then_else (ordered:CC (cc0) 18838 (const_int 0)) 18839 (label_ref (match_operand 0 "")) 18840 (pc)))] 18841 "" 18842 { 18843 gen_conditional_branch (operands, ORDERED); 18844 DONE; 18845 }) 18846 18847 ... 18848 18849 18850 File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top 18851 18852 15 Target Description Macros and Functions 18853 ****************************************** 18854 18855 In addition to the file `MACHINE.md', a machine description includes a 18856 C header file conventionally given the name `MACHINE.h' and a C source 18857 file named `MACHINE.c'. The header file defines numerous macros that 18858 convey the information about the target machine that does not fit into 18859 the scheme of the `.md' file. The file `tm.h' should be a link to 18860 `MACHINE.h'. The header file `config.h' includes `tm.h' and most 18861 compiler source files include `config.h'. The source file defines a 18862 variable `targetm', which is a structure containing pointers to 18863 functions and data relating to the target machine. `MACHINE.c' should 18864 also contain their definitions, if they are not defined elsewhere in 18865 GCC, and other functions called through the macros defined in the `.h' 18866 file. 18867 18868 * Menu: 18869 18870 * Target Structure:: The `targetm' variable. 18871 * Driver:: Controlling how the driver runs the compilation passes. 18872 * Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'. 18873 * Per-Function Data:: Defining data structures for per-function information. 18874 * Storage Layout:: Defining sizes and alignments of data. 18875 * Type Layout:: Defining sizes and properties of basic user data types. 18876 * Registers:: Naming and describing the hardware registers. 18877 * Register Classes:: Defining the classes of hardware registers. 18878 * Old Constraints:: The old way to define machine-specific constraints. 18879 * Stack and Calling:: Defining which way the stack grows and by how much. 18880 * Varargs:: Defining the varargs macros. 18881 * Trampolines:: Code set up at run time to enter a nested function. 18882 * Library Calls:: Controlling how library routines are implicitly called. 18883 * Addressing Modes:: Defining addressing modes valid for memory operands. 18884 * Anchored Addresses:: Defining how `-fsection-anchors' should work. 18885 * Condition Code:: Defining how insns update the condition code. 18886 * Costs:: Defining relative costs of different operations. 18887 * Scheduling:: Adjusting the behavior of the instruction scheduler. 18888 * Sections:: Dividing storage into text, data, and other sections. 18889 * PIC:: Macros for position independent code. 18890 * Assembler Format:: Defining how to write insns and pseudo-ops to output. 18891 * Debugging Info:: Defining the format of debugging output. 18892 * Floating Point:: Handling floating point for cross-compilers. 18893 * Mode Switching:: Insertion of mode-switching instructions. 18894 * Target Attributes:: Defining target-specific uses of `__attribute__'. 18895 * MIPS Coprocessors:: MIPS coprocessor support and how to customize it. 18896 * PCH Target:: Validity checking for precompiled headers. 18897 * C++ ABI:: Controlling C++ ABI changes. 18898 * Misc:: Everything else. 18899 18900 18901 File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros 18902 18903 15.1 The Global `targetm' Variable 18904 ================================== 18905 18906 -- Variable: struct gcc_target targetm 18907 The target `.c' file must define the global `targetm' variable 18908 which contains pointers to functions and data relating to the 18909 target machine. The variable is declared in `target.h'; 18910 `target-def.h' defines the macro `TARGET_INITIALIZER' which is 18911 used to initialize the variable, and macros for the default 18912 initializers for elements of the structure. The `.c' file should 18913 override those macros for which the default definition is 18914 inappropriate. For example: 18915 #include "target.h" 18916 #include "target-def.h" 18917 18918 /* Initialize the GCC target structure. */ 18919 18920 #undef TARGET_COMP_TYPE_ATTRIBUTES 18921 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes 18922 18923 struct gcc_target targetm = TARGET_INITIALIZER; 18924 18925 Where a macro should be defined in the `.c' file in this manner to form 18926 part of the `targetm' structure, it is documented below as a "Target 18927 Hook" with a prototype. Many macros will change in future from being 18928 defined in the `.h' file to being part of the `targetm' structure. 18929 18930 18931 File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros 18932 18933 15.2 Controlling the Compilation Driver, `gcc' 18934 ============================================== 18935 18936 You can control the compilation driver. 18937 18938 -- Macro: SWITCH_TAKES_ARG (CHAR) 18939 A C expression which determines whether the option `-CHAR' takes 18940 arguments. The value should be the number of arguments that 18941 option takes-zero, for many options. 18942 18943 By default, this macro is defined as `DEFAULT_SWITCH_TAKES_ARG', 18944 which handles the standard options properly. You need not define 18945 `SWITCH_TAKES_ARG' unless you wish to add additional options which 18946 take arguments. Any redefinition should call 18947 `DEFAULT_SWITCH_TAKES_ARG' and then check for additional options. 18948 18949 -- Macro: WORD_SWITCH_TAKES_ARG (NAME) 18950 A C expression which determines whether the option `-NAME' takes 18951 arguments. The value should be the number of arguments that 18952 option takes-zero, for many options. This macro rather than 18953 `SWITCH_TAKES_ARG' is used for multi-character option names. 18954 18955 By default, this macro is defined as 18956 `DEFAULT_WORD_SWITCH_TAKES_ARG', which handles the standard options 18957 properly. You need not define `WORD_SWITCH_TAKES_ARG' unless you 18958 wish to add additional options which take arguments. Any 18959 redefinition should call `DEFAULT_WORD_SWITCH_TAKES_ARG' and then 18960 check for additional options. 18961 18962 -- Macro: SWITCH_CURTAILS_COMPILATION (CHAR) 18963 A C expression which determines whether the option `-CHAR' stops 18964 compilation before the generation of an executable. The value is 18965 boolean, nonzero if the option does stop an executable from being 18966 generated, zero otherwise. 18967 18968 By default, this macro is defined as 18969 `DEFAULT_SWITCH_CURTAILS_COMPILATION', which handles the standard 18970 options properly. You need not define 18971 `SWITCH_CURTAILS_COMPILATION' unless you wish to add additional 18972 options which affect the generation of an executable. Any 18973 redefinition should call `DEFAULT_SWITCH_CURTAILS_COMPILATION' and 18974 then check for additional options. 18975 18976 -- Macro: SWITCHES_NEED_SPACES 18977 A string-valued C expression which enumerates the options for which 18978 the linker needs a space between the option and its argument. 18979 18980 If this macro is not defined, the default value is `""'. 18981 18982 -- Macro: TARGET_OPTION_TRANSLATE_TABLE 18983 If defined, a list of pairs of strings, the first of which is a 18984 potential command line target to the `gcc' driver program, and the 18985 second of which is a space-separated (tabs and other whitespace 18986 are not supported) list of options with which to replace the first 18987 option. The target defining this list is responsible for assuring 18988 that the results are valid. Replacement options may not be the 18989 `--opt' style, they must be the `-opt' style. It is the intention 18990 of this macro to provide a mechanism for substitution that affects 18991 the multilibs chosen, such as one option that enables many 18992 options, some of which select multilibs. Example nonsensical 18993 definition, where `-malt-abi', `-EB', and `-mspoo' cause different 18994 multilibs to be chosen: 18995 18996 #define TARGET_OPTION_TRANSLATE_TABLE \ 18997 { "-fast", "-march=fast-foo -malt-abi -I/usr/fast-foo" }, \ 18998 { "-compat", "-EB -malign=4 -mspoo" } 18999 19000 -- Macro: DRIVER_SELF_SPECS 19001 A list of specs for the driver itself. It should be a suitable 19002 initializer for an array of strings, with no surrounding braces. 19003 19004 The driver applies these specs to its own command line between 19005 loading default `specs' files (but not command-line specified 19006 ones) and choosing the multilib directory or running any 19007 subcommands. It applies them in the order given, so each spec can 19008 depend on the options added by earlier ones. It is also possible 19009 to remove options using `%<OPTION' in the usual way. 19010 19011 This macro can be useful when a port has several interdependent 19012 target options. It provides a way of standardizing the command 19013 line so that the other specs are easier to write. 19014 19015 Do not define this macro if it does not need to do anything. 19016 19017 -- Macro: OPTION_DEFAULT_SPECS 19018 A list of specs used to support configure-time default options 19019 (i.e. `--with' options) in the driver. It should be a suitable 19020 initializer for an array of structures, each containing two 19021 strings, without the outermost pair of surrounding braces. 19022 19023 The first item in the pair is the name of the default. This must 19024 match the code in `config.gcc' for the target. The second item is 19025 a spec to apply if a default with this name was specified. The 19026 string `%(VALUE)' in the spec will be replaced by the value of the 19027 default everywhere it occurs. 19028 19029 The driver will apply these specs to its own command line between 19030 loading default `specs' files and processing `DRIVER_SELF_SPECS', 19031 using the same mechanism as `DRIVER_SELF_SPECS'. 19032 19033 Do not define this macro if it does not need to do anything. 19034 19035 -- Macro: CPP_SPEC 19036 A C string constant that tells the GCC driver program options to 19037 pass to CPP. It can also specify how to translate options you 19038 give to GCC into options for GCC to pass to the CPP. 19039 19040 Do not define this macro if it does not need to do anything. 19041 19042 -- Macro: CPLUSPLUS_CPP_SPEC 19043 This macro is just like `CPP_SPEC', but is used for C++, rather 19044 than C. If you do not define this macro, then the value of 19045 `CPP_SPEC' (if any) will be used instead. 19046 19047 -- Macro: CC1_SPEC 19048 A C string constant that tells the GCC driver program options to 19049 pass to `cc1', `cc1plus', `f771', and the other language front 19050 ends. It can also specify how to translate options you give to 19051 GCC into options for GCC to pass to front ends. 19052 19053 Do not define this macro if it does not need to do anything. 19054 19055 -- Macro: CC1PLUS_SPEC 19056 A C string constant that tells the GCC driver program options to 19057 pass to `cc1plus'. It can also specify how to translate options 19058 you give to GCC into options for GCC to pass to the `cc1plus'. 19059 19060 Do not define this macro if it does not need to do anything. Note 19061 that everything defined in CC1_SPEC is already passed to `cc1plus' 19062 so there is no need to duplicate the contents of CC1_SPEC in 19063 CC1PLUS_SPEC. 19064 19065 -- Macro: ASM_SPEC 19066 A C string constant that tells the GCC driver program options to 19067 pass to the assembler. It can also specify how to translate 19068 options you give to GCC into options for GCC to pass to the 19069 assembler. See the file `sun3.h' for an example of this. 19070 19071 Do not define this macro if it does not need to do anything. 19072 19073 -- Macro: ASM_FINAL_SPEC 19074 A C string constant that tells the GCC driver program how to run 19075 any programs which cleanup after the normal assembler. Normally, 19076 this is not needed. See the file `mips.h' for an example of this. 19077 19078 Do not define this macro if it does not need to do anything. 19079 19080 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT 19081 Define this macro, with no value, if the driver should give the 19082 assembler an argument consisting of a single dash, `-', to 19083 instruct it to read from its standard input (which will be a pipe 19084 connected to the output of the compiler proper). This argument is 19085 given after any `-o' option specifying the name of the output file. 19086 19087 If you do not define this macro, the assembler is assumed to read 19088 its standard input if given no non-option arguments. If your 19089 assembler cannot read standard input at all, use a `%{pipe:%e}' 19090 construct; see `mips.h' for instance. 19091 19092 -- Macro: LINK_SPEC 19093 A C string constant that tells the GCC driver program options to 19094 pass to the linker. It can also specify how to translate options 19095 you give to GCC into options for GCC to pass to the linker. 19096 19097 Do not define this macro if it does not need to do anything. 19098 19099 -- Macro: LIB_SPEC 19100 Another C string constant used much like `LINK_SPEC'. The 19101 difference between the two is that `LIB_SPEC' is used at the end 19102 of the command given to the linker. 19103 19104 If this macro is not defined, a default is provided that loads the 19105 standard C library from the usual place. See `gcc.c'. 19106 19107 -- Macro: LIBGCC_SPEC 19108 Another C string constant that tells the GCC driver program how 19109 and when to place a reference to `libgcc.a' into the linker 19110 command line. This constant is placed both before and after the 19111 value of `LIB_SPEC'. 19112 19113 If this macro is not defined, the GCC driver provides a default 19114 that passes the string `-lgcc' to the linker. 19115 19116 -- Macro: REAL_LIBGCC_SPEC 19117 By default, if `ENABLE_SHARED_LIBGCC' is defined, the 19118 `LIBGCC_SPEC' is not directly used by the driver program but is 19119 instead modified to refer to different versions of `libgcc.a' 19120 depending on the values of the command line flags `-static', 19121 `-shared', `-static-libgcc', and `-shared-libgcc'. On targets 19122 where these modifications are inappropriate, define 19123 `REAL_LIBGCC_SPEC' instead. `REAL_LIBGCC_SPEC' tells the driver 19124 how to place a reference to `libgcc' on the link command line, 19125 but, unlike `LIBGCC_SPEC', it is used unmodified. 19126 19127 -- Macro: USE_LD_AS_NEEDED 19128 A macro that controls the modifications to `LIBGCC_SPEC' mentioned 19129 in `REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that 19130 uses -as-needed and the shared libgcc in place of the static 19131 exception handler library, when linking without any of `-static', 19132 `-static-libgcc', or `-shared-libgcc'. 19133 19134 -- Macro: LINK_EH_SPEC 19135 If defined, this C string constant is added to `LINK_SPEC'. When 19136 `USE_LD_AS_NEEDED' is zero or undefined, it also affects the 19137 modifications to `LIBGCC_SPEC' mentioned in `REAL_LIBGCC_SPEC'. 19138 19139 -- Macro: STARTFILE_SPEC 19140 Another C string constant used much like `LINK_SPEC'. The 19141 difference between the two is that `STARTFILE_SPEC' is used at the 19142 very beginning of the command given to the linker. 19143 19144 If this macro is not defined, a default is provided that loads the 19145 standard C startup file from the usual place. See `gcc.c'. 19146 19147 -- Macro: ENDFILE_SPEC 19148 Another C string constant used much like `LINK_SPEC'. The 19149 difference between the two is that `ENDFILE_SPEC' is used at the 19150 very end of the command given to the linker. 19151 19152 Do not define this macro if it does not need to do anything. 19153 19154 -- Macro: THREAD_MODEL_SPEC 19155 GCC `-v' will print the thread model GCC was configured to use. 19156 However, this doesn't work on platforms that are multilibbed on 19157 thread models, such as AIX 4.3. On such platforms, define 19158 `THREAD_MODEL_SPEC' such that it evaluates to a string without 19159 blanks that names one of the recognized thread models. `%*', the 19160 default value of this macro, will expand to the value of 19161 `thread_file' set in `config.gcc'. 19162 19163 -- Macro: SYSROOT_SUFFIX_SPEC 19164 Define this macro to add a suffix to the target sysroot when GCC is 19165 configured with a sysroot. This will cause GCC to search for 19166 usr/lib, et al, within sysroot+suffix. 19167 19168 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC 19169 Define this macro to add a headers_suffix to the target sysroot 19170 when GCC is configured with a sysroot. This will cause GCC to 19171 pass the updated sysroot+headers_suffix to CPP, causing it to 19172 search for usr/include, et al, within sysroot+headers_suffix. 19173 19174 -- Macro: EXTRA_SPECS 19175 Define this macro to provide additional specifications to put in 19176 the `specs' file that can be used in various specifications like 19177 `CC1_SPEC'. 19178 19179 The definition should be an initializer for an array of structures, 19180 containing a string constant, that defines the specification name, 19181 and a string constant that provides the specification. 19182 19183 Do not define this macro if it does not need to do anything. 19184 19185 `EXTRA_SPECS' is useful when an architecture contains several 19186 related targets, which have various `..._SPECS' which are similar 19187 to each other, and the maintainer would like one central place to 19188 keep these definitions. 19189 19190 For example, the PowerPC System V.4 targets use `EXTRA_SPECS' to 19191 define either `_CALL_SYSV' when the System V calling sequence is 19192 used or `_CALL_AIX' when the older AIX-based calling sequence is 19193 used. 19194 19195 The `config/rs6000/rs6000.h' target file defines: 19196 19197 #define EXTRA_SPECS \ 19198 { "cpp_sysv_default", CPP_SYSV_DEFAULT }, 19199 19200 #define CPP_SYS_DEFAULT "" 19201 19202 The `config/rs6000/sysv.h' target file defines: 19203 #undef CPP_SPEC 19204 #define CPP_SPEC \ 19205 "%{posix: -D_POSIX_SOURCE } \ 19206 %{mcall-sysv: -D_CALL_SYSV } \ 19207 %{!mcall-sysv: %(cpp_sysv_default) } \ 19208 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}" 19209 19210 #undef CPP_SYSV_DEFAULT 19211 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV" 19212 19213 while the `config/rs6000/eabiaix.h' target file defines 19214 `CPP_SYSV_DEFAULT' as: 19215 19216 #undef CPP_SYSV_DEFAULT 19217 #define CPP_SYSV_DEFAULT "-D_CALL_AIX" 19218 19219 -- Macro: LINK_LIBGCC_SPECIAL_1 19220 Define this macro if the driver program should find the library 19221 `libgcc.a'. If you do not define this macro, the driver program 19222 will pass the argument `-lgcc' to tell the linker to do the search. 19223 19224 -- Macro: LINK_GCC_C_SEQUENCE_SPEC 19225 The sequence in which libgcc and libc are specified to the linker. 19226 By default this is `%G %L %G'. 19227 19228 -- Macro: LINK_COMMAND_SPEC 19229 A C string constant giving the complete command line need to 19230 execute the linker. When you do this, you will need to update 19231 your port each time a change is made to the link command line 19232 within `gcc.c'. Therefore, define this macro only if you need to 19233 completely redefine the command line for invoking the linker and 19234 there is no other way to accomplish the effect you need. 19235 Overriding this macro may be avoidable by overriding 19236 `LINK_GCC_C_SEQUENCE_SPEC' instead. 19237 19238 -- Macro: LINK_ELIMINATE_DUPLICATE_LDIRECTORIES 19239 A nonzero value causes `collect2' to remove duplicate 19240 `-LDIRECTORY' search directories from linking commands. Do not 19241 give it a nonzero value if removing duplicate search directories 19242 changes the linker's semantics. 19243 19244 -- Macro: MULTILIB_DEFAULTS 19245 Define this macro as a C expression for the initializer of an 19246 array of string to tell the driver program which options are 19247 defaults for this target and thus do not need to be handled 19248 specially when using `MULTILIB_OPTIONS'. 19249 19250 Do not define this macro if `MULTILIB_OPTIONS' is not defined in 19251 the target makefile fragment or if none of the options listed in 19252 `MULTILIB_OPTIONS' are set by default. *Note Target Fragment::. 19253 19254 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR 19255 Define this macro to tell `gcc' that it should only translate a 19256 `-B' prefix into a `-L' linker option if the prefix indicates an 19257 absolute file name. 19258 19259 -- Macro: MD_EXEC_PREFIX 19260 If defined, this macro is an additional prefix to try after 19261 `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the 19262 `-b' option is used, or the compiler is built as a cross compiler. 19263 If you define `MD_EXEC_PREFIX', then be sure to add it to the 19264 list of directories used to find the assembler in `configure.in'. 19265 19266 -- Macro: STANDARD_STARTFILE_PREFIX 19267 Define this macro as a C string constant if you wish to override 19268 the standard choice of `libdir' as the default prefix to try when 19269 searching for startup files such as `crt0.o'. 19270 `STANDARD_STARTFILE_PREFIX' is not searched when the compiler is 19271 built as a cross compiler. 19272 19273 -- Macro: STANDARD_STARTFILE_PREFIX_1 19274 Define this macro as a C string constant if you wish to override 19275 the standard choice of `/lib' as a prefix to try after the default 19276 prefix when searching for startup files such as `crt0.o'. 19277 `STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is 19278 built as a cross compiler. 19279 19280 -- Macro: STANDARD_STARTFILE_PREFIX_2 19281 Define this macro as a C string constant if you wish to override 19282 the standard choice of `/lib' as yet another prefix to try after 19283 the default prefix when searching for startup files such as 19284 `crt0.o'. `STANDARD_STARTFILE_PREFIX_2' is not searched when the 19285 compiler is built as a cross compiler. 19286 19287 -- Macro: MD_STARTFILE_PREFIX 19288 If defined, this macro supplies an additional prefix to try after 19289 the standard prefixes. `MD_EXEC_PREFIX' is not searched when the 19290 `-b' option is used, or when the compiler is built as a cross 19291 compiler. 19292 19293 -- Macro: MD_STARTFILE_PREFIX_1 19294 If defined, this macro supplies yet another prefix to try after the 19295 standard prefixes. It is not searched when the `-b' option is 19296 used, or when the compiler is built as a cross compiler. 19297 19298 -- Macro: INIT_ENVIRONMENT 19299 Define this macro as a C string constant if you wish to set 19300 environment variables for programs called by the driver, such as 19301 the assembler and loader. The driver passes the value of this 19302 macro to `putenv' to initialize the necessary environment 19303 variables. 19304 19305 -- Macro: LOCAL_INCLUDE_DIR 19306 Define this macro as a C string constant if you wish to override 19307 the standard choice of `/usr/local/include' as the default prefix 19308 to try when searching for local header files. `LOCAL_INCLUDE_DIR' 19309 comes before `SYSTEM_INCLUDE_DIR' in the search order. 19310 19311 Cross compilers do not search either `/usr/local/include' or its 19312 replacement. 19313 19314 -- Macro: MODIFY_TARGET_NAME 19315 Define this macro if you wish to define command-line switches that 19316 modify the default target name. 19317 19318 For each switch, you can include a string to be appended to the 19319 first part of the configuration name or a string to be deleted 19320 from the configuration name, if present. The definition should be 19321 an initializer for an array of structures. Each array element 19322 should have three elements: the switch name (a string constant, 19323 including the initial dash), one of the enumeration codes `ADD' or 19324 `DELETE' to indicate whether the string should be inserted or 19325 deleted, and the string to be inserted or deleted (a string 19326 constant). 19327 19328 For example, on a machine where `64' at the end of the 19329 configuration name denotes a 64-bit target and you want the `-32' 19330 and `-64' switches to select between 32- and 64-bit targets, you 19331 would code 19332 19333 #define MODIFY_TARGET_NAME \ 19334 { { "-32", DELETE, "64"}, \ 19335 {"-64", ADD, "64"}} 19336 19337 -- Macro: SYSTEM_INCLUDE_DIR 19338 Define this macro as a C string constant if you wish to specify a 19339 system-specific directory to search for header files before the 19340 standard directory. `SYSTEM_INCLUDE_DIR' comes before 19341 `STANDARD_INCLUDE_DIR' in the search order. 19342 19343 Cross compilers do not use this macro and do not search the 19344 directory specified. 19345 19346 -- Macro: STANDARD_INCLUDE_DIR 19347 Define this macro as a C string constant if you wish to override 19348 the standard choice of `/usr/include' as the default prefix to try 19349 when searching for header files. 19350 19351 Cross compilers ignore this macro and do not search either 19352 `/usr/include' or its replacement. 19353 19354 -- Macro: STANDARD_INCLUDE_COMPONENT 19355 The "component" corresponding to `STANDARD_INCLUDE_DIR'. See 19356 `INCLUDE_DEFAULTS', below, for the description of components. If 19357 you do not define this macro, no component is used. 19358 19359 -- Macro: INCLUDE_DEFAULTS 19360 Define this macro if you wish to override the entire default 19361 search path for include files. For a native compiler, the default 19362 search path usually consists of `GCC_INCLUDE_DIR', 19363 `LOCAL_INCLUDE_DIR', `SYSTEM_INCLUDE_DIR', 19364 `GPLUSPLUS_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition, 19365 `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are defined 19366 automatically by `Makefile', and specify private search areas for 19367 GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used only for C++ 19368 programs. 19369 19370 The definition should be an initializer for an array of structures. 19371 Each array element should have four elements: the directory name (a 19372 string constant), the component name (also a string constant), a 19373 flag for C++-only directories, and a flag showing that the 19374 includes in the directory don't need to be wrapped in `extern `C'' 19375 when compiling C++. Mark the end of the array with a null element. 19376 19377 The component name denotes what GNU package the include file is 19378 part of, if any, in all uppercase letters. For example, it might 19379 be `GCC' or `BINUTILS'. If the package is part of a 19380 vendor-supplied operating system, code the component name as `0'. 19381 19382 For example, here is the definition used for VAX/VMS: 19383 19384 #define INCLUDE_DEFAULTS \ 19385 { \ 19386 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \ 19387 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \ 19388 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \ 19389 { ".", 0, 0, 0}, \ 19390 { 0, 0, 0, 0} \ 19391 } 19392 19393 Here is the order of prefixes tried for exec files: 19394 19395 1. Any prefixes specified by the user with `-B'. 19396 19397 2. The environment variable `GCC_EXEC_PREFIX', if any. 19398 19399 3. The directories specified by the environment variable 19400 `COMPILER_PATH'. 19401 19402 4. The macro `STANDARD_EXEC_PREFIX'. 19403 19404 5. `/usr/lib/gcc/'. 19405 19406 6. The macro `MD_EXEC_PREFIX', if any. 19407 19408 Here is the order of prefixes tried for startfiles: 19409 19410 1. Any prefixes specified by the user with `-B'. 19411 19412 2. The environment variable `GCC_EXEC_PREFIX', if any. 19413 19414 3. The directories specified by the environment variable 19415 `LIBRARY_PATH' (or port-specific name; native only, cross 19416 compilers do not use this). 19417 19418 4. The macro `STANDARD_EXEC_PREFIX'. 19419 19420 5. `/usr/lib/gcc/'. 19421 19422 6. The macro `MD_EXEC_PREFIX', if any. 19423 19424 7. The macro `MD_STARTFILE_PREFIX', if any. 19425 19426 8. The macro `STANDARD_STARTFILE_PREFIX'. 19427 19428 9. `/lib/'. 19429 19430 10. `/usr/lib/'. 19431 19432 19433 File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros 19434 19435 15.3 Run-time Target Specification 19436 ================================== 19437 19438 Here are run-time target specifications. 19439 19440 -- Macro: TARGET_CPU_CPP_BUILTINS () 19441 This function-like macro expands to a block of code that defines 19442 built-in preprocessor macros and assertions for the target cpu, 19443 using the functions `builtin_define', `builtin_define_std' and 19444 `builtin_assert'. When the front end calls this macro it provides 19445 a trailing semicolon, and since it has finished command line 19446 option processing your code can use those results freely. 19447 19448 `builtin_assert' takes a string in the form you pass to the 19449 command-line option `-A', such as `cpu=mips', and creates the 19450 assertion. `builtin_define' takes a string in the form accepted 19451 by option `-D' and unconditionally defines the macro. 19452 19453 `builtin_define_std' takes a string representing the name of an 19454 object-like macro. If it doesn't lie in the user's namespace, 19455 `builtin_define_std' defines it unconditionally. Otherwise, it 19456 defines a version with two leading underscores, and another version 19457 with two leading and trailing underscores, and defines the original 19458 only if an ISO standard was not requested on the command line. For 19459 example, passing `unix' defines `__unix', `__unix__' and possibly 19460 `unix'; passing `_mips' defines `__mips', `__mips__' and possibly 19461 `_mips', and passing `_ABI64' defines only `_ABI64'. 19462 19463 You can also test for the C dialect being compiled. The variable 19464 `c_language' is set to one of `clk_c', `clk_cplusplus' or 19465 `clk_objective_c'. Note that if we are preprocessing assembler, 19466 this variable will be `clk_c' but the function-like macro 19467 `preprocessing_asm_p()' will return true, so you might want to 19468 check for that first. If you need to check for strict ANSI, the 19469 variable `flag_iso' can be used. The function-like macro 19470 `preprocessing_trad_p()' can be used to check for traditional 19471 preprocessing. 19472 19473 -- Macro: TARGET_OS_CPP_BUILTINS () 19474 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional 19475 and is used for the target operating system instead. 19476 19477 -- Macro: TARGET_OBJFMT_CPP_BUILTINS () 19478 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional 19479 and is used for the target object format. `elfos.h' uses this 19480 macro to define `__ELF__', so you probably do not need to define 19481 it yourself. 19482 19483 -- Variable: extern int target_flags 19484 This variable is declared in `options.h', which is included before 19485 any target-specific headers. 19486 19487 -- Variable: Target Hook int TARGET_DEFAULT_TARGET_FLAGS 19488 This variable specifies the initial value of `target_flags'. Its 19489 default setting is 0. 19490 19491 -- Target Hook: bool TARGET_HANDLE_OPTION (size_t CODE, const char 19492 *ARG, int VALUE) 19493 This hook is called whenever the user specifies one of the 19494 target-specific options described by the `.opt' definition files 19495 (*note Options::). It has the opportunity to do some 19496 option-specific processing and should return true if the option is 19497 valid. The default definition does nothing but return true. 19498 19499 CODE specifies the `OPT_NAME' enumeration value associated with 19500 the selected option; NAME is just a rendering of the option name 19501 in which non-alphanumeric characters are replaced by underscores. 19502 ARG specifies the string argument and is null if no argument was 19503 given. If the option is flagged as a `UInteger' (*note Option 19504 properties::), VALUE is the numeric value of the argument. 19505 Otherwise VALUE is 1 if the positive form of the option was used 19506 and 0 if the "no-" form was. 19507 19508 -- Macro: TARGET_VERSION 19509 This macro is a C statement to print on `stderr' a string 19510 describing the particular machine description choice. Every 19511 machine description should define `TARGET_VERSION'. For example: 19512 19513 #ifdef MOTOROLA 19514 #define TARGET_VERSION \ 19515 fprintf (stderr, " (68k, Motorola syntax)"); 19516 #else 19517 #define TARGET_VERSION \ 19518 fprintf (stderr, " (68k, MIT syntax)"); 19519 #endif 19520 19521 -- Macro: OVERRIDE_OPTIONS 19522 Sometimes certain combinations of command options do not make 19523 sense on a particular target machine. You can define a macro 19524 `OVERRIDE_OPTIONS' to take account of this. This macro, if 19525 defined, is executed once just after all the command options have 19526 been parsed. 19527 19528 Don't use this macro to turn on various extra optimizations for 19529 `-O'. That is what `OPTIMIZATION_OPTIONS' is for. 19530 19531 -- Macro: C_COMMON_OVERRIDE_OPTIONS 19532 This is similar to `OVERRIDE_OPTIONS' but is only used in the C 19533 language frontends (C, Objective-C, C++, Objective-C++) and so can 19534 be used to alter option flag variables which only exist in those 19535 frontends. 19536 19537 -- Macro: OPTIMIZATION_OPTIONS (LEVEL, SIZE) 19538 Some machines may desire to change what optimizations are 19539 performed for various optimization levels. This macro, if 19540 defined, is executed once just after the optimization level is 19541 determined and before the remainder of the command options have 19542 been parsed. Values set in this macro are used as the default 19543 values for the other command line options. 19544 19545 LEVEL is the optimization level specified; 2 if `-O2' is 19546 specified, 1 if `-O' is specified, and 0 if neither is specified. 19547 19548 SIZE is nonzero if `-Os' is specified and zero otherwise. 19549 19550 You should not use this macro to change options that are not 19551 machine-specific. These should uniformly selected by the same 19552 optimization level on all supported machines. Use this macro to 19553 enable machine-specific optimizations. 19554 19555 *Do not examine `write_symbols' in this macro!* The debugging 19556 options are not supposed to alter the generated code. 19557 19558 -- Macro: CAN_DEBUG_WITHOUT_FP 19559 Define this macro if debugging can be performed even without a 19560 frame pointer. If this macro is defined, GCC will turn on the 19561 `-fomit-frame-pointer' option whenever `-O' is specified. 19562 19563 19564 File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros 19565 19566 15.4 Defining data structures for per-function information. 19567 =========================================================== 19568 19569 If the target needs to store information on a per-function basis, GCC 19570 provides a macro and a couple of variables to allow this. Note, just 19571 using statics to store the information is a bad idea, since GCC supports 19572 nested functions, so you can be halfway through encoding one function 19573 when another one comes along. 19574 19575 GCC defines a data structure called `struct function' which contains 19576 all of the data specific to an individual function. This structure 19577 contains a field called `machine' whose type is `struct 19578 machine_function *', which can be used by targets to point to their own 19579 specific data. 19580 19581 If a target needs per-function specific data it should define the type 19582 `struct machine_function' and also the macro `INIT_EXPANDERS'. This 19583 macro should be used to initialize the function pointer 19584 `init_machine_status'. This pointer is explained below. 19585 19586 One typical use of per-function, target specific data is to create an 19587 RTX to hold the register containing the function's return address. This 19588 RTX can then be used to implement the `__builtin_return_address' 19589 function, for level 0. 19590 19591 Note--earlier implementations of GCC used a single data area to hold 19592 all of the per-function information. Thus when processing of a nested 19593 function began the old per-function data had to be pushed onto a stack, 19594 and when the processing was finished, it had to be popped off the 19595 stack. GCC used to provide function pointers called 19596 `save_machine_status' and `restore_machine_status' to handle the saving 19597 and restoring of the target specific information. Since the single 19598 data area approach is no longer used, these pointers are no longer 19599 supported. 19600 19601 -- Macro: INIT_EXPANDERS 19602 Macro called to initialize any target specific information. This 19603 macro is called once per function, before generation of any RTL 19604 has begun. The intention of this macro is to allow the 19605 initialization of the function pointer `init_machine_status'. 19606 19607 -- Variable: void (*)(struct function *) init_machine_status 19608 If this function pointer is non-`NULL' it will be called once per 19609 function, before function compilation starts, in order to allow the 19610 target to perform any target specific initialization of the 19611 `struct function' structure. It is intended that this would be 19612 used to initialize the `machine' of that structure. 19613 19614 `struct machine_function' structures are expected to be freed by 19615 GC. Generally, any memory that they reference must be allocated 19616 by using `ggc_alloc', including the structure itself. 19617 19618 19619 File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros 19620 19621 15.5 Storage Layout 19622 =================== 19623 19624 Note that the definitions of the macros in this table which are sizes or 19625 alignments measured in bits do not need to be constant. They can be C 19626 expressions that refer to static variables, such as the `target_flags'. 19627 *Note Run-time Target::. 19628 19629 -- Macro: BITS_BIG_ENDIAN 19630 Define this macro to have the value 1 if the most significant bit 19631 in a byte has the lowest number; otherwise define it to have the 19632 value zero. This means that bit-field instructions count from the 19633 most significant bit. If the machine has no bit-field 19634 instructions, then this must still be defined, but it doesn't 19635 matter which value it is defined to. This macro need not be a 19636 constant. 19637 19638 This macro does not affect the way structure fields are packed into 19639 bytes or words; that is controlled by `BYTES_BIG_ENDIAN'. 19640 19641 -- Macro: BYTES_BIG_ENDIAN 19642 Define this macro to have the value 1 if the most significant byte 19643 in a word has the lowest number. This macro need not be a 19644 constant. 19645 19646 -- Macro: WORDS_BIG_ENDIAN 19647 Define this macro to have the value 1 if, in a multiword object, 19648 the most significant word has the lowest number. This applies to 19649 both memory locations and registers; GCC fundamentally assumes 19650 that the order of words in memory is the same as the order in 19651 registers. This macro need not be a constant. 19652 19653 -- Macro: LIBGCC2_WORDS_BIG_ENDIAN 19654 Define this macro if `WORDS_BIG_ENDIAN' is not constant. This 19655 must be a constant value with the same meaning as 19656 `WORDS_BIG_ENDIAN', which will be used only when compiling 19657 `libgcc2.c'. Typically the value will be set based on 19658 preprocessor defines. 19659 19660 -- Macro: FLOAT_WORDS_BIG_ENDIAN 19661 Define this macro to have the value 1 if `DFmode', `XFmode' or 19662 `TFmode' floating point numbers are stored in memory with the word 19663 containing the sign bit at the lowest address; otherwise define it 19664 to have the value 0. This macro need not be a constant. 19665 19666 You need not define this macro if the ordering is the same as for 19667 multi-word integers. 19668 19669 -- Macro: BITS_PER_UNIT 19670 Define this macro to be the number of bits in an addressable 19671 storage unit (byte). If you do not define this macro the default 19672 is 8. 19673 19674 -- Macro: BITS_PER_WORD 19675 Number of bits in a word. If you do not define this macro, the 19676 default is `BITS_PER_UNIT * UNITS_PER_WORD'. 19677 19678 -- Macro: MAX_BITS_PER_WORD 19679 Maximum number of bits in a word. If this is undefined, the 19680 default is `BITS_PER_WORD'. Otherwise, it is the constant value 19681 that is the largest value that `BITS_PER_WORD' can have at 19682 run-time. 19683 19684 -- Macro: UNITS_PER_WORD 19685 Number of storage units in a word; normally the size of a 19686 general-purpose register, a power of two from 1 or 8. 19687 19688 -- Macro: MIN_UNITS_PER_WORD 19689 Minimum number of units in a word. If this is undefined, the 19690 default is `UNITS_PER_WORD'. Otherwise, it is the constant value 19691 that is the smallest value that `UNITS_PER_WORD' can have at 19692 run-time. 19693 19694 -- Macro: UNITS_PER_SIMD_WORD 19695 Number of units in the vectors that the vectorizer can produce. 19696 The default is equal to `UNITS_PER_WORD', because the vectorizer 19697 can do some transformations even in absence of specialized SIMD 19698 hardware. 19699 19700 -- Macro: POINTER_SIZE 19701 Width of a pointer, in bits. You must specify a value no wider 19702 than the width of `Pmode'. If it is not equal to the width of 19703 `Pmode', you must define `POINTERS_EXTEND_UNSIGNED'. If you do 19704 not specify a value the default is `BITS_PER_WORD'. 19705 19706 -- Macro: POINTERS_EXTEND_UNSIGNED 19707 A C expression whose value is greater than zero if pointers that 19708 need to be extended from being `POINTER_SIZE' bits wide to `Pmode' 19709 are to be zero-extended and zero if they are to be sign-extended. 19710 If the value is less then zero then there must be an "ptr_extend" 19711 instruction that extends a pointer from `POINTER_SIZE' to `Pmode'. 19712 19713 You need not define this macro if the `POINTER_SIZE' is equal to 19714 the width of `Pmode'. 19715 19716 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE) 19717 A macro to update M and UNSIGNEDP when an object whose type is 19718 TYPE and which has the specified mode and signedness is to be 19719 stored in a register. This macro is only called when TYPE is a 19720 scalar type. 19721 19722 On most RISC machines, which only have operations that operate on 19723 a full register, define this macro to set M to `word_mode' if M is 19724 an integer mode narrower than `BITS_PER_WORD'. In most cases, 19725 only integer modes should be widened because wider-precision 19726 floating-point operations are usually more expensive than their 19727 narrower counterparts. 19728 19729 For most machines, the macro definition does not change UNSIGNEDP. 19730 However, some machines, have instructions that preferentially 19731 handle either signed or unsigned quantities of certain modes. For 19732 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add 19733 instructions sign-extend the result to 64 bits. On such machines, 19734 set UNSIGNEDP according to which kind of extension is more 19735 efficient. 19736 19737 Do not define this macro if it would never modify M. 19738 19739 -- Macro: PROMOTE_FUNCTION_MODE 19740 Like `PROMOTE_MODE', but is applied to outgoing function arguments 19741 or function return values, as specified by 19742 `TARGET_PROMOTE_FUNCTION_ARGS' and 19743 `TARGET_PROMOTE_FUNCTION_RETURN', respectively. 19744 19745 The default is `PROMOTE_MODE'. 19746 19747 -- Target Hook: bool TARGET_PROMOTE_FUNCTION_ARGS (tree FNTYPE) 19748 This target hook should return `true' if the promotion described by 19749 `PROMOTE_FUNCTION_MODE' should be done for outgoing function 19750 arguments. 19751 19752 -- Target Hook: bool TARGET_PROMOTE_FUNCTION_RETURN (tree FNTYPE) 19753 This target hook should return `true' if the promotion described by 19754 `PROMOTE_FUNCTION_MODE' should be done for the return value of 19755 functions. 19756 19757 If this target hook returns `true', `TARGET_FUNCTION_VALUE' must 19758 perform the same promotions done by `PROMOTE_FUNCTION_MODE'. 19759 19760 -- Macro: PARM_BOUNDARY 19761 Normal alignment required for function parameters on the stack, in 19762 bits. All stack parameters receive at least this much alignment 19763 regardless of data type. On most machines, this is the same as the 19764 size of an integer. 19765 19766 -- Macro: STACK_BOUNDARY 19767 Define this macro to the minimum alignment enforced by hardware 19768 for the stack pointer on this machine. The definition is a C 19769 expression for the desired alignment (measured in bits). This 19770 value is used as a default if `PREFERRED_STACK_BOUNDARY' is not 19771 defined. On most machines, this should be the same as 19772 `PARM_BOUNDARY'. 19773 19774 -- Macro: PREFERRED_STACK_BOUNDARY 19775 Define this macro if you wish to preserve a certain alignment for 19776 the stack pointer, greater than what the hardware enforces. The 19777 definition is a C expression for the desired alignment (measured 19778 in bits). This macro must evaluate to a value equal to or larger 19779 than `STACK_BOUNDARY'. 19780 19781 -- Macro: FUNCTION_BOUNDARY 19782 Alignment required for a function entry point, in bits. 19783 19784 -- Macro: BIGGEST_ALIGNMENT 19785 Biggest alignment that any data type can require on this machine, 19786 in bits. 19787 19788 -- Macro: MINIMUM_ATOMIC_ALIGNMENT 19789 If defined, the smallest alignment, in bits, that can be given to 19790 an object that can be referenced in one operation, without 19791 disturbing any nearby object. Normally, this is `BITS_PER_UNIT', 19792 but may be larger on machines that don't have byte or half-word 19793 store operations. 19794 19795 -- Macro: BIGGEST_FIELD_ALIGNMENT 19796 Biggest alignment that any structure or union field can require on 19797 this machine, in bits. If defined, this overrides 19798 `BIGGEST_ALIGNMENT' for structure and union fields only, unless 19799 the field alignment has been set by the `__attribute__ ((aligned 19800 (N)))' construct. 19801 19802 -- Macro: ADJUST_FIELD_ALIGN (FIELD, COMPUTED) 19803 An expression for the alignment of a structure field FIELD if the 19804 alignment computed in the usual way (including applying of 19805 `BIGGEST_ALIGNMENT' and `BIGGEST_FIELD_ALIGNMENT' to the 19806 alignment) is COMPUTED. It overrides alignment only if the field 19807 alignment has not been set by the `__attribute__ ((aligned (N)))' 19808 construct. 19809 19810 -- Macro: MAX_OFILE_ALIGNMENT 19811 Biggest alignment supported by the object file format of this 19812 machine. Use this macro to limit the alignment which can be 19813 specified using the `__attribute__ ((aligned (N)))' construct. If 19814 not defined, the default value is `BIGGEST_ALIGNMENT'. 19815 19816 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN) 19817 If defined, a C expression to compute the alignment for a variable 19818 in the static store. TYPE is the data type, and BASIC-ALIGN is 19819 the alignment that the object would ordinarily have. The value of 19820 this macro is used instead of that alignment to align the object. 19821 19822 If this macro is not defined, then BASIC-ALIGN is used. 19823 19824 One use of this macro is to increase alignment of medium-size data 19825 to make it all fit in fewer cache lines. Another is to cause 19826 character arrays to be word-aligned so that `strcpy' calls that 19827 copy constants to character arrays can be done inline. 19828 19829 -- Macro: CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN) 19830 If defined, a C expression to compute the alignment given to a 19831 constant that is being placed in memory. CONSTANT is the constant 19832 and BASIC-ALIGN is the alignment that the object would ordinarily 19833 have. The value of this macro is used instead of that alignment to 19834 align the object. 19835 19836 If this macro is not defined, then BASIC-ALIGN is used. 19837 19838 The typical use of this macro is to increase alignment for string 19839 constants to be word aligned so that `strcpy' calls that copy 19840 constants can be done inline. 19841 19842 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN) 19843 If defined, a C expression to compute the alignment for a variable 19844 in the local store. TYPE is the data type, and BASIC-ALIGN is the 19845 alignment that the object would ordinarily have. The value of this 19846 macro is used instead of that alignment to align the object. 19847 19848 If this macro is not defined, then BASIC-ALIGN is used. 19849 19850 One use of this macro is to increase alignment of medium-size data 19851 to make it all fit in fewer cache lines. 19852 19853 -- Macro: EMPTY_FIELD_BOUNDARY 19854 Alignment in bits to be given to a structure bit-field that 19855 follows an empty field such as `int : 0;'. 19856 19857 If `PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro. 19858 19859 -- Macro: STRUCTURE_SIZE_BOUNDARY 19860 Number of bits which any structure or union's size must be a 19861 multiple of. Each structure or union's size is rounded up to a 19862 multiple of this. 19863 19864 If you do not define this macro, the default is the same as 19865 `BITS_PER_UNIT'. 19866 19867 -- Macro: STRICT_ALIGNMENT 19868 Define this macro to be the value 1 if instructions will fail to 19869 work if given data not on the nominal alignment. If instructions 19870 will merely go slower in that case, define this macro as 0. 19871 19872 -- Macro: PCC_BITFIELD_TYPE_MATTERS 19873 Define this if you wish to imitate the way many other C compilers 19874 handle alignment of bit-fields and the structures that contain 19875 them. 19876 19877 The behavior is that the type written for a named bit-field (`int', 19878 `short', or other integer type) imposes an alignment for the entire 19879 structure, as if the structure really did contain an ordinary 19880 field of that type. In addition, the bit-field is placed within 19881 the structure so that it would fit within such a field, not 19882 crossing a boundary for it. 19883 19884 Thus, on most machines, a named bit-field whose type is written as 19885 `int' would not cross a four-byte boundary, and would force 19886 four-byte alignment for the whole structure. (The alignment used 19887 may not be four bytes; it is controlled by the other alignment 19888 parameters.) 19889 19890 An unnamed bit-field will not affect the alignment of the 19891 containing structure. 19892 19893 If the macro is defined, its definition should be a C expression; 19894 a nonzero value for the expression enables this behavior. 19895 19896 Note that if this macro is not defined, or its value is zero, some 19897 bit-fields may cross more than one alignment boundary. The 19898 compiler can support such references if there are `insv', `extv', 19899 and `extzv' insns that can directly reference memory. 19900 19901 The other known way of making bit-fields work is to define 19902 `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then 19903 every structure can be accessed with fullwords. 19904 19905 Unless the machine has bit-field instructions or you define 19906 `STRUCTURE_SIZE_BOUNDARY' that way, you must define 19907 `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. 19908 19909 If your aim is to make GCC use the same conventions for laying out 19910 bit-fields as are used by another compiler, here is how to 19911 investigate what the other compiler does. Compile and run this 19912 program: 19913 19914 struct foo1 19915 { 19916 char x; 19917 char :0; 19918 char y; 19919 }; 19920 19921 struct foo2 19922 { 19923 char x; 19924 int :0; 19925 char y; 19926 }; 19927 19928 main () 19929 { 19930 printf ("Size of foo1 is %d\n", 19931 sizeof (struct foo1)); 19932 printf ("Size of foo2 is %d\n", 19933 sizeof (struct foo2)); 19934 exit (0); 19935 } 19936 19937 If this prints 2 and 5, then the compiler's behavior is what you 19938 would get from `PCC_BITFIELD_TYPE_MATTERS'. 19939 19940 -- Macro: BITFIELD_NBYTES_LIMITED 19941 Like `PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited 19942 to aligning a bit-field within the structure. 19943 19944 -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELDS (void) 19945 When `PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine 19946 whether unnamed bitfields affect the alignment of the containing 19947 structure. The hook should return true if the structure should 19948 inherit the alignment requirements of an unnamed bitfield's type. 19949 19950 -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELDS (void) 19951 This target hook should return `true' if accesses to volatile 19952 bitfields should use the narrowest mode possible. It should 19953 return `false' if these accesses should use the bitfield container 19954 type. 19955 19956 The default is `!TARGET_STRICT_ALIGN'. 19957 19958 -- Macro: MEMBER_TYPE_FORCES_BLK (FIELD, MODE) 19959 Return 1 if a structure or array containing FIELD should be 19960 accessed using `BLKMODE'. 19961 19962 If FIELD is the only field in the structure, MODE is its mode, 19963 otherwise MODE is VOIDmode. MODE is provided in the case where 19964 structures of one field would require the structure's mode to 19965 retain the field's mode. 19966 19967 Normally, this is not needed. See the file `c4x.h' for an example 19968 of how to use this macro to prevent a structure having a floating 19969 point field from being accessed in an integer mode. 19970 19971 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED) 19972 Define this macro as an expression for the alignment of a type 19973 (given by TYPE as a tree node) if the alignment computed in the 19974 usual way is COMPUTED and the alignment explicitly specified was 19975 SPECIFIED. 19976 19977 The default is to use SPECIFIED if it is larger; otherwise, use 19978 the smaller of COMPUTED and `BIGGEST_ALIGNMENT' 19979 19980 -- Macro: MAX_FIXED_MODE_SIZE 19981 An integer expression for the size in bits of the largest integer 19982 machine mode that should actually be used. All integer machine 19983 modes of this size or smaller can be used for structures and 19984 unions with the appropriate sizes. If this macro is undefined, 19985 `GET_MODE_BITSIZE (DImode)' is assumed. 19986 19987 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL) 19988 If defined, an expression of type `enum machine_mode' that 19989 specifies the mode of the save area operand of a 19990 `save_stack_LEVEL' named pattern (*note Standard Names::). 19991 SAVE_LEVEL is one of `SAVE_BLOCK', `SAVE_FUNCTION', or 19992 `SAVE_NONLOCAL' and selects which of the three named patterns is 19993 having its mode specified. 19994 19995 You need not define this macro if it always returns `Pmode'. You 19996 would most commonly define this macro if the `save_stack_LEVEL' 19997 patterns need to support both a 32- and a 64-bit mode. 19998 19999 -- Macro: STACK_SIZE_MODE 20000 If defined, an expression of type `enum machine_mode' that 20001 specifies the mode of the size increment operand of an 20002 `allocate_stack' named pattern (*note Standard Names::). 20003 20004 You need not define this macro if it always returns `word_mode'. 20005 You would most commonly define this macro if the `allocate_stack' 20006 pattern needs to support both a 32- and a 64-bit mode. 20007 20008 -- Macro: TARGET_FLOAT_FORMAT 20009 A code distinguishing the floating point format of the target 20010 machine. There are four defined values: 20011 20012 `IEEE_FLOAT_FORMAT' 20013 This code indicates IEEE floating point. It is the default; 20014 there is no need to define `TARGET_FLOAT_FORMAT' when the 20015 format is IEEE. 20016 20017 `VAX_FLOAT_FORMAT' 20018 This code indicates the "F float" (for `float') and "D float" 20019 or "G float" formats (for `double') used on the VAX and 20020 PDP-11. 20021 20022 `IBM_FLOAT_FORMAT' 20023 This code indicates the format used on the IBM System/370. 20024 20025 `C4X_FLOAT_FORMAT' 20026 This code indicates the format used on the TMS320C3x/C4x. 20027 20028 If your target uses a floating point format other than these, you 20029 must define a new NAME_FLOAT_FORMAT code for it, and add support 20030 for it to `real.c'. 20031 20032 The ordering of the component words of floating point values 20033 stored in memory is controlled by `FLOAT_WORDS_BIG_ENDIAN'. 20034 20035 -- Macro: MODE_HAS_NANS (MODE) 20036 When defined, this macro should be true if MODE has a NaN 20037 representation. The compiler assumes that NaNs are not equal to 20038 anything (including themselves) and that addition, subtraction, 20039 multiplication and division all return NaNs when one operand is 20040 NaN. 20041 20042 By default, this macro is true if MODE is a floating-point mode 20043 and the target floating-point format is IEEE. 20044 20045 -- Macro: MODE_HAS_INFINITIES (MODE) 20046 This macro should be true if MODE can represent infinity. At 20047 present, the compiler uses this macro to decide whether `x - x' is 20048 always defined. By default, the macro is true when MODE is a 20049 floating-point mode and the target format is IEEE. 20050 20051 -- Macro: MODE_HAS_SIGNED_ZEROS (MODE) 20052 True if MODE distinguishes between positive and negative zero. 20053 The rules are expected to follow the IEEE standard: 20054 20055 * `x + x' has the same sign as `x'. 20056 20057 * If the sum of two values with opposite sign is zero, the 20058 result is positive for all rounding modes expect towards 20059 -infinity, for which it is negative. 20060 20061 * The sign of a product or quotient is negative when exactly one 20062 of the operands is negative. 20063 20064 The default definition is true if MODE is a floating-point mode 20065 and the target format is IEEE. 20066 20067 -- Macro: MODE_HAS_SIGN_DEPENDENT_ROUNDING (MODE) 20068 If defined, this macro should be true for MODE if it has at least 20069 one rounding mode in which `x' and `-x' can be rounded to numbers 20070 of different magnitude. Two such modes are towards -infinity and 20071 towards +infinity. 20072 20073 The default definition of this macro is true if MODE is a 20074 floating-point mode and the target format is IEEE. 20075 20076 -- Macro: ROUND_TOWARDS_ZERO 20077 If defined, this macro should be true if the prevailing rounding 20078 mode is towards zero. A true value has the following effects: 20079 20080 * `MODE_HAS_SIGN_DEPENDENT_ROUNDING' will be false for all 20081 modes. 20082 20083 * `libgcc.a''s floating-point emulator will round towards zero 20084 rather than towards nearest. 20085 20086 * The compiler's floating-point emulator will round towards 20087 zero after doing arithmetic, and when converting from the 20088 internal float format to the target format. 20089 20090 The macro does not affect the parsing of string literals. When the 20091 primary rounding mode is towards zero, library functions like 20092 `strtod' might still round towards nearest, and the compiler's 20093 parser should behave like the target's `strtod' where possible. 20094 20095 Not defining this macro is equivalent to returning zero. 20096 20097 -- Macro: LARGEST_EXPONENT_IS_NORMAL (SIZE) 20098 This macro should return true if floats with SIZE bits do not have 20099 a NaN or infinity representation, but use the largest exponent for 20100 normal numbers instead. 20101 20102 Defining this macro to true for SIZE causes `MODE_HAS_NANS' and 20103 `MODE_HAS_INFINITIES' to be false for SIZE-bit modes. It also 20104 affects the way `libgcc.a' and `real.c' emulate floating-point 20105 arithmetic. 20106 20107 The default definition of this macro returns false for all sizes. 20108 20109 -- Target Hook: bool TARGET_VECTOR_OPAQUE_P (tree TYPE) 20110 This target hook should return `true' a vector is opaque. That 20111 is, if no cast is needed when copying a vector value of type TYPE 20112 into another vector lvalue of the same size. Vector opaque types 20113 cannot be initialized. The default is that there are no such 20114 types. 20115 20116 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (tree RECORD_TYPE) 20117 This target hook returns `true' if bit-fields in the given 20118 RECORD_TYPE are to be laid out following the rules of Microsoft 20119 Visual C/C++, namely: (i) a bit-field won't share the same storage 20120 unit with the previous bit-field if their underlying types have 20121 different sizes, and the bit-field will be aligned to the highest 20122 alignment of the underlying types of itself and of the previous 20123 bit-field; (ii) a zero-sized bit-field will affect the alignment of 20124 the whole enclosing structure, even if it is unnamed; except that 20125 (iii) a zero-sized bit-field will be disregarded unless it follows 20126 another bit-field of nonzero size. If this hook returns `true', 20127 other macros that control bit-field layout are ignored. 20128 20129 When a bit-field is inserted into a packed record, the whole size 20130 of the underlying type is used by one or more same-size adjacent 20131 bit-fields (that is, if its long:3, 32 bits is used in the record, 20132 and any additional adjacent long bit-fields are packed into the 20133 same chunk of 32 bits. However, if the size changes, a new field 20134 of that size is allocated). In an unpacked record, this is the 20135 same as using alignment, but not equivalent when packing. 20136 20137 If both MS bit-fields and `__attribute__((packed))' are used, the 20138 latter will take precedence. If `__attribute__((packed))' is used 20139 on a single field when MS bit-fields are in use, it will take 20140 precedence for that field, but the alignment of the rest of the 20141 structure may affect its placement. 20142 20143 -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void) 20144 Returns true if the target supports decimal floating point. 20145 20146 -- Target Hook: const char * TARGET_MANGLE_FUNDAMENTAL_TYPE (tree TYPE) 20147 If your target defines any fundamental types, define this hook to 20148 return the appropriate encoding for these types as part of a C++ 20149 mangled name. The TYPE argument is the tree structure 20150 representing the type to be mangled. The hook may be applied to 20151 trees which are not target-specific fundamental types; it should 20152 return `NULL' for all such types, as well as arguments it does not 20153 recognize. If the return value is not `NULL', it must point to a 20154 statically-allocated string constant. 20155 20156 Target-specific fundamental types might be new fundamental types or 20157 qualified versions of ordinary fundamental types. Encode new 20158 fundamental types as `u N NAME', where NAME is the name used for 20159 the type in source code, and N is the length of NAME in decimal. 20160 Encode qualified versions of ordinary types as `U N NAME CODE', 20161 where NAME is the name used for the type qualifier in source code, 20162 N is the length of NAME as above, and CODE is the code used to 20163 represent the unqualified version of this type. (See 20164 `write_builtin_type' in `cp/mangle.c' for the list of codes.) In 20165 both cases the spaces are for clarity; do not include any spaces 20166 in your string. 20167 20168 The default version of this hook always returns `NULL', which is 20169 appropriate for a target that does not define any new fundamental 20170 types. 20171 20172 20173 File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros 20174 20175 15.6 Layout of Source Language Data Types 20176 ========================================= 20177 20178 These macros define the sizes and other characteristics of the standard 20179 basic data types used in programs being compiled. Unlike the macros in 20180 the previous section, these apply to specific features of C and related 20181 languages, rather than to fundamental aspects of storage layout. 20182 20183 -- Macro: INT_TYPE_SIZE 20184 A C expression for the size in bits of the type `int' on the 20185 target machine. If you don't define this, the default is one word. 20186 20187 -- Macro: SHORT_TYPE_SIZE 20188 A C expression for the size in bits of the type `short' on the 20189 target machine. If you don't define this, the default is half a 20190 word. (If this would be less than one storage unit, it is rounded 20191 up to one unit.) 20192 20193 -- Macro: LONG_TYPE_SIZE 20194 A C expression for the size in bits of the type `long' on the 20195 target machine. If you don't define this, the default is one word. 20196 20197 -- Macro: ADA_LONG_TYPE_SIZE 20198 On some machines, the size used for the Ada equivalent of the type 20199 `long' by a native Ada compiler differs from that used by C. In 20200 that situation, define this macro to be a C expression to be used 20201 for the size of that type. If you don't define this, the default 20202 is the value of `LONG_TYPE_SIZE'. 20203 20204 -- Macro: LONG_LONG_TYPE_SIZE 20205 A C expression for the size in bits of the type `long long' on the 20206 target machine. If you don't define this, the default is two 20207 words. If you want to support GNU Ada on your machine, the value 20208 of this macro must be at least 64. 20209 20210 -- Macro: CHAR_TYPE_SIZE 20211 A C expression for the size in bits of the type `char' on the 20212 target machine. If you don't define this, the default is 20213 `BITS_PER_UNIT'. 20214 20215 -- Macro: BOOL_TYPE_SIZE 20216 A C expression for the size in bits of the C++ type `bool' and C99 20217 type `_Bool' on the target machine. If you don't define this, and 20218 you probably shouldn't, the default is `CHAR_TYPE_SIZE'. 20219 20220 -- Macro: FLOAT_TYPE_SIZE 20221 A C expression for the size in bits of the type `float' on the 20222 target machine. If you don't define this, the default is one word. 20223 20224 -- Macro: DOUBLE_TYPE_SIZE 20225 A C expression for the size in bits of the type `double' on the 20226 target machine. If you don't define this, the default is two 20227 words. 20228 20229 -- Macro: LONG_DOUBLE_TYPE_SIZE 20230 A C expression for the size in bits of the type `long double' on 20231 the target machine. If you don't define this, the default is two 20232 words. 20233 20234 -- Macro: LIBGCC2_LONG_DOUBLE_TYPE_SIZE 20235 Define this macro if `LONG_DOUBLE_TYPE_SIZE' is not constant or if 20236 you want routines in `libgcc2.a' for a size other than 20237 `LONG_DOUBLE_TYPE_SIZE'. If you don't define this, the default is 20238 `LONG_DOUBLE_TYPE_SIZE'. 20239 20240 -- Macro: LIBGCC2_HAS_DF_MODE 20241 Define this macro if neither `LIBGCC2_DOUBLE_TYPE_SIZE' nor 20242 `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is `DFmode' but you want `DFmode' 20243 routines in `libgcc2.a' anyway. If you don't define this and 20244 either `LIBGCC2_DOUBLE_TYPE_SIZE' or 20245 `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 64 then the default is 1, 20246 otherwise it is 0. 20247 20248 -- Macro: LIBGCC2_HAS_XF_MODE 20249 Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not 20250 `XFmode' but you want `XFmode' routines in `libgcc2.a' anyway. If 20251 you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 80 20252 then the default is 1, otherwise it is 0. 20253 20254 -- Macro: LIBGCC2_HAS_TF_MODE 20255 Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not 20256 `TFmode' but you want `TFmode' routines in `libgcc2.a' anyway. If 20257 you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 128 20258 then the default is 1, otherwise it is 0. 20259 20260 -- Macro: SF_SIZE 20261 -- Macro: DF_SIZE 20262 -- Macro: XF_SIZE 20263 -- Macro: TF_SIZE 20264 Define these macros to be the size in bits of the mantissa of 20265 `SFmode', `DFmode', `XFmode' and `TFmode' values, if the defaults 20266 in `libgcc2.h' are inappropriate. By default, `FLT_MANT_DIG' is 20267 used for `SF_SIZE', `LDBL_MANT_DIG' for `XF_SIZE' and `TF_SIZE', 20268 and `DBL_MANT_DIG' or `LDBL_MANT_DIG' for `DF_SIZE' according to 20269 whether `LIBGCC2_DOUBLE_TYPE_SIZE' or 20270 `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 64. 20271 20272 -- Macro: TARGET_FLT_EVAL_METHOD 20273 A C expression for the value for `FLT_EVAL_METHOD' in `float.h', 20274 assuming, if applicable, that the floating-point control word is 20275 in its default state. If you do not define this macro the value of 20276 `FLT_EVAL_METHOD' will be zero. 20277 20278 -- Macro: WIDEST_HARDWARE_FP_SIZE 20279 A C expression for the size in bits of the widest floating-point 20280 format supported by the hardware. If you define this macro, you 20281 must specify a value less than or equal to the value of 20282 `LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the 20283 value of `LONG_DOUBLE_TYPE_SIZE' is the default. 20284 20285 -- Macro: DEFAULT_SIGNED_CHAR 20286 An expression whose value is 1 or 0, according to whether the type 20287 `char' should be signed or unsigned by default. The user can 20288 always override this default with the options `-fsigned-char' and 20289 `-funsigned-char'. 20290 20291 -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void) 20292 This target hook should return true if the compiler should give an 20293 `enum' type only as many bytes as it takes to represent the range 20294 of possible values of that type. It should return false if all 20295 `enum' types should be allocated like `int'. 20296 20297 The default is to return false. 20298 20299 -- Macro: SIZE_TYPE 20300 A C expression for a string describing the name of the data type 20301 to use for size values. The typedef name `size_t' is defined 20302 using the contents of the string. 20303 20304 The string can contain more than one keyword. If so, separate 20305 them with spaces, and write first any length keyword, then 20306 `unsigned' if appropriate, and finally `int'. The string must 20307 exactly match one of the data type names defined in the function 20308 `init_decl_processing' in the file `c-decl.c'. You may not omit 20309 `int' or change the order--that would cause the compiler to crash 20310 on startup. 20311 20312 If you don't define this macro, the default is `"long unsigned 20313 int"'. 20314 20315 -- Macro: PTRDIFF_TYPE 20316 A C expression for a string describing the name of the data type 20317 to use for the result of subtracting two pointers. The typedef 20318 name `ptrdiff_t' is defined using the contents of the string. See 20319 `SIZE_TYPE' above for more information. 20320 20321 If you don't define this macro, the default is `"long int"'. 20322 20323 -- Macro: WCHAR_TYPE 20324 A C expression for a string describing the name of the data type 20325 to use for wide characters. The typedef name `wchar_t' is defined 20326 using the contents of the string. See `SIZE_TYPE' above for more 20327 information. 20328 20329 If you don't define this macro, the default is `"int"'. 20330 20331 -- Macro: WCHAR_TYPE_SIZE 20332 A C expression for the size in bits of the data type for wide 20333 characters. This is used in `cpp', which cannot make use of 20334 `WCHAR_TYPE'. 20335 20336 -- Macro: WINT_TYPE 20337 A C expression for a string describing the name of the data type to 20338 use for wide characters passed to `printf' and returned from 20339 `getwc'. The typedef name `wint_t' is defined using the contents 20340 of the string. See `SIZE_TYPE' above for more information. 20341 20342 If you don't define this macro, the default is `"unsigned int"'. 20343 20344 -- Macro: INTMAX_TYPE 20345 A C expression for a string describing the name of the data type 20346 that can represent any value of any standard or extended signed 20347 integer type. The typedef name `intmax_t' is defined using the 20348 contents of the string. See `SIZE_TYPE' above for more 20349 information. 20350 20351 If you don't define this macro, the default is the first of 20352 `"int"', `"long int"', or `"long long int"' that has as much 20353 precision as `long long int'. 20354 20355 -- Macro: UINTMAX_TYPE 20356 A C expression for a string describing the name of the data type 20357 that can represent any value of any standard or extended unsigned 20358 integer type. The typedef name `uintmax_t' is defined using the 20359 contents of the string. See `SIZE_TYPE' above for more 20360 information. 20361 20362 If you don't define this macro, the default is the first of 20363 `"unsigned int"', `"long unsigned int"', or `"long long unsigned 20364 int"' that has as much precision as `long long unsigned int'. 20365 20366 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION 20367 The C++ compiler represents a pointer-to-member-function with a 20368 struct that looks like: 20369 20370 struct { 20371 union { 20372 void (*fn)(); 20373 ptrdiff_t vtable_index; 20374 }; 20375 ptrdiff_t delta; 20376 }; 20377 20378 The C++ compiler must use one bit to indicate whether the function 20379 that will be called through a pointer-to-member-function is 20380 virtual. Normally, we assume that the low-order bit of a function 20381 pointer must always be zero. Then, by ensuring that the 20382 vtable_index is odd, we can distinguish which variant of the union 20383 is in use. But, on some platforms function pointers can be odd, 20384 and so this doesn't work. In that case, we use the low-order bit 20385 of the `delta' field, and shift the remainder of the `delta' field 20386 to the left. 20387 20388 GCC will automatically make the right selection about where to 20389 store this bit using the `FUNCTION_BOUNDARY' setting for your 20390 platform. However, some platforms such as ARM/Thumb have 20391 `FUNCTION_BOUNDARY' set such that functions always start at even 20392 addresses, but the lowest bit of pointers to functions indicate 20393 whether the function at that address is in ARM or Thumb mode. If 20394 this is the case of your architecture, you should define this 20395 macro to `ptrmemfunc_vbit_in_delta'. 20396 20397 In general, you should not have to define this macro. On 20398 architectures in which function addresses are always even, 20399 according to `FUNCTION_BOUNDARY', GCC will automatically define 20400 this macro to `ptrmemfunc_vbit_in_pfn'. 20401 20402 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS 20403 Normally, the C++ compiler uses function pointers in vtables. This 20404 macro allows the target to change to use "function descriptors" 20405 instead. Function descriptors are found on targets for whom a 20406 function pointer is actually a small data structure. Normally the 20407 data structure consists of the actual code address plus a data 20408 pointer to which the function's data is relative. 20409 20410 If vtables are used, the value of this macro should be the number 20411 of words that the function descriptor occupies. 20412 20413 -- Macro: TARGET_VTABLE_ENTRY_ALIGN 20414 By default, the vtable entries are void pointers, the so the 20415 alignment is the same as pointer alignment. The value of this 20416 macro specifies the alignment of the vtable entry in bits. It 20417 should be defined only when special alignment is necessary. */ 20418 20419 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE 20420 There are a few non-descriptor entries in the vtable at offsets 20421 below zero. If these entries must be padded (say, to preserve the 20422 alignment specified by `TARGET_VTABLE_ENTRY_ALIGN'), set this to 20423 the number of words in each data entry. 20424 20425 20426 File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros 20427 20428 15.7 Register Usage 20429 =================== 20430 20431 This section explains how to describe what registers the target machine 20432 has, and how (in general) they can be used. 20433 20434 The description of which registers a specific instruction can use is 20435 done with register classes; see *Note Register Classes::. For 20436 information on using registers to access a stack frame, see *Note Frame 20437 Registers::. For passing values in registers, see *Note Register 20438 Arguments::. For returning values in registers, see *Note Scalar 20439 Return::. 20440 20441 * Menu: 20442 20443 * Register Basics:: Number and kinds of registers. 20444 * Allocation Order:: Order in which registers are allocated. 20445 * Values in Registers:: What kinds of values each reg can hold. 20446 * Leaf Functions:: Renumbering registers for leaf functions. 20447 * Stack Registers:: Handling a register stack such as 80387. 20448 20449 20450 File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers 20451 20452 15.7.1 Basic Characteristics of Registers 20453 ----------------------------------------- 20454 20455 Registers have various characteristics. 20456 20457 -- Macro: FIRST_PSEUDO_REGISTER 20458 Number of hardware registers known to the compiler. They receive 20459 numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first 20460 pseudo register's number really is assigned the number 20461 `FIRST_PSEUDO_REGISTER'. 20462 20463 -- Macro: FIXED_REGISTERS 20464 An initializer that says which registers are used for fixed 20465 purposes all throughout the compiled code and are therefore not 20466 available for general allocation. These would include the stack 20467 pointer, the frame pointer (except on machines where that can be 20468 used as a general register when no frame pointer is needed), the 20469 program counter on machines where that is considered one of the 20470 addressable registers, and any other numbered register with a 20471 standard use. 20472 20473 This information is expressed as a sequence of numbers, separated 20474 by commas and surrounded by braces. The Nth number is 1 if 20475 register N is fixed, 0 otherwise. 20476 20477 The table initialized from this macro, and the table initialized by 20478 the following one, may be overridden at run time either 20479 automatically, by the actions of the macro 20480 `CONDITIONAL_REGISTER_USAGE', or by the user with the command 20481 options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'. 20482 20483 -- Macro: CALL_USED_REGISTERS 20484 Like `FIXED_REGISTERS' but has 1 for each register that is 20485 clobbered (in general) by function calls as well as for fixed 20486 registers. This macro therefore identifies the registers that are 20487 not available for general allocation of values that must live 20488 across function calls. 20489 20490 If a register has 0 in `CALL_USED_REGISTERS', the compiler 20491 automatically saves it on function entry and restores it on 20492 function exit, if the register is used within the function. 20493 20494 -- Macro: CALL_REALLY_USED_REGISTERS 20495 Like `CALL_USED_REGISTERS' except this macro doesn't require that 20496 the entire set of `FIXED_REGISTERS' be included. 20497 (`CALL_USED_REGISTERS' must be a superset of `FIXED_REGISTERS'). 20498 This macro is optional. If not specified, it defaults to the value 20499 of `CALL_USED_REGISTERS'. 20500 20501 -- Macro: HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE) 20502 A C expression that is nonzero if it is not permissible to store a 20503 value of mode MODE in hard register number REGNO across a call 20504 without some part of it being clobbered. For most machines this 20505 macro need not be defined. It is only required for machines that 20506 do not preserve the entire contents of a register across a call. 20507 20508 -- Macro: CONDITIONAL_REGISTER_USAGE 20509 Zero or more C statements that may conditionally modify five 20510 variables `fixed_regs', `call_used_regs', `global_regs', 20511 `reg_names', and `reg_class_contents', to take into account any 20512 dependence of these register sets on target flags. The first three 20513 of these are of type `char []' (interpreted as Boolean vectors). 20514 `global_regs' is a `const char *[]', and `reg_class_contents' is a 20515 `HARD_REG_SET'. Before the macro is called, `fixed_regs', 20516 `call_used_regs', `reg_class_contents', and `reg_names' have been 20517 initialized from `FIXED_REGISTERS', `CALL_USED_REGISTERS', 20518 `REG_CLASS_CONTENTS', and `REGISTER_NAMES', respectively. 20519 `global_regs' has been cleared, and any `-ffixed-REG', 20520 `-fcall-used-REG' and `-fcall-saved-REG' command options have been 20521 applied. 20522 20523 You need not define this macro if it has no work to do. 20524 20525 If the usage of an entire class of registers depends on the target 20526 flags, you may indicate this to GCC by using this macro to modify 20527 `fixed_regs' and `call_used_regs' to 1 for each of the registers 20528 in the classes which should not be used by GCC. Also define the 20529 macro `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' to 20530 return `NO_REGS' if it is called with a letter for a class that 20531 shouldn't be used. 20532 20533 (However, if this class is not included in `GENERAL_REGS' and all 20534 of the insn patterns whose constraints permit this class are 20535 controlled by target switches, then GCC will automatically avoid 20536 using these registers when the target switches are opposed to 20537 them.) 20538 20539 -- Macro: INCOMING_REGNO (OUT) 20540 Define this macro if the target machine has register windows. 20541 This C expression returns the register number as seen by the 20542 called function corresponding to the register number OUT as seen 20543 by the calling function. Return OUT if register number OUT is not 20544 an outbound register. 20545 20546 -- Macro: OUTGOING_REGNO (IN) 20547 Define this macro if the target machine has register windows. 20548 This C expression returns the register number as seen by the 20549 calling function corresponding to the register number IN as seen 20550 by the called function. Return IN if register number IN is not an 20551 inbound register. 20552 20553 -- Macro: LOCAL_REGNO (REGNO) 20554 Define this macro if the target machine has register windows. 20555 This C expression returns true if the register is call-saved but 20556 is in the register window. Unlike most call-saved registers, such 20557 registers need not be explicitly restored on function exit or 20558 during non-local gotos. 20559 20560 -- Macro: PC_REGNUM 20561 If the program counter has a register number, define this as that 20562 register number. Otherwise, do not define it. 20563 20564 20565 File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers 20566 20567 15.7.2 Order of Allocation of Registers 20568 --------------------------------------- 20569 20570 Registers are allocated in order. 20571 20572 -- Macro: REG_ALLOC_ORDER 20573 If defined, an initializer for a vector of integers, containing the 20574 numbers of hard registers in the order in which GCC should prefer 20575 to use them (from most preferred to least). 20576 20577 If this macro is not defined, registers are used lowest numbered 20578 first (all else being equal). 20579 20580 One use of this macro is on machines where the highest numbered 20581 registers must always be saved and the save-multiple-registers 20582 instruction supports only sequences of consecutive registers. On 20583 such machines, define `REG_ALLOC_ORDER' to be an initializer that 20584 lists the highest numbered allocable register first. 20585 20586 -- Macro: ORDER_REGS_FOR_LOCAL_ALLOC 20587 A C statement (sans semicolon) to choose the order in which to 20588 allocate hard registers for pseudo-registers local to a basic 20589 block. 20590 20591 Store the desired register order in the array `reg_alloc_order'. 20592 Element 0 should be the register to allocate first; element 1, the 20593 next register; and so on. 20594 20595 The macro body should not assume anything about the contents of 20596 `reg_alloc_order' before execution of the macro. 20597 20598 On most machines, it is not necessary to define this macro. 20599 20600 20601 File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers 20602 20603 15.7.3 How Values Fit in Registers 20604 ---------------------------------- 20605 20606 This section discusses the macros that describe which kinds of values 20607 (specifically, which machine modes) each register can hold, and how many 20608 consecutive registers are needed for a given mode. 20609 20610 -- Macro: HARD_REGNO_NREGS (REGNO, MODE) 20611 A C expression for the number of consecutive hard registers, 20612 starting at register number REGNO, required to hold a value of mode 20613 MODE. 20614 20615 On a machine where all registers are exactly one word, a suitable 20616 definition of this macro is 20617 20618 #define HARD_REGNO_NREGS(REGNO, MODE) \ 20619 ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \ 20620 / UNITS_PER_WORD) 20621 20622 -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE) 20623 A C expression that is nonzero if a value of mode MODE, stored in 20624 memory, ends with padding that causes it to take up more space than 20625 in registers starting at register number REGNO (as determined by 20626 multiplying GCC's notion of the size of the register when 20627 containing this mode by the number of registers returned by 20628 `HARD_REGNO_NREGS'). By default this is zero. 20629 20630 For example, if a floating-point value is stored in three 32-bit 20631 registers but takes up 128 bits in memory, then this would be 20632 nonzero. 20633 20634 This macros only needs to be defined if there are cases where 20635 `subreg_regno_offset' and `subreg_offset_representable_p' would 20636 otherwise wrongly determine that a `subreg' can be represented by 20637 an offset to the register number, when in fact such a `subreg' 20638 would contain some of the padding not stored in registers and so 20639 not be representable. 20640 20641 -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE) 20642 For values of REGNO and MODE for which 20643 `HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression 20644 returning the greater number of registers required to hold the 20645 value including any padding. In the example above, the value 20646 would be four. 20647 20648 -- Macro: REGMODE_NATURAL_SIZE (MODE) 20649 Define this macro if the natural size of registers that hold values 20650 of mode MODE is not the word size. It is a C expression that 20651 should give the natural size in bytes for the specified mode. It 20652 is used by the register allocator to try to optimize its results. 20653 This happens for example on SPARC 64-bit where the natural size of 20654 floating-point registers is still 32-bit. 20655 20656 -- Macro: HARD_REGNO_MODE_OK (REGNO, MODE) 20657 A C expression that is nonzero if it is permissible to store a 20658 value of mode MODE in hard register number REGNO (or in several 20659 registers starting with that one). For a machine where all 20660 registers are equivalent, a suitable definition is 20661 20662 #define HARD_REGNO_MODE_OK(REGNO, MODE) 1 20663 20664 You need not include code to check for the numbers of fixed 20665 registers, because the allocation mechanism considers them to be 20666 always occupied. 20667 20668 On some machines, double-precision values must be kept in even/odd 20669 register pairs. You can implement that by defining this macro to 20670 reject odd register numbers for such modes. 20671 20672 The minimum requirement for a mode to be OK in a register is that 20673 the `movMODE' instruction pattern support moves between the 20674 register and other hard register in the same class and that moving 20675 a value into the register and back out not alter it. 20676 20677 Since the same instruction used to move `word_mode' will work for 20678 all narrower integer modes, it is not necessary on any machine for 20679 `HARD_REGNO_MODE_OK' to distinguish between these modes, provided 20680 you define patterns `movhi', etc., to take advantage of this. This 20681 is useful because of the interaction between `HARD_REGNO_MODE_OK' 20682 and `MODES_TIEABLE_P'; it is very desirable for all integer modes 20683 to be tieable. 20684 20685 Many machines have special registers for floating point arithmetic. 20686 Often people assume that floating point machine modes are allowed 20687 only in floating point registers. This is not true. Any 20688 registers that can hold integers can safely _hold_ a floating 20689 point machine mode, whether or not floating arithmetic can be done 20690 on it in those registers. Integer move instructions can be used 20691 to move the values. 20692 20693 On some machines, though, the converse is true: fixed-point machine 20694 modes may not go in floating registers. This is true if the 20695 floating registers normalize any value stored in them, because 20696 storing a non-floating value there would garble it. In this case, 20697 `HARD_REGNO_MODE_OK' should reject fixed-point machine modes in 20698 floating registers. But if the floating registers do not 20699 automatically normalize, if you can store any bit pattern in one 20700 and retrieve it unchanged without a trap, then any machine mode 20701 may go in a floating register, so you can define this macro to say 20702 so. 20703 20704 The primary significance of special floating registers is rather 20705 that they are the registers acceptable in floating point arithmetic 20706 instructions. However, this is of no concern to 20707 `HARD_REGNO_MODE_OK'. You handle it by writing the proper 20708 constraints for those instructions. 20709 20710 On some machines, the floating registers are especially slow to 20711 access, so that it is better to store a value in a stack frame 20712 than in such a register if floating point arithmetic is not being 20713 done. As long as the floating registers are not in class 20714 `GENERAL_REGS', they will not be used unless some pattern's 20715 constraint asks for one. 20716 20717 -- Macro: HARD_REGNO_RENAME_OK (FROM, TO) 20718 A C expression that is nonzero if it is OK to rename a hard 20719 register FROM to another hard register TO. 20720 20721 One common use of this macro is to prevent renaming of a register 20722 to another register that is not saved by a prologue in an interrupt 20723 handler. 20724 20725 The default is always nonzero. 20726 20727 -- Macro: MODES_TIEABLE_P (MODE1, MODE2) 20728 A C expression that is nonzero if a value of mode MODE1 is 20729 accessible in mode MODE2 without copying. 20730 20731 If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R, 20732 MODE2)' are always the same for any R, then `MODES_TIEABLE_P 20733 (MODE1, MODE2)' should be nonzero. If they differ for any R, you 20734 should define this macro to return zero unless some other 20735 mechanism ensures the accessibility of the value in a narrower 20736 mode. 20737 20738 You should define this macro to return nonzero in as many cases as 20739 possible since doing so will allow GCC to perform better register 20740 allocation. 20741 20742 -- Macro: AVOID_CCMODE_COPIES 20743 Define this macro if the compiler should avoid copies to/from 20744 `CCmode' registers. You should only define this macro if support 20745 for copying to/from `CCmode' is incomplete. 20746 20747 20748 File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers 20749 20750 15.7.4 Handling Leaf Functions 20751 ------------------------------ 20752 20753 On some machines, a leaf function (i.e., one which makes no calls) can 20754 run more efficiently if it does not make its own register window. 20755 Often this means it is required to receive its arguments in the 20756 registers where they are passed by the caller, instead of the registers 20757 where they would normally arrive. 20758 20759 The special treatment for leaf functions generally applies only when 20760 other conditions are met; for example, often they may use only those 20761 registers for its own variables and temporaries. We use the term "leaf 20762 function" to mean a function that is suitable for this special 20763 handling, so that functions with no calls are not necessarily "leaf 20764 functions". 20765 20766 GCC assigns register numbers before it knows whether the function is 20767 suitable for leaf function treatment. So it needs to renumber the 20768 registers in order to output a leaf function. The following macros 20769 accomplish this. 20770 20771 -- Macro: LEAF_REGISTERS 20772 Name of a char vector, indexed by hard register number, which 20773 contains 1 for a register that is allowable in a candidate for leaf 20774 function treatment. 20775 20776 If leaf function treatment involves renumbering the registers, 20777 then the registers marked here should be the ones before 20778 renumbering--those that GCC would ordinarily allocate. The 20779 registers which will actually be used in the assembler code, after 20780 renumbering, should not be marked with 1 in this vector. 20781 20782 Define this macro only if the target machine offers a way to 20783 optimize the treatment of leaf functions. 20784 20785 -- Macro: LEAF_REG_REMAP (REGNO) 20786 A C expression whose value is the register number to which REGNO 20787 should be renumbered, when a function is treated as a leaf 20788 function. 20789 20790 If REGNO is a register number which should not appear in a leaf 20791 function before renumbering, then the expression should yield -1, 20792 which will cause the compiler to abort. 20793 20794 Define this macro only if the target machine offers a way to 20795 optimize the treatment of leaf functions, and registers need to be 20796 renumbered to do this. 20797 20798 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' must 20799 usually treat leaf functions specially. They can test the C variable 20800 `current_function_is_leaf' which is nonzero for leaf functions. 20801 `current_function_is_leaf' is set prior to local register allocation 20802 and is valid for the remaining compiler passes. They can also test the 20803 C variable `current_function_uses_only_leaf_regs' which is nonzero for 20804 leaf functions which only use leaf registers. 20805 `current_function_uses_only_leaf_regs' is valid after all passes that 20806 modify the instructions have been run and is only useful if 20807 `LEAF_REGISTERS' is defined. 20808 20809 20810 File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers 20811 20812 15.7.5 Registers That Form a Stack 20813 ---------------------------------- 20814 20815 There are special features to handle computers where some of the 20816 "registers" form a stack. Stack registers are normally written by 20817 pushing onto the stack, and are numbered relative to the top of the 20818 stack. 20819 20820 Currently, GCC can only handle one group of stack-like registers, and 20821 they must be consecutively numbered. Furthermore, the existing support 20822 for stack-like registers is specific to the 80387 floating point 20823 coprocessor. If you have a new architecture that uses stack-like 20824 registers, you will need to do substantial work on `reg-stack.c' and 20825 write your machine description to cooperate with it, as well as 20826 defining these macros. 20827 20828 -- Macro: STACK_REGS 20829 Define this if the machine has any stack-like registers. 20830 20831 -- Macro: FIRST_STACK_REG 20832 The number of the first stack-like register. This one is the top 20833 of the stack. 20834 20835 -- Macro: LAST_STACK_REG 20836 The number of the last stack-like register. This one is the 20837 bottom of the stack. 20838 20839 20840 File: gccint.info, Node: Register Classes, Next: Old Constraints, Prev: Registers, Up: Target Macros 20841 20842 15.8 Register Classes 20843 ===================== 20844 20845 On many machines, the numbered registers are not all equivalent. For 20846 example, certain registers may not be allowed for indexed addressing; 20847 certain registers may not be allowed in some instructions. These 20848 machine restrictions are described to the compiler using "register 20849 classes". 20850 20851 You define a number of register classes, giving each one a name and 20852 saying which of the registers belong to it. Then you can specify 20853 register classes that are allowed as operands to particular instruction 20854 patterns. 20855 20856 In general, each register will belong to several classes. In fact, one 20857 class must be named `ALL_REGS' and contain all the registers. Another 20858 class must be named `NO_REGS' and contain no registers. Often the 20859 union of two classes will be another class; however, this is not 20860 required. 20861 20862 One of the classes must be named `GENERAL_REGS'. There is nothing 20863 terribly special about the name, but the operand constraint letters `r' 20864 and `g' specify this class. If `GENERAL_REGS' is the same as 20865 `ALL_REGS', just define it as a macro which expands to `ALL_REGS'. 20866 20867 Order the classes so that if class X is contained in class Y then X 20868 has a lower class number than Y. 20869 20870 The way classes other than `GENERAL_REGS' are specified in operand 20871 constraints is through machine-dependent operand constraint letters. 20872 You can define such letters to correspond to various classes, then use 20873 them in operand constraints. 20874 20875 You should define a class for the union of two classes whenever some 20876 instruction allows both classes. For example, if an instruction allows 20877 either a floating point (coprocessor) register or a general register 20878 for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS' 20879 which includes both of them. Otherwise you will get suboptimal code. 20880 20881 You must also specify certain redundant information about the register 20882 classes: for each class, which classes contain it and which ones are 20883 contained in it; for each pair of classes, the largest class contained 20884 in their union. 20885 20886 When a value occupying several consecutive registers is expected in a 20887 certain class, all the registers used must belong to that class. 20888 Therefore, register classes cannot be used to enforce a requirement for 20889 a register pair to start with an even-numbered register. The way to 20890 specify this requirement is with `HARD_REGNO_MODE_OK'. 20891 20892 Register classes used for input-operands of bitwise-and or shift 20893 instructions have a special requirement: each such class must have, for 20894 each fixed-point machine mode, a subclass whose registers can transfer 20895 that mode to or from memory. For example, on some machines, the 20896 operations for single-byte values (`QImode') are limited to certain 20897 registers. When this is so, each register class that is used in a 20898 bitwise-and or shift instruction must have a subclass consisting of 20899 registers from which single-byte values can be loaded or stored. This 20900 is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to 20901 return. 20902 20903 -- Data type: enum reg_class 20904 An enumerated type that must be defined with all the register 20905 class names as enumerated values. `NO_REGS' must be first. 20906 `ALL_REGS' must be the last register class, followed by one more 20907 enumerated value, `LIM_REG_CLASSES', which is not a register class 20908 but rather tells how many classes there are. 20909 20910 Each register class has a number, which is the value of casting 20911 the class name to type `int'. The number serves as an index in 20912 many of the tables described below. 20913 20914 -- Macro: N_REG_CLASSES 20915 The number of distinct register classes, defined as follows: 20916 20917 #define N_REG_CLASSES (int) LIM_REG_CLASSES 20918 20919 -- Macro: REG_CLASS_NAMES 20920 An initializer containing the names of the register classes as C 20921 string constants. These names are used in writing some of the 20922 debugging dumps. 20923 20924 -- Macro: REG_CLASS_CONTENTS 20925 An initializer containing the contents of the register classes, as 20926 integers which are bit masks. The Nth integer specifies the 20927 contents of class N. The way the integer MASK is interpreted is 20928 that register R is in the class if `MASK & (1 << R)' is 1. 20929 20930 When the machine has more than 32 registers, an integer does not 20931 suffice. Then the integers are replaced by sub-initializers, 20932 braced groupings containing several integers. Each 20933 sub-initializer must be suitable as an initializer for the type 20934 `HARD_REG_SET' which is defined in `hard-reg-set.h'. In this 20935 situation, the first integer in each sub-initializer corresponds to 20936 registers 0 through 31, the second integer to registers 32 through 20937 63, and so on. 20938 20939 -- Macro: REGNO_REG_CLASS (REGNO) 20940 A C expression whose value is a register class containing hard 20941 register REGNO. In general there is more than one such class; 20942 choose a class which is "minimal", meaning that no smaller class 20943 also contains the register. 20944 20945 -- Macro: BASE_REG_CLASS 20946 A macro whose definition is the name of the class to which a valid 20947 base register must belong. A base register is one used in an 20948 address which is the register value plus a displacement. 20949 20950 -- Macro: MODE_BASE_REG_CLASS (MODE) 20951 This is a variation of the `BASE_REG_CLASS' macro which allows the 20952 selection of a base register in a mode dependent manner. If MODE 20953 is VOIDmode then it should return the same value as 20954 `BASE_REG_CLASS'. 20955 20956 -- Macro: MODE_BASE_REG_REG_CLASS (MODE) 20957 A C expression whose value is the register class to which a valid 20958 base register must belong in order to be used in a base plus index 20959 register address. You should define this macro if base plus index 20960 addresses have different requirements than other base register 20961 uses. 20962 20963 -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, OUTER_CODE, INDEX_CODE) 20964 A C expression whose value is the register class to which a valid 20965 base register must belong. OUTER_CODE and INDEX_CODE define the 20966 context in which the base register occurs. OUTER_CODE is the code 20967 of the immediately enclosing expression (`MEM' for the top level 20968 of an address, `ADDRESS' for something that occurs in an 20969 `address_operand'). INDEX_CODE is the code of the corresponding 20970 index expression if OUTER_CODE is `PLUS'; `SCRATCH' otherwise. 20971 20972 -- Macro: INDEX_REG_CLASS 20973 A macro whose definition is the name of the class to which a valid 20974 index register must belong. An index register is one used in an 20975 address where its value is either multiplied by a scale factor or 20976 added to another register (as well as added to a displacement). 20977 20978 -- Macro: REGNO_OK_FOR_BASE_P (NUM) 20979 A C expression which is nonzero if register number NUM is suitable 20980 for use as a base register in operand addresses. It may be either 20981 a suitable hard register or a pseudo register that has been 20982 allocated such a hard register. 20983 20984 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE) 20985 A C expression that is just like `REGNO_OK_FOR_BASE_P', except that 20986 that expression may examine the mode of the memory reference in 20987 MODE. You should define this macro if the mode of the memory 20988 reference affects whether a register may be used as a base 20989 register. If you define this macro, the compiler will use it 20990 instead of `REGNO_OK_FOR_BASE_P'. The mode may be `VOIDmode' for 20991 addresses that appear outside a `MEM', i.e. as an 20992 `address_operand'. 20993 20994 20995 -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE) 20996 A C expression which is nonzero if register number NUM is suitable 20997 for use as a base register in base plus index operand addresses, 20998 accessing memory in mode MODE. It may be either a suitable hard 20999 register or a pseudo register that has been allocated such a hard 21000 register. You should define this macro if base plus index 21001 addresses have different requirements than other base register 21002 uses. 21003 21004 Use of this macro is deprecated; please use the more general 21005 `REGNO_MODE_CODE_OK_FOR_BASE_P'. 21006 21007 -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, OUTER_CODE, 21008 INDEX_CODE) 21009 A C expression that is just like `REGNO_MODE_OK_FOR_BASE_P', 21010 except that that expression may examine the context in which the 21011 register appears in the memory reference. OUTER_CODE is the code 21012 of the immediately enclosing expression (`MEM' if at the top level 21013 of the address, `ADDRESS' for something that occurs in an 21014 `address_operand'). INDEX_CODE is the code of the corresponding 21015 index expression if OUTER_CODE is `PLUS'; `SCRATCH' otherwise. 21016 The mode may be `VOIDmode' for addresses that appear outside a 21017 `MEM', i.e. as an `address_operand'. 21018 21019 -- Macro: REGNO_OK_FOR_INDEX_P (NUM) 21020 A C expression which is nonzero if register number NUM is suitable 21021 for use as an index register in operand addresses. It may be 21022 either a suitable hard register or a pseudo register that has been 21023 allocated such a hard register. 21024 21025 The difference between an index register and a base register is 21026 that the index register may be scaled. If an address involves the 21027 sum of two registers, neither one of them scaled, then either one 21028 may be labeled the "base" and the other the "index"; but whichever 21029 labeling is used must fit the machine's constraints of which 21030 registers may serve in each capacity. The compiler will try both 21031 labelings, looking for one that is valid, and will reload one or 21032 both registers only if neither labeling works. 21033 21034 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS) 21035 A C expression that places additional restrictions on the register 21036 class to use when it is necessary to copy value X into a register 21037 in class CLASS. The value is a register class; perhaps CLASS, or 21038 perhaps another, smaller class. On many machines, the following 21039 definition is safe: 21040 21041 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS 21042 21043 Sometimes returning a more restrictive class makes better code. 21044 For example, on the 68000, when X is an integer constant that is 21045 in range for a `moveq' instruction, the value of this macro is 21046 always `DATA_REGS' as long as CLASS includes the data registers. 21047 Requiring a data register guarantees that a `moveq' will be used. 21048 21049 One case where `PREFERRED_RELOAD_CLASS' must not return CLASS is 21050 if X is a legitimate constant which cannot be loaded into some 21051 register class. By returning `NO_REGS' you can force X into a 21052 memory location. For example, rs6000 can load immediate values 21053 into general-purpose registers, but does not have an instruction 21054 for loading an immediate value into a floating-point register, so 21055 `PREFERRED_RELOAD_CLASS' returns `NO_REGS' when X is a 21056 floating-point constant. If the constant can't be loaded into any 21057 kind of register, code generation will be better if 21058 `LEGITIMATE_CONSTANT_P' makes the constant illegitimate instead of 21059 using `PREFERRED_RELOAD_CLASS'. 21060 21061 If an insn has pseudos in it after register allocation, reload 21062 will go through the alternatives and call repeatedly 21063 `PREFERRED_RELOAD_CLASS' to find the best one. Returning 21064 `NO_REGS', in this case, makes reload add a `!' in front of the 21065 constraint: the x86 back-end uses this feature to discourage usage 21066 of 387 registers when math is done in the SSE registers (and vice 21067 versa). 21068 21069 -- Macro: PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS) 21070 Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of 21071 input reloads. If you don't define this macro, the default is to 21072 use CLASS, unchanged. 21073 21074 You can also use `PREFERRED_OUTPUT_RELOAD_CLASS' to discourage 21075 reload from using some alternatives, like `PREFERRED_RELOAD_CLASS'. 21076 21077 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS) 21078 A C expression that places additional restrictions on the register 21079 class to use when it is necessary to be able to hold a value of 21080 mode MODE in a reload register for which class CLASS would 21081 ordinarily be used. 21082 21083 Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when 21084 there are certain modes that simply can't go in certain reload 21085 classes. 21086 21087 The value is a register class; perhaps CLASS, or perhaps another, 21088 smaller class. 21089 21090 Don't define this macro unless the target machine has limitations 21091 which require the macro to do something nontrivial. 21092 21093 -- Target Hook: enum reg_class TARGET_SECONDARY_RELOAD (bool IN_P, rtx 21094 X, enum reg_class RELOAD_CLASS, enum machine_mode 21095 RELOAD_MODE, secondary_reload_info *SRI) 21096 Many machines have some registers that cannot be copied directly 21097 to or from memory or even from other types of registers. An 21098 example is the `MQ' register, which on most machines, can only be 21099 copied to or from general registers, but not memory. Below, we 21100 shall be using the term 'intermediate register' when a move 21101 operation cannot be performed directly, but has to be done by 21102 copying the source into the intermediate register first, and then 21103 copying the intermediate register to the destination. An 21104 intermediate register always has the same mode as source and 21105 destination. Since it holds the actual value being copied, reload 21106 might apply optimizations to re-use an intermediate register and 21107 eliding the copy from the source when it can determine that the 21108 intermediate register still holds the required value. 21109 21110 Another kind of secondary reload is required on some machines which 21111 allow copying all registers to and from memory, but require a 21112 scratch register for stores to some memory locations (e.g., those 21113 with symbolic address on the RT, and those with certain symbolic 21114 address on the SPARC when compiling PIC). Scratch registers need 21115 not have the same mode as the value being copied, and usually hold 21116 a different value that that being copied. Special patterns in the 21117 md file are needed to describe how the copy is performed with the 21118 help of the scratch register; these patterns also describe the 21119 number, register class(es) and mode(s) of the scratch register(s). 21120 21121 In some cases, both an intermediate and a scratch register are 21122 required. 21123 21124 For input reloads, this target hook is called with nonzero IN_P, 21125 and X is an rtx that needs to be copied to a register in of class 21126 RELOAD_CLASS in RELOAD_MODE. For output reloads, this target hook 21127 is called with zero IN_P, and a register of class RELOAD_MODE 21128 needs to be copied to rtx X in RELOAD_MODE. 21129 21130 If copying a register of RELOAD_CLASS from/to X requires an 21131 intermediate register, the hook `secondary_reload' should return 21132 the register class required for this intermediate register. If no 21133 intermediate register is required, it should return NO_REGS. If 21134 more than one intermediate register is required, describe the one 21135 that is closest in the copy chain to the reload register. 21136 21137 If scratch registers are needed, you also have to describe how to 21138 perform the copy from/to the reload register to/from this closest 21139 intermediate register. Or if no intermediate register is 21140 required, but still a scratch register is needed, describe the 21141 copy from/to the reload register to/from the reload operand X. 21142 21143 You do this by setting `sri->icode' to the instruction code of a 21144 pattern in the md file which performs the move. Operands 0 and 1 21145 are the output and input of this copy, respectively. Operands 21146 from operand 2 onward are for scratch operands. These scratch 21147 operands must have a mode, and a single-register-class output 21148 constraint. 21149 21150 When an intermediate register is used, the `secondary_reload' hook 21151 will be called again to determine how to copy the intermediate 21152 register to/from the reload operand X, so your hook must also have 21153 code to handle the register class of the intermediate operand. 21154 21155 X might be a pseudo-register or a `subreg' of a pseudo-register, 21156 which could either be in a hard register or in memory. Use 21157 `true_regnum' to find out; it will return -1 if the pseudo is in 21158 memory and the hard register number if it is in a register. 21159 21160 Scratch operands in memory (constraint `"=m"' / `"=&m"') are 21161 currently not supported. For the time being, you will have to 21162 continue to use `SECONDARY_MEMORY_NEEDED' for that purpose. 21163 21164 `copy_cost' also uses this target hook to find out how values are 21165 copied. If you want it to include some extra cost for the need to 21166 allocate (a) scratch register(s), set `sri->extra_cost' to the 21167 additional cost. Or if two dependent moves are supposed to have a 21168 lower cost than the sum of the individual moves due to expected 21169 fortuitous scheduling and/or special forwarding logic, you can set 21170 `sri->extra_cost' to a negative amount. 21171 21172 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X) 21173 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X) 21174 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X) 21175 These macros are obsolete, new ports should use the target hook 21176 `TARGET_SECONDARY_RELOAD' instead. 21177 21178 These are obsolete macros, replaced by the 21179 `TARGET_SECONDARY_RELOAD' target hook. Older ports still define 21180 these macros to indicate to the reload phase that it may need to 21181 allocate at least one register for a reload in addition to the 21182 register to contain the data. Specifically, if copying X to a 21183 register CLASS in MODE requires an intermediate register, you were 21184 supposed to define `SECONDARY_INPUT_RELOAD_CLASS' to return the 21185 largest register class all of whose registers can be used as 21186 intermediate registers or scratch registers. 21187 21188 If copying a register CLASS in MODE to X requires an intermediate 21189 or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' was supposed 21190 to be defined be defined to return the largest register class 21191 required. If the requirements for input and output reloads were 21192 the same, the macro `SECONDARY_RELOAD_CLASS' should have been used 21193 instead of defining both macros identically. 21194 21195 The values returned by these macros are often `GENERAL_REGS'. 21196 Return `NO_REGS' if no spare register is needed; i.e., if X can be 21197 directly copied to or from a register of CLASS in MODE without 21198 requiring a scratch register. Do not define this macro if it 21199 would always return `NO_REGS'. 21200 21201 If a scratch register is required (either with or without an 21202 intermediate register), you were supposed to define patterns for 21203 `reload_inM' or `reload_outM', as required (*note Standard 21204 Names::. These patterns, which were normally implemented with a 21205 `define_expand', should be similar to the `movM' patterns, except 21206 that operand 2 is the scratch register. 21207 21208 These patterns need constraints for the reload register and scratch 21209 register that contain a single register class. If the original 21210 reload register (whose class is CLASS) can meet the constraint 21211 given in the pattern, the value returned by these macros is used 21212 for the class of the scratch register. Otherwise, two additional 21213 reload registers are required. Their classes are obtained from 21214 the constraints in the insn pattern. 21215 21216 X might be a pseudo-register or a `subreg' of a pseudo-register, 21217 which could either be in a hard register or in memory. Use 21218 `true_regnum' to find out; it will return -1 if the pseudo is in 21219 memory and the hard register number if it is in a register. 21220 21221 These macros should not be used in the case where a particular 21222 class of registers can only be copied to memory and not to another 21223 class of registers. In that case, secondary reload registers are 21224 not needed and would not be helpful. Instead, a stack location 21225 must be used to perform the copy and the `movM' pattern should use 21226 memory as an intermediate storage. This case often occurs between 21227 floating-point and general registers. 21228 21229 -- Macro: SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M) 21230 Certain machines have the property that some registers cannot be 21231 copied to some other registers without using memory. Define this 21232 macro on those machines to be a C expression that is nonzero if 21233 objects of mode M in registers of CLASS1 can only be copied to 21234 registers of class CLASS2 by storing a register of CLASS1 into 21235 memory and loading that memory location into a register of CLASS2. 21236 21237 Do not define this macro if its value would always be zero. 21238 21239 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE) 21240 Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler 21241 allocates a stack slot for a memory location needed for register 21242 copies. If this macro is defined, the compiler instead uses the 21243 memory location defined by this macro. 21244 21245 Do not define this macro if you do not define 21246 `SECONDARY_MEMORY_NEEDED'. 21247 21248 -- Macro: SECONDARY_MEMORY_NEEDED_MODE (MODE) 21249 When the compiler needs a secondary memory location to copy 21250 between two registers of mode MODE, it normally allocates 21251 sufficient memory to hold a quantity of `BITS_PER_WORD' bits and 21252 performs the store and load operations in a mode that many bits 21253 wide and whose class is the same as that of MODE. 21254 21255 This is right thing to do on most machines because it ensures that 21256 all bits of the register are copied and prevents accesses to the 21257 registers in a narrower mode, which some machines prohibit for 21258 floating-point registers. 21259 21260 However, this default behavior is not correct on some machines, 21261 such as the DEC Alpha, that store short integers in floating-point 21262 registers differently than in integer registers. On those 21263 machines, the default widening will not work correctly and you 21264 must define this macro to suppress that widening in some cases. 21265 See the file `alpha.h' for details. 21266 21267 Do not define this macro if you do not define 21268 `SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is 21269 `BITS_PER_WORD' bits wide is correct for your machine. 21270 21271 -- Macro: SMALL_REGISTER_CLASSES 21272 On some machines, it is risky to let hard registers live across 21273 arbitrary insns. Typically, these machines have instructions that 21274 require values to be in specific registers (like an accumulator), 21275 and reload will fail if the required hard register is used for 21276 another purpose across such an insn. 21277 21278 Define `SMALL_REGISTER_CLASSES' to be an expression with a nonzero 21279 value on these machines. When this macro has a nonzero value, the 21280 compiler will try to minimize the lifetime of hard registers. 21281 21282 It is always safe to define this macro with a nonzero value, but 21283 if you unnecessarily define it, you will reduce the amount of 21284 optimizations that can be performed in some cases. If you do not 21285 define this macro with a nonzero value when it is required, the 21286 compiler will run out of spill registers and print a fatal error 21287 message. For most machines, you should not define this macro at 21288 all. 21289 21290 -- Macro: CLASS_LIKELY_SPILLED_P (CLASS) 21291 A C expression whose value is nonzero if pseudos that have been 21292 assigned to registers of class CLASS would likely be spilled 21293 because registers of CLASS are needed for spill registers. 21294 21295 The default value of this macro returns 1 if CLASS has exactly one 21296 register and zero otherwise. On most machines, this default 21297 should be used. Only define this macro to some other expression 21298 if pseudos allocated by `local-alloc.c' end up in memory because 21299 their hard registers were needed for spill registers. If this 21300 macro returns nonzero for those classes, those pseudos will only 21301 be allocated by `global.c', which knows how to reallocate the 21302 pseudo to another register. If there would not be another 21303 register available for reallocation, you should not change the 21304 definition of this macro since the only effect of such a 21305 definition would be to slow down register allocation. 21306 21307 -- Macro: CLASS_MAX_NREGS (CLASS, MODE) 21308 A C expression for the maximum number of consecutive registers of 21309 class CLASS needed to hold a value of mode MODE. 21310 21311 This is closely related to the macro `HARD_REGNO_NREGS'. In fact, 21312 the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be 21313 the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all 21314 REGNO values in the class CLASS. 21315 21316 This macro helps control the handling of multiple-word values in 21317 the reload pass. 21318 21319 -- Macro: CANNOT_CHANGE_MODE_CLASS (FROM, TO, CLASS) 21320 If defined, a C expression that returns nonzero for a CLASS for 21321 which a change from mode FROM to mode TO is invalid. 21322 21323 For the example, loading 32-bit integer or floating-point objects 21324 into floating-point registers on the Alpha extends them to 64 bits. 21325 Therefore loading a 64-bit object and then storing it as a 32-bit 21326 object does not store the low-order 32 bits, as would be the case 21327 for a normal register. Therefore, `alpha.h' defines 21328 `CANNOT_CHANGE_MODE_CLASS' as below: 21329 21330 #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ 21331 (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ 21332 ? reg_classes_intersect_p (FLOAT_REGS, (CLASS)) : 0) 21333 21334 21335 File: gccint.info, Node: Old Constraints, Next: Stack and Calling, Prev: Register Classes, Up: Target Macros 21336 21337 15.9 Obsolete Macros for Defining Constraints 21338 ============================================= 21339 21340 Machine-specific constraints can be defined with these macros instead 21341 of the machine description constructs described in *Note Define 21342 Constraints::. This mechanism is obsolete. New ports should not use 21343 it; old ports should convert to the new mechanism. 21344 21345 -- Macro: CONSTRAINT_LEN (CHAR, STR) 21346 For the constraint at the start of STR, which starts with the 21347 letter C, return the length. This allows you to have register 21348 class / constant / extra constraints that are longer than a single 21349 letter; you don't need to define this macro if you can do with 21350 single-letter constraints only. The definition of this macro 21351 should use DEFAULT_CONSTRAINT_LEN for all the characters that you 21352 don't want to handle specially. There are some sanity checks in 21353 genoutput.c that check the constraint lengths for the md file, so 21354 you can also use this macro to help you while you are 21355 transitioning from a byzantine single-letter-constraint scheme: 21356 when you return a negative length for a constraint you want to 21357 re-use, genoutput will complain about every instance where it is 21358 used in the md file. 21359 21360 -- Macro: REG_CLASS_FROM_LETTER (CHAR) 21361 A C expression which defines the machine-dependent operand 21362 constraint letters for register classes. If CHAR is such a 21363 letter, the value should be the register class corresponding to 21364 it. Otherwise, the value should be `NO_REGS'. The register 21365 letter `r', corresponding to class `GENERAL_REGS', will not be 21366 passed to this macro; you do not need to handle it. 21367 21368 -- Macro: REG_CLASS_FROM_CONSTRAINT (CHAR, STR) 21369 Like `REG_CLASS_FROM_LETTER', but you also get the constraint 21370 string passed in STR, so that you can use suffixes to distinguish 21371 between different variants. 21372 21373 -- Macro: CONST_OK_FOR_LETTER_P (VALUE, C) 21374 A C expression that defines the machine-dependent operand 21375 constraint letters (`I', `J', `K', ... `P') that specify 21376 particular ranges of integer values. If C is one of those 21377 letters, the expression should check that VALUE, an integer, is in 21378 the appropriate range and return 1 if so, 0 otherwise. If C is 21379 not one of those letters, the value should be 0 regardless of 21380 VALUE. 21381 21382 -- Macro: CONST_OK_FOR_CONSTRAINT_P (VALUE, C, STR) 21383 Like `CONST_OK_FOR_LETTER_P', but you also get the constraint 21384 string passed in STR, so that you can use suffixes to distinguish 21385 between different variants. 21386 21387 -- Macro: CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C) 21388 A C expression that defines the machine-dependent operand 21389 constraint letters that specify particular ranges of 21390 `const_double' values (`G' or `H'). 21391 21392 If C is one of those letters, the expression should check that 21393 VALUE, an RTX of code `const_double', is in the appropriate range 21394 and return 1 if so, 0 otherwise. If C is not one of those 21395 letters, the value should be 0 regardless of VALUE. 21396 21397 `const_double' is used for all floating-point constants and for 21398 `DImode' fixed-point constants. A given letter can accept either 21399 or both kinds of values. It can use `GET_MODE' to distinguish 21400 between these kinds. 21401 21402 -- Macro: CONST_DOUBLE_OK_FOR_CONSTRAINT_P (VALUE, C, STR) 21403 Like `CONST_DOUBLE_OK_FOR_LETTER_P', but you also get the 21404 constraint string passed in STR, so that you can use suffixes to 21405 distinguish between different variants. 21406 21407 -- Macro: EXTRA_CONSTRAINT (VALUE, C) 21408 A C expression that defines the optional machine-dependent 21409 constraint letters that can be used to segregate specific types of 21410 operands, usually memory references, for the target machine. Any 21411 letter that is not elsewhere defined and not matched by 21412 `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' may be used. 21413 Normally this macro will not be defined. 21414 21415 If it is required for a particular target machine, it should 21416 return 1 if VALUE corresponds to the operand type represented by 21417 the constraint letter C. If C is not defined as an extra 21418 constraint, the value returned should be 0 regardless of VALUE. 21419 21420 For example, on the ROMP, load instructions cannot have their 21421 output in r0 if the memory reference contains a symbolic address. 21422 Constraint letter `Q' is defined as representing a memory address 21423 that does _not_ contain a symbolic address. An alternative is 21424 specified with a `Q' constraint on the input and `r' on the 21425 output. The next alternative specifies `m' on the input and a 21426 register class that does not include r0 on the output. 21427 21428 -- Macro: EXTRA_CONSTRAINT_STR (VALUE, C, STR) 21429 Like `EXTRA_CONSTRAINT', but you also get the constraint string 21430 passed in STR, so that you can use suffixes to distinguish between 21431 different variants. 21432 21433 -- Macro: EXTRA_MEMORY_CONSTRAINT (C, STR) 21434 A C expression that defines the optional machine-dependent 21435 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT', 21436 that should be treated like memory constraints by the reload pass. 21437 21438 It should return 1 if the operand type represented by the 21439 constraint at the start of STR, the first letter of which is the 21440 letter C, comprises a subset of all memory references including 21441 all those whose address is simply a base register. This allows 21442 the reload pass to reload an operand, if it does not directly 21443 correspond to the operand type of C, by copying its address into a 21444 base register. 21445 21446 For example, on the S/390, some instructions do not accept 21447 arbitrary memory references, but only those that do not make use 21448 of an index register. The constraint letter `Q' is defined via 21449 `EXTRA_CONSTRAINT' as representing a memory address of this type. 21450 If the letter `Q' is marked as `EXTRA_MEMORY_CONSTRAINT', a `Q' 21451 constraint can handle any memory operand, because the reload pass 21452 knows it can be reloaded by copying the memory address into a base 21453 register if required. This is analogous to the way a `o' 21454 constraint can handle any memory operand. 21455 21456 -- Macro: EXTRA_ADDRESS_CONSTRAINT (C, STR) 21457 A C expression that defines the optional machine-dependent 21458 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT' / 21459 `EXTRA_CONSTRAINT_STR', that should be treated like address 21460 constraints by the reload pass. 21461 21462 It should return 1 if the operand type represented by the 21463 constraint at the start of STR, which starts with the letter C, 21464 comprises a subset of all memory addresses including all those 21465 that consist of just a base register. This allows the reload pass 21466 to reload an operand, if it does not directly correspond to the 21467 operand type of STR, by copying it into a base register. 21468 21469 Any constraint marked as `EXTRA_ADDRESS_CONSTRAINT' can only be 21470 used with the `address_operand' predicate. It is treated 21471 analogously to the `p' constraint. 21472 21473 21474 File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Old Constraints, Up: Target Macros 21475 21476 15.10 Stack Layout and Calling Conventions 21477 ========================================== 21478 21479 This describes the stack layout and calling conventions. 21480 21481 * Menu: 21482 21483 * Frame Layout:: 21484 * Exception Handling:: 21485 * Stack Checking:: 21486 * Frame Registers:: 21487 * Elimination:: 21488 * Stack Arguments:: 21489 * Register Arguments:: 21490 * Scalar Return:: 21491 * Aggregate Return:: 21492 * Caller Saves:: 21493 * Function Entry:: 21494 * Profiling:: 21495 * Tail Calls:: 21496 * Stack Smashing Protection:: 21497 21498 21499 File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling 21500 21501 15.10.1 Basic Stack Layout 21502 -------------------------- 21503 21504 Here is the basic stack layout. 21505 21506 -- Macro: STACK_GROWS_DOWNWARD 21507 Define this macro if pushing a word onto the stack moves the stack 21508 pointer to a smaller address. 21509 21510 When we say, "define this macro if ...", it means that the 21511 compiler checks this macro only with `#ifdef' so the precise 21512 definition used does not matter. 21513 21514 -- Macro: STACK_PUSH_CODE 21515 This macro defines the operation used when something is pushed on 21516 the stack. In RTL, a push operation will be `(set (mem 21517 (STACK_PUSH_CODE (reg sp))) ...)' 21518 21519 The choices are `PRE_DEC', `POST_DEC', `PRE_INC', and `POST_INC'. 21520 Which of these is correct depends on the stack direction and on 21521 whether the stack pointer points to the last item on the stack or 21522 whether it points to the space for the next item on the stack. 21523 21524 The default is `PRE_DEC' when `STACK_GROWS_DOWNWARD' is defined, 21525 which is almost always right, and `PRE_INC' otherwise, which is 21526 often wrong. 21527 21528 -- Macro: FRAME_GROWS_DOWNWARD 21529 Define this macro to nonzero value if the addresses of local 21530 variable slots are at negative offsets from the frame pointer. 21531 21532 -- Macro: ARGS_GROW_DOWNWARD 21533 Define this macro if successive arguments to a function occupy 21534 decreasing addresses on the stack. 21535 21536 -- Macro: STARTING_FRAME_OFFSET 21537 Offset from the frame pointer to the first local variable slot to 21538 be allocated. 21539 21540 If `FRAME_GROWS_DOWNWARD', find the next slot's offset by 21541 subtracting the first slot's length from `STARTING_FRAME_OFFSET'. 21542 Otherwise, it is found by adding the length of the first slot to 21543 the value `STARTING_FRAME_OFFSET'. 21544 21545 -- Macro: STACK_ALIGNMENT_NEEDED 21546 Define to zero to disable final alignment of the stack during 21547 reload. The nonzero default for this macro is suitable for most 21548 ports. 21549 21550 On ports where `STARTING_FRAME_OFFSET' is nonzero or where there 21551 is a register save block following the local block that doesn't 21552 require alignment to `STACK_BOUNDARY', it may be beneficial to 21553 disable stack alignment and do it in the backend. 21554 21555 -- Macro: STACK_POINTER_OFFSET 21556 Offset from the stack pointer register to the first location at 21557 which outgoing arguments are placed. If not specified, the 21558 default value of zero is used. This is the proper value for most 21559 machines. 21560 21561 If `ARGS_GROW_DOWNWARD', this is the offset to the location above 21562 the first location at which outgoing arguments are placed. 21563 21564 -- Macro: FIRST_PARM_OFFSET (FUNDECL) 21565 Offset from the argument pointer register to the first argument's 21566 address. On some machines it may depend on the data type of the 21567 function. 21568 21569 If `ARGS_GROW_DOWNWARD', this is the offset to the location above 21570 the first argument's address. 21571 21572 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL) 21573 Offset from the stack pointer register to an item dynamically 21574 allocated on the stack, e.g., by `alloca'. 21575 21576 The default value for this macro is `STACK_POINTER_OFFSET' plus the 21577 length of the outgoing arguments. The default is correct for most 21578 machines. See `function.c' for details. 21579 21580 -- Macro: INITIAL_FRAME_ADDRESS_RTX 21581 A C expression whose value is RTL representing the address of the 21582 initial stack frame. This address is passed to `RETURN_ADDR_RTX' 21583 and `DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a 21584 reasonable default value will be used. Define this macro in order 21585 to make frame pointer elimination work in the presence of 21586 `__builtin_frame_address (count)' and `__builtin_return_address 21587 (count)' for `count' not equal to zero. 21588 21589 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR) 21590 A C expression whose value is RTL representing the address in a 21591 stack frame where the pointer to the caller's frame is stored. 21592 Assume that FRAMEADDR is an RTL expression for the address of the 21593 stack frame itself. 21594 21595 If you don't define this macro, the default is to return the value 21596 of FRAMEADDR--that is, the stack frame address is also the address 21597 of the stack word that points to the previous frame. 21598 21599 -- Macro: SETUP_FRAME_ADDRESSES 21600 If defined, a C expression that produces the machine-specific code 21601 to setup the stack so that arbitrary frames can be accessed. For 21602 example, on the SPARC, we must flush all of the register windows 21603 to the stack before we can access arbitrary stack frames. You 21604 will seldom need to define this macro. 21605 21606 -- Target Hook: bool TARGET_BUILTIN_SETJMP_FRAME_VALUE () 21607 This target hook should return an rtx that is used to store the 21608 address of the current frame into the built in `setjmp' buffer. 21609 The default value, `virtual_stack_vars_rtx', is correct for most 21610 machines. One reason you may need to define this target hook is if 21611 `hard_frame_pointer_rtx' is the appropriate value on your machine. 21612 21613 -- Macro: FRAME_ADDR_RTX (FRAMEADDR) 21614 A C expression whose value is RTL representing the value of the 21615 frame address for the current frame. FRAMEADDR is the frame 21616 pointer of the current frame. This is used for 21617 __builtin_frame_address. You need only define this macro if the 21618 frame address is not the same as the frame pointer. Most machines 21619 do not need to define it. 21620 21621 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR) 21622 A C expression whose value is RTL representing the value of the 21623 return address for the frame COUNT steps up from the current 21624 frame, after the prologue. FRAMEADDR is the frame pointer of the 21625 COUNT frame, or the frame pointer of the COUNT - 1 frame if 21626 `RETURN_ADDR_IN_PREVIOUS_FRAME' is defined. 21627 21628 The value of the expression must always be the correct address when 21629 COUNT is zero, but may be `NULL_RTX' if there is not way to 21630 determine the return address of other frames. 21631 21632 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME 21633 Define this if the return address of a particular stack frame is 21634 accessed from the frame pointer of the previous stack frame. 21635 21636 -- Macro: INCOMING_RETURN_ADDR_RTX 21637 A C expression whose value is RTL representing the location of the 21638 incoming return address at the beginning of any function, before 21639 the prologue. This RTL is either a `REG', indicating that the 21640 return value is saved in `REG', or a `MEM' representing a location 21641 in the stack. 21642 21643 You only need to define this macro if you want to support call 21644 frame debugging information like that provided by DWARF 2. 21645 21646 If this RTL is a `REG', you should also define 21647 `DWARF_FRAME_RETURN_COLUMN' to `DWARF_FRAME_REGNUM (REGNO)'. 21648 21649 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN 21650 A C expression whose value is an integer giving a DWARF 2 column 21651 number that may be used as an alternate return column. This should 21652 be defined only if `DWARF_FRAME_RETURN_COLUMN' is set to a general 21653 register, but an alternate column needs to be used for signal 21654 frames. 21655 21656 -- Macro: DWARF_ZERO_REG 21657 A C expression whose value is an integer giving a DWARF 2 register 21658 number that is considered to always have the value zero. This 21659 should only be defined if the target has an architected zero 21660 register, and someone decided it was a good idea to use that 21661 register number to terminate the stack backtrace. New ports 21662 should avoid this. 21663 21664 -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char 21665 *LABEL, rtx PATTERN, int INDEX) 21666 This target hook allows the backend to emit frame-related insns 21667 that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame 21668 debugging info engine will invoke it on insns of the form 21669 (set (reg) (unspec [...] UNSPEC_INDEX)) 21670 and 21671 (set (reg) (unspec_volatile [...] UNSPECV_INDEX)). 21672 to let the backend emit the call frame instructions. LABEL is the 21673 CFI label attached to the insn, PATTERN is the pattern of the insn 21674 and INDEX is `UNSPEC_INDEX' or `UNSPECV_INDEX'. 21675 21676 -- Macro: INCOMING_FRAME_SP_OFFSET 21677 A C expression whose value is an integer giving the offset, in 21678 bytes, from the value of the stack pointer register to the top of 21679 the stack frame at the beginning of any function, before the 21680 prologue. The top of the frame is defined to be the value of the 21681 stack pointer in the previous frame, just before the call 21682 instruction. 21683 21684 You only need to define this macro if you want to support call 21685 frame debugging information like that provided by DWARF 2. 21686 21687 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL) 21688 A C expression whose value is an integer giving the offset, in 21689 bytes, from the argument pointer to the canonical frame address 21690 (cfa). The final value should coincide with that calculated by 21691 `INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable 21692 during virtual register instantiation. 21693 21694 The default value for this macro is `FIRST_PARM_OFFSET (fundecl)', 21695 which is correct for most machines; in general, the arguments are 21696 found immediately before the stack frame. Note that this is not 21697 the case on some targets that save registers into the caller's 21698 frame, such as SPARC and rs6000, and so such targets need to 21699 define this macro. 21700 21701 You only need to define this macro if the default is incorrect, 21702 and you want to support call frame debugging information like that 21703 provided by DWARF 2. 21704 21705 -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL) 21706 If defined, a C expression whose value is an integer giving the 21707 offset in bytes from the frame pointer to the canonical frame 21708 address (cfa). The final value should coincide with that 21709 calculated by `INCOMING_FRAME_SP_OFFSET'. 21710 21711 Normally the CFA is calculated as an offset from the argument 21712 pointer, via `ARG_POINTER_CFA_OFFSET', but if the argument pointer 21713 is variable due to the ABI, this may not be possible. If this 21714 macro is defined, it implies that the virtual register 21715 instantiation should be based on the frame pointer instead of the 21716 argument pointer. Only one of `FRAME_POINTER_CFA_OFFSET' and 21717 `ARG_POINTER_CFA_OFFSET' should be defined. 21718 21719 -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL) 21720 If defined, a C expression whose value is an integer giving the 21721 offset in bytes from the canonical frame address (cfa) to the 21722 frame base used in DWARF 2 debug information. The default is 21723 zero. A different value may reduce the size of debug information 21724 on some ports. 21725 21726 21727 File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling 21728 21729 15.10.2 Exception Handling Support 21730 ---------------------------------- 21731 21732 -- Macro: EH_RETURN_DATA_REGNO (N) 21733 A C expression whose value is the Nth register number used for 21734 data by exception handlers, or `INVALID_REGNUM' if fewer than N 21735 registers are usable. 21736 21737 The exception handling library routines communicate with the 21738 exception handlers via a set of agreed upon registers. Ideally 21739 these registers should be call-clobbered; it is possible to use 21740 call-saved registers, but may negatively impact code size. The 21741 target must support at least 2 data registers, but should define 4 21742 if there are enough free registers. 21743 21744 You must define this macro if you want to support call frame 21745 exception handling like that provided by DWARF 2. 21746 21747 -- Macro: EH_RETURN_STACKADJ_RTX 21748 A C expression whose value is RTL representing a location in which 21749 to store a stack adjustment to be applied before function return. 21750 This is used to unwind the stack to an exception handler's call 21751 frame. It will be assigned zero on code paths that return 21752 normally. 21753 21754 Typically this is a call-clobbered hard register that is otherwise 21755 untouched by the epilogue, but could also be a stack slot. 21756 21757 Do not define this macro if the stack pointer is saved and restored 21758 by the regular prolog and epilog code in the call frame itself; in 21759 this case, the exception handling library routines will update the 21760 stack location to be restored in place. Otherwise, you must define 21761 this macro if you want to support call frame exception handling 21762 like that provided by DWARF 2. 21763 21764 -- Macro: EH_RETURN_HANDLER_RTX 21765 A C expression whose value is RTL representing a location in which 21766 to store the address of an exception handler to which we should 21767 return. It will not be assigned on code paths that return 21768 normally. 21769 21770 Typically this is the location in the call frame at which the 21771 normal return address is stored. For targets that return by 21772 popping an address off the stack, this might be a memory address 21773 just below the _target_ call frame rather than inside the current 21774 call frame. If defined, `EH_RETURN_STACKADJ_RTX' will have already 21775 been assigned, so it may be used to calculate the location of the 21776 target call frame. 21777 21778 Some targets have more complex requirements than storing to an 21779 address calculable during initial code generation. In that case 21780 the `eh_return' instruction pattern should be used instead. 21781 21782 If you want to support call frame exception handling, you must 21783 define either this macro or the `eh_return' instruction pattern. 21784 21785 -- Macro: RETURN_ADDR_OFFSET 21786 If defined, an integer-valued C expression for which rtl will be 21787 generated to add it to the exception handler address before it is 21788 searched in the exception handling tables, and to subtract it 21789 again from the address before using it to return to the exception 21790 handler. 21791 21792 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL) 21793 This macro chooses the encoding of pointers embedded in the 21794 exception handling sections. If at all possible, this should be 21795 defined such that the exception handling section will not require 21796 dynamic relocations, and so may be read-only. 21797 21798 CODE is 0 for data, 1 for code labels, 2 for function pointers. 21799 GLOBAL is true if the symbol may be affected by dynamic 21800 relocations. The macro should return a combination of the 21801 `DW_EH_PE_*' defines as found in `dwarf2.h'. 21802 21803 If this macro is not defined, pointers will not be encoded but 21804 represented directly. 21805 21806 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE, 21807 ADDR, DONE) 21808 This macro allows the target to emit whatever special magic is 21809 required to represent the encoding chosen by 21810 `ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of 21811 pc-relative and indirect encodings; this must be defined if the 21812 target uses text-relative or data-relative encodings. 21813 21814 This is a C statement that branches to DONE if the format was 21815 handled. ENCODING is the format chosen, SIZE is the number of 21816 bytes that the format occupies, ADDR is the `SYMBOL_REF' to be 21817 emitted. 21818 21819 -- Macro: MD_UNWIND_SUPPORT 21820 A string specifying a file to be #include'd in unwind-dw2.c. The 21821 file so included typically defines `MD_FALLBACK_FRAME_STATE_FOR'. 21822 21823 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS) 21824 This macro allows the target to add cpu and operating system 21825 specific code to the call-frame unwinder for use when there is no 21826 unwind data available. The most common reason to implement this 21827 macro is to unwind through signal frames. 21828 21829 This macro is called from `uw_frame_state_for' in `unwind-dw2.c' 21830 and `unwind-ia64.c'. CONTEXT is an `_Unwind_Context'; FS is an 21831 `_Unwind_FrameState'. Examine `context->ra' for the address of 21832 the code being executed and `context->cfa' for the stack pointer 21833 value. If the frame can be decoded, the register save addresses 21834 should be updated in FS and the macro should evaluate to 21835 `_URC_NO_REASON'. If the frame cannot be decoded, the macro should 21836 evaluate to `_URC_END_OF_STACK'. 21837 21838 For proper signal handling in Java this macro is accompanied by 21839 `MAKE_THROW_FRAME', defined in `libjava/include/*-signal.h' 21840 headers. 21841 21842 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS) 21843 This macro allows the target to add operating system specific code 21844 to the call-frame unwinder to handle the IA-64 `.unwabi' unwinding 21845 directive, usually used for signal or interrupt frames. 21846 21847 This macro is called from `uw_update_context' in `unwind-ia64.c'. 21848 CONTEXT is an `_Unwind_Context'; FS is an `_Unwind_FrameState'. 21849 Examine `fs->unwabi' for the abi and context in the `.unwabi' 21850 directive. If the `.unwabi' directive can be handled, the 21851 register save addresses should be updated in FS. 21852 21853 -- Macro: TARGET_USES_WEAK_UNWIND_INFO 21854 A C expression that evaluates to true if the target requires unwind 21855 info to be given comdat linkage. Define it to be `1' if comdat 21856 linkage is necessary. The default is `0'. 21857 21858 21859 File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling 21860 21861 15.10.3 Specifying How Stack Checking is Done 21862 --------------------------------------------- 21863 21864 GCC will check that stack references are within the boundaries of the 21865 stack, if the `-fstack-check' is specified, in one of three ways: 21866 21867 1. If the value of the `STACK_CHECK_BUILTIN' macro is nonzero, GCC 21868 will assume that you have arranged for stack checking to be done at 21869 appropriate places in the configuration files, e.g., in 21870 `TARGET_ASM_FUNCTION_PROLOGUE'. GCC will do not other special 21871 processing. 21872 21873 2. If `STACK_CHECK_BUILTIN' is zero and you defined a named pattern 21874 called `check_stack' in your `md' file, GCC will call that pattern 21875 with one argument which is the address to compare the stack value 21876 against. You must arrange for this pattern to report an error if 21877 the stack pointer is out of range. 21878 21879 3. If neither of the above are true, GCC will generate code to 21880 periodically "probe" the stack pointer using the values of the 21881 macros defined below. 21882 21883 Normally, you will use the default values of these macros, so GCC will 21884 use the third approach. 21885 21886 -- Macro: STACK_CHECK_BUILTIN 21887 A nonzero value if stack checking is done by the configuration 21888 files in a machine-dependent manner. You should define this macro 21889 if stack checking is require by the ABI of your machine or if you 21890 would like to have to stack checking in some more efficient way 21891 than GCC's portable approach. The default value of this macro is 21892 zero. 21893 21894 -- Macro: STACK_CHECK_PROBE_INTERVAL 21895 An integer representing the interval at which GCC must generate 21896 stack probe instructions. You will normally define this macro to 21897 be no larger than the size of the "guard pages" at the end of a 21898 stack area. The default value of 4096 is suitable for most 21899 systems. 21900 21901 -- Macro: STACK_CHECK_PROBE_LOAD 21902 A integer which is nonzero if GCC should perform the stack probe 21903 as a load instruction and zero if GCC should use a store 21904 instruction. The default is zero, which is the most efficient 21905 choice on most systems. 21906 21907 -- Macro: STACK_CHECK_PROTECT 21908 The number of bytes of stack needed to recover from a stack 21909 overflow, for languages where such a recovery is supported. The 21910 default value of 75 words should be adequate for most machines. 21911 21912 -- Macro: STACK_CHECK_MAX_FRAME_SIZE 21913 The maximum size of a stack frame, in bytes. GCC will generate 21914 probe instructions in non-leaf functions to ensure at least this 21915 many bytes of stack are available. If a stack frame is larger 21916 than this size, stack checking will not be reliable and GCC will 21917 issue a warning. The default is chosen so that GCC only generates 21918 one instruction on most systems. You should normally not change 21919 the default value of this macro. 21920 21921 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE 21922 GCC uses this value to generate the above warning message. It 21923 represents the amount of fixed frame used by a function, not 21924 including space for any callee-saved registers, temporaries and 21925 user variables. You need only specify an upper bound for this 21926 amount and will normally use the default of four words. 21927 21928 -- Macro: STACK_CHECK_MAX_VAR_SIZE 21929 The maximum size, in bytes, of an object that GCC will place in the 21930 fixed area of the stack frame when the user specifies 21931 `-fstack-check'. GCC computed the default from the values of the 21932 above macros and you will normally not need to override that 21933 default. 21934 21935 21936 File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling 21937 21938 15.10.4 Registers That Address the Stack Frame 21939 ---------------------------------------------- 21940 21941 This discusses registers that address the stack frame. 21942 21943 -- Macro: STACK_POINTER_REGNUM 21944 The register number of the stack pointer register, which must also 21945 be a fixed register according to `FIXED_REGISTERS'. On most 21946 machines, the hardware determines which register this is. 21947 21948 -- Macro: FRAME_POINTER_REGNUM 21949 The register number of the frame pointer register, which is used to 21950 access automatic variables in the stack frame. On some machines, 21951 the hardware determines which register this is. On other 21952 machines, you can choose any register you wish for this purpose. 21953 21954 -- Macro: HARD_FRAME_POINTER_REGNUM 21955 On some machines the offset between the frame pointer and starting 21956 offset of the automatic variables is not known until after register 21957 allocation has been done (for example, because the saved registers 21958 are between these two locations). On those machines, define 21959 `FRAME_POINTER_REGNUM' the number of a special, fixed register to 21960 be used internally until the offset is known, and define 21961 `HARD_FRAME_POINTER_REGNUM' to be the actual hard register number 21962 used for the frame pointer. 21963 21964 You should define this macro only in the very rare circumstances 21965 when it is not possible to calculate the offset between the frame 21966 pointer and the automatic variables until after register 21967 allocation has been completed. When this macro is defined, you 21968 must also indicate in your definition of `ELIMINABLE_REGS' how to 21969 eliminate `FRAME_POINTER_REGNUM' into either 21970 `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'. 21971 21972 Do not define this macro if it would be the same as 21973 `FRAME_POINTER_REGNUM'. 21974 21975 -- Macro: ARG_POINTER_REGNUM 21976 The register number of the arg pointer register, which is used to 21977 access the function's argument list. On some machines, this is 21978 the same as the frame pointer register. On some machines, the 21979 hardware determines which register this is. On other machines, 21980 you can choose any register you wish for this purpose. If this is 21981 not the same register as the frame pointer register, then you must 21982 mark it as a fixed register according to `FIXED_REGISTERS', or 21983 arrange to be able to eliminate it (*note Elimination::). 21984 21985 -- Macro: RETURN_ADDRESS_POINTER_REGNUM 21986 The register number of the return address pointer register, which 21987 is used to access the current function's return address from the 21988 stack. On some machines, the return address is not at a fixed 21989 offset from the frame pointer or stack pointer or argument 21990 pointer. This register can be defined to point to the return 21991 address on the stack, and then be converted by `ELIMINABLE_REGS' 21992 into either the frame pointer or stack pointer. 21993 21994 Do not define this macro unless there is no other way to get the 21995 return address from the stack. 21996 21997 -- Macro: STATIC_CHAIN_REGNUM 21998 -- Macro: STATIC_CHAIN_INCOMING_REGNUM 21999 Register numbers used for passing a function's static chain 22000 pointer. If register windows are used, the register number as 22001 seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM', 22002 while the register number as seen by the calling function is 22003 `STATIC_CHAIN_REGNUM'. If these registers are the same, 22004 `STATIC_CHAIN_INCOMING_REGNUM' need not be defined. 22005 22006 The static chain register need not be a fixed register. 22007 22008 If the static chain is passed in memory, these macros should not be 22009 defined; instead, the next two macros should be defined. 22010 22011 -- Macro: STATIC_CHAIN 22012 -- Macro: STATIC_CHAIN_INCOMING 22013 If the static chain is passed in memory, these macros provide rtx 22014 giving `mem' expressions that denote where they are stored. 22015 `STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as 22016 seen by the calling and called functions, respectively. Often the 22017 former will be at an offset from the stack pointer and the latter 22018 at an offset from the frame pointer. 22019 22020 The variables `stack_pointer_rtx', `frame_pointer_rtx', and 22021 `arg_pointer_rtx' will have been initialized prior to the use of 22022 these macros and should be used to refer to those items. 22023 22024 If the static chain is passed in a register, the two previous 22025 macros should be defined instead. 22026 22027 -- Macro: DWARF_FRAME_REGISTERS 22028 This macro specifies the maximum number of hard registers that can 22029 be saved in a call frame. This is used to size data structures 22030 used in DWARF2 exception handling. 22031 22032 Prior to GCC 3.0, this macro was needed in order to establish a 22033 stable exception handling ABI in the face of adding new hard 22034 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is 22035 insulated from changes in the number of hard registers. 22036 Nevertheless, this macro can still be used to reduce the runtime 22037 memory requirements of the exception handling routines, which can 22038 be substantial if the ISA contains a lot of registers that are not 22039 call-saved. 22040 22041 If this macro is not defined, it defaults to 22042 `FIRST_PSEUDO_REGISTER'. 22043 22044 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS 22045 This macro is similar to `DWARF_FRAME_REGISTERS', but is provided 22046 for backward compatibility in pre GCC 3.0 compiled code. 22047 22048 If this macro is not defined, it defaults to 22049 `DWARF_FRAME_REGISTERS'. 22050 22051 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO) 22052 Define this macro if the target's representation for dwarf 22053 registers is different than the internal representation for unwind 22054 column. Given a dwarf register, this macro should return the 22055 internal unwind column number to use instead. 22056 22057 See the PowerPC's SPE target for an example. 22058 22059 -- Macro: DWARF_FRAME_REGNUM (REGNO) 22060 Define this macro if the target's representation for dwarf 22061 registers used in .eh_frame or .debug_frame is different from that 22062 used in other debug info sections. Given a GCC hard register 22063 number, this macro should return the .eh_frame register number. 22064 The default is `DBX_REGISTER_NUMBER (REGNO)'. 22065 22066 22067 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH) 22068 Define this macro to map register numbers held in the call frame 22069 info that GCC has collected using `DWARF_FRAME_REGNUM' to those 22070 that should be output in .debug_frame (`FOR_EH' is zero) and 22071 .eh_frame (`FOR_EH' is nonzero). The default is to return `REGNO'. 22072 22073 22074 22075 File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling 22076 22077 15.10.5 Eliminating Frame Pointer and Arg Pointer 22078 ------------------------------------------------- 22079 22080 This is about eliminating the frame pointer and arg pointer. 22081 22082 -- Macro: FRAME_POINTER_REQUIRED 22083 A C expression which is nonzero if a function must have and use a 22084 frame pointer. This expression is evaluated in the reload pass. 22085 If its value is nonzero the function will have a frame pointer. 22086 22087 The expression can in principle examine the current function and 22088 decide according to the facts, but on most machines the constant 0 22089 or the constant 1 suffices. Use 0 when the machine allows code to 22090 be generated with no frame pointer, and doing so saves some time 22091 or space. Use 1 when there is no possible advantage to avoiding a 22092 frame pointer. 22093 22094 In certain cases, the compiler does not know how to produce valid 22095 code without a frame pointer. The compiler recognizes those cases 22096 and automatically gives the function a frame pointer regardless of 22097 what `FRAME_POINTER_REQUIRED' says. You don't need to worry about 22098 them. 22099 22100 In a function that does not require a frame pointer, the frame 22101 pointer register can be allocated for ordinary usage, unless you 22102 mark it as a fixed register. See `FIXED_REGISTERS' for more 22103 information. 22104 22105 -- Macro: INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR) 22106 A C statement to store in the variable DEPTH-VAR the difference 22107 between the frame pointer and the stack pointer values immediately 22108 after the function prologue. The value would be computed from 22109 information such as the result of `get_frame_size ()' and the 22110 tables of registers `regs_ever_live' and `call_used_regs'. 22111 22112 If `ELIMINABLE_REGS' is defined, this macro will be not be used and 22113 need not be defined. Otherwise, it must be defined even if 22114 `FRAME_POINTER_REQUIRED' is defined to always be true; in that 22115 case, you may set DEPTH-VAR to anything. 22116 22117 -- Macro: ELIMINABLE_REGS 22118 If defined, this macro specifies a table of register pairs used to 22119 eliminate unneeded registers that point into the stack frame. If 22120 it is not defined, the only elimination attempted by the compiler 22121 is to replace references to the frame pointer with references to 22122 the stack pointer. 22123 22124 The definition of this macro is a list of structure 22125 initializations, each of which specifies an original and 22126 replacement register. 22127 22128 On some machines, the position of the argument pointer is not 22129 known until the compilation is completed. In such a case, a 22130 separate hard register must be used for the argument pointer. 22131 This register can be eliminated by replacing it with either the 22132 frame pointer or the argument pointer, depending on whether or not 22133 the frame pointer has been eliminated. 22134 22135 In this case, you might specify: 22136 #define ELIMINABLE_REGS \ 22137 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ 22138 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ 22139 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} 22140 22141 Note that the elimination of the argument pointer with the stack 22142 pointer is specified first since that is the preferred elimination. 22143 22144 -- Macro: CAN_ELIMINATE (FROM-REG, TO-REG) 22145 A C expression that returns nonzero if the compiler is allowed to 22146 try to replace register number FROM-REG with register number 22147 TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is 22148 defined, and will usually be the constant 1, since most of the 22149 cases preventing register elimination are things that the compiler 22150 already knows about. 22151 22152 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR) 22153 This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It 22154 specifies the initial difference between the specified pair of 22155 registers. This macro must be defined if `ELIMINABLE_REGS' is 22156 defined. 22157 22158 22159 File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling 22160 22161 15.10.6 Passing Function Arguments on the Stack 22162 ----------------------------------------------- 22163 22164 The macros in this section control how arguments are passed on the 22165 stack. See the following section for other macros that control passing 22166 certain arguments in registers. 22167 22168 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (tree FNTYPE) 22169 This target hook returns `true' if an argument declared in a 22170 prototype as an integral type smaller than `int' should actually be 22171 passed as an `int'. In addition to avoiding errors in certain 22172 cases of mismatch, it also makes for better code on certain 22173 machines. The default is to not promote prototypes. 22174 22175 -- Macro: PUSH_ARGS 22176 A C expression. If nonzero, push insns will be used to pass 22177 outgoing arguments. If the target machine does not have a push 22178 instruction, set it to zero. That directs GCC to use an alternate 22179 strategy: to allocate the entire argument block and then store the 22180 arguments into it. When `PUSH_ARGS' is nonzero, `PUSH_ROUNDING' 22181 must be defined too. 22182 22183 -- Macro: PUSH_ARGS_REVERSED 22184 A C expression. If nonzero, function arguments will be evaluated 22185 from last to first, rather than from first to last. If this macro 22186 is not defined, it defaults to `PUSH_ARGS' on targets where the 22187 stack and args grow in opposite directions, and 0 otherwise. 22188 22189 -- Macro: PUSH_ROUNDING (NPUSHED) 22190 A C expression that is the number of bytes actually pushed onto the 22191 stack when an instruction attempts to push NPUSHED bytes. 22192 22193 On some machines, the definition 22194 22195 #define PUSH_ROUNDING(BYTES) (BYTES) 22196 22197 will suffice. But on other machines, instructions that appear to 22198 push one byte actually push two bytes in an attempt to maintain 22199 alignment. Then the definition should be 22200 22201 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) 22202 22203 -- Macro: ACCUMULATE_OUTGOING_ARGS 22204 A C expression. If nonzero, the maximum amount of space required 22205 for outgoing arguments will be computed and placed into the 22206 variable `current_function_outgoing_args_size'. No space will be 22207 pushed onto the stack for each call; instead, the function 22208 prologue should increase the stack frame size by this amount. 22209 22210 Setting both `PUSH_ARGS' and `ACCUMULATE_OUTGOING_ARGS' is not 22211 proper. 22212 22213 -- Macro: REG_PARM_STACK_SPACE (FNDECL) 22214 Define this macro if functions should assume that stack space has 22215 been allocated for arguments even when their values are passed in 22216 registers. 22217 22218 The value of this macro is the size, in bytes, of the area 22219 reserved for arguments passed in registers for the function 22220 represented by FNDECL, which can be zero if GCC is calling a 22221 library function. 22222 22223 This space can be allocated by the caller, or be a part of the 22224 machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says 22225 which. 22226 22227 -- Macro: OUTGOING_REG_PARM_STACK_SPACE 22228 Define this if it is the responsibility of the caller to allocate 22229 the area reserved for arguments passed in registers. 22230 22231 If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls 22232 whether the space for these arguments counts in the value of 22233 `current_function_outgoing_args_size'. 22234 22235 -- Macro: STACK_PARMS_IN_REG_PARM_AREA 22236 Define this macro if `REG_PARM_STACK_SPACE' is defined, but the 22237 stack parameters don't skip the area specified by it. 22238 22239 Normally, when a parameter is not passed in registers, it is 22240 placed on the stack beyond the `REG_PARM_STACK_SPACE' area. 22241 Defining this macro suppresses this behavior and causes the 22242 parameter to be passed on the stack in its natural location. 22243 22244 -- Macro: RETURN_POPS_ARGS (FUNDECL, FUNTYPE, STACK-SIZE) 22245 A C expression that should indicate the number of bytes of its own 22246 arguments that a function pops on returning, or 0 if the function 22247 pops no arguments and the caller must therefore pop them all after 22248 the function returns. 22249 22250 FUNDECL is a C variable whose value is a tree node that describes 22251 the function in question. Normally it is a node of type 22252 `FUNCTION_DECL' that describes the declaration of the function. 22253 From this you can obtain the `DECL_ATTRIBUTES' of the function. 22254 22255 FUNTYPE is a C variable whose value is a tree node that describes 22256 the function in question. Normally it is a node of type 22257 `FUNCTION_TYPE' that describes the data type of the function. 22258 From this it is possible to obtain the data types of the value and 22259 arguments (if known). 22260 22261 When a call to a library function is being considered, FUNDECL 22262 will contain an identifier node for the library function. Thus, if 22263 you need to distinguish among various library functions, you can 22264 do so by their names. Note that "library function" in this 22265 context means a function used to perform arithmetic, whose name is 22266 known specially in the compiler and was not mentioned in the C 22267 code being compiled. 22268 22269 STACK-SIZE is the number of bytes of arguments passed on the 22270 stack. If a variable number of bytes is passed, it is zero, and 22271 argument popping will always be the responsibility of the calling 22272 function. 22273 22274 On the VAX, all functions always pop their arguments, so the 22275 definition of this macro is STACK-SIZE. On the 68000, using the 22276 standard calling convention, no functions pop their arguments, so 22277 the value of the macro is always 0 in this case. But an 22278 alternative calling convention is available in which functions 22279 that take a fixed number of arguments pop them but other functions 22280 (such as `printf') pop nothing (the caller pops all). When this 22281 convention is in use, FUNTYPE is examined to determine whether a 22282 function takes a fixed number of arguments. 22283 22284 -- Macro: CALL_POPS_ARGS (CUM) 22285 A C expression that should indicate the number of bytes a call 22286 sequence pops off the stack. It is added to the value of 22287 `RETURN_POPS_ARGS' when compiling a function call. 22288 22289 CUM is the variable in which all arguments to the called function 22290 have been accumulated. 22291 22292 On certain architectures, such as the SH5, a call trampoline is 22293 used that pops certain registers off the stack, depending on the 22294 arguments that have been passed to the function. Since this is a 22295 property of the call site, not of the called function, 22296 `RETURN_POPS_ARGS' is not appropriate. 22297 22298 22299 File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling 22300 22301 15.10.7 Passing Arguments in Registers 22302 -------------------------------------- 22303 22304 This section describes the macros which let you control how various 22305 types of arguments are passed in registers or how they are arranged in 22306 the stack. 22307 22308 -- Macro: FUNCTION_ARG (CUM, MODE, TYPE, NAMED) 22309 A C expression that controls whether a function argument is passed 22310 in a register, and which register. 22311 22312 The arguments are CUM, which summarizes all the previous 22313 arguments; MODE, the machine mode of the argument; TYPE, the data 22314 type of the argument as a tree node or 0 if that is not known 22315 (which happens for C support library functions); and NAMED, which 22316 is 1 for an ordinary argument and 0 for nameless arguments that 22317 correspond to `...' in the called function's prototype. TYPE can 22318 be an incomplete type if a syntax error has previously occurred. 22319 22320 The value of the expression is usually either a `reg' RTX for the 22321 hard register in which to pass the argument, or zero to pass the 22322 argument on the stack. 22323 22324 For machines like the VAX and 68000, where normally all arguments 22325 are pushed, zero suffices as a definition. 22326 22327 The value of the expression can also be a `parallel' RTX. This is 22328 used when an argument is passed in multiple locations. The mode 22329 of the `parallel' should be the mode of the entire argument. The 22330 `parallel' holds any number of `expr_list' pairs; each one 22331 describes where part of the argument is passed. In each 22332 `expr_list' the first operand must be a `reg' RTX for the hard 22333 register in which to pass this part of the argument, and the mode 22334 of the register RTX indicates how large this part of the argument 22335 is. The second operand of the `expr_list' is a `const_int' which 22336 gives the offset in bytes into the entire argument of where this 22337 part starts. As a special exception the first `expr_list' in the 22338 `parallel' RTX may have a first operand of zero. This indicates 22339 that the entire argument is also stored on the stack. 22340 22341 The last time this macro is called, it is called with `MODE == 22342 VOIDmode', and its result is passed to the `call' or `call_value' 22343 pattern as operands 2 and 3 respectively. 22344 22345 The usual way to make the ISO library `stdarg.h' work on a machine 22346 where some arguments are usually passed in registers, is to cause 22347 nameless arguments to be passed on the stack instead. This is done 22348 by making `FUNCTION_ARG' return 0 whenever NAMED is 0. 22349 22350 You may use the hook `targetm.calls.must_pass_in_stack' in the 22351 definition of this macro to determine if this argument is of a 22352 type that must be passed in the stack. If `REG_PARM_STACK_SPACE' 22353 is not defined and `FUNCTION_ARG' returns nonzero for such an 22354 argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is 22355 defined, the argument will be computed in the stack and then 22356 loaded into a register. 22357 22358 -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (enum machine_mode 22359 MODE, tree TYPE) 22360 This target hook should return `true' if we should not pass TYPE 22361 solely in registers. The file `expr.h' defines a definition that 22362 is usually appropriate, refer to `expr.h' for additional 22363 documentation. 22364 22365 -- Macro: FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED) 22366 Define this macro if the target machine has "register windows", so 22367 that the register in which a function sees an arguments is not 22368 necessarily the same as the one in which the caller passed the 22369 argument. 22370 22371 For such machines, `FUNCTION_ARG' computes the register in which 22372 the caller passes the value, and `FUNCTION_INCOMING_ARG' should be 22373 defined in a similar fashion to tell the function being called 22374 where the arguments will arrive. 22375 22376 If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves 22377 both purposes. 22378 22379 -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (CUMULATIVE_ARGS *CUM, 22380 enum machine_mode MODE, tree TYPE, bool NAMED) 22381 This target hook returns the number of bytes at the beginning of an 22382 argument that must be put in registers. The value must be zero for 22383 arguments that are passed entirely in registers or that are 22384 entirely pushed on the stack. 22385 22386 On some machines, certain arguments must be passed partially in 22387 registers and partially in memory. On these machines, typically 22388 the first few words of arguments are passed in registers, and the 22389 rest on the stack. If a multi-word argument (a `double' or a 22390 structure) crosses that boundary, its first few words must be 22391 passed in registers and the rest must be pushed. This macro tells 22392 the compiler when this occurs, and how many bytes should go in 22393 registers. 22394 22395 `FUNCTION_ARG' for these arguments should return the first 22396 register to be used by the caller for this argument; likewise 22397 `FUNCTION_INCOMING_ARG', for the called function. 22398 22399 -- Target Hook: bool TARGET_PASS_BY_REFERENCE (CUMULATIVE_ARGS *CUM, 22400 enum machine_mode MODE, tree TYPE, bool NAMED) 22401 This target hook should return `true' if an argument at the 22402 position indicated by CUM should be passed by reference. This 22403 predicate is queried after target independent reasons for being 22404 passed by reference, such as `TREE_ADDRESSABLE (type)'. 22405 22406 If the hook returns true, a copy of that argument is made in 22407 memory and a pointer to the argument is passed instead of the 22408 argument itself. The pointer is passed in whatever way is 22409 appropriate for passing a pointer to that type. 22410 22411 -- Target Hook: bool TARGET_CALLEE_COPIES (CUMULATIVE_ARGS *CUM, enum 22412 machine_mode MODE, tree TYPE, bool NAMED) 22413 The function argument described by the parameters to this hook is 22414 known to be passed by reference. The hook should return true if 22415 the function argument should be copied by the callee instead of 22416 copied by the caller. 22417 22418 For any argument for which the hook returns true, if it can be 22419 determined that the argument is not modified, then a copy need not 22420 be generated. 22421 22422 The default version of this hook always returns false. 22423 22424 -- Macro: CUMULATIVE_ARGS 22425 A C type for declaring a variable that is used as the first 22426 argument of `FUNCTION_ARG' and other related values. For some 22427 target machines, the type `int' suffices and can hold the number 22428 of bytes of argument so far. 22429 22430 There is no need to record in `CUMULATIVE_ARGS' anything about the 22431 arguments that have been passed on the stack. The compiler has 22432 other variables to keep track of that. For target machines on 22433 which all arguments are passed on the stack, there is no need to 22434 store anything in `CUMULATIVE_ARGS'; however, the data structure 22435 must exist and should not be empty, so use `int'. 22436 22437 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL, 22438 N_NAMED_ARGS) 22439 A C statement (sans semicolon) for initializing the variable CUM 22440 for the state at the beginning of the argument list. The variable 22441 has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node 22442 for the data type of the function which will receive the args, or 22443 0 if the args are to a compiler support library function. For 22444 direct calls that are not libcalls, FNDECL contain the declaration 22445 node of the function. FNDECL is also set when 22446 `INIT_CUMULATIVE_ARGS' is used to find arguments for the function 22447 being compiled. N_NAMED_ARGS is set to the number of named 22448 arguments, including a structure return address if it is passed as 22449 a parameter, when making a call. When processing incoming 22450 arguments, N_NAMED_ARGS is set to -1. 22451 22452 When processing a call to a compiler support library function, 22453 LIBNAME identifies which one. It is a `symbol_ref' rtx which 22454 contains the name of the function, as a string. LIBNAME is 0 when 22455 an ordinary C function call is being processed. Thus, each time 22456 this macro is called, either LIBNAME or FNTYPE is nonzero, but 22457 never both of them at once. 22458 22459 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME) 22460 Like `INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, 22461 it gets a `MODE' argument instead of FNTYPE, that would be `NULL'. 22462 INDIRECT would always be zero, too. If this macro is not 22463 defined, `INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is 22464 used instead. 22465 22466 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME) 22467 Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of 22468 finding the arguments for the function being compiled. If this 22469 macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead. 22470 22471 The value passed for LIBNAME is always 0, since library routines 22472 with special calling conventions are never compiled with GCC. The 22473 argument LIBNAME exists for symmetry with `INIT_CUMULATIVE_ARGS'. 22474 22475 -- Macro: FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED) 22476 A C statement (sans semicolon) to update the summarizer variable 22477 CUM to advance past an argument in the argument list. The values 22478 MODE, TYPE and NAMED describe that argument. Once this is done, 22479 the variable CUM is suitable for analyzing the _following_ 22480 argument with `FUNCTION_ARG', etc. 22481 22482 This macro need not do anything if the argument in question was 22483 passed on the stack. The compiler knows how to track the amount 22484 of stack space used for arguments without any special help. 22485 22486 -- Macro: FUNCTION_ARG_PADDING (MODE, TYPE) 22487 If defined, a C expression which determines whether, and in which 22488 direction, to pad out an argument with extra space. The value 22489 should be of type `enum direction': either `upward' to pad above 22490 the argument, `downward' to pad below, or `none' to inhibit 22491 padding. 22492 22493 The _amount_ of padding is always just enough to reach the next 22494 multiple of `FUNCTION_ARG_BOUNDARY'; this macro does not control 22495 it. 22496 22497 This macro has a default definition which is right for most 22498 systems. For little-endian machines, the default is to pad 22499 upward. For big-endian machines, the default is to pad downward 22500 for an argument of constant size shorter than an `int', and upward 22501 otherwise. 22502 22503 -- Macro: PAD_VARARGS_DOWN 22504 If defined, a C expression which determines whether the default 22505 implementation of va_arg will attempt to pad down before reading 22506 the next argument, if that argument is smaller than its aligned 22507 space as controlled by `PARM_BOUNDARY'. If this macro is not 22508 defined, all such arguments are padded down if `BYTES_BIG_ENDIAN' 22509 is true. 22510 22511 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST) 22512 Specify padding for the last element of a block move between 22513 registers and memory. FIRST is nonzero if this is the only 22514 element. Defining this macro allows better control of register 22515 function parameters on big-endian machines, without using 22516 `PARALLEL' rtl. In particular, `MUST_PASS_IN_STACK' need not test 22517 padding and mode of types in registers, as there is no longer a 22518 "wrong" part of a register; For example, a three byte aggregate 22519 may be passed in the high part of a register if so required. 22520 22521 -- Macro: FUNCTION_ARG_BOUNDARY (MODE, TYPE) 22522 If defined, a C expression that gives the alignment boundary, in 22523 bits, of an argument with the specified mode and type. If it is 22524 not defined, `PARM_BOUNDARY' is used for all arguments. 22525 22526 -- Macro: FUNCTION_ARG_REGNO_P (REGNO) 22527 A C expression that is nonzero if REGNO is the number of a hard 22528 register in which function arguments are sometimes passed. This 22529 does _not_ include implicit arguments such as the static chain and 22530 the structure-value address. On many machines, no registers can be 22531 used for this purpose since all function arguments are pushed on 22532 the stack. 22533 22534 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (tree TYPE) 22535 This hook should return true if parameter of type TYPE are passed 22536 as two scalar parameters. By default, GCC will attempt to pack 22537 complex arguments into the target's word size. Some ABIs require 22538 complex arguments to be split and treated as their individual 22539 components. For example, on AIX64, complex floats should be 22540 passed in a pair of floating point registers, even though a 22541 complex float would fit in one 64-bit floating point register. 22542 22543 The default value of this hook is `NULL', which is treated as 22544 always false. 22545 22546 -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void) 22547 This hook returns a type node for `va_list' for the target. The 22548 default version of the hook returns `void*'. 22549 22550 -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree 22551 TYPE, tree *PRE_P, tree *POST_P) 22552 This hook performs target-specific gimplification of 22553 `VA_ARG_EXPR'. The first two parameters correspond to the 22554 arguments to `va_arg'; the latter two are as in 22555 `gimplify.c:gimplify_expr'. 22556 22557 -- Target Hook: bool TARGET_VALID_POINTER_MODE (enum machine_mode MODE) 22558 Define this to return nonzero if the port can handle pointers with 22559 machine mode MODE. The default version of this hook returns true 22560 for both `ptr_mode' and `Pmode'. 22561 22562 -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (enum machine_mode 22563 MODE) 22564 Define this to return nonzero if the port is prepared to handle 22565 insns involving scalar mode MODE. For a scalar mode to be 22566 considered supported, all the basic arithmetic and comparisons 22567 must work. 22568 22569 The default version of this hook returns true for any mode 22570 required to handle the basic C types (as defined by the port). 22571 Included here are the double-word arithmetic supported by the code 22572 in `optabs.c'. 22573 22574 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (enum machine_mode 22575 MODE) 22576 Define this to return nonzero if the port is prepared to handle 22577 insns involving vector mode MODE. At the very least, it must have 22578 move patterns for this mode. 22579 22580 22581 File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 22582 22583 15.10.8 How Scalar Function Values Are Returned 22584 ----------------------------------------------- 22585 22586 This section discusses the macros that control returning scalars as 22587 values--values that can fit in registers. 22588 22589 -- Target Hook: rtx TARGET_FUNCTION_VALUE (tree RET_TYPE, tree 22590 FN_DECL_OR_TYPE, bool OUTGOING) 22591 Define this to return an RTX representing the place where a 22592 function returns or receives a value of data type RET_TYPE, a tree 22593 node node representing a data type. FN_DECL_OR_TYPE is a tree node 22594 representing `FUNCTION_DECL' or `FUNCTION_TYPE' of a function 22595 being called. If OUTGOING is false, the hook should compute the 22596 register in which the caller will see the return value. 22597 Otherwise, the hook should return an RTX representing the place 22598 where a function returns a value. 22599 22600 On many machines, only `TYPE_MODE (RET_TYPE)' is relevant. 22601 (Actually, on most machines, scalar values are returned in the same 22602 place regardless of mode.) The value of the expression is usually 22603 a `reg' RTX for the hard register where the return value is stored. 22604 The value can also be a `parallel' RTX, if the return value is in 22605 multiple places. See `FUNCTION_ARG' for an explanation of the 22606 `parallel' form. 22607 22608 If `TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply 22609 the same promotion rules specified in `PROMOTE_MODE' if VALTYPE is 22610 a scalar type. 22611 22612 If the precise function being called is known, FUNC is a tree node 22613 (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 22614 makes it possible to use a different value-returning convention 22615 for specific functions when all their calls are known. 22616 22617 Some target machines have "register windows" so that the register 22618 in which a function returns its value is not the same as the one 22619 in which the caller sees the value. For such machines, you should 22620 return different RTX depending on OUTGOING. 22621 22622 `TARGET_FUNCTION_VALUE' is not used for return values with 22623 aggregate data types, because these are returned in another way. 22624 See `TARGET_STRUCT_VALUE_RTX' and related macros, below. 22625 22626 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC) 22627 This macro has been deprecated. Use `TARGET_FUNCTION_VALUE' for a 22628 new target instead. 22629 22630 -- Macro: FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC) 22631 This macro has been deprecated. Use `TARGET_FUNCTION_VALUE' for a 22632 new target instead. 22633 22634 -- Macro: LIBCALL_VALUE (MODE) 22635 A C expression to create an RTX representing the place where a 22636 library function returns a value of mode MODE. If the precise 22637 function being called is known, FUNC is a tree node 22638 (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 22639 makes it possible to use a different value-returning convention 22640 for specific functions when all their calls are known. 22641 22642 Note that "library function" in this context means a compiler 22643 support routine, used to perform arithmetic, whose name is known 22644 specially by the compiler and was not mentioned in the C code being 22645 compiled. 22646 22647 The definition of `LIBRARY_VALUE' need not be concerned aggregate 22648 data types, because none of the library functions returns such 22649 types. 22650 22651 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO) 22652 A C expression that is nonzero if REGNO is the number of a hard 22653 register in which the values of called function may come back. 22654 22655 A register whose use for returning values is limited to serving as 22656 the second of a pair (for a value of type `double', say) need not 22657 be recognized by this macro. So for most machines, this definition 22658 suffices: 22659 22660 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) 22661 22662 If the machine has register windows, so that the caller and the 22663 called function use different registers for the return value, this 22664 macro should recognize only the caller's register numbers. 22665 22666 -- Macro: APPLY_RESULT_SIZE 22667 Define this macro if `untyped_call' and `untyped_return' need more 22668 space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and 22669 restoring an arbitrary return value. 22670 22671 -- Target Hook: bool TARGET_RETURN_IN_MSB (tree TYPE) 22672 This hook should return true if values of type TYPE are returned 22673 at the most significant end of a register (in other words, if they 22674 are padded at the least significant end). You can assume that TYPE 22675 is returned in a register; the caller is required to check this. 22676 22677 Note that the register provided by `TARGET_FUNCTION_VALUE' must be 22678 able to hold the complete return value. For example, if a 1-, 2- 22679 or 3-byte structure is returned at the most significant end of a 22680 4-byte register, `TARGET_FUNCTION_VALUE' should provide an 22681 `SImode' rtx. 22682 22683 22684 File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 22685 22686 15.10.9 How Large Values Are Returned 22687 ------------------------------------- 22688 22689 When a function value's mode is `BLKmode' (and in some other cases), 22690 the value is not returned according to `TARGET_FUNCTION_VALUE' (*note 22691 Scalar Return::). Instead, the caller passes the address of a block of 22692 memory in which the value should be stored. This address is called the 22693 "structure value address". 22694 22695 This section describes how to control returning structure values in 22696 memory. 22697 22698 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (tree TYPE, tree FNTYPE) 22699 This target hook should return a nonzero value to say to return the 22700 function value in memory, just as large structures are always 22701 returned. Here TYPE will be the data type of the value, and FNTYPE 22702 will be the type of the function doing the returning, or `NULL' for 22703 libcalls. 22704 22705 Note that values of mode `BLKmode' must be explicitly handled by 22706 this function. Also, the option `-fpcc-struct-return' takes 22707 effect regardless of this macro. On most systems, it is possible 22708 to leave the hook undefined; this causes a default definition to 22709 be used, whose value is the constant 1 for `BLKmode' values, and 0 22710 otherwise. 22711 22712 Do not use this hook to indicate that structures and unions should 22713 always be returned in memory. You should instead use 22714 `DEFAULT_PCC_STRUCT_RETURN' to indicate this. 22715 22716 -- Macro: DEFAULT_PCC_STRUCT_RETURN 22717 Define this macro to be 1 if all structure and union return values 22718 must be in memory. Since this results in slower code, this should 22719 be defined only if needed for compatibility with other compilers 22720 or with an ABI. If you define this macro to be 0, then the 22721 conventions used for structure and union return values are decided 22722 by the `TARGET_RETURN_IN_MEMORY' target hook. 22723 22724 If not defined, this defaults to the value 1. 22725 22726 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING) 22727 This target hook should return the location of the structure value 22728 address (normally a `mem' or `reg'), or 0 if the address is passed 22729 as an "invisible" first argument. Note that FNDECL may be `NULL', 22730 for libcalls. You do not need to define this target hook if the 22731 address is always passed as an "invisible" first argument. 22732 22733 On some architectures the place where the structure value address 22734 is found by the called function is not the same place that the 22735 caller put it. This can be due to register windows, or it could 22736 be because the function prologue moves it to a different place. 22737 INCOMING is `1' or `2' when the location is needed in the context 22738 of the called function, and `0' in the context of the caller. 22739 22740 If INCOMING is nonzero and the address is to be found on the 22741 stack, return a `mem' which refers to the frame pointer. If 22742 INCOMING is `2', the result is being used to fetch the structure 22743 value address at the beginning of a function. If you need to emit 22744 adjusting code, you should do it at this point. 22745 22746 -- Macro: PCC_STATIC_STRUCT_RETURN 22747 Define this macro if the usual system convention on the target 22748 machine for returning structures and unions is for the called 22749 function to return the address of a static variable containing the 22750 value. 22751 22752 Do not define this if the usual system convention is for the 22753 caller to pass an address to the subroutine. 22754 22755 This macro has effect in `-fpcc-struct-return' mode, but it does 22756 nothing when you use `-freg-struct-return' mode. 22757 22758 22759 File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling 22760 22761 15.10.10 Caller-Saves Register Allocation 22762 ----------------------------------------- 22763 22764 If you enable it, GCC can save registers around function calls. This 22765 makes it possible to use call-clobbered registers to hold variables that 22766 must live across calls. 22767 22768 -- Macro: CALLER_SAVE_PROFITABLE (REFS, CALLS) 22769 A C expression to determine whether it is worthwhile to consider 22770 placing a pseudo-register in a call-clobbered hard register and 22771 saving and restoring it around each function call. The expression 22772 should be 1 when this is worth doing, and 0 otherwise. 22773 22774 If you don't define this macro, a default is used which is good on 22775 most machines: `4 * CALLS < REFS'. 22776 22777 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS) 22778 A C expression specifying which mode is required for saving NREGS 22779 of a pseudo-register in call-clobbered hard register REGNO. If 22780 REGNO is unsuitable for caller save, `VOIDmode' should be 22781 returned. For most machines this macro need not be defined since 22782 GCC will select the smallest suitable mode. 22783 22784 22785 File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling 22786 22787 15.10.11 Function Entry and Exit 22788 -------------------------------- 22789 22790 This section describes the macros that output function entry 22791 ("prologue") and exit ("epilogue") code. 22792 22793 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE, 22794 HOST_WIDE_INT SIZE) 22795 If defined, a function that outputs the assembler code for entry 22796 to a function. The prologue is responsible for setting up the 22797 stack frame, initializing the frame pointer register, saving 22798 registers that must be saved, and allocating SIZE additional bytes 22799 of storage for the local variables. SIZE is an integer. FILE is 22800 a stdio stream to which the assembler code should be output. 22801 22802 The label for the beginning of the function need not be output by 22803 this macro. That has already been done when the macro is run. 22804 22805 To determine which registers to save, the macro can refer to the 22806 array `regs_ever_live': element R is nonzero if hard register R is 22807 used anywhere within the function. This implies the function 22808 prologue should save register R, provided it is not one of the 22809 call-used registers. (`TARGET_ASM_FUNCTION_EPILOGUE' must 22810 likewise use `regs_ever_live'.) 22811 22812 On machines that have "register windows", the function entry code 22813 does not save on the stack the registers that are in the windows, 22814 even if they are supposed to be preserved by function calls; 22815 instead it takes appropriate steps to "push" the register stack, 22816 if any non-call-used registers are used in the function. 22817 22818 On machines where functions may or may not have frame-pointers, the 22819 function entry code must vary accordingly; it must set up the frame 22820 pointer if one is wanted, and not otherwise. To determine whether 22821 a frame pointer is in wanted, the macro can refer to the variable 22822 `frame_pointer_needed'. The variable's value will be 1 at run 22823 time in a function that needs a frame pointer. *Note 22824 Elimination::. 22825 22826 The function entry code is responsible for allocating any stack 22827 space required for the function. This stack space consists of the 22828 regions listed below. In most cases, these regions are allocated 22829 in the order listed, with the last listed region closest to the 22830 top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is 22831 defined, and the highest address if it is not defined). You can 22832 use a different order for a machine if doing so is more convenient 22833 or required for compatibility reasons. Except in cases where 22834 required by standard or by a debugger, there is no reason why the 22835 stack layout used by GCC need agree with that used by other 22836 compilers for a machine. 22837 22838 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE) 22839 If defined, a function that outputs assembler code at the end of a 22840 prologue. This should be used when the function prologue is being 22841 emitted as RTL, and you have some extra assembler that needs to be 22842 emitted. *Note prologue instruction pattern::. 22843 22844 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE) 22845 If defined, a function that outputs assembler code at the start of 22846 an epilogue. This should be used when the function epilogue is 22847 being emitted as RTL, and you have some extra assembler that needs 22848 to be emitted. *Note epilogue instruction pattern::. 22849 22850 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE, 22851 HOST_WIDE_INT SIZE) 22852 If defined, a function that outputs the assembler code for exit 22853 from a function. The epilogue is responsible for restoring the 22854 saved registers and stack pointer to their values when the 22855 function was called, and returning control to the caller. This 22856 macro takes the same arguments as the macro 22857 `TARGET_ASM_FUNCTION_PROLOGUE', and the registers to restore are 22858 determined from `regs_ever_live' and `CALL_USED_REGISTERS' in the 22859 same way. 22860 22861 On some machines, there is a single instruction that does all the 22862 work of returning from the function. On these machines, give that 22863 instruction the name `return' and do not define the macro 22864 `TARGET_ASM_FUNCTION_EPILOGUE' at all. 22865 22866 Do not define a pattern named `return' if you want the 22867 `TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target 22868 switches to control whether return instructions or epilogues are 22869 used, define a `return' pattern with a validity condition that 22870 tests the target switches appropriately. If the `return' 22871 pattern's validity condition is false, epilogues will be used. 22872 22873 On machines where functions may or may not have frame-pointers, the 22874 function exit code must vary accordingly. Sometimes the code for 22875 these two cases is completely different. To determine whether a 22876 frame pointer is wanted, the macro can refer to the variable 22877 `frame_pointer_needed'. The variable's value will be 1 when 22878 compiling a function that needs a frame pointer. 22879 22880 Normally, `TARGET_ASM_FUNCTION_PROLOGUE' and 22881 `TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially. 22882 The C variable `current_function_is_leaf' is nonzero for such a 22883 function. *Note Leaf Functions::. 22884 22885 On some machines, some functions pop their arguments on exit while 22886 others leave that for the caller to do. For example, the 68020 22887 when given `-mrtd' pops arguments in functions that take a fixed 22888 number of arguments. 22889 22890 Your definition of the macro `RETURN_POPS_ARGS' decides which 22891 functions pop their own arguments. `TARGET_ASM_FUNCTION_EPILOGUE' 22892 needs to know what was decided. The variable that is called 22893 `current_function_pops_args' is the number of bytes of its 22894 arguments that a function should pop. *Note Scalar Return::. 22895 22896 * A region of `current_function_pretend_args_size' bytes of 22897 uninitialized space just underneath the first argument arriving on 22898 the stack. (This may not be at the very start of the allocated 22899 stack region if the calling sequence has pushed anything else 22900 since pushing the stack arguments. But usually, on such machines, 22901 nothing else has been pushed yet, because the function prologue 22902 itself does all the pushing.) This region is used on machines 22903 where an argument may be passed partly in registers and partly in 22904 memory, and, in some cases to support the features in `<stdarg.h>'. 22905 22906 * An area of memory used to save certain registers used by the 22907 function. The size of this area, which may also include space for 22908 such things as the return address and pointers to previous stack 22909 frames, is machine-specific and usually depends on which registers 22910 have been used in the function. Machines with register windows 22911 often do not require a save area. 22912 22913 * A region of at least SIZE bytes, possibly rounded up to an 22914 allocation boundary, to contain the local variables of the 22915 function. On some machines, this region and the save area may 22916 occur in the opposite order, with the save area closer to the top 22917 of the stack. 22918 22919 * Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a region of 22920 `current_function_outgoing_args_size' bytes to be used for outgoing 22921 argument lists of the function. *Note Stack Arguments::. 22922 22923 -- Macro: EXIT_IGNORE_STACK 22924 Define this macro as a C expression that is nonzero if the return 22925 instruction or the function epilogue ignores the value of the stack 22926 pointer; in other words, if it is safe to delete an instruction to 22927 adjust the stack pointer before a return from the function. The 22928 default is 0. 22929 22930 Note that this macro's value is relevant only for functions for 22931 which frame pointers are maintained. It is never safe to delete a 22932 final stack adjustment in a function that has no frame pointer, 22933 and the compiler knows this regardless of `EXIT_IGNORE_STACK'. 22934 22935 -- Macro: EPILOGUE_USES (REGNO) 22936 Define this macro as a C expression that is nonzero for registers 22937 that are used by the epilogue or the `return' pattern. The stack 22938 and frame pointer registers are already assumed to be used as 22939 needed. 22940 22941 -- Macro: EH_USES (REGNO) 22942 Define this macro as a C expression that is nonzero for registers 22943 that are used by the exception handling mechanism, and so should 22944 be considered live on entry to an exception edge. 22945 22946 -- Macro: DELAY_SLOTS_FOR_EPILOGUE 22947 Define this macro if the function epilogue contains delay slots to 22948 which instructions from the rest of the function can be "moved". 22949 The definition should be a C expression whose value is an integer 22950 representing the number of delay slots there. 22951 22952 -- Macro: ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N) 22953 A C expression that returns 1 if INSN can be placed in delay slot 22954 number N of the epilogue. 22955 22956 The argument N is an integer which identifies the delay slot now 22957 being considered (since different slots may have different rules of 22958 eligibility). It is never negative and is always less than the 22959 number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE' 22960 returns). If you reject a particular insn for a given delay slot, 22961 in principle, it may be reconsidered for a subsequent delay slot. 22962 Also, other insns may (at least in principle) be considered for 22963 the so far unfilled delay slot. 22964 22965 The insns accepted to fill the epilogue delay slots are put in an 22966 RTL list made with `insn_list' objects, stored in the variable 22967 `current_function_epilogue_delay_list'. The insn for the first 22968 delay slot comes first in the list. Your definition of the macro 22969 `TARGET_ASM_FUNCTION_EPILOGUE' should fill the delay slots by 22970 outputting the insns in this list, usually by calling 22971 `final_scan_insn'. 22972 22973 You need not define this macro if you did not define 22974 `DELAY_SLOTS_FOR_EPILOGUE'. 22975 22976 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree 22977 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT 22978 VCALL_OFFSET, tree FUNCTION) 22979 A function that outputs the assembler code for a thunk function, 22980 used to implement C++ virtual function calls with multiple 22981 inheritance. The thunk acts as a wrapper around a virtual 22982 function, adjusting the implicit object parameter before handing 22983 control off to the real function. 22984 22985 First, emit code to add the integer DELTA to the location that 22986 contains the incoming first argument. Assume that this argument 22987 contains a pointer, and is the one used to pass the `this' pointer 22988 in C++. This is the incoming argument _before_ the function 22989 prologue, e.g. `%o0' on a sparc. The addition must preserve the 22990 values of all other incoming arguments. 22991 22992 Then, if VCALL_OFFSET is nonzero, an additional adjustment should 22993 be made after adding `delta'. In particular, if P is the adjusted 22994 pointer, the following adjustment should be made: 22995 22996 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)] 22997 22998 After the additions, emit code to jump to FUNCTION, which is a 22999 `FUNCTION_DECL'. This is a direct pure jump, not a call, and does 23000 not touch the return address. Hence returning from FUNCTION will 23001 return to whoever called the current `thunk'. 23002 23003 The effect must be as if FUNCTION had been called directly with 23004 the adjusted first argument. This macro is responsible for 23005 emitting all of the code for a thunk function; 23006 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' 23007 are not invoked. 23008 23009 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already 23010 been extracted from it.) It might possibly be useful on some 23011 targets, but probably not. 23012 23013 If you do not define this macro, the target-independent code in 23014 the C++ front end will generate a less efficient heavyweight thunk 23015 that calls FUNCTION instead of jumping to it. The generic 23016 approach does not support varargs. 23017 23018 -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (tree 23019 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT 23020 VCALL_OFFSET, tree FUNCTION) 23021 A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would 23022 be able to output the assembler code for the thunk function 23023 specified by the arguments it is passed, and false otherwise. In 23024 the latter case, the generic approach will be used by the C++ 23025 front end, with the limitations previously exposed. 23026 23027 23028 File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling 23029 23030 15.10.12 Generating Code for Profiling 23031 -------------------------------------- 23032 23033 These macros will help you generate code for profiling. 23034 23035 -- Macro: FUNCTION_PROFILER (FILE, LABELNO) 23036 A C statement or compound statement to output to FILE some 23037 assembler code to call the profiling subroutine `mcount'. 23038 23039 The details of how `mcount' expects to be called are determined by 23040 your operating system environment, not by GCC. To figure them out, 23041 compile a small program for profiling using the system's installed 23042 C compiler and look at the assembler code that results. 23043 23044 Older implementations of `mcount' expect the address of a counter 23045 variable to be loaded into some register. The name of this 23046 variable is `LP' followed by the number LABELNO, so you would 23047 generate the name using `LP%d' in a `fprintf'. 23048 23049 -- Macro: PROFILE_HOOK 23050 A C statement or compound statement to output to FILE some assembly 23051 code to call the profiling subroutine `mcount' even the target does 23052 not support profiling. 23053 23054 -- Macro: NO_PROFILE_COUNTERS 23055 Define this macro to be an expression with a nonzero value if the 23056 `mcount' subroutine on your system does not need a counter variable 23057 allocated for each function. This is true for almost all modern 23058 implementations. If you define this macro, you must not use the 23059 LABELNO argument to `FUNCTION_PROFILER'. 23060 23061 -- Macro: PROFILE_BEFORE_PROLOGUE 23062 Define this macro if the code for function profiling should come 23063 before the function prologue. Normally, the profiling code comes 23064 after. 23065 23066 23067 File: gccint.info, Node: Tail Calls, Next: Stack Smashing Protection, Prev: Profiling, Up: Stack and Calling 23068 23069 15.10.13 Permitting tail calls 23070 ------------------------------ 23071 23072 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree 23073 EXP) 23074 True if it is ok to do sibling call optimization for the specified 23075 call expression EXP. DECL will be the called function, or `NULL' 23076 if this is an indirect call. 23077 23078 It is not uncommon for limitations of calling conventions to 23079 prevent tail calls to functions outside the current unit of 23080 translation, or during PIC compilation. The hook is used to 23081 enforce these restrictions, as the `sibcall' md pattern can not 23082 fail, or fall over to a "normal" call. The criteria for 23083 successful sibling call optimization may vary greatly between 23084 different architectures. 23085 23086 -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap *REGS) 23087 Add any hard registers to REGS that are live on entry to the 23088 function. This hook only needs to be defined to provide registers 23089 that cannot be found by examination of FUNCTION_ARG_REGNO_P, the 23090 callee saved registers, STATIC_CHAIN_INCOMING_REGNUM, 23091 STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX, 23092 FRAME_POINTER_REGNUM, EH_USES, FRAME_POINTER_REGNUM, 23093 ARG_POINTER_REGNUM, and the PIC_OFFSET_TABLE_REGNUM. 23094 23095 23096 File: gccint.info, Node: Stack Smashing Protection, Prev: Tail Calls, Up: Stack and Calling 23097 23098 15.10.14 Stack smashing protection 23099 ---------------------------------- 23100 23101 -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void) 23102 This hook returns a `DECL' node for the external variable to use 23103 for the stack protection guard. This variable is initialized by 23104 the runtime to some random value and is used to initialize the 23105 guard value that is placed at the top of the local stack frame. 23106 The type of this variable must be `ptr_type_node'. 23107 23108 The default version of this hook creates a variable called 23109 `__stack_chk_guard', which is normally defined in `libgcc2.c'. 23110 23111 -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void) 23112 This hook returns a tree expression that alerts the runtime that 23113 the stack protect guard variable has been modified. This 23114 expression should involve a call to a `noreturn' function. 23115 23116 The default version of this hook invokes a function called 23117 `__stack_chk_fail', taking no arguments. This function is 23118 normally defined in `libgcc2.c'. 23119 23120 23121 File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros 23122 23123 15.11 Implementing the Varargs Macros 23124 ===================================== 23125 23126 GCC comes with an implementation of `<varargs.h>' and `<stdarg.h>' that 23127 work without change on machines that pass arguments on the stack. 23128 Other machines require their own implementations of varargs, and the 23129 two machine independent header files must have conditionals to include 23130 it. 23131 23132 ISO `<stdarg.h>' differs from traditional `<varargs.h>' mainly in the 23133 calling convention for `va_start'. The traditional implementation 23134 takes just one argument, which is the variable in which to store the 23135 argument pointer. The ISO implementation of `va_start' takes an 23136 additional second argument. The user is supposed to write the last 23137 named argument of the function here. 23138 23139 However, `va_start' should not use this argument. The way to find the 23140 end of the named arguments is with the built-in functions described 23141 below. 23142 23143 -- Macro: __builtin_saveregs () 23144 Use this built-in function to save the argument registers in 23145 memory so that the varargs mechanism can access them. Both ISO 23146 and traditional versions of `va_start' must use 23147 `__builtin_saveregs', unless you use 23148 `TARGET_SETUP_INCOMING_VARARGS' (see below) instead. 23149 23150 On some machines, `__builtin_saveregs' is open-coded under the 23151 control of the target hook `TARGET_EXPAND_BUILTIN_SAVEREGS'. On 23152 other machines, it calls a routine written in assembler language, 23153 found in `libgcc2.c'. 23154 23155 Code generated for the call to `__builtin_saveregs' appears at the 23156 beginning of the function, as opposed to where the call to 23157 `__builtin_saveregs' is written, regardless of what the code is. 23158 This is because the registers must be saved before the function 23159 starts to use them for its own purposes. 23160 23161 -- Macro: __builtin_args_info (CATEGORY) 23162 Use this built-in function to find the first anonymous arguments in 23163 registers. 23164 23165 In general, a machine may have several categories of registers 23166 used for arguments, each for a particular category of data types. 23167 (For example, on some machines, floating-point registers are used 23168 for floating-point arguments while other arguments are passed in 23169 the general registers.) To make non-varargs functions use the 23170 proper calling convention, you have defined the `CUMULATIVE_ARGS' 23171 data type to record how many registers in each category have been 23172 used so far 23173 23174 `__builtin_args_info' accesses the same data structure of type 23175 `CUMULATIVE_ARGS' after the ordinary argument layout is finished 23176 with it, with CATEGORY specifying which word to access. Thus, the 23177 value indicates the first unused register in a given category. 23178 23179 Normally, you would use `__builtin_args_info' in the implementation 23180 of `va_start', accessing each category just once and storing the 23181 value in the `va_list' object. This is because `va_list' will 23182 have to update the values, and there is no way to alter the values 23183 accessed by `__builtin_args_info'. 23184 23185 -- Macro: __builtin_next_arg (LASTARG) 23186 This is the equivalent of `__builtin_args_info', for stack 23187 arguments. It returns the address of the first anonymous stack 23188 argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns 23189 the address of the location above the first anonymous stack 23190 argument. Use it in `va_start' to initialize the pointer for 23191 fetching arguments from the stack. Also use it in `va_start' to 23192 verify that the second parameter LASTARG is the last named argument 23193 of the current function. 23194 23195 -- Macro: __builtin_classify_type (OBJECT) 23196 Since each machine has its own conventions for which data types are 23197 passed in which kind of register, your implementation of `va_arg' 23198 has to embody these conventions. The easiest way to categorize the 23199 specified data type is to use `__builtin_classify_type' together 23200 with `sizeof' and `__alignof__'. 23201 23202 `__builtin_classify_type' ignores the value of OBJECT, considering 23203 only its data type. It returns an integer describing what kind of 23204 type that is--integer, floating, pointer, structure, and so on. 23205 23206 The file `typeclass.h' defines an enumeration that you can use to 23207 interpret the values of `__builtin_classify_type'. 23208 23209 These machine description macros help implement varargs: 23210 23211 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void) 23212 If defined, this hook produces the machine-specific code for a 23213 call to `__builtin_saveregs'. This code will be moved to the very 23214 beginning of the function, before any parameter access are made. 23215 The return value of this function should be an RTX that contains 23216 the value to use as the return of `__builtin_saveregs'. 23217 23218 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (CUMULATIVE_ARGS 23219 *ARGS_SO_FAR, enum machine_mode MODE, tree TYPE, int 23220 *PRETEND_ARGS_SIZE, int SECOND_TIME) 23221 This target hook offers an alternative to using 23222 `__builtin_saveregs' and defining the hook 23223 `TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous 23224 register arguments into the stack so that all the arguments appear 23225 to have been passed consecutively on the stack. Once this is 23226 done, you can use the standard implementation of varargs that 23227 works for machines that pass all their arguments on the stack. 23228 23229 The argument ARGS_SO_FAR points to the `CUMULATIVE_ARGS' data 23230 structure, containing the values that are obtained after 23231 processing the named arguments. The arguments MODE and TYPE 23232 describe the last named argument--its machine mode and its data 23233 type as a tree node. 23234 23235 The target hook should do two things: first, push onto the stack 23236 all the argument registers _not_ used for the named arguments, and 23237 second, store the size of the data thus pushed into the 23238 `int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value 23239 that you store here will serve as additional offset for setting up 23240 the stack frame. 23241 23242 Because you must generate code to push the anonymous arguments at 23243 compile time without knowing their data types, 23244 `TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that 23245 have just a single category of argument register and use it 23246 uniformly for all data types. 23247 23248 If the argument SECOND_TIME is nonzero, it means that the 23249 arguments of the function are being analyzed for the second time. 23250 This happens for an inline function, which is not actually 23251 compiled until the end of the source file. The hook 23252 `TARGET_SETUP_INCOMING_VARARGS' should not generate any 23253 instructions in this case. 23254 23255 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (CUMULATIVE_ARGS 23256 *CA) 23257 Define this hook to return `true' if the location where a function 23258 argument is passed depends on whether or not it is a named 23259 argument. 23260 23261 This hook controls how the NAMED argument to `FUNCTION_ARG' is set 23262 for varargs and stdarg functions. If this hook returns `true', 23263 the NAMED argument is always true for named arguments, and false 23264 for unnamed arguments. If it returns `false', but 23265 `TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns `true', then all 23266 arguments are treated as named. Otherwise, all named arguments 23267 except the last are treated as named. 23268 23269 You need not define this hook if it always returns zero. 23270 23271 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED 23272 If you need to conditionally change ABIs so that one works with 23273 `TARGET_SETUP_INCOMING_VARARGS', but the other works like neither 23274 `TARGET_SETUP_INCOMING_VARARGS' nor 23275 `TARGET_STRICT_ARGUMENT_NAMING' was defined, then define this hook 23276 to return `true' if `TARGET_SETUP_INCOMING_VARARGS' is used, 23277 `false' otherwise. Otherwise, you should not define this hook. 23278 23279 23280 File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 23281 23282 15.12 Trampolines for Nested Functions 23283 ====================================== 23284 23285 A "trampoline" is a small piece of code that is created at run time 23286 when the address of a nested function is taken. It normally resides on 23287 the stack, in the stack frame of the containing function. These macros 23288 tell GCC how to generate code to allocate and initialize a trampoline. 23289 23290 The instructions in the trampoline must do two things: load a constant 23291 address into the static chain register, and jump to the real address of 23292 the nested function. On CISC machines such as the m68k, this requires 23293 two instructions, a move immediate and a jump. Then the two addresses 23294 exist in the trampoline as word-long immediate operands. On RISC 23295 machines, it is often necessary to load each address into a register in 23296 two parts. Then pieces of each address form separate immediate 23297 operands. 23298 23299 The code generated to initialize the trampoline must store the variable 23300 parts--the static chain value and the function address--into the 23301 immediate operands of the instructions. On a CISC machine, this is 23302 simply a matter of copying each address to a memory reference at the 23303 proper offset from the start of the trampoline. On a RISC machine, it 23304 may be necessary to take out pieces of the address and store them 23305 separately. 23306 23307 -- Macro: TRAMPOLINE_TEMPLATE (FILE) 23308 A C statement to output, on the stream FILE, assembler code for a 23309 block of data that contains the constant parts of a trampoline. 23310 This code should not include a label--the label is taken care of 23311 automatically. 23312 23313 If you do not define this macro, it means no template is needed 23314 for the target. Do not define this macro on systems where the 23315 block move code to copy the trampoline into place would be larger 23316 than the code to generate it on the spot. 23317 23318 -- Macro: TRAMPOLINE_SECTION 23319 Return the section into which the trampoline template is to be 23320 placed (*note Sections::). The default value is 23321 `readonly_data_section'. 23322 23323 -- Macro: TRAMPOLINE_SIZE 23324 A C expression for the size in bytes of the trampoline, as an 23325 integer. 23326 23327 -- Macro: TRAMPOLINE_ALIGNMENT 23328 Alignment required for trampolines, in bits. 23329 23330 If you don't define this macro, the value of `BIGGEST_ALIGNMENT' 23331 is used for aligning trampolines. 23332 23333 -- Macro: INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN) 23334 A C statement to initialize the variable parts of a trampoline. 23335 ADDR is an RTX for the address of the trampoline; FNADDR is an RTX 23336 for the address of the nested function; STATIC_CHAIN is an RTX for 23337 the static chain value that should be passed to the function when 23338 it is called. 23339 23340 -- Macro: TRAMPOLINE_ADJUST_ADDRESS (ADDR) 23341 A C statement that should perform any machine-specific adjustment 23342 in the address of the trampoline. Its argument contains the 23343 address that was passed to `INITIALIZE_TRAMPOLINE'. In case the 23344 address to be used for a function call should be different from 23345 the address in which the template was stored, the different 23346 address should be assigned to ADDR. If this macro is not defined, 23347 ADDR will be used for function calls. 23348 23349 If this macro is not defined, by default the trampoline is 23350 allocated as a stack slot. This default is right for most 23351 machines. The exceptions are machines where it is impossible to 23352 execute instructions in the stack area. On such machines, you may 23353 have to implement a separate stack, using this macro in 23354 conjunction with `TARGET_ASM_FUNCTION_PROLOGUE' and 23355 `TARGET_ASM_FUNCTION_EPILOGUE'. 23356 23357 FP points to a data structure, a `struct function', which 23358 describes the compilation status of the immediate containing 23359 function of the function which the trampoline is for. The stack 23360 slot for the trampoline is in the stack frame of this containing 23361 function. Other allocation strategies probably must do something 23362 analogous with this information. 23363 23364 Implementing trampolines is difficult on many machines because they 23365 have separate instruction and data caches. Writing into a stack 23366 location fails to clear the memory in the instruction cache, so when 23367 the program jumps to that location, it executes the old contents. 23368 23369 Here are two possible solutions. One is to clear the relevant parts of 23370 the instruction cache whenever a trampoline is set up. The other is to 23371 make all trampolines identical, by having them jump to a standard 23372 subroutine. The former technique makes trampoline execution faster; the 23373 latter makes initialization faster. 23374 23375 To clear the instruction cache when a trampoline is initialized, define 23376 the following macro. 23377 23378 -- Macro: CLEAR_INSN_CACHE (BEG, END) 23379 If defined, expands to a C expression clearing the _instruction 23380 cache_ in the specified interval. The definition of this macro 23381 would typically be a series of `asm' statements. Both BEG and END 23382 are both pointer expressions. 23383 23384 The operating system may also require the stack to be made executable 23385 before calling the trampoline. To implement this requirement, define 23386 the following macro. 23387 23388 -- Macro: ENABLE_EXECUTE_STACK 23389 Define this macro if certain operations must be performed before 23390 executing code located on the stack. The macro should expand to a 23391 series of C file-scope constructs (e.g. functions) and provide a 23392 unique entry point named `__enable_execute_stack'. The target is 23393 responsible for emitting calls to the entry point in the code, for 23394 example from the `INITIALIZE_TRAMPOLINE' macro. 23395 23396 To use a standard subroutine, define the following macro. In addition, 23397 you must make sure that the instructions in a trampoline fill an entire 23398 cache line with identical instructions, or else ensure that the 23399 beginning of the trampoline code is always aligned at the same point in 23400 its cache line. Look in `m68k.h' as a guide. 23401 23402 -- Macro: TRANSFER_FROM_TRAMPOLINE 23403 Define this macro if trampolines need a special subroutine to do 23404 their work. The macro should expand to a series of `asm' 23405 statements which will be compiled with GCC. They go in a library 23406 function named `__transfer_from_trampoline'. 23407 23408 If you need to avoid executing the ordinary prologue code of a 23409 compiled C function when you jump to the subroutine, you can do so 23410 by placing a special label of your own in the assembler code. Use 23411 one `asm' statement to generate an assembler label, and another to 23412 make the label global. Then trampolines can use that label to 23413 jump directly to your special assembler code. 23414 23415 23416 File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 23417 23418 15.13 Implicit Calls to Library Routines 23419 ======================================== 23420 23421 Here is an explanation of implicit calls to library routines. 23422 23423 -- Macro: DECLARE_LIBRARY_RENAMES 23424 This macro, if defined, should expand to a piece of C code that 23425 will get expanded when compiling functions for libgcc.a. It can 23426 be used to provide alternate names for GCC's internal library 23427 functions if there are ABI-mandated names that the compiler should 23428 provide. 23429 23430 -- Target Hook: void TARGET_INIT_LIBFUNCS (void) 23431 This hook should declare additional library routines or rename 23432 existing ones, using the functions `set_optab_libfunc' and 23433 `init_one_libfunc' defined in `optabs.c'. `init_optabs' calls 23434 this macro after initializing all the normal library routines. 23435 23436 The default is to do nothing. Most ports don't need to define 23437 this hook. 23438 23439 -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON) 23440 This macro should return `true' if the library routine that 23441 implements the floating point comparison operator COMPARISON in 23442 mode MODE will return a boolean, and FALSE if it will return a 23443 tristate. 23444 23445 GCC's own floating point libraries return tristates from the 23446 comparison operators, so the default returns false always. Most 23447 ports don't need to define this macro. 23448 23449 -- Macro: TARGET_LIB_INT_CMP_BIASED 23450 This macro should evaluate to `true' if the integer comparison 23451 functions (like `__cmpdi2') return 0 to indicate that the first 23452 operand is smaller than the second, 1 to indicate that they are 23453 equal, and 2 to indicate that the first operand is greater than 23454 the second. If this macro evaluates to `false' the comparison 23455 functions return -1, 0, and 1 instead of 0, 1, and 2. If the 23456 target uses the routines in `libgcc.a', you do not need to define 23457 this macro. 23458 23459 -- Macro: US_SOFTWARE_GOFAST 23460 Define this macro if your system C library uses the US Software 23461 GOFAST library to provide floating point emulation. 23462 23463 In addition to defining this macro, your architecture must set 23464 `TARGET_INIT_LIBFUNCS' to `gofast_maybe_init_libfuncs', or else 23465 call that function from its version of that hook. It is defined 23466 in `config/gofast.h', which must be included by your 23467 architecture's `CPU.c' file. See `sparc/sparc.c' for an example. 23468 23469 If this macro is defined, the 23470 `TARGET_FLOAT_LIB_COMPARE_RETURNS_BOOL' target hook must return 23471 false for `SFmode' and `DFmode' comparisons. 23472 23473 -- Macro: TARGET_EDOM 23474 The value of `EDOM' on the target machine, as a C integer constant 23475 expression. If you don't define this macro, GCC does not attempt 23476 to deposit the value of `EDOM' into `errno' directly. Look in 23477 `/usr/include/errno.h' to find the value of `EDOM' on your system. 23478 23479 If you do not define `TARGET_EDOM', then compiled code reports 23480 domain errors by calling the library function and letting it 23481 report the error. If mathematical functions on your system use 23482 `matherr' when there is an error, then you should leave 23483 `TARGET_EDOM' undefined so that `matherr' is used normally. 23484 23485 -- Macro: GEN_ERRNO_RTX 23486 Define this macro as a C expression to create an rtl expression 23487 that refers to the global "variable" `errno'. (On certain systems, 23488 `errno' may not actually be a variable.) If you don't define this 23489 macro, a reasonable default is used. 23490 23491 -- Macro: TARGET_C99_FUNCTIONS 23492 When this macro is nonzero, GCC will implicitly optimize `sin' 23493 calls into `sinf' and similarly for other functions defined by C99 23494 standard. The default is nonzero that should be proper value for 23495 most modern systems, however number of existing systems lacks 23496 support for these functions in the runtime so they needs this 23497 macro to be redefined to 0. 23498 23499 -- Macro: NEXT_OBJC_RUNTIME 23500 Define this macro to generate code for Objective-C message sending 23501 using the calling convention of the NeXT system. This calling 23502 convention involves passing the object, the selector and the 23503 method arguments all at once to the method-lookup library function. 23504 23505 The default calling convention passes just the object and the 23506 selector to the lookup function, which returns a pointer to the 23507 method. 23508 23509 23510 File: gccint.info, Node: Addressing Modes, Next: Anchored Addresses, Prev: Library Calls, Up: Target Macros 23511 23512 15.14 Addressing Modes 23513 ====================== 23514 23515 This is about addressing modes. 23516 23517 -- Macro: HAVE_PRE_INCREMENT 23518 -- Macro: HAVE_PRE_DECREMENT 23519 -- Macro: HAVE_POST_INCREMENT 23520 -- Macro: HAVE_POST_DECREMENT 23521 A C expression that is nonzero if the machine supports 23522 pre-increment, pre-decrement, post-increment, or post-decrement 23523 addressing respectively. 23524 23525 -- Macro: HAVE_PRE_MODIFY_DISP 23526 -- Macro: HAVE_POST_MODIFY_DISP 23527 A C expression that is nonzero if the machine supports pre- or 23528 post-address side-effect generation involving constants other than 23529 the size of the memory operand. 23530 23531 -- Macro: HAVE_PRE_MODIFY_REG 23532 -- Macro: HAVE_POST_MODIFY_REG 23533 A C expression that is nonzero if the machine supports pre- or 23534 post-address side-effect generation involving a register 23535 displacement. 23536 23537 -- Macro: CONSTANT_ADDRESS_P (X) 23538 A C expression that is 1 if the RTX X is a constant which is a 23539 valid address. On most machines, this can be defined as 23540 `CONSTANT_P (X)', but a few machines are more restrictive in which 23541 constant addresses are supported. 23542 23543 -- Macro: CONSTANT_P (X) 23544 `CONSTANT_P', which is defined by target-independent code, accepts 23545 integer-values expressions whose values are not explicitly known, 23546 such as `symbol_ref', `label_ref', and `high' expressions and 23547 `const' arithmetic expressions, in addition to `const_int' and 23548 `const_double' expressions. 23549 23550 -- Macro: MAX_REGS_PER_ADDRESS 23551 A number, the maximum number of registers that can appear in a 23552 valid memory address. Note that it is up to you to specify a 23553 value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS' 23554 would ever accept. 23555 23556 -- Macro: GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL) 23557 A C compound statement with a conditional `goto LABEL;' executed 23558 if X (an RTX) is a legitimate memory address on the target machine 23559 for a memory operand of mode MODE. 23560 23561 It usually pays to define several simpler macros to serve as 23562 subroutines for this one. Otherwise it may be too complicated to 23563 understand. 23564 23565 This macro must exist in two variants: a strict variant and a 23566 non-strict one. The strict variant is used in the reload pass. It 23567 must be defined so that any pseudo-register that has not been 23568 allocated a hard register is considered a memory reference. In 23569 contexts where some kind of register is required, a pseudo-register 23570 with no hard register must be rejected. 23571 23572 The non-strict variant is used in other passes. It must be 23573 defined to accept all pseudo-registers in every context where some 23574 kind of register is required. 23575 23576 Compiler source files that want to use the strict variant of this 23577 macro define the macro `REG_OK_STRICT'. You should use an `#ifdef 23578 REG_OK_STRICT' conditional to define the strict variant in that 23579 case and the non-strict variant otherwise. 23580 23581 Subroutines to check for acceptable registers for various purposes 23582 (one for base registers, one for index registers, and so on) are 23583 typically among the subroutines used to define 23584 `GO_IF_LEGITIMATE_ADDRESS'. Then only these subroutine macros 23585 need have two variants; the higher levels of macros may be the 23586 same whether strict or not. 23587 23588 Normally, constant addresses which are the sum of a `symbol_ref' 23589 and an integer are stored inside a `const' RTX to mark them as 23590 constant. Therefore, there is no need to recognize such sums 23591 specifically as legitimate addresses. Normally you would simply 23592 recognize any `const' as legitimate. 23593 23594 Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant 23595 sums that are not marked with `const'. It assumes that a naked 23596 `plus' indicates indexing. If so, then you _must_ reject such 23597 naked constant sums as illegitimate addresses, so that none of 23598 them will be given to `PRINT_OPERAND_ADDRESS'. 23599 23600 On some machines, whether a symbolic address is legitimate depends 23601 on the section that the address refers to. On these machines, 23602 define the target hook `TARGET_ENCODE_SECTION_INFO' to store the 23603 information into the `symbol_ref', and then check for it here. 23604 When you see a `const', you will have to look inside it to find the 23605 `symbol_ref' in order to determine the section. *Note Assembler 23606 Format::. 23607 23608 -- Macro: FIND_BASE_TERM (X) 23609 A C expression to determine the base term of address X. This 23610 macro is used in only one place: `find_base_term' in alias.c. 23611 23612 It is always safe for this macro to not be defined. It exists so 23613 that alias analysis can understand machine-dependent addresses. 23614 23615 The typical use of this macro is to handle addresses containing a 23616 label_ref or symbol_ref within an UNSPEC. 23617 23618 -- Macro: LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN) 23619 A C compound statement that attempts to replace X with a valid 23620 memory address for an operand of mode MODE. WIN will be a C 23621 statement label elsewhere in the code; the macro definition may use 23622 23623 GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN); 23624 23625 to avoid further processing if the address has become legitimate. 23626 23627 X will always be the result of a call to `break_out_memory_refs', 23628 and OLDX will be the operand that was given to that function to 23629 produce X. 23630 23631 The code generated by this macro should not alter the substructure 23632 of X. If it transforms X into a more legitimate form, it should 23633 assign X (which will always be a C variable) a new value. 23634 23635 It is not necessary for this macro to come up with a legitimate 23636 address. The compiler has standard ways of doing so in all cases. 23637 In fact, it is safe to omit this macro. But often a 23638 machine-dependent strategy can generate better code. 23639 23640 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, 23641 WIN) 23642 A C compound statement that attempts to replace X, which is an 23643 address that needs reloading, with a valid memory address for an 23644 operand of mode MODE. WIN will be a C statement label elsewhere 23645 in the code. It is not necessary to define this macro, but it 23646 might be useful for performance reasons. 23647 23648 For example, on the i386, it is sometimes possible to use a single 23649 reload register instead of two by reloading a sum of two pseudo 23650 registers into a register. On the other hand, for number of RISC 23651 processors offsets are limited so that often an intermediate 23652 address needs to be generated in order to address a stack slot. 23653 By defining `LEGITIMIZE_RELOAD_ADDRESS' appropriately, the 23654 intermediate addresses generated for adjacent some stack slots can 23655 be made identical, and thus be shared. 23656 23657 _Note_: This macro should be used with caution. It is necessary 23658 to know something of how reload works in order to effectively use 23659 this, and it is quite easy to produce macros that build in too 23660 much knowledge of reload internals. 23661 23662 _Note_: This macro must be able to reload an address created by a 23663 previous invocation of this macro. If it fails to handle such 23664 addresses then the compiler may generate incorrect code or abort. 23665 23666 The macro definition should use `push_reload' to indicate parts 23667 that need reloading; OPNUM, TYPE and IND_LEVELS are usually 23668 suitable to be passed unaltered to `push_reload'. 23669 23670 The code generated by this macro must not alter the substructure of 23671 X. If it transforms X into a more legitimate form, it should 23672 assign X (which will always be a C variable) a new value. This 23673 also applies to parts that you change indirectly by calling 23674 `push_reload'. 23675 23676 The macro definition may use `strict_memory_address_p' to test if 23677 the address has become legitimate. 23678 23679 If you want to change only a part of X, one standard way of doing 23680 this is to use `copy_rtx'. Note, however, that is unshares only a 23681 single level of rtl. Thus, if the part to be changed is not at the 23682 top level, you'll need to replace first the top level. It is not 23683 necessary for this macro to come up with a legitimate address; 23684 but often a machine-dependent strategy can generate better code. 23685 23686 -- Macro: GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL) 23687 A C statement or compound statement with a conditional `goto 23688 LABEL;' executed if memory address X (an RTX) can have different 23689 meanings depending on the machine mode of the memory reference it 23690 is used for or if the address is valid for some modes but not 23691 others. 23692 23693 Autoincrement and autodecrement addresses typically have 23694 mode-dependent effects because the amount of the increment or 23695 decrement is the size of the operand being addressed. Some 23696 machines have other mode-dependent addresses. Many RISC machines 23697 have no mode-dependent addresses. 23698 23699 You may assume that ADDR is a valid address for the machine. 23700 23701 -- Macro: LEGITIMATE_CONSTANT_P (X) 23702 A C expression that is nonzero if X is a legitimate constant for 23703 an immediate operand on the target machine. You can assume that X 23704 satisfies `CONSTANT_P', so you need not check this. In fact, `1' 23705 is a suitable definition for this macro on machines where anything 23706 `CONSTANT_P' is valid. 23707 23708 -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X) 23709 This hook is used to undo the possibly obfuscating effects of the 23710 `LEGITIMIZE_ADDRESS' and `LEGITIMIZE_RELOAD_ADDRESS' target 23711 macros. Some backend implementations of these macros wrap symbol 23712 references inside an `UNSPEC' rtx to represent PIC or similar 23713 addressing modes. This target hook allows GCC's optimizers to 23714 understand the semantics of these opaque `UNSPEC's by converting 23715 them back into their original form. 23716 23717 -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (rtx X) 23718 This hook should return true if X is of a form that cannot (or 23719 should not) be spilled to the constant pool. The default version 23720 of this hook returns false. 23721 23722 The primary reason to define this hook is to prevent reload from 23723 deciding that a non-legitimate constant would be better reloaded 23724 from the constant pool instead of spilling and reloading a register 23725 holding the constant. This restriction is often true of addresses 23726 of TLS symbols for various targets. 23727 23728 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (enum 23729 machine_mode MODE, rtx X) 23730 This hook should return true if pool entries for constant X can be 23731 placed in an `object_block' structure. MODE is the mode of X. 23732 23733 The default version returns false for all constants. 23734 23735 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void) 23736 This hook should return the DECL of a function F that given an 23737 address ADDR as an argument returns a mask M that can be used to 23738 extract from two vectors the relevant data that resides in ADDR in 23739 case ADDR is not properly aligned. 23740 23741 The autovectrizer, when vectorizing a load operation from an 23742 address ADDR that may be unaligned, will generate two vector loads 23743 from the two aligned addresses around ADDR. It then generates a 23744 `REALIGN_LOAD' operation to extract the relevant data from the two 23745 loaded vectors. The first two arguments to `REALIGN_LOAD', V1 and 23746 V2, are the two vectors, each of size VS, and the third argument, 23747 OFF, defines how the data will be extracted from these two 23748 vectors: if OFF is 0, then the returned vector is V2; otherwise, 23749 the returned vector is composed from the last VS-OFF elements of 23750 V1 concatenated to the first OFF elements of V2. 23751 23752 If this hook is defined, the autovectorizer will generate a call 23753 to F (using the DECL tree that this hook returns) and will use the 23754 return value of F as the argument OFF to `REALIGN_LOAD'. 23755 Therefore, the mask M returned by F should comply with the 23756 semantics expected by `REALIGN_LOAD' described above. If this 23757 hook is not defined, then ADDR will be used as the argument OFF to 23758 `REALIGN_LOAD', in which case the low log2(VS)-1 bits of ADDR will 23759 be considered. 23760 23761 23762 File: gccint.info, Node: Anchored Addresses, Next: Condition Code, Prev: Addressing Modes, Up: Target Macros 23763 23764 15.15 Anchored Addresses 23765 ======================== 23766 23767 GCC usually addresses every static object as a separate entity. For 23768 example, if we have: 23769 23770 static int a, b, c; 23771 int foo (void) { return a + b + c; } 23772 23773 the code for `foo' will usually calculate three separate symbolic 23774 addresses: those of `a', `b' and `c'. On some targets, it would be 23775 better to calculate just one symbolic address and access the three 23776 variables relative to it. The equivalent pseudocode would be something 23777 like: 23778 23779 int foo (void) 23780 { 23781 register int *xr = &x; 23782 return xr[&a - &x] + xr[&b - &x] + xr[&c - &x]; 23783 } 23784 23785 (which isn't valid C). We refer to shared addresses like `x' as 23786 "section anchors". Their use is controlled by `-fsection-anchors'. 23787 23788 The hooks below describe the target properties that GCC needs to know 23789 in order to make effective use of section anchors. It won't use 23790 section anchors at all unless either `TARGET_MIN_ANCHOR_OFFSET' or 23791 `TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value. 23792 23793 -- Variable: Target Hook HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET 23794 The minimum offset that should be applied to a section anchor. On 23795 most targets, it should be the smallest offset that can be applied 23796 to a base register while still giving a legitimate address for 23797 every mode. The default value is 0. 23798 23799 -- Variable: Target Hook HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET 23800 Like `TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive) 23801 offset that should be applied to section anchors. The default 23802 value is 0. 23803 23804 -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X) 23805 Write the assembly code to define section anchor X, which is a 23806 `SYMBOL_REF' for which `SYMBOL_REF_ANCHOR_P (X)' is true. The 23807 hook is called with the assembly output position set to the 23808 beginning of `SYMBOL_REF_BLOCK (X)'. 23809 23810 If `ASM_OUTPUT_DEF' is available, the hook's default definition 23811 uses it to define the symbol as `. + SYMBOL_REF_BLOCK_OFFSET (X)'. 23812 If `ASM_OUTPUT_DEF' is not available, the hook's default definition 23813 is `NULL', which disables the use of section anchors altogether. 23814 23815 -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (rtx X) 23816 Return true if GCC should attempt to use anchors to access 23817 `SYMBOL_REF' X. You can assume `SYMBOL_REF_HAS_BLOCK_INFO_P (X)' 23818 and `!SYMBOL_REF_ANCHOR_P (X)'. 23819 23820 The default version is correct for most targets, but you might 23821 need to intercept this hook to handle things like target-specific 23822 attributes or target-specific sections. 23823 23824 23825 File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros 23826 23827 15.16 Condition Code Status 23828 =========================== 23829 23830 This describes the condition code status. 23831 23832 The file `conditions.h' defines a variable `cc_status' to describe how 23833 the condition code was computed (in case the interpretation of the 23834 condition code depends on the instruction that it was set by). This 23835 variable contains the RTL expressions on which the condition code is 23836 currently based, and several standard flags. 23837 23838 Sometimes additional machine-specific flags must be defined in the 23839 machine description header file. It can also add additional 23840 machine-specific information by defining `CC_STATUS_MDEP'. 23841 23842 -- Macro: CC_STATUS_MDEP 23843 C code for a data type which is used for declaring the `mdep' 23844 component of `cc_status'. It defaults to `int'. 23845 23846 This macro is not used on machines that do not use `cc0'. 23847 23848 -- Macro: CC_STATUS_MDEP_INIT 23849 A C expression to initialize the `mdep' field to "empty". The 23850 default definition does nothing, since most machines don't use the 23851 field anyway. If you want to use the field, you should probably 23852 define this macro to initialize it. 23853 23854 This macro is not used on machines that do not use `cc0'. 23855 23856 -- Macro: NOTICE_UPDATE_CC (EXP, INSN) 23857 A C compound statement to set the components of `cc_status' 23858 appropriately for an insn INSN whose body is EXP. It is this 23859 macro's responsibility to recognize insns that set the condition 23860 code as a byproduct of other activity as well as those that 23861 explicitly set `(cc0)'. 23862 23863 This macro is not used on machines that do not use `cc0'. 23864 23865 If there are insns that do not set the condition code but do alter 23866 other machine registers, this macro must check to see whether they 23867 invalidate the expressions that the condition code is recorded as 23868 reflecting. For example, on the 68000, insns that store in address 23869 registers do not set the condition code, which means that usually 23870 `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns. 23871 But suppose that the previous insn set the condition code based 23872 on location `a4@(102)' and the current insn stores a new value in 23873 `a4'. Although the condition code is not changed by this, it will 23874 no longer be true that it reflects the contents of `a4@(102)'. 23875 Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case 23876 to say that nothing is known about the condition code value. 23877 23878 The definition of `NOTICE_UPDATE_CC' must be prepared to deal with 23879 the results of peephole optimization: insns whose patterns are 23880 `parallel' RTXs containing various `reg', `mem' or constants which 23881 are just the operands. The RTL structure of these insns is not 23882 sufficient to indicate what the insns actually do. What 23883 `NOTICE_UPDATE_CC' should do when it sees one is just to run 23884 `CC_STATUS_INIT'. 23885 23886 A possible definition of `NOTICE_UPDATE_CC' is to call a function 23887 that looks at an attribute (*note Insn Attributes::) named, for 23888 example, `cc'. This avoids having detailed information about 23889 patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'. 23890 23891 -- Macro: SELECT_CC_MODE (OP, X, Y) 23892 Returns a mode from class `MODE_CC' to be used when comparison 23893 operation code OP is applied to rtx X and Y. For example, on the 23894 SPARC, `SELECT_CC_MODE' is defined as (see *note Jump Patterns:: 23895 for a description of the reason for this definition) 23896 23897 #define SELECT_CC_MODE(OP,X,Y) \ 23898 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ 23899 ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \ 23900 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 23901 || GET_CODE (X) == NEG) \ 23902 ? CC_NOOVmode : CCmode)) 23903 23904 You should define this macro if and only if you define extra CC 23905 modes in `MACHINE-modes.def'. 23906 23907 -- Macro: CANONICALIZE_COMPARISON (CODE, OP0, OP1) 23908 On some machines not all possible comparisons are defined, but you 23909 can convert an invalid comparison into a valid one. For example, 23910 the Alpha does not have a `GT' comparison, but you can use an `LT' 23911 comparison instead and swap the order of the operands. 23912 23913 On such machines, define this macro to be a C statement to do any 23914 required conversions. CODE is the initial comparison code and OP0 23915 and OP1 are the left and right operands of the comparison, 23916 respectively. You should modify CODE, OP0, and OP1 as required. 23917 23918 GCC will not assume that the comparison resulting from this macro 23919 is valid but will see if the resulting insn matches a pattern in 23920 the `md' file. 23921 23922 You need not define this macro if it would never change the 23923 comparison code or operands. 23924 23925 -- Macro: REVERSIBLE_CC_MODE (MODE) 23926 A C expression whose value is one if it is always safe to reverse a 23927 comparison whose mode is MODE. If `SELECT_CC_MODE' can ever 23928 return MODE for a floating-point inequality comparison, then 23929 `REVERSIBLE_CC_MODE (MODE)' must be zero. 23930 23931 You need not define this macro if it would always returns zero or 23932 if the floating-point format is anything other than 23933 `IEEE_FLOAT_FORMAT'. For example, here is the definition used on 23934 the SPARC, where floating-point inequality comparisons are always 23935 given `CCFPEmode': 23936 23937 #define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode) 23938 23939 -- Macro: REVERSE_CONDITION (CODE, MODE) 23940 A C expression whose value is reversed condition code of the CODE 23941 for comparison done in CC_MODE MODE. The macro is used only in 23942 case `REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in 23943 case machine has some non-standard way how to reverse certain 23944 conditionals. For instance in case all floating point conditions 23945 are non-trapping, compiler may freely convert unordered compares 23946 to ordered one. Then definition may look like: 23947 23948 #define REVERSE_CONDITION(CODE, MODE) \ 23949 ((MODE) != CCFPmode ? reverse_condition (CODE) \ 23950 : reverse_condition_maybe_unordered (CODE)) 23951 23952 -- Macro: REVERSE_CONDEXEC_PREDICATES_P (OP1, OP2) 23953 A C expression that returns true if the conditional execution 23954 predicate OP1, a comparison operation, is the inverse of OP2 and 23955 vice versa. Define this to return 0 if the target has conditional 23956 execution predicates that cannot be reversed safely. There is no 23957 need to validate that the arguments of op1 and op2 are the same, 23958 this is done separately. If no expansion is specified, this macro 23959 is defined as follows: 23960 23961 #define REVERSE_CONDEXEC_PREDICATES_P (x, y) \ 23962 (GET_CODE ((x)) == reversed_comparison_code ((y), NULL)) 23963 23964 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int *, 23965 unsigned int *) 23966 On targets which do not use `(cc0)', and which use a hard register 23967 rather than a pseudo-register to hold condition codes, the regular 23968 CSE passes are often not able to identify cases in which the hard 23969 register is set to a common value. Use this hook to enable a 23970 small pass which optimizes such cases. This hook should return 23971 true to enable this pass, and it should set the integers to which 23972 its arguments point to the hard register numbers used for 23973 condition codes. When there is only one such register, as is true 23974 on most systems, the integer pointed to by the second argument 23975 should be set to `INVALID_REGNUM'. 23976 23977 The default version of this hook returns false. 23978 23979 -- Target Hook: enum machine_mode TARGET_CC_MODES_COMPATIBLE (enum 23980 machine_mode, enum machine_mode) 23981 On targets which use multiple condition code modes in class 23982 `MODE_CC', it is sometimes the case that a comparison can be 23983 validly done in more than one mode. On such a system, define this 23984 target hook to take two mode arguments and to return a mode in 23985 which both comparisons may be validly done. If there is no such 23986 mode, return `VOIDmode'. 23987 23988 The default version of this hook checks whether the modes are the 23989 same. If they are, it returns that mode. If they are different, 23990 it returns `VOIDmode'. 23991 23992 23993 File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros 23994 23995 15.17 Describing Relative Costs of Operations 23996 ============================================= 23997 23998 These macros let you describe the relative speed of various operations 23999 on the target machine. 24000 24001 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO) 24002 A C expression for the cost of moving data of mode MODE from a 24003 register in class FROM to one in class TO. The classes are 24004 expressed using the enumeration values such as `GENERAL_REGS'. A 24005 value of 2 is the default; other values are interpreted relative to 24006 that. 24007 24008 It is not required that the cost always equal 2 when FROM is the 24009 same as TO; on some machines it is expensive to move between 24010 registers if they are not general registers. 24011 24012 If reload sees an insn consisting of a single `set' between two 24013 hard registers, and if `REGISTER_MOVE_COST' applied to their 24014 classes returns a value of 2, reload does not check to ensure that 24015 the constraints of the insn are met. Setting a cost of other than 24016 2 will allow reload to verify that the constraints are met. You 24017 should do this if the `movM' pattern's constraints do not allow 24018 such copying. 24019 24020 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN) 24021 A C expression for the cost of moving data of mode MODE between a 24022 register of class CLASS and memory; IN is zero if the value is to 24023 be written to memory, nonzero if it is to be read in. This cost 24024 is relative to those in `REGISTER_MOVE_COST'. If moving between 24025 registers and memory is more expensive than between two registers, 24026 you should define this macro to express the relative cost. 24027 24028 If you do not define this macro, GCC uses a default cost of 4 plus 24029 the cost of copying via a secondary reload register, if one is 24030 needed. If your machine requires a secondary reload register to 24031 copy between memory and a register of CLASS but the reload 24032 mechanism is more complex than copying via an intermediate, define 24033 this macro to reflect the actual cost of the move. 24034 24035 GCC defines the function `memory_move_secondary_cost' if secondary 24036 reloads are needed. It computes the costs due to copying via a 24037 secondary register. If your machine copies from memory using a 24038 secondary register in the conventional way but the default base 24039 value of 4 is not correct for your machine, define this macro to 24040 add some other value to the result of that function. The 24041 arguments to that function are the same as to this macro. 24042 24043 -- Macro: BRANCH_COST 24044 A C expression for the cost of a branch instruction. A value of 1 24045 is the default; other values are interpreted relative to that. 24046 24047 Here are additional macros which do not specify precise relative costs, 24048 but only that certain actions are more expensive than GCC would 24049 ordinarily expect. 24050 24051 -- Macro: SLOW_BYTE_ACCESS 24052 Define this macro as a C expression which is nonzero if accessing 24053 less than a word of memory (i.e. a `char' or a `short') is no 24054 faster than accessing a word of memory, i.e., if such access 24055 require more than one instruction or if there is no difference in 24056 cost between byte and (aligned) word loads. 24057 24058 When this macro is not defined, the compiler will access a field by 24059 finding the smallest containing object; when it is defined, a 24060 fullword load will be used if alignment permits. Unless bytes 24061 accesses are faster than word accesses, using word accesses is 24062 preferable since it may eliminate subsequent memory access if 24063 subsequent accesses occur to other fields in the same word of the 24064 structure, but to different bytes. 24065 24066 -- Macro: SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT) 24067 Define this macro to be the value 1 if memory accesses described 24068 by the MODE and ALIGNMENT parameters have a cost many times greater 24069 than aligned accesses, for example if they are emulated in a trap 24070 handler. 24071 24072 When this macro is nonzero, the compiler will act as if 24073 `STRICT_ALIGNMENT' were nonzero when generating code for block 24074 moves. This can cause significantly more instructions to be 24075 produced. Therefore, do not set this macro nonzero if unaligned 24076 accesses only add a cycle or two to the time for a memory access. 24077 24078 If the value of this macro is always zero, it need not be defined. 24079 If this macro is defined, it should produce a nonzero value when 24080 `STRICT_ALIGNMENT' is nonzero. 24081 24082 -- Macro: MOVE_RATIO 24083 The threshold of number of scalar memory-to-memory move insns, 24084 _below_ which a sequence of insns should be generated instead of a 24085 string move insn or a library call. Increasing the value will 24086 always make code faster, but eventually incurs high cost in 24087 increased code size. 24088 24089 Note that on machines where the corresponding move insn is a 24090 `define_expand' that emits a sequence of insns, this macro counts 24091 the number of such sequences. 24092 24093 If you don't define this, a reasonable default is used. 24094 24095 -- Macro: MOVE_BY_PIECES_P (SIZE, ALIGNMENT) 24096 A C expression used to determine whether `move_by_pieces' will be 24097 used to copy a chunk of memory, or whether some other block move 24098 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns' 24099 returns less than `MOVE_RATIO'. 24100 24101 -- Macro: MOVE_MAX_PIECES 24102 A C expression used by `move_by_pieces' to determine the largest 24103 unit a load or store used to copy memory is. Defaults to 24104 `MOVE_MAX'. 24105 24106 -- Macro: CLEAR_RATIO 24107 The threshold of number of scalar move insns, _below_ which a 24108 sequence of insns should be generated to clear memory instead of a 24109 string clear insn or a library call. Increasing the value will 24110 always make code faster, but eventually incurs high cost in 24111 increased code size. 24112 24113 If you don't define this, a reasonable default is used. 24114 24115 -- Macro: CLEAR_BY_PIECES_P (SIZE, ALIGNMENT) 24116 A C expression used to determine whether `clear_by_pieces' will be 24117 used to clear a chunk of memory, or whether some other block clear 24118 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns' 24119 returns less than `CLEAR_RATIO'. 24120 24121 -- Macro: STORE_BY_PIECES_P (SIZE, ALIGNMENT) 24122 A C expression used to determine whether `store_by_pieces' will be 24123 used to set a chunk of memory to a constant value, or whether some 24124 other mechanism will be used. Used by `__builtin_memset' when 24125 storing values other than constant zero and by `__builtin_strcpy' 24126 when when called with a constant source string. Defaults to 1 if 24127 `move_by_pieces_ninsns' returns less than `MOVE_RATIO'. 24128 24129 -- Macro: USE_LOAD_POST_INCREMENT (MODE) 24130 A C expression used to determine whether a load postincrement is a 24131 good thing to use for a given mode. Defaults to the value of 24132 `HAVE_POST_INCREMENT'. 24133 24134 -- Macro: USE_LOAD_POST_DECREMENT (MODE) 24135 A C expression used to determine whether a load postdecrement is a 24136 good thing to use for a given mode. Defaults to the value of 24137 `HAVE_POST_DECREMENT'. 24138 24139 -- Macro: USE_LOAD_PRE_INCREMENT (MODE) 24140 A C expression used to determine whether a load preincrement is a 24141 good thing to use for a given mode. Defaults to the value of 24142 `HAVE_PRE_INCREMENT'. 24143 24144 -- Macro: USE_LOAD_PRE_DECREMENT (MODE) 24145 A C expression used to determine whether a load predecrement is a 24146 good thing to use for a given mode. Defaults to the value of 24147 `HAVE_PRE_DECREMENT'. 24148 24149 -- Macro: USE_STORE_POST_INCREMENT (MODE) 24150 A C expression used to determine whether a store postincrement is 24151 a good thing to use for a given mode. Defaults to the value of 24152 `HAVE_POST_INCREMENT'. 24153 24154 -- Macro: USE_STORE_POST_DECREMENT (MODE) 24155 A C expression used to determine whether a store postdecrement is 24156 a good thing to use for a given mode. Defaults to the value of 24157 `HAVE_POST_DECREMENT'. 24158 24159 -- Macro: USE_STORE_PRE_INCREMENT (MODE) 24160 This macro is used to determine whether a store preincrement is a 24161 good thing to use for a given mode. Defaults to the value of 24162 `HAVE_PRE_INCREMENT'. 24163 24164 -- Macro: USE_STORE_PRE_DECREMENT (MODE) 24165 This macro is used to determine whether a store predecrement is a 24166 good thing to use for a given mode. Defaults to the value of 24167 `HAVE_PRE_DECREMENT'. 24168 24169 -- Macro: NO_FUNCTION_CSE 24170 Define this macro if it is as good or better to call a constant 24171 function address than to call an address kept in a register. 24172 24173 -- Macro: RANGE_TEST_NON_SHORT_CIRCUIT 24174 Define this macro if a non-short-circuit operation produced by 24175 `fold_range_test ()' is optimal. This macro defaults to true if 24176 `BRANCH_COST' is greater than or equal to the value 2. 24177 24178 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, int CODE, int 24179 OUTER_CODE, int *TOTAL) 24180 This target hook describes the relative costs of RTL expressions. 24181 24182 The cost may depend on the precise form of the expression, which is 24183 available for examination in X, and the rtx code of the expression 24184 in which it is contained, found in OUTER_CODE. CODE is the 24185 expression code--redundant, since it can be obtained with 24186 `GET_CODE (X)'. 24187 24188 In implementing this hook, you can use the construct 24189 `COSTS_N_INSNS (N)' to specify a cost equal to N fast instructions. 24190 24191 On entry to the hook, `*TOTAL' contains a default estimate for the 24192 cost of the expression. The hook should modify this value as 24193 necessary. Traditionally, the default costs are `COSTS_N_INSNS 24194 (5)' for multiplications, `COSTS_N_INSNS (7)' for division and 24195 modulus operations, and `COSTS_N_INSNS (1)' for all other 24196 operations. 24197 24198 When optimizing for code size, i.e. when `optimize_size' is 24199 nonzero, this target hook should be used to estimate the relative 24200 size cost of an expression, again relative to `COSTS_N_INSNS'. 24201 24202 The hook returns true when all subexpressions of X have been 24203 processed, and false when `rtx_cost' should recurse. 24204 24205 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS) 24206 This hook computes the cost of an addressing mode that contains 24207 ADDRESS. If not defined, the cost is computed from the ADDRESS 24208 expression and the `TARGET_RTX_COST' hook. 24209 24210 For most CISC machines, the default cost is a good approximation 24211 of the true cost of the addressing mode. However, on RISC 24212 machines, all instructions normally have the same length and 24213 execution time. Hence all addresses will have equal costs. 24214 24215 In cases where more than one form of an address is known, the form 24216 with the lowest cost will be used. If multiple forms have the 24217 same, lowest, cost, the one that is the most complex will be used. 24218 24219 For example, suppose an address that is equal to the sum of a 24220 register and a constant is used twice in the same basic block. 24221 When this macro is not defined, the address will be computed in a 24222 register and memory references will be indirect through that 24223 register. On machines where the cost of the addressing mode 24224 containing the sum is no higher than that of a simple indirect 24225 reference, this will produce an additional instruction and 24226 possibly require an additional register. Proper specification of 24227 this macro eliminates this overhead for such machines. 24228 24229 This hook is never called with an invalid address. 24230 24231 On machines where an address involving more than one register is as 24232 cheap as an address computation involving only one register, 24233 defining `TARGET_ADDRESS_COST' to reflect this can cause two 24234 registers to be live over a region of code where only one would 24235 have been if `TARGET_ADDRESS_COST' were not defined in that 24236 manner. This effect should be considered in the definition of 24237 this macro. Equivalent costs should probably only be given to 24238 addresses with different numbers of registers on machines with 24239 lots of registers. 24240 24241 24242 File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros 24243 24244 15.18 Adjusting the Instruction Scheduler 24245 ========================================= 24246 24247 The instruction scheduler may need a fair amount of machine-specific 24248 adjustment in order to produce good code. GCC provides several target 24249 hooks for this purpose. It is usually enough to define just a few of 24250 them: try the first ones in this list first. 24251 24252 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void) 24253 This hook returns the maximum number of instructions that can ever 24254 issue at the same time on the target machine. The default is one. 24255 Although the insn scheduler can define itself the possibility of 24256 issue an insn on the same cycle, the value can serve as an 24257 additional constraint to issue insns on the same simulated 24258 processor cycle (see hooks `TARGET_SCHED_REORDER' and 24259 `TARGET_SCHED_REORDER2'). This value must be constant over the 24260 entire compilation. If you need it to vary depending on what the 24261 instructions are, you must use `TARGET_SCHED_VARIABLE_ISSUE'. 24262 24263 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int 24264 VERBOSE, rtx INSN, int MORE) 24265 This hook is executed by the scheduler after it has scheduled an 24266 insn from the ready list. It should return the number of insns 24267 which can still be issued in the current cycle. The default is 24268 `MORE - 1' for insns other than `CLOBBER' and `USE', which 24269 normally are not counted against the issue rate. You should 24270 define this hook if some insns take more machine resources than 24271 others, so that fewer insns can follow them in the same cycle. 24272 FILE is either a null pointer, or a stdio stream to write any 24273 debug output to. VERBOSE is the verbose level provided by 24274 `-fsched-verbose-N'. INSN is the instruction that was scheduled. 24275 24276 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx INSN, rtx LINK, rtx 24277 DEP_INSN, int COST) 24278 This function corrects the value of COST based on the relationship 24279 between INSN and DEP_INSN through the dependence LINK. It should 24280 return the new value. The default is to make no adjustment to 24281 COST. This can be used for example to specify to the scheduler 24282 using the traditional pipeline description that an output- or 24283 anti-dependence does not incur the same cost as a data-dependence. 24284 If the scheduler using the automaton based pipeline description, 24285 the cost of anti-dependence is zero and the cost of 24286 output-dependence is maximum of one and the difference of latency 24287 times of the first and the second insns. If these values are not 24288 acceptable, you could use the hook to modify them too. See also 24289 *note Processor pipeline description::. 24290 24291 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx INSN, int 24292 PRIORITY) 24293 This hook adjusts the integer scheduling priority PRIORITY of 24294 INSN. It should return the new priority. Increase the priority to 24295 execute INSN earlier, reduce the priority to execute INSN later. 24296 Do not define this hook if you do not need to adjust the 24297 scheduling priorities of insns. 24298 24299 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, rtx 24300 *READY, int *N_READYP, int CLOCK) 24301 This hook is executed by the scheduler after it has scheduled the 24302 ready list, to allow the machine description to reorder it (for 24303 example to combine two small instructions together on `VLIW' 24304 machines). FILE is either a null pointer, or a stdio stream to 24305 write any debug output to. VERBOSE is the verbose level provided 24306 by `-fsched-verbose-N'. READY is a pointer to the ready list of 24307 instructions that are ready to be scheduled. N_READYP is a 24308 pointer to the number of elements in the ready list. The scheduler 24309 reads the ready list in reverse order, starting with 24310 READY[*N_READYP-1] and going to READY[0]. CLOCK is the timer tick 24311 of the scheduler. You may modify the ready list and the number of 24312 ready insns. The return value is the number of insns that can 24313 issue this cycle; normally this is just `issue_rate'. See also 24314 `TARGET_SCHED_REORDER2'. 24315 24316 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE, 24317 rtx *READY, int *N_READY, CLOCK) 24318 Like `TARGET_SCHED_REORDER', but called at a different time. That 24319 function is called whenever the scheduler starts a new cycle. 24320 This one is called once per iteration over a cycle, immediately 24321 after `TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list 24322 and return the number of insns to be scheduled in the same cycle. 24323 Defining this hook can be useful if there are frequent situations 24324 where scheduling one insn causes other insns to become ready in 24325 the same cycle. These other insns can then be taken into account 24326 properly. 24327 24328 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK (rtx 24329 HEAD, rtx TAIL) 24330 This hook is called after evaluation forward dependencies of insns 24331 in chain given by two parameter values (HEAD and TAIL 24332 correspondingly) but before insns scheduling of the insn chain. 24333 For example, it can be used for better insn classification if it 24334 requires analysis of dependencies. This hook can use backward and 24335 forward dependencies of the insn scheduler because they are already 24336 calculated. 24337 24338 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int 24339 MAX_READY) 24340 This hook is executed by the scheduler at the beginning of each 24341 block of instructions that are to be scheduled. FILE is either a 24342 null pointer, or a stdio stream to write any debug output to. 24343 VERBOSE is the verbose level provided by `-fsched-verbose-N'. 24344 MAX_READY is the maximum number of insns in the current scheduling 24345 region that can be live at the same time. This can be used to 24346 allocate scratch space if it is needed, e.g. by 24347 `TARGET_SCHED_REORDER'. 24348 24349 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE) 24350 This hook is executed by the scheduler at the end of each block of 24351 instructions that are to be scheduled. It can be used to perform 24352 cleanup of any actions done by the other scheduling hooks. FILE 24353 is either a null pointer, or a stdio stream to write any debug 24354 output to. VERBOSE is the verbose level provided by 24355 `-fsched-verbose-N'. 24356 24357 -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int 24358 VERBOSE, int OLD_MAX_UID) 24359 This hook is executed by the scheduler after function level 24360 initializations. FILE is either a null pointer, or a stdio stream 24361 to write any debug output to. VERBOSE is the verbose level 24362 provided by `-fsched-verbose-N'. OLD_MAX_UID is the maximum insn 24363 uid when scheduling begins. 24364 24365 -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int 24366 VERBOSE) 24367 This is the cleanup hook corresponding to 24368 `TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a 24369 stdio stream to write any debug output to. VERBOSE is the verbose 24370 level provided by `-fsched-verbose-N'. 24371 24372 -- Target Hook: int TARGET_SCHED_DFA_PRE_CYCLE_INSN (void) 24373 The hook returns an RTL insn. The automaton state used in the 24374 pipeline hazard recognizer is changed as if the insn were scheduled 24375 when the new simulated processor cycle starts. Usage of the hook 24376 may simplify the automaton pipeline description for some VLIW 24377 processors. If the hook is defined, it is used only for the 24378 automaton based pipeline description. The default is not to 24379 change the state when the new simulated processor cycle starts. 24380 24381 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void) 24382 The hook can be used to initialize data used by the previous hook. 24383 24384 -- Target Hook: int TARGET_SCHED_DFA_POST_CYCLE_INSN (void) 24385 The hook is analogous to `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used 24386 to changed the state as if the insn were scheduled when the new 24387 simulated processor cycle finishes. 24388 24389 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void) 24390 The hook is analogous to `TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but 24391 used to initialize data used by the previous hook. 24392 24393 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 24394 (void) 24395 This hook controls better choosing an insn from the ready insn 24396 queue for the DFA-based insn scheduler. Usually the scheduler 24397 chooses the first insn from the queue. If the hook returns a 24398 positive value, an additional scheduler code tries all 24399 permutations of `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 24400 ()' subsequent ready insns to choose an insn whose issue will 24401 result in maximal number of issued insns on the same cycle. For 24402 the VLIW processor, the code could actually solve the problem of 24403 packing simple insns into the VLIW insn. Of course, if the rules 24404 of VLIW packing are described in the automaton. 24405 24406 This code also could be used for superscalar RISC processors. Let 24407 us consider a superscalar RISC processor with 3 pipelines. Some 24408 insns can be executed in pipelines A or B, some insns can be 24409 executed only in pipelines B or C, and one insn can be executed in 24410 pipeline B. The processor may issue the 1st insn into A and the 24411 2nd one into B. In this case, the 3rd insn will wait for freeing B 24412 until the next cycle. If the scheduler issues the 3rd insn the 24413 first, the processor could issue all 3 insns per cycle. 24414 24415 Actually this code demonstrates advantages of the automaton based 24416 pipeline hazard recognizer. We try quickly and easy many insn 24417 schedules to choose the best one. 24418 24419 The default is no multipass scheduling. 24420 24421 -- Target Hook: int 24422 TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD (rtx) 24423 This hook controls what insns from the ready insn queue will be 24424 considered for the multipass insn scheduling. If the hook returns 24425 zero for insn passed as the parameter, the insn will be not chosen 24426 to be issued. 24427 24428 The default is that any ready insns can be chosen to be issued. 24429 24430 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *, int, rtx, int, 24431 int, int *) 24432 This hook is called by the insn scheduler before issuing insn 24433 passed as the third parameter on given cycle. If the hook returns 24434 nonzero, the insn is not issued on given processors cycle. 24435 Instead of that, the processor cycle is advanced. If the value 24436 passed through the last parameter is zero, the insn ready queue is 24437 not sorted on the new cycle start as usually. The first parameter 24438 passes file for debugging output. The second one passes the 24439 scheduler verbose level of the debugging output. The forth and 24440 the fifth parameter values are correspondingly processor cycle on 24441 which the previous insn has been issued and the current processor 24442 cycle. 24443 24444 -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (rtx INSN1, rtx 24445 INSN2, rtx DEP_LINK, int DEP_COST, int DISTANCE) 24446 This hook is used to define which dependences are considered 24447 costly by the target, so costly that it is not advisable to 24448 schedule the insns that are involved in the dependence too close 24449 to one another. The parameters to this hook are as follows: The 24450 second parameter INSN2 is dependent upon the first parameter 24451 INSN1. The dependence between INSN1 and INSN2 is represented by 24452 the third parameter DEP_LINK. The fourth parameter COST is the 24453 cost of the dependence, and the fifth parameter DISTANCE is the 24454 distance in cycles between the two insns. The hook returns `true' 24455 if considering the distance between the two insns the dependence 24456 between them is considered costly by the target, and `false' 24457 otherwise. 24458 24459 Defining this hook can be useful in multiple-issue out-of-order 24460 machines, where (a) it's practically hopeless to predict the 24461 actual data/resource delays, however: (b) there's a better chance 24462 to predict the actual grouping that will be formed, and (c) 24463 correctly emulating the grouping can be very important. In such 24464 targets one may want to allow issuing dependent insns closer to 24465 one another--i.e., closer than the dependence distance; however, 24466 not in cases of "costly dependences", which this hooks allows to 24467 define. 24468 24469 -- Target Hook: int TARGET_SCHED_ADJUST_COST_2 (rtx INSN, int 24470 DEP_TYPE, rtx DEP_INSN, int COST) 24471 This hook is a modified version of `TARGET_SCHED_ADJUST_COST'. 24472 Instead of passing dependence as a second parameter, it passes a 24473 type of that dependence. This is useful to calculate cost of 24474 dependence between insns not having the corresponding link. If 24475 `TARGET_SCHED_ADJUST_COST_2' is defined it is used instead of 24476 `TARGET_SCHED_ADJUST_COST'. 24477 24478 -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void) 24479 This hook is called by the insn scheduler after emitting a new 24480 instruction to the instruction stream. The hook notifies a target 24481 backend to extend its per instruction data structures. 24482 24483 -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx INSN, int 24484 REQUEST, rtx *NEW_PAT) 24485 This hook is called by the insn scheduler when INSN has only 24486 speculative dependencies and therefore can be scheduled 24487 speculatively. The hook is used to check if the pattern of INSN 24488 has a speculative version and, in case of successful check, to 24489 generate that speculative pattern. The hook should return 1, if 24490 the instruction has a speculative form, or -1, if it doesn't. 24491 REQUEST describes the type of requested speculation. If the 24492 return value equals 1 then NEW_PAT is assigned the generated 24493 speculative pattern. 24494 24495 -- Target Hook: int TARGET_SCHED_NEEDS_BLOCK_P (rtx INSN) 24496 This hook is called by the insn scheduler during generation of 24497 recovery code for INSN. It should return nonzero, if the 24498 corresponding check instruction should branch to recovery code, or 24499 zero otherwise. 24500 24501 -- Target Hook: rtx TARGET_SCHED_GEN_CHECK (rtx INSN, rtx LABEL, int 24502 MUTATE_P) 24503 This hook is called by the insn scheduler to generate a pattern 24504 for recovery check instruction. If MUTATE_P is zero, then INSN is 24505 a speculative instruction for which the check should be generated. 24506 LABEL is either a label of a basic block, where recovery code 24507 should be emitted, or a null pointer, when requested check doesn't 24508 branch to recovery code (a simple check). If MUTATE_P is nonzero, 24509 then a pattern for a branchy check corresponding to a simple check 24510 denoted by INSN should be generated. In this case LABEL can't be 24511 null. 24512 24513 -- Target Hook: int 24514 TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC (rtx INSN) 24515 This hook is used as a workaround for 24516 `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD' not being 24517 called on the first instruction of the ready list. The hook is 24518 used to discard speculative instruction that stand first in the 24519 ready list from being scheduled on the current cycle. For 24520 non-speculative instructions, the hook should always return 24521 nonzero. For example, in the ia64 backend the hook is used to 24522 cancel data speculative insns when the ALAT table is nearly full. 24523 24524 -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (unsigned int 24525 *FLAGS, spec_info_t SPEC_INFO) 24526 This hook is used by the insn scheduler to find out what features 24527 should be enabled/used. FLAGS initially may have either the 24528 SCHED_RGN or SCHED_EBB bit set. This denotes the scheduler pass 24529 for which the data should be provided. The target backend should 24530 modify FLAGS by modifying the bits corresponding to the following 24531 features: USE_DEPS_LIST, USE_GLAT, DETACH_LIFE_INFO, and 24532 DO_SPECULATION. For the DO_SPECULATION feature an additional 24533 structure SPEC_INFO should be filled by the target. The structure 24534 describes speculation types that can be used in the scheduler. 24535 24536 24537 File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros 24538 24539 15.19 Dividing the Output into Sections (Texts, Data, ...) 24540 ========================================================== 24541 24542 An object file is divided into sections containing different types of 24543 data. In the most common case, there are three sections: the "text 24544 section", which holds instructions and read-only data; the "data 24545 section", which holds initialized writable data; and the "bss section", 24546 which holds uninitialized data. Some systems have other kinds of 24547 sections. 24548 24549 `varasm.c' provides several well-known sections, such as 24550 `text_section', `data_section' and `bss_section'. The normal way of 24551 controlling a `FOO_section' variable is to define the associated 24552 `FOO_SECTION_ASM_OP' macro, as described below. The macros are only 24553 read once, when `varasm.c' initializes itself, so their values must be 24554 run-time constants. They may however depend on command-line flags. 24555 24556 _Note:_ Some run-time files, such `crtstuff.c', also make use of the 24557 `FOO_SECTION_ASM_OP' macros, and expect them to be string literals. 24558 24559 Some assemblers require a different string to be written every time a 24560 section is selected. If your assembler falls into this category, you 24561 should define the `TARGET_ASM_INIT_SECTIONS' hook and use 24562 `get_unnamed_section' to set up the sections. 24563 24564 You must always create a `text_section', either by defining 24565 `TEXT_SECTION_ASM_OP' or by initializing `text_section' in 24566 `TARGET_ASM_INIT_SECTIONS'. The same is true of `data_section' and 24567 `DATA_SECTION_ASM_OP'. If you do not create a distinct 24568 `readonly_data_section', the default is to reuse `text_section'. 24569 24570 All the other `varasm.c' sections are optional, and are null if the 24571 target does not provide them. 24572 24573 -- Macro: TEXT_SECTION_ASM_OP 24574 A C expression whose value is a string, including spacing, 24575 containing the assembler operation that should precede 24576 instructions and read-only data. Normally `"\t.text"' is right. 24577 24578 -- Macro: HOT_TEXT_SECTION_NAME 24579 If defined, a C string constant for the name of the section 24580 containing most frequently executed functions of the program. If 24581 not defined, GCC will provide a default definition if the target 24582 supports named sections. 24583 24584 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME 24585 If defined, a C string constant for the name of the section 24586 containing unlikely executed functions in the program. 24587 24588 -- Macro: DATA_SECTION_ASM_OP 24589 A C expression whose value is a string, including spacing, 24590 containing the assembler operation to identify the following data 24591 as writable initialized data. Normally `"\t.data"' is right. 24592 24593 -- Macro: SDATA_SECTION_ASM_OP 24594 If defined, a C expression whose value is a string, including 24595 spacing, containing the assembler operation to identify the 24596 following data as initialized, writable small data. 24597 24598 -- Macro: READONLY_DATA_SECTION_ASM_OP 24599 A C expression whose value is a string, including spacing, 24600 containing the assembler operation to identify the following data 24601 as read-only initialized data. 24602 24603 -- Macro: BSS_SECTION_ASM_OP 24604 If defined, a C expression whose value is a string, including 24605 spacing, containing the assembler operation to identify the 24606 following data as uninitialized global data. If not defined, and 24607 neither `ASM_OUTPUT_BSS' nor `ASM_OUTPUT_ALIGNED_BSS' are defined, 24608 uninitialized global data will be output in the data section if 24609 `-fno-common' is passed, otherwise `ASM_OUTPUT_COMMON' will be 24610 used. 24611 24612 -- Macro: SBSS_SECTION_ASM_OP 24613 If defined, a C expression whose value is a string, including 24614 spacing, containing the assembler operation to identify the 24615 following data as uninitialized, writable small data. 24616 24617 -- Macro: INIT_SECTION_ASM_OP 24618 If defined, a C expression whose value is a string, including 24619 spacing, containing the assembler operation to identify the 24620 following data as initialization code. If not defined, GCC will 24621 assume such a section does not exist. This section has no 24622 corresponding `init_section' variable; it is used entirely in 24623 runtime code. 24624 24625 -- Macro: FINI_SECTION_ASM_OP 24626 If defined, a C expression whose value is a string, including 24627 spacing, containing the assembler operation to identify the 24628 following data as finalization code. If not defined, GCC will 24629 assume such a section does not exist. This section has no 24630 corresponding `fini_section' variable; it is used entirely in 24631 runtime code. 24632 24633 -- Macro: INIT_ARRAY_SECTION_ASM_OP 24634 If defined, a C expression whose value is a string, including 24635 spacing, containing the assembler operation to identify the 24636 following data as part of the `.init_array' (or equivalent) 24637 section. If not defined, GCC will assume such a section does not 24638 exist. Do not define both this macro and `INIT_SECTION_ASM_OP'. 24639 24640 -- Macro: FINI_ARRAY_SECTION_ASM_OP 24641 If defined, a C expression whose value is a string, including 24642 spacing, containing the assembler operation to identify the 24643 following data as part of the `.fini_array' (or equivalent) 24644 section. If not defined, GCC will assume such a section does not 24645 exist. Do not define both this macro and `FINI_SECTION_ASM_OP'. 24646 24647 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION) 24648 If defined, an ASM statement that switches to a different section 24649 via SECTION_OP, calls FUNCTION, and switches back to the text 24650 section. This is used in `crtstuff.c' if `INIT_SECTION_ASM_OP' or 24651 `FINI_SECTION_ASM_OP' to calls to initialization and finalization 24652 functions from the init and fini sections. By default, this macro 24653 uses a simple function call. Some ports need hand-crafted 24654 assembly code to avoid dependencies on registers initialized in 24655 the function prologue or to ensure that constant pools don't end 24656 up too far way in the text section. 24657 24658 -- Macro: TARGET_LIBGCC_SDATA_SECTION 24659 If defined, a string which names the section into which small 24660 variables defined in crtstuff and libgcc should go. This is useful 24661 when the target has options for optimizing access to small data, 24662 and you want the crtstuff and libgcc routines to be conservative 24663 in what they expect of your application yet liberal in what your 24664 application expects. For example, for targets with a `.sdata' 24665 section (like MIPS), you could compile crtstuff with `-G 0' so 24666 that it doesn't require small data support from your application, 24667 but use this macro to put small data into `.sdata' so that your 24668 application can access these variables whether it uses small data 24669 or not. 24670 24671 -- Macro: FORCE_CODE_SECTION_ALIGN 24672 If defined, an ASM statement that aligns a code section to some 24673 arbitrary boundary. This is used to force all fragments of the 24674 `.init' and `.fini' sections to have to same alignment and thus 24675 prevent the linker from having to add any padding. 24676 24677 -- Macro: JUMP_TABLES_IN_TEXT_SECTION 24678 Define this macro to be an expression with a nonzero value if jump 24679 tables (for `tablejump' insns) should be output in the text 24680 section, along with the assembler instructions. Otherwise, the 24681 readonly data section is used. 24682 24683 This macro is irrelevant if there is no separate readonly data 24684 section. 24685 24686 -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void) 24687 Define this hook if you need to do something special to set up the 24688 `varasm.c' sections, or if your target has some special sections 24689 of its own that you need to create. 24690 24691 GCC calls this hook after processing the command line, but before 24692 writing any assembly code, and before calling any of the 24693 section-returning hooks described below. 24694 24695 -- Target Hook: TARGET_ASM_RELOC_RW_MASK (void) 24696 Return a mask describing how relocations should be treated when 24697 selecting sections. Bit 1 should be set if global relocations 24698 should be placed in a read-write section; bit 0 should be set if 24699 local relocations should be placed in a read-write section. 24700 24701 The default version of this function returns 3 when `-fpic' is in 24702 effect, and 0 otherwise. The hook is typically redefined when the 24703 target cannot support (some kinds of) dynamic relocations in 24704 read-only sections even in executables. 24705 24706 -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int 24707 RELOC, unsigned HOST_WIDE_INT ALIGN) 24708 Return the section into which EXP should be placed. You can 24709 assume that EXP is either a `VAR_DECL' node or a constant of some 24710 sort. RELOC indicates whether the initial value of EXP requires 24711 link-time relocations. Bit 0 is set when variable contains local 24712 relocations only, while bit 1 is set for global relocations. 24713 ALIGN is the constant alignment in bits. 24714 24715 The default version of this function takes care of putting 24716 read-only variables in `readonly_data_section'. 24717 24718 See also USE_SELECT_SECTION_FOR_FUNCTIONS. 24719 24720 -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS 24721 Define this macro if you wish TARGET_ASM_SELECT_SECTION to be 24722 called for `FUNCTION_DECL's as well as for variables and constants. 24723 24724 In the case of a `FUNCTION_DECL', RELOC will be zero if the 24725 function has been determined to be likely to be called, and 24726 nonzero if it is unlikely to be called. 24727 24728 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC) 24729 Build up a unique section name, expressed as a `STRING_CST' node, 24730 and assign it to `DECL_SECTION_NAME (DECL)'. As with 24731 `TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial 24732 value of EXP requires link-time relocations. 24733 24734 The default version of this function appends the symbol name to the 24735 ELF section name that would normally be used for the symbol. For 24736 example, the function `foo' would be placed in `.text.foo'. 24737 Whatever the actual target object format, this is often good 24738 enough. 24739 24740 -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree 24741 DECL) 24742 Return the readonly data section associated with 24743 `DECL_SECTION_NAME (DECL)'. The default version of this function 24744 selects `.gnu.linkonce.r.name' if the function's section is 24745 `.gnu.linkonce.t.name', `.rodata.name' if function is in 24746 `.text.name', and the normal readonly-data section otherwise. 24747 24748 -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (enum 24749 machine_mode MODE, rtx X, unsigned HOST_WIDE_INT ALIGN) 24750 Return the section into which a constant X, of mode MODE, should 24751 be placed. You can assume that X is some kind of constant in RTL. 24752 The argument MODE is redundant except in the case of a 24753 `const_int' rtx. ALIGN is the constant alignment in bits. 24754 24755 The default version of this function takes care of putting symbolic 24756 constants in `flag_pic' mode in `data_section' and everything else 24757 in `readonly_data_section'. 24758 24759 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL, 24760 int NEW_DECL_P) 24761 Define this hook if references to a symbol or a constant must be 24762 treated differently depending on something about the variable or 24763 function named by the symbol (such as what section it is in). 24764 24765 The hook is executed immediately after rtl has been created for 24766 DECL, which may be a variable or function declaration or an entry 24767 in the constant pool. In either case, RTL is the rtl in question. 24768 Do _not_ use `DECL_RTL (DECL)' in this hook; that field may not 24769 have been initialized yet. 24770 24771 In the case of a constant, it is safe to assume that the rtl is a 24772 `mem' whose address is a `symbol_ref'. Most decls will also have 24773 this form, but that is not guaranteed. Global register variables, 24774 for instance, will have a `reg' for their rtl. (Normally the 24775 right thing to do with such unusual rtl is leave it alone.) 24776 24777 The NEW_DECL_P argument will be true if this is the first time 24778 that `TARGET_ENCODE_SECTION_INFO' has been invoked on this decl. 24779 It will be false for subsequent invocations, which will happen for 24780 duplicate declarations. Whether or not anything must be done for 24781 the duplicate declaration depends on whether the hook examines 24782 `DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is 24783 called for a constant. 24784 24785 The usual thing for this hook to do is to record flags in the 24786 `symbol_ref', using `SYMBOL_REF_FLAG' or `SYMBOL_REF_FLAGS'. 24787 Historically, the name string was modified if it was necessary to 24788 encode more than one bit of information, but this practice is now 24789 discouraged; use `SYMBOL_REF_FLAGS'. 24790 24791 The default definition of this hook, `default_encode_section_info' 24792 in `varasm.c', sets a number of commonly-useful bits in 24793 `SYMBOL_REF_FLAGS'. Check whether the default does what you need 24794 before overriding it. 24795 24796 -- Target Hook: const char *TARGET_STRIP_NAME_ENCODING (const char 24797 *name) 24798 Decode NAME and return the real name part, sans the characters 24799 that `TARGET_ENCODE_SECTION_INFO' may have added. 24800 24801 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (tree EXP) 24802 Returns true if EXP should be placed into a "small data" section. 24803 The default version of this hook always returns false. 24804 24805 -- Variable: Target Hook bool TARGET_HAVE_SRODATA_SECTION 24806 Contains the value true if the target places read-only "small 24807 data" into a separate section. The default value is false. 24808 24809 -- Target Hook: bool TARGET_BINDS_LOCAL_P (tree EXP) 24810 Returns true if EXP names an object for which name resolution 24811 rules must resolve to the current "module" (dynamic shared library 24812 or executable image). 24813 24814 The default version of this hook implements the name resolution 24815 rules for ELF, which has a looser model of global name binding 24816 than other currently supported object file formats. 24817 24818 -- Variable: Target Hook bool TARGET_HAVE_TLS 24819 Contains the value true if the target supports thread-local 24820 storage. The default value is false. 24821 24822 24823 File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros 24824 24825 15.20 Position Independent Code 24826 =============================== 24827 24828 This section describes macros that help implement generation of position 24829 independent code. Simply defining these macros is not enough to 24830 generate valid PIC; you must also add support to the macros 24831 `GO_IF_LEGITIMATE_ADDRESS' and `PRINT_OPERAND_ADDRESS', as well as 24832 `LEGITIMIZE_ADDRESS'. You must modify the definition of `movsi' to do 24833 something appropriate when the source operand contains a symbolic 24834 address. You may also need to alter the handling of switch statements 24835 so that they use relative addresses. 24836 24837 -- Macro: PIC_OFFSET_TABLE_REGNUM 24838 The register number of the register used to address a table of 24839 static data addresses in memory. In some cases this register is 24840 defined by a processor's "application binary interface" (ABI). 24841 When this macro is defined, RTL is generated for this register 24842 once, as with the stack pointer and frame pointer registers. If 24843 this macro is not defined, it is up to the machine-dependent files 24844 to allocate such a register (if necessary). Note that this 24845 register must be fixed when in use (e.g. when `flag_pic' is true). 24846 24847 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED 24848 Define this macro if the register defined by 24849 `PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. Do not define 24850 this macro if `PIC_OFFSET_TABLE_REGNUM' is not defined. 24851 24852 -- Macro: LEGITIMATE_PIC_OPERAND_P (X) 24853 A C expression that is nonzero if X is a legitimate immediate 24854 operand on the target machine when generating position independent 24855 code. You can assume that X satisfies `CONSTANT_P', so you need 24856 not check this. You can also assume FLAG_PIC is true, so you need 24857 not check it either. You need not define this macro if all 24858 constants (including `SYMBOL_REF') can be immediate operands when 24859 generating position independent code. 24860 24861 24862 File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros 24863 24864 15.21 Defining the Output Assembler Language 24865 ============================================ 24866 24867 This section describes macros whose principal purpose is to describe how 24868 to write instructions in assembler language--rather than what the 24869 instructions do. 24870 24871 * Menu: 24872 24873 * File Framework:: Structural information for the assembler file. 24874 * Data Output:: Output of constants (numbers, strings, addresses). 24875 * Uninitialized Data:: Output of uninitialized variables. 24876 * Label Output:: Output and generation of labels. 24877 * Initialization:: General principles of initialization 24878 and termination routines. 24879 * Macros for Initialization:: 24880 Specific macros that control the handling of 24881 initialization and termination routines. 24882 * Instruction Output:: Output of actual instructions. 24883 * Dispatch Tables:: Output of jump tables. 24884 * Exception Region Output:: Output of exception region code. 24885 * Alignment Output:: Pseudo ops for alignment and skipping data. 24886 24887 24888 File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format 24889 24890 15.21.1 The Overall Framework of an Assembler File 24891 -------------------------------------------------- 24892 24893 This describes the overall framework of an assembly file. 24894 24895 -- Target Hook: void TARGET_ASM_FILE_START () 24896 Output to `asm_out_file' any text which the assembler expects to 24897 find at the beginning of a file. The default behavior is 24898 controlled by two flags, documented below. Unless your target's 24899 assembler is quite unusual, if you override the default, you 24900 should call `default_file_start' at some point in your target 24901 hook. This lets other target files rely on these variables. 24902 24903 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF 24904 If this flag is true, the text of the macro `ASM_APP_OFF' will be 24905 printed as the very first line in the assembly file, unless 24906 `-fverbose-asm' is in effect. (If that macro has been defined to 24907 the empty string, this variable has no effect.) With the normal 24908 definition of `ASM_APP_OFF', the effect is to notify the GNU 24909 assembler that it need not bother stripping comments or extra 24910 whitespace from its input. This allows it to work a bit faster. 24911 24912 The default is false. You should not set it to true unless you 24913 have verified that your port does not generate any extra 24914 whitespace or comments that will cause GAS to issue errors in 24915 NO_APP mode. 24916 24917 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE 24918 If this flag is true, `output_file_directive' will be called for 24919 the primary source file, immediately after printing `ASM_APP_OFF' 24920 (if that is enabled). Most ELF assemblers expect this to be done. 24921 The default is false. 24922 24923 -- Target Hook: void TARGET_ASM_FILE_END () 24924 Output to `asm_out_file' any text which the assembler expects to 24925 find at the end of a file. The default is to output nothing. 24926 24927 -- Function: void file_end_indicate_exec_stack () 24928 Some systems use a common convention, the `.note.GNU-stack' 24929 special section, to indicate whether or not an object file relies 24930 on the stack being executable. If your system uses this 24931 convention, you should define `TARGET_ASM_FILE_END' to this 24932 function. If you need to do other things in that hook, have your 24933 hook function call this function. 24934 24935 -- Macro: ASM_COMMENT_START 24936 A C string constant describing how to begin a comment in the target 24937 assembler language. The compiler assumes that the comment will 24938 end at the end of the line. 24939 24940 -- Macro: ASM_APP_ON 24941 A C string constant for text to be output before each `asm' 24942 statement or group of consecutive ones. Normally this is 24943 `"#APP"', which is a comment that has no effect on most assemblers 24944 but tells the GNU assembler that it must check the lines that 24945 follow for all valid assembler constructs. 24946 24947 -- Macro: ASM_APP_OFF 24948 A C string constant for text to be output after each `asm' 24949 statement or group of consecutive ones. Normally this is 24950 `"#NO_APP"', which tells the GNU assembler to resume making the 24951 time-saving assumptions that are valid for ordinary compiler 24952 output. 24953 24954 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME) 24955 A C statement to output COFF information or DWARF debugging 24956 information which indicates that filename NAME is the current 24957 source file to the stdio stream STREAM. 24958 24959 This macro need not be defined if the standard form of output for 24960 the file format in use is appropriate. 24961 24962 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING) 24963 A C statement to output the string STRING to the stdio stream 24964 STREAM. If you do not call the function `output_quoted_string' in 24965 your config files, GCC will only call it to output filenames to 24966 the assembler source. So you can use it to canonicalize the format 24967 of the filename using this macro. 24968 24969 -- Macro: ASM_OUTPUT_IDENT (STREAM, STRING) 24970 A C statement to output something to the assembler file to handle a 24971 `#ident' directive containing the text STRING. If this macro is 24972 not defined, nothing is output for a `#ident' directive. 24973 24974 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME, 24975 unsigned int FLAGS, unsigned int ALIGN) 24976 Output assembly directives to switch to section NAME. The section 24977 should have attributes as specified by FLAGS, which is a bit mask 24978 of the `SECTION_*' flags defined in `output.h'. If ALIGN is 24979 nonzero, it contains an alignment in bytes to be used for the 24980 section, otherwise some target default should be used. Only 24981 targets that must specify an alignment within the section 24982 directive need pay attention to ALIGN - we will still use 24983 `ASM_OUTPUT_ALIGN'. 24984 24985 -- Target Hook: bool TARGET_HAVE_NAMED_SECTIONS 24986 This flag is true if the target supports 24987 `TARGET_ASM_NAMED_SECTION'. 24988 24989 -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS 24990 This flag is true if we can create zeroed data by switching to a 24991 BSS section and then using `ASM_OUTPUT_SKIP' to allocate the space. 24992 This is true on most ELF targets. 24993 24994 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL, 24995 const char *NAME, int RELOC) 24996 Choose a set of section attributes for use by 24997 `TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a 24998 section name, and whether or not the declaration's initializer may 24999 contain runtime relocations. DECL may be null, in which case 25000 read-write data should be assumed. 25001 25002 The default version of this function handles choosing code vs data, 25003 read-only vs read-write data, and `flag_pic'. You should only 25004 need to override this if your target has special flags that might 25005 be set via `__attribute__'. 25006 25007 25008 File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format 25009 25010 15.21.2 Output of Data 25011 ---------------------- 25012 25013 -- Target Hook: const char * TARGET_ASM_BYTE_OP 25014 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP 25015 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP 25016 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP 25017 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP 25018 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP 25019 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP 25020 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP 25021 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP 25022 These hooks specify assembly directives for creating certain kinds 25023 of integer object. The `TARGET_ASM_BYTE_OP' directive creates a 25024 byte-sized object, the `TARGET_ASM_ALIGNED_HI_OP' one creates an 25025 aligned two-byte object, and so on. Any of the hooks may be 25026 `NULL', indicating that no suitable directive is available. 25027 25028 The compiler will print these strings at the start of a new line, 25029 followed immediately by the object's initial value. In most cases, 25030 the string should contain a tab, a pseudo-op, and then another tab. 25031 25032 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int 25033 ALIGNED_P) 25034 The `assemble_integer' function uses this hook to output an 25035 integer object. X is the object's value, SIZE is its size in 25036 bytes and ALIGNED_P indicates whether it is aligned. The function 25037 should return `true' if it was able to output the object. If it 25038 returns false, `assemble_integer' will try to split the object 25039 into smaller parts. 25040 25041 The default implementation of this hook will use the 25042 `TARGET_ASM_BYTE_OP' family of strings, returning `false' when the 25043 relevant string is `NULL'. 25044 25045 -- Macro: OUTPUT_ADDR_CONST_EXTRA (STREAM, X, FAIL) 25046 A C statement to recognize RTX patterns that `output_addr_const' 25047 can't deal with, and output assembly code to STREAM corresponding 25048 to the pattern X. This may be used to allow machine-dependent 25049 `UNSPEC's to appear within constants. 25050 25051 If `OUTPUT_ADDR_CONST_EXTRA' fails to recognize a pattern, it must 25052 `goto fail', so that a standard error message is printed. If it 25053 prints an error message itself, by calling, for example, 25054 `output_operand_lossage', it may just complete normally. 25055 25056 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN) 25057 A C statement to output to the stdio stream STREAM an assembler 25058 instruction to assemble a string constant containing the LEN bytes 25059 at PTR. PTR will be a C expression of type `char *' and LEN a C 25060 expression of type `int'. 25061 25062 If the assembler has a `.ascii' pseudo-op as found in the Berkeley 25063 Unix assembler, do not define the macro `ASM_OUTPUT_ASCII'. 25064 25065 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N) 25066 A C statement to output word N of a function descriptor for DECL. 25067 This must be defined if `TARGET_VTABLE_USES_DESCRIPTORS' is 25068 defined, and is otherwise unused. 25069 25070 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION 25071 You may define this macro as a C expression. You should define the 25072 expression to have a nonzero value if GCC should output the 25073 constant pool for a function before the code for the function, or 25074 a zero value if GCC should output the constant pool after the 25075 function. If you do not define this macro, the usual case, GCC 25076 will output the constant pool before the function. 25077 25078 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE) 25079 A C statement to output assembler commands to define the start of 25080 the constant pool for a function. FUNNAME is a string giving the 25081 name of the function. Should the return type of the function be 25082 required, it can be obtained via FUNDECL. SIZE is the size, in 25083 bytes, of the constant pool that will be written immediately after 25084 this call. 25085 25086 If no constant-pool prefix is required, the usual case, this macro 25087 need not be defined. 25088 25089 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, 25090 LABELNO, JUMPTO) 25091 A C statement (with or without semicolon) to output a constant in 25092 the constant pool, if it needs special treatment. (This macro 25093 need not do anything for RTL expressions that can be output 25094 normally.) 25095 25096 The argument FILE is the standard I/O stream to output the 25097 assembler code on. X is the RTL expression for the constant to 25098 output, and MODE is the machine mode (in case X is a `const_int'). 25099 ALIGN is the required alignment for the value X; you should 25100 output an assembler directive to force this much alignment. 25101 25102 The argument LABELNO is a number to use in an internal label for 25103 the address of this pool entry. The definition of this macro is 25104 responsible for outputting the label definition at the proper 25105 place. Here is how to do this: 25106 25107 `(*targetm.asm_out.internal_label)' (FILE, "LC", LABELNO); 25108 25109 When you output a pool entry specially, you should end with a 25110 `goto' to the label JUMPTO. This will prevent the same pool entry 25111 from being output a second time in the usual manner. 25112 25113 You need not define this macro if it would do nothing. 25114 25115 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE) 25116 A C statement to output assembler commands to at the end of the 25117 constant pool for a function. FUNNAME is a string giving the name 25118 of the function. Should the return type of the function be 25119 required, you can obtain it via FUNDECL. SIZE is the size, in 25120 bytes, of the constant pool that GCC wrote immediately before this 25121 call. 25122 25123 If no constant-pool epilogue is required, the usual case, you need 25124 not define this macro. 25125 25126 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C) 25127 Define this macro as a C expression which is nonzero if C is used 25128 as a logical line separator by the assembler. 25129 25130 If you do not define this macro, the default is that only the 25131 character `;' is treated as a logical line separator. 25132 25133 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN 25134 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN 25135 These target hooks are C string constants, describing the syntax 25136 in the assembler for grouping arithmetic expressions. If not 25137 overridden, they default to normal parentheses, which is correct 25138 for most assemblers. 25139 25140 These macros are provided by `real.h' for writing the definitions of 25141 `ASM_OUTPUT_DOUBLE' and the like: 25142 25143 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L) 25144 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L) 25145 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L) 25146 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L) 25147 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L) 25148 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L) 25149 These translate X, of type `REAL_VALUE_TYPE', to the target's 25150 floating point representation, and store its bit pattern in the 25151 variable L. For `REAL_VALUE_TO_TARGET_SINGLE' and 25152 `REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple 25153 `long int'. For the others, it should be an array of `long int'. 25154 The number of elements in this array is determined by the size of 25155 the desired target floating point data type: 32 bits of it go in 25156 each `long int' array element. Each array element holds 32 bits 25157 of the result, even if `long int' is wider than 32 bits on the 25158 host machine. 25159 25160 The array element values are designed so that you can print them 25161 out using `fprintf' in the order they should appear in the target 25162 machine's memory. 25163 25164 25165 File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format 25166 25167 15.21.3 Output of Uninitialized Variables 25168 ----------------------------------------- 25169 25170 Each of the macros in this section is used to do the whole job of 25171 outputting a single uninitialized variable. 25172 25173 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED) 25174 A C statement (sans semicolon) to output to the stdio stream 25175 STREAM the assembler definition of a common-label named NAME whose 25176 size is SIZE bytes. The variable ROUNDED is the size rounded up 25177 to whatever alignment the caller wants. 25178 25179 Use the expression `assemble_name (STREAM, NAME)' to output the 25180 name itself; before and after that, output the additional 25181 assembler syntax for defining the name, and a newline. 25182 25183 This macro controls how the assembler definitions of uninitialized 25184 common global variables are output. 25185 25186 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT) 25187 Like `ASM_OUTPUT_COMMON' except takes the required alignment as a 25188 separate, explicit argument. If you define this macro, it is used 25189 in place of `ASM_OUTPUT_COMMON', and gives you more flexibility in 25190 handling the required alignment of the variable. The alignment is 25191 specified as the number of bits. 25192 25193 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE, 25194 ALIGNMENT) 25195 Like `ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable 25196 to be output, if there is one, or `NULL_TREE' if there is no 25197 corresponding variable. If you define this macro, GCC will use it 25198 in place of both `ASM_OUTPUT_COMMON' and 25199 `ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to 25200 see the variable's decl in order to chose what to output. 25201 25202 -- Macro: ASM_OUTPUT_BSS (STREAM, DECL, NAME, SIZE, ROUNDED) 25203 A C statement (sans semicolon) to output to the stdio stream 25204 STREAM the assembler definition of uninitialized global DECL named 25205 NAME whose size is SIZE bytes. The variable ROUNDED is the size 25206 rounded up to whatever alignment the caller wants. 25207 25208 Try to use function `asm_output_bss' defined in `varasm.c' when 25209 defining this macro. If unable, use the expression `assemble_name 25210 (STREAM, NAME)' to output the name itself; before and after that, 25211 output the additional assembler syntax for defining the name, and 25212 a newline. 25213 25214 There are two ways of handling global BSS. One is to define either 25215 this macro or its aligned counterpart, `ASM_OUTPUT_ALIGNED_BSS'. 25216 The other is to have `TARGET_ASM_SELECT_SECTION' return a 25217 switchable BSS section (*note 25218 TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::). You do not need to do 25219 both. 25220 25221 Some languages do not have `common' data, and require a non-common 25222 form of global BSS in order to handle uninitialized globals 25223 efficiently. C++ is one example of this. However, if the target 25224 does not support global BSS, the front end may choose to make 25225 globals common in order to save space in the object file. 25226 25227 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT) 25228 Like `ASM_OUTPUT_BSS' except takes the required alignment as a 25229 separate, explicit argument. If you define this macro, it is used 25230 in place of `ASM_OUTPUT_BSS', and gives you more flexibility in 25231 handling the required alignment of the variable. The alignment is 25232 specified as the number of bits. 25233 25234 Try to use function `asm_output_aligned_bss' defined in file 25235 `varasm.c' when defining this macro. 25236 25237 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED) 25238 A C statement (sans semicolon) to output to the stdio stream 25239 STREAM the assembler definition of a local-common-label named NAME 25240 whose size is SIZE bytes. The variable ROUNDED is the size 25241 rounded up to whatever alignment the caller wants. 25242 25243 Use the expression `assemble_name (STREAM, NAME)' to output the 25244 name itself; before and after that, output the additional 25245 assembler syntax for defining the name, and a newline. 25246 25247 This macro controls how the assembler definitions of uninitialized 25248 static variables are output. 25249 25250 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT) 25251 Like `ASM_OUTPUT_LOCAL' except takes the required alignment as a 25252 separate, explicit argument. If you define this macro, it is used 25253 in place of `ASM_OUTPUT_LOCAL', and gives you more flexibility in 25254 handling the required alignment of the variable. The alignment is 25255 specified as the number of bits. 25256 25257 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE, 25258 ALIGNMENT) 25259 Like `ASM_OUTPUT_ALIGNED_DECL' except that DECL of the variable to 25260 be output, if there is one, or `NULL_TREE' if there is no 25261 corresponding variable. If you define this macro, GCC will use it 25262 in place of both `ASM_OUTPUT_DECL' and `ASM_OUTPUT_ALIGNED_DECL'. 25263 Define this macro when you need to see the variable's decl in 25264 order to chose what to output. 25265 25266 25267 File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format 25268 25269 15.21.4 Output and Generation of Labels 25270 --------------------------------------- 25271 25272 This is about outputting labels. 25273 25274 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME) 25275 A C statement (sans semicolon) to output to the stdio stream 25276 STREAM the assembler definition of a label named NAME. Use the 25277 expression `assemble_name (STREAM, NAME)' to output the name 25278 itself; before and after that, output the additional assembler 25279 syntax for defining the name, and a newline. A default definition 25280 of this macro is provided which is correct for most systems. 25281 25282 -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME) 25283 Identical to `ASM_OUTPUT_LABEL', except that NAME is known to 25284 refer to a compiler-generated label. The default definition uses 25285 `assemble_name_raw', which is like `assemble_name' except that it 25286 is more efficient. 25287 25288 -- Macro: SIZE_ASM_OP 25289 A C string containing the appropriate assembler directive to 25290 specify the size of a symbol, without any arguments. On systems 25291 that use ELF, the default (in `config/elfos.h') is `"\t.size\t"'; 25292 on other systems, the default is not to define this macro. 25293 25294 Define this macro only if it is correct to use the default 25295 definitions of `ASM_OUTPUT_SIZE_DIRECTIVE' and 25296 `ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own 25297 custom definitions of those macros, or if you do not need explicit 25298 symbol sizes at all, do not define this macro. 25299 25300 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE) 25301 A C statement (sans semicolon) to output to the stdio stream 25302 STREAM a directive telling the assembler that the size of the 25303 symbol NAME is SIZE. SIZE is a `HOST_WIDE_INT'. If you define 25304 `SIZE_ASM_OP', a default definition of this macro is provided. 25305 25306 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME) 25307 A C statement (sans semicolon) to output to the stdio stream 25308 STREAM a directive telling the assembler to calculate the size of 25309 the symbol NAME by subtracting its address from the current 25310 address. 25311 25312 If you define `SIZE_ASM_OP', a default definition of this macro is 25313 provided. The default assumes that the assembler recognizes a 25314 special `.' symbol as referring to the current address, and can 25315 calculate the difference between this and another symbol. If your 25316 assembler does not recognize `.' or cannot do calculations with 25317 it, you will need to redefine `ASM_OUTPUT_MEASURED_SIZE' to use 25318 some other technique. 25319 25320 -- Macro: TYPE_ASM_OP 25321 A C string containing the appropriate assembler directive to 25322 specify the type of a symbol, without any arguments. On systems 25323 that use ELF, the default (in `config/elfos.h') is `"\t.type\t"'; 25324 on other systems, the default is not to define this macro. 25325 25326 Define this macro only if it is correct to use the default 25327 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 25328 need your own custom definition of this macro, or if you do not 25329 need explicit symbol types at all, do not define this macro. 25330 25331 -- Macro: TYPE_OPERAND_FMT 25332 A C string which specifies (using `printf' syntax) the format of 25333 the second operand to `TYPE_ASM_OP'. On systems that use ELF, the 25334 default (in `config/elfos.h') is `"@%s"'; on other systems, the 25335 default is not to define this macro. 25336 25337 Define this macro only if it is correct to use the default 25338 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 25339 need your own custom definition of this macro, or if you do not 25340 need explicit symbol types at all, do not define this macro. 25341 25342 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE) 25343 A C statement (sans semicolon) to output to the stdio stream 25344 STREAM a directive telling the assembler that the type of the 25345 symbol NAME is TYPE. TYPE is a C string; currently, that string 25346 is always either `"function"' or `"object"', but you should not 25347 count on this. 25348 25349 If you define `TYPE_ASM_OP' and `TYPE_OPERAND_FMT', a default 25350 definition of this macro is provided. 25351 25352 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL) 25353 A C statement (sans semicolon) to output to the stdio stream 25354 STREAM any text necessary for declaring the name NAME of a 25355 function which is being defined. This macro is responsible for 25356 outputting the label definition (perhaps using 25357 `ASM_OUTPUT_LABEL'). The argument DECL is the `FUNCTION_DECL' 25358 tree node representing the function. 25359 25360 If this macro is not defined, then the function name is defined in 25361 the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 25362 25363 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 25364 of this macro. 25365 25366 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL) 25367 A C statement (sans semicolon) to output to the stdio stream 25368 STREAM any text necessary for declaring the size of a function 25369 which is being defined. The argument NAME is the name of the 25370 function. The argument DECL is the `FUNCTION_DECL' tree node 25371 representing the function. 25372 25373 If this macro is not defined, then the function size is not 25374 defined. 25375 25376 You may wish to use `ASM_OUTPUT_MEASURED_SIZE' in the definition 25377 of this macro. 25378 25379 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL) 25380 A C statement (sans semicolon) to output to the stdio stream 25381 STREAM any text necessary for declaring the name NAME of an 25382 initialized variable which is being defined. This macro must 25383 output the label definition (perhaps using `ASM_OUTPUT_LABEL'). 25384 The argument DECL is the `VAR_DECL' tree node representing the 25385 variable. 25386 25387 If this macro is not defined, then the variable name is defined in 25388 the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 25389 25390 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' and/or 25391 `ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro. 25392 25393 -- Macro: ASM_DECLARE_CONSTANT_NAME (STREAM, NAME, EXP, SIZE) 25394 A C statement (sans semicolon) to output to the stdio stream 25395 STREAM any text necessary for declaring the name NAME of a 25396 constant which is being defined. This macro is responsible for 25397 outputting the label definition (perhaps using 25398 `ASM_OUTPUT_LABEL'). The argument EXP is the value of the 25399 constant, and SIZE is the size of the constant in bytes. NAME 25400 will be an internal label. 25401 25402 If this macro is not defined, then the NAME is defined in the 25403 usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 25404 25405 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 25406 of this macro. 25407 25408 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME) 25409 A C statement (sans semicolon) to output to the stdio stream 25410 STREAM any text necessary for claiming a register REGNO for a 25411 global variable DECL with name NAME. 25412 25413 If you don't define this macro, that is equivalent to defining it 25414 to do nothing. 25415 25416 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND) 25417 A C statement (sans semicolon) to finish up declaring a variable 25418 name once the compiler has processed its initializer fully and 25419 thus has had a chance to determine the size of an array when 25420 controlled by an initializer. This is used on systems where it's 25421 necessary to declare something about the size of the object. 25422 25423 If you don't define this macro, that is equivalent to defining it 25424 to do nothing. 25425 25426 You may wish to use `ASM_OUTPUT_SIZE_DIRECTIVE' and/or 25427 `ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro. 25428 25429 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const 25430 char *NAME) 25431 This target hook is a function to output to the stdio stream 25432 STREAM some commands that will make the label NAME global; that 25433 is, available for reference from other files. 25434 25435 The default implementation relies on a proper definition of 25436 `GLOBAL_ASM_OP'. 25437 25438 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME) 25439 A C statement (sans semicolon) to output to the stdio stream 25440 STREAM some commands that will make the label NAME weak; that is, 25441 available for reference from other files but only used if no other 25442 definition is available. Use the expression `assemble_name 25443 (STREAM, NAME)' to output the name itself; before and after that, 25444 output the additional assembler syntax for making that name weak, 25445 and a newline. 25446 25447 If you don't define this macro or `ASM_WEAKEN_DECL', GCC will not 25448 support weak symbols and you should not define the `SUPPORTS_WEAK' 25449 macro. 25450 25451 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE) 25452 Combines (and replaces) the function of `ASM_WEAKEN_LABEL' and 25453 `ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function 25454 or variable decl. If VALUE is not `NULL', this C statement should 25455 output to the stdio stream STREAM assembler code which defines 25456 (equates) the weak symbol NAME to have the value VALUE. If VALUE 25457 is `NULL', it should output commands to make NAME weak. 25458 25459 -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE) 25460 Outputs a directive that enables NAME to be used to refer to 25461 symbol VALUE with weak-symbol semantics. `decl' is the 25462 declaration of `name'. 25463 25464 -- Macro: SUPPORTS_WEAK 25465 A C expression which evaluates to true if the target supports weak 25466 symbols. 25467 25468 If you don't define this macro, `defaults.h' provides a default 25469 definition. If either `ASM_WEAKEN_LABEL' or `ASM_WEAKEN_DECL' is 25470 defined, the default definition is `1'; otherwise, it is `0'. 25471 Define this macro if you want to control weak symbol support with 25472 a compiler flag such as `-melf'. 25473 25474 -- Macro: MAKE_DECL_ONE_ONLY (DECL) 25475 A C statement (sans semicolon) to mark DECL to be emitted as a 25476 public symbol such that extra copies in multiple translation units 25477 will be discarded by the linker. Define this macro if your object 25478 file format provides support for this concept, such as the `COMDAT' 25479 section flags in the Microsoft Windows PE/COFF format, and this 25480 support requires changes to DECL, such as putting it in a separate 25481 section. 25482 25483 -- Macro: SUPPORTS_ONE_ONLY 25484 A C expression which evaluates to true if the target supports 25485 one-only semantics. 25486 25487 If you don't define this macro, `varasm.c' provides a default 25488 definition. If `MAKE_DECL_ONE_ONLY' is defined, the default 25489 definition is `1'; otherwise, it is `0'. Define this macro if you 25490 want to control one-only symbol support with a compiler flag, or if 25491 setting the `DECL_ONE_ONLY' flag is enough to mark a declaration to 25492 be emitted as one-only. 25493 25494 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, const 25495 char *VISIBILITY) 25496 This target hook is a function to output to ASM_OUT_FILE some 25497 commands that will make the symbol(s) associated with DECL have 25498 hidden, protected or internal visibility as specified by 25499 VISIBILITY. 25500 25501 -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC 25502 A C expression that evaluates to true if the target's linker 25503 expects that weak symbols do not appear in a static archive's 25504 table of contents. The default is `0'. 25505 25506 Leaving weak symbols out of an archive's table of contents means 25507 that, if a symbol will only have a definition in one translation 25508 unit and will have undefined references from other translation 25509 units, that symbol should not be weak. Defining this macro to be 25510 nonzero will thus have the effect that certain symbols that would 25511 normally be weak (explicit template instantiations, and vtables 25512 for polymorphic classes with noninline key methods) will instead 25513 be nonweak. 25514 25515 The C++ ABI requires this macro to be zero. Define this macro for 25516 targets where full C++ ABI compliance is impossible and where 25517 linker restrictions require weak symbols to be left out of a 25518 static archive's table of contents. 25519 25520 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME) 25521 A C statement (sans semicolon) to output to the stdio stream 25522 STREAM any text necessary for declaring the name of an external 25523 symbol named NAME which is referenced in this compilation but not 25524 defined. The value of DECL is the tree node for the declaration. 25525 25526 This macro need not be defined if it does not need to output 25527 anything. The GNU assembler and most Unix assemblers don't 25528 require anything. 25529 25530 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF) 25531 This target hook is a function to output to ASM_OUT_FILE an 25532 assembler pseudo-op to declare a library function name external. 25533 The name of the library function is given by SYMREF, which is a 25534 `symbol_ref'. 25535 25536 -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (tree DECL) 25537 This target hook is a function to output to ASM_OUT_FILE an 25538 assembler directive to annotate used symbol. Darwin target use 25539 .no_dead_code_strip directive. 25540 25541 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME) 25542 A C statement (sans semicolon) to output to the stdio stream 25543 STREAM a reference in assembler syntax to a label named NAME. 25544 This should add `_' to the front of the name, if that is customary 25545 on your operating system, as it is in most Berkeley Unix systems. 25546 This macro is used in `assemble_name'. 25547 25548 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM) 25549 A C statement (sans semicolon) to output a reference to 25550 `SYMBOL_REF' SYM. If not defined, `assemble_name' will be used to 25551 output the name of the symbol. This macro may be used to modify 25552 the way a symbol is referenced depending on information encoded by 25553 `TARGET_ENCODE_SECTION_INFO'. 25554 25555 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF) 25556 A C statement (sans semicolon) to output a reference to BUF, the 25557 result of `ASM_GENERATE_INTERNAL_LABEL'. If not defined, 25558 `assemble_name' will be used to output the name of the symbol. 25559 This macro is not used by `output_asm_label', or the `%l' 25560 specifier that calls it; the intention is that this macro should 25561 be set when it is necessary to output a label differently when its 25562 address is being taken. 25563 25564 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const 25565 char *PREFIX, unsigned long LABELNO) 25566 A function to output to the stdio stream STREAM a label whose name 25567 is made from the string PREFIX and the number LABELNO. 25568 25569 It is absolutely essential that these labels be distinct from the 25570 labels used for user-level functions and variables. Otherwise, 25571 certain programs will have name conflicts with internal labels. 25572 25573 It is desirable to exclude internal labels from the symbol table 25574 of the object file. Most assemblers have a naming convention for 25575 labels that should be excluded; on many systems, the letter `L' at 25576 the beginning of a label has this effect. You should find out what 25577 convention your system uses, and follow it. 25578 25579 The default version of this function utilizes 25580 `ASM_GENERATE_INTERNAL_LABEL'. 25581 25582 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM) 25583 A C statement to output to the stdio stream STREAM a debug info 25584 label whose name is made from the string PREFIX and the number 25585 NUM. This is useful for VLIW targets, where debug info labels may 25586 need to be treated differently than branch target labels. On some 25587 systems, branch target labels must be at the beginning of 25588 instruction bundles, but debug info labels can occur in the middle 25589 of instruction bundles. 25590 25591 If this macro is not defined, then 25592 `(*targetm.asm_out.internal_label)' will be used. 25593 25594 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM) 25595 A C statement to store into the string STRING a label whose name 25596 is made from the string PREFIX and the number NUM. 25597 25598 This string, when output subsequently by `assemble_name', should 25599 produce the output that `(*targetm.asm_out.internal_label)' would 25600 produce with the same PREFIX and NUM. 25601 25602 If the string begins with `*', then `assemble_name' will output 25603 the rest of the string unchanged. It is often convenient for 25604 `ASM_GENERATE_INTERNAL_LABEL' to use `*' in this way. If the 25605 string doesn't start with `*', then `ASM_OUTPUT_LABELREF' gets to 25606 output the string, and may change it. (Of course, 25607 `ASM_OUTPUT_LABELREF' is also part of your machine description, so 25608 you should know what it does on your machine.) 25609 25610 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER) 25611 A C expression to assign to OUTVAR (which is a variable of type 25612 `char *') a newly allocated string made from the string NAME and 25613 the number NUMBER, with some suitable punctuation added. Use 25614 `alloca' to get space for the string. 25615 25616 The string will be used as an argument to `ASM_OUTPUT_LABELREF' to 25617 produce an assembler label for an internal static variable whose 25618 name is NAME. Therefore, the string must be such as to result in 25619 valid assembler code. The argument NUMBER is different each time 25620 this macro is executed; it prevents conflicts between 25621 similarly-named internal static variables in different scopes. 25622 25623 Ideally this string should not be a valid C identifier, to prevent 25624 any conflict with the user's own symbols. Most assemblers allow 25625 periods or percent signs in assembler symbols; putting at least 25626 one of these between the name and the number will suffice. 25627 25628 If this macro is not defined, a default definition will be provided 25629 which is correct for most systems. 25630 25631 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE) 25632 A C statement to output to the stdio stream STREAM assembler code 25633 which defines (equates) the symbol NAME to have the value VALUE. 25634 25635 If `SET_ASM_OP' is defined, a default definition is provided which 25636 is correct for most systems. 25637 25638 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME, 25639 DECL_OF_VALUE) 25640 A C statement to output to the stdio stream STREAM assembler code 25641 which defines (equates) the symbol whose tree node is DECL_OF_NAME 25642 to have the value of the tree node DECL_OF_VALUE. This macro will 25643 be used in preference to `ASM_OUTPUT_DEF' if it is defined and if 25644 the tree nodes are available. 25645 25646 If `SET_ASM_OP' is defined, a default definition is provided which 25647 is correct for most systems. 25648 25649 -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE) 25650 A C statement that evaluates to true if the assembler code which 25651 defines (equates) the symbol whose tree node is DECL_OF_NAME to 25652 have the value of the tree node DECL_OF_VALUE should be emitted 25653 near the end of the current compilation unit. The default is to 25654 not defer output of defines. This macro affects defines output by 25655 `ASM_OUTPUT_DEF' and `ASM_OUTPUT_DEF_FROM_DECLS'. 25656 25657 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE) 25658 A C statement to output to the stdio stream STREAM assembler code 25659 which defines (equates) the weak symbol NAME to have the value 25660 VALUE. If VALUE is `NULL', it defines NAME as an undefined weak 25661 symbol. 25662 25663 Define this macro if the target only supports weak aliases; define 25664 `ASM_OUTPUT_DEF' instead if possible. 25665 25666 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, 25667 SEL_NAME) 25668 Define this macro to override the default assembler names used for 25669 Objective-C methods. 25670 25671 The default name is a unique method number followed by the name of 25672 the class (e.g. `_1_Foo'). For methods in categories, the name of 25673 the category is also included in the assembler name (e.g. 25674 `_1_Foo_Bar'). 25675 25676 These names are safe on most systems, but make debugging difficult 25677 since the method's selector is not present in the name. 25678 Therefore, particular systems define other ways of computing names. 25679 25680 BUF is an expression of type `char *' which gives you a buffer in 25681 which to store the name; its length is as long as CLASS_NAME, 25682 CAT_NAME and SEL_NAME put together, plus 50 characters extra. 25683 25684 The argument IS_INST specifies whether the method is an instance 25685 method or a class method; CLASS_NAME is the name of the class; 25686 CAT_NAME is the name of the category (or `NULL' if the method is 25687 not in a category); and SEL_NAME is the name of the selector. 25688 25689 On systems where the assembler can handle quoted names, you can 25690 use this macro to provide more human-readable names. 25691 25692 -- Macro: ASM_DECLARE_CLASS_REFERENCE (STREAM, NAME) 25693 A C statement (sans semicolon) to output to the stdio stream 25694 STREAM commands to declare that the label NAME is an Objective-C 25695 class reference. This is only needed for targets whose linkers 25696 have special support for NeXT-style runtimes. 25697 25698 -- Macro: ASM_DECLARE_UNRESOLVED_REFERENCE (STREAM, NAME) 25699 A C statement (sans semicolon) to output to the stdio stream 25700 STREAM commands to declare that the label NAME is an unresolved 25701 Objective-C class reference. This is only needed for targets 25702 whose linkers have special support for NeXT-style runtimes. 25703 25704 25705 File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format 25706 25707 15.21.5 How Initialization Functions Are Handled 25708 ------------------------------------------------ 25709 25710 The compiled code for certain languages includes "constructors" (also 25711 called "initialization routines")--functions to initialize data in the 25712 program when the program is started. These functions need to be called 25713 before the program is "started"--that is to say, before `main' is 25714 called. 25715 25716 Compiling some languages generates "destructors" (also called 25717 "termination routines") that should be called when the program 25718 terminates. 25719 25720 To make the initialization and termination functions work, the compiler 25721 must output something in the assembler code to cause those functions to 25722 be called at the appropriate time. When you port the compiler to a new 25723 system, you need to specify how to do this. 25724 25725 There are two major ways that GCC currently supports the execution of 25726 initialization and termination functions. Each way has two variants. 25727 Much of the structure is common to all four variations. 25728 25729 The linker must build two lists of these functions--a list of 25730 initialization functions, called `__CTOR_LIST__', and a list of 25731 termination functions, called `__DTOR_LIST__'. 25732 25733 Each list always begins with an ignored function pointer (which may 25734 hold 0, -1, or a count of the function pointers after it, depending on 25735 the environment). This is followed by a series of zero or more function 25736 pointers to constructors (or destructors), followed by a function 25737 pointer containing zero. 25738 25739 Depending on the operating system and its executable file format, 25740 either `crtstuff.c' or `libgcc2.c' traverses these lists at startup 25741 time and exit time. Constructors are called in reverse order of the 25742 list; destructors in forward order. 25743 25744 The best way to handle static constructors works only for object file 25745 formats which provide arbitrarily-named sections. A section is set 25746 aside for a list of constructors, and another for a list of destructors. 25747 Traditionally these are called `.ctors' and `.dtors'. Each object file 25748 that defines an initialization function also puts a word in the 25749 constructor section to point to that function. The linker accumulates 25750 all these words into one contiguous `.ctors' section. Termination 25751 functions are handled similarly. 25752 25753 This method will be chosen as the default by `target-def.h' if 25754 `TARGET_ASM_NAMED_SECTION' is defined. A target that does not support 25755 arbitrary sections, but does support special designated constructor and 25756 destructor sections may define `CTORS_SECTION_ASM_OP' and 25757 `DTORS_SECTION_ASM_OP' to achieve the same effect. 25758 25759 When arbitrary sections are available, there are two variants, 25760 depending upon how the code in `crtstuff.c' is called. On systems that 25761 support a ".init" section which is executed at program startup, parts 25762 of `crtstuff.c' are compiled into that section. The program is linked 25763 by the `gcc' driver like this: 25764 25765 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o 25766 25767 The prologue of a function (`__init') appears in the `.init' section 25768 of `crti.o'; the epilogue appears in `crtn.o'. Likewise for the 25769 function `__fini' in the ".fini" section. Normally these files are 25770 provided by the operating system or by the GNU C library, but are 25771 provided by GCC for a few targets. 25772 25773 The objects `crtbegin.o' and `crtend.o' are (for most targets) 25774 compiled from `crtstuff.c'. They contain, among other things, code 25775 fragments within the `.init' and `.fini' sections that branch to 25776 routines in the `.text' section. The linker will pull all parts of a 25777 section together, which results in a complete `__init' function that 25778 invokes the routines we need at startup. 25779 25780 To use this variant, you must define the `INIT_SECTION_ASM_OP' macro 25781 properly. 25782 25783 If no init section is available, when GCC compiles any function called 25784 `main' (or more accurately, any function designated as a program entry 25785 point by the language front end calling `expand_main_function'), it 25786 inserts a procedure call to `__main' as the first executable code after 25787 the function prologue. The `__main' function is defined in `libgcc2.c' 25788 and runs the global constructors. 25789 25790 In file formats that don't support arbitrary sections, there are again 25791 two variants. In the simplest variant, the GNU linker (GNU `ld') and 25792 an `a.out' format must be used. In this case, `TARGET_ASM_CONSTRUCTOR' 25793 is defined to produce a `.stabs' entry of type `N_SETT', referencing 25794 the name `__CTOR_LIST__', and with the address of the void function 25795 containing the initialization code as its value. The GNU linker 25796 recognizes this as a request to add the value to a "set"; the values 25797 are accumulated, and are eventually placed in the executable as a 25798 vector in the format described above, with a leading (ignored) count 25799 and a trailing zero element. `TARGET_ASM_DESTRUCTOR' is handled 25800 similarly. Since no init section is available, the absence of 25801 `INIT_SECTION_ASM_OP' causes the compilation of `main' to call `__main' 25802 as above, starting the initialization process. 25803 25804 The last variant uses neither arbitrary sections nor the GNU linker. 25805 This is preferable when you want to do dynamic linking and when using 25806 file formats which the GNU linker does not support, such as `ECOFF'. In 25807 this case, `TARGET_HAVE_CTORS_DTORS' is false, initialization and 25808 termination functions are recognized simply by their names. This 25809 requires an extra program in the linkage step, called `collect2'. This 25810 program pretends to be the linker, for use with GCC; it does its job by 25811 running the ordinary linker, but also arranges to include the vectors of 25812 initialization and termination functions. These functions are called 25813 via `__main' as described above. In order to use this method, 25814 `use_collect2' must be defined in the target in `config.gcc'. 25815 25816 The following section describes the specific macros that control and 25817 customize the handling of initialization and termination functions. 25818 25819 25820 File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format 25821 25822 15.21.6 Macros Controlling Initialization Routines 25823 -------------------------------------------------- 25824 25825 Here are the macros that control how the compiler handles initialization 25826 and termination functions: 25827 25828 -- Macro: INIT_SECTION_ASM_OP 25829 If defined, a C string constant, including spacing, for the 25830 assembler operation to identify the following data as 25831 initialization code. If not defined, GCC will assume such a 25832 section does not exist. When you are using special sections for 25833 initialization and termination functions, this macro also controls 25834 how `crtstuff.c' and `libgcc2.c' arrange to run the initialization 25835 functions. 25836 25837 -- Macro: HAS_INIT_SECTION 25838 If defined, `main' will not call `__main' as described above. 25839 This macro should be defined for systems that control start-up code 25840 on a symbol-by-symbol basis, such as OSF/1, and should not be 25841 defined explicitly for systems that support `INIT_SECTION_ASM_OP'. 25842 25843 -- Macro: LD_INIT_SWITCH 25844 If defined, a C string constant for a switch that tells the linker 25845 that the following symbol is an initialization routine. 25846 25847 -- Macro: LD_FINI_SWITCH 25848 If defined, a C string constant for a switch that tells the linker 25849 that the following symbol is a finalization routine. 25850 25851 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC) 25852 If defined, a C statement that will write a function that can be 25853 automatically called when a shared library is loaded. The function 25854 should call FUNC, which takes no arguments. If not defined, and 25855 the object format requires an explicit initialization function, 25856 then a function called `_GLOBAL__DI' will be generated. 25857 25858 This function and the following one are used by collect2 when 25859 linking a shared library that needs constructors or destructors, 25860 or has DWARF2 exception tables embedded in the code. 25861 25862 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC) 25863 If defined, a C statement that will write a function that can be 25864 automatically called when a shared library is unloaded. The 25865 function should call FUNC, which takes no arguments. If not 25866 defined, and the object format requires an explicit finalization 25867 function, then a function called `_GLOBAL__DD' will be generated. 25868 25869 -- Macro: INVOKE__main 25870 If defined, `main' will call `__main' despite the presence of 25871 `INIT_SECTION_ASM_OP'. This macro should be defined for systems 25872 where the init section is not actually run automatically, but is 25873 still useful for collecting the lists of constructors and 25874 destructors. 25875 25876 -- Macro: SUPPORTS_INIT_PRIORITY 25877 If nonzero, the C++ `init_priority' attribute is supported and the 25878 compiler should emit instructions to control the order of 25879 initialization of objects. If zero, the compiler will issue an 25880 error message upon encountering an `init_priority' attribute. 25881 25882 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS 25883 This value is true if the target supports some "native" method of 25884 collecting constructors and destructors to be run at startup and 25885 exit. It is false if we must use `collect2'. 25886 25887 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY) 25888 If defined, a function that outputs assembler code to arrange to 25889 call the function referenced by SYMBOL at initialization time. 25890 25891 Assume that SYMBOL is a `SYMBOL_REF' for a function taking no 25892 arguments and with no return value. If the target supports 25893 initialization priorities, PRIORITY is a value between 0 and 25894 `MAX_INIT_PRIORITY'; otherwise it must be `DEFAULT_INIT_PRIORITY'. 25895 25896 If this macro is not defined by the target, a suitable default will 25897 be chosen if (1) the target supports arbitrary section names, (2) 25898 the target defines `CTORS_SECTION_ASM_OP', or (3) `USE_COLLECT2' 25899 is not defined. 25900 25901 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY) 25902 This is like `TARGET_ASM_CONSTRUCTOR' but used for termination 25903 functions rather than initialization functions. 25904 25905 If `TARGET_HAVE_CTORS_DTORS' is true, the initialization routine 25906 generated for the generated object file will have static linkage. 25907 25908 If your system uses `collect2' as the means of processing 25909 constructors, then that program normally uses `nm' to scan an object 25910 file for constructor functions to be called. 25911 25912 On certain kinds of systems, you can define this macro to make 25913 `collect2' work faster (and, in some cases, make it work at all): 25914 25915 -- Macro: OBJECT_FORMAT_COFF 25916 Define this macro if the system uses COFF (Common Object File 25917 Format) object files, so that `collect2' can assume this format 25918 and scan object files directly for dynamic constructor/destructor 25919 functions. 25920 25921 This macro is effective only in a native compiler; `collect2' as 25922 part of a cross compiler always uses `nm' for the target machine. 25923 25924 -- Macro: REAL_NM_FILE_NAME 25925 Define this macro as a C string constant containing the file name 25926 to use to execute `nm'. The default is to search the path 25927 normally for `nm'. 25928 25929 If your system supports shared libraries and has a program to list 25930 the dynamic dependencies of a given library or executable, you can 25931 define these macros to enable support for running initialization 25932 and termination functions in shared libraries: 25933 25934 -- Macro: LDD_SUFFIX 25935 Define this macro to a C string constant containing the name of 25936 the program which lists dynamic dependencies, like `"ldd"' under 25937 SunOS 4. 25938 25939 -- Macro: PARSE_LDD_OUTPUT (PTR) 25940 Define this macro to be C code that extracts filenames from the 25941 output of the program denoted by `LDD_SUFFIX'. PTR is a variable 25942 of type `char *' that points to the beginning of a line of output 25943 from `LDD_SUFFIX'. If the line lists a dynamic dependency, the 25944 code must advance PTR to the beginning of the filename on that 25945 line. Otherwise, it must set PTR to `NULL'. 25946 25947 25948 File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format 25949 25950 15.21.7 Output of Assembler Instructions 25951 ---------------------------------------- 25952 25953 This describes assembler instruction output. 25954 25955 -- Macro: REGISTER_NAMES 25956 A C initializer containing the assembler's names for the machine 25957 registers, each one as a C string constant. This is what 25958 translates register numbers in the compiler into assembler 25959 language. 25960 25961 -- Macro: ADDITIONAL_REGISTER_NAMES 25962 If defined, a C initializer for an array of structures containing 25963 a name and a register number. This macro defines additional names 25964 for hard registers, thus allowing the `asm' option in declarations 25965 to refer to registers using alternate names. 25966 25967 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR) 25968 Define this macro if you are using an unusual assembler that 25969 requires different names for the machine instructions. 25970 25971 The definition is a C statement or statements which output an 25972 assembler instruction opcode to the stdio stream STREAM. The 25973 macro-operand PTR is a variable of type `char *' which points to 25974 the opcode name in its "internal" form--the form that is written 25975 in the machine description. The definition should output the 25976 opcode name to STREAM, performing any translation you desire, and 25977 increment the variable PTR to point at the end of the opcode so 25978 that it will not be output twice. 25979 25980 In fact, your macro definition may process less than the entire 25981 opcode name, or more than the opcode name; but if you want to 25982 process text that includes `%'-sequences to substitute operands, 25983 you must take care of the substitution yourself. Just be sure to 25984 increment PTR over whatever text should not be output normally. 25985 25986 If you need to look at the operand values, they can be found as the 25987 elements of `recog_data.operand'. 25988 25989 If the macro definition does nothing, the instruction is output in 25990 the usual way. 25991 25992 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS) 25993 If defined, a C statement to be executed just prior to the output 25994 of assembler code for INSN, to modify the extracted operands so 25995 they will be output differently. 25996 25997 Here the argument OPVEC is the vector containing the operands 25998 extracted from INSN, and NOPERANDS is the number of elements of 25999 the vector which contain meaningful data for this insn. The 26000 contents of this vector are what will be used to convert the insn 26001 template into assembler code, so you can change the assembler 26002 output by changing the contents of the vector. 26003 26004 This macro is useful when various assembler syntaxes share a single 26005 file of instruction patterns; by defining this macro differently, 26006 you can cause a large class of instructions to be output 26007 differently (such as with rearranged operands). Naturally, 26008 variations in assembler syntax affecting individual insn patterns 26009 ought to be handled by writing conditional output routines in 26010 those patterns. 26011 26012 If this macro is not defined, it is equivalent to a null statement. 26013 26014 -- Macro: PRINT_OPERAND (STREAM, X, CODE) 26015 A C compound statement to output to stdio stream STREAM the 26016 assembler syntax for an instruction operand X. X is an RTL 26017 expression. 26018 26019 CODE is a value that can be used to specify one of several ways of 26020 printing the operand. It is used when identical operands must be 26021 printed differently depending on the context. CODE comes from the 26022 `%' specification that was used to request printing of the 26023 operand. If the specification was just `%DIGIT' then CODE is 0; 26024 if the specification was `%LTR DIGIT' then CODE is the ASCII code 26025 for LTR. 26026 26027 If X is a register, this macro should print the register's name. 26028 The names can be found in an array `reg_names' whose type is `char 26029 *[]'. `reg_names' is initialized from `REGISTER_NAMES'. 26030 26031 When the machine description has a specification `%PUNCT' (a `%' 26032 followed by a punctuation character), this macro is called with a 26033 null pointer for X and the punctuation character for CODE. 26034 26035 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE) 26036 A C expression which evaluates to true if CODE is a valid 26037 punctuation character for use in the `PRINT_OPERAND' macro. If 26038 `PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no 26039 punctuation characters (except for the standard one, `%') are used 26040 in this way. 26041 26042 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X) 26043 A C compound statement to output to stdio stream STREAM the 26044 assembler syntax for an instruction operand that is a memory 26045 reference whose address is X. X is an RTL expression. 26046 26047 On some machines, the syntax for a symbolic address depends on the 26048 section that the address refers to. On these machines, define the 26049 hook `TARGET_ENCODE_SECTION_INFO' to store the information into the 26050 `symbol_ref', and then check for it here. *Note Assembler 26051 Format::. 26052 26053 -- Macro: DBR_OUTPUT_SEQEND (FILE) 26054 A C statement, to be executed after all slot-filler instructions 26055 have been output. If necessary, call `dbr_sequence_length' to 26056 determine the number of slots filled in a sequence (zero if not 26057 currently outputting a sequence), to decide how many no-ops to 26058 output, or whatever. 26059 26060 Don't define this macro if it has nothing to do, but it is helpful 26061 in reading assembly output if the extent of the delay sequence is 26062 made explicit (e.g. with white space). 26063 26064 Note that output routines for instructions with delay slots must be 26065 prepared to deal with not being output as part of a sequence (i.e. when 26066 the scheduling pass is not run, or when no slot fillers could be 26067 found.) The variable `final_sequence' is null when not processing a 26068 sequence, otherwise it contains the `sequence' rtx being output. 26069 26070 -- Macro: REGISTER_PREFIX 26071 -- Macro: LOCAL_LABEL_PREFIX 26072 -- Macro: USER_LABEL_PREFIX 26073 -- Macro: IMMEDIATE_PREFIX 26074 If defined, C string expressions to be used for the `%R', `%L', 26075 `%U', and `%I' options of `asm_fprintf' (see `final.c'). These 26076 are useful when a single `md' file must support multiple assembler 26077 formats. In that case, the various `tm.h' files can define these 26078 macros differently. 26079 26080 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT) 26081 If defined this macro should expand to a series of `case' 26082 statements which will be parsed inside the `switch' statement of 26083 the `asm_fprintf' function. This allows targets to define extra 26084 printf formats which may useful when generating their assembler 26085 statements. Note that uppercase letters are reserved for future 26086 generic extensions to asm_fprintf, and so are not available to 26087 target specific code. The output file is given by the parameter 26088 FILE. The varargs input pointer is ARGPTR and the rest of the 26089 format string, starting the character after the one that is being 26090 switched upon, is pointed to by FORMAT. 26091 26092 -- Macro: ASSEMBLER_DIALECT 26093 If your target supports multiple dialects of assembler language 26094 (such as different opcodes), define this macro as a C expression 26095 that gives the numeric index of the assembler language dialect to 26096 use, with zero as the first variant. 26097 26098 If this macro is defined, you may use constructs of the form 26099 `{option0|option1|option2...}' 26100 in the output templates of patterns (*note Output Template::) or 26101 in the first argument of `asm_fprintf'. This construct outputs 26102 `option0', `option1', `option2', etc., if the value of 26103 `ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters 26104 within these strings retain their usual meaning. If there are 26105 fewer alternatives within the braces than the value of 26106 `ASSEMBLER_DIALECT', the construct outputs nothing. 26107 26108 If you do not define this macro, the characters `{', `|' and `}' 26109 do not have any special meaning when used in templates or operands 26110 to `asm_fprintf'. 26111 26112 Define the macros `REGISTER_PREFIX', `LOCAL_LABEL_PREFIX', 26113 `USER_LABEL_PREFIX' and `IMMEDIATE_PREFIX' if you can express the 26114 variations in assembler language syntax with that mechanism. 26115 Define `ASSEMBLER_DIALECT' and use the `{option0|option1}' syntax 26116 if the syntax variant are larger and involve such things as 26117 different opcodes or operand order. 26118 26119 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO) 26120 A C expression to output to STREAM some assembler code which will 26121 push hard register number REGNO onto the stack. The code need not 26122 be optimal, since this macro is used only when profiling. 26123 26124 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO) 26125 A C expression to output to STREAM some assembler code which will 26126 pop hard register number REGNO off of the stack. The code need 26127 not be optimal, since this macro is used only when profiling. 26128 26129 26130 File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format 26131 26132 15.21.8 Output of Dispatch Tables 26133 --------------------------------- 26134 26135 This concerns dispatch tables. 26136 26137 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL) 26138 A C statement to output to the stdio stream STREAM an assembler 26139 pseudo-instruction to generate a difference between two labels. 26140 VALUE and REL are the numbers of two internal labels. The 26141 definitions of these labels are output using 26142 `(*targetm.asm_out.internal_label)', and they must be printed in 26143 the same way here. For example, 26144 26145 fprintf (STREAM, "\t.word L%d-L%d\n", 26146 VALUE, REL) 26147 26148 You must provide this macro on machines where the addresses in a 26149 dispatch table are relative to the table's own address. If 26150 defined, GCC will also use this macro on all machines when 26151 producing PIC. BODY is the body of the `ADDR_DIFF_VEC'; it is 26152 provided so that the mode and flags can be read. 26153 26154 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE) 26155 This macro should be provided on machines where the addresses in a 26156 dispatch table are absolute. 26157 26158 The definition should be a C statement to output to the stdio 26159 stream STREAM an assembler pseudo-instruction to generate a 26160 reference to a label. VALUE is the number of an internal label 26161 whose definition is output using 26162 `(*targetm.asm_out.internal_label)'. For example, 26163 26164 fprintf (STREAM, "\t.word L%d\n", VALUE) 26165 26166 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE) 26167 Define this if the label before a jump-table needs to be output 26168 specially. The first three arguments are the same as for 26169 `(*targetm.asm_out.internal_label)'; the fourth argument is the 26170 jump-table which follows (a `jump_insn' containing an `addr_vec' 26171 or `addr_diff_vec'). 26172 26173 This feature is used on system V to output a `swbeg' statement for 26174 the table. 26175 26176 If this macro is not defined, these labels are output with 26177 `(*targetm.asm_out.internal_label)'. 26178 26179 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE) 26180 Define this if something special must be output at the end of a 26181 jump-table. The definition should be a C statement to be executed 26182 after the assembler code for the table is written. It should write 26183 the appropriate code to stdio stream STREAM. The argument TABLE 26184 is the jump-table insn, and NUM is the label-number of the 26185 preceding label. 26186 26187 If this macro is not defined, nothing special is output at the end 26188 of the jump-table. 26189 26190 -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (STREAM, DECL, 26191 FOR_EH, EMPTY) 26192 This target hook emits a label at the beginning of each FDE. It 26193 should be defined on targets where FDEs need special labels, and it 26194 should write the appropriate label, for the FDE associated with the 26195 function declaration DECL, to the stdio stream STREAM. The third 26196 argument, FOR_EH, is a boolean: true if this is for an exception 26197 table. The fourth argument, EMPTY, is a boolean: true if this is 26198 a placeholder label for an omitted FDE. 26199 26200 The default is that FDEs are not given nonlocal labels. 26201 26202 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (STREAM) 26203 This target hook emits a label at the beginning of the exception 26204 table. It should be defined on targets where it is desirable for 26205 the table to be broken up according to function. 26206 26207 The default is that no label is emitted. 26208 26209 -- Target Hook: void TARGET_UNWIND_EMIT (FILE * STREAM, rtx INSN) 26210 This target hook emits and assembly directives required to unwind 26211 the given instruction. This is only used when TARGET_UNWIND_INFO 26212 is set. 26213 26214 26215 File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format 26216 26217 15.21.9 Assembler Commands for Exception Regions 26218 ------------------------------------------------ 26219 26220 This describes commands marking the start and the end of an exception 26221 region. 26222 26223 -- Macro: EH_FRAME_SECTION_NAME 26224 If defined, a C string constant for the name of the section 26225 containing exception handling frame unwind information. If not 26226 defined, GCC will provide a default definition if the target 26227 supports named sections. `crtstuff.c' uses this macro to switch 26228 to the appropriate section. 26229 26230 You should define this symbol if your target supports DWARF 2 frame 26231 unwind information and the default definition does not work. 26232 26233 -- Macro: EH_FRAME_IN_DATA_SECTION 26234 If defined, DWARF 2 frame unwind information will be placed in the 26235 data section even though the target supports named sections. This 26236 might be necessary, for instance, if the system linker does garbage 26237 collection and sections cannot be marked as not to be collected. 26238 26239 Do not define this macro unless `TARGET_ASM_NAMED_SECTION' is also 26240 defined. 26241 26242 -- Macro: EH_TABLES_CAN_BE_READ_ONLY 26243 Define this macro to 1 if your target is such that no frame unwind 26244 information encoding used with non-PIC code will ever require a 26245 runtime relocation, but the linker may not support merging 26246 read-only and read-write sections into a single read-write section. 26247 26248 -- Macro: MASK_RETURN_ADDR 26249 An rtx used to mask the return address found via 26250 `RETURN_ADDR_RTX', so that it does not contain any extraneous set 26251 bits in it. 26252 26253 -- Macro: DWARF2_UNWIND_INFO 26254 Define this macro to 0 if your target supports DWARF 2 frame unwind 26255 information, but it does not yet work with exception handling. 26256 Otherwise, if your target supports this information (if it defines 26257 `INCOMING_RETURN_ADDR_RTX' and either `UNALIGNED_INT_ASM_OP' or 26258 `OBJECT_FORMAT_ELF'), GCC will provide a default definition of 1. 26259 26260 If `TARGET_UNWIND_INFO' is defined, the target specific unwinder 26261 will be used in all cases. Defining this macro will enable the 26262 generation of DWARF 2 frame debugging information. 26263 26264 If `TARGET_UNWIND_INFO' is not defined, and this macro is defined 26265 to 1, the DWARF 2 unwinder will be the default exception handling 26266 mechanism; otherwise, the `setjmp'/`longjmp'-based scheme will be 26267 used by default. 26268 26269 -- Macro: TARGET_UNWIND_INFO 26270 Define this macro if your target has ABI specified unwind tables. 26271 Usually these will be output by `TARGET_UNWIND_EMIT'. 26272 26273 -- Variable: Target Hook bool TARGET_UNWIND_TABLES_DEFAULT 26274 This variable should be set to `true' if the target ABI requires 26275 unwinding tables even when exceptions are not used. 26276 26277 -- Macro: MUST_USE_SJLJ_EXCEPTIONS 26278 This macro need only be defined if `DWARF2_UNWIND_INFO' is 26279 runtime-variable. In that case, `except.h' cannot correctly 26280 determine the corresponding definition of 26281 `MUST_USE_SJLJ_EXCEPTIONS', so the target must provide it directly. 26282 26283 -- Macro: DONT_USE_BUILTIN_SETJMP 26284 Define this macro to 1 if the `setjmp'/`longjmp'-based scheme 26285 should use the `setjmp'/`longjmp' functions from the C library 26286 instead of the `__builtin_setjmp'/`__builtin_longjmp' machinery. 26287 26288 -- Macro: DWARF_CIE_DATA_ALIGNMENT 26289 This macro need only be defined if the target might save registers 26290 in the function prologue at an offset to the stack pointer that is 26291 not aligned to `UNITS_PER_WORD'. The definition should be the 26292 negative minimum alignment if `STACK_GROWS_DOWNWARD' is defined, 26293 and the positive minimum alignment otherwise. *Note SDB and 26294 DWARF::. Only applicable if the target supports DWARF 2 frame 26295 unwind information. 26296 26297 -- Variable: Target Hook bool TARGET_TERMINATE_DW2_EH_FRAME_INFO 26298 Contains the value true if the target should add a zero word onto 26299 the end of a Dwarf-2 frame info section when used for exception 26300 handling. Default value is false if `EH_FRAME_SECTION_NAME' is 26301 defined, and true otherwise. 26302 26303 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG) 26304 Given a register, this hook should return a parallel of registers 26305 to represent where to find the register pieces. Define this hook 26306 if the register and its mode are represented in Dwarf in 26307 non-contiguous locations, or if the register should be represented 26308 in more than one register in Dwarf. Otherwise, this hook should 26309 return `NULL_RTX'. If not defined, the default is to return 26310 `NULL_RTX'. 26311 26312 -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM) 26313 This hook is used to output a reference from a frame unwinding 26314 table to the type_info object identified by SYM. It should return 26315 `true' if the reference was output. Returning `false' will cause 26316 the reference to be output using the normal Dwarf2 routines. 26317 26318 -- Target Hook: bool TARGET_ARM_EABI_UNWINDER 26319 This hook should be set to `true' on targets that use an ARM EABI 26320 based unwinding library, and `false' on other targets. This 26321 effects the format of unwinding tables, and how the unwinder in 26322 entered after running a cleanup. The default is `false'. 26323 26324 26325 File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format 26326 26327 15.21.10 Assembler Commands for Alignment 26328 ----------------------------------------- 26329 26330 This describes commands for alignment. 26331 26332 -- Macro: JUMP_ALIGN (LABEL) 26333 The alignment (log base 2) to put in front of LABEL, which is a 26334 common destination of jumps and has no fallthru incoming edge. 26335 26336 This macro need not be defined if you don't want any special 26337 alignment to be done at such a time. Most machine descriptions do 26338 not currently define the macro. 26339 26340 Unless it's necessary to inspect the LABEL parameter, it is better 26341 to set the variable ALIGN_JUMPS in the target's 26342 `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's 26343 selection in ALIGN_JUMPS in a `JUMP_ALIGN' implementation. 26344 26345 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL) 26346 The alignment (log base 2) to put in front of LABEL, which follows 26347 a `BARRIER'. 26348 26349 This macro need not be defined if you don't want any special 26350 alignment to be done at such a time. Most machine descriptions do 26351 not currently define the macro. 26352 26353 -- Macro: LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP 26354 The maximum number of bytes to skip when applying 26355 `LABEL_ALIGN_AFTER_BARRIER'. This works only if 26356 `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 26357 26358 -- Macro: LOOP_ALIGN (LABEL) 26359 The alignment (log base 2) to put in front of LABEL, which follows 26360 a `NOTE_INSN_LOOP_BEG' note. 26361 26362 This macro need not be defined if you don't want any special 26363 alignment to be done at such a time. Most machine descriptions do 26364 not currently define the macro. 26365 26366 Unless it's necessary to inspect the LABEL parameter, it is better 26367 to set the variable `align_loops' in the target's 26368 `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's 26369 selection in `align_loops' in a `LOOP_ALIGN' implementation. 26370 26371 -- Macro: LOOP_ALIGN_MAX_SKIP 26372 The maximum number of bytes to skip when applying `LOOP_ALIGN'. 26373 This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 26374 26375 -- Macro: LABEL_ALIGN (LABEL) 26376 The alignment (log base 2) to put in front of LABEL. If 26377 `LABEL_ALIGN_AFTER_BARRIER' / `LOOP_ALIGN' specify a different 26378 alignment, the maximum of the specified values is used. 26379 26380 Unless it's necessary to inspect the LABEL parameter, it is better 26381 to set the variable `align_labels' in the target's 26382 `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's 26383 selection in `align_labels' in a `LABEL_ALIGN' implementation. 26384 26385 -- Macro: LABEL_ALIGN_MAX_SKIP 26386 The maximum number of bytes to skip when applying `LABEL_ALIGN'. 26387 This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 26388 26389 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES) 26390 A C statement to output to the stdio stream STREAM an assembler 26391 instruction to advance the location counter by NBYTES bytes. 26392 Those bytes should be zero when loaded. NBYTES will be a C 26393 expression of type `int'. 26394 26395 -- Macro: ASM_NO_SKIP_IN_TEXT 26396 Define this macro if `ASM_OUTPUT_SKIP' should not be used in the 26397 text section because it fails to put zeros in the bytes that are 26398 skipped. This is true on many Unix systems, where the pseudo-op 26399 to skip bytes produces no-op instructions rather than zeros when 26400 used in the text section. 26401 26402 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER) 26403 A C statement to output to the stdio stream STREAM an assembler 26404 command to advance the location counter to a multiple of 2 to the 26405 POWER bytes. POWER will be a C expression of type `int'. 26406 26407 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER) 26408 Like `ASM_OUTPUT_ALIGN', except that the "nop" instruction is used 26409 for padding, if necessary. 26410 26411 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP) 26412 A C statement to output to the stdio stream STREAM an assembler 26413 command to advance the location counter to a multiple of 2 to the 26414 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to 26415 satisfy the alignment request. POWER and MAX_SKIP will be a C 26416 expression of type `int'. 26417 26418 26419 File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros 26420 26421 15.22 Controlling Debugging Information Format 26422 ============================================== 26423 26424 This describes how to specify debugging information. 26425 26426 * Menu: 26427 26428 * All Debuggers:: Macros that affect all debugging formats uniformly. 26429 * DBX Options:: Macros enabling specific options in DBX format. 26430 * DBX Hooks:: Hook macros for varying DBX format. 26431 * File Names and DBX:: Macros controlling output of file names in DBX format. 26432 * SDB and DWARF:: Macros for SDB (COFF) and DWARF formats. 26433 * VMS Debug:: Macros for VMS debug format. 26434 26435 26436 File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info 26437 26438 15.22.1 Macros Affecting All Debugging Formats 26439 ---------------------------------------------- 26440 26441 These macros affect all debugging formats. 26442 26443 -- Macro: DBX_REGISTER_NUMBER (REGNO) 26444 A C expression that returns the DBX register number for the 26445 compiler register number REGNO. In the default macro provided, 26446 the value of this expression will be REGNO itself. But sometimes 26447 there are some registers that the compiler knows about and DBX 26448 does not, or vice versa. In such cases, some register may need to 26449 have one number in the compiler and another for DBX. 26450 26451 If two registers have consecutive numbers inside GCC, and they can 26452 be used as a pair to hold a multiword value, then they _must_ have 26453 consecutive numbers after renumbering with `DBX_REGISTER_NUMBER'. 26454 Otherwise, debuggers will be unable to access such a pair, because 26455 they expect register pairs to be consecutive in their own 26456 numbering scheme. 26457 26458 If you find yourself defining `DBX_REGISTER_NUMBER' in way that 26459 does not preserve register pairs, then what you must do instead is 26460 redefine the actual register numbering scheme. 26461 26462 -- Macro: DEBUGGER_AUTO_OFFSET (X) 26463 A C expression that returns the integer offset value for an 26464 automatic variable having address X (an RTL expression). The 26465 default computation assumes that X is based on the frame-pointer 26466 and gives the offset from the frame-pointer. This is required for 26467 targets that produce debugging output for DBX or COFF-style 26468 debugging output for SDB and allow the frame-pointer to be 26469 eliminated when the `-g' options is used. 26470 26471 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X) 26472 A C expression that returns the integer offset value for an 26473 argument having address X (an RTL expression). The nominal offset 26474 is OFFSET. 26475 26476 -- Macro: PREFERRED_DEBUGGING_TYPE 26477 A C expression that returns the type of debugging output GCC should 26478 produce when the user specifies just `-g'. Define this if you 26479 have arranged for GCC to support more than one format of debugging 26480 output. Currently, the allowable values are `DBX_DEBUG', 26481 `SDB_DEBUG', `DWARF_DEBUG', `DWARF2_DEBUG', `XCOFF_DEBUG', 26482 `VMS_DEBUG', and `VMS_AND_DWARF2_DEBUG'. 26483 26484 When the user specifies `-ggdb', GCC normally also uses the value 26485 of this macro to select the debugging output format, but with two 26486 exceptions. If `DWARF2_DEBUGGING_INFO' is defined, GCC uses the 26487 value `DWARF2_DEBUG'. Otherwise, if `DBX_DEBUGGING_INFO' is 26488 defined, GCC uses `DBX_DEBUG'. 26489 26490 The value of this macro only affects the default debugging output; 26491 the user can always get a specific type of output by using 26492 `-gstabs', `-gcoff', `-gdwarf-2', `-gxcoff', or `-gvms'. 26493 26494 26495 File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info 26496 26497 15.22.2 Specific Options for DBX Output 26498 --------------------------------------- 26499 26500 These are specific options for DBX output. 26501 26502 -- Macro: DBX_DEBUGGING_INFO 26503 Define this macro if GCC should produce debugging output for DBX 26504 in response to the `-g' option. 26505 26506 -- Macro: XCOFF_DEBUGGING_INFO 26507 Define this macro if GCC should produce XCOFF format debugging 26508 output in response to the `-g' option. This is a variant of DBX 26509 format. 26510 26511 -- Macro: DEFAULT_GDB_EXTENSIONS 26512 Define this macro to control whether GCC should by default generate 26513 GDB's extended version of DBX debugging information (assuming 26514 DBX-format debugging information is enabled at all). If you don't 26515 define the macro, the default is 1: always generate the extended 26516 information if there is any occasion to. 26517 26518 -- Macro: DEBUG_SYMS_TEXT 26519 Define this macro if all `.stabs' commands should be output while 26520 in the text section. 26521 26522 -- Macro: ASM_STABS_OP 26523 A C string constant, including spacing, naming the assembler 26524 pseudo op to use instead of `"\t.stabs\t"' to define an ordinary 26525 debugging symbol. If you don't define this macro, `"\t.stabs\t"' 26526 is used. This macro applies only to DBX debugging information 26527 format. 26528 26529 -- Macro: ASM_STABD_OP 26530 A C string constant, including spacing, naming the assembler 26531 pseudo op to use instead of `"\t.stabd\t"' to define a debugging 26532 symbol whose value is the current location. If you don't define 26533 this macro, `"\t.stabd\t"' is used. This macro applies only to 26534 DBX debugging information format. 26535 26536 -- Macro: ASM_STABN_OP 26537 A C string constant, including spacing, naming the assembler 26538 pseudo op to use instead of `"\t.stabn\t"' to define a debugging 26539 symbol with no name. If you don't define this macro, 26540 `"\t.stabn\t"' is used. This macro applies only to DBX debugging 26541 information format. 26542 26543 -- Macro: DBX_NO_XREFS 26544 Define this macro if DBX on your system does not support the 26545 construct `xsTAGNAME'. On some systems, this construct is used to 26546 describe a forward reference to a structure named TAGNAME. On 26547 other systems, this construct is not supported at all. 26548 26549 -- Macro: DBX_CONTIN_LENGTH 26550 A symbol name in DBX-format debugging information is normally 26551 continued (split into two separate `.stabs' directives) when it 26552 exceeds a certain length (by default, 80 characters). On some 26553 operating systems, DBX requires this splitting; on others, 26554 splitting must not be done. You can inhibit splitting by defining 26555 this macro with the value zero. You can override the default 26556 splitting-length by defining this macro as an expression for the 26557 length you desire. 26558 26559 -- Macro: DBX_CONTIN_CHAR 26560 Normally continuation is indicated by adding a `\' character to 26561 the end of a `.stabs' string when a continuation follows. To use 26562 a different character instead, define this macro as a character 26563 constant for the character you want to use. Do not define this 26564 macro if backslash is correct for your system. 26565 26566 -- Macro: DBX_STATIC_STAB_DATA_SECTION 26567 Define this macro if it is necessary to go to the data section 26568 before outputting the `.stabs' pseudo-op for a non-global static 26569 variable. 26570 26571 -- Macro: DBX_TYPE_DECL_STABS_CODE 26572 The value to use in the "code" field of the `.stabs' directive for 26573 a typedef. The default is `N_LSYM'. 26574 26575 -- Macro: DBX_STATIC_CONST_VAR_CODE 26576 The value to use in the "code" field of the `.stabs' directive for 26577 a static variable located in the text section. DBX format does not 26578 provide any "right" way to do this. The default is `N_FUN'. 26579 26580 -- Macro: DBX_REGPARM_STABS_CODE 26581 The value to use in the "code" field of the `.stabs' directive for 26582 a parameter passed in registers. DBX format does not provide any 26583 "right" way to do this. The default is `N_RSYM'. 26584 26585 -- Macro: DBX_REGPARM_STABS_LETTER 26586 The letter to use in DBX symbol data to identify a symbol as a 26587 parameter passed in registers. DBX format does not customarily 26588 provide any way to do this. The default is `'P''. 26589 26590 -- Macro: DBX_FUNCTION_FIRST 26591 Define this macro if the DBX information for a function and its 26592 arguments should precede the assembler code for the function. 26593 Normally, in DBX format, the debugging information entirely 26594 follows the assembler code. 26595 26596 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE 26597 Define this macro, with value 1, if the value of a symbol 26598 describing the scope of a block (`N_LBRAC' or `N_RBRAC') should be 26599 relative to the start of the enclosing function. Normally, GCC 26600 uses an absolute address. 26601 26602 -- Macro: DBX_LINES_FUNCTION_RELATIVE 26603 Define this macro, with value 1, if the value of a symbol 26604 indicating the current line number (`N_SLINE') should be relative 26605 to the start of the enclosing function. Normally, GCC uses an 26606 absolute address. 26607 26608 -- Macro: DBX_USE_BINCL 26609 Define this macro if GCC should generate `N_BINCL' and `N_EINCL' 26610 stabs for included header files, as on Sun systems. This macro 26611 also directs GCC to output a type number as a pair of a file 26612 number and a type number within the file. Normally, GCC does not 26613 generate `N_BINCL' or `N_EINCL' stabs, and it outputs a single 26614 number for a type number. 26615 26616 26617 File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info 26618 26619 15.22.3 Open-Ended Hooks for DBX Format 26620 --------------------------------------- 26621 26622 These are hooks for DBX format. 26623 26624 -- Macro: DBX_OUTPUT_LBRAC (STREAM, NAME) 26625 Define this macro to say how to output to STREAM the debugging 26626 information for the start of a scope level for variable names. The 26627 argument NAME is the name of an assembler symbol (for use with 26628 `assemble_name') whose value is the address where the scope begins. 26629 26630 -- Macro: DBX_OUTPUT_RBRAC (STREAM, NAME) 26631 Like `DBX_OUTPUT_LBRAC', but for the end of a scope level. 26632 26633 -- Macro: DBX_OUTPUT_NFUN (STREAM, LSCOPE_LABEL, DECL) 26634 Define this macro if the target machine requires special handling 26635 to output an `N_FUN' entry for the function DECL. 26636 26637 -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER) 26638 A C statement to output DBX debugging information before code for 26639 line number LINE of the current source file to the stdio stream 26640 STREAM. COUNTER is the number of time the macro was invoked, 26641 including the current invocation; it is intended to generate 26642 unique labels in the assembly output. 26643 26644 This macro should not be defined if the default output is correct, 26645 or if it can be made correct by defining 26646 `DBX_LINES_FUNCTION_RELATIVE'. 26647 26648 -- Macro: NO_DBX_FUNCTION_END 26649 Some stabs encapsulation formats (in particular ECOFF), cannot 26650 handle the `.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx 26651 extension construct. On those machines, define this macro to turn 26652 this feature off without disturbing the rest of the gdb extensions. 26653 26654 -- Macro: NO_DBX_BNSYM_ENSYM 26655 Some assemblers cannot handle the `.stabd BNSYM/ENSYM,0,0' gdb dbx 26656 extension construct. On those machines, define this macro to turn 26657 this feature off without disturbing the rest of the gdb extensions. 26658 26659 26660 File: gccint.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info 26661 26662 15.22.4 File Names in DBX Format 26663 -------------------------------- 26664 26665 This describes file names in DBX format. 26666 26667 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME) 26668 A C statement to output DBX debugging information to the stdio 26669 stream STREAM, which indicates that file NAME is the main source 26670 file--the file specified as the input file for compilation. This 26671 macro is called only once, at the beginning of compilation. 26672 26673 This macro need not be defined if the standard form of output for 26674 DBX debugging information is appropriate. 26675 26676 It may be necessary to refer to a label equal to the beginning of 26677 the text section. You can use `assemble_name (stream, 26678 ltext_label_name)' to do so. If you do this, you must also set 26679 the variable USED_LTEXT_LABEL_NAME to `true'. 26680 26681 -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY 26682 Define this macro, with value 1, if GCC should not emit an 26683 indication of the current directory for compilation and current 26684 source language at the beginning of the file. 26685 26686 -- Macro: NO_DBX_GCC_MARKER 26687 Define this macro, with value 1, if GCC should not emit an 26688 indication that this object file was compiled by GCC. The default 26689 is to emit an `N_OPT' stab at the beginning of every source file, 26690 with `gcc2_compiled.' for the string and value 0. 26691 26692 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME) 26693 A C statement to output DBX debugging information at the end of 26694 compilation of the main source file NAME. Output should be 26695 written to the stdio stream STREAM. 26696 26697 If you don't define this macro, nothing special is output at the 26698 end of compilation, which is correct for most machines. 26699 26700 -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END 26701 Define this macro _instead of_ defining 26702 `DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at 26703 the end of compilation is a `N_SO' stab with an empty string, 26704 whose value is the highest absolute text address in the file. 26705 26706 26707 File: gccint.info, Node: SDB and DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info 26708 26709 15.22.5 Macros for SDB and DWARF Output 26710 --------------------------------------- 26711 26712 Here are macros for SDB and DWARF output. 26713 26714 -- Macro: SDB_DEBUGGING_INFO 26715 Define this macro if GCC should produce COFF-style debugging output 26716 for SDB in response to the `-g' option. 26717 26718 -- Macro: DWARF2_DEBUGGING_INFO 26719 Define this macro if GCC should produce dwarf version 2 format 26720 debugging output in response to the `-g' option. 26721 26722 -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (tree 26723 FUNCTION) 26724 Define this to enable the dwarf attribute 26725 `DW_AT_calling_convention' to be emitted for each function. 26726 Instead of an integer return the enum value for the `DW_CC_' 26727 tag. 26728 26729 To support optional call frame debugging information, you must also 26730 define `INCOMING_RETURN_ADDR_RTX' and either set 26731 `RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the 26732 prologue, or call `dwarf2out_def_cfa' and `dwarf2out_reg_save' as 26733 appropriate from `TARGET_ASM_FUNCTION_PROLOGUE' if you don't. 26734 26735 -- Macro: DWARF2_FRAME_INFO 26736 Define this macro to a nonzero value if GCC should always output 26737 Dwarf 2 frame information. If `DWARF2_UNWIND_INFO' (*note 26738 Exception Region Output:: is nonzero, GCC will output this 26739 information not matter how you define `DWARF2_FRAME_INFO'. 26740 26741 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO 26742 Define this macro to be a nonzero value if the assembler can 26743 generate Dwarf 2 line debug info sections. This will result in 26744 much more compact line number tables, and hence is desirable if it 26745 works. 26746 26747 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2) 26748 A C statement to issue assembly directives that create a difference 26749 LAB1 minus LAB2, using an integer of the given SIZE. 26750 26751 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, SECTION) 26752 A C statement to issue assembly directives that create a 26753 section-relative reference to the given LABEL, using an integer of 26754 the given SIZE. The label is known to be defined in the given 26755 SECTION. 26756 26757 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL) 26758 A C statement to issue assembly directives that create a 26759 self-relative reference to the given LABEL, using an integer of 26760 the given SIZE. 26761 26762 -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int 26763 SIZE, rtx X) 26764 If defined, this target hook is a function which outputs a 26765 DTP-relative reference to the given TLS symbol of the specified 26766 size. 26767 26768 -- Macro: PUT_SDB_... 26769 Define these macros to override the assembler syntax for the 26770 special SDB assembler directives. See `sdbout.c' for a list of 26771 these macros and their arguments. If the standard syntax is used, 26772 you need not define them yourself. 26773 26774 -- Macro: SDB_DELIM 26775 Some assemblers do not support a semicolon as a delimiter, even 26776 between SDB assembler directives. In that case, define this macro 26777 to be the delimiter to use (usually `\n'). It is not necessary to 26778 define a new set of `PUT_SDB_OP' macros if this is the only change 26779 required. 26780 26781 -- Macro: SDB_ALLOW_UNKNOWN_REFERENCES 26782 Define this macro to allow references to unknown structure, union, 26783 or enumeration tags to be emitted. Standard COFF does not allow 26784 handling of unknown references, MIPS ECOFF has support for it. 26785 26786 -- Macro: SDB_ALLOW_FORWARD_REFERENCES 26787 Define this macro to allow references to structure, union, or 26788 enumeration tags that have not yet been seen to be handled. Some 26789 assemblers choke if forward tags are used, while some require it. 26790 26791 -- Macro: SDB_OUTPUT_SOURCE_LINE (STREAM, LINE) 26792 A C statement to output SDB debugging information before code for 26793 line number LINE of the current source file to the stdio stream 26794 STREAM. The default is to emit an `.ln' directive. 26795 26796 26797 File: gccint.info, Node: VMS Debug, Prev: SDB and DWARF, Up: Debugging Info 26798 26799 15.22.6 Macros for VMS Debug Format 26800 ----------------------------------- 26801 26802 Here are macros for VMS debug format. 26803 26804 -- Macro: VMS_DEBUGGING_INFO 26805 Define this macro if GCC should produce debugging output for VMS 26806 in response to the `-g' option. The default behavior for VMS is 26807 to generate minimal debug info for a traceback in the absence of 26808 `-g' unless explicitly overridden with `-g0'. This behavior is 26809 controlled by `OPTIMIZATION_OPTIONS' and `OVERRIDE_OPTIONS'. 26810 26811 26812 File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros 26813 26814 15.23 Cross Compilation and Floating Point 26815 ========================================== 26816 26817 While all modern machines use twos-complement representation for 26818 integers, there are a variety of representations for floating point 26819 numbers. This means that in a cross-compiler the representation of 26820 floating point numbers in the compiled program may be different from 26821 that used in the machine doing the compilation. 26822 26823 Because different representation systems may offer different amounts of 26824 range and precision, all floating point constants must be represented in 26825 the target machine's format. Therefore, the cross compiler cannot 26826 safely use the host machine's floating point arithmetic; it must emulate 26827 the target's arithmetic. To ensure consistency, GCC always uses 26828 emulation to work with floating point values, even when the host and 26829 target floating point formats are identical. 26830 26831 The following macros are provided by `real.h' for the compiler to use. 26832 All parts of the compiler which generate or optimize floating-point 26833 calculations must use these macros. They may evaluate their operands 26834 more than once, so operands must not have side effects. 26835 26836 -- Macro: REAL_VALUE_TYPE 26837 The C data type to be used to hold a floating point value in the 26838 target machine's format. Typically this is a `struct' containing 26839 an array of `HOST_WIDE_INT', but all code should treat it as an 26840 opaque quantity. 26841 26842 -- Macro: int REAL_VALUES_EQUAL (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 26843 Compares for equality the two values, X and Y. If the target 26844 floating point format supports negative zeroes and/or NaNs, 26845 `REAL_VALUES_EQUAL (-0.0, 0.0)' is true, and `REAL_VALUES_EQUAL 26846 (NaN, NaN)' is false. 26847 26848 -- Macro: int REAL_VALUES_LESS (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 26849 Tests whether X is less than Y. 26850 26851 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X) 26852 Truncates X to a signed integer, rounding toward zero. 26853 26854 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX 26855 (REAL_VALUE_TYPE X) 26856 Truncates X to an unsigned integer, rounding toward zero. If X is 26857 negative, returns zero. 26858 26859 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, enum 26860 machine_mode MODE) 26861 Converts STRING into a floating point number in the target 26862 machine's representation for mode MODE. This routine can handle 26863 both decimal and hexadecimal floating point constants, using the 26864 syntax defined by the C language for both. 26865 26866 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X) 26867 Returns 1 if X is negative (including negative zero), 0 otherwise. 26868 26869 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X) 26870 Determines whether X represents infinity (positive or negative). 26871 26872 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X) 26873 Determines whether X represents a "NaN" (not-a-number). 26874 26875 -- Macro: void REAL_ARITHMETIC (REAL_VALUE_TYPE OUTPUT, enum tree_code 26876 CODE, REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 26877 Calculates an arithmetic operation on the two floating point values 26878 X and Y, storing the result in OUTPUT (which must be a variable). 26879 26880 The operation to be performed is specified by CODE. Only the 26881 following codes are supported: `PLUS_EXPR', `MINUS_EXPR', 26882 `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'. 26883 26884 If `REAL_ARITHMETIC' is asked to evaluate division by zero and the 26885 target's floating point format cannot represent infinity, it will 26886 call `abort'. Callers should check for this situation first, using 26887 `MODE_HAS_INFINITIES'. *Note Storage Layout::. 26888 26889 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X) 26890 Returns the negative of the floating point value X. 26891 26892 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X) 26893 Returns the absolute value of X. 26894 26895 -- Macro: REAL_VALUE_TYPE REAL_VALUE_TRUNCATE (REAL_VALUE_TYPE MODE, 26896 enum machine_mode X) 26897 Truncates the floating point value X to fit in MODE. The return 26898 value is still a full-size `REAL_VALUE_TYPE', but it has an 26899 appropriate bit pattern to be output asa floating constant whose 26900 precision accords with mode MODE. 26901 26902 -- Macro: void REAL_VALUE_TO_INT (HOST_WIDE_INT LOW, HOST_WIDE_INT 26903 HIGH, REAL_VALUE_TYPE X) 26904 Converts a floating point value X into a double-precision integer 26905 which is then stored into LOW and HIGH. If the value is not 26906 integral, it is truncated. 26907 26908 -- Macro: void REAL_VALUE_FROM_INT (REAL_VALUE_TYPE X, HOST_WIDE_INT 26909 LOW, HOST_WIDE_INT HIGH, enum machine_mode MODE) 26910 Converts a double-precision integer found in LOW and HIGH, into a 26911 floating point value which is then stored into X. The value is 26912 truncated to fit in mode MODE. 26913 26914 26915 File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros 26916 26917 15.24 Mode Switching Instructions 26918 ================================= 26919 26920 The following macros control mode switching optimizations: 26921 26922 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY) 26923 Define this macro if the port needs extra instructions inserted 26924 for mode switching in an optimizing compilation. 26925 26926 For an example, the SH4 can perform both single and double 26927 precision floating point operations, but to perform a single 26928 precision operation, the FPSCR PR bit has to be cleared, while for 26929 a double precision operation, this bit has to be set. Changing 26930 the PR bit requires a general purpose register as a scratch 26931 register, hence these FPSCR sets have to be inserted before 26932 reload, i.e. you can't put this into instruction emitting or 26933 `TARGET_MACHINE_DEPENDENT_REORG'. 26934 26935 You can have multiple entities that are mode-switched, and select 26936 at run time which entities actually need it. 26937 `OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY 26938 that needs mode-switching. If you define this macro, you also 26939 have to define `NUM_MODES_FOR_MODE_SWITCHING', `MODE_NEEDED', 26940 `MODE_PRIORITY_TO_MODE' and `EMIT_MODE_SET'. `MODE_AFTER', 26941 `MODE_ENTRY', and `MODE_EXIT' are optional. 26942 26943 -- Macro: NUM_MODES_FOR_MODE_SWITCHING 26944 If you define `OPTIMIZE_MODE_SWITCHING', you have to define this as 26945 initializer for an array of integers. Each initializer element N 26946 refers to an entity that needs mode switching, and specifies the 26947 number of different modes that might need to be set for this 26948 entity. The position of the initializer in the 26949 initializer--starting counting at zero--determines the integer 26950 that is used to refer to the mode-switched entity in question. In 26951 macros that take mode arguments / yield a mode result, modes are 26952 represented as numbers 0 ... N - 1. N is used to specify that no 26953 mode switch is needed / supplied. 26954 26955 -- Macro: MODE_NEEDED (ENTITY, INSN) 26956 ENTITY is an integer specifying a mode-switched entity. If 26957 `OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to 26958 return an integer value not larger than the corresponding element 26959 in `NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY 26960 must be switched into prior to the execution of INSN. 26961 26962 -- Macro: MODE_AFTER (MODE, INSN) 26963 If this macro is defined, it is evaluated for every INSN during 26964 mode switching. It determines the mode that an insn results in (if 26965 different from the incoming mode). 26966 26967 -- Macro: MODE_ENTRY (ENTITY) 26968 If this macro is defined, it is evaluated for every ENTITY that 26969 needs mode switching. It should evaluate to an integer, which is 26970 a mode that ENTITY is assumed to be switched to at function entry. 26971 If `MODE_ENTRY' is defined then `MODE_EXIT' must be defined. 26972 26973 -- Macro: MODE_EXIT (ENTITY) 26974 If this macro is defined, it is evaluated for every ENTITY that 26975 needs mode switching. It should evaluate to an integer, which is 26976 a mode that ENTITY is assumed to be switched to at function exit. 26977 If `MODE_EXIT' is defined then `MODE_ENTRY' must be defined. 26978 26979 -- Macro: MODE_PRIORITY_TO_MODE (ENTITY, N) 26980 This macro specifies the order in which modes for ENTITY are 26981 processed. 0 is the highest priority, 26982 `NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value 26983 of the macro should be an integer designating a mode for ENTITY. 26984 For any fixed ENTITY, `mode_priority_to_mode' (ENTITY, N) shall be 26985 a bijection in 0 ... `num_modes_for_mode_switching[ENTITY] - 1'. 26986 26987 -- Macro: EMIT_MODE_SET (ENTITY, MODE, HARD_REGS_LIVE) 26988 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE 26989 is the set of hard registers live at the point where the insn(s) 26990 are to be inserted. 26991 26992 26993 File: gccint.info, Node: Target Attributes, Next: MIPS Coprocessors, Prev: Mode Switching, Up: Target Macros 26994 26995 15.25 Defining target-specific uses of `__attribute__' 26996 ====================================================== 26997 26998 Target-specific attributes may be defined for functions, data and types. 26999 These are described using the following target hooks; they also need to 27000 be documented in `extend.texi'. 27001 27002 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE 27003 If defined, this target hook points to an array of `struct 27004 attribute_spec' (defined in `tree.h') specifying the machine 27005 specific attributes for this target and some of the restrictions 27006 on the entities to which these attributes are applied and the 27007 arguments they take. 27008 27009 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (tree TYPE1, tree 27010 TYPE2) 27011 If defined, this target hook is a function which returns zero if 27012 the attributes on TYPE1 and TYPE2 are incompatible, one if they 27013 are compatible, and two if they are nearly compatible (which 27014 causes a warning to be generated). If this is not defined, 27015 machine-specific attributes are supposed always to be compatible. 27016 27017 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE) 27018 If defined, this target hook is a function which assigns default 27019 attributes to newly defined TYPE. 27020 27021 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree 27022 TYPE2) 27023 Define this target hook if the merging of type attributes needs 27024 special handling. If defined, the result is a list of the combined 27025 `TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that 27026 `comptypes' has already been called and returned 1. This function 27027 may call `merge_attributes' to handle machine-independent merging. 27028 27029 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree 27030 NEWDECL) 27031 Define this target hook if the merging of decl attributes needs 27032 special handling. If defined, the result is a list of the combined 27033 `DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate 27034 declaration of OLDDECL. Examples of when this is needed are when 27035 one attribute overrides another, or when an attribute is nullified 27036 by a subsequent definition. This function may call 27037 `merge_attributes' to handle machine-independent merging. 27038 27039 If the only target-specific handling you require is `dllimport' 27040 for Microsoft Windows targets, you should define the macro 27041 `TARGET_DLLIMPORT_DECL_ATTRIBUTES' to `1'. The compiler will then 27042 define a function called `merge_dllimport_decl_attributes' which 27043 can then be defined as the expansion of 27044 `TARGET_MERGE_DECL_ATTRIBUTES'. You can also add 27045 `handle_dll_attribute' in the attribute table for your port to 27046 perform initial processing of the `dllimport' and `dllexport' 27047 attributes. This is done in `i386/cygwin.h' and `i386/i386.c', 27048 for example. 27049 27050 -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (tree DECL) 27051 DECL is a variable or function with `__attribute__((dllimport))' 27052 specified. Use this hook if the target needs to add extra 27053 validation checks to `handle_dll_attribute'. 27054 27055 -- Macro: TARGET_DECLSPEC 27056 Define this macro to a nonzero value if you want to treat 27057 `__declspec(X)' as equivalent to `__attribute((X))'. By default, 27058 this behavior is enabled only for targets that define 27059 `TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of 27060 `__declspec' is via a built-in macro, but you should not rely on 27061 this implementation detail. 27062 27063 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree 27064 *ATTR_PTR) 27065 Define this target hook if you want to be able to add attributes 27066 to a decl when it is being created. This is normally useful for 27067 back ends which wish to implement a pragma by using the attributes 27068 which correspond to the pragma's effect. The NODE argument is the 27069 decl which is being created. The ATTR_PTR argument is a pointer 27070 to the attribute list for this decl. The list itself should not 27071 be modified, since it may be shared with other decls, but 27072 attributes may be chained on the head of the list and `*ATTR_PTR' 27073 modified to point to the new attributes, or a copy of the list may 27074 be made if further changes are needed. 27075 27076 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (tree 27077 FNDECL) 27078 This target hook returns `true' if it is ok to inline FNDECL into 27079 the current function, despite its having target-specific 27080 attributes, `false' otherwise. By default, if a function has a 27081 target specific attribute attached to it, it will not be inlined. 27082 27083 27084 File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Target Attributes, Up: Target Macros 27085 27086 15.26 Defining coprocessor specifics for MIPS targets. 27087 ====================================================== 27088 27089 The MIPS specification allows MIPS implementations to have as many as 4 27090 coprocessors, each with as many as 32 private registers. GCC supports 27091 accessing these registers and transferring values between the registers 27092 and memory using asm-ized variables. For example: 27093 27094 register unsigned int cp0count asm ("c0r1"); 27095 unsigned int d; 27096 27097 d = cp0count + 3; 27098 27099 ("c0r1" is the default name of register 1 in coprocessor 0; alternate 27100 names may be added as described below, or the default names may be 27101 overridden entirely in `SUBTARGET_CONDITIONAL_REGISTER_USAGE'.) 27102 27103 Coprocessor registers are assumed to be epilogue-used; sets to them 27104 will be preserved even if it does not appear that the register is used 27105 again later in the function. 27106 27107 Another note: according to the MIPS spec, coprocessor 1 (if present) is 27108 the FPU. One accesses COP1 registers through standard mips 27109 floating-point support; they are not included in this mechanism. 27110 27111 There is one macro used in defining the MIPS coprocessor interface 27112 which you may want to override in subtargets; it is described below. 27113 27114 -- Macro: ALL_COP_ADDITIONAL_REGISTER_NAMES 27115 A comma-separated list (with leading comma) of pairs describing the 27116 alternate names of coprocessor registers. The format of each 27117 entry should be 27118 { ALTERNATENAME, REGISTER_NUMBER} 27119 Default: empty. 27120 27121 27122 File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros 27123 27124 15.27 Parameters for Precompiled Header Validity Checking 27125 ========================================================= 27126 27127 -- Target Hook: void *TARGET_GET_PCH_VALIDITY (size_t *SZ) 27128 This hook returns the data needed by `TARGET_PCH_VALID_P' and sets 27129 `*SZ' to the size of the data in bytes. 27130 27131 -- Target Hook: const char *TARGET_PCH_VALID_P (const void *DATA, 27132 size_t SZ) 27133 This hook checks whether the options used to create a PCH file are 27134 compatible with the current settings. It returns `NULL' if so and 27135 a suitable error message if not. Error messages will be presented 27136 to the user and must be localized using `_(MSG)'. 27137 27138 DATA is the data that was returned by `TARGET_GET_PCH_VALIDITY' 27139 when the PCH file was created and SZ is the size of that data in 27140 bytes. It's safe to assume that the data was created by the same 27141 version of the compiler, so no format checking is needed. 27142 27143 The default definition of `default_pch_valid_p' should be suitable 27144 for most targets. 27145 27146 -- Target Hook: const char *TARGET_CHECK_PCH_TARGET_FLAGS (int 27147 PCH_FLAGS) 27148 If this hook is nonnull, the default implementation of 27149 `TARGET_PCH_VALID_P' will use it to check for compatible values of 27150 `target_flags'. PCH_FLAGS specifies the value that `target_flags' 27151 had when the PCH file was created. The return value is the same 27152 as for `TARGET_PCH_VALID_P'. 27153 27154 27155 File: gccint.info, Node: C++ ABI, Next: Misc, Prev: PCH Target, Up: Target Macros 27156 27157 15.28 C++ ABI parameters 27158 ======================== 27159 27160 -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void) 27161 Define this hook to override the integer type used for guard 27162 variables. These are used to implement one-time construction of 27163 static objects. The default is long_long_integer_type_node. 27164 27165 -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void) 27166 This hook determines how guard variables are used. It should 27167 return `false' (the default) if first byte should be used. A 27168 return value of `true' indicates the least significant bit should 27169 be used. 27170 27171 -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE) 27172 This hook returns the size of the cookie to use when allocating an 27173 array whose elements have the indicated TYPE. Assumes that it is 27174 already known that a cookie is needed. The default is `max(sizeof 27175 (size_t), alignof(type))', as defined in section 2.7 of the 27176 IA64/Generic C++ ABI. 27177 27178 -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void) 27179 This hook should return `true' if the element size should be 27180 stored in array cookies. The default is to return `false'. 27181 27182 -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int 27183 IMPORT_EXPORT) 27184 If defined by a backend this hook allows the decision made to 27185 export class TYPE to be overruled. Upon entry IMPORT_EXPORT will 27186 contain 1 if the class is going to be exported, -1 if it is going 27187 to be imported and 0 otherwise. This function should return the 27188 modified value and perform any other actions necessary to support 27189 the backend's targeted operating system. 27190 27191 -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void) 27192 This hook should return `true' if constructors and destructors 27193 return the address of the object created/destroyed. The default 27194 is to return `false'. 27195 27196 -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void) 27197 This hook returns true if the key method for a class (i.e., the 27198 method which, if defined in the current translation unit, causes 27199 the virtual table to be emitted) may be an inline function. Under 27200 the standard Itanium C++ ABI the key method may be an inline 27201 function so long as the function is not declared inline in the 27202 class definition. Under some variants of the ABI, an inline 27203 function can never be the key method. The default is to return 27204 `true'. 27205 27206 -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree 27207 DECL) 27208 DECL is a virtual table, virtual table table, typeinfo object, or 27209 other similar implicit class data object that will be emitted with 27210 external linkage in this translation unit. No ELF visibility has 27211 been explicitly specified. If the target needs to specify a 27212 visibility other than that of the containing class, use this hook 27213 to set `DECL_VISIBILITY' and `DECL_VISIBILITY_SPECIFIED'. 27214 27215 -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void) 27216 This hook returns true (the default) if virtual tables and other 27217 similar implicit class data objects are always COMDAT if they have 27218 external linkage. If this hook returns false, then class data for 27219 classes whose virtual table will be emitted in only one translation 27220 unit will not be COMDAT. 27221 27222 -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void) 27223 This hook returns true if `__aeabi_atexit' (as defined by the ARM 27224 EABI) should be used to register static destructors when 27225 `-fuse-cxa-atexit' is in effect. The default is to return false 27226 to use `__cxa_atexit'. 27227 27228 -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE) 27229 TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has 27230 just been defined. Use this hook to make adjustments to the class 27231 (eg, tweak visibility or perform any other required target 27232 modifications). 27233 27234 27235 File: gccint.info, Node: Misc, Prev: C++ ABI, Up: Target Macros 27236 27237 15.29 Miscellaneous Parameters 27238 ============================== 27239 27240 Here are several miscellaneous parameters. 27241 27242 -- Macro: HAS_LONG_COND_BRANCH 27243 Define this boolean macro to indicate whether or not your 27244 architecture has conditional branches that can span all of memory. 27245 It is used in conjunction with an optimization that partitions 27246 hot and cold basic blocks into separate sections of the 27247 executable. If this macro is set to false, gcc will convert any 27248 conditional branches that attempt to cross between sections into 27249 unconditional branches or indirect jumps. 27250 27251 -- Macro: HAS_LONG_UNCOND_BRANCH 27252 Define this boolean macro to indicate whether or not your 27253 architecture has unconditional branches that can span all of 27254 memory. It is used in conjunction with an optimization that 27255 partitions hot and cold basic blocks into separate sections of the 27256 executable. If this macro is set to false, gcc will convert any 27257 unconditional branches that attempt to cross between sections into 27258 indirect jumps. 27259 27260 -- Macro: CASE_VECTOR_MODE 27261 An alias for a machine mode name. This is the machine mode that 27262 elements of a jump-table should have. 27263 27264 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY) 27265 Optional: return the preferred mode for an `addr_diff_vec' when 27266 the minimum and maximum offset are known. If you define this, it 27267 enables extra code in branch shortening to deal with 27268 `addr_diff_vec'. To make this work, you also have to define 27269 `INSN_ALIGN' and make the alignment for `addr_diff_vec' explicit. 27270 The BODY argument is provided so that the offset_unsigned and scale 27271 flags can be updated. 27272 27273 -- Macro: CASE_VECTOR_PC_RELATIVE 27274 Define this macro to be a C expression to indicate when jump-tables 27275 should contain relative addresses. You need not define this macro 27276 if jump-tables never contain relative addresses, or jump-tables 27277 should contain relative addresses only when `-fPIC' or `-fPIC' is 27278 in effect. 27279 27280 -- Macro: CASE_VALUES_THRESHOLD 27281 Define this to be the smallest number of different values for 27282 which it is best to use a jump-table instead of a tree of 27283 conditional branches. The default is four for machines with a 27284 `casesi' instruction and five otherwise. This is best for most 27285 machines. 27286 27287 -- Macro: CASE_USE_BIT_TESTS 27288 Define this macro to be a C expression to indicate whether C switch 27289 statements may be implemented by a sequence of bit tests. This is 27290 advantageous on processors that can efficiently implement left 27291 shift of 1 by the number of bits held in a register, but 27292 inappropriate on targets that would require a loop. By default, 27293 this macro returns `true' if the target defines an `ashlsi3' 27294 pattern, and `false' otherwise. 27295 27296 -- Macro: WORD_REGISTER_OPERATIONS 27297 Define this macro if operations between registers with integral 27298 mode smaller than a word are always performed on the entire 27299 register. Most RISC machines have this property and most CISC 27300 machines do not. 27301 27302 -- Macro: LOAD_EXTEND_OP (MEM_MODE) 27303 Define this macro to be a C expression indicating when insns that 27304 read memory in MEM_MODE, an integral mode narrower than a word, 27305 set the bits outside of MEM_MODE to be either the sign-extension 27306 or the zero-extension of the data read. Return `SIGN_EXTEND' for 27307 values of MEM_MODE for which the insn sign-extends, `ZERO_EXTEND' 27308 for which it zero-extends, and `UNKNOWN' for other modes. 27309 27310 This macro is not called with MEM_MODE non-integral or with a width 27311 greater than or equal to `BITS_PER_WORD', so you may return any 27312 value in this case. Do not define this macro if it would always 27313 return `UNKNOWN'. On machines where this macro is defined, you 27314 will normally define it as the constant `SIGN_EXTEND' or 27315 `ZERO_EXTEND'. 27316 27317 You may return a non-`UNKNOWN' value even if for some hard 27318 registers the sign extension is not performed, if for the 27319 `REGNO_REG_CLASS' of these hard registers 27320 `CANNOT_CHANGE_MODE_CLASS' returns nonzero when the FROM mode is 27321 MEM_MODE and the TO mode is any integral mode larger than this but 27322 not larger than `word_mode'. 27323 27324 You must return `UNKNOWN' if for some hard registers that allow 27325 this mode, `CANNOT_CHANGE_MODE_CLASS' says that they cannot change 27326 to `word_mode', but that they can change to another integral mode 27327 that is larger then MEM_MODE but still smaller than `word_mode'. 27328 27329 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND 27330 Define this macro if loading short immediate values into registers 27331 sign extends. 27332 27333 -- Macro: FIXUNS_TRUNC_LIKE_FIX_TRUNC 27334 Define this macro if the same instructions that convert a floating 27335 point number to a signed fixed point number also convert validly 27336 to an unsigned one. 27337 27338 -- Target Hook: int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL (enum 27339 machine_mode MODE) 27340 When `-ffast-math' is in effect, GCC tries to optimize divisions 27341 by the same divisor, by turning them into multiplications by the 27342 reciprocal. This target hook specifies the minimum number of 27343 divisions that should be there for GCC to perform the optimization 27344 for a variable of mode MODE. The default implementation returns 3 27345 if the machine has an instruction for the division, and 2 if it 27346 does not. 27347 27348 -- Macro: MOVE_MAX 27349 The maximum number of bytes that a single instruction can move 27350 quickly between memory and registers or between two memory 27351 locations. 27352 27353 -- Macro: MAX_MOVE_MAX 27354 The maximum number of bytes that a single instruction can move 27355 quickly between memory and registers or between two memory 27356 locations. If this is undefined, the default is `MOVE_MAX'. 27357 Otherwise, it is the constant value that is the largest value that 27358 `MOVE_MAX' can have at run-time. 27359 27360 -- Macro: SHIFT_COUNT_TRUNCATED 27361 A C expression that is nonzero if on this machine the number of 27362 bits actually used for the count of a shift operation is equal to 27363 the number of bits needed to represent the size of the object 27364 being shifted. When this macro is nonzero, the compiler will 27365 assume that it is safe to omit a sign-extend, zero-extend, and 27366 certain bitwise `and' instructions that truncates the count of a 27367 shift operation. On machines that have instructions that act on 27368 bit-fields at variable positions, which may include `bit test' 27369 instructions, a nonzero `SHIFT_COUNT_TRUNCATED' also enables 27370 deletion of truncations of the values that serve as arguments to 27371 bit-field instructions. 27372 27373 If both types of instructions truncate the count (for shifts) and 27374 position (for bit-field operations), or if no variable-position 27375 bit-field instructions exist, you should define this macro. 27376 27377 However, on some machines, such as the 80386 and the 680x0, 27378 truncation only applies to shift operations and not the (real or 27379 pretended) bit-field operations. Define `SHIFT_COUNT_TRUNCATED' 27380 to be zero on such machines. Instead, add patterns to the `md' 27381 file that include the implied truncation of the shift instructions. 27382 27383 You need not define this macro if it would always have the value 27384 of zero. 27385 27386 -- Target Hook: int TARGET_SHIFT_TRUNCATION_MASK (enum machine_mode 27387 MODE) 27388 This function describes how the standard shift patterns for MODE 27389 deal with shifts by negative amounts or by more than the width of 27390 the mode. *Note shift patterns::. 27391 27392 On many machines, the shift patterns will apply a mask M to the 27393 shift count, meaning that a fixed-width shift of X by Y is 27394 equivalent to an arbitrary-width shift of X by Y & M. If this is 27395 true for mode MODE, the function should return M, otherwise it 27396 should return 0. A return value of 0 indicates that no particular 27397 behavior is guaranteed. 27398 27399 Note that, unlike `SHIFT_COUNT_TRUNCATED', this function does 27400 _not_ apply to general shift rtxes; it applies only to instructions 27401 that are generated by the named shift patterns. 27402 27403 The default implementation of this function returns 27404 `GET_MODE_BITSIZE (MODE) - 1' if `SHIFT_COUNT_TRUNCATED' and 0 27405 otherwise. This definition is always safe, but if 27406 `SHIFT_COUNT_TRUNCATED' is false, and some shift patterns 27407 nevertheless truncate the shift count, you may get better code by 27408 overriding it. 27409 27410 -- Macro: TRULY_NOOP_TRUNCATION (OUTPREC, INPREC) 27411 A C expression which is nonzero if on this machine it is safe to 27412 "convert" an integer of INPREC bits to one of OUTPREC bits (where 27413 OUTPREC is smaller than INPREC) by merely operating on it as if it 27414 had only OUTPREC bits. 27415 27416 On many machines, this expression can be 1. 27417 27418 When `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for 27419 modes for which `MODES_TIEABLE_P' is 0, suboptimal code can result. 27420 If this is the case, making `TRULY_NOOP_TRUNCATION' return 0 in 27421 such cases may improve things. 27422 27423 -- Target Hook: int TARGET_MODE_REP_EXTENDED (enum machine_mode MODE, 27424 enum machine_mode REP_MODE) 27425 The representation of an integral mode can be such that the values 27426 are always extended to a wider integral mode. Return 27427 `SIGN_EXTEND' if values of MODE are represented in sign-extended 27428 form to REP_MODE. Return `UNKNOWN' otherwise. (Currently, none 27429 of the targets use zero-extended representation this way so unlike 27430 `LOAD_EXTEND_OP', `TARGET_MODE_REP_EXTENDED' is expected to return 27431 either `SIGN_EXTEND' or `UNKNOWN'. Also no target extends MODE to 27432 MODE_REP so that MODE_REP is not the next widest integral mode and 27433 currently we take advantage of this fact.) 27434 27435 Similarly to `LOAD_EXTEND_OP' you may return a non-`UNKNOWN' value 27436 even if the extension is not performed on certain hard registers 27437 as long as for the `REGNO_REG_CLASS' of these hard registers 27438 `CANNOT_CHANGE_MODE_CLASS' returns nonzero. 27439 27440 Note that `TARGET_MODE_REP_EXTENDED' and `LOAD_EXTEND_OP' describe 27441 two related properties. If you define `TARGET_MODE_REP_EXTENDED 27442 (mode, word_mode)' you probably also want to define 27443 `LOAD_EXTEND_OP (mode)' to return the same type of extension. 27444 27445 In order to enforce the representation of `mode', 27446 `TRULY_NOOP_TRUNCATION' should return false when truncating to 27447 `mode'. 27448 27449 -- Macro: STORE_FLAG_VALUE 27450 A C expression describing the value returned by a comparison 27451 operator with an integral mode and stored by a store-flag 27452 instruction (`sCOND') when the condition is true. This 27453 description must apply to _all_ the `sCOND' patterns and all the 27454 comparison operators whose results have a `MODE_INT' mode. 27455 27456 A value of 1 or -1 means that the instruction implementing the 27457 comparison operator returns exactly 1 or -1 when the comparison is 27458 true and 0 when the comparison is false. Otherwise, the value 27459 indicates which bits of the result are guaranteed to be 1 when the 27460 comparison is true. This value is interpreted in the mode of the 27461 comparison operation, which is given by the mode of the first 27462 operand in the `sCOND' pattern. Either the low bit or the sign 27463 bit of `STORE_FLAG_VALUE' be on. Presently, only those bits are 27464 used by the compiler. 27465 27466 If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will 27467 generate code that depends only on the specified bits. It can also 27468 replace comparison operators with equivalent operations if they 27469 cause the required bits to be set, even if the remaining bits are 27470 undefined. For example, on a machine whose comparison operators 27471 return an `SImode' value and where `STORE_FLAG_VALUE' is defined as 27472 `0x80000000', saying that just the sign bit is relevant, the 27473 expression 27474 27475 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) 27476 27477 can be converted to 27478 27479 (ashift:SI X (const_int N)) 27480 27481 where N is the appropriate shift count to move the bit being 27482 tested into the sign bit. 27483 27484 There is no way to describe a machine that always sets the 27485 low-order bit for a true value, but does not guarantee the value 27486 of any other bits, but we do not know of any machine that has such 27487 an instruction. If you are trying to port GCC to such a machine, 27488 include an instruction to perform a logical-and of the result with 27489 1 in the pattern for the comparison operators and let us know at 27490 <gcc (a] gcc.gnu.org>. 27491 27492 Often, a machine will have multiple instructions that obtain a 27493 value from a comparison (or the condition codes). Here are rules 27494 to guide the choice of value for `STORE_FLAG_VALUE', and hence the 27495 instructions to be used: 27496 27497 * Use the shortest sequence that yields a valid definition for 27498 `STORE_FLAG_VALUE'. It is more efficient for the compiler to 27499 "normalize" the value (convert it to, e.g., 1 or 0) than for 27500 the comparison operators to do so because there may be 27501 opportunities to combine the normalization with other 27502 operations. 27503 27504 * For equal-length sequences, use a value of 1 or -1, with -1 27505 being slightly preferred on machines with expensive jumps and 27506 1 preferred on other machines. 27507 27508 * As a second choice, choose a value of `0x80000001' if 27509 instructions exist that set both the sign and low-order bits 27510 but do not define the others. 27511 27512 * Otherwise, use a value of `0x80000000'. 27513 27514 Many machines can produce both the value chosen for 27515 `STORE_FLAG_VALUE' and its negation in the same number of 27516 instructions. On those machines, you should also define a pattern 27517 for those cases, e.g., one matching 27518 27519 (set A (neg:M (ne:M B C))) 27520 27521 Some machines can also perform `and' or `plus' operations on 27522 condition code values with less instructions than the corresponding 27523 `sCOND' insn followed by `and' or `plus'. On those machines, 27524 define the appropriate patterns. Use the names `incscc' and 27525 `decscc', respectively, for the patterns which perform `plus' or 27526 `minus' operations on condition code values. See `rs6000.md' for 27527 some examples. The GNU Superoptizer can be used to find such 27528 instruction sequences on other machines. 27529 27530 If this macro is not defined, the default value, 1, is used. You 27531 need not define `STORE_FLAG_VALUE' if the machine has no store-flag 27532 instructions, or if the value generated by these instructions is 1. 27533 27534 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE) 27535 A C expression that gives a nonzero `REAL_VALUE_TYPE' value that is 27536 returned when comparison operators with floating-point results are 27537 true. Define this macro on machines that have comparison 27538 operations that return floating-point values. If there are no 27539 such operations, do not define this macro. 27540 27541 -- Macro: VECTOR_STORE_FLAG_VALUE (MODE) 27542 A C expression that gives a rtx representing the nonzero true 27543 element for vector comparisons. The returned rtx should be valid 27544 for the inner mode of MODE which is guaranteed to be a vector 27545 mode. Define this macro on machines that have vector comparison 27546 operations that return a vector result. If there are no such 27547 operations, do not define this macro. Typically, this macro is 27548 defined as `const1_rtx' or `constm1_rtx'. This macro may return 27549 `NULL_RTX' to prevent the compiler optimizing such vector 27550 comparison operations for the given mode. 27551 27552 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 27553 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 27554 A C expression that evaluates to true if the architecture defines 27555 a value for `clz' or `ctz' with a zero operand. If so, VALUE 27556 should be set to this value. If this macro is not defined, the 27557 value of `clz' or `ctz' is assumed to be undefined. 27558 27559 This macro must be defined if the target's expansion for `ffs' 27560 relies on a particular value to get correct results. Otherwise it 27561 is not necessary, though it may be used to optimize some corner 27562 cases. 27563 27564 Note that regardless of this macro the "definedness" of `clz' and 27565 `ctz' at zero do _not_ extend to the builtin functions visible to 27566 the user. Thus one may be free to adjust the value at will to 27567 match the target expansion of these operations without fear of 27568 breaking the API. 27569 27570 -- Macro: Pmode 27571 An alias for the machine mode for pointers. On most machines, 27572 define this to be the integer mode corresponding to the width of a 27573 hardware pointer; `SImode' on 32-bit machine or `DImode' on 64-bit 27574 machines. On some machines you must define this to be one of the 27575 partial integer modes, such as `PSImode'. 27576 27577 The width of `Pmode' must be at least as large as the value of 27578 `POINTER_SIZE'. If it is not equal, you must define the macro 27579 `POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to 27580 `Pmode'. 27581 27582 -- Macro: FUNCTION_MODE 27583 An alias for the machine mode used for memory references to 27584 functions being called, in `call' RTL expressions. On most 27585 machines this should be `QImode'. 27586 27587 -- Macro: STDC_0_IN_SYSTEM_HEADERS 27588 In normal operation, the preprocessor expands `__STDC__' to the 27589 constant 1, to signify that GCC conforms to ISO Standard C. On 27590 some hosts, like Solaris, the system compiler uses a different 27591 convention, where `__STDC__' is normally 0, but is 1 if the user 27592 specifies strict conformance to the C Standard. 27593 27594 Defining `STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host 27595 convention when processing system header files, but when 27596 processing user files `__STDC__' will always expand to 1. 27597 27598 -- Macro: NO_IMPLICIT_EXTERN_C 27599 Define this macro if the system header files support C++ as well 27600 as C. This macro inhibits the usual method of using system header 27601 files in C++, which is to pretend that the file's contents are 27602 enclosed in `extern "C" {...}'. 27603 27604 -- Macro: REGISTER_TARGET_PRAGMAS () 27605 Define this macro if you want to implement any target-specific 27606 pragmas. If defined, it is a C expression which makes a series of 27607 calls to `c_register_pragma' or `c_register_pragma_with_expansion' 27608 for each pragma. The macro may also do any setup required for the 27609 pragmas. 27610 27611 The primary reason to define this macro is to provide 27612 compatibility with other compilers for the same target. In 27613 general, we discourage definition of target-specific pragmas for 27614 GCC. 27615 27616 If the pragma can be implemented by attributes then you should 27617 consider defining the target hook `TARGET_INSERT_ATTRIBUTES' as 27618 well. 27619 27620 Preprocessor macros that appear on pragma lines are not expanded. 27621 All `#pragma' directives that do not match any registered pragma 27622 are silently ignored, unless the user specifies 27623 `-Wunknown-pragmas'. 27624 27625 -- Function: void c_register_pragma (const char *SPACE, const char 27626 *NAME, void (*CALLBACK) (struct cpp_reader *)) 27627 -- Function: void c_register_pragma_with_expansion (const char *SPACE, 27628 const char *NAME, void (*CALLBACK) (struct cpp_reader *)) 27629 Each call to `c_register_pragma' or 27630 `c_register_pragma_with_expansion' establishes one pragma. The 27631 CALLBACK routine will be called when the preprocessor encounters a 27632 pragma of the form 27633 27634 #pragma [SPACE] NAME ... 27635 27636 SPACE is the case-sensitive namespace of the pragma, or `NULL' to 27637 put the pragma in the global namespace. The callback routine 27638 receives PFILE as its first argument, which can be passed on to 27639 cpplib's functions if necessary. You can lex tokens after the 27640 NAME by calling `pragma_lex'. Tokens that are not read by the 27641 callback will be silently ignored. The end of the line is 27642 indicated by a token of type `CPP_EOF'. Macro expansion occurs on 27643 the arguments of pragmas registered with 27644 `c_register_pragma_with_expansion' but not on the arguments of 27645 pragmas registered with `c_register_pragma'. 27646 27647 For an example use of this routine, see `c4x.h' and the callback 27648 routines defined in `c4x-c.c'. 27649 27650 Note that the use of `pragma_lex' is specific to the C and C++ 27651 compilers. It will not work in the Java or Fortran compilers, or 27652 any other language compilers for that matter. Thus if 27653 `pragma_lex' is going to be called from target-specific code, it 27654 must only be done so when building the C and C++ compilers. This 27655 can be done by defining the variables `c_target_objs' and 27656 `cxx_target_objs' in the target entry in the `config.gcc' file. 27657 These variables should name the target-specific, language-specific 27658 object file which contains the code that uses `pragma_lex'. Note 27659 it will also be necessary to add a rule to the makefile fragment 27660 pointed to by `tmake_file' that shows how to build this object 27661 file. 27662 27663 -- Macro: HANDLE_SYSV_PRAGMA 27664 Define this macro (to a value of 1) if you want the System V style 27665 pragmas `#pragma pack(<n>)' and `#pragma weak <name> [=<value>]' 27666 to be supported by gcc. 27667 27668 The pack pragma specifies the maximum alignment (in bytes) of 27669 fields within a structure, in much the same way as the 27670 `__aligned__' and `__packed__' `__attribute__'s do. A pack value 27671 of zero resets the behavior to the default. 27672 27673 A subtlety for Microsoft Visual C/C++ style bit-field packing 27674 (e.g. -mms-bitfields) for targets that support it: When a 27675 bit-field is inserted into a packed record, the whole size of the 27676 underlying type is used by one or more same-size adjacent 27677 bit-fields (that is, if its long:3, 32 bits is used in the record, 27678 and any additional adjacent long bit-fields are packed into the 27679 same chunk of 32 bits. However, if the size changes, a new field 27680 of that size is allocated). 27681 27682 If both MS bit-fields and `__attribute__((packed))' are used, the 27683 latter will take precedence. If `__attribute__((packed))' is used 27684 on a single field when MS bit-fields are in use, it will take 27685 precedence for that field, but the alignment of the rest of the 27686 structure may affect its placement. 27687 27688 The weak pragma only works if `SUPPORTS_WEAK' and 27689 `ASM_WEAKEN_LABEL' are defined. If enabled it allows the creation 27690 of specifically named weak labels, optionally with a value. 27691 27692 -- Macro: HANDLE_PRAGMA_PACK_PUSH_POP 27693 Define this macro (to a value of 1) if you want to support the 27694 Win32 style pragmas `#pragma pack(push[,N])' and `#pragma 27695 pack(pop)'. The `pack(push,[N])' pragma specifies the maximum 27696 alignment (in bytes) of fields within a structure, in much the 27697 same way as the `__aligned__' and `__packed__' `__attribute__'s 27698 do. A pack value of zero resets the behavior to the default. 27699 Successive invocations of this pragma cause the previous values to 27700 be stacked, so that invocations of `#pragma pack(pop)' will return 27701 to the previous value. 27702 27703 -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION 27704 Define this macro, as well as `HANDLE_SYSV_PRAGMA', if macros 27705 should be expanded in the arguments of `#pragma pack'. 27706 27707 -- Macro: TARGET_DEFAULT_PACK_STRUCT 27708 If your target requires a structure packing default other than 0 27709 (meaning the machine default), define this macro to the necessary 27710 value (in bytes). This must be a value that would also be valid 27711 to use with `#pragma pack()' (that is, a small power of two). 27712 27713 -- Macro: DOLLARS_IN_IDENTIFIERS 27714 Define this macro to control use of the character `$' in 27715 identifier names for the C family of languages. 0 means `$' is 27716 not allowed by default; 1 means it is allowed. 1 is the default; 27717 there is no need to define this macro in that case. 27718 27719 -- Macro: NO_DOLLAR_IN_LABEL 27720 Define this macro if the assembler does not accept the character 27721 `$' in label names. By default constructors and destructors in 27722 G++ have `$' in the identifiers. If this macro is defined, `.' is 27723 used instead. 27724 27725 -- Macro: NO_DOT_IN_LABEL 27726 Define this macro if the assembler does not accept the character 27727 `.' in label names. By default constructors and destructors in G++ 27728 have names that use `.'. If this macro is defined, these names 27729 are rewritten to avoid `.'. 27730 27731 -- Macro: INSN_SETS_ARE_DELAYED (INSN) 27732 Define this macro as a C expression that is nonzero if it is safe 27733 for the delay slot scheduler to place instructions in the delay 27734 slot of INSN, even if they appear to use a resource set or 27735 clobbered in INSN. INSN is always a `jump_insn' or an `insn'; GCC 27736 knows that every `call_insn' has this behavior. On machines where 27737 some `insn' or `jump_insn' is really a function call and hence has 27738 this behavior, you should define this macro. 27739 27740 You need not define this macro if it would always return zero. 27741 27742 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN) 27743 Define this macro as a C expression that is nonzero if it is safe 27744 for the delay slot scheduler to place instructions in the delay 27745 slot of INSN, even if they appear to set or clobber a resource 27746 referenced in INSN. INSN is always a `jump_insn' or an `insn'. 27747 On machines where some `insn' or `jump_insn' is really a function 27748 call and its operands are registers whose use is actually in the 27749 subroutine it calls, you should define this macro. Doing so 27750 allows the delay slot scheduler to move instructions which copy 27751 arguments into the argument registers into the delay slot of INSN. 27752 27753 You need not define this macro if it would always return zero. 27754 27755 -- Macro: MULTIPLE_SYMBOL_SPACES 27756 Define this macro as a C expression that is nonzero if, in some 27757 cases, global symbols from one translation unit may not be bound 27758 to undefined symbols in another translation unit without user 27759 intervention. For instance, under Microsoft Windows symbols must 27760 be explicitly imported from shared libraries (DLLs). 27761 27762 You need not define this macro if it would always evaluate to zero. 27763 27764 -- Target Hook: tree TARGET_MD_ASM_CLOBBERS (tree OUTPUTS, tree 27765 INPUTS, tree CLOBBERS) 27766 This target hook should add to CLOBBERS `STRING_CST' trees for any 27767 hard regs the port wishes to automatically clobber for an asm. It 27768 should return the result of the last `tree_cons' used to add a 27769 clobber. The OUTPUTS, INPUTS and CLOBBER lists are the 27770 corresponding parameters to the asm and may be inspected to avoid 27771 clobbering a register that is an input or output of the asm. You 27772 can use `tree_overlaps_hard_reg_set', declared in `tree.h', to test 27773 for overlap with regards to asm-declared registers. 27774 27775 -- Macro: MATH_LIBRARY 27776 Define this macro as a C string constant for the linker argument 27777 to link in the system math library, or `""' if the target does not 27778 have a separate math library. 27779 27780 You need only define this macro if the default of `"-lm"' is wrong. 27781 27782 -- Macro: LIBRARY_PATH_ENV 27783 Define this macro as a C string constant for the environment 27784 variable that specifies where the linker should look for libraries. 27785 27786 You need only define this macro if the default of `"LIBRARY_PATH"' 27787 is wrong. 27788 27789 -- Macro: TARGET_POSIX_IO 27790 Define this macro if the target supports the following POSIX file 27791 functions, access, mkdir and file locking with fcntl / F_SETLKW. 27792 Defining `TARGET_POSIX_IO' will enable the test coverage code to 27793 use file locking when exiting a program, which avoids race 27794 conditions if the program has forked. It will also create 27795 directories at run-time for cross-profiling. 27796 27797 -- Macro: MAX_CONDITIONAL_EXECUTE 27798 A C expression for the maximum number of instructions to execute 27799 via conditional execution instructions instead of a branch. A 27800 value of `BRANCH_COST'+1 is the default if the machine does not 27801 use cc0, and 1 if it does use cc0. 27802 27803 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR) 27804 Used if the target needs to perform machine-dependent 27805 modifications on the conditionals used for turning basic blocks 27806 into conditionally executed code. CE_INFO points to a data 27807 structure, `struct ce_if_block', which contains information about 27808 the currently processed blocks. TRUE_EXPR and FALSE_EXPR are the 27809 tests that are used for converting the then-block and the 27810 else-block, respectively. Set either TRUE_EXPR or FALSE_EXPR to a 27811 null pointer if the tests cannot be converted. 27812 27813 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR, 27814 FALSE_EXPR) 27815 Like `IFCVT_MODIFY_TESTS', but used when converting more 27816 complicated if-statements into conditions combined by `and' and 27817 `or' operations. BB contains the basic block that contains the 27818 test that is currently being processed and about to be turned into 27819 a condition. 27820 27821 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN) 27822 A C expression to modify the PATTERN of an INSN that is to be 27823 converted to conditional execution format. CE_INFO points to a 27824 data structure, `struct ce_if_block', which contains information 27825 about the currently processed blocks. 27826 27827 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO) 27828 A C expression to perform any final machine dependent 27829 modifications in converting code to conditional execution. The 27830 involved basic blocks can be found in the `struct ce_if_block' 27831 structure that is pointed to by CE_INFO. 27832 27833 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO) 27834 A C expression to cancel any machine dependent modifications in 27835 converting code to conditional execution. The involved basic 27836 blocks can be found in the `struct ce_if_block' structure that is 27837 pointed to by CE_INFO. 27838 27839 -- Macro: IFCVT_INIT_EXTRA_FIELDS (CE_INFO) 27840 A C expression to initialize any extra fields in a `struct 27841 ce_if_block' structure, which are defined by the 27842 `IFCVT_EXTRA_FIELDS' macro. 27843 27844 -- Macro: IFCVT_EXTRA_FIELDS 27845 If defined, it should expand to a set of field declarations that 27846 will be added to the `struct ce_if_block' structure. These should 27847 be initialized by the `IFCVT_INIT_EXTRA_FIELDS' macro. 27848 27849 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG () 27850 If non-null, this hook performs a target-specific pass over the 27851 instruction stream. The compiler will run it at all optimization 27852 levels, just before the point at which it normally does 27853 delayed-branch scheduling. 27854 27855 The exact purpose of the hook varies from target to target. Some 27856 use it to do transformations that are necessary for correctness, 27857 such as laying out in-function constant pools or avoiding hardware 27858 hazards. Others use it as an opportunity to do some 27859 machine-dependent optimizations. 27860 27861 You need not implement the hook if it has nothing to do. The 27862 default definition is null. 27863 27864 -- Target Hook: void TARGET_INIT_BUILTINS () 27865 Define this hook if you have any machine-specific built-in 27866 functions that need to be defined. It should be a function that 27867 performs the necessary setup. 27868 27869 Machine specific built-in functions can be useful to expand 27870 special machine instructions that would otherwise not normally be 27871 generated because they have no equivalent in the source language 27872 (for example, SIMD vector instructions or prefetch instructions). 27873 27874 To create a built-in function, call the function 27875 `lang_hooks.builtin_function' which is defined by the language 27876 front end. You can use any type nodes set up by 27877 `build_common_tree_nodes' and `build_common_tree_nodes_2'; only 27878 language front ends that use those two functions will call 27879 `TARGET_INIT_BUILTINS'. 27880 27881 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx 27882 SUBTARGET, enum machine_mode MODE, int IGNORE) 27883 Expand a call to a machine specific built-in function that was set 27884 up by `TARGET_INIT_BUILTINS'. EXP is the expression for the 27885 function call; the result should go to TARGET if that is 27886 convenient, and have mode MODE if that is convenient. SUBTARGET 27887 may be used as the target for computing one of EXP's operands. 27888 IGNORE is nonzero if the value is to be ignored. This function 27889 should return the result of the call to the built-in function. 27890 27891 -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (tree FNDECL, 27892 tree ARGLIST) 27893 Select a replacement for a machine specific built-in function that 27894 was set up by `TARGET_INIT_BUILTINS'. This is done _before_ 27895 regular type checking, and so allows the target to implement a 27896 crude form of function overloading. FNDECL is the declaration of 27897 the built-in function. ARGLIST is the list of arguments passed to 27898 the built-in function. The result is a complete expression that 27899 implements the operation, usually another `CALL_EXPR'. 27900 27901 -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, tree ARGLIST, 27902 bool IGNORE) 27903 Fold a call to a machine specific built-in function that was set 27904 up by `TARGET_INIT_BUILTINS'. FNDECL is the declaration of the 27905 built-in function. ARGLIST is the list of arguments passed to the 27906 built-in function. The result is another tree containing a 27907 simplified expression for the call's result. If IGNORE is true 27908 the value will be ignored. 27909 27910 -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (rtx INSN) 27911 Take an instruction in INSN and return NULL if it is valid within a 27912 low-overhead loop, otherwise return a string why doloop could not 27913 be applied. 27914 27915 Many targets use special registers for low-overhead looping. For 27916 any instruction that clobbers these this function should return a 27917 string indicating the reason why the doloop could not be applied. 27918 By default, the RTL loop optimizer does not use a present doloop 27919 pattern for loops containing function calls or branch on table 27920 instructions. 27921 27922 -- Macro: MD_CAN_REDIRECT_BRANCH (BRANCH1, BRANCH2) 27923 Take a branch insn in BRANCH1 and another in BRANCH2. Return true 27924 if redirecting BRANCH1 to the destination of BRANCH2 is possible. 27925 27926 On some targets, branches may have a limited range. Optimizing the 27927 filling of delay slots can result in branches being redirected, 27928 and this may in turn cause a branch offset to overflow. 27929 27930 -- Target Hook: bool TARGET_COMMUTATIVE_P (rtx X, OUTER_CODE) 27931 This target hook returns `true' if X is considered to be 27932 commutative. Usually, this is just COMMUTATIVE_P (X), but the HP 27933 PA doesn't consider PLUS to be commutative inside a MEM. 27934 OUTER_CODE is the rtx code of the enclosing rtl, if known, 27935 otherwise it is UNKNOWN. 27936 27937 -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG) 27938 When the initial value of a hard register has been copied in a 27939 pseudo register, it is often not necessary to actually allocate 27940 another register to this pseudo register, because the original 27941 hard register or a stack slot it has been saved into can be used. 27942 `TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register 27943 allocation once for each hard register that had its initial value 27944 copied by using `get_func_hard_reg_initial_val' or 27945 `get_hard_reg_initial_val'. Possible values are `NULL_RTX', if 27946 you don't want to do any special allocation, a `REG' rtx--that 27947 would typically be the hard register itself, if it is known not to 27948 be clobbered--or a `MEM'. If you are returning a `MEM', this is 27949 only a hint for the allocator; it might decide to use another 27950 register anyways. You may use `current_function_leaf_function' in 27951 the hook, functions that use `REG_N_SETS', to determine if the hard 27952 register in question will not be clobbered. The default value of 27953 this hook is `NULL', which disables any special allocation. 27954 27955 -- Macro: TARGET_OBJECT_SUFFIX 27956 Define this macro to be a C string representing the suffix for 27957 object files on your target machine. If you do not define this 27958 macro, GCC will use `.o' as the suffix for object files. 27959 27960 -- Macro: TARGET_EXECUTABLE_SUFFIX 27961 Define this macro to be a C string representing the suffix to be 27962 automatically added to executable files on your target machine. 27963 If you do not define this macro, GCC will use the null string as 27964 the suffix for executable files. 27965 27966 -- Macro: COLLECT_EXPORT_LIST 27967 If defined, `collect2' will scan the individual object files 27968 specified on its command line and create an export list for the 27969 linker. Define this macro for systems like AIX, where the linker 27970 discards object files that are not referenced from `main' and uses 27971 export lists. 27972 27973 -- Macro: MODIFY_JNI_METHOD_CALL (MDECL) 27974 Define this macro to a C expression representing a variant of the 27975 method call MDECL, if Java Native Interface (JNI) methods must be 27976 invoked differently from other methods on your target. For 27977 example, on 32-bit Microsoft Windows, JNI methods must be invoked 27978 using the `stdcall' calling convention and this macro is then 27979 defined as this expression: 27980 27981 build_type_attribute_variant (MDECL, 27982 build_tree_list 27983 (get_identifier ("stdcall"), 27984 NULL)) 27985 27986 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void) 27987 This target hook returns `true' past the point in which new jump 27988 instructions could be created. On machines that require a 27989 register for every jump such as the SHmedia ISA of SH5, this point 27990 would typically be reload, so this target hook should be defined 27991 to a function such as: 27992 27993 static bool 27994 cannot_modify_jumps_past_reload_p () 27995 { 27996 return (reload_completed || reload_in_progress); 27997 } 27998 27999 -- Target Hook: int TARGET_BRANCH_TARGET_REGISTER_CLASS (void) 28000 This target hook returns a register class for which branch target 28001 register optimizations should be applied. All registers in this 28002 class should be usable interchangeably. After reload, registers 28003 in this class will be re-allocated and loads will be hoisted out 28004 of loops and be subjected to inter-block scheduling. 28005 28006 -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool 28007 AFTER_PROLOGUE_EPILOGUE_GEN) 28008 Branch target register optimization will by default exclude 28009 callee-saved registers that are not already live during the 28010 current function; if this target hook returns true, they will be 28011 included. The target code must than make sure that all target 28012 registers in the class returned by 28013 `TARGET_BRANCH_TARGET_REGISTER_CLASS' that might need saving are 28014 saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates if prologues and 28015 epilogues have already been generated. Note, even if you only 28016 return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, you still 28017 are likely to have to make special provisions in 28018 `INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved 28019 target registers. 28020 28021 -- Macro: POWI_MAX_MULTS 28022 If defined, this macro is interpreted as a signed integer C 28023 expression that specifies the maximum number of floating point 28024 multiplications that should be emitted when expanding 28025 exponentiation by an integer constant inline. When this value is 28026 defined, exponentiation requiring more than this number of 28027 multiplications is implemented by calling the system library's 28028 `pow', `powf' or `powl' routines. The default value places no 28029 upper bound on the multiplication count. 28030 28031 -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char 28032 *IPREFIX, int STDINC) 28033 This target hook should register any extra include files for the 28034 target. The parameter STDINC indicates if normal include files 28035 are present. The parameter SYSROOT is the system root directory. 28036 The parameter IPREFIX is the prefix for the gcc directory. 28037 28038 -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const 28039 char *IPREFIX, int STDINC) 28040 This target hook should register any extra include files for the 28041 target before any standard headers. The parameter STDINC 28042 indicates if normal include files are present. The parameter 28043 SYSROOT is the system root directory. The parameter IPREFIX is 28044 the prefix for the gcc directory. 28045 28046 -- Macro: void TARGET_OPTF (char *PATH) 28047 This target hook should register special include paths for the 28048 target. The parameter PATH is the include to register. On Darwin 28049 systems, this is used for Framework includes, which have semantics 28050 that are different from `-I'. 28051 28052 -- Target Hook: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL) 28053 This target hook returns `true' if it is safe to use a local alias 28054 for a virtual function FNDECL when constructing thunks, `false' 28055 otherwise. By default, the hook returns `true' for all functions, 28056 if a target supports aliases (i.e. defines `ASM_OUTPUT_DEF'), 28057 `false' otherwise, 28058 28059 -- Macro: TARGET_FORMAT_TYPES 28060 If defined, this macro is the name of a global variable containing 28061 target-specific format checking information for the `-Wformat' 28062 option. The default is to have no target-specific format checks. 28063 28064 -- Macro: TARGET_N_FORMAT_TYPES 28065 If defined, this macro is the number of entries in 28066 `TARGET_FORMAT_TYPES'. 28067 28068 -- Target Hook: bool TARGET_RELAXED_ORDERING 28069 If set to `true', means that the target's memory model does not 28070 guarantee that loads which do not depend on one another will access 28071 main memory in the order of the instruction stream; if ordering is 28072 important, an explicit memory barrier must be used. This is true 28073 of many recent processors which implement a policy of "relaxed," 28074 "weak," or "release" memory consistency, such as Alpha, PowerPC, 28075 and ia64. The default is `false'. 28076 28077 -- Target Hook: const char *TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN 28078 (tree TYPELIST, tree FUNCDECL, tree VAL) 28079 If defined, this macro returns the diagnostic message when it is 28080 illegal to pass argument VAL to function FUNCDECL with prototype 28081 TYPELIST. 28082 28083 -- Target Hook: const char * TARGET_INVALID_CONVERSION (tree FROMTYPE, 28084 tree TOTYPE) 28085 If defined, this macro returns the diagnostic message when it is 28086 invalid to convert from FROMTYPE to TOTYPE, or `NULL' if validity 28087 should be determined by the front end. 28088 28089 -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, tree 28090 TYPE) 28091 If defined, this macro returns the diagnostic message when it is 28092 invalid to apply operation OP (where unary plus is denoted by 28093 `CONVERT_EXPR') to an operand of type TYPE, or `NULL' if validity 28094 should be determined by the front end. 28095 28096 -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, tree 28097 TYPE1, tree TYPE2) 28098 If defined, this macro returns the diagnostic message when it is 28099 invalid to apply operation OP to operands of types TYPE1 and 28100 TYPE2, or `NULL' if validity should be determined by the front end. 28101 28102 -- Macro: TARGET_USE_JCR_SECTION 28103 This macro determines whether to use the JCR section to register 28104 Java classes. By default, TARGET_USE_JCR_SECTION is defined to 1 28105 if both SUPPORTS_WEAK and TARGET_HAVE_NAMED_SECTIONS are true, 28106 else 0. 28107 28108 -- Macro: OBJC_JBLEN 28109 This macro determines the size of the objective C jump buffer for 28110 the NeXT runtime. By default, OBJC_JBLEN is defined to an 28111 innocuous value. 28112 28113 28114 File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top 28115 28116 16 Host Configuration 28117 ********************* 28118 28119 Most details about the machine and system on which the compiler is 28120 actually running are detected by the `configure' script. Some things 28121 are impossible for `configure' to detect; these are described in two 28122 ways, either by macros defined in a file named `xm-MACHINE.h' or by 28123 hook functions in the file specified by the OUT_HOST_HOOK_OBJ variable 28124 in `config.gcc'. (The intention is that very few hosts will need a 28125 header file but nearly every fully supported host will need to override 28126 some hooks.) 28127 28128 If you need to define only a few macros, and they have simple 28129 definitions, consider using the `xm_defines' variable in your 28130 `config.gcc' entry instead of creating a host configuration header. 28131 *Note System Config::. 28132 28133 * Menu: 28134 28135 * Host Common:: Things every host probably needs implemented. 28136 * Filesystem:: Your host can't have the letter `a' in filenames? 28137 * Host Misc:: Rare configuration options for hosts. 28138 28139 28140 File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config 28141 28142 16.1 Host Common 28143 ================ 28144 28145 Some things are just not portable, even between similar operating 28146 systems, and are too difficult for autoconf to detect. They get 28147 implemented using hook functions in the file specified by the 28148 HOST_HOOK_OBJ variable in `config.gcc'. 28149 28150 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void) 28151 This host hook is used to set up handling for extra signals. The 28152 most common thing to do in this hook is to detect stack overflow. 28153 28154 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int 28155 FD) 28156 This host hook returns the address of some space that is likely to 28157 be free in some subsequent invocation of the compiler. We intend 28158 to load the PCH data at this address such that the data need not 28159 be relocated. The area should be able to hold SIZE bytes. If the 28160 host uses `mmap', FD is an open file descriptor that can be used 28161 for probing. 28162 28163 -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, 28164 size_t SIZE, int FD, size_t OFFSET) 28165 This host hook is called when a PCH file is about to be loaded. 28166 We want to load SIZE bytes from FD at OFFSET into memory at 28167 ADDRESS. The given address will be the result of a previous 28168 invocation of `HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we 28169 couldn't allocate SIZE bytes at ADDRESS. Return 0 if the memory 28170 is allocated but the data is not loaded. Return 1 if the hook has 28171 performed everything. 28172 28173 If the implementation uses reserved address space, free any 28174 reserved space beyond SIZE, regardless of the return value. If no 28175 PCH will be loaded, this hook may be called with SIZE zero, in 28176 which case all reserved address space should be freed. 28177 28178 Do not try to handle values of ADDRESS that could not have been 28179 returned by this executable; just return -1. Such values usually 28180 indicate an out-of-date PCH file (built by some other GCC 28181 executable), and such a PCH file won't work. 28182 28183 -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void); 28184 This host hook returns the alignment required for allocating 28185 virtual memory. Usually this is the same as getpagesize, but on 28186 some hosts the alignment for reserving memory differs from the 28187 pagesize for committing memory. 28188 28189 28190 File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config 28191 28192 16.2 Host Filesystem 28193 ==================== 28194 28195 GCC needs to know a number of things about the semantics of the host 28196 machine's filesystem. Filesystems with Unix and MS-DOS semantics are 28197 automatically detected. For other systems, you can define the 28198 following macros in `xm-MACHINE.h'. 28199 28200 `HAVE_DOS_BASED_FILE_SYSTEM' 28201 This macro is automatically defined by `system.h' if the host file 28202 system obeys the semantics defined by MS-DOS instead of Unix. DOS 28203 file systems are case insensitive, file specifications may begin 28204 with a drive letter, and both forward slash and backslash (`/' and 28205 `\') are directory separators. 28206 28207 `DIR_SEPARATOR' 28208 `DIR_SEPARATOR_2' 28209 If defined, these macros expand to character constants specifying 28210 separators for directory names within a file specification. 28211 `system.h' will automatically give them appropriate values on Unix 28212 and MS-DOS file systems. If your file system is neither of these, 28213 define one or both appropriately in `xm-MACHINE.h'. 28214 28215 However, operating systems like VMS, where constructing a pathname 28216 is more complicated than just stringing together directory names 28217 separated by a special character, should not define either of these 28218 macros. 28219 28220 `PATH_SEPARATOR' 28221 If defined, this macro should expand to a character constant 28222 specifying the separator for elements of search paths. The default 28223 value is a colon (`:'). DOS-based systems usually, but not 28224 always, use semicolon (`;'). 28225 28226 `VMS' 28227 Define this macro if the host system is VMS. 28228 28229 `HOST_OBJECT_SUFFIX' 28230 Define this macro to be a C string representing the suffix for 28231 object files on your host machine. If you do not define this 28232 macro, GCC will use `.o' as the suffix for object files. 28233 28234 `HOST_EXECUTABLE_SUFFIX' 28235 Define this macro to be a C string representing the suffix for 28236 executable files on your host machine. If you do not define this 28237 macro, GCC will use the null string as the suffix for executable 28238 files. 28239 28240 `HOST_BIT_BUCKET' 28241 A pathname defined by the host operating system, which can be 28242 opened as a file and written to, but all the information written 28243 is discarded. This is commonly known as a "bit bucket" or "null 28244 device". If you do not define this macro, GCC will use 28245 `/dev/null' as the bit bucket. If the host does not support a bit 28246 bucket, define this macro to an invalid filename. 28247 28248 `UPDATE_PATH_HOST_CANONICALIZE (PATH)' 28249 If defined, a C statement (sans semicolon) that performs 28250 host-dependent canonicalization when a path used in a compilation 28251 driver or preprocessor is canonicalized. PATH is a malloc-ed path 28252 to be canonicalized. If the C statement does canonicalize PATH 28253 into a different buffer, the old path should be freed and the new 28254 buffer should have been allocated with malloc. 28255 28256 `DUMPFILE_FORMAT' 28257 Define this macro to be a C string representing the format to use 28258 for constructing the index part of debugging dump file names. The 28259 resultant string must fit in fifteen bytes. The full filename 28260 will be the concatenation of: the prefix of the assembler file 28261 name, the string resulting from applying this format to an index 28262 number, and a string unique to each dump file kind, e.g. `rtl'. 28263 28264 If you do not define this macro, GCC will use `.%02d.'. You should 28265 define this macro if using the default will create an invalid file 28266 name. 28267 28268 `DELETE_IF_ORDINARY' 28269 Define this macro to be a C statement (sans semicolon) that 28270 performs host-dependent removal of ordinary temp files in the 28271 compilation driver. 28272 28273 If you do not define this macro, GCC will use the default version. 28274 You should define this macro if the default version does not 28275 reliably remove the temp file as, for example, on VMS which allows 28276 multiple versions of a file. 28277 28278 `HOST_LACKS_INODE_NUMBERS' 28279 Define this macro if the host filesystem does not report 28280 meaningful inode numbers in struct stat. 28281 28282 28283 File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config 28284 28285 16.3 Host Misc 28286 ============== 28287 28288 `FATAL_EXIT_CODE' 28289 A C expression for the status code to be returned when the compiler 28290 exits after serious errors. The default is the system-provided 28291 macro `EXIT_FAILURE', or `1' if the system doesn't define that 28292 macro. Define this macro only if these defaults are incorrect. 28293 28294 `SUCCESS_EXIT_CODE' 28295 A C expression for the status code to be returned when the compiler 28296 exits without serious errors. (Warnings are not serious errors.) 28297 The default is the system-provided macro `EXIT_SUCCESS', or `0' if 28298 the system doesn't define that macro. Define this macro only if 28299 these defaults are incorrect. 28300 28301 `USE_C_ALLOCA' 28302 Define this macro if GCC should use the C implementation of 28303 `alloca' provided by `libiberty.a'. This only affects how some 28304 parts of the compiler itself allocate memory. It does not change 28305 code generation. 28306 28307 When GCC is built with a compiler other than itself, the C `alloca' 28308 is always used. This is because most other implementations have 28309 serious bugs. You should define this macro only on a system where 28310 no stack-based `alloca' can possibly work. For instance, if a 28311 system has a small limit on the size of the stack, GCC's builtin 28312 `alloca' will not work reliably. 28313 28314 `COLLECT2_HOST_INITIALIZATION' 28315 If defined, a C statement (sans semicolon) that performs 28316 host-dependent initialization when `collect2' is being initialized. 28317 28318 `GCC_DRIVER_HOST_INITIALIZATION' 28319 If defined, a C statement (sans semicolon) that performs 28320 host-dependent initialization when a compilation driver is being 28321 initialized. 28322 28323 `HOST_LONG_LONG_FORMAT' 28324 If defined, the string used to indicate an argument of type `long 28325 long' to functions like `printf'. The default value is `"ll"'. 28326 28327 In addition, if `configure' generates an incorrect definition of any 28328 of the macros in `auto-host.h', you can override that definition in a 28329 host configuration header. If you need to do this, first see if it is 28330 possible to fix `configure'. 28331 28332 28333 File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top 28334 28335 17 Makefile Fragments 28336 ********************* 28337 28338 When you configure GCC using the `configure' script, it will construct 28339 the file `Makefile' from the template file `Makefile.in'. When it does 28340 this, it can incorporate makefile fragments from the `config' 28341 directory. These are used to set Makefile parameters that are not 28342 amenable to being calculated by autoconf. The list of fragments to 28343 incorporate is set by `config.gcc' (and occasionally `config.build' and 28344 `config.host'); *Note System Config::. 28345 28346 Fragments are named either `t-TARGET' or `x-HOST', depending on 28347 whether they are relevant to configuring GCC to produce code for a 28348 particular target, or to configuring GCC to run on a particular host. 28349 Here TARGET and HOST are mnemonics which usually have some relationship 28350 to the canonical system name, but no formal connection. 28351 28352 If these files do not exist, it means nothing needs to be added for a 28353 given target or host. Most targets need a few `t-TARGET' fragments, 28354 but needing `x-HOST' fragments is rare. 28355 28356 * Menu: 28357 28358 * Target Fragment:: Writing `t-TARGET' files. 28359 * Host Fragment:: Writing `x-HOST' files. 28360 28361 28362 File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments 28363 28364 17.1 Target Makefile Fragments 28365 ============================== 28366 28367 Target makefile fragments can set these Makefile variables. 28368 28369 `LIBGCC2_CFLAGS' 28370 Compiler flags to use when compiling `libgcc2.c'. 28371 28372 `LIB2FUNCS_EXTRA' 28373 A list of source file names to be compiled or assembled and 28374 inserted into `libgcc.a'. 28375 28376 `Floating Point Emulation' 28377 To have GCC include software floating point libraries in `libgcc.a' 28378 define `FPBIT' and `DPBIT' along with a few rules as follows: 28379 # We want fine grained libraries, so use the new code 28380 # to build the floating point emulation libraries. 28381 FPBIT = fp-bit.c 28382 DPBIT = dp-bit.c 28383 28384 28385 fp-bit.c: $(srcdir)/config/fp-bit.c 28386 echo '#define FLOAT' > fp-bit.c 28387 cat $(srcdir)/config/fp-bit.c >> fp-bit.c 28388 28389 dp-bit.c: $(srcdir)/config/fp-bit.c 28390 cat $(srcdir)/config/fp-bit.c > dp-bit.c 28391 28392 You may need to provide additional #defines at the beginning of 28393 `fp-bit.c' and `dp-bit.c' to control target endianness and other 28394 options. 28395 28396 `CRTSTUFF_T_CFLAGS' 28397 Special flags used when compiling `crtstuff.c'. *Note 28398 Initialization::. 28399 28400 `CRTSTUFF_T_CFLAGS_S' 28401 Special flags used when compiling `crtstuff.c' for shared linking. 28402 Used if you use `crtbeginS.o' and `crtendS.o' in `EXTRA-PARTS'. 28403 *Note Initialization::. 28404 28405 `MULTILIB_OPTIONS' 28406 For some targets, invoking GCC in different ways produces objects 28407 that can not be linked together. For example, for some targets GCC 28408 produces both big and little endian code. For these targets, you 28409 must arrange for multiple versions of `libgcc.a' to be compiled, 28410 one for each set of incompatible options. When GCC invokes the 28411 linker, it arranges to link in the right version of `libgcc.a', 28412 based on the command line options used. 28413 28414 The `MULTILIB_OPTIONS' macro lists the set of options for which 28415 special versions of `libgcc.a' must be built. Write options that 28416 are mutually incompatible side by side, separated by a slash. 28417 Write options that may be used together separated by a space. The 28418 build procedure will build all combinations of compatible options. 28419 28420 For example, if you set `MULTILIB_OPTIONS' to `m68000/m68020 28421 msoft-float', `Makefile' will build special versions of `libgcc.a' 28422 using the following sets of options: `-m68000', `-m68020', 28423 `-msoft-float', `-m68000 -msoft-float', and `-m68020 -msoft-float'. 28424 28425 `MULTILIB_DIRNAMES' 28426 If `MULTILIB_OPTIONS' is used, this variable specifies the 28427 directory names that should be used to hold the various libraries. 28428 Write one element in `MULTILIB_DIRNAMES' for each element in 28429 `MULTILIB_OPTIONS'. If `MULTILIB_DIRNAMES' is not used, the 28430 default value will be `MULTILIB_OPTIONS', with all slashes treated 28431 as spaces. 28432 28433 For example, if `MULTILIB_OPTIONS' is set to `m68000/m68020 28434 msoft-float', then the default value of `MULTILIB_DIRNAMES' is 28435 `m68000 m68020 msoft-float'. You may specify a different value if 28436 you desire a different set of directory names. 28437 28438 `MULTILIB_MATCHES' 28439 Sometimes the same option may be written in two different ways. 28440 If an option is listed in `MULTILIB_OPTIONS', GCC needs to know 28441 about any synonyms. In that case, set `MULTILIB_MATCHES' to a 28442 list of items of the form `option=option' to describe all relevant 28443 synonyms. For example, `m68000=mc68000 m68020=mc68020'. 28444 28445 `MULTILIB_EXCEPTIONS' 28446 Sometimes when there are multiple sets of `MULTILIB_OPTIONS' being 28447 specified, there are combinations that should not be built. In 28448 that case, set `MULTILIB_EXCEPTIONS' to be all of the switch 28449 exceptions in shell case syntax that should not be built. 28450 28451 For example the ARM processor cannot execute both hardware floating 28452 point instructions and the reduced size THUMB instructions at the 28453 same time, so there is no need to build libraries with both of 28454 these options enabled. Therefore `MULTILIB_EXCEPTIONS' is set to: 28455 *mthumb/*mhard-float* 28456 28457 `MULTILIB_EXTRA_OPTS' 28458 Sometimes it is desirable that when building multiple versions of 28459 `libgcc.a' certain options should always be passed on to the 28460 compiler. In that case, set `MULTILIB_EXTRA_OPTS' to be the list 28461 of options to be used for all builds. If you set this, you should 28462 probably set `CRTSTUFF_T_CFLAGS' to a dash followed by it. 28463 28464 `NATIVE_SYSTEM_HEADER_DIR' 28465 If the default location for system headers is not `/usr/include', 28466 you must set this to the directory containing the headers. This 28467 value should match the value of the `SYSTEM_INCLUDE_DIR' macro. 28468 28469 `SPECS' 28470 Unfortunately, setting `MULTILIB_EXTRA_OPTS' is not enough, since 28471 it does not affect the build of target libraries, at least not the 28472 build of the default multilib. One possible work-around is to use 28473 `DRIVER_SELF_SPECS' to bring options from the `specs' file as if 28474 they had been passed in the compiler driver command line. 28475 However, you don't want to be adding these options after the 28476 toolchain is installed, so you can instead tweak the `specs' file 28477 that will be used during the toolchain build, while you still 28478 install the original, built-in `specs'. The trick is to set 28479 `SPECS' to some other filename (say `specs.install'), that will 28480 then be created out of the built-in specs, and introduce a 28481 `Makefile' rule to generate the `specs' file that's going to be 28482 used at build time out of your `specs.install'. 28483 28484 28485 File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments 28486 28487 17.2 Host Makefile Fragments 28488 ============================ 28489 28490 The use of `x-HOST' fragments is discouraged. You should do so only if 28491 there is no other mechanism to get the behavior desired. Host 28492 fragments should never forcibly override variables set by the configure 28493 script, as they may have been adjusted by the user. 28494 28495 Variables provided for host fragments to set include: 28496 28497 `X_CFLAGS' 28498 `X_CPPFLAGS' 28499 These are extra flags to pass to the C compiler and preprocessor, 28500 respectively. They are used both when building GCC, and when 28501 compiling things with the just-built GCC. 28502 28503 `XCFLAGS' 28504 These are extra flags to use when building the compiler. They are 28505 not used when compiling `libgcc.a'. However, they _are_ used when 28506 recompiling the compiler with itself in later stages of a 28507 bootstrap. 28508 28509 `BOOT_LDFLAGS' 28510 Flags to be passed to the linker when recompiling the compiler with 28511 itself in later stages of a bootstrap. You might need to use this 28512 if, for instance, one of the front ends needs more text space than 28513 the linker provides by default. 28514 28515 `EXTRA_PROGRAMS' 28516 A list of additional programs required to use the compiler on this 28517 host, which should be compiled with GCC and installed alongside 28518 the front ends. If you set this variable, you must also provide 28519 rules to build the extra programs. 28520 28521 28522 28523 File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top 28524 28525 18 `collect2' 28526 ************* 28527 28528 GCC uses a utility called `collect2' on nearly all systems to arrange 28529 to call various initialization functions at start time. 28530 28531 The program `collect2' works by linking the program once and looking 28532 through the linker output file for symbols with particular names 28533 indicating they are constructor functions. If it finds any, it creates 28534 a new temporary `.c' file containing a table of them, compiles it, and 28535 links the program a second time including that file. 28536 28537 The actual calls to the constructors are carried out by a subroutine 28538 called `__main', which is called (automatically) at the beginning of 28539 the body of `main' (provided `main' was compiled with GNU CC). Calling 28540 `__main' is necessary, even when compiling C code, to allow linking C 28541 and C++ object code together. (If you use `-nostdlib', you get an 28542 unresolved reference to `__main', since it's defined in the standard 28543 GCC library. Include `-lgcc' at the end of your compiler command line 28544 to resolve this reference.) 28545 28546 The program `collect2' is installed as `ld' in the directory where the 28547 passes of the compiler are installed. When `collect2' needs to find 28548 the _real_ `ld', it tries the following file names: 28549 28550 * `real-ld' in the directories listed in the compiler's search 28551 directories. 28552 28553 * `real-ld' in the directories listed in the environment variable 28554 `PATH'. 28555 28556 * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 28557 if specified. 28558 28559 * `ld' in the compiler's search directories, except that `collect2' 28560 will not execute itself recursively. 28561 28562 * `ld' in `PATH'. 28563 28564 "The compiler's search directories" means all the directories where 28565 `gcc' searches for passes of the compiler. This includes directories 28566 that you specify with `-B'. 28567 28568 Cross-compilers search a little differently: 28569 28570 * `real-ld' in the compiler's search directories. 28571 28572 * `TARGET-real-ld' in `PATH'. 28573 28574 * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 28575 if specified. 28576 28577 * `ld' in the compiler's search directories. 28578 28579 * `TARGET-ld' in `PATH'. 28580 28581 `collect2' explicitly avoids running `ld' using the file name under 28582 which `collect2' itself was invoked. In fact, it remembers up a list 28583 of such names--in case one copy of `collect2' finds another copy (or 28584 version) of `collect2' installed as `ld' in a second place in the 28585 search path. 28586 28587 `collect2' searches for the utilities `nm' and `strip' using the same 28588 algorithm as above for `ld'. 28589 28590 28591 File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top 28592 28593 19 Standard Header File Directories 28594 *********************************** 28595 28596 `GCC_INCLUDE_DIR' means the same thing for native and cross. It is 28597 where GCC stores its private include files, and also where GCC stores 28598 the fixed include files. A cross compiled GCC runs `fixincludes' on 28599 the header files in `$(tooldir)/include'. (If the cross compilation 28600 header files need to be fixed, they must be installed before GCC is 28601 built. If the cross compilation header files are already suitable for 28602 GCC, nothing special need be done). 28603 28604 `GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It 28605 is where `g++' looks first for header files. The C++ library installs 28606 only target independent header files in that directory. 28607 28608 `LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't 28609 install anything there. It is normally `/usr/local/include'. This is 28610 where local additions to a packaged system should place header files. 28611 28612 `CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't 28613 install anything there. 28614 28615 `TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is 28616 the place for other packages to install header files that GCC will use. 28617 For a cross-compiler, this is the equivalent of `/usr/include'. When 28618 you build a cross-compiler, `fixincludes' processes any header files in 28619 this directory. 28620 28621 28622 File: gccint.info, Node: Type Information, Next: Funding, Prev: Header Dirs, Up: Top 28623 28624 20 Memory Management and Type Information 28625 ***************************************** 28626 28627 GCC uses some fairly sophisticated memory management techniques, which 28628 involve determining information about GCC's data structures from GCC's 28629 source code and using this information to perform garbage collection and 28630 implement precompiled headers. 28631 28632 A full C parser would be too complicated for this task, so a limited 28633 subset of C is interpreted and special markers are used to determine 28634 what parts of the source to look at. All `struct' and `union' 28635 declarations that define data structures that are allocated under 28636 control of the garbage collector must be marked. All global variables 28637 that hold pointers to garbage-collected memory must also be marked. 28638 Finally, all global variables that need to be saved and restored by a 28639 precompiled header must be marked. (The precompiled header mechanism 28640 can only save static variables if they're scalar. Complex data 28641 structures must be allocated in garbage-collected memory to be saved in 28642 a precompiled header.) 28643 28644 The full format of a marker is 28645 GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...)) 28646 but in most cases no options are needed. The outer double parentheses 28647 are still necessary, though: `GTY(())'. Markers can appear: 28648 28649 * In a structure definition, before the open brace; 28650 28651 * In a global variable declaration, after the keyword `static' or 28652 `extern'; and 28653 28654 * In a structure field definition, before the name of the field. 28655 28656 Here are some examples of marking simple data structures and globals. 28657 28658 struct TAG GTY(()) 28659 { 28660 FIELDS... 28661 }; 28662 28663 typedef struct TAG GTY(()) 28664 { 28665 FIELDS... 28666 } *TYPENAME; 28667 28668 static GTY(()) struct TAG *LIST; /* points to GC memory */ 28669 static GTY(()) int COUNTER; /* save counter in a PCH */ 28670 28671 The parser understands simple typedefs such as `typedef struct TAG 28672 *NAME;' and `typedef int NAME;'. These don't need to be marked. 28673 28674 * Menu: 28675 28676 * GTY Options:: What goes inside a `GTY(())'. 28677 * GGC Roots:: Making global variables GGC roots. 28678 * Files:: How the generated files work. 28679 28680 28681 File: gccint.info, Node: GTY Options, Next: GGC Roots, Up: Type Information 28682 28683 20.1 The Inside of a `GTY(())' 28684 ============================== 28685 28686 Sometimes the C code is not enough to fully describe the type 28687 structure. Extra information can be provided with `GTY' options and 28688 additional markers. Some options take a parameter, which may be either 28689 a string or a type name, depending on the parameter. If an option 28690 takes no parameter, it is acceptable either to omit the parameter 28691 entirely, or to provide an empty string as a parameter. For example, 28692 `GTY ((skip))' and `GTY ((skip ("")))' are equivalent. 28693 28694 When the parameter is a string, often it is a fragment of C code. Four 28695 special escapes may be used in these strings, to refer to pieces of the 28696 data structure being marked: 28697 28698 `%h' 28699 The current structure. 28700 28701 `%1' 28702 The structure that immediately contains the current structure. 28703 28704 `%0' 28705 The outermost structure that contains the current structure. 28706 28707 `%a' 28708 A partial expression of the form `[i1][i2]...' that indexes the 28709 array item currently being marked. 28710 28711 For instance, suppose that you have a structure of the form 28712 struct A { 28713 ... 28714 }; 28715 struct B { 28716 struct A foo[12]; 28717 }; 28718 and `b' is a variable of type `struct B'. When marking `b.foo[11]', 28719 `%h' would expand to `b.foo[11]', `%0' and `%1' would both expand to 28720 `b', and `%a' would expand to `[11]'. 28721 28722 As in ordinary C, adjacent strings will be concatenated; this is 28723 helpful when you have a complicated expression. 28724 GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE" 28725 " ? TYPE_NEXT_VARIANT (&%h.generic)" 28726 " : TREE_CHAIN (&%h.generic)"))) 28727 28728 The available options are: 28729 28730 `length ("EXPRESSION")' 28731 There are two places the type machinery will need to be explicitly 28732 told the length of an array. The first case is when a structure 28733 ends in a variable-length array, like this: 28734 struct rtvec_def GTY(()) { 28735 int num_elem; /* number of elements */ 28736 rtx GTY ((length ("%h.num_elem"))) elem[1]; 28737 }; 28738 28739 In this case, the `length' option is used to override the specified 28740 array length (which should usually be `1'). The parameter of the 28741 option is a fragment of C code that calculates the length. 28742 28743 The second case is when a structure or a global variable contains a 28744 pointer to an array, like this: 28745 tree * 28746 GTY ((length ("%h.regno_pointer_align_length"))) regno_decl; 28747 In this case, `regno_decl' has been allocated by writing something 28748 like 28749 x->regno_decl = 28750 ggc_alloc (x->regno_pointer_align_length * sizeof (tree)); 28751 and the `length' provides the length of the field. 28752 28753 This second use of `length' also works on global variables, like: 28754 static GTY((length ("reg_base_value_size"))) 28755 rtx *reg_base_value; 28756 28757 `skip' 28758 If `skip' is applied to a field, the type machinery will ignore it. 28759 This is somewhat dangerous; the only safe use is in a union when 28760 one field really isn't ever used. 28761 28762 `desc ("EXPRESSION")' 28763 `tag ("CONSTANT")' 28764 `default' 28765 The type machinery needs to be told which field of a `union' is 28766 currently active. This is done by giving each field a constant 28767 `tag' value, and then specifying a discriminator using `desc'. 28768 The value of the expression given by `desc' is compared against 28769 each `tag' value, each of which should be different. If no `tag' 28770 is matched, the field marked with `default' is used if there is 28771 one, otherwise no field in the union will be marked. 28772 28773 In the `desc' option, the "current structure" is the union that it 28774 discriminates. Use `%1' to mean the structure containing it. 28775 There are no escapes available to the `tag' option, since it is a 28776 constant. 28777 28778 For example, 28779 struct tree_binding GTY(()) 28780 { 28781 struct tree_common common; 28782 union tree_binding_u { 28783 tree GTY ((tag ("0"))) scope; 28784 struct cp_binding_level * GTY ((tag ("1"))) level; 28785 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope; 28786 tree value; 28787 }; 28788 28789 In this example, the value of BINDING_HAS_LEVEL_P when applied to a 28790 `struct tree_binding *' is presumed to be 0 or 1. If 1, the type 28791 mechanism will treat the field `level' as being present and if 0, 28792 will treat the field `scope' as being present. 28793 28794 `param_is (TYPE)' 28795 `use_param' 28796 Sometimes it's convenient to define some data structure to work on 28797 generic pointers (that is, `PTR') and then use it with a specific 28798 type. `param_is' specifies the real type pointed to, and 28799 `use_param' says where in the generic data structure that type 28800 should be put. 28801 28802 For instance, to have a `htab_t' that points to trees, one would 28803 write the definition of `htab_t' like this: 28804 typedef struct GTY(()) { 28805 ... 28806 void ** GTY ((use_param, ...)) entries; 28807 ... 28808 } htab_t; 28809 and then declare variables like this: 28810 static htab_t GTY ((param_is (union tree_node))) ict; 28811 28812 `paramN_is (TYPE)' 28813 `use_paramN' 28814 In more complicated cases, the data structure might need to work on 28815 several different types, which might not necessarily all be 28816 pointers. For this, `param1_is' through `param9_is' may be used to 28817 specify the real type of a field identified by `use_param1' through 28818 `use_param9'. 28819 28820 `use_params' 28821 When a structure contains another structure that is parameterized, 28822 there's no need to do anything special, the inner structure 28823 inherits the parameters of the outer one. When a structure 28824 contains a pointer to a parameterized structure, the type 28825 machinery won't automatically detect this (it could, it just 28826 doesn't yet), so it's necessary to tell it that the pointed-to 28827 structure should use the same parameters as the outer structure. 28828 This is done by marking the pointer with the `use_params' option. 28829 28830 `deletable' 28831 `deletable', when applied to a global variable, indicates that when 28832 garbage collection runs, there's no need to mark anything pointed 28833 to by this variable, it can just be set to `NULL' instead. This 28834 is used to keep a list of free structures around for re-use. 28835 28836 `if_marked ("EXPRESSION")' 28837 Suppose you want some kinds of object to be unique, and so you put 28838 them in a hash table. If garbage collection marks the hash table, 28839 these objects will never be freed, even if the last other 28840 reference to them goes away. GGC has special handling to deal 28841 with this: if you use the `if_marked' option on a global hash 28842 table, GGC will call the routine whose name is the parameter to 28843 the option on each hash table entry. If the routine returns 28844 nonzero, the hash table entry will be marked as usual. If the 28845 routine returns zero, the hash table entry will be deleted. 28846 28847 The routine `ggc_marked_p' can be used to determine if an element 28848 has been marked already; in fact, the usual case is to use 28849 `if_marked ("ggc_marked_p")'. 28850 28851 `maybe_undef' 28852 When applied to a field, `maybe_undef' indicates that it's OK if 28853 the structure that this fields points to is never defined, so long 28854 as this field is always `NULL'. This is used to avoid requiring 28855 backends to define certain optional structures. It doesn't work 28856 with language frontends. 28857 28858 `nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")' 28859 The type machinery expects all pointers to point to the start of an 28860 object. Sometimes for abstraction purposes it's convenient to have 28861 a pointer which points inside an object. So long as it's possible 28862 to convert the original object to and from the pointer, such 28863 pointers can still be used. TYPE is the type of the original 28864 object, the TO EXPRESSION returns the pointer given the original 28865 object, and the FROM EXPRESSION returns the original object given 28866 the pointer. The pointer will be available using the `%h' escape. 28867 28868 `chain_next ("EXPRESSION")' 28869 `chain_prev ("EXPRESSION")' 28870 It's helpful for the type machinery to know if objects are often 28871 chained together in long lists; this lets it generate code that 28872 uses less stack space by iterating along the list instead of 28873 recursing down it. `chain_next' is an expression for the next 28874 item in the list, `chain_prev' is an expression for the previous 28875 item. For singly linked lists, use only `chain_next'; for doubly 28876 linked lists, use both. The machinery requires that taking the 28877 next item of the previous item gives the original item. 28878 28879 `reorder ("FUNCTION NAME")' 28880 Some data structures depend on the relative ordering of pointers. 28881 If the precompiled header machinery needs to change that ordering, 28882 it will call the function referenced by the `reorder' option, 28883 before changing the pointers in the object that's pointed to by 28884 the field the option applies to. The function must take four 28885 arguments, with the signature 28886 `void *, void *, gt_pointer_operator, void *'. The first 28887 parameter is a pointer to the structure that contains the object 28888 being updated, or the object itself if there is no containing 28889 structure. The second parameter is a cookie that should be 28890 ignored. The third parameter is a routine that, given a pointer, 28891 will update it to its correct new value. The fourth parameter is 28892 a cookie that must be passed to the second parameter. 28893 28894 PCH cannot handle data structures that depend on the absolute 28895 values of pointers. `reorder' functions can be expensive. When 28896 possible, it is better to depend on properties of the data, like 28897 an ID number or the hash of a string instead. 28898 28899 `special ("NAME")' 28900 The `special' option is used to mark types that have to be dealt 28901 with by special case machinery. The parameter is the name of the 28902 special case. See `gengtype.c' for further details. Avoid adding 28903 new special cases unless there is no other alternative. 28904 28905 28906 File: gccint.info, Node: GGC Roots, Next: Files, Prev: GTY Options, Up: Type Information 28907 28908 20.2 Marking Roots for the Garbage Collector 28909 ============================================ 28910 28911 In addition to keeping track of types, the type machinery also locates 28912 the global variables ("roots") that the garbage collector starts at. 28913 Roots must be declared using one of the following syntaxes: 28914 28915 * `extern GTY(([OPTIONS])) TYPE NAME;' 28916 28917 * `static GTY(([OPTIONS])) TYPE NAME;' 28918 The syntax 28919 * `GTY(([OPTIONS])) TYPE NAME;' 28920 is _not_ accepted. There should be an `extern' declaration of such a 28921 variable in a header somewhere--mark that, not the definition. Or, if 28922 the variable is only used in one file, make it `static'. 28923 28924 28925 File: gccint.info, Node: Files, Prev: GGC Roots, Up: Type Information 28926 28927 20.3 Source Files Containing Type Information 28928 ============================================= 28929 28930 Whenever you add `GTY' markers to a source file that previously had 28931 none, or create a new source file containing `GTY' markers, there are 28932 three things you need to do: 28933 28934 1. You need to add the file to the list of source files the type 28935 machinery scans. There are four cases: 28936 28937 a. For a back-end file, this is usually done automatically; if 28938 not, you should add it to `target_gtfiles' in the appropriate 28939 port's entries in `config.gcc'. 28940 28941 b. For files shared by all front ends, add the filename to the 28942 `GTFILES' variable in `Makefile.in'. 28943 28944 c. For files that are part of one front end, add the filename to 28945 the `gtfiles' variable defined in the appropriate 28946 `config-lang.in'. For C, the file is `c-config-lang.in'. 28947 28948 d. For files that are part of some but not all front ends, add 28949 the filename to the `gtfiles' variable of _all_ the front ends 28950 that use it. 28951 28952 2. If the file was a header file, you'll need to check that it's 28953 included in the right place to be visible to the generated files. 28954 For a back-end header file, this should be done automatically. 28955 For a front-end header file, it needs to be included by the same 28956 file that includes `gtype-LANG.h'. For other header files, it 28957 needs to be included in `gtype-desc.c', which is a generated file, 28958 so add it to `ifiles' in `open_base_file' in `gengtype.c'. 28959 28960 For source files that aren't header files, the machinery will 28961 generate a header file that should be included in the source file 28962 you just changed. The file will be called `gt-PATH.h' where PATH 28963 is the pathname relative to the `gcc' directory with slashes 28964 replaced by -, so for example the header file to be included in 28965 `cp/parser.c' is called `gt-cp-parser.c'. The generated header 28966 file should be included after everything else in the source file. 28967 Don't forget to mention this file as a dependency in the 28968 `Makefile'! 28969 28970 28971 For language frontends, there is another file that needs to be included 28972 somewhere. It will be called `gtype-LANG.h', where LANG is the name of 28973 the subdirectory the language is contained in. 28974 28975 28976 File: gccint.info, Node: Funding, Next: GNU Project, Prev: Type Information, Up: Top 28977 28978 Funding Free Software 28979 ********************* 28980 28981 If you want to have more free software a few years from now, it makes 28982 sense for you to help encourage people to contribute funds for its 28983 development. The most effective approach known is to encourage 28984 commercial redistributors to donate. 28985 28986 Users of free software systems can boost the pace of development by 28987 encouraging for-a-fee distributors to donate part of their selling price 28988 to free software developers--the Free Software Foundation, and others. 28989 28990 The way to convince distributors to do this is to demand it and expect 28991 it from them. So when you compare distributors, judge them partly by 28992 how much they give to free software development. Show distributors 28993 they must compete to be the one who gives the most. 28994 28995 To make this approach work, you must insist on numbers that you can 28996 compare, such as, "We will donate ten dollars to the Frobnitz project 28997 for each disk sold." Don't be satisfied with a vague promise, such as 28998 "A portion of the profits are donated," since it doesn't give a basis 28999 for comparison. 29000 29001 Even a precise fraction "of the profits from this disk" is not very 29002 meaningful, since creative accounting and unrelated business decisions 29003 can greatly alter what fraction of the sales price counts as profit. 29004 If the price you pay is $50, ten percent of the profit is probably less 29005 than a dollar; it might be a few cents, or nothing at all. 29006 29007 Some redistributors do development work themselves. This is useful 29008 too; but to keep everyone honest, you need to inquire how much they do, 29009 and what kind. Some kinds of development make much more long-term 29010 difference than others. For example, maintaining a separate version of 29011 a program contributes very little; maintaining the standard version of a 29012 program for the whole community contributes much. Easy new ports 29013 contribute little, since someone else would surely do them; difficult 29014 ports such as adding a new CPU to the GNU Compiler Collection 29015 contribute more; major new features or packages contribute the most. 29016 29017 By establishing the idea that supporting further development is "the 29018 proper thing to do" when distributing free software for a fee, we can 29019 assure a steady flow of resources into making more free software. 29020 29021 Copyright (C) 1994 Free Software Foundation, Inc. 29022 Verbatim copying and redistribution of this section is permitted 29023 without royalty; alteration is not permitted. 29024 29025 29026 File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top 29027 29028 The GNU Project and GNU/Linux 29029 ***************************** 29030 29031 The GNU Project was launched in 1984 to develop a complete Unix-like 29032 operating system which is free software: the GNU system. (GNU is a 29033 recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".) 29034 Variants of the GNU operating system, which use the kernel Linux, are 29035 now widely used; though these systems are often referred to as "Linux", 29036 they are more accurately called GNU/Linux systems. 29037 29038 For more information, see: 29039 `http://www.gnu.org/' 29040 `http://www.gnu.org/gnu/linux-and-gnu.html' 29041 29042 29043 File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top 29044 29045 GNU GENERAL PUBLIC LICENSE 29046 ************************** 29047 29048 Version 2, June 1991 29049 29050 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 29051 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA 29052 29053 Everyone is permitted to copy and distribute verbatim copies 29054 of this license document, but changing it is not allowed. 29055 29056 Preamble 29057 ======== 29058 29059 The licenses for most software are designed to take away your freedom 29060 to share and change it. By contrast, the GNU General Public License is 29061 intended to guarantee your freedom to share and change free 29062 software--to make sure the software is free for all its users. This 29063 General Public License applies to most of the Free Software 29064 Foundation's software and to any other program whose authors commit to 29065 using it. (Some other Free Software Foundation software is covered by 29066 the GNU Library General Public License instead.) You can apply it to 29067 your programs, too. 29068 29069 When we speak of free software, we are referring to freedom, not 29070 price. Our General Public Licenses are designed to make sure that you 29071 have the freedom to distribute copies of free software (and charge for 29072 this service if you wish), that you receive source code or can get it 29073 if you want it, that you can change the software or use pieces of it in 29074 new free programs; and that you know you can do these things. 29075 29076 To protect your rights, we need to make restrictions that forbid 29077 anyone to deny you these rights or to ask you to surrender the rights. 29078 These restrictions translate to certain responsibilities for you if you 29079 distribute copies of the software, or if you modify it. 29080 29081 For example, if you distribute copies of such a program, whether 29082 gratis or for a fee, you must give the recipients all the rights that 29083 you have. You must make sure that they, too, receive or can get the 29084 source code. And you must show them these terms so they know their 29085 rights. 29086 29087 We protect your rights with two steps: (1) copyright the software, and 29088 (2) offer you this license which gives you legal permission to copy, 29089 distribute and/or modify the software. 29090 29091 Also, for each author's protection and ours, we want to make certain 29092 that everyone understands that there is no warranty for this free 29093 software. If the software is modified by someone else and passed on, we 29094 want its recipients to know that what they have is not the original, so 29095 that any problems introduced by others will not reflect on the original 29096 authors' reputations. 29097 29098 Finally, any free program is threatened constantly by software 29099 patents. We wish to avoid the danger that redistributors of a free 29100 program will individually obtain patent licenses, in effect making the 29101 program proprietary. To prevent this, we have made it clear that any 29102 patent must be licensed for everyone's free use or not licensed at all. 29103 29104 The precise terms and conditions for copying, distribution and 29105 modification follow. 29106 29107 TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 29108 0. This License applies to any program or other work which contains a 29109 notice placed by the copyright holder saying it may be distributed 29110 under the terms of this General Public License. The "Program", 29111 below, refers to any such program or work, and a "work based on 29112 the Program" means either the Program or any derivative work under 29113 copyright law: that is to say, a work containing the Program or a 29114 portion of it, either verbatim or with modifications and/or 29115 translated into another language. (Hereinafter, translation is 29116 included without limitation in the term "modification".) Each 29117 licensee is addressed as "you". 29118 29119 Activities other than copying, distribution and modification are 29120 not covered by this License; they are outside its scope. The act 29121 of running the Program is not restricted, and the output from the 29122 Program is covered only if its contents constitute a work based on 29123 the Program (independent of having been made by running the 29124 Program). Whether that is true depends on what the Program does. 29125 29126 1. You may copy and distribute verbatim copies of the Program's 29127 source code as you receive it, in any medium, provided that you 29128 conspicuously and appropriately publish on each copy an appropriate 29129 copyright notice and disclaimer of warranty; keep intact all the 29130 notices that refer to this License and to the absence of any 29131 warranty; and give any other recipients of the Program a copy of 29132 this License along with the Program. 29133 29134 You may charge a fee for the physical act of transferring a copy, 29135 and you may at your option offer warranty protection in exchange 29136 for a fee. 29137 29138 2. You may modify your copy or copies of the Program or any portion 29139 of it, thus forming a work based on the Program, and copy and 29140 distribute such modifications or work under the terms of Section 1 29141 above, provided that you also meet all of these conditions: 29142 29143 a. You must cause the modified files to carry prominent notices 29144 stating that you changed the files and the date of any change. 29145 29146 b. You must cause any work that you distribute or publish, that 29147 in whole or in part contains or is derived from the Program 29148 or any part thereof, to be licensed as a whole at no charge 29149 to all third parties under the terms of this License. 29150 29151 c. If the modified program normally reads commands interactively 29152 when run, you must cause it, when started running for such 29153 interactive use in the most ordinary way, to print or display 29154 an announcement including an appropriate copyright notice and 29155 a notice that there is no warranty (or else, saying that you 29156 provide a warranty) and that users may redistribute the 29157 program under these conditions, and telling the user how to 29158 view a copy of this License. (Exception: if the Program 29159 itself is interactive but does not normally print such an 29160 announcement, your work based on the Program is not required 29161 to print an announcement.) 29162 29163 These requirements apply to the modified work as a whole. If 29164 identifiable sections of that work are not derived from the 29165 Program, and can be reasonably considered independent and separate 29166 works in themselves, then this License, and its terms, do not 29167 apply to those sections when you distribute them as separate 29168 works. But when you distribute the same sections as part of a 29169 whole which is a work based on the Program, the distribution of 29170 the whole must be on the terms of this License, whose permissions 29171 for other licensees extend to the entire whole, and thus to each 29172 and every part regardless of who wrote it. 29173 29174 Thus, it is not the intent of this section to claim rights or 29175 contest your rights to work written entirely by you; rather, the 29176 intent is to exercise the right to control the distribution of 29177 derivative or collective works based on the Program. 29178 29179 In addition, mere aggregation of another work not based on the 29180 Program with the Program (or with a work based on the Program) on 29181 a volume of a storage or distribution medium does not bring the 29182 other work under the scope of this License. 29183 29184 3. You may copy and distribute the Program (or a work based on it, 29185 under Section 2) in object code or executable form under the terms 29186 of Sections 1 and 2 above provided that you also do one of the 29187 following: 29188 29189 a. Accompany it with the complete corresponding machine-readable 29190 source code, which must be distributed under the terms of 29191 Sections 1 and 2 above on a medium customarily used for 29192 software interchange; or, 29193 29194 b. Accompany it with a written offer, valid for at least three 29195 years, to give any third party, for a charge no more than your 29196 cost of physically performing source distribution, a complete 29197 machine-readable copy of the corresponding source code, to be 29198 distributed under the terms of Sections 1 and 2 above on a 29199 medium customarily used for software interchange; or, 29200 29201 c. Accompany it with the information you received as to the offer 29202 to distribute corresponding source code. (This alternative is 29203 allowed only for noncommercial distribution and only if you 29204 received the program in object code or executable form with 29205 such an offer, in accord with Subsection b above.) 29206 29207 The source code for a work means the preferred form of the work for 29208 making modifications to it. For an executable work, complete 29209 source code means all the source code for all modules it contains, 29210 plus any associated interface definition files, plus the scripts 29211 used to control compilation and installation of the executable. 29212 However, as a special exception, the source code distributed need 29213 not include anything that is normally distributed (in either 29214 source or binary form) with the major components (compiler, 29215 kernel, and so on) of the operating system on which the executable 29216 runs, unless that component itself accompanies the executable. 29217 29218 If distribution of executable or object code is made by offering 29219 access to copy from a designated place, then offering equivalent 29220 access to copy the source code from the same place counts as 29221 distribution of the source code, even though third parties are not 29222 compelled to copy the source along with the object code. 29223 29224 4. You may not copy, modify, sublicense, or distribute the Program 29225 except as expressly provided under this License. Any attempt 29226 otherwise to copy, modify, sublicense or distribute the Program is 29227 void, and will automatically terminate your rights under this 29228 License. However, parties who have received copies, or rights, 29229 from you under this License will not have their licenses 29230 terminated so long as such parties remain in full compliance. 29231 29232 5. You are not required to accept this License, since you have not 29233 signed it. However, nothing else grants you permission to modify 29234 or distribute the Program or its derivative works. These actions 29235 are prohibited by law if you do not accept this License. 29236 Therefore, by modifying or distributing the Program (or any work 29237 based on the Program), you indicate your acceptance of this 29238 License to do so, and all its terms and conditions for copying, 29239 distributing or modifying the Program or works based on it. 29240 29241 6. Each time you redistribute the Program (or any work based on the 29242 Program), the recipient automatically receives a license from the 29243 original licensor to copy, distribute or modify the Program 29244 subject to these terms and conditions. You may not impose any 29245 further restrictions on the recipients' exercise of the rights 29246 granted herein. You are not responsible for enforcing compliance 29247 by third parties to this License. 29248 29249 7. If, as a consequence of a court judgment or allegation of patent 29250 infringement or for any other reason (not limited to patent 29251 issues), conditions are imposed on you (whether by court order, 29252 agreement or otherwise) that contradict the conditions of this 29253 License, they do not excuse you from the conditions of this 29254 License. If you cannot distribute so as to satisfy simultaneously 29255 your obligations under this License and any other pertinent 29256 obligations, then as a consequence you may not distribute the 29257 Program at all. For example, if a patent license would not permit 29258 royalty-free redistribution of the Program by all those who 29259 receive copies directly or indirectly through you, then the only 29260 way you could satisfy both it and this License would be to refrain 29261 entirely from distribution of the Program. 29262 29263 If any portion of this section is held invalid or unenforceable 29264 under any particular circumstance, the balance of the section is 29265 intended to apply and the section as a whole is intended to apply 29266 in other circumstances. 29267 29268 It is not the purpose of this section to induce you to infringe any 29269 patents or other property right claims or to contest validity of 29270 any such claims; this section has the sole purpose of protecting 29271 the integrity of the free software distribution system, which is 29272 implemented by public license practices. Many people have made 29273 generous contributions to the wide range of software distributed 29274 through that system in reliance on consistent application of that 29275 system; it is up to the author/donor to decide if he or she is 29276 willing to distribute software through any other system and a 29277 licensee cannot impose that choice. 29278 29279 This section is intended to make thoroughly clear what is believed 29280 to be a consequence of the rest of this License. 29281 29282 8. If the distribution and/or use of the Program is restricted in 29283 certain countries either by patents or by copyrighted interfaces, 29284 the original copyright holder who places the Program under this 29285 License may add an explicit geographical distribution limitation 29286 excluding those countries, so that distribution is permitted only 29287 in or among countries not thus excluded. In such case, this 29288 License incorporates the limitation as if written in the body of 29289 this License. 29290 29291 9. The Free Software Foundation may publish revised and/or new 29292 versions of the General Public License from time to time. Such 29293 new versions will be similar in spirit to the present version, but 29294 may differ in detail to address new problems or concerns. 29295 29296 Each version is given a distinguishing version number. If the 29297 Program specifies a version number of this License which applies 29298 to it and "any later version", you have the option of following 29299 the terms and conditions either of that version or of any later 29300 version published by the Free Software Foundation. If the Program 29301 does not specify a version number of this License, you may choose 29302 any version ever published by the Free Software Foundation. 29303 29304 10. If you wish to incorporate parts of the Program into other free 29305 programs whose distribution conditions are different, write to the 29306 author to ask for permission. For software which is copyrighted 29307 by the Free Software Foundation, write to the Free Software 29308 Foundation; we sometimes make exceptions for this. Our decision 29309 will be guided by the two goals of preserving the free status of 29310 all derivatives of our free software and of promoting the sharing 29311 and reuse of software generally. 29312 29313 NO WARRANTY 29314 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO 29315 WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE 29316 LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT 29317 HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT 29318 WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT 29319 NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND 29320 FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE 29321 QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE 29322 PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY 29323 SERVICING, REPAIR OR CORRECTION. 29324 29325 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN 29326 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY 29327 MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE 29328 LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, 29329 INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR 29330 INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF 29331 DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU 29332 OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY 29333 OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN 29334 ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 29335 29336 END OF TERMS AND CONDITIONS 29337 Appendix: How to Apply These Terms to Your New Programs 29338 ======================================================= 29339 29340 If you develop a new program, and you want it to be of the greatest 29341 possible use to the public, the best way to achieve this is to make it 29342 free software which everyone can redistribute and change under these 29343 terms. 29344 29345 To do so, attach the following notices to the program. It is safest 29346 to attach them to the start of each source file to most effectively 29347 convey the exclusion of warranty; and each file should have at least 29348 the "copyright" line and a pointer to where the full notice is found. 29349 29350 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. 29351 Copyright (C) YEAR NAME OF AUTHOR 29352 29353 This program is free software; you can redistribute it and/or modify 29354 it under the terms of the GNU General Public License as published by 29355 the Free Software Foundation; either version 2 of the License, or 29356 (at your option) any later version. 29357 29358 This program is distributed in the hope that it will be useful, 29359 but WITHOUT ANY WARRANTY; without even the implied warranty of 29360 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 29361 GNU General Public License for more details. 29362 29363 You should have received a copy of the GNU General Public License 29364 along with this program; if not, write to the Free Software 29365 Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA 29366 29367 Also add information on how to contact you by electronic and paper 29368 mail. 29369 29370 If the program is interactive, make it output a short notice like this 29371 when it starts in an interactive mode: 29372 29373 Gnomovision version 69, Copyright (C) YEAR NAME OF AUTHOR 29374 Gnomovision comes with ABSOLUTELY NO WARRANTY; for details 29375 type `show w'. 29376 This is free software, and you are welcome to redistribute it 29377 under certain conditions; type `show c' for details. 29378 29379 The hypothetical commands `show w' and `show c' should show the 29380 appropriate parts of the General Public License. Of course, the 29381 commands you use may be called something other than `show w' and `show 29382 c'; they could even be mouse-clicks or menu items--whatever suits your 29383 program. 29384 29385 You should also get your employer (if you work as a programmer) or your 29386 school, if any, to sign a "copyright disclaimer" for the program, if 29387 necessary. Here is a sample; alter the names: 29388 29389 Yoyodyne, Inc., hereby disclaims all copyright interest in the program 29390 `Gnomovision' (which makes passes at compilers) written by James Hacker. 29391 29392 SIGNATURE OF TY COON, 1 April 1989 29393 Ty Coon, President of Vice 29394 29395 This General Public License does not permit incorporating your program 29396 into proprietary programs. If your program is a subroutine library, 29397 you may consider it more useful to permit linking proprietary 29398 applications with the library. If this is what you want to do, use the 29399 GNU Library General Public License instead of this License. 29400 29401 29402 File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top 29403 29404 GNU Free Documentation License 29405 ****************************** 29406 29407 Version 1.2, November 2002 29408 29409 Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 29410 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA 29411 29412 Everyone is permitted to copy and distribute verbatim copies 29413 of this license document, but changing it is not allowed. 29414 29415 0. PREAMBLE 29416 29417 The purpose of this License is to make a manual, textbook, or other 29418 functional and useful document "free" in the sense of freedom: to 29419 assure everyone the effective freedom to copy and redistribute it, 29420 with or without modifying it, either commercially or 29421 noncommercially. Secondarily, this License preserves for the 29422 author and publisher a way to get credit for their work, while not 29423 being considered responsible for modifications made by others. 29424 29425 This License is a kind of "copyleft", which means that derivative 29426 works of the document must themselves be free in the same sense. 29427 It complements the GNU General Public License, which is a copyleft 29428 license designed for free software. 29429 29430 We have designed this License in order to use it for manuals for 29431 free software, because free software needs free documentation: a 29432 free program should come with manuals providing the same freedoms 29433 that the software does. But this License is not limited to 29434 software manuals; it can be used for any textual work, regardless 29435 of subject matter or whether it is published as a printed book. 29436 We recommend this License principally for works whose purpose is 29437 instruction or reference. 29438 29439 1. APPLICABILITY AND DEFINITIONS 29440 29441 This License applies to any manual or other work, in any medium, 29442 that contains a notice placed by the copyright holder saying it 29443 can be distributed under the terms of this License. Such a notice 29444 grants a world-wide, royalty-free license, unlimited in duration, 29445 to use that work under the conditions stated herein. The 29446 "Document", below, refers to any such manual or work. Any member 29447 of the public is a licensee, and is addressed as "you". You 29448 accept the license if you copy, modify or distribute the work in a 29449 way requiring permission under copyright law. 29450 29451 A "Modified Version" of the Document means any work containing the 29452 Document or a portion of it, either copied verbatim, or with 29453 modifications and/or translated into another language. 29454 29455 A "Secondary Section" is a named appendix or a front-matter section 29456 of the Document that deals exclusively with the relationship of the 29457 publishers or authors of the Document to the Document's overall 29458 subject (or to related matters) and contains nothing that could 29459 fall directly within that overall subject. (Thus, if the Document 29460 is in part a textbook of mathematics, a Secondary Section may not 29461 explain any mathematics.) The relationship could be a matter of 29462 historical connection with the subject or with related matters, or 29463 of legal, commercial, philosophical, ethical or political position 29464 regarding them. 29465 29466 The "Invariant Sections" are certain Secondary Sections whose 29467 titles are designated, as being those of Invariant Sections, in 29468 the notice that says that the Document is released under this 29469 License. If a section does not fit the above definition of 29470 Secondary then it is not allowed to be designated as Invariant. 29471 The Document may contain zero Invariant Sections. If the Document 29472 does not identify any Invariant Sections then there are none. 29473 29474 The "Cover Texts" are certain short passages of text that are 29475 listed, as Front-Cover Texts or Back-Cover Texts, in the notice 29476 that says that the Document is released under this License. A 29477 Front-Cover Text may be at most 5 words, and a Back-Cover Text may 29478 be at most 25 words. 29479 29480 A "Transparent" copy of the Document means a machine-readable copy, 29481 represented in a format whose specification is available to the 29482 general public, that is suitable for revising the document 29483 straightforwardly with generic text editors or (for images 29484 composed of pixels) generic paint programs or (for drawings) some 29485 widely available drawing editor, and that is suitable for input to 29486 text formatters or for automatic translation to a variety of 29487 formats suitable for input to text formatters. A copy made in an 29488 otherwise Transparent file format whose markup, or absence of 29489 markup, has been arranged to thwart or discourage subsequent 29490 modification by readers is not Transparent. An image format is 29491 not Transparent if used for any substantial amount of text. A 29492 copy that is not "Transparent" is called "Opaque". 29493 29494 Examples of suitable formats for Transparent copies include plain 29495 ASCII without markup, Texinfo input format, LaTeX input format, 29496 SGML or XML using a publicly available DTD, and 29497 standard-conforming simple HTML, PostScript or PDF designed for 29498 human modification. Examples of transparent image formats include 29499 PNG, XCF and JPG. Opaque formats include proprietary formats that 29500 can be read and edited only by proprietary word processors, SGML or 29501 XML for which the DTD and/or processing tools are not generally 29502 available, and the machine-generated HTML, PostScript or PDF 29503 produced by some word processors for output purposes only. 29504 29505 The "Title Page" means, for a printed book, the title page itself, 29506 plus such following pages as are needed to hold, legibly, the 29507 material this License requires to appear in the title page. For 29508 works in formats which do not have any title page as such, "Title 29509 Page" means the text near the most prominent appearance of the 29510 work's title, preceding the beginning of the body of the text. 29511 29512 A section "Entitled XYZ" means a named subunit of the Document 29513 whose title either is precisely XYZ or contains XYZ in parentheses 29514 following text that translates XYZ in another language. (Here XYZ 29515 stands for a specific section name mentioned below, such as 29516 "Acknowledgements", "Dedications", "Endorsements", or "History".) 29517 To "Preserve the Title" of such a section when you modify the 29518 Document means that it remains a section "Entitled XYZ" according 29519 to this definition. 29520 29521 The Document may include Warranty Disclaimers next to the notice 29522 which states that this License applies to the Document. These 29523 Warranty Disclaimers are considered to be included by reference in 29524 this License, but only as regards disclaiming warranties: any other 29525 implication that these Warranty Disclaimers may have is void and 29526 has no effect on the meaning of this License. 29527 29528 2. VERBATIM COPYING 29529 29530 You may copy and distribute the Document in any medium, either 29531 commercially or noncommercially, provided that this License, the 29532 copyright notices, and the license notice saying this License 29533 applies to the Document are reproduced in all copies, and that you 29534 add no other conditions whatsoever to those of this License. You 29535 may not use technical measures to obstruct or control the reading 29536 or further copying of the copies you make or distribute. However, 29537 you may accept compensation in exchange for copies. If you 29538 distribute a large enough number of copies you must also follow 29539 the conditions in section 3. 29540 29541 You may also lend copies, under the same conditions stated above, 29542 and you may publicly display copies. 29543 29544 3. COPYING IN QUANTITY 29545 29546 If you publish printed copies (or copies in media that commonly 29547 have printed covers) of the Document, numbering more than 100, and 29548 the Document's license notice requires Cover Texts, you must 29549 enclose the copies in covers that carry, clearly and legibly, all 29550 these Cover Texts: Front-Cover Texts on the front cover, and 29551 Back-Cover Texts on the back cover. Both covers must also clearly 29552 and legibly identify you as the publisher of these copies. The 29553 front cover must present the full title with all words of the 29554 title equally prominent and visible. You may add other material 29555 on the covers in addition. Copying with changes limited to the 29556 covers, as long as they preserve the title of the Document and 29557 satisfy these conditions, can be treated as verbatim copying in 29558 other respects. 29559 29560 If the required texts for either cover are too voluminous to fit 29561 legibly, you should put the first ones listed (as many as fit 29562 reasonably) on the actual cover, and continue the rest onto 29563 adjacent pages. 29564 29565 If you publish or distribute Opaque copies of the Document 29566 numbering more than 100, you must either include a 29567 machine-readable Transparent copy along with each Opaque copy, or 29568 state in or with each Opaque copy a computer-network location from 29569 which the general network-using public has access to download 29570 using public-standard network protocols a complete Transparent 29571 copy of the Document, free of added material. If you use the 29572 latter option, you must take reasonably prudent steps, when you 29573 begin distribution of Opaque copies in quantity, to ensure that 29574 this Transparent copy will remain thus accessible at the stated 29575 location until at least one year after the last time you 29576 distribute an Opaque copy (directly or through your agents or 29577 retailers) of that edition to the public. 29578 29579 It is requested, but not required, that you contact the authors of 29580 the Document well before redistributing any large number of 29581 copies, to give them a chance to provide you with an updated 29582 version of the Document. 29583 29584 4. MODIFICATIONS 29585 29586 You may copy and distribute a Modified Version of the Document 29587 under the conditions of sections 2 and 3 above, provided that you 29588 release the Modified Version under precisely this License, with 29589 the Modified Version filling the role of the Document, thus 29590 licensing distribution and modification of the Modified Version to 29591 whoever possesses a copy of it. In addition, you must do these 29592 things in the Modified Version: 29593 29594 A. Use in the Title Page (and on the covers, if any) a title 29595 distinct from that of the Document, and from those of 29596 previous versions (which should, if there were any, be listed 29597 in the History section of the Document). You may use the 29598 same title as a previous version if the original publisher of 29599 that version gives permission. 29600 29601 B. List on the Title Page, as authors, one or more persons or 29602 entities responsible for authorship of the modifications in 29603 the Modified Version, together with at least five of the 29604 principal authors of the Document (all of its principal 29605 authors, if it has fewer than five), unless they release you 29606 from this requirement. 29607 29608 C. State on the Title page the name of the publisher of the 29609 Modified Version, as the publisher. 29610 29611 D. Preserve all the copyright notices of the Document. 29612 29613 E. Add an appropriate copyright notice for your modifications 29614 adjacent to the other copyright notices. 29615 29616 F. Include, immediately after the copyright notices, a license 29617 notice giving the public permission to use the Modified 29618 Version under the terms of this License, in the form shown in 29619 the Addendum below. 29620 29621 G. Preserve in that license notice the full lists of Invariant 29622 Sections and required Cover Texts given in the Document's 29623 license notice. 29624 29625 H. Include an unaltered copy of this License. 29626 29627 I. Preserve the section Entitled "History", Preserve its Title, 29628 and add to it an item stating at least the title, year, new 29629 authors, and publisher of the Modified Version as given on 29630 the Title Page. If there is no section Entitled "History" in 29631 the Document, create one stating the title, year, authors, 29632 and publisher of the Document as given on its Title Page, 29633 then add an item describing the Modified Version as stated in 29634 the previous sentence. 29635 29636 J. Preserve the network location, if any, given in the Document 29637 for public access to a Transparent copy of the Document, and 29638 likewise the network locations given in the Document for 29639 previous versions it was based on. These may be placed in 29640 the "History" section. You may omit a network location for a 29641 work that was published at least four years before the 29642 Document itself, or if the original publisher of the version 29643 it refers to gives permission. 29644 29645 K. For any section Entitled "Acknowledgements" or "Dedications", 29646 Preserve the Title of the section, and preserve in the 29647 section all the substance and tone of each of the contributor 29648 acknowledgements and/or dedications given therein. 29649 29650 L. Preserve all the Invariant Sections of the Document, 29651 unaltered in their text and in their titles. Section numbers 29652 or the equivalent are not considered part of the section 29653 titles. 29654 29655 M. Delete any section Entitled "Endorsements". Such a section 29656 may not be included in the Modified Version. 29657 29658 N. Do not retitle any existing section to be Entitled 29659 "Endorsements" or to conflict in title with any Invariant 29660 Section. 29661 29662 O. Preserve any Warranty Disclaimers. 29663 29664 If the Modified Version includes new front-matter sections or 29665 appendices that qualify as Secondary Sections and contain no 29666 material copied from the Document, you may at your option 29667 designate some or all of these sections as invariant. To do this, 29668 add their titles to the list of Invariant Sections in the Modified 29669 Version's license notice. These titles must be distinct from any 29670 other section titles. 29671 29672 You may add a section Entitled "Endorsements", provided it contains 29673 nothing but endorsements of your Modified Version by various 29674 parties--for example, statements of peer review or that the text 29675 has been approved by an organization as the authoritative 29676 definition of a standard. 29677 29678 You may add a passage of up to five words as a Front-Cover Text, 29679 and a passage of up to 25 words as a Back-Cover Text, to the end 29680 of the list of Cover Texts in the Modified Version. Only one 29681 passage of Front-Cover Text and one of Back-Cover Text may be 29682 added by (or through arrangements made by) any one entity. If the 29683 Document already includes a cover text for the same cover, 29684 previously added by you or by arrangement made by the same entity 29685 you are acting on behalf of, you may not add another; but you may 29686 replace the old one, on explicit permission from the previous 29687 publisher that added the old one. 29688 29689 The author(s) and publisher(s) of the Document do not by this 29690 License give permission to use their names for publicity for or to 29691 assert or imply endorsement of any Modified Version. 29692 29693 5. COMBINING DOCUMENTS 29694 29695 You may combine the Document with other documents released under 29696 this License, under the terms defined in section 4 above for 29697 modified versions, provided that you include in the combination 29698 all of the Invariant Sections of all of the original documents, 29699 unmodified, and list them all as Invariant Sections of your 29700 combined work in its license notice, and that you preserve all 29701 their Warranty Disclaimers. 29702 29703 The combined work need only contain one copy of this License, and 29704 multiple identical Invariant Sections may be replaced with a single 29705 copy. If there are multiple Invariant Sections with the same name 29706 but different contents, make the title of each such section unique 29707 by adding at the end of it, in parentheses, the name of the 29708 original author or publisher of that section if known, or else a 29709 unique number. Make the same adjustment to the section titles in 29710 the list of Invariant Sections in the license notice of the 29711 combined work. 29712 29713 In the combination, you must combine any sections Entitled 29714 "History" in the various original documents, forming one section 29715 Entitled "History"; likewise combine any sections Entitled 29716 "Acknowledgements", and any sections Entitled "Dedications". You 29717 must delete all sections Entitled "Endorsements." 29718 29719 6. COLLECTIONS OF DOCUMENTS 29720 29721 You may make a collection consisting of the Document and other 29722 documents released under this License, and replace the individual 29723 copies of this License in the various documents with a single copy 29724 that is included in the collection, provided that you follow the 29725 rules of this License for verbatim copying of each of the 29726 documents in all other respects. 29727 29728 You may extract a single document from such a collection, and 29729 distribute it individually under this License, provided you insert 29730 a copy of this License into the extracted document, and follow 29731 this License in all other respects regarding verbatim copying of 29732 that document. 29733 29734 7. AGGREGATION WITH INDEPENDENT WORKS 29735 29736 A compilation of the Document or its derivatives with other 29737 separate and independent documents or works, in or on a volume of 29738 a storage or distribution medium, is called an "aggregate" if the 29739 copyright resulting from the compilation is not used to limit the 29740 legal rights of the compilation's users beyond what the individual 29741 works permit. When the Document is included in an aggregate, this 29742 License does not apply to the other works in the aggregate which 29743 are not themselves derivative works of the Document. 29744 29745 If the Cover Text requirement of section 3 is applicable to these 29746 copies of the Document, then if the Document is less than one half 29747 of the entire aggregate, the Document's Cover Texts may be placed 29748 on covers that bracket the Document within the aggregate, or the 29749 electronic equivalent of covers if the Document is in electronic 29750 form. Otherwise they must appear on printed covers that bracket 29751 the whole aggregate. 29752 29753 8. TRANSLATION 29754 29755 Translation is considered a kind of modification, so you may 29756 distribute translations of the Document under the terms of section 29757 4. Replacing Invariant Sections with translations requires special 29758 permission from their copyright holders, but you may include 29759 translations of some or all Invariant Sections in addition to the 29760 original versions of these Invariant Sections. You may include a 29761 translation of this License, and all the license notices in the 29762 Document, and any Warranty Disclaimers, provided that you also 29763 include the original English version of this License and the 29764 original versions of those notices and disclaimers. In case of a 29765 disagreement between the translation and the original version of 29766 this License or a notice or disclaimer, the original version will 29767 prevail. 29768 29769 If a section in the Document is Entitled "Acknowledgements", 29770 "Dedications", or "History", the requirement (section 4) to 29771 Preserve its Title (section 1) will typically require changing the 29772 actual title. 29773 29774 9. TERMINATION 29775 29776 You may not copy, modify, sublicense, or distribute the Document 29777 except as expressly provided for under this License. Any other 29778 attempt to copy, modify, sublicense or distribute the Document is 29779 void, and will automatically terminate your rights under this 29780 License. However, parties who have received copies, or rights, 29781 from you under this License will not have their licenses 29782 terminated so long as such parties remain in full compliance. 29783 29784 10. FUTURE REVISIONS OF THIS LICENSE 29785 29786 The Free Software Foundation may publish new, revised versions of 29787 the GNU Free Documentation License from time to time. Such new 29788 versions will be similar in spirit to the present version, but may 29789 differ in detail to address new problems or concerns. See 29790 `http://www.gnu.org/copyleft/'. 29791 29792 Each version of the License is given a distinguishing version 29793 number. If the Document specifies that a particular numbered 29794 version of this License "or any later version" applies to it, you 29795 have the option of following the terms and conditions either of 29796 that specified version or of any later version that has been 29797 published (not as a draft) by the Free Software Foundation. If 29798 the Document does not specify a version number of this License, 29799 you may choose any version ever published (not as a draft) by the 29800 Free Software Foundation. 29801 29802 ADDENDUM: How to use this License for your documents 29803 ==================================================== 29804 29805 To use this License in a document you have written, include a copy of 29806 the License in the document and put the following copyright and license 29807 notices just after the title page: 29808 29809 Copyright (C) YEAR YOUR NAME. 29810 Permission is granted to copy, distribute and/or modify this document 29811 under the terms of the GNU Free Documentation License, Version 1.2 29812 or any later version published by the Free Software Foundation; 29813 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 29814 Texts. A copy of the license is included in the section entitled ``GNU 29815 Free Documentation License''. 29816 29817 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, 29818 replace the "with...Texts." line with this: 29819 29820 with the Invariant Sections being LIST THEIR TITLES, with 29821 the Front-Cover Texts being LIST, and with the Back-Cover Texts 29822 being LIST. 29823 29824 If you have Invariant Sections without Cover Texts, or some other 29825 combination of the three, merge those two alternatives to suit the 29826 situation. 29827 29828 If your document contains nontrivial examples of program code, we 29829 recommend releasing these examples in parallel under your choice of 29830 free software license, such as the GNU General Public License, to 29831 permit their use in free software. 29832 29833 29834 File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top 29835 29836 Contributors to GCC 29837 ******************* 29838 29839 The GCC project would like to thank its many contributors. Without 29840 them the project would not have been nearly as successful as it has 29841 been. Any omissions in this list are accidental. Feel free to contact 29842 <law (a] redhat.com> or <gerald (a] pfeifer.com> if you have been left out or 29843 some of your contributions are not listed. Please keep this list in 29844 alphabetical order. 29845 29846 * Analog Devices helped implement the support for complex data types 29847 and iterators. 29848 29849 * John David Anglin for threading-related fixes and improvements to 29850 libstdc++-v3, and the HP-UX port. 29851 29852 * James van Artsdalen wrote the code that makes efficient use of the 29853 Intel 80387 register stack. 29854 29855 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta 29856 Series port. 29857 29858 * Alasdair Baird for various bug fixes. 29859 29860 * Giovanni Bajo for analyzing lots of complicated C++ problem 29861 reports. 29862 29863 * Peter Barada for his work to improve code generation for new 29864 ColdFire cores. 29865 29866 * Gerald Baumgartner added the signature extension to the C++ front 29867 end. 29868 29869 * Godmar Back for his Java improvements and encouragement. 29870 29871 * Scott Bambrough for help porting the Java compiler. 29872 29873 * Wolfgang Bangerth for processing tons of bug reports. 29874 29875 * Jon Beniston for his Microsoft Windows port of Java. 29876 29877 * Daniel Berlin for better DWARF2 support, faster/better 29878 optimizations, improved alias analysis, plus migrating GCC to 29879 Bugzilla. 29880 29881 * Geoff Berry for his Java object serialization work and various 29882 patches. 29883 29884 * Uros Bizjak for the implementation of x87 math built-in functions 29885 and for various middle end and i386 back end improvements and 29886 bugfixes. 29887 29888 * Eric Blake for helping to make GCJ and libgcj conform to the 29889 specifications. 29890 29891 * Janne Blomqvist for contributions to GNU Fortran. 29892 29893 * Segher Boessenkool for various fixes. 29894 29895 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and 29896 other Java work. 29897 29898 * Neil Booth for work on cpplib, lang hooks, debug hooks and other 29899 miscellaneous clean-ups. 29900 29901 * Steven Bosscher for integrating the GNU Fortran front end into GCC 29902 and for contributing to the tree-ssa branch. 29903 29904 * Eric Botcazou for fixing middle- and backend bugs left and right. 29905 29906 * Per Bothner for his direction via the steering committee and 29907 various improvements to the infrastructure for supporting new 29908 languages. Chill front end implementation. Initial 29909 implementations of cpplib, fix-header, config.guess, libio, and 29910 past C++ library (libg++) maintainer. Dreaming up, designing and 29911 implementing much of GCJ. 29912 29913 * Devon Bowen helped port GCC to the Tahoe. 29914 29915 * Don Bowman for mips-vxworks contributions. 29916 29917 * Dave Brolley for work on cpplib and Chill. 29918 29919 * Paul Brook for work on the ARM architecture and maintaining GNU 29920 Fortran. 29921 29922 * Robert Brown implemented the support for Encore 32000 systems. 29923 29924 * Christian Bruel for improvements to local store elimination. 29925 29926 * Herman A.J. ten Brugge for various fixes. 29927 29928 * Joerg Brunsmann for Java compiler hacking and help with the GCJ 29929 FAQ. 29930 29931 * Joe Buck for his direction via the steering committee. 29932 29933 * Craig Burley for leadership of the G77 Fortran effort. 29934 29935 * Stephan Buys for contributing Doxygen notes for libstdc++. 29936 29937 * Paolo Carlini for libstdc++ work: lots of efficiency improvements 29938 to the C++ strings, streambufs and formatted I/O, hard detective 29939 work on the frustrating localization issues, and keeping up with 29940 the problem reports. 29941 29942 * John Carr for his alias work, SPARC hacking, infrastructure 29943 improvements, previous contributions to the steering committee, 29944 loop optimizations, etc. 29945 29946 * Stephane Carrez for 68HC11 and 68HC12 ports. 29947 29948 * Steve Chamberlain for support for the Renesas SH and H8 processors 29949 and the PicoJava processor, and for GCJ config fixes. 29950 29951 * Glenn Chambers for help with the GCJ FAQ. 29952 29953 * John-Marc Chandonia for various libgcj patches. 29954 29955 * Scott Christley for his Objective-C contributions. 29956 29957 * Eric Christopher for his Java porting help and clean-ups. 29958 29959 * Branko Cibej for more warning contributions. 29960 29961 * The GNU Classpath project for all of their merged runtime code. 29962 29963 * Nick Clifton for arm, mcore, fr30, v850, m32r work, `--help', and 29964 other random hacking. 29965 29966 * Michael Cook for libstdc++ cleanup patches to reduce warnings. 29967 29968 * R. Kelley Cook for making GCC buildable from a read-only directory 29969 as well as other miscellaneous build process and documentation 29970 clean-ups. 29971 29972 * Ralf Corsepius for SH testing and minor bugfixing. 29973 29974 * Stan Cox for care and feeding of the x86 port and lots of behind 29975 the scenes hacking. 29976 29977 * Alex Crain provided changes for the 3b1. 29978 29979 * Ian Dall for major improvements to the NS32k port. 29980 29981 * Paul Dale for his work to add uClinux platform support to the m68k 29982 backend. 29983 29984 * Dario Dariol contributed the four varieties of sample programs 29985 that print a copy of their source. 29986 29987 * Russell Davidson for fstream and stringstream fixes in libstdc++. 29988 29989 * Bud Davis for work on the G77 and GNU Fortran compilers. 29990 29991 * Mo DeJong for GCJ and libgcj bug fixes. 29992 29993 * DJ Delorie for the DJGPP port, build and libiberty maintenance, 29994 various bug fixes, and the M32C port. 29995 29996 * Arnaud Desitter for helping to debug GNU Fortran. 29997 29998 * Gabriel Dos Reis for contributions to G++, contributions and 29999 maintenance of GCC diagnostics infrastructure, libstdc++-v3, 30000 including `valarray<>', `complex<>', maintaining the numerics 30001 library (including that pesky `<limits>' :-) and keeping 30002 up-to-date anything to do with numbers. 30003 30004 * Ulrich Drepper for his work on glibc, testing of GCC using glibc, 30005 ISO C99 support, CFG dumping support, etc., plus support of the 30006 C++ runtime libraries including for all kinds of C interface 30007 issues, contributing and maintaining `complex<>', sanity checking 30008 and disbursement, configuration architecture, libio maintenance, 30009 and early math work. 30010 30011 * Zdenek Dvorak for a new loop unroller and various fixes. 30012 30013 * Richard Earnshaw for his ongoing work with the ARM. 30014 30015 * David Edelsohn for his direction via the steering committee, 30016 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa 30017 loop changes, doing the entire AIX port of libstdc++ with his bare 30018 hands, and for ensuring GCC properly keeps working on AIX. 30019 30020 * Kevin Ediger for the floating point formatting of num_put::do_put 30021 in libstdc++. 30022 30023 * Phil Edwards for libstdc++ work including configuration hackery, 30024 documentation maintainer, chief breaker of the web pages, the 30025 occasional iostream bug fix, and work on shared library symbol 30026 versioning. 30027 30028 * Paul Eggert for random hacking all over GCC. 30029 30030 * Mark Elbrecht for various DJGPP improvements, and for libstdc++ 30031 configuration support for locales and fstream-related fixes. 30032 30033 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and 30034 iostreams. 30035 30036 * Christian Ehrhardt for dealing with bug reports. 30037 30038 * Ben Elliston for his work to move the Objective-C runtime into its 30039 own subdirectory and for his work on autoconf. 30040 30041 * Marc Espie for OpenBSD support. 30042 30043 * Doug Evans for much of the global optimization framework, arc, 30044 m32r, and SPARC work. 30045 30046 * Christopher Faylor for his work on the Cygwin port and for caring 30047 and feeding the gcc.gnu.org box and saving its users tons of spam. 30048 30049 * Fred Fish for BeOS support and Ada fixes. 30050 30051 * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ. 30052 30053 * Peter Gerwinski for various bug fixes and the Pascal front end. 30054 30055 * Kaveh R. Ghazi for his direction via the steering committee, 30056 amazing work to make `-W -Wall -W* -Werror' useful, and 30057 continuously testing GCC on a plethora of platforms. Kaveh 30058 extends his gratitude to the CAIP Center at Rutgers University for 30059 providing him with computing resources to work on Free Software 30060 since the late 1980s. 30061 30062 * John Gilmore for a donation to the FSF earmarked improving GNU 30063 Java. 30064 30065 * Judy Goldberg for c++ contributions. 30066 30067 * Torbjorn Granlund for various fixes and the c-torture testsuite, 30068 multiply- and divide-by-constant optimization, improved long long 30069 support, improved leaf function register allocation, and his 30070 direction via the steering committee. 30071 30072 * Anthony Green for his `-Os' contributions and Java front end work. 30073 30074 * Stu Grossman for gdb hacking, allowing GCJ developers to debug 30075 Java code. 30076 30077 * Michael K. Gschwind contributed the port to the PDP-11. 30078 30079 * Ron Guilmette implemented the `protoize' and `unprotoize' tools, 30080 the support for Dwarf symbolic debugging information, and much of 30081 the support for System V Release 4. He has also worked heavily on 30082 the Intel 386 and 860 support. 30083 30084 * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload 30085 GCSE. 30086 30087 * Bruno Haible for improvements in the runtime overhead for EH, new 30088 warnings and assorted bug fixes. 30089 30090 * Andrew Haley for his amazing Java compiler and library efforts. 30091 30092 * Chris Hanson assisted in making GCC work on HP-UX for the 9000 30093 series 300. 30094 30095 * Michael Hayes for various thankless work he's done trying to get 30096 the c30/c40 ports functional. Lots of loop and unroll 30097 improvements and fixes. 30098 30099 * Dara Hazeghi for wading through myriads of target-specific bug 30100 reports. 30101 30102 * Kate Hedstrom for staking the G77 folks with an initial testsuite. 30103 30104 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 30105 work, loop opts, and generally fixing lots of old problems we've 30106 ignored for years, flow rewrite and lots of further stuff, 30107 including reviewing tons of patches. 30108 30109 * Aldy Hernandez for working on the PowerPC port, SIMD support, and 30110 various fixes. 30111 30112 * Nobuyuki Hikichi of Software Research Associates, Tokyo, 30113 contributed the support for the Sony NEWS machine. 30114 30115 * Kazu Hirata for caring and feeding the Renesas H8/300 port and 30116 various fixes. 30117 30118 * Katherine Holcomb for work on GNU Fortran. 30119 30120 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots 30121 of testing and bug fixing, particularly of GCC configury code. 30122 30123 * Steve Holmgren for MachTen patches. 30124 30125 * Jan Hubicka for his x86 port improvements. 30126 30127 * Falk Hueffner for working on C and optimization bug reports. 30128 30129 * Bernardo Innocenti for his m68k work, including merging of 30130 ColdFire improvements and uClinux support. 30131 30132 * Christian Iseli for various bug fixes. 30133 30134 * Kamil Iskra for general m68k hacking. 30135 30136 * Lee Iverson for random fixes and MIPS testing. 30137 30138 * Andreas Jaeger for testing and benchmarking of GCC and various bug 30139 fixes. 30140 30141 * Jakub Jelinek for his SPARC work and sibling call optimizations as 30142 well as lots of bug fixes and test cases, and for improving the 30143 Java build system. 30144 30145 * Janis Johnson for ia64 testing and fixes, her quality improvement 30146 sidetracks, and web page maintenance. 30147 30148 * Kean Johnston for SCO OpenServer support and various fixes. 30149 30150 * Tim Josling for the sample language treelang based originally on 30151 Richard Kenner's "toy" language. 30152 30153 * Nicolai Josuttis for additional libstdc++ documentation. 30154 30155 * Klaus Kaempf for his ongoing work to make alpha-vms a viable 30156 target. 30157 30158 * Steven G. Kargl for work on GNU Fortran. 30159 30160 * David Kashtan of SRI adapted GCC to VMS. 30161 30162 * Ryszard Kabatek for many, many libstdc++ bug fixes and 30163 optimizations of strings, especially member functions, and for 30164 auto_ptr fixes. 30165 30166 * Geoffrey Keating for his ongoing work to make the PPC work for 30167 GNU/Linux and his automatic regression tester. 30168 30169 * Brendan Kehoe for his ongoing work with G++ and for a lot of early 30170 work in just about every part of libstdc++. 30171 30172 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the 30173 MIL-STD-1750A. 30174 30175 * Richard Kenner of the New York University Ultracomputer Research 30176 Laboratory wrote the machine descriptions for the AMD 29000, the 30177 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the 30178 support for instruction attributes. He also made changes to 30179 better support RISC processors including changes to common 30180 subexpression elimination, strength reduction, function calling 30181 sequence handling, and condition code support, in addition to 30182 generalizing the code for frame pointer elimination and delay slot 30183 scheduling. Richard Kenner was also the head maintainer of GCC 30184 for several years. 30185 30186 * Mumit Khan for various contributions to the Cygwin and Mingw32 30187 ports and maintaining binary releases for Microsoft Windows hosts, 30188 and for massive libstdc++ porting work to Cygwin/Mingw32. 30189 30190 * Robin Kirkham for cpu32 support. 30191 30192 * Mark Klein for PA improvements. 30193 30194 * Thomas Koenig for various bug fixes. 30195 30196 * Bruce Korb for the new and improved fixincludes code. 30197 30198 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 30199 effort. 30200 30201 * Charles LaBrec contributed the support for the Integrated Solutions 30202 68020 system. 30203 30204 * Asher Langton and Mike Kumbera for contributing Cray pointer 30205 support to GNU Fortran, and for other GNU Fortran improvements. 30206 30207 * Jeff Law for his direction via the steering committee, 30208 coordinating the entire egcs project and GCC 2.95, rolling out 30209 snapshots and releases, handling merges from GCC2, reviewing tons 30210 of patches that might have fallen through the cracks else, and 30211 random but extensive hacking. 30212 30213 * Marc Lehmann for his direction via the steering committee and 30214 helping with analysis and improvements of x86 performance. 30215 30216 * Victor Leikehman for work on GNU Fortran. 30217 30218 * Ted Lemon wrote parts of the RTL reader and printer. 30219 30220 * Kriang Lerdsuwanakij for C++ improvements including template as 30221 template parameter support, and many C++ fixes. 30222 30223 * Warren Levy for tremendous work on libgcj (Java Runtime Library) 30224 and random work on the Java front end. 30225 30226 * Alain Lichnewsky ported GCC to the MIPS CPU. 30227 30228 * Oskar Liljeblad for hacking on AWT and his many Java bug reports 30229 and patches. 30230 30231 * Robert Lipe for OpenServer support, new testsuites, testing, etc. 30232 30233 * Weiwen Liu for testing and various bug fixes. 30234 30235 * Dave Love for his ongoing work with the Fortran front end and 30236 runtime libraries. 30237 30238 * Martin von Lo"wis for internal consistency checking infrastructure, 30239 various C++ improvements including namespace support, and tons of 30240 assistance with libstdc++/compiler merges. 30241 30242 * H.J. Lu for his previous contributions to the steering committee, 30243 many x86 bug reports, prototype patches, and keeping the GNU/Linux 30244 ports working. 30245 30246 * Greg McGary for random fixes and (someday) bounded pointers. 30247 30248 * Andrew MacLeod for his ongoing work in building a real EH system, 30249 various code generation improvements, work on the global 30250 optimizer, etc. 30251 30252 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC 30253 hacking improvements to compile-time performance, overall 30254 knowledge and direction in the area of instruction scheduling, and 30255 design and implementation of the automaton based instruction 30256 scheduler. 30257 30258 * Bob Manson for his behind the scenes work on dejagnu. 30259 30260 * Philip Martin for lots of libstdc++ string and vector iterator 30261 fixes and improvements, and string clean up and testsuites. 30262 30263 * All of the Mauve project contributors, for Java test code. 30264 30265 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements. 30266 30267 * Adam Megacz for his work on the Microsoft Windows port of GCJ. 30268 30269 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, 30270 powerpc, haifa, ECOFF debug support, and other assorted hacking. 30271 30272 * Jason Merrill for his direction via the steering committee and 30273 leading the G++ effort. 30274 30275 * Martin Michlmayr for testing GCC on several architectures using the 30276 entire Debian archive. 30277 30278 * David Miller for his direction via the steering committee, lots of 30279 SPARC work, improvements in jump.c and interfacing with the Linux 30280 kernel developers. 30281 30282 * Gary Miller ported GCC to Charles River Data Systems machines. 30283 30284 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning 30285 the entire libstdc++ testsuite namespace-compatible. 30286 30287 * Mark Mitchell for his direction via the steering committee, 30288 mountains of C++ work, load/store hoisting out of loops, alias 30289 analysis improvements, ISO C `restrict' support, and serving as 30290 release manager for GCC 3.x. 30291 30292 * Alan Modra for various GNU/Linux bits and testing. 30293 30294 * Toon Moene for his direction via the steering committee, Fortran 30295 maintenance, and his ongoing work to make us make Fortran run fast. 30296 30297 * Jason Molenda for major help in the care and feeding of all the 30298 services on the gcc.gnu.org (formerly egcs.cygnus.com) 30299 machine--mail, web services, ftp services, etc etc. Doing all 30300 this work on scrap paper and the backs of envelopes would have 30301 been... difficult. 30302 30303 * Catherine Moore for fixing various ugly problems we have sent her 30304 way, including the haifa bug which was killing the Alpha & PowerPC 30305 Linux kernels. 30306 30307 * Mike Moreton for his various Java patches. 30308 30309 * David Mosberger-Tang for various Alpha improvements, and for the 30310 initial IA-64 port. 30311 30312 * Stephen Moshier contributed the floating point emulator that 30313 assists in cross-compilation and permits support for floating 30314 point numbers wider than 64 bits and for ISO C99 support. 30315 30316 * Bill Moyer for his behind the scenes work on various issues. 30317 30318 * Philippe De Muyter for his work on the m68k port. 30319 30320 * Joseph S. Myers for his work on the PDP-11 port, format checking 30321 and ISO C99 support, and continuous emphasis on (and contributions 30322 to) documentation. 30323 30324 * Nathan Myers for his work on libstdc++-v3: architecture and 30325 authorship through the first three snapshots, including 30326 implementation of locale infrastructure, string, shadow C headers, 30327 and the initial project documentation (DESIGN, CHECKLIST, and so 30328 forth). Later, more work on MT-safe string and shadow headers. 30329 30330 * Felix Natter for documentation on porting libstdc++. 30331 30332 * Nathanael Nerode for cleaning up the configuration/build process. 30333 30334 * NeXT, Inc. donated the front end that supports the Objective-C 30335 language. 30336 30337 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to 30338 the search engine setup, various documentation fixes and other 30339 small fixes. 30340 30341 * Geoff Noer for his work on getting cygwin native builds working. 30342 30343 * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance 30344 tracking web pages and assorted fixes. 30345 30346 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, 30347 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and 30348 related infrastructure improvements. 30349 30350 * Alexandre Oliva for various build infrastructure improvements, 30351 scripts and amazing testing work, including keeping libtool issues 30352 sane and happy. 30353 30354 * Stefan Olsson for work on mt_alloc. 30355 30356 * Melissa O'Neill for various NeXT fixes. 30357 30358 * Rainer Orth for random MIPS work, including improvements to GCC's 30359 o32 ABI support, improvements to dejagnu's MIPS support, Java 30360 configuration clean-ups and porting work, etc. 30361 30362 * Hartmut Penner for work on the s390 port. 30363 30364 * Paul Petersen wrote the machine description for the Alliant FX/8. 30365 30366 * Alexandre Petit-Bianco for implementing much of the Java compiler 30367 and continued Java maintainership. 30368 30369 * Matthias Pfaller for major improvements to the NS32k port. 30370 30371 * Gerald Pfeifer for his direction via the steering committee, 30372 pointing out lots of problems we need to solve, maintenance of the 30373 web pages, and taking care of documentation maintenance in general. 30374 30375 * Andrew Pinski for processing bug reports by the dozen. 30376 30377 * Ovidiu Predescu for his work on the Objective-C front end and 30378 runtime libraries. 30379 30380 * Jerry Quinn for major performance improvements in C++ formatted 30381 I/O. 30382 30383 * Ken Raeburn for various improvements to checker, MIPS ports and 30384 various cleanups in the compiler. 30385 30386 * Rolf W. Rasmussen for hacking on AWT. 30387 30388 * David Reese of Sun Microsystems contributed to the Solaris on 30389 PowerPC port. 30390 30391 * Volker Reichelt for keeping up with the problem reports. 30392 30393 * Joern Rennecke for maintaining the sh port, loop, regmove & reload 30394 hacking. 30395 30396 * Loren J. Rittle for improvements to libstdc++-v3 including the 30397 FreeBSD port, threading fixes, thread-related configury changes, 30398 critical threading documentation, and solutions to really tricky 30399 I/O problems, as well as keeping GCC properly working on FreeBSD 30400 and continuous testing. 30401 30402 * Craig Rodrigues for processing tons of bug reports. 30403 30404 * Ola Ro"nnerup for work on mt_alloc. 30405 30406 * Gavin Romig-Koch for lots of behind the scenes MIPS work. 30407 30408 * David Ronis inspired and encouraged Craig to rewrite the G77 30409 documentation in texinfo format by contributing a first pass at a 30410 translation of the old `g77-0.5.16/f/DOC' file. 30411 30412 * Ken Rose for fixes to GCC's delay slot filling code. 30413 30414 * Paul Rubin wrote most of the preprocessor. 30415 30416 * Pe'tur Runo'lfsson for major performance improvements in C++ 30417 formatted I/O and large file support in C++ filebuf. 30418 30419 * Chip Salzenberg for libstdc++ patches and improvements to locales, 30420 traits, Makefiles, libio, libtool hackery, and "long long" support. 30421 30422 * Juha Sarlin for improvements to the H8 code generator. 30423 30424 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series 30425 300. 30426 30427 * Roger Sayle for improvements to constant folding and GCC's RTL 30428 optimizers as well as for fixing numerous bugs. 30429 30430 * Bradley Schatz for his work on the GCJ FAQ. 30431 30432 * Peter Schauer wrote the code to allow debugging to work on the 30433 Alpha. 30434 30435 * William Schelter did most of the work on the Intel 80386 support. 30436 30437 * Tobias Schlu"ter for work on GNU Fortran. 30438 30439 * Bernd Schmidt for various code generation improvements and major 30440 work in the reload pass as well a serving as release manager for 30441 GCC 2.95.3. 30442 30443 * Peter Schmid for constant testing of libstdc++--especially 30444 application testing, going above and beyond what was requested for 30445 the release criteria--and libstdc++ header file tweaks. 30446 30447 * Jason Schroeder for jcf-dump patches. 30448 30449 * Andreas Schwab for his work on the m68k port. 30450 30451 * Lars Segerlund for work on GNU Fortran. 30452 30453 * Joel Sherrill for his direction via the steering committee, RTEMS 30454 contributions and RTEMS testing. 30455 30456 * Nathan Sidwell for many C++ fixes/improvements. 30457 30458 * Jeffrey Siegal for helping RMS with the original design of GCC, 30459 some code which handles the parse tree and RTL data structures, 30460 constant folding and help with the original VAX & m68k ports. 30461 30462 * Kenny Simpson for prompting libstdc++ fixes due to defect reports 30463 from the LWG (thereby keeping GCC in line with updates from the 30464 ISO). 30465 30466 * Franz Sirl for his ongoing work with making the PPC port stable 30467 for GNU/Linux. 30468 30469 * Andrey Slepuhin for assorted AIX hacking. 30470 30471 * Christopher Smith did the port for Convex machines. 30472 30473 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports. 30474 30475 * Randy Smith finished the Sun FPA support. 30476 30477 * Scott Snyder for queue, iterator, istream, and string fixes and 30478 libstdc++ testsuite entries. Also for providing the patch to G77 30479 to add rudimentary support for `INTEGER*1', `INTEGER*2', and 30480 `LOGICAL*1'. 30481 30482 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique. 30483 30484 * Richard Stallman, for writing the original GCC and launching the 30485 GNU project. 30486 30487 * Jan Stein of the Chalmers Computer Society provided support for 30488 Genix, as well as part of the 32000 machine description. 30489 30490 * Nigel Stephens for various mips16 related fixes/improvements. 30491 30492 * Jonathan Stone wrote the machine description for the Pyramid 30493 computer. 30494 30495 * Graham Stott for various infrastructure improvements. 30496 30497 * John Stracke for his Java HTTP protocol fixes. 30498 30499 * Mike Stump for his Elxsi port, G++ contributions over the years 30500 and more recently his vxworks contributions 30501 30502 * Jeff Sturm for Java porting help, bug fixes, and encouragement. 30503 30504 * Shigeya Suzuki for this fixes for the bsdi platforms. 30505 30506 * Ian Lance Taylor for his mips16 work, general configury hacking, 30507 fixincludes, etc. 30508 30509 * Holger Teutsch provided the support for the Clipper CPU. 30510 30511 * Gary Thomas for his ongoing work to make the PPC work for 30512 GNU/Linux. 30513 30514 * Philipp Thomas for random bug fixes throughout the compiler 30515 30516 * Jason Thorpe for thread support in libstdc++ on NetBSD. 30517 30518 * Kresten Krab Thorup wrote the run time support for the Objective-C 30519 language and the fantastic Java bytecode interpreter. 30520 30521 * Michael Tiemann for random bug fixes, the first instruction 30522 scheduler, initial C++ support, function integration, NS32k, SPARC 30523 and M88k machine description work, delay slot scheduling. 30524 30525 * Andreas Tobler for his work porting libgcj to Darwin. 30526 30527 * Teemu Torma for thread safe exception handling support. 30528 30529 * Leonard Tower wrote parts of the parser, RTL generator, and RTL 30530 definitions, and of the VAX machine description. 30531 30532 * Tom Tromey for internationalization support and for his many Java 30533 contributions and libgcj maintainership. 30534 30535 * Lassi Tuura for improvements to config.guess to determine HP 30536 processor types. 30537 30538 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes. 30539 30540 * Andy Vaught for the design and initial implementation of the GNU 30541 Fortran front end. 30542 30543 * Brent Verner for work with the libstdc++ cshadow files and their 30544 associated configure steps. 30545 30546 * Todd Vierling for contributions for NetBSD ports. 30547 30548 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML 30549 guidance. 30550 30551 * Dean Wakerley for converting the install documentation from HTML 30552 to texinfo in time for GCC 3.0. 30553 30554 * Krister Walfridsson for random bug fixes. 30555 30556 * Feng Wang for contributions to GNU Fortran. 30557 30558 * Stephen M. Webb for time and effort on making libstdc++ shadow 30559 files work with the tricky Solaris 8+ headers, and for pushing the 30560 build-time header tree. 30561 30562 * John Wehle for various improvements for the x86 code generator, 30563 related infrastructure improvements to help x86 code generation, 30564 value range propagation and other work, WE32k port. 30565 30566 * Ulrich Weigand for work on the s390 port. 30567 30568 * Zack Weinberg for major work on cpplib and various other bug fixes. 30569 30570 * Matt Welsh for help with Linux Threads support in GCJ. 30571 30572 * Urban Widmark for help fixing java.io. 30573 30574 * Mark Wielaard for new Java library code and his work integrating 30575 with Classpath. 30576 30577 * Dale Wiles helped port GCC to the Tahoe. 30578 30579 * Bob Wilson from Tensilica, Inc. for the Xtensa port. 30580 30581 * Jim Wilson for his direction via the steering committee, tackling 30582 hard problems in various places that nobody else wanted to work 30583 on, strength reduction and other loop optimizations. 30584 30585 * Paul Woegerer and Tal Agmon for the CRX port. 30586 30587 * Carlo Wood for various fixes. 30588 30589 * Tom Wood for work on the m88k port. 30590 30591 * Canqun Yang for work on GNU Fortran. 30592 30593 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine 30594 description for the Tron architecture (specifically, the Gmicro). 30595 30596 * Kevin Zachmann helped port GCC to the Tahoe. 30597 30598 * Ayal Zaks for Swing Modulo Scheduling (SMS). 30599 30600 * Xiaoqiang Zhang for work on GNU Fortran. 30601 30602 * Gilles Zunino for help porting Java to Irix. 30603 30604 30605 The following people are recognized for their contributions to GNAT, 30606 the Ada front end of GCC: 30607 * Bernard Banner 30608 30609 * Romain Berrendonner 30610 30611 * Geert Bosch 30612 30613 * Emmanuel Briot 30614 30615 * Joel Brobecker 30616 30617 * Ben Brosgol 30618 30619 * Vincent Celier 30620 30621 * Arnaud Charlet 30622 30623 * Chien Chieng 30624 30625 * Cyrille Comar 30626 30627 * Cyrille Crozes 30628 30629 * Robert Dewar 30630 30631 * Gary Dismukes 30632 30633 * Robert Duff 30634 30635 * Ed Falis 30636 30637 * Ramon Fernandez 30638 30639 * Sam Figueroa 30640 30641 * Vasiliy Fofanov 30642 30643 * Michael Friess 30644 30645 * Franco Gasperoni 30646 30647 * Ted Giering 30648 30649 * Matthew Gingell 30650 30651 * Laurent Guerby 30652 30653 * Jerome Guitton 30654 30655 * Olivier Hainque 30656 30657 * Jerome Hugues 30658 30659 * Hristian Kirtchev 30660 30661 * Jerome Lambourg 30662 30663 * Bruno Leclerc 30664 30665 * Albert Lee 30666 30667 * Sean McNeil 30668 30669 * Javier Miranda 30670 30671 * Laurent Nana 30672 30673 * Pascal Obry 30674 30675 * Dong-Ik Oh 30676 30677 * Laurent Pautet 30678 30679 * Brett Porter 30680 30681 * Thomas Quinot 30682 30683 * Nicolas Roche 30684 30685 * Pat Rogers 30686 30687 * Jose Ruiz 30688 30689 * Douglas Rupp 30690 30691 * Sergey Rybin 30692 30693 * Gail Schenker 30694 30695 * Ed Schonberg 30696 30697 * Nicolas Setton 30698 30699 * Samuel Tardieu 30700 30701 30702 The following people are recognized for their contributions of new 30703 features, bug reports, testing and integration of classpath/libgcj for 30704 GCC version 4.1: 30705 * Lillian Angel for `JTree' implementation and lots Free Swing 30706 additions and bugfixes. 30707 30708 * Wolfgang Baer for `GapContent' bugfixes. 30709 30710 * Anthony Balkissoon for `JList', Free Swing 1.5 updates and mouse 30711 event fixes, lots of Free Swing work including `JTable' editing. 30712 30713 * Stuart Ballard for RMI constant fixes. 30714 30715 * Goffredo Baroncelli for `HTTPURLConnection' fixes. 30716 30717 * Gary Benson for `MessageFormat' fixes. 30718 30719 * Daniel Bonniot for `Serialization' fixes. 30720 30721 * Chris Burdess for lots of gnu.xml and http protocol fixes, `StAX' 30722 and `DOM xml:id' support. 30723 30724 * Ka-Hing Cheung for `TreePath' and `TreeSelection' fixes. 30725 30726 * Archie Cobbs for build fixes, VM interface updates, 30727 `URLClassLoader' updates. 30728 30729 * Kelley Cook for build fixes. 30730 30731 * Martin Cordova for Suggestions for better `SocketTimeoutException'. 30732 30733 * David Daney for `BitSet' bugfixes, `HttpURLConnection' rewrite and 30734 improvements. 30735 30736 * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo 30737 2D support. Lots of imageio framework additions, lots of AWT and 30738 Free Swing bugfixes. 30739 30740 * Jeroen Frijters for `ClassLoader' and nio cleanups, serialization 30741 fixes, better `Proxy' support, bugfixes and IKVM integration. 30742 30743 * Santiago Gala for `AccessControlContext' fixes. 30744 30745 * Nicolas Geoffray for `VMClassLoader' and `AccessController' 30746 improvements. 30747 30748 * David Gilbert for `basic' and `metal' icon and plaf support and 30749 lots of documenting, Lots of Free Swing and metal theme additions. 30750 `MetalIconFactory' implementation. 30751 30752 * Anthony Green for `MIDI' framework, `ALSA' and `DSSI' providers. 30753 30754 * Andrew Haley for `Serialization' and `URLClassLoader' fixes, gcj 30755 build speedups. 30756 30757 * Kim Ho for `JFileChooser' implementation. 30758 30759 * Andrew John Hughes for `Locale' and net fixes, URI RFC2986 30760 updates, `Serialization' fixes, `Properties' XML support and 30761 generic branch work, VMIntegration guide update. 30762 30763 * Bastiaan Huisman for `TimeZone' bugfixing. 30764 30765 * Andreas Jaeger for mprec updates. 30766 30767 * Paul Jenner for better `-Werror' support. 30768 30769 * Ito Kazumitsu for `NetworkInterface' implementation and updates. 30770 30771 * Roman Kennke for `BoxLayout', `GrayFilter' and `SplitPane', plus 30772 bugfixes all over. Lots of Free Swing work including styled text. 30773 30774 * Simon Kitching for `String' cleanups and optimization suggestions. 30775 30776 * Michael Koch for configuration fixes, `Locale' updates, bug and 30777 build fixes. 30778 30779 * Guilhem Lavaux for configuration, thread and channel fixes and 30780 Kaffe integration. JCL native `Pointer' updates. Logger bugfixes. 30781 30782 * David Lichteblau for JCL support library global/local reference 30783 cleanups. 30784 30785 * Aaron Luchko for JDWP updates and documentation fixes. 30786 30787 * Ziga Mahkovec for `Graphics2D' upgraded to Cairo 0.5 and new regex 30788 features. 30789 30790 * Sven de Marothy for BMP imageio support, CSS and `TextLayout' 30791 fixes. `GtkImage' rewrite, 2D, awt, free swing and date/time fixes 30792 and implementing the Qt4 peers. 30793 30794 * Casey Marshall for crypto algorithm fixes, `FileChannel' lock, 30795 `SystemLogger' and `FileHandler' rotate implementations, NIO 30796 `FileChannel.map' support, security and policy updates. 30797 30798 * Bryce McKinlay for RMI work. 30799 30800 * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus 30801 testing and documenting. 30802 30803 * Kalle Olavi Niemitalo for build fixes. 30804 30805 * Rainer Orth for build fixes. 30806 30807 * Andrew Overholt for `File' locking fixes. 30808 30809 * Ingo Proetel for `Image', `Logger' and `URLClassLoader' updates. 30810 30811 * Olga Rodimina for `MenuSelectionManager' implementation. 30812 30813 * Jan Roehrich for `BasicTreeUI' and `JTree' fixes. 30814 30815 * Julian Scheid for documentation updates and gjdoc support. 30816 30817 * Christian Schlichtherle for zip fixes and cleanups. 30818 30819 * Robert Schuster for documentation updates and beans fixes, 30820 `TreeNode' enumerations and `ActionCommand' and various fixes, XML 30821 and URL, AWT and Free Swing bugfixes. 30822 30823 * Keith Seitz for lots of JDWP work. 30824 30825 * Christian Thalinger for 64-bit cleanups, Configuration and VM 30826 interface fixes and `CACAO' integration, `fdlibm' updates. 30827 30828 * Gael Thomas for `VMClassLoader' boot packages support suggestions. 30829 30830 * Andreas Tobler for Darwin and Solaris testing and fixing, `Qt4' 30831 support for Darwin/OS X, `Graphics2D' support, `gtk+' updates. 30832 30833 * Dalibor Topic for better `DEBUG' support, build cleanups and Kaffe 30834 integration. `Qt4' build infrastructure, `SHA1PRNG' and 30835 `GdkPixbugDecoder' updates. 30836 30837 * Tom Tromey for Eclipse integration, generics work, lots of bugfixes 30838 and gcj integration including coordinating The Big Merge. 30839 30840 * Mark Wielaard for bugfixes, packaging and release management, 30841 `Clipboard' implementation, system call interrupts and network 30842 timeouts and `GdkPixpufDecoder' fixes. 30843 30844 30845 In addition to the above, all of which also contributed time and 30846 energy in testing GCC, we would like to thank the following for their 30847 contributions to testing: 30848 30849 * Michael Abd-El-Malek 30850 30851 * Thomas Arend 30852 30853 * Bonzo Armstrong 30854 30855 * Steven Ashe 30856 30857 * Chris Baldwin 30858 30859 * David Billinghurst 30860 30861 * Jim Blandy 30862 30863 * Stephane Bortzmeyer 30864 30865 * Horst von Brand 30866 30867 * Frank Braun 30868 30869 * Rodney Brown 30870 30871 * Sidney Cadot 30872 30873 * Bradford Castalia 30874 30875 * Jonathan Corbet 30876 30877 * Ralph Doncaster 30878 30879 * Richard Emberson 30880 30881 * Levente Farkas 30882 30883 * Graham Fawcett 30884 30885 * Mark Fernyhough 30886 30887 * Robert A. French 30888 30889 * Jo"rgen Freyh 30890 30891 * Mark K. Gardner 30892 30893 * Charles-Antoine Gauthier 30894 30895 * Yung Shing Gene 30896 30897 * David Gilbert 30898 30899 * Simon Gornall 30900 30901 * Fred Gray 30902 30903 * John Griffin 30904 30905 * Patrik Hagglund 30906 30907 * Phil Hargett 30908 30909 * Amancio Hasty 30910 30911 * Takafumi Hayashi 30912 30913 * Bryan W. Headley 30914 30915 * Kevin B. Hendricks 30916 30917 * Joep Jansen 30918 30919 * Christian Joensson 30920 30921 * Michel Kern 30922 30923 * David Kidd 30924 30925 * Tobias Kuipers 30926 30927 * Anand Krishnaswamy 30928 30929 * A. O. V. Le Blanc 30930 30931 * llewelly 30932 30933 * Damon Love 30934 30935 * Brad Lucier 30936 30937 * Matthias Klose 30938 30939 * Martin Knoblauch 30940 30941 * Rick Lutowski 30942 30943 * Jesse Macnish 30944 30945 * Stefan Morrell 30946 30947 * Anon A. Mous 30948 30949 * Matthias Mueller 30950 30951 * Pekka Nikander 30952 30953 * Rick Niles 30954 30955 * Jon Olson 30956 30957 * Magnus Persson 30958 30959 * Chris Pollard 30960 30961 * Richard Polton 30962 30963 * Derk Reefman 30964 30965 * David Rees 30966 30967 * Paul Reilly 30968 30969 * Tom Reilly 30970 30971 * Torsten Rueger 30972 30973 * Danny Sadinoff 30974 30975 * Marc Schifer 30976 30977 * Erik Schnetter 30978 30979 * Wayne K. Schroll 30980 30981 * David Schuler 30982 30983 * Vin Shelton 30984 30985 * Tim Souder 30986 30987 * Adam Sulmicki 30988 30989 * Bill Thorson 30990 30991 * George Talbot 30992 30993 * Pedro A. M. Vazquez 30994 30995 * Gregory Warnes 30996 30997 * Ian Watson 30998 30999 * David E. Young 31000 31001 * And many others 31002 31003 And finally we'd like to thank everyone who uses the compiler, submits 31004 bug reports and generally reminds us why we're doing this work in the 31005 first place. 31006 31007 31008 File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top 31009 31010 Option Index 31011 ************ 31012 31013 GCC's command line options are indexed here without any initial `-' or 31014 `--'. Where an option has both positive and negative forms (such as 31015 `-fOPTION' and `-fno-OPTION'), relevant entries in the manual are 31016 indexed under the most appropriate form; it may sometimes be useful to 31017 look up both forms. 31018 31019 [index] 31020 * Menu: 31021 31022 * msoft-float: Soft float library routines. 31023 (line 6) 31024 31025 31026 File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top 31027 31028 Concept Index 31029 ************* 31030 31031 [index] 31032 * Menu: 31033 31034 * ! in constraint: Multi-Alternative. (line 47) 31035 * # in constraint: Modifiers. (line 67) 31036 * # in template: Output Template. (line 66) 31037 * #pragma: Misc. (line 370) 31038 * % in constraint: Modifiers. (line 45) 31039 * % in GTY option: GTY Options. (line 18) 31040 * % in template: Output Template. (line 6) 31041 * & in constraint: Modifiers. (line 25) 31042 * (: Sections. (line 160) 31043 * (nil): RTL Objects. (line 73) 31044 * *: Host Common. (line 17) 31045 * * in constraint: Modifiers. (line 72) 31046 * * in template: Output Statement. (line 29) 31047 * *TARGET_GET_PCH_VALIDITY: PCH Target. (line 7) 31048 * + in constraint: Modifiers. (line 12) 31049 * -fsection-anchors <1>: Special Accessors. (line 106) 31050 * -fsection-anchors: Anchored Addresses. (line 6) 31051 * /c in RTL dump: Flags. (line 219) 31052 * /f in RTL dump: Flags. (line 224) 31053 * /i in RTL dump: Flags. (line 275) 31054 * /j in RTL dump: Flags. (line 288) 31055 * /s in RTL dump: Flags. (line 239) 31056 * /u in RTL dump: Flags. (line 298) 31057 * /v in RTL dump: Flags. (line 330) 31058 * 0 in constraint: Simple Constraints. (line 118) 31059 * < in constraint: Simple Constraints. (line 46) 31060 * = in constraint: Modifiers. (line 8) 31061 * > in constraint: Simple Constraints. (line 50) 31062 * ? in constraint: Multi-Alternative. (line 41) 31063 * \: Output Template. (line 46) 31064 * __absvdi2: Integer library routines. 31065 (line 107) 31066 * __absvsi2: Integer library routines. 31067 (line 106) 31068 * __adddd3: Decimal float library routines. 31069 (line 15) 31070 * __adddf3: Soft float library routines. 31071 (line 23) 31072 * __addsd3: Decimal float library routines. 31073 (line 14) 31074 * __addsf3: Soft float library routines. 31075 (line 22) 31076 * __addtd3: Decimal float library routines. 31077 (line 17) 31078 * __addtf3: Soft float library routines. 31079 (line 25) 31080 * __addvdi3: Integer library routines. 31081 (line 111) 31082 * __addvsi3: Integer library routines. 31083 (line 110) 31084 * __addxf3: Soft float library routines. 31085 (line 27) 31086 * __ashldi3: Integer library routines. 31087 (line 14) 31088 * __ashlsi3: Integer library routines. 31089 (line 13) 31090 * __ashlti3: Integer library routines. 31091 (line 15) 31092 * __ashrdi3: Integer library routines. 31093 (line 19) 31094 * __ashrsi3: Integer library routines. 31095 (line 18) 31096 * __ashrti3: Integer library routines. 31097 (line 20) 31098 * __builtin_args_info: Varargs. (line 42) 31099 * __builtin_classify_type: Varargs. (line 76) 31100 * __builtin_next_arg: Varargs. (line 66) 31101 * __builtin_saveregs: Varargs. (line 24) 31102 * __clear_cache: Miscellaneous routines. 31103 (line 10) 31104 * __clzdi2: Integer library routines. 31105 (line 131) 31106 * __clzsi2: Integer library routines. 31107 (line 130) 31108 * __clzti2: Integer library routines. 31109 (line 132) 31110 * __cmpdf2: Soft float library routines. 31111 (line 164) 31112 * __cmpdi2: Integer library routines. 31113 (line 87) 31114 * __cmpsf2: Soft float library routines. 31115 (line 163) 31116 * __cmptf2: Soft float library routines. 31117 (line 165) 31118 * __cmpti2: Integer library routines. 31119 (line 88) 31120 * __CTOR_LIST__: Initialization. (line 25) 31121 * __ctzdi2: Integer library routines. 31122 (line 138) 31123 * __ctzsi2: Integer library routines. 31124 (line 137) 31125 * __ctzti2: Integer library routines. 31126 (line 139) 31127 * __divdc3: Soft float library routines. 31128 (line 252) 31129 * __divdd3: Decimal float library routines. 31130 (line 34) 31131 * __divdf3: Soft float library routines. 31132 (line 48) 31133 * __divdi3: Integer library routines. 31134 (line 25) 31135 * __divsc3: Soft float library routines. 31136 (line 250) 31137 * __divsd3: Decimal float library routines. 31138 (line 33) 31139 * __divsf3: Soft float library routines. 31140 (line 47) 31141 * __divsi3: Integer library routines. 31142 (line 24) 31143 * __divtc3: Soft float library routines. 31144 (line 254) 31145 * __divtd3: Decimal float library routines. 31146 (line 36) 31147 * __divtf3: Soft float library routines. 31148 (line 50) 31149 * __divti3: Integer library routines. 31150 (line 26) 31151 * __divxc3: Soft float library routines. 31152 (line 256) 31153 * __divxf3: Soft float library routines. 31154 (line 52) 31155 * __DTOR_LIST__: Initialization. (line 25) 31156 * __eqdd2: Decimal float library routines. 31157 (line 148) 31158 * __eqdf2: Soft float library routines. 31159 (line 194) 31160 * __eqsd2: Decimal float library routines. 31161 (line 147) 31162 * __eqsf2: Soft float library routines. 31163 (line 193) 31164 * __eqtd2: Decimal float library routines. 31165 (line 149) 31166 * __eqtf2: Soft float library routines. 31167 (line 195) 31168 * __extendddtd2: Decimal float library routines. 31169 (line 50) 31170 * __extendddxf: Decimal float library routines. 31171 (line 56) 31172 * __extenddfdd: Decimal float library routines. 31173 (line 55) 31174 * __extenddftd: Decimal float library routines. 31175 (line 58) 31176 * __extenddftf2: Soft float library routines. 31177 (line 68) 31178 * __extenddfxf2: Soft float library routines. 31179 (line 69) 31180 * __extendsddd2: Decimal float library routines. 31181 (line 48) 31182 * __extendsddf: Decimal float library routines. 31183 (line 52) 31184 * __extendsdtd2: Decimal float library routines. 31185 (line 49) 31186 * __extendsdxf: Decimal float library routines. 31187 (line 53) 31188 * __extendsfdd: Decimal float library routines. 31189 (line 54) 31190 * __extendsfdf2: Soft float library routines. 31191 (line 65) 31192 * __extendsfsd: Decimal float library routines. 31193 (line 51) 31194 * __extendsftd: Decimal float library routines. 31195 (line 57) 31196 * __extendsftf2: Soft float library routines. 31197 (line 66) 31198 * __extendsfxf2: Soft float library routines. 31199 (line 67) 31200 * __extendxftd: Decimal float library routines. 31201 (line 59) 31202 * __ffsdi2: Integer library routines. 31203 (line 144) 31204 * __ffsti2: Integer library routines. 31205 (line 145) 31206 * __fixdddi: Decimal float library routines. 31207 (line 83) 31208 * __fixddsi: Decimal float library routines. 31209 (line 78) 31210 * __fixdfdi: Soft float library routines. 31211 (line 88) 31212 * __fixdfsi: Soft float library routines. 31213 (line 81) 31214 * __fixdfti: Soft float library routines. 31215 (line 94) 31216 * __fixsddi: Decimal float library routines. 31217 (line 82) 31218 * __fixsdsi: Decimal float library routines. 31219 (line 77) 31220 * __fixsfdi: Soft float library routines. 31221 (line 87) 31222 * __fixsfsi: Soft float library routines. 31223 (line 80) 31224 * __fixsfti: Soft float library routines. 31225 (line 93) 31226 * __fixtddi: Decimal float library routines. 31227 (line 84) 31228 * __fixtdsi: Decimal float library routines. 31229 (line 79) 31230 * __fixtfdi: Soft float library routines. 31231 (line 89) 31232 * __fixtfsi: Soft float library routines. 31233 (line 82) 31234 * __fixtfti: Soft float library routines. 31235 (line 95) 31236 * __fixunsdddi: Decimal float library routines. 31237 (line 94) 31238 * __fixunsddsi: Decimal float library routines. 31239 (line 88) 31240 * __fixunsdfdi: Soft float library routines. 31241 (line 108) 31242 * __fixunsdfsi: Soft float library routines. 31243 (line 101) 31244 * __fixunsdfti: Soft float library routines. 31245 (line 115) 31246 * __fixunssddi: Decimal float library routines. 31247 (line 93) 31248 * __fixunssdsi: Decimal float library routines. 31249 (line 87) 31250 * __fixunssfdi: Soft float library routines. 31251 (line 107) 31252 * __fixunssfsi: Soft float library routines. 31253 (line 100) 31254 * __fixunssfti: Soft float library routines. 31255 (line 114) 31256 * __fixunstddi: Decimal float library routines. 31257 (line 95) 31258 * __fixunstdsi: Decimal float library routines. 31259 (line 89) 31260 * __fixunstfdi: Soft float library routines. 31261 (line 109) 31262 * __fixunstfsi: Soft float library routines. 31263 (line 102) 31264 * __fixunstfti: Soft float library routines. 31265 (line 116) 31266 * __fixunsxfdi: Soft float library routines. 31267 (line 110) 31268 * __fixunsxfsi: Soft float library routines. 31269 (line 103) 31270 * __fixunsxfti: Soft float library routines. 31271 (line 117) 31272 * __fixxfdi: Soft float library routines. 31273 (line 90) 31274 * __fixxfsi: Soft float library routines. 31275 (line 83) 31276 * __fixxfti: Soft float library routines. 31277 (line 96) 31278 * __floatdidd: Decimal float library routines. 31279 (line 106) 31280 * __floatdidf: Soft float library routines. 31281 (line 128) 31282 * __floatdisd: Decimal float library routines. 31283 (line 105) 31284 * __floatdisf: Soft float library routines. 31285 (line 127) 31286 * __floatditd: Decimal float library routines. 31287 (line 107) 31288 * __floatditf: Soft float library routines. 31289 (line 129) 31290 * __floatdixf: Soft float library routines. 31291 (line 130) 31292 * __floatsidd: Decimal float library routines. 31293 (line 100) 31294 * __floatsidf: Soft float library routines. 31295 (line 122) 31296 * __floatsisd: Decimal float library routines. 31297 (line 99) 31298 * __floatsisf: Soft float library routines. 31299 (line 121) 31300 * __floatsitd: Decimal float library routines. 31301 (line 101) 31302 * __floatsitf: Soft float library routines. 31303 (line 123) 31304 * __floatsixf: Soft float library routines. 31305 (line 124) 31306 * __floattidf: Soft float library routines. 31307 (line 134) 31308 * __floattisf: Soft float library routines. 31309 (line 133) 31310 * __floattitf: Soft float library routines. 31311 (line 135) 31312 * __floattixf: Soft float library routines. 31313 (line 136) 31314 * __floatundidf: Soft float library routines. 31315 (line 146) 31316 * __floatundisf: Soft float library routines. 31317 (line 145) 31318 * __floatunditf: Soft float library routines. 31319 (line 147) 31320 * __floatundixf: Soft float library routines. 31321 (line 148) 31322 * __floatunsdidd: Decimal float library routines. 31323 (line 118) 31324 * __floatunsdisd: Decimal float library routines. 31325 (line 117) 31326 * __floatunsditd: Decimal float library routines. 31327 (line 119) 31328 * __floatunsidf: Soft float library routines. 31329 (line 140) 31330 * __floatunsisf: Soft float library routines. 31331 (line 139) 31332 * __floatunsitf: Soft float library routines. 31333 (line 141) 31334 * __floatunsixf: Soft float library routines. 31335 (line 142) 31336 * __floatunssidd: Decimal float library routines. 31337 (line 112) 31338 * __floatunssisd: Decimal float library routines. 31339 (line 111) 31340 * __floatunssitd: Decimal float library routines. 31341 (line 113) 31342 * __floatuntidf: Soft float library routines. 31343 (line 152) 31344 * __floatuntisf: Soft float library routines. 31345 (line 151) 31346 * __floatuntitf: Soft float library routines. 31347 (line 153) 31348 * __floatuntixf: Soft float library routines. 31349 (line 154) 31350 * __gedd2: Decimal float library routines. 31351 (line 160) 31352 * __gedf2: Soft float library routines. 31353 (line 206) 31354 * __gesd2: Decimal float library routines. 31355 (line 159) 31356 * __gesf2: Soft float library routines. 31357 (line 205) 31358 * __getd2: Decimal float library routines. 31359 (line 161) 31360 * __getf2: Soft float library routines. 31361 (line 207) 31362 * __gtdd2: Decimal float library routines. 31363 (line 178) 31364 * __gtdf2: Soft float library routines. 31365 (line 224) 31366 * __gtsd2: Decimal float library routines. 31367 (line 177) 31368 * __gtsf2: Soft float library routines. 31369 (line 223) 31370 * __gttd2: Decimal float library routines. 31371 (line 179) 31372 * __gttf2: Soft float library routines. 31373 (line 225) 31374 * __ledd2: Decimal float library routines. 31375 (line 172) 31376 * __ledf2: Soft float library routines. 31377 (line 218) 31378 * __lesd2: Decimal float library routines. 31379 (line 171) 31380 * __lesf2: Soft float library routines. 31381 (line 217) 31382 * __letd2: Decimal float library routines. 31383 (line 173) 31384 * __letf2: Soft float library routines. 31385 (line 219) 31386 * __lshrdi3: Integer library routines. 31387 (line 31) 31388 * __lshrsi3: Integer library routines. 31389 (line 30) 31390 * __lshrti3: Integer library routines. 31391 (line 32) 31392 * __ltdd2: Decimal float library routines. 31393 (line 166) 31394 * __ltdf2: Soft float library routines. 31395 (line 212) 31396 * __ltsd2: Decimal float library routines. 31397 (line 165) 31398 * __ltsf2: Soft float library routines. 31399 (line 211) 31400 * __lttd2: Decimal float library routines. 31401 (line 167) 31402 * __lttf2: Soft float library routines. 31403 (line 213) 31404 * __main: Collect2. (line 15) 31405 * __moddi3: Integer library routines. 31406 (line 37) 31407 * __modsi3: Integer library routines. 31408 (line 36) 31409 * __modti3: Integer library routines. 31410 (line 38) 31411 * __muldc3: Soft float library routines. 31412 (line 241) 31413 * __muldd3: Decimal float library routines. 31414 (line 28) 31415 * __muldf3: Soft float library routines. 31416 (line 40) 31417 * __muldi3: Integer library routines. 31418 (line 43) 31419 * __mulsc3: Soft float library routines. 31420 (line 239) 31421 * __mulsd3: Decimal float library routines. 31422 (line 27) 31423 * __mulsf3: Soft float library routines. 31424 (line 39) 31425 * __mulsi3: Integer library routines. 31426 (line 42) 31427 * __multc3: Soft float library routines. 31428 (line 243) 31429 * __multd3: Decimal float library routines. 31430 (line 30) 31431 * __multf3: Soft float library routines. 31432 (line 42) 31433 * __multi3: Integer library routines. 31434 (line 44) 31435 * __mulvdi3: Integer library routines. 31436 (line 115) 31437 * __mulvsi3: Integer library routines. 31438 (line 114) 31439 * __mulxc3: Soft float library routines. 31440 (line 245) 31441 * __mulxf3: Soft float library routines. 31442 (line 44) 31443 * __nedd2: Decimal float library routines. 31444 (line 154) 31445 * __nedf2: Soft float library routines. 31446 (line 200) 31447 * __negdd2: Decimal float library routines. 31448 (line 40) 31449 * __negdf2: Soft float library routines. 31450 (line 56) 31451 * __negdi2: Integer library routines. 31452 (line 47) 31453 * __negsd2: Decimal float library routines. 31454 (line 39) 31455 * __negsf2: Soft float library routines. 31456 (line 55) 31457 * __negtd2: Decimal float library routines. 31458 (line 41) 31459 * __negtf2: Soft float library routines. 31460 (line 57) 31461 * __negti2: Integer library routines. 31462 (line 48) 31463 * __negvdi2: Integer library routines. 31464 (line 119) 31465 * __negvsi2: Integer library routines. 31466 (line 118) 31467 * __negxf2: Soft float library routines. 31468 (line 58) 31469 * __nesd2: Decimal float library routines. 31470 (line 153) 31471 * __nesf2: Soft float library routines. 31472 (line 199) 31473 * __netd2: Decimal float library routines. 31474 (line 155) 31475 * __netf2: Soft float library routines. 31476 (line 201) 31477 * __paritydi2: Integer library routines. 31478 (line 151) 31479 * __paritysi2: Integer library routines. 31480 (line 150) 31481 * __parityti2: Integer library routines. 31482 (line 152) 31483 * __popcountdi2: Integer library routines. 31484 (line 157) 31485 * __popcountsi2: Integer library routines. 31486 (line 156) 31487 * __popcountti2: Integer library routines. 31488 (line 158) 31489 * __powidf2: Soft float library routines. 31490 (line 233) 31491 * __powisf2: Soft float library routines. 31492 (line 232) 31493 * __powitf2: Soft float library routines. 31494 (line 234) 31495 * __powixf2: Soft float library routines. 31496 (line 235) 31497 * __subdd3: Decimal float library routines. 31498 (line 21) 31499 * __subdf3: Soft float library routines. 31500 (line 31) 31501 * __subsd3: Decimal float library routines. 31502 (line 20) 31503 * __subsf3: Soft float library routines. 31504 (line 30) 31505 * __subtd3: Decimal float library routines. 31506 (line 23) 31507 * __subtf3: Soft float library routines. 31508 (line 33) 31509 * __subvdi3: Integer library routines. 31510 (line 123) 31511 * __subvsi3: Integer library routines. 31512 (line 122) 31513 * __subxf3: Soft float library routines. 31514 (line 35) 31515 * __truncdddf: Decimal float library routines. 31516 (line 69) 31517 * __truncddsd2: Decimal float library routines. 31518 (line 62) 31519 * __truncddsf: Decimal float library routines. 31520 (line 68) 31521 * __truncdfsd: Decimal float library routines. 31522 (line 66) 31523 * __truncdfsf2: Soft float library routines. 31524 (line 76) 31525 * __truncsdsf: Decimal float library routines. 31526 (line 65) 31527 * __trunctddd2: Decimal float library routines. 31528 (line 64) 31529 * __trunctddf: Decimal float library routines. 31530 (line 72) 31531 * __trunctdsd2: Decimal float library routines. 31532 (line 63) 31533 * __trunctdsf: Decimal float library routines. 31534 (line 71) 31535 * __trunctdxf: Decimal float library routines. 31536 (line 73) 31537 * __trunctfdf2: Soft float library routines. 31538 (line 73) 31539 * __trunctfsf2: Soft float library routines. 31540 (line 75) 31541 * __truncxfdd: Decimal float library routines. 31542 (line 70) 31543 * __truncxfdf2: Soft float library routines. 31544 (line 72) 31545 * __truncxfsd: Decimal float library routines. 31546 (line 67) 31547 * __truncxfsf2: Soft float library routines. 31548 (line 74) 31549 * __ucmpdi2: Integer library routines. 31550 (line 93) 31551 * __ucmpti2: Integer library routines. 31552 (line 95) 31553 * __udivdi3: Integer library routines. 31554 (line 54) 31555 * __udivmoddi3: Integer library routines. 31556 (line 61) 31557 * __udivsi3: Integer library routines. 31558 (line 52) 31559 * __udivti3: Integer library routines. 31560 (line 56) 31561 * __umoddi3: Integer library routines. 31562 (line 71) 31563 * __umodsi3: Integer library routines. 31564 (line 69) 31565 * __umodti3: Integer library routines. 31566 (line 73) 31567 * __unorddd2: Decimal float library routines. 31568 (line 127) 31569 * __unorddf2: Soft float library routines. 31570 (line 173) 31571 * __unordsd2: Decimal float library routines. 31572 (line 126) 31573 * __unordsf2: Soft float library routines. 31574 (line 172) 31575 * __unordtd2: Decimal float library routines. 31576 (line 128) 31577 * __unordtf2: Soft float library routines. 31578 (line 174) 31579 * abort: Portability. (line 21) 31580 * abs: Arithmetic. (line 183) 31581 * abs and attributes: Expressions. (line 64) 31582 * ABS_EXPR: Expression trees. (line 6) 31583 * absence_set: Processor pipeline description. 31584 (line 215) 31585 * absM2 instruction pattern: Standard Names. (line 316) 31586 * absolute value: Arithmetic. (line 183) 31587 * access to operands: Accessors. (line 6) 31588 * access to special operands: Special Accessors. (line 6) 31589 * accessors: Accessors. (line 6) 31590 * ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 46) 31591 * ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 135) 31592 * ADA_LONG_TYPE_SIZE: Type Layout. (line 26) 31593 * ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 15) 31594 * addM3 instruction pattern: Standard Names. (line 188) 31595 * addMODEcc instruction pattern: Standard Names. (line 685) 31596 * addr_diff_vec: Side Effects. (line 299) 31597 * addr_diff_vec, length of: Insn Lengths. (line 26) 31598 * ADDR_EXPR: Expression trees. (line 6) 31599 * addr_vec: Side Effects. (line 294) 31600 * addr_vec, length of: Insn Lengths. (line 26) 31601 * address constraints: Simple Constraints. (line 152) 31602 * address_operand <1>: Machine-Independent Predicates. 31603 (line 63) 31604 * address_operand: Simple Constraints. (line 156) 31605 * addressing modes: Addressing Modes. (line 6) 31606 * addressof: Regs and Memory. (line 260) 31607 * ADJUST_FIELD_ALIGN: Storage Layout. (line 185) 31608 * ADJUST_INSN_LENGTH: Insn Lengths. (line 35) 31609 * AGGR_INIT_EXPR: Expression trees. (line 6) 31610 * aggregates as return values: Aggregate Return. (line 6) 31611 * alias: Alias analysis. (line 6) 31612 * ALL_COP_ADDITIONAL_REGISTER_NAMES: MIPS Coprocessors. (line 32) 31613 * ALL_REGS: Register Classes. (line 17) 31614 * allocate_stack instruction pattern: Standard Names. (line 1008) 31615 * alternate entry points: Insns. (line 138) 31616 * anchored addresses: Anchored Addresses. (line 6) 31617 * and: Arithmetic. (line 142) 31618 * and and attributes: Expressions. (line 50) 31619 * and, canonicalization of: Insn Canonicalizations. 31620 (line 54) 31621 * andM3 instruction pattern: Standard Names. (line 194) 31622 * annotations: Annotations. (line 6) 31623 * APPLY_RESULT_SIZE: Scalar Return. (line 87) 31624 * ARG_POINTER_CFA_OFFSET: Frame Layout. (line 190) 31625 * ARG_POINTER_REGNUM: Frame Registers. (line 41) 31626 * ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65) 31627 * arg_pointer_rtx: Frame Registers. (line 85) 31628 * ARGS_GROW_DOWNWARD: Frame Layout. (line 35) 31629 * argument passing: Interface. (line 36) 31630 * arguments in registers: Register Arguments. (line 6) 31631 * arguments on stack: Stack Arguments. (line 6) 31632 * arithmetic library: Soft float library routines. 31633 (line 6) 31634 * arithmetic shift: Arithmetic. (line 157) 31635 * arithmetic shift with signed saturation: Arithmetic. (line 157) 31636 * arithmetic, in RTL: Arithmetic. (line 6) 31637 * ARITHMETIC_TYPE_P: Types. (line 76) 31638 * array: Types. (line 6) 31639 * ARRAY_RANGE_REF: Expression trees. (line 6) 31640 * ARRAY_REF: Expression trees. (line 6) 31641 * ARRAY_TYPE: Types. (line 6) 31642 * AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 151) 31643 * ashift: Arithmetic. (line 157) 31644 * ashift and attributes: Expressions. (line 64) 31645 * ashiftrt: Arithmetic. (line 173) 31646 * ashiftrt and attributes: Expressions. (line 64) 31647 * ashlM3 instruction pattern: Standard Names. (line 299) 31648 * ashrM3 instruction pattern: Standard Names. (line 309) 31649 * ASM_APP_OFF: File Framework. (line 61) 31650 * ASM_APP_ON: File Framework. (line 54) 31651 * ASM_COMMENT_START: File Framework. (line 49) 31652 * ASM_DECLARE_CLASS_REFERENCE: Label Output. (line 427) 31653 * ASM_DECLARE_CONSTANT_NAME: Label Output. (line 128) 31654 * ASM_DECLARE_FUNCTION_NAME: Label Output. (line 87) 31655 * ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 101) 31656 * ASM_DECLARE_OBJECT_NAME: Label Output. (line 114) 31657 * ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 143) 31658 * ASM_DECLARE_UNRESOLVED_REFERENCE: Label Output. (line 433) 31659 * ASM_FINAL_SPEC: Driver. (line 144) 31660 * ASM_FINISH_DECLARE_OBJECT: Label Output. (line 151) 31661 * ASM_FORMAT_PRIVATE_NAME: Label Output. (line 345) 31662 * asm_fprintf: Instruction Output. (line 123) 31663 * ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 134) 31664 * ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 329) 31665 * asm_input: Side Effects. (line 281) 31666 * asm_input and /v: Flags. (line 79) 31667 * ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 82) 31668 * ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 72) 31669 * asm_noperands: Insns. (line 270) 31670 * asm_operands and /v: Flags. (line 79) 31671 * asm_operands, RTL sharing: Sharing. (line 45) 31672 * asm_operands, usage: Assembler. (line 6) 31673 * ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 9) 31674 * ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 26) 31675 * ASM_OUTPUT_ALIGN: Alignment Output. (line 79) 31676 * ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 84) 31677 * ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 64) 31678 * ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 23) 31679 * ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 31) 31680 * ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 95) 31681 * ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 87) 31682 * ASM_OUTPUT_ASCII: Data Output. (line 50) 31683 * ASM_OUTPUT_BSS: Uninitialized Data. (line 39) 31684 * ASM_OUTPUT_CASE_END: Dispatch Tables. (line 51) 31685 * ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 38) 31686 * ASM_OUTPUT_COMMON: Uninitialized Data. (line 10) 31687 * ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 317) 31688 * ASM_OUTPUT_DEF: Label Output. (line 366) 31689 * ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 374) 31690 * ASM_OUTPUT_DWARF_DELTA: SDB and DWARF. (line 42) 31691 * ASM_OUTPUT_DWARF_OFFSET: SDB and DWARF. (line 46) 31692 * ASM_OUTPUT_DWARF_PCREL: SDB and DWARF. (line 52) 31693 * ASM_OUTPUT_EXTERNAL: Label Output. (line 255) 31694 * ASM_OUTPUT_FDESC: Data Output. (line 59) 31695 * ASM_OUTPUT_IDENT: File Framework. (line 83) 31696 * ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 17) 31697 * ASM_OUTPUT_LABEL: Label Output. (line 9) 31698 * ASM_OUTPUT_LABEL_REF: Label Output. (line 290) 31699 * ASM_OUTPUT_LABELREF: Label Output. (line 276) 31700 * ASM_OUTPUT_LOCAL: Uninitialized Data. (line 74) 31701 * ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 88) 31702 * ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 41) 31703 * ASM_OUTPUT_OPCODE: Instruction Output. (line 21) 31704 * ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 109) 31705 * ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 72) 31706 * ASM_OUTPUT_REG_POP: Instruction Output. (line 178) 31707 * ASM_OUTPUT_REG_PUSH: Instruction Output. (line 173) 31708 * ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 35) 31709 * ASM_OUTPUT_SKIP: Alignment Output. (line 66) 31710 * ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 68) 31711 * ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 84) 31712 * ASM_OUTPUT_SYMBOL_REF: Label Output. (line 283) 31713 * ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 77) 31714 * ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 392) 31715 * ASM_OUTPUT_WEAKREF: Label Output. (line 194) 31716 * ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 67) 31717 * ASM_SPEC: Driver. (line 136) 31718 * ASM_STABD_OP: DBX Options. (line 36) 31719 * ASM_STABN_OP: DBX Options. (line 43) 31720 * ASM_STABS_OP: DBX Options. (line 29) 31721 * ASM_WEAKEN_DECL: Label Output. (line 186) 31722 * ASM_WEAKEN_LABEL: Label Output. (line 173) 31723 * assemble_name: Label Output. (line 8) 31724 * assemble_name_raw: Label Output. (line 16) 31725 * assembler format: File Framework. (line 6) 31726 * assembler instructions in RTL: Assembler. (line 6) 31727 * ASSEMBLER_DIALECT: Instruction Output. (line 146) 31728 * assigning attribute values to insns: Tagging Insns. (line 6) 31729 * assignment operator: Function Basics. (line 6) 31730 * asterisk in template: Output Statement. (line 29) 31731 * atan2M3 instruction pattern: Standard Names. (line 368) 31732 * attr <1>: Expressions. (line 154) 31733 * attr: Tagging Insns. (line 54) 31734 * attr_flag: Expressions. (line 119) 31735 * attribute expressions: Expressions. (line 6) 31736 * attribute specifications: Attr Example. (line 6) 31737 * attribute specifications example: Attr Example. (line 6) 31738 * attributes: Attributes. (line 6) 31739 * attributes, defining: Defining Attributes. 31740 (line 6) 31741 * attributes, target-specific: Target Attributes. (line 6) 31742 * autoincrement addressing, availability: Portability. (line 21) 31743 * autoincrement/decrement addressing: Simple Constraints. (line 28) 31744 * automata_option: Processor pipeline description. 31745 (line 296) 31746 * automaton based pipeline description: Processor pipeline description. 31747 (line 49) 31748 * automaton based scheduler: Processor pipeline description. 31749 (line 6) 31750 * AVOID_CCMODE_COPIES: Values in Registers. 31751 (line 143) 31752 * backslash: Output Template. (line 46) 31753 * barrier: Insns. (line 158) 31754 * barrier and /f: Flags. (line 106) 31755 * barrier and /i: Flags. (line 133) 31756 * barrier and /v: Flags. (line 29) 31757 * BASE_REG_CLASS: Register Classes. (line 107) 31758 * basic block: Basic Blocks. (line 6) 31759 * basic-block.h: Control Flow. (line 6) 31760 * basic_block: Basic Blocks. (line 6) 31761 * BASIC_BLOCK: Basic Blocks. (line 19) 31762 * BB_DIRTY, clear_bb_flags, update_life_info_in_dirty_blocks: Liveness information. 31763 (line 29) 31764 * BB_HEAD, BB_END: Maintaining the CFG. 31765 (line 88) 31766 * bCOND instruction pattern: Standard Names. (line 722) 31767 * BIGGEST_ALIGNMENT: Storage Layout. (line 167) 31768 * BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 178) 31769 * BImode: Machine Modes. (line 22) 31770 * BIND_EXPR: Expression trees. (line 6) 31771 * BINFO_TYPE: Classes. (line 6) 31772 * bit-fields: Bit-Fields. (line 6) 31773 * BIT_AND_EXPR: Expression trees. (line 6) 31774 * BIT_IOR_EXPR: Expression trees. (line 6) 31775 * BIT_NOT_EXPR: Expression trees. (line 6) 31776 * BIT_XOR_EXPR: Expression trees. (line 6) 31777 * BITFIELD_NBYTES_LIMITED: Storage Layout. (line 323) 31778 * BITS_BIG_ENDIAN: Storage Layout. (line 12) 31779 * BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8) 31780 * BITS_PER_UNIT: Storage Layout. (line 52) 31781 * BITS_PER_WORD: Storage Layout. (line 57) 31782 * bitwise complement: Arithmetic. (line 138) 31783 * bitwise exclusive-or: Arithmetic. (line 152) 31784 * bitwise inclusive-or: Arithmetic. (line 147) 31785 * bitwise logical-and: Arithmetic. (line 142) 31786 * BLKmode: Machine Modes. (line 110) 31787 * BLKmode, and function return values: Calls. (line 23) 31788 * block statement iterators <1>: Maintaining the CFG. 31789 (line 45) 31790 * block statement iterators: Basic Blocks. (line 68) 31791 * BLOCK_FOR_INSN, bb_for_stmt: Maintaining the CFG. 31792 (line 40) 31793 * BLOCK_REG_PADDING: Register Arguments. (line 214) 31794 * Blocks: Blocks. (line 6) 31795 * bool <1>: Sections. (line 270) 31796 * bool <2>: Exception Region Output. 31797 (line 60) 31798 * bool: Sections. (line 283) 31799 * BOOL_TYPE_SIZE: Type Layout. (line 44) 31800 * BOOLEAN_TYPE: Types. (line 6) 31801 * branch prediction: Profile information. 31802 (line 24) 31803 * BRANCH_COST: Costs. (line 52) 31804 * break_out_memory_refs: Addressing Modes. (line 118) 31805 * BREAK_STMT: Function Bodies. (line 6) 31806 * bsi_commit_edge_inserts: Maintaining the CFG. 31807 (line 118) 31808 * bsi_end_p: Maintaining the CFG. 31809 (line 60) 31810 * bsi_insert_after: Maintaining the CFG. 31811 (line 72) 31812 * bsi_insert_before: Maintaining the CFG. 31813 (line 78) 31814 * bsi_insert_on_edge: Maintaining the CFG. 31815 (line 118) 31816 * bsi_last: Maintaining the CFG. 31817 (line 56) 31818 * bsi_next: Maintaining the CFG. 31819 (line 64) 31820 * bsi_prev: Maintaining the CFG. 31821 (line 68) 31822 * bsi_remove: Maintaining the CFG. 31823 (line 84) 31824 * bsi_start: Maintaining the CFG. 31825 (line 52) 31826 * BSS_SECTION_ASM_OP: Sections. (line 68) 31827 * btruncM2 instruction pattern: Standard Names. (line 386) 31828 * builtin_longjmp instruction pattern: Standard Names. (line 1094) 31829 * builtin_setjmp_receiver instruction pattern: Standard Names. 31830 (line 1084) 31831 * builtin_setjmp_setup instruction pattern: Standard Names. (line 1073) 31832 * byte_mode: Machine Modes. (line 239) 31833 * BYTES_BIG_ENDIAN: Storage Layout. (line 24) 31834 * BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 136) 31835 * C statements for assembler output: Output Statement. (line 6) 31836 * C/C++ Internal Representation: Trees. (line 6) 31837 * C4X_FLOAT_FORMAT: Storage Layout. (line 407) 31838 * C99 math functions, implicit usage: Library Calls. (line 76) 31839 * C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 100) 31840 * c_register_pragma: Misc. (line 393) 31841 * c_register_pragma_with_expansion: Misc. (line 395) 31842 * call <1>: Side Effects. (line 86) 31843 * call: Flags. (line 219) 31844 * call instruction pattern: Standard Names. (line 755) 31845 * call usage: Calls. (line 10) 31846 * call, in mem: Flags. (line 84) 31847 * call-clobbered register: Register Basics. (line 35) 31848 * call-saved register: Register Basics. (line 53) 31849 * call-used register: Register Basics. (line 53) 31850 * CALL_EXPR: Expression trees. (line 6) 31851 * call_insn: Insns. (line 93) 31852 * call_insn and /f: Flags. (line 106) 31853 * call_insn and /i: Flags. (line 133) 31854 * call_insn and /j: Flags. (line 164) 31855 * call_insn and /s: Flags. (line 151) 31856 * call_insn and /u: Flags. (line 24) 31857 * call_insn and /v: Flags. (line 29) 31858 * CALL_INSN_FUNCTION_USAGE: Insns. (line 99) 31859 * call_pop instruction pattern: Standard Names. (line 783) 31860 * CALL_POPS_ARGS: Stack Arguments. (line 127) 31861 * CALL_REALLY_USED_REGISTERS: Register Basics. (line 46) 31862 * CALL_USED_REGISTERS: Register Basics. (line 35) 31863 * call_used_regs: Register Basics. (line 59) 31864 * call_value instruction pattern: Standard Names. (line 775) 31865 * call_value_pop instruction pattern: Standard Names. (line 783) 31866 * CALLER_SAVE_PROFITABLE: Caller Saves. (line 11) 31867 * calling conventions: Stack and Calling. (line 6) 31868 * calling functions in RTL: Calls. (line 6) 31869 * CAN_DEBUG_WITHOUT_FP: Run-time Target. (line 127) 31870 * CAN_ELIMINATE: Elimination. (line 71) 31871 * can_fallthru: Basic Blocks. (line 57) 31872 * canadian: Configure Terms. (line 6) 31873 * CANNOT_CHANGE_MODE_CLASS: Register Classes. (line 481) 31874 * canonicalization of instructions: Insn Canonicalizations. 31875 (line 6) 31876 * CANONICALIZE_COMPARISON: Condition Code. (line 84) 31877 * canonicalize_funcptr_for_compare instruction pattern: Standard Names. 31878 (line 939) 31879 * CASE_USE_BIT_TESTS: Misc. (line 54) 31880 * CASE_VALUES_THRESHOLD: Misc. (line 47) 31881 * CASE_VECTOR_MODE: Misc. (line 27) 31882 * CASE_VECTOR_PC_RELATIVE: Misc. (line 40) 31883 * CASE_VECTOR_SHORTEN_MODE: Misc. (line 31) 31884 * casesi instruction pattern: Standard Names. (line 863) 31885 * cbranchMODE4 instruction pattern: Standard Names. (line 744) 31886 * cc0: Regs and Memory. (line 182) 31887 * cc0, RTL sharing: Sharing. (line 27) 31888 * cc0_rtx: Regs and Memory. (line 208) 31889 * CC1_SPEC: Driver. (line 118) 31890 * CC1PLUS_SPEC: Driver. (line 126) 31891 * cc_status: Condition Code. (line 8) 31892 * CC_STATUS_MDEP: Condition Code. (line 19) 31893 * CC_STATUS_MDEP_INIT: Condition Code. (line 25) 31894 * CCmode: Machine Modes. (line 103) 31895 * CDImode: Machine Modes. (line 129) 31896 * CEIL_DIV_EXPR: Expression trees. (line 6) 31897 * CEIL_MOD_EXPR: Expression trees. (line 6) 31898 * ceilM2 instruction pattern: Standard Names. (line 402) 31899 * CFA_FRAME_BASE_OFFSET: Frame Layout. (line 222) 31900 * CFG, Control Flow Graph: Control Flow. (line 6) 31901 * cfghooks.h: Maintaining the CFG. 31902 (line 6) 31903 * cgraph_finalize_function: Parsing pass. (line 52) 31904 * chain_next: GTY Options. (line 188) 31905 * chain_prev: GTY Options. (line 188) 31906 * change_address: Standard Names. (line 47) 31907 * char <1>: Misc. (line 677) 31908 * char <2>: Sections. (line 262) 31909 * char <3>: Misc. (line 845) 31910 * char: PCH Target. (line 12) 31911 * CHAR_TYPE_SIZE: Type Layout. (line 39) 31912 * check_stack instruction pattern: Standard Names. (line 1026) 31913 * CHImode: Machine Modes. (line 129) 31914 * class: Classes. (line 6) 31915 * class definitions, register: Register Classes. (line 6) 31916 * class preference constraints: Class Preferences. (line 6) 31917 * CLASS_LIKELY_SPILLED_P: Register Classes. (line 452) 31918 * CLASS_MAX_NREGS: Register Classes. (line 469) 31919 * CLASS_TYPE_P: Types. (line 80) 31920 * classes of RTX codes: RTL Classes. (line 6) 31921 * CLASSTYPE_DECLARED_CLASS: Classes. (line 6) 31922 * CLASSTYPE_HAS_MUTABLE: Classes. (line 80) 31923 * CLASSTYPE_NON_POD_P: Classes. (line 85) 31924 * CLEANUP_DECL: Function Bodies. (line 6) 31925 * CLEANUP_EXPR: Function Bodies. (line 6) 31926 * CLEANUP_POINT_EXPR: Expression trees. (line 6) 31927 * CLEANUP_STMT: Function Bodies. (line 6) 31928 * Cleanups: Cleanups. (line 6) 31929 * CLEAR_BY_PIECES_P: Costs. (line 124) 31930 * CLEAR_INSN_CACHE: Trampolines. (line 100) 31931 * CLEAR_RATIO: Costs. (line 115) 31932 * clobber: Side Effects. (line 100) 31933 * clz: Arithmetic. (line 196) 31934 * CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 319) 31935 * clzM2 instruction pattern: Standard Names. (line 447) 31936 * cmpM instruction pattern: Standard Names. (line 476) 31937 * cmpmemM instruction pattern: Standard Names. (line 577) 31938 * cmpstrM instruction pattern: Standard Names. (line 558) 31939 * cmpstrnM instruction pattern: Standard Names. (line 546) 31940 * code generation RTL sequences: Expander Definitions. 31941 (line 6) 31942 * code macros in .md files: Code Macros. (line 6) 31943 * code_label: Insns. (line 117) 31944 * code_label and /i: Flags. (line 44) 31945 * code_label and /v: Flags. (line 29) 31946 * CODE_LABEL_NUMBER: Insns. (line 117) 31947 * codes, RTL expression: RTL Objects. (line 47) 31948 * COImode: Machine Modes. (line 129) 31949 * COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32) 31950 * COLLECT_EXPORT_LIST: Misc. (line 733) 31951 * COLLECT_SHARED_FINI_FUNC: Macros for Initialization. 31952 (line 44) 31953 * COLLECT_SHARED_INIT_FUNC: Macros for Initialization. 31954 (line 33) 31955 * combiner pass: Regs and Memory. (line 148) 31956 * commit_edge_insertions: Maintaining the CFG. 31957 (line 118) 31958 * compare: Arithmetic. (line 43) 31959 * compare, canonicalization of: Insn Canonicalizations. 31960 (line 37) 31961 * comparison_operator: Machine-Independent Predicates. 31962 (line 111) 31963 * compiler passes and files: Passes. (line 6) 31964 * complement, bitwise: Arithmetic. (line 138) 31965 * COMPLEX_CST: Expression trees. (line 6) 31966 * COMPLEX_EXPR: Expression trees. (line 6) 31967 * COMPLEX_TYPE: Types. (line 6) 31968 * COMPONENT_REF: Expression trees. (line 6) 31969 * Compound Expressions: Compound Expressions. 31970 (line 6) 31971 * Compound Lvalues: Compound Lvalues. (line 6) 31972 * COMPOUND_EXPR: Expression trees. (line 6) 31973 * COMPOUND_LITERAL_EXPR: Expression trees. (line 6) 31974 * COMPOUND_LITERAL_EXPR_DECL: Expression trees. (line 568) 31975 * COMPOUND_LITERAL_EXPR_DECL_STMT: Expression trees. (line 568) 31976 * computed jump: Edges. (line 128) 31977 * computing the length of an insn: Insn Lengths. (line 6) 31978 * cond: Comparisons. (line 90) 31979 * cond and attributes: Expressions. (line 37) 31980 * cond_exec: Side Effects. (line 245) 31981 * COND_EXPR: Expression trees. (line 6) 31982 * condition code register: Regs and Memory. (line 182) 31983 * condition code status: Condition Code. (line 6) 31984 * condition codes: Comparisons. (line 20) 31985 * conditional execution: Conditional Execution. 31986 (line 6) 31987 * Conditional Expressions: Conditional Expressions. 31988 (line 6) 31989 * CONDITIONAL_REGISTER_USAGE: Register Basics. (line 60) 31990 * conditional_trap instruction pattern: Standard Names. (line 1160) 31991 * conditions, in patterns: Patterns. (line 43) 31992 * configuration file <1>: Filesystem. (line 6) 31993 * configuration file: Host Misc. (line 6) 31994 * configure terms: Configure Terms. (line 6) 31995 * CONJ_EXPR: Expression trees. (line 6) 31996 * const and /i: Flags. (line 133) 31997 * CONST0_RTX: Constants. (line 73) 31998 * const0_rtx: Constants. (line 16) 31999 * const1_rtx: Constants. (line 16) 32000 * CONST1_RTX: Constants. (line 73) 32001 * CONST2_RTX: Constants. (line 73) 32002 * const2_rtx: Constants. (line 16) 32003 * CONST_DECL: Declarations. (line 6) 32004 * const_double: Constants. (line 32) 32005 * const_double, RTL sharing: Sharing. (line 29) 32006 * CONST_DOUBLE_CHAIN: Constants. (line 51) 32007 * CONST_DOUBLE_LOW: Constants. (line 60) 32008 * CONST_DOUBLE_MEM: Constants. (line 51) 32009 * CONST_DOUBLE_OK_FOR_CONSTRAINT_P: Old Constraints. (line 69) 32010 * CONST_DOUBLE_OK_FOR_LETTER_P: Old Constraints. (line 54) 32011 * const_double_operand: Machine-Independent Predicates. 32012 (line 21) 32013 * const_int: Constants. (line 8) 32014 * const_int and attribute tests: Expressions. (line 47) 32015 * const_int and attributes: Expressions. (line 10) 32016 * const_int, RTL sharing: Sharing. (line 23) 32017 * const_int_operand: Machine-Independent Predicates. 32018 (line 16) 32019 * CONST_OK_FOR_CONSTRAINT_P: Old Constraints. (line 49) 32020 * CONST_OK_FOR_LETTER_P: Old Constraints. (line 40) 32021 * CONST_OR_PURE_CALL_P: Flags. (line 19) 32022 * const_string: Constants. (line 82) 32023 * const_string and attributes: Expressions. (line 20) 32024 * const_true_rtx: Constants. (line 26) 32025 * const_vector: Constants. (line 39) 32026 * const_vector, RTL sharing: Sharing. (line 32) 32027 * constant attributes: Constant Attributes. 32028 (line 6) 32029 * constant definitions: Constant Definitions. 32030 (line 6) 32031 * CONSTANT_ADDRESS_P: Addressing Modes. (line 29) 32032 * CONSTANT_ALIGNMENT: Storage Layout. (line 212) 32033 * CONSTANT_P: Addressing Modes. (line 35) 32034 * CONSTANT_POOL_ADDRESS_P: Flags. (line 10) 32035 * CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 64) 32036 * constants in constraints: Simple Constraints. (line 58) 32037 * constm1_rtx: Constants. (line 16) 32038 * constraint modifier characters: Modifiers. (line 6) 32039 * constraint, matching: Simple Constraints. (line 130) 32040 * CONSTRAINT_LEN: Old Constraints. (line 12) 32041 * constraint_num: C Constraint Interface. 32042 (line 38) 32043 * constraint_satisfied_p: C Constraint Interface. 32044 (line 54) 32045 * constraints: Constraints. (line 6) 32046 * constraints, defining: Define Constraints. (line 6) 32047 * constraints, defining, obsolete method: Old Constraints. (line 6) 32048 * constraints, machine specific: Machine Constraints. 32049 (line 6) 32050 * constraints, testing: C Constraint Interface. 32051 (line 6) 32052 * constructor: Function Basics. (line 6) 32053 * CONSTRUCTOR: Expression trees. (line 6) 32054 * constructors, automatic calls: Collect2. (line 15) 32055 * constructors, output of: Initialization. (line 6) 32056 * container: Containers. (line 6) 32057 * CONTINUE_STMT: Function Bodies. (line 6) 32058 * contributors: Contributors. (line 6) 32059 * controlling register usage: Register Basics. (line 76) 32060 * controlling the compilation driver: Driver. (line 6) 32061 * conventions, run-time: Interface. (line 6) 32062 * conversions: Conversions. (line 6) 32063 * CONVERT_EXPR: Expression trees. (line 6) 32064 * copy constructor: Function Basics. (line 6) 32065 * copy_rtx: Addressing Modes. (line 170) 32066 * copy_rtx_if_shared: Sharing. (line 64) 32067 * copysignM3 instruction pattern: Standard Names. (line 428) 32068 * cosM2 instruction pattern: Standard Names. (line 327) 32069 * costs of instructions: Costs. (line 6) 32070 * CP_INTEGRAL_TYPE: Types. (line 72) 32071 * cp_namespace_decls: Namespaces. (line 44) 32072 * CP_TYPE_CONST_NON_VOLATILE_P: Types. (line 45) 32073 * CP_TYPE_CONST_P: Types. (line 36) 32074 * CP_TYPE_QUALS: Types. (line 28) 32075 * CP_TYPE_RESTRICT_P: Types. (line 42) 32076 * CP_TYPE_VOLATILE_P: Types. (line 39) 32077 * CPLUSPLUS_CPP_SPEC: Driver. (line 113) 32078 * CPP_SPEC: Driver. (line 106) 32079 * CQImode: Machine Modes. (line 129) 32080 * cross compilation and floating point: Floating Point. (line 6) 32081 * CRT_CALL_STATIC_FUNCTION: Sections. (line 112) 32082 * CRTSTUFF_T_CFLAGS: Target Fragment. (line 35) 32083 * CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 39) 32084 * CSImode: Machine Modes. (line 129) 32085 * CTImode: Machine Modes. (line 129) 32086 * ctz: Arithmetic. (line 204) 32087 * CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 320) 32088 * ctzM2 instruction pattern: Standard Names. (line 454) 32089 * CUMULATIVE_ARGS: Register Arguments. (line 127) 32090 * current_function_epilogue_delay_list: Function Entry. (line 181) 32091 * current_function_is_leaf: Leaf Functions. (line 51) 32092 * current_function_outgoing_args_size: Stack Arguments. (line 45) 32093 * current_function_pops_args: Function Entry. (line 106) 32094 * current_function_pretend_args_size: Function Entry. (line 112) 32095 * current_function_uses_only_leaf_regs: Leaf Functions. (line 51) 32096 * current_insn_predicate: Conditional Execution. 32097 (line 26) 32098 * data bypass: Processor pipeline description. 32099 (line 106) 32100 * data dependence delays: Processor pipeline description. 32101 (line 6) 32102 * Data Dependency Analysis: Dependency analysis. 32103 (line 6) 32104 * data structures: Per-Function Data. (line 6) 32105 * DATA_ALIGNMENT: Storage Layout. (line 199) 32106 * DATA_SECTION_ASM_OP: Sections. (line 53) 32107 * DBR_OUTPUT_SEQEND: Instruction Output. (line 107) 32108 * dbr_sequence_length: Instruction Output. (line 106) 32109 * DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 103) 32110 * DBX_CONTIN_CHAR: DBX Options. (line 66) 32111 * DBX_CONTIN_LENGTH: DBX Options. (line 56) 32112 * DBX_DEBUGGING_INFO: DBX Options. (line 9) 32113 * DBX_FUNCTION_FIRST: DBX Options. (line 97) 32114 * DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 109) 32115 * DBX_NO_XREFS: DBX Options. (line 50) 32116 * DBX_OUTPUT_LBRAC: DBX Hooks. (line 9) 32117 * DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 34) 32118 * DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 9) 32119 * DBX_OUTPUT_NFUN: DBX Hooks. (line 18) 32120 * DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX. 32121 (line 42) 32122 * DBX_OUTPUT_RBRAC: DBX Hooks. (line 15) 32123 * DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 22) 32124 * DBX_REGISTER_NUMBER: All Debuggers. (line 9) 32125 * DBX_REGPARM_STABS_CODE: DBX Options. (line 87) 32126 * DBX_REGPARM_STABS_LETTER: DBX Options. (line 92) 32127 * DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 82) 32128 * DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 73) 32129 * DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 78) 32130 * DBX_USE_BINCL: DBX Options. (line 115) 32131 * DCmode: Machine Modes. (line 124) 32132 * DDmode: Machine Modes. (line 90) 32133 * De Morgan's law: Insn Canonicalizations. 32134 (line 54) 32135 * dead_or_set_p: define_peephole. (line 65) 32136 * DEBUG_SYMS_TEXT: DBX Options. (line 25) 32137 * DEBUGGER_ARG_OFFSET: All Debuggers. (line 37) 32138 * DEBUGGER_AUTO_OFFSET: All Debuggers. (line 28) 32139 * decimal float library: Decimal float library routines. 32140 (line 6) 32141 * DECL_ALIGN: Declarations. (line 6) 32142 * DECL_ANTICIPATED: Function Basics. (line 48) 32143 * DECL_ARGUMENTS: Function Basics. (line 163) 32144 * DECL_ARRAY_DELETE_OPERATOR_P: Function Basics. (line 184) 32145 * DECL_ARTIFICIAL <1>: Working with declarations. 32146 (line 24) 32147 * DECL_ARTIFICIAL: Function Basics. (line 6) 32148 * DECL_ASSEMBLER_NAME: Function Basics. (line 6) 32149 * DECL_ATTRIBUTES: Attributes. (line 22) 32150 * DECL_BASE_CONSTRUCTOR_P: Function Basics. (line 94) 32151 * DECL_CLASS_SCOPE_P: Working with declarations. 32152 (line 41) 32153 * DECL_COMPLETE_CONSTRUCTOR_P: Function Basics. (line 90) 32154 * DECL_COMPLETE_DESTRUCTOR_P: Function Basics. (line 104) 32155 * DECL_CONST_MEMFUNC_P: Function Basics. (line 77) 32156 * DECL_CONSTRUCTOR_P: Function Basics. (line 83) 32157 * DECL_CONTEXT: Namespaces. (line 26) 32158 * DECL_CONV_FN_P: Function Basics. (line 111) 32159 * DECL_COPY_CONSTRUCTOR_P: Function Basics. (line 98) 32160 * DECL_DESTRUCTOR_P: Function Basics. (line 101) 32161 * DECL_EXTERN_C_FUNCTION_P: Function Basics. (line 52) 32162 * DECL_EXTERNAL <1>: Function Basics. (line 38) 32163 * DECL_EXTERNAL: Declarations. (line 6) 32164 * DECL_FUNCTION_MEMBER_P: Function Basics. (line 6) 32165 * DECL_FUNCTION_SCOPE_P: Working with declarations. 32166 (line 44) 32167 * DECL_GLOBAL_CTOR_P: Function Basics. (line 6) 32168 * DECL_GLOBAL_DTOR_P: Function Basics. (line 6) 32169 * DECL_INITIAL: Declarations. (line 6) 32170 * DECL_LINKONCE_P: Function Basics. (line 56) 32171 * DECL_LOCAL_FUNCTION_P: Function Basics. (line 44) 32172 * DECL_MAIN_P: Function Basics. (line 7) 32173 * DECL_NAME <1>: Function Basics. (line 6) 32174 * DECL_NAME <2>: Namespaces. (line 15) 32175 * DECL_NAME <3>: Function Basics. (line 11) 32176 * DECL_NAME: Working with declarations. 32177 (line 7) 32178 * DECL_NAMESPACE_ALIAS: Namespaces. (line 30) 32179 * DECL_NAMESPACE_SCOPE_P: Working with declarations. 32180 (line 37) 32181 * DECL_NAMESPACE_STD_P: Namespaces. (line 40) 32182 * DECL_NON_THUNK_FUNCTION_P: Function Basics. (line 144) 32183 * DECL_NONCONVERTING_P: Function Basics. (line 86) 32184 * DECL_NONSTATIC_MEMBER_FUNCTION_P: Function Basics. (line 74) 32185 * DECL_OVERLOADED_OPERATOR_P: Function Basics. (line 108) 32186 * DECL_RESULT: Function Basics. (line 168) 32187 * DECL_SIZE: Declarations. (line 6) 32188 * DECL_STATIC_FUNCTION_P: Function Basics. (line 71) 32189 * DECL_STMT: Function Bodies. (line 6) 32190 * DECL_STMT_DECL: Function Bodies. (line 6) 32191 * DECL_THUNK_P: Function Basics. (line 122) 32192 * DECL_VOLATILE_MEMFUNC_P: Function Basics. (line 80) 32193 * declaration: Declarations. (line 6) 32194 * declarations, RTL: RTL Declarations. (line 6) 32195 * DECLARE_LIBRARY_RENAMES: Library Calls. (line 9) 32196 * decrement_and_branch_until_zero instruction pattern: Standard Names. 32197 (line 901) 32198 * default: GTY Options. (line 82) 32199 * default_file_start: File Framework. (line 9) 32200 * DEFAULT_GDB_EXTENSIONS: DBX Options. (line 18) 32201 * DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 34) 32202 * DEFAULT_SIGNED_CHAR: Type Layout. (line 114) 32203 * define_address_constraint: Define Constraints. (line 105) 32204 * define_asm_attributes: Tagging Insns. (line 73) 32205 * define_attr: Defining Attributes. 32206 (line 6) 32207 * define_automaton: Processor pipeline description. 32208 (line 53) 32209 * define_bypass: Processor pipeline description. 32210 (line 197) 32211 * define_code_attr: Code Macros. (line 6) 32212 * define_code_macro: Code Macros. (line 6) 32213 * define_cond_exec: Conditional Execution. 32214 (line 13) 32215 * define_constants: Constant Definitions. 32216 (line 6) 32217 * define_constraint: Define Constraints. (line 46) 32218 * define_cpu_unit: Processor pipeline description. 32219 (line 68) 32220 * define_delay: Delay Slots. (line 25) 32221 * define_expand: Expander Definitions. 32222 (line 11) 32223 * define_insn: Patterns. (line 6) 32224 * define_insn example: Example. (line 6) 32225 * define_insn_and_split: Insn Splitting. (line 170) 32226 * define_insn_reservation: Processor pipeline description. 32227 (line 106) 32228 * define_memory_constraint: Define Constraints. (line 86) 32229 * define_mode_attr: Substitutions. (line 6) 32230 * define_mode_macro: Defining Mode Macros. 32231 (line 6) 32232 * define_peephole: define_peephole. (line 6) 32233 * define_peephole2: define_peephole2. (line 6) 32234 * define_predicate: Defining Predicates. 32235 (line 6) 32236 * define_query_cpu_unit: Processor pipeline description. 32237 (line 90) 32238 * define_register_constraint: Define Constraints. (line 28) 32239 * define_reservation: Processor pipeline description. 32240 (line 186) 32241 * define_special_predicate: Defining Predicates. 32242 (line 6) 32243 * define_split: Insn Splitting. (line 32) 32244 * defining attributes and their values: Defining Attributes. 32245 (line 6) 32246 * defining constraints: Define Constraints. (line 6) 32247 * defining constraints, obsolete method: Old Constraints. (line 6) 32248 * defining jump instruction patterns: Jump Patterns. (line 6) 32249 * defining looping instruction patterns: Looping Patterns. (line 6) 32250 * defining peephole optimizers: Peephole Definitions. 32251 (line 6) 32252 * defining predicates: Defining Predicates. 32253 (line 6) 32254 * defining RTL sequences for code generation: Expander Definitions. 32255 (line 6) 32256 * delay slots, defining: Delay Slots. (line 6) 32257 * DELAY_SLOTS_FOR_EPILOGUE: Function Entry. (line 163) 32258 * deletable: GTY Options. (line 150) 32259 * DELETE_IF_ORDINARY: Filesystem. (line 79) 32260 * Dependent Patterns: Dependent Patterns. (line 6) 32261 * desc: GTY Options. (line 82) 32262 * destructor: Function Basics. (line 6) 32263 * destructors, output of: Initialization. (line 6) 32264 * deterministic finite state automaton: Processor pipeline description. 32265 (line 296) 32266 * DF_SIZE: Type Layout. (line 90) 32267 * DFmode: Machine Modes. (line 73) 32268 * digits in constraint: Simple Constraints. (line 118) 32269 * DImode: Machine Modes. (line 45) 32270 * DIR_SEPARATOR: Filesystem. (line 18) 32271 * DIR_SEPARATOR_2: Filesystem. (line 19) 32272 * directory options .md: Including Patterns. (line 44) 32273 * disabling certain registers: Register Basics. (line 76) 32274 * dispatch table: Dispatch Tables. (line 8) 32275 * div: Arithmetic. (line 106) 32276 * div and attributes: Expressions. (line 64) 32277 * division: Arithmetic. (line 106) 32278 * divM3 instruction pattern: Standard Names. (line 194) 32279 * divmodM4 instruction pattern: Standard Names. (line 279) 32280 * DO_BODY: Function Bodies. (line 6) 32281 * DO_COND: Function Bodies. (line 6) 32282 * DO_STMT: Function Bodies. (line 6) 32283 * DOLLARS_IN_IDENTIFIERS: Misc. (line 480) 32284 * doloop_begin instruction pattern: Standard Names. (line 932) 32285 * doloop_end instruction pattern: Standard Names. (line 911) 32286 * DONE: Expander Definitions. 32287 (line 74) 32288 * DONT_USE_BUILTIN_SETJMP: Exception Region Output. 32289 (line 70) 32290 * DOUBLE_TYPE_SIZE: Type Layout. (line 53) 32291 * driver: Driver. (line 6) 32292 * DRIVER_SELF_SPECS: Driver. (line 71) 32293 * DUMPFILE_FORMAT: Filesystem. (line 67) 32294 * DWARF2_ASM_LINE_DEBUG_INFO: SDB and DWARF. (line 36) 32295 * DWARF2_DEBUGGING_INFO: SDB and DWARF. (line 13) 32296 * DWARF2_FRAME_INFO: SDB and DWARF. (line 30) 32297 * DWARF2_FRAME_REG_OUT: Frame Registers. (line 133) 32298 * DWARF2_UNWIND_INFO: Exception Region Output. 32299 (line 40) 32300 * DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 152) 32301 * DWARF_CIE_DATA_ALIGNMENT: Exception Region Output. 32302 (line 75) 32303 * DWARF_FRAME_REGISTERS: Frame Registers. (line 93) 32304 * DWARF_FRAME_REGNUM: Frame Registers. (line 125) 32305 * DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 117) 32306 * DWARF_ZERO_REG: Frame Layout. (line 159) 32307 * DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 92) 32308 * E in constraint: Simple Constraints. (line 77) 32309 * earlyclobber operand: Modifiers. (line 25) 32310 * edge: Edges. (line 6) 32311 * edge in the flow graph: Edges. (line 6) 32312 * edge iterators: Edges. (line 15) 32313 * edge splitting: Maintaining the CFG. 32314 (line 118) 32315 * EDGE_ABNORMAL: Edges. (line 128) 32316 * EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 171) 32317 * EDGE_ABNORMAL, EDGE_EH: Edges. (line 96) 32318 * EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 122) 32319 * EDGE_FALLTHRU, force_nonfallthru: Edges. (line 86) 32320 * EDOM, implicit usage: Library Calls. (line 58) 32321 * EH_FRAME_IN_DATA_SECTION: Exception Region Output. 32322 (line 20) 32323 * EH_FRAME_SECTION_NAME: Exception Region Output. 32324 (line 10) 32325 * eh_return instruction pattern: Standard Names. (line 1100) 32326 * EH_RETURN_DATA_REGNO: Exception Handling. (line 7) 32327 * EH_RETURN_HANDLER_RTX: Exception Handling. (line 39) 32328 * EH_RETURN_STACKADJ_RTX: Exception Handling. (line 22) 32329 * EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output. 32330 (line 29) 32331 * EH_USES: Function Entry. (line 158) 32332 * ei_edge: Edges. (line 43) 32333 * ei_end_p: Edges. (line 27) 32334 * ei_last: Edges. (line 23) 32335 * ei_next: Edges. (line 35) 32336 * ei_one_before_end_p: Edges. (line 31) 32337 * ei_prev: Edges. (line 39) 32338 * ei_safe_safe: Edges. (line 47) 32339 * ei_start: Edges. (line 19) 32340 * ELIGIBLE_FOR_EPILOGUE_DELAY: Function Entry. (line 169) 32341 * ELIMINABLE_REGS: Elimination. (line 44) 32342 * ELSE_CLAUSE: Function Bodies. (line 6) 32343 * EMIT_MODE_SET: Mode Switching. (line 74) 32344 * Empty Statements: Empty Statements. (line 6) 32345 * EMPTY_CLASS_EXPR: Function Bodies. (line 6) 32346 * EMPTY_FIELD_BOUNDARY: Storage Layout. (line 236) 32347 * ENABLE_EXECUTE_STACK: Trampolines. (line 110) 32348 * ENDFILE_SPEC: Driver. (line 218) 32349 * endianness: Portability. (line 21) 32350 * ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 28) 32351 * enum machine_mode: Machine Modes. (line 6) 32352 * enum reg_class: Register Classes. (line 65) 32353 * ENUMERAL_TYPE: Types. (line 6) 32354 * epilogue: Function Entry. (line 6) 32355 * epilogue instruction pattern: Standard Names. (line 1132) 32356 * EPILOGUE_USES: Function Entry. (line 152) 32357 * eq: Comparisons. (line 52) 32358 * eq and attributes: Expressions. (line 64) 32359 * eq_attr: Expressions. (line 85) 32360 * EQ_EXPR: Expression trees. (line 6) 32361 * equal: Comparisons. (line 52) 32362 * errno, implicit usage: Library Calls. (line 70) 32363 * EXACT_DIV_EXPR: Expression trees. (line 6) 32364 * examining SSA_NAMEs: SSA. (line 210) 32365 * exception handling <1>: Exception Handling. (line 6) 32366 * exception handling: Edges. (line 96) 32367 * exception_receiver instruction pattern: Standard Names. (line 1064) 32368 * exclamation point: Multi-Alternative. (line 47) 32369 * exclusion_set: Processor pipeline description. 32370 (line 215) 32371 * exclusive-or, bitwise: Arithmetic. (line 152) 32372 * EXIT_EXPR: Expression trees. (line 6) 32373 * EXIT_IGNORE_STACK: Function Entry. (line 140) 32374 * expander definitions: Expander Definitions. 32375 (line 6) 32376 * expM2 instruction pattern: Standard Names. (line 343) 32377 * expr_list: Insns. (line 538) 32378 * EXPR_STMT: Function Bodies. (line 6) 32379 * EXPR_STMT_EXPR: Function Bodies. (line 6) 32380 * expression: Expression trees. (line 6) 32381 * expression codes: RTL Objects. (line 47) 32382 * extendMN2 instruction pattern: Standard Names. (line 634) 32383 * extensible constraints: Simple Constraints. (line 161) 32384 * EXTRA_ADDRESS_CONSTRAINT: Old Constraints. (line 123) 32385 * EXTRA_CONSTRAINT: Old Constraints. (line 74) 32386 * EXTRA_CONSTRAINT_STR: Old Constraints. (line 95) 32387 * EXTRA_MEMORY_CONSTRAINT: Old Constraints. (line 100) 32388 * EXTRA_SPECS: Driver. (line 245) 32389 * extv instruction pattern: Standard Names. (line 643) 32390 * extzv instruction pattern: Standard Names. (line 658) 32391 * F in constraint: Simple Constraints. (line 82) 32392 * FAIL: Expander Definitions. 32393 (line 80) 32394 * fall-thru: Edges. (line 69) 32395 * FATAL_EXIT_CODE: Host Misc. (line 6) 32396 * FDL, GNU Free Documentation License: GNU Free Documentation License. 32397 (line 6) 32398 * features, optional, in system conventions: Run-time Target. 32399 (line 59) 32400 * ffs: Arithmetic. (line 190) 32401 * ffsM2 instruction pattern: Standard Names. (line 437) 32402 * FIELD_DECL: Declarations. (line 6) 32403 * file_end_indicate_exec_stack: File Framework. (line 41) 32404 * files and passes of the compiler: Passes. (line 6) 32405 * files, generated: Files. (line 6) 32406 * final_absence_set: Processor pipeline description. 32407 (line 215) 32408 * FINAL_PRESCAN_INSN: Instruction Output. (line 46) 32409 * final_presence_set: Processor pipeline description. 32410 (line 215) 32411 * final_scan_insn: Function Entry. (line 181) 32412 * final_sequence: Instruction Output. (line 117) 32413 * FIND_BASE_TERM: Addressing Modes. (line 100) 32414 * FINI_ARRAY_SECTION_ASM_OP: Sections. (line 105) 32415 * FINI_SECTION_ASM_OP: Sections. (line 90) 32416 * finite state automaton minimization: Processor pipeline description. 32417 (line 296) 32418 * FIRST_PARM_OFFSET: Frame Layout. (line 67) 32419 * FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65) 32420 * FIRST_PSEUDO_REGISTER: Register Basics. (line 9) 32421 * FIRST_STACK_REG: Stack Registers. (line 23) 32422 * FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 32423 * fix: Conversions. (line 77) 32424 * FIX_TRUNC_EXPR: Expression trees. (line 6) 32425 * fix_truncMN2 instruction pattern: Standard Names. (line 621) 32426 * fixed register: Register Basics. (line 15) 32427 * FIXED_REGISTERS: Register Basics. (line 15) 32428 * fixed_regs: Register Basics. (line 59) 32429 * fixMN2 instruction pattern: Standard Names. (line 601) 32430 * FIXUNS_TRUNC_LIKE_FIX_TRUNC: Misc. (line 100) 32431 * fixuns_truncMN2 instruction pattern: Standard Names. (line 625) 32432 * fixunsMN2 instruction pattern: Standard Names. (line 610) 32433 * flags in RTL expression: Flags. (line 6) 32434 * float: Conversions. (line 58) 32435 * FLOAT_EXPR: Expression trees. (line 6) 32436 * float_extend: Conversions. (line 33) 32437 * FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 25) 32438 * FLOAT_STORE_FLAG_VALUE: Misc. (line 301) 32439 * float_truncate: Conversions. (line 53) 32440 * FLOAT_TYPE_SIZE: Type Layout. (line 49) 32441 * FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 43) 32442 * FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory. 32443 (line 140) 32444 * floating point and cross compilation: Floating Point. (line 6) 32445 * Floating Point Emulation: Target Fragment. (line 15) 32446 * floating point emulation library, US Software GOFAST: Library Calls. 32447 (line 44) 32448 * floatMN2 instruction pattern: Standard Names. (line 593) 32449 * floatunsMN2 instruction pattern: Standard Names. (line 597) 32450 * FLOOR_DIV_EXPR: Expression trees. (line 6) 32451 * FLOOR_MOD_EXPR: Expression trees. (line 6) 32452 * floorM2 instruction pattern: Standard Names. (line 378) 32453 * flow-insensitive alias analysis: Alias analysis. (line 6) 32454 * flow-sensitive alias analysis: Alias analysis. (line 6) 32455 * FOR_BODY: Function Bodies. (line 6) 32456 * FOR_COND: Function Bodies. (line 6) 32457 * FOR_EXPR: Function Bodies. (line 6) 32458 * FOR_INIT_STMT: Function Bodies. (line 6) 32459 * FOR_STMT: Function Bodies. (line 6) 32460 * FORCE_CODE_SECTION_ALIGN: Sections. (line 136) 32461 * force_reg: Standard Names. (line 36) 32462 * frame layout: Frame Layout. (line 6) 32463 * FRAME_ADDR_RTX: Frame Layout. (line 116) 32464 * FRAME_GROWS_DOWNWARD: Frame Layout. (line 31) 32465 * FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory. 32466 (line 69) 32467 * FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 208) 32468 * frame_pointer_needed: Function Entry. (line 34) 32469 * FRAME_POINTER_REGNUM: Frame Registers. (line 14) 32470 * FRAME_POINTER_REGNUM and virtual registers: Regs and Memory. 32471 (line 74) 32472 * FRAME_POINTER_REQUIRED: Elimination. (line 9) 32473 * frame_pointer_rtx: Frame Registers. (line 85) 32474 * frame_related: Flags. (line 224) 32475 * frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags. 32476 (line 106) 32477 * frame_related, in mem: Flags. (line 70) 32478 * frame_related, in reg: Flags. (line 93) 32479 * frame_related, in symbol_ref: Flags. (line 168) 32480 * frequency, count, BB_FREQ_BASE: Profile information. 32481 (line 30) 32482 * ftruncM2 instruction pattern: Standard Names. (line 616) 32483 * function: Functions. (line 6) 32484 * function body: Function Bodies. (line 6) 32485 * function call conventions: Interface. (line 6) 32486 * function entry and exit: Function Entry. (line 6) 32487 * function entry point, alternate function entry point: Edges. 32488 (line 180) 32489 * function-call insns: Calls. (line 6) 32490 * FUNCTION_ARG: Register Arguments. (line 11) 32491 * FUNCTION_ARG_ADVANCE: Register Arguments. (line 178) 32492 * FUNCTION_ARG_BOUNDARY: Register Arguments. (line 224) 32493 * FUNCTION_ARG_PADDING: Register Arguments. (line 189) 32494 * FUNCTION_ARG_REGNO_P: Register Arguments. (line 229) 32495 * FUNCTION_BOUNDARY: Storage Layout. (line 164) 32496 * FUNCTION_DECL: Functions. (line 6) 32497 * FUNCTION_INCOMING_ARG: Register Arguments. (line 68) 32498 * FUNCTION_MODE: Misc. (line 349) 32499 * FUNCTION_OUTGOING_VALUE: Scalar Return. (line 51) 32500 * FUNCTION_PROFILER: Profiling. (line 9) 32501 * FUNCTION_TYPE: Types. (line 6) 32502 * FUNCTION_VALUE: Scalar Return. (line 47) 32503 * FUNCTION_VALUE_REGNO_P: Scalar Return. (line 72) 32504 * functions, leaf: Leaf Functions. (line 6) 32505 * fundamental type: Types. (line 6) 32506 * g in constraint: Simple Constraints. (line 108) 32507 * G in constraint: Simple Constraints. (line 86) 32508 * GCC and portability: Portability. (line 6) 32509 * GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36) 32510 * gcov_type: Profile information. 32511 (line 41) 32512 * ge: Comparisons. (line 72) 32513 * ge and attributes: Expressions. (line 64) 32514 * GE_EXPR: Expression trees. (line 6) 32515 * GEN_ERRNO_RTX: Library Calls. (line 71) 32516 * gencodes: RTL passes. (line 18) 32517 * general_operand: Machine-Independent Predicates. 32518 (line 105) 32519 * GENERAL_REGS: Register Classes. (line 23) 32520 * generated files: Files. (line 6) 32521 * generating assembler output: Output Statement. (line 6) 32522 * generating insns: RTL Template. (line 6) 32523 * GENERIC <1>: GENERIC. (line 6) 32524 * GENERIC <2>: Gimplification pass. 32525 (line 12) 32526 * GENERIC: Parsing pass. (line 6) 32527 * generic predicates: Machine-Independent Predicates. 32528 (line 6) 32529 * genflags: RTL passes. (line 18) 32530 * get_attr: Expressions. (line 80) 32531 * get_attr_length: Insn Lengths. (line 46) 32532 * GET_CLASS_NARROWEST_MODE: Machine Modes. (line 236) 32533 * GET_CODE: RTL Objects. (line 47) 32534 * get_frame_size: Elimination. (line 31) 32535 * get_insns: Insns. (line 34) 32536 * get_last_insn: Insns. (line 34) 32537 * GET_MODE: Machine Modes. (line 191) 32538 * GET_MODE_ALIGNMENT: Machine Modes. (line 223) 32539 * GET_MODE_BITSIZE: Machine Modes. (line 215) 32540 * GET_MODE_CLASS: Machine Modes. (line 205) 32541 * GET_MODE_MASK: Machine Modes. (line 218) 32542 * GET_MODE_NAME: Machine Modes. (line 202) 32543 * GET_MODE_NUNITS: Machine Modes. (line 232) 32544 * GET_MODE_SIZE: Machine Modes. (line 212) 32545 * GET_MODE_UNIT_SIZE: Machine Modes. (line 226) 32546 * GET_MODE_WIDER_MODE: Machine Modes. (line 208) 32547 * GET_RTX_CLASS: RTL Classes. (line 6) 32548 * GET_RTX_FORMAT: RTL Classes. (line 130) 32549 * GET_RTX_LENGTH: RTL Classes. (line 127) 32550 * geu: Comparisons. (line 72) 32551 * geu and attributes: Expressions. (line 64) 32552 * GGC: Type Information. (line 6) 32553 * GIMPLE <1>: GIMPLE. (line 6) 32554 * GIMPLE <2>: Gimplification pass. 32555 (line 6) 32556 * GIMPLE: Parsing pass. (line 14) 32557 * GIMPLE Example: GIMPLE Example. (line 6) 32558 * GIMPLE Exception Handling: GIMPLE Exception Handling. 32559 (line 6) 32560 * GIMPLE Expressions: GIMPLE Expressions. (line 6) 32561 * gimplification <1>: Interfaces. (line 6) 32562 * gimplification <2>: Gimplification pass. 32563 (line 6) 32564 * gimplification: Parsing pass. (line 14) 32565 * gimplifier: Parsing pass. (line 14) 32566 * gimplify_expr: Gimplification pass. 32567 (line 18) 32568 * gimplify_function_tree: Gimplification pass. 32569 (line 18) 32570 * GLOBAL_INIT_PRIORITY: Function Basics. (line 147) 32571 * global_live_at_start, global_live_at_end: Liveness information. 32572 (line 22) 32573 * global_regs: Register Basics. (line 59) 32574 * GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 48) 32575 * GO_IF_MODE_DEPENDENT_ADDRESS: Addressing Modes. (line 178) 32576 * GOFAST, floating point emulation library: Library Calls. (line 44) 32577 * gofast_maybe_init_libfuncs: Library Calls. (line 44) 32578 * greater than: Comparisons. (line 60) 32579 * gt: Comparisons. (line 60) 32580 * gt and attributes: Expressions. (line 64) 32581 * GT_EXPR: Expression trees. (line 6) 32582 * gtu: Comparisons. (line 64) 32583 * gtu and attributes: Expressions. (line 64) 32584 * GTY: Type Information. (line 6) 32585 * H in constraint: Simple Constraints. (line 86) 32586 * HANDLE_PRAGMA_PACK_PUSH_POP: Misc. (line 459) 32587 * HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 470) 32588 * HANDLE_SYSV_PRAGMA: Misc. (line 430) 32589 * HANDLER: Function Bodies. (line 6) 32590 * HANDLER_BODY: Function Bodies. (line 6) 32591 * HANDLER_PARMS: Function Bodies. (line 6) 32592 * hard registers: Regs and Memory. (line 9) 32593 * HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 20) 32594 * HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 53) 32595 * HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 20) 32596 * HARD_REGNO_MODE_OK: Values in Registers. 32597 (line 57) 32598 * HARD_REGNO_NREGS: Values in Registers. 32599 (line 11) 32600 * HARD_REGNO_NREGS_HAS_PADDING: Values in Registers. 32601 (line 23) 32602 * HARD_REGNO_NREGS_WITH_PADDING: Values in Registers. 32603 (line 42) 32604 * HARD_REGNO_RENAME_OK: Values in Registers. 32605 (line 118) 32606 * HAS_INIT_SECTION: Macros for Initialization. 32607 (line 19) 32608 * HAS_LONG_COND_BRANCH: Misc. (line 9) 32609 * HAS_LONG_UNCOND_BRANCH: Misc. (line 18) 32610 * HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11) 32611 * HAVE_POST_DECREMENT: Addressing Modes. (line 12) 32612 * HAVE_POST_INCREMENT: Addressing Modes. (line 11) 32613 * HAVE_POST_MODIFY_DISP: Addressing Modes. (line 18) 32614 * HAVE_POST_MODIFY_REG: Addressing Modes. (line 24) 32615 * HAVE_PRE_DECREMENT: Addressing Modes. (line 10) 32616 * HAVE_PRE_INCREMENT: Addressing Modes. (line 9) 32617 * HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 17) 32618 * HAVE_PRE_MODIFY_REG: Addressing Modes. (line 23) 32619 * HCmode: Machine Modes. (line 124) 32620 * HFmode: Machine Modes. (line 58) 32621 * high: Constants. (line 120) 32622 * HImode: Machine Modes. (line 29) 32623 * HImode, in insn: Insns. (line 235) 32624 * host configuration: Host Config. (line 6) 32625 * host functions: Host Common. (line 6) 32626 * host hooks: Host Common. (line 6) 32627 * host makefile fragment: Host Fragment. (line 6) 32628 * HOST_BIT_BUCKET: Filesystem. (line 51) 32629 * HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45) 32630 * HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 12) 32631 * HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 45) 32632 * HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 26) 32633 * HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89) 32634 * HOST_LONG_LONG_FORMAT: Host Misc. (line 41) 32635 * HOST_OBJECT_SUFFIX: Filesystem. (line 40) 32636 * HOST_WIDE_INT: Anchored Addresses. (line 39) 32637 * HOT_TEXT_SECTION_NAME: Sections. (line 43) 32638 * I in constraint: Simple Constraints. (line 69) 32639 * i in constraint: Simple Constraints. (line 58) 32640 * IBM_FLOAT_FORMAT: Storage Layout. (line 404) 32641 * identifier: Identifiers. (line 6) 32642 * IDENTIFIER_LENGTH: Identifiers. (line 20) 32643 * IDENTIFIER_NODE: Identifiers. (line 6) 32644 * IDENTIFIER_OPNAME_P: Identifiers. (line 25) 32645 * IDENTIFIER_POINTER: Identifiers. (line 15) 32646 * IDENTIFIER_TYPENAME_P: Identifiers. (line 31) 32647 * IEEE-754R: Decimal float library routines. 32648 (line 6) 32649 * IEEE_FLOAT_FORMAT: Storage Layout. (line 394) 32650 * IF_COND: Function Bodies. (line 6) 32651 * if_marked: GTY Options. (line 156) 32652 * IF_STMT: Function Bodies. (line 6) 32653 * if_then_else: Comparisons. (line 80) 32654 * if_then_else and attributes: Expressions. (line 32) 32655 * if_then_else usage: Side Effects. (line 56) 32656 * IFCVT_EXTRA_FIELDS: Misc. (line 611) 32657 * IFCVT_INIT_EXTRA_FIELDS: Misc. (line 606) 32658 * IFCVT_MODIFY_CANCEL: Misc. (line 600) 32659 * IFCVT_MODIFY_FINAL: Misc. (line 594) 32660 * IFCVT_MODIFY_INSN: Misc. (line 588) 32661 * IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 581) 32662 * IFCVT_MODIFY_TESTS: Misc. (line 570) 32663 * IMAGPART_EXPR: Expression trees. (line 6) 32664 * Immediate Uses: Statement Operands. (line 291) 32665 * immediate_operand: Machine-Independent Predicates. 32666 (line 11) 32667 * IMMEDIATE_PREFIX: Instruction Output. (line 127) 32668 * in_struct: Flags. (line 239) 32669 * in_struct, in code_label and note: Flags. (line 44) 32670 * in_struct, in insn and jump_insn and call_insn: Flags. (line 34) 32671 * in_struct, in insn, jump_insn and call_insn: Flags. (line 151) 32672 * in_struct, in mem: Flags. (line 55) 32673 * in_struct, in subreg: Flags. (line 190) 32674 * include: Including Patterns. (line 6) 32675 * INCLUDE_DEFAULTS: Driver. (line 430) 32676 * inclusive-or, bitwise: Arithmetic. (line 147) 32677 * INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 179) 32678 * INCOMING_REGNO: Register Basics. (line 91) 32679 * INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 139) 32680 * INDEX_REG_CLASS: Register Classes. (line 134) 32681 * indirect_jump instruction pattern: Standard Names. (line 859) 32682 * indirect_operand: Machine-Independent Predicates. 32683 (line 71) 32684 * INDIRECT_REF: Expression trees. (line 6) 32685 * INIT_ARRAY_SECTION_ASM_OP: Sections. (line 98) 32686 * INIT_CUMULATIVE_ARGS: Register Arguments. (line 141) 32687 * INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 169) 32688 * INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 162) 32689 * INIT_ENVIRONMENT: Driver. (line 369) 32690 * INIT_EXPANDERS: Per-Function Data. (line 39) 32691 * INIT_EXPR: Expression trees. (line 6) 32692 * init_machine_status: Per-Function Data. (line 45) 32693 * init_one_libfunc: Library Calls. (line 15) 32694 * INIT_SECTION_ASM_OP <1>: Sections. (line 82) 32695 * INIT_SECTION_ASM_OP: Macros for Initialization. 32696 (line 10) 32697 * INITIAL_ELIMINATION_OFFSET: Elimination. (line 79) 32698 * INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 83) 32699 * INITIAL_FRAME_POINTER_OFFSET: Elimination. (line 32) 32700 * initialization routines: Initialization. (line 6) 32701 * INITIALIZE_TRAMPOLINE: Trampolines. (line 55) 32702 * inlining: Target Attributes. (line 86) 32703 * insert_insn_on_edge: Maintaining the CFG. 32704 (line 118) 32705 * insn: Insns. (line 63) 32706 * insn and /f: Flags. (line 106) 32707 * insn and /i: Flags. (line 133) 32708 * insn and /j: Flags. (line 160) 32709 * insn and /s: Flags. (line 34) 32710 * insn and /u: Flags. (line 24) 32711 * insn and /v: Flags. (line 29) 32712 * insn attributes: Insn Attributes. (line 6) 32713 * insn canonicalization: Insn Canonicalizations. 32714 (line 6) 32715 * insn includes: Including Patterns. (line 6) 32716 * insn lengths, computing: Insn Lengths. (line 6) 32717 * insn splitting: Insn Splitting. (line 6) 32718 * insn-attr.h: Defining Attributes. 32719 (line 24) 32720 * INSN_ANNULLED_BRANCH_P: Flags. (line 24) 32721 * INSN_CODE: Insns. (line 261) 32722 * INSN_DELETED_P: Flags. (line 29) 32723 * INSN_FROM_TARGET_P: Flags. (line 34) 32724 * insn_list: Insns. (line 538) 32725 * insn_list and /i: Flags. (line 133) 32726 * INSN_REFERENCES_ARE_DELAYED: Misc. (line 509) 32727 * INSN_SETS_ARE_DELAYED: Misc. (line 498) 32728 * INSN_UID: Insns. (line 23) 32729 * insns: Insns. (line 6) 32730 * insns, generating: RTL Template. (line 6) 32731 * insns, recognizing: RTL Template. (line 6) 32732 * instruction attributes: Insn Attributes. (line 6) 32733 * instruction latency time: Processor pipeline description. 32734 (line 197) 32735 * instruction patterns: Patterns. (line 6) 32736 * instruction splitting: Insn Splitting. (line 6) 32737 * insv instruction pattern: Standard Names. (line 661) 32738 * int: Run-time Target. (line 56) 32739 * INT_TYPE_SIZE: Type Layout. (line 12) 32740 * INTEGER_CST: Expression trees. (line 6) 32741 * INTEGER_TYPE: Types. (line 6) 32742 * integrated: Flags. (line 275) 32743 * integrated, in insn, call_insn, jump_insn, barrier, code_label, insn_list, const, and note: Flags. 32744 (line 133) 32745 * integrated, in reg: Flags. (line 88) 32746 * integrated, in symbol_ref: Flags. (line 205) 32747 * Interdependence of Patterns: Dependent Patterns. (line 6) 32748 * interfacing to GCC output: Interface. (line 6) 32749 * interlock delays: Processor pipeline description. 32750 (line 6) 32751 * intermediate representation lowering: Parsing pass. (line 14) 32752 * INTMAX_TYPE: Type Layout. (line 173) 32753 * introduction: Top. (line 6) 32754 * INVOKE__main: Macros for Initialization. 32755 (line 51) 32756 * ior: Arithmetic. (line 147) 32757 * ior and attributes: Expressions. (line 50) 32758 * ior, canonicalization of: Insn Canonicalizations. 32759 (line 54) 32760 * iorM3 instruction pattern: Standard Names. (line 194) 32761 * IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 120) 32762 * IV analysis on GIMPLE: Scalar evolutions. (line 6) 32763 * IV analysis on RTL: loop-iv. (line 6) 32764 * jump: Flags. (line 288) 32765 * jump instruction pattern: Standard Names. (line 750) 32766 * jump instruction patterns: Jump Patterns. (line 6) 32767 * jump instructions and set: Side Effects. (line 56) 32768 * jump, in call_insn: Flags. (line 164) 32769 * jump, in insn: Flags. (line 160) 32770 * jump, in mem: Flags. (line 64) 32771 * JUMP_ALIGN: Alignment Output. (line 9) 32772 * jump_insn: Insns. (line 73) 32773 * jump_insn and /f: Flags. (line 106) 32774 * jump_insn and /i: Flags. (line 133) 32775 * jump_insn and /s: Flags. (line 34) 32776 * jump_insn and /u: Flags. (line 24) 32777 * jump_insn and /v: Flags. (line 29) 32778 * JUMP_LABEL: Insns. (line 79) 32779 * JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 142) 32780 * Jumps: Jumps. (line 6) 32781 * LABEL_ALIGN: Alignment Output. (line 52) 32782 * LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 22) 32783 * LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output. (line 30) 32784 * LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 62) 32785 * LABEL_ALT_ENTRY_P: Insns. (line 138) 32786 * LABEL_ALTERNATE_NAME: Edges. (line 180) 32787 * LABEL_DECL: Declarations. (line 6) 32788 * LABEL_KIND: Insns. (line 138) 32789 * LABEL_NUSES: Insns. (line 134) 32790 * LABEL_PRESERVE_P: Flags. (line 44) 32791 * label_ref: Constants. (line 97) 32792 * label_ref and /v: Flags. (line 50) 32793 * label_ref, RTL sharing: Sharing. (line 35) 32794 * LABEL_REF_NONLOCAL_P: Flags. (line 50) 32795 * lang_hooks.gimplify_expr: Gimplification pass. 32796 (line 18) 32797 * lang_hooks.parse_file: Parsing pass. (line 6) 32798 * language-independent intermediate representation: Parsing pass. 32799 (line 14) 32800 * large return values: Aggregate Return. (line 6) 32801 * LARGEST_EXPONENT_IS_NORMAL: Storage Layout. (line 480) 32802 * LAST_STACK_REG: Stack Registers. (line 27) 32803 * LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 32804 * LCSSA: LCSSA. (line 6) 32805 * LD_FINI_SWITCH: Macros for Initialization. 32806 (line 29) 32807 * LD_INIT_SWITCH: Macros for Initialization. 32808 (line 25) 32809 * LDD_SUFFIX: Macros for Initialization. 32810 (line 116) 32811 * le: Comparisons. (line 76) 32812 * le and attributes: Expressions. (line 64) 32813 * LE_EXPR: Expression trees. (line 6) 32814 * leaf functions: Leaf Functions. (line 6) 32815 * leaf_function_p: Standard Names. (line 821) 32816 * LEAF_REG_REMAP: Leaf Functions. (line 39) 32817 * LEAF_REGISTERS: Leaf Functions. (line 25) 32818 * left rotate: Arithmetic. (line 178) 32819 * left shift: Arithmetic. (line 157) 32820 * LEGITIMATE_CONSTANT_P: Addressing Modes. (line 193) 32821 * LEGITIMATE_PIC_OPERAND_P: PIC. (line 31) 32822 * LEGITIMIZE_ADDRESS: Addressing Modes. (line 110) 32823 * LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 133) 32824 * length: GTY Options. (line 50) 32825 * less than: Comparisons. (line 68) 32826 * less than or equal: Comparisons. (line 76) 32827 * leu: Comparisons. (line 76) 32828 * leu and attributes: Expressions. (line 64) 32829 * LIB2FUNCS_EXTRA: Target Fragment. (line 11) 32830 * LIB_SPEC: Driver. (line 170) 32831 * LIBCALL_VALUE: Scalar Return. (line 55) 32832 * libgcc.a: Library Calls. (line 6) 32833 * LIBGCC2_CFLAGS: Target Fragment. (line 8) 32834 * LIBGCC2_HAS_DF_MODE: Type Layout. (line 69) 32835 * LIBGCC2_HAS_TF_MODE: Type Layout. (line 83) 32836 * LIBGCC2_HAS_XF_MODE: Type Layout. (line 77) 32837 * LIBGCC2_LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 63) 32838 * LIBGCC2_WORDS_BIG_ENDIAN: Storage Layout. (line 36) 32839 * LIBGCC_SPEC: Driver. (line 178) 32840 * library subroutine names: Library Calls. (line 6) 32841 * LIBRARY_PATH_ENV: Misc. (line 549) 32842 * LIMIT_RELOAD_CLASS: Register Classes. (line 239) 32843 * Linear loop transformations framework: Lambda. (line 6) 32844 * LINK_COMMAND_SPEC: Driver. (line 299) 32845 * LINK_EH_SPEC: Driver. (line 205) 32846 * LINK_ELIMINATE_DUPLICATE_LDIRECTORIES: Driver. (line 309) 32847 * LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 295) 32848 * LINK_LIBGCC_SPECIAL_1: Driver. (line 290) 32849 * LINK_SPEC: Driver. (line 163) 32850 * linkage: Function Basics. (line 6) 32851 * list: Containers. (line 6) 32852 * Liveness representation: Liveness information. 32853 (line 6) 32854 * lo_sum: Arithmetic. (line 24) 32855 * load address instruction: Simple Constraints. (line 152) 32856 * LOAD_EXTEND_OP: Misc. (line 69) 32857 * load_multiple instruction pattern: Standard Names. (line 137) 32858 * LOCAL_ALIGNMENT: Storage Layout. (line 225) 32859 * LOCAL_CLASS_P: Classes. (line 68) 32860 * LOCAL_INCLUDE_DIR: Driver. (line 376) 32861 * LOCAL_LABEL_PREFIX: Instruction Output. (line 125) 32862 * LOCAL_REGNO: Register Basics. (line 105) 32863 * LOG_LINKS: Insns. (line 280) 32864 * Logical Operators: Logical Operators. (line 6) 32865 * logical-and, bitwise: Arithmetic. (line 142) 32866 * logM2 instruction pattern: Standard Names. (line 351) 32867 * LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 58) 32868 * LONG_LONG_TYPE_SIZE: Type Layout. (line 33) 32869 * LONG_TYPE_SIZE: Type Layout. (line 22) 32870 * longjmp and automatic variables: Interface. (line 52) 32871 * Loop analysis: Loop representation. 32872 (line 6) 32873 * Loop manipulation: Loop manipulation. (line 6) 32874 * Loop querying: Loop querying. (line 6) 32875 * Loop representation: Loop representation. 32876 (line 6) 32877 * Loop-closed SSA form: LCSSA. (line 6) 32878 * LOOP_ALIGN: Alignment Output. (line 35) 32879 * LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 48) 32880 * LOOP_EXPR: Expression trees. (line 6) 32881 * looping instruction patterns: Looping Patterns. (line 6) 32882 * Loops: Loops. (line 6) 32883 * lowering, language-dependent intermediate representation: Parsing pass. 32884 (line 14) 32885 * LSHIFT_EXPR: Expression trees. (line 6) 32886 * lshiftrt: Arithmetic. (line 173) 32887 * lshiftrt and attributes: Expressions. (line 64) 32888 * lshrM3 instruction pattern: Standard Names. (line 309) 32889 * lt: Comparisons. (line 68) 32890 * lt and attributes: Expressions. (line 64) 32891 * LT_EXPR: Expression trees. (line 6) 32892 * LTGT_EXPR: Expression trees. (line 6) 32893 * ltu: Comparisons. (line 68) 32894 * m in constraint: Simple Constraints. (line 17) 32895 * machine attributes: Target Attributes. (line 6) 32896 * machine description macros: Target Macros. (line 6) 32897 * machine descriptions: Machine Desc. (line 6) 32898 * machine mode conversions: Conversions. (line 6) 32899 * machine modes: Machine Modes. (line 6) 32900 * machine specific constraints: Machine Constraints. 32901 (line 6) 32902 * machine-independent predicates: Machine-Independent Predicates. 32903 (line 6) 32904 * machine_mode: Condition Code. (line 157) 32905 * macros in .md files: Macros. (line 6) 32906 * macros, target description: Target Macros. (line 6) 32907 * MAKE_DECL_ONE_ONLY: Label Output. (line 209) 32908 * make_safe_from: Expander Definitions. 32909 (line 148) 32910 * makefile fragment: Fragments. (line 6) 32911 * makefile targets: Makefile. (line 6) 32912 * marking roots: GGC Roots. (line 6) 32913 * MASK_RETURN_ADDR: Exception Region Output. 32914 (line 35) 32915 * match_dup <1>: define_peephole2. (line 28) 32916 * match_dup: RTL Template. (line 73) 32917 * match_dup and attributes: Insn Lengths. (line 16) 32918 * match_op_dup: RTL Template. (line 163) 32919 * match_operand: RTL Template. (line 16) 32920 * match_operand and attributes: Expressions. (line 55) 32921 * match_operator: RTL Template. (line 95) 32922 * match_par_dup: RTL Template. (line 219) 32923 * match_parallel: RTL Template. (line 172) 32924 * match_scratch <1>: define_peephole2. (line 28) 32925 * match_scratch: RTL Template. (line 58) 32926 * matching constraint: Simple Constraints. (line 130) 32927 * matching operands: Output Template. (line 49) 32928 * math library: Soft float library routines. 32929 (line 6) 32930 * math, in RTL: Arithmetic. (line 6) 32931 * MATH_LIBRARY: Misc. (line 542) 32932 * matherr: Library Calls. (line 58) 32933 * MAX_BITS_PER_WORD: Storage Layout. (line 61) 32934 * MAX_CONDITIONAL_EXECUTE: Misc. (line 564) 32935 * MAX_FIXED_MODE_SIZE: Storage Layout. (line 363) 32936 * MAX_MOVE_MAX: Misc. (line 120) 32937 * MAX_OFILE_ALIGNMENT: Storage Layout. (line 193) 32938 * MAX_REGS_PER_ADDRESS: Addressing Modes. (line 42) 32939 * maxM3 instruction pattern: Standard Names. (line 201) 32940 * may_trap_p, tree_could_trap_p: Edges. (line 115) 32941 * maybe_undef: GTY Options. (line 171) 32942 * mcount: Profiling. (line 12) 32943 * MD_CAN_REDIRECT_BRANCH: Misc. (line 689) 32944 * MD_EXEC_PREFIX: Driver. (line 330) 32945 * MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 98) 32946 * MD_HANDLE_UNWABI: Exception Handling. (line 117) 32947 * MD_STARTFILE_PREFIX: Driver. (line 358) 32948 * MD_STARTFILE_PREFIX_1: Driver. (line 364) 32949 * MD_UNWIND_SUPPORT: Exception Handling. (line 94) 32950 * mem: Regs and Memory. (line 249) 32951 * mem and /c: Flags. (line 84) 32952 * mem and /f: Flags. (line 70) 32953 * mem and /j: Flags. (line 64) 32954 * mem and /s: Flags. (line 55) 32955 * mem and /u: Flags. (line 137) 32956 * mem and /v: Flags. (line 79) 32957 * mem, RTL sharing: Sharing. (line 40) 32958 * MEM_ALIAS_SET: Special Accessors. (line 9) 32959 * MEM_ALIGN: Special Accessors. (line 36) 32960 * MEM_EXPR: Special Accessors. (line 20) 32961 * MEM_IN_STRUCT_P: Flags. (line 55) 32962 * MEM_KEEP_ALIAS_SET_P: Flags. (line 64) 32963 * MEM_NOTRAP_P: Flags. (line 84) 32964 * MEM_OFFSET: Special Accessors. (line 28) 32965 * MEM_READONLY_P: Flags. (line 137) 32966 * MEM_SCALAR_P: Flags. (line 70) 32967 * MEM_SIZE: Special Accessors. (line 31) 32968 * MEM_VOLATILE_P: Flags. (line 79) 32969 * MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 341) 32970 * memory reference, nonoffsettable: Simple Constraints. (line 244) 32971 * memory references in constraints: Simple Constraints. (line 17) 32972 * memory_barrier instruction pattern: Standard Names. (line 1189) 32973 * MEMORY_MOVE_COST: Costs. (line 29) 32974 * memory_operand: Machine-Independent Predicates. 32975 (line 58) 32976 * METHOD_TYPE: Types. (line 6) 32977 * MIN_UNITS_PER_WORD: Storage Layout. (line 71) 32978 * MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 171) 32979 * minM3 instruction pattern: Standard Names. (line 201) 32980 * minus: Arithmetic. (line 36) 32981 * minus and attributes: Expressions. (line 64) 32982 * minus, canonicalization of: Insn Canonicalizations. 32983 (line 27) 32984 * MINUS_EXPR: Expression trees. (line 6) 32985 * MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6) 32986 * mod: Arithmetic. (line 120) 32987 * mod and attributes: Expressions. (line 64) 32988 * mode classes: Machine Modes. (line 146) 32989 * mode macros in .md files: Mode Macros. (line 6) 32990 * mode switching: Mode Switching. (line 6) 32991 * MODE_AFTER: Mode Switching. (line 49) 32992 * MODE_BASE_REG_CLASS: Register Classes. (line 112) 32993 * MODE_BASE_REG_REG_CLASS: Register Classes. (line 118) 32994 * MODE_CC: Machine Modes. (line 179) 32995 * MODE_CODE_BASE_REG_CLASS: Register Classes. (line 125) 32996 * MODE_COMPLEX_FLOAT: Machine Modes. (line 171) 32997 * MODE_COMPLEX_INT: Machine Modes. (line 168) 32998 * MODE_DECIMAL_FLOAT: Machine Modes. (line 164) 32999 * MODE_ENTRY: Mode Switching. (line 54) 33000 * MODE_EXIT: Mode Switching. (line 60) 33001 * MODE_FLOAT: Machine Modes. (line 160) 33002 * MODE_FUNCTION: Machine Modes. (line 175) 33003 * MODE_HAS_INFINITIES: Storage Layout. (line 428) 33004 * MODE_HAS_NANS: Storage Layout. (line 418) 33005 * MODE_HAS_SIGN_DEPENDENT_ROUNDING: Storage Layout. (line 450) 33006 * MODE_HAS_SIGNED_ZEROS: Storage Layout. (line 434) 33007 * MODE_INT: Machine Modes. (line 152) 33008 * MODE_NEEDED: Mode Switching. (line 42) 33009 * MODE_PARTIAL_INT: Machine Modes. (line 156) 33010 * MODE_PRIORITY_TO_MODE: Mode Switching. (line 66) 33011 * MODE_RANDOM: Machine Modes. (line 184) 33012 * MODES_TIEABLE_P: Values in Registers. 33013 (line 128) 33014 * modifiers in constraints: Modifiers. (line 6) 33015 * MODIFY_EXPR: Expression trees. (line 6) 33016 * MODIFY_JNI_METHOD_CALL: Misc. (line 740) 33017 * MODIFY_TARGET_NAME: Driver. (line 385) 33018 * modM3 instruction pattern: Standard Names. (line 194) 33019 * modulo scheduling: RTL passes. (line 131) 33020 * MOVE_BY_PIECES_P: Costs. (line 104) 33021 * MOVE_MAX: Misc. (line 115) 33022 * MOVE_MAX_PIECES: Costs. (line 110) 33023 * MOVE_RATIO: Costs. (line 91) 33024 * movM instruction pattern: Standard Names. (line 11) 33025 * movmemM instruction pattern: Standard Names. (line 494) 33026 * movmisalignM instruction pattern: Standard Names. (line 126) 33027 * movMODEcc instruction pattern: Standard Names. (line 672) 33028 * movstr instruction pattern: Standard Names. (line 522) 33029 * movstrictM instruction pattern: Standard Names. (line 120) 33030 * mulhisi3 instruction pattern: Standard Names. (line 255) 33031 * mulM3 instruction pattern: Standard Names. (line 194) 33032 * mulqihi3 instruction pattern: Standard Names. (line 259) 33033 * mulsidi3 instruction pattern: Standard Names. (line 259) 33034 * mult: Arithmetic. (line 91) 33035 * mult and attributes: Expressions. (line 64) 33036 * mult, canonicalization of: Insn Canonicalizations. 33037 (line 27) 33038 * MULT_EXPR: Expression trees. (line 6) 33039 * MULTILIB_DEFAULTS: Driver. (line 315) 33040 * MULTILIB_DIRNAMES: Target Fragment. (line 64) 33041 * MULTILIB_EXCEPTIONS: Target Fragment. (line 84) 33042 * MULTILIB_EXTRA_OPTS: Target Fragment. (line 96) 33043 * MULTILIB_MATCHES: Target Fragment. (line 77) 33044 * MULTILIB_OPTIONS: Target Fragment. (line 44) 33045 * multiple alternative constraints: Multi-Alternative. (line 6) 33046 * MULTIPLE_SYMBOL_SPACES: Misc. (line 522) 33047 * multiplication: Arithmetic. (line 91) 33048 * MUST_USE_SJLJ_EXCEPTIONS: Exception Region Output. 33049 (line 64) 33050 * n in constraint: Simple Constraints. (line 63) 33051 * N_REG_CLASSES: Register Classes. (line 76) 33052 * name: Identifiers. (line 6) 33053 * named patterns and conditions: Patterns. (line 47) 33054 * names, pattern: Standard Names. (line 6) 33055 * namespace: Namespaces. (line 6) 33056 * namespace, class, scope: Scopes. (line 6) 33057 * NAMESPACE_DECL <1>: Namespaces. (line 6) 33058 * NAMESPACE_DECL: Declarations. (line 6) 33059 * NATIVE_SYSTEM_HEADER_DIR: Target Fragment. (line 103) 33060 * ne: Comparisons. (line 56) 33061 * ne and attributes: Expressions. (line 64) 33062 * NE_EXPR: Expression trees. (line 6) 33063 * nearbyintM2 instruction pattern: Standard Names. (line 410) 33064 * neg: Arithmetic. (line 81) 33065 * neg and attributes: Expressions. (line 64) 33066 * neg, canonicalization of: Insn Canonicalizations. 33067 (line 27) 33068 * NEGATE_EXPR: Expression trees. (line 6) 33069 * negation: Arithmetic. (line 81) 33070 * negation with signed saturation: Arithmetic. (line 81) 33071 * negM2 instruction pattern: Standard Names. (line 313) 33072 * nested functions, trampolines for: Trampolines. (line 6) 33073 * nested_ptr: GTY Options. (line 178) 33074 * next_bb, prev_bb, FOR_EACH_BB: Basic Blocks. (line 10) 33075 * next_cc0_user: Jump Patterns. (line 64) 33076 * NEXT_INSN: Insns. (line 30) 33077 * NEXT_OBJC_RUNTIME: Library Calls. (line 85) 33078 * nil: RTL Objects. (line 73) 33079 * NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 39) 33080 * NO_DBX_FUNCTION_END: DBX Hooks. (line 33) 33081 * NO_DBX_GCC_MARKER: File Names and DBX. (line 28) 33082 * NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 23) 33083 * NO_DOLLAR_IN_LABEL: Misc. (line 486) 33084 * NO_DOT_IN_LABEL: Misc. (line 492) 33085 * NO_FUNCTION_CSE: Costs. (line 178) 33086 * NO_IMPLICIT_EXTERN_C: Misc. (line 365) 33087 * no_new_pseudos: Standard Names. (line 75) 33088 * NO_PROFILE_COUNTERS: Profiling. (line 28) 33089 * NO_REGS: Register Classes. (line 17) 33090 * NON_LVALUE_EXPR: Expression trees. (line 6) 33091 * nondeterministic finite state automaton: Processor pipeline description. 33092 (line 296) 33093 * nonimmediate_operand: Machine-Independent Predicates. 33094 (line 101) 33095 * nonlocal goto handler: Edges. (line 171) 33096 * nonlocal_goto instruction pattern: Standard Names. (line 1036) 33097 * nonlocal_goto_receiver instruction pattern: Standard Names. 33098 (line 1053) 33099 * nonmemory_operand: Machine-Independent Predicates. 33100 (line 97) 33101 * nonoffsettable memory reference: Simple Constraints. (line 244) 33102 * nop instruction pattern: Standard Names. (line 854) 33103 * NOP_EXPR: Expression trees. (line 6) 33104 * normal predicates: Predicates. (line 31) 33105 * not: Arithmetic. (line 138) 33106 * not and attributes: Expressions. (line 50) 33107 * not equal: Comparisons. (line 56) 33108 * not, canonicalization of: Insn Canonicalizations. 33109 (line 27) 33110 * note: Insns. (line 166) 33111 * note and /i: Flags. (line 133) 33112 * note and /v: Flags. (line 29) 33113 * NOTE_INSN_BASIC_BLOCK, CODE_LABEL, notes: Basic Blocks. (line 41) 33114 * NOTE_INSN_BLOCK_BEG: Insns. (line 191) 33115 * NOTE_INSN_BLOCK_END: Insns. (line 191) 33116 * NOTE_INSN_DELETED: Insns. (line 181) 33117 * NOTE_INSN_DELETED_LABEL: Insns. (line 186) 33118 * NOTE_INSN_EH_REGION_BEG: Insns. (line 197) 33119 * NOTE_INSN_EH_REGION_END: Insns. (line 197) 33120 * NOTE_INSN_FUNCTION_BEG: Insns. (line 221) 33121 * NOTE_INSN_FUNCTION_END: Insns. (line 225) 33122 * NOTE_INSN_LOOP_BEG: Insns. (line 205) 33123 * NOTE_INSN_LOOP_CONT: Insns. (line 211) 33124 * NOTE_INSN_LOOP_END: Insns. (line 205) 33125 * NOTE_INSN_LOOP_VTOP: Insns. (line 215) 33126 * NOTE_LINE_NUMBER: Insns. (line 166) 33127 * NOTE_SOURCE_FILE: Insns. (line 166) 33128 * NOTICE_UPDATE_CC: Condition Code. (line 33) 33129 * NUM_MACHINE_MODES: Machine Modes. (line 197) 33130 * NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30) 33131 * Number of iterations analysis: Number of iterations. 33132 (line 6) 33133 * o in constraint: Simple Constraints. (line 21) 33134 * OBJC_GEN_METHOD_LABEL: Label Output. (line 402) 33135 * OBJC_JBLEN: Misc. (line 875) 33136 * OBJECT_FORMAT_COFF: Macros for Initialization. 33137 (line 97) 33138 * OFFSET_TYPE: Types. (line 6) 33139 * offsettable address: Simple Constraints. (line 21) 33140 * OImode: Machine Modes. (line 51) 33141 * OMP_ATOMIC: Expression trees. (line 6) 33142 * OMP_CLAUSE: Expression trees. (line 6) 33143 * OMP_CONTINUE: Expression trees. (line 6) 33144 * OMP_CRITICAL: Expression trees. (line 6) 33145 * OMP_FOR: Expression trees. (line 6) 33146 * OMP_MASTER: Expression trees. (line 6) 33147 * OMP_ORDERED: Expression trees. (line 6) 33148 * OMP_PARALLEL: Expression trees. (line 6) 33149 * OMP_RETURN: Expression trees. (line 6) 33150 * OMP_SECTION: Expression trees. (line 6) 33151 * OMP_SECTIONS: Expression trees. (line 6) 33152 * OMP_SINGLE: Expression trees. (line 6) 33153 * one_cmplM2 instruction pattern: Standard Names. (line 473) 33154 * operand access: Accessors. (line 6) 33155 * Operand Access Routines: Statement Operands. (line 119) 33156 * operand constraints: Constraints. (line 6) 33157 * Operand Iterators: Statement Operands. (line 119) 33158 * operand predicates: Predicates. (line 6) 33159 * operand substitution: Output Template. (line 6) 33160 * operands <1>: Patterns. (line 53) 33161 * operands: Statement Operands. (line 6) 33162 * operator predicates: Predicates. (line 6) 33163 * Optimization infrastructure for GIMPLE: Tree SSA. (line 6) 33164 * OPTIMIZATION_OPTIONS: Run-time Target. (line 106) 33165 * OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 9) 33166 * option specification files: Options. (line 6) 33167 * OPTION_DEFAULT_SPECS: Driver. (line 88) 33168 * optional hardware or system features: Run-time Target. (line 59) 33169 * options, directory search: Including Patterns. (line 44) 33170 * opts.sh: Options. (line 6) 33171 * order of register allocation: Allocation Order. (line 6) 33172 * ORDER_REGS_FOR_LOCAL_ALLOC: Allocation Order. (line 23) 33173 * ORDERED_EXPR: Expression trees. (line 6) 33174 * Ordering of Patterns: Pattern Ordering. (line 6) 33175 * ORIGINAL_REGNO: Special Accessors. (line 40) 33176 * other register constraints: Simple Constraints. (line 161) 33177 * OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 70) 33178 * OUTGOING_REGNO: Register Basics. (line 98) 33179 * output of assembler code: File Framework. (line 6) 33180 * output statements: Output Statement. (line 6) 33181 * output templates: Output Template. (line 6) 33182 * OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 39) 33183 * output_asm_insn: Output Statement. (line 53) 33184 * OUTPUT_QUOTED_STRING: File Framework. (line 76) 33185 * OVERLOAD: Functions. (line 6) 33186 * OVERRIDE_OPTIONS: Run-time Target. (line 90) 33187 * OVL_CURRENT: Functions. (line 6) 33188 * OVL_NEXT: Functions. (line 6) 33189 * p in constraint: Simple Constraints. (line 152) 33190 * PAD_VARARGS_DOWN: Register Arguments. (line 206) 33191 * parallel: Side Effects. (line 201) 33192 * param_is: GTY Options. (line 114) 33193 * parameters, c++ abi: C++ ABI. (line 6) 33194 * parameters, miscellaneous: Misc. (line 6) 33195 * parameters, precompiled headers: PCH Target. (line 6) 33196 * paramN_is: GTY Options. (line 132) 33197 * parity: Arithmetic. (line 216) 33198 * parityM2 instruction pattern: Standard Names. (line 467) 33199 * PARM_BOUNDARY: Storage Layout. (line 143) 33200 * PARM_DECL: Declarations. (line 6) 33201 * PARSE_LDD_OUTPUT: Macros for Initialization. 33202 (line 121) 33203 * passes and files of the compiler: Passes. (line 6) 33204 * passing arguments: Interface. (line 36) 33205 * PATH_SEPARATOR: Filesystem. (line 31) 33206 * PATTERN: Insns. (line 251) 33207 * pattern conditions: Patterns. (line 43) 33208 * pattern names: Standard Names. (line 6) 33209 * Pattern Ordering: Pattern Ordering. (line 6) 33210 * patterns: Patterns. (line 6) 33211 * pc: Regs and Memory. (line 236) 33212 * pc and attributes: Insn Lengths. (line 20) 33213 * pc, RTL sharing: Sharing. (line 25) 33214 * PC_REGNUM: Register Basics. (line 112) 33215 * pc_rtx: Regs and Memory. (line 241) 33216 * PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 255) 33217 * PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 64) 33218 * PDImode: Machine Modes. (line 40) 33219 * peephole optimization, RTL representation: Side Effects. (line 235) 33220 * peephole optimizer definitions: Peephole Definitions. 33221 (line 6) 33222 * per-function data: Per-Function Data. (line 6) 33223 * percent sign: Output Template. (line 6) 33224 * PHI_ARG_DEF: SSA. (line 71) 33225 * PHI_ARG_EDGE: SSA. (line 68) 33226 * PHI_ARG_ELT: SSA. (line 63) 33227 * PHI_NUM_ARGS: SSA. (line 59) 33228 * PHI_RESULT: SSA. (line 56) 33229 * PIC: PIC. (line 6) 33230 * PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 26) 33231 * PIC_OFFSET_TABLE_REGNUM: PIC. (line 16) 33232 * pipeline hazard recognizer: Processor pipeline description. 33233 (line 53) 33234 * plus: Arithmetic. (line 14) 33235 * plus and attributes: Expressions. (line 64) 33236 * plus, canonicalization of: Insn Canonicalizations. 33237 (line 27) 33238 * PLUS_EXPR: Expression trees. (line 6) 33239 * Pmode: Misc. (line 337) 33240 * pmode_register_operand: Machine-Independent Predicates. 33241 (line 35) 33242 * pointer: Types. (line 6) 33243 * POINTER_SIZE: Storage Layout. (line 83) 33244 * POINTER_TYPE: Types. (line 6) 33245 * POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 89) 33246 * pop_operand: Machine-Independent Predicates. 33247 (line 88) 33248 * popcount: Arithmetic. (line 212) 33249 * popcountM2 instruction pattern: Standard Names. (line 461) 33250 * portability: Portability. (line 6) 33251 * position independent code: PIC. (line 6) 33252 * post_dec: Incdec. (line 25) 33253 * post_inc: Incdec. (line 30) 33254 * post_modify: Incdec. (line 33) 33255 * POSTDECREMENT_EXPR: Expression trees. (line 6) 33256 * POSTINCREMENT_EXPR: Expression trees. (line 6) 33257 * POWI_MAX_MULTS: Misc. (line 788) 33258 * powM3 instruction pattern: Standard Names. (line 359) 33259 * pragma: Misc. (line 429) 33260 * pre_dec: Incdec. (line 8) 33261 * PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 110) 33262 * pre_inc: Incdec. (line 22) 33263 * pre_modify: Incdec. (line 51) 33264 * PREDECREMENT_EXPR: Expression trees. (line 6) 33265 * predefined macros: Run-time Target. (line 6) 33266 * predicates: Predicates. (line 6) 33267 * predicates and machine modes: Predicates. (line 31) 33268 * predication: Conditional Execution. 33269 (line 6) 33270 * predict.def: Profile information. 33271 (line 24) 33272 * PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 42) 33273 * PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 231) 33274 * PREFERRED_RELOAD_CLASS: Register Classes. (line 196) 33275 * PREFERRED_STACK_BOUNDARY: Storage Layout. (line 157) 33276 * prefetch: Side Effects. (line 309) 33277 * prefetch instruction pattern: Standard Names. (line 1173) 33278 * PREINCREMENT_EXPR: Expression trees. (line 6) 33279 * presence_set: Processor pipeline description. 33280 (line 215) 33281 * preserving SSA form: SSA. (line 76) 33282 * preserving virtual SSA form: SSA. (line 189) 33283 * prev_active_insn: define_peephole. (line 60) 33284 * prev_cc0_setter: Jump Patterns. (line 64) 33285 * PREV_INSN: Insns. (line 26) 33286 * PRINT_OPERAND: Instruction Output. (line 68) 33287 * PRINT_OPERAND_ADDRESS: Instruction Output. (line 96) 33288 * PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 89) 33289 * processor functional units: Processor pipeline description. 33290 (line 68) 33291 * processor pipeline description: Processor pipeline description. 33292 (line 6) 33293 * product: Arithmetic. (line 91) 33294 * profile feedback: Profile information. 33295 (line 14) 33296 * profile representation: Profile information. 33297 (line 6) 33298 * PROFILE_BEFORE_PROLOGUE: Profiling. (line 35) 33299 * PROFILE_HOOK: Profiling. (line 23) 33300 * profiling, code generation: Profiling. (line 6) 33301 * program counter: Regs and Memory. (line 237) 33302 * prologue: Function Entry. (line 6) 33303 * prologue instruction pattern: Standard Names. (line 1119) 33304 * PROMOTE_FUNCTION_MODE: Storage Layout. (line 122) 33305 * PROMOTE_MODE: Storage Layout. (line 99) 33306 * pseudo registers: Regs and Memory. (line 9) 33307 * PSImode: Machine Modes. (line 32) 33308 * PTRDIFF_TYPE: Type Layout. (line 144) 33309 * PTRMEM_CST: Expression trees. (line 6) 33310 * PTRMEM_CST_CLASS: Expression trees. (line 6) 33311 * PTRMEM_CST_MEMBER: Expression trees. (line 6) 33312 * purge_dead_edges <1>: Maintaining the CFG. 33313 (line 93) 33314 * purge_dead_edges: Edges. (line 104) 33315 * push address instruction: Simple Constraints. (line 152) 33316 * PUSH_ARGS: Stack Arguments. (line 18) 33317 * PUSH_ARGS_REVERSED: Stack Arguments. (line 26) 33318 * push_operand: Machine-Independent Predicates. 33319 (line 81) 33320 * push_reload: Addressing Modes. (line 157) 33321 * PUSH_ROUNDING: Stack Arguments. (line 32) 33322 * pushM1 instruction pattern: Standard Names. (line 181) 33323 * PUT_CODE: RTL Objects. (line 47) 33324 * PUT_MODE: Machine Modes. (line 194) 33325 * PUT_REG_NOTE_KIND: Insns. (line 317) 33326 * PUT_SDB_: SDB and DWARF. (line 63) 33327 * QCmode: Machine Modes. (line 124) 33328 * QFmode: Machine Modes. (line 54) 33329 * QImode: Machine Modes. (line 25) 33330 * QImode, in insn: Insns. (line 235) 33331 * qualified type: Types. (line 6) 33332 * querying function unit reservations: Processor pipeline description. 33333 (line 90) 33334 * question mark: Multi-Alternative. (line 41) 33335 * quotient: Arithmetic. (line 106) 33336 * r in constraint: Simple Constraints. (line 54) 33337 * RANGE_TEST_NON_SHORT_CIRCUIT: Costs. (line 182) 33338 * RDIV_EXPR: Expression trees. (line 6) 33339 * READONLY_DATA_SECTION_ASM_OP: Sections. (line 63) 33340 * real operands: Statement Operands. (line 6) 33341 * REAL_ARITHMETIC: Floating Point. (line 66) 33342 * REAL_CST: Expression trees. (line 6) 33343 * REAL_LIBGCC_SPEC: Driver. (line 187) 33344 * REAL_NM_FILE_NAME: Macros for Initialization. 33345 (line 106) 33346 * REAL_TYPE: Types. (line 6) 33347 * REAL_VALUE_ABS: Floating Point. (line 82) 33348 * REAL_VALUE_ATOF: Floating Point. (line 50) 33349 * REAL_VALUE_FIX: Floating Point. (line 41) 33350 * REAL_VALUE_FROM_INT: Floating Point. (line 99) 33351 * REAL_VALUE_ISINF: Floating Point. (line 59) 33352 * REAL_VALUE_ISNAN: Floating Point. (line 62) 33353 * REAL_VALUE_NEGATE: Floating Point. (line 79) 33354 * REAL_VALUE_NEGATIVE: Floating Point. (line 56) 33355 * REAL_VALUE_TO_INT: Floating Point. (line 93) 33356 * REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 142) 33357 * REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 140) 33358 * REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 141) 33359 * REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 138) 33360 * REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 139) 33361 * REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 137) 33362 * REAL_VALUE_TRUNCATE: Floating Point. (line 86) 33363 * REAL_VALUE_TYPE: Floating Point. (line 26) 33364 * REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 45) 33365 * REAL_VALUES_EQUAL: Floating Point. (line 32) 33366 * REAL_VALUES_LESS: Floating Point. (line 38) 33367 * REALPART_EXPR: Expression trees. (line 6) 33368 * recog_data.operand: Instruction Output. (line 39) 33369 * recognizing insns: RTL Template. (line 6) 33370 * RECORD_TYPE <1>: Classes. (line 6) 33371 * RECORD_TYPE: Types. (line 6) 33372 * redirect_edge_and_branch: Profile information. 33373 (line 71) 33374 * redirect_edge_and_branch, redirect_jump: Maintaining the CFG. 33375 (line 103) 33376 * reduc_smax_M instruction pattern: Standard Names. (line 207) 33377 * reduc_smin_M instruction pattern: Standard Names. (line 207) 33378 * reduc_splus_M instruction pattern: Standard Names. (line 219) 33379 * reduc_umax_M instruction pattern: Standard Names. (line 213) 33380 * reduc_umin_M instruction pattern: Standard Names. (line 213) 33381 * reduc_uplus_M instruction pattern: Standard Names. (line 225) 33382 * reference: Types. (line 6) 33383 * REFERENCE_TYPE: Types. (line 6) 33384 * reg: Regs and Memory. (line 9) 33385 * reg and /f: Flags. (line 93) 33386 * reg and /i: Flags. (line 88) 33387 * reg and /v: Flags. (line 97) 33388 * reg, RTL sharing: Sharing. (line 17) 33389 * REG_ALLOC_ORDER: Allocation Order. (line 9) 33390 * REG_BR_PRED: Insns. (line 524) 33391 * REG_BR_PROB: Insns. (line 518) 33392 * REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information. 33393 (line 82) 33394 * REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information. 33395 (line 52) 33396 * REG_CC_SETTER: Insns. (line 493) 33397 * REG_CC_USER: Insns. (line 493) 33398 * reg_class: Register Classes. (line 257) 33399 * reg_class_contents: Register Basics. (line 59) 33400 * REG_CLASS_CONTENTS: Register Classes. (line 86) 33401 * REG_CLASS_FROM_CONSTRAINT: Old Constraints. (line 35) 33402 * REG_CLASS_FROM_LETTER: Old Constraints. (line 27) 33403 * REG_CLASS_NAMES: Register Classes. (line 81) 33404 * REG_CROSSING_JUMP: Insns. (line 382) 33405 * REG_DEAD: Insns. (line 328) 33406 * REG_DEAD, REG_UNUSED: Liveness information. 33407 (line 14) 33408 * REG_DEP_ANTI: Insns. (line 508) 33409 * REG_DEP_OUTPUT: Insns. (line 511) 33410 * REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 110) 33411 * REG_EQUAL: Insns. (line 398) 33412 * REG_EQUIV: Insns. (line 398) 33413 * REG_EXPR: Special Accessors. (line 46) 33414 * REG_FRAME_RELATED_EXPR: Insns. (line 530) 33415 * REG_FUNCTION_VALUE_P: Flags. (line 88) 33416 * REG_INC: Insns. (line 344) 33417 * REG_LABEL: Insns. (line 374) 33418 * reg_label and /v: Flags. (line 50) 33419 * REG_LIBCALL: Insns. (line 486) 33420 * reg_names <1>: Register Basics. (line 59) 33421 * reg_names: Instruction Output. (line 80) 33422 * REG_NO_CONFLICT: Insns. (line 358) 33423 * REG_NONNEG: Insns. (line 350) 33424 * REG_NOTE_KIND: Insns. (line 317) 33425 * REG_NOTES: Insns. (line 285) 33426 * REG_OFFSET: Special Accessors. (line 50) 33427 * REG_OK_STRICT: Addressing Modes. (line 67) 33428 * REG_PARM_STACK_SPACE: Stack Arguments. (line 56) 33429 * REG_PARM_STACK_SPACE, and FUNCTION_ARG: Register Arguments. 33430 (line 52) 33431 * REG_POINTER: Flags. (line 93) 33432 * REG_RETVAL: Insns. (line 470) 33433 * REG_SETJMP: Insns. (line 392) 33434 * REG_UNUSED: Insns. (line 337) 33435 * REG_USERVAR_P: Flags. (line 97) 33436 * regclass_for_constraint: C Constraint Interface. 33437 (line 60) 33438 * register allocation order: Allocation Order. (line 6) 33439 * register class definitions: Register Classes. (line 6) 33440 * register class preference constraints: Class Preferences. (line 6) 33441 * register pairs: Values in Registers. 33442 (line 68) 33443 * Register Transfer Language (RTL): RTL. (line 6) 33444 * register usage: Registers. (line 6) 33445 * REGISTER_MOVE_COST: Costs. (line 10) 33446 * REGISTER_NAMES: Instruction Output. (line 9) 33447 * register_operand: Machine-Independent Predicates. 33448 (line 30) 33449 * REGISTER_PREFIX: Instruction Output. (line 124) 33450 * REGISTER_TARGET_PRAGMAS: Misc. (line 371) 33451 * registers arguments: Register Arguments. (line 6) 33452 * registers in constraints: Simple Constraints. (line 54) 33453 * REGMODE_NATURAL_SIZE: Values in Registers. 33454 (line 49) 33455 * REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 170) 33456 * REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 146) 33457 * REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 157) 33458 * REGNO_OK_FOR_BASE_P: Register Classes. (line 140) 33459 * REGNO_OK_FOR_INDEX_P: Register Classes. (line 181) 33460 * REGNO_REG_CLASS: Register Classes. (line 101) 33461 * regs_ever_live: Function Entry. (line 21) 33462 * regular expressions: Processor pipeline description. 33463 (line 106) 33464 * relative costs: Costs. (line 6) 33465 * RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 325) 33466 * reload pass: Regs and Memory. (line 148) 33467 * reload_completed: Standard Names. (line 821) 33468 * reload_in instruction pattern: Standard Names. (line 99) 33469 * reload_in_progress: Standard Names. (line 57) 33470 * reload_out instruction pattern: Standard Names. (line 99) 33471 * reloading: RTL passes. (line 172) 33472 * remainder: Arithmetic. (line 120) 33473 * reorder: GTY Options. (line 199) 33474 * representation of RTL: RTL. (line 6) 33475 * reservation delays: Processor pipeline description. 33476 (line 6) 33477 * rest_of_decl_compilation: Parsing pass. (line 52) 33478 * rest_of_type_compilation: Parsing pass. (line 52) 33479 * restore_stack_block instruction pattern: Standard Names. (line 955) 33480 * restore_stack_function instruction pattern: Standard Names. 33481 (line 955) 33482 * restore_stack_nonlocal instruction pattern: Standard Names. 33483 (line 955) 33484 * RESULT_DECL: Declarations. (line 6) 33485 * return: Side Effects. (line 72) 33486 * return instruction pattern: Standard Names. (line 808) 33487 * return values in registers: Scalar Return. (line 6) 33488 * RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 135) 33489 * RETURN_ADDR_OFFSET: Exception Handling. (line 60) 33490 * RETURN_ADDR_RTX: Frame Layout. (line 124) 33491 * RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 51) 33492 * RETURN_EXPR: Function Bodies. (line 6) 33493 * RETURN_POPS_ARGS: Stack Arguments. (line 87) 33494 * RETURN_STMT: Function Bodies. (line 6) 33495 * returning aggregate values: Aggregate Return. (line 6) 33496 * returning structures and unions: Interface. (line 10) 33497 * reverse probability: Profile information. 33498 (line 66) 33499 * REVERSE_CONDEXEC_PREDICATES_P: Condition Code. (line 129) 33500 * REVERSE_CONDITION: Condition Code. (line 116) 33501 * REVERSIBLE_CC_MODE: Condition Code. (line 102) 33502 * right rotate: Arithmetic. (line 178) 33503 * right shift: Arithmetic. (line 173) 33504 * rintM2 instruction pattern: Standard Names. (line 418) 33505 * RISC: Processor pipeline description. 33506 (line 6) 33507 * roots, marking: GGC Roots. (line 6) 33508 * rotate: Arithmetic. (line 178) 33509 * rotatert: Arithmetic. (line 178) 33510 * rotlM3 instruction pattern: Standard Names. (line 309) 33511 * rotrM3 instruction pattern: Standard Names. (line 309) 33512 * Rough GIMPLE Grammar: Rough GIMPLE Grammar. 33513 (line 6) 33514 * ROUND_DIV_EXPR: Expression trees. (line 6) 33515 * ROUND_MOD_EXPR: Expression trees. (line 6) 33516 * ROUND_TOWARDS_ZERO: Storage Layout. (line 459) 33517 * ROUND_TYPE_ALIGN: Storage Layout. (line 354) 33518 * roundM2 instruction pattern: Standard Names. (line 394) 33519 * RSHIFT_EXPR: Expression trees. (line 6) 33520 * RTL addition: Arithmetic. (line 14) 33521 * RTL addition with signed saturation: Arithmetic. (line 14) 33522 * RTL addition with unsigned saturation: Arithmetic. (line 14) 33523 * RTL classes: RTL Classes. (line 6) 33524 * RTL comparison: Arithmetic. (line 43) 33525 * RTL comparison operations: Comparisons. (line 6) 33526 * RTL constant expression types: Constants. (line 6) 33527 * RTL constants: Constants. (line 6) 33528 * RTL declarations: RTL Declarations. (line 6) 33529 * RTL difference: Arithmetic. (line 36) 33530 * RTL expression: RTL Objects. (line 6) 33531 * RTL expressions for arithmetic: Arithmetic. (line 6) 33532 * RTL format: RTL Classes. (line 71) 33533 * RTL format characters: RTL Classes. (line 76) 33534 * RTL function-call insns: Calls. (line 6) 33535 * RTL insn template: RTL Template. (line 6) 33536 * RTL integers: RTL Objects. (line 6) 33537 * RTL memory expressions: Regs and Memory. (line 6) 33538 * RTL object types: RTL Objects. (line 6) 33539 * RTL postdecrement: Incdec. (line 6) 33540 * RTL postincrement: Incdec. (line 6) 33541 * RTL predecrement: Incdec. (line 6) 33542 * RTL preincrement: Incdec. (line 6) 33543 * RTL register expressions: Regs and Memory. (line 6) 33544 * RTL representation: RTL. (line 6) 33545 * RTL side effect expressions: Side Effects. (line 6) 33546 * RTL strings: RTL Objects. (line 6) 33547 * RTL structure sharing assumptions: Sharing. (line 6) 33548 * RTL subtraction: Arithmetic. (line 36) 33549 * RTL subtraction with signed saturation: Arithmetic. (line 36) 33550 * RTL subtraction with unsigned saturation: Arithmetic. (line 36) 33551 * RTL sum: Arithmetic. (line 14) 33552 * RTL vectors: RTL Objects. (line 6) 33553 * RTX (See RTL): RTL Objects. (line 6) 33554 * RTX codes, classes of: RTL Classes. (line 6) 33555 * RTX_FRAME_RELATED_P: Flags. (line 106) 33556 * run-time conventions: Interface. (line 6) 33557 * run-time target specification: Run-time Target. (line 6) 33558 * s in constraint: Simple Constraints. (line 90) 33559 * same_type_p: Types. (line 102) 33560 * satisfies_constraint_: C Constraint Interface. 33561 (line 47) 33562 * SAVE_EXPR: Expression trees. (line 6) 33563 * save_stack_block instruction pattern: Standard Names. (line 955) 33564 * save_stack_function instruction pattern: Standard Names. (line 955) 33565 * save_stack_nonlocal instruction pattern: Standard Names. (line 955) 33566 * SBSS_SECTION_ASM_OP: Sections. (line 77) 33567 * Scalar evolutions: Scalar evolutions. (line 6) 33568 * scalars, returned as values: Scalar Return. (line 6) 33569 * SCHED_GROUP_P: Flags. (line 151) 33570 * SCmode: Machine Modes. (line 124) 33571 * sCOND instruction pattern: Standard Names. (line 692) 33572 * scratch: Regs and Memory. (line 173) 33573 * scratch operands: Regs and Memory. (line 173) 33574 * scratch, RTL sharing: Sharing. (line 35) 33575 * scratch_operand: Machine-Independent Predicates. 33576 (line 50) 33577 * SDATA_SECTION_ASM_OP: Sections. (line 58) 33578 * SDB_ALLOW_FORWARD_REFERENCES: SDB and DWARF. (line 81) 33579 * SDB_ALLOW_UNKNOWN_REFERENCES: SDB and DWARF. (line 76) 33580 * SDB_DEBUGGING_INFO: SDB and DWARF. (line 9) 33581 * SDB_DELIM: SDB and DWARF. (line 69) 33582 * SDB_OUTPUT_SOURCE_LINE: SDB and DWARF. (line 86) 33583 * SDmode: Machine Modes. (line 85) 33584 * sdot_prodM instruction pattern: Standard Names. (line 231) 33585 * search options: Including Patterns. (line 44) 33586 * SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 335) 33587 * SECONDARY_MEMORY_NEEDED: Register Classes. (line 391) 33588 * SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 410) 33589 * SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 401) 33590 * SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 336) 33591 * SECONDARY_RELOAD_CLASS: Register Classes. (line 334) 33592 * SELECT_CC_MODE: Condition Code. (line 68) 33593 * Selection Statements: Selection Statements. 33594 (line 6) 33595 * sequence: Side Effects. (line 251) 33596 * set: Side Effects. (line 15) 33597 * set and /f: Flags. (line 106) 33598 * SET_ASM_OP: Label Output. (line 369) 33599 * set_attr: Tagging Insns. (line 31) 33600 * set_attr_alternative: Tagging Insns. (line 49) 33601 * SET_DEST: Side Effects. (line 69) 33602 * SET_IS_RETURN_P: Flags. (line 160) 33603 * SET_LABEL_KIND: Insns. (line 138) 33604 * set_optab_libfunc: Library Calls. (line 15) 33605 * SET_SRC: Side Effects. (line 69) 33606 * setmemM instruction pattern: Standard Names. (line 530) 33607 * SETUP_FRAME_ADDRESSES: Frame Layout. (line 102) 33608 * SF_SIZE: Type Layout. (line 89) 33609 * SFmode: Machine Modes. (line 66) 33610 * sharing of RTL components: Sharing. (line 6) 33611 * shift: Arithmetic. (line 157) 33612 * SHIFT_COUNT_TRUNCATED: Misc. (line 127) 33613 * SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 96) 33614 * SHORT_TYPE_SIZE: Type Layout. (line 16) 33615 * sibcall_epilogue instruction pattern: Standard Names. (line 1145) 33616 * sibling call: Edges. (line 122) 33617 * SIBLING_CALL_P: Flags. (line 164) 33618 * sign_extend: Conversions. (line 23) 33619 * sign_extract: Bit-Fields. (line 8) 33620 * sign_extract, canonicalization of: Insn Canonicalizations. 33621 (line 93) 33622 * signed division: Arithmetic. (line 106) 33623 * signed maximum: Arithmetic. (line 125) 33624 * signed minimum: Arithmetic. (line 125) 33625 * SImode: Machine Modes. (line 37) 33626 * simple constraints: Simple Constraints. (line 6) 33627 * sinM2 instruction pattern: Standard Names. (line 335) 33628 * SIZE_ASM_OP: Label Output. (line 23) 33629 * SIZE_TYPE: Type Layout. (line 128) 33630 * skip: GTY Options. (line 77) 33631 * SLOW_BYTE_ACCESS: Costs. (line 60) 33632 * SLOW_UNALIGNED_ACCESS: Costs. (line 75) 33633 * SMALL_REGISTER_CLASSES: Register Classes. (line 433) 33634 * smax: Arithmetic. (line 125) 33635 * smin: Arithmetic. (line 125) 33636 * sms, swing, software pipelining: RTL passes. (line 131) 33637 * smulM3_highpart instruction pattern: Standard Names. (line 271) 33638 * soft float library: Soft float library routines. 33639 (line 6) 33640 * special: GTY Options. (line 219) 33641 * special predicates: Predicates. (line 31) 33642 * SPECS: Target Fragment. (line 108) 33643 * speed of instructions: Costs. (line 6) 33644 * split_block: Maintaining the CFG. 33645 (line 110) 33646 * splitting instructions: Insn Splitting. (line 6) 33647 * sqrt: Arithmetic. (line 186) 33648 * sqrtM2 instruction pattern: Standard Names. (line 319) 33649 * square root: Arithmetic. (line 186) 33650 * ss_ashift: Arithmetic. (line 157) 33651 * ss_minus: Arithmetic. (line 36) 33652 * ss_neg: Arithmetic. (line 81) 33653 * ss_plus: Arithmetic. (line 14) 33654 * ss_truncate: Conversions. (line 43) 33655 * SSA: SSA. (line 6) 33656 * SSA_NAME_DEF_STMT: SSA. (line 213) 33657 * SSA_NAME_VERSION: SSA. (line 218) 33658 * ssum_widenM3 instruction pattern: Standard Names. (line 241) 33659 * stack arguments: Stack Arguments. (line 6) 33660 * stack frame layout: Frame Layout. (line 6) 33661 * stack smashing protection: Stack Smashing Protection. 33662 (line 6) 33663 * STACK_ALIGNMENT_NEEDED: Frame Layout. (line 48) 33664 * STACK_BOUNDARY: Storage Layout. (line 149) 33665 * STACK_CHECK_BUILTIN: Stack Checking. (line 29) 33666 * STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 64) 33667 * STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 55) 33668 * STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 71) 33669 * STACK_CHECK_PROBE_INTERVAL: Stack Checking. (line 37) 33670 * STACK_CHECK_PROBE_LOAD: Stack Checking. (line 44) 33671 * STACK_CHECK_PROTECT: Stack Checking. (line 50) 33672 * STACK_DYNAMIC_OFFSET: Frame Layout. (line 75) 33673 * STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory. 33674 (line 83) 33675 * STACK_GROWS_DOWNWARD: Frame Layout. (line 9) 33676 * STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 78) 33677 * STACK_POINTER_OFFSET: Frame Layout. (line 58) 33678 * STACK_POINTER_OFFSET and virtual registers: Regs and Memory. 33679 (line 93) 33680 * STACK_POINTER_REGNUM: Frame Registers. (line 9) 33681 * STACK_POINTER_REGNUM and virtual registers: Regs and Memory. 33682 (line 83) 33683 * stack_pointer_rtx: Frame Registers. (line 85) 33684 * stack_protect_set instruction pattern: Standard Names. (line 1312) 33685 * stack_protect_test instruction pattern: Standard Names. (line 1322) 33686 * STACK_PUSH_CODE: Frame Layout. (line 17) 33687 * STACK_REGS: Stack Registers. (line 20) 33688 * STACK_SAVEAREA_MODE: Storage Layout. (line 370) 33689 * STACK_SIZE_MODE: Storage Layout. (line 382) 33690 * standard pattern names: Standard Names. (line 6) 33691 * STANDARD_INCLUDE_COMPONENT: Driver. (line 425) 33692 * STANDARD_INCLUDE_DIR: Driver. (line 417) 33693 * STANDARD_STARTFILE_PREFIX: Driver. (line 337) 33694 * STANDARD_STARTFILE_PREFIX_1: Driver. (line 344) 33695 * STANDARD_STARTFILE_PREFIX_2: Driver. (line 351) 33696 * STARTFILE_SPEC: Driver. (line 210) 33697 * STARTING_FRAME_OFFSET: Frame Layout. (line 39) 33698 * STARTING_FRAME_OFFSET and virtual registers: Regs and Memory. 33699 (line 74) 33700 * Statement Sequences: Statement Sequences. 33701 (line 6) 33702 * Statements: Statements. (line 6) 33703 * statements: Function Bodies. (line 6) 33704 * Static profile estimation: Profile information. 33705 (line 24) 33706 * static single assignment: SSA. (line 6) 33707 * STATIC_CHAIN: Frame Registers. (line 77) 33708 * STATIC_CHAIN_INCOMING: Frame Registers. (line 78) 33709 * STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 64) 33710 * STATIC_CHAIN_REGNUM: Frame Registers. (line 63) 33711 * stdarg.h and register arguments: Register Arguments. (line 47) 33712 * STDC_0_IN_SYSTEM_HEADERS: Misc. (line 354) 33713 * STMT_EXPR: Expression trees. (line 6) 33714 * STMT_IS_FULL_EXPR_P: Function Bodies. (line 22) 33715 * storage layout: Storage Layout. (line 6) 33716 * STORE_BY_PIECES_P: Costs. (line 130) 33717 * STORE_FLAG_VALUE: Misc. (line 216) 33718 * store_multiple instruction pattern: Standard Names. (line 160) 33719 * strcpy: Storage Layout. (line 206) 33720 * STRICT_ALIGNMENT: Storage Layout. (line 250) 33721 * strict_low_part: RTL Declarations. (line 9) 33722 * strict_memory_address_p: Addressing Modes. (line 167) 33723 * STRING_CST: Expression trees. (line 6) 33724 * STRING_POOL_ADDRESS_P: Flags. (line 168) 33725 * strlenM instruction pattern: Standard Names. (line 586) 33726 * structure value address: Aggregate Return. (line 6) 33727 * STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 242) 33728 * structures, returning: Interface. (line 10) 33729 * subM3 instruction pattern: Standard Names. (line 194) 33730 * SUBOBJECT: Function Bodies. (line 6) 33731 * SUBOBJECT_CLEANUP: Function Bodies. (line 6) 33732 * subreg: Regs and Memory. (line 97) 33733 * subreg and /s: Flags. (line 190) 33734 * subreg and /u: Flags. (line 183) 33735 * subreg and /u and /v: Flags. (line 173) 33736 * subreg, in strict_low_part: RTL Declarations. (line 9) 33737 * subreg, special reload handling: Regs and Memory. (line 148) 33738 * SUBREG_BYTE: Regs and Memory. (line 169) 33739 * SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 173) 33740 * SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 183) 33741 * SUBREG_PROMOTED_VAR_P: Flags. (line 190) 33742 * SUBREG_REG: Regs and Memory. (line 169) 33743 * SUCCESS_EXIT_CODE: Host Misc. (line 12) 33744 * SUPPORTS_INIT_PRIORITY: Macros for Initialization. 33745 (line 58) 33746 * SUPPORTS_ONE_ONLY: Label Output. (line 218) 33747 * SUPPORTS_WEAK: Label Output. (line 199) 33748 * SWITCH_BODY: Function Bodies. (line 6) 33749 * SWITCH_COND: Function Bodies. (line 6) 33750 * SWITCH_CURTAILS_COMPILATION: Driver. (line 33) 33751 * SWITCH_STMT: Function Bodies. (line 6) 33752 * SWITCH_TAKES_ARG: Driver. (line 9) 33753 * SWITCHES_NEED_SPACES: Driver. (line 47) 33754 * SYMBOL_FLAG_ANCHOR: Special Accessors. (line 106) 33755 * SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 88) 33756 * SYMBOL_FLAG_FUNCTION: Special Accessors. (line 81) 33757 * SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 102) 33758 * SYMBOL_FLAG_LOCAL: Special Accessors. (line 84) 33759 * SYMBOL_FLAG_SMALL: Special Accessors. (line 93) 33760 * SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 97) 33761 * symbol_ref: Constants. (line 87) 33762 * symbol_ref and /f: Flags. (line 168) 33763 * symbol_ref and /i: Flags. (line 205) 33764 * symbol_ref and /u: Flags. (line 10) 33765 * symbol_ref and /v: Flags. (line 209) 33766 * symbol_ref, RTL sharing: Sharing. (line 20) 33767 * SYMBOL_REF_ANCHOR_P: Special Accessors. (line 106) 33768 * SYMBOL_REF_BLOCK: Special Accessors. (line 119) 33769 * SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 124) 33770 * SYMBOL_REF_CONSTANT: Special Accessors. (line 67) 33771 * SYMBOL_REF_DATA: Special Accessors. (line 71) 33772 * SYMBOL_REF_DECL: Special Accessors. (line 55) 33773 * SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 88) 33774 * SYMBOL_REF_FLAG: Flags. (line 209) 33775 * SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 249) 33776 * SYMBOL_REF_FLAGS: Special Accessors. (line 75) 33777 * SYMBOL_REF_FUNCTION_P: Special Accessors. (line 81) 33778 * SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 102) 33779 * SYMBOL_REF_LOCAL_P: Special Accessors. (line 84) 33780 * SYMBOL_REF_SMALL_P: Special Accessors. (line 93) 33781 * SYMBOL_REF_TLS_MODEL: Special Accessors. (line 97) 33782 * SYMBOL_REF_USED: Flags. (line 200) 33783 * SYMBOL_REF_WEAK: Flags. (line 205) 33784 * symbolic label: Sharing. (line 20) 33785 * sync_addMODE instruction pattern: Standard Names. (line 1226) 33786 * sync_andMODE instruction pattern: Standard Names. (line 1226) 33787 * sync_compare_and_swap_ccMODE instruction pattern: Standard Names. 33788 (line 1213) 33789 * sync_compare_and_swapMODE instruction pattern: Standard Names. 33790 (line 1195) 33791 * sync_iorMODE instruction pattern: Standard Names. (line 1226) 33792 * sync_lock_releaseMODE instruction pattern: Standard Names. (line 1293) 33793 * sync_lock_test_and_setMODE instruction pattern: Standard Names. 33794 (line 1267) 33795 * sync_nandMODE instruction pattern: Standard Names. (line 1226) 33796 * sync_new_addMODE instruction pattern: Standard Names. (line 1260) 33797 * sync_new_andMODE instruction pattern: Standard Names. (line 1260) 33798 * sync_new_iorMODE instruction pattern: Standard Names. (line 1260) 33799 * sync_new_nandMODE instruction pattern: Standard Names. (line 1260) 33800 * sync_new_subMODE instruction pattern: Standard Names. (line 1260) 33801 * sync_new_xorMODE instruction pattern: Standard Names. (line 1260) 33802 * sync_old_addMODE instruction pattern: Standard Names. (line 1243) 33803 * sync_old_andMODE instruction pattern: Standard Names. (line 1243) 33804 * sync_old_iorMODE instruction pattern: Standard Names. (line 1243) 33805 * sync_old_nandMODE instruction pattern: Standard Names. (line 1243) 33806 * sync_old_subMODE instruction pattern: Standard Names. (line 1243) 33807 * sync_old_xorMODE instruction pattern: Standard Names. (line 1243) 33808 * sync_subMODE instruction pattern: Standard Names. (line 1226) 33809 * sync_xorMODE instruction pattern: Standard Names. (line 1226) 33810 * SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 239) 33811 * SYSROOT_SUFFIX_SPEC: Driver. (line 234) 33812 * SYSTEM_INCLUDE_DIR: Driver. (line 408) 33813 * t-TARGET: Target Fragment. (line 6) 33814 * table jump: Basic Blocks. (line 57) 33815 * tablejump instruction pattern: Standard Names. (line 883) 33816 * tag: GTY Options. (line 82) 33817 * tagging insns: Tagging Insns. (line 6) 33818 * tail calls: Tail Calls. (line 6) 33819 * target attributes: Target Attributes. (line 6) 33820 * target description macros: Target Macros. (line 6) 33821 * target functions: Target Structure. (line 6) 33822 * target hooks: Target Structure. (line 6) 33823 * target makefile fragment: Target Fragment. (line 6) 33824 * target specifications: Run-time Target. (line 6) 33825 * TARGET_ADDRESS_COST: Costs. (line 214) 33826 * TARGET_ALIGN_ANON_BITFIELDS: Storage Layout. (line 327) 33827 * TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 704) 33828 * TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 83) 33829 * TARGET_ARM_EABI_UNWINDER: Exception Region Output. 33830 (line 105) 33831 * TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 10) 33832 * TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 8) 33833 * TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 9) 33834 * TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 11) 33835 * TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 230) 33836 * TARGET_ASM_BYTE_OP: Data Output. (line 7) 33837 * TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 237) 33838 * TARGET_ASM_CLOSE_PAREN: Data Output. (line 128) 33839 * TARGET_ASM_CONSTRUCTOR: Macros for Initialization. 33840 (line 69) 33841 * TARGET_ASM_DESTRUCTOR: Macros for Initialization. 33842 (line 83) 33843 * TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 74) 33844 * TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 63) 33845 * TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 265) 33846 * TARGET_ASM_FILE_END: File Framework. (line 37) 33847 * TARGET_ASM_FILE_START: File Framework. (line 9) 33848 * TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 17) 33849 * TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 31) 33850 * TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 61) 33851 * TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 55) 33852 * TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 68) 33853 * TARGET_ASM_FUNCTION_EPILOGUE and trampolines: Trampolines. (line 70) 33854 * TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 11) 33855 * TARGET_ASM_FUNCTION_PROLOGUE and trampolines: Trampolines. (line 70) 33856 * TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 206) 33857 * TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 165) 33858 * TARGET_ASM_INIT_SECTIONS: Sections. (line 151) 33859 * TARGET_ASM_INTEGER: Data Output. (line 27) 33860 * TARGET_ASM_INTERNAL_LABEL: Label Output. (line 300) 33861 * TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 271) 33862 * TARGET_ASM_NAMED_SECTION: File Framework. (line 89) 33863 * TARGET_ASM_OPEN_PAREN: Data Output. (line 127) 33864 * TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 44) 33865 * TARGET_ASM_OUTPUT_DWARF_DTPREL: SDB and DWARF. (line 58) 33866 * TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 195) 33867 * TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 214) 33868 * TARGET_ASM_SELECT_SECTION: Sections. (line 172) 33869 * TARGET_ASM_TTYPE: Exception Region Output. 33870 (line 99) 33871 * TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 14) 33872 * TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 12) 33873 * TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 13) 33874 * TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 15) 33875 * TARGET_ASM_UNIQUE_SECTION: Sections. (line 193) 33876 * TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 11) 33877 * TARGET_BINDS_LOCAL_P: Sections. (line 274) 33878 * TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 774) 33879 * TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 766) 33880 * TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 249) 33881 * TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 109) 33882 * TARGET_C99_FUNCTIONS: Library Calls. (line 77) 33883 * TARGET_CALLEE_COPIES: Register Arguments. (line 115) 33884 * TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 209) 33885 * TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 753) 33886 * TARGET_COMMUTATIVE_P: Misc. (line 697) 33887 * TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 19) 33888 * TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 9) 33889 * TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 75) 33890 * TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 38) 33891 * TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 62) 33892 * TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 25) 33893 * TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 54) 33894 * TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 18) 33895 * TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 12) 33896 * TARGET_CXX_GUARD_TYPE: C++ ABI. (line 7) 33897 * TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 30) 33898 * TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 43) 33899 * TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 69) 33900 * TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 526) 33901 * TARGET_DECLSPEC: Target Attributes. (line 64) 33902 * TARGET_DEFAULT_PACK_STRUCT: Misc. (line 474) 33903 * TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 120) 33904 * TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 384) 33905 * TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 200) 33906 * TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 47) 33907 * TARGET_DWARF_CALLING_CONVENTION: SDB and DWARF. (line 18) 33908 * TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 168) 33909 * TARGET_DWARF_REGISTER_SPAN: Exception Region Output. 33910 (line 90) 33911 * TARGET_EDOM: Library Calls. (line 59) 33912 * TARGET_ENCODE_SECTION_INFO: Sections. (line 225) 33913 * TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes. 33914 (line 91) 33915 * TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 100) 33916 * TARGET_EXECUTABLE_SUFFIX: Misc. (line 727) 33917 * TARGET_EXPAND_BUILTIN: Misc. (line 649) 33918 * TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 92) 33919 * TARGET_EXPR: Expression trees. (line 6) 33920 * TARGET_EXTRA_INCLUDES: Misc. (line 799) 33921 * TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 21) 33922 * TARGET_EXTRA_PRE_INCLUDES: Misc. (line 806) 33923 * TARGET_FIXED_CONDITION_CODE_REGS: Condition Code. (line 142) 33924 * target_flags: Run-time Target. (line 52) 33925 * TARGET_FLOAT_FORMAT: Storage Layout. (line 391) 33926 * TARGET_FLT_EVAL_METHOD: Type Layout. (line 101) 33927 * TARGET_FOLD_BUILTIN: Misc. (line 669) 33928 * TARGET_FORMAT_TYPES: Misc. (line 826) 33929 * TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 86) 33930 * TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 8) 33931 * TARGET_FUNCTION_VALUE: Scalar Return. (line 11) 33932 * TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 254) 33933 * TARGET_HANDLE_OPTION: Run-time Target. (line 61) 33934 * TARGET_HAVE_CTORS_DTORS: Macros for Initialization. 33935 (line 64) 33936 * TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 99) 33937 * TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 103) 33938 * TARGET_IN_SMALL_DATA_P: Sections. (line 266) 33939 * TARGET_INIT_BUILTINS: Misc. (line 631) 33940 * TARGET_INIT_LIBFUNCS: Library Calls. (line 16) 33941 * TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 73) 33942 * TARGET_INVALID_BINARY_OP: Misc. (line 864) 33943 * TARGET_INVALID_CONVERSION: Misc. (line 851) 33944 * TARGET_INVALID_UNARY_OP: Misc. (line 857) 33945 * TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 35) 33946 * TARGET_LIBGCC_SDATA_SECTION: Sections. (line 123) 33947 * TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 616) 33948 * TARGET_MANGLE_FUNDAMENTAL_TYPE: Storage Layout. (line 529) 33949 * TARGET_MD_ASM_CLOBBERS: Misc. (line 532) 33950 * TARGET_MEM_REF: Expression trees. (line 6) 33951 * TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 39) 33952 * TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 31) 33953 * TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 106) 33954 * TARGET_MODE_REP_EXTENDED: Misc. (line 191) 33955 * TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 499) 33956 * TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 62) 33957 * TARGET_MUST_PASS_IN_STACK, and FUNCTION_ARG: Register Arguments. 33958 (line 52) 33959 * TARGET_N_FORMAT_TYPES: Misc. (line 831) 33960 * TARGET_NARROW_VOLATILE_BITFIELDS: Storage Layout. (line 333) 33961 * TARGET_OBJECT_SUFFIX: Misc. (line 722) 33962 * TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 46) 33963 * TARGET_OPTF: Misc. (line 813) 33964 * TARGET_OPTION_TRANSLATE_TABLE: Driver. (line 53) 33965 * TARGET_OS_CPP_BUILTINS: Run-time Target. (line 42) 33966 * TARGET_PASS_BY_REFERENCE: Register Arguments. (line 103) 33967 * TARGET_POSIX_IO: Misc. (line 556) 33968 * TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 152) 33969 * TARGET_PROMOTE_FUNCTION_ARGS: Storage Layout. (line 130) 33970 * TARGET_PROMOTE_FUNCTION_RETURN: Storage Layout. (line 135) 33971 * TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 11) 33972 * TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 195) 33973 * TARGET_RELAXED_ORDERING: Misc. (line 835) 33974 * TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 659) 33975 * TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 16) 33976 * TARGET_RETURN_IN_MSB: Scalar Return. (line 92) 33977 * TARGET_RTX_COSTS: Costs. (line 188) 33978 * TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 266) 33979 * TARGET_SCHED_ADJUST_COST: Scheduling. (line 37) 33980 * TARGET_SCHED_ADJUST_COST_2: Scheduling. (line 230) 33981 * TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 52) 33982 * TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 89) 33983 * TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 191) 33984 * TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 144) 33985 * TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 132) 33986 * TARGET_SCHED_FINISH: Scheduling. (line 109) 33987 * TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 126) 33988 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling. 33989 (line 154) 33990 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling. 33991 (line 182) 33992 * TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC: Scheduling. 33993 (line 274) 33994 * TARGET_SCHED_GEN_CHECK: Scheduling. (line 262) 33995 * TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 238) 33996 * TARGET_SCHED_INIT: Scheduling. (line 99) 33997 * TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 149) 33998 * TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 141) 33999 * TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 118) 34000 * TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 205) 34001 * TARGET_SCHED_ISSUE_RATE: Scheduling. (line 12) 34002 * TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 255) 34003 * TARGET_SCHED_REORDER: Scheduling. (line 60) 34004 * TARGET_SCHED_REORDER2: Scheduling. (line 77) 34005 * TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 285) 34006 * TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 244) 34007 * TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 24) 34008 * TARGET_SECTION_TYPE_FLAGS: File Framework. (line 109) 34009 * TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 26) 34010 * TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 101) 34011 * TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 154) 34012 * TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 237) 34013 * TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection. 34014 (line 17) 34015 * TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection. 34016 (line 7) 34017 * TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 137) 34018 * TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 44) 34019 * TARGET_UNWIND_EMIT: Dispatch Tables. (line 81) 34020 * TARGET_UNWIND_INFO: Exception Region Output. 34021 (line 56) 34022 * TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 55) 34023 * TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 221) 34024 * TARGET_USE_JCR_SECTION: Misc. (line 869) 34025 * TARGET_USE_LOCAL_THUNK_ALIAS_P: Misc. (line 819) 34026 * TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 128) 34027 * TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 59) 34028 * TARGET_VALID_POINTER_MODE: Register Arguments. (line 260) 34029 * TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 278) 34030 * TARGET_VECTOR_OPAQUE_P: Storage Layout. (line 492) 34031 * TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 227) 34032 * TARGET_VERSION: Run-time Target. (line 77) 34033 * TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 248) 34034 * TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 242) 34035 * TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 231) 34036 * TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 236) 34037 * targetm: Target Structure. (line 7) 34038 * targets, makefile: Makefile. (line 6) 34039 * TCmode: Machine Modes. (line 124) 34040 * TDmode: Machine Modes. (line 94) 34041 * TEMPLATE_DECL: Declarations. (line 6) 34042 * Temporaries: Temporaries. (line 6) 34043 * termination routines: Initialization. (line 6) 34044 * testing constraints: C Constraint Interface. 34045 (line 6) 34046 * TEXT_SECTION_ASM_OP: Sections. (line 38) 34047 * TF_SIZE: Type Layout. (line 92) 34048 * TFmode: Machine Modes. (line 98) 34049 * THEN_CLAUSE: Function Bodies. (line 6) 34050 * THREAD_MODEL_SPEC: Driver. (line 225) 34051 * THROW_EXPR: Expression trees. (line 6) 34052 * THUNK_DECL: Declarations. (line 6) 34053 * THUNK_DELTA: Declarations. (line 6) 34054 * TImode: Machine Modes. (line 48) 34055 * TImode, in insn: Insns. (line 235) 34056 * tm.h macros: Target Macros. (line 6) 34057 * TQFmode: Machine Modes. (line 62) 34058 * TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 62) 34059 * TRAMPOLINE_ALIGNMENT: Trampolines. (line 49) 34060 * TRAMPOLINE_SECTION: Trampolines. (line 40) 34061 * TRAMPOLINE_SIZE: Trampolines. (line 45) 34062 * TRAMPOLINE_TEMPLATE: Trampolines. (line 29) 34063 * trampolines for nested functions: Trampolines. (line 6) 34064 * TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 124) 34065 * trap instruction pattern: Standard Names. (line 1155) 34066 * tree <1>: Tree overview. (line 6) 34067 * tree: Macros and Functions. 34068 (line 6) 34069 * Tree SSA: Tree SSA. (line 6) 34070 * TREE_CODE: Tree overview. (line 6) 34071 * TREE_FILENAME: Working with declarations. 34072 (line 14) 34073 * tree_int_cst_equal: Expression trees. (line 6) 34074 * TREE_INT_CST_HIGH: Expression trees. (line 6) 34075 * TREE_INT_CST_LOW: Expression trees. (line 6) 34076 * tree_int_cst_lt: Expression trees. (line 6) 34077 * TREE_LINENO: Working with declarations. 34078 (line 20) 34079 * TREE_LIST: Containers. (line 6) 34080 * TREE_OPERAND: Expression trees. (line 6) 34081 * TREE_PUBLIC: Function Basics. (line 6) 34082 * TREE_PURPOSE: Containers. (line 6) 34083 * TREE_STRING_LENGTH: Expression trees. (line 6) 34084 * TREE_STRING_POINTER: Expression trees. (line 6) 34085 * TREE_TYPE <1>: Function Basics. (line 171) 34086 * TREE_TYPE <2>: Types. (line 6) 34087 * TREE_TYPE <3>: Expression trees. (line 6) 34088 * TREE_TYPE: Working with declarations. 34089 (line 11) 34090 * TREE_VALUE: Containers. (line 6) 34091 * TREE_VEC: Containers. (line 6) 34092 * TREE_VEC_ELT: Containers. (line 6) 34093 * TREE_VEC_LENGTH: Containers. (line 6) 34094 * Trees: Trees. (line 6) 34095 * TRULY_NOOP_TRUNCATION: Misc. (line 177) 34096 * TRUNC_DIV_EXPR: Expression trees. (line 6) 34097 * TRUNC_MOD_EXPR: Expression trees. (line 6) 34098 * truncate: Conversions. (line 38) 34099 * truncMN2 instruction pattern: Standard Names. (line 629) 34100 * TRUTH_AND_EXPR: Expression trees. (line 6) 34101 * TRUTH_ANDIF_EXPR: Expression trees. (line 6) 34102 * TRUTH_NOT_EXPR: Expression trees. (line 6) 34103 * TRUTH_OR_EXPR: Expression trees. (line 6) 34104 * TRUTH_ORIF_EXPR: Expression trees. (line 6) 34105 * TRUTH_XOR_EXPR: Expression trees. (line 6) 34106 * TRY_BLOCK: Function Bodies. (line 6) 34107 * TRY_HANDLERS: Function Bodies. (line 6) 34108 * TRY_STMTS: Function Bodies. (line 6) 34109 * tstM instruction pattern: Standard Names. (line 483) 34110 * type: Types. (line 6) 34111 * type declaration: Declarations. (line 6) 34112 * TYPE_ALIGN: Types. (line 61) 34113 * TYPE_ARG_TYPES: Types. (line 6) 34114 * TYPE_ASM_OP: Label Output. (line 55) 34115 * TYPE_ATTRIBUTES: Attributes. (line 25) 34116 * TYPE_BINFO: Classes. (line 6) 34117 * TYPE_BUILT_IN: Types. (line 83) 34118 * TYPE_CONTEXT: Types. (line 6) 34119 * TYPE_DECL: Declarations. (line 6) 34120 * TYPE_FIELDS <1>: Classes. (line 6) 34121 * TYPE_FIELDS: Types. (line 6) 34122 * TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 91) 34123 * TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 76) 34124 * TYPE_HAS_MUTABLE_P: Classes. (line 81) 34125 * TYPE_HAS_NEW_OPERATOR: Classes. (line 88) 34126 * TYPE_MAIN_VARIANT: Types. (line 50) 34127 * TYPE_MAX_VALUE: Types. (line 6) 34128 * TYPE_METHOD_BASETYPE: Types. (line 6) 34129 * TYPE_METHODS: Classes. (line 6) 34130 * TYPE_MIN_VALUE: Types. (line 6) 34131 * TYPE_NAME: Types. (line 64) 34132 * TYPE_NOTHROW_P: Function Basics. (line 180) 34133 * TYPE_OFFSET_BASETYPE: Types. (line 6) 34134 * TYPE_OPERAND_FMT: Label Output. (line 66) 34135 * TYPE_OVERLOADS_ARRAY_REF: Classes. (line 99) 34136 * TYPE_OVERLOADS_ARROW: Classes. (line 102) 34137 * TYPE_OVERLOADS_CALL_EXPR: Classes. (line 95) 34138 * TYPE_POLYMORPHIC_P: Classes. (line 72) 34139 * TYPE_PRECISION: Types. (line 6) 34140 * TYPE_PTR_P: Types. (line 89) 34141 * TYPE_PTRFN_P: Types. (line 93) 34142 * TYPE_PTRMEM_P: Types. (line 86) 34143 * TYPE_PTROB_P: Types. (line 96) 34144 * TYPE_PTROBV_P: Types. (line 6) 34145 * TYPE_QUAL_CONST: Types. (line 6) 34146 * TYPE_QUAL_RESTRICT: Types. (line 6) 34147 * TYPE_QUAL_VOLATILE: Types. (line 6) 34148 * TYPE_RAISES_EXCEPTIONS: Function Basics. (line 175) 34149 * TYPE_SIZE: Types. (line 56) 34150 * TYPE_UNQUALIFIED: Types. (line 6) 34151 * TYPE_VFIELD: Classes. (line 6) 34152 * TYPENAME_TYPE: Types. (line 6) 34153 * TYPENAME_TYPE_FULLNAME: Types. (line 6) 34154 * TYPEOF_TYPE: Types. (line 6) 34155 * udiv: Arithmetic. (line 117) 34156 * udivM3 instruction pattern: Standard Names. (line 194) 34157 * udivmodM4 instruction pattern: Standard Names. (line 296) 34158 * udot_prodM instruction pattern: Standard Names. (line 232) 34159 * UINTMAX_TYPE: Type Layout. (line 184) 34160 * umax: Arithmetic. (line 133) 34161 * umaxM3 instruction pattern: Standard Names. (line 194) 34162 * umin: Arithmetic. (line 133) 34163 * uminM3 instruction pattern: Standard Names. (line 194) 34164 * umod: Arithmetic. (line 120) 34165 * umodM3 instruction pattern: Standard Names. (line 194) 34166 * umulhisi3 instruction pattern: Standard Names. (line 262) 34167 * umulM3_highpart instruction pattern: Standard Names. (line 276) 34168 * umulqihi3 instruction pattern: Standard Names. (line 262) 34169 * umulsidi3 instruction pattern: Standard Names. (line 262) 34170 * unchanging: Flags. (line 298) 34171 * unchanging, in call_insn: Flags. (line 19) 34172 * unchanging, in jump_insn, call_insn and insn: Flags. (line 24) 34173 * unchanging, in mem: Flags. (line 137) 34174 * unchanging, in subreg: Flags. (line 183) 34175 * unchanging, in symbol_ref: Flags. (line 10) 34176 * UNEQ_EXPR: Expression trees. (line 6) 34177 * UNGE_EXPR: Expression trees. (line 6) 34178 * UNGT_EXPR: Expression trees. (line 6) 34179 * UNION_TYPE <1>: Types. (line 6) 34180 * UNION_TYPE: Classes. (line 6) 34181 * unions, returning: Interface. (line 10) 34182 * UNITS_PER_SIMD_WORD: Storage Layout. (line 77) 34183 * UNITS_PER_WORD: Storage Layout. (line 67) 34184 * UNKNOWN_TYPE: Types. (line 6) 34185 * UNLE_EXPR: Expression trees. (line 6) 34186 * UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 49) 34187 * UNLT_EXPR: Expression trees. (line 6) 34188 * UNORDERED_EXPR: Expression trees. (line 6) 34189 * unshare_all_rtl: Sharing. (line 58) 34190 * unsigned division: Arithmetic. (line 117) 34191 * unsigned greater than: Comparisons. (line 64) 34192 * unsigned less than: Comparisons. (line 68) 34193 * unsigned minimum and maximum: Arithmetic. (line 133) 34194 * unsigned_fix: Conversions. (line 72) 34195 * unsigned_float: Conversions. (line 62) 34196 * unspec: Side Effects. (line 284) 34197 * unspec_volatile: Side Effects. (line 284) 34198 * untyped_call instruction pattern: Standard Names. (line 793) 34199 * untyped_return instruction pattern: Standard Names. (line 843) 34200 * UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59) 34201 * update_ssa: SSA. (line 76) 34202 * update_stmt: Statement Operands. (line 6) 34203 * US Software GOFAST, floating point emulation library: Library Calls. 34204 (line 44) 34205 * us_minus: Arithmetic. (line 36) 34206 * us_plus: Arithmetic. (line 14) 34207 * US_SOFTWARE_GOFAST: Library Calls. (line 45) 34208 * us_truncate: Conversions. (line 48) 34209 * use: Side Effects. (line 159) 34210 * USE_C_ALLOCA: Host Misc. (line 19) 34211 * USE_LD_AS_NEEDED: Driver. (line 198) 34212 * USE_LOAD_POST_DECREMENT: Costs. (line 143) 34213 * USE_LOAD_POST_INCREMENT: Costs. (line 138) 34214 * USE_LOAD_PRE_DECREMENT: Costs. (line 153) 34215 * USE_LOAD_PRE_INCREMENT: Costs. (line 148) 34216 * use_param: GTY Options. (line 114) 34217 * use_paramN: GTY Options. (line 132) 34218 * use_params: GTY Options. (line 140) 34219 * USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 185) 34220 * USE_STORE_POST_DECREMENT: Costs. (line 163) 34221 * USE_STORE_POST_INCREMENT: Costs. (line 158) 34222 * USE_STORE_PRE_DECREMENT: Costs. (line 173) 34223 * USE_STORE_PRE_INCREMENT: Costs. (line 168) 34224 * used: Flags. (line 316) 34225 * used, in symbol_ref: Flags. (line 200) 34226 * USER_LABEL_PREFIX: Instruction Output. (line 126) 34227 * USING_DECL: Declarations. (line 6) 34228 * USING_STMT: Function Bodies. (line 6) 34229 * usmulhisi3 instruction pattern: Standard Names. (line 266) 34230 * usmulqihi3 instruction pattern: Standard Names. (line 266) 34231 * usmulsidi3 instruction pattern: Standard Names. (line 266) 34232 * usum_widenM3 instruction pattern: Standard Names. (line 242) 34233 * V in constraint: Simple Constraints. (line 41) 34234 * VA_ARG_EXPR: Expression trees. (line 6) 34235 * values, returned by functions: Scalar Return. (line 6) 34236 * VAR_DECL <1>: Expression trees. (line 6) 34237 * VAR_DECL: Declarations. (line 6) 34238 * varargs implementation: Varargs. (line 6) 34239 * variable: Declarations. (line 6) 34240 * VAX_FLOAT_FORMAT: Storage Layout. (line 399) 34241 * vec_concat: Vector Operations. (line 25) 34242 * vec_duplicate: Vector Operations. (line 30) 34243 * vec_extractM instruction pattern: Standard Names. (line 171) 34244 * vec_initM instruction pattern: Standard Names. (line 176) 34245 * vec_merge: Vector Operations. (line 11) 34246 * vec_select: Vector Operations. (line 19) 34247 * vec_setM instruction pattern: Standard Names. (line 166) 34248 * vec_shl_M instruction pattern: Standard Names. (line 249) 34249 * vec_shr_M instruction pattern: Standard Names. (line 249) 34250 * vector: Containers. (line 6) 34251 * vector operations: Vector Operations. (line 6) 34252 * VECTOR_CST: Expression trees. (line 6) 34253 * VECTOR_STORE_FLAG_VALUE: Misc. (line 308) 34254 * virtual operands: Statement Operands. (line 6) 34255 * VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59) 34256 * VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87) 34257 * VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78) 34258 * VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69) 34259 * VLIW: Processor pipeline description. 34260 (line 215) 34261 * VMS: Filesystem. (line 37) 34262 * VMS_DEBUGGING_INFO: VMS Debug. (line 9) 34263 * VOID_TYPE: Types. (line 6) 34264 * VOIDmode: Machine Modes. (line 117) 34265 * volatil: Flags. (line 330) 34266 * volatil, in insn, call_insn, jump_insn, code_label, barrier, and note: Flags. 34267 (line 29) 34268 * volatil, in label_ref and reg_label: Flags. (line 50) 34269 * volatil, in mem, asm_operands, and asm_input: Flags. (line 79) 34270 * volatil, in reg: Flags. (line 97) 34271 * volatil, in subreg: Flags. (line 173) 34272 * volatil, in symbol_ref: Flags. (line 209) 34273 * volatile memory references: Flags. (line 331) 34274 * voting between constraint alternatives: Class Preferences. (line 6) 34275 * walk_dominator_tree: SSA. (line 248) 34276 * walk_use_def_chains: SSA. (line 224) 34277 * WCHAR_TYPE: Type Layout. (line 152) 34278 * WCHAR_TYPE_SIZE: Type Layout. (line 160) 34279 * which_alternative: Output Statement. (line 59) 34280 * WHILE_BODY: Function Bodies. (line 6) 34281 * WHILE_COND: Function Bodies. (line 6) 34282 * WHILE_STMT: Function Bodies. (line 6) 34283 * WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 107) 34284 * WINT_TYPE: Type Layout. (line 165) 34285 * word_mode: Machine Modes. (line 239) 34286 * WORD_REGISTER_OPERATIONS: Misc. (line 63) 34287 * WORD_SWITCH_TAKES_ARG: Driver. (line 20) 34288 * WORDS_BIG_ENDIAN: Storage Layout. (line 29) 34289 * WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 132) 34290 * X in constraint: Simple Constraints. (line 112) 34291 * x-HOST: Host Fragment. (line 6) 34292 * XCmode: Machine Modes. (line 124) 34293 * XCOFF_DEBUGGING_INFO: DBX Options. (line 13) 34294 * XEXP: Accessors. (line 6) 34295 * XF_SIZE: Type Layout. (line 91) 34296 * XFmode: Machine Modes. (line 79) 34297 * XINT: Accessors. (line 6) 34298 * xm-MACHINE.h <1>: Filesystem. (line 6) 34299 * xm-MACHINE.h: Host Misc. (line 6) 34300 * xor: Arithmetic. (line 152) 34301 * xor, canonicalization of: Insn Canonicalizations. 34302 (line 81) 34303 * xorM3 instruction pattern: Standard Names. (line 194) 34304 * XSTR: Accessors. (line 6) 34305 * XVEC: Accessors. (line 41) 34306 * XVECEXP: Accessors. (line 48) 34307 * XVECLEN: Accessors. (line 44) 34308 * XWINT: Accessors. (line 6) 34309 * zero_extend: Conversions. (line 28) 34310 * zero_extendMN2 instruction pattern: Standard Names. (line 639) 34311 * zero_extract: Bit-Fields. (line 30) 34312 * zero_extract, canonicalization of: Insn Canonicalizations. 34313 (line 93) 34314 34315 34316 34317 Tag Table: 34318 Node: Top2088 34319 Node: Contributing4967 34320 Node: Portability5708 34321 Node: Interface7496 34322 Node: Libgcc10536 34323 Node: Integer library routines12317 34324 Node: Soft float library routines19002 34325 Node: Decimal float library routines30939 34326 Node: Exception handling routines39332 34327 Node: Miscellaneous routines40430 34328 Node: Languages40813 34329 Node: Source Tree42360 34330 Node: Configure Terms42979 34331 Node: Top Level45937 34332 Node: gcc Directory48285 34333 Node: Subdirectories49254 34334 Node: Configuration51592 34335 Node: Config Fragments52312 34336 Node: System Config53656 34337 Node: Configuration Files54592 34338 Node: Build57278 34339 Node: Makefile57690 34340 Ref: Makefile-Footnote-164407 34341 Ref: Makefile-Footnote-264556 34342 Node: Library Files64630 34343 Node: Headers65192 34344 Node: Documentation67171 34345 Node: Texinfo Manuals68030 34346 Node: Man Page Generation70354 34347 Node: Miscellaneous Docs72269 34348 Node: Front End73624 34349 Node: Front End Directory77391 34350 Node: Front End Config82632 34351 Node: Back End85861 34352 Node: Testsuites89535 34353 Node: Test Idioms90327 34354 Node: Test Directives93728 34355 Node: Ada Tests103776 34356 Node: C Tests105068 34357 Node: libgcj Tests109423 34358 Node: gcov Testing110843 34359 Node: profopt Testing113827 34360 Node: compat Testing115270 34361 Node: Options119492 34362 Node: Option file format119933 34363 Node: Option properties122483 34364 Node: Passes128142 34365 Node: Parsing pass128877 34366 Node: Gimplification pass132405 34367 Node: Pass manager134232 34368 Node: Tree-SSA passes135560 34369 Node: RTL passes157028 34370 Node: Trees168456 34371 Node: Deficiencies171182 34372 Node: Tree overview171419 34373 Node: Macros and Functions175542 34374 Node: Identifiers175688 34375 Node: Containers177213 34376 Node: Types178368 34377 Node: Scopes190902 34378 Node: Namespaces191664 34379 Node: Classes194476 34380 Node: Declarations199233 34381 Node: Working with declarations199728 34382 Node: Internal structure206185 34383 Node: Current structure hierarchy206567 34384 Node: Adding new DECL node types208659 34385 Node: Functions212730 34386 Node: Function Basics215133 34387 Node: Function Bodies222298 34388 Node: Attributes233540 34389 Node: Expression trees234781 34390 Node: Tree SSA270575 34391 Node: GENERIC272452 34392 Node: GIMPLE274062 34393 Node: Interfaces275353 34394 Node: Temporaries277506 34395 Ref: Temporaries-Footnote-1278826 34396 Node: GIMPLE Expressions278889 34397 Node: Compound Expressions279661 34398 Node: Compound Lvalues279909 34399 Node: Conditional Expressions280689 34400 Node: Logical Operators281366 34401 Node: Statements281859 34402 Node: Blocks282567 34403 Node: Statement Sequences283984 34404 Node: Empty Statements284321 34405 Node: Loops284899 34406 Node: Selection Statements285143 34407 Node: Jumps285996 34408 Node: Cleanups286657 34409 Node: GIMPLE Exception Handling288448 34410 Node: GIMPLE Example290327 34411 Node: Rough GIMPLE Grammar291738 34412 Node: Annotations296994 34413 Node: Statement Operands297660 34414 Node: SSA312966 34415 Node: Alias analysis325108 34416 Node: Loop Analysis and Representation332287 34417 Node: Loop representation333283 34418 Node: Loop querying338550 34419 Node: Loop manipulation341336 34420 Node: LCSSA344114 34421 Node: Scalar evolutions346186 34422 Node: loop-iv349430 34423 Node: Number of iterations351356 34424 Node: Dependency analysis354054 34425 Node: Lambda360422 34426 Node: RTL362078 34427 Node: RTL Objects364182 34428 Node: RTL Classes368056 34429 Node: Accessors373008 34430 Node: Special Accessors375402 34431 Node: Flags380620 34432 Node: Machine Modes395833 34433 Node: Constants405090 34434 Node: Regs and Memory411345 34435 Node: Arithmetic424419 34436 Node: Comparisons433273 34437 Node: Bit-Fields437565 34438 Node: Vector Operations439117 34439 Node: Conversions440743 34440 Node: RTL Declarations444058 34441 Node: Side Effects444879 34442 Node: Incdec460995 34443 Node: Assembler464335 34444 Node: Insns465867 34445 Node: Calls491219 34446 Node: Sharing493812 34447 Node: Reading RTL496922 34448 Node: Control Flow497912 34449 Node: Basic Blocks498883 34450 Node: Edges503451 34451 Node: Profile information512013 34452 Node: Maintaining the CFG516699 34453 Node: Liveness information523591 34454 Node: Machine Desc526011 34455 Node: Overview528490 34456 Node: Patterns530531 34457 Node: Example533969 34458 Node: RTL Template535404 34459 Node: Output Template546059 34460 Node: Output Statement550025 34461 Node: Predicates553987 34462 Node: Machine-Independent Predicates556905 34463 Node: Defining Predicates561537 34464 Node: Constraints567502 34465 Node: Simple Constraints568663 34466 Node: Multi-Alternative580725 34467 Node: Class Preferences583566 34468 Node: Modifiers584458 34469 Node: Machine Constraints588584 34470 Node: Define Constraints616148 34471 Node: C Constraint Interface622799 34472 Node: Standard Names626419 34473 Ref: shift patterns639852 34474 Ref: prologue instruction pattern676930 34475 Ref: epilogue instruction pattern677423 34476 Node: Pattern Ordering686446 34477 Node: Dependent Patterns687682 34478 Node: Jump Patterns690496 34479 Node: Looping Patterns696192 34480 Node: Insn Canonicalizations700794 34481 Node: Expander Definitions705070 34482 Node: Insn Splitting713188 34483 Node: Including Patterns722784 34484 Node: Peephole Definitions724564 34485 Node: define_peephole725817 34486 Node: define_peephole2732148 34487 Node: Insn Attributes735215 34488 Node: Defining Attributes736321 34489 Node: Expressions738338 34490 Node: Tagging Insns744940 34491 Node: Attr Example749293 34492 Node: Insn Lengths751667 34493 Node: Constant Attributes754726 34494 Node: Delay Slots755895 34495 Node: Processor pipeline description759119 34496 Ref: Processor pipeline description-Footnote-1776362 34497 Node: Conditional Execution776692 34498 Node: Constant Definitions779545 34499 Node: Macros781137 34500 Node: Mode Macros781566 34501 Node: Defining Mode Macros782505 34502 Node: Substitutions783969 34503 Node: Examples786173 34504 Node: Code Macros787609 34505 Node: Target Macros789824 34506 Node: Target Structure792776 34507 Node: Driver794045 34508 Node: Run-time Target816305 34509 Node: Per-Function Data822505 34510 Node: Storage Layout825268 34511 Node: Type Layout850010 34512 Node: Registers861398 34513 Node: Register Basics862321 34514 Node: Allocation Order867888 34515 Node: Values in Registers869333 34516 Node: Leaf Functions876306 34517 Node: Stack Registers879164 34518 Node: Register Classes880280 34519 Node: Old Constraints905855 34520 Node: Stack and Calling913007 34521 Node: Frame Layout913541 34522 Node: Exception Handling924180 34523 Node: Stack Checking930530 34524 Node: Frame Registers934161 34525 Node: Elimination940767 34526 Node: Stack Arguments944798 34527 Node: Register Arguments951375 34528 Node: Scalar Return965604 34529 Node: Aggregate Return970515 34530 Node: Caller Saves974174 34531 Node: Function Entry975352 34532 Node: Profiling987967 34533 Node: Tail Calls989666 34534 Node: Stack Smashing Protection991033 34535 Node: Varargs992145 34536 Node: Trampolines1000105 34537 Node: Library Calls1006771 34538 Node: Addressing Modes1011191 34539 Node: Anchored Addresses1023456 34540 Node: Condition Code1026117 34541 Node: Costs1034406 34542 Node: Scheduling1046406 34543 Node: Sections1062584 34544 Node: PIC1076685 34545 Node: Assembler Format1078675 34546 Node: File Framework1079754 34547 Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1084660 34548 Node: Data Output1085558 34549 Node: Uninitialized Data1093178 34550 Node: Label Output1098249 34551 Node: Initialization1119538 34552 Node: Macros for Initialization1125500 34553 Node: Instruction Output1131563 34554 Node: Dispatch Tables1140557 34555 Node: Exception Region Output1144352 34556 Node: Alignment Output1149644 34557 Node: Debugging Info1153788 34558 Node: All Debuggers1154458 34559 Node: DBX Options1157313 34560 Node: DBX Hooks1162762 34561 Node: File Names and DBX1164688 34562 Node: SDB and DWARF1166799 34563 Node: VMS Debug1170791 34564 Node: Floating Point1171361 34565 Node: Mode Switching1176183 34566 Node: Target Attributes1180109 34567 Node: MIPS Coprocessors1184851 34568 Node: PCH Target1186425 34569 Node: C++ ABI1187946 34570 Node: Misc1191918 34571 Ref: TARGET_SHIFT_TRUNCATION_MASK1199289 34572 Node: Host Config1235779 34573 Node: Host Common1236839 34574 Node: Filesystem1239218 34575 Node: Host Misc1243333 34576 Node: Fragments1245472 34577 Node: Target Fragment1246667 34578 Node: Host Fragment1252333 34579 Node: Collect21253775 34580 Node: Header Dirs1256318 34581 Node: Type Information1257741 34582 Node: GTY Options1259929 34583 Node: GGC Roots1270063 34584 Node: Files1270783 34585 Node: Funding1273143 34586 Node: GNU Project1275639 34587 Node: Copying1276288 34588 Node: GNU Free Documentation License1295468 34589 Node: Contributors1317877 34590 Node: Option Index1353736 34591 Node: Concept Index1354321 34592 34593 End Tag Table 34594
